Detection of all attacks in pcap file

Zeek
1

Hi all,

I am beginner in Zeek. Currently, I have a task to perform analysis of . pcap files and detect all possible attacks per time instances. In the other words I have to test Zeek as an IDS tool and find with which percentage is Zeek able to classify traffic correctly (True/False positive, True/False negative indication). Is there possibility to do so? For example, I tried to run integrated Brute-Forcing.zeek script against my .pcap file but in the notice.log there is just note that there was an attack which is not what I am looking. Do I have to search for labeled network in some other logs?

Thanks in advance

Borivoje

2

Hello,

The notice log would contain any information pertaining to the policy/protocols/ssh/detect-bruteforcing.zeek script.

However, I’m a little concerned by the nature of your task. Zeek isn’t really designed as an “intrusion detection system” like Snort or Suricata. Is this a school project?

Sincerely,

Richard

3

Hi Borivoje and Zeek users,

Traditionally, analyst uses Zeek to transform their network traffic into compact logs that describe a variety of activities. Rather than recording full content in a .pcap if you’re interested in a FTP session, for example, Zeek will create one or more logs describing the important elements of that FTP session. There’s no concept of “good” or “bad” in that log, or in most logs.

So, the premise of comparing Zeek as an IDS with Snort or Suricata doesn’t make much sense. You would be better off comparing Snort with Suricata, as they are both designed as intrusion detection systems, i.e., they render judgments based on the traffic they observe. Of course you need to provide rule sets, which contain the essence of “badness” as designed by the rule creators.

You could conceivably program Zeek to be an IDS if you decided what was bad on your network and told Zeek to write a notice when it sees that activity. Running default Zeek against a data set from the Internet is not going to yield the results your professor is seeking.

Sincerely,

Richard

4

That’s generally what IDS users want to know — what activity is normal, suspicious, or malicious?

Richard

5

It would be extremely difficult to compare IDS systems and here are a couple of reasons why.

What does it mean, to compare IDS systems? Would you compare the performance? Sure, this one can be measured, but it’s so much ruleset dependent that it rarely makes sense.

Detection accuracy? All of them basically perform the same job - reassemble a number of packets in a stream, compare that stream against a huge dataset, flag matches. If one of those components does not work correctly, for example, IDS X can correctly reassemble TCP flows 99% of time, it is either a bug in the engine or there is something wrong with the capture, or there are performance problems.

Then it comes the comparison of “how many alerts will IDS X generate vs IDS Y vs Z for the same input”. You’re not really comparing IDS-es again, but the set of rules. Some rules can be used by multiple engines, like the Emerging Threats has versions for both Snort and Suricata. Some don’t - like the commercial Palo Alto Networks.

Finally, you have the “neutral” engines, like Zeek (or Suricata without any rules and with flow and protocol logging enabled in eve-json). They do not tell what is good and what is bad - because that’s up to you. They merely tell you about a connection that happened in the past, was from A to B, N bytes and packets were sent and M bytes and packets were received, it took 5 minutes and it was SSL.
In case of Zeek or Suricata you can have protocol analysis done, so for our SSL connection, you will see the SNI, ciphersuites negotiated, X509 certificate details and so on.

At this point nothing is technically good or bad. Now, you as an analyst can feed Zeek with rules saying “connections to or from IP A are always bad” - and Zeek will let you know when those happen (or try to happen).

Or you can say “all SSL connections with a certificate with a serial number 12345 are bad” or flag a domain name in many places (not just the DNS traffic), calculate file hashes, analyze PE files, SMB and RPC sessions, etc.

NSM like Zeek is basically like a giant time machine + a matching engine + an engine that can do almost arbitrary operations on network flows. It’s up to you to program it.

And that’s why I think it cannot be compared with IDSes like Snort (purely rule based) or Suricata (a combination of a traditional IDS with NSM functionality).

Comparing Snort vs Suricata doesn’t make sense either - because you would be comparing rulesets, not engines.

6

Looking at the page I found for CICIDS2017, it seems like there are specific attacks enumerated on the page that describe the traffic in the PCAPs. Roughly the captured behavior seems like it can be broken down into reconnaissance, specific exploits, botnet activity, implant activity, and DoS. There is included already scanning and ssh brute force detection, an example provided of how to set up FTP brute force detection, as well as a blog post on Heartbleed detection in Zeek, that was arguably more robust than the signature based detections that went out at the same time. I encourage you to check these resources out!

Your results with Zeek will depend on just how deep down the rabbit hole you are willing to go. The exploits and implants will likely not be detected by Zeek “out of the box”, the same likely goes with the DoS detection (though the SumStats framework may help here with some quick wins). Some could likely be caught with good IOC (domain, IP) feeds, transformed into something usable by Zeek, and fed into Zeek’s intel framework. Other exploit / implant detection might require further log analysis or some scripting. Some might only be detectable by bytestream signatures. It’s hard to tell without digging in further.

As others have explained, Zeek “out of the box” can provide useful telemetry, in the form of network protocol logs, that could be used downstream, in either some sort of SIEM, rules engine, or similarly purposed data infrastructure, to not only detect such attacks, but provide a fuller context to incident responders running down these detections, who might need later follow-up information that the pattern matching based approaches would not have preserved. As others have also said, Zeek makes more observations than judgments, and it is up to the operator what response to take to these observations.

Without knowing more about those specific DoS attacks or exploit based attacks, it’s hard to know what would show up in the standard logs, but it could be an interesting exercise to run the PCAPs through default Zeek, feed the logs to Splunk or ELK, look for patterns that you might be able to discern and write rules for them, either in the downstream log processor, or in Zeek scripting language itself. I encourage you to consider Zeek as a crucial source component of your overall security detection stack, rather than a full-stack, fully-calibrated network detection engine in a box.

One cool thing about Zeek vs most signature based IDS systems is that it Zeek reaches as deep as it can into the protocols it understands, and makes even more information available than it does by default to operators who are willing to dive into script land. If you know what you’re looking for, and it’s observable on the network, chances are there’s a way to analyze it with a Zeek script. As an example, Corelight recently published an overview of such work for SSH analysis. Zeek offers a diverse set of Protocol Analyzers that provide a rich stream of events that can be hooked to suit your every purpose. There’s also a collection of packages to explore if you’re interested in learning more about scripting. If you have an hour, or two, I’d also check out this talk which I found helpful in explaining what it is you’re signing up yourself up for :slight_smile:

All the best
Jamie