I've seen two samples of the same malware coming from two different spam campaigns this week. One was from an e-mail with the subject "USPS Delivery Confirmation," and the other was called "Taxes." Both contain an attached word document.
Run the document through trusty old OfficeMalScanner, and surprise surprise, it contains some VBMacros! Color me shocked. In this case, there are three of them, and they're all obfuscated, as malware often is. I haven't searched for tools to deobfuscate VBCode yet, but I finally have my bomb shelter machine set up for detonating malware in. So we move on to that.
Opened up the document, and it presents me with this lovely little gem.
Oh noes! I document have incorrect encoding! *click Enable Editing* Below we see the results of this in process explorer. The macro spawns a command prompt process, executes a ping command, and then spawns the cscript and powershell processes. Both of these interact with an adobeacd-update file, which gets changed from .bat, to .vbs, to .ps1, clearly being some kind of script exected by the powershell. I haven't been able to catch the source, but you can track the powershell process in procmon quite readily.
The powershell turns on all kinds of language settings in the registry, and downloads and executes an executable (in my case 444.exe) this exe also showed up in wireshark http objects, the first sample this exe came from 126.96.36.199 as install.exe. The second came from 188.8.131.52 as file.exe. Both executed as 444.exe.
444.exe briefly calls regsrv32.exe, which I didn't catch, but process monitor shows this. I didn't find the tie until using the autoruns utility to see what kind of persistence I could find. Autoruns revealed a dll at c:\programdata\muscopreym\aajrakbapr.qff, which has huge hits on VirusTotal. Then doing a filter for this path in procmon shows the process that created it (regsrv32).
Winlogin.exe gets spawned, but I haven't been able to determine what exactly it does yet... It's definitely part of the malware, however.
This malware also injects into every single running process (easily discovered with Volatility Malfind, as they all have the telltale MZ header.) Extracting this file and uploading it to virustotal also reveals several hits. I've actually never seen a sample that is so NOISY in volatility's malfind plugin. Definitely no attempt to hide from memory forensics on this one!
To capture and pull a volatility compatible memory dump out of VirtualBox I did the following (found these steps at https://sites.google.com/site/capaste2014/virtualbox/extracting-physical-memory-from-elf-file):
VBoxManage debugvm guestVMName dumpguestcore --filename filename.ext
This generates a kind of messy ELF file. To see the segments of this file we run the command:
readelf -W -l filename.ext
It will show a table of program headers. The first will show NOTE, then the following will all be LOADs. We are interested in the first LOAD, specifically the offset and the filesize. We need to convert these two values to decimal (the offset is where the dump starts, the size is obviously how large it is,) then we use some command line trickery to extract this section from the ELF file. In my example, the first offset translated to 1832 (but we want to add one to this value, making it 1833,) and the second value came out as 1073741824.
So, the command to cut out the part we can run volatility against became:
tail -c +1833 filename.ext | head -c 1073741824 > filename.raw
Then I simply ran my volatility plugins as per usual.
The injected dlls, as well as winlogin.exe, appear to be packed (although pescanner and pyew don't detect them,) and are beyond my current abilities for deeper analysis.