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 analyzer’s 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
CPU / Hardware
DomU(Windows
Guest)
DomU(Windows
Guest)
Ether Hypervisor Component
Ether Userspace Component
Xen!!!!!!!!
...Dom0
The Ether Framework
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, unpack-execution occurred – First proposed in Renovo
Able to handle multiple packing layers Dumps unpacked memory images to
disk
Obfuscation Tool Distribution
!"#$%&''()
*+,)
-./)
01,)
234#&%$)
5,)
-6$78)
1,)
.9:(#6$7;)
<,)
!=.$78)
>,)
?=@)
>,)
!=."(;47;)
A,)
B&C-.$78)
*,)
;9'(78)
*,)
.DEF29A*)
*,)
G(%$HI)."(;)
*,)
JI.$78)
*,)
K9B)
0,)
C.$78)
0,) L;34")
0A,)
Known
Sample
Obfuscated
Samples
Trace
Logs
Obfuscation
Tools
Obfuscated
Samples
Dynamic
Malware
Analyzers
Evaluation: EtherTrace
Examine trace logs for expected actions – File – Registry
!"#$%&''())
*+,)
!-."(/01/))
2,)
/3'(14))
*,)
5.6))
78,)9:0#&%$))
;,)
5.$14))
8,)
.3<(#=$1/))
>,)
!-.$14))
?,)
@-A))
?,)
B&C5.$14))
*,)
.DEF932*))
*,)
G(%$HI)."(/J))
*,)
KI.$14))
*,)
L3B))
7,)
C.$14))
7,) M/:0")
72,)
!"#$%&'
Evaluation: EtherTrace
Obfuscation tools traced ranked by popularity
!"#$%&''())
*+,)
-(%$./)0"(12))
*,)
304))
56,)
789#&%$))
:,)
30$;<))
6,)
0=>(#?$;1))
@,)
!A0$;<))
B,)
CAD))
B,)
!A0"(19;1))
E,)
F&G30$;<))
*,)
1='(;<))
*,)
0HIJ7=E*))
*,)
K/0$;<))
*,)
L=F))
5,)
G0$;<))
5,)M189")
5E,)
!"#$%&'
!"#$%#$&' ()"'*+),$' ()""-#'*+),$'
Evaluation: EtherTrace
Ether is more transparent
!"#$%&''())
*+,)
-./))
01,)
234#&%$))
+,)
-.$56))
1,)
.78(#9$5:))
;,)
!<.$56))
=,)
><?))
=,)
!<."(:45:))
@,)
A&B-.$56))
*,)
:7'(56))
*,)
.CDE27@*))
*,)
F(%$GH)."(:I)
*,)
JH.$56))
*,)
K7A))
0,)
B.$56))
0,) L:34")
0@,)
!"#$%#$&' ()"'*+),$' ()""-#'*+),$'
Evaluation: EtherUnpack
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
Unpacked
Samples
Renovo
SamplesAutomated
Unpackers
!"#$%&''())
*+,)
-./#&%$))
0,)
123))
45,)
267(#8$9:))
;,)
<=>))
?,)
!@8$9A))
?,)
!@8"(:/9:))
B,)
C&D12$9A))
*,)
E(%$F@)
2"(:))
*,)
G6C))
4,)
!"#$%&#'()*+,&-./+01)2'+$3$)
!"#$%&''()) -./#&%$))
HI@&%&J#)) 123))
267(#8$9:)) <=>))
!@8$9A)) !@8"(:/9:))
C&D12$9A)) E(%$F@)2"(:))
G6C)) G('/I(K))
G("8.&D/)) 123)=))
Evaluation: EtherUnpack
Obfuscation tools unpacked ranked by popularity
!"#$%&''())
*+,)
-./#&%$))
0,)
123(#4$56))
7,)!84$59))
:,)
;&<=1$59))
*,)>(%$?8)1"(6))
*,)
=1@))
AB,)
CDE))
:,)
!84"(6/56))
F,)
G2;))
A,)
!"#$%&#'()*+,&-./+01)2$34*+,&-.)
!"#$%&''())
-./#&%$))
123(#4$56))
!84$59))
;&<=1$59))
>(%$?8)1"(6))
G('/H(I))
JH8&%&K#))
=1@))
CDE))
!84"(6/56))
G2;))
G("4.&</))
=1@)D))
!"#$%#&"'($ !"##)*$%#&"'($
Evaluation: EtherUnpack
Ether is more transparent
!"#$%&''())
*+,)
-./))
01,)
234#&%$))
5,).67(#8$9:))
;,)
<=>))
?,)
!@8$9A))
?,)
!@8"(:49:))
B,)
C&D-.$9A))
*,)
E(%$F@)."(:))
*,)
G6C)
0,)
!"#$%&#'()*+,&-./+01)2#3'4*+,&-.)
!"#$%&''())
-./))
234#&%$))
.67(#8$9:))
<=>))
!@8$9A))
!@8"(:49:))
C&D-.$9A))
E(%$F@)."(:))
G6C))
G('4H(I))
G("83&D4))
JH@&%&K#))
-./)=))
!"#$%#&"'($ !"##)*$%#&"'($
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
Top Related