RAID 2011 - Vrije Universiteit Amsterdam

Transcription

RAID 2011 14th International Symposium on Recent Advances in Intrusion Detection
KLIMAX: Profiling Memory Write Patterns
to
Detect Keystroke-Harvesting Malware
Menlo Park, 21st September 2011
Stefano Ortolani - [email protected]
Cristiano Giuffrida - [email protected]
Vrije Universiteit
Amsterdam,The Netherlands
Bruno Crispo - [email protected]
Università di Trento
Trento, Italy
Motivation
2
Stefano Ortolani, Cristiano Giuffrida, Bruno Crispo
Motivation
2
Motivation
Malware is here to
stay.
Especially if it can access
private data.
2
In a Nutshell ...
3
In a Nutshell ...
•
State-of-the-art approaches detect when data
is leaked!
Leaking!
3
In a Nutshell ...
•
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
In a Nutshell ...
•
is leaked!
•
They all depend on the adopted window of
observation.
•
•
But real-world malware conceal theirself!
•
Let’s backtrack to the harvesting then!
Harvesting!
Leaking is delayed until the malware is able to
blend in with the background noise.
•
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
Outline
•
•
•
•
•
•
Requirements.
Our approach, i.e. KLIMAX.
Technical challenges.
Architecture.
Detecting privacy-breaching malware.
Conclusions.
4
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
Possible Approaches
•
Tracking memory usage is conceptually simple, but how to do it?
•
OS performance counters?
•
•
•
•
Have NO knowledge of single memory accesses. NOT fine-grained.
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.
6
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.
Code regions: main binary or/and libraries.
Memory regions: heap, data segment.
We obtain in return a set of performance counters.
7
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.
Code regions: main binary or/and libraries.
Why not the
stack?
Memory regions: heap, data segment.
We obtain in return a set of performance counters.
7
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
return 0;
Bottom of the stack
}
8
•
buff[*v++] = 5;
}
int i = 0;
int buff[SIZE];
Top of the stack
while(1)
locals of main - int
foo(buff, &i);
i, buff[]
return address of main
}
params of main - argv,
return 0;
argc
Bottom of the stack
}
8
•
buff[*v++] = 5;
}
int i = 0;
int buff[SIZE];
Top of the stack
while(1)
foo(buff, &i);
i, buff[]
}
return 0;
argc
Bottom of the stack
}
8
•
buff[*v++] = 5;
}
Top of the stack
locals of foo
int i = 0;
return address of foo
int buff[SIZE];
while(1)
foo(buff, &i);
params of foo - int
*buff, *v
i, buff[]
}
return 0;
argc
Bottom of the stack
}
8
•
buff[*v++] = 5;
}
int i = 0;
int buff[SIZE];
Top of the stack
while(1)
foo(buff, &i);
i, buff[]
}
return 0;
argc
Bottom of the stack
}
8
•
buff[*v++] = 5;
}
Top of the stack
locals of foo
int i = 0;
return address of foo
int buff[SIZE];
while(1)
foo(buff, &i);
params of foo - int
*buff, *v
i, buff[]
}
return 0;
argc
Bottom of the stack
}
8
•
buff[*v++] = 5;
}
int i = 0;
int buff[SIZE];
Top of the stack
while(1)
foo(buff, &i);
i, buff[]
}
return 0;
argc
Bottom of the stack
}
8
•
Solution
buff[*v++] = 5;
Keep
track of the lowest
}
*argv, int argc) {
topintofmain(char
the stack.
int i = 0;
And monitor only stack
while(1)
regions below
the
foo(buff, &i);
lowest} top of the stack.
int buff[SIZE];
Top of the stack
i, buff[]
return 0;
argc
Bottom of the stack
}
8
Technical Challenges
•
Paging provides applications with a uniform and isolated
memory address space.
•
•
•
All the memory accesses are controlled by the hardware.
•
The intuition is to trigger a page fault for every
memory access.
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
9
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
Introducing KLIMAX
•
We implemented KLIMAX as a device-less driver on Windows XP
SP3.
•
•
We support unmodified kernel and applications.
•
KLIMAX’s two main components:
Current implementation features a thread-safe monitor.
•
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
Architecture and Interactions (1/2)
Windows Kernel (Ring 0)
Page
Fault
Handler
Page
Tables
3 - Restore PTE
5 - Forward INT 0E
Classifier
4 - Update Counters
2 - INT 0E
Shadower
IDT
Monitor
KLIMAX
6 - Single Step
1 - Page Fault
Monitored
Process
User-land (Ring 3)
12
Architecture and Interactions (2/2)
Page
Fault
Handler
Page
Tables
3 - Override PTE
Classifier
4 - Shadow Query
2 - INT 01
Shadower
IDT
Monitor
KLIMAX
1 - Single Step
Monitored
Process
User-land (Ring 3)
13
... and it works!
Let’s poke under the hood of modern browsers ...









•






                              

14
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
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.
Classifier
3a - Sample Injected
Injector
Shadower
Monitor
KLIMAX
3b - Memory Writes
Memory Writes
2 - Injection Pattern
4 - Writes Counters
1 - Attach to Process
Monitored
Process
Detector
User-land (Ring 3)
16
Evaluation - False Positives
•
We tested the worst case scenario, e.g. shortcut managers.
Keylogger
Standard API
RegisterHotKey
Correlation
HoeKey 1.13
√
√
negligible
KeyTweak 2.3.0
√
-
negligible
Hot Key Plus 1.01
√
√
negligible
AutoHotkey 1.0.96.00
√
√
~1
ZenKEY 2.3.9
√
√
negligible
Acquarius Soft Keyboard Hotkey 2.5
√
√
negligible
Hotkey Recorder Version 2
√
-
negligible
HotKey Magic 1.3.0
√
-
negligible
17
Evaluation - False Positives
•
We tested the worst case scenario, e.g. shortcut managers.
8 lines for its cfg file
makes AutoHotKey
a KeyLogger
Keylogger
Standard API
RegisterHotKey
Correlation
HoeKey 1.13
√
√
negligible
KeyTweak 2.3.0
√
-
negligible
Hot Key Plus 1.01
√
√
negligible
AutoHotkey 1.0.96.00
√
√
~1
ZenKEY 2.3.9
√
√
negligible
Acquarius Soft Keyboard Hotkey 2.5
√
√
negligible
Hotkey Recorder Version 2
√
-
negligible
HotKey Magic 1.3.0
√
-
negligible
17
Evaluation - False Negatives
Keylogger
25 Samples from
the Sandnet dataset.
[Ross11]
Correlation
Keylogging API
API used
√
√
~1
Trojan-Downloader.Win32.Zlob.vzd
-
-
negligible
Monitor.Win32.Perflogger.ca
-
-
negligible
Suspicious.Graybird.1
-
-
negligible
Trojan-Spy.Win32.SCKeyLog.am
-
-
negligible
Backdoor.Win32.IRCBot.ebt
-
-
negligible
√
√
0.74
-
-
negligible
BackDoor.Generic9.MQL
√
√
~1
Trojan.Win32.Agent.arim
-
-
negligible
√
√
0.78
Worm.Win32.AutoRun.adro
-
-
negligible
Trojan.Win32.Delf.eq
-
-
negligible
Net-Worm.Win32.Mytob.jxu
-
-
negligible
Trojan-Spy.Win32.SCKeyLog.au
-
-
negligible
√
√
√
0.98
-
negligible
-
-
negligible
√
-
negligible
Downloader.Rozena
-
-
negligible
Downloader.Banload.BDRQ
-
-
negligible
Heur.Trojan.Generic
-
-
negligible
PSW.Generic7.BNDX
-
-
negligible
Backdoor.Win32.Poison.pg
Worm.MSIL.PSW.d
Worm.Win32.Fujack.cr
PSW.Agent.7.AH
Backdoor.Ciadoor
Backdoor.Win32.Agent.su
Backdoor.Win32.G_Spot.20
Trojan-Spy.MSIL.KeyLogger.oa
18
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.
•
•
•
Detecting keylogging malware is just the first application of KLIMAX.
False positives are due to poor programming practices.
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
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

RAID 2011 - Vrije Universiteit Amsterdam

Transcription

Similar documents

Sexy Shoeis - SHOEI Premium Helmets

stone-crete - INCRETE Systems

Stefano Di Battista - BH Hopper Management

kik-step®

DriveSavers RAID Recovery Services

Hamptons July 2013 - Tuxedo Hudson Realty

how to shape and polish polymer clay

a Brochure

1010 W Maude Ave

thiocure - Bruno Bock