Malware detection by Artifacts: The Nanocore case

One of CyberSOC’s missions is to detect the presence of malware in our clients’ information systems (IS). There are many methods and strategies to achieve that goal, such as Threat Intelligence-based detection, which means raising an alert if a connection is made with a network indicator (IP addresses, domain names, etc.) that has a bad reputation.

The disadvantage of this technique is that it relies on static elements and lacks, even if successful, a context to qualify the incident. To overcome this defect, our CyberSOC develops detection rules based on a list of patterns or, alternatively, on behaviors and operating modes specific to certain malware. This method allows the threat to be qualified as soon as it is detected by the SIEM (Security Information and Event Management). However, it does imply permanent monitoring to keep this list up to date and adapt it to the specific network environments that are to be monitored.

Nanocore, (MITRE ATT&CK S0336), is a widespread RAT (Remote Access Trojan) malware and has been used for many years by different attackers’ profiles. “Customizable” thanks to many plugins, it is coded in “.Net” and available for about twenty US dollars. Its source code has been published on various specialized forums, which also contributes to its popularity.

Figure 1: Example of a Nanocore panel – Source: https://web.archive.org/web/20160203201047/http://www.nanocore.io/

Originally distributed as a “remote administration tool”, its developer praised the tool’s spying capabilities and promised 24/7 support for a very attractive price. In fact, it is widely used for cybercriminal purposes, particularly in malware campaigns. It is regularly detected by our CyberSOC, and is part of Aggah’s arsenal.

Its author, Taylor Hudleston, was arrested by the FBI in early 2017 and was sentenced to 33 months in prison[1].

There are several methods to detect this malware, the simplest being to monitor the creation of a run.dat file in the user’s AppData\Roaming\{GUID} directory, which is typical behavior for this malware.

Figure 2: Total VirusTotal result for sample bfc803c89604e9adb4572d2a752bfc0e77aa3181c321768081f47b8e1ebc7d53 – Source: VirusTotal

Although this method may seem simple and effective, it is not necessarily applicable to all our clients’ contexts. Monitoring the creation of files implies the presence of an EDR, or at least, of Sysmon. Although they are increasingly used, the activity logs of these solutions are rarely collected in SIEM, as they are extremely verbose and therefore expensive.

Our CyberSOC has therefore thought about an alternative technique based on the data generally collected by the SIEMs but also the significant artifacts generated by malware activities. The choice went to the Windows security logs and more particularly the event 4657 – A registry value was modified. This event records any creation, modification or deletion of register key values. However, this monitoring must be activated (via GPO for example).

Based on the reports from running Nanocore samples from a public sandbox, we find that for all these samples, the HKCU\Software\Microsoft\Windows\CurrentVersion\Run\TCP Monitor registry key is created. Its value is the path to the tcpmon.exe executable. We notice that this executable is located in a directory named TCP Monitor.

This could be a detection pattern. However, by executing these same samples in the sandbox developed by Orange Cyberdefense (P2A), we realize that the name of the key and its value differ: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\NAS Host having for value the path to the executable nashost.exe. We observe the same behavior: the executable is also located in a directory corresponding to the name of the key (NAS Host).

This behavior has aroused our curiosity; our hypothesis being that the malware code contains a list of values. A function is then tasked with deriving one of these values according to machine elements.

This post does not aim to detail the reverse side of Nanocore, a topic that is already the subject of many publications but to focus on the functions that allow us to understand how the Run key is named and its value.

A simple static search on the “Monitor” pattern allows us to identify a constructor of type Structs containing tables of variables of type String within which we find the various observed values.

Figure 3: code extract containing the tables of variables – Source: Orange Cyberdefense CyberSOC

The same constructor also contains a function that uses these three variables. This function takes the machine’s Guid (Globally Unique ID – the unique numerical fingerprint of the machine) as a parameter and returns two variables of type String whose structure (presence of space and extension .exe) corresponds to the name of the key and its value.

Figure 4: Extract of the code containing the function generating the key name and its value – Source: Orange CyberSOC Cyberdefense

The function is called to obtain the name of the key and its value. They are connected to the machine guide. The function returns two variables of type String:

• String_0 is the name of the key, constructed by concatenating a capitalized value from the String_4 array, followed by a space and then a value from the String_3 array.
• String_1 is the value of the key. It is built by concatenating the same value of the array String_4 as for String_0 then a value of the array String_2 followed by .exe.

For example, starting from the Guid of the VirusTotal sandbox (e308eb5f-53cc-4bed-89c0-f9bbcc246f37), the values would be as follows:

• String_0 = SMTP Service
• String_1 = smtpsvc.exe

Given the number of variables contained in each of these tables, there are 138 different values of key names and possible values. The key path is contained in a Class constructor that is in charge of initializing the parameters.

Figure 5: Extract of the code containing the path of the Run key – Source: Orange CyberSOC Cyberdefense

In the latter, we also note that the malware creates a scheduled task that is typically used as an execution and persistence tactic (Mitre ATT&CK T1053).

Figure 6: Code extract containing the function creating the scheduled task – Source: Orange CyberSOC Cyberdefense

In this case, we note the use of the /tn parameter which allows naming the task using the String_4 variable. This contains the name of the Run key. The name of the scheduled task, therefore, corresponds to the name of the Run key.

It is possible and recommended to “log” the creation, modification and deletion of scheduled tasks (EventCode 4698 – 4702 – 4699). Searching for one of the 138 key name values in these logs is also a method of detecting Nanocore.

Using the previously obtained tables of values and a simple script, it is thus possible to determine all possible combinations of values. All you have to do is feed the SIEM with these different values and then add a correlation rule.

Once this mechanism is in place, an alert will be generated as soon as a key-value pair corresponding to Nanocore is detected. It is of course possible to add other key-value pairs (associated with other malware for example).

Figure 7: Example of Splunk detection via Sysmon log and security event logs – Source: Orange CyberSOC Cyberdefense

The advantage of this mechanism is that it is simple to implement. In addition, the alert already contains a first qualification of the incident by “mapping” the event to a malware name and type.

This example of detection also reminds us of the importance of parsing and normalization of logs. If the data sources (Sysmon and Windows security event logs) return the same information, the field names are different, hence the importance of standardizing the fields.

Note that in the Splunk case presented, it would have been preferable to use the Endpoint data model and respect the CIM (Common Information Model) when parsing these different logs. The different key-value pairs are filled in the lookup named registry_malware_pattern. The rule raises an alert when it notices the creation of a registry key whose value is present in this file. This mechanism is used because it is easier to maintain.

During incidents of this type, one of the analysts’ tasks is to detect the C2(s). An effective way to do this is to detect beaconing from the infected machine. It is thus necessary, via firewall logs, to calculate the time interval between each IP Source, IP Dest and Port Dest triplet and keep only the source IPs that communicate at regular intervals with an IP Dest-Port Dest couple.

This type of request is quite simple to write in SPL (Search Processing Language) but it is resource consuming. That is why it is better to filter logs from the infected asset only.

Figure 8: Splunk visualization example of beaconing a workstation to a C2 Houdini RAT – Source: Orange CyberSOC Cyberdefense

The graph above illustrates the number of connections to a C2 per time interval for a machine infected with the Houdini RAT. The principle is the same for Nanocore. In this example, the machine beacon every 5-6 seconds.

If the C2 is known to the Threat Intelligence bases, it is also possible that the SIEM will raise an alert for this connection, thus generating two alerts for the same incident. The coupling of the SIEM with an orchestrator (SOAR) makes sense here.

For this type of incident, we can imagine that following the Nanocore alert, the SOAR rolls out a particular playbook depending on the type of malware. In this case, it can execute a beaconing search and thus enrich the alert. It will also be able to “merge” this alert with the IOC detection alert. Thus, the analyst will automatically have all the information needed to characterize the incident.

This example illustrates a technique for quickly identifying the presence of malware. However, this detection mechanism must be used in addition to other rules for several reasons. The main one being that it is difficult and costly to maintain the completeness of such a list. In addition, a mature attacker can customize the malware source code (change values) bypassing this detection mechanism.

Overall, it is recommended to monitor the creation of Run keys which are, in general, still used as persistence techniques (Mitre ATT&CK T1060). For critical assets, such as Active Directory servers, it is recommended to monitor and investigate when creating a Run registry key.

While using the sandbox execution results is a quick and easy way to build a dictionary of malware-signing value-keys, one must remain vigilant. As this note demonstrates, these values are sometimes linked to the system on which the malware is running. As a minimum, to get around this problem, it is preferable to run your sample in two different sandboxes. Reverse engineering is still the most reliable way to obtain this information.