Darkmegi was in the news a couple of months back; it was the first known threat to be delivered through the Microsoft vulnerability CVE-2012-0003 (MIDI Remote Code Execution Vulnerability) exploitation. More recently Darkmegi has been seen in CVE-2011-3544 (Java Runtime Remote Code Execution) drive-by attacks as part of the Gong Da Pack exploit kit. Darkmegi uses a kernel rootkit component to maintain a stronghold on infected systems.
Hook Installation
It’s common for rootkits to deny read and/or delete access to its files and/or registry keys, and Darkmegi is no exception. The Trojan drops its kernel driver to com32.sys in the Drivers directory. This rootkit drops a usermode component, com32.dll, which gets injected into explorer.exe and iexplore.exe. It also hooks the Dispatch table of ntfs.sys [IRP_MJ_CLOSE, IRP_MJ_CREATE, IRP_MJ_DEVICE_CONTROL] and fastfat.sys to prevent applications from reading (or scanning) the com32.dll and com32.sys files.
Hook Impact
Once the rootkit has compromised the operating system, attempts to copy or read protected files are rejected.
Attempting to copy rootkit driver to another directory.
Attempting to open rootkit driver.
No Malware Here
Another trick this Trojan uses is to pad its malware files with garbage data, around 25MB of garbage data! This is surely an attempt to look more legitimate than your typical malware, which takes less than 1MB. Indeed, less than 0.03% of known malware is greater than 25MB. This is another example of how malware authors continue to change their tactics to evade a file-centric view of security.
Distribution of 79 million malware file sizes.
But for all Darkmegi does, it does not hide its file locations.
Half-Stealth
So why does a malware author go to the trouble of creating a rootkit and yet not hide the files he or she aims to protect? One reason is that some antirootkit tools compare a list of files returned by the Windows API against a tool-created list created from raw NTFS scanning. Any discrepancies are presented as suspicious.
I wanted to see how various on-demand antirootkit tools fared against Darkmegi running on Windows 7, but alas most tools still haven’t been updated to support Windows 7, including some of the most popular (even Microsoft’s RootkitRevealer).
I did find that one tool was able to identify the usermode component protected by the kernel driver as infected. However, the tool prompted me to reboot to complete the repair. After two reboots (the first hung the system), I read “Cleanup completed”; however, the undetected kernel driver simply restored and reinjected the usermode component.
Another post-infection tool was able to identify the two Darkmegi malicious executables, but when I chose to remove them the tool told me it was not recommended–as it could cause system problems. Indeed, after proceeding anyway, the system went into a BSOD loop, even in Safe Mode.
With no success under Windows 7, I decided to try diffing tools on an infected Windows XP system. That test suggested that the trick of allowing files to be listed, but not read, would evade some tools.
Obviously running rootkit removal tools after the fact is not ideal (unless one is doing forensics or incident response). It’s much better to identify them before they can compromise the OS.
Caught In The Act
Through real-time kernel-memory monitoring, Deep Defender can block malicious events, and blacklist and delete the offending rootkit.
Deep Defender catching Darkmegi during installation.
With the rootkit removed, or even just neutralized, the usermode component no longer loads and is also neutered.