Executive Summary

During our analysis of a July 2023 campaign targeting groups supporting Ukraine's admission into NATO, we discovered a new vulnerability for bypassing Microsoft's Mark-of-the-Web (MotW) security feature. This activity has been attributed by the community to the pro-Russian APT group known as Storm-0978 (also known as the RomCom Group, in reference to their use of the RomCom backdoor). This group used a highly complex and well-developed exploit chain leveraging a remote code execution (RCE) vulnerability in Microsoft Office designated CVE-2023-36884 to infect its targets with malware.

Our investigation revealed a new exploit method related to CVE-2023-36884 that can bypass MotW. Microsoft awarded our team a bug bounty and assigned CVE-2023-36584 (CVSS score 5) to this new vulnerability discovered during our investigation.

The lure for these attacks is a weaponized Microsoft Word document disguised as talking points for attendees of the July 2023 NATO Summit discussing Ukraine’s entry into NATO. This article examines the file and provides technical insight into the attack’s exploit chain that has not yet been publicly discussed.

Palo Alto Networks customers receive protections from and mitigations for the threats discussed in this article. Cortex XDR and Prisma Cloud detect and prevent this exploit chain in its early and post-exploitation stages. Organizations can also engage the Unit 42 Incident Response team for specific assistance with this and other threats.

Related Unit 42 Topics	CVE-2023-36884, CVE-2023-36584

Table of Contents

Introduction to the Lure
Technical Analysis Leading to CVE-2023-36584
A Closer Look at the Word Document
First Stage of the Exploit Chain
Abusing the Windows Search Handler
Recreating Windows Search Handler File
Windows Security Zones and Other Obstacles
New MotW Bypass - CVE-2023-36584
Technique #1: Server Side ZIP Swap - Metadata TOCTOU
Technique #2: Server Side Delay - Close Operation
Technique #3: Server Side Delay - Read Operation
Microsoft Security Updates Address CVE-2023-36884
Continuing the Exploit Chain
ActiveX Attack Surface
Elevating Security Zones For Command Execution
Bypassing SmartScreen
An Initial Workaround
Conclusion
Indicators of Compromise
Additional Resources

Introduction to the Lure

This exploit chain begins with the following lure:

Filename	Overview_of_UWCs_UkraineInNATO_campaign.docx
SHA256 hash	a61b2eafcf39715031357df6b01e85e0d1ea2e8ee1dfec241b114e18f7a1163f

While monitoring Ukraine's threat landscape, our team observed an interesting Microsoft Word document (.docx file) first submitted to VirusTotal on July 3, 2023, named Overview_of_UWCs_UkraineInNATO_campaign.docx. The filename and content indicate it targeted participants at the July 2023 NATO Summit discussing Ukraine’s entry into NATO.

This activity has been attributed by the community to a pro-Russian APT group known as Storm-0978 (also known as the RomCom Group, in reference to their use of the RomCom backdoor). Below, Figure 1 shows a screenshot of this document.

VirusTotal indicates this document was hosted at the following URL:

hxxps://www.ukrainianworldcongress[.]info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx

The above link indicates this document was most likely distributed through email, with the email text containing a link to the .docx file. The document’s creation date and the registration date of domain ukrainianworldcongress[.]info are both June 26, 2023. This timing suggests an email-based campaign with a link to the .docx file targeted organizations or individuals attending the July 2023 NATO Summit.

When the file was initially submitted to VirusTotal, 27 of the 62 AV engines identified it as malicious. While we found no evidence this lure was sent to any of our customers, we conducted in-depth analysis to ensure coverage of any associated vulnerabilities.

Our investigation revealed a new vulnerability for CVE-2023-36584. The next section of this article provides detailed technical analysis and fully explains each step of the full exploit chain.

Technical Analysis Leading to CVE-2023-36584

Our investigation starts with a closer examination of Overview_of_UWCs_UkraineInNATO_campaign.docx, then we review the remaining steps of this exploit chain in further detail.

A Closer Look at the Word Document

Microsoft Office documents have been a common attack method for criminals to distribute malware. In response to this threat, Microsoft implemented its MotW security feature that restricts various functions in Office documents from untrusted locations.

Windows identifies these files as high-risk. A file tagged with MotW generates a SmartScreen prompt indicating it is potentially dangerous.

In our .docx file, successful exploitation occurs when the Word document is not tagged as MotW, which causes Protected View to be disabled. We investigated this document to explore the full exploit chain that includes CVE-2023-36884.

To understand how CVE-2023-36884 was exploited by this specific lure, we should first understand Microsoft Word’s implementation of the Open XML file format, in this case for MS-DOCX (.docx) files.

An MS-DOCX file is a compressed ZIP archive containing multiple specification files used to display the Word document. One of those is an XML file at word/document.xml. This is the core XML component of an MS-DOCX file, and it contains the document’s text and formatting.

When viewing an MS-DOCX file in Microsoft Word, much of the document's content is imported by word/document.xml.

In our .docx lure, word/document.xml imports content using the Anchor for Imported External Content element known as altChunk, shown below in Figure 2.

This altChunk element can import content that uses another format, such as Rich Text Format (RTF). As shown above in Figure 2, word/document.xml from our .docx file has an altChunk element that indicates a relationship (r) to external content using the identifier AltChunkId5. This identifier is defined in a relationship file at word/_rels/document.xml.rels.

The snippet of document.xml.rels shown above in Figure 3 identifies the imported target as a file at word/afchunk.rtf.

The RTF file afchunk.rtf contains two malicious Object Linking and Embedding (OLE) objects. The first OLE object uses type OLE autolink set with the objautlink RTF control word. After the objautlink control word, an objupdate control word forces the objects to update before they are displayed, as noted below in Figure 4.

As shown above in Figure 4, the object class is defined as Word.Document.8, and its data contains the LinkedObject structure in its header followed by ASCII text representing hexadecimal characters.

We used Didier Steven’s rtfdump.py tool to further inspect afchunk.rtf. Below, Figure 5 shows hexadecimal (hex) output of the objautlink snippet shown previously in Figure 4. This output more clearly shows the LinkedObject structure.

This hex dump reveals \\104.234.239[.]26\share1\MSHTML_C7\file001.url, a malicious URL that uses the Server Messenger Block (SMB) protocol.

Using rtfdump.py to review afchunk.rtf, we found another malicious OLE object using the xmlfile class, and its header contains the EmbeddedObject structure. The embedded object is a compound document that contains a URLMoniker that loads an XML file from the URL hxxp://74.50.94[.]156/MSHTML_C7/start.xml, noted in blue in Figure 6 below.

First Stage of the Exploit Chain

Initial research on this exploit chain resulted in a flow chart created by @zcracga and shared by @r00tbsd on July 12, 2023 (Figure 7). This flow chart is helpful to visualize the different stages as we work our way through the exploit chain.

Our initial area of concern is two URLs from the malicious OLE objects in afchunk.rtf. As noted previously, these OLE objects request content from the following URLs:

• \\104.234.239[.]26\share1\MSHTML_C7\file001.url
• hxxp://74.50.94[.]156/MSHTML_C7/start.xml

When a Windows client connects to an SMB server, that client sends Windows NT LAN Manager (NTLM) credentials for authentication. Because of this, when the victim host accesses the URL at \\104.234.239[.]26\share1\MSHTML_C7\file001.url, it leaks the victim's NTLM credentials along with its hostname and username to the attacker-controlled SMB server. The collected information is later used in the attack chain.

Figure 8 reveals HTML code embedded inside file001.url.

Examining file001.url, the UName variable contains the victim’s username. This is the username collected by the attacker-controlled SMB server from the victim’s leaked NTLM credentials. If variable d shown above in Figure 8 is not empty, the exploit chain concatenates the username with an attacker-passed value that is used to create a path to the CHM file named 2222.chm contained in a file named file001.zip.

At this stage in the exploit chain, 2222.chm doesn’t exist, or it could be part of some other exploit used by the attackers. Further behaviors of file001.url will be explained later, as it closely relates to 2222.chm.

The second malicious OLE object in afchunk.rtf retrieves a file from hxxp://74.50.94[.]156/MSHTML_C7/start.xml. This start.xml file contains an iframe to load another file named RFile.asp, from the same server and directory path. Below, Figure 9 shows the iframe snippet from start.xml referencing RFile.asp.

RFile.asp is responsible for loading another file with an attack-specific path on the server defined as:

• file[:]//104.234.239[.]26/share1/MSHTML_C7/1/<ip>_<id>_file001.htm?d=<ip>_<id>_

This path is assembled from the victim’s public IP address for <ip> and a five-digit identifier for <id>. We refer to this file as file001.htm.

Abusing the Windows Search Handler

The core behavior of file001.htm is the execution of JavaScript as seen below from the code snippet in Figure 11.

JavaScript from file001.htm uses iframes to load several files. It first loads a saved search file with a filename consisting of the victim’s IP address and five-digit identifier that ends with the string file001.search-ms. We will refer to this file as the last part of its filename, file001.search-ms.

This is followed by three HTTP requests using the string .zip_k* in their URLs. This behavior has no apparent value besides performing a timing or no-op operation.

Finally, MSHTML re-loads file001.search-ms and then loads redir_obj.htm.

The order of these requests stands out, because the intended purpose is not immediately apparent. Based on the timestamps from an example of the associated network traffic, we speculated this order of events achieved a bypass through server-side manipulation, where the requests to the .zip_k* files are used as a delay mechanism. Figure 12 shows a packet capture (pcap) of the traffic filtered in Wireshark, highlighting a two-second delay between one of the HTTP GET requests and its HTTP response.

When examining the file redir_obj.htm, we found a code snippet shown below in Figure 13. This code loads a file from a local path that uses the leaked hostname and username captured during the initial SMB connection as CompName and UName variables, respectively. This is used to open an HTML file named 1111.htm contained in file file001.zip.

Recreating Windows Search Handler File

We used Windows File Explorer to create a blank saved search file with the .search-ms file extension to control where the ZIP file containing 2222.chm is extracted and illustrate how this exploit chain works. We initiated a search in File Explorer and saved the results, which created a .search-ms file. This saved search file is a blank template that can reproduce search handler file behaviors used in this exploit chain.

The Windows system file Windows.Storage.Search.dll processes .search-ms files. In order for the ZIP file to be successfully extracted into the directory specified in the redir_obj.htm file, loaded by the JavaScript iframe shown earlier in Figure 11, several changes need to be made.

First, the include element must contain a local path as its network path and use FILE_ATTRIBUTE_NORMAL, implemented as the variable attributes="128" shown below in Figure 14.

Next, the autoListFlags attribute must have its second least significant bit turned on, implemented as shown below in Figure 15. This results in a complete search that also includes the content of any ZIP archives.

Processing the .search-ms file at this point would create a directory on the target machine in the following path:

• C:\Users\[USERNAME]\AppData\Local\Temp\[Temp1_zip_filename]

The contents of the ZIP file are then extracted into this directory.

File .search-ms handles the ZIP file placement and extraction of its contents based on the earlier SMB-leaked host information.

Our results confirmed the two files extracted from the ZIP file: 1111.htm and 2222.chm.

Similar behavior was observed during an exploit for a previous RCE vulnerability in Office, CVE-2021-40444. In that attack, attackers would exploit a Microsoft Compressed Archive (CAB) path traversal extraction bug to achieve a similar objective: extracting an HTML file to a predictable path on the machine.

Before discussing our 1111.htm and 2222.chm files, we first should understand Windows Security Zones.

Windows Security Zones and Other Obstacles

Also known as Internet Explorer Security Zones or URL Security Zones, Windows Security Zones are the mechanism Microsoft uses to determine permissions for files originating from various sources. Typically, files retrieved from the internet are identified as from the “Internet Zone” and tagged with MotW for restricted permissions.

This data is stored in the file’s Alternate Data Stream (ADS) named Zone.Identifier to indicate the file’s security zone. Files from the “Internet Zone” are identified with a ZoneId value of 3 (Security Zone 3).

For the rest of the exploit chain to succeed, the 1111.htm and 2222.chm files must both be identified with a ZoneId value of 1 in their Zone.Identifier ADS (Security Zone 1). However, this presents an obstacle, because ZIP content downloaded from a remote path and extracted by .search-ms has a ZoneId value of 3, and this content is automatically tagged with MotW.

Two other obstacles must also be addressed for successful exploitation:

• Obstacle 1: When our Windows Search using .search-ms completes, it deletes the [Temp1_zip_filename] directory. This generates a race condition to load files inside the temporary directory.
• Obstacle 2: By default, Windows will not search the contents of CHM files. Our 2222.chm file is required as part of this exploit chain, but it will not be extracted from the ZIP archive using default settings for Windows Search.

New MotW Bypass - CVE-2023-36584

During our analysis of this exploit chain using CVE-2023-36884, our team discovered a different exploit vector, which Microsoft designated as CVE-2023-36584 and awarded us a bug bounty for.

Windows Search iterates through all files inside a ZIP archive during its search. Windows Search checks the file extension of each file to determine if its contents also need to be searched. If so, Windows Search writes the file to a temporary directory and adds MotW to it.

This implementation generates an inherent race condition. There is a short time window between writing an extracted file to disk and marking it with MotW. If we delay Windows Search during this window, we can solve the race condition and ultimately bypass MotW.

A previous technique exploiting CVE-2022-41049 bypassed MotW by adding a read-only attribute to files inside the ZIP archive. This avoided modifications to the Zone.Identifier ADS and prevented extracted files from receiving MotW. This technique inspired us and led to our discovery to bypass MotW.

Technique #1: Server Side ZIP Swap - Metadata TOCTOU

Server-side manipulation enables us to solve these issues. We found a Time-Of-Check to Time-Of-Use (TOCTOU) vulnerability that is exploitable when the ZIP archive is downloaded from a remote server.

Windows uses the system file zipfldr.dll to extract the content of ZIP archives. This Windows DLL file reads the ZIP file’s header and caches the data in memory while the ZIP archive’s content is extracted and saved to disk. Zipfldr.dll exposes an API, which can be used to extract a file by specifying its index in the ZIP archive.

When using zipfldr.dll to extract contents of a ZIP archive, the extracted file’s header is read from cached memory. This creates a scenario that can prevent extracted files from receiving MotW.

Once the file header is read and before it is decompressed using zipfldr.dll, we can replace the ZIP file on the remote server with a ZIP file that holds files with different names, leading to the MotW not being written.

This technique works because urlmon.dll uses the file path to write the MotW originally read from the ZIP’s header cached in memory. This makes it possible to bypass writing the MotW to the file.

This technique solves the two obstacles mentioned earlier regarding the exploitation of CVE-2023-36884. The .chm file that otherwise would fail to extract is successfully extracted, and the files are not immediately deleted.

Below, Figure 16 shows a Process Monitor (procmon) view illustrating failed attempts to create a substitute file named 2222.txt. This condition allows the previously-saved 2222.chm to avoid MotW.

We cannot confirm this is the exact technique threat actors used in the original exploit chain. However, behavioral logs from VirusTotal’s sandbox analysis of the initial .docx lure show the creation of a file named 1111.txt indicating a possible substitute filename mirroring 1111.htm, and this hints at the same method we discuss here for Technique #1.

Technique #2: Server Side Delay - Close Operation

Discovering the first technique opened the door to further research, and we discovered two additional techniques that can significantly delay the writing of the MotW. This scenario prevents the MotW attribute from being written and allows the files to be executed from another thread in Security Zone 1.

After extracting files from the ZIP archive and before the MotW is added to the Zone.Identifier ADS, we can introduce a timing delay from the attacker-controlled SMB server. This is possible due to the SMB2 protocol’s close operation, which consists of a close request and a close response that ends an SMB-based file transfer.

When a client receives all data from the transferred file, it sends an SMB close request back to the server and waits for an SMB close response. The file has been transferred, but the transfer operation is not yet complete until the client receives a close response. This is a synchronic operation, which can be delayed for a significant period of time.

Below, the procmon list in Figure 17 shows a 30 second delay after an SMB server at 111.222.111[.]20 transferred a file named served.zip before the next operation. This indicates a 30-second delay between close request and close response.

During this 30-second window, the 1111.htm file is a Security Zone 1 file without MotW. After a close response is finally sent 30 seconds later, the process continues, and it writes the MotW to 1111.htm.

Technique #3: Server Side Delay - Read Operation

When transferring a large file from a ZIP archive, Windows reads portions of the file from the remote share, appends the data to a local file on disk, then reads additional portions from the remote share until the file is fully written to disk. If we append random data at the end of the file (keeping it usable), we can delay writing of the file from the SMB server before Windows adds MotW to the file. The file is usable during this writing process, since it is opened with a read/write dwShareMode.

We tested this theory by introducing ten second delays in the process as shown below in Figure 18.

Microsoft Security Updates Address CVE-2023-36884

The threat actors that developed this exploit chain knew the path for a temporarily-saved local file used during SMB file transfer was predictable. But after Microsoft’s August 2023 security updates, researchers like Will Dorman reported a Universally Unique Identifier (UUID) has been added to the temporarily-saved local filename that makes the path random. We confirmed this, as shown below in Figure 19.

As shown above in Figure 19 during our test run, the temporarily saved file includes the UUID string 90be3adb-6ec5-4f3f-bdd8-1e22ee6c326c in the directory path for the temporarily saved local file.

During the SMB file transfer process for a ZIP archive, zipfldr.dll creates a temporary folder by calling the CTempFileNameArray::GetTempLocation function, which calls CTempFileNameArray::_TryCreatingInPath.

Using BinDiff to find changes in the patched version of zipfldr.dll, we spotted a notable new code block in the CTempFileNameArray::_TryCreatingInPath function, as shown below in Figure 20.

Microsoft added a call to UuidCreate, and extracting content from a ZIP archive fails if the path is not constructed with the new UUID.

Another interesting update in the patched version of zipfldr.dll is found in the ExtractZipToFile function. New code is added after extracting the file, which will append the MotW immediately after the file is written. If SetFileAttributes fails, the file is deleted, as shown in Figure 21.

Continuing the Exploit Chain

Although Microsoft's August 2023 Security Updates mitigated this exploit chain, other steps of the chain remained unpatched.

ActiveX Attack Surface

Running a file in Security Zone 1 results in a more permissive policy toward ActiveX controls and provides a greater ActiveX attack surface. This allows executing old ActiveX code that could be exploited to execute malicious code.

An increased ActiveX attack surface allows us to trigger the next step in the exploit chain. Below, Figure 22 shows a code snippet from 1111.htm that leads to the next step.

This code from 1111.htm creates a hidden popup and runs the ActiveX WebBrowser control within the hidden popup. The WebBrowser control is a wrapper that allows web browsing functionality in Windows-based applications. Developers often use this ActiveX control to embed an HTML viewer in an application.

Elevating Security Zones For Command Execution

While Security Zone 1 allows us to avoid MotW and increase the ActiveX attack surface, we can elevate our files to Security Zone 0 for command execution. Files tagged as Security Zone 0 represent the "Local Machine" zone, which is the most trusted zone and provides maximum allowable permissions.

At this stage, the WebBrowser control redirects the page from a network path in Zone 1 to a local path of the same page. Now that file 1111.htm is loaded from a local path, it executes in Security Zone 0.

Next, 1111.htm loads 2222.chm by invoking ms-its shown below in Figure 23.

Windows uses this ms-its handler to display Microsoft Compiled HTML Help (CHM) files. This function is implemented in module itss.dll, which loads the extracted 2222.chm file.

Figure 24 below reveals the contents of 2222.chm when viewing the file in HTML Help Workshop.

The CHM file contains a file named file1.htm, which redirects to file1.mht (handled by inetcomm.dll, part of Microsoft's internet messaging API). Then file1.mht uses the showHelp method to load fileH.htm. Then FileH.htm redirects to fileH.mht, and finally fileH.mht executes the script shown below in Figure 25.

The code snippet from fileH.mht in Figure 25 uses the window.open method to invoke the ShellExecuteExW API to open a file at:

• file[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.url

Bypassing SmartScreen

The Internet Shortcut (URL) file named ex001.url from Figure 25 points to file[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.zip/file001.vbs.

The downloaded file001.vbs file contains malicious Visual Basic Script (VBS) designed to bypass SmartScreen protection.

When a URL file points to a remote UNC path, the URL file downloads and runs content returned from that path. Executing the content calls the ShellExecuteW API which triggers the CheckSmartScreen function, prompting the user for confirmation, as shown below in Figure 26.

However, our file resides within a ZIP archive, so it triggers a slightly different behavioral flow. File file001.vbs is downloaded during the exploit chain and extracted to the user’s local temp directory with MotW, but it is immediately executed without any popup warnings. This is illustrated below from the procmon list below in Figure 27.

As shown above in Figure 27, file ex001.zip is retrieved from a remote directory, then file001.vbs is extracted from the ZIP archive. Later in the process event list, we find a Process Create entry for wscript.exe to run the VBS file, as highlighted in blue.

This bypass was also described on Twitter by Will Dormann. This may be a regression, because Microsoft fixed a very similar issue in 2016.

An Initial Workaround

Before patching the CVE-2023-36884 vulnerability, Microsoft announced the following mitigation.

• Disable cross protocol navigation: Microsoft stated “organizations who cannot take advantage of these protections can set the FEATURE_BLOCK_CROSS_PROTOCOL_FILE_NAVIGATION registry key to avoid exploitation.”

Disabling cross protocol navigation prevents navigation between URI schemes. This mitigation stops the redirection from RFile.asp, discussed earlier with Figure 9 and Figure 10.

Conclusion

Starting with the malicious .docx file, our analysis of the July 2023 campaign targeting groups supporting Ukraine's admission into NATO revealed a more complex exploit than originally reported. Our analysis of this chain revealed a chain of more than 20 steps that not only exploited CVE-2023-36884, but included additional vulnerabilities to bypass protections in Microsoft Office and Windows.

Microsoft awarded our team a bug bounty and assigned CVE-2023-36584 to a new vulnerability discovered in our research.

Palo Alto Networks customers receive protection from and mitigation for these exploits the following ways:

• Cortex XDR customers received protection from these exploit methods before they were discovered.
• Prisma Cloud is capable of detecting and preventing cloud application deployment that contains exploits against either CVE-2023-36884 or CVE-2023-36584. Protection from these exploits was available out of the box.

If you think you may have been compromised or have an urgent matter, contact the Unit 42 Incident Response team or call:

• North America Toll-Free: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• Japan: +81.50.1790.0200

For additional information about how Palo Alto Networks customers receive protection from this exploit chain, see our previous article about CVE-2023-36884.

Palo Alto Networks has shared our findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Indicators of Compromise

The following files are associated with the July 2023 campaign lure Overview_of_UWCs_UkraineInNATO_campaign.docx and have been posted to VirusTotal. Of note, SHA256 hashes for some of these files are different for each infection.

Read: SHA256 hash - Filename

• a61b2eafcf39715031357df6b01e85e0d1ea2e8ee1dfec241b114e18f7a1163f - Overview_of_UWCs_UkraineInNATO_campaign.docx
• 0896e7c5433b2d426a30a43e7f4ef351fa870be8bd336952a0655392f8f8052d - word/document.xml
• b5731baa7920b4649add429fc4a025142ce6a1e1adacb45850470ca4562d5e37 - word/_rels/document.xml.rels
• e7cfeb023c3160a7366f209a16a6f6ea5a0bc9a3ddc16c6cba758114dfe6b539 - afchunk.rtf
• 3d0dae359325e8e96cf46459c38d086279865457379bd6380523727db350de43 - file001.url
• 48142dc7fe28a5d8a849fff11cb8206912e8382314a2f05e72abad0978b27e90 - start.xml
• bfe3ebcc92a4a7d294b63ce0d7eba6313980d982709a27b337abe32651b63856 - file001.zip
• c94e2bfd4e2241fed42113049c84ac333fcff340cc202afe8926f8e885d5fca3 - 2222.chm
• f08cc922c5dab73f6a2534f8ceec8525604814ae7541688b7f65ac9924ace855 - 1111.htm
• cdc39ce48f8f587c536450a3bd0feb58bf40b59b310569797c1c9ae8d28b2914 - RFile.asp
• fd4fd44ff26e84ce6587413271cf7ff3960471a55eb0d51b0a9870b577d66f4a - file001.htm
• 4fc768476ee92230db5dbc4d8cbca49a71f8433542e62e093c3ad160f699c98d - redir_obj.htm
• 0adb2734a1ca0ccaf27d8a46c08b2fd1e19cb1fbd3fea6d8307851c691011f0f - file1.htm
• 7a1494839927c20a4b27be19041f2a2c2845600691aa9a2032518b81463f83be - file1.mht
• 20f58bd5381509072e46ad79e859fb198335dcd49c2cb738bd76f1d37d24c0a7 - fileH.htm
• ee46f8c9769858aad6fa02466c867d7341ebe8a59c21e06e9e034048013bf65a - fileH.mht
• c187aa84f92e4cb5b2d9714b35f5b892fa14fec52f2963f72b83c0b2d259449d - ex001.url

The following network paths referenced in this research are associated with the July 2023 lure:

• \\104.234.239[.]26\share1\MSHTML_C7\file001.url
• \\104.234.239[.]26\share1\MSHTML_C7\ex001.url
• file[:]//104.234.239[.]26/share1/MSHTML_C7/1/
• file[:]//104.234.239[.]26/share1/MSHTML_C7/ex001.zip/file001.vbs
• hxxp://74.50.94[.]156/MSHTML_C7/start.xml
• hxxp://74.50.94[.]156/MSHTML_C7/zip_k.asp?d=
• hxxp://74.50.94[.]156/MSHTML_C7/zip_k2.asp?d=
• hxxp://74.50.94[.]156/MSHTML_C7/zip_k3.asp?d=
• hxxps://www.ukrainianworldcongress[.]info/sites/default/files/document/forms/2023/Overview_of_UWCs_UkraineInNATO_campaign.docx

Additional Resources

• CVE-2023-36884 - Microsoft Office and Windows HTML Remote Code Execution: Threat Brief – Unit 42, Palo Alto Networks
• Storm-0978 attacks reveal financial and espionage motives – Microsoft Security
• The Tale of Two Exploits – Breaking Down CVE-2023-36884 and the Infection Chain - Trellix
• Windows Search Remote Code Execution Vulnerability – vu.ls blog
• Post by @r00tbsd on X from thread about CVE-2023-36884 exploit - Post by @r00tbsd on X from thread about CVE-2023-36884 exploit