You are on page 1of 28

Ether

Malware Analysis via Hardware Virtualization Extensions


Artem Dinaburg*, Paul Royal*, Monirul Sharif* and Wenke Lee*
*Georgia

Institute of Technology Damballa

ACM CCS 2008

Agenda
Motivation
The malware problem

The Ether Framework


Transparency and transparent malware analysis

Evaluation
Comparing Ether to current approaches

Conclusion

The Malware Problem


A centerpiece of current security threats
Botnets Spam Information Theft Financial Fraud

Real Criminals
Criminal infrastructure Domain of organized crime

Malware Analysis
There is a profound need to understand malware behavior
Forensics and Asset Remediation C&C Detection Threat Analysis

Malware authors make analysis very challenging


Direct financial motivation

Two Types of Malware Analysis


Static Analysis
What a program would do Complete view of program behavior Requires accurate disassembly of x86 machine code Often impossible to do in practice

Dynamic Analysis
Shows what a program actually did when executed Only gives a partial view of program behavior Misses trigger based actions How do you hide your analyzer?

The Malware Uncertainty Principle


An important practical problem Observer affecting the observed environment Robust and detailed analyzers are typically invasive
In-memory presence Hooks CPU Emulation

Malware will refuse to run

The Malware Uncertainty Principle, Commercialized

Dynamic analyzer detection is a standard malware feature

Explaining the Malware Uncertainty Principle


Why such a high detection rate? Detection of In-Guest presence
PolyUnpack, CWSandbox

Detection of Whole-System emulation


Anubis, Renovo

Detection of API Emulation


Norman Sandbox

Contributions
Transparency
The theory

Ether: A transparent malware analysis platform


The implementation

An externally reproducible evaluation of our results


Source Code Malware Samples

Solving the Malware Uncertainty Principle


An analyzers aim should be transparency.
Defining transparency

The execution of the malware and the malware analyzer is governed by the principle of non-interference.

Transparency Requirements
Higher Privilege No non-privileged side effects Same instruction execution semantics Identical exception handling Identical notion of time

Additional Analyzer Requirements


Semantic information
Process names, system call arguments, etc.

Coarse grained (system call level) tracing


Behavioral anti-virus Malware Analysis Services

Fine grained (instruction by instruction) tracing


Dynamic taint analysis Automated unpacking Multipath exploration

Fulfilling Transparency Requirements


Debugging API
In-guest presence Exception Handling

Reduced Privilege Guests (VMWare, etc)


Non-privileged side effects

Emulation (QEMU, Simics)


Instruction execution semantics

Fulfilling Transparency Requirements


Idea: Use hardware assisted virtualization Provides several attractive transparency features
External Capable Equivalent

Poses complex analysis challenges


Different goals

Challenges
A transparent yet functional malware analyzer Use features of Intel VT in novel ways to achieve:
Guest memory analysis Coarse grained tracing Fine grained tracing

Maintaining transparency

The Ether Framework


Dom0 Ether Userspace Component DomU (Windows Guest)

...

DomU (Windows Guest)

Ether Hypervisor Component CPU / Hardware

Xen!!!!!!!!

Detecting Ether
Detecting Intel VT
Increasingly irrelevant Not the same

Timing attacks
Network-based clock sources Nothing we can really do

Memory Hierarchy Attacks


Use AMD

About EtherTrace
An implementation of a coarse grained tracer using the Ether framework Traces the Windows equivalent of system calls (Native API)
Concept extends to other OSes

Information Provided:
Call name Typed arguments Return values Context (Process ID, Thread ID)

About EtherUnpack
Precision universal automated unpacker Uses instruction-by-instruction tracing (fine grained tracing) to detect unpack execute behavior If code written is later executed, unpackexecution occurred
First proposed in Renovo

Able to handle multiple packing layers Dumps unpacked memory images to disk

Obfuscation Tool Distribution


K9B) JI.$78) 0,) *,) G(%$HI)."(;) .DEF29A*) *,) *,) ;9'(78) *,) B&C-.$78) *,) !=."(;47;) A,) C.$78) 0,) L;34") 0A,) !"#$%&''() *+,)

?=@) >,) !=.$78) >,) .9:(#6$7;) <,) -6$78) 1,) -./) 01,) 234#&%$) 5,)

Evaluation: EtherTrace
Known Sample Obfuscation Tools Obfuscated Samples

Obfuscated Samples

Dynamic Malware Analyzers

Trace Logs

Examine trace logs for expected actions


File Registry

Evaluation: EtherTrace
!"#$%&'
C.$14)) 7,) L3B)) 7,) KI.$14)) *,) G(%$HI)."(/J)) *,) .DEF932*)) *,) B&C5.$14)) *,) @-A)) ?,) !-.$14)) ?,) .3<(#=$1/)) >,) 5.$14)) 8,) 9:0#&%$)) ;,) M/:0") 72,)

!"#$%&'
G0$;<)) 5,) L=F)) 5,) K/0$;<)) *,) 0HIJ7=E*)) *,) 1='(;<)) *,) F&G30$;<)) *,) !A0"(19;1)) E,) CAD)) B,) !A0$;<)) B,) 0=>(#?$;1)) @,) 30$;<)) 6,) -(%$./)0"(12)) *,) M189") 5E,)

!"#$%&''()) *+,)

!"#$%&''()) *+,)

!-."(/01/)) 2,) /3'(14)) *,) 5.6)) 78,)

304)) 56,) 789#&%$)) :,)

!"#$%#$&'

()"'*+),$'

()""-#'*+),$'

Obfuscation tools traced ranked by popularity

Evaluation: EtherTrace
B.$56)) 0,) K7A)) 0,) JH.$56)) *,) F(%$GH)."(:I) *,) .CDE27@*)) *,) :7'(56)) *,) A&B-.$56)) *,) !<."(:45:)) @,) ><?)) =,) !<.$56)) =,) .78(#9$5:)) ;,) -.$56)) 1,) 234#&%$)) +,) -./)) 01,) L:34") 0@,) !"#$%&''()) *+,)

!"#$%#$&'

()"'*+),$'

()""-#'*+),$'

Ether is more transparent

Evaluation: EtherUnpack
Renovo Samples Automated Unpackers Unpacked Samples

Looked for a 32 byte string present in the original code section Not a random string
Avoid API calls Not at entry point On code path

Evaluation: EtherUnpack
!"#$%&#'()*+,&-./+01)2'+$3$) !"#$%&#'()*+,&-./+01)2$34*+,&-.)
!"#$%&''()) HI@&%&J#)) 267(#8$9:)) !@8$9A)) C&D12$9A)) G6C)) G("8.&D/)) G6C)) 4,) E(%$F@) 2"(:)) *,) C&D12$9A)) *,) !@8"(:/9:)) B,) !@8$9A)) ?,) <=>)) ?,) 123)) 45,) 267(#8$9:)) ;,) -./#&%$)) 123)) <=>)) !@8"(:/9:)) E(%$F@)2"(:)) G('/I(K)) 123)=)) !"#$%&''()) *+,) !"#$%&''()) !"#$%&''()) *+,) -./#&%$)) 123(#4$56)) !84$59)) ;&<=1$59)) G2;)) A,) !84"(6/56)) F,) CDE)) :,) >(%$?8)1"(6)) G('/H(I)) JH8&%&K#)) =1@)) -./#&%$)) 0,) 123(#4$56)) 7,) !84$59)) :,) >(%$?8)1"(6)) *,) ;&<=1$59)) *,) CDE)) !84"(6/56)) G2;)) =1@)) AB,) G("4.&</)) =1@)D))

-./#&%$)) 0,)

!"#$%#&"'($

!"##)*$%#&"'($

Obfuscation tools unpacked ranked by popularity

Evaluation: EtherUnpack
!"#$%&#'()*+,&-./+01)2#3'4*+,&-.)
!"#$%&''()) !"#$%&''()) *+,) -./)) 234#&%$)) .67(#8$9:)) <=>)) !@8$9A)) G6C) 0,) E(%$F@)."(:)) *,) C&D-.$9A)) *,) !@8"(:49:)) B,) !@8"(:49:)) C&D-.$9A)) E(%$F@)."(:)) G6C)) !@8$9A)) ?,) <=>)) ?,) 234#&%$)) 5,) G('4H(I)) -./)) 01,) G("83&D4)) JH@&%&K#)) -./)=))

.67(#8$9:)) ;,)

!"#$%#&"'($

!"##)*$%#&"'($

Ether is more transparent

Conclusion
An inadequacy of current tools Theoretically, we can do better Ether is an implementation of a different approach Evaluation confirms Ether is more transparent

Questions?
Source code and samples available at: http://ether.gtisc.gatech.edu

You might also like