The Cybaze-Yoroi ZLab analyzed a new sample of Nanocore Remote Administrator Tools (RAT) using a Delphi wrapper to protect its code.

Introduction

Historically, cyber-criminals adopted one or more layers of encryption and obfuscation to lower their footprint and avoid detection. The usage of cryptors and packers has become a commodity in the contemporary malware landscape, providing the so-called “FUD” (Fully UnDetectable) capabilities to malicious code and allowing the outsourcing of the payload hiding.

The CSDC monitoring operations spotted a particular sample of the famous Nanocore Remote Administrator Tools (RAT). In this specific case, a Delphi wrapper was used to protect the RAT. Thus, Cybaze-Yoroi ZLab decided to analyze this threat.

Technical Analysis

Nanocore RAT is a “general purpose” malware with specific client factories available to everyone and easily accessible. During our cyber-defense activities we discovered attack attempts against Italian companies operating in the Luxury sector. For instance, we intercepted malicious email claiming to come from a well known Italian Bank and then we started to analyze it.

Figure 1: Part of initial e-mail

The attachment looks like a 7z archive file containing a valid PE file with Adobe Acrobat icon. Trivial trick used to lure ingenuous users to believe that it is a legit PDF file. However, it contains a PE executable:

Hash 8274313b5b1e941a67b54e9f311094f2f56a3afe97820ad03560d9885a60b71b Threat Nanocore RAT wrapper Brief Description Delphi Language Wrapper for Nanocore RAT Ssdeep 24576:FZ8elMYdWD7yWQ5/It6OxPtNHApfqGwcblA8:FyYEvt6OxPTHAgJcblA8 Icon

Table 1: Static info about Nanocore dropper/NanoCore RAT

Then we extracted some static information on the sample:

Figure 2: Information about “trasferimento.exe” dropper/NanoCore RAT

The sample was compiled with “BobSoft Mini Delphi” compiler and two characteristics are significant: the first one is the high level of entropy, this leads us to think that the sample was somehow packed; the second one is the absolutely fake compilation timestamp of the executable.

Executing the malware, we notice the presence of some checks performed by the malware in order to evade analysis boxes.

Figure 3: Processes checked by malware

In the above figure, are shown some processes checked by the malware. This action is performed through the usage of the classical Win32 API calls “CreateToolhelp32Snapshot” and “Process32Next”.

Figure 4: API calls to check open tools

If no one of the checked processes is active, the malware can proceed with the real infection: it writes the real payload of Nanocore RAT in the “%TEMP%” folder.

Figure 5: NanoCore payload written by the loader and relative API calls

The interesting thing is the payload, that is further loaded into memory, is merely embedded inside a resource without any encryption or obfuscation.

Figure 6: Comparison between payload embedded in resource of “trasferimento.exe” sample and “non.exe” written in %TEMP% folder

As shown in the above figure, the “trasferimento.exe” Delphi wrapper has got a lot of embedded resources (as visible on the left), and one of them contains the entire Nanocore RAT payload. On the right, there is a diff analysis of the resource named “2035” and the actual payload triggered on the victim machine. The resource “2035” has a sort of header (highlighted in yellow, on the left upper corner), which contains the name of the payload to implant on the machine “non.exe”. The succeeding piece of code is identical, without any protection. The “trasferimento.exe” component runs a scheduled task in order to guarantee its persistence.

Figure 7: Task-scheduler set by malware

At this point the malware creates a xml file with a pseudo-random name containing the configuration for its persistence on the machine. After creating this file, the malware spawns the “non.exe” process and then re-spawn itself through the following command lines.

schtasks.exe” /create /f /tn “IMAP Subsystem” /xml “C:\Users\admin\AppData\Local\Temp\tmpC5A7.tmp”schtasks.exe” /create /f /tn “IMAP Subsystem” /xml “C:\Users\admin\AppData\Local\Temp\tmpCB59.tmp”

The body of the xml configuration file is the following:

<?xml version=”1.0″ encoding=”UTF-16″?><Task version=”1.2″ xmlns=”http://schemas.microsoft.com/windows/2004/02/mit/task”> <RegistrationInfo /> <Triggers /> <Principals> <Principal id=”Author”> <LogonType>InteractiveToken</LogonType> <RunLevel>HighestAvailable</RunLevel> </Principal> </Principals> <Settings> <MultipleInstancesPolicy>Parallel</MultipleInstancesPolicy> <DisallowStartIfOnBatteries>false</DisallowStartIfOnBatteries> <StopIfGoingOnBatteries>false</StopIfGoingOnBatteries> <AllowHardTerminate>true</AllowHardTerminate> <StartWhenAvailable>false</StartWhenAvailable> <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable> <IdleSettings> <StopOnIdleEnd>false</StopOnIdleEnd> <RestartOnIdle>false</RestartOnIdle> </IdleSettings> <AllowStartOnDemand>true</AllowStartOnDemand> <Enabled>true</Enabled> <Hidden>false</Hidden> <RunOnlyIfIdle>false</RunOnlyIfIdle> <WakeToRun>false</WakeToRun> <ExecutionTimeLimit>PT0S</ExecutionTimeLimit> <Priority>4</Priority> </Settings> <Actions Context=”Author”> <Exec> <Command>”C:\Users\admin\Desktop\trasferimento.exe”</Command> <Arguments>$(Arg0)</Arguments> </Exec> </Actions></Task>

The difference between the two scheduled tasks is the fact that one references “trasferimento.exe” process and the other one references “non.exe” process. It seems to be a sort of a survival mechanism in which both the processes work and keep the infection alive.

Figure 8: Details about set task scheduler

These two processes contact two different C2s. During the analysis one of them (185.244.31.[50) was down and the other one (79.134.225[.41) continues to work.

Figure 9: Communication with two different C2

NanoCore Client

Hash 52d73eee176a2ff30af7e386809b94ef1c4918f131f8de1e2b66915ab8cc3790 Threat Nanocore RAT Brief Description NanoCore RAT client Ssdeep 6144:MLV6Bta6dtJmakIM5u8GL+1WUQ52F+/8Ej4eg:MLV6BtpmkqGLUcQsEEj4h

Table 2: Information about “non.exe” NanoCore RAT

At this point, let’s start to analyze the “non.exe” file which is the Nanocore RAT Client, even this one is compiled in .NET language.

Figure 10: Other information about “non.exe” NanoCore RAT and relative compiled language

The de-compiled code is quite obfuscated and encrypted with some custom routines.

Figure 11: Version of NanoCore Client

The real nature of the payload is revealed after few steps of debugging, we extracted also the current version: 1.2.2.0, as highlighted in the red square. Going ahead with debugging, we found a recurrent routine used to decrypt RAT’s static strings and the malware configuration too:

Figure 12: Decryption routine to extract the configuration file

Like other crimeware, also this one leverages encrypted configuration only decrypted during the malware execution. Interestingly, the extracted configuration does not include persistence, which is however guaranteed by the scheduled task handled by the external wrapper.

Figure 13: Configuration information of the RAT client

As we can see from the above figure, this client has some interesting enabled features, like the capability to bypass the UAC control, or prevent the system to go to sleep. Moreover, the primary and backup C2 are the same and the solution of the backup C2 is guaranteed through the other “trasferimento.exe” RAT mode process.

Conclusion

Nowadays a lot of cyber criminals don’t strive to write malware from scratch because there already are a vastity of public tools suitable for this need. From the attacker point of view, the problem about the usage of these tools is the fact they sooner or later will be recognized by the Anti-Virus engines.

Therefore, attackers adopt other technologies like packers and obfuscators, many time publicly available too, or write down custom loaders to hide their espionage tools, keeping them running into victim machines for a long time, silently observing their targets and awaiting the right time to act their criminal plans.

Technical details, including IoCs and Yara Rules, are available in the analysis published in the Yoroi blog.

https://blog.yoroi.company/research/dissecting-nanocore-crimeware-attack-chain/

Pierluigi Paganini

(SecurityAffairs – NanoCore, malware)