View
219
Download
0
Tags:
Embed Size (px)
Citation preview
Botfarm DevelopmentDynamic Malware Containment
Vern Paxson & Christian Kreibich
UC Berkeley Team
Nov. 20, 2009
Role of the Botfarm• Controlled habitat for large-scale botnet experimentation
- Support safe yet faithful analysis • Tight control over communications
- Internally: isolation between bots (& infrastructure)- Externally: prevent malicious traffic, preserve C&C
• Habitat for wide range of malware
- Provide suitable platforms despite anti-VM techniques etc- Create illusion of unconstrained operation
• Enable long-term experimentation & operation
- Behavioral analysis, botnet infiltration - Automated C&C analysis, C&C rewriting
What are we doing?
Critical issue: Containment
• Containment is vital
- Must prevent attacks or abusive traffic from impinging on outside world- Ethical, legal & operational motivations
• Containment is hard
- Program behavior not known ahead of time
- Behavior may change over time
- Botnet infiltration & analysis requires (unknown!) C&C to be allowed
- Botmaster trump card: require successful attacks before bot can “join the gang”
Who cares?
State of the Art• Focus on static, packet-level containment
- Inflexible: need dynamic, per-bot policies-Unsafe: need deep app-level control
• Focus on network traffic- Incomplete: program inspection required for context
• Insufficiently granular- E.g. “Allow HTTP, redirect SMTP” may leak attacks- Infiltration requires precise C&C rewriting & synthesis
• Single-experiment setup- Production botfarm requires mutually isolated
“subfarms”
How is itdone today?
Botfarm Development Efforts• Separate policy & mechanism
-Containment servers implement per-bot containment
- Focus on app-level functionality
• Automate
- Full bot lifecycle management enables scalabilityo Infection / activity monitoring / cleanup/re-infection
• Diversify the habitat
- Virtual machines (VMware, QEMU, Xen), raw iron
- Binary analysis & tracing platforms
- Integration of external communication moduleso Address diversity, Tor, GRE tunnels to remote components
What's new?Payoffs?
Containment Servers• Flexible, policy-controlled, transparent app-layer
proxies
- Separate containment decisions (policy) from packet-level forwarding (mechanism)
- Provide flexible containment decisions
o Drop, Rate-limit, Redirect, Reflect, Rewrite
- Internal servers can require containment tooo E.g., Remote SMTP banner-grabbing for SMTP sinks
- Enable lifecycle management
o Auto-infection, activity monitoring, recovery/restart
- Scalability via multiple servers per subfarm
• Realization: shimming protocol
What's new?What difference will it make?
What's new?
SYN
SYN
SYN’-ACKACKRequest Shim
• Sender IP/port• Destination IP/port• VLAN ID
SYN’
Response Shim
• Sender IP/port• Destination IP/port • VerdictFORWARDREDIRECTREFLECTDROPLIMITREWRITE
Lifecycle Automation• Prototype of subfarm config. Specifications
• E.g., 10 Rustock bots w/ idleness monitoring& SMTP sink
What's new?
[VLAN 10-19]Decider = RustockInfection = bins/rustock.exeTrigger = *:25/tcp < 1/20min -> reboot
[Autoinfect]Address = 10.9.8.7Port = 6543
[SmtpBannerSink]Address = 10.3.1.4Port = 2525
Monitoring and Reporting• Continuous tracking of inmate behavior (via Bro)
Subfarm 1 [Containment server VLAN 11]------------------------------------------------------------------------
Gheg [x.y.0.164/10.3.9.247, VLAN 15] ---------------------------------------------------------------------- FORWARD - permitted port #flows target port 38 89.107.104.110 https REFLECT - full SMTP containment #flows target port 3433 *.*.*.* smtp
Rustock [x.y.0.130/10.3.128.81, VLAN 165] ---------------------------------------------------------------------- REFLECT - full SMTP containment #flows target port 15776 *.*.*.* smtp REWRITE - C&C filtering #flows target port 38 174.139.29.114 http 2 72.247.242.201 http
What's new?
• Vision: fully navigable reports w/ drill-down & historical archive
Overarching Challenge• Starting with specimens of a new botnet …
… successfully instantiate in controlled environment …
… extract C&C functionality/structure …
… engage with working botnet …
… analyze its structural vulnerabilities …
… determine efficacy of corresponding attacks aimed at intelligence/repurposing/disruption
• Achieve such analysis …
… Safely …
… with high fidelity at scale …
… much more readily than today’s one-off approaches achieve
Risks, challenges
Pending Issues• Bot “quickening”
- Getting bots to run in the first place / analyzing why an instance fails to functionally activate
• VM detection?- Compare w/ raw-iron run (diff syscall activity)
- Binary analysis to find VM detection logic
• Containment restriction?- Network-based analysis of attempted connections
• Mundane environmental deficiency?- Need host-side tracing / analysis of exit path
Risks, challenges
Pending Issues, con’t• Generation of containment policies
-Currently, burdensome manual process
- Semi-automation viao Matching observed activity against previous containment
templates
o Generalizing activity across multiple bot runs
• Dynamic containment via speculative execution
- Snapshot VM at point of outbound connection
-Reflect to internal server for analysis
- If vetted okay, recover to snapshot point & allow out
Risks, challenges
Pending Issues, con’t• Network-level C&C analysis and synthesis
- Inference of (non-encrypted) C&C structure
- Drive generation of C&C parsers from binary analysiso Along with C&C templates for mimicry
• Construction of faux C&C servers to drive contained experiments of botnet as complex distributed system• Safely explore large-scale effects/dynamics of C&C
disruption
Risks, challenges