
Mebroot (version from 2008)

Analysis done by Peter Kleissner


  Sector 0      Bootloader, Interrupt 13h Hook Code
  Sector 60     Ntldr Hook Code
  Sector 61     Kernel Code (executed directly after Ntoskrnl)
  Sector 62     Original Master Boot Record Backup

  End of drive  Kernel Driver


Sector 0:
  Size: 512 Bytes
  Location: 7C00h (Bootloader), 9F400h (relocated Interrupt 13h Handler)
  Contains malicious boot code which does some init stuff and hooks int 13h.
  Relocates itself to end of Real Mode Memory (~ 1 MB).
  Contains also code to hook ntldr and to read sector 60 and sector 61 into memory.
  Loads original bootloader from sector 62 and executes it.

  Offset 1B5h: 3 bytes for language message descriptions [unused]
  Offset 440:  Microsofts Disk Signature
  Offset 1BEh: Partition Table
  Offset 510:  Boot Signature

Sector 60:
  Size: 512 Bytes
  Location: 9F600h
  Contains malicious code which is executed by ntldr hook.
  The code is now executed in Protected Mode, and does just hooks ntoskrnl and copies sector 61 directly to after ntoskrnl.

Sector 61:
  Size: 512 Bytes
  Location: 806CDE00h (depends on location of ntoskrnl image), dynamic allocated driver memory
  Contains malicious Kernel Code which is executed by ntoskrnl hook.
  Copies itself to dynamic allocated driver memory.
  Reads and executes the malicious driver from end of disk.
  After execution, deletes malicious driver from memory, and itself from memory.
  Gives control finally back to Windows Kernel.

Sector 62:
  Size: 512 Bytes
  Microsofts original Master Boot Record (the first sector of it), a copy for executing it on startup for perfect stealth.

All other sectors remain zero.
Total size of Master Boot Record: 63 sectors, 7E00h Bytes


Bootloader:

  Initialize registers
  Copying itself to end of memory
  Reading further virus data, sector 60 and sector 61
  Hooking Interrupt 13
  Loading original Microsoft MBR from sector 62 to address 7C00h and execute it
  Int Interrupt 13 hook, check if function is Read Sectors or is Extended Read Sectors, execute request
  Check read buffer for ntldr, to inject jump code to sector 60
  Check read buffer for ntldr, to overwrite code integrity verification code with nops

Kernel Code:

  ntoskrnl.NtOpenFile(&FileHandle, GENERIC_READ | SYNCHRONIZE, &ObjectAttributes, &IoStatusBlock, FILE_SHARE_READ | FILE_SHARE_WRITE, FILE_SYNCHRONOUS_IO_NONALERT)
    opens handle to \??\PhysicalDrive0
  
  ntoskrnl.ExAllocatePool(type 0, 0x58600);
    to retrieve buffer for driver file
  
  ntoskrnl.NtReadFile(FileHandle, NULL, NULL, NULL, &IoStatusBlock, Buffer, Length, ByteOffset, 0);
    read driver from end of partition
  
  ntoskrnl.NtClose(FileHandle);
    unlike the infector file we close opened handles
  
  ntoskrnl.ExAllocatePool(type 0, SizeOfImage);
    get memory for the driver file we will execute later
  
  ...
    we copy and relocate the driver file
  
  ntoskrnl.ExFreePool(File Buffer);
    we give free the read buffer used for NtReadFile
  
  DriverEntry(PSLoadedModuleList, Module Base Address)
    we execute "Banken Virus"
  
  ...
    we erase "Banken Virus" in memory
  
  ntoskrnl.ExFreePool("Banken Virus" memory);
    we give free "Banken Virus" memory (where driver resisted)
  
  ...we delete stage 4 and stage 5 code...
  
    ...and that's it!

Kernel Driver:

  hard wired written to end of drive, sector number is stored on infection time into the MBR code
  in memory on ntoskrnl end of image & 0FFFFFE00h - 512 bytes


Windows Vista is not affected, because 

  - of its different boot mechanism
  - its different boot files, it has bootmgr, winload.exe and winresume.exe (there is no ntldr no more)
  - it loads just signed drivers
  - Kernel Patch Protection will prevent patching ntoskrnl
  - User Account Control will block write access to disk; thus the infector does not work (under right circumstances)


Log entry format:
  00h   WORD    Signature (0005h for normal phishing content, 0007h for uninterpreted raw data captured)
  02h   WORD    Record Type
                  0001h = visited internet domains in username@domain format
                  0002h = basic login capture (for example Windows logon)
                  000Eh = Internet Explorer phishing content
                  0010h = Outlook phishing content
  04h   DWORD   Checksum of data
  08h   WORD    Record Size
                  how many bytes of data (text encoded) will follow

[username_version]

with version stored as BCD encoded decimal value


Analysis from
http://web17.webbpro.de/index.php/analysis-of-sinowal

