Automatic Discovery of Parasitic Malware
Download
Report
Transcript Automatic Discovery of Parasitic Malware
A UTOMATIC D ISCOVERY OF
PARASITIC M ALWARE
1
2
O UTLINE
Introduction
Parasitic Malware
Architecture
Implementation Details
Evaluation
Conclusions
I NTRODUCTION
3
Parasitic behaviors help malware execute
behaviors—such as spam generation, denial-ofservice attacks, and propagation—without
themselves raising suspicion
DLL
App
Malware
I NTRODUCTION
4
Network can pinpoint infected machines but not
processes
Host can observe parasitic behaviors but cannot
distinguish between benign and malicious behaviors
–For example: Debugger, Google toolbar
Neither approach is perfect
Combine network and host information
5
PARASITIC M ALWARE -T HREAT M ODEL
Attackers are able to install malicious software on a
victim computer system at both the user and kernel
levels
Distinguish between trusted and untrusted drivers
and isolate untrusted drivers in a separate address
space
Assume that the malware will at some point send or
receive network traffic that network-level intrusion
detection systems (network sensors) are able to
classify as malicious or suspicious
6
PARASITIC M ALWARE -M ALWARE B EHAVIORS
Parasitic malware alters the execution behavior of
existing benign processes as a way to evade detection.
These malware often abuse both Windows user and
kernel API functions to induce parasitic behaviors
7
PARASITIC M ALWARE -M ALWARE B EHAVIORS
Number
Source
Target
Description
Case 1A
Process
Process
DLL and thread injection
Dynamically-linked library (DLL) injection allows one
process to inject entire DLLs into the address space of a
second process
Target Process
OpenProcess()
CreateProcess()
Process Handle
VirtualAllocEx()
WriteProcessMemory()
CreateRemoteThread()
LoadLibrary()
Abc.dll
8
PARASITIC M ALWARE -M ALWARE B EHAVIORS
Number
Source
Target
Description
Case 1B
Process
Process
Raw code and thread injection
A raw code injection attack is similar to a DLL injection
in that user-space malware creates a remote thread of
execution, but it does not require a malicious DLL to be
stored on the victim’s computer system
9
PARASITIC M ALWARE -M ALWARE B EHAVIORS
Number
Source
Target
Description
Case 2A
Kernel driver
Process
DLL and thread alteration
Asynchronous Procedure Calls (APCs)
A method of executing code asynchronously in the
context of a particular thread and, therefore, within the
address space of a particular process
Malicious drivers identify a process → allocate memory
inside it → copy the malicious DLL to memory → create
and initialize a new APC → execute the inserted code
10
PARASITIC M ALWARE -M ALWARE B EHAVIORS
Number
Source
Target
Description
Case 2B
Kernel driver
Process
Raw code and thread alteration
Malicious kernel drivers inject raw code into a benign
process and execute it using the APC
11
PARASITIC M ALWARE -M ALWARE B EHAVIORS
Number
Source
Target
Description
Case 2C
Kernel driver
Process
Kernel thread injection
Kernel thread injection is the method by which
malicious drivers execute malicious functionality
entirely inside the kernel
A kernel thread executing malicious functionality is
owned by a user-level process, though the user-level
process had not requested its creation
By default, these threads are owned by the System
process, however a driver may also choose to execute
its kernel thread on behalf of any running process
12
A RCHITECTURE – D ESIGN G OAL
Pyrenee
Accurate
Automatic, Runtime Detection
Resist Direct and Indirect Attacks
13
A RCHITECTURE
Detect Malicious
Traffic
Malware
Records end-point
process(App)
True origin
- Malware
Records parasitic
behaviors
14
A RCHITECTURE -NIDS
Use off-the-shelf sensor identifies inbound or
outbound network traffic of suspicion
Network Intrusion Detection System like BotHunter,
Snort or Bro.
15
A RCHITECTURE -N ETWORK ATTRIBUTION S ENSOR
Given a network sensor (NIDS) alert for some
suspicious traffic flow, the network attribution sensor
is responsible for determining which process is the
local endpoint of that flow in the untrusted VM
Two subcomponents:
- one in the VM’s kernel space and one in user space
16
A RCHITECTURE -H OST ATTRIBUTION S ENSOR
User-level Parasitism
Monitors the runtime behavior of all processes
executing within the victim VM by intercepting their
system calls <Native API>
Intercepts all system calls, but it processes only those
that may be used by a DLL or thread injection attack
EX: NtOpenProcess, NtCreateProcess,etc.
17
A RCHITECTURE -H OST ATTRIBUTION S ENSOR
18
A RCHITECTURE -H OST ATTRIBUTION S ENSOR
Kernel-level Parasitic
Isolating in a separate address space and monitoring
kernel APIs invoked by untrusted drivers through this
new interface
19
A RCHITECTURE -C ORRELATION E NGINE
Finds actual malicious code on the system
Gathers data from all sensors
- NIDS,NAS,HAS
Uses NIDS provides network alert information
Uses NAS to find the process
Uses HAS to find parasitic behavior
20
I MPLEMENTATION D ETAILS
Victim host – Windows XP SP2 in VM
Hypervisor – Xen 3.2
Pyrenee run on high privilege VM – Fedora Core 9
I MPLEMENTATION D ETAILS
21
Fast Network Flow Discovery
Deployed the sensor’s packet filter inside the trusted
VM’s kernel-space as a Linux kernel module
Set up untrusted VMs to use a virtual network
interface bridged to the trusted VM
Inserted a hook into a bridge-based packet filtering
framework called ebtables to view packets crossing
the bridge
I MPLEMENTATION D ETAILS
22
Introspection
Windows does not store network port and process
name information in a single structure
Input : IP and port
I MPLEMENTATION D ETAILS
23
Introspection - EPROCESS
I MPLEMENTATION D ETAILS
24
Hypervisor gain control
System Call Interpositioning and Parameter
Extraction
Host attribution sensor requires Records
information
about
the system
call
number
(in eax
register)
system calls used as part of DLL or
thread
injection
IA32_SYSENTER _EIP
Locate system-call
parameters
not XP uses the fast x86 system-call
Address
Windows
instruction
on the kernel stack (used
allocate
to the ( Transfers
SYSENTER
control to astored
system-call
dispatch
Fault
edx
register)
guest OS
routine at an address specified in the IA32_SYSENTER
Extracts IN parameters
_EIP register)
Get currently-executing process’
ID and thread ID (use FS
segment selector → TIB)
Return
I MPLEMENTATION D ETAILS
Two-step procedure to extract values of OUT
parameters at system call return
Step 1 : Record the value present in an OUT
parameter at the beginning of the system call
Step 2 : A thread returning to user mode at the
completion of a system call will fault due to our
manipulation.
26
I MPLEMENTATION D ETAILS
Address Space Construction and Switching
Map untrusted driver code pages into the UPT
and trusted kernel and driver code into the TPT
Pyrenee switches between the two address
spaces depending upon the execution context
27
I MPLEMENTATION D ETAILS
Records this behavior
as an attack and raises
an alarm
Switches the address
space by storing the
value of TPT_CR3
Invaild
Vaild
Kernel API
Untrusted driver
Execution Fault
(non-executable
kernel code in
the UPT)
Check the
entry point
into TPT is
vaild or not
Pyrenee in
hypervisor
I MPLEMENTATION D ETAILS
28
Interception of Driver Loading
Pyrenee intercepts all driver loading mechanisms
Rewrites the kernel’s binary code on driver loading
paths automatically at runtime
29
E VALUATION
Malware
Parasitic Behavior
Attribution
Conficker worm
Process to process
Correct
Adclicker.BA trojan
Process to process
Correct
Storm worm
Kernel to Process
Correct
E VALUATION
30
Tested prototype on an Intel Core 2 Quad 2.66 GHz
system.
Assigned 1 GB of memory to the untrusted Windows
XP SP2 VM and 3 GB combined to the Xen hypervisor
and the high privilege Fedora Core 9 VM
PassMark Performance Test – CPU and memory
experiment
IBM Page Detailer and wget - measured networking
overheads
31
E VALUATION
32
E VALUATION
33
C ONCLUSIONS
Develop a well-reasoned malware detection
architecture that finds unknown malware based
on its undesirable network use
Works for both the user- and kernel-level malware
Satisfies protection and performance goals