MBR Stealth Rootkit / Sinowal
This is an amazing solution - I needed this 3 weeks ago!
Detection appears to have improved (log entry appearing in message #5).
Code:
Infected copy of c:\windows\system32\DRIVERS\nvatabus.sys was found and disinfected
The key to the solution appears to be CFscript and invoking mbr.exe from combofx. This prevents the re-infection.
The first signs pointed to rootkit infection referred to as MBR Stealth or Sinowal or Mebroot, as shown by log entry from message #3.
Code:
detected MBR rootkit hooks:
\Driver\Disk -> CLASSPNP.SYS @ 0xba10cf28
\Driver\ACPI -> ACPI.sys @ 0xb9f7fcb8
\Driver\atapi -> atapi.sys @ 0xb9f11852
IoDeviceObjectType -> DeleteProcedure -> ntkrnlpa.exe @ 0x805836a8
ParseProcedure -> ntkrnlpa.exe @ 0x805827e8
\Device\Harddisk0\DR0 -> DeleteProcedure -> ntkrnlpa.exe @ 0x805836a8
ParseProcedure -> ntkrnlpa.exe @ 0x805827e8
NDIS: Broadcom NetXtreme 57xx Gigabit Controller -> SendCompleteHandler -> NDIS.sys @ 0xb9decbb0
PacketIndicateHandler -> NDIS.sys @ 0xb9df9a21
SendHandler -> NDIS.sys @ 0xb9dd787b
Is there any residual problem left behind when it comes to the mirror copy of the directory structures? I believe that this infection stole disk allocation by marking blocks used to hide parts of the payload.
<Reasoning for the question.>
I am speaking of the MFT. A mirror copy is kept. For the variety of rootkit I encountered, I felt that it used free area of the hard drive to hide code called by the hooked code. I clearly saw sectors in track 0 were part of the payload. Supposedly the rootkit hid code in free space of the hard drive to overwrite drivers . From this I infer that the malware could only protect this area by showing its allocation in the MFT.
Background:
Before proceeding with disinfecting: chkdsk infected drive; clone the drive; and verify cloned drive is bootable.
Method 1: Ghost9 clone produces a image copy of infected drive. Restoring image to clone drive reports "mismatch" error. Cloned drive is bootable. Demote clone to slave; chkdsk finds no errors.
Method 2: XXclone produces a file copy version of infected drive. No errors reported. Cloned drive is not bootable. Demote clone to slave; chkdsk finds lost blocks; creates file0000. In theory this method does not copy a file or folder if is absent from the directory structures. XXclone was able to clone (a bootable copy) an uninfected version.
Method 3: Partition Magic 8 checks drive for errors and reports "mismatch" errors.
General: I could not verify what the defect was that was reported as "mismatch". XXclone chkdsk error makes no sense since file copy makes changes to MFT; in this case MFT started clean and changes to MFT correspond to files successfully copied to the drive.
Observation: Even with a clean track 0, the corrupted driver(s) was still able to plant its hooks. From my perspective, this gave weight to code hidden in free space. Other utilities (Ghost9, Partition Magic, XXclone) found discrepancies with disk structure and/or allocation.