Pierluigi Paganini June 14, 2019

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.

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:

Table 1: Static info about Nanocore dropper/NanoCore RAT

Then we extracted some static information on the sample:

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.

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”.

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.

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

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.

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.

The body of the xml configuration file is the following:

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.

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.

NanoCore Client

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.

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

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:

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.

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)

[adrotate banner=”5″]

[adrotate banner=”13″]