The new book from Matrosov, Rodionov and Bratus gave me some amazing insights into reverse engineering and malware mitigation. What a great read!
This year, I’ve been voraciously reading technical material on UEFI, Linux, and the Windows kernel to support my MinnowBoard Chronicles blog series. Among my early purchases were:
Harnessing the UEFI Shell
Rothman, Zimmer and Lewis
Practical Reverse Engineering
Dang, Gazet and Bachaalany
Windows Internals, Part 1 and 2: 6th Edition
Russinovich, Solomon and Ionescu
Linux Kernel Development
Love
The IDA Pro Book
Eagle
For those that do follow the Chronicles, you’ll know that as of the time of this writing (mid-August), I’ve done a fair bit of research on UEFI, have started digging into the Linux kernel, and am planning to install Windows 10 on my MinnowBoard. At this pace, the MinnowBoard Chronicles should run through to at least the end of 2017! Keep in mind, though, that I have a full-time job; and this research, learning and writing is slightly orthogonal to my day job. But, it’s a great hobby!
As my knowledge of OS design and debugging has deepened, I’ve also gotten interested in the whole area of reverse engineering and malware mitigation. Certainly, cybersecurity has been in the news lately, with recent ransomware attacks such as WannaCry getting a lot of media attention. And this is a growing, dynamic field. But, more broadly, I’m fascinated by the questions surrounding our assurance that the platforms we use are secure. Or, to put it another way, what technology is used to create malware, and how can this same technology be used to detect, protect and mediate against it? It is a fascinating question. This is the topic of Rootkits and Bootkits: Reversing Modern Malware and Next Generation Threats by Alex Matrosov, Eugene Rodionov and Sergey Bratus.
I became aware of this book after reviewing the slides from Matrosov’s Black Hat USA 2017 slide deck, Betraying the BIOS: Where the Guardians of the BIOS are Failing. I didn’t get to attend Black Hat USA this year, and a review of the slides is outside the scope of this blog, but it also makes for some interesting reading; highly recommended.
Rootkits and Bootkits is published by NoStarch Press, an excellent resource for geeks like myself. They also have an offering they call “Early Access”, that allows for early pre-purchase of pre-release copies in electronic form of upcoming books. Rootkits and Bootkits won’t be available in final published form until October of 2017, but you can get an early incomplete copy in PDF form now. So that’s what I did: I’ll get the final eBook and printed copy in October, but I have an early PDF version now dated June 12, 2017. All in all, the book will have 19 chapters, of which 14 are in my Early Access copy. And the material is excellent: it is extremely technical, requiring a lot of depth in Microsoft Windows architecture, x86 assembly language, and other topics to follow along; but at the same time it has a nice chronological “telling a story” appeal as it describes how malware came about over the years, and how it is defended against.
Having a couple of flights to take in the past week, I got a chance to get some heavy reading in. Here’s a spot review of some of the more fascinating chapters:
Chapter 2, What’s in a Rootkit: The TDL3 Case Study, introduces how the TDL3 malware infects a system, and how it subverts specific OS interfaces and mechanisms in order to survive and remain undetected. This is older malware, first seen in 2010; it only works on older 32-bit systems, as newer 64-bit kernel-mode code signing (“PatchGuard”) prevents its from loading its code into the Windows kernel. But studying its architecture gives a lot of insight into not only how malware is created, but also how it is distributed, how it creates a hidden file system, and how it intercepts hard drive read/write operations to protect itself.
One fascinating insight from this chapter was how bad actors will re-use, to the fullest extent possible, standard Windows interfaces to improve the reliability of the rootkit. This makes their code less susceptible to detection and provides more stability to the malcode. They want it to “blend in”, as it were.
Chapter 3, The Festi Rootkit: The Most Advanced Spam Bot, describes how this particular rootkit was used in cybercrime. In 2011, a payment processing company named Assist was bidding for a contract with Aeroflot, Russia’s largest airline. A few weeks before Aeroflot were due to confirm Assist as its vendor, cybercriminals launched a massive DDoS attack against the company. The attack, carried out using the Festi botnet, rendered the processing system unusable for an extended period of time, and eventually forced Aeroflot to select another supplier.
One highlight of this chapter, for me, was in learning how this rootkit established “secret” communications back to Command & Control (C&C, or C2) centers, for downloading of malicious plug-ins.
Another fascinating aspect of Festi is that it also checked for the presence of a kernel debugger in the system by examining the KdDebuggerEnabled variable exported from the operating system kernel-image. If a system debugger is attached to the operating system this variable contains the value TRUE, and contains FALSE otherwise. So, if a debugger is detected, Festi actively counteracts the system debugger by periodically zeroing the debugging registers dr0 through dr3. These registers are used to store addresses for breakpoints, and removing the hardware breakpoints hinders the debugging process, making the rootkit more stealthy. The code for zeroing out the registers is quite simple:
mov dr0, 0
mov dr1, 0
mov dr2, 0
mov dr3, 0
This strategy appears to be quite commonly used by newer generations of malware.
Of course, Festi would not have been able to detect SourcePoint; it only looks for an agent-based debugger. A JTAG-based debugger working out-of-band would be immune to detection via this mechanism. Malware can still zero out debug registers to avoid detection, but this can be sensed and mitigated against by JTAG-based debuggers.
Chapter 4, Bootkit History and Background, makes for a fascinating historical look at how malicious code now typically burrows deeper down closer to the hardware root of trust, infecting the boot records of platforms, so they can be “trusted” by the operating system as it loads.
This fourth chapter sets the stage for the remaining Bootkit chapters within the book, that covers incredibly technically informative sections on how the OS boot process works, what Kernel-Mode Signing Policy and Early-Launch Anti-Malware (ELAM) can and cannot do, how MBR/VBR work and how they can be infected, how to use IDA Pro for bootkit static analysis, and so on.
The chapters that have yet to be published include additional information on UEFI Firmware Vulnerabilities, and on using CHIPSEC for BIOS/UEFI forensics. I’m really looking forward to reading those new chapters when they arrive from NoStarch Press.
One key takeaway I had from reading this tome was that malware designers are having to burrow deeper into the platform as operating system protections, malware and virus checkers have become more sophisticated. New and creative means are being sought to infect the boot process, processor and chipset configurations; as well of course as how to defend them. Technologies like Secure Boot, Trusted Boot, and Boot Guard are being used to secure platforms at a very low level. And frameworks such as the Python-based CHIPSEC, that analyze the security of platforms, including their hardware, BIOS, and platform configuration, are being actively developed and open-sourced. Incidentally, a great overview of CHIPSEC (as well as pointers to additional technical materials can be found at Basic Input/Output: A Tour of CHIPSEC.
JTAG, often touted as a platform vulnerability, has that double-edged sword aspect of also being a very powerful tool for malware detection and analysis. I’ve written a couple of blogs on this topic, at The MinnowBoard Chronicles Episode 18: Reverse-Engineering Code Execution and The Minnowboard Chronicles Episode 14: Poking around SecCore in UEFI. Further, SourcePoint complements the static analysis capability of IDA Pro, by using the various trace features within Intel silicon, a portion of which are described in my blog The MinnowBoard Chronicles Episode 11: Using Instruction Trace.
A really great description of the use of dynamic trace analysis is in our eBook, Firmware Debug with Intel Embedded Trace Tools (note: requires registration). Intel Architecture Event Trace (AET) in particular can trap on MSR read/writes, interrupts, IN/OUTs, and other valuable signals of errant code; and when combined with a hardware-assisted debugger, make it an essential tool in the reverse engineer’s toolkit.
Finally, to wrap up, one of the best parts of the Rootkits and Bootkits book was the cover, which is what attracted me to it in the first place. A very interesting, well-done piece of art:
