Automatic Discovery of Parasitic Malware

1. Automatic Discovery of Parasitic Malware AbhinavSrivastava and Jonathon Giffin (RAID,2010) School of Computer Science, Georgia Institute of Technology, USA

2. Outline • Introduction • Parasitic Malware • Architecture • Implementation Details • Evaluation • Conclusions

3. Introduction • Parasitic behaviors help malware execute behaviors—such as spam generation, denial-of-service attacks, and propagation—without themselves raising suspicion DLL App Malware

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

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

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

7. 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 OpenProcess()CreateProcess() VirtualAllocEx() WriteProcessMemory() Abc.dll CreateRemoteThread() LoadLibrary()

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

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

10. Parasitic Malware-Malware Behaviors • Malicious kernel drivers inject raw code into a benign process and execute it using the APC

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

12. Architecture–Design Goal • Pyrenee • Accurate • Automatic, Runtime Detection • Resist Direct and Indirect Attacks

13. Architecture Detect Malicious Traffic Malware Records end-point process(App) True origin - Malware Records parasitic behaviors

14. Architecture-NIDS • Use off-the-shelf sensor identifies inbound or outbound network traffic of suspicion • Network Intrusion Detection System like BotHunter, Snort or Bro.

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

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

17. Architecture-Host Attribution Sensor

18. Architecture-Host Attribution Sensor • Kernel-level Parasitic • Isolating in a separateaddress space and monitoring kernel APIs invoked by untrusted drivers throughthis new interface

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

20. Implementation Details • Victim host – Windows XP SP2 in VM • Hypervisor – Xen 3.2 • Pyrenee run on high privilege VM – Fedora Core 9

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

22. Implementation Details • Introspection • Windows does not store network port and process name information in a single structure Input : IP and port

23. Implementation Details • Introspection - EPROCESS

24. 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) IA32_SYSENTER _EIP Address not allocate to the guest OS Locate system-call parameters stored on the kernel stack (used edx register) Fault Extracts IN parameters Get currently-executing process’ ID and thread ID (use FS segment selector → TIB) Return

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

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

27. Implementation Details Records this behavior as an attack and raises an alarm Invaild Switches the address space by storing the value of TPT_CR3 Vaild 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

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

29. Evaluation

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

32. Evaluation

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