From Automated Twitter Post to Decoded Shellcode
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.
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:
Going down the RFC to section 7.6 we find this is called a “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:
Then we select IP from the “Embedded Artifacts” dropdown:
Then we can input the 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).
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:
For our deep dive here we are going to use the sample from this automated Tweet on June 28th:
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:
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:
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”.
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.
Examining the hex contents of the file, notice the “Encrypted Package” string below:
Using the command line Python tool msoffcrypto-crack.py we can verify 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 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:
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:
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:
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:
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.
Note that you must nibble the leading 0-byte at 0x20 above, as done here:
Extracting from that point forward, we get the proper output:
After saving the bytes from the “docfile” header on, the data here can then be 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,
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
- IP: 103.207.37[.]236
- 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.