Ho ho ho! Christmas is coming, and for many people it’s time to do some online shopping.
Authors of banking Trojans are well aware of this yearly phenomenon, so it shouldn’t come as a surprise that some of them have been hard at work preparing some nasty surprises for this shopping season.
And that’s exactly what TrickBot has just gone and done. As one of the most prevalent banking malware for Windows nowadays, we’ve recently seen it diversify into attacking Nordic banks. We’ve blogged about that a couple of times already.
As usual, the Trojan is being delivered via spam campaigns. According to this graph, based on our telemetry, most spam was distributed between Tuesday afternoon and Wednesday morning:
The spam emails we’ve seen typically have a generic subject like “Your Payment – 1234”, a body with nothing but “Your Payment is attached”, and indeed an attachment which is a Microsoft Word document with instructions in somewhat poor English…
Clicking the button will not reveal any document content, but launch a macro that will eventually download and run the TrickBot payload.
Same old trick, but some people who have just bought a Christmas gift might still fall for it and end up with another ‘gift’ installed on their computer.
And that ‘gift’ is the most interesting part of this story. The newest payload underwent some changes which are, well, remarkable…
Since its initial appearance during Fall 2016, the actors have been actively developing the malware, and are constantly expanding and changing the targets. Here a short summary of the recently spotted changes:
Up till now, we were not aware of any features in TrickBot that were checking if the malware is run in a virtual machine or a sandboxed environment used for automatic analysis. The new version has introduced a few simple checks against some known sandboxes by calling GetModuleHandle for the following DLLs:
(More info about every DLL can be found here)
If any of these modules are found, the payload just quits.
Interestingly, we have also found a few encrypted strings that seem to indicate detection of the Windows virtual machine images that Microsoft provides for web developers to test their code in Internet Explorer and Edge, however, these strings are not used anywhere (yet). Let’s see if the actors will expand their sandbox evasion attempts in a future version.
But we have saved the best for last. When the payload was running, we noticed that it didn’t run with user rights, as it always did before. Instead, it was running under the SYSTEM account, i.e. with full system privileges. There was no UAC prompt during the infection sequence, so TrickBot must have used an auto-elevation mechanism to gain admin rights.
A little search in the disassembly quickly revealed an obvious clue:
Combined with a few hard-coded CLSIDs …
… we found out that the actors have implemented a UAC bypass which was (as far as we are aware of) publicly disclosed only a few months ago. The original discovery is explained here:
And later implemented as a standalone piece of code, and most likely the main inspiration for the TrickBot coders:
In short: this bypass is a re-implementation of a COM interface to launch ShellExec with admin rights, and it is used in a standard Windows component “Component Manager Administrator Kit” to install network connections on machine level.
It works everywhere from Windows 7 up to the latest Windows 10 version 1709 with default UAC settings, and considering it’s basically a Windows feature, probably hard to address. In other words, perfect for usage in malware, and it wouldn’t surprise us if we’ll see the same bypass in more families soon.
Thanks to Päivi for the spam graph.