The topology

┌────────────┐     ┌───────────────────────────┐
│  pfSense   │────▶│  LAN segment (management)  │
│ (router)   │     └───────────────────────────┘
└────────────┘              │
        │                   │
  ┌─────┴──────┐    ┌───────┴────────┐
  │ Wazuh      │    │ Victim VMs     │
  │ manager    │    │ Win11, Ubuntu  │
  │ (ELK stack)│    │ (sysmon/auditd)│
  └────────────┘    └────────────────┘

Why these tools

• Wazuh — free, has a great agent story for both Windows (Sysmon) and Linux, and ships useful out-of-box rules before you write your own.
• pfSense — separates my lab from my home network and logs everything at the perimeter.
• Suricata in line with the switch SPAN port gives me network detection practice.

What I practiced first

1. Getting telemetry flowing: agents → manager → dashboards.
2. Tuning noise — the hardest part of SOC work, honestly.
3. Writing my first custom rule: alert on Kerberoasting-style TGS requests (event 4769 with RC4 encryption type).

- rule:
    level: 10
    description: "Possible Kerberoasting via RC4-encrypted TGS request"
    windows:
      - event_id: 4769
    filter:
      - keyword: "rc4_hmac"

Cost & effort

A retired desktop with 64 GB RAM is plenty. Expect an evening to stand it up and a weekend of elbow grease on the telemetry. Totally worth it — everything else on this site is practiced here first.

The four questions

1. What is it? — one line: which product, which component.
2. How is it triggered? — authentication required? local or remote? (look for attack vector / attack complexity in the CVSS string).
3. What’s the impact? — RCE, data leak, DoS? Read past the CVSS score: 9.8s get patched, but a 5.3 on an internet-facing box can be the one that matters in practice.
4. What do I do? — patch version, workaround, or detection query.

The CVSS short-cut

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
   │   │   │    │    │    │    │   │   │   └─ Availability
   │   │   │    │    │    │    │   │   └───── Integrity
   │   │   │    │    │    │    │   └───────── Confidentiality
   │   │   │    │    │    │    └───────────── Scope
   │   │   │    │    │    └────────────────── User Interaction
   │   │   │    │    └─────────────────────── Privileges Required
   │   │   │    └──────────────────────────── Attack Complexity
   │   │   └───────────────────────────────── Attack Vector
   │   └───────────────────────────────────── Version
   └───────────────────────────────────────── Vector family

AV:N (network) + PR:N (no auth) is the “drop everything” combo.

Where I read them

• NVD — the raw database.
• Vendor advisory pages — the source of truth for patch versions.
• The MITRE ATT&CK technique listed (if any) to think in detection terms.

That’s it — advisories get much friendlier once you decide the four questions are the only things you need out of them.

The standard sweep

$ nmap -sC -sV -p- -T4 <target>

• -sC default scripts (safe + valuable), -sV version detection
• -p- all 65535 ports — half the battle is finding the unusual port
• -T4 aggressive timing for lab/CTF targets (use -T2 on real scopes)

Faster discovery phase

$ nmap -sn -T4 10.10.10.0/24        # ping sweep, no port scan
$ nmap -sU --top-ports 20 <target>  # top 20 UDP (DNS, SNMP, NTP...)

When scripts are too loud

$ nmap -p 80 --script http-enum <target>
$ nmap -p 445 --script smb-enum-shares <target>

Targeted script groups by service, instead of -sC on everything.

Output habits

$ nmap -oN scan.txt -oX scan.xml <target>   # keep both, forever

Keep every scan in a folder per target — your future writeup self will thank you, and the report discipline carries over to real assessments.

The meta-rule

Version detection (-sV) output is worth more than the port list itself. A service + version is a search query; a port number is trivia.