Debug Trap in atapi.sys
PostPosted:Tue Mar 06, 2012 9:00 am
Hello
I got some piece of rootkit I analysed.
Dropper here (clic on white skull, pass infected) : http://www3.malekal.com/malwares/index. ... b526d6abc0
The rootkit patches acpi.sys for reboot survival.
Then it hooks a function somewhere in atapi.sys to hide the patched driver.
What is relevant (gmer log):
My question is the following:
How does the rootkit do to hide the patched driver on the disk?
Someone has an idea of which function it hooks? and how works the 0xCC trap to act as a filter?
I got the atapi.sys base address in memory, launched IDA and found the place where it's supposed to be hooked on the legit driver (I can't get the infected one)
Looks like this:
I got some piece of rootkit I analysed.
Dropper here (clic on white skull, pass infected) : http://www3.malekal.com/malwares/index. ... b526d6abc0
The rootkit patches acpi.sys for reboot survival.
Then it hooks a function somewhere in atapi.sys to hide the patched driver.
What is relevant (gmer log):
---- Kernel code sections - GMER 1.0.15 ----I fixed the atapi hook (code rewrite with Gmer), and the scan become (as expected):
PAGE ntkrnlpa.exe!ZwResumeThread 805CAC22 1 Byte [CC] {INT 3 }
.text atapi.sys F9805852 1 Byte [CC] {INT 3 }
---- Kernel code sections - GMER 1.0.15 ----We can see the acpi.sys patched in memory and on the disk.
PAGE ntkrnlpa.exe!ZwResumeThread 805CAC22 1 Byte [CC] {INT 3 }
.text ACPI.sys F986D300 24 Bytes [00, 00, 00, 00, 00, 00, 8B, ...]
.text ACPI.sys F986D319 7 Bytes [00, 6A, 0C, E8, AD, 13, 01]
.text ACPI.sys F986D321 5 Bytes [56, 68, CA, 06, 87]
.text ACPI.sys F986D327 3 Bytes [68, 5B, 2A]
.text ACPI.sys F986D32C 12 Bytes CALL F987E6CC ACPI.sys (Pilote ACPI pour NT/Microsoft Corporation)
.text ...
.text C:\WINDOWS\system32\drivers\ACPI.sys section is writeable [0xF986D300, 0x1AF00, 0xE8000020]
.rsrc C:\WINDOWS\system32\drivers\ACPI.sys section is executable [0xF9896F00, 0x1C48, 0xE8000040]
.reloc C:\WINDOWS\system32\drivers\ACPI.sys section is executable [0xF9898B80, 0x2506, 0xE8000040]
My question is the following:
How does the rootkit do to hide the patched driver on the disk?
Someone has an idea of which function it hooks? and how works the 0xCC trap to act as a filter?
I got the atapi.sys base address in memory, launched IDA and found the place where it's supposed to be hooked on the legit driver (I can't get the infected one)
Looks like this: