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?

Botfarm Architecture What's new?

Subfarms What's new?

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