From BroWiki

This section describes a specific procedure that can be followed with each "incident" that Bro uncovers, but one must keep in mind that intrusion detection is not a static problem. The perpetrators of intrusions and malicious network activity are constantly changing their techniques with the express purpose of evading detection. Unexpected activities are often found by investigation of seemingly innocuous network oddities or serendipitous inspection of logs. While Bro is an exceptionally useful tool for collecting, sorting, analyzing and flagging suspect network data, it cannot be expected to flag all new, cleverly disguised attacks. Nor can it be expected to differentiate with 100% accuracy between aberrant, but legitimate, user behavior and a malicious attack. Sometimes a strong curiosity is an analyst's best friend and Bro is the vehicle for allowing him or her to follow that curiosity.

Contents 1 Two Types of Triggers 1.1 Converted Signatures 1.2 Embedded Bro Rule 2 General Process Steps 3 Understand What Triggered the Alarm(s) 3.1 Converted Snort Signatures 3.2 Embedded Bro Rule 4 Understand the Intent of the Alarm(s) 4.1 Converted Snort Signatures 4.2 Embedded Bro Rule 5 Examine HTTP FTP or SMTP Sessions 6 Examine the Connection and Weird Logs 6.1 Breakin Indicators 6.2 Connections to Other Computers 6.3 Odd Activity 7 Examine the Bulk Trace if Available 8 Contact and Question Appropriate People

Two Types of Triggers

There are two ways that alarms can be triggered. One is when network traffic matches a signatures that has been converted to work with Bro. The other way is by matching Bro rules that are embedded in the Bro analyzers.

Converted Signatures

In the Bro report, converted signatures are identified by the alarm type: SensitiveSignature and the existence of a bro identification number. Each signature is distinct, targeting one specific set of network events for each alarm. Currently the majority of converted signatures are developed from Snort signatures using the snort2bro utility. In addition, enhancing have been made by utilizing features in the Bro policy language that are absent in Snort. Most Bro signatures are found in the $BROHOME/site/signatures.sig, however, they can exist in other .sig files.

Embedded Bro Rule

Bro rules are typically embedded in the Bro analyzers or other .bro policy files. Several trigger conditions are usually lumped into a grouping of Bro rules within a .bro file, making it difficult to separate the exact condition that triggered the alarm. Hence, alarms triggered by an embedded Bro rule will not have a specific bro identification number, nor will the signature code block appear in the report.

Possible types of embedded bro rule alarms

AddressDropped	AddressScan	BackscatterSeen
ClearToEncrypted_SS	CountSignature	DNS::DNS_MappingChanged
DNS::DNS_PTR_Scan	FTP::FTP_BadPort	FTP::FTP_ExcessiveFilename
FTP::FTP_PrivPort	FTP::FTP_Sensitive	FTP::FTP_UnexpectedConn
HTTP::HTTP_SensitiveURI	HotEmailRecipient	ICMP::ICMPAsymPayload
ICMP::ICMPUnpairedEchoReply	ICMP::ICMPConnectionPair	IdentSensitiveID
LoginForbiddenButConfused	LocalWorm	MultipleSigResponders
MultipleSignatures	OutboundTFTP	PasswordGuessing
PortScan	RemoteWorm	ResolverInconsistency
SSH_Overflow	SSL_SessConIncon	SSL_X509Violation
ScanSummary	SensitiveConnection	SensitiveDNS_Lookup
SensitivePortmapperAccess	SensitiveLogin	SensitiveSignature
SensitiveUsernameInPassword	SignatureSummary	SynFloodEnd
SynFloodStart	SynFloodStatus	TRW::TRWAddressScan
TerminatingConnection	W32B_SourceLocal	W32B_SourceRemote
ZoneTransfer

General Process Steps

The following steps will both aid the Bro user with uncovering network activity of interest, and also help acquaint the user with the anomalies that Bro detects, together building up an understanding of what constitutes "normal" network traffic for the local site. The analyst might follow each successive step with each incident until a firm determination is made if the incident is malicious or a "false positive".

• Understand What Triggered the Alarm(s)
• Understand the Intent of the Alarm(s)
• Examine the Session(s) from the HTTP, FTP, or SMTP Logs
• Examine the Connection Logs for Breakin Indicators
• Examine for Connections to Other Computers
• Examine Other Bro Logs for Odd Activity
• Examine the Bulk Trace if Available
• Contact and Question Appropriate People

Understand What Triggered the Alarm(s)

To understand what triggered the alarm, compare the signature or rule code with payload. The network traffic that matches the signature, rule, or policy is known as the payload. The payload that triggers the alarm is usually included in the Bro's incident report. Often it is obvious that the payload is not malicious.

Example The signature may trigger on the word shadow, notifying that someone may be attempting to download the shadow password file. However, the payload may reveal that the actual download is something like theshadow.jpg, which is obliviously innocuous.

The two kinds of alarms, converted signatures and embedded rules trigger alarms differently, so they must be treated separately. The following sections describe how to investigate the signature or rule code and payload of each.

Converted Snort Signatures

These signatures are recognizable by the inclusion of a bro number and the identification SensitiveSignature. A signature code and payload block should be present in the incident report. To understand what triggered the alarm, compare the payload to the signature code and find the defined signature within the payload. Since some payload lines can get extremely long, the payload lines in the report and notice and alarm logs has been truncated to 250 characters. Sometimes the actual trigger payload is beyond the 250 character cut off. In this case, the protocol sessions log file must be examined. @xref{Examine HTTP FTP or SMTP Sessions}.

Embedded Bro Rule

For alarms triggered by an embedded Bro rule the signature code block will not appear, and in many cases, neither will the payload. There is currently no direct way to find the specific Bro rule that triggered the alarm other than to search the Bro policy files. Following is a process for conducting that search. The example of the HTTP_SensitiveURL is used. In actual practice, this rule appears quite often in the reports.

Read about the specific analyzer In the Bro Technical Reference Manual there are sections for each type of analyzer. In the case of our example the HTTP analyzer is the obvious choice. In the section on the HTTP analyzer, it is noted that the variables sensitive_URIs and sensitive_post_URIs are responsible for flagging sensitive URIs.

Find the policy file that defines these variables Using egrep to search for sensitive_URIs and/or sensitive_post_URIs yields the following:

> egrep "sensitive_URIs | sensitive_post_URIs" http*
http-request.bro:   const sensitive_URIs =
http-request.bro:  # URIs that match sensitive_URIs but can be generated by worms
http-request.bro:   const skip_remote_sensitive_URIs = /\/cgi-bin\/(phf|php\.cgi|test-cgi)/ &redef;
http-request.bro:   const sensitive_post_URIs = /wwwroot|WWWROOT/ &redef;
http-request.bro:   if ( (sensitive_URIs in URI && URI != worm_URIs) ||
http-request.bro:   (method == "POST" && sensitive_post_URIs in URI) )
http-request.bro:   skip_remote_sensitive_URIs in URI )

Clearly http-request.bro is the file of interest. If, in the case of other types of analyzers, more than one file appears, look for the place where the const statement is used to declare the variable(s).

Look into the policy file Search in the section of Bro policy code that describes the rule(s) for the specific notification. In the file http-request.bro, is found:

export{
  const sensitive_URIs =
     /etc.*\/.*(passwd|shadow|netconfig)/
     | /IFS[ \t]*=/
     | /nph-test-cgi\?/
     | /(%0a|\.\.)\/(bin|etc|usr|tmp)/
     | /\/Admin_files\/order\.log/
     | /\/carbo\.dll/
     | /\/cgi-bin\/(phf|php\.cgi|test-cgi)/
     | /\/cgi-dos\/args\.bat/
     | /\/cgi-win\/uploader\.exe/
     | /\/search97\.vts/
     | /tk\.tgz/
     | /ownz/        # somewhat prone to false positives
    &redef;

    # URIs that match sensitive_URIs but can be generated by worms,
    # and hence should not be flagged (because they're so common).
    const worm_URIs =
         /.*\/c\+dir/
         | /.*cool.dll.*/
         | /.*Admin.dll.*Admin.dll.*/
    &redef;
}

redef capture_filters +=  {
       ["http-request"] = "tcp dst port 80 or tcp dst port 8080
                           or tcp dst port 8000"
};

# URIs that should not be considered sensitive if accessed remotely,
# i.e. by a local client.
const skip_remote_sensitive_URIs = /\/cgi-bin\/(phf|php\.cgi|test-cgi)/
&redef;

const sensitive_post_URIs = /wwwroot|WWWROOT/ &redef;

Unfortunately, there isn't any way of knowing exactly which one of these rules triggered the HTTP_SensitiveURL alarm. As will be seen in the next section, the triggering payload must be compared against this entire section.

Understand the Intent of the Alarm(s)

While understanding the technical signature or policy "code" that "triggered" the alarm, it is also useful to understand the reason the trigger was built.

• What attack or malicious behavior is the alarm trying to illuminate?
• What is the normal method of attack ... manual? automated? expert? novice?
• How long has the particular attack existed?
• How often is it seen? How often is it actually used by attackers?

All of these things, and any other information that can be gathered, will help in differentiating attacks from legitimate behavior. Although this process may seem tedious and time consuming in the beginning, the Bro analyst will quickly build up a substantial knowledge of known attacks. Even if the incident in question turns out to be benign, the effort to learn about the attack almost always proves useful in future investigations.

Converted Snort Signatures

Since Snort signatures are usually fairly well documented, one way to discover the intent of the signature is to search the web for the title of the signature using any of the common search engines (Yahoo, Google, Teoma, AltaVista, or one of the may others). For instance, a search on the MS SQL xp_cmdshell vulnerability yields ~7000 hits. One of those hits is:

Zone-H.org * Advisories
... Successful exploitation of this vulnerability can enable an attacker to 
execute commands in the system (via MS SQL xp_cmdshell function). ...
www.zone-h.org/advisories/read/id=4243 - 17k - Cached - Similar pages

This web site give a fairly detailed description of the exploit and verifies that it can be used to root compromise a computer and hence, is a vulnerability of significant interest. Several other sites also give details about the signature, the attack, and other useful information.

Embedded Bro Rule

Unfortunately, most of the embedded Bro rules have not been documented. The analyst must rely on his/her own understand of network attacks to guess what the intent of the rule is. Sometimes useful comments are written into the Bro policy source.

Examine HTTP FTP or SMTP Sessions

These three files record session activity on ports 80(http), 21(ftp), and 25(smtp) respectively. If the alarm involves any of these ports, these files may reveal the details of the sessions. The general format of all three files is: date/time[SP]%sessionnumber[SP]Message

where: date/time is the time in UNIX epoch time. The cf utility can be used to convert this time to @cite{readable} time. Reference Tech Manual

sessionnumber is the number assigned to session. All subsequent records in the file that are part of the session will retain this same session number. Session numbers are prefixed with the @samp{%} sign.

message is the message that Bro policy has formed to describe the session event. Typically the message will be:

• the start of the session, including the two ip addresses involved
• an anomolous event
• the full protocol command line that was sent
• short statistics concerning the transaction (e.g. bytes sent)

In an alarm where the session number is given (typically in a SensitiveSignature alarm), a search on the session number in the appropriate file(s) will show the full sessons. @xref{The bro/logs Directory}.

Example: Consider the following alarm:

Alarm: HTTP_SensitiveURI
      11/22_12.52.42                128.333.48.179 -> 80.143.378.186
                                          3091/tcp -> 80/tcp
      session: %73280
      payload: GET\/NR/rdonlyres/eirownz4tqwlseoggqm2ahj5cqsdbedlaxyye
               7kvdz7rnh6u4o2v2gpvmoggqjlekzdtulryyatiinj3xwimmiavgfb/
               smallshoulders.gif\ (200\ "OK"\ [1134])

From the payload shown, it is unclear what triggered the alarm. To investigate further, the entire session can be viewed:

Example:

> grep %73280 http.hostname.04-11-22_12.52.42 | cf
Nov 22 15:18:30 %73280 start 128.333.48.179 > 80.143.378.186
Nov 22 15:18:30 %73280 GET /fitness/default.htm (200 "OK" [10473])
Nov 22 15:18:30 %73280 GET /javascripts/cms_common.js (304 "Not Modified"[0])
Nov 22 15:19:47 %73280 GET /food_nutrition/default.htm (200 "OK"[13177])
Nov 22 15:19:47 %73280 GET/NR/rdonlyres/eirwwu3xtlr22dkat5cim4ziupouzxb6kz4xb
zbr4zs255ca57cvv5mhcjcrmrfg6kpcrevyndo2za3yoi5esheiolf/News111904Dairy NotFor Diet.jpg (200 "OK" [6572])
Nov 22 15:19:51 %73280 GET /NR/rdonlyres/0D25692F-D59A-4B90-AB53-8BBC9E75A286. gif (200 "OK" [189])
Nov 22 15:19:51 %73280 GET /NR/rdonlyres/eqpbdbex34wpqpagp2fcbxh35omcjtq45feyf7zgtjff6fhrybfbsvtszeu4rc2clayghhslfimaafkoocae6cv6wof/doctor.jpg (200 "OK" [1615])/NR/rdonlyres/enhskrfoodzuquvmbli2hasjspusrgsvyhbd3nlue5msoli2ueagrwdxw56gqaaa7sosee3yn2hwywcg6kgv4wcv6jc/bigback.gif (200 "OK" [8192 (interrupted)])/NR/rdonlyres/ej2cpd275ghrefp23ezou43haqe6fmj3oyeqxkvopf4bv4zhwbqimfrrbndqpotx55pogc7xiqvdcovaxo66afyqfof/smallleg.jpg (200 "OK" [1010])
Nov 22 15:22:12 %73280 GET /NR/rdonlyres/eirownz4tqwlseoggqm2ahj5cqsdbedlaxyye7kvdz7rnh6u4o2v2gpvmoggqjlekzdtulryyatiinj3xwimmiavgfb/smallshoulders.gif (200 "OK" [1134])
Nov 22 15:22:13 %73280 GET /NR/rdonlyres/49D86A33-AF6C-4873-AD11-F26DDBF222B1.gif (200 "OK" [167])

By examining this session it can clearly be seen that the session is simply a web visit to a fitness website. There is no need to investigate further.

Examine the Connection and Weird Logs

The connection logs are a record of every connection Bro detects. Although they don't contain content, being able to track the network movement of an attacking host is often very useful.

Breakin Indicators

If it is still not clear if a suspect host is an attacker, the connection surrounding the suspicious connection can be examined. Here are some questions that might be answered by the conn logs. itemize item How many more successful connection the attacker make to the target host? item How much data was transfered? A lot of data means something more than an unsuccessful probe. item Did the target host connect back to the attacker? This is a fairly sure sign of a successful attack. The attacker has gained control of the target and is connecting back to his own host. item What was the time duration? If several attacks occur in a very short time and then slow down to human speed, it could indicate the attacker used an automated attack to gain control and then switched to a manual mode to "work on" the compromised target host.

Connections to Other Computers

If a host has been successfully identified as an attacker, it is useful to know what and how many other hosts the attacker has touched. This can be found by grepping through the conn logs for instances of connections by the suspect host.

example here

If the attack used a specific, little used, port; another investigation would be to search for other similar connection using that port. Often the attacker might change attack hosts, but will continue to use the same attack method.

example here

NOTES However, be forwarned that the conn logs tend to get very large and doing extensive searches can take a very long time.}

Odd Activity

Despite attempts to have the network community adhere to network standards, non-compliant traffic occurs all the time. The weird logs are a record of instances of network traffic that simply should not happen.

While these logs are usually of interest to the most hard-core of network engineers, if a unique attack is detected, it is sometimes valuable to search the weird logs for other unusual activities by the attacking host. Hackers are not bound by standard protocol and sometimes find ways to circumvent security via weird methods.

Examine the Bulk Trace if Available

For information on using the Bulk trace files for analysis, see Bulk Traces and Off-line Analysis.

Contact and Question Appropriate People

The final and usually the most definitive investigation is to call the owners of the hosts involved. Often a call to the owner of the local host can reveal that the activity was not normal, but appropriate or a mistake.

User Manual Overview of Bro | Requirements | Installation and Configuration Running Bro | Bro Output | Analysis of Incidents and Alarms | Customizing Bro Intrusion Prevention Using Bro | Performance Tuning | Bulk Traces and Off-line Analysis Reference Manual