A few days ago, I was investigating a sample piece of malware where our static analysis flagged a spreadsheet as containing a Trojan but the behavioural trace showed very little happening. This is quite common for various reasons, but one of the quirks of how we work at Bromium is that we care about getting malware to run and fully detonate within our secure containers. This enables our customers to understand the threats they are facing, and to take any other remedial action necessary without any risk to their endpoints or company assets. Running their malware actually makes our customers more secure.
A quick look at the macros in this spreadsheet revealed that it was coded to exit Excel immediately if the machine was not based in Italy (country 39):
We often see malware samples failing to run based on location, but usually they look for signs of being in Russia. This is widely believed to help groups based there avoid prosecution by local authorities, but of course leads to false-flag usage too. My interest was piqued, so I modified the document to remove this check so it would open and then I could see if we could get the malware to detonate. The usual social engineering prompt is displayed on opening:
Roughly translated as ‘It’s not possible to view the preview online. To view the content, you need to click on “enable edit” and “enable content”’.
After modifying the spreadsheet, the malware detonates inside one of our containers. We see the usual macro-based launch of cmd.exe and PowerShell with obfuscated arguments. This is very run-of-the-mill, but these arguments stood out as not being from one of the usual obfuscators we see, so I was determined to dig a bit deeper:
(truncated very early)
As a side note, malware authors actually spend quite a lot of effort on marketing, including often mentioning specific researchers by name within samples. This happens because of the nature of modern Platform Criminality – malware is licensed to affiliates for distribution, and in order to attract the most interest and best prices malware authors need to make a name for themselves. It’s not clear whether or not this sample was actually trying to encourage me to investigate or not, but sometimes huge clues like this are put into samples on purpose.
The binary strings are just a list of encoded characters, so this was easily reconstructed to the following code, which looks like PowerShell:
At this point, things seemed particularly interesting. My PowerShell skills are basic, but it looks like this sample is trying to download an image and extract some data from the pixel values. There was only one person to turn to – our PowerShell evangelist and polymath Tim Howes, who was also intrigued.
Meanwhile, I pulled the images, with each looking roughly like this:
(I’ve slightly resized and blurred).
Steganographic techniques such as using the low-bits from pixel values are clearly not new, but it’s rare that we see this kind of thing in malspam; even at Bromium, where we normally see slightly more advanced malware that evaded the rest of the endpoint security stack. It’s also pretty hard to defend against this kind of traffic at the firewall.
Now over to Tim to make sense of the PowerShell plumbing.
A manual re-shuffle to de-obfuscate the code and you can see more clearly the bitwise operation on the blue and green pixels. Since only the lower 4 bits of blue and green have been used, this won’t make a big difference to the image when looked at by a human, but it is quite trivial to hide some code within.
Recasting the above code to a different form makes slightly more sense of where in the image we’re extracting from:
This equates to the area in blue at the top of the image here:
The above code is finding the next level of code from the blue and green channel from pixels in a small region of the image. The lower bits of each pixel are used as adjustments to these and yield minimal differences to the perceived image. Running this presents yet more heavily obfuscated PowerShell:
We can work through this by noticing that there is another large string (base64 encoded) sliced/diced into 40 parts. This can be reassembled:
Looking at the above, we see they are using a .net decompressor; so employing our own local variables to step through each part yields:
This gives a resultant stream of yet more PowerShell:
We execute the “-split” operations on the large string and then convert to a string:
We now see that $str is still more mildly obfuscated PowerShell:
There’s another slice/dice to form “iex” (the alias for invoke-expression in PowerShell): ($env:comspec)[4,15,25] == 'iex'.
The manually de-obfuscated PowerShell reveals the final level which is dropping and executing from a site, but only if the output of ‘get-culture’ on the machine matches “ita” (for example if the culture is Italian, which matches the earlier targeting attempts).
We downloaded the samples from the above, including from an Italy-based VPN and were given various samples of Gandcrab[*] ransomware. Gandcrab has seen phenomenal success last year, initially being distributed by exploit kits and becoming especially prevalent in the Far East.
I am generally skeptical of malware attribution claims, and the implications of so much obfuscated code hidden within a picture of Mario and checking for an Italian victim are not obvious; for all we know the fictional Wario may be as likely to be responsible as any geopolitical actor. However, a future avenue for investigation here is to examine the encoded affiliate IDs, and compare against samples we have collected from other sources to see if there are patterns for whom this affiliate is targeting.
Another key forensic advantage that we have at Bromium is that we partition our isolation at the granularity of a user task (in this instance, the opening of a piece of malspam from an email). This means we can associate each sample with lots of forensic metadata about the task the user was performing, simply because they are from the same container. Mining our set of Gandcrab samples to track the behaviour of their affiliates is definitely a task for another day.
Whether or not they are based in a targeted country, our users can open malicious emails safely and transparently with Bromium as our hardware-enforced containers securely isolate the malware from the host system (our princess is in another castle).
Update: Thanks to the ZLab team for getting in touch and pointing out that the final EXE samples are actually Ursnif and not Gandcrab as reported above. My attribution was based on the few AV tools that were detecting this at the time claiming it as Gandcrab, but they have subsequently updated. The ZLab team also wrote about this threat here.
- Original Spreadsheet: 3849381059d9e8bbcc59c253d2cbe1c92f7e1f1992b752d396e349892f2bb0e7
- Mario image: 2726cd6796774521d03a5f949e10707424800882955686c886d944d2b2a61e0
- Other Mario image: 0c8c27f06a0acb976b8f12ff6749497d4ce1f7a98c2a161b0a9eb956e6955362