Attackers test CAB-less 40444 exploit in a dry run

Attackers sent out spam emails that look like this one. The only viable samples we received came in messages with an identical message body and From: address.
The message body contains two street addresses in Hungary, but used a From: address with a domain that was slightly different from that of a real business based in Jamaica seemingly unconnected to the attack.
Attached to the message was an archive file named Profile.rar. RAR archives are not unique or unusual as malicious file attachments, but this one had been malformed. Prepended to the RAR file was a script written in Windows Scripting Host notation, with the malicious Word document immediately following the script text.

Most archive utilities perform a sanity check when attempting to uncompress an archive file, usually by checking the file’s “magic bytes” appear at the beginning of the archive. Normally, if these magic bytes are not present in the expected location, the archiving utility throws an error and quits.

Other archiving utilities would be unable to uncompress this type of RAR file, but the WinRAR utility is unusually fault-tolerant, and can uncompress an archive even though its magic bytes (“Rar!” in the image below) don’t appear in the file until a few hundred characters after the beginning of the file.

A user who received this malicious RAR attachment, if they double-click the file, would be prompted (by default) to uncompress the Word document into the same folder where the archive is stored. When the recipient opens the Word document, the exploit triggers.
The malicious document contains a few unusually placed apostrophes in its bargain basement social engineering style.
The message indicating the malcode source URL flashes by quickly on the Word startup screen as the document loads, so don’t blink or you’ll miss it.
In a tool like Process Explorer, shown below, the Word document appears to invoke the RAR archive itself as though it were a Windows Scripting Host (WSH) script, a weird sort of circular reference that (in theory) shouldn’t work, but does.
Windows allows these kinds of scripts to mix together other scripting formats. Process Explorer shows the command line as wscript.exe “.wsf:../../../[path where RAR was saved]/Profile.rar?.wsf”
Because the text of the script appears before the magic bytes of the archive, the Windows Scripting Host process wscript.exe successfully invokes the embedded PowerShell command in the RAR file.

That PowerShell command decodes a long string of base64-encoded text, which is itself a separate scripting command that instructs PowerShell to retrieve a malware executable from a remote website, and run it on the system as dllhostSvc.exe.
In theory, this attack just shouldn’t work. But it does because there had been assumptions about how the exploit works that led to a too-narrowly focused patch.
It also worked because WinRAR is unique in that it treats any file that contains the correct magic bytes as an archive, no matter where the magic bytes appear in the file.
Taken as a whole these led to a set of expectations that weren’t met by the attackers who modified the attack method in this case.

As with previous exploits against the 40444 bug, the attackers used an Office document that contains an OLE Object (a mechanism to embed external files or documents), which in a non-malicious document might be used to view or download a web page with JavaScript.
But buried in the weaponized .docx (which is just a zipped collection of XML files), inside a file named “word/_rels/document.xml.rels,” the attackers embedded a line of code in the MHTML protocol handler that looked like this.

The attackers knew it would be possible some security vendors would detect the plain text of a URL so they encoded it with XML character entity references.
The value of &#x48 above declares a hex value of 48, which in ASCII is the letter H, &#x54 represents an ASCII T, and &#x50 is P… the first letters in the familiar http:// protocol header in a URL.

While there is no VBA or macro in the document that can execute, the attacker prompted the user to “enable content” in the body of the Word document.
Doing so triggers the computer to load a page at hxxp://104.244.78.177/Profile.html (obfuscation intentional).
However, looking more closely at the source code of that page, there’s some unusual, obfuscated Javascript code there.

The JavaScript on the page would be executed within Office.
It is an obfuscated version of the JavaScript already published in a proof-of-concept for this technique to launch that original RAR file as a WSF instead.
Once the file is found, wscript.exe will run the VBScript code, which in turn launches PowerShell.
As mentioned previously, a base64 encoded PowerShell command is used. Decoding that reveals the final stage of exploitation.
This resulted in the computer downloading a malicious file into “AppDataLocal” and launching it.
The Labs team later confirmed that this EXE was a sample of a malware family called Formbook.
This attack was particularly noisy from a network perspective.

The Javascript that runs on the Profile.html page creates a series of network requests that was somewhat bizarre.
The practical effect of the Javascript deobfuscating itself as it runs causes a noticeable delay in the execution of the script, taking from five to eight seconds to complete the infection process and generating distinctive network traffic in the process.
The script running on Profile.html triggers the computer to make multiple requests to the page using different HTTP request “verbs” – not only the typical GET request, but also HEAD, OPTIONS, and PROPFIND.
It’s this last HTTP request type that’s of interest not only because it’s unusual, but because the purpose of that request type is for XML documents to request web-based resources – exactly what the exploit does.

At the end of this process, the script triggers Word to run the Windows Script Host, pointing it at the .rar file.
The script invokes PowerShell, which (eventually) downloads the Formbook payload. Noticeably, while the other HTTP requests in this process all have User-Agent strings, the final request that delivers the malware executable does not. Notably, the User-Agents that do get used during these requests make no sense: Some of the requests pretend to be from an Internet Explorer 7 browser running on a version of Windows 8 that’s five years past its best by date, and others appear to use the User-Agent string of Microsoft Office Existence Discovery (which, we are reasonably certain, is not a service for existentialist philosophers such as Jean-Paul Sartre or Albert Camus).
As for the malware payload itself, Formbook is an extremely noisy customer.
The malware communicated with more than 50 servers over the course of about 18 hours, generating a huge number of web requests that were also distinctive in that the bot connected to a URL with the string /zxsc/ in the URI path on each server, and without a User-Agent in the request header.
It made many HTTP connections per minute following this pattern, which would be extremely obvious to anyone monitoring the network for unusually high volumes of anomalous activity.