Home Lab Journal

Structured attack and defence practice

Six sessions documenting what I did and what I learned across Wazuh, Splunk, LimaCharlie, and Kali Linux. Built on two Proxmox hosts connected via a TP-Link managed switch, with segmented VLANs separating the red team from the targets.

GMKtec — pfSense + Mint Linux jumpbox Beelink — Wazuh + Splunk VLAN 10 — Kali Linux VLAN 20 — Metasploitable 3 Ubuntu / Windows, Windows 10, Ubuntu LTS
Session 1

Reconnaissance scan against Metasploitable 3

10 May 2026 Wazuh · Splunk · LimaCharlie T1046 — Network Service Scanning
What I did
  • Ran a ping sweep across the lab subnet with nmap, then a full service and version scan against Metasploitable 3 Ubuntu
  • Watched the alerts generated in Wazuh, Splunk, and noted what each tool surfaced from the same scan
What I learned
  • Wazuh fired individual service alerts but no single alert tied them together as one port scan — correlation requires a custom rule
  • nmap signs its own name in logs: NmapNSE_1.0 and NmapSSH1-Hostkey visible in raw Splunk events, making the scanner immediately identifiable
Session 2

Detection engineering — fixing log collection and writing a custom rule

10–12 May 2026 Wazuh T1046 — Network Service Scanning
What I did
  • Discovered Wazuh was not reading Apache logs due to Linux file permissions — fixed by adding the Wazuh user to the correct group
  • Wrote a custom Wazuh detection rule (Rule 100002) that fires a Level 12 alert when multiple web probes come from the same source IP within 60 seconds
What I learned
  • Wazuh only collects logs that are explicitly configured — unlike Splunk which collects everything. A misconfigured agent is silent even during an active attack
  • Custom rules require the parent rule to actually fire before the child rule can trigger — debugging order matters
Wazuh Threat Hunting dashboard showing 206 total alerts, 1 Level 12 alert, and MITRE ATT&CK distribution after log collection fix
Wazuh Threat Hunting dashboard — 206 alerts captured, 1 Level 12 fired after custom rule deployed. MITRE ATT&CK donut shows Valid Accounts and SSH as top techniques.
Session 3

Splunk investigation workflow — reading logs properly to find an attacker

14 May 2026 Splunk T1046 — Network Service Scanning
What I did
  • Discovered all logs were arriving as generic syslog with no parsed fields — fixed sourcetype mapping so source IPs and URLs became searchable
  • Ran a full investigation from zero: identified one IP that produced 200, 404, 405, and 501 status codes — classic scanner behaviour — and traced it mapping every web application on the box
What I learned
  • Without correct sourcetypes Splunk is just storage — no parsed fields means no investigation
  • The correct workflow is: summarise first with stats and timechart, confirm with raw logs last — never start with raw logs
Session 4

LimaCharlie introduction — comparing three tools on the same scan

15 May 2026 LimaCharlie · Wazuh · Splunk T1046 — Network Service Scanning
What I did
  • Ran the same nmap scan and watched how Wazuh, Splunk, and LimaCharlie each reported the same activity differently
  • Explored LimaCharlie's Timeline tab and found a chatbot process (papa_smurf) running as root with USER_ID 0 — a critical risk with no alert raised
What I learned
  • Wazuh gave a high-level alert, Splunk showed granular raw log detail, LimaCharlie showed the exact process tree — 7 sshd children spawned and killed in 10 seconds
  • LimaCharlie ships empty — no default rules fire on a port scan. Detection rules must be written from scratch, which makes it a better learning tool than CrowdStrike
Session 5

First real exploitation — why the SIEM missed it and the EDR didn't

19 Jun 2026 Kali Linux · Wazuh · LimaCharlie T1190 — Exploitation of Public-Facing Application
What I did
  • Used a documented 2010 UnrealIRCd backdoor exploit in Metasploit to get a working shell on Metasploitable 3 Ubuntu
  • Checked Wazuh for alerts — zero. Checked LimaCharlie Timeline — found the full process chain: service spawning a shell, shell downloading a payload with curl, payload executing
What I learned
  • Wazuh is log-file based — this attack never wrote to a monitored log file so it was completely invisible to the SIEM
  • LimaCharlie hooks at the kernel level and sees every process creation instantly, no log file needed — this is the core difference between a SIEM and an EDR
Session 6

Writing a detection rule from scratch to close the gap

20 Jun 2026 LimaCharlie · Kali Linux T1190 — Exploitation of Public-Facing Application
What I did
  • Built a LimaCharlie D&R rule to detect NEW_PROCESS events with "curl" in the command line, wrote matching and non-matching unit tests, then re-ran the live exploit twice to confirm the rule fired on the real attack
  • Verified the hashes of curl and dash against known-good values — both matched legitimate system binaries, confirming living-off-the-land behaviour rather than custom malware
What I learned
  • A detection rule has two parts: Detect (the pattern) and Response (what fires). Writing it felt like filling in a structured form — the real skill is knowing what pattern to look for
  • Unit testing a rule against both a match and a non-match case before trusting it on live data is the correct workflow — a rule that only fires on test data is not validated
LimaCharlie Detections panel showing three suspicious-curl-execution alerts firing on the ubuntu sensor after the detection rule was deployed
LimaCharlie Detections — three "suspicious-curl-execution" alerts firing on the ubuntu sensor at 05:57:56. The rule caught the live UnrealIRCd exploit on re-run, confirming it works against real attack data, not just synthetic test events.
← Back to portfolio