Post cover image

July 13, 2026

The VAPT Chronicles — SIEM, Detection & Blue Team Concepts

Ongoing VAPT learning | Part 11 of a multi-part series on the vulnerability assessment and penetration testing lifecycle

By R. Mahathi

5 min read

Why This Post Exists

Ten parts into this series, we've broken into networks, phished users, cracked hashes, pivoted across domains, and popped wireless and physical access controls. Every one of those posts assumed the same thing: nobody's watching.

That assumption doesn't hold in the real world. Real environments have SIEMs, real analysts triage alerts, and real detection engineers write rules that catch the exact tools we've been using. A pentester who doesn't understand the blue side is only doing half the job — and a report that doesn't tell the client what would have caught this is a report that gets filed and forgotten.

This part flips the lens. We're going to walk through how detection actually works — Wazuh, Splunk, Sigma rules, MITRE ATT&CK mapping, log analysis, alert tuning, and Security Configuration Assessment (SCA) — so that the next time we run an attack, we can also answer: would this have been seen?

1. Why Detection Knowledge Matters for a Pentester

Two reasons, and both show up directly in client deliverables:

  • Evasion is informed, not accidental. You can't reliably avoid detection if you don't know what triggers it. Understanding log sources, alert logic, and correlation rules is what separates "got lucky" from "tested the control."
  • Reports need a blue-team lens. A finding that says "we obtained Domain Admin via Kerberoasting" is incomplete. A mature finding says that, and explains which Windows Event IDs, Sigma rules, or Wazuh decoders would have flagged the ticket request, and where the detection gap is.

This is also why every post in this series since Part 6 has carried a "Blue Team Detection" section — this post is where we go deep on the tooling behind those sections.

2. SIEM Fundamentals — What's Actually Happening Under the Hood

A SIEM (Security Information and Event Management platform) does three jobs:

  1. Collect — pull logs from endpoints, network devices, cloud services, and applications.
  2. Normalize & Correlate — parse raw logs into a common schema and match patterns across multiple sources.
  3. Alert & Respond — surface anomalies to analysts, often ranked by severity, and route them into a response workflow.

The value of a SIEM isn't the dashboard — it's the correlation. A single failed login means nothing. Five hundred failed logins across forty accounts in ninety seconds, followed by one success, is a password spray — and only a SIEM correlating across accounts and time windows will catch that pattern a human scrolling through logs never would.

Wazuh

Wazuh is the open-source SIEM/XDR stack this series has used throughout the lab (see the earlier Wazuh + Windows 11 agent setup). Its architecture has three core pieces:

  • Wazuh Agent — installed on endpoints, ships logs and file-integrity data back to the manager.
  • Wazuh Manager — decodes and rule-matches incoming events using a decoder/ruleset pipeline.
  • Wazuh Indexer + Dashboard — stores and visualizes the processed alerts (OpenSearch-based).

A typical decoded alert for a suspicious PowerShell execution looks like this once it hits the manager:

** Alert 1720835123.481923: - windows,powershell,mitre_execution
2026 Jul 12 14:45:23 (WIN11-ENDPOINT) any->WinEvtLog
Rule: 92037 (level 12) -> 'PowerShell script block logging: suspicious keywords detected.'
mitre.id: T1059.001
mitre.tactic: Execution
Src IP: 10.10.10.15
User: PHANTOM\jsmith
Command: IEX (New-Object Net.WebClient).DownloadString(...)

That single alert bundles the raw event, the matched rule, and a MITRE ATT&CK technique ID — which is exactly the chain we need for reporting.

Splunk

Splunk operates on the same collect-normalize-alert model but is built around its own query language, SPL (Search Processing Language). Where Wazuh gives you pre-built rules, Splunk expects you to write searches and correlation logic yourself (or use app content like the Splunk Security Essentials or ES content packs).

A simple SPL query to hunt for the same PowerShell abuse pattern:

spl

index=windows sourcetype="WinEventLog:Microsoft-Windows-PowerShell/Operational" EventCode=4104
| search ScriptBlockText="*DownloadString*" OR ScriptBlockText="*IEX*" OR ScriptBlockText="*-EncodedCommand*"
| stats count by Computer, User, ScriptBlockText
| where count > 0

The practical difference for a pentester: Wazuh tells you what it already watches for out of the box; Splunk tells you what an analyst could watch for if they wrote the query. Both matter — one shows you baseline coverage, the other shows you the ceiling of what's possible.

3. Sigma Rules — The Detection-as-Code Layer

Sigma is to detection rules what YARA is to malware signatures — a generic, platform-agnostic format that gets translated into whatever backend you run (Splunk SPL, Wazuh/Elastic query DSL, Sentinel KQL, etc.).

A Sigma rule for detecting Kerberoasting (something this series has actually performed, back in the lateral movement post) looks like this:

yaml

title: Potential Kerberoasting Activity
id: 6a5583c2-3d6a-4ffd-8f43-1a6f3d3ea555
status: stable
description: Detects RC4 ticket requests for service accounts, a common indicator of Kerberoasting
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
    ServiceName|endswith: '$'
  filter:
    ServiceName: 'krbtgt'
  condition: selection and not filter
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

Notice the tags field — Sigma rules are natively MITRE ATT&CK-aware. That's the bridge between "here's a detection rule" and "here's the ATT&CK technique it maps to," which is exactly the table format this series has used since the phishing post.

Why Sigma matters for a VAPT report: instead of telling a client "you should detect Kerberoasting," you can hand them a working, importable Sigma rule tuned to their environment — that's the difference between a finding and a fix.

4. MITRE ATT&CK Mapping — Connecting Attack to Detection

Every post in this series has included a MITRE mapping table. Here's the detection-focused version for this post, showing technique → data source → where you'd catch it:

None

This table is the deliverable-ready format

5. Log Analysis — What Analysts Actually Look At

Detection tools only surface what the underlying logs contain. The core Windows event sources every VAPT professional should know:

None

The skill isn't memorizing IDs — it's pattern reading. A single 4688 is noise. A 4688 for powershell.exe spawned by winword.exe, followed by a 4104 with a Base64-encoded command, followed by a 4769 for a service account, is an attack chain — and that chain is exactly what a Sigma correlation rule or a Wazuh composite rule is built to catch.

6. Alert Tuning — The Unglamorous Part That Matters Most

An under-tuned SIEM is arguably worse than no SIEM — analysts drown in false positives and stop trusting alerts (alert fatigue is a real, documented failure mode in SOC operations). Tuning generally follows three levers:

  • Threshold tuning — adjusting counts/time windows (e.g., "5 failed logins in 2 minutes" instead of "1 failed login").
  • Allowlisting known-good behavior — scheduled backup jobs, vulnerability scanners, admin scripts that would otherwise trip a rule.
  • Severity recalibration — not every match deserves a level-12 alert; tuning maps technical severity to actual business risk.

From a pentester's perspective, this is useful intel: environments with poor tuning tend to either miss real attacks in the noise, or have disabled/loosened rules entirely because they were too noisy — both are findings worth calling out.

7. SCA — Security Configuration Assessment

SCA is the piece that's easy to overlook because it's not about detecting activity — it's about continuously checking configuration state against a hardening benchmark (CIS Benchmarks, for example). Wazuh ships an SCA module that runs periodic checks against the host and reports pass/fail per control, things like:

  • Is SMBv1 disabled?
  • Is LSASS running as a protected process?
  • Are password complexity policies enforced?
  • Is PowerShell running in Constrained Language Mode?

The reason SCA belongs in this post: half the attack techniques covered in this series (SMB relay, LSASS dumping, weak password policies enabling spraying) are only possible because of a configuration gap that SCA would have flagged before any attack occurred. This is the preventive counterpart to the detective controls (SIEM/Sigma) covered above — and a mature VAPT report distinguishes between the two.

8. Blue Team Detection — Recap Table for This Post

None

This post is part of an ongoing VAPT learning series documenting hands-on offensive and defensive security work in a lab environment. Previous parts covered web application testing, social engineering, post-exploitation, wireless attacks, and physical/HID attack vectors.