How BotHunter Analyzes Network Flows

BotHunter models an infection sequence as a composition of participants and a loosely ordered sequence of network dialog exchanges:

Infection I = <A, V, E, C, P, V’, {D}>

where A = attacker, V = victim, E = egg download location, C = C&C server, P = peer to peer coordination points, and V’ = the victim’s next propagation targets.  {D} represents a set of dialog sequences composed of bidirectional flows  that cross the egress boundary.

BotHunter’s current infection dialog set {D} provides the following detection coverage  for your network:

E1: Inbound malware port focused scans

E2: In and Outbound Exploit Detection
Client-side infection attempts (Web)
Direct Microsoft Exploit Coverage, including
– RPC exploits
– Netbios attacks
– OP/Shell code attack via overflow
Special Port Exploits
High Application Port Exploits
Inbound  Only: Browser specific attacks
Outbound Only: Bad outbound email from non-SMTP
Outbound Only:
– Moderate malware-focused outbound scan detection
– Prolific non-malware-focused outbound scan detection

E3: Forced Download / Illegal Software Install Detection:
Malware/Trojan-initiated download request
Classic network stream binary spotting
Malware FTP Comms
Web-based spyware Infection Download / Install

E4: C&C Detection
Web based spyware phone home / periodic checkin
Web based malware install success reports
Inbound spyware command detection (flow established)
Web-based ADWARE phone home
BotNet C&C  login/dialog /command recognition
Trojan horse periodic checkin (primarily via web ports)
Application port checkin/install success reports
DNS-based call-backs
SMTP callbacks (from non-SMTP hosts)
Statefull IRC botnet C&C detection
Russian Business Network (RBN) address

E5/E6: Insider Attack / Malware  Preparation Activity
Spambot MX record search via DNS
DNS malware associated query

E7  Peer to Peer Rules
BotNet P2P protocol activity

E8: Malware Infection Declaration Rules:
Known botnet C&C IP address  (specific address)
Prolific malware-focused outbound scan detection

References:

Responsibility Assignment Matrix (RAM/RACI)

http://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Key Responsibility Roles

Responsible

Those who do the work to achieve the task.[7] There is typically one role with a participation type of Responsible, although others can be delegated to assist in the work required (see also RASCI below for separately identifying those who participate in a supporting role).

Accountable (also Approver or final Approving Authority)

The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one from whom Responsible is delegated the work.[7] In other words, an Accountable must sign off (Approve) on work that Responsible provides. There must be only one Accountable specified for each task or deliverable.[4]

Consulted (sometimes Counsel)

Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication.[7]

Informed

Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication.[7]

Very often the role that is Accountable for a task or deliverable may also be Responsible for completing it (indicated on the matrix by the task or deliverable having a role Accountable for it, but no role Responsible for its completion, i.e. it is implied). Outside of this exception, it is generally recommended that each role in the project or process for each task receive, at most, just one of the participation types. Where more than one participation type is shown, this generally implies that participation has not yet been fully resolved, which can impede the value of this technique in clarifying the participation of each role on each task.