[DIMVA2015] "Nice Boots!" - A Large-Scale Analysis of Bootkits and New Ways to Stop Them
Transcript of [DIMVA2015] "Nice Boots!" - A Large-Scale Analysis of Bootkits and New Ways to Stop Them
“Nice Boots!” - A Large-Scale Analysis of Bootkits and New Ways to Stop Them
Bernhard Grill, Andrei Bacs, Christian Platzer, Herbert Bos
Vienna University of Technology (Austria), VU University Amsterdam (Netherlands), SBA Research (Austria)
Outline
● Background (boot process, bootkit)
● Large-scale bootkit analysis
● Detecting & preventing infections
● Future bootkit evolution directions
● Conclusion
Outline
● Background (boot process, bootkit)
● Large-scale bootkit analysis
● Detecting & preventing infections
● Future bootkit evolution directions
● Conclusion
Background – Boot Process
● The boot process for BIOS based systems work as follows:
– MBR (Master Boot Record)– VBR (Volume Boot Record)– BL (Bootloader)
Background – What is a Bootkit?
● Bootkits (BKs) are a class of malware specifically designed to interfere with the operating system’s (OS) boot process in order to run malicious code prior kernel execution
● Focus on Master Boot Record (MBR) / Volume Boot Record (VBR) / bootloader (BL) based bootkits → dominating types
Background – How does a bootkit work?
● Boot process for a benign system
– BIOS → Master Boot Record (MBR) → Volume Boot Record (VBR) → Bootloader (BL) → OS Kernel
● Boot process with an infected bootloader
Background – Dark Regions
● Dark Regions (DR) are disk regions not utilized by file system
● Some only used during boot process (e.g. MBR) others not used at all (e.g. gaps between partitions)
● DRs often utilized to hide additional data / code, e.g. configs, DLLs to inject in kernel
Background – Interrupt Hooking
● Bootkits often hook the interrupt vector table during the boot process in x86 real mode
● To regain control after the kernel is loaded in memory by the bootloader, but before the kernel executes
● So the bootkit can infect the kernel before it runs
Outline
● Background (boot process, bootkit)
● Large-scale bootkit analysis
● Detecting & preventing infections
● Future bootkit evolution directions
● Conclusion
Large-scale Bootkit Analysis
● Built a bootkit detection & analysis environment
● Virtualized malware sandboxes with focuses on bootkits based on QEMU
● Malware samples are executed within the sandbox
– Observed during installation time
– And during boot time● In order to gain a detailed picture on the bootkit's
installation and boot behavior
Large-scale Bootkit Analysis – Experimental Setup
● Dynamic analysis with 2,424 malware samples
● 29 different families
● 8 years (2006 - 2014)
● Win XP SP3 & Win7 (both x86)
● No Internet access
● Deactivated defensive mechanisms (firewall, UAC)
● Each sample monitored for 2 minutes after execution
Large-scale Bootkit Analysis - Some Results
Exploited dark regions as data storage locations from successful infections
Every analyzed bootkit writes to at least one dark region!
Initial infection vectors from successful infections
Large-scale Bootkit Analysis - Some Results
Exploited interrupt hooks from successful infections
Very interesting, since our initial assumption was that interrupt hooking is mandatory for all bootkits! → more details in a few slides
Large-scale Bootkit Analysis - Some Results (Historic View)
Overview on interrupt hooking evolution
Overview on initial infection vector evolution
Outline
● Background (boot process, bootkit)
● Large-scale bootkit analysis
● Detecting infections
● Future bootkit evolution directions
● Conclusion
Detecting Bootkit Infections
● During malware infection:● Dark region modifications: detect disk writes outside
the file system
● During boot process:● Dark region reads: detect suspicious disk reads (dark
regions)● Interrupt hooks: detect installed interrupt hooks● Reuse existing code: detect existing code re-usage
(jumps to 0000h:7c00h)
Detection Results
● Dark region read and write heuristic detects all bootkits!
● Since every bootkit read additional data (e.g. config, code) from a hidden store in a dark region
● Interrupt hooks perform also very well
Some Interesting Findings
● “Reuse existing code” fails whenever the bootloader is infected
● 0.5% do not perform interrupt hooking!
● A few Mybios samples (in 2011) and a few Plite samples (in 2014) do not hook interrupts or patch the kernel in memory
● Instead they replace the explorer.exe on disk with a malicious one [4]
● Technique did not establish itself (yet?) → Problem: suspicious traces within the file system (e.g. anti virus might trigger)
Preventing Bootkit Infections in Virtualized Environments
● Our solution is implemented directly in QEMU
● Also suitable for Bochs, VMware, VirtualBox,...● Based on observation that each bootkit samples writes
to at least one dark region (as already discussed)
● Prevent any writes to dark regions
● To prohibit initial infection vector and other data persistence
● No infections anymore while prevention technique in place
Outline
● Background (boot process, bootkit)
● Large-scale bootkit analysis
● Detecting & preventing infections
● Future bootkit evolution directions
● Conclusion
Potential Future Bootkit Evolution Directions
● Shift towards exploiting the bootloader stage (a little stealthier)
● Diversification of dark region utilization, e.g. meta data, file slack space, alternate data streams
● In general possible, but might get very hard to implement● BIOS / UEFI based bootkits
● Complex to implement, might be interesting for very targeted attacks, e.g. GrayFish (Equation Group) [3]
● VM based bootkits, e.g. applying SubVirt [2]
● Shift whole system into a VM
Outline
● Background (boot process, bootkit)
● Large-scale bootkit analysis
● Detecting & preventing infections
● Future bootkit evolution directions
● Conclusion
Conclusion
● Bootkit techniques & background infos
● Performed large-scale bootkit analysis
● How to detect bootkit infections based on large-scale analysis
● Future bootkit evolution directions
Questions?
Thank you very much for your attention!
References
● C. Rossow, C. J. Dietrich, C. Kreibich, C. Grier, V. Paxson, N. Pohlmann, H. Bos, and M. van Steen. Prudent Practices for Designing Malware Experiments: Status Quo and Outlook . In IEEE S&P, 2012.
● S. T. King, P. M. Chen, Y.-M. Wang, C. Verbowski, H. J. Wang, and J. R. Lorch. Subvirt: Implementing malware with virtual machines. In IEEE S&P, 2006.
● Kaspersky Lab. Equation group: Questions and answers, 2015. https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf
● Plite Bootkit http://labs.bitdefender.com/2012/05/plite-rootkit-spies-on-gamers/
● B. Grill, A. Bacs, C. Platzer, & H. Bos. “Nice Boots!” - A Large-Scale Analysis of Bootkits and New Ways to Stop Them. In DIMVA, 2015.
Discussion
● No support for UEFI / BIOS based bootkits (yet?)
● No Anti-VM detection
● No Anti-Analysis detection
Large-scale Bootkit Analysis – Some Definitions
● Bootkit like behavior are samples writing to any dark region
● Bootkit detected are samples writing either the MBR, VBR or bootloader
● Working infections are samples satisfying bootkit detected definition and the system reboots successfully after infection
● Successful infection rate is the rate (in %) between the number of samples with bootkit like behavior and working infections
Large-scale Bootkit Analysis - Some Results
Experimental sample set’s operability on different operating systems
Comparing analysis’ outcome with and without Internet access on XP
Prevention – Secure Boot
● Requires Windows 8 and UEFI 2.2
● Afaik does not prevent infection but its execution
● Highly controversial since MS controls runnable software (e.g. two Linux providers were removed recently)
http://www.pcworld.com/article/248342/windows_8_secure_boot_the_controversy_continues.html