Malware Analysis - NanoCore

Sample:

1d52c927094cc5862349a1b81ddaf10c

Background

NanoCore is a modular remote access tool developed in .NET that can be used to spy on victims and steal information. It has been used for a while by numerous criminal actors, as well as by nation-state threat actors such as the Iranian group APT33.

Static Analysis - Stage 1

_{Figure 1: Malware Bazaar Entry}

This sample is detected by 20 vendors and contains multiple stages, with the analysis revealing key details, including the extraction of the malware’s configuration.

_{Figure 2: Using Detect It Easy}

At first, I will use DIE on the sample to gather more information about it, including the programming language in which it was written, as shown in Figure 2.

_{Figure 3: Using CAPA}

Based on the CAPA output, I speculate that this is likely only the first stage, with additional stages potentially following. Furthermore, the output suggests the presence of anti-analysis techniques.

_{Figure 4: PEStudio Output}

As shown in Figure 4, multiple strings and indicators are flagged by PeStudio, providing a better understanding of the malware’s functionality. It is most likely packed and contains Stage 2.

This malware includes anti-debugging techniques, making it more challenging to statically extract the unpacked malware. As a result, I decided to take a different approach. The second stage was dynamically extracted from memory after the malware was executed.

Dynamic Analysis - Stage 1

The behavior of the malware was as follows:

A process for the first executed program was created. After a few seconds, the process was terminated, and a new process was created under the same name as the first process.

_{Figure 5: New Process Creation}

From this process, a tool was executed to extract any suspicious artifacts, such as implemented PE, as shown in Figure 6.

_{Figure 6: Extracting Artifacts}

Static Analysis - Stage 2

The newly outputted PE was further analyzed using various tools.

_{Figure 7: Detect It Easy On 2nd Stage}

From the output of DIE, it was observed that the malware was written in .NET and protected with Eazfuscator, a tool designed to obfuscate .NET code to prevent reverse engineering and tampering.

_{Figure 8: CAPA Output}

From the CAPA output, we can observe significantly more details than in the previous analysis, as this is the unpacked version, revealing many more techniques and behaviors.

_{Figure 9: PEStudio Output}

This second stage was analyzed in dnSpy, a popular tool for decompiling and inspecting .NET assemblies, allowing for a deeper examination of the code and its behavior. As shown in Figure 10, this is the entry point of the malware.

_{Figure 10: dnSpy Entry Point}

After some time spent debugging, I was able to locate and extract the malware’s configuration, as shown in Figure 11.

_{Figure 11: Malware Configuration}

Details such as the C2 domain, port, run-on startup, and mutex were observed. A mutex (short for mutual exclusion) is a synchronization object used to prevent multiple processes from accessing shared resources simultaneously, often used by malware to ensure a single instance of itself runs on the system.

• Decoded Malware Configuration:

+		[0]	["KeyboardLogging", true]
+		[1]	["BuildTime", {1/9/2025 10:54:57 AM}]
+		[2]	["Version", {1.2.2.0}]
+		[3]	["Mutex", {3740d544-7efc-40b2-8c32-f31974309f7d}]
+		[4]	["DefaultGroup", "JAMJAM01"]
+		[5]	["PrimaryConnectionHost", "lxtihmjohnson163[.]airdns[.]org"]
+		[6]	["BackupConnectionHost", ""]
+		[7]	["ConnectionPort", 43366]
+		[8]	["RunOnStartup", true]
+		[9]	["RequestElevation", false]
+		[10]	["BypassUserAccountControl", true]
+		[11]	["BypassUserAccountControlData", {byte[0x000004FE]}]
+		[12]	["ClearZoneIdentifier", true]
+		[13]	["ClearAccessControl", false]
+		[14]	["SetCriticalProcess", false]
+		[15]	["PreventSystemSleep", true]
+		[16]	["ActivateAwayMode", false]
+		[17]	["EnableDebugMode", false]
+		[18]	["RunDelay", 0]
+		[19]	["ConnectDelay", 4000]
+		[20]	["RestartDelay", 5000]
+		[21]	["TimeoutInterval", 5000]
+		[22]	["KeepAliveTimeout", 30000]
+		[23]	["MutexTimeout", 5000]
+		[24]	["LanTimeout", 2500]
+		[25]	["WanTimeout", 8000]
+		[26]	["BufferSize", 65535]
+		[27]	["MaxPacketSize", 10485760]
+		[28]	["GCThreshold", 10485760]
+		[29]	["UseCustomDnsServer", true]
+		[30]	["PrimaryDnsServer", "8.8.8.8"]
+		[31]	["BackupDnsServer", "8.8.4.4"]

Dynamic Analysis - Stage 2

After running the malware, more information was revealed, such as registry manipulation, changes to file locations, access to the camera, and keylogging techniques.

_{Figure 12: TCPView Trying To Establish Connection}

After a restart, the malware starts from a new location under the name “ddpss”, attempting to impersonate a legitimate process.

_{Figure 13: Process Starts Under a New Name}

In Autoruns, it was observed that a new entry was added under ‘Logon,’ indicating that this process will start after the computer boots up.

_{Figure 14: Autoruns Entry "Logon"}

Network Analysis

Using Wireshark, a C2 domain was discovered, which matched the domain found in the malware’s configuration, confirming that this is the real configuration for the malware.

_{Figure 15: Wireshark C2 Domain}

Summary

NanoCore is a remote access Trojan (RAT) linked to Iranian threat actor APT33. It features multiple stages, anti-analysis techniques, and obfuscation. During analysis, I extracted its configuration, which revealed C2 domains, mutexes, bypass UAC, and other key details. The malware ensures persistence across reboots by impersonating legitimate processes and manipulating the registry.

IOCs

• Hash:

  1d52c927094cc5862349a1b81ddaf10c
  6a6a79c0c2208774bfb564576ee1c25c
  

• Domain:

  lxtihmjohnson163[.]airdns[.]org
  tunhost[.]duckdns[.]org
  

• IP:

  213[.]152[.]161[.]114