Storm-0978 Campaign Analysis

Recently Microsoft released some security updates for a newly detected Zero-Day vulnerability, CVE-2023–36884. Along with this vulnerability came an update statement associating it with a phishing campaign that has been observed targeting defense and government entities. Microsoft has identified the group responsible for these attack campaigns as Storm-0978. In this post we are going to look at one of these campaigns that was intended on luring Ukrainian officials via a Microsoft Word Phishing document. We will look at what composes the initially received archive, examine the network traffic that occurs after detonation, and discuss how easily this attack can evade detection.

Diving into the Word document

2400b169ee2c38ac146c67408debc9b4fa4fca5f

The sha1 hash listed above is the sample we are examining. It was initially reported to have reached the target via email. The document was originally detected with the title, ‘Overview_of_UWCs_UkraineInNATO_campaign.docx.doc’. If we examine the document contents, we learn that it is in fact an OOXML, (Open Office XML), file format… not just a Microsoft Word .doc.

The OOXML is a zipped XML archive that follows a certain structure.

When we unzip it, we can begin poking around for interesting artifacts.

Fig. 1 — OOXML archive contents

MS documents can have malicious attacks embedded in numerous ways like inside documents and themes, but in this instance, it appears that the source of the communication comes from a file named atfchunk.rtf.

This rtf file contains 3 embedded objects, 2 of which are responsible for outbound communication.

Fig. 2 — atfchunk OLE obj 1

The first embedded OLE object that we see above is objauthlink\objupdate with the objclass of type ‘ Word Document 8 ‘. Inside this, is the data that attempts to open an outbound SMB connection to a share titled ‘share1\MSHTML_C7’ requesting the file001.url.

This file001.url is another document that contains an html file with an embedded iframe that will render upon the document’s execution.

Fig. 3 — file001.url

The next embedded OLE object we can see includes the Windows MS-CFB (Compound Binary File Format) header — 0xE11AB1A1E011CFD0 -, with an objclass of xmlfile.

Much further below the header is the HTTP path to the external server hosting the path to MSHTML_C7/start.xml

Fig. 4 — atfchunk OLE obj 2

Network Traffic

Now that we have an idea of what the OOXML archive looks like, let’s inspect the HTTP traffic.

As we’ve seen in the embedded object, the first outbound request is made via an HTTP GET to the attacker’s remote server including the IP address and the URI path with the location — /MSHTML_C7/start.xml

The attacker’s server responds with the embedded HTML file containing the iframe to a file titled RFile.asp

Fig. 5 — MSHTML start.xml request

Following this response is an outbound HTTP GET to /MSHTML_C7/RFile.asp

The attacker responds with html that waits 30 seconds before reaching out to the attacker’s server.

Fig. 6 — RFile.asp request

Finally, serveral nearly identical HTTP GET requests are made to the attacker /MSHTML_C7/zip_k(x).asp?d=(ip)_(id)_ with x being incremental and the ip and id being generated from the target system.

Fig. 7 — additional asp requests

These files will continually download html files from the attacker and eventually grab an .htm file that will download a malicious payload.

ATI Campaign

The campaign we generate at Keysight replicates this entire attack traffic so that you can simulate this real-world threat against your network devices. However, it does more than just that.

During my analysis I was playing with the original threat and discovered that the Windows Security Threat Defender was catching the malicious document, which is great news. In fact, it detected many pieces, the OOXML archive, and the atfchunk, which is great.

For our threat campaign we start by sending the initial OOXML archive over the wire via many network transmission protocols that are available to the user to select like imap, smtp, smb, http etc.

After this, we make a decision. We either send the original binary with all of the originally observed traffic, or open the archive during runtime and modify the binaries to change the ip addresses to match the continuing execution steps as described above. We make sure to randomly generate and change any data that could be easily altered by the attacker in the future, both in the original binary/archive’s ‘atfchunk’, and then in the network traffic. After doing this, I was surprised to see that the document was no longer flagged. So, deeper inspection would be needed for this modified threat.