CySA+ Runbook 01 — SOC Alert Triage and Escalation

Runbook Information

Item	Details
Runbook	01
Runbook Name	SOC Alert Triage and Escalation
Track	CompTIA CySA+
Difficulty	Intermediate
Primary Role	SOC Analyst / Cybersecurity Analyst
Purpose	Standardize initial security alert investigation and escalation
Primary Systems	SIEM, EDR, IDS/IPS, Email Security, WAF, Threat Intelligence
Output	Closed Alert / Continued Investigation / Security Incident / Escalation
Related Labs	Labs 08–20

Operational Principle: An alert is a signal requiring validation. It is not automatically proof of compromise.

1. Purpose

This runbook provides a repeatable process for handling security alerts received by a Security Operations Center.

Use this workflow to move from:

Security Alert
      ↓
Validation
      ↓
Context
      ↓
Evidence
      ↓
Risk Assessment
      ↓
Classification
      ↓
Priority
      ↓
Escalation Decision

The objective is to answer:

Is this alert legitimate?

What happened?

What asset is involved?

Which identity is involved?

Is malicious activity confirmed?

What is the potential impact?

Is the activity still occurring?

How urgent is the response?

Should this become an incident?

Who needs to receive the escalation?

2. When to Use This Runbook

Use this runbook whenever a SOC analyst receives an alert from:

SIEM

EDR / XDR

IDS / IPS

Firewall

Email Security

Identity Provider

Cloud Security Platform

Web Application Firewall

Vulnerability Platform

Threat Intelligence

Data Loss Prevention

Other Security Monitoring Systems

This runbook should normally be the starting workflow before moving into a specialized investigation runbook.

3. Expected Outcomes

Every alert should ultimately reach a defensible disposition.

Use:

Alert
  ↓
├── False Positive
│
├── Benign True Positive
│
├── Suspicious — Continue Investigation
│
├── Confirmed Security Incident
│
└── Insufficient Evidence — Monitor / Escalate

Never close an alert simply because:

"I couldn't find anything."

Document what was checked and why the disposition is justified.

4. Triage Priorities

During initial triage, prioritize:

1. Critical Assets

2. Privileged Identities

3. Active Threats

4. Confirmed Malware

5. Successful Unauthorized Access

6. Lateral Movement

7. Data Exposure

8. Destructive Activity

9. Multiple Correlated Detections

10. High-Confidence Threat Intelligence

5. SOC Triage Workflow

Use the following workflow:

Alert Received
      ↓
Review Alert
      ↓
Validate Detection
      ↓
Identify Asset
      ↓
Identify Identity
      ↓
Establish Timeline
      ↓
Collect Supporting Evidence
      ↓
Enrich Indicators
      ↓
Correlate Related Events
      ↓
Determine Scope
      ↓
Assess Impact
      ↓
Classify Alert
      ↓
Assign Severity
      ↓
Contain if Authorized
      ↓
Escalate / Close
      ↓
Document

6. Step 1 — Record the Alert

Before modifying anything, capture the original alert.

Record:

Alert ID:

Alert Name:

Detection Source:

Detection Time:

Severity:

Source IP:

Destination IP:

Hostname:

Username:

Process:

Filename:

Hash:

Domain:

URL:

Detection Rule:

Raw Event:

Preserve the original detection context.

7. Step 2 — Read the Detection Carefully

Understand exactly what triggered the alert.

Ask:

What behavior was detected?

Which telemetry triggered it?

Which rule generated the alert?

What threshold was crossed?

Was the activity blocked?

Was it merely detected?

How confident is the detection?

Do not investigate only from the alert title.

For example:

"Malware Detected"

may mean:

File Detected
     ↓
Blocked Before Execution

or:

File Executed
     ↓
Detected Afterwards

Those represent very different risks.

8. Step 3 — Identify the Detection Source

Determine whether the alert originated from:

SIEM

EDR

Firewall

IDS

WAF

Email Gateway

Identity Platform

Cloud Security Tool

Threat Intelligence

Then identify the underlying evidence.

Example:

SIEM Alert
   ↓
Windows Event 4625

or:

IDS Alert
   ↓
Network Packet / Flow

9. Step 4 — Identify the Affected Asset

Record:

Hostname:

IP Address:

Operating System:

Asset Owner:

Business Function:

Environment:

Criticality:

Internet Exposure:

Classify asset criticality:

Low

Medium

High

Critical

An alert involving:

Employee Laptop

and one involving:

Production Identity Server

may require different response priorities.

10. Step 5 — Identify the User or Identity

Record:

Username:

Account Type:

Department:

Privilege Level:

Normal Host:

Authentication Method:

MFA Status:

Determine whether the identity is:

Standard User

Administrator

Service Account

Cloud Identity

Application Identity

Privileged Account

Privileged identities generally increase incident risk.

11. Step 6 — Establish the Initial Timeline

Record:

First Alert:

First Related Event:

Last Related Event:

Current Time:

Activity Still Occurring:
Yes / No / Unknown

Begin with a reasonable window around the alert.

Example:

Alert:
10:30

Initial Investigation Window:
09:30–11:00

Expand as evidence requires.

12. Step 7 — Validate the Alert

Determine whether the underlying activity actually occurred.

For example:

Alert:
Repeated Authentication Failures

Validate using authentication telemetry.

Or:

Alert:
Suspicious PowerShell

Validate using:

Process Creation

PowerShell Logs

Command Line

Parent Process

User Context

13. Step 8 — Identify the Triggering Event

Record the specific evidence responsible for the alert.

Example:

Detection:

10 failed authentication attempts
from the same external IP
against one account
within 3 minutes.

This provides more useful context than:

Brute Force Alert

14. Step 9 — Determine Whether the Detection Was Prevented

Check:

Blocked

Quarantined

Denied

Terminated

Allowed

Detection Only

Unknown

Example:

Malicious File
     ↓
EDR Blocked Execution

may have lower immediate impact than:

Malicious File
     ↓
Execution Allowed
     ↓
Network Communication

But blocked activity may still indicate attempted compromise.

15. Step 10 — Review Historical Activity

Search backward.

Ask:

Has this host generated similar alerts?

Has this user generated similar alerts?

Has this IP been seen before?

Has this hash appeared elsewhere?

Has this domain been contacted previously?

This helps distinguish:

Isolated Event

from:

Ongoing Campaign

16. Step 11 — Pivot on the Host

Search the hostname or IP across available telemetry.

Review:

Authentication

Process Activity

Endpoint Alerts

DNS

Network Connections

File Activity

Security Alerts

Look for events occurring before and after the original alert.

17. Step 12 — Pivot on the User

Search the identity across:

Authentication Logs

Endpoint Logs

Cloud Logs

VPN

Email Security

Application Logs

Determine:

Which systems did the user access?

From where?

When?

Was privilege involved?

Was activity normal?

18. Step 13 — Pivot on the Source IP

Search:

Source IP

across:

Firewall

Authentication

Zeek

Suricata

WAF

Web Logs

Threat Intelligence

Determine whether the source:

Targeted multiple accounts

Targeted multiple systems

Generated multiple alerts

Communicated with compromised assets

19. Step 14 — Pivot on Domains and URLs

For suspicious:

Domain

URL

search:

DNS Logs

Proxy Logs

Web Logs

Email Logs

Endpoint Telemetry

Determine:

Which hosts contacted it?

Which users?

When?

How frequently?

20. Step 15 — Pivot on File Hashes

For:

MD5

SHA-1

SHA-256

prefer SHA-256 where available.

Search:

EDR

SIEM

File Telemetry

Threat Intelligence

Determine whether the artifact exists on:

One Host

or:

Multiple Hosts

21. Step 16 — Enrich Suspicious Indicators

Enrich:

IP

Domain

URL

Hash

using approved threat-intelligence sources.

Document:

Indicator:

Reputation:

Classification:

Associated Threat:

First Seen:

Last Seen:

Confidence:

Source:

Do not classify something as malicious solely because one reputation service reports it.

22. Step 17 — Look for Correlated Alerts

Search for additional alerts involving:

Same Host

Same User

Same Source IP

Same Domain

Same Hash

Same Time Window

A sequence such as:

Authentication Alert
       ↓
PowerShell Alert
       ↓
Malware Alert
       ↓
DNS Alert
       ↓
Network Alert

is significantly more concerning than a single isolated event.

23. Step 18 — Build the Event Sequence

Create:

Authentication
      ↓
Process Execution
      ↓
File Creation
      ↓
DNS Query
      ↓
Network Connection

Then ask:

Does the sequence make technical and chronological sense?

24. Step 19 — Check for Initial Access

Look for evidence involving:

Phishing

Compromised Credentials

Public-Facing Application

Malicious Download

Remote Service

External Device

Do not force a root-cause conclusion during initial triage.

25. Step 20 — Check for Execution

Look for:

Suspicious Process

PowerShell

Shell

Script Interpreter

Unknown Executable

Office Child Process

Record:

Process:

Parent:

Command Line:

User:

Timestamp:

26. Step 21 — Check for Persistence

Look for:

Scheduled Task

Service

Startup Entry

Registry Modification

Cron

New Account

Persistence often increases urgency.

27. Step 22 — Check for Privilege Activity

Determine whether:

Administrative privileges

Root

sudo

Cloud administrative roles

Service-account privileges

were involved.

Distinguish:

Privilege Escalation

from:

Use of Already-Privileged Credentials

28. Step 23 — Check for Lateral Movement

Look for:

RDP

SMB

SSH

WinRM

Remote Services

Administrative Shares

Internal Authentication

Record:

Source Host

Destination Host

Identity

Protocol

Outcome

29. Step 24 — Check for Command-and-Control

Look for:

Suspicious DNS

Rare External IP

Periodic Connections

Unexpected Ports

Connections from Suspicious Processes

Require supporting evidence before classifying communication as C2.

30. Step 25 — Check for Data Access or Exfiltration

Look for:

Sensitive File Access

Archive Creation

Large Outbound Transfers

Cloud Storage Activity

Database Exports

Unusual Uploads

Classify:

Confirmed

Suspected

Not Observed

Unknown

31. Step 26 — Determine Whether Activity Is Active

Ask:

Is the suspicious process running?

Is the account still authenticated?

Are connections continuing?

Are new alerts appearing?

Are additional systems being contacted?

Classify:

Active

Stopped

Contained

Historical

Unknown

Active threats normally require faster escalation.

32. Step 27 — Determine Scope

Identify:

Affected Hosts

Affected Users

Affected Applications

Affected Accounts

Affected Network Segments

Affected Cloud Resources

Use:

Confirmed Compromised

Suspected Compromised

Exposed / Contacted

Unaffected

Unknown

Do not label a system compromised solely because it was contacted.

33. Step 28 — Assess Confidentiality Impact

Ask:

Was sensitive information accessed?

Were credentials exposed?

Was data transferred?

Were privileged resources accessed?

34. Step 29 — Assess Integrity Impact

Ask:

Were files modified?

Were configurations changed?

Were accounts created?

Was persistence installed?

Was application data modified?

35. Step 30 — Assess Availability Impact

Ask:

Were systems unavailable?

Were services stopped?

Were files encrypted?

Was business functionality interrupted?

36. Step 31 — Classify the Alert

Use one of the following.

False Positive

Detection triggered,
but underlying activity was not malicious
and the rule incorrectly classified it.

Example:

Approved administrative scanner
triggered an IDS signature.

Benign True Positive

Detection correctly identified the behavior,
but the activity was authorized and legitimate.

Example:

Approved administrator executed
a monitored administrative PowerShell command.

Suspicious Activity

Evidence indicates potentially malicious activity,
but compromise is not yet confirmed.

Confirmed Incident

Evidence supports unauthorized or malicious activity
requiring incident response.

Inconclusive

Available telemetry is insufficient
to make a defensible determination.

37. Step 32 — Assign Severity

Use organizational severity criteria where available.

A practical model is:

Low

Low-impact event

No confirmed compromise

Low-value asset

No privileged access

No ongoing threat

Medium

Suspicious activity

Limited scope

Potential compromise

No major business impact

High

Confirmed compromise

Malware execution

Privileged account involvement

Persistence

Lateral movement

Sensitive asset involvement

Critical

Active widespread compromise

Ransomware

Confirmed sensitive data exfiltration

Critical infrastructure impact

Domain-wide privilege compromise

Major business disruption

38. Severity Is Not the Same as Alert Severity

A SIEM may report:

Alert Severity:
Critical

but your investigation may determine:

Incident Severity:
Low

or vice versa.

The detection severity reflects the rule.

The incident severity reflects:

Context
+
Scope
+
Impact
+
Confidence

39. Step 33 — Assign Response Priority

Example:

P1 — Immediate

P2 — Urgent

P3 — Standard

P4 — Monitor / Informational

Priority considers both:

Severity
+
Urgency

40. P1 Escalation Criteria

Immediately escalate when evidence indicates:

Active ransomware

Confirmed data exfiltration

Domain administrator compromise

Critical infrastructure compromise

Active lateral movement

Widespread malware

Destructive activity

Critical production outage caused by attack

41. P2 Escalation Criteria

Escalate urgently for:

Confirmed endpoint compromise

Malware execution

Persistence

Privileged account misuse

Successful unauthorized authentication

Potential lateral movement

High-confidence C2

Compromised public-facing application

42. P3 Escalation Criteria

Examples:

Suspicious activity requiring deeper investigation

Limited-scope incident

Blocked attack with additional investigation required

Potential credential compromise

43. Step 34 — Decide Whether Immediate Containment Is Required

Ask:

Will delaying containment increase damage?

Is attacker activity still occurring?

Could the attacker move laterally?

Could data be exposed?

Could business systems be disrupted?

If yes, containment may need to occur before the complete investigation is finished.

44. Common Immediate Containment Options

Depending on authorization:

Isolate Endpoint

Disable Account

Revoke Sessions

Block IP

Block Domain

Block Hash

Quarantine File

Restrict Network Segment

Disable Application

Protect Backups

Do not perform containment outside your assigned authority.

45. Preserve Evidence Before Destructive Actions

Before:

Deleting Files

Reimaging

Restarting

Clearing Logs

Removing Persistence

consider collecting:

Logs

Process Information

Network Connections

Suspicious Files

Hashes

Memory

Screenshots

Authentication Evidence

46. Step 35 — Determine Escalation Destination

Depending on the incident:

SOC Tier 2 / Tier 3

Incident Response

Digital Forensics

Threat Hunting

Malware Analysis

Identity Team

Network Security

Cloud Security

Application Security

Vulnerability Management

Security Leadership

47. Escalation Should Include Context

Never escalate only:

"Please investigate this alert."

Provide:

What happened

When it happened

Which systems are affected

Which identities are affected

What evidence supports the assessment

What has already been checked

What actions have already been taken

What remains unknown

What action is requested

48. SOC Escalation Template

Use:

Case ID:
<case>

Alert:
<alert>

Classification:
<classification>

Severity:
<severity>

Priority:
<priority>

Status:
Active / Contained / Historical / Unknown

Affected Asset:
<hostname / IP>

Affected Identity:
<username>

Detection Time:
<timestamp>

Earliest Suspicious Activity:
<timestamp>

Summary:
<short explanation>

Evidence:
<key supporting evidence>

IOCs:
<IP / Domain / Hash / URL>

Scope:
<known affected systems/users>

Potential Impact:
<confidentiality / integrity / availability>

Actions Taken:
<actions>

Recommended Immediate Action:
<recommendation>

Outstanding Questions:
<unknowns>

Escalated To:
<team>

Escalation Time:
<timestamp>

49. Example Escalation

Case ID:
SOC-2026-081

Classification:
Confirmed Endpoint Compromise

Severity:
High

Priority:
P2

Affected Asset:
FIN-WIN23

Affected Identity:
user01

Summary:
Suspicious authentication was followed by
PowerShell execution and an unknown executable.

Evidence:
Authentication logs show successful access from
an unusual source. Endpoint telemetry shows
PowerShell spawning an unknown executable.

Network:
The endpoint subsequently contacted an
unusual external domain.

Scope:
One endpoint confirmed affected.
Additional hosts currently being searched.

Status:
Potentially Active

Recommended Action:
Isolate FIN-WIN23, secure user01,
preserve evidence, block validated indicators,
and perform enterprise IOC hunting.

Escalated To:
Incident Response

50. Step 36 — Document Analyst Actions

Record every significant analyst action.

Use:

Time	Analyst Action	Result
10:32	Opened alert	Initial review
10:35	Queried host	Related endpoint alert found
10:39	Queried user	Suspicious login identified
10:44	Enriched IP	High-risk infrastructure
10:49	Escalated case	IR notified

This creates an investigation audit trail.

51. Step 37 — Record Evidence Sources

Document exactly where evidence originated.

Example:

EVID-001
Source:
Windows Security

Event:
4624

Host:
WIN01

Time:
10:21

This makes findings reproducible.

52. Step 38 — Document Analyst Confidence

For major conclusions, use:

Low Confidence

Medium Confidence

High Confidence

Example:

Assessment:
Potential C2 communication

Confidence:
Medium

Reason:
Rare external destination and suspicious process
correlation observed, but destination reputation
is inconclusive.

53. Step 39 — Identify Unknowns

Good investigations explicitly document gaps.

Examples:

Initial access unknown

No endpoint telemetry before 09:00

Source IP attribution unknown

Data exfiltration not confirmed

Memory evidence unavailable

Unknown does not mean benign.

54. Step 40 — Close or Transfer the Alert

Before closing or transferring, ensure:

Classification Complete

Severity Assigned

Scope Documented

Evidence Recorded

Timeline Updated

Actions Recorded

Escalation Completed

Next Owner Identified

55. Alert Closure Requirements

For a closed alert, document:

Final Classification:

Reason:

Evidence Reviewed:

Business Context:

Related Alerts:

Threat Intelligence:

Analyst:

Closure Time:

Avoid closure notes such as:

Looks fine.

False positive.

Nothing found.

These provide no defensible investigation record.

56. False Positive Closure Example

Classification:
False Positive

Alert:
Suspicious Network Scanner

Investigation:
Source IP belongs to the authorized
vulnerability scanner.

Validation:
Scanning activity occurred during the
approved vulnerability assessment window.

Related Activity:
No unauthorized activity identified.

Impact:
None.

Disposition:
Close as False Positive.

Recommendation:
Consider tuning the rule to recognize
the approved scanner.

57. Benign True Positive Example

Classification:
Benign True Positive

Alert:
PowerShell Administrative Activity

Investigation:
PowerShell activity occurred as detected.

User:
Authorized systems administrator.

Change:
Associated with approved maintenance activity.

Impact:
None.

Disposition:
Close as Benign True Positive.

58. Confirmed Incident Example

Classification:
Confirmed Security Incident

Alert:
Suspicious Endpoint Execution

Evidence:
Unknown executable launched by PowerShell.

Network:
Process contacted suspicious external infrastructure.

Persistence:
New scheduled task identified.

Scope:
One endpoint confirmed compromised.

Severity:
High

Priority:
P2

Disposition:
Escalate to Incident Response.

59. Triage Decision Tree

Use:

Alert Received
      ↓
Is underlying activity real?
      ↓
 ┌────┴────┐
 No        Yes
 ↓          ↓
False     Is activity
Positive  authorized?
            ↓
       ┌────┴────┐
      Yes        No
       ↓          ↓
   Benign TP    Is malicious
               activity confirmed?
                    ↓
               ┌────┴────┐
              No         Yes
               ↓          ↓
          Suspicious    Incident
               ↓          ↓
        Investigate    Assess Scope
                           ↓
                     Assign Severity
                           ↓
                       Contain
                           ↓
                       Escalate

60. Rapid Triage Checklist

For time-sensitive SOC operations:

□ Alert validated

□ Host identified

□ User identified

□ Detection time recorded

□ Activity status determined

□ Related alerts searched

□ Host pivot completed

□ User pivot completed

□ IOCs extracted

□ Threat intelligence checked

□ Scope estimated

□ Impact assessed

□ Classification assigned

□ Severity assigned

□ Priority assigned

□ Containment considered

□ Evidence preserved

□ Escalation decision made

□ Case documented

61. Escalate Immediately If

Do not wait for complete investigation when you observe:

Active ransomware

Active destructive behavior

Critical system compromise

Privileged account takeover

Active lateral movement

Confirmed sensitive data exfiltration

Multiple systems becoming compromised

Active attacker persistence

Rapidly expanding incident scope

Escalate with the evidence currently available and continue investigation.

62. Common Analyst Mistakes

Avoid:

Trusting the alert title

Closing alerts too quickly

Ignoring business context

Treating every IOC as malicious

Relying on one threat-intelligence source

Failing to pivot on users

Failing to pivot on hosts

Ignoring events before the alert

Ignoring related alerts

Confusing detection with compromise

Confusing contact with compromise

Ignoring privileged identities

Failing to preserve evidence

Performing unauthorized containment

Poor escalation notes

Failing to document unknowns

63. Quality Standard

A high-quality SOC triage should allow another analyst to understand:

Why the alert fired

What happened

What was investigated

What evidence was found

What was ruled out

What remains unknown

How serious the activity is

What action was taken

Why the alert was closed or escalated

without repeating the investigation from scratch.

64. Analyst Handoff

If your shift ends before investigation is complete, provide:

Case ID

Current Classification

Current Severity

Affected Assets

Affected Identities

Key Evidence

Current Timeline

IOCs

Completed Actions

Outstanding Tasks

Immediate Risks

Next Recommended Action

Never leave only:

"Still investigating."

65. Runbook Documentation Template

# SOC Alert Triage Record

## Case Information

Case ID:

Analyst:

Date:

## Alert

Alert ID:

Alert Name:

Detection Source:

Detection Time:

Original Severity:

## Asset

Hostname:

IP:

Criticality:

Business Function:

## Identity

Username:

Privilege:

Account Type:

## Detection Validation

What triggered the alert?

Was the activity confirmed?

Was it blocked?

## Investigation Timeline

Document relevant events.

## Related Alerts

Document correlated detections.

## Host Investigation

Document findings.

## Identity Investigation

Document findings.

## IOC Investigation

### IPs

### Domains

### URLs

### Hashes

## Threat Intelligence

Document enrichment and confidence.

## Scope

### Confirmed Compromised

### Suspected

### Exposed / Contacted

### Unaffected

### Unknown

## Impact

### Confidentiality

### Integrity

### Availability

## Classification

False Positive / Benign True Positive / Suspicious / Confirmed Incident / Inconclusive

## Severity

Low / Medium / High / Critical

## Priority

P1 / P2 / P3 / P4

## Threat Status

Active / Contained / Historical / Unknown

## Evidence

Document preserved evidence.

## Actions Taken

Document analyst actions.

## Containment

Document actions or recommendations.

## Escalation

Escalated:
Yes / No

Escalated To:

Escalation Time:

## Outstanding Questions

Document investigation gaps.

## Final Analyst Assessment

Summarize the findings.

## Disposition

Close / Monitor / Continue Investigation / Escalate

66. Runbook Validation Checklist

Alert

• Original alert preserved

• Alert rule understood

• Detection source identified

• Triggering telemetry validated

• Prevention/block status determined

Context

• Asset identified

• Asset criticality established

• Identity identified

• Identity privilege determined

• Investigation window established

Investigation

• Host pivot completed

• User pivot completed

• Source IP pivot completed where relevant

• Domain/URL pivot completed where relevant

• Hash pivot completed where relevant

• Historical activity reviewed

• Related alerts identified

• Event sequence constructed

Threat Activity

• Initial access considered

• Execution investigated

• Persistence investigated

• Privileged activity investigated

• Lateral movement investigated

• C2 investigated

• Data access/exfiltration considered

Intelligence

• Relevant IOCs extracted

• IOCs enriched

• Internal IOC matches searched

• Threat-intelligence confidence documented

Scope & Impact

• Affected systems identified

• Affected identities identified

• Compromised vs contacted assets distinguished

• Confidentiality impact assessed

• Integrity impact assessed

• Availability impact assessed

• Activity status determined

Decision

• Alert classified

• Incident severity assigned

• Response priority assigned

• Containment requirements considered

• Escalation criteria evaluated

Documentation

• Analyst actions recorded

• Evidence sources documented

• Confidence documented

• Unknowns documented

• Escalation contains sufficient context

• Final disposition recorded

67. Runbook Summary

The purpose of SOC triage is not simply:

Alert
 ↓
Close

A professional workflow is:

Alert
  ↓
Validate
  ↓
Understand Context
  ↓
Collect Evidence
  ↓
Correlate
  ↓
Determine Scope
  ↓
Assess Impact
  ↓
Classify
  ↓
Prioritize
  ↓
Contain
  ↓
Escalate
  ↓
Document

The key operational principle is:

Treat every alert as a hypothesis that must be validated with evidence, context, and correlation before making a security decision.

What’s Next?

CySA+ Runbook 02 — Suspicious Authentication Investigation

The next runbook focuses specifically on identity-related alerts.

You will build a repeatable procedure for investigating:

• failed authentication

• successful authentication after failures

• brute-force patterns

• password spraying

• credential stuffing indicators

• unusual source IPs

• impossible or unusual access patterns

• privileged authentication

• service-account anomalies

• MFA-related events

• authentication across multiple systems

• compromised-account indicators

• session activity

• identity scope

• credential containment

• escalation

The workflow progresses from:

Generic Alert Triage
        ↓
Identity Alert
        ↓
Authentication Evidence
        ↓
User Context
        ↓
Source Analysis
        ↓
Behavior Correlation
        ↓
Compromise Assessment
        ↓
Identity Containment

➡️ Next: CySA+ Runbook 02 — Suspicious Authentication Investigation