"Check my CV", Generating YARA Rules
Recently, one e-Mail that was sent to one of my colleagues caught my attention. The message was quite believable but there were some little subtleties that gave it away. First step was to get the attachment out of the message and do an initial analysis.
From Microsoft Office 2007 onwards, the Word document is in its essence a Zip file.
1#!/bin/bash
2# Decode the e-Mail attachment
3base64 -w 0 -d email-attachment-b64.txt > CV_8888.doc
4
5# Check the file type
6file CV_8888.doc
7#CV_8888.doc: Microsoft Word 2007+
8
9# Checked the contents of Word document
10unzip -l CV_8888.doc
11#Archive: CV_8888.doc
12# Length Date Time Name
13#--------- ---------- ----- ----
14# 2088 01-01-1980 00:00 [Content_Types].xml
15# 590 01-01-1980 00:00 _rels/.rels
16# 1602 01-01-1980 00:00 word/_rels/document.xml.rels
17# 3711 01-01-1980 00:00 word/document.xml
18# 1525 01-01-1980 00:00 word/footer1.xml
19# 1568 01-01-1980 00:00 word/endnotes.xml
20# 1574 01-01-1980 00:00 word/footnotes.xml
21# 10240 01-01-1980 00:00 word/vbaProject.bin
22# 6804 01-01-1980 00:00 word/theme/theme1.xml
23# 277 01-01-1980 00:00 word/_rels/vbaProject.bin.rels
24# 2651 01-01-1980 00:00 word/settings.xml
25# 1358 01-01-1980 00:00 word/vbaData.xml
26# 17578 01-01-1980 00:00 word/styles.xml
27# 3256 01-01-1980 00:00 word/numbering.xml
28# 1486 01-01-1980 00:00 word/fontTable.xml
29# 740 01-01-1980 00:00 docProps/core.xml
30# 428 01-01-1980 00:00 word/webSettings.xml
31# 18331 01-01-1980 00:00 word/stylesWithEffects.xml
32# 987 01-01-1980 00:00 docProps/app.xml
33#--------- -------
34# 76794 19 files
Right away one thing pops out, the file word/vbaProject.bin. This means that this Microsoft Word document contains Visual Basic for Applications (VBA) macros.
1#!/bin/bash
2# Extract the file from the Word document
3unzip CV_8888.doc word/vbaProject.bin
4#Archive: CV_8888.doc
5# inflating: word/vbaProject.bin
6
7# Extract the strings from the file and do a quick analysis
8strings -a word/vbaProject.bin
9#ShellExecuteA
10#(...)
11#http://xxx.xxx.xxx.xxx:888/troll.e
12#(...)
13#shell32.dll+
14#(...)
15#Document_Open
Those strings are a very good indicator that the file is malicious and that upon opening (reference to Document_Open), it will try to download an executable (reference to a URL, http://xxx.xxx.xxx.xxx:888/troll.e) and execute it (reference to the Windows API SheellExecuteA and the DLL that exports it, shell32.dll).
1#!/bin/bash
2# Download the malware
3wget http://xxx.xxx.xxx.xxx:888/troll.exe
4#--2015-05-02 16:40:45-- http://xxx.xxx.xxx.xxx:888/troll.exe
5#Connecting to xxx.xxx.xxx.xxx:888... connected.
6#HTTP request sent, awaiting response... 200 OK
7#Length: 200704 (196K) [application/x-msdownload]
8#Saving to: 'troll.exe'
9#
10#troll.exe 100%[============================================
11# ====================================================>] 196.00K 342KB/s in 0.6s
12#
13#2015-05-02 16:40:45 (342 KB/s) - 'troll.exe' saved [200704/200704]
After submitting the file to Mawlr, I was surprised that the executable came so clean from the analysis and only three anti-virus have detect it as malicious (at the time of writing). The next step was to run the malware on a disposable virtual machine and observe it’s behaviour.
1#!/bin/bash
2# Create the analysis directories
3mkdir -p /tmp/malware/memory
4
5# Start a packet capture
6tcpdump -i br0 -s 1514 -w /tmp/malware/network.pcap
One thing that wasn't reported by the Malwr sandbox (among others), was that the malware created and executed a file in the %temp% folder to delete the dropped malware. The file deleted the malware, but failed to delete itself (as seen in the image). The failure from the Malwr sandbox to detect this behaviour, leads me to believe that the malware employs anti-virtualization techniques. Interestingly enough, it didn't seem to have detected my environment as such, maybe it is using specific checks for the Malwr sandbox.
After the execution had finished, I dumped the virtual machine memory (Virtual Box) into a directory mounted in RAM to make the Volatility analysis run a little faster.
1#!/bin/bash
2# Dump the Virtual Machine memory
3VBoxManage debugvm sandbox dumpguestcore --filename /tmp/malware/sandbox.dmp
4
5# Mount a directory in memory with enough space to contain the memory dump
6mount -t tmpfs -o size=2560m tmpfs /tmp/malware/memory/
7
8# Convert the memory dump to a raw format
9volatility imagecopy --filename /tmp/malware/sandbox.dmp -O /tmp/malware/memory/sandbox-raw.dmp
10# Writing data (5.00 MB chunks): |.............................................................
11# .............................................................................................
12#..............................................................................................
13#..............................................................................................
14#....................................................................................|
The next step was to check for the processes running in the virtual machine using the Volatility process cross-view plug-in.
1#!/bin/bash
2# Get a cross-view of the processes running using the various methods
3volatility --filename /tmp/malware/memory/sandbox-raw.dmp --profile Win7SP1x64 psxview
4#Volatility Foundation Volatility Framework 2.4
5#Offset(P) Name PID pslist psscan thrdproc pspcid csrss session deskthrd ExitTime
6#------------------ -------------------- ------ ------ ------ -------- ------ ----- ------- -------- --------
7#(...)
8#0x000000007e3d6740 WINWORD.EXE 2104 True True False True True True True
9#(...)
10#0x000000007de9bb30 svchost.exe 708 True True False True True True True
11#(...)
Once again I was surprised, there was no trace of the malware process. From what I have observed in ProcessHacker, there should have been two entries (or a minimum of one) in the processes list (both named lf.exe), one for the original dropped and packed malware, and another one for the malware already unpacked.
1#!/bin/bash
2# Extract the strings from the dropped malware
3strings -a -td /tmp/malware/troll.exe > /tmp/malware/troll-strings.txt
4strings -a -td -el /tmp/malware/troll.exe >> /tmp/malware/troll-strings.txt
5
6# Only noticed two interesting strings
7cat /tmp/malware/troll-strings.txt
8#(...)
9# 133776 C:\Dachshunds4\Urged7\Vasoganglion0\VB6.OLB
10#(...)
11# 135280 C:\Dachshunds4\Urged7\Vasoganglion0\MSCOMCTL.oca
12#(...)
With those two strings, I used the strings plug-in in Volatility in order to try and find the process(es) in memory.
1#!/bin/bash
2# Extract the strings from the sandbox memory dump
3strings -a -td /tmp/malware/memory/sandbox-raw.dmp > /tmp/malware/sandbox-strings.txt
4strings -a -td -el /tmp/malware/memory/sandbox-raw.dmp >> /tmp/malware/sandbox-strings.txt
5
6# Will only search for those two strings
7grep "Dachshunds4" /tmp/malware/sandbox-strings.txt | sed 's/\([0-9]\+\)\s\(.*\)/\1:\2/g' > /tmp/malware/strings-search.txt
8
9# Search for the strings in the memory dump
10volatility --filename /tmp/malware/memory/sandbox-raw.dmp --profile Win7SP1x64 strings -s /tmp/malware/strings-search.txt
11#Volatility Foundation Volatility Framework 2.4
12#1499365488 [FREE MEMORY] C:\Dachshunds4\Urged7\Vasoganglion0\MSCOMCTL.oca
13#1503558288 [FREE MEMORY] C:\Dachshunds4\Urged7\Vasoganglion0\VB6.OLB
14#1514606896 [2104:08812130] C:\Dachshunds4\Urged7\Vasoganglion0\MSCOMCTL.oca
15#1515916112 [2104:08811b50] C:\Dachshunds4\Urged7\Vasoganglion0\VB6.OLB
16#1524592928 [2104:087e1120] C:\Dachshunds4\Urged7\Vasoganglion0\MSCOMCTL.oca
17#1526186640 [2104:07b68290] C:\Dachshunds4\Urged7\Vasoganglion0\VB6.OLB
18#1526188144 [2104:07b68870] C:\Dachshunds4\Urged7\Vasoganglion0\MSCOMCTL.oca
19#1527212864 [2104:087e0b40] C:\Dachshunds4\Urged7\Vasoganglion0\VB6.OLB
20#2123231803 [kernel:fa8002edf23b] C:\Dachshunds4\Urged7\Vasoganglion0\VB6.OLB
21#2123244143 [kernel:fa8002ee226f] C:\Dachshunds4\Urged7\Vasoganglion0\MSCOMCTL.oca
There are reference to both strings in Microsoft Word and in the Kernel. This means the malware didn’t just disappear, but instead of continuing the hunt for it with Volatility, it became easier to dump the process of the unpacked version using ProcessHacker.
1#!/bin/bash
2# Getting the strings from the unpacked malware
3strings -a -td /tmp/malware/lf.exe.dmp > /tmp/malware/lf-strings.txt
4strings -a -td -el /tmp/malware/lf.exe.dmp >> /tmp/malware/lf-strings.txt
5
6# Noticed a bunch of interesting strings
7cat /tmp/malware/lf-strings.txt
8#(...)
9# 647259 GET %s HTTP/1.1
10# 647276 Host: %s
11# 647286 User-Agent: %s
12# 647302 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
13# 647375 Accept-Language: en-us,en;q=0.5
14# 647408 Keep-Alive: 300
15# 647425 Connection: keep-alive
16#(...)
17# 652799 IMAP Password
18# 652871 POP3 Password
19# 652943 HTTP Password
20# 653015 SMTP Password
21# 653103 wine_get_unix_file_name
22# 654359 IsWow64Process
23# 654595 cmd.exe /c ping 127.0.0.1 -n 4&del "%s"
24#(...)
25# 656611 RegQueryValueExA
26# 656631 RegOpenKeyA
27# 656643 RegCloseKey
28# 656655 Software\N3NNetwork\
From the strings it was possible to confirm that the malware is indeed using anti-virtualization techniques (reference to the function wine_get_unix_file_name). It is also possible that it has password stealing and key logging capabilities. With all this information, it is easy to create YARA rules.
1rule cv_malware_packed {
2meta:
3 version="1.1"
4 filetype="PE"
5 author="Duarte Silva"
6 license="GPLv3"
7 reference="https://www.serializing.me/2015/05/03/check-my-cv-generating-yara-rules/"
8 date="2015-04-03"
9 description="Detection for the packed version of the malware downloaded using a rigged Word document"
10strings:
11 $a1="C:\\Dachshunds4\\Urged7\\Vasoganglion0\\VB6.OLB"
12 $a2="C:\\Dachshunds4\\Urged7\\Vasoganglion0\\MSCOMCTL.oca"
13condition:
14 (all of ($a*))
15}
16
17rule cv_malware_unpacked {
18meta:
19 version="1.1"
20 filetype="PE"
21 author="Duarte Silva"
22 license="GPLv3"
23 reference="https://www.serializing.me/2015/05/03/check-my-cv-generating-yara-rules/"
24 date="2015-04-03"
25 description="Detection for the unpacked version of the malware downloaded using a rigged Word document"
26strings:
27 $cmd="cmd.exe /c ping 127.0.0.1 -n 4&del \"%s\""
28 $regkey="Software\\N3NNetwork\\"
29 $a1="C:\\Dachshunds4\\Urged7\\Vasoganglion0\\VB6.OLB"
30 $a2="C:\\Dachshunds4\\Urged7\\Vasoganglion0\\MSCOMCTL.oca"
31 $b1="IMAP Password"
32 $b2="POP3 Password"
33 $b3="HTTP Password"
34 $b4="SMTP Password"
35condition:
36 $cmd and $regkey and (all of ($a*)) and (any of ($b*))
37}
The received message with the attachment is available here (password without quotes is “Original message received with the malicious document."), happy YARA’ing!