Analysis of a malicious email

Over the past few months we have seen that the waves of malspam are becoming increasingly sophisticated. A new modus operandi, more elaborate than previously, has been identified this summer and deserves being looked at more closely.

Everything has been studied in the closest detail to trap the user and defeat his diligence, on the one hand by making him believe in the email’s legitimacy and on the other hand by leading him to open the attachments. This is a targeted attack that resembles a phishing email, and is sufficiently personalized to pass for a legitimate email while in fact it contains malware. Unlike ordinary malspam, this attack is not sent massively, nor over a long period, but we find that this method reappears regularly, with or without variants.

This modus operandi is more difficult to detect because it avoids attracting attention and gets through the meshes of most messaging protection systems. Let’s take a look in detail at the elaborate way of operating and the different elements implemented to successively reassure the user, persuade him to open the attachment, trigger execution of the malware and hide it from the eyes of email analysis tools.

Email Analysis

The first part of the email aims to win our trust by trying to make us believe that contact has already been established. So the subject line of the email includes a “Fw” which aims to reassure the reader and make him believe it continues from a discussion started previously.

The second part persuades him to open the attached documents and asks for some information to make the scenario credible.

The last part gives information on the sender of the email. We have a surname, a first name, his position, an address, a telephone and fax number to make us even more confident.

Attachments

Analysis of attachments

It is rather rare to have 2 attachments in a malspam. As a general rule, malspams are less complex, and contain little text and only one attachment.

Let’s study these two files to understand how the attack proceeds.

Analysis of the ‘order.pdf’ file

The PDF file, once opened, is empty. A message from Adobe Acrobat Reader tells us that execution of JavaScript is deactivated and that activating it could cause problems. By default, execution of JavaScript code is deactivated when installing Adobe Acrobat Reader – the user can still change this behavior in the application’s settings. In this case the JavaScript code is executed directly, without any warning message being displayed.

What happens if we enable execution of the JavaScript code? Let’s first analyze the file.

The PDF format is somewhat of a tag format, so it is possible to open PDF files with a text editor.

Inside of it there are several parts that are interesting:

Line 9 tells us that the file contains another file named ‘jon001.docx’ and its data are in the ‘7 0’ object.

Line 10 indicates that an action will be performed when the file is opened. The action that will be performed is found in the ‘9 0’ object. Here is what it contains:

The object contains keywords ‘/Action’, ‘/S /JavaScript’ and ‘/JS’ which indicates that the JavaScript code will be executed. Here, the JavaScript code will open the file ‘jon001.docx’ which is contained in the PDF.

It turns out that the ‘jon001.docx’ file is the same as the order.docx file in the email.

Let us check what happens when JavaScript is activated (this action is not recommended).

We now know that if we open the attached PDF or docx file the result will be the same, i.e. opening the docx file. The presence of two attachments leading to the same result multiplies the attack’s chances of success.

Analysis of the order.docx file

Like the PDF file, the docx file is empty and proposes that we activate a change... Let us first analyze it as we did for the PDF file.

The OOXML format was introduced with Microsoft Office 2007 and has become the default format since. OOXML files (docx, xlsx, pptx) are ZIP archives, so a file can be extracted to see its contents.

The image below represents the content of the ‘order.docx’ file after it is extracted.

The ‘document.xml’ file provides important information on the action that the document will make if the modification is activated.

Line 21 (red box) tells us that the document contains an ‘OLE’ object of the ‘Link’ type, with the identifier ‘_id_1659’. To find what the object is, look in the ‘document.xml.rels’ file which is found in the ‘_rels’ folder.

At line 9 we find:

• ID: the identifier we are looking for
• Type: the type of identifier, which confirms that this is an ‘oleObject’ file
• TargetMode: defined as ‘External’, which means that the file will be downloaded
• Target: the address of the file to be downloaded, namely, 'hxxps://pomf[.]pyonpyon[.]moe/befqki[.]doc'

 
To conclude the analysis of the docx file, if we activate the modification a file named ‘befqki.doc’ will be downloaded and opened.

Analysis of the befqki.doc file

Unlike the previous files, this one does not have the correct extension. It is not a DOC but an RTF.

It is very common these days to see attachments with the ‘.doc’ extension while they are actually RTF files. The DOC and RTF format are both file formats developed by Microsoft. Applications such as Microsoft Word or even LibreOffice are not based on the extension but on the file header to read its content, so it is possible to modify its extension without having any effect when reading it.

Why modify its extension? The RTF format is less known and less used than the DOC format, with users being increasingly sensitive to computer threats and tending to be more suspicious of a file with an unknown extension. The modification is simple and quick to make and will reach a large number of users.

The file uses CVE-2017-11882 to download and execute a file when it is opened.

• Microsoft CVE-2017-11882
• Simple Poc for CVE-2017-11882

As static analysis of this CVE is more complex than the previous ones we will not do it here, but here is a summary of how it proceeds:

1. The RTF file contains an embedded doc file.
2. The extracted doc file contains an Ole10Native stream.
3. This stream contains a shellcode that we need to analyze.
4. The shellcode downloads and executes the malware.

Here is an article that explains in detail the extraction and analysis of a shellcode contained in an RTF file: CVE-2017–11882 - RTF.

Analysis of ANY RUN indicates that the ‘befqki.doc’ file downloads a file from the address 'hxxp://irishlebanese[ . ]com/wp-admin/images/eight/jon001[ . ]exe' and then executes it.

The jon001.exe file turns out to be the malware and therefore the final step of the attack, with the previous files only being downloaders and droppers.

• A downloader is a file that downloads and executes malware, such as the 'order.docx' and 'befqki.doc’ files.
• A dropper is a file that directly embeds the malware by concealing it to avoid detection and then execute it; in our example the ‘order.pdf’ file is a dropper since it embeds the ‘order.docx’ file which will be used to download malware.

We will not analyze the malware in detail but here are its main actions:

• Take screenshots
• Steal passwords
• Record keyboard keystrokes
• Send the information collected to a remote server

Conclusion

Here is a summary of how the entire attack proceeds which, as we have seen, is more elaborate than the usual malspam by its sequence and use of two attachments.

1st step: Opening the email that contains two attachments.

2nd step: Opening one or more attachments. The ‘order.pdf’ file contains a ‘jon001.docx’ file which turns out to be the same file as the second attachment (order.docx). The ‘befqki.doc’ file will be downloaded.

3rd step: The ‘befqki.doc’ file uses CVE-2017-11882 to execute the code that will download and execute the ‘jon001.exe’ file.

4th step: The malware executes and performs various actions: stealing passwords saved on the machine, recording keyboard keystrokes and then transmits them to the attacker.

References: