Necurs is a kernel mode driver best known at the moment for being used by Gameover Zeus (GOZ) to hinder attempts to detect and remove the malware. The technical details of the Necurs driver have already been exhaustively covered in a writeup by Peter Ferrie, but during our analysis we came across some interesting details of Necur's gradual uptake as a "crimeware for sale" module.
We saw the earliest version of the Necurs driver as a standalone malware in May 2011; it didn't become associated with another malware until early 2012, when we observed it being dropped by a trojan-downloader, also called Necurs since it was the only user mode component the driver was seen with at the time.
It was only in February 2014 that we saw the driver included in GOZ, which raised its profile considerably. The GOZ botnet is estimated to run into hundreds of thousands of infections and it is mainly used for online banking theft.
Before Necurs was incorporated, GOZ had been operating without an associated driver. Its addition to the botnet's operations was rather curious, as it occurred about 2.5 months before the United States' Federal Bureau of Investigations (FBI) started their takedown operations.
The Necurs driver's design is interesting in that it doesn't require any changes by the authors for use by a third party. The dropper code used by both the Necurs trojan-downloader and GOZ to create and install the Necurs driver is the same, so the author has provided everything needed for the driver to be taken into use.
The dropper code has been written in the style of shellcode, so it can be executed as is, and as such it can be easily included into the source code of whatever malware will end up using the driver.
No source code needs to be given to the customers, and the driver can be easily configured to protect any executable just by correctly setting its service key values. The name of the file to be protected is taken from the DisplayName value of the driver's service key.
The Necurs driver also includes a control interface that allows the user mode component to give commands to the driver, regardless of the actual family. Controlling is done with specific IRP_MJ_DEVICE_CONTROL requests, which can be sent with the DeviceIoControl user-mode API.
The first control code the user-mode component must send is 0x220000; on receiving this, the Necurs driver will store the handle of the process that sent that request as the process that will be able to control the driver. This command is only accepted once per bootup.
To be stored as the controlling process, the IRP.AssociatedIrp.SystemBuffer for that request must be 12-bytes long and adhere to two checks:
• first_dword ^ 0xdeadc0de == second_dword • first_dword ^ third_dword == pid of process that sends the request
An additional check is that the name of the process that sends the control code must be the same as the DisplayName field in the Necurs service key. This prevents unwanted processes from sending the commands, as any kind of access to a file with that name will be prevented by the driver.
Necurs listens for a total of 15 different IoControlCodes, including:
• 0x220000 register process as Necurs master • 0x22000c get Necurs driver path • 0x220010 get Necurs service key name • 0x220018 update Necurs driver (driver file content is replaced by data in IRP.AssociatedIrp.SystemBuffer) • 0x22001c uninstall Necurs driver • 0x220028 terminate process by process identifier • 0x22002c terminate process by name
The code for calling all of the commands is included in the dropper code that also handles the installation of the driver.
These features essentially make the Necurs driver well suited for resale and use by third parties, as is evident by its use in the GOZ trojan. Though the current takedown effort against the botnet is likely to put a crimp in the operations of Necurs' biggest "customer", at least for a while.
We detect Necurs driver variants as Rootkit.Necurs.
