NBE analysis

What need to be remembered is  that incident response appears when the standard, or automatic security controls fail. We have tons of network/security appliances in our companies, tons of false-positive alerts and very often sophisticated malware or attack occurs and shows where do we have a security gap.

NBE is the information that is gathered (or can be reactively) from network nodes such as routers, DNS servers, taps, hubs .etc. This is all packages that can be catched by any network device  supported with  standard formats. This is all information that can be found in network traffic. It allows confirming and determining whether incident occurred or not. In another words this is the type of data that is complementary to information obtained from live response – usually only this data is available. 

There are 4 types of NBE information that can be taken from standard network traffic.

       a)      Full content data

         Consists of packages payload ,the entire content can be read depending on the use of 

         encryption. 

        

       b)     Session data

        This in nothing else than the aggregation of packages. Odd traffic can be easily  

        noticeable. We get  information about protocol, source/destination IPs and ports. The best

        way to  check what  happened  after attack.  

      c)      Alert Data

        IDS is programmed to recognize patterns of bits, specific  sorts of malicious activity,
        and other traffic that matches any signs of violations.

      d)     Statistical Data

        What we get is simple summarize  of traffic obtained in specific time   

      frame. There are  values describing percent of protocols used, number of packages  

      transported and so on.  

How to analyze network based evidence in post-mortem approach ? I am listing and shortly describing tools that will help us achieving this goal.

     

Statistical Data

Tcpdstat is a simple and powerful tool for creating summarize and statistics for traffic found in tcpdump (or other sniffing tool supporting libpacp).

Output will give us the idea about - how big and how long trace do we have, what protocols have been used, how many packages transported and the sizes.

tcpdstat evidence.raw  > output /statistical_output.txt

Documentation : http://www.sonycsl.co.jp/~kjc/papers/freenix2000/node14.html

Download : https://github.com/netik/tcpdstat

Alert Data

 Alert data are taken from Intrusion Detection System. It depends how are we obtaining NBE –   

 reactively or proactively – but here we gonna check how to use snort in batch mode.

 snort -c  /etc/snort/snort.conf -r /home/user/NBE/evidence.raw -b -l /var/log/snort/

 Using this command we are telling snort just to act as a standard IDS, but in this case as input we are using previously acquired traffic dump. Also /etc/snort/snort.conf need to be set up correctly and be filled with directory to Snort rules. As output we are getting two files :

a) Alerts

b) Snort log file - presenting packages in which snort found suspicious patterns

Documentation : http://www.snort.org/

Session Data

     

Using tools such as argus or tcptrace we can recreate sessions established from raw traffic dump. The output will be simple and showing the time frame, protocol, source port, IP with destination, and state of connection or reply and bytes transported.

Recreating with Argus :

argus -d -r /home/user/NBE/evidence.raw -w evidence.argus

Next runnning argus client ra to view session data in text format:

    ra -a -c -n -r evidence.argus > captured_session.txt

 Please, check also the possibilities supported by tcpdump:

tcpdump -n -r evidence.raw > evidence_full_session.txt 

 To build the session data tcptrace can be used:

tcptrace -n -r evidence.raw  > session_data.txt

        Documentation and Download : http://www.tcptrace.org/, http://www.qosient.com/argus/.

Full Content Data

       In this part, we are checking what details are hidden in the raw packages – after following clues found in previous layers of NBE. Firstly, we can easily use tshark to convert raw traffic evidence to more readable and human friendly format :

      tshark -x -r evidence.raw > fullcontent.raw

       The output will show us from which communication is every package (session data available), presenting data in hexadecimal and ascii format. Here we are looking for “known” patterns or supporting information for our previously found clues.

       We can try to literally recreate full sessions from the raw file. Within session data, the only thing done with tcptrace was the list all session information. Here we gonna build the session one more time, and view all information transported between hosts.

       To maximize usefulness of this evidence we can filter what we are looking for. Imagine, that you had found some suspicious behavior on port  5454 or 2323. To recreate session use:

      tcpflow -r evidence.raw port 5454 or 2323

       As the output you will be given with 4 files, or 4 session. Examining them will give you any information that was transported between hosts.

   

       Documentation and download : http://www.circlemud.org/jelson/software/tcpflow/, http://www.wireshark.org/docs/man-pages/tshark.html

       For other related tools please visit this page : http://www.tcpdump.org/related.html