Blog

From Automated Twitter Post to Decoded Shellcode

Files flagged as malicious

The purpose of InQuest Labs is to enable independent security researchers with a convenient mixture of files and threat intelligence. Users can register for free and interface via the UI/UX, an open API, or via a Python library / command-line interface. The InQuest team leverages this API to implement a variety of automations designed to surface novel threats, we call these “Special Operations” or SpecOps for short. One of these SpecOps actively follows links discovered in malicious documents. If the target of the link is a malicious file, and that link has not been widely reported, and the file has not been previously seen… then a Tweet is automatically posted. Recently, there’s been a number of Tweets that reveal a common pattern, this blog post is a deep dive into these samples. The samples sourced for this post came from the following Twitter search:

“@InQuest Potentially malicious RTF document”

Two examples of which are depicted below.

@InQuest Potentially malicious RTF document

The usage of the ‘@’ symbol in the URLs immediately catches the eye. Scrolling down the list we see multiple posts with a random subdomain, followed by “github.io”, then the “@” symbol, and finally various bare IP addresses prior to the requested path. When we attempt to make a GET request with the full URL we find it will ignore everything before the ”@” symbol. So what is happening here? If we look at RFC 3986 we learn that the “@” symbol is a reserved character used as a delimiter:

Reserved characters

Going down the RFC to section 7.6  we find this is called a “Semantic Attack”.

Semantic Attack

So if we find a URL with a “@” symbol in it we need to pay closer attention to what it is. Extracting the data from the tweets we have a list of IP’s.

192.227.168[.]194 -- 27 hits
192.227.129[.]26  -- 1 hit
104.168.32[.]43   -- 5 hits
193.169.255[.]115 -- 4 hits
107.175.3[.]116   -- 1 hit
198.12.81[.]50    -- 2 hits
104.168.32[.]21   -- 2 hits
104.168.33[.]68   -- 1 hit
185.29.10[.]20    -- 2 hits
192.3.239[.]42    -- 1 hit
198.12.89[.]203   -- 1 hit
35.177.103[.]98   -- 1 hit
104.168.33[.]66   -- 1 hit
103.147.184[.]143 -- 1 hit
107.172.76[.]188  -- 2 hits

Let’s take our first IP and search InQuest Labs. We select the IOC option from the “Search by” dropdown:

InQuest Labs IP search

Then we select IP from the “Embedded Artifacts” dropdown:

InQuest Labs Embedded Artifacts

Then we can input the IP from the Tweet:

IP from the Tweet

We can see it found 27 files that reference that IP. Another column that may be of interest is the “Subcategory” which shows what source the sample was initially seen on. Here we see a mix of malshare.com, malware_bazaar, and maldoc_hunter (VirusTotal).

27 files that reference that IP

If you click on the malshare.com link it will take you to the source file on Malshare. If you click on the malware_bazaar link it will take you to the file hosted on Malware Bazaar. If you click on the link for maldoc_hunter it will take you to GitHub where the YARA rule is hosted for hunting this kind of file:

GitHub YARA rule

For our deep dive here we are going to use the sample from this automated Tweet on June 28th:

Potentially malicious RTF document deep dive

Here we see the URL extracted from the Office document, the hash for the RTF file that got downloaded and then the link to the original file. Going back to our search in InQuest Labs we can find the matching hash value:

URL extracted from the Office document
Extracted from the Office document

Another thing we can see is this was ingested from MalwareBazaar. Clicking on the category column will take us directly to the file entry for additional information:

MalwareBazaar file entry

This first section is a spoiler. It tells us the file is am XLSX file, the final deliverable for this sample is Formbook, and that the file is encrypted and it found the password was “VelvetSweatshop”.

OLE Dump

Above is an OLE Dump that verifies it is encrypted and below is the detection ratios from the various file scanning services integrated with Malware Bazaar, including InQuest.

Detection ratios

Examining the hex contents of the file, notice the “Encrypted Package” string below:

Hex contents of the file

Using the command line Python tool msoffcrypto-crack.py we can verify the password.

Verifying the password

Using the command line again we can use msoffcrypto-tool to decrypt the file using the password “VelvetSweatshop”. The decrypted file’s SHA256 hash is:

E72A227E59B00C42AE7725BFB28B37A91E4CF22E4E094E31C9073176BAD875EF

Notice the “Encrypted Package” string is now gone:

The "Encrypted Package" string is now gone

The decrypted file is now in ZIP file format and easily decompressed:

The decrypted file is now in ZIP file format and easily decompressed

Unzipping the file we can navigate to the XL folder and find the following two files under the embeddings subfolder:

Two files under the embeddings subfolder

Among the two embedded objects appears to be a decoy document and an OLE Object, the contents of which contain the IOC for the next-stage payload, seen highlighted here:

IOC for the next-stage payload

Following this link, we discover that the next-stage payload is an RTF document with a sparse header. Note that the proper RTF header magic is {\rtf1. However, Microsoft applications will accept this shorter form:

RTF document with a sparse header

Now we have the RTF downloaded. When we open it up in an editor the formatting reveals whitespace obfuscation. Notice the superfluous inclusion of both newlines and spaces below:

Whitespace obfuscation
Hex string familiar to the OLE file format

If we strip the whitespace and newlines, we reveal that there is a hex string in there of “D0 CF 11 E0”, the familiar prefix for the OLE file format.

OLE file format
OLE file format continued

Note that you must nibble the leading 0-byte at 0x20 above, as done here:

Leading 0-byte

Extracting from that point forward, we get the proper output:

Proper file output

After saving the bytes from the “docfile” header on, the data here can then be decompressed/extracted using 7Zip.

Saved bytes from the “docfile” header on
Data decompressed/extracted using 7Zip

Using OLE Native this is the shellcode that is targeting CVE-2017-11882, one of 787 entries from CISA’s Known Exploited Vulnerabilities (KEV) catalog,

Shellcode that is targeting CVE-2017-11882

Using CyberChef disassembler we can get the assembly of the shellcode. Here they made it easy for us to find all of the values needed to input into a decoder.

The shellcode will use “URLDownloadToFileW” to download from “hxxp://103.207.37[.]236/winspace/scrss.exe” and save it to “%PUBLIC%\vbc.exe” and then load it with “ShellExecuteExW“.

As we have seen earlier this ended up being detected as Formbook.

I have seen several of this type of URL used recently and there appears to be different malware that ultimately gets dropped.

IOCS:

  • URL: hxxp://103.207.37[.]236/winspace/scrss.exe
  • RTF: 94a9a05d826383c1a9dc0d475659b01603ef617773305d62871749cf96ccf147

How Effective Is Your Email Security Stack?

Did you know, 80% of malware is delivered via email? How well do your defenses stand up to today’s emerging malware? Discover how effectively your email provider’s security performs with our Email Attack Simulation. You’ll receive daily reports on threats that bypassed your defenses as well as recommendations for closing the gap. Free of charge, for 30 days.

Get My Email Attack Simulation