“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?

bgrill@seclab.tuwien.ac.at

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