Vern paxson christian kreibich uc berkeley team nov 20 2009
This presentation is the property of its rightful owner.
Sponsored Links
1 / 15

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


  • 68 Views
  • Uploaded on
  • Presentation posted in: General

Vern Paxson & Christian Kreibich UC Berkeley Team Nov. 20, 2009. Botfarm Development Dynamic Malware Containment. Role of the Botfarm. What are we doing?. Controlled habitat for large-scale botnet experimentation Support safe yet faithful analysis Tight control over communications

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Vern paxson christian kreibich uc berkeley team nov 20 2009

Vern Paxson & Christian Kreibich

UC Berkeley Team

Nov. 20, 2009

Botfarm DevelopmentDynamic Malware Containment


Role of the botfarm

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


Critical issue containment

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”


State of the art

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”


Botfarm development efforts

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


Containment servers

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


Botfarm architecture

Botfarm Architecture

What's new?


Subfarms

Subfarms

What's new?


Vern paxson christian kreibich uc berkeley team nov 20 2009

  • 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


Lifecycle automation

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


Monitoring and reporting

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


Overarching challenge

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


Pending issues

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

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


Pending issues con t1

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


  • Login