In this article, Check Point Research shares findings on a group / activity cluster with ties to Tropic Trooper:

Check Point Research has recently been tracking a cluster of malicious activity that has been going on for the past several years. The observed activity has strong connections to the Tropic Trooper cluster of activity, as documented by Trend Micro, based on shared infrastructure, tools, and coding practices. Tropic Trooper was previously observed targeting Philippines, Hong Kong and Taiwan; while the two latest are Chinese-speaking countries. This activity in particular caught our interest due to its unusual technical quirks and targeting, as well as the use of a new net-capable strain of a previously documented piece of malware. In this article, we share our findings, with an emphasis on the technical highlights (this is a polite way of saying there won’t be an IDA screenshot of a single-byte-XOR decryption).

Malware authors, a superstitious and risk-averse lot, generally keep their distance from the primordial soup of programming languages trying to ‘make it’ in industry. We don’t encounter many Haskell Banking Trojans or Prolog Ransomware binaries, and the same goes for Nim backdoors. Still, even that rule has its strange exceptions, such as this downloader used by Zebrocy or Nimar loader used by the Trickbot Group. We can now add to this list a new loader, which we dub Nimbda.

Nimbda contains an embedded executable, an SMS Bomber, which it drops into the victim’s temp folder and then executes. Following that, Nimbda separately injects a different piece of code into a launched notepad.exe process.

The dropped executable is a Chinese GUI tool called “SMS Bomber”. It should take a phone number as input and then slaps it on to a very long list of pre-baked HTTP requests asking for one-time codes, verification messages, password recoveries and the like. The result is that the victim’s phone becomes flooded with messages and presumably unusable. SMS Bomber warns users not to use their own phone number for testing, is registered to “A Pot of Sake All rights reserved”, and is written in EPL, a language specifically popular in China for its native support of Chinese strings. This tool is, for lack of a better word, shady. Many security solutions will outright categorize it as malware, even if they can’t agree on a specific reason why. EPL is so disproportionately popular among malware developers compared to the general population that it sometimes gets slapped with the ‘malware’ label on sight, regardless of what the EPL script actually does. The EPL interpreter DLL itself is stored in memory, UPX-packed and loaded in real time, which also isn’t a good look. For what it’s worth, the tool does what it says it does and the author felt comfortable enough to leave their QQ (Chinese instant messenger) number under a ‘contact the author’ menu item, so maybe we shouldn’t be so quick to judge by a first impression.

Figure 2: SMS Bomber main interface

Figure 3: A pre-made HTTP request asking for a verification code to be sent to a given phone number, part of the SMS Bomber tool.

Figure 4: Google-translated highlighted strings from a sandbox run of the SMS bomber.

As mentioned before, in addition to running an embedded executable (SMS Bomber in this specific chain), Nimbda injects a piece of code into a launched notepad.exe process, in this particular infection chain kicking off a three-tier execution flow.

First, initial shellcode glue is injected into notepad.exe and run. This shellcode contacts an attacker-controlled GitHub or Gitee repository and downloads a EULA.md file that contains an obfuscated IP address. A Python script to perform deobfuscation for the IP address, as done in the initial shellcode, is included below (the resulting IP address in the below example is 159[.]75[.]144[.]13)

The initial shellcode then requests https://<IP Address>/index.htm which is a next-stage obfuscated executable, which is run via process hollowing of a launched dllhost.exe process.

This deobfuscated payload is an improved version of TROJ_YAHOYAH backdoor/downloader used by Tropic Trooper previously, as detailed in the original report. This version collects information about local wireless network SSIDs in the victim machine’s vicinity, in addition to information collected by the original Yahoyah (such as computer name, MAC address, OS version, installed AV products, and presence of WeChat and Tencent files). The collected information is formatted and sent to the C&C server.

Figure 5: SN-Yahoyah iterates over available WiFi SSIDs.

Figure 6: SN-Yahoyah reports collected data to its C&C server

Note the “SN” prefix in the string SN202012_x86 — these strings are believed to be internal version identifiers used by the attackers (they also appear, in identical format, in the “USBFerry” malware used by Tropic Trooper). This version of Yahoyah with SSID-scanning functionality is tagged with a unique string prefix of SN (we speculate that it stands for “Spot Net” or “Scan Networks”, or something to that extent). The malware then proceeds to act similarly to known versions of Yahoyah, setting up a DLL for purposes of persistence – it’s either registered as a service or referenced by Run or Winlogon registry key. This DLL downloads an image from the C&C server which actually contains a steganographically-encoded final payload. The DLL will extract the PE and run an exported function StartWork. Other than this Yahoyah variant, the infection chains we have observed make heavy use of other custom variants of Yahoyah (some of which are not new, and predate the above-mentioned activity by a while). While these custom variants all share many features — such as steganography methods, a homebrew hash function for performing obfuscated lookup of process names, and tweaked encryption (see below) — there is also a grab-bag of features that each appear in some variants but not others. These features are all generic backdoor fare, such as anti-analysis checks or a mutex to prevent simultaneous executions (implemented in some samples via writing to an INI file, in others via direct use of the windows API). In one specific sample, we saw use of the Windows Transactional NTFS API for loading and executing an embedded PE inside a seemingly legitimate process (infamously used in the Process Doppelganging technique).

The final payload encoded in the image is TClient, a backdoor known to have been used by Tropic Trooper campaigns. A full analysis of TClient, as well as the original Yahoyah trojan and the Persistence DLL (TROJ_YAHAMAM) is available in the original “Tropic Trooper” report.

Figure 7: Persistence DLL code for loading and executing a payload hidden inside an image

At this point, we ought to ask what this unorthodox execution chain was supposed to achieve, exactly. While there are no definitive answers, we can provide an educated guess. Whoever crafted the Nim loader took special care to give it the same executable icon as the SMS Bomber that it drops and executes. Therefore the entire bundle works as a trojanized binary. That is: the victim launches what they think is just an SMS Bomber, but is actually an SMS Bomber plus a backdoor. An attack making use of such a trojanized binary is necessarily aimed at a rather unorthodox target — people who’d use such an “SMS Bomber” tool in the first place.

The routines that deobfuscate some of the strings in the SN Yahoyah sample we obtained appeared at first glance to be simple AES, except decryption failed when using AES and the given key. Further digging into the malware’s implementation of AES led to the following curious piece of code:

The inverted sequence of round operations (ShiftRows, SubBytes, AddRoundKey, MixColumns) is performed twice, making this not quite AES — one could call it AEES, maybe. A hand-written implementation of AEES was able to properly decrypt the obfuscated strings. When we were young and impressionable we’d often ask ourselves, “why do malware developers roll their own crypto all the time? Doesn’t it just lead to mistakes and reduced security?”. While sometimes it inevitably does, it also serves the important purpose of wasting copious amounts of analyst time. Let’s be candid and share our average and mediocre workflow when encountering an encryption algorithm. First we look for tell-tale strings or constants, using FindCrypt or some such, to identify the algorithm. Then, if that approach fails, we dynamically probe the code and attempt to tease out which algorithm is in use by seeing how it reacts to some choice test inputs. Finally, when all else fails, we become resigned to our cruel fate — we are looking at ‘Unicorn Crypto’ and as far as we are concerned there is exactly one working implementation of it, and it’s inside the malware we are researching right now. Then begins the eye-straining session of looking at disassembly, decompilation, re-implementation, debugging, …

Getting an analyst to go through that entire rigmarole is a cruel and effective feat, especially for the meager cost on the malware author’s side. They just need the knowledge and self-confidence to mess with the crypto in a way that will not render it nonoperational. Executing the round operation sequence of AES twice reads like a textbook example of that. The average malware developer will wonder “Is it weaker now?”, but anyone who knows anything about AES immediately knows that the answer is ‘no’. (Let’s not even get to the slightly-savvier folk who’ll dare ask, ‘does it matter? When attacking the data at rest, you have the key; and trying to attack the data in transit is, broadly speaking, insane’).

The only criticism we can think of regarding this master-stroke is the authors’ use of AES in the ECB mode of operation, which famously allows attackers to See the Penguin. But otherwise, good show, malware authors. That’s some nice chunk of time lost that we will never get back again.

We identified a few dozens of hosts served for this campaign. Most of the infrastructure used in operation the current operation has been hosted in Chinese hosting providers:

Figure 8: Distribution of the servers within different ASN

The relevant host names were extracted directly from samples, as well as from deobfuscated git commits made to the repository used by the above-mentioned Nim loader. Note that the first host is actually a local IP address, and it appears in a commit from August 12, 2020. This host might have been used to test the Nim loader locally. There was a 3-week gap in activity before the next committed host.

Table 1: Hosts extracted from obfuscated git commits.

We have concluded that this activity is probably connected to Tropic Trooper, and TA428 by proxy, based on the following TTPs:

The observed activity cluster paints a picture of a focused, determined actor with a clear goal in mind. Usually, when 3rd-party benign (or benign-appearing) tools are hand-picked to be inserted into an infection chain, they are chosen to be the least conspicuous possible; the choice of an “SMS Bomber” tool for this purpose is unsettling, and tells a whole story the moment one dares to extrapolate a motive and an intended victim.

The surgical modifications to AES are evidence that this actor probably has a decent grasp of block cipher internals. And, finally, the addition of network scanning functionality to Yahoyah shows us that the tools at the disposal of threat actors will be honed and improved as time passes, one way or the other. It falls to the security industry to try to keep pace with these changes as they happen, and react accordingly. For one thing, the next time we run ‘FindCrypt’, we will surely be at least a bit more eager to manually verify the output.

Check Point’s evasion-resistant technology maximizes zero-day protection, providing comprehensive coverage of attack tactics, file-types, and operating systems

Based on the Git commits and the compilation timestamps, we can guess the working hours of the attackers.

While compilation timestamps can be tampered with, the times of the Git commits are likely more reliable.

Figure 9: Distribution of actor’s working hours

© 1994 Check Point Software Technologies LTD. All rights reserved. Property of CheckPoint.com | Privacy Policy