Botfarm Development Dynamic Malware Containment

Vern Paxson & Christian Kreibich

UC Berkeley TeamNov. 20, 2009

Role of the BotfarmControlled habitat for large-scale botnet experimentationSupport safe yet faithful analysis Tight control over communicationsInternally: isolation between bots (& infrastructure)Externally: prevent malicious traffic, preserve C&CHabitat for wide range of malwareProvide suitable platforms despite anti-VM techniques etcCreate illusion of unconstrained operationEnable long-term experimentation & operationBehavioral analysis, botnet infiltration Automated C&C analysis, C&C rewritingWhat are we doing?

Critical issue: ContainmentContainment is vitalMust prevent attacks or abusive traffic from impinging on outside worldEthical, legal & operational motivationsContainment is hardProgram behavior not known ahead of timeBehavior may change over timeBotnet infiltration & analysis requires (unknown!) C&C to be allowedBotmaster trump card: require successful attacks before bot can join the gangWho cares?

State of the ArtFocus on static, packet-level containmentInflexible: need dynamic, per-bot policiesUnsafe: need deep app-level controlFocus on network trafficIncomplete: program inspection required for contextInsufficiently granularE.g. Allow HTTP, redirect SMTP may leak attacksInfiltration requires precise C&C rewriting & synthesisSingle-experiment setupProduction botfarm requires mutually isolated subfarmsHow is itdone today?

Botfarm Development EffortsSeparate policy & mechanismContainment servers implement per-bot containmentFocus on app-level functionalityAutomateFull bot lifecycle management enables scalabilityInfection / activity monitoring / cleanup/re-infectionDiversify the habitatVirtual machines (VMware, QEMU, Xen), raw ironBinary analysis & tracing platformsIntegration of external communication modulesAddress diversity, Tor, GRE tunnels to remote componentsWhat's new?Payoffs?

Containment ServersFlexible, policy-controlled, transparent app-layer proxiesSeparate containment decisions (policy) from packet-level forwarding (mechanism)Provide flexible containment decisionsDrop, Rate-limit, Redirect, Reflect, RewriteInternal servers can require containment tooE.g., Remote SMTP banner-grabbing for SMTP sinksEnable lifecycle managementAuto-infection, activity monitoring, recovery/restartScalability via multiple servers per subfarmRealization: shimming protocolWhat's new?What difference will it make?

Botfarm ArchitectureWhat's new?

SubfarmsWhat's new?

What's new?SYNFORWARDREDIRECTREFLECTDROPLIMITREWRITE

Lifecycle AutomationPrototype of subfarm config. SpecificationsE.g., 10 Rustock bots w/ idleness monitoring & SMTP sinkWhat'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 ReportingContinuous 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 ChallengeStarting 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/disruptionAchieve such analysis Safely with high fidelity at scale much more readily than todays one-off approaches achieveRisks, challenges

Pending IssuesBot quickeningGetting bots to run in the first place / analyzing why an instance fails to functionally activateVM detection?Compare w/ raw-iron run (diff syscall activity)Binary analysis to find VM detection logicContainment restriction?Network-based analysis of attempted connectionsMundane environmental deficiency?Need host-side tracing / analysis of exit pathRisks, challenges

Pending Issues, contGeneration of containment policiesCurrently, burdensome manual processSemi-automation viaMatching observed activity against previous containment templatesGeneralizing activity across multiple bot runsDynamic containment via speculative executionSnapshot VM at point of outbound connectionReflect to internal server for analysisIf vetted okay, recover to snapshot point & allow out Risks, challenges

Pending Issues, contNetwork-level C&C analysis and synthesisInference of (non-encrypted) C&C structureDrive generation of C&C parsers from binary analysisAlong with C&C templates for mimicryConstruction of faux C&C servers to drive contained experiments of botnet as complex distributed systemSafely explore large-scale effects/dynamics of C&C disruptionRisks, challenges

***************