[SUP] Vercel Supply Chain Breach via AI Tool–Driven OAuth Compromise

Report Type: Supply Chain Threat Assessment
Threat Category: Identity Compromise via OAuth and SaaS Integration Abuse
Assessment Date: April 20, 2026
Primary Impact Domain: Identity and Access Control
Secondary Impact Domains: Cloud Infrastructure Access; Credential and Secret Exposure; SaaS Operational Integrity
Affected Asset Class: Enterprise Identity Systems; SaaS Platforms and Integrations; Credential Stores and Configuration Data; Cloud-Connected Services
Threat Objective Classification: Unauthorized Access, Credential Exposure, and Downstream System Access

BLUF

‍  Unauthorized access occurred through a supply chain–linked identity compromise involving OAuth-based authorization that enabled attacker access without traditional credential theft. The primary risk is trusted identity misuse, allowing access to internal systems, sensitive credentials, and configuration data with potential downstream credential exposure. The exploit posture is high because initial access activity appears legitimate and detection is only reliable after attacker behavior progresses into privileged or sensitive operations . Immediate executive action is required to strengthen identity governance, enforce OAuth control, and ensure detection capability focused on post-access behavior rather than initial compromise.

S3 Why This Matters Now

·        Expansion of OAuth-based SaaS integrations increases enterprise attack surface

·        AI-enabled tools introduce new trust pathways into enterprise identity systems

·        OAuth authorization enables access without direct credential compromise while preserving trusted identity context

·        Supply chain attacks are shifting toward identity trust abuse instead of software exploitation

·        Detection models remain misaligned with identity-driven attack patterns

·        Early-stage attacker activity blends into legitimate SaaS usage

·        Identity compromise enables direct access into cloud and operational environments

S4 Key Judgments

·        Attack represents a supply chain–origin identity compromise, not a malware-driven intrusion

·        OAuth authorization is the most likely access mechanism based on attack class behavior

·        Detection of initial compromise is structurally limited without OAuth telemetry

·        High-confidence detection requires correlation with privileged or sensitive follow-on activity

·        Post-access behavior drives the majority of enterprise risk exposure

·        Weak identity baselining creates significant detection blind spots

·        Cloud environments become secondary risk surfaces through credential reuse

·        Attackers can evade detection by operating within known identity and access patterns

S5 Executive Risk Summary

Risk Overview

·        Unauthorized identity access through trusted SaaS integration pathways

·        Exposure of internal systems, sensitive credentials, and configuration data

·        Potential downstream compromise through credential reuse

Business Impact

·        Unauthorized access to internal operational environments

·        Exposure of sensitive credentials and system configuration data

·        Risk of configuration manipulation or deployment abuse

·        Expansion of compromise into cloud environments

Likelihood

·        High due to widespread OAuth usage and SaaS dependency

·        Increased in environments lacking OAuth governance and monitoring

Detection Reality

·        Early-stage detection is limited

·        Detection becomes reliable only after measurable attacker activity

Overall Risk Level

·        High

S6 Executive Cost Summary

Low Impact Scenario

·        Identity compromise detected shortly after first privileged or sensitive action

·        Limited exposure of low-sensitivity configuration or credentials

·        No evidence of downstream credential reuse

·        Containment limited to session revocation and targeted credential rotation

·        Estimated Cost Range: $120K – $350K

Moderate Impact Scenario (Most Likely)

·        Detection occurs after access to internal systems and partial retrieval of sensitive credentials or configuration

·        Exposure includes credentials with limited privilege scope

·        Potential or limited downstream credential use cannot be ruled out

·        Requires coordinated credential rotation and system validation across affected environments

·        Estimated Cost Range: $350K – $1.8M

High Impact Scenario

·        Extended attacker dwell time with repeated privileged access and high-value credential retrieval

·        Exposure includes credentials enabling cross-environment or cloud access

·        Confirmed or likely downstream credential operationalization

·        Requires large-scale credential rotation, investigation, and environment validation

·        Estimated Cost Range: $1.8M – $6.5M+

S6A Key Cost Drivers

·        Detection delay and attacker dwell time

·        Privilege level of compromised identity

·        Sensitivity and scope of exposed credentials and configuration data

·        Credential reuse potential across environments

·        Cloud environment exposure and scale

·        Logging completeness and investigation visibility

·        Operational dependency on SaaS platforms

S6B Compliance and Risk Context

·        Identity compromise may trigger access control and data protection violations

·        Exposure of credentials may require breach disclosure obligations

·        SaaS supply chain involvement introduces third-party accountability considerations

·        Weak OAuth governance reflects inadequate access control enforcement

·        Incomplete logging impacts audit defensibility and response validation

·        Cross-environment credential misuse expands regulatory exposure

S7 Risk Drivers

·        Expansion of OAuth trust relationships without strict governance

·        Limited visibility into OAuth authorization and token activity

·        Weak identity baselining across users and devices

·        Incomplete SaaS audit logging and normalization

·        Limited visibility into credential and configuration access

·        Over-reliance on endpoint and network detection models

·        Use of shared or automated identities reducing attribution clarity

·        Fragmented telemetry across identity, SaaS, and cloud systems

S8 Bottom Line for Executives

·        Attack exploits identity trust relationships rather than technical vulnerabilities

·        Prevention of initial access is limited and detection must focus on post-access behavior

·        Highest risk is driven by credential exposure and reuse across environments

·        Organizations lacking strong identity visibility operate with material detection gaps

·        Immediate priority is strengthening identity governance, OAuth control, and SaaS monitoring

S9 Board-Level Takeaway

This incident demonstrates that enterprise risk is shifting toward identity-driven compromise, where trusted SaaS and OAuth relationships can be exploited without triggering traditional defenses. The organization’s exposure is determined by its ability to detect and respond to abnormal identity behavior and its downstream impact rather than prevent initial access. Failure to enforce strong identity governance, OAuth control, and cross-platform visibility creates systemic risk that can propagate across internal systems and cloud environments.

Figure 2

S10 Supply Chain Attack Overview

·        Attack originates from compromise of a trusted third-party SaaS or AI-enabled integration

·        Initial access is established through identity trust relationships rather than software exploitation

·        OAuth authorization is the most likely mechanism enabling attacker-controlled access to enterprise identities

·        Access is obtained without credential theft, allowing activity to appear legitimate

·        Compromise leverages enterprise trust in SaaS integrations and identity federation

·        Attack progression relies on post-access identity misuse rather than payload execution

·        Supply chain vector enables scalable attack potential across multiple organizations

S11 Affected Product / Trust Dependency Overview

·        Enterprise identity provider integrated with third-party SaaS applications is the primary dependency

·        OAuth-based authorization creates delegated access between identity provider and external applications

·        AI-enabled or automation-driven SaaS tools introduce additional identity trust relationships

·        Internal SaaS platforms rely on identity provider for authentication and access control

·        Trust model assumes authorized applications operate within defined permission scopes

·        Compromise occurs when attacker-controlled application is granted legitimate authorization

·        Downstream dependencies include SaaS control-plane systems, internal environments, and cloud platforms

S12 Enabling Vulnerability and Exposure Context

·        No traditional software vulnerability is required for initial compromise

·        Exposure is created through permissive OAuth authorization workflows

·        Lack of strict application approval governance enables unauthorized application consent

·        Limited visibility into OAuth authorization and token lifecycle reduces detection capability

·        Over-permissioned application scopes increase potential impact

·        Weak identity baselining limits detection of abnormal authorization behavior

·        Incomplete SaaS audit logging reduces visibility into post-authorization activity

·        Exposure is amplified by reliance on identity as the primary control boundary

S13 Exploitability, Patch, and Exposure Management Status

·        Exploitability is high due to reliance on authorization workflows and user consent mechanisms

·        No patch exists because the attack does not rely on a software flaw

·        Risk persists until identity governance and OAuth control mechanisms are strengthened

·        Exposure management depends on restricting OAuth approval, enforcing least privilege, and monitoring authorization activity

·        Organizations with poorly governed OAuth ecosystems remain highly exposed

·        Mitigation is operational and policy-driven rather than patch-driven

·        Detection and response capability becomes the primary control layer

S14 Sectors / Countries Affected

Affected Sectors

·        Technology and SaaS providers

·        Cloud-native organizations

·        Enterprises with heavy reliance on third-party integrations

·        Organizations adopting AI-enabled productivity tools

High-Exposure Environment Types

·        Federated identity architectures

·        Multi-SaaS operational dependency

·        Environments with weak OAuth governance

·        Environments with limited identity and authorization visibility

Geographic Exposure

·        Global exposure due to SaaS delivery model

·        No region-specific constraint on attack applicability

·        Risk is determined by identity architecture maturity rather than geography

S15 Adversary Capability Profiling

·        Adversary demonstrates capability in identity-focused attack techniques

·        Able to exploit OAuth authorization flows and trust relationships

·        Capable of operating without malware or exploit payloads

·        Demonstrates understanding of SaaS integration and identity federation models

·        Able to perform post-access activity including privileged interaction and credential access

·        Capable of maintaining low-noise operational profile using legitimate access pathways

·        No confirmed malware family or named threat actor attribution; classified as unidentified threat actor using identity-based tradecraft

S16 Targeting Probability Assessment

High-Probability Targets

·        Organizations with extensive SaaS integration ecosystems

·        Organizations with weak OAuth governance and approval controls

·        Organizations with limited visibility into identity and authorization events

Elevated Targeting Likelihood

·        Organizations using AI-enabled SaaS tools

·        Cloud-first enterprises

·        Cloud-native enterprises

Targeting Model Assessment

·        Opportunistic targeting is likely due to scalable supply chain vector

·        Low attacker friction increases likelihood of repeated exploitation attempts

·        Organizations with strong identity controls and monitoring have reduced probability of successful compromise

S17 MITRE ATT&CK Chain Flow Mapping

Initial Access

·        OAuth-based application authorization enables attacker-controlled access without credential theft

·        Access is established through trusted identity relationships rather than credential compromise

·        T1078 Valid Accounts

·        T1528 Steal Application Access Token

Persistence

·        Authorization grants ongoing access through token lifecycle and delegated permissions

·        Access persists without requiring credential reuse or additional authentication

·        T1098 Account Manipulation

Defense Evasion

·        Activity blends into legitimate identity and SaaS usage patterns

·        Actions appear consistent with normal authorized application behavior

·        T1036 Masquerading

Credential Access

·        Access to credentials and configuration data within SaaS and internal systems

·        Retrieval of environment variables, API keys, or tokens following access

·        T1552 Unsecured Credentials

Discovery

·        Enumeration of accessible accounts, systems, and resources

·        Identification of high-value targets within accessible scope

·        T1087 Account Discovery

Lateral Movement

·        Use of retrieved credentials to access additional systems or environments

·        Expansion of access into connected services or cloud platforms

·        T1021 Remote Services

S18 Attack Path Narrative (Signal-Aligned Execution Flow)

The attack begins when a trusted third-party SaaS or AI-enabled integration is used to obtain authorized access through an enterprise identity relationship rather than through malware delivery, exploit execution, or direct credential theft. The most likely entry condition is OAuth-based authorization that grants attacker-controlled application access under legitimate identity context, allowing initial activity to align with normal SaaS usage and limiting early visibility. Detection at this stage is constrained unless anomalies in application authorization, approval patterns, or identity context are observable.

Following access establishment, the attacker leverages existing permissions to interact with internal systems, focusing on identifying reachable resources, administrative functions, and configuration surfaces without introducing disruptive behavior. The transition from simple access to interaction with sensitive systems creates the first meaningful detection opportunity, particularly when access patterns deviate from expected identity or application behavior.

The attack progresses into retrieval of sensitive credentials and configuration material, including environment variables, API keys, and tokens that enable expanded access. This stage represents a critical inflection point where detection becomes materially stronger, especially when credential or configuration access closely follows earlier identity anomalies. At this point, the compromise extends beyond the initial SaaS boundary.

If usable credentials are obtained, the attacker extends access into downstream internal or cloud-connected environments using valid authentication pathways. This expansion relies on existing trust relationships rather than new exploit activity, making it difficult to distinguish from legitimate operations without cross-domain correlation. The most significant impact occurs when credential exposure enables continued privileged interaction or broader operational access across connected systems.

S19 Attack Chain Risk Amplification Summary

·        Risk increases immediately when activity begins under trusted identity context because initial access appears legitimate

·        Risk amplifies when delegated application access bypasses traditional credential-compromise assumptions

·        Risk increases when internal system access occurs without clear differentiation between approved and unapproved application behavior

·        Risk materially escalates when privileged functions or sensitive configuration areas become accessible

·        Risk sharply increases when credentials or configuration data are retrieved because compromise extends beyond the initial access boundary

·        Risk expands across environments when exposed credentials enable access to connected services or cloud platforms

·        Risk becomes harder to contain when telemetry gaps prevent reconstruction of authorization and access sequence

·        Risk remains elevated even without confirmed exfiltration due to sustained access and credential exposure potential

Figure 3

S20 Tactics, Techniques, and Procedures

Access Establishment Variants

·        Induced authorization through deceptive consent flows that mimic legitimate integration onboarding

·        Use of pre-existing approved applications as an access proxy rather than introducing new application registrations

·        Selection of narrowly scoped permissions followed by incremental reauthorization to expand access over time

·        Targeting identities with pre-approved high-privilege application access to avoid new approval events

Identity Usage Adaptation

·        Alignment of activity timing with historical user or service usage patterns to reduce anomaly visibility

·        Use of application or service identities instead of user identities to minimize behavioral deviation

·        Shifting activity across identities or sessions to fragment observable patterns

·        Leveraging idle or infrequently monitored identities to reduce detection likelihood

Privilege and Access Expansion Behaviors

·        Indirect access to higher-privilege functions through chained service relationships rather than direct privilege escalation

·        Exploitation of misconfigured permission inheritance across SaaS or identity platforms

·        Use of cross-application trust relationships to reach sensitive functions without modifying roles

·        Gradual expansion into higher-value systems through sequential low-risk access steps

Credential and Configuration Access Behaviors

·        Prioritized targeting of credential stores associated with automation, integration, or deployment workflows

·        Retrieval of credentials tied to cross-environment access rather than single-system use

·        Staggered extraction patterns that avoid threshold-based alerting mechanisms

·        Selection of credential sources with weaker access monitoring or classification controls

Stealth and Activity Shaping

·        Distribution of activity across multiple sessions or time windows to avoid correlation

·        Use of access sequences that resemble normal administrative or integration workflows

·        Avoidance of actions that trigger high-sensitivity logging or alerting paths

·        Limitation of activity volume to remain within expected operational variance

Downstream Operationalization Variants

·        Use of exposed credentials within federated or trust-linked environments rather than direct system targeting

·        Reuse of tokens or secrets in service-to-service communication patterns to avoid interactive authentication signals

·        Testing of access through low-impact operations before broader use

·        Expansion through integration pathways rather than direct lateral movement mechanisms

S20A Adversary Tradecraft Summary

·        Tradecraft is identity-driven and operates through trusted access relationships rather than exploit execution

·        Attacker effectiveness depends on delegated access, weak OAuth governance, and limited visibility into identity activity

·        Operational approach favors low-noise interaction, gradual expansion, and use of valid permissions

·        Credential and configuration access enables transition from initial compromise to broader downstream risk

·        Stealth is achieved through alignment with expected SaaS and identity behavior rather than explicit evasion mechanisms

·        Tradecraft is scalable and effective in environments built on interconnected identity and SaaS trust models

S21 Detection Strategy Overview

Detection Objective

·        Detect supply chain–origin identity compromise resulting in unauthorized internal system access and potential downstream credential misuse

·        Detect OAuth-based account takeover, privileged access abuse, and post-access secret exposure behaviors

·        Ensure detection coverage across identity, control-plane, and downstream access layers without reliance on incident-specific artifacts

Detection Strategy Model

·        Use behavior-anchored detection based on attacker-required actions independent of specific tooling or implementation

·        Apply multi-layer detection across identity provider, SaaS control plane, and downstream access environments

·        Use correlation-driven detection combining identity anomalies with contextual access deviations

·        Design detections to remain valid across variant attack paths within the same attack class

Threat Model Basis

Confirmed Conditions

·        Unauthorized access to internal systems occurred

·        Compromise originated from a third-party SaaS dependency

·        Enterprise identity compromise enabled internal system access

Likely Conditions

·        Identity compromise involved OAuth or token-based access mechanisms consistent with SaaS identity attack patterns

·        Post-compromise activity included elevated or privileged system interaction

·        Internal access enabled visibility into configuration or non-sensitive secret material

Not Verified / Not Assumed

·        Confirmed data exfiltration scope

·        Malware usage or endpoint-based payload execution

·        Specific attacker tooling, commands, or persistence mechanisms

Primary Detection Planes

Identity Plane (Primary)

·        Detect OAuth application authorization anomalies

·        Detect token issuance and reuse outside established baselines

·        Detect privileged account activity deviations

·        Detect session anomalies including location, device, and timing inconsistencies

Control Plane (Primary)

·        Detect internal system access anomalies following identity events

·        Detect administrative or configuration activity outside expected workflows

·        Detect environment variable access, enumeration, or modification activity

·        Detect deployment or system-change operations inconsistent with baseline behavior

Endpoint Plane (Supporting)

·        Detect browser or CLI-based authentication activity tied to abnormal identity context

·        Detect process-level signals associated with token usage or authentication flows

·        Detect execution patterns inconsistent with known user or service behavior

Cloud / Downstream Plane (Conditional)

·        Detect usage of exposed credentials in external cloud environments

·        Detect API access anomalies using newly exposed or rotated tokens

·        Detect cross-account or service access deviations following potential credential exposure

Detection Prioritization Logic

Priority 1 – Identity Compromise Detection

·        Detect OAuth abuse, token misuse, and abnormal authentication behavior

·        Anchor downstream detection to identity compromise indicators

Priority 2 – Privileged Access and Internal System Abuse

·        Detect anomalous access to internal systems and administrative functions

·        Detect deviations from established operational baselines

Priority 3 – Secret Exposure and Credential Handling Activity

·        Detect access, enumeration, or modification of environment variables and tokens

·        Detect patterns consistent with credential harvesting or staging

Priority 4 – Post-Access Operational Activity

·        Detect suspicious deployments, configuration changes, or system actions

·        Detect attempts to operationalize unauthorized access

Priority 5 – Downstream Credential Misuse (Conditional)

·        Detect use of exposed credentials in external environments

·        Detect anomalous API or cloud activity tied to compromised tokens

System Strategy Alignment

Primary Detection Systems

·        Splunk

·        Elastic

·        QRadar

·        Role: Identity correlation, audit log analysis, and multi-source behavioral detection

Portable Detection Layer

·        SIGMA

·        Role: Standardized behavioral rule definition across SIEM platforms

Supporting Detection System

·        SentinelOne

·        Role: Endpoint context for identity-related activity and abnormal execution patterns

Conditional Detection Systems

·        AWS

·        Azure

·        GCP

·        Role: Detection of downstream credential misuse and cloud activity anomalies

Non-Primary Systems

·        Suricata

·        YARA

·        Role: Not aligned to this attack class under current evidence

Detection Design Principles

·        Anchor detections to behaviors required for identity compromise and post-access activity

·        Avoid reliance on single indicators or incident-specific artifacts

·        Ensure each detection rule is independently viable within its system

·        Prioritize low-noise, high-confidence detections over broad anomaly signals

·        Maintain explicit separation between confirmed conditions and inferred variants

·        Design detections to remain effective under attacker evasion attempts

Analytical Boundaries

·        Strategy is based on confirmed unauthorized access and identity compromise conditions

·        Strategy incorporates identity-based access patterns consistent with the observed attack class without asserting specific mechanisms

·        Strategy excludes unverified claims related to data exfiltration, attacker tooling, or persistence methods

·        Detection coverage targets the attack class rather than a single incident implementation

Operational Outcome

·        Enables construction of high-DRI behavioral detection rules across primary SIEM platforms

·        Supports correlation of identity, control-plane, and post-access activity

·        Provides scalable detection coverage for supply chain–driven identity compromise scenarios

·        Establishes a detection foundation that remains valid under incomplete forensic detail

S22 Primary Detection Signals

Signal Objective

·        Define compressed, behavior-anchored detection signals aligned to S21 strategy

·        Ensure each signal represents a distinct, observable detection condition

·        Enable direct translation of signals into S25 rule logic and Figure 5 mapping

Signal Group 1: Identity and OAuth Compromise

·        Detect new OAuth application authorization events for enterprise identities outside the approved application baseline

·        Detect token issuance, refresh, or reuse from IP, device, or session context not previously associated with the identity

·        Detect successful authentication from a new geographic location, device, or session profile relative to the established baseline

·        Detect authentication or OAuth authorization events followed within a defined short time window by access to sensitive systems or sensitive configuration areas

Signal Group 2: Privileged Access and Account Misuse

·        Detect privileged account access originating from IP ranges or devices not previously associated with privileged activity

·        Detect assignment or use of administrative roles without prior historical baseline for the identity

·        Detect execution of administrative actions outside defined operational time windows or approved workflows

Signal Group 3: Internal System and Control Plane Access

·        Detect access to restricted or internal systems immediately following identity anomaly signals

·        Detect configuration or administrative actions executed outside approved change windows or established workflows

·        Detect abnormal increases in frequency or sequence of system access events relative to baseline activity

Signal Group 4: Secret and Credential Access Activity

·        Detect access to environment variables, API keys, tokens, or configuration data by identities without prior access history

·        Detect bulk retrieval or enumeration patterns involving environment variables or secrets within a defined time window

·        Detect access to sensitive configuration or credential data occurring shortly after identity or authentication anomalies

Signal Group 5: Post-Access Operational Activity

·        Detect initiation of deployment actions by identities without prior deployment activity history

·        Detect configuration or system state changes occurring after confirmed identity or access anomalies

·        Detect sequences of actions consistent with preparation for sustained unauthorized access, including repeated configuration or deployment operations within a short time window

Signal Group 6: Downstream Credential Misuse (Conditional)

·        Detect API or cloud access using credentials from IP ranges, regions, or services not previously associated with those credentials

·        Detect abnormal increases in API request volume or service interaction following credential access or credential rotation events

·        Detect cross-account or cross-environment access patterns inconsistent with the established credential usage baseline

Signal Quality Characteristics

·        Signals are behavior-based and independent of incident-specific artifacts

·        Signals are defined as observable and measurable deviations from established baselines

·        Signals are non-overlapping and represent distinct detection conditions

·        Signals are directly translatable into system-specific detection logic

·        Signals remain valid across variations of the same attack class

Signal Limitations

·        Signals do not attribute activity to a specific threat actor or toolset

·        Signals do not independently confirm data exfiltration without supporting telemetry

·        Signals require defined baselines for user, device, IP, and service behavior

·        Signals depend on availability and completeness of identity, audit, and control-plane telemetry

Operational Outcome

·        Provides a minimal, high-impact signal set for S25 detection engineering

·        Enables clean mapping between signals, detection rules, and detection coverage visualization

·        Supports development of high-DRI, low-noise detection rules

·        Maintains alignment with the confirmed attack class without introducing redundancy or speculative assumptions

S23 Telemetry Requirements

Telemetry Objective

·        Define the minimum and enhanced telemetry required to operationalize S22 detection signals

·        Establish explicit linkage between telemetry availability and signal observability

·        Define correlation requirements needed for S25 rule construction

·        Identify adversarial telemetry limitations, high-impact gaps, and deployment constraints

Signal-to-Telemetry Alignment

Signal Group 1: Identity and OAuth Compromise

·        Required telemetry domains:

o   Identity and authentication telemetry

o   OAuth authorization and consent telemetry

o   Token lifecycle telemetry

·        Required for:

o   Detection of abnormal OAuth authorization

o   Detection of abnormal token issuance, refresh, or reuse

o   Detection of authentication from abnormal user context

Signal Group 2: Privileged Access and Account Misuse

·        Required telemetry domains:

o   Identity and authentication telemetry

o   Privileged access and role management telemetry

o   Application and control-plane telemetry

·        Required for:

o   Detection of abnormal privileged account access

o   Detection of role escalation or privilege misuse

o   Detection of administrative actions outside expected workflows

Signal Group 3: Internal System and Control Plane Access

·        Required telemetry domains:

o   Application and control-plane telemetry

o   Identity and authentication telemetry

·        Required for:

o   Detection of restricted system access after identity anomalies

o   Detection of abnormal configuration or administrative actions

o   Detection of abnormal system access sequencing or volume

Signal Group 4: Secret and Credential Access Activity

·        Required telemetry domains:

o   Secret and credential access telemetry

o   Application and control-plane telemetry

o   Identity and authentication telemetry

·        Required for:

o   Detection of environment variable or secret access outside baseline

o   Detection of bulk retrieval or enumeration behavior

o   Detection of credential access shortly after identity anomalies

Signal Group 5: Post-Access Operational Activity

·        Required telemetry domains:

o   Deployment and operational activity telemetry

o   Application and control-plane telemetry

o   Identity and authentication telemetry

·        Required for:

o   Detection of anomalous deployment initiation

o   Detection of post-access configuration or system state changes

o   Detection of repeated operational actions consistent with access operationalization

Signal Group 6: Downstream Credential Misuse (Conditional)

·        Required telemetry domains:

o   API and token usage telemetry

o   Downstream cloud telemetry

o   Identity and authentication telemetry where federation exists

·        Required for:

o   Detection of abnormal external credential use

o   Detection of unusual API request volume or cloud service interaction

o   Detection of cross-account or cross-environment credential misuse

Telemetry Domain 1: Identity and Authentication Telemetry (Primary)

Required Telemetry Sources

·        Identity provider authentication logs

·        OAuth application authorization and consent logs

·        Session creation and session validation logs

·        Token issuance and refresh logs, where supported

Required Fields

·        User identifier normalized across systems

·        Source IP address

·        Device identifier, session identifier, or equivalent session context

·        Geographic metadata derived from source IP

·        Application or OAuth client identifier

·        Authentication method and authentication result

·        Timestamp synchronized across sources

Telemetry Purpose

·        Support detection of OAuth authorization anomalies

·        Support detection of abnormal authentication context and session behavior

·        Support baseline construction for user, device, location, and application access patterns

Adversarial Limitations

·        Detection degrades if attackers reuse trusted devices, residential IP ranges, or previously observed locations

·        Detection degrades if token issuance visibility is absent and only downstream session use is logged

·        Detection degrades if session identifiers are missing or inconsistent across sources

Telemetry Domain 2: Privileged Access and Role Management

Required Telemetry Sources

·        Identity provider administrative activity logs

·        Role assignment and privilege modification logs

·        Access control system logs

Required Fields

·        User identifier

·        Role or privilege level assigned or used

·        Action type including assignment, modification, and privileged use

·        Source IP or initiating system

·        Timestamp

Telemetry Purpose

·        Support detection of privileged account misuse

·        Support detection of role escalation and abnormal privilege usage

·        Support linkage between identity anomalies and subsequent privilege activity

Adversarial Limitations

·        Detection weakens when privilege use is logged but privilege assignment is not

·        Detection weakens when shared administrative accounts prevent user-level attribution

·        Detection weakens when approvals and change windows are not formally recorded

Telemetry Domain 3: Application and Control Plane Telemetry (Primary)

Required Telemetry Sources

·        SaaS platform audit logs

·        Administrative activity logs

·        Configuration change logs

·        System access logs

Required Fields

·        User or service account identifier

·        Action performed

·        Resource identifier

·        Action outcome

·        Source IP or access origin

·        Timestamp

Telemetry Purpose

·        Support detection of restricted system access after identity anomalies

·        Support detection of abnormal administrative or configuration actions

·        Support measurement of system access sequence and frequency deviations

Adversarial Limitations

·        Detection weakens when read access is not logged and only write activity is captured

·        Detection weakens when service account actions cannot be tied back to a human identity or session

·        Detection weakens when high-volume administrative automation is not baselined and separated from interactive access

Telemetry Domain 4: Secret and Credential Access Telemetry

Required Telemetry Sources

·        Environment variable access logs

·        Secret management system logs

·        API key and token access logs

·        Configuration retrieval logs

Required Fields

·        User or service account identifier

·        Resource accessed

·        Access type including read, list, export, and modify

·        Access volume or count, where available

·        Source IP or system

·        Timestamp

Telemetry Purpose

·        Support detection of secret enumeration and credential access

·        Support detection of unusual credential retrieval volume and timing

·        Support linkage between secret access and preceding identity anomalies

Adversarial Limitations

·        Detection fails where secret reads are not logged and only secret changes are recorded

·        Detection weakens when bulk access is indistinguishable from normal application synchronization

·        Detection weakens when token retrieval and token use occur in separate platforms without correlation support

Telemetry Domain 5: Deployment and Operational Activity Telemetry

Required Telemetry Sources

·        Deployment execution logs

·        CI/CD pipeline logs

·        Change management logs

·        Operational action logs

Required Fields

·        Initiating user or service account

·        Action type

·        Target environment or system

·        Execution status

·        Source IP or system context

·        Timestamp

Telemetry Purpose

·        Support detection of anomalous deployment activity

·        Support detection of post-access operationalization behavior

·        Support distinction between approved change activity and unauthorized operational actions

Adversarial Limitations

·        Detection weakens when deployments are attributed only to shared automation identities

·        Detection weakens when change approval data is absent or not machine-readable

·        Detection weakens when operational logs do not distinguish manual execution from scheduled automation

Telemetry Domain 6: API and Token Usage Telemetry

Required Telemetry Sources

·        API gateway or service logs

·        Token usage logs

·        Service authentication logs

Required Fields

·        Token or API key identifier

·        Associated user or service account, where available

·        Source IP or service context

·        Endpoint accessed

·        Request frequency and volume

·        Timestamp

Telemetry Purpose

·        Support detection of token misuse

·        Support detection of abnormal API behavior after credential exposure

·        Support linkage between token access, token rotation, and token reuse patterns

Adversarial Limitations

·        Detection weakens when token identifiers are masked or absent in usage logs

·        Detection weakens when traffic is proxied through trusted services that obscure original source context

·        Detection weakens when rate patterns are low and intentionally blended into normal service usage

Telemetry Domain 7: Downstream Cloud Telemetry (Conditional)

Required Telemetry Sources

·        Cloud provider audit logs

·        API activity logs within cloud environments

·        IAM and service account activity logs

Required Fields

·        Credential or service account identifier

·        Source IP or region

·        API action performed

·        Resource accessed

·        Request frequency and volume

·        Timestamp

Telemetry Purpose

·        Support detection of downstream credential misuse

·        Support detection of cross-account and cross-environment access anomalies

·        Support assessment of secondary compromise following credential exposure

Adversarial Limitations

·        Detection weakens when federated identity context is lost between SaaS and cloud environments

·        Detection weakens when regional access is expected and no geographic baseline exists

·        Detection weakens when cloud audit logging excludes data-plane actions relevant to the compromised credential

Telemetry Normalization Requirements

·        Normalize user identifiers across identity, application, secret, deployment, and cloud telemetry

·        Synchronize timestamps across all telemetry sources

·        Standardize IP address formatting and enrichment

·        Normalize device, session, and service identifiers where available

·        Standardize action naming and outcome fields across telemetry sources

·        Preserve raw source identifiers needed for cross-platform correlation

Correlation Requirements

·        Correlate OAuth authorization, authentication anomaly, and privileged activity within short investigative windows appropriate to interactive compromise

·        Correlate identity anomaly signals with restricted system access and configuration actions in forward sequence order

·        Correlate secret or credential access with preceding identity anomalies and subsequent token or API use

·        Correlate deployment or operational actions with prior access anomalies and privilege use

·        Preserve sequence directionality so later activity is not used to infer earlier compromise without supporting evidence

Minimum Viable Telemetry (Operational Baseline)

·        Identity provider authentication logs

·        SaaS platform audit logs

·        Administrative activity logs

·        Basic API usage logs

Enhanced Telemetry (High-Confidence Detection)

·        OAuth authorization and consent logs

·        Token lifecycle visibility including issuance and refresh

·        Detailed secret and environment variable access logs

·        Deployment and CI/CD activity logs

·        Cloud audit logs for downstream environments

·        Device or session context sufficient for user-context baselining

Telemetry Constraints

High-Impact Constraints

·        Absence of identity provider logs severely reduces ability to detect initial compromise and abnormal user context

·        Absence of SaaS audit logs severely reduces ability to detect internal system access and administrative actions

·        Absence of secret access telemetry severely reduces ability to detect credential enumeration or retrieval

·        Absence of OAuth authorization telemetry prevents direct visibility into the likely initial authorization event

Moderate-Impact Constraints

·        Missing device or session context reduces confidence in abnormal authentication detection

·        Missing token lifecycle visibility reduces confidence in token misuse detection

·        Missing deployment telemetry reduces visibility into post-access operationalization

Lower-Impact Constraints

·        Limited geographic enrichment reduces location-based anomaly strength

·        Inconsistent action naming increases correlation complexity and tuning overhead

Telemetry Gap Impact

·        If identity logs are absent, S22 Signal Groups 1 and 2 degrade materially

·        If SaaS audit logs are absent, S22 Signal Groups 3 and 5 degrade materially

·        If secret access logs are absent, S22 Signal Group 4 degrades materially

·        If API and cloud usage logs are absent, S22 Signal Group 6 degrades materially

·        If correlation fields are inconsistent across sources, all multi-stage detections degrade and TCR must be reduced accordingly

Operational Outcome

·        Provides explicit telemetry support for every S22 signal group

·        Defines the minimum telemetry baseline required for viable rule engineering

·        Defines enhanced telemetry required for higher-confidence, lower-noise detections

·        Establishes adversarially realistic telemetry dependencies, blind spots, and gap impact for S25 and TCR scoring

Figure 4

S24 Detection Opportunities and Gaps

Detection Objective

·        Define viable detection opportunities derived from S22 signals under S23 telemetry constraints

·        Identify detection paths that are reliable, degraded, or non-viable under real-world and adversarial conditions

·        Establish clear boundaries for S25 rule selection based on deployability, noise, and evasion resistance

·        Ensure all opportunities are directly traceable to observable telemetry and measurable conditions

Detection Opportunity Model

·        Evaluate detection opportunities based on telemetry availability and completeness

·        Evaluate signal observability and measurability

·        Evaluate correlation feasibility with defined forward sequence logic

·        Evaluate expected noise relative to baseline stability

·        Evaluate resistance to adversarial evasion behavior

·        Categorize each opportunity as:

·        High-Confidence Detection Opportunity

·        Conditional Detection Opportunity

·        Degraded Detection Opportunity

·        Detection Gap

Signal Group 1: Identity and OAuth Compromise

High-Confidence Detection Opportunities

·        Detect OAuth authorization events for applications not present in approved application baseline

·        Detect successful authentication from new device or geographic context relative to established user baseline

·        Detect authentication followed within a defined short time window by access to restricted systems

Conditional Detection Opportunities

·        Detect token issuance, refresh, or reuse anomalies where token lifecycle telemetry is available

Degraded Detection Opportunities

·        Detect session anomalies where device or session identifiers are incomplete or inconsistent

·        Detect context anomalies where baseline includes high geographic or IP diversity

Detection Gaps

·        No detection of OAuth compromise where authorization logs are absent

·        No detection of token creation where issuance logs are not captured

Adversarial Considerations

·        Attackers may reuse known devices or IP ranges to reduce context deviation

·        Attackers may limit authentication frequency to avoid anomaly thresholds

Signal Group 2: Privileged Access and Account Misuse

High-Confidence Detection Opportunities

·        Detect privileged access from devices or IP ranges not associated with prior privileged activity

·        Detect role assignment or privilege escalation outside established baseline

·        Detect administrative actions executed outside defined operational workflows or time windows

Conditional Detection Opportunities

·        Detect privilege misuse correlated with prior identity anomalies where correlation fields are consistent

Degraded Detection Opportunities

·        Detect misuse where shared administrative accounts reduce attribution accuracy

·        Detect anomalies where privileged activity baseline is broad or poorly defined

Detection Gaps

·        No reliable attribution where identity is not preserved in privileged activity logs

·        No detection of misuse where privilege usage is logged but role assignment is not

Adversarial Considerations

·        Attackers may operate within existing privileged roles to avoid escalation detection

·        Attackers may use shared or service accounts to reduce attribution visibility

Signal Group 3: Internal System and Control Plane Access

High-Confidence Detection Opportunities

·        Detect access to restricted systems following identity anomaly signals

·        Detect configuration or administrative actions outside approved change windows

·        Detect abnormal increases in system interaction frequency within defined time windows

Conditional Detection Opportunities

·        Detect control-plane abuse where full audit logging of actions is available

Degraded Detection Opportunities

·        Detect anomalies where read-level access is not logged

·        Detect anomalies where service account activity cannot be linked to user identity

Detection Gaps

·        No detection of unauthorized read access where read operations are not logged

·        No attribution of system actions where identity linkage is absent

Adversarial Considerations

·        Attackers may restrict activity to read-only operations to avoid detection

·        Attackers may blend actions into high-volume administrative activity

Signal Group 4: Secret and Credential Access Activity

High-Confidence Detection Opportunities

·        Detect access to secrets or environment variables by identities without prior access history

·        Detect bulk retrieval or enumeration of secrets within defined time windows

·        Detect credential access occurring shortly after identity anomalies

Conditional Detection Opportunities

·        Detect abnormal access volume where access count telemetry is available

Degraded Detection Opportunities

·        Detect patterns where only modification events are logged and read access is absent

·        Detect enumeration behavior where legitimate synchronization produces similar patterns

Detection Gaps

·        No detection of secret retrieval where read access is not logged

·        No differentiation between legitimate and malicious bulk access without stable baseline

Adversarial Considerations

·        Attackers may retrieve credentials incrementally to avoid bulk detection thresholds

·        Attackers may use legitimate automation to mask credential access

Signal Group 5: Post-Access Operational Activity

High-Confidence Detection Opportunities

·        Detect deployment actions initiated by identities without prior deployment history

·        Detect configuration or system changes occurring after identity or access anomalies

·        Detect repeated operational actions within short time windows indicative of unauthorized activity

Conditional Detection Opportunities

·        Detect operational misuse where change management metadata is available and correlated

Degraded Detection Opportunities

·        Detect anomalies where deployments are attributed to shared automation identities

·        Detect unauthorized actions where approval workflows are not consistently enforced

Detection Gaps

·        No reliable detection of unauthorized operational activity where identity attribution is absent

·        No distinction between approved and unapproved activity where change control data is missing

Adversarial Considerations

·        Attackers may execute actions through existing automation pipelines

·        Attackers may align activity with normal deployment windows to avoid detection

Signal Group 6: Downstream Credential Misuse (Conditional)

High-Confidence Detection Opportunities

·        Detect API or cloud access from new regions or services using exposed credentials

·        Detect abnormal increases in API request volume within defined time windows

Conditional Detection Opportunities

·        Detect cross-account or cross-environment access where cloud audit logging is available

Degraded Detection Opportunities

·        Detect low-volume credential misuse that remains within baseline thresholds

Detection Gaps

·        No detection of downstream misuse where cloud audit logging is absent

·        No correlation where identity context is not preserved across environments

Adversarial Considerations

·        Attackers may distribute activity across environments to reduce anomaly visibility

·        Attackers may throttle usage to remain within normal operational thresholds

Cross-Signal Correlation Opportunities

High-Confidence Correlation Opportunities

·        Detect identity anomaly followed by privileged access within a defined short time window

·        Detect identity anomaly followed by secret access activity in forward sequence

·        Detect identity anomaly followed by configuration or deployment actions

Conditional Correlation Opportunities

·        Detect multi-stage attack sequence where telemetry fields are present and normalized

Degraded Correlation Opportunities

·        Detect partial sequence where one or more telemetry domains are incomplete

Detection Gaps

·        No multi-stage correlation where telemetry sources cannot be linked through shared identifiers or synchronized timestamps

Adversarial Considerations

·        Attackers may delay actions between stages to evade time-based correlation

·        Attackers may interleave benign activity to disrupt sequence patterns

Detection Opportunity Constraints

High-Impact Constraints

·        Absence of identity provider logs prevents detection of identity compromise signals

·        Absence of SaaS audit logs prevents detection of internal system access and control-plane activity

·        Absence of secret access telemetry prevents detection of credential retrieval

·        Absence of OAuth authorization logs prevents visibility into initial access vector

Moderate-Impact Constraints

·        Missing device or session context reduces confidence in identity anomaly detection

·        Missing token lifecycle visibility reduces detection fidelity for token misuse

·        Missing deployment telemetry reduces visibility into post-access activity

Lower-Impact Constraints

·        Limited geographic enrichment reduces effectiveness of location-based detection

·        Inconsistent normalization increases correlation complexity

Detection Coverage Summary

·        Identity compromise detection is reliable when identity telemetry is available and normalized

·        Privileged misuse detection is reliable with consistent role and access logging

·        Control-plane detection depends on completeness of SaaS audit logging

·        Secret access detection depends on availability of read-level telemetry and stable baselines

·        Post-access detection depends on identity attribution and change tracking

·        Downstream detection depends on cloud telemetry availability and correlation capability

Operational Outcome

·        Establishes viable and non-viable detection paths under real-world conditions

·        Defines strict selection boundaries for S25 rule development

·        Identifies detection blind spots and adversarial evasion paths

·        Provides a realistic foundation for DRI and TCR scoring

S24 Detection Opportunities and Gaps

Detection Objective

·        Define viable detection opportunities derived from S22 signals under S23 telemetry constraints

·        Identify detection paths that are reliable, degraded, or non-viable under real-world and adversarial conditions

·        Establish clear boundaries for S25 rule selection based on deployability, noise, and evasion resistance

·        Ensure all opportunities are directly traceable to observable telemetry and measurable conditions

Detection Opportunity Model

·        Evaluate detection opportunities based on telemetry availability and completeness

·        Evaluate signal observability and measurability

·        Evaluate correlation feasibility with defined forward sequence logic

·        Evaluate expected noise relative to baseline stability

·        Evaluate resistance to adversarial evasion behavior

·        Categorize each opportunity as:

·        High-Confidence Detection Opportunity

·        Conditional Detection Opportunity

·        Degraded Detection Opportunity

·        Detection Gap

Signal Group 1: Identity and OAuth Compromise

High-Confidence Detection Opportunities

·        Detect OAuth authorization events for applications not present in approved application baseline

·        Detect successful authentication from new device or geographic context relative to established user baseline

·        Detect authentication followed within a defined short time window by access to restricted systems

Conditional Detection Opportunities

·        Detect token issuance, refresh, or reuse anomalies where token lifecycle telemetry is available

Degraded Detection Opportunities

·        Detect session anomalies where device or session identifiers are incomplete or inconsistent

·        Detect context anomalies where baseline includes high geographic or IP diversity

Detection Gaps

·        No detection of OAuth compromise where authorization logs are absent

·        No detection of token creation where issuance logs are not captured

Adversarial Considerations

·        Attackers may reuse known devices or IP ranges to reduce context deviation

·        Attackers may limit authentication frequency to avoid anomaly thresholds

Signal Group 2: Privileged Access and Account Misuse

High-Confidence Detection Opportunities

·        Detect privileged access from devices or IP ranges not associated with prior privileged activity

·        Detect role assignment or privilege escalation outside established baseline

·        Detect administrative actions executed outside defined operational workflows or time windows

Conditional Detection Opportunities

·        Detect privilege misuse correlated with prior identity anomalies where correlation fields are consistent

Degraded Detection Opportunities

·        Detect misuse where shared administrative accounts reduce attribution accuracy

·        Detect anomalies where privileged activity baseline is broad or poorly defined

Detection Gaps

·        No reliable attribution where identity is not preserved in privileged activity logs

·        No detection of misuse where privilege usage is logged but role assignment is not

Adversarial Considerations

·        Attackers may operate within existing privileged roles to avoid escalation detection

·        Attackers may use shared or service accounts to reduce attribution visibility

Signal Group 3: Internal System and Control Plane Access

High-Confidence Detection Opportunities

·        Detect access to restricted systems following identity anomaly signals

·        Detect configuration or administrative actions outside approved change windows

·        Detect abnormal increases in system interaction frequency within defined time windows

Conditional Detection Opportunities

·        Detect control-plane abuse where full audit logging of actions is available

Degraded Detection Opportunities

·        Detect anomalies where read-level access is not logged

·        Detect anomalies where service account activity cannot be linked to user identity

Detection Gaps

·        No detection of unauthorized read access where read operations are not logged

·        No attribution of system actions where identity linkage is absent

Adversarial Considerations

·        Attackers may restrict activity to read-only operations to avoid detection

·        Attackers may blend actions into high-volume administrative activity

Signal Group 4: Secret and Credential Access Activity

High-Confidence Detection Opportunities

·        Detect access to secrets or environment variables by identities without prior access history

·        Detect bulk retrieval or enumeration of secrets within defined time windows

·        Detect credential access occurring shortly after identity anomalies

Conditional Detection Opportunities

·        Detect abnormal access volume where access count telemetry is available

Degraded Detection Opportunities

·        Detect patterns where only modification events are logged and read access is absent

·        Detect enumeration behavior where legitimate synchronization produces similar patterns

Detection Gaps

·        No detection of secret retrieval where read access is not logged

·        No differentiation between legitimate and malicious bulk access without stable baseline

Adversarial Considerations

·        Attackers may retrieve credentials incrementally to avoid bulk detection thresholds

·        Attackers may use legitimate automation to mask credential access

Signal Group 5: Post-Access Operational Activity

High-Confidence Detection Opportunities

·        Detect deployment actions initiated by identities without prior deployment history

·        Detect configuration or system changes occurring after identity or access anomalies

·        Detect repeated operational actions within short time windows indicative of unauthorized activity

Conditional Detection Opportunities

·        Detect operational misuse where change management metadata is available and correlated

Degraded Detection Opportunities

·        Detect anomalies where deployments are attributed to shared automation identities

·        Detect unauthorized actions where approval workflows are not consistently enforced

Detection Gaps

·        No reliable detection of unauthorized operational activity where identity attribution is absent

·        No distinction between approved and unapproved activity where change control data is missing

Adversarial Considerations

·        Attackers may execute actions through existing automation pipelines

·        Attackers may align activity with normal deployment windows to avoid detection

Signal Group 6: Downstream Credential Misuse (Conditional)

High-Confidence Detection Opportunities

·        Detect API or cloud access from new regions or services using exposed credentials

·        Detect abnormal increases in API request volume within defined time windows

Conditional Detection Opportunities

·        Detect cross-account or cross-environment access where cloud audit logging is available

Degraded Detection Opportunities

·        Detect low-volume credential misuse that remains within baseline thresholds

Detection Gaps

·        No detection of downstream misuse where cloud audit logging is absent

·        No correlation where identity context is not preserved across environments

Adversarial Considerations

·        Attackers may distribute activity across environments to reduce anomaly visibility

·        Attackers may throttle usage to remain within normal operational thresholds

Cross-Signal Correlation Opportunities

High-Confidence Correlation Opportunities

·        Detect identity anomaly followed by privileged access within a defined short time window

·        Detect identity anomaly followed by secret access activity in forward sequence

·        Detect identity anomaly followed by configuration or deployment actions

Conditional Correlation Opportunities

·        Detect multi-stage attack sequence where telemetry fields are present and normalized

Degraded Correlation Opportunities

·        Detect partial sequence where one or more telemetry domains are incomplete

Detection Gaps

·        No multi-stage correlation where telemetry sources cannot be linked through shared identifiers or synchronized timestamps

Adversarial Considerations

·        Attackers may delay actions between stages to evade time-based correlation

·        Attackers may interleave benign activity to disrupt sequence patterns

Detection Opportunity Constraints

High-Impact Constraints

·        Absence of identity provider logs prevents detection of identity compromise signals

·        Absence of SaaS audit logs prevents detection of internal system access and control-plane activity

·        Absence of secret access telemetry prevents detection of credential retrieval

·        Absence of OAuth authorization logs prevents visibility into initial access vector

Moderate-Impact Constraints

·        Missing device or session context reduces confidence in identity anomaly detection

·        Missing token lifecycle visibility reduces detection fidelity for token misuse

·        Missing deployment telemetry reduces visibility into post-access activity

Lower-Impact Constraints

·        Limited geographic enrichment reduces effectiveness of location-based detection

·        Inconsistent normalization increases correlation complexity

Detection Coverage Summary

·        Identity compromise detection is reliable when identity telemetry is available and normalized

·        Privileged misuse detection is reliable with consistent role and access logging

·        Control-plane detection depends on completeness of SaaS audit logging

·        Secret access detection depends on availability of read-level telemetry and stable baselines

·        Post-access detection depends on identity attribution and change tracking

·        Downstream detection depends on cloud telemetry availability and correlation capability

Operational Outcome

·        Establishes viable and non-viable detection paths under real-world conditions

·        Defines strict selection boundaries for S25 rule development

·        Identifies detection blind spots and adversarial evasion paths

·        Provides a realistic foundation for DRI and TCR scoring

S25 Ultra-Tuned Detection Engineering Rules

Suricata

Detection Viability Assessment

·        No viable Suricata detection rules meet CyberDax v2.7 standards for this attack scenario

Why Suricata Doesn’t Fit This Attack Scenario

Suricata is a network-based detection engine. It works best when an attack produces identifiable patterns in network traffic, such as:

·        Known malicious signatures

·        Command-and-control communication

·        Exploit payloads

·        Suspicious protocol behavior

However, in this case, the attack operates differently.

Trusted Application Traffic

·        Activity occurs within legitimate, encrypted HTTPS sessions

·        Traffic is directed to trusted SaaS platforms

·        Network patterns appear normal and expected

No Distinct Network Signature

·        No malware delivery or exploit payloads

·        No suspicious domains or infrastructure

·        No protocol anomalies detectable at the network layer

Critical Signals Exist Outside Network Visibility

·        Indicators are tied to identity and application behavior

·        Examples include abnormal login activity, access patterns, and administrative actions

·        These signals are only visible in identity and application logs

Encryption Limits Visibility

·        Network traffic is encrypted using TLS

·        Suricata cannot determine user identity, permissions, or intent

·        Actions performed within sessions are not visible at the packet level

Bottom Line

Suricata is effective for detecting threats that generate identifiable network signatures.
This attack does not produce those signals and instead requires visibility at the identity and application layer.

SentinelOne

Rule Name

·        Newly Observed SaaS Automation from Non-Baselined User-Device Context

Detection Objective

·        Detect endpoint-executed SaaS API or automation activity performed by a user-device combination without prior history for that behavior

Behavioral Anchor

·        Detects attacker requirement to operationalize compromised SaaS access using endpoint-based tooling outside established user-device baselines

Telemetry Dependencies

·        Process creation telemetry

·        Command-line telemetry

·        User-to-process attribution

·        Device identifier

·        Customer-maintained baseline of approved user-device-tool combinations

Engineering Implementation Instructions

·        Maintain customer-managed allowlists for:

o   approved SaaS automation tools

o   approved automation users

o   approved automation hosts (CI/CD, service accounts)

·        Maintain baseline mapping of user-to-device and user-to-tool behavior

·        Ensure command-line logging is enabled and normalized across all supported operating systems

·        Separate automation infrastructure from interactive user endpoints for accurate tuning

Noise and Tuning Considerations

·        Noise remains low only when user-device-tool baselines are properly maintained

·        Engineering environments require explicit allowlisting of approved workflows

·        Detection quality degrades if automation systems are not clearly separated from user endpoints

Evasion Considerations

·        Attackers can evade detection by remaining in browser-only workflows

·        Attackers can evade detection by using already baselined users, devices, or approved tools

·        Attackers can blend activity into existing automation pipelines or service-account workflows

DRI Score

·        8.5

DRI Justification

·        Strong behavioral anchoring on post-access operationalization outside established user-device baselines

·        Detection logic enforces baseline deviation, increasing resistance to common attacker variants

·        Low dependence on static artifacts or indicators

·        Evasion requires attacker to either remain in browser-only activity or successfully blend into approved automation patterns

TCR (Operational)

·        7.4

TCR (Full-Telemetry)

·        8.3

TCR Justification

·        Operational confidence depends on completeness of command-line telemetry and accuracy of user-device attribution

·        Detection requires maintained customer-managed baselines for automation behavior

·        Full-telemetry confidence improves with normalized endpoint telemetry and stable identity-to-device mapping

Detection Logic (SentinelOne Deep Visibility Query)

EventType = "Process Creation"
AND ProcessName IN ("node", "python", "curl", "powershell", "pwsh", "bash")
AND CommandLine RegExp "(vercel|deploy)"
AND UserName NOT IN ("APPROVED_SAAS_AUTOMATION_USERS")
AND EndpointName NOT IN ("APPROVED_AUTOMATION_HOSTS")

Splunk

Rule Name

·        OAuth Authorization Followed by Sensitive Resource Access

Detection Objective

·        Detect OAuth authorization for a non-approved application followed by access to a tagged sensitive resource within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to establish application access and rapidly use that access to reach a sensitive target

Telemetry Dependencies

·        OAuth authorization logs

·        SaaS resource access logs

·        Normalized user identity

·        Customer-managed lookup table for approved OAuth applications

·        Customer-managed lookup table for sensitive resources

Engineering Implementation Instructions

·        Maintain a customer-managed lookup table of approved OAuth applications

·        Maintain a customer-managed lookup table of tagged sensitive resources

·        Normalize user identity across identity and SaaS logs before deployment

·        Validate timestamp consistency across both log sources

·        Scope searches to the specific identity and SaaS indexes that contain these events

·        Convert to scheduled correlation or summary-backed execution if runtime cost becomes material

Noise and Tuning Considerations

·        Noise remains low when approved applications and sensitive resources are tightly curated

·        False positives are most likely during legitimate new integration activity

·        Tuning should prioritize allowlisting of approved applications and approved rollout windows

Evasion Considerations

·        Attackers can delay sensitive access outside the time window

·        Attackers can reuse already approved applications

·        Attackers can target untagged resources if resource classification is incomplete

DRI Score

·        9.2

DRI Justification

·        Strong behavioral anchor on ordered attacker activity from access establishment to sensitive follow-on use

·        Low dependence on static artifacts or one-off indicators

·        Good resistance to tooling variation because the attacker objective remains stable

·        Evasion requires delay, approved-path reuse, or movement to lower-visibility resources

TCR (Operational)

·        8.7

TCR (Full-Telemetry)

·        9.4

TCR Justification

·        Operational confidence depends on complete OAuth authorization logging and accurate sensitive-resource tagging

·        Confidence increases materially when SaaS access logs are complete and user identity is normalized

·        Confidence degrades when authorization events or resource labels are incomplete

Detection Logic (Splunk SPL)

(
    search index=identity_logs action="oauth_authorization"
    | rename user as user_id app as oauth_app
    | lookup approved_oauth_apps oauth_app OUTPUT oauth_app as approved_app
    | where isnull(approved_app)
    | eval cdx_stage="start"
    | fields time userid oauth_app cdx_stage
)
| append [
    search index=saas_logs action="resource_access"
    | lookup sensitive_resources_lookup resource OUTPUT resource as sensitive_resource
    | where isnotnull(sensitive_resource)
    | rename user as user_id
    | eval cdx_stage="end"
    | fields time userid resource cdx_stage
]
| sort 0 user_id time
| streamstats current=f last(eval(if(cdxstage="start", time, null()))) as starttime by user_id
| streamstats current=f last(eval(if(cdx_stage="start", oauth_app, null()))) as start_oauth_app by user_id
| where cdx_stage="end" AND isnotnull(start_time) AND time>=starttime AND (_time-start_time)<=900
| dedup user_id start_time sortby +_time
| eval oauth_time=start_time, access_time=_time, oauth_app=start_oauth_app
| table user_id oauth_time oauth_app access_time resource

Rule Name

·        New Authentication Context Followed by Privileged Action

Detection Objective

·        Detect successful authentication from a non-baselined context followed by privileged or administrative activity within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to use compromised identity from a new context and convert that access into privileged action

Telemetry Dependencies

·        Authentication logs

·        Privileged activity logs

·        Customer-managed user-IP baseline lookup

·        Customer-managed user-device baseline lookup

·        Normalized user identity

Engineering Implementation Instructions

·        Maintain customer-managed lookup tables for baseline user-IP and baseline user-device relationships

·        Tag privileged and administrative actions consistently across all relevant log sources

·        Exclude approved VPN ranges, approved jump hosts, and approved travel patterns where applicable

·        Normalize user identity across authentication and administrative telemetry before deployment

·        Validate timestamp consistency and field completeness across both sources

·        Scope searches tightly and convert to scheduled correlation if runtime cost becomes material

Noise and Tuning Considerations

·        Noise can be moderate if user baselines are stale or broad

·        Tuning should prioritize high-impact privileged actions over low-value administrative noise

·        Detection quality improves when approved access infrastructure is explicitly modeled

Evasion Considerations

·        Attackers can reuse known IP addresses or known devices

·        Attackers can delay privileged activity outside the time window

·        Attackers can postpone privilege use to later stages

DRI Score

·        8.9

DRI Justification

·        Strong linkage between abnormal context and privileged follow-on action

·        Good behavioral anchoring with limited dependence on static indicators

·        Variant resistance remains high because the privileged objective persists across tooling changes

·        Evasion requires blending into known context or deferring meaningful action

TCR (Operational)

·        8.4

TCR (Full-Telemetry)

·        9.1

TCR Justification

·        Operational confidence depends on accurate context baselines and complete privileged-action logging

·        Confidence increases with stable device attribution and normalized administrative telemetry

·        Confidence degrades when device context is incomplete or approved access paths are not modeled

Detection Logic (Splunk SPL)

(
    search index=auth_logs action="login_success"
    | rename user as user_id ip as auth_ip device as auth_device
    | lookup baseline_user_ip_lookup user_id auth_ip OUTPUT auth_ip as known_ip
    | lookup baseline_user_device_lookup user_id auth_device OUTPUT auth_device as known_device
    | where isnull(known_ip) OR isnull(known_device)
    | eval cdx_stage="start"
    | fields time userid auth_ip auth_device cdx_stage
)
| append [
    search index=admin_logs action IN ("privileged_action","role_change","config_change")
    | rename user as user_id action as privileged_action
    | eval cdx_stage="end"
    | fields time userid privileged_action target cdx_stage
]
| sort 0 user_id time
| streamstats current=f last(eval(if(cdxstage="start", time, null()))) as starttime by user_id
| streamstats current=f last(eval(if(cdx_stage="start", auth_ip, null()))) as start_auth_ip by user_id
| streamstats current=f last(eval(if(cdx_stage="start", auth_device, null()))) as start_auth_device by user_id
| where cdx_stage="end" AND isnotnull(start_time) AND time>=starttime AND (_time-start_time)<=900
| dedup user_id start_time sortby +_time
| eval auth_time=start_time, action_time=_time, auth_ip=start_auth_ip, auth_device=start_auth_device
| table user_id auth_time auth_ip auth_device action_time privileged_action target

Rule Name

·        Identity Anomaly Followed by Secret or Configuration Access

Detection Objective

·        Detect successful authentication from a non-baselined context followed by secret, environment variable, or configuration access within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to retrieve sensitive configuration or credential material after gaining access

Telemetry Dependencies

·        Authentication logs

·        Secret and configuration access logs

·        Customer-managed user-IP baseline lookup

·        Customer-managed user-device baseline lookup

·        Normalized user identity

Engineering Implementation Instructions

·        Maintain customer-managed lookup tables for baseline user-IP and baseline user-device relationships

·        Tag secret, environment variable, and configuration access events consistently across log sources

·        Exclude approved service accounts, automation paths, and known synchronization workflows where applicable

·        Normalize user identity across authentication and secret/configuration telemetry before deployment

·        Validate that read-level logging exists for targeted secret and configuration sources prior to enablement

·        Scope searches tightly and convert to scheduled correlation if runtime cost becomes material

Noise and Tuning Considerations

·        Noise is low to moderate when service accounts and automation are explicitly excluded

·        Detection quality drops materially if secret-access baselines are unstable

·        Tuning should prioritize high-value secret stores and interactive user activity

Evasion Considerations

·        Attackers can retrieve sensitive material slowly to avoid clustered access

·        Attackers can blend into approved automation or service-account workflows

·        Attackers can target poorly logged configuration stores

DRI Score

·        9.0

DRI Justification

·        Strong linkage between suspicious identity context and sensitive follow-on objective

·        High-value attacker behavior with low dependence on static indicators

·        Good resistance to tooling variation because the objective remains consistent

·        Evasion requires slower access, better blending, or movement into lower-visibility stores

TCR (Operational)

·        8.6

TCR (Full-Telemetry)

·        9.2

TCR Justification

·        Operational confidence depends on read-level secret and configuration access logging plus stable identity baselines

·        Confidence increases when secret-access events are complete, normalized, and attributable to users

·        Confidence degrades when read activity is absent or automation paths are not clearly separated from user behavior

Detection Logic (Splunk SPL)

(
    search index=auth_logs action="login_success"
    | rename user as user_id ip as auth_ip device as auth_device
    | lookup baseline_user_ip_lookup user_id auth_ip OUTPUT auth_ip as known_ip
    | lookup baseline_user_device_lookup user_id auth_device OUTPUT auth_device as known_device
    | where isnull(known_ip) OR isnull(known_device)
    | eval cdx_stage="start"
    | fields time userid auth_ip auth_device cdx_stage
)
| append [
    search index=secrets_logs action IN ("secret_read","env_read","config_access")
    | rename user as user_id action as access_action
    | eval cdx_stage="end"
    | fields time userid access_action resource cdx_stage
]
| sort 0 user_id time
| streamstats current=f last(eval(if(cdxstage="start", time, null()))) as starttime by user_id
| streamstats current=f last(eval(if(cdx_stage="start", auth_ip, null()))) as start_auth_ip by user_id
| streamstats current=f last(eval(if(cdx_stage="start", auth_device, null()))) as start_auth_device by user_id
| where cdx_stage="end" AND isnotnull(start_time) AND time>=starttime AND (_time-start_time)<=900
| dedup user_id start_time sortby +_time
| eval auth_time=start_time, access_time=_time, auth_ip=start_auth_ip, auth_device=start_auth_device
| table user_id auth_time auth_ip auth_device access_time access_action resource

Elastic

Rule Name

·        OAuth Authorization Followed by Sensitive Resource Access

Detection Objective

·        Detect OAuth authorization for a non-approved application followed by access to a high-value resource within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to establish application access and immediately use it to reach a sensitive target

Telemetry Dependencies

·        OAuth authorization events mapped to ECS (event.category, event.action)

·        SaaS resource access logs

·        Normalized user.id

·        Customer-managed enrichment:

o   oauth_app_approved (boolean)

o   resource_sensitivity (tagged high-value resources)

Engineering Implementation Instructions

·        Build enrichment pipeline that:

o   tags OAuth apps as approved/unapproved

o   tags resources as sensitive based on business-defined criteria

·        Ensure identity normalization into user.id across all sources

·        Validate timestamp alignment across identity and SaaS logs

·        Restrict rule to high-value resources only before enabling

Noise and Tuning Considerations

·        Low noise when sensitive resource tagging is strict

·        False positives may occur during legitimate new integrations

·        Tune by allowlisting approved applications and rollout windows

Evasion Considerations

·        Attackers may delay access beyond the time window

·        Attackers may reuse previously approved applications

·        Attackers may target untagged or lower-value resources

DRI Score

·        9.2

DRI Justification

·        Strong ordered behavioral sequence tied to attacker objective

·        Low dependence on static indicators

·        High resistance to tool variation

·        Evasion requires delay or use of approved access paths

TCR (Operational)

·        8.6

TCR (Full-Telemetry)

·        9.3

TCR Justification

·        Dependent on completeness of OAuth logging and resource tagging

·        Confidence improves with validated enrichment pipelines

·        Degrades when application approval or resource sensitivity tagging is incomplete

Detection Logic (Elastic EQL)

sequence by user.id with maxspan=15m
  [ any where event.category == "authentication"
      and event.action == "oauth_authorization"
      and oauth_app_approved == false ]
  [ any where event.action == "resource_access"
      and resource_sensitivity == "high" ]

Rule Name

·        New Authentication Context Followed by High-Risk Privileged Action

Detection Objective

·        Detect successful authentication from a non-baselined context followed by high-risk privileged activity

Behavioral Anchor

·        Detects attacker requirement to use compromised identity in a new context and escalate impact through privileged action

Telemetry Dependencies

·        Authentication logs (ECS-aligned)

·        Privileged activity logs

·        Normalized user.id

·        Customer-managed enrichment:

o   user_ip_known

o   user_device_known

o   privilege_risk_level (high-risk actions only)

Engineering Implementation Instructions

·        Build enrichment pipeline that:

o   tags user IPs/devices as known or unknown

o   classifies privileged actions by risk level

·        Ensure consistent identity mapping across authentication and admin logs

·        Limit detection to high-risk administrative actions before deployment

Noise and Tuning Considerations

·        Noise controlled by restricting to high-risk actions

·        False positives possible with legitimate new device usage

·        Tune by excluding approved VPNs, jump hosts, and admin workflows

Evasion Considerations

·        Attackers may reuse known devices or IPs

·        Attackers may delay privileged activity

·        Attackers may avoid high-risk actions initially

DRI Score

·        8.9

DRI Justification

·        Strong correlation between abnormal context and high-impact action

·        Reduced noise through risk-based scoping

·        Maintains resistance across attacker tooling variation

·        Evasion requires blending into known contexts or deferring activity

TCR (Operational)

·        8.3

TCR (Full-Telemetry)

·        9.0

TCR Justification

·        Dependent on accuracy of context enrichment and action classification

·        Improves with stable device attribution and normalized logs

·        Degrades if enrichment pipelines are incomplete

Detection Logic (Elastic EQL)

sequence by user.id with maxspan=15m
  [ authentication where event.outcome == "success"
      and (user_ip_known == false or user_device_known == false) ]
  [ any where privilege_risk_level == "high" ]

Rule Name

·        Identity Anomaly Followed by High-Value Secret or Configuration Access

Detection Objective

·        Detect successful authentication from a non-baselined context followed by access to high-value secrets or configuration

Behavioral Anchor

·        Detects attacker requirement to retrieve sensitive credential or configuration material after gaining access

Telemetry Dependencies

·        Authentication logs

·        Secret and configuration access logs

·        Normalized user.id

·        Customer-managed enrichment:

o   user_ip_known

o   user_device_known

o   secret_value_level (high-value only)

Engineering Implementation Instructions

·        Build enrichment pipeline that:

o   classifies secret/configuration access by value level

o   tags known vs unknown user context

·        Ensure read-level logging exists for secrets/configuration stores

·        Exclude service accounts and automation paths prior to enabling

Noise and Tuning Considerations

·        Low noise when limited to high-value secrets

·        Noise increases in automation-heavy environments without exclusions

·        Tune by isolating interactive user behavior

Evasion Considerations

·        Attackers may retrieve data slowly to avoid detection windows

·        Attackers may use automation or service accounts

·        Attackers may target unmonitored or low-visibility stores

DRI Score

·        9.0

DRI Justification

·        Strong linkage between identity anomaly and attacker objective

·        Focus on high-value targets increases detection strength

·        Low reliance on specific tools or artifacts

·        Evasion requires slower access or blending into trusted workflows

TCR (Operational)

·        8.5

TCR (Full-Telemetry)

·        9.2

TCR Justification

·        Dependent on availability of read-level access logs

·        Improved confidence with validated enrichment pipelines

·        Degrades when secret access visibility is incomplete

Detection Logic (Elastic EQL)

sequence by user.id with maxspan=15m
  [ authentication where event.outcome == "success"
      and (user_ip_known == false or user_device_known == false) ]
  [ any where secret_value_level == "high" ]

QRadar

Rule Name

·        OAuth Authorization Followed by Sensitive Resource Access

Detection Objective

·        Detect OAuth authorization for a non-approved application followed by access to a high-value resource within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to establish application access and rapidly use that access to reach a sensitive target

Telemetry Dependencies

·        OAuth authorization events

·        SaaS resource access events

·        Normalized shared identity field

·        Customer-managed reference set for approved OAuth applications

·        Customer-managed reference set for sensitive resources

Engineering Implementation Instructions

·        Normalize identity into a shared property such as username or user ID across identity and SaaS events

·        Maintain a customer-managed reference set of approved OAuth applications

·        Maintain a customer-managed reference set of high-value sensitive resources

·        Ensure parsing exposes OAuth application identifiers, accessed resources, and normalized identity

·        Validate timestamp consistency across both event sources prior to deployment

Noise and Tuning Considerations

·        Noise remains low when approved applications and sensitive resources are tightly curated

·        False positives are most likely during legitimate new integration activity

·        Tune by excluding approved onboarding, testing, and rollout workflows

Evasion Considerations

·        Attackers can delay sensitive access outside the correlation window

·        Attackers can reuse already approved applications

·        Attackers can target untagged or lower-visibility resources

DRI Score

·        9.2

DRI Justification

·        Strong ordered behavioral sequence tied to attacker objective

·        Low dependence on static artifacts

·        High resistance to tooling variation

·        Evasion requires delay, approved-path reuse, or movement to lower-visibility resources

TCR (Operational)

·        8.6

TCR (Full-Telemetry)

·        9.3

TCR Justification

·        Operational confidence depends on complete OAuth authorization logging and accurate sensitive-resource tagging

·        Confidence improves when identity normalization and SaaS access parsing are complete

·        Confidence degrades when application approval or resource classification is incomplete

Detection Logic (QRadar AQL)

SELECT
  o.username AS user_id,
  o.devicetime AS oauth_time,
  o.application AS oauth_app,
  MIN(s.devicetime) AS access_time,
  MIN(s.resource) AS resource
FROM events o, events s
WHERE o.username = s.username
  AND o.eventname = 'oauth_authorization'
  AND NOT REFERENCESETCONTAINS('approved_oauth_apps', o.application)
  AND s.eventname = 'resource_access'
  AND REFERENCESETCONTAINS('sensitive_resources', s.resource)
  AND s.devicetime >= o.devicetime
  AND s.devicetime <= o.devicetime + 900
GROUP BY o.username, o.devicetime, o.application

Rule Name

·        New Authentication Context Followed by High-Risk Privileged Action

Detection Objective

·        Detect successful authentication from a non-baselined context followed by high-risk privileged activity within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to use compromised identity from a new context and convert that access into privileged action

Telemetry Dependencies

·        Authentication events

·        Privileged activity events

·        Customer-managed enrichment for known user IP and device context

·        Normalized shared identity field

·        Customer-managed enrichment for high-risk privileged actions

Engineering Implementation Instructions

·        Normalize authentication and administrative events to a shared identity field

·        Maintain enrichment fields identifying known user IP and device context

·        Classify and tag privileged actions by risk level and restrict to high-risk actions only

·        Exclude approved VPN ranges, jump hosts, and known administrative workflows

·        Validate enrichment outputs and event classification before deployment

Noise and Tuning Considerations

·        Noise can be moderate if baselines are incomplete or stale

·        Detection quality improves when privileged actions are tightly scoped

·        Tune by excluding approved access infrastructure and routine operations

Evasion Considerations

·        Attackers can reuse known IP addresses or devices

·        Attackers can delay privileged activity outside the time window

·        Attackers can defer high-risk actions to later stages

DRI Score

·        8.9

DRI Justification

·        Strong linkage between abnormal context and high-impact privileged action

·        Behavioral anchoring remains strong across attacker variants

·        Reduced noise through strict scoping to high-risk actions

·        Evasion requires blending into known context or delaying impact

TCR (Operational)

·        8.3

TCR (Full-Telemetry)

·        9.0

TCR Justification

·        Operational confidence depends on accurate context enrichment and privileged-action classification

·        Confidence improves with stable identity attribution and normalized logs

·        Confidence degrades when baselines or enrichment are incomplete

Detection Logic (QRadar AQL)

SELECT
  a.username AS user_id,
  a.devicetime AS auth_time,
  a.sourceip AS auth_ip,
  a.devicehostname AS auth_device,
  MIN(p.devicetime) AS action_time,
  MIN(p.eventname) AS privileged_action,
  MIN(p.target) AS target
FROM events a, events p
WHERE a.username = p.username
  AND a.eventname = 'login_success'
  AND (a.user_ip_known = 'false' OR a.user_device_known = 'false')
  AND p.privilege_risk_level = 'high'
  AND p.devicetime >= a.devicetime
  AND p.devicetime <= a.devicetime + 900
GROUP BY a.username, a.devicetime, a.sourceip, a.devicehostname

Rule Name

·        Identity Anomaly Followed by High-Value Secret or Configuration Access

Detection Objective

·        Detect successful authentication from a non-baselined context followed by access to high-value secrets or configuration within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to retrieve sensitive credential or configuration material after gaining access

Telemetry Dependencies

·        Authentication events

·        Secret and configuration access events

·        Customer-managed enrichment for known user IP and device context

·        Normalized shared identity field

·        Customer-managed enrichment for high-value secret or configuration targets

Engineering Implementation Instructions

·        Normalize authentication and secret/configuration events to a shared identity field

·        Maintain enrichment fields identifying known user IP and device context

·        Classify and tag high-value secret and configuration targets

·        Ensure read-level logging is available for targeted systems

·        Exclude service accounts, automation workflows, and synchronization activity

Noise and Tuning Considerations

·        Noise is low to moderate when automation and service accounts are excluded

·        Detection quality depends on accurate classification of high-value targets

·        Tune by focusing on interactive user behavior and critical stores

Evasion Considerations

·        Attackers can retrieve material slowly to avoid detection windows

·        Attackers can blend into approved automation or service-account workflows

·        Attackers can target lower-visibility or unclassified resources

DRI Score

·        9.0

DRI Justification

·        Strong linkage between identity anomaly and sensitive follow-on objective

·        High-value behavior with low dependence on static indicators

·        Consistent detection strength across tooling variation

·        Evasion requires slower access or blending into trusted activity

TCR (Operational)

·        8.5

TCR (Full-Telemetry)

·        9.2

TCR Justification

·        Operational confidence depends on read-level access visibility and accurate classification of sensitive targets

·        Confidence improves with validated enrichment pipelines and normalized identity

·        Confidence degrades when visibility or classification is incomplete

Detection Logic (QRadar AQL)

SELECT
  a.username AS user_id,
  a.devicetime AS auth_time,
  a.sourceip AS auth_ip,
  a.devicehostname AS auth_device,
  MIN(s.devicetime) AS access_time,
  MIN(s.eventname) AS access_action,
  MIN(s.resource) AS resource
FROM events a, events s
WHERE a.username = s.username
  AND a.eventname = 'login_success'
  AND (a.user_ip_known = 'false' OR a.user_device_known = 'false')
  AND s.secret_value_level = 'high'
  AND s.devicetime >= a.devicetime
  AND s.devicetime <= a.devicetime + 900
GROUP BY a.username, a.devicetime, a.sourceip, a.devicehostname

SIGMA

Rule Name

·        OAuth Authorization Followed by Sensitive Resource Access

Detection Objective

·        Detect OAuth authorization for a non-approved application followed by access to a high-value resource within a defined short time window

Behavioral Anchor

·        Access establishment followed by immediate sensitive resource interaction

Telemetry Dependencies

·        OAuth authorization events

·        Resource access events

·        Normalized identity field

·        Precomputed enrichment:

o   oauth_app_approved

o   resource_sensitivity

Engineering Implementation Instructions

·        Normalize identity into a shared field such as user.id prior to rule execution

·        Ensure enrichment fields are computed before ingestion into the Sigma backend

·        Restrict detection to high-value resources only

·        Validate that the target backend supports ordered correlation rules before deployment

Noise and Tuning Considerations

·        Low noise when sensitive resource tagging is strict

·        False positives may occur during legitimate integration activity

·        Tune by excluding approved applications and rollout windows

Evasion Considerations

·        Attackers may delay resource access

·        Attackers may reuse approved applications

·        Attackers may target unclassified resources

DRI Score

·        9.1

TCR (Operational)

·        8.3

TCR (Full-Telemetry)

·        9.1

System Ready Code

title: OAuth Authorization Followed by Sensitive Resource Access
status: test
logsource:
  category: authentication
detection:
  selection_oauth:
    event.action: oauth_authorization
    oauth_app_approved: false
  condition: selection_oauth
---
title: Sensitive Resource Access (High Value)
status: test
logsource:
  category: application
detection:
  selection_resource:
    event.action: resource_access
    resource_sensitivity: high
  condition: selection_resource
---
title: Correlation - OAuth Authorization Followed by Sensitive Resource Access
status: test
correlation:
  type: temporal_ordered
  rules:
    - OAuth Authorization Followed by Sensitive Resource Access
    - Sensitive Resource Access (High Value)
  group-by:
    - user.id
  timespan: 15m

Rule Name

·        New Authentication Context Followed by High-Risk Privileged Action

Detection Objective

·        Detect non-baselined authentication followed by high-risk privileged action

Behavioral Anchor

·        Identity anomaly followed by control-plane escalation

Telemetry Dependencies

·        Authentication events

·        Privileged activity events

·        Normalized identity field

·        Precomputed enrichment:

o   user_ip_known

o   user_device_known

o   privilege_risk_level

Engineering Implementation Instructions

·        Precompute context baseline fields prior to rule execution

·        Restrict privileged activity to high-risk actions

·        Validate backend support for correlation rules before deployment

Noise and Tuning Considerations

·        Moderate noise if baselines are incomplete

·        Reduced noise when limited to high-risk actions

·        Tune by excluding known infrastructure and workflows

Evasion Considerations

·        Attackers may reuse known context

·        Attackers may delay privileged activity

·        Attackers may avoid high-risk actions

DRI Score

·        8.8

TCR (Operational)

·        8.1

TCR (Full-Telemetry)

·        8.9

System Ready Code

title: Successful Authentication from Non-Baselined Context
status: test
logsource:
  category: authentication
detection:
  selection:
    event.outcome: success
  filter_known:
    user_ip_known: true
    user_device_known: true
  condition: selection and not filter_known
---
title: High-Risk Privileged Action
status: test
logsource:
  category: application
detection:
  selection:
    privilege_risk_level: high
  condition: selection
---
title: Correlation - New Authentication Context Followed by High-Risk Privileged Action
status: test
correlation:
  type: temporal_ordered
  rules:
    - Successful Authentication from Non-Baselined Context
    - High-Risk Privileged Action
  group-by:
    - user.id
  timespan: 15m

Rule Name

·        Identity Anomaly Followed by High-Value Secret or Configuration Access

Detection Objective

·        Detect non-baselined authentication followed by high-value secret or configuration access

Behavioral Anchor

·        Identity anomaly followed by data/credential objective

Telemetry Dependencies

·        Authentication events

·        Secret/configuration access events

·        Normalized identity field

·        Precomputed enrichment:

o   user_ip_known

o   user_device_known

o   secret_value_level

Engineering Implementation Instructions

·        Ensure read-level access visibility exists for target systems

·        Exclude service accounts and automation workflows

·        Restrict detection to high-value targets only

·        Validate backend support for correlation rules before deployment

Noise and Tuning Considerations

·        Low to moderate noise depending on automation presence

·        Reduced noise when scoped to high-value targets

·        Tune by focusing on interactive user activity

Evasion Considerations

·        Attackers may slow down access patterns

·        Attackers may blend into automation

·        Attackers may target unclassified resources

DRI Score

·        9.0

TCR (Operational)

·        8.2

TCR (Full-Telemetry)

·        9.0

System Ready Code

title: Successful Authentication from Non-Baselined Context
status: test
logsource:
  category: authentication
detection:
  selection:
    event.outcome: success
  filter_known:
    user_ip_known: true
    user_device_known: true
  condition: selection and not filter_known
---
title: High-Value Secret or Configuration Access
status: test
logsource:
  category: application
detection:
  selection:
    secret_value_level: high
  condition: selection
---
title: Correlation - Identity Anomaly Followed by High-Value Secret or Configuration Access
status: test
correlation:
  type: temporal_ordered
  rules:
    - Successful Authentication from Non-Baselined Context
    - High-Value Secret or Configuration Access
  group-by:
    - user.id
  timespan: 15m

  YARA

Detection Viability Assessment

·        No viable YARA detection rules meet CyberDax v2.7 standards for this attack scenario

·        YARA is designed for file, memory, or binary content matching and is not a fit for this identity-driven, SaaS control-plane attack

Final disposition: 0 rules

Why YARA Doesn’t Fit This Attack Scenario

YARA is most effective when detection can anchor to:

·        Malware binaries

·        Script bodies

·        Dropped files

·        Memory-resident artifacts

·        Stable string or byte-pattern indicators

This attack does not currently present that kind of detection surface.

No Confirmed Malware or File Artifact

·        No malware family has been confirmed

·        No payload, binary, or malicious script body has been validated

·        No stable file-based artifact is available for pattern matching

Core Activity Occurs Outside YARA Visibility

·        Attack activity is centered on:

o   OAuth and identity abuse

o   SaaS platform access

o   Privileged application behavior

o   Secret or configuration access

·        These behaviors occur in identity, audit, and control-plane telemetry, not in files or memory patterns

No Stable Content Signature

·        There is no reliable byte pattern, string cluster, or content signature tied to the observed attack class

·        Any attempted YARA rule would be speculative, brittle, or overly generic

Adversarial Reality

·        Attackers do not need to deploy malware to execute this intrusion pattern

·        Even if local tooling is used, currently available information does not provide stable content-level indicators suitable for YARA

·        Forcing a YARA rule here would create weak coverage and violate CyberDax quality gating

Bottom Line

YARA is not an appropriate detection system for this attack class under current evidence.
The attack is identity-driven and SaaS-mediated, while YARA requires stable file or memory artifacts that are not present here.

AWS

Rule Name

·        Non-Baselined AWS API Usage Targeting High-Value Services

Detection Objective

·        Detect AWS API activity from a principal operating outside its established region or service baseline and targeting high-value AWS services

Behavioral Anchor

·        Detects attacker requirement to operationalize exposed credentials by performing high-impact AWS API actions from abnormal execution context

Telemetry Dependencies

·        AWS CloudTrail management events

·        Normalized principal identity (userIdentity.arn)

·        Source region (awsRegion)

·        Source IP (sourceIPAddress)

·        Precomputed enrichment:

o   principal_region_known

o   principal_service_known

o   high_value_api

Engineering Implementation Instructions

·        Enable CloudTrail management event logging across all relevant accounts

·        Build enrichment pipeline that:

o   maps principals to known regions

o   maps principals to known services

o   tags high-value API actions

·        Exclude:

o   service roles

o   CI/CD roles

o   infrastructure automation roles

·        Validate role-assumption normalization before deployment

Noise and Tuning Considerations

·        Noise remains low when baselines are mature and automation roles are excluded

·        False positives occur when:

o   new region expansion is not modeled

o   new service adoption is not tracked

·        Detection quality depends on accurate principal baselining

Evasion Considerations

·        Attackers may reuse known regions and services

·        Attackers may operate slowly to avoid anomaly thresholds

·        Attackers may target poorly baselined services

DRI Score

·        8.8

DRI Justification

·        Strong behavioral anchor on credential misuse and cloud operationalization

·        Low dependence on static indicators

·        Good resistance to tool variation

·        Evasion requires blending into known principal behavior or reducing activity

TCR (Operational)

·        8.0

TCR (Full-Telemetry)

·        8.9

TCR Justification

·        Depends on CloudTrail completeness and enrichment accuracy

·        Improves with mature principal baselining

·        Degrades in multi-account environments without normalization

System Ready Code

-- CloudWatch Logs Insights Query (CloudTrail Log Group)

fields @timestamp, userIdentity.arn, eventSource, eventName, awsRegion, sourceIPAddress
| filter eventSource in ["iam.amazonaws.com","sts.amazonaws.com","secretsmanager.amazonaws.com","kms.amazonaws.com","ssm.amazonaws.com"]
| filter high_value_api = true
| filter principal_region_known = false or principal_service_known = false
| stats earliest(@timestamp) as first_seen,
        values(eventName) as api_actions,
        values(eventSource) as services,
        values(awsRegion) as regions,
        values(sourceIPAddress) as source_ips
  by userIdentity.arn

Azure

Rule Name

·        Non-Baselined Azure Sign-In Followed by High-Value Azure Control-Plane Activity

Detection Objective

·        Detect successful Azure sign-in activity from a non-baselined context followed by high-value Azure control-plane or secret-management activity within a defined short time window

Behavioral Anchor

·        Detects attacker requirement to operationalize exposed credentials or federated access by performing impactful Azure activity from abnormal sign-in context

Telemetry Dependencies

·        SigninLogs in Log Analytics for successful sign-ins and sign-in context. Microsoft documents fields such as IPAddress, IsInteractive, and related sign-in details in SigninLogs.

·        Azure activity / control-plane telemetry in Log Analytics

·        Normalized identity field

·        Customer-managed enrichment:

o   user_region_known

o   user_app_known

o   high_value_azure_action

Engineering Implementation Instructions

·        Route Microsoft Entra sign-in logs into Log Analytics before deployment. Microsoft documents integrating Entra activity logs with Azure Monitor Logs for analysis.

·        Build enrichment that classifies:

o   whether the sign-in region is normal for the identity

o   whether the app or resource pattern is normal for the identity

o   whether the downstream Azure action is high value

·        Exclude:

o   approved automation identities

o   managed identities

o   known administration jump paths

·        Validate that the Sentinel analytics rule query returns TimeGenerated, as required for scheduled analytics rules.

Noise and Tuning Considerations

·        Noise remains manageable only when region and app baselines are mature

·        False positives increase when organizations have broad travel patterns, frequent geo-distributed administration, or poorly separated automation identities

·        Detection quality improves when high-value actions are tightly scoped and service principals / automation identities are explicitly excluded

Evasion Considerations

·        Attackers may reuse known regions, apps, or expected access paths

·        Attackers may delay privileged or high-value activity outside the correlation window

·        Attackers may blend into existing automation or administrative workflows

DRI Score

·        8.7

DRI Justification

·        Strong behavioral anchor on downstream credential misuse and cloud operationalization

·        Low dependence on static indicators or one-off artifacts

·        Good resistance to tooling variation because the attacker objective remains high-value Azure activity after abnormal access

·        Evasion requires blending into known user-context patterns or reducing operational tempo

TCR (Operational)

·        8.0

TCR (Full-Telemetry)

·        8.9

TCR Justification

·        Operational confidence depends on complete Entra sign-in ingestion, normalized downstream Azure telemetry, and accurate enrichment for known context

·        Confidence improves when sign-in logs, downstream activity logs, and enrichment pipelines are complete and validated

·        Confidence degrades when automation identities, managed identities, or federated access paths are not clearly separated from interactive user activity

System Ready Code

let SigninAnomaly =
SigninLogs
| where ResultType == 0
| where user_region_known == false or user_app_known == false
| project UserPrincipalName, IPAddress, AppDisplayName, TimeGenerated;

let HighValueAzureActivity =
AzureActivity
| where high_value_azure_action == true
| project Caller, OperationNameValue, ResourceGroup, ResourceProviderValue, TimeGenerated;

SigninAnomaly
| join kind=innerunique (
    HighValueAzureActivity
) on $left.UserPrincipalName == $right.Caller
| where TimeGenerated1 >= TimeGenerated
| where TimeGenerated1 <= TimeGenerated + 15m
| summarize FirstSignIn=min(TimeGenerated),
            FirstHighValueAction=min(TimeGenerated1),
            IPs=make_set(IPAddress),
            Apps=make_set(AppDisplayName),
            Actions=make_set(OperationNameValue),
            Providers=make_set(ResourceProviderValue)
  by UserPrincipalName
| project UserPrincipalName, FirstSignIn, FirstHighValueAction, IPs, Apps, Actions, Providers, TimeGenerated=FirstHighValueAction

GCP

Rule Name

·        Non-Baselined GCP High-Value API Activity from Abnormal Execution Context

Detection Objective

·        Detect high-value GCP API activity executed by a principal operating outside its established IP or service baseline

Behavioral Anchor

·        Detects attacker requirement to operationalize exposed credentials by executing high-impact GCP control-plane or secret-management actions from abnormal execution context

Telemetry Dependencies

·        GCP Cloud Audit Logs

·        Principal identity:

o   protoPayload.authenticationInfo.principalEmail

·        Source IP:

o   protoPayload.requestMetadata.callerIp

·        API activity:

o   protoPayload.serviceName

o   protoPayload.methodName

·        Precomputed enrichment:

o   principal_ip_known

o   principal_service_known

o   high_value_gcp_action

Engineering Implementation Instructions

·        Enable Cloud Audit Logs:

o   Admin Activity (default)

o   Data Access (for Secret Manager, KMS, etc.)

·        Build enrichment pipeline that:

o   maps principals to known IP ranges

o   maps principals to known service usage

o   classifies high-value API actions

·        Exclude:

o   service accounts used for automation

o   CI/CD pipelines

o   infrastructure provisioning workflows

·        Normalize identity across projects before deployment

Noise and Tuning Considerations

·        Noise remains low when:

o   service accounts are excluded

o   principal baselines are mature

·        False positives occur when:

o   new services or regions are introduced without baseline updates

·        Detection quality depends on accurate principal baselining

Evasion Considerations

·        Attackers may reuse known IP ranges or services

·        Attackers may operate slowly to avoid anomaly thresholds

·        Attackers may target poorly baselined services

DRI Score

·        8.8

DRI Justification

·        Strong behavioral anchor on credential misuse and downstream cloud operationalization

·        Low dependence on static indicators

·        Good resistance to tooling variation

·        Evasion requires blending into known principal behavior or reducing activity

TCR (Operational)

·        8.0

TCR (Full-Telemetry)

·        8.8

TCR Justification

·        Operational confidence depends on Cloud Audit Log completeness and enrichment accuracy

·        Improves with consistent cross-project identity normalization

·        Degrades when Data Access logs are not enabled or service-account separation is incomplete

System Ready Code

-- BigQuery (Cloud Audit Logs Export)

SELECT
  protoPayload.authenticationInfo.principalEmail AS principal,
  MIN(timestamp) AS first_seen,
  ARRAY_AGG(DISTINCT protoPayload.methodName) AS api_methods,
  ARRAY_AGG(DISTINCT protoPayload.serviceName) AS services,
  ARRAY_AGG(DISTINCT protoPayload.requestMetadata.callerIp) AS source_ips
FROM
  `PROJECT_ID.DATASET.cloudaudit_googleapis_com_activity_*`
WHERE
  high_value_gcp_action = TRUE
  AND (principal_ip_known = FALSE OR principal_service_known = FALSE)
  AND protoPayload.serviceName IN (
    "iam.googleapis.com",
    "cloudkms.googleapis.com",
    "secretmanager.googleapis.com",
    "cloudresourcemanager.googleapis.com"
  )
  AND protoPayload.methodName IN (
    "SetIamPolicy",
    "CreateCryptoKey",
    "Decrypt",
    "AccessSecretVersion",
    "AddIamPolicyBinding"
  )
GROUP BY
  principal

S26 Threat-to-Rule Traceability Matrix

Purpose

·        Establish direct traceability between attacker behavior, observable signals, and detection rules

·        Ensure every rule maps to a required attacker action

·        Validate that no detections exist without behavioral justification

Behavior Stage 1 – Access Establishment via OAuth / Identity Abuse

Threat Behavior

·        Unauthorized OAuth application authorization

·        Establishment of persistent access without credential theft

Primary Signals

·        OAuth authorization event

·        Unapproved application usage

Detection Coverage

·        Splunk – OAuth Authorization Followed by Sensitive Resource Access

·        Elastic – OAuth Authorization Followed by Sensitive Resource Access

·        QRadar – OAuth Authorization Followed by Sensitive Resource Access

·        SIGMA – OAuth Authorization Followed by Sensitive Resource Access

Coverage Assessment

·        Detection exists only when authorization is followed by resource interaction

·        No direct detection of authorization alone

·        Coverage is intentionally delayed to enforce low-noise behavior

Behavior Stage 2 – Identity Misuse / Non-Baselined Access

Threat Behavior

·        Successful authentication from abnormal IP, region, device, or application context

Primary Signals

·        Successful login event

·        Non-baselined context indicators

Detection Coverage

·        Splunk – New Authentication Context Followed by High-Risk Privileged Action

·        Splunk – Identity Anomaly Followed by Secret or Configuration Access

·        Elastic – New Authentication Context Followed by High-Risk Privileged Action

·        Elastic – Identity Anomaly Followed by High-Value Secret or Configuration Access

·        QRadar – New Authentication Context Followed by High-Risk Privileged Action

·        QRadar – Identity Anomaly Followed by High-Value Secret or Configuration Access

·        SIGMA – New Authentication Context Followed by High-Risk Privileged Action

·        SIGMA – Identity Anomaly Followed by High-Value Secret or Configuration Access

·        Azure – Non-Baselined Azure Sign-In Followed by High-Value Azure Control-Plane Activity

·        AWS – Non-Baselined AWS API Usage Targeting High-Value Services

·        GCP – Non-Baselined GCP High-Value API Activity from Abnormal Execution Context

Coverage Assessment

·        Coverage is strong for identity misuse that leads to meaningful follow-on activity

·        Detection is dependent on:

o   enrichment quality

o   baseline accuracy

·        Identity anomaly without follow-on behavior is not directly detected

Behavior Stage 3 – Privilege Escalation / Control-Plane Abuse

Threat Behavior

·        Role modification

·        Permission changes

·        Administrative configuration changes

Primary Signals

·        High-risk privileged actions

·        Control-plane modification activity

Detection Coverage

·        Splunk – New Authentication Context Followed by High-Risk Privileged Action

·        Elastic – New Authentication Context Followed by High-Risk Privileged Action

·        QRadar – New Authentication Context Followed by High-Risk Privileged Action

·        SIGMA – New Authentication Context Followed by High-Risk Privileged Action

·        Azure – Non-Baselined Azure Sign-In Followed by High-Value Azure Control-Plane Activity

·        AWS – Non-Baselined AWS API Usage Targeting High-Value Services

·        GCP – Non-Baselined GCP High-Value API Activity from Abnormal Execution Context

Coverage Assessment

·        Detection is tightly scoped to high-impact administrative actions

·        Low noise due to restriction to meaningful privilege escalation behavior

·        Effectiveness depends on accurate classification of high-risk actions

Behavior Stage 4 – Sensitive Resource / Secret Access

Threat Behavior

·        Access to secrets, configuration, or sensitive SaaS resources

Primary Signals

·        Secret read events

·        Configuration access

·        High-value resource interaction

Detection Coverage

·        Splunk – Identity Anomaly Followed by Secret or Configuration Access

·        Elastic – Identity Anomaly Followed by High-Value Secret or Configuration Access

·        QRadar – Identity Anomaly Followed by High-Value Secret or Configuration Access

·        SIGMA – Identity Anomaly Followed by High-Value Secret or Configuration Access

·        Azure – Non-Baselined Azure Sign-In Followed by High-Value Azure Control-Plane Activity

·        AWS – Non-Baselined AWS API Usage Targeting High-Value Services

·        GCP – Non-Baselined GCP High-Value API Activity from Abnormal Execution Context

Coverage Assessment

·        Detection is strong when sensitive access occurs under abnormal context

·        Coverage depends on:

o   visibility into secret access events

o   accurate classification of high-value resources

·        Detection is reduced where read-level logging is incomplete

Behavior Stage 5 – Cloud Operationalization

Threat Behavior

·        Use of exposed credentials or tokens within cloud platforms

·        API activity inconsistent with prior usage patterns

Primary Signals

·        API calls from new regions, services, or identity contexts

Detection Coverage

·        Azure – Non-Baselined Azure Sign-In Followed by High-Value Azure Control-Plane Activity

·        AWS – Non-Baselined AWS API Usage Targeting High-Value Services

·        GCP – Non-Baselined GCP High-Value API Activity from Abnormal Execution Context

Coverage Assessment

·        Detection is strong for post-compromise cloud activity when baselines are mature

·        Detection depends on:

o   cloud logging completeness

o   enrichment pipelines

·        Detection is limited when attackers operate within known patterns

Residual Gaps

·        OAuth authorization without follow-on activity is not detected

·        Identity anomalies without follow-on activity are not detected

·        Detection effectiveness is reduced when attackers remain within:

o   approved applications

o   known regions

o   known services

·        Cloud detection effectiveness depends on:

o   enrichment quality

o   baseline maturity

o   logging completeness

Bottom Line

·        All detection rules map directly to attacker-required behaviors

·        No orphan detections exist

·        Coverage is intentionally behavior-driven and low-noise

·        Detection strategy prioritizes:

o   high-confidence signals

o   post-compromise activity

o   adversary-required actions

S27 Behavior and Log Artifacts

Purpose

·        Define observable artifacts produced by attacker behavior

·        Map behavior to telemetry fields

·        Ensure detections are grounded in real log evidence

Behavior Stage 1 – Access Establishment via OAuth / Identity Abuse

Threat Behavior

·        Unauthorized OAuth application authorization

·        Establishment of persistent access

Observable Artifacts

·        OAuth authorization events

·        Application consent grants

·        Token issuance events

Log Sources and Fields

·        Identity logs

o   user identity

o   application identifier

o   consent type

o   timestamp

·        SaaS audit logs

o   resource access events

o   application usage

Detection-Relevant Characteristics

·        Authorization followed by resource interaction

·        Unapproved application usage

Behavior Stage 2 – Identity Misuse / Non-Baselined Access

Threat Behavior

·        Successful authentication from abnormal context

Observable Artifacts

·        Successful login events

·        New IP, region, device, or application context

Log Sources and Fields

·        Authentication logs

o   user identity

o   source IP

o   region

o   device information

o   login result

·        Enrichment outputs

o   user_ip_known

o   user_region_known

o   user_device_known

Detection-Relevant Characteristics

·        Valid authentication under abnormal context

·        Deviation from established baseline

Behavior Stage 3 – Privilege Escalation / Control-Plane Activity

Threat Behavior

·        Role or permission modification

·        Administrative configuration changes

Observable Artifacts

·        Privileged API calls

·        Role assignment changes

·        Policy updates

Log Sources and Fields

·        Audit logs

o   action type

o   target resource

o   privilege level

·        Cloud logs

o   service name

o   method name

o   caller identity

Detection-Relevant Characteristics

·        High-risk actions following authentication

·        Administrative activity outside baseline

Behavior Stage 4 – Sensitive Resource / Secret Access

Threat Behavior

·        Access to secrets or sensitive configuration

Observable Artifacts

·        Secret retrieval events

·        Configuration access events

·        High-value resource interaction

Log Sources and Fields

·        Secret management logs

o   secret identifier

o   access operation

·        SaaS and cloud logs

o   resource accessed

o   action performed

·        Enrichment outputs

o   resource_sensitivity

o   secret_value_level

Detection-Relevant Characteristics

·        Access to high-value resources

·        Activity following identity anomaly

Behavior Stage 5 – Cloud Operationalization

Threat Behavior

·        Use of credentials or tokens in cloud platforms

Observable Artifacts

·        API activity from abnormal context

·        Use of new regions or services

Log Sources and Fields

·        Cloud audit logs

o   principal identity

o   source IP

o   region

o   service name

o   method name

·        Enrichment outputs

o   principal_region_known

o   principal_service_known

Detection-Relevant Characteristics

·        High-value API usage under abnormal context

·        Post-compromise operational behavior

Bottom Line

·        All detections are grounded in observable log artifacts

·        No reliance on inferred or non-existent telemetry

S28 Detection Strategy and SOC Implementation Guidance

Figure 5

Purpose

·        Translate detection logic into operational workflows

·        Ensure alerts can be triaged and acted upon

Detection Strategy

·        behavioral correlation over single-event detection

Focus on

·       identity misuse

·       high-risk follow-on activity

Enforce

·       short correlation windows

·       high-value action scoping

Alert Triage Model

·        Step 1

o   validate identity context

§  IP

§  region

§  device

·        Step 2

o   confirm follow-on activity

§  privileged action

§  sensitive access

·        Step 3

o   determine scope

§  affected resources

§  potential lateral movement

Response Actions

·        Immediate

o   revoke sessions or tokens

o   disable compromised accounts

·        Short-term

o   rotate credentials

o   review privilege assignments

·        Follow-up

o   audit logs

o   validate no persistence remains

Operational Dependencies

·        Identity baselining must be maintained

·        Enrichment pipelines must remain accurate

·        Logging completeness must be validated

Bottom Line

·        Detection effectiveness depends on SOC execution quality

·        Alerts are high-confidence but require rapid validation

S29 Detection Coverage Summary

Purpose

·        Provide a consolidated view of detection coverage across all behavior stages

·        Clearly represent where detection is strong, conditional, or limited

·        Maintain alignment with S26 traceability and S25 rule capability

Access establishment

·        Coverage level

o   partial

·        Condition

o   requires follow-on activity for detection

Identity misuse

·        Coverage level

o   strong

·        Condition

o   requires deviation from established baseline and subsequent activity

Privilege escalation

·        Coverage level

o   strong

·        Condition

o   limited to high-risk administrative or control-plane actions

Sensitive access

·        Coverage level

o   strong

·        Condition

o   requires visibility into high-value resource or secret access

Cloud operationalization

·        Coverage level

o   conditional strong

·        Condition

o   dependent on cloud telemetry completeness and enrichment quality

Coverage Characteristics

Detection is

·        behavior-driven

·        low-noise by design

·        focused on attacker-required actions

·        dependent on correlation between identity and follow-on activity

Detection is not

·        signature-based

·        dependent on static indicators

·        reliant on single-event anomaly detection

Limitations

Reduced visibility when attackers

·        remain within known identity, device, or regional baselines

·        avoid high-value or high-risk actions

·        distribute activity over extended time periods

Detection effectiveness depends on

·        logging completeness across identity, SaaS, and cloud environments

·        enrichment accuracy for baseline and sensitivity classification

·        consistency of identity normalization across telemetry sources

Bottom Line

·        Detection coverage is strongest in post-compromise stages where attacker behavior produces measurable impact

·        Early-stage access establishment detection is intentionally constrained to reduce noise

·        Overall coverage is behavior-driven, correlation-dependent, and aligned to high-confidence detection outcomes

S30 Intelligence Maturity Assessment

Purpose

·        Evaluate detection capability maturity

Detection Maturity Level

·        High maturity

o   identity misuse detection

o   privilege escalation detection

o   sensitive access detection

·        Moderate maturity

o   access establishment detection

o   cloud operationalization detection

Strengths

·        Behavior-driven detection model

·        Strong correlation logic

·        High signal-to-noise ratio

·        Cross-platform coverage

Weaknesses

·        Dependence on enrichment and baselining

·        Limited early-stage detection

·        Reduced effectiveness against low-and-slow activity

Adversarial Resilience

·        Resistant to

o   tooling variation

o   signature evasion

·        Less resistant to

o   baseline mimicry

o   delayed execution

Improvement Priorities

·        Improve baseline accuracy

·        Expand high-value resource classification

·        Strengthen cloud telemetry coverage

Bottom Line

·        Detection capability is mature and behavior-driven

·        Effectiveness depends on high-quality telemetry and enrichment

S31 Mitigation and Remediation

·        Revoke all active OAuth authorizations associated with affected identities and applications

·        Invalidate active sessions and tokens across identity and SaaS platforms

·        Rotate all exposed or potentially exposed credentials including API keys, tokens, and environment variables

·        Disable or isolate unverified third-party application integrations pending validation

·        Audit recent identity activity for unauthorized access to sensitive systems and configuration data

·        Remove unauthorized or unapproved application access from identity platforms

·        Apply temporary least-privilege restrictions to affected identities and service accounts

·        Review downstream systems for indicators of credential reuse or extended access

S32 Security Control Recommendations

Identity Governance Controls

·        Enforce centralized approval workflows for all third-party application access

·        Maintain full visibility into identity authorization and consent events

·        Implement least-privilege access enforcement across all identity types

·        Restrict use of high-privilege identities for application and integration access

OAuth and Application Controls

·        Limit application authorization to explicitly approved and validated integrations

·        Enforce granular permission scoping for all authorized applications

·        Maintain continuous inventory and validation of authorized applications

·        Monitor for deviations in authorization behavior and application usage patterns

SaaS Visibility Controls

·        Enable comprehensive logging for identity, authorization, and access activity

·        Correlate identity activity with SaaS administrative and configuration actions

·        Monitor access to sensitive systems, configurations, and administrative functions

·        Establish and maintain baselines for expected SaaS usage behavior

Credential and Secret Management Controls

·        Centralize management of credentials and configuration secrets

·        Enforce access restrictions for credential retrieval and usage

·        Monitor for abnormal access to credential stores and sensitive configuration data

·        Maintain consistent credential rotation policies for high-risk systems

S33 Strategic Defensive Improvement

·        Evolve toward identity-centric security models that prioritize authorization control and visibility

·        Develop unified monitoring across identity, SaaS, and cloud environments

·        Strengthen governance of third-party integrations and delegated access models

·        Improve detection capability for identity misuse and credential access behaviors

·        Reduce implicit trust across interconnected SaaS and identity ecosystems

·        Expand cross-domain correlation capabilities across identity, access, and credential activity

·        Establish continuous validation of identity trust relationships and application access

S34 Defensive Architecture Overview

Figure 6

·        Identity layer governs authentication, authorization, and application access control

·        SaaS layer provides visibility into application usage, configuration access, and administrative activity

·        Credential management layer controls storage, access, and protection of sensitive credentials and configuration data

·        Detection layer correlates identity, SaaS, and credential activity to identify abnormal behavior patterns

·        Downstream systems layer enforces access control and monitors credential usage across internal and cloud environments

S35 Security Hardening Guidance

OAuth Hardening

·        Restrict application authorization to pre-approved integrations only

·        Enforce least-privilege permission scopes for all applications

·        Limit or disable user-driven application consent where not required

·        Remove unused or unnecessary application authorizations on a recurring basis

Identity Hardening

·        Enforce least-privilege access across all identities

·        Minimize use of persistent high-privilege identities

·        Require strong authentication for access to sensitive systems

·        Separate administrative and operational identity roles

Credential and Configuration Hardening

·        Eliminate plaintext storage of credentials and configuration data

·        Restrict access to credential stores based on defined roles

·        Classify and monitor access to sensitive configuration data

·        Reduce exposure of credentials within automation and environment configurations

SaaS and Integration Hardening

·        Limit integration of external applications to validated operational requirements

·        Monitor administrative and configuration-level activity across SaaS platforms

·        Restrict unnecessary cross-application trust relationships

·        Continuously validate behavior of integrated applications

S36 Security Program Maturity Assessment

·        Identity governance maturity is limited where application authorization and consent are not centrally enforced

·        Visibility maturity is constrained where identity and SaaS activity are not fully logged and correlated

·        Detection maturity is reduced when identity behavior is not prioritized as a primary detection domain

·        Credential management maturity is weakened where secrets are broadly accessible or insufficiently controlled

·        Integration governance maturity is low in environments with unmanaged third-party application access

·        Cross-domain correlation maturity is limited when identity, SaaS, and cloud telemetry remain fragmented

S37 Residual Risk and Forward Outlook

Figure 7

·        Residual risk persists due to reliance on trusted identity relationships that can be abused without triggering traditional controls

·        Detection limitations remain where identity and authorization telemetry is incomplete or not fully correlated

·        SaaS dependency continues to introduce exposure through third-party integrations and delegated access models

·        Credential exposure risk cannot be fully eliminated in environments with distributed configuration and automation dependencies

·        Attack scalability remains due to reuse of common integration and identity trust patterns across organizations

·        Threat evolution is expected to continue targeting identity trust boundaries rather than software vulnerabilities

S38 Intelligence Confidence Assessment

·        High confidence in identity-driven attack model based on consistent behavioral patterns and absence of malware or exploit indicators

·        Moderate to high confidence that OAuth-based authorization was the initial access mechanism based on access characteristics and attack structure

·        High confidence in post-access behavior involving internal system interaction and credential or configuration access

·        High confidence in risk associated with credential exposure and downstream access potential

·        Moderate confidence in full scope of compromise due to incomplete visibility into SaaS and identity telemetry

·        Low confidence in attribution due to absence of identifiable threat actor, malware family, or campaign linkage

S39 Analytical Notes and Limitations

·        Initial access mechanism is assessed as most likely based on behavioral evidence rather than direct authorization logs

·        Visibility into OAuth authorization events and token lifecycle activity may be incomplete or unavailable

·        Full scope of credential and configuration access may not be fully observable due to SaaS logging limitations

·        No confirmed evidence of data exfiltration, but absence of evidence does not eliminate the possibility

·        Downstream access into connected systems or cloud environments may not be fully captured in available telemetry

·        Attribution remains limited due to lack of unique indicators or adversary-specific artifacts

S40 References

MITRE ATT&CK Framework

·        hxxps://attack.mitre[.]org/techniques/T1078/

OAuth and Identity Models

·        hxxps://developer.okta[.]com/docs/concepts/oauth-openid/

·        hxxps://learn.microsoft[.]com/en-us/entra/identity-platform/permissions-consent-overview

Identity Security Architecture

·        hxxps://learn.microsoft[.]com/en-us/security/zero-trust/deploy/identity

·        hxxps://cloud.google[.]com/architecture/identity

  ‍