Proofpoint researchers observed an interesting email campaign by a threat actor we track as TA800. This actor has predominantly used BazaLoader since April of 2020, but on February 3rd, 2021 they distributed a new malware we are calling NimzaLoader. One of NimzaLoader’s distinguishing features is that it is written in the Nim programming language. Malware written in Nim are rare in the threat landscape. Malware developers may choose to use a rare programming language to avoid detection, as reverse engineers may not be familiar with Nim’s implementation, or focused on developing detection for it, and therefore tools and sandboxes may struggle to analyze samples of it.
There has been some initial analysis of the malware on Twitter indicating that it may just be another variant of BazaLoader, of which there are many variants. On March 1st, Joshua Platt and Jason Reaves from Walmart put forth an excellent writeup on this malware that they call Nimar Loader. Our independent analysis corroborates their analysis and assertions that this malware is not a BazaLoader variant. Some of the major differences between NimzaLoader and the BazaLoader variants that we’ve analyzed include:
- Written in a completely different programming language
- Doesn’t use the same code flattening obfuscator
- Doesn’t use the same style of string decryption
- Doesn’t use the same XOR/rotate based Windows API hashing algorithm
- Doesn’t use the same RC4 using dates as the key command and control (C&C) response decryption
- Doesn’t use a domain generation algorithm (DGA)
- Makes use of JSON in C&C communications
In this post we’ll take a closer look at the email campaign and the malware.
On February 3rd, 2021, Proofpoint observed a TA800 campaign distributing NimzaLoader. Consistent with previous activity, this campaign utilized personalized details in its lure, including, the recipient’s name and/or the company’s name. The messages contained links, which in some cases were shortened links, purporting to be a link to a PDF preview, but instead linked to GetResponse (an email marketing service) landing pages. The landing pages contained links to the “PDF” which was the NimzaLoader executable hosted on Slack and used a fake Adobe icon in an attempt to fool the user.
Figure 1: TA800 message linking to the GetResponse Landing Page
Figure 2: TA800 GetResponse Landing page linking to the download of NimzaLoader
The sample with a SHA-256 hash of 540c91d46a1aa2bb306f9cc15b93bdab6c4784047d64b95561cf2759368d3d1d was reverse engineered for this analysis. At the time of research, the C&C servers were already down, so we also made use of a PCAP file uploaded to VirusTotal.
Nim Programming Language
NimzaLoader was developed using the Nim programming language. This can be seen by the various “nim” related strings in the executable (Figure 3):
Figure 3: Example of Nim related strings
Most of the strings used by the malware are encrypted when stored by using an XOR-based algorithm and a single key per string. An IDA Python function of the algorithm will be available on our GitHub. Here is a listing of decrypted strings from the analyzed sample:
A few strings, mostly command names, are stored as stack strings instead of encrypted strings.
One of the encrypted strings is a Unix epoch timestamp and is used as an expiration date for the malware. In the analyzed sample, the expiration date was set to “1612963255.0039535” (e.g., Wednesday, February 10, 2021 1:20:55.003 PM GMT) and the malware will not run after this date and time.
The C&C URLs are stored as encrypted strings and in the analyzed sample were the following:
There is also an encrypted string that contains a C&C URL path component used in command requests. In the analyzed sample this component was “about”.
Command and Control
C&C is HTTPS based. The initial beacon is called a “handshake” by the malware and an example looks like Figure 4:
Figure 4: Example handshake request and response
The handshake is used to do a X2551 key exchange with the C&C server and retrieve some configuration items. The “SID” value in the “Cookie” header request is base64 encoded. Once decoded, it contains the malware’s generated public key for the key exchange and some additional data to decrypt the handshake response from the C&C server.
The C&C response can be decrypted by using this data along with some of the encrypted strings from the malware and some primitives from the Monocypher crypto library. A Python snippet using data from the above referenced PCAP and its sample showing this decryption process will be available on our GitHub. Once decrypted the response contains a JSON object that looks like Figure 5: