Vern Paxson & Christian Kreibich UC Berkeley Team Nov. 20, 2009

1. Vern Paxson & Christian Kreibich UC Berkeley Team Nov. 20, 2009 Botfarm DevelopmentDynamic Malware Containment

2. Role of the Botfarm What are we doing? • 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

3. Critical issue: Containment Who cares? • 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”

4. State of the Art How is it done today? • 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”

5. Botfarm Development Efforts What's new? Payoffs? • Separate policy & mechanism • Containment servers implement per-bot containment • Focus on app-level functionality • Automate • Full bot lifecycle management enables scalability • Infection / activity monitoring / cleanup/re-infection • Diversify the habitat • Virtual machines (VMware, QEMU, Xen), raw iron • Binary analysis & tracing platforms • Integration of external communication modules • Address diversity, Tor, GRE tunnels to remote components

6. Containment Servers What's new? What difference will it make? • Flexible, policy-controlled, transparent app-layer proxies • Separate containment decisions (policy) from packet-level forwarding (mechanism) • Provide flexible containment decisions • Drop, Rate-limit, Redirect, Reflect, Rewrite • Internal servers can require containment too • E.g., Remote SMTP banner-grabbing for SMTP sinks • Enable lifecycle management • Auto-infection, activity monitoring, recovery/restart • Scalability via multiple servers per subfarm • Realization: shimming protocol

7. Botfarm Architecture What's new?

8. Subfarms What's new?

9. Response Shim • Sender IP/port • Destination IP/port • Verdict • Request Shim • Sender IP/port • Destination IP/port • VLAN ID SYN’-ACK ACK SYN’ SYN What's new? SYN FORWARD REDIRECT REFLECT DROP LIMIT REWRITE

10. Lifecycle Automation What's new? • Prototype of subfarm config. Specifications • E.g., 10 Rustock bots w/ idleness monitoring& SMTP sink [VLAN 10-19] Decider = Rustock Infection = bins/rustock.exe Trigger = *:25/tcp < 1/20min -> reboot [Autoinfect] Address = 10.9.8.7 Port = 6543 [SmtpBannerSink] Address = 10.3.1.4 Port = 2525

11. Monitoring and Reporting What's new? • 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 • Vision: fully navigable reports w/ drill-down & historical archive

12. Overarching Challenge Risks, challenges • 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

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

14. Pending Issues, con’t Generationof containment policies Currently, burdensome manual process Semi-automation via Matching observed activity against previous containment templates 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

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