Detecting the DC-1 attack with Suricata — what a network IDS caught, and what walked past it

I’ve already published how I broke DC-1. This is the other half: I wanted to know what a defender would actually have seen while I did it. So I put Suricata in front of the same attack and ran it again from the top. The result surprised me a little — the noisiest things I did were the harmless ones, and the single step that gave me root didn’t show up on the network at all. That gap turned out to be the whole point of the exercise.

This is the defensive companion to my DC-1 penetration test.

Lab setup

• Target: VulnHub DC-1 on an isolated host-only network (192.168.56.0/24), no route to the internet.
• Attacker: Kali Linux on the same segment.
• IDS: Suricata running the Emerging Threats (ET) open ruleset.
• Authorization: my own VMs, isolated lab, nothing real in scope — same rules as the offensive engagement.

Two honest caveats up front:

1. Vantage point is artificial. Suricata ran on the attacker (Kali), sniffing its own interface, not on a SPAN port or tap at a gateway. In a real deployment the sensor sits on the network path, not on the attacking host. So this is a “what would a sensor on this segment see” taster, not a production setup — the traffic it observed is right, the placement is not.
2. No captured alert logs. I didn’t retain the eve.json / fast.log from this run, so everything below is described from my lab notes qualitatively. I’m not quoting alert lines or signature IDs I can’t verify — where I say “an ET signature fired,” that’s what I observed, not a reconstructed log.

The attack, replayed

The same chain as the DC-1 report, with a loud brute-force step added for contrast:

1. nmap — host discovery and service/version enumeration.
2. Drupalgeddon (CVE-2014-3704) — the unauthenticated exploit that gave the original foothold.
3. hydra — a login brute-force run, included deliberately as a “loud” baseline to compare against.
4. SUID find privilege escalation — the local misconfiguration that took www-data to root.

What fired, and what didn’t

Attack step	Network footprint	Suricata result	Why
nmap scan	Many packets across many ports	Loud — lots of alerts	Scanning is inherently noisy; port-sweep behaviour is exactly what scan signatures look for
Drupalgeddon (CVE-2014-3704)	Only a handful of packets	Caught, precisely	A specific ET signature exists for this CVE — so it’s flagged despite the tiny volume
hydra brute-force	Many repeated login attempts	Loud — alerts kept coming	Brute-force = many packets in a recognisable pattern
Post-exploitation inside DC-1	Almost nothing new on the wire	Quiet	Actions ran inside an already-established session; little for a signature to grab
SUID find → root	Zero packets — 100% local	Invisible	A local privilege escalation generates no network traffic at all

The lesson: volume ≠ detectability

The instinct is to assume “more traffic = easier to catch.” This lab says otherwise, in both directions:

• Drupalgeddon was tiny but caught. A few packets, and Suricata flagged it precisely — because a signature for that exact known attack exists. A quiet, known attack still gets caught. Detection tracks whether a signature matches, not how much noise you make.
• The loudest steps were the least dangerous. nmap and hydra generated the most alerts, but they’re only recon and credential-guessing — early warning, not a breach. Catching them tells a defender someone is knocking, not that someone is in.
• The step that actually gave me root was silent. The SUID find escalation — the move that turned a limited web shell into full administrative control — produced zero packets and was completely invisible to the network IDS.

That last point is the whole argument. The most consequential action in the entire kill chain was the one a network sensor could never see.

Why this argues for defense-in-depth

A network IDS sees the network. It is structurally blind to anything that happens locally on a host — privilege escalation, local file abuse, in-memory tradecraft. Drupalgeddon crossed the wire, so Suricata had a shot at it; the find privesc never left the box, so it didn’t.

The fix isn’t a better network rule. It’s a second layer looking at the host itself:

• Network detection (Suricata) catches the entry — the exploit crossing the wire.
• Host detection (Wazuh / auditd / an EDR agent on the box) is what catches the local half — the SUID abuse, the new root shell, the file reads.

Network + host = layered detection, and the DC-1 chain is an almost perfect teaching case for it: neither layer alone sees the whole attack, but together they cover entry and escalation.

What I’d change next

Turning this taster into something closer to real:

1. Move the sensor to a proper vantage point — a SPAN port or tap at the gateway, not the attacker host.
2. Retain and parse the logs — keep eve.json, feed it into a small SIEM/dashboard, and actually quantify the alerts instead of eyeballing them.
3. Add a host agent on the target — put Wazuh (or auditd) on DC-1 and re-run the privesc, to catch the exact step Suricata missed here. That closes the visibility gap this lab exposed.
4. Tune the noise — the scan/brute-force alerts drown the signal; some tuning (or rate-based rules) would make the high-value exploit alert stand out.

Takeaways

• Signatures catch known attacks regardless of volume. A small, recognised exploit is caught; a loud unknown one might not be.
• Local actions are invisible to a network IDS. The most damaging step here — privesc to root — produced no traffic.
• Detection coverage is about vantage point and layers, not packet count. You need network and host visibility, because each is blind to what the other sees.