Malware Analysis: A Python Malware on campus 1

So a few weeks back after a class I'd taken with them,  a number of my students told me of a particular malware that was affecting students' computers, in particular, computers running Windows OS. According to them, if you tried to open a folder that was residing on the USB stick with the malware, the malware would delete some of your files and convert folders into executable files. Granted, the likelihood of a random folder miraculously transforming into a single executable file was kinda "out there" but I figured I'd check it out and use that as a teaching moment for those interested in venturing into malware analysis.

So I tasked them to bring me a sample of the malware so I could take a look at it and maybe figure it out. I advised one of them to download DumpIt and then extract the memory dump from an infected computer using a clean flash disk and then bring it to me. How do you do this exactly? here's how:

1. Download DumpIt. It's a portable executable so you don't have to install it to use it.
2. Format a USB drive that is at least two times the size of the RAM on the infected computer. This is to accommodate virtual memory when copying the dumped RAM from the infected computer. If you're dealing with virtual machines, that's a different exercise and I hope I'll get a chance to post on that in future.
3. Copy the Dumpit executable to the formatted USB drive. Let's call this the Forensics USB or F-USB.
4. Connect the F-USB to the infected computer. Open the command window from that drive and run Dumpit.exe. It should automatically copy the dump to the F-USB.
5. after it's done copying, disconnect the F-USB and then go analyze the ram dump with Volatility or Redline by FireEye (also to be delved into in future articles).

So that is basically how you extract a RAM dump from an infected computer. Unfortunately, my student didn't get to bring that to me (exam pressures and all) but then another student went for a simpler approach and brought me an infected USB drive. So, to handle that, these are the steps I went through:

1. To avoid getting infected, since malware analysis is a fancy way of saying "playing with Fire" I created a live disk running a Linux distribution called REMnux OS. It's purpose is mainly for malware analysis just as SIFT3 workstation is for Forensics and Kali Linux is for penetration testing.  This may be Greek to others so this is how you create a live disk or a bootable disk using a nifty tool called Rufus:


• Download Rufus from here. It's also a portable executable so you don't have to install it to use it
• Download REMnux from here.
• Write the REMnux iso file to a USB drive while following these instuctions
• Voila! you have your first bootable USB drive which we'll call the REMnux USB or R-USB
2. Shutdown your computer and boot from the R-USB. If you're facing challenges in that it keeps booting into the OS you already have installed, have no fear. Use this link to help you configure your computer to boot from USB first. A point to note though, you may have to look for other ways to handle this challenge if your OS uses SecureBoot or is UEFI as is the case with most new machines these days. This link may help.
3. When the REMnux OS boots, you can log in. If the screen locks or if you have to enter a password, the default password is "malware". I will now proceed to explain what I did in the analysis of the malware
4. I connected the infected USB to the REMnux machine and viewed the files in the drive. it was interesting to note that all the folders in each directory had a corresponding executable file with the exact same name but with a .exe extension.
5. I then checked the hash of one executable, we'll call it W.exe (which became my primary malware sample) using md5sum from the command line and then copied it to a new file. [Please note, that as this is a live disk, it does not save anything to disk so after you shut down the computer, all the stuff you saved is lost.]
6. Out of interest, I wanted to check if each malicious executable file was different from the rest or not so i did a batch md5sum on all executables in the root directory and it showed that they all had the exact same signature!
7. I ran the file command on the executable/malware sample W.exe just to verify if it really was a PE32 windows executable file and indeed it was. 
8. Next, I ran the pestr command as  well to see if there were any strings that could be gathered from W.exe to help make sense of it. Funnily enough, it had a lot of strings (so clearly it was not stripped of strings, which can be done using the strip command,after it was created). Of note was that some of the strings were structured as Python statements which piqued my interest.
9. I then ran the pescanner command on W.exe to gain more information on its structure which is when things got very interesting. I have inserted a screenshot of the resources section of W.exe
10. 
11. this was very interesting in that there was a Python2.7 DLL which led me to assume that for the malware to execute, it needed Python to be able to run on the target and that also explained the PYTHONSCRIPT also listed in the entries. Now, typically, to convert a Python script to an executable file, people use a tool called py2exe which basically adds all necessary files for the script to run to a folder, zips it and packages it as an executable file. What that means is that to get to the source code, I'd have to unzip the executable and get to the compiled python code, if they had indeed used py2exe.
12. I then opened the browser from REMnux and submitted it to VirusTotal. VirusTotal is basically a site where you can upload suspicious programs to or their corresponding hashes to check if any antivirus (including AVG, Kaspersky and other notable AV companies) recognizes them as malicious software. It had its hash generated and apparently it had been doing the rounds for some time. The link to the VirusTotal results is here.
13. I wanted to proceed to the next stage which was static analysis with windows tools and then dynamic analysis but first I had to contain W.exe to make sure it wouldn't infect my host computer by mistake. The best way to do this is to zip and encrypt it but all I did was zip it and secure it with a password.
14. I then copied the zipped W.exe to another USB so I could then take it to my Windows malware analysis VM  which will be the topic of the next blog post.

So in summary, we were clearly dealing with a malware that was written in Python and which we could potentially reverse engineer the code to see what it did and see if the damage it did could be mitigated in some way. Say if it had been encrypting files using a symmetric encryption with a hard coded passphrase in the code, we could tweak the code to decrypt the encrypted files. Though it did not do this in particular, but that example was mainly to highlight the benefits of not simply formatting a drive with malware but trying to understand the malware and potentially undo or reduce the damage it has and can cause. 

Till the next post!