Last week, Minerva prevented a new malware variant that was distributed via phishing emails in south-east Asia. This threat is not an impressive APT, it dosen’t utilize any 0-day exploits and is far from being perfect, yet – during the first couple of days after its release it wasn't detected by the vast majority of security solutions. Its ability to evade detection, even only for a couple of days, combined with the info-stealing capabilities this malware possses, can be devastating. This malware varient provides another live example of the blind spots in current security products At the same time we are able to showcase Minerva's prevention before detection methodology and its effectiveness.
This blog post will detail the infection method, the malaware's charechristics and capabilities and will provide IoC.
We are seeing a trend in which most cybercrime attacks are initiated either by phishing emails or by exploit kits. This case is no exception – the malware in question was sent via a ZIP archive as an email attachment. The content trying to lure the victim to open the attachment is typical to these campaigns: an invoice from the customer support manager of the south-east-Asian branch of a large shipping company:
Although the real sender is clearly not the manager, the content of the email looks credible and plausible. We suspect that recipient was victim to previous phishing campaign, and that his original emails and details were used by the attackers to optimize their current wave of attacks.
The attacker’s electing the identity of the manager at the South-East Asia branch of the shipping company along with the fact that we were able to detect victims of this attack in multiple countries in this region leads us to believe that this wave of phishing emails was geographically focused.
This new threat disguised as the common MySQL utility called Navicat.
The cyber criminals behind this threat tried very hard to make it look like a benign copy of Navicat, editing the metadata so it will be the same as the genuine binary.
The version mimicked by the malware (on the left) is obsolete when compared to the latest Navicat (on the right), while the rest of the properties were carefully copied by the attackers. Another issue the attackers missed was the icon, instead of Navicat's original icon they used a generic one:
For the attackers, editing the metadata wasn't enough, so they signed the malware – with a cryptographically corrupted certificate, suggesting either the certificate or the signed binary were altered:
Fortunately enough, not only did the tampered code signature fail verification – it can also be easily spotted by the different chain of CAs which signed it. The certificate for the real Navicat was issued by Digicert and for the rogue Navicat by Certum.
The fact that Navicat was selected as the disguise shows us that the attackers probably targeted users who wouldn’t suspect it, e.g. – DBAs and IT personnel. Combining the malware's extensive info-stealing capabilities with the high-level privileges of targeted users can highly dangerous for an enterprise.
As seen in the image below, the malware (under the name atiedxx.exe and tmpf_Moc7.exe) executes its own binary nine times. Each of the nine iterations gets a new argument and has a different role in its effort to evade detection, collect data and gain persistency:
We will go through the techniques used by this malware in detail later in this section.
The techniques used to gain persistency are all well-known:
The fact that this malware uses so many techniques simultaneously "just to be on the safe side", created an interesting situation – on each reboot of an endpoint multiple instances of the malware will start:
This issue was partially solved by using mutex objects, however – we still encountered some collisions when multiple instances were executed.
Multiple core components of the malware implement many techniques for stealing various data types, they target:
All the information collected is first saved locally in the following format
Afterwards it is encrypted, and exfiltrated to the attackers, and can be in order to gain control over more assets the victim may have access to.
The malware searches for multiple VNC products and versions including RealVNC, WinVNC, UltraVNC and TightVNC. The versions it searches are obsolete, e.g. RealVNC 4 which was already superseded by version 5 in 2013. This may hint to us that this module was created over four years ago.
A "traditional" Keylogger, Calling SetWindowsHookA with the WH_KEYBOARD_LL parameter. The exfiltrated data will be sent as plaintext over HTTP requests:
Just like BlackPOS, used in the Target breach, this malware checks whether an executable called POS.exe is present on the victim's machine. We have yet to observed any card scraping capability in this malware, but it signals to the C2 server once this file is found – possibly as a request for an advanced module which implements POS-specific capabilities.
One of the most interesting anti-analysis tricks used by this malware is the folder it uses to store a persistent copy of its binary and various other logs and configuration files. It is named com3 and is followed by an extension which is the CLSID of Windows power management utility:
As you can see, the malware is identified by Explorer as a "file folder", however, its filetype causes Windows to open the power management control panel when simply double clicked. Moreover, using "com" as part of the folder name confuses other utilities like cmd.exe, but we overcame this obstacle as well by referencing this folder as a network path:
Above, you can see how in the first DIR command the com3 folder was found and detected as directory, however when we tried to enumerate it directly, it returned a "File Not Found" error.
In order to evade detection this malware (like many others) used a commercial product called Themida.
It provides a framework which allows you to "recompile" your code, maintaining its original functionality while altering the binary. It has legitimate uses, like protecting intellectual property embedded in software, but if Themida's input is a malicious, it will alter the malware in a way that it will make both automatic analysis (e.g. – by an anti-virus solution) and manual analysis much more difficult.
Our sample resolved the URL iamthecause[.]top to the IP address 91[.]134[.]207[.]32 was located in Bulgaria. After going through multiple sources,  we found an older brother to our malware. It had the exact same properties as the original sample but was not signed. This suggests that the capability to sign binaries, even with a corrupted signature, was obtained by the attackers only recently.
Signing the binary, even with invalid signature, minimizes the chances it will be detected. Some security programs do not verify the validity of signatures but have exceptions for signed binaries. This kind of behavior can allow the newer sample to disguise as the original Navicat, or to fly under the radar by simply being a generic signed program.
Once the malware has landed, if starts sending repetitive signals to its C2 server in regular intervals, in this case – it does so every 64 seconds. Each signal contains basic identifying parameters and some optional flags:
The parameter a45 is always present in this "beacon frames", however z=1 and y=1 are optional and depend on the victim machine. y=1 for example will be sent to the C2 only if the file POS.exe is present on the infected machine, supporting our theory about a POS-specific module which can be deployed.
In an attempt to lure the malware to download and deploy this "mystery module" we caused the malware to believe that POS.exe is present. Unfortunately, although our machine broadcasted the unique parameter notifying the C2 that POS.exe is present – we haven't witnessed a case where a POS specific module was downloaded.
Another type of communication between the agent and the C2 servers was the keylogger output, sent as plaintext file with the parameter a63:
The attackers used at least two different URLs, the older sample resolved fraternitylaw[.]co[.]in and the newer sample resolved iamthecause[.]top as already mentioned. In both cases a legitimate website was replicated to give a seemingly benign façade to the C2 gate:
Going through the source of this C2 fake façade gave us an interesting glimpse into the timeline of the phishing campaign:
We found out that the attackers used the free website copier utility HTTrack, and more importantly, as the attackers forgot to remove HTTrack's imprinted logs from the page – we were able to verify the timeline. The content of the URL resolved by the "older brother" was created three months before the one resolved by the newer sample.
At first glance this complex intrusive threat might sound a bit frightening– but if your Enterprise is protected by Minerva you need not worry even a bit. Minerva Anti-Evasion Platform makes the malware believe that its greatest fears have been realized, causing it to immediately halt its execution.
The analyzed phishing campaign and dropped malware are just another example of a fast growing and worrisome trend fish in an overflowing ocean of dangerous threats. Although we assess this campaign was assembled from an eclectic collection of different modules, some significantly older than others, it was almost undetectable when it initially came out. Nevertheless, the potential damage it may cause to an enterprise is severe, considering the effect the leaked sensitive credentials of high-level privileged users might have.
The emergence of these generic, yet-dangerous threats emphasizes the need for a paradigm shift. Countless similar threats are created daily. At Minerva, our goal is to make sure that you have nothing to worry about. We do so by using the Malware's capabilities against itself, preventing it without the need to first detect it.