How to detect attacks that have bypassed preventive controls — covering SIEM architecture, UEBA, anomaly detection, threat hunting, and detection-as-code with Sigma rules.
How to detect attacks that have bypassed preventive controls — covering SIEM architecture, UEBA, anomaly detection, threat hunting, and detection-as-code with Sigma rules.
Preventive controls (firewalls, WAFs, MFA) are bypassed every day. The average attacker dwell time before detection is 207 days (IBM 2023). Without active detection, attackers operate undetected inside your environment for months.
Attackers move laterally, exfiltrate data, establish persistence, and prepare ransomware over weeks or months. By the time damage is visible, the attacker has long-term access.
Anomalous behaviour is detected within hours or days. Threat hunters proactively search for indicators of compromise. Detection rules are codified as tests. MTTD shrinks from months to hours.
Lesson outline
A complete threat detection stack combines several layers, each catching different classes of threat.
| Layer | What it detects | Examples |
|---|---|---|
| SIEM | Cross-source correlation: brute force then successful login from new geo, lateral movement patterns | Splunk, Microsoft Sentinel, Elastic SIEM |
| EDR | Process injection, credential dumping, malware execution on hosts | CrowdStrike Falcon, SentinelOne, Microsoft Defender |
| Cloud-Native | API abuse, IAM anomalies, resource misconfigurations | AWS GuardDuty, GCP SCC, Azure Defender |
| UEBA | Unusual user behaviour: access at odd hours, large data downloads, new system access | Splunk UBA, Sentinel UEBA, Securonix |
| NDR | Lateral movement, C2 beaconing, data exfiltration over network | Darktrace, ExtraHop, Vectra AI |
| SOAR | Automates response playbooks: isolate host, block IP, revoke credentials | Palo Alto XSOAR, Splunk SOAR |
SIEM is only as good as the logs fed into it
Before investing in SIEM tuning, ensure you have: authentication logs (Okta, AD, CloudTrail), network flow logs, application logs (structured JSON with user IDs), endpoint telemetry (EDR), and cloud activity logs (CloudTrail, GCP Audit Logs).
Effective detection starts with a prioritised set of use cases based on your most likely threat scenarios.
Detection rules every organisation should have
AWS GuardDuty is a managed threat detection service that continuously monitors CloudTrail, VPC Flow Logs, and DNS logs — with no agents required.
Key GuardDuty finding types
Enable GuardDuty in every AWS account and every region
GuardDuty costs ~$3/month for most accounts and catches real attacks automatically. Enable it organisation-wide via AWS Organizations. Enable in all regions — attackers sometimes use inactive regions to avoid detection.
1# GuardDuty + EventBridge automated response — quarantine compromised EC22resource "aws_cloudwatch_event_rule" "guardduty_high" {3name = "guardduty-high-severity"4event_pattern = jsonencode({5source = ["aws.guardduty"]6detail-type = ["GuardDuty Finding"]7detail = {8severity = [{ numeric = [">=", 7] }] # 7.0+ = HIGH severityseverity >= 7.0 = HIGH; 9.0+ = CRITICAL9}10})11}12resource "aws_cloudwatch_event_target" "response_lambda" {14rule = aws_cloudwatch_event_rule.guardduty_high.name15arn = aws_lambda_function.incident_response.arn16}17# Lambda response (Python) — triggered on HIGH+ finding19import boto320def handler(event, context):22finding = event['detail']23instance_id = (finding.get('resource', {})24.get('instanceDetails', {})25.get('instanceId'))26if instance_id:27ec2 = boto3.client('ec2')Quarantine SG blocks all traffic while preserving instance for forensics28# 1. Apply quarantine SG — blocks all traffic, preserves for forensics29ec2.modify_instance_attribute(30InstanceId=instance_id,31Groups=['sg-quarantine-0abc1234']Always snapshot before terminating — forensic evidence is critical32)33# 2. Snapshot root volume for forensic analysis34ec2.create_snapshot(35Description=f"Forensic: GuardDuty {finding['type']}",36VolumeId=get_root_volume_id(instance_id),37)
UEBA builds a baseline of normal behaviour for each user and entity, then alerts when behaviour deviates significantly from that baseline.
What UEBA detects that rule-based systems miss
UEBA needs 2–4 weeks to establish a baseline before generating reliable alerts
Enable UEBA on day 1 but do not act on findings for the first 2–4 weeks. The system is still learning. Acting on immature baselines produces alert storms from legitimate but unusual activity.
Threat hunting is the proactive search for threats that have evaded automated detection. Hunters assume attackers are already inside and look for evidence.
Threat hunting methodology
01
Form a hypothesis — based on threat intelligence ("APT29 uses registry run keys for persistence") or internal signals ("unusual outbound DNS to .ru domains")
02
Collect and query relevant data — search logs, EDR telemetry, network flows for the specific indicator or behaviour pattern
03
Analyse results — distinguish true positives from false positives; follow the kill chain for suspicious findings
04
Document findings — regardless of outcome: what was searched, what was found, what was ruled out
05
Automate — convert successful hunts into automated detection rules so the same pattern is caught automatically in future
Form a hypothesis — based on threat intelligence ("APT29 uses registry run keys for persistence") or internal signals ("unusual outbound DNS to .ru domains")
Collect and query relevant data — search logs, EDR telemetry, network flows for the specific indicator or behaviour pattern
Analyse results — distinguish true positives from false positives; follow the kill chain for suspicious findings
Document findings — regardless of outcome: what was searched, what was found, what was ruled out
Automate — convert successful hunts into automated detection rules so the same pattern is caught automatically in future
Every successful hunt produces a new automated detection rule
Threat hunting feeds detection engineering. Over time, automation coverage improves and hunters can focus on novel TTPs rather than repeated manual searches.
Detection-as-code treats detection rules as software — version-controlled, tested, peer-reviewed, deployed via CI/CD. Sigma is the YAML-based, vendor-neutral detection rule format.
Sigma rules compile to any SIEM query language
A Sigma rule written once compiles to Splunk SPL, Elastic EQL, Microsoft KQL, or CloudWatch Insights using the sigmac tool. Write once, deploy anywhere — no vendor lock-in.
1# Sigma rule — detect AWS IAM privilege escalation2title: AWS IAM Privilege Escalation via Admin Policy Attachment3id: a1b2c3d4-e5f6-7890-abcd-ef12345678904status: stable5description: |6Detects when an IAM identity attaches AdministratorAccess or creates7a custom policy with iam:* permissions — common post-compromise escalation.8references:9- https://attack.mitre.org/techniques/T1098/10tags:11- attack.privilege_escalation12- attack.t1098.003MITRE ATT&CK T1098.003 — Account Manipulation: Add Cloud Credentials13logsource:15product: aws16service: cloudtrail17detection:19selection_attach:20eventSource: iam.amazonaws.com21eventName: AttachUserPolicyCatch AdministratorAccess attachment22requestParameters.policyArn|contains:23- 'AdministratorAccess'24- 'IAMFullAccess'25selection_create:26eventSource: iam.amazonaws.com27eventName: PutUserPolicyCatch inline policy with iam:* wildcard28requestParameters.policyDocument|contains:29- '"iam:*"'30- '"Action":"*"'31condition: selection_attach or selection_create32falsepositives:falsepositives — document expected triggers to reduce noise34- Legitimate IAM administration by security or infra teams35- Initial account bootstrap36level: high38# Compile to Splunk: sigma convert -t splunk <rule.yml>40# Compile to KQL: sigma convert -t microsoft365defender <rule.yml>
Detection effectiveness is measured by two key metrics.
| Metric | Definition | Industry Average (2023) | Target |
|---|---|---|---|
| MTTD (Mean Time to Detect) | Time from breach to detection | 207 days (IBM 2023) | < 24 hours |
| MTTR (Mean Time to Respond) | Time from detection to full containment | 73 days (IBM 2023) | < 4h critical / < 24h high |
| Alert Precision | True positives / all alerts | 5–10% (most alerts are noise) | > 30% before expanding coverage |
| Detection Coverage | % of MITRE ATT&CK techniques with active rules | < 20% for most orgs | > 60% for critical techniques |
Reduce MTTD, not just MTTR
Most orgs focus on MTTR (response speed). But MTTD is where attackers steal data — every day of undetected presence is a day of exfiltration. A breach detected in 6 hours with 2-hour MTTR beats one detected in 207 days with 1-hour MTTR.
Advanced threat detection appears in security engineer, SOC analyst, and DevSecOps architect interviews. Expect scenario questions: "An attacker has been in your environment for 3 months — how would you find them?"
Common questions:
Strong answer: Knows MTTD vs MTTR difference, describes a threat hunting hypothesis, mentions Sigma for detection-as-code, and understands UEBA catches slow-and-low attacks rule-based systems miss.
Red flags: Thinking a firewall means you do not need detection, not knowing what GuardDuty or a SIEM is, or conflating MTTD with MTTR.
Quick check · Advanced Threat Detection
1 / 3
Key takeaways
A GuardDuty finding shows "Recon:IAMUser/UserPermissions" for a developer IAM user. What does this mean and what is your response?
This means the IAM user is making API calls to enumerate their own permissions (GetPolicy, ListPolicies, SimulatePrincipalPolicy) — reconnaissance behaviour: an attacker who has compromised the account is mapping what they can access. Response: (1) Immediately verify with the developer — if they did not make these calls, treat as account compromise. (2) If compromised: disable access keys, invalidate sessions, review CloudTrail for the past 24–72h. (3) Investigate how credentials were obtained. (4) Rotate all credentials for this identity.
What is the difference between a SIEM alert and a threat hunt?
A SIEM alert is a pre-written rule that runs continuously and fires automatically on known patterns — reactive, automated, catches known TTPs. A threat hunt is a proactive, hypothesis-driven manual investigation for attacker activity that may have evaded automated detection — exploratory, catches novel or subtle activity. Use SIEM alerts for high-confidence known patterns (brute force, privilege escalation). Use threat hunting when threat intelligence suggests a specific TTP, after a peer breach, or on a regular schedule to find slow-and-low attacks.
From the books
The Practice of Network Security Monitoring (Richard Bejtlich, No Starch Press)
Foundational guide to network security monitoring, threat detection, and incident response. Covers the analyst mindset and practical detection methodology.
Applied Network Security Monitoring (Chris Sanders & Jason Smith)
Practical NSM guide covering collection, detection, and analysis. Includes hands-on exercises with open-source tools (Zeek, Snort, Suricata).
💡 Analogy
Security cameras and a 24/7 SOC — not just locks
⚡ Core Idea
Preventive controls (locks, firewalls, MFA) stop attackers at the door. Threat detection assumes the lock has been picked and asks: how quickly would we know? Detection is the security camera, the motion detector, and the SOC analyst who investigates the alert. Without detection, a burglar inside your house could stay for months.
🎯 Why It Matters
The SolarWinds attackers were inside for 9 months. The Equifax attackers exfiltrated data for 78 days. These were not discovered by preventive controls — they were discovered by detection (or reported externally). Breach cost scales linearly with dwell time. Cutting MTTD from 207 days to 24 hours reduces breach cost by an order of magnitude.
Ready to see how this works in the cloud?
Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.
View role-based pathsSign in to track your progress and mark lessons complete.
Questions? Discuss in the community or start a thread below.
Join DiscordSign in to start or join a thread.