Author: @d4rksystem

It has been a while since I’ve touched a malicious RTF document and I’ve been itching to refresh my knowledge in this area. The tricky part was finding a maldoc worth investigation. Well, my luck recently changed – along came a maldoc lure that targeted guests of the 2023 NATO Summit in Lithuania in July. I found a maldoc worthy of my time.

BlackBerry wrote a great post of the analysis of the entire attack chain, but glossed over the analysis of the first-stage lure, which is what prompted me to analyze this further. Note that I’ll only be covering the 1st-stage lure in this post. The filename of the file I am investigating in this post is “Overview_of_UWCs_UkraineInNATO_campaign.docx”. The document is available on VirusTotal:

SHA256: a61b2eafcf39715031357df6b01e85e0d1ea2e8ee1dfec241b114e18f7a1163f

Analysis of the Lure

Upon initial inspection, this MS Word document does indeed appear to be quite targeted:

To begin my analysis, I first executed the document in a Windows 10 VM while capturing network traffic in Fiddler. The screenshot below shows connections to two IP addresses:

The first connection seems to be an HTTP OPTIONS request to 104.234.239.26.

Edit 1: I was informed from a reader (@k0ck4) that the malware is also making SMB connections to the remote server. This is true – the malware attempts to connect to the remote server via SMB, and following this makes an HTTP OPTIONS request. I was not able to get the malware to connect to the server (likely, the server is offline) but according to the strings in the RTF document objects, it attempts to download a file (more on this later!). The following screenshot from Wireshark shows the SMB connections:

The second connection is for another IP, 74.50.94.156. The second IP appears to be downloading a file (start.xml). For fun, I queried these IP’s in Shodan to see if there is anything interesting. Fun fact: The 74.50.94.156 IP is using WinRM and other services and has some interesting data exposed. (I blurred the data out, but you can check it out on Shodan if interested):

Lets dig deeper into this Document file. I switched over to Remnux VM, and used the tool zipdump to get an idea of what this file’s contents are.

There is definitely something in this document. An embedded RTF file (index 13) which seems to be titled “afchunk.rtf”! Let’s extract it:

(Since this command is a bit hard to read, here it is in text):

zipdump.py -d -s 13 <target_file_name> >> afchunk.rtf

Analysis of “Afchunk.rtf”

Let’s switch over to the rtfdump tool to see what is inside this RTF file:

It looks like we have three potential embedded objects. The first object (index 147) has a size of 0 bytes… interesting. The second object (index 152) appears to be an “OLE2LINK” object. And the third object (index 161) has the designation “SAXXMLReader”.

While rtfdump, rtfobj, and similar tools are extremely valuable, they are reliant on malware authors behaving properly. Some RTF malware may be able to hide objects from these tools or otherwise obfuscate the data inside. For this reason, I almost always look into the raw data of the file to make sure my findings align. To start, I ran the strings tool on the afchunk.rtf file (command: strings afchunk.rtf). A few things pop out:

There are what appears to be two objects embedded in this RTF file, denoted by the highlighted “objdata” tags. The first objdata tag is succeeded by a blob of hex data. If we copy this hex and transform it to ASCII, we would see some interesting things – but we’ll extract the object in a moment. This objdata tag is preceded by the string “Word.Document.8” which informs us that this may be an embedded Word document.. However, the standard DOC magic bytes (“D0CF11E”) are missing from the hex data. This object seems to be potentially malformed – this could be purposefully done, so as to mislead analysts and automated tools.

The second objdata tag contains another hex blob, but this time we see the “D0CF11E” magic bytes, which denotes an embedded document file or OLE (Object Linking & Embedding) object.

OLE is a way for different programs to exchange data between them. Imagine you have a document in MS Word, and you want to include a chart or a spreadsheet from MS Excel. OLE enables this. The chart or spreadsheet becomes an OLE object. You can learn more about OLE here. In the case of maldocs, malware authors often link or embed malicious objects into otherwise benign RTF documents as a way to hide them and stealthily execute evil activity.

Let’s dump the objects we discovered to disk. The rtfobj tool can help with this:

This command displays the objects inside this RTF file, and dumps them to separate files so we can analyze them. As we suspected, the first object (ID 0 in this output) states that the object is “Not a well-formed OLE object”. The second object (ID 1) has a class name of “OLE2LINK”, a type of OLE object. As a fun homework assignment, Google “OLE2LINK” – the first thing you’ll see is a list of vulnerabilities affecting this object type.

So, let’s take a look at the embedded objects we just extracted.

Analysis of Embedded Object 1

Viewed in a hex editor, Object 1 contains some interesting strings, notably: The IP “104.234.239.26” and the URI path “\share1\MSHTML_C7\file001.url”. When the afchunk.rtf file executes, this embedded object also executes, forcing MS Word to send an HTTP request to this remote server. We’ll discuss this more in a moment.

Edit 2: As a described in Edit 1, this document makes an SMB connection as well as the HTTP request. You can tell this is SMB by the reversed Windows SMB slashes (“\\” and “\”).

Analysis of Embedded Object 2

Similarly to Object 1, Object 2 can be viewed in a hex editor:

Viewing the second object in hex editor reveals another interesting string: “74.50.94.156”, as well as a URI path “/MSHTML_C7/start.xml”. This is the other IP we saw in our Fiddler traffic. As with the first embedded object, this second embedded OLE object also executes upon afchunk.rtf executing, and similarly tricks MS Word into contacting a remote web server. How does this work? I am glad you asked.

These embedded objects seem to be taking advantage of a known older vulnerability called (CVE-2017-0199). According to Microsoft, this vulnerability “exists in the way that Microsoft Office and WordPad parse specially crafted files. An attacker who successfully exploited this vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.” Sounds quite dangerous… and very generic.

Digging deeper, I found publicly available exploit code for this vulnerability. If you compare the exploit’s payload code to the strings in the RTF document, you can see some similarities. The malware authors perhaps even re-used some of this exploit code for their own maldoc. For example, the following strings from the original RTF exploit code were existent in this document:

The Next Stages

During the time of my analysis, I could not contact the IP’s directly, so I could not obtain the files as they were supposed to be downloaded (via exploitation of the RTF document and MS Word). However, I was able to obtain them from VirusTotal.

The file hosted on 104.234.239.26 is another MS Word file that renders an iframe in preparation for the next stage of the attack. The file hosted on 74.50.94.156 is an XML file containing a weaponized iframe that is then loaded into MS Word. This malicious iframe is part of the CVE-2022-30190 vulnerability, and sets the stage for the later stages of this attack. 

Since the goal of this blog post was simply to show one methodology for analyzing an RTF file, I won’t go into detail on the later stages of this attack. You can read it on the BlackBerry blog post.

For further reading, I found a good older article from the researchers at Nviso. Additionally, McAfee researchers posted a great article on malicious RTF documents and how they work.

I hope you enjoyed! If you see any inconsistencies or errors in this post, please let me know! Also, if you have additional techniques, I am always happy to learn new ways of malware analysis! 🙂

— @d4rksystem