Scenario 7: Blue Team Detection Architecture

The Core Insight

Every scan leaves traces. The question is never if blue team can detect it — it's which layer catches it, and how long before correlation kicks in. A red teamer who understands the detection architecture can make informed trade-offs. One who doesn't is just hoping for the best.

Detection Layer Architecture

Blue team detection is not a single gate — it's a layered pipeline. Each layer operates on different data, at different timescales, with different blind spots.

┌─────────────────────────────────────────────────┐
│           Layer 3 — SIEM Correlation            │
│     (Splunk, Microsoft Sentinel, Elastic)       │
│   Cross-log analysis · Statistical baselines    │
│         Time windows: 1 hr → 24+ hrs            │
├─────────────────────────────────────────────────┤
│        Layer 2 — Network Monitoring             │
│       (Snort / Suricata / Zeek + NetFlow)       │
│  Signature rules · Flow metadata · SYN ratios   │
├─────────────────────────────────────────────────┤
│        Layer 1 — Perimeter (Firewall / IPS)     │
│    Rate-limiting · Geo-blocking · Port ACLs     │
│         Connection logs · Drop counters         │
├─────────────────────────────────────────────────┤
│        EDR / Endpoint Layer                     │
│  (CrowdStrike Falcon / Defender for Endpoint)   │
│  Process telemetry · Behavioral analytics       │
└─────────────────────────────────────────────────┘

Layer 1 — Perimeter (Firewall / IPS)

The first thing a scan hits. Firewalls and inline IPS devices operate in real-time on individual packets and connections.

What it catches:

What it logs: Source IP, destination IP, destination port, action (allow/deny), timestamp, bytes transferred.

Blind spots: Slow scans below rate thresholds. Scans routed through expected geographies (residential proxies). Traffic that looks like legitimate application connections.

Layer 2 — Network Monitoring (IDS/IPS + NetFlow)

This is where signature-based and flow-based detection operate. Two distinct sub-systems work here.

IDS/IPS Signature Detection

Snort and Suricata run pattern-matching rules against packet content and connection behavior.

Key rule example:

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"ET SCAN Potential TCP Port Scan"; 
flow:stateless; flags:S,12; threshold:type both, track by_src, count 50, seconds 120; 
classtype:attempted-recon; sid:2024000; rev:1;)

This fires when a source sends 50+ SYN packets to distinct ports within 120 seconds. GHOST tier at ~1 port/min produces ~2 SYNs in 120 seconds — well below this threshold.

NetFlow Metadata Analysis

NetFlow signals that flag scanning activity:

The failed connection ratio is particularly damaging to port scans: even at GHOST speed, scanning 1000 ports where 990 are closed produces a 99% failure ratio — a massive statistical outlier that NetFlow analysis catches trivially.

Layer 3 — Log Correlation (SIEM)

SIEM platforms (Splunk, Microsoft Sentinel, Elastic Security) aggregate logs from every other layer and apply cross-source, time-windowed correlation.

How SIEM catches what other layers miss:

1. Cross-log correlation — A single denied firewall connection is noise. The same source IP appearing in firewall deny logs, IDS alerts, and NetFlow anomaly reports within a 4-hour window is an investigation trigger.

2. Statistical anomaly detection — SIEM baselines normal traffic patterns per source, per subnet, per time-of-day. It flags deviations, not absolute thresholds. A host that normally talks to 5 destination ports suddenly touching 200 — even over 24 hours — is an outlier.

3. Sliding time windows — Correlation rules operate on configurable windows from 1 hour to 24+ hours. GHOST tier's 60-second delay means scanning 1000 ports takes ~16 hours — well within a 24-hour correlation window.

Example SIEM detection logic (pseudocode):

WHEN source_ip IN firewall_deny_logs
  AND count(DISTINCT dest_port) > 20
  AND timewindow <= 24h
  AND failed_connection_ratio > 0.3
THEN alert("Reconnaissance - Distributed Port Scan", severity=MEDIUM)

Key SIEM platforms and their scan-detection capabilities:

EDR / Endpoint Layer

When a scan reaches a host — even if it passes perimeter and network layers — endpoint detection and response (EDR) platforms observe it from the inside.

CrowdStrike Falcon:

• Logs all inbound network connections at the host level
• Detects rapid connection attempts from single sources via behavioral indicators of attack (IOAs)
• Correlates network activity with process context — identifies what process accepted or initiated connections
• Cloud-based threat graph links activity across the entire fleet

Microsoft Defender for Endpoint:

• Network connection logging with process attribution
• DeviceNetworkEvents table captures every inbound/outbound connection with timestamp, remote IP, port, and initiating process
• Advanced hunting (KQL) enables custom scan detection queries
• Automated investigation triggers on connection pattern anomalies

What EDR catches that network layers miss:

• Scans originating from inside a compromised host (post-pivot lateral movement)
• Single-port slow scans that blend into normal traffic at the network level but show unusual process behavior at the endpoint
• Tool execution artifacts — the scan tool process itself (nmap, masscan, custom scripts) appearing in process telemetry

Detection vs. Stealth Tier Matrix

How each stealth tier from the playbook maps against the detection layers:

What Blue Team Actually Sees

Concrete examples of what each detection layer produces when a scan is in progress:

Firewall log entry (single denied connection):

2026-02-26T03:14:22Z DENY TCP src=10.20.30.40 dst=192.168.1.100 dport=3389 
  rule="default-deny" action=drop bytes=0 session_duration=0s

IDS alert (Suricata, CAREFUL tier triggering threshold):

[**] ET SCAN Potential TCP Port Scan [**]
02/26/2026-03:15:00.123456  10.20.30.40:54321 -> 192.168.1.100:445
Classification: Attempted Information Leak  Priority: 2

SIEM correlation alert (Splunk, after 6-hour GHOST scan):

Alert: Network - Distributed Port Scan Detected
Source: 10.20.30.40
Distinct destination ports: 347 (over 6 hours)
Failed connection ratio: 94.2%
Correlated events: 12 firewall denies + NetFlow anomaly score 8.7/10
Severity: MEDIUM  |  Status: New  |  Assigned: SOC-L1

EDR detection (CrowdStrike Falcon process telemetry):

Detection: Suspicious Network Reconnaissance
Host: WORKSTATION-42
Process: /usr/bin/nmap (PID 18234)
User: compromised_svc_account
Network activity: 89 outbound connections to 192.168.1.0/24 in 45 minutes
Tactic: Discovery (TA0007)  |  Technique: Network Service Scanning (T1046)
Severity: Medium  |  Action: Detected (not blocked)

NetFlow anomaly summary (24-hour GHOST scan, as seen by analyst):

The contrast between a scanning host and normal baseline traffic is stark — regardless of scan speed. This is why NetFlow metadata analysis is considered the most reliable scan detection method at the network layer.