NanoCore RAT Under the Microscope

In this blog, we will present some findings on how NanoCore RAT 1.2.2.0 is actively being delivered in new and different ways that we discovered at Morphisec Labs in the last couple of months. Specifically, we will focus on the sophisticated fileless methods for delivering the RAT without touching the disk.

Background

Remote Access Trojans, also known as RATs, remain as one of the most prevalent forms of malware and are leveraged in many different types of cyber-attacks. Various flavors and versions of these RATs are freely available and easily modified to fit the unique requirements of any given attack. The primary purpose of using RATs is to gain unauthorized remote access to the victim’s device after the initial infection of the machine. Once an attacker gains access to the machine using these RATs, they can try to collect keystrokes, usernames, passwords, browser history, emails, screenshots, etc. A few examples from a much larger list of popular RATs include Poison-Ivy, JRAT, NjRAT, Orcust-RAT, CyberGate, DarkComet, DreamWare, BlackShades, NetWire.

NanoCore Malware is a RAT that has become popular in recent years as it is commonly used by threat actors and is believed to be one of the most sophisticated RATs in the market. Since it was discovered in 2013, multiple different versions have been leaked on underground forums. The latest leaked version was 1.2.2.0 in March 2015 and is available online to download for free. NanoCore RAT comes with a few base plugins and the ability to expand its functionality, so threat actors can develop additional features for other malicious actions. There is already a wide range of NanoCore plugins available online that can be used for cryptocurrency mining, ransomware attacks, and more.

Defense solutions have been updated to detect NanoCore malware based on multiple metadata and strings that reside within its Client executable. Going fileless and in-memory gives the adversaries the advantage of bypassing behavior and static scanning attempts without sacrificing functionality.

Distribution Methods

The most common initial delivery method today is via attachments in spam emails and web download links. Previously security researchers found MS Word documents with malicious auto-executable VBA code and a fake invoice in PDF format that can install the NanoCore RAT.

The first delivery method we identified is using the actual compiler, Autoit3.exe (version 3.3.8.1) which was used by renaming the legitimate AutoIT Script interpreter to cxf.exe to bypass basic script control based solutions. Additionally, the malicious code was executed as a script instead of as an actual AutoIT executable to further evade detection from AV. The malicious script demonstrates advanced support for process hollowing for both 32 and 64-bit architectures, VM evasion, and the use of advanced shellcodes such as RunPE. Here we will investigate the functionality of the script and how it delivers and executes the NanoCore RAT. A similar type of attack was previously reported by TALOS and HornetSecurity, but with a different primary source of the attack and a different file type for the config file.

The second distribution method is using a PowerShell command to download and execute the NanoCore malware from a Pastebin account in-memory. The method is well described as part of the “Aggah” campaign that eventually delivers RevengeRat. In this method, a Pastebin link is run via PowerShell which deobfuscates to NanoCore RAT that was obfuscated with Eazfuscator.

The third delivery method involves the compilation of the malicious AutoIT script into an executable that includes additional functionality. With this method, the executable includes mechanisms for bypassing user control based on the target OS, extended hollowing capabilities for executing the NanoCore RAT from within different legitimate Windows processes, and more advanced shellcodes that bypass hooks and monitoring.

Past Abuse of AutoIT

AutoIT script  is a legitimate tool that is used by many IT administrators to automate tasks. At the same time, it is constantly leveraged by malware authors to deliver different types of malware. In March 2018, security researchers at HornetSecurity witnessed an attack where the NanoCore RAT was distributed via a phishing email that had a PDF file with a link that downloaded a self-extracting archive. The archive contained a legitimate AutoIT interpreter that had been renamed, a malicious script, a configuration file with a .docx extension, and many other files with various extensions. 

In April 2019, researchers at SonicWall observed a phishing campaign that spread the NanoCore RAT through malicious attachments. The attachments had an iso file that had an AutoIT compiled executable that executed the NanoCore RAT in memory. 

Similarly, in May 2018, researchers at Fortinet identified usage of AutoIT to distribute Remcos RAT by using Exploit CVE-2017-11882. Researchers also noticed a similar type of approach where AutoIT was used to deliver Mokes/SmokeBot backdoor and Dofoil/Smoke Loader as well.

Technical Analysis

Method 1: AutoIT Executes a Malicious FILE

Stage 1:

Main Components Involved:

1. ufj=ked 
2. cxf.exe 
3. qnb.jpg 

The script file ufi=ked contains commented garbage code. Most of the code includes comments that are disregarded by the interpreter. After cleaning the garbage code, the size of the script file came down from 203 kb to 7 kb. Below is the de-obfuscated code in ufj=ked script.

Before we get into what ufj=ked script does, let’s first look at the third file qnb.jpg, which is the configuration used by the script and contains a second AutoIT script and a loader. This qnb.jpg file is also riddled with garbage values that required cleaning. Below is an image showing how it looks after cleaning.

cxf.exe, a copy of Autoit3.exe interpreter runs the malicious Autoit script ufj=ked. If we go back to the de-obfuscated code in ufj=ked script (first figure) and understand how the script ufi=ked works, we can clearly see that the script is checking for existing Avast AV process avastui.exe. Then it locates the configuration file qnb.jpg and gets the values of sK and sN. If the values are empty, the script terminates. If the values are not empty, the script reads all the data between [sData] and [esData] and gets sK value (which here is 545) to process the decoder function and finally execute the script. During this process, a randomly named file is written to the same directory with the data from the configuration file. This new script is also an obfuscated AutoIT script that also sets the attributes of files in that current directory to read-only and hidden. This first script is similar to the scripts in the older attacks mentioned above, except with the addition of the configuration file. 

Stage 2:

In this stage, the randomly named AutoIT script dropped by ufj=ked script is also triggered by the same cxf.exe. This new script also checks for the values in the configuration file, qnb.jpg, and has different checks before it even runs the NanoCore RAT payload.

So, what’s inside this new script?

The first thing to notice is its obfuscation, which is similar to the main script. After spending a significant amount of time on de-obfuscation, we were able to find some interesting items inside. The script starts with declared global variables, some of which are dword values for registry checks and modifications. Others are for the values obtained from the configuration file. We also noticed that it has some unused variables that might just be included for use in later versions. As soon as this script is triggered, it sets the attributes of files in that current directory to read-only and hidden, just like the previous script. The script then performs different checks and makes modifications to system configuration and registry values. It checks if it is running inside virtual machines or sandboxed applications and if so, it terminates. Otherwise, it disables UAC, system restore points, and task manager and then adds a Windows Update key to the registry and startup for persistency. Finally, if the config file has a URL, it downloads the payload from there. If the config file has raw PE data, it gets a payload from there and injects it into the process memory of RegSvcs.exe using the RunPE technique.

Below are a few images of the code from the script that we de-obfuscated, cleaned, and renamed functions and variables to show the functionality. The functions are not in exact order, instead, they are presented as below for easy understanding.

From the above figure, we can see that the RunPE_Payload function takes malicious payload data from the config file, decrypts using the Keys value. _S0x9A130944BC5ED49CF25A0ABCA629E5FB function, then takes the value and decrypts the payload using CryptDecrypt function. Finally, the RunPE_Payload function injects the payload into RegSvcs process memory.

NanoCore RAT & Plugins

Method 2: PowerShell In-memory Delivered NanoCore

The second delivery method was already covered by YOROI but in our case, NanoCore was delivered instead of NjRat.

The first PowerShell is an array of ASCII and after decoding we get the next PowerShell code.

The second PowerShell downloads two items from Pastebin; Process Hollowing Injector and the NanoCore RAT.

The Pastebin is been uploaded by the HAGGA actor.

.NET Process Hollowing Injector:

The first call to Pastebin downloads a .NET application that uses kernel32 calls to Hollow the NanoCore into MSBuild.

The PowerShell invoke exe function that is part of k.Hackitup class.

The NanoCore RAT (which is downloaded from the second pastbin.com link) is being passed to the exe function.

In the Injector, a call to POPO class reveals all the kernel32 calls that are used to do the Process Hollowing.

NanoCore:

Method 3: AutoIT Delivers Compiled Script to Executable

The AutoIt compiled executable was delivered as a PDF file with an executable extension, using the AutoIt tool “Exe2Aut” reveals the obfuscated script, the execution steps are controlled by an assigned variable whose value is validated across multiple ‘if’ conditions running in a ‘for’ loop – each time only a single condition is evaluated and following this the next step is assigned to be evaluated in the loop iteration.

We have previously encountered this type of “shift” and “Loop” automatic obfuscation in previous AutoIt campaigns. Following a de-obfuscation of the script we identified a couple of interesting new additions:

A UAC Bypass implementation that correlates to the OS version update:

Persistence through a shortcut in the start-up directory:

Multiple hollowing modes (configurable):

In-memory injection of the binary using shellcode:

In previous versions, we identified the use of simplistic RunPE for injection and hollowing of the NanoCore. However, in the current version, the shellcode was adjusted to implement known methods of bypass and evading hooks by remapping the relevant executables from the knownDlls section.

The dlls that are mapped using NtOpenSection on the KnownDlls directory handle are:

\\KnownDlls32\\advapi32.dll

\\KnownDlls32\\kernel32.dll

\\KnownDlls32\\ntdll.dll

\\KnownDlls32\\user32.dll

\\KnownDlls32\\Ole32.dll

AES Decryption of the NanoCore Payload:

The payload is decrypted using AES_256 algorithm (0x6610).

NanoCore decrypted settings:

The compiled NanoCore client embeds the encrypted plugins and settings as part of its file resources.

Below is the decrypted settings snapshot from the three described instances of NanoCore.

Conclusions:

This research further exposes the tendency of adversaries to abuse memory for the execution of known RAT families that are otherwise easily detected when downloaded to disk. We also see a drastic increase in sophistication over the last year through moving more and more of the attack stages into the memory while using a legitimate Windows process to bypass whitelisting.

Adversaries have the advantage of what, when and where:

• Adversaries can choose where to inject their malicious code and when to execute it while the defenders can not scan the full memory of a process in every possible millisecond without a significant impact on the time and resources.

The only possible way to cope with such risk is by looking at things differently by applying preventive measures.

Moving target defense as well as additional preventive controls such as attack surface reduction or/and proper access control limitation would be able to help mitigate such a risk.

Morphisec prevents all the described attacks by applying Moving target defense on the process memory.