Zurück 
Summary
Threat actors often employ stealthy attack techniques to elude detection and stay under the defender’s radar. One way they do so is by using uncommon programming languages to develop malware. Using an uncommon programming language to develop malware provides several benefits, including:
- Evading some signature based detections
- Impeding analysis by malware analysts that are unfamiliar with the language
- Limited community detection and published analysis
Netskope recently analyzed a malicious backdoor written in Nim, which is a relatively new programming language. Netskope Threat labs has observed an increase in Nim-based malware over the past year and expects Nim-based malware to become more popular as attackers continue to modify existing Nim-based samples. One of the highest-profile Nim-based malware families was the Dark Power ransomware, which began spreading in the wild earlier this year.
This blog post provides a breakdown of a recent targeted threat that uses Word document bait to deliver a Nim backdoor.
Delivery Method
A malicious Word document was used to drop the Nim backdoor. The document was sent as an email attachment, where the sender claims to be a Nepali government official sending security arrangements. Despite the security controls placed around macros in Office files, we are still seeing APT-attributed malware using them to drop their payload, like the Menorah malware we analyzed a couple of months ago.
Initially opening the file will show a blank document with an instruction to enable macros. When the user clicks “Enable Content,” the auto-trigger routine (Document_Open) in the code will execute. Once the main function is called, the code is executed through additional VBA functions inside the document.
Defense Evasion
To help bypass AV and static based detections, the VBA project is password protected and macros are obfuscated using the Chr( ) VBA function and string concatenation. The VBA code is split into the four subroutines in the image below.
sch_task is a function that creates a VBscript named “OCu3HBg7gyI9aUaB.vbs” that will serve as the chain trigger. Initially, the VBscript is created in the AppData startup folder (C:\Users\<user>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\OCu3HBg7gyI9aUaB.vbs) and is set as a hidden file. Oddly, some variables are initialized in one function, but then utilized in a different function/s, which could be meant to confuse static analysis. Some strings referring to directories and libraries are split and then concatenated to evade static detection.
hide_cons is a function to create another VBScript named “skriven.vbs,” which will be used by “8lGghf8kIPIuu3cM.bat” as a shell to run other scripts. More detailed info about this batch script is found below. Again, some strings referring to directories and libraries are split and then concatenated.
read_shell is a function that creates the payload named conhost.exe, which is inside a ZIP archive. As can be seen from the screenshot below of the macro code, it assembles the ZIP from an array of decimals (by converting each to byte) stored in the “UserForm1” object. The resulting byte array is the actual ZIP file and is dropped to C:\Users\<user>\AppData\Local\Microsoft\conhost.zip
vb_chainis a function mainly for creating “8lGghf8kIPIuu3cM.bat”, which will be the stage of infection before the final payload. Exact file paths are generated by the VBA macro before writing to the batch file.