Okay, we already know about Necurs, just remind it interesting features:
If the driver is blacklisted, Necurs patches it entry point with two instructions, so DriverEntry after that returns STATUS_UNSUCCESSFULL and IO manager not load this driver.
Collection of information into white list rootkit performs on stage of initialization. Rootkit performs scanning of \drivers directory and look for drivers not included into blacklist.
Also it walks by services registry key and adds drivers into these lists.
To avoid misunderstanding it adds loaders into these lists.
Ways of drivers entry point modifications looks like:
Necurs also blocks registry operations for own service key. So, any attempt to access to key fails. It possible with help of http://msdn.microsoft.com/ru-ru/library/windows/hardware/ff545879(v=vs.85).aspx
Similar situation with file system. Necurs attaches his device object to volume and tracks all FS operation, so rootkit body on volume is unaccessible.
Another interesting feature of Necurs - possibility of start before ALL drivers in the system [including boot bus extender drivers].
But on clean system we have another picture:
Ok, all right.
The conclusion is obvious: Necurs adds itself into "Boot Bus Extender" group and modifies priority ("Tag") of all drivers from this group (increases their Tag numbers by one, +1). Detailed about priority of drivers load, look http://support.microsoft.com/kb/103000
Summary:
Necurs also registers callback for tracking operations about handle creation for process with help of ObRegisterCallback. API - http://msdn.microsoft.com/en-us/library/windows/hardware/ff558692(v=vs.85).aspx
From this callback rootkit performs modification of original final desired access for the handle in special cases of handle opening.
Mission of NtOpenProcessHook consists in blocking open handle operation for process which rootkit considers as trusted.
According to Microsoft Malware Protection Center (MMPC) Necurs found on more than 83,000 machines and Microsoft report calls rootkit a "prevalent threat". This is not surprising after disclosure of the threat, it becomes clear why this is so.
http://www.darkreading.com/risk-management/167901115/security/attacks-breaches/240144203/necurs-rootkit-spreading-quickly-microsoft-warns.html
http://blogs.technet.com/b/mmpc/archive/2012/12/07/unexpected-reboot-necurs.aspx
Fingerprints:
x32 version:
SHA256:742a3c8c0a3601af29daffb966e947334d4f20501e5568b9c9fbf4c3526b4b84
SHA1:30f63b8cae41a97456a82131c4577a2020697b89
MD5:0907292986e05a8752bc1863556d229e
File size:59776 bytes
x64 version:
SHA256:b3fea8183670ecf6150325f05aed28dfa27d7c6d2c1007808661f97c27fd7e1e
SHA1:d69b06801a8378e8c9ac8b369cb9e14ef8c8d479
MD5:39b447e293979ac7259d4d9a2711c9a0
File size:75720 bytes
- Highly difficult in terms of removal from infected system;
- Targeted to blocking drivers around 30 AV products [and 130 drivers in total];
- Also targeted to x64 platform [has x64 version of driver];
- Driver has obfuscated relocatable code;
- Provides for itself the earliest start in the system [before all AV or Anti-malware drivers and system drivers];
- Has it's own PE-loader with features of module relocation and IAT tuning for creation a complete copy of working driver;
- Three types of black list: checking version info, special code signatures and drivers names.
I already wrote about detection of this rootkit by various anti-rootkits here http://artemonsecurity.blogspot.ru/2011/11/necurs-rootkit-detection.html. In that post also listed symptoms of infection and various kernel anomalies. Today we'll talk about Necurs more detail.
First of all - black list and how it's implemented. According to list, which is subject to examination by the rootkit, it includes about 30 various AV products (checking via version info), and 130 various drivers (checking via image names comparison). Full list of vendors avalaible here - http://pastebin.com/BznsXcD2 and list of drivers here - http://pastebin.com/ahTezZ1d.
Before you start the static analysis you should retrieve decrypted version of driver. In normal encrypted state it looks like this:
To be convinced that rootkit is active, you need to check presence of NtSecureSys device object.
On the next step need to dump it decrypted body from memory with help of anti-rootkit or windbg. Ok, let's do it with windbg. Necurs sets some hooks to SSDT and this is one of the start point for dumping it image from memory.
Next we can dump it from memory.
Instead !pool command you can use search for MZ header in reverse order for retrieving start of decrypted copy:
s 822bbe2b L-10000 'M' 'Z'
Decrypted driver:
Start point of black list checks - LoadImageNotifyRoutine function. Detailed info about this feature http://msdn.microsoft.com/en-us/library/windows/hardware/ff559957(v=vs.85).aspx. This callback is called every time when new driver [or user mode image] was loaded in system [or in process].
This function contains all types of blacklist checks. For example, on this screenshot below is represented check via vendors names in version info.
If the driver is blacklisted, Necurs patches it entry point with two instructions, so DriverEntry after that returns STATUS_UNSUCCESSFULL and IO manager not load this driver.
Rootkit also contains two special white lists of drivers that not included into black list.
Collection of information into white list rootkit performs on stage of initialization. Rootkit performs scanning of \drivers directory and look for drivers not included into blacklist.
Also it walks by services registry key and adds drivers into these lists.
To avoid misunderstanding it adds loaders into these lists.
Ways of drivers entry point modifications looks like:
Necurs also blocks registry operations for own service key. So, any attempt to access to key fails. It possible with help of http://msdn.microsoft.com/ru-ru/library/windows/hardware/ff545879(v=vs.85).aspx
Similar situation with file system. Necurs attaches his device object to volume and tracks all FS operation, so rootkit body on volume is unaccessible.
Another interesting feature of Necurs - possibility of start before ALL drivers in the system [including boot bus extender drivers].
But on clean system we have another picture:
Ok, all right.
The conclusion is obvious: Necurs adds itself into "Boot Bus Extender" group and modifies priority ("Tag") of all drivers from this group (increases their Tag numbers by one, +1). Detailed about priority of drivers load, look http://support.microsoft.com/kb/103000
Summary:
Necurs also registers callback for tracking operations about handle creation for process with help of ObRegisterCallback. API - http://msdn.microsoft.com/en-us/library/windows/hardware/ff558692(v=vs.85).aspx
From this callback rootkit performs modification of original final desired access for the handle in special cases of handle opening.
Mission of NtOpenProcessHook consists in blocking open handle operation for process which rootkit considers as trusted.
According to Microsoft Malware Protection Center (MMPC) Necurs found on more than 83,000 machines and Microsoft report calls rootkit a "prevalent threat". This is not surprising after disclosure of the threat, it becomes clear why this is so.
http://www.darkreading.com/risk-management/167901115/security/attacks-breaches/240144203/necurs-rootkit-spreading-quickly-microsoft-warns.html
http://blogs.technet.com/b/mmpc/archive/2012/12/07/unexpected-reboot-necurs.aspx
Fingerprints:
x32 version:
SHA256:742a3c8c0a3601af29daffb966e947334d4f20501e5568b9c9fbf4c3526b4b84
SHA1:30f63b8cae41a97456a82131c4577a2020697b89
MD5:0907292986e05a8752bc1863556d229e
File size:59776 bytes
x64 version:
SHA256:b3fea8183670ecf6150325f05aed28dfa27d7c6d2c1007808661f97c27fd7e1e
SHA1:d69b06801a8378e8c9ac8b369cb9e14ef8c8d479
MD5:39b447e293979ac7259d4d9a2711c9a0
File size:75720 bytes