This month we added Win32/Necurs to the Microsoft Malicious Software Removal Tool (MSRT). In a previous blog about Necurs I outlined the family's prevalence and the techniques it uses to execute its payload. In this blog, I will discuss the Necurs rootkit components Trojan:WinNT/Necurs.A and Trojan:Win64/Necurs.A in greater depth.
These Necurs rootkit components are sophisticated drivers that try to block security products during every stage of Windows startup.
It’s important to note that Microsoft security products can detect and remove these rootkit components, as well as other threats within the Necurs family.
Figure 1 illustrates the stages of the startup process where a security product could launch its protection, and how Necurs tries block these efforts. We’ll elaborate more on this below.
Figure 1: Necurs attempts to interfere with security products that could block it during startup
AM ELAM driver stage
The Early Launch Antimalware (ELAM) driver is a new antimalware feature introduced in Windows 8. It allows the antimalware driver to launch before any third-party software, and is therefore able to detect some malware in the boot process and prevent it from initializing. However, because the driver launches at the very early boot stage, and considering its efficiency and dependencies, the security check is restricted.
Necurs signer information is auto-generated with a random signer name. This means there isn't meaningful information from the certificate that the ELAM driver can use. The registry entry name is also generated with a random name. The file is polymorphically encrypted, which results in variable hashes. These techniques prevent ELAM from blocking it effectively.
AM boot-start driver stage
The boot-start drivers are loaded after ELAM. Antimalware drivers can be also launched at this stage. It is important to note that there is also an internal loading priority order for boot-start drivers. Necurs registers itself as a member of one of the top priority loading groups, meaning it can be typically loaded before any boot-start type antimalware driver.
AM system/other start type driver stage
When the Necurs driver is installed for the first time it immediately takes a system running driver snapshot and puts the drivers that it considers allowable into a whitelist. A driver blacklist is also used to help create this whitelist. The logic is:
- Step 1: If the driver file name is not in the blacklist, continue to check step 2.
- Step 2: If the driver security section in memory doesn’t contain certain key words in the blacklist, put into whitelist.
The blacklist contains most of the major security products that I mentioned in my previous blog.
Once the filtering is done, the whitelist is saved in a hidden registry entry as an MD5 list for each driver. During system startup, the hidden registry is loaded and Necurs blocks any driver that isn’t in the whitelist from loading.
By doing this any antimalware drivers that run after Necurs are terminated - even if they contain a random name, or deploy strong self-protection functions. The method Necurs uses to monitor the loading driver is notable. Boot-start and other start type drivers are treated separately as follows:
- Boot-start drivers: Necurs retrieves all the boot-start driver information from a global system variable in memory which is generated by osloader.
- System-start and other drivers: An image-notify routine is installed for monitoring all the drivers before they start.
In order to protect this hidden whitelist registry entry from being deleted or modified by antimalware software Necurs sets a registry-callback routine to monitor the registry access behavior. Any request to open and remove the malware registry is blocked. Even if antimalware software can bypass this trick, the whitelist is not easy to touch because if it’s wiped it can result in a Blue Screen of Death (BSOD) when the system critical driver is also blocked by Necurs during system startup. Adding an antimalware driver into the list is also difficult. The MD5 value is customized based on certain areas of the image in memory chosen by Necurs. That means simply calculating the file-based MD5 won’t work. The MD5 location also needs to be calculated by customized sorting algorithm. In that way, simply adding any MD5 at start or end of the list would also trigger BSOD.
Necurs rootkits are widely used in the wild by lot of prevalent malware as a self-protection component. You can read more technical details for these threats in the Win32/Necurs family description.
To help stay protected we recommend you to install an up-to-date, real-time protection security product such as Microsoft Security Essentials.
Tim Liu
MMPC