CRON jobbing with alerts that won't fire
Cron logged every check-in to syslog automatically, and Wazuh ingested every line of it, but nothing in the default ruleset ever turned a plain CRON entry into an alert. Suricata caught it from a raw-IP curl heuristic instead.
Third and last attack against the Homelab. The nmap scan was structurally invisible to the host layer, nothing to log, ever. The Samba exploit was a configuration gap, the data could have existed on the host but nothing was pointed at it. This one is neither. I picked cron specifically because it logs every execution to syslog automatically, which Wazuh already ingests by default.
Setting up a fake implant
lab-isolated has no route out at all, so the “malicious” IP a real implant would beacon to had to be my own attacker box, kali-pentest, running python3 -m http.server 8080 as a stand-in listener. On nxtserver, a per-minute cron line: curl -s http://192.168.100.218:8080/checkin >/dev/null 2>&1.
What actually happened
The listener caught seven check-ins landing at almost exactly one-minute intervals, 18:19:02 through 18:25:02, a clean, periodic pattern. Each one a GET /checkin returning 404, since nothing was actually there. I just wanted to see if I could get it to detect what C2 usually does.
I checked Suricata’s eve.json for the same window expecting nothing. Plain periodic HTTP with no known-bad content or reputation-listed destination felt like exactly the kind of thing a signature engine has nothing for. Wrong, I actually saw alerts! Which was pretty cool to see.
Then I checked nxtserver’s syslog for the cron executions and got almost nothing back, plus a grep: /var/log/syslog: binary file matches warning. Plain grep had flagged the file as binary and silently swallowed the real matches. Re-running with grep -a pulled every execution back verbatim, one CRON[...] CMD (curl -s http://192.168.100.218:8080/checkin ...) line per minute, timestamps matching the listener exactly.
Then the dashboard, for the same window. Zero rows referencing any of the CRON executions. The only host-layer entries present were the same PAM and sudo noise from my own SSH sessions that showed up in both earlier attacks.
What fired
Network: ET HUNTING curl User-Agent to Dotted Quad, sid 2034567, category “Potentially Bad Traffic,” severity informational. Fired on every single check-in, no exceptions. It’s a HUNTING-tier heuristic, deliberately low confidence, built for exactly this shape of traffic, curl’s default user agent hitting a raw IP instead of a hostname, which is also what a lot of harmless scripting looks like, hence the low severity.
Host: nothing. The cron executions were sitting in nxtserver’s own syslog the entire time, complete and correctly timestamped. Wazuh’s agent does ingest syslog. But logged and alerted are two different tiers, and nothing in the default ruleset promotes a plain CRON line into something that shows up in Threat Hunting.
The gap that’s different from the first two
Three attacks, three different reasons the host layer missed it, and that turned out to be the actual finding, not three repeats of the same result. The scan was structural, nothing to see. The Samba exploit was a configuration gap, the signals existed but nothing was watching them. This one was a lot harder to figure out than the other two. The sensor was watching, the data reached it intact, and the option that could turn “logged” into “alerted” simply didn’t exist! “The data was captured” and “an analyst would ever see an alert for it” are not the same claim, and from a dashboard, this failure mode looks identical to having no visibility at all, even though the raw logs had everything!
ET Open’s own signature already covers the shape of this traffic. What it doesn’t cover is the pattern behind it, one raw IP curl request looks the same whether it’s a person typing a command by hand or the fifth check-in from a real implant. Closing that piece of the gap myself, and what a signature engine can and can’t honestly claim to detect, is its own story.
What I took away
I went in assuming a signature-based network sensor would have nothing for harmless, content-free periodic traffic, no CVE, no malware string, nothing to pattern-match. I was wrong, and ET Open’s HUNTING category exists for precisely this kind of behavioral heuristic. The key lesson I learnt is that you can have all the information you want but if it never gets delivered to you at the right time or place, it’s useless.
Limits
Like I said in the summary, this is a naive, fixed-interval beacon that could be easily bypassed. It’s also relying on the beacon using plaintext HTTP with a stock curl user agent. A slower C2 interval or a spoofer would completely dismiss even the built in detection Suricata had.