SOC TRAINING

MODULE
Advanced Alert
Analysis for 2026
Threat
Landscape
BY IZZMIER IZZUDDIN
MODULE 0
Foundations of SOC Alert Analysis for 2026
From Noise Detection to Trust-Breach Identification

0.1 PURPOSE OF MODULE 0

Module 0 establishes the mental model every SOC analyst must adopt before touching
alerts in 2026 and beyond.

This module does not teach tools. This module teaches how to think.

By the end of Module 0, an analyst must understand:

1. Why most future breaches will not look like “attacks”

2. Why alerts will be low severity, late or misleading
3. Why trusted systems are now the primary attack surface
4. Why SOC success depends on context, not volume
5. Why silence in logs does not equal safety

0.2 WHY TRADITIONAL SOC THINKING FAILS IN 2026

Legacy SOC Assumptions (Now Dangerous)

Old Assumption Why It Fails

If malware exists, EDR will alert Many attacks have no malware
If credentials are stolen, login Tokens, sessions and service identities do not
alerts appear generate login failures
If encryption is used, data is safe Encrypted data can be harvested and decrypted
later
If PAM approves the session, Abuse can occur inside approved sessions
activity is valid
If user denies activity, it is insider External actors can shadow legitimate identities
threat

The core problem is not tools. The core problem is trust.

0.3 THE 2026 SOC THREAT MODEL

Modern Attacker Objective
Attackers are no longer optimising for speed. They are optimising for longevity.

Their goal is to:

• Avoid triggering alerts

• Avoid user interaction
• Avoid malware deployment
• Blend into operational noise
• Stay invisible for months or years

Modern Attacker Entry Points

Entry Point Why It Is Attractive

Service accounts Rarely monitored, highly trusted
API tokens No login events, no MFA
Automation pipelines Secrets often exposed
Privileged sessions Pre-approved access
Encrypted traffic SOC avoids inspecting it

These are designed features, not vulnerabilities.

0.4 SOC VISIBILITY MYTHS

Myth 1: “We Have Full Visibility”

Reality: You have partial telemetry, fragmented across systems, with no single tool seeing
the full picture.

Example:

• IAM sees authentication

• EDR sees endpoints
• NDR sees flows
• SIEM sees logs
• None see intent

Myth 2: “If It’s Allowed, It’s Safe”

Reality: Most modern attacks operate entirely within allowed boundaries.

Example:

• Valid token
 • Approved role
• Trusted endpoint
• Encrypted channel

Safety is not determined by permission. Safety is determined by behaviour consistency.

0.5 CORE SOC PRINCIPLE FOR 2026

Every analyst must internalise this:

Authentication proves identity.

Authorisation proves permission.
Behaviour proves legitimacy.

If behaviour deviates, trust is broken.

0.6 BASELINE VS DRIFT (CRITICAL CONCEPT)

What Is a Baseline

A baseline is not:

• A policy
• A rule
• A threshold

A baseline is:

• How an identity behaves over time

• What it normally accesses
• When it acts
• How much it transfers
• Where it connects from

What Is Drift

Drift is:

• New behaviour
• Gradual behaviour
• Justified-looking behaviour
• Behaviour that does not trigger controls
Drift is how breaches begin.

0.7 SIMULATED BASELINE DATA (SERVICE ACCOUNT)

Historical Behaviour (90 Days)

Identity: svc-reporting-engine
Login Method: Client Secret
Average Login Time: 02:00 – 02:05
API Calls:
- /report/daily
- /report/summary
Data Volume:
- Average: 120 MB
Destination:
- Internal analytics server only

No alerts. Trusted.

0.8 SIMULATED DRIFT (FIRST WARNING)

Week 1 – Slight Change

Date: 2026-01-12
New API Call:
- /storage/list
Data Volume:
- 160 MB
Destination:
- analytics server

SOC reaction: Ignore. Looks reasonable.

Week 3 – More Change

Date: 2026-01-28
New API Call:
- /storage/export
Data Volume:
- 480 MB
Destination:
- cloud object storage

SOC reaction: Still no alert. All authorised.

Week 6 – Breach State

Date: 2026-02-15
API Calls:
- /storage/export
- /storage/listKeys
Data Volume:
- 1.4 GB
Destination:
- CDN endpoint

At this point, the breach already happened.

0.9 WHY ALERTS FAIL IN THIS MODEL

Why SIEM Did Not Trigger

Control Reason
Authentication Successful
Authorisation Allowed
EDR No process anomaly
Firewall TLS allowed
PAM Not a human user
IDS No exploit

Every tool did its job. The SOC failed to interpret intent.

0.10 NEW SOC QUESTIONS (MANDATORY IN 2026)

Every alert must be analysed with these questions:

1. Has this identity done this before?

2. Is the data sensitivity increasing?
3. Is access expanding horizontally?
4. Is timing changing?
5. Is volume trending upward?
6. Is destination consistent?
7. Is this explainable by a business change?

If any answer is “no”, investigation is required.

0.11 SIMULATED ANALYST THINKING EXERCISE

Alert Presented to Analyst

Alert Name: Unusual API Behaviour

Severity: Low
Identity: svc-reporting-engine
Details:
- New API call observed
- Increased data volume

Poor Analyst Response (2022 Thinking)

“This is a service account. Probably application update. Closing.”

Correct Analyst Response (2026 Thinking)

“This identity has expanded capability scope, increased data volume and changed
destination. There is no change record. This is behavioural drift. Escalate.”

0.12 FAILURE MODES SOC MUST AVOID

1. Dismissing low-severity alerts
2. Trusting service accounts blindly
3. Assuming encryption equals protection
4. Treating PAM approval as absolute trust
5. Waiting for malware confirmation
6. Expecting attackers to be noisy

0.13 WHEN TO ESCALATE WITHOUT CONFIRMATION

SOC must escalate even when:

• There is no malware
• There is no exploit
• There is no user complaint
• There is no outage
• There is no policy violation

Escalation is based on risk, not proof.

0.14 MODULE 0 PRACTICAL TASK

Analyst Exercise

Given:

• IAM logs
 • API logs
• Network telemetry

Task:

1. Identify baseline
2. Identify drift
3. Determine risk
4. Decide escalation

No tools required. Thinking required.

0.15 PASS / FAIL CRITERIA

An analyst passes Module 0 if they can:

• Explain why an alert is risky even if allowed

• Identify drift without malware
• Justify escalation using behaviour
• Avoid relying on severity labels
MODULE 1
Service Account Drift Abuse
Detecting Silent Post-Compromise Automation Hijack

1.1 PURPOSE OF MODULE 1

Module 1 trains SOC analysts to detect and respond to service account abuse, one of the
most critical and misunderstood attack paths in 2026.

This module focuses on:

• Non-human identities
• Fully authorised access
• No malware
• No failed logins
• No obvious security control failure

By the end of this module, analysts must be able to identify compromise without
compromise indicators.

1.2 WHY SERVICE ACCOUNTS ARE HIGH-RISK IN 2026

Service accounts are now:

• More privileged than users

• Less monitored than users
• Used continuously
• Rarely rotated
• Rarely challenged

Modern environments contain:

• CI/CD service accounts

• API integration accounts
• Data synchronisation accounts
• Reporting and analytics bots
• Cloud workload identities

Attackers target these accounts because:

 • Behaviour is repetitive
• Alerts are suppressed
• Changes are assumed to be operational

1.3 ATTACK MODEL OVERVIEW

Attacker Objective

To silently exfiltrate sensitive data by abusing an existing service account without:

• Creating new accounts

• Changing roles explicitly
• Triggering alerts
• Interrupting business operations

This is a trust hijack, not a break-in.

Attack Entry Points

Service account secrets are commonly exposed via:

• CI/CD pipeline logs

• Application debug logs
• Infrastructure-as-code repositories
• Third-party SaaS integrations
• Backup scripts

Exposure may happen months before abuse.

1.4 SIMULATED ENVIRONMENT

Identity

Account Name: svc-finance-aggregation

Identity Type: Azure AD Service Principal
Authentication: Client Secret
Token Lifetime: 24 hours

Normal Function

Purpose:
- Aggregate daily transaction summaries
- Push data to internal finance dashboard
Execution Schedule:
- Daily at 01:00

Normal Scope:
- Read-only access to finance_summary table

1.5 BASELINE BEHAVIOUR (NORMAL STATE)

IAM Authentication Logs (30-Day Baseline)
Auth Method: OAuth2 Client Credentials
Average Login Time: 01:00 – 01:03
Source IP: [Link]
Geo: Internal DC
Result: Success

API Usage Baseline

Endpoints:
- /finance/summary/read
- /finance/report/push

Average Requests:
- 12 per execution

Average Data Volume:

- 95 MB

Network Baseline

Destination:
- Internal analytics server
Protocol:
- HTTPS
Session Duration:
- < 3 minutes

This behaviour is trusted and stable.

1.6 INITIAL DRIFT (EARLY COMPROMISE PHASE)

Week 1 – Minor Behaviour Expansion

Date: 2026-03-04
New API Endpoint:
- /finance/archive/list

Data Volume:
- 130 MB

SOC Context:

• No alert triggered
• Endpoint allowed
• No role change detected

This is the first missed detection opportunity.

1.7 MID-STAGE DRIFT (ACTIVE ABUSE)

API Gateway Logs

Date: 2026-03-18 01:07:41

Caller: svc-finance-aggregation
Endpoint: /finance/archive/export
Response Size: 420 MB
Status: 200 OK

IAM Logs

No role assignment changes

No conditional access violations
No authentication anomalies

SOC tools report nothing suspicious.

1.8 BREACH STATE (DATA EXFILTRATION)

Cloud Activity Logs

Date: 2026-04-02 01:09:12

Operation:
[Link]/storageAccounts/listKeys/action

Resource:
finance-backup-store

Result:
Success

This action was never performed before.

Network Logs
Time: 01:09:18
Source: [Link]
Destination: [Link]
Protocol: HTTPS
Data Transferred: 1.8 GB

EDR Telemetry

Process:
[Link]

Action:
Outbound HTTPS

Reputation:
Trusted

Alert:
None

1.9 WHY CONTROLS DID NOT STOP THIS

Control Reason for Failure
IAM Access was authorised
MFA Not applicable
EDR No malicious process
Firewall Encrypted trusted traffic
SIEM No rule for behavioural drift

The environment worked as designed.

1.10 SOC DETECTION POINT (LATE)

SIEM Behavioural Alert

Alert Name:
Service Account Behaviour Drift

Severity:
Medium

Triggers:
- New API usage
- Increased data volume
- New destination endpoint

This alert arrives after data exposure.

1.11 SOC TIMELINE RECONSTRUCTION
Time Event
01:00 Service account authenticates
01:02 Archive listing initiated
01:05 Full export triggered
01:09 Storage keys enumerated
01:10 Data exfiltrated
01:12 Session ends

1.12 ANALYST DECISION POINTS

Decision 1

Is this an automation update?

Correct approach:

• Check change records

• Validate owner confirmation
• Review historical scope

No change record exists.

Decision 2

Is this misuse or compromise?

Indicators:

• Capability expansion
• Data sensitivity increase
• External destination

Conclusion: This is unauthorised behaviour.

1.13 MITRE ATT&CK MAPPING

• Initial Access: Valid Accounts (T1078)
• Persistence: Account Manipulation (T1098)
• Defense Evasion: Trusted Relationship Abuse (T1199)
• Collection: Data from Information Repositories (T1213)
 • Exfiltration: Exfiltration Over Web Services (T1567)

1.14 SOC RESPONSE PLAYBOOK (EXPECTED)

Immediate Actions

1. Revoke service account credentials

2. Rotate all dependent secrets
3. Suspend data export APIs

Investigation Actions

1. Identify secret exposure source

2. Review historical activity
3. Determine data exposure window

Preventive Actions

1. Scope restriction on service accounts

2. Behavioural baselining enforcement
3. Token lifetime reduction
4. CI/CD secret scanning

1.15 ESCALATION CRITERIA

SOC must escalate if:

• Behaviour deviates from baseline

• Data sensitivity increases
• Destination changes without approval
• Identity acts outside historical scope

Malware presence is not required.

1.16 PRACTICAL ANALYST EXERCISE

Given Logs

• IAM authentication logs

• API gateway logs
• Network flow logs
Analyst Tasks

1. Identify baseline
2. Identify drift
3. Determine breach window
4. Decide escalation level
5. Propose containment steps

1.17 PASS / FAIL CRITERIA

Analyst passes Module 1 if they can:

• Detect compromise without malware

• Justify escalation using behaviour
• Explain why controls failed
• Propose correct containment

ASSESSMENT
Question 1

Explain why service accounts are considered higher risk than user accounts in modern
enterprise environments.

Question 2

A service account performs only authorised actions, but its behaviour has changed
significantly over time.

What factor should drive the SOC’s decision to investigate or escalate?

Question 3

Why is behavioural baselining critical for detecting service account compromise?

Question 4

Describe how service account credentials are commonly exposed without triggering
immediate security alerts.

Question 5
Why does the absence of failed authentication events not indicate that a service account
has not been compromised?

Question 6

What behavioural indicators would suggest that a service account is being abused for data
exfiltration?

Question 7

Explain why endpoint detection tools often fail to detect service account abuse.

Question 8

A SOC analyst assumes that new service account behaviour is due to an application
update.

What verification steps should be taken before closing the alert?

Question 9

Why should access to sensitive data by service accounts be treated differently from
access by human users?

Question 10

From a SOC escalation perspective, what conditions justify revoking service account
credentials even when access was technically authorised?
MODULE 2
Harvest Now, Decrypt Later
Detecting Silent Cryptographic Exposure in Encrypted Traffic

2.1 PURPOSE OF MODULE 2

Module 2 trains SOC analysts to detect strategic data compromise where:

• No systems are breached

• No credentials are stolen
• No malware is deployed
• No data is decrypted today

Yet the organisation has already lost confidentiality. This module addresses a critical
misconception in SOC operations: Encrypted traffic is not automatically safe traffic.

2.2 WHY THIS ATTACK EXISTS (CONTEXT FOR ANALYSTS)

Traditional SOC Belief

If traffic is encrypted using TLS, then:

• Confidentiality is preserved
• Attackers cannot read the data
• SOC focus should move elsewhere

This belief is no longer valid.

Modern Reality (2026)

Attackers, particularly advanced threat actors, do not need to decrypt traffic today.

They only need to:

• Capture encrypted traffic

• Store it
• Decrypt it in the future when cryptography weakens

This strategy is known as Harvest Now, Decrypt Later (HN-DL).

2.3 WHY SOCs FAIL TO DETECT HN-DL
SOCs fail because:

• No payload inspection occurs

• No endpoint is compromised
• No abnormal login is observed
• No policy is violated
• No immediate impact is visible

Most SOCs are operationally focused. HN-DL is strategic compromise, not operational
disruption.

2.4 ATTACK MODEL OVERVIEW

Attacker Objective

To collect large volumes of encrypted sensitive data for future decryption, targeting:

• Financial transactions
• Identity data
• Personal data
• Cryptographic handshakes
• Authentication exchanges

The attacker is patient and invisible.

Attacker Positioning (No Intrusion Required)

Possible collection points:

• Compromised upstream ISP

• Cloud routing misconfiguration
• Border gateway interception
• Passive taps
• Nation-state collection infrastructure

The organisation itself may not be breached at all.

2.5 SIMULATED ENVIRONMENT

Organisation Profile
Sector: Financial Services
Architecture: Hybrid (On-Prem + Cloud)
TLS Deployment:
- TLS 1.2 and TLS 1.3 mixed
Key Exchange:
- RSA-2048
- ECDHE-P256

Critical Services

- Internet Banking API

- Payment Gateway
- Internal Settlement System

2.6 NORMAL ENCRYPTED TRAFFIC BASELINE

Network Behaviour (90-Day Baseline)

Average TLS Sessions per Hour: 14,000

Average Session Duration: 2–4 seconds
Average Data per Session: < 1 MB
TLS Versions:
- 78% TLS 1.3
- 22% TLS 1.2
Key Exchange:
- Predominantly ECDHE

Traffic appears healthy and stable.

2.7 FIRST ANOMALY (MISSED BY MOST SOCs)

NDR Metadata Alert (Low Severity)

Alert Name: Encrypted Traffic Pattern Deviation

Severity: Low
Description:
- Repeated long-lived TLS sessions detected
- Identical cryptographic fingerprint observed

Typical SOC reaction:

• Mark as false positive

• Assume API batch jobs
• Defer investigation

This is the first detection opportunity.

2.8 SIMULATED LONG LOG DATA (CORE EVIDENCE)
TLS Metadata Log

Time: 2026-06-14 02:41:12

Source IP: [Link]
Destination IP: [Link]
SNI: [Link]
TLS Version: 1.2
Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384
Key Exchange: RSA
Session Duration: 17m 08s
Bytes Sent: 92 MB
Bytes Received: 7 MB

Key observations:

• TLS 1.2 still in use

• RSA key exchange
• Session duration abnormally long
• High outbound data volume

Repeated Cryptographic Fingerprint

JA3 Hash: 72a589da586844d7f0818ce684948eea

Occurrences:
02:41
02:59
03:18
03:37

Identical JA3 indicates automated bulk collection tooling.

Firewall Log

Action: Allow
Reason: Valid TLS Traffic
Inspection: Skipped
Category: Financial Services

Everything is allowed.

2.9 WHY THIS IS NOT NORMAL API TRAFFIC

Comparative Analysis
 Parameter Normal Observed
TLS Version TLS 1.3 TLS 1.2
Key Exchange ECDHE RSA
Session Duration Seconds Minutes
JA3 Variance High Identical
Traffic Pattern Request-response Bulk stream

This traffic is collection-oriented, not transactional.

2.10 SOC TIMELINE RECONSTRUCTION

Time Event
02:41 TLS session established
02:41–02:58 Continuous encrypted data flow
02:59 Session renegotiation
03:18 New session begins
03:37 Pattern repeats
Nightly Continuous recurrence

No alerts escalate. No user complaints.

2.11 RISK ASSESSMENT

Risk Area Assessment
Confidentiality Critical
Integrity Not impacted
Availability Not impacted
Detection Difficulty Extremely High
Impact Timing Delayed
Regulatory Risk High

This is a future breach already in progress.

2.12 WHY THIS IS A BREACH EVEN WITHOUT

DECRYPTION
Key principle for analysts: Confidentiality is lost when an unauthorised party gains
possession of protected data, regardless of immediate readability.

Encrypted capture still represents:

 • Loss of exclusivity
• Loss of control
• Regulatory exposure
• Strategic disadvantage

2.13 MITRE ATT&CK MAPPING

• Collection: Data from Information Repositories (T1213)
• Defense Evasion: Encrypted Channel (T1573)
• Exfiltration: Exfiltration Over Web Services (T1567)
• Impact: Confidentiality Loss (Delayed)

2.14 SOC RESPONSE PLAYBOOK (EXPECTED)

Immediate Actions

1. Identify all RSA-based TLS sessions

2. Force TLS 1.3 for sensitive services
3. Shorten TLS session lifetimes

Investigation Actions

1. Identify affected datasets

2. Estimate exposure window
3. Assess cryptographic strength used
4. Determine regulatory notification requirements

Strategic Actions

1. Cryptographic inventory creation

2. PQC migration planning
3. TLS metadata monitoring
4. Encrypted traffic behaviour analytics

2.15 ANALYST DECISION POINTS

Key questions analysts must answer:

1. Is encryption sufficient protection?

2. Is traffic behaviour consistent with business use?
3. Is cryptography forward-secure?
4. Is this collection or communication?
Correct conclusion:
This is a strategic confidentiality breach.

2.16 PRACTICAL ANALYST EXERCISE

Given

• NDR TLS metadata logs

• Firewall logs
• Service inventory

Analyst Tasks

1. Identify weak cryptographic usage

2. Detect anomalous encrypted traffic patterns
3. Assess long-term confidentiality risk
4. Decide escalation and notification

2.17 PASS / FAIL CRITERIA

Analyst passes Module 2 if they can:

• Explain HN-DL in simple terms

• Identify risky encrypted traffic without payloads
• Justify escalation without decryption evidence
• Understand cryptography as a SOC concern

ASSESSMENT
Question 1

Explain why encrypted network traffic can still represent a confidentiality risk even when
strong cryptographic protocols are in use.

Question 2

What characteristics of encrypted traffic would indicate that it is being collected rather
than used for normal transactional communication?

Question 3
Why are long-lived TLS sessions with high outbound data volume considered suspicious in
sensitive environments?

Question 4

Describe the significance of repeated identical TLS or JA3 fingerprints in the context of
encrypted traffic monitoring.

Question 5

Why does the absence of system compromise or malware not eliminate the possibility of a
security breach in Harvest Now, Decrypt Later scenarios?

Question 6

Explain why Harvest Now, Decrypt Later attacks are particularly difficult for traditional SOC
detection models to identify.

Question 7

What role does cryptographic posture, such as key exchange methods and protocol
versions, play in assessing long-term data exposure risk?

Question 8

Why should SOC analysts treat the capture of encrypted sensitive data as a breach even if
decryption has not occurred?

Question 9

What types of telemetry are most important for detecting potential Harvest Now, Decrypt
Later activity in the absence of payload inspection?

Question 10

From a SOC risk management perspective, when should Harvest Now, Decrypt Later
activity be escalated to management or regulators?
MODULE 3
Privileged Session Shadowing
Detecting High-Impact Abuse Inside Approved PAM / PIM Sessions

3.1 PURPOSE OF MODULE 3

Module 3 trains SOC analysts to detect privileged abuse that occurs entirely inside
approved, recorded and compliant privileged access sessions. This module addresses a
dangerous misconception: If PAM approved the session and recorded it, the activity must
be legitimate. This assumption is false in 2026.

By the end of this module, analysts must be able to:

• Detect abuse without credential theft

• Identify external attackers hiding behind legitimate administrators
• Understand why PAM visibility is incomplete
• Escalate incidents that appear authorised on paper

3.2 WHY PRIVILEGED ACCESS IS A PRIME TARGET

Privileged identities control:

• Core banking systems

• Databases
• Backup platforms
• Identity infrastructure
• Security tooling itself

Modern environments have:

• Just-In-Time access
• MFA-protected admin roles
• Session recording
• Approval workflows

Attackers no longer try to bypass these controls. They wait for them to be used.

3.3 ATTACK MODEL OVERVIEW

Attacker Objective

To execute high-impact actions by shadowing a legitimate privileged session, without:

• Stealing admin passwords

• Creating new admin accounts
• Triggering PAM violations
• Generating abnormal login events

This is privilege abuse without privilege escalation.

How Shadowing Occurs

Shadowing may occur through:

• Compromised browser session tokens

• Hijacked admin web sessions
• WebSocket reuse
• Remote session piggybacking
• Secondary network channels inside RDP

The attacker does not replace the admin. They coexist invisibly.

3.4 SIMULATED ENVIRONMENT

Identity and Access

Identity Platform: Azure AD / Entra ID

Privileged Access: PIM (Just-In-Time)
PAM Solution: Centralised Vault with Session Recording

Critical Assets

- Privileged Jump Server

- Core Banking Database
- Backup Management Console

3.5 NORMAL PRIVILEGED ACCESS BASELINE

PIM Activation Log (Normal)

Time: 2026-07-03 21:58:12

User: [Link]@[Link]
Role: Global Administrator
Activation: JIT
Duration: 2 hours
MFA: Passed
Approval: Auto (Change Window)
Source IP: [Link]

PAM Session Metadata

Session ID: PAM-882145

Target: jump-svr-01
Protocol: RDP
Recording: Enabled
Expected Activity:
- Patch verification
- Service restart

Historical Behaviour (90 Days)

- Access limited to infrastructure servers

- No direct database queries
- No bulk data access
- No external data movement

This admin is trusted.

3.6 PRE-ATTACK CONDITION (MISSED SIGNAL)

Prior Identity Anomaly (Weeks Earlier)

Event: MFA Push Accepted

User: [Link]
Context:
- Multiple MFA prompts
- Approved outside normal working hours

No alert escalation occurred.

3.7 SHADOWING BEGINS (INVISIBLE TO PAM)

Jump Server Security Log

Time: 22:03:17
Event ID: 4624
Logon Type: 10 (RemoteInteractive)
Account: [Link]
Source IP: [Link]
PAM session recording begins.

Privilege Assignment

Event ID: 4672

Account: [Link]
Privileges:
- SeDebugPrivilege
- SeTcbPrivilege

Expected for admin.

3.8 LONG CORRELATED LOGS (CRITICAL EVIDENCE)

Network Telemetry (NDR)

Time: 22:07:41
Source: jump-svr-01
Destination: core-db-03
Protocol: SMB
Authentication: Kerberos
Concurrent Sessions: 2

Baseline shows only one SMB session per admin.

Database Audit Log

Time: 22:09:12
User: [Link]
Client Host: jump-svr-01
Query Type: SELECT
Table: customer_profile_full
Rows Returned: 3,950,000
Execution Context: Interactive

This query has never been executed by this admin before.

Data Movement Log

Time: 22:10:05
Source: core-db-03
Destination: jump-svr-01
Data Size: 2.7 GB
Protocol: SMB

EDR Telemetry
Process: [Link]
Parent Process: [Link]
User Context: [Link]
Alert: None

No malicious process detected.

3.9 WHY PAM DID NOT DETECT THIS

PAM Capability Limitation
Session Approval Approved the human
Session Recording Captured primary UI only
Command Tracking Commands appeared legitimate
Credential Vault No password theft

The attacker acted inside the approved session.

3.10 SIEM CORRELATION ALERT (LATE)

Alert Name: Privileged Behaviour Drift
Severity: Medium
Indicators:
- Unusual data volume
- New database access pattern
- Parallel network sessions

This alert is often under-prioritised.

3.11 SOC TIMELINE RECONSTRUCTION

Time Event
21:58 Admin activates PIM
22:03 PAM session starts
22:07 Parallel SMB session detected
22:09 Mass data query executed
22:10 Data staged on jump server
22:18 Admin logs out

Admin denies performing the data query.

3.12 ANALYST DECISION POINTS

Decision 1
Is this insider activity?

Indicators:

• Legitimate admin identity

• Approved access
• Admin denies behaviour

Conclusion: Could be insider or external shadowing.

Decision 2

Is PAM evidence sufficient to close this?

Answer: No. PAM evidence only confirms the admin session existed.

Decision 3

Is escalation required?

Answer: Yes. High-impact data access occurred.

3.13 MITRE ATT&CK MAPPING

• Initial Access: Valid Accounts (T1078)
• Privilege Abuse: Abuse of Elevation Control Mechanism (T1548)
• Credential Access: Web Session Token Abuse
• Collection: Data from Information Repositories (T1213)
• Defense Evasion: Impersonation (T1656)

3.14 SOC RESPONSE PLAYBOOK (EXPECTED)

Immediate Actions

1. Suspend affected admin account

2. Invalidate all active tokens
3. Freeze access to affected data systems

Investigation Actions

1. Review parallel session telemetry

2. Validate admin activity intent
3. Analyse historical admin behaviour
 4. Check identity session reuse

Preventive Controls

1. One-session-per-identity enforcement
2. Privileged UEBA
3. Token binding to device
4. PAM and NDR integration

3.15 ESCALATION CRITERIA

SOC must escalate when:

• Privileged activity deviates from baseline

• Data sensitivity accessed without justification
• Parallel sessions exist
• Admin denies performing actions

Proof of malware is not required.

3.16 PRACTICAL ANALYST EXERCISE

Provided Data

• PIM logs
• PAM session metadata
• Database audit logs
• Network flow logs

Analyst Tasks

1. Identify baseline admin behaviour

2. Detect abnormal activity
3. Decide insider vs external shadowing
4. Propose containment steps
5. Justify escalation decision

3.17 PASS / FAIL CRITERIA

Analyst passes Module 3 if they can:

• Detect abuse inside approved sessions

 • Explain why PAM did not prevent the attack
• Escalate without blaming the admin prematurely
• Recommend controls beyond PAM

ASSESSMENT
Question 1

Explain why an approved PAM or PIM session does not guarantee that all actions
performed during that session are legitimate.

Question 2

A privileged administrator denies performing a high-volume data query that occurred

during their approved session.

What factors should the SOC consider before concluding insider misuse?

Question 3

Why are parallel network sessions during a privileged session considered a high-risk
indicator?

Question 4

Describe how session shadowing can occur without stealing administrative credentials.

Question 5

Why is session recording alone insufficient as a control for detecting privileged abuse?

Question 6

A SOC detects unusual database access by a privileged account during a maintenance

window.

What additional context is required to determine whether escalation is necessary?

Question 7

Explain the role of behavioural baselining in distinguishing legitimate administrative activity

from abuse.
Question 8

Why is it dangerous to immediately classify unusual privileged activity as an insider threat?

Question 9

What logs or telemetry sources are most critical for detecting abuse that occurs inside an
approved privileged session?

Question 10

From a SOC escalation perspective, what conditions justify suspending a privileged

account even when access was technically authorised?
MODULE 4
EDR-Blind API Token Replay
Detecting Identity Abuse Without Endpoints, Logins or Malware

4.1 PURPOSE OF MODULE 4

Module 4 trains SOC analysts to detect high-impact cloud breaches that bypass endpoint
security entirely. This module addresses one of the most dangerous assumptions still
present in SOC operations: If EDR did not alert, nothing bad happened. In 2026, this
assumption is incorrect. By the end of this module, analysts must be able to:

• Understand why EDR cannot detect API token abuse

• Investigate non-interactive identities
• Identify token replay attacks using behaviour, not login failures
• Escalate incidents where authentication is technically valid

4.2 WHY API TOKENS ARE A CRITICAL BLIND SPOT

Modern environments rely on:

• Service principals
• OAuth tokens
• Managed identities
• Workload identities
• API keys

These identities:

• Do not log in interactively

• Do not perform MFA
• Do not generate failed login events
• Often have broad permissions
• Commonly exist outside human review

EDR protects devices. API tokens do not use devices.

4.3 ATTACK MODEL OVERVIEW

Attacker Objective
To exfiltrate sensitive data by replaying a valid API token from outside the organisation,
without:

• Compromising endpoints
• Triggering authentication alerts
• Violating access policies
• Appearing malicious at the application layer

This is identity compromise without identity theft.

Token Exposure Sources

API tokens are commonly exposed through:

• CI/CD pipeline debug logs

• Application configuration files
• Infrastructure-as-code repositories
• Third-party SaaS integrations
• Monitoring and observability tools

Exposure may occur months before detection.

4.4 SIMULATED ENVIRONMENT

Identity

Name: sp-finance-export
Type: Azure AD Service Principal
Authentication: OAuth2 Client Credentials
Token Lifetime: 24 hours

Intended Usage

Purpose:
- Export daily transaction summaries

Expected Behaviour:
- Internal IP range only
- Small response size
- Predictable schedule

4.5 NORMAL BASELINE BEHAVIOUR

API Usage Baseline (90 Days)
Endpoints:
- /finance/report/daily

Execution:
- Once per day at 02:00

Average Response Size:

- 45 MB

Source IP:
- [Link]

IAM Logs

No interactive sign-ins
No MFA events
No conditional access failures

This identity is considered low risk.

4.6 TOKEN REPLAY BEGINS (INVISIBLE PHASE)

Critical Point for Analysts

There is no login event when a token is replayed.

The SOC does not see:

• Failed authentication
• New session creation
• MFA bypass
• Password usage

The token is simply accepted.

4.7 SIMULATED LONG LOG DATA (PRIMARY EVIDENCE)

API Gateway Logs

Time: 2026-08-11 03:14:02

Caller: sp-finance-export
Auth Method: Bearer Token
Token ID: 6f9a-91bc
Source IP: [Link]
ASN: AS9009
Country: NL
Endpoint: /finance/export/full
Response Size: 1.2 GB
Status: 200 OK

Key observations:

• New endpoint usage

• Large response size
• External IP address
• Non-business ASN

Cloud Storage Access Log

Time: 03:14:08
Caller: sp-finance-export
Operation: ReadBlob
Container: finance-archive-prod
Objects Read: 842
Result: Success

Firewall Log

Action: Allow
Reason: Valid OAuth Token
Inspection: Skipped (TLS)

EDR Telemetry

No endpoint activity
No process execution
No network alerts

EDR is functioning correctly and still blind.

4.8 WHY THIS ACTIVITY IS NOT LEGITIMATE

Behaviour Comparison

Parameter Baseline Observed

Source IP Internal External
Endpoint Summary only Full export
Data Volume < 50 MB > 1 GB
Schedule Fixed Random
Destination Internal External

Authentication succeeded, but behaviour is invalid.

4.9 SOC DETECTION POINT (BEHAVIOURAL)
SIEM Correlation Alert

Alert Name: Non-Interactive Identity Behaviour Drift

Severity: Medium
Indicators:
- New API endpoint accessed
- Geo-location change
- Data volume anomaly

This alert often arrives late and is frequently under-prioritised.

4.10 SOC TIMELINE RECONSTRUCTION

Time Event
03:14 Token replayed externally
03:14 Full dataset exported
03:15 Object storage accessed
03:17 Session ends
Daily Pattern repeats

No service disruption occurs.

4.11 WHY CONTROLS DID NOT STOP THIS

Control Reason
EDR No endpoint involved
IAM Token valid
MFA Not applicable
Firewall Encrypted trusted traffic
API Gateway No behaviour rules

The environment behaved as designed.

4.12 RISK ASSESSMENT

Risk Area Assessment
Confidentiality Critical
Integrity Not affected
Availability Not affected
Detection Difficulty Extremely High
 Regulatory Exposure High

This is a silent data breach.

4.13 MITRE ATT&CK MAPPING

• Initial Access: Valid Accounts – Cloud Accounts (T1078.004)
• Credential Access: Unsecured Credentials (T1552)
• Collection: Data from Cloud Storage (T1530)
• Exfiltration: Exfiltration Over Web Services (T1567)
• Defense Evasion: No Endpoint Visibility

4.14 SOC RESPONSE PLAYBOOK (EXPECTED)

Immediate Actions

1. Revoke compromised API token

2. Rotate all related secrets
3. Suspend affected service principal

Investigation Actions

1. Trace token exposure source

2. Review historical API usage
3. Identify affected datasets
4. Estimate exposure window

Preventive Controls

1. Token lifetime reduction

2. Geo-restriction for non-interactive identities
3. Token-level UEBA
4. CI/CD secret scanning
5. Identity-aware API gateways

4.15 ANALYST DECISION POINTS

Key questions analysts must answer:

1. Did EDR fail?

2. Did authentication fail?
3. Was access authorised?
 4. Is this a breach?

Correct answers:

• EDR did not fail

• Authentication succeeded
• Access was unauthorised
• This is a breach

4.16 PRACTICAL ANALYST EXERCISE

Provided Logs

• API gateway logs

• Cloud activity logs
• Firewall logs

Analyst Tasks

1. Identify baseline behaviour

2. Detect token replay indicators
3. Determine breach window
4. Recommend containment steps
5. Justify escalation decision

4.17 PASS / FAIL CRITERIA

Analyst passes Module 4 if they can:

• Explain why EDR is irrelevant here

• Identify API abuse without login events
• Escalate based on behaviour alone
• Recommend controls beyond endpoint security

ASSESSMENT
Question 1

Explain why API token replay attacks may not generate any authentication alerts in
traditional IAM or SIEM systems.

Question 2
Why is endpoint detection and response (EDR) ineffective for detecting non-interactive
identity abuse?

Question 3

A service principal accesses a new API endpoint and exports significantly larger datasets,
but authentication succeeds and no policy violations are logged.

What behavioural indicators suggest this activity may be malicious?

Question 4

Describe how CI/CD pipelines can become a long-term exposure point for API tokens
without triggering SOC alerts.

Question 5

Why should a change in geographic source or ASN be treated as a high-risk indicator for
non-interactive identity usage?

Question 6

Explain the difference between valid authentication and authorised behaviour in the
context of API token misuse.

Question 7

A SOC analyst notes that EDR dashboards are green during a suspected data breach.

Why is this observation insufficient to rule out a security incident?

Question 8

What investigation steps should a SOC analyst prioritise after identifying suspected API
token replay activity?

Question 9

Why is reducing API token lifetime considered a critical preventive control against replay
attacks?

Question 10
From a SOC detection strategy perspective, what types of logs are most critical for
identifying API token abuse in the absence of endpoint telemetry?
MODULE 5
SOAR Abuse and Automation Manipulation
When Attackers Weaponise Your SOC’s Own Response Logic

5.1 PURPOSE OF MODULE 5

Module 5 trains SOC analysts to detect and respond to attacks that exploit security
automation itself, rather than bypassing it. This module addresses a critical but under-
acknowledged risk: If automation is trusted blindly, it becomes an attack surface.

By the end of this module, analysts must be able to:

• Understand how SOAR workflows can be abused

• Detect attacker-triggered automation loops
• Identify containment actions that increase attacker advantage
• Safely interrupt automation during active incidents
• Escalate incidents where the SOC itself is being manipulated

5.2 WHY SOAR BECOMES A TARGET IN 2026

By 2026, most mature SOCs have:

• Automated alert enrichment

• Automated containment actions
• Automated ticketing and closure
• Automated IP blocking
• Automated account disablement

These automations are:

• Deterministic
• Predictable
• Trigger-based
• Trusted implicitly

Attackers study these workflows and design attacks to trigger them deliberately.

5.3 ATTACK MODEL OVERVIEW

Attacker Objective

To manipulate SOC automation so that:

• Defensive actions create blind spots

• Legitimate users or systems are blocked
• Attack infrastructure is whitelisted
• SOC analysts are overwhelmed or misled
• Response logic works against the organisation

This is defence inversion, not defence evasion.

Common SOAR Abuse Patterns

1. Alert flooding to exhaust automation limits

2. Triggering auto-block rules to force service disruption
3. Causing automated account resets to generate confusion
4. Using automation timing to mask real attacks
5. Poisoning enrichment data used by SOAR decisions

5.4 SIMULATED ENVIRONMENT

SOC Tooling
SIEM: Centralised SIEM
SOAR: Integrated with SIEM
Automation:
- Auto IP block (Firewall)
- Auto account disable (IAM)
- Auto ticket closure (Low severity)

Critical Systems

- Internet Banking Portal

- API Gateway
- Customer Identity Platform

5.5 NORMAL AUTOMATION BASELINE

Normal SOAR Behaviour

Alert Type: Brute Force Attempt

Threshold: >10 failures in 5 minutes
Action:
- Block source IP
- Create SOC ticket
- Notify L1

Automation is fast and effective in normal conditions.

5.6 ATTACK PREPARATION (RECON ON SOC LOGIC)

Attackers observe:

• How fast IPs are blocked

• Which alerts auto-close
• Which alerts trigger escalation
• Which actions require human approval

This is done silently over time.

5.7 ATTACK PHASE 1 – AUTOMATION PRIMING

Simulated Authentication Logs

Time: 2026-09-03 01:12:14

Event: Failed Login
Username: random_user_01
Source IP: [Link]
Result: Invalid Password

This repeats from multiple IPs.

SOAR Trigger

Alert: Brute Force Attempt

Severity: Low
Action:
- Block IP
- Close alert

SOC sees nothing unusual.

5.8 ATTACK PHASE 2 – AUTOMATED CONTAINMENT

ABUSE
Simulated Identity Logs

Time: 01:24:41
User: customer-service-admin
Event: Failed Login (x12)
Source IP: [Link]

This is a legitimate admin working remotely.

SOAR Action

Action:
- Disable user account
- Notify IAM
- Ticket created

Attacker has now:

• Removed a legitimate defender

• Caused operational disruption
• Created noise for SOC to manage

5.9 ATTACK PHASE 3 – REAL ATTACK HIDES BEHIND

AUTOMATION NOISE
Real Attack Begins (Overlooked)

API Logs

Time: 01:26:08
Caller: sp-payment-sync
Auth: Valid Token
Endpoint: /payment/export/full
Response Size: 980 MB
Source IP: [Link]

SOC attention is diverted to account lockouts and blocks.

5.10 SOAR BLIND SPOT (CRITICAL FAILURE)

SOAR logic assumes:

• Automation reduces risk

• Alerts are independent
• High volume equals threat

In reality:
 • Automation created distraction
• Critical alerts were buried
• Analysts trusted automation outcomes

5.11 SIEM CORRELATION (LATE AND WEAK)

Alert Name: API Behaviour Anomaly
Severity: Medium
Status: Not Investigated
Reason:
- SOC queue saturated

This alert represented the real breach.

5.12 SOC TIMELINE RECONSTRUCTION

Time Event
01:12 Automation priming begins
01:24 Legitimate admin disabled
01:26 Real data exfiltration starts
01:30 SOC overwhelmed
01:48 Attack completes

5.13 WHY THIS ATTACK SUCCEEDS

Factor Explanation
Automation Trust Analysts trust outcomes
Predictable Logic Attacker plans around it
Alert Flooding SOC attention diverted
No Human Check High-impact actions automated
False Sense of Safety Automation seen as defence

5.14 RISK ASSESSMENT

Risk Area Assessment
Confidentiality Critical
Integrity Potential
Availability Impacted
Detection Difficulty High
Operational Risk Severe
This is both a security and operational incident.

5.15 MITRE ATT&CK MAPPING

• Defense Evasion: Exploit Security Control Logic
• Impact: Service Disruption
• Collection: Data from Cloud Storage
• Exfiltration: Exfiltration Over Web Services

This attack spans multiple ATT&CK phases simultaneously.

5.16 SOC RESPONSE PLAYBOOK (EXPECTED)

Immediate Actions

1. Pause automated containment rules

2. Manually review active alerts
3. Re-enable critical accounts
4. Contain real breach activity

Investigation Actions

1. Identify automation abuse patterns

2. Review SOAR decision logic
3. Correlate alerts across timelines
4. Identify attacker-triggered sequences

Preventive Controls

1. Human approval for high-impact actions

2. Rate limiting on automation
3. Context-aware SOAR logic
4. Automation kill-switch
5. Separate noise-handling from critical response

5.17 ANALYST DECISION POINTS

Key analyst questions:

1. Is automation helping or harming right now?

2. Are multiple alerts related intentionally?
3. Is SOC attention being manipulated?
 4. Should automation be paused?

Correct decision:
Automation must never override judgement.

5.18 PRACTICAL ANALYST EXERCISE

Provided Data

• Authentication logs
• SOAR execution logs
• API gateway logs
• SIEM alert queue

Analyst Tasks

1. Identify automation abuse

2. Detect real attack hidden in noise
3. Decide when to disable automation
4. Propose safer SOAR design

5.19 PASS / FAIL CRITERIA

Analyst passes Module 5 if they can:

• Identify attacker-driven automation misuse

• Recognise when automation increases risk
• Escalate despite automation outcomes
• Recommend secure automation controls

ASSESSMENT
Question 1

Explain why security automation can become an attack surface rather than a defensive
control in mature SOC environments.

Question 2

A SOC experiences a sudden spike in automated IP blocks and account disablements

while a separate data exfiltration alert goes uninvestigated.
What behavioural indicator suggests that automation is being deliberately manipulated by
an attacker?

Question 3

Why is it dangerous to allow high-impact SOAR actions, such as account disablement, to

execute without human review?

Question 4

Describe how attackers can use alert flooding to invert defensive priorities within a SOC.

Question 5

What role does predictability in SOAR workflows play in enabling automation abuse?

Question 6

Explain why the successful execution of an automated containment action does not
necessarily indicate a successful security outcome.

Question 7

A SOC analyst decides to temporarily pause automation during an ongoing incident.

From a SOC decision-making perspective, what risk does this action mitigate?

Question 8

How can enrichment data used by SOAR playbooks be poisoned or manipulated to

influence automated decisions?

Question 9

What safeguards should be implemented to ensure that SOAR automation supports

analysts rather than overrides human judgement?

Question 10

From a SOC maturity standpoint, what distinguishes safe automation from blind
automation?
MODULE 6
SOC Decision-Making and Escalation Mastery
How Analysts Decide Under Uncertainty in Silent Breaches

6.1 PURPOSE OF MODULE 6

Module 6 trains SOC analysts to make correct decisions when evidence is incomplete,
alerts are weak and controls appear to function normally. This module addresses the most
dangerous SOC failure mode: Waiting for certainty before acting. In 2026, waiting for
certainty means responding after the damage is done.

By the end of this module, analysts must be able to:

• Make defensible decisions with partial data

• Escalate incidents without malware confirmation
• Justify actions to management and auditors
• Avoid both panic escalation and dangerous inaction
• Understand escalation as risk management, not alarmism

6.2 WHY DECISION-MAKING IS THE REAL SOC SKILL

Most SOC tools can:

• Detect events
• Correlate logs
• Enrich alerts
• Automate actions

No tool can:

• Understand business context

• Judge intent
• Balance operational impact against risk
• Decide when silence is dangerous

These decisions belong to humans.

6.3 THE 2026 DECISION ENVIRONMENT

SOC analysts now operate in an environment where:

• Alerts are low severity

• Breaches are slow and quiet
• Access is technically valid
• Controls show green status
• Attackers aim for persistence, not disruption

This creates decision paralysis.

6.4 COMMON DECISION FAILURES IN SOCs

Failure 1: Severity Label Obsession

Analysts treat severity as truth rather than a hint.

Example:

Alert Severity: Low

Analyst Decision: Ignore

Reality:
Severity reflects rule confidence, not risk.

Failure 2: Tool Authority Bias

Analysts assume: “If the tool did not alert, nothing is wrong.”

Tools report what they are designed to see, not what matters.

Failure 3: Malware Dependency

Analysts delay escalation until malware is found.

In modern scenarios:

• There may be no malware

• Waiting guarantees loss

Failure 4: Over-Escalation Fear

Analysts fear being wrong more than being late.

This is organisational, not technical.

6.5 DECISION VS DETECTION
Detection answers: “What happened?”

Decision answers: “What should we do next?”

Good SOCs detect well. Great SOCs decide correctly.

6.6 THE SOC DECISION TRIANGLE (2026 MODEL)

Every decision must balance:

1. Behaviour deviation
2. Data sensitivity
3. Trust boundary impact

If two of the three are present, escalation is justified.

6.7 DECISION INPUTS ANALYSTS MUST PRIORITISE

High-Value Inputs

• Behaviour drift from baseline

• Expansion of access scope
• Increase in data volume
• Change in destination or geography
• Abuse of trusted identities
• Timing anomalies

Low-Value Inputs (Overrated)

• Alert severity labels

• Single-tool verdicts
• Lack of malware
• Absence of failed logins
• Green dashboard status

6.8 SIMULATED DECISION SCENARIO A

Situation

Alert:
Non-Interactive Identity Behaviour Drift

Severity:
Medium

Details:
- API token used externally
- Large data export
- Authentication successful

Wrong Decision

“This is probably a misconfigured job. No login failure. Closing.”

Correct Decision

“This identity accessed new endpoints, from a new geography, with large data volume. This
is unauthorised behaviour. Escalate.”

6.9 SIMULATED DECISION SCENARIO B

Situation

PAM Session:
Approved
Recorded
Admin denies unusual activity

Wrong Decision

“PAM approved it. Must be insider error.”

Correct Decision

“Approved access does not equal approved behaviour. Parallel sessions and unusual data
access exist. Escalate.”

6.10 ESCALATION IS NOT ACCUSATION

A critical concept for analysts:

Escalation does not mean:

• Blaming a user
• Declaring a breach publicly
 • Initiating disciplinary action

Escalation means:

• Risk acknowledgement
• Temporary containment
• Controlled investigation

6.11 WHEN TO ESCALATE WITHOUT FULL EVIDENCE

Escalate when:

• Behaviour deviates significantly

• Sensitive data is involved
• Trust boundaries are crossed
• Activity cannot be explained promptly
• Delay increases potential impact

Do not wait for:

• Malware confirmation
• Exploit proof
• User admission
• Business hours

6.12 DECISION DOCUMENTATION (CRITICAL FOR AUDIT)

Every escalation must be documented with:

1. Observed behaviour
2. Baseline comparison
3. Risk assessment
4. Decision rationale
5. Temporary controls applied

Documentation protects:

• The analyst
• The SOC
• The organisation

6.13 SIMULATED DECISION LOG (GOOD PRACTICE)

Decision Summary:
Service account exhibited new storage access, increased data volume and external destination without
change approval.

Risk:
Potential unauthorised data exposure.

Action:
Credentials revoked pending investigation.

Justification:
Behaviour deviates from 90-day baseline. Delay increases risk.

This is defensible even if later proven benign.

6.14 DECISION AUTHORITY LEVELS

L1 Analysts

• Identify deviation
• Raise concern
• Do not close prematurely

L2 Analysts

• Validate behaviour
• Recommend escalation
• Initiate containment

L3 / IR

• Confirm incident
• Lead response
• Communicate to management

Escalation is a handover, not a failure.

6.15 SOC DECISION MATRIX (2026)

Condition Escalate
Valid access, abnormal behaviour Yes
No malware, high data exposure Yes
Encryption used, bulk capture suspected Yes
Automation triggered suspiciously Yes
Single anomaly, low impact Monitor
6.16 PRACTICAL ANALYST EXERCISE
Provided

• Mixed alert queue

• Behavioural anomalies
• No malware indicators

Analyst Tasks

1. Rank alerts by risk, not severity

2. Decide escalation threshold
3. Justify each decision in writing
4. Identify false urgency vs real risk

6.17 PASS / FAIL CRITERIA

Analyst passes Module 6 if they can:

• Escalate correctly with incomplete data

• Avoid waiting for certainty
• Document decisions clearly
• Balance security risk with operational impact

ASSESSMENT
Question 1

An alert shows valid authentication, authorised access and no malware detection, but the
behaviour deviates significantly from the identity’s historical baseline.

What is the primary factor that should drive the SOC analyst’s decision to escalate?

Question 2

Explain why waiting for “complete evidence” before escalating an incident is considered a
high-risk practice in modern SOC operations.

Question 3
A low-severity alert involves access to highly sensitive customer data by a trusted identity.
No policy violations are logged.

Which element should carry more weight in the escalation decision: alert severity or data
sensitivity? Explain why.

Question 4

Describe the difference between escalation and accusation and why confusing these two
concepts leads to delayed incident response.

Question 5

A SOC analyst identifies unusual behaviour but fears escalation because the activity may
later be proven legitimate.

From a SOC governance perspective, why is escalation still the correct action?

Question 6

In a scenario where all security controls appear to be functioning normally, what indicators
justify escalation despite the absence of tool failures?

Question 7

Explain why SOC decision-making in 2026 is better described as risk management rather
than incident confirmation.

Question 8

A senior analyst overrides an automated SOAR action after recognising that automation is
increasing operational risk.

What decision-making principle justifies this override?

Question 9

What documentation elements must be included in an escalation decision to ensure it is

defensible to management, auditors and regulators?

Question 10

A SOC consistently escalates only incidents that involve malware or service disruption.
From a decision-maturity standpoint, what critical category of threats is this SOC likely to
miss?
MODULE 7
Detection Engineering and Analyst Tooling Mastery
Converting Behavioural Risk into Reliable SOC Detections

7.1 PURPOSE OF MODULE 7

Module 7 trains SOC analysts to design, evaluate and improve detections for threats that:

• Have no malware
• Use valid credentials
• Operate within allowed access
• Evade signature-based rules
• Appear operationally normal

This module bridges the gap between:

• Analyst intuition
• SOC tooling
• Detection logic
• Audit-ready justification

By the end of this module, analysts must be able to build detections that survive real
attackers, not just pass lab tests.

7.2 WHY TRADITIONAL DETECTIONS FAIL IN 2026

Traditional Detection Focus

• Known bad IPs

• Malware hashes
• Exploit signatures
• Failed authentication
• IOC matching

These detections are reactive and brittle.

Modern Detection Reality

Attackers now:
 • Use trusted identities
• Abuse automation
• Blend into baseline behaviour
• Avoid repetition
• Operate slowly

Therefore, detections must focus on change, not known badness.

7.3 WHAT DETECTION ENGINEERING REALLY MEANS

Detection engineering is not:

• Writing SIEM queries only

• Adding more alerts
• Increasing severity

Detection engineering is:

• Translating risk into logic

• Defining what “normal” means
• Detecting meaningful deviation
• Reducing false confidence
• Improving analyst decision quality

7.4 CORE DETECTION PRINCIPLES FOR 2026

Every detection should answer:

1. What behaviour is being monitored?

2. Why does deviation matter?
3. What is the expected baseline?
4. What is the risk if ignored?
5. What should the analyst do next?

If these cannot be answered, the detection is incomplete.

7.5 DETECTION CATEGORIES SOCs MUST BUILD

Category 1: Identity Behaviour Drift

Focus:

• Service accounts
 • API tokens
• Privileged users

Examples:

• New API scope usage

• New destination access
• Increased data volume
• New geographic source

Category 2: Trust Boundary Violations

Focus:

• Internal to external transitions

• Privileged to non-privileged systems
• Data sensitivity escalation

Examples:

• Internal service account accessing external storage

• Admin accessing customer datasets
• Backup systems exporting data

Category 3: Encrypted Traffic Anomalies

Focus:

• TLS metadata
• Session behaviour
• Cryptographic posture

Examples:

• Long-lived TLS sessions

• Weak key exchange persistence
• Identical TLS fingerprints

Category 4: Automation and Control Abuse

Focus:

• SOAR logic
• Automated containment
 • Alert sequencing

Examples:

• Repeated triggering of auto-block rules

• Automation masking higher-risk alerts
• SOAR actions increasing exposure

7.6 BASELINE-FIRST DETECTION DESIGN

Step 1: Define Baseline

A baseline must include:

• Identity
• Action
• Volume
• Time
• Destination

Example baseline:

Identity: svc-payment-report
Endpoints: /summary only
Volume: < 100 MB
Destination: Internal only
Frequency: Once per day

Step 2: Define Drift

Drift is not:

• Any change

Drift is:

• Meaningful change without justification

Example drift:

New endpoint: /export/full

Volume: 1.2 GB
Destination: External CDN

Step 3: Define Risk Threshold

Not every drift is critical.

Risk increases when:

• Data sensitivity increases

• Scope expands
• Destination changes
• Timing becomes irregular

7.7 SIMULATED DETECTION DESIGN EXAMPLE

Use Case

Service account data exfiltration without malware.

Detection Logic (Conceptual)

IF
identity_type = service_account
AND api_endpoint NOT IN historical_endpoints
AND data_volume > baseline_average * 5
AND destination != internal
THEN
raise_alert

Why This Works

• No reliance on known IOCs

• Resistant to obfuscation
• Focuses on intent, not method

7.8 DETECTION QUALITY ATTRIBUTES

Good detections are:

• Explainable
• Behaviour-based
• Low-noise
• Actionable
• Auditable

Bad detections are:

• Black-box
 • Signature-only
• Alert-heavy
• Action-ambiguous
• Hard to justify

7.9 TOOL-SPECIFIC THINKING (WITHOUT VENDOR

DEPENDENCE)
SIEM

Role:

• Correlation
• Historical comparison
• Context aggregation

Limitation:

• Cannot infer intent alone

EDR

Role:

• Endpoint execution visibility

Limitation:

• Blind to API and identity abuse

NDR

Role:

• Flow and metadata visibility

Limitation:

• No identity context by default

SOAR

Role:
 • Speed and consistency

Limitation:

• Amplifies flawed logic

Detection engineering must connect these tools, not rely on any one.

7.10 DETECTION FAILURE MODES TO AVOID

1. Over-alerting on benign changes
2. Suppressing alerts due to noise
3. Trusting severity labels blindly
4. Treating detections as final truth
5. Closing alerts without behavioural analysis

7.11 DETECTION TUNING STRATEGY

Phase 1: Observe

• Collect baseline data

• Avoid immediate enforcement

Phase 2: Alert

• Generate low-severity alerts

• Train analysts on interpretation

Phase 3: Enforce

• Increase confidence
• Add automated containment carefully

Automation must come last, not first.

7.12 ANALYST-DETECTION FEEDBACK LOOP

Healthy SOCs ensure:

• Analysts provide feedback on detections

• Detections evolve based on investigations
• False positives are analysed, not ignored
• Detection logic is documented and reviewed
Detection engineering is continuous.

7.13 SIMULATED ANALYST EXERCISE

Provided

• 30 days of identity logs

• API access logs
• Network flow metadata

Analyst Tasks

1. Build a baseline for one service account

2. Identify drift candidates
3. Propose detection logic
4. Define escalation criteria
5. Justify detection to management

7.14 PASS / FAIL CRITERIA

Analyst passes Module 7 if they can:

• Design a behavioural detection

• Explain why it matters
• Reduce false positives logically
• Connect detection to response

ASSESSMENT
Question 1

A service account has been operating for over one year with stable behaviour. Over the last
three weeks, it begins accessing new API endpoints and exporting larger datasets, but all
actions are authorised and no alerts are triggered by IAM or EDR.

What is the primary reason this activity should still be investigated by the SOC?

Question 2

Explain why a detection rule based purely on failed authentication attempts is ineffective
for identifying API token replay attacks in modern cloud environments.
Question 3

A SOC detects repeated long-lived TLS sessions using TLS 1.2 with RSA key exchange
originating from sensitive internal systems and terminating externally. No decryption or
application errors are observed.

From a detection engineering perspective, what behavioural indicators make this traffic
suspicious?

Question 4

Describe the difference between baseline deviation and malicious intent and explain why
detection engineering must focus on the former rather than attempting to directly infer the
latter.

Question 5

An automated SOAR playbook blocks IP addresses after repeated authentication failures.

During an incident, this automation is triggered repeatedly, creating operational disruption
while a separate data exfiltration alert goes uninvestigated.

From a detection engineering standpoint, what control weakness allowed this to happen?

Question 6

Why is it dangerous for SOC analysts to treat alert severity labels as an accurate reflection
of business risk when designing or responding to detections?

Question 7

A detection rule identifies a privileged account accessing a customer database for the first
time. The access occurred during an approved PAM session and was technically allowed.

What additional context must a SOC analyst evaluate before deciding whether to
escalate?

Question 8

Explain why encrypted traffic visibility is still a SOC responsibility even when payload
inspection is not possible or permitted.

Question 9
When designing behavioural detections for service accounts, what are the four minimum
dimensions that must be baselined to ensure the detection is meaningful and defensible?

Question 10

A detection engineer proposes a new rule that generates frequent alerts but has a low
false-negative rate. Analysts report alert fatigue and begin ignoring the alerts.

From a SOC maturity perspective, what is the core design flaw in this detection approach?
END-TO-END ASSESSMENT
Question 1

You observe a service account that has operated normally for over a year. Over a two-
month period, its data access scope gradually expands, data volume increases and
destinations shift from internal systems to cloud storage. All access remains authorised
and no alerts are triggered.

Describe the full analytical process a SOC analyst should follow from first detection to
escalation, including baseline validation, risk assessment and decision justification.

Question 2

An encrypted traffic anomaly shows long-lived TLS sessions using TLS 1.2 with RSA key
exchange. No decryption occurs and no system is compromised.

Explain why this scenario represents a security incident and detail how you would justify
escalation to management who argue that “nothing has been stolen yet.”

Question 3

A privileged administrator performs actions during an approved PAM session that match all
access controls but deviate significantly from their historical behaviour. The administrator
denies performing these actions.

Outline how the SOC should investigate this case without prematurely accusing the
administrator, while still containing potential risk.

Question 4

An API token belonging to a service principal is replayed from an external IP, resulting in
large data exports. There are no failed logins, no MFA events and no endpoint telemetry.

Explain why this incident would be invisible to traditional SOC models and describe the
minimum telemetry required to detect it.

Question 5

A SOAR platform automatically disables multiple user accounts and blocks IPs due to a
surge in authentication alerts. During this time, a separate data exfiltration alert remains
uninvestigated.
Describe how an attacker could intentionally engineer this situation and explain what SOC
controls failed.

Question 6

Your SOC receives a low-severity alert involving access to highly sensitive data by a trusted
identity. Senior management questions why escalation is necessary given the alert
severity.

Construct a risk-based argument for escalation that does not rely on malware, exploit
evidence or policy violations.

Question 7

Explain the difference between valid authentication, authorised access and legitimate
behaviour and describe why confusing these concepts leads to silent breaches.

Question 8

A SOC analyst delays escalation because they cannot determine whether unusual
behaviour is malicious or due to a business change.

Explain why this hesitation represents a decision failure and describe the correct
escalation philosophy in modern SOC operations.

Question 9

Design a high-level detection strategy for identifying service account abuse that avoids
reliance on signatures, malware indicators or static thresholds.

Your answer should address baseline definition, drift detection and analyst action.

Question 10

Explain why endpoint-centric security architectures are insufficient for defending modern
environments, even when EDR coverage is complete.

Question 11

A SOC analyst claims that because PAM session recording captured all keystrokes, no
abuse could have occurred.

Critically analyse this assumption and explain how abuse can still occur inside recorded
sessions.
Question 12

Describe how attackers exploit predictability in SOC automation and explain the difference
between safe automation and dangerous automation.

Question 13

You are asked to justify a decision to revoke service account credentials during an
investigation that later proves benign.

Explain why this action is still considered correct from a SOC governance and risk
management perspective.

Question 14

Explain why SOC analysts must treat encryption as a risk management problem, not a
binary secure/insecure control.

Question 15

Construct a SOC decision matrix for determining when to escalate incidents that involve
no malware, no user complaints and no service disruption.

Explain the rationale behind each escalation criterion.

Question 16

Describe how detection engineering should evolve from generating alerts to shaping
analyst behaviour and decisions.

Question 17

A SOC experiences alert fatigue due to high-volume behavioural detections. Analysts begin
ignoring alerts.

Analyse whether this represents a tooling problem, a detection design problem or a

governance problem and justify your conclusion.

Question 18

Explain why silent breaches are more dangerous than noisy attacks, both technically and
organisationally.
Question 19

Describe the documentation required to defend a SOC escalation decision to regulators

when no confirmed breach has yet occurred.

Question 20

Summarise how a mature SOC in 2026 should redefine “success,” moving beyond metrics
such as alert closure rate or malware detection count.