KLIMAX: Profiling Memory Write Patterns to Detect Keystroke-Harvesting Malware

Transcription

1 to Detect Keystroke-Harvesting Malware Menlo Park, 21st September 2011 Stefano Ortolani - ortolani@cs.vu.nl Cristiano Giuffrida - giuffrida@cs.vu.nl Vrije Universiteit Amsterdam, The Netherlands Bruno Crispo - crispo@disi.unitn.it Università di Trento Trento, Italy

2 Motivation 2

3 Motivation 2

4 Motivation Malware is here to stay. Especially if it can access private data. 2

5 In a Nutshell... 3

6 In a Nutshell... State-of-the-art approaches detect when data is leaked! Leaking! 3

7 In a Nutshell... State-of-the-art approaches detect when data is leaked! They all depend on the adopted window of observation. But real-world malware conceal theirself! Leaking is delayed until the malware is able to blend in with the background noise. 3

8 In a Nutshell... State-of-the-art approaches detect when data is leaked! They all depend on the adopted window of observation. Harvesting! But real-world malware conceal theirself! Leaking is delayed until the malware is able to blend in with the background noise. Let s backtrack to the harvesting then! We measure the harvesting by quantitatively profiling the memory. An approach so application-agnostic allows us to deal with a huge variety of malware. 3

9 Outline Requirements. Our approach, i.e. KLIMAX. Technical challenges. Architecture. Detecting privacy-breaching malware. Conclusions. 4

10 Infrastructure Requirements Transparent Application-agnostic. Backward compatible Retrofit existing applications and OSes. Live deployable Can be installed in production at any time. Fine-grained Distinguishes the nature of memory accesses. 5

11 Possible Approaches Tracking memory usage is conceptually simple, but how to do it? OS performance counters? Snapshots? Memory access dynamics is LOST. Merely intercepting page-faults? MISSES accesses. OS is not entirely in control. Virtualization? NOT live, and NOT fine-grained. Have NO knowledge of single memory accesses. NOT fine-grained. 6

12 Our Approach We designed a component running in kernel space forcibly monitoring any memory write. The monitoring is enabled on-demand, hence no overhead if no analysis is in progress. We control a set of monitoring parameters. Monitoring time. Processes and thread to be monitored. Memory regions: heap, data segment. Code regions: main binary or/and libraries. We obtain in return a set of performance counters. 7

13 Our Approach We designed a component running in kernel space forcibly monitoring any memory write. The monitoring is enabled on-demand, hence no overhead if no analysis is in progress. We control a set of monitoring parameters. Monitoring time. Processes and thread to be monitored. Memory regions: heap, data segment. Code regions: main binary or/and libraries. We obtain in return a set of performance counters. Why not the stack? 7

14 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); return 0; Top of the stack Bottom of the stack 8

15 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); return 0; Top of the stack locals of main - int i, buff[] return address of main params of main - argv, argc Bottom of the stack 8

16 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); return 0; Top of the stack locals of main - int i, buff[] return address of main params of main - argv, argc Bottom of the stack 8

17 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); Top of the stack locals of foo return address of foo params of foo - int *buff, *v locals of main - int i, buff[] return address of main return 0; params of main - argv, argc Bottom of the stack 8

18 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); return 0; Top of the stack locals of main - int i, buff[] return address of main params of main - argv, argc Bottom of the stack 8

19 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); Top of the stack locals of foo return address of foo params of foo - int *buff, *v locals of main - int i, buff[] return address of main return 0; params of main - argv, argc Bottom of the stack 8

20 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { buff[*v++] = 5; int main(char *argv, int argc) { int i = 0; int buff[size]; while(1) foo(buff, &i); return 0; Top of the stack locals of main - int i, buff[] return address of main params of main - argv, argc Bottom of the stack 8

21 Long-Lived Stack Regions The stack is not always transient... void foo(int * buff, int * v) { Solution buff[*v++] = 5; Keep track of the lowest top of the stack. int main(char *argv, int argc) { int i = 0; And monitor int buff[size]; only stack while(1) regions below the foo(buff, &i); lowest top of the stack. Top of the stack locals of main - int i, buff[] return address of main return 0; params of main - argv, argc Bottom of the stack 8

22 Technical Challenges Paging provides applications with a uniform and isolated memory address space. All the memory accesses are controlled by the hardware. The OS is only in charge of dealing with page faults. A page fault may happen for different reasons: protection fault, page swapped on disk... etc The intuition is to trigger a page fault for every memory access. 9

23 Technical Challenges - Solution (1) We override the owner bit of some of the OS page table entries (PTE) (2) Each memory access triggers a protection page fault. (3) We disassemble the instruction to compute the number of bytes accessed. (4) We disable the protection and we allow the OS to resolve the fake page-fault. (5) The monitored process then executes as usual. (6) The protection is then restored right after the processor completed the execution of the faulting instruction. 10

24 Introducing KLIMAX We implemented KLIMAX as a device-less driver on Windows XP SP3. We support unmodified kernel and applications. Current implementation features a thread-safe monitor. KLIMAX s two main components: Shadower follows the complex MM model of windows (see Windows Internals). Classifier introspects windows data structures and PE headers to retrieve detailed process information. 11

25 Architecture and Interactions (1/2) Windows Kernel (Ring 0) Page Tables 3 - Restore PTE 5 - Forward INT 0E Page Fault Handler Classifier 4 - Update Counters Shadower KLIMAX Monitor 2 - INT 0E IDT 6 - Single Step 1 - Page Fault Monitored Process User-land (Ring 3) 12

26 Architecture and Interactions (2/2) Windows Kernel (Ring 0) Page Tables 3 - Override PTE Page Fault Handler Classifier 4 - Shadow Query Shadower KLIMAX Monitor 2 - INT 01 IDT 1 - Single Step Monitored Process User-land (Ring 3) 13

27 ... and it works! Let s poke under the hood of modern browsers... 14

28 KLIMAX for malware with keylogging behavior (1/2) In our previous work [OGC10] we taunted a keylogger with some input that looks real. Our strategy comprised two contemporary phases: Injection phase - the launch of the bait, i.e. the injection of the keystrokes. Monitor phase - in which we monitor all the processes. A third phase, termed Detection phase, flags as a keylogger any process exhibiting high correlation between: The stream of keystrokes we injected. The stream of bytes the process wrote on the hard drive. 15

29 KLIMAX for malware with keylogging behavior (2/2) Our old approach fails against malware postponing the leakage indefinitely (no clear I/O activity). In this scenario we can easily use KLIMAX and its ability to monitor each memory write. Windows Kernel (Ring 0) Classifier Shadower KLIMAX Monitor 3a - Sample Injected 3b - Memory Writes Injector Memory Writes 2 - Injection Pattern 4 - Writes Counters 1 - Attach to Process Monitored Process Detector User-land (Ring 3) 16

30 Evaluation - False Positives We tested the worst case scenario, e.g. shortcut managers. Keylogger Standard API RegisterHotKey Correlation HoeKey 1.13 negligible KeyTweak negligible Hot Key Plus 1.01 negligible AutoHotkey ~1 ZenKEY negligible Acquarius Soft Keyboard Hotkey 2.5 negligible Hotkey Recorder Version 2 - negligible HotKey Magic negligible 17

31 Evaluation - False Positives We tested the worst case scenario, e.g. shortcut managers. Keylogger Standard API RegisterHotKey Correlation HoeKey 1.13 negligible KeyTweak negligible Hot Key Plus 1.01 negligible AutoHotkey ~1 ZenKEY negligible Acquarius Soft Keyboard Hotkey 2.5 negligible Hotkey Recorder Version 2 - negligible HotKey Magic negligible 8 lines for its cfg file makes AutoHotKey a KeyLogger 17

32 Evaluation - False Negatives Keylogger Keylogging API API used Correlation Backdoor.Win32.Poison.pg ~1 Trojan-Downloader.Win32.Zlob.vzd - - negligible Monitor.Win32.Perflogger.ca - - negligible Suspicious.Graybird negligible Trojan-Spy.Win32.SCKeyLog.am - - negligible Backdoor.Win32.IRCBot.ebt - - negligible Worm.MSIL.PSW.d 0.74 Worm.Win32.Fujack.cr - - negligible BackDoor.Generic9.MQL ~1 Trojan.Win32.Agent.arim - - negligible PSW.Agent.7.AH 0.78 Worm.Win32.AutoRun.adro - - negligible Trojan.Win32.Delf.eq - - negligible Net-Worm.Win32.Mytob.jxu - - negligible Trojan-Spy.Win32.SCKeyLog.au - - negligible Backdoor.Ciadoor 0.98 Backdoor.Win32.Agent.su - negligible Backdoor.Win32.G_Spot negligible Trojan-Spy.MSIL.KeyLogger.oa - negligible Downloader.Rozena - - negligible Downloader.Banload.BDRQ - - negligible Heur.Trojan.Generic - - negligible PSW.Generic7.BNDX - - negligible 25 Samples from the Sandnet dataset. [Ross11] 18

33 Conclusions Two main modes of detection: Proactive detection - controlled by the user. Reactive detection - monitors the processes that register the keylogging callback. Promising results from our evaluation against real-world malware. False positives are due to poor programming practices. Detecting keylogging malware is just the first application of KLIMAX. KLIMAX can successfully monitor complex applications like modern web browsers. More tuning-up is needed to improve the performance (e.g. overriding the writable bit). 19

34 Thanks for your attention! Any questions? [OGC11] - Ortolani et al. - Bait your Hook: A Novel Detection Technique for Keyloggers [Ros11] - Rossow et al. - Sandnet: Network Traffic Analysis of Malicious Software. 20