I am excited to be speaking at SyScan Singapore 2012 today. SyScan has a reputation for being a high-quality, extremely technical conference, as you can tell by the impressive line-up of speakers. In my presentation, I/O, You Own: Regaining Control of your Disk in the Presence of Bootkits," I will debut operating system research I've been working on for the past few months.
As the title suggests, the research introduces a novel technique to side-step MBR rootkits ("bootkits"). The secret sauce in this technique involves utilizing (note: not tampering with or altering) the crash dump mechanism provided by the Windows operating system in order to read/write to disk. All software that runs on Windows (including forensic tools) uses the "Normal I/O path" to disk in order to save or open files. The Normal I/O Path consists of various drivers (port, miniport, class, file system, volume, partition, and so on) that provide access to the physical hardware. Over the past 20 years, rootkits and bootkits have been infecting various drivers in this Normal I/O path in order to hide malicious files. As I will show in my presentation, the mysterious crash dump mechanism, which is largely undocumented by Microsoft, provides an alternative path to disk (the "Crash Dump I/O Path") that can be used to locate data hidden by rootkits. To my knowledge, there is no malware in the wild today that hooks or alters the crash dump I/O path. That means it is a pristine path which effectively defeats all known disk I/O-hooking rootkits.
The naysayers will be quick to point out the fight against rootkits is a cat-and-mouse game and that within weeks there will be some new rootkit that defeats this technique. While this might be true on some level (every defense mechanism in software can be undermined in some way), I would argue that tampering with the crash dump mechanism presents a unique challenge to rootkit authors. In short, it is much harder to tamper with due to technical restrictions which I will leave up to the rootkit authors to discover. Additionally, infecting the crash dump mechanism presents a conundrum for an attacker. If it is corrupted or rendered inoperable, the attacker's presence would be revealed, because the system would not be able to "blue screen" and generate a crash dump. Either way, I look forward to the debate.
In addition to covering the technique to use the crash dump mechanism outside of the operating system, my presentation will cover details of how the crash dump process itself works, from Windows 2000 up to Windows 7. This material is a result of weeks reversing the Windows kernel and related crash dump drivers, as well as port and miniport drivers for SCSI and IDE drives.
I hope this post has piqued your interest. Stay tuned to the M-unition blog for links to the slides and whitepaper, which will be released after the conference.