unveiling the kernel: rootkit discovery using selective ... · unveiling the kernel: rootkit...

Unveiling the kernel: Rootkit discovery

using selective automated kernel memory

differencing Ahmed Zaki and Benjamin Humphrey

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

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

How do we automate the process?

•Use existing tools

•Build our own • Using anti-rootkit tools

• Using a custom diff based solution

4

Bird’s eye view

5

HOST

Auxiliary module

Processing module

Django templates

GUEST

Analysis Packages

Auxiliary module

Signatures

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

Usage of the Sophos AV 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

Examining the kernel

Drivers Modules SSDT

IDT Callbacks Disk

Information

What areas are we looking at?

8

Processing the data

9

{ "mbr" : { }, "drivers" : {

"\\FileSystem\\luafv" : {

"driverstart" : -1869398016,

"driversize" : 110592,

"driverinit" : -1869319406,

"driverstartio" : 0,

"driverunload" : 0, "filepath"

:

"C:\\Windows\\System32\\driver

s\\luafv.sys", "sha" :

"befb20d2e32a0107602707d3f

6de84aa483a5b5e",

{ "mbr" : { }, "drivers" : {

"\\FileSystem\\MRxDAV" : {

"driverstart" : -161308672,

"driversize" : 180608,

"driverinit" : -161144443,

"driverstartio" : 0,

"driverunload" : -161263572,

"filepath" :

"C:\\WINDOWS\\system32\\driv

ers\\mrxdav.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

Analysis log

Baseline log

Processing the data

10

Data flow

11

Data Signatures Reporting

{"drivers": {"\\Driver\\4C3553F1":

{"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

…

Drivers

New driver objects

Modified driver objects

Deleted driver objects

Signatures

12

Modules

New Modules

Modified Modules

Deleted Modules

Signatures

13

Devices

New device objects

New device objects by

newservice

Signatures

14

Callbacks

New Callbacks

Modified Callbacks

Signatures

15

Hooks

SSDT Hooks

IDT Hooks

Signatures

16

Disk

Modified MBR

Modified VBR

Modified EOD size

Signatures

17

Reports

18

19

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

TDL Derivatives

21

22

TDL Derivatives

GAPZ

23

6A08 push byte +0x8

CDC3 int 0xc3

90 nop

Turla a.k.a Snake, Uroborus

24

Necurs

25

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

Experiment B

27

82%

18%

Malicious Drivers

With KernelData

WithoutKernelData

51% 49%

Clean Drivers

With KernelData

WithoutKernelData

• 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.

And the results is

28

0

10

20

30

40

50

60

70

80

90

100

Malicious

Clean

Experiment A

29

Experiment C

30

96%

4%

Set of PE files

With Kernelmemory

Without KernelData

• 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 PEfiles

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

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

Future work • Exploring other areas of the kernel

• Object table

• DKOM

• 64bit drivers

• Sample clustering

• Usermode rootkits

33

Questions?

34