During an incident response process, one of the fundamental variables to consider is speed. If a net capture is being made where we can presumably find evidence that who and how is causing an incident, any second counts in order to anticipate the attacker in the cyber kill chain sequence.

We need to use a passive approach in the analysis of network traffic to be quick in obtaining results. Zeek is a powerful tool to use in these scenarios. It is a tool with network traffic processing capabilities for application level protocols (DCE-RPC, DHCP, DNP3, DNS, FTP, HTTP, IMAP, IRC, KRB, MODBUS, MQTT, MYSQL, NTLM, NTP, POP3, RADIUS, RDP, RFB, SIP, SMB, SMTP, SOCKS, SSH, SSL, SYSLOG, TUNNELS, XMPP), pattern search and a powerful scripting language to process what the incident responder might require.

Zeek scripts work through events. We can find a summary of all possible events that can be used at https://docs.zeek.org/en/stable/scripts/base/bif/event.bif.zeek.html. Next we will review those that will be covered by the examples of this diary:

• new_connection: This event is raised everytime a new connection is detected.
• zeek_done: This event is raised when the packet input is exhausted.
• protocol_confirmation: This event is raised when zeek was able to confirm the protocol inside a specific connection.

We will cover three simple use cases in this diary:

• Top talkers by source IP connection and new connections performed.
• Top talkers by source IP and destination port, with new connections performed.
• Number of connections confirmed by zeek for a specific IP address with a specific protocol.

Top talkers by source IP connection

The following script implements the use case:

global attempts: table[addr] of count &default=0; 
event new_connection (c: connection)
{
    local source = c$id$orig_h;
    local n = ++attempts[source];
}

event zeek_done ()
{
    local toplog=open("toptalkers.log");
    for (k in attempts)
        print toplog,fmt("%s %s",attempts[k],k);
    close(toplog);
}
 

Let's go through the script in detail:

• We will store the result in the attempts table. We will store there IP addresses type addr and count the occurrences with type count.
• Using the new_connection event, we traverse the capture counting source IP addresses that generate new connections.
• Once the packet input is exhausted, using the zeek_done event we create the toptalkers.log file and write the information in the attempts table separated by blank spaces.

Let's see a snippet of the output:

We can get a sorted output:

Top talkers by source IP and destination port, with new connections performed

The following script implements the use case:

global attempts: table[addr,port] of count &default=0; 
event new_connection (c: connection)
{
    local source = c$id$orig_h;
    local the_port = c$id$resp_p;
    local n = ++attempts[source,the_port];
}

event zeek_done ()
{
    local toplog=open("toptalkers.log");
    for ([k,l] in attempts)
        print toplog,fmt("%s %s %s",attempts[k,l],k,l);
    close(toplog);
}
 

Let's review the differences from the previous one:

• Table now includes ports. Therefore, a new type is included in declaration: port.
• The source IP, the destination port and the counter for each repetition of this pair of data in the network capture are stored in the code within the new_connection event.
• Information is written once packet processing is finished to file toptalkers.log.

Let's see a snippet of the script's output:

We can get a sorted output:

Number of connections confirmed by zeek for a specific IP address with a specific protocol

The following script implements the use case:

global attempts: table[addr,Analyzer::Tag] of count &default=0; 
event protocol_confirmation (c: connection, the_type: Analyzer::Tag, aid:count)
{
    local source = c$id$orig_h;
    local n = ++attempts[source,the_type];
}

event zeek_done ()
{
    local toplog=open("toptalkers.log");
    for ([k,l] in attempts)
        print toplog,fmt("%s,%s,%s",k,l,attempts[k,l]);
    close(toplog);
}
 

We can see the some new aspects:

• The Analyzer::Tag attribute: When the protocol_confirmation event is raised, this attribute saves the protocol that was confirmed by zeek to be in the connection.
• Information is stored in the table and then saved to a file within the zeek_done event.

Let's see a snippet of the script's output:

In my next diaries I will cover other interesting use cases with zeek using the frameworks that it has.

Manuel Humberto Santander Peláez
SANS Internet Storm Center - Handler
Twitter: @manuelsantander
Web:http://manuel.santander.name
e-mail: msantand at isc dot sans dot org