A real example of finding unknown malware in a RAM image using Volatility
Background:
While doing some research on some new intrusion detection rules I noticed that a system on a network was causing a "new" IDS rule to be tripped. The rule itself was fairly simple and looked for something similar to "SSH-2.0-PuTTY_Local:_Apr" in the payload on a destination TCP port of 22. This rule was one I hadn't seen before, so I thought I would dig in a bit and take a look. Looking through the logs the system seemed to be tripping this rule every morning around the same time, but never on the weekends. I also noticed that it would occasionally happen in the afternoon right after the lunch time as well. This led me to believe that it was only checking out when the user rebooted their system. I knew where this system was located, and I also knew that there was a fairly comprehensive firewall in front of it. This meant that it was next to impossible to attempt a remote analysis via the network (which is usually a last resort anyway). I scheduled some time with the user so I could capture RAM and find out what was going on.
The tools:
After using the super reliable Dumpit from
http://www.moonsols.com/ to create a RAM image on my flash drive I walked back to my office hoping this would end up being an interesting case. The user was already having a replacement system installed, so they would be back to work quickly as well. I copied the newly created file to my analysis network and set up my vol_script.sh mentioned in a previous blog post. In about an hour it was finished running, and I had managed to get a few other things done. Such a time saver!
First steps using Volatility's plugins:
Netscan
I knew this potential infection was using the network, so I looked at the output from the netscan plugin. The only item that really jumped out at me was that winlogon was listening on localhost via TCP port 7908 as seen here:
That's weird. I wrote down PID 8024 after inspecting the rest of the connections and moved on.
Cmdline / pstree / pslist
There are several plugins that will give you a list of processes running, including some that scan for active and exited processes. For this instance I started with pstree. Why? Because it is awesome.
PID 8024 was shown to be:
Well, that is strange! I don't recall this being a valid directory. The number of handles for a valid winlogon process is also pretty low. The parent of this process, PID 2156, turned out to be:
I sincerely doubt that winlogon.exe would be started by WScript.exe - at least it was highly suspect!
I pulled up the output from the cmdline plugin to see exactly how these processes were started. I've changed some of the variables, but the content remains largely the same:
Well, there's the problem right there! I also noticed the wininit.exe process running out of the same directory and a strange vbe script that might be able to be carved out of the RAM image.
At first glance it appears to have set up a reverse tunnel (with a modified version of putty that I recalled from the payload of the IDS alert) on TCP port 7908 using this fake winlogon.exe process. There is also a connection to a remote DNS name via the wininet.exe process. Strange.
Now I have a few tasks. See if the DNS name identified is associated with any malware, extract those processes, extract the vbe file, find the original point of compromise, and look for any other hints as to what is happening. I will concentrate on just the Volatility related tasks to keep this short.
Procdump
Part of my script already extracts the processes to a folder, so I checked the output for the PIDs I cared about:
Success! I made notes to check these executables out later. Later VirusTotal.com reported zero results. Looks like a manual disassembly is in my future if I can't figure this out!
Filescan
Next I checked the output from the filescan plugin for the GoogleIndexer.vbe file.
Success! I have the physical offset of the vbe file, so now I will try extracting the file.
Dumpfiles
This vbe file type is basically an obfuscated VBscript that uses something like Microsoft's Script Encoder to encode scripts. I had a really old conversion script in my toolkit that would "decrypt" the code, so I fired it up. The human readable output of the script was essentially the persistence mechanism that ended up running:
"
winlogon.exe -d -t -l -e0.0.0.0 -i127.0.0.1 -p7908 -a"
Later I found a startup entry in the user's registry confirming this as the persistence mechanism.
Consoles
On a whim I decided to check the output from the consoles plugin. This plugin may find commands that attackers typed into cmd.exe or executed via backdoors. The first item I noticed was my PowerShell prompt where I ran dumpit. After that I found this interesting tidbit:
That is certainly exciting! It appears to be the remote information panel for some kind of proxy. The malicious user also needs to reboot their system to apply some updates. A quick search of the IP directed me to a VirusTotal link that suggested the infection was a malicious proxy known as Penepe.
https://www.virustotal.com/en/ip-address/91.229.78.202/information/
Well, now I have enough information to confirm that this system was definitely running a malicious proxy. Now to find out how this system was originally infected. For this I looked through the logs to find out the very first time this IDS rule was tripped.
Scripted timeline
Part of my automation script runs three distinct plugins that can combined to make a simple timeline. These plugins (mftparser, shellbags, and timeliner) can all output their findings in bodyfile format. Then a quick mactime conversion will produce a very nice csv file that is easily filtered.
I knew that around 15:15 on the 23rd of the month was the first time the IDS rule was tripped, so I filtered the timeline to look for files created on the 22nd or later.
On the 23rd at 15:13 the following ZIP file was created:
A corresponding .lnk file was also created immediately following the file creation timestamp. Coincidentally, the folder where I found the three proxy files was also created at the same time.
The file obviously looks suspicious, and it appears that it was downloaded via the user's web browser. I didn't see anything else suspicious during the time frame surrounding the initial checkin, so further analysis is needed. Based on timestamps alone it looks highly suspicious.
Chromedownloads
The chromedownloads plugin is a newer plugin written by superponible (
https://github.com/superponible) that parses the contents of Google Chrome's SQLite database.
The output confirms that the user, who I knew uses Gmail, downloaded an attachment called fax-message01282190.zip and saved it to their Downloads directory.
Summary:
Now we have a potential point of compromise, the malware location, the persistence mechanism, and a nice and quick assessment of the infected system.
After 15 minutes of analysis I had all of the information I needed to report back to a local administrator on what was happening. Further work would be needed looking through network logs, but for now I was confident in the results!
Footnotes:
*I seriously considered obfuscating the DNS name and remote IP address of the malicious host. Nope! Since the IP is blacklisted a few places and one of the first Google search hits yields a VirusTotal page, I think it is safe to assume it is malicious.*
**Tonight's drink of choice is Woodford Reserve Double Oaked bourbon.**
