automatic discovery of parasitic malware n.
Skip this Video
Loading SlideShow in 5 Seconds..
Automatic Discovery of Parasitic Malware PowerPoint Presentation
Download Presentation
Automatic Discovery of Parasitic Malware

Loading in 2 Seconds...

play fullscreen
1 / 33

Automatic Discovery of Parasitic Malware - PowerPoint PPT Presentation

  • Uploaded on

Automatic Discovery of Parasitic Malware. Abhinav Srivastava and Jonathon Giffin (RAID,2010) School of Computer Science, Georgia Institute of Technology, USA. Outline. Introduction Parasitic Malware Architecture Implementation Details Evaluation Conclusions. Introduction.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Automatic Discovery of Parasitic Malware' - ember

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
automatic discovery of parasitic malware

Automatic Discovery of Parasitic Malware

AbhinavSrivastava and Jonathon Giffin (RAID,2010)

School of Computer Science, Georgia Institute of Technology, USA

  • Introduction
  • Parasitic Malware
  • Architecture
  • Implementation Details
  • Evaluation
  • Conclusions
  • Parasitic behaviors help malware execute behaviors—such as spam generation, denial-of-service attacks, and propagation—without themselves raising suspicion




  • 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 perfectCombine network and host information
parasitic malware threat model
Parasitic Malware-Threat Model
  • Attackers are able to install malicious software on a victim computer systemat both the user and kernel levels
  • Distinguish between trusted anduntrusted 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
parasitic malware malware behaviors
Parasitic Malware-Malware Behaviors
  • Parasitic malware alters the execution behavior of existing benign processes asa way to evade detection.
  • These malware often abuse both Windows user and kernel API functions to induce parasitic behaviors
parasitic malware malware behaviors1
Parasitic Malware-Malware Behaviors
  • Dynamically-linked library (DLL) injection allows one process toinject entire DLLs into the address space of a second process

Target Process

Process Handle







parasitic malware malware behaviors2
Parasitic Malware-Malware Behaviors
  • 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
parasitic malware malware behaviors3
Parasitic Malware-Malware Behaviors
  • 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
parasitic malware malware behaviors4
Parasitic Malware-Malware Behaviors
  • Malicious kernel drivers inject raw code into a benign process and execute it using the APC
parasitic malware malware behaviors5
Parasitic Malware-Malware Behaviors
  • Kernel thread injection is the method by which malicious drivers execute malicious functionality entirely inside the kernel
  • A kernelthread executing malicious functionality is owned by a user-level process, thoughthe user-level process had not requested its creation
  • By default, these threadsare owned by the System process, however a driver may also choose to executeits kernel thread on behalf of any running process
architecture design goal
Architecture–Design Goal
  • Pyrenee
  • Accurate
  • Automatic, Runtime Detection
  • Resist Direct and Indirect Attacks

Detect Malicious Traffic


Records end-point process(App)

True origin - Malware

Records parasitic behaviors

architecture nids
  • Use off-the-shelf sensor identifies inbound or outbound network traffic of suspicion
  • Network Intrusion Detection System like BotHunter, Snort or Bro.
architecture network attribution sensor
Architecture-Network Attribution Sensor
  • 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 userspace
architecture host attribution sensor
Architecture-Host Attribution Sensor
  • 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 attackEX: NtOpenProcess, NtCreateProcess,etc.
architecture host attribution sensor2
Architecture-Host Attribution Sensor
  • Kernel-level Parasitic
  • Isolating in a separateaddress space and monitoring kernel APIs invoked by untrusted drivers throughthis new interface
architecture correlation engine
Architecture-Correlation Engine
  • 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
implementation details
Implementation Details
  • Victim host – Windows XP SP2 in VM
  • Hypervisor – Xen 3.2
  • Pyrenee run on high privilege VM – Fedora Core 9
implementation details1
Implementation Details
  • 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
implementation details2
Implementation Details
  • Introspection
  • Windows does not store network port and process name information in a single structure

Input : IP and port

implementation details3
Implementation Details
  • Introspection - EPROCESS
implementation details4
Implementation Details

Hypervisor gain control

  • System Call Interpositioning and Parameter Extraction
  • Host attribution sensor requires information about system calls used as part of DLL or thread injection
  • Windows XP uses the fast x86 system-call instruction SYSENTER ( Transfers control to a system-call dispatch routine at an address specified in the IA32_SYSENTER _EIP register)

Records the system call number (in eax register)


Address not allocate to the guest OS

Locate system-call parameters stored on the kernel stack (used edx register)


Extracts IN parameters

Get currently-executing process’ ID and thread ID (use FS segment selector → TIB)


implementation details5
Implementation Details
  • Two-step procedure to extract values of OUT parameters at system call return
  • Step 1 : Record the value present in an OUT parameter atthe 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.
implementation details6
Implementation Details
  • 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
implementation details7
Implementation Details

Records this behavior as an attack and raises an alarm


Switches the address space by storing the value of TPT_CR3


Check the entry point into TPT is vaild or not

Execution Fault

Kernel API

(non-executable kernel code in the UPT)

Pyrenee in hypervisor

Untrusted driver

implementation details8
Implementation Details
  • Interception of Driver Loading
  • Pyrenee intercepts all driver loading mechanisms
  • Rewrites the kernel’s binary code on driver loading paths automatically at runtime
  • 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
  • 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