Rule one: There are no rules ...
--------------------------------

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.

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.

     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.

     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.  See 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.

     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.

     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).

     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/timeSP%sessionnumberSPMessage

where:

     is the time in UNIX epoch time.  The cf utility can be used to convert this time to readable time. Reference Tech Manual

     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 % sign.

     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.  See 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/eqpbdbex34wpqpagp2fcbxh35omcjtq45feyf7
zgtjff6fhrybfbsvtszeu4rc2clayghhslfimaafkoocae6cv6wof/doctor.jpg (200 "OK" [161
5])/NR/rdonlyres/enhskrfoodzuquvmbli2hasjspusrgsvyhbd3nlue5msoli2ueagrwdxw56gqa
aa7sosee3yn2hwywcg6kgv4wcv6jc/bigback.gif (200 "OK" [8192 (interrupted)])/NR/rd
onlyres/ej2cpd275ghrefp23ezou43haqe6fmj3oyeqxkvopf4bv4zhwbqimfrrbndqpotx55pogc7
xiqvdcovaxo66afyqfof/smallleg.jpg (200 "OK" [1010])
Nov 22 15:22:12 %73280 GET /NR/rdonlyres/eirownz4tqwlseoggqm2ahj5cqsdbedlaxyye7
kvdz7rnh6u4o2v2gpvmoggqjlekzdtulryyatiinj3xwimmiavgfb/smallshoulders.gif (200 "
OK" [1134])
Nov 22 15:22:13 %73280 GET /NR/rdonlyres/49D86A33-AF6C-4873-AD11-F26DDBF222B1.g
if (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

     You may want to go back several days, weeks, months, or even years to see if the attacker has visited (and perhaps compromised) you site earlier without being detected.

     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.