This is the second article about the analysis of malicious documents observed in March 2018.
You can read the first part here: A close look at malicious documents (Part I )
- rtfobj tool – part of python-oletools package – “rtfobj is a Python module to detect and extract embedded objects stored in RTF files, such as OLE objects. It can also detect OLE Package objects, and extract the embedded files.” https://github.com/decalage2/oletools/wiki/rtfobj
- 7zip – archiver
- Hexinator – a powerful hex editor
- Notepad++ – a powerful text editor
Sample 3 – march 2018 order.docx
Analysis date: March 7
This is a docx file – in OOXML format – so we can unzip it with 7zip. We can see the following directory structure:
By examining the footer2.xml, we can observe that an external Relationship of type oleObject is embedded in this document.
The link to external resource is hxxp://bit.ly/2FAcCe3, which is redirected to hxxp://babymama.co.ke/0802/3/word.doc
We can append plus sign (+) to the end of shortened bit.ly URLs to see the visiting statistics.
word.doc is an rtf document. In A close look at malicious documents (Part I ) post, I manually extracted the ole objects embedded in the rtf file (sample 2). However, this time, I use rtfobj tool to extract the ole objects and dump them on the file system.
rtfobj.exe [/path/to/rtffile] -s all -d [/path/to/dump/dir]
By opening these files with the Hexinator, we can observe that “2FAcCe3_object_000000EF.package” contains a PE file. The 4 byte before “MZ” determine the length of tthe embedded object (which a PE file)
I uploaded the extracted PE file on VirusTotal on March 31st.
[Update] After publishing this post, James (@James_inthe_box) mentioned that this is #formbook malware
docx (external Relationship) -> rtf (OLE package) -> PE file
Sample 4 – document2018-03-20-104831.doc
Analysis date: 21 March 2018
First, we use rtfobj to examine this rtf document.
The rtf file contains one OLE object with an unknown class name (package), b’CNBo8Z3Oqbh02JzEwftSelDsq’, so the class name is ignored.
When we open the OLE object in the Hexinator, we see:
Fig 8 depicts the content of the extracted OLE object. We can see a link to a remote wsdl file (hxxp://my.mixtape.moe/tzsfgh). When we open the file, it contains many whitespaces (e.g. the first few hundred lines are empty). We can use replace capability in Notepad++ to remove extra whitespaces:
After removing the extra characters, we can see the following:
The embedded code is in C#. To see what is going on in the code, we can debug the code with Visual C# debugger. I created a Console app and copy/pasted the whole C# code into its main function and then formatted the code. You can see this code in https://pastebin.com/dSdwau7p.
UxSul is an array with the length of 6522 chars (each char is 2 bytes). UxSul is converted to a String obj on line 6568. Let’s run the code and see the generated string.
Fig 12. shows the content of BCvBK variable, which is another c# application. The generated c# code is then compiled and then invoked by code on lines 6569-6581. You can get the embedded C# code from https://pastebin.com/3i8TZryf.
The embedded C# code contains machine code, which will be injected into the process itself and will be executed, shown in Fig 13.