This document describes a technique for automatically discovering rootkits by comparing kernel memory snapshots before and after running potentially malicious drivers or executables. The technique was implemented in a system that runs samples in a virtual machine, extracts kernel memory contents, analyzes differences to identify suspicious modifications, and generates signatures of common rootkit behaviors. The system was tested on high-profile rootkits, driver samples, and random executables. It was able to identify kernel modifications in over 80% of malicious samples and detect behaviors of known rootkits without relying on file contents or known signatures. The authors conclude the technique is effective but note areas for future work, such as analyzing additional kernel structures and detecting more advanced techniques like DKOM or usermode rootkits

1. Unveilingthekernel:Rootkitdiscovery
usingselectiveautomatedkernelmemory
differencing
Ahmed Zaki and Benjamin Humphrey

2. Agenda
2
• Objective and method
• System design and implementation
• Running drivers
• Data extraction
• Processing the data
• Reporting and signatures
• And the result is …
• Experiment A: High profile rootkits
• Experiment B: Driver files
• Experiment C: Random set of PE files
• Conclusion
• Future work

3. What is the objective?
• Automate the process of finding samples that
exhibit kernelmode behaviour
• List the modifications made to the kernel
• Identify the maliciousness of specific
modifications
• Import that data into other systems
3

4. How do we automate the process?
•Use existing tools
•Build our own
•Using anti-rootkit tools
•Using a custom diff based solution
4

5. Bird’s eye view
5
HOST
Auxiliary module
Processing module
Django templates
GUEST
Analysis Packages
Auxiliary module
Signatures

6. Running Driver files
6
Guest VM
Is Driver
file ?
Driver Analysis
Package
Other Analysis
package
(Servicename | StartType | ServiceType | LoadMode)
“Register service using scm
If not loadmode then:
start service using NTLoadDriver
Else:
start service using loadmode option
If not service is running:
report FAIL ! “

7. Usage of the SophosAV Engine
With the SAV engine we get:
• Existing software that has a presence in the kernel
• The ability to examine/dump areas of kernel memory
• The ability to write to a log file
NOTE: Due to modular design we don’t need to use the
Sophos AV engine.
7

8. Examining the kernel
Drivers Modules SSDT
IDT Callbacks
Disk
Information
What areas are we looking at?
8

9. Processing the data
9
{ "mbr" : { }, "drivers" : {
"FileSystemluafv" : {
"driverstart" : -1869398016,
"driversize" : 110592,
"driverinit" : -1869319406,
"driverstartio" : 0,
"driverunload" : 0, "filepath"
:
"C:WindowsSystem32driver
sluafv.sys", "sha" :
"befb20d2e32a0107602707d3f
6de84aa483a5b5e",
{ "mbr" : { }, "drivers" : {
"FileSystemMRxDAV" : {
"driverstart" : -161308672,
"driversize" : 180608,
"driverinit" : -161144443,
"driverstartio" : 0,
"driverunload" : -161263572,
"filepath" :
"C:WINDOWSsystem32driv
ersmrxdav.sys", "sha" :
"68dc26e6576ef52bedc7d97ba
44679a0e1cc3d74", "irp" : {
Processing module
Capture Added – Changed –
Deleted data
Eliminate noise
Tag and organise data
Baseline data Job analysis data
Diff data

10. Analysis log
Baseline log
Processing the data
10

11. Data flow
11
Data Signatures Reporting
{"drivers": {"Driver4C3553F1":
{"Added": {"driverinit":
"0xf7b97983", "driverunload":
"0xf7b9794a", "irp":
{"IRP_MJ_CREATE_MAILSLOT
": "0xf7b97965",
"IRP_MJ_SET_QUOTA":
"0xf7b97965",
"IRP_MJ_SET_SECURITY":
"0xf7b97965",
"IRP_MJ_SET_VOLUME_INFO
RMATION": "0xf7b97965",
"IRP_MJ_WRITE":
"0xf7b97965", …"
generic_new_driver
generic_modified_driver
generic_deleted_driver
generic_new_module
generic_deleted_module
generic_ssdt_hook
generic_idt_hook
generic_new_callback
generic_modifed_callback
generic_attached_device
…

12. Drivers
New driver objects
Modified driver objects
Deleted driver objects
Signatures
12

13. Modules
New Modules
Modified Modules
Deleted Modules
Signatures
13

14. Devices
New device objects
New device objects by
newservice
Signatures
14

15. Callbacks
New Callbacks
Modified Callbacks
Signatures
15

16. Hooks
SSDT Hooks
IDT Hooks
Signatures
16

17. Disk
Modified MBR
Modified VBR
Modified EOD size
Signatures
17

18. Reports
18

19. 19

20. Tests
• High profile rootkits
• TDL Derivatives
• GAPZ
• Turla
• Necurs
• Experiment B: Malicious and clean driver set
• Experiment C: Random set of known malicious PE files
20

21. TDLDerivatives
21

22. 22
TDLDerivatives

23. GAPZ
23

24. 6A08 push byte +0x8
CDC3 int 0xc3
90 nop
Turla a.k.a Snake, Uroborus
24

25. Necurs
25

26. High profile rootkits
• We do not always get enough information to
classify specific families
• We are getting enough information to warrant
further investigation by an researcher
26

27. Experiment B
27
82%
18%
Malicious Drivers
With Kernel
Data
Without
Kernel
Data
51%
49%
Clean Drivers
With Kernel
Data
Without
Kernel
Data
• Total number of malicious drivers 1854.
• Total number of clean drivers 1053.
• Insufficient time for the log to be generated was a common
reason for failure to get back kernel data. Miss the log by a
second or two. It’s a trade off.

28. And the results is
28
0
10
20
30
40
50
60
70
80
90
100
Malicious
Clean

29. ExperimentA
29

30. Experiment C
30
96%
4%
Set of PE files
With Kernel
memory
Without Kernel
Data
• 319 of known malicious PE files.
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
Kernel memory signature hits for PE files
Kernel memory signature hits for PE
files

31. Weighting the signatures
31
Suspicious
Modified driver
Modified module
Info
New driver objects
New module
Malicious
SSDT Hook
IDT Hook
New Callback
Attached Device
Modified MBR
Modified VBR
Modified EOD size

32. Conclusion
• Malicious activity can be identified via modifications
rather than creation
• Malicious drivers are unlikely to employ anti-sandboxing
techniques
• Good enough to identify kernel activity
• Not exhaustive analysis
32

33. Future work
• Exploring other areas of the kernel
• Object table
• DKOM
• 64bit drivers
• Sample clustering
• Usermode rootkits
33

34. Questions?
34