Investigation into the state of Nim malware

By: Jason Reaves and Joshua Platt

Whenever malware is found to be written in new programming languages the AV detections are generally lacking because the new language is producing bytecode sequences that are relatively unknown along with strings of data that can throw off static based heuristic models. It also usually causes stress within the malware reverse engineering community as was seen with GoLang malware initially.

Enter Nim[1], which was used to create a repository of code examples leveraging Nim for red team related utilities but malware developers take notice of things that can be leveraged for more infections including compiled programming languages that bypass AV detections. This was brought more to light recently in a report we put out going over a new loader being leveraged by the TrickBot cybercrime group that was written in Nim, NimRod[5], much the same as they use BazarLoader[3] and some of the concepts or development requirements for Baza could of been imposed on NimRod after all they are both being leveraged as loaders to deliver CobaltStrike primarily[4].

This left me wondering what else was out there in the world of Nim malware, this report is a compilation of my findings.

Nim Crypter

First we have possibly an adversary leveraging code from OffensiveNim to conceal an onboard encrypted binary, something we would normally refer to as a Crypter in the malware world but is a tool that is designed to bypass AV by wrapping a layer around a binary that would otherwise be detected.

This is using publicly available code from OffensiveNim but also step-by-step instructions[6,7] that are available for how to use the code to crypt up and deliver a .NET assembly. The standard method in the repo involves storing the file AES encrypted and Base64 encoded, we can reverse the process to statically recover the onboard file.

In this case it is loading a GruntHTTP stager:

Another usage of OffensiveNim code as a crypter but this time direct references to SharpKatz which was explained in the PPN github repo[6]. Decoding out the onboard file in the same manner leaves us with SharpKatz:

Nim Stagers

A common area where we saw GoLang being used when malware developers started noticing it was with stagers or Meterpreter or CobaltStrike, the same pattern holds true for Nim as well.

The shellcode is in the clear and appears to be Metasploit code for downloading and executing a next stage, even with the shellcode in the clear the detections at time of upload to VirusTotal were 4/66.

Here we can see that the next stage will be pulled from 45.43.2.118 but this was down at the time I discovered the file, the IP address was associated with being a CobaltStrike C2 at one point in time according to VirusTotal data.

Photo credit: VirusTotal

This is also a stager but this time the shellcode is obfuscated, the first layer is base64.

After Base64 decoding this the sample will then treat the first 256 bytes as a lookup table to deobfuscate the remaining data.

The decoded data is CobaltStrike stager shellcode with a local IP address. We were able to pivot on this technique of decoding the shellcode to find another stager using the same decoding mechanism to a live C2:

The shellcode stager this decodes out goes to:

Which contains a shellcode wrapped CobaltStrike beacon when downloaded.

This also turns out to be a CobaltStrike stager with a local IP address but the data is encrypted using 3DES with the key on top of the encrypted data:

The last stager we are going to look at it has a few more layers of encoding on the stager shellcode but it also currently only has 5 detections on VirusTotal.

The XOR key for the shellcode is stored single byte XOR encoded itself:

Then the encoded stager shellcode is copied:

The encoded shellcode and XOR key are then passed to a function calling itself showStr:

This function will actually be decoding the shellcode:

The steps are Base64 decode -> XOR -> unhexlify which leaves us with another stager shellcode blob:

Loaders

Aside from NimRod there appears to be other loader malware out there written in Nim that shares some code similarity with NimRod in regards to the string encoding technique, whether this mean they are based on similar code bases or were developed by the same person is unsure.

The CAB file contains two files in it which are both written in Nim and contain the same string encoding routine as NimRod.

Loader.exe:

Decoded strings:

reader_sl.exe

Clear strings:

Decoded strings:

We’ve shown a number of examples that demonstrate a variety of people are experimenting with using Nim for various purposes, most of the testing at this time appears to be red team related but some malicious actors have also been utilizing it recently.

IOCs

References

1: https://nim-lang.org/

2: https://github.com/byt3bl33d3r/OffensiveNim

3: https://www.crowdstrike.com/blog/wizard-spider-adversary-update/

4: https://www.bleepingcomputer.com/news/security/bazarloader-used-to-deploy-ryuk-ransomware-on-high-value-targets/

5: https://medium.com/walmartglobaltech/nimar-loader-4f61c090c49e

6: https://github.com/snovvcrash/PPN

7: https://s3cur3th1ssh1t.github.io/Playing-with-OffensiveNim/

--

--

We’re powering the next great retail disruption. Learn more about us — https://www.linkedin.com/company/walmartglobaltech/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Jason Reaves

Malware Researcher, Crimeware Threat Intel, Reverse Engineer @Walmart