Detection Engineering With Snort | TryHackMe | detection challenge

Build production-ready Snort detections: behaviour rules, tuning, suppression, and IOC lifecycle.

Disclaimer: This blog post is based on a walkthrough hosted on TryHackMe and it is intended for educational purposes only.

The Snort room covered the basics of running Snort, including loading a config, reading a PCAP, and writing rule syntax. That is the starting point, and this room builds on it.

Detection engineering is the work that begins after the tool is running. We write rules that fire on what matters, keep them silent on what does not, tune them as the network changes, and validate that they still work next week. This is what separates a SOC that runs a downloaded ruleset from one that defends its own network on purpose.

Learning Objectives

In this room, we walk the intrusion chain phase by phase and write a detection rule for each one. By the end, our ruleset covers the following:

• A behaviour-based C2 beacon rule
• A DNS tunnelling rule that works on encrypted payloads
• Thresholds and suppression to keep the ruleset quiet
• A reputation blocklist loaded with Operation SILENT TRANSFER IOCs
• A tested local.rules file ready to ship

🛠️ Type: Walkthrough

👤 Role: SOC Analyst

💪 Difficulty: Medium

🔗Link : https://tryhackme.com/room/detectionengineeringwithsnort

Which workstation fires this rule most often after fixing flow direction, despite never making an outbound GET request?

After tightening the content match to content:"GET ", depth 4, how many alerts does the rule produce?

After writing the behaviour-based rule and running it against task-03-beaconing.pcap, how many alerts does it produce?

What is the source IP address of the host that crosses the detection threshold in task-03-beaconing.pcap?

Before adding any suppression entry, how many total alerts does Snort produce against task-04-noisy-traffic.pcap?

After suppressing 10.14.22.199, how many alerts does Snort produce against task-04-noisy-traffic.pcap?

After enabling the reputation inspector and running it on task-05-ti-integration.pcap, how many alerts are produced?

How many false positive alerts fire when running the shipped ruleset against task-06-clean.pcap?

After fixing sid 1000005 and re-running against task-06-dirty.pcap, how many times does the corrected rule fire?

Detection Challenge

source: https://tryhackme.com/room/detectionengineeringwithsnort

Before adding the suppression entry, how many alerts does the beacon rule produce?

Which source IP on the Finance subnet is responsible for the beacon-rule noise that must be suppressed?

After adding the suppression entry, how many SID 1000100 alerts remain?

After loading the blocklist, how many reputation inspector alerts appear in the final summary?

The Detection Engineering Mindset

Three habits separate operating Snort from engineering detection with it.

• Detect behavior, not signatures. Attackers swap tools more often than they swap tradecraft. A rule built around the attacker’s behavior continues to work even when the domain rotates, the payload is recompiled, or the channel switches to QUIC. A rule built around a specific byte string fails the moment the operator edits a line of code.
• Tune before you ship. A noisy rule that nobody reads is worse than no rule at all. Every false positive crowds out an alert that actually matters. A well-running SOC does not just write rules; it tunes them, thresholds them, and retires them when they stop working.
• Validate every change. The three-pass cycle (positive test, negative test, performance profile) applies to every rule before it leaves staging. Running the cycle takes minutes. Skipping it is how outages happen.

What Snort Still Cannot See

Snort fires on rule matches. Anything our rules do not describe stays invisible to it. Snort cannot see connections that no rule matches against, encrypted channels where there is no plaintext payload to inspect, or first-appearance traffic that no threat feed has flagged yet. All three sit outside this room’s coverage.

When we need to investigate traffic that did not produce an alert, Snort alone is not enough. That is where Zeek comes in. Zeek writes a structured log line for every connection, every DNS query, and every TLS handshake, regardless of whether a rule fired. When we need to know what crossed the wire without alerting, the Zeek logs are the starting point. This point is addressed in the next room on Zeek.