[EXP] ShinyHunters’ European Commission Data Breach Sensitive Data Exposure

Report Type: Exposure-Driven Data Breach Threat Assessment
Threat Category: Identity and Access Abuse Leading to Sensitive Data Exposure
Assessment Date: April 22, 2026
Primary Impact Domain: Data Access and Exposure Control
Secondary Impact Domains: Identity and Session Integrity; Regulatory Compliance and Data Protection; SaaS Data Governance and Access Visibility
Affected Asset Class: Enterprise Identity Systems; SaaS and Cloud Data Platforms; Document and Data Repositories; Access Control and Sharing Mechanisms
Threat Objective Classification: Unauthorized Data Access, Exposure via Access Control Manipulation, and Data Monetization

BLUF

‍ A data exposure event attributed to the ShinyHunters threat actor has resulted in unauthorized access and external exposure of sensitive European Commission data, creating immediate regulatory, operational, and geopolitical risk. The breach is driven by abuse of legitimate access and data-sharing mechanisms, allowing adversaries to expose high-value data without triggering traditional security controls. The current threat posture reflects high exploitability through identity and SaaS control weaknesses, with continued exposure and secondary misuse of data highly likely. Immediate executive action is required to contain exposure pathways, validate access control integrity, and enforce strict governance over identity and data access.

S3 — Why This Matters Now

·        Data exposure is the primary impact event, meaning risk persists until access is fully controlled.

·        Regulatory exposure is immediate due to GDPR obligations tied to EU institutional data.

·        The threat model is repeatable and scalable, increasing likelihood of additional exploitation or reuse.

·        The attack bypasses traditional defenses by using legitimate access pathways.

·        Similar control weaknesses exist broadly across enterprise and government environments.

S4 — Key Judgments

·        The event is a failure of access control and data governance, not a traditional intrusion.

·        Identity-layer abuse is the central enabling condition.

·        Detection is difficult because activity appears legitimate at the system level.

·        The primary risk is ongoing exposure rather than initial access.

·        Organizations without strong visibility into data access and sharing are at elevated risk.

S5 — Executive Risk Summary

·        Business Risk: Exposure of sensitive institutional data creates regulatory penalties, reputational damage, and operational disruption; risk extends to long-term misuse of data and broader strategic impact.

·        Technical Cause: Unauthorized exposure resulted from misuse or misconfiguration of identity and data-sharing controls; limited visibility into access and permission changes delayed detection and increased impact.

·        Threat Posture: The adversary operates using legitimate access methods with low observable noise; continued exploitation and reuse of exposed data is likely.

·        Executive Decision Requirement: Contain all external access and validate exposure state across affected systems; verify identity control integrity; enforce governance over data classification, access, and sharing.

S6 — Executive Cost Summary

·        Low Impact Scenario: Rapid containment with limited exposure and no external propagation; estimated impact $10M – $30M.

·        Moderate Impact Scenario: Confirmed exposure of sensitive data with delayed detection and limited external distribution; estimated impact $75M – $200M.

·        High Impact Scenario: Broad external exposure, regulatory escalation, and sustained data misuse; estimated impact $250M – $600M+.

S6A — Key Cost Drivers

·        Sensitivity and volume of exposed data

·        Time to detection and containment

·        Degree of external accessibility

·        Persistence of unauthorized access

·        Regulatory enforcement under EU frameworks

·        Secondary use or redistribution of exposed data

·        Most Likely Scenario Justification: Moderate scenario is most likely due to confirmed exposure conditions, high regulatory sensitivity, and realistic detection delays without evidence of uncontrolled global propagation.

S6B — Compliance and Risk Context

·        Compliance Exposure Indicator: High

·        Risk Register Entry

·        Risk Title: Unauthorized Exposure of Sensitive European Commission Data

·        Risk Description: Sensitive institutional data was exposed externally due to failure in identity and access control, enabling unauthorized access and potential redistribution.

·        Likelihood: High

·        Impact: Severe

·        Risk Rating: Critical

·        Annualized Risk Exposure: Estimated $100M – $300M+

S7 — Risk Drivers

·        Weak or inconsistent data classification

·        Limited visibility into sharing and permission changes

·        Over-reliance on traditional detection models

·        Lack of identity behavior monitoring

·        Incomplete SaaS and API logging

·        Over-permissive external access configurations

S8 — Bottom Line for Executives

·        This risk remains active until all exposure pathways are identified and controlled.

·        Existing defenses are insufficient against abuse of legitimate access mechanisms.

·        Immediate priority is enforcing visibility and control over data access and sharing.

·        Comparable environments should be assumed exposed until validated.

S9 — Board-Level Takeaway

·        This event reflects a failure in data governance and access control, not a failure of perimeter security.

·        Data exposure through identity misuse represents a primary organizational risk requiring board-level oversight.

·        Leadership focus must shift toward enforceable controls over data access, sharing, and visibility with measurable accountability.

Figure 2

S10 — Threat Overview

The ShinyHunters campaign targeting the European Commission represents a data exposure-driven intrusion model focused on unauthorized access and externalization of sensitive institutional data. The operation relies on identity-layer abuse and misuse of legitimate access and data-sharing mechanisms rather than traditional exploit-based compromise. The threat is characterized by low-noise execution, use of valid credentials or session artifacts, and scalable data harvesting across SaaS and cloud environments. The campaign objective aligns with large-scale data monetization, potential intelligence value, and downstream exploitation of exposed institutional data.

S11 — Threat Classification and Type

Threat Type

·        Data Breach

Threat Sub-Type

·        Sensitive Data Exposure via Identity and Access Abuse

Operational Classification

·        Post-Compromise Data Access and Exposure Operation

Primary Function

·        Unauthorized Access, Aggregation, and External Exposure of High-Value Data

S12 — Campaign or Activity Overview

·        The campaign involves unauthorized access to sensitive data repositories followed by external exposure through sharing mechanisms, access grants, or transfer pathways.

·        Activity is consistent with identity compromise or misuse, enabling adversaries to operate within legitimate access boundaries.

·        The attack prioritizes data access, aggregation, and exposure rather than disruption or destruction.

·        Execution is adaptable across SaaS platforms, cloud storage systems, and enterprise data environments.

·        The campaign model supports repeatability and scalability across multiple targets.

S13 — Targets and Exposure Surface

·        Primary targets include centralized data repositories such as document management systems, internal portals, and structured data stores.

·        SaaS platforms and cloud storage services represent the dominant exposure surface due to broad access and sharing capabilities.

·        Identity systems are a critical exposure vector due to their role in authentication and authorization.

·        Data-sharing mechanisms including external collaboration, link-based access, and delegated permissions are primary exposure pathways.

·        API access surfaces enable automated enumeration and large-scale data retrieval.

S14 — Sectors / Countries Affected

Sectors Affected

·        Government and Public Sector

·        Regulatory and Policy Institutions

·        International Governance Bodies

Countries Affected

·        European Union Member States

·        Cross-border exposure affecting multiple jurisdictions due to distributed data access and institutional data handling

S15 — Adversary Capability Profiling

Capability Level

·        High

Technical Sophistication

·        Moderate-High, with strong proficiency in identity abuse, API-driven access, and SaaS exploitation without reliance on advanced malware

Infrastructure Maturity

·        Moderate, leveraging legitimate platforms and minimizing attacker-controlled infrastructure

Operational Scale

·        High, with demonstrated ability to access large datasets across multiple environments

Escalation Likelihood

·        High, due to repeatable attack model and broad applicability across similar targets

S16 — Targeting Probability Assessment

Overall Targeting Probability

·        High

Targeting Drivers

·        High-value institutional data with regulatory, political, or intelligence significance

·        Centralized SaaS and cloud environments with broad access surfaces

·        Weaknesses in identity governance and access control enforcement

·        Limited visibility into data access, sharing, and exposure states

Most Likely Targets

·        Government agencies and regulatory bodies

·        Organizations with large-scale SaaS and cloud data environments

·        Entities handling sensitive policy, legal, or strategic data

·        Organizations with complex external collaboration requirements

S17 — MITRE ATT&CK Chain Flow Mapping

Access Establishment

·        Adversary obtains valid credentials, tokens, or session artifacts enabling authorized access to target systems

·        Activity occurs through legitimate authentication pathways

·        ATT&CK Techniques: T1078 Valid Accounts, T1550 Use of Stolen Authentication Tokens

Discovery / Enumeration

·        Adversary performs structured discovery of accessible data repositories using APIs or platform-native capabilities

·        Focus is on identifying high-value and accessible data objects

·        ATT&CK Techniques: T1087 Account Discovery, T1083 File and Directory Discovery

Collection / Data Access

·        Sensitive data is accessed at scale across multiple repositories

·        Includes repeated retrieval and expansion of access scope

·        ATT&CK Techniques: T1213 Data from Information Repositories

Exposure

·        Data is made externally accessible through sharing mechanisms or access configuration changes

·        Represents a direct risk condition without requiring transfer

·        ATT&CK Techniques: T1537 Transfer Data to Cloud Account

Aggregation / Staging (Conditional)

·        Data may be aggregated or prepared for transfer depending on attack path

·        Not required in exposure-first scenarios

·        ATT&CK Techniques: T1074 Data Staged

Exfiltration (Conditional)

·        Data may be transferred externally using APIs, web services, or cloud mechanisms

·        Occurs when exposure alone is insufficient

·        ATT&CK Techniques: T1567 Exfiltration Over Web Services

Persistence / Continued Access (Parallel Behavior)

·        Access may be maintained through token reuse, session persistence, or retained permissions

·        Supports continued data access and exposure over time

·        ATT&CK Techniques: T1078 Valid Accounts, T1550 Use of Stolen Authentication Tokens

S18 — Attack Path Narrative (Signal-Aligned Execution Flow)

·        Access establishment occurs through valid credentials, tokens, or session artifacts, observable via authentication logs showing legitimate login success with anomalous session context such as new device, location, or authentication pattern.

·        Structured discovery follows through API calls and platform-native queries, observable via repeated object access attempts, repository traversal patterns, and API request sequences indicating enumeration behavior.

·        Collection is performed through repeated access to sensitive data objects across repositories, observable through increased object access counts, expansion in accessed data scope, and deviation from baseline access patterns.

·        Exposure is enabled through permission modification, sharing changes, or external access configuration, observable via access control state changes, creation of external sharing links, or introduction of external principals.

·        Aggregation or staging may occur where data is organized, exported, or packaged, observable through bulk access sequences, file aggregation behavior, or export-related activity within endpoints or SaaS platforms.

·        Exfiltration, when present, occurs through API transfers, synchronization mechanisms, or outbound connections, observable through abnormal transfer volume, destination deviation, or unusual API export patterns.

·        Persistence is maintained through continued validity or reuse of credentials, tokens, or sessions, observable via long-lived sessions, token reuse across devices, or repeated access over extended periods without normal workflow indicators.

S19 — Attack Chain Risk Amplification Summary

·        Exposure as a primary outcome removes dependency on outbound transfer, eliminating reliance on network-layer detection and shifting detection burden to access control and sharing telemetry.

·        Use of valid credentials and legitimate access paths suppresses high-fidelity intrusion signals, forcing reliance on behavioral deviation and correlation across identity and data telemetry.

·        API-driven access enables high-volume data interaction with consistent structure, reducing variability and weakening simple anomaly detection models.

·        Absence or inconsistency of data classification removes sensitivity context, degrading prioritization accuracy and increasing ambiguity in detection outputs.

·        Incomplete object-level or API telemetry prevents reliable reconstruction of access sequences, limiting the ability to detect enumeration and staging behavior.

·        Distributed or low-rate activity reduces signal concentration within detection windows, requiring longer baselines and increasing dependency on temporal correlation.

·        Inconsistent identity, session, or object identifiers across telemetry sources disrupt correlation, fragmenting detection visibility across systems.

·        Abuse of approved services and trusted collaboration pathways introduces ambiguity in distinguishing legitimate activity from malicious exposure or transfer.

Figure 3

S20 — Tactics, Techniques, and Procedures

·        Valid account usage and token-based authentication are used to establish and maintain access without reliance on exploit-based compromise.

·        API-driven enumeration and structured repository traversal are used to identify accessible data and expand visibility into available datasets.

·        Authorized access mechanisms are used to retrieve sensitive data across multiple objects, repositories, or environments.

·        Permission modification, sharing configuration changes, and external access enablement are used to alter effective accessibility of data.

·        Export, aggregation, and packaging functions are used to consolidate data where transfer or extended control is required.

·        Platform-native transfer mechanisms, APIs, and synchronization features are used when data movement is performed.

·        Session reuse, token persistence, and retained permissions are used to maintain ongoing access.

·        Legitimate workflows and platform-native functionality are used to reduce detection surface and avoid reliance on identifiable malicious artifacts.

S20A — Adversary Tradecraft Summary

·        The adversary relies on identity and access control weaknesses rather than exploit-driven compromise to achieve objectives.

·        Tradecraft is designed to operate within normal system and application behavior, reducing the effectiveness of single-event detection.

·        Structured API usage and automation enable scalable, repeatable data access across large environments.

·        Exposure mechanisms are used as a direct objective, allowing impact without requiring traditional exfiltration.

·        The operational model minimizes reliance on attacker-controlled infrastructure, reducing external indicators and observable artifacts.

·        Detection difficulty increases when visibility into identity, data access, and sharing state is incomplete or poorly correlated.

S21 — Detection Strategy Overview

Detection Philosophy

Detection is anchored on post-compromise data access, staging, exposure, and exfiltration behaviors rather than assumptions about initial access vectors due to uncertainty in breach origin.
The strategy prioritizes high-confidence, low-noise behavioral signals tied directly to sensitive data interaction and exposure pathways instead of generic intrusion artifacts.
Identity, SaaS, and application-layer telemetry are treated as primary detection surfaces given the enterprise and governmental cloud dependency model.
Detection logic is designed to remain effective under valid-account abuse scenarios, minimizing reliance on malware signatures or exploit-specific indicators.

Primary Detection Anchors

Abnormal access to high-sensitivity data repositories including document systems, internal portals, and structured data stores.
Identity-layer anomalies such as privilege misuse, session irregularities, and access pattern deviation.
Unauthorized permission changes including sharing enablement, delegated access creation, external access grants, and privilege expansion.
Bulk permission propagation and rapid sharing expansion patterns indicating large-scale exposure enablement.
Cross-tenant or external collaboration exposure pathways involving data sharing outside trusted organizational boundaries.
API-driven or automated data access behaviors distinct from normal user interaction patterns.
Data staging behaviors including bulk aggregation, compression, or transformation prior to exfiltration or exposure.
Outbound data transfer patterns involving unauthorized cloud storage uploads, API-driven extraction, or atypical encrypted channels.
Persistence mechanisms centered on identity tokens, session reuse, or application-layer access retention.

Detection Prioritization Model

Priority 1
Focuses on confirmed sensitive data access or exposure combined with anomalous identity or session context.

Priority 2
Focuses on unauthorized permission changes, bulk sharing expansion, and data staging behaviors that enable large-scale exposure or exfiltration.

Priority 3
Focuses on outbound data movement with contextual validation including destination, volume, and protocol characteristics.

Priority 4
Includes supporting signals such as privilege escalation, administrative abuse, or lateral movement within SaaS or hybrid environments.

Deprioritized Signals
Low-context signals such as isolated login anomalies without linkage to data interaction or exposure.

Correlation Strategy (Strict Enforcement)

Correlation is behavior-driven and requires multi-signal alignment across identity, data access, permission change, API activity, and network layers before alert elevation.
Detection logic enforces strict linkage between sensitive data interaction or exposure and anomalous execution context to prevent alert inflation.
Temporal correlation across sessions and activities is required to identify low-and-slow or staged behaviors over time.
Cross-domain correlation between SaaS logs, identity providers, endpoint telemetry, and network telemetry is required for high-confidence detections.
No rule may depend on outputs from other rules, and all correlations must be derived directly from telemetry sources.

Telemetry Prioritization

Identity provider telemetry including authentication logs, token usage, session metadata, and privilege assignments is prioritized as a primary signal source.
SaaS and collaboration platform telemetry including document access, sharing activity, permission changes, API usage, and administrative actions is treated as critical.
API and audit telemetry must capture automation patterns, access frequency, and behavioral deviation from human interaction baselines.
Endpoint telemetry including process execution and file interaction is used to validate local staging or access behaviors where applicable.
Network telemetry including outbound traffic patterns, DNS queries, and encrypted session characteristics supports exfiltration detection.
Web and application telemetry is conditionally leveraged depending on availability and logging maturity.

Detection Design Constraints

Detection must operate effectively under conditions of legitimate credential use without assuming exploit visibility.
Rules must maintain low noise and avoid reliance on high-volume baseline deviations without contextual enrichment.
All detections must be deployable within realistic enterprise telemetry environments without requiring idealized data sources.
Detection logic must avoid dependence on single telemetry points that are easily evaded or disabled.

Baseline and Deployment Requirements

Environment-specific baselines for normal data access patterns, user roles, and application usage must be established prior to deployment.
Identity behavior baselines including typical login geography, device usage, and session duration must be defined and validated.
Longitudinal baselines must be established to detect low-and-slow deviations within normal role-aligned activity.
Data sensitivity classification must be mapped to monitored repositories to enable prioritization of high-risk access and exposure events.
Outbound traffic baselines including typical destinations and transfer volumes must be established to support anomaly detection.

Variant Resilience Requirements

Detection must account for adversary use of legitimate tools, APIs, and built-in platform capabilities to avoid signature-based evasion.
Detection must cover non-exfiltration exposure pathways including large-scale sharing, permission misconfiguration, delegated access, and silent data exposure without transfer.
Detection must account for low-and-slow access patterns that remain within normal role expectations but deviate over time.
Detection must include administrative configuration abuse affecting access control, visibility, or logging mechanisms.
Logic must remain effective across variations including different data repositories, access methods, and exposure or exfiltration channels.
Detection must not rely on fixed indicators such as file names, domains, or static infrastructure artifacts.
Behavioral anchoring must ensure resilience against changes in tooling, access paths, or staging techniques.

Operational Detection Model

Detection operates as a layered model combining identity, data access, permission changes, API behavior, staging, and exfiltration signals into unified behavioral detections.
High-confidence alerts require alignment across multiple telemetry domains and temporal patterns rather than isolated signal triggers.
SOC workflows must prioritize investigation of data-centric and exposure-centric alerts over generic intrusion signals due to higher business impact.
Detection outputs must be actionable, context-rich, and directly tied to sensitive data exposure risk.

Explicit Non-Deployment Guardrails

Do not deploy detections that rely solely on login anomalies without data interaction or exposure context.
Do not deploy rules that trigger on high-volume user activity without sensitivity classification or role-based validation.
Do not deploy detections dependent on unavailable or inconsistently collected telemetry sources.
Do not deploy rules that require correlation with outputs from other detection rules instead of direct telemetry evidence.

S22 — Primary Detection Signals

·        Sensitive data access events where data classification tags, repository sensitivity labels, or access control designations indicate high-value data and access occurs with measurable deviation in device, session origin, authentication method, or privilege context, or demonstrates cumulative deviation in access scope, frequency, or sensitivity over time relative to established baseline.

·        Unauthorized permission modification events on sensitive data objects including direct or inherited changes to access control lists, sharing settings, or role assignments that increase effective access scope, introduce new principals, or expand indirect access pathways through group or permission inheritance structures.

·        Bulk permission propagation defined as an increase exceeding baseline thresholds in number of objects shared, number of users granted access, or number of external entities introduced within a defined time window.

·        Incremental permission drift defined as cumulative increases in access control entries, sharing scope, delegated access, or inherited permissions across multiple time intervals exceeding longitudinal baseline patterns.

·        External or cross-tenant exposure events where sensitive data objects transition from restricted/internal access states to externally accessible states, including domain-based sharing, anonymous link generation, or federated access enablement.

·        API-driven sensitive data access characterized by non-interactive authentication events, token-based access, or structured request sequencing including enumeration, traversal, or repeated object access patterns across sessions or identities.

·        Data staging behavior defined as sequential or distributed access to multiple sensitive data objects combined with download, copy, compression, export, or packaging operations across one or more sessions or identities indicating preparation for exposure or transfer.

·        Exfiltration activity defined as outbound transfer events involving sensitive data where measurable attributes including destination, transfer size, frequency, or method deviate from baseline behavior, including use of approved services, exports, or synchronization features exhibiting abnormal patterns.

·        Sensitivity manipulation events where data classification labels, access tags, or protection states are modified in a manner that reduces protection level prior to access, exposure, or transfer activity.

Supporting Detection Signals

·        Session anomalies including token reuse across multiple device identifiers, concurrent sessions across geographic regions, or abnormal session duration relative to baseline.

·        Privilege modification events including role changes, group membership updates, or administrative actions affecting access to sensitive data repositories.

·        Access scope expansion defined as increase in number, diversity, or sensitivity level of accessed data objects compared to historical baseline across single or multiple sessions.

·        Cross-identity access patterns where multiple identities access overlapping sensitive data sets in coordinated or distributed patterns within correlated timeframes.

·        Access sequence anomalies including ordered traversal across object identifiers, datasets, or repositories indicating systematic enumeration rather than task-based access.

·        API behavioral anomalies including structured sequencing, uniform request patterns, or distributed automation across sessions or identities.

·        Administrative configuration changes affecting sharing policies, external access controls, or audit and logging visibility.

·        Creation or introduction of new external identities, domains, or collaborators interacting with sensitive data objects.

Exploit Attempt and Instability Signals

·        Repeated access failures or permission-denied events targeting sensitive data objects followed by successful access within the same or correlated identity context.

·        Authentication attempts against restricted resources using non-standard access paths, APIs, or tokens.

·        Application or API error responses indicating enumeration of identifiers or probing of access control boundaries.

Outbound Communication Signals (Exfiltration-Specific)

·        Outbound transfer events where data volume, object count, or frequency exceeds baseline thresholds within defined time windows.

·        Connections to previously unobserved or low-reputation destinations immediately following sensitive data access or staging activity.

·        Encrypted outbound sessions exhibiting deviation in destination, timing, or frequency relative to baseline patterns.

·        API-based export or retrieval operations involving measurable indicators such as pagination depth, object count, or export size.

·        Data transfers to approved services, integrations, or synchronization mechanisms exhibiting abnormal volume, frequency, or access patterns.

Exposure Signals (Non-Transfer Data Risk)

·        Transition of sensitive data objects from restricted/internal access states to externally accessible states as recorded in access control or sharing logs.

·        Creation of anonymous, public, or externally accessible links tied to sensitive data objects.

·        Expansion of sharing scope reflected by measurable increase in external principals, domains, or access pathways.

·        Delegated or inherited access assignments enabling indirect access to sensitive data without direct user interaction.

·        Cumulative increase in externally accessible sensitive data objects exceeding baseline thresholds across defined time intervals.

Persistence and Post-Exploitation Signals (Conditional)

·        Authentication tokens or sessions associated with sensitive data access persisting beyond defined lifetime thresholds or reused across sessions, devices, or identities.

·        Repeated access events to sensitive data objects across extended timeframes without corresponding business workflow indicators.

·        Retention of elevated permissions, sharing states, or delegated access beyond expected operational duration.

Lateral Movement and Expansion Signals (Conditional)

·        Access events spanning multiple sensitive repositories, systems, or environments across sessions or identities exceeding baseline scope.

·        Use of shared or reused authentication artifacts across multiple services or platforms.

·        Sequential permission modifications enabling chained access expansion across data environments.

Temporal Behavior Signals

·        Burst activity defined as number of access, sharing, or transfer events exceeding baseline thresholds within short-duration windows.

·        Low-and-slow activity defined as sustained deviation in access count, sharing scope, or data interaction across extended periods relative to longitudinal baseline metrics.

·        Gradual exposure pattern defined as cumulative increase in externally accessible data objects, permissions, or collaborators exceeding baseline growth rates over time.

·        Cross-session aggregation defined as distributed access, staging, or exposure activity occurring across multiple sessions or identities that collectively exceed baseline thresholds.

·        Sequence-based activity defined as ordered progression of measurable events including access → aggregation → staging → exposure or transfer within correlated timeframes.

Signal Usage Constraints

·        Primary detection requires correlation between sensitive data classification indicators and measurable deviation or cumulative expansion in access, permission, exposure, or transfer attributes.

·        Authentication anomalies alone must not generate alerts without associated measurable data interaction or exposure events.

·        Volume-based detection must include sensitivity context and deviation or cumulative expansion relative to baseline thresholds.

·        API-based detection must rely on sequencing, structure, authentication type, and cross-session behavior rather than request rate alone.

·        Permission modification signals must not be treated as exposure unless a measurable change in effective data accessibility state occurs.

·        Use of approved services or trusted destinations must not suppress detection if measurable deviation or abnormal patterns are present.

·        Temporal and cross-session correlation is required to detect distributed, staged, or low-and-slow attack patterns.

·        Cross-identity correlation must be considered when distributed access patterns collectively exceed baseline thresholds.

·        Single-domain signals must not produce high-confidence alerts without supporting signals from additional telemetry domains where available.

·        Do not alert on access patterns fully consistent with role scope, sensitivity level, and baseline thresholds without measurable deviation or cumulative expansion.

S23 — Telemetry Requirements

Endpoint and Process Execution Telemetry

·        Process execution logs capturing process name, parent process, full command-line arguments, execution timestamp, user identifier, and device identifier to support detection of local staging, automation tooling, and export utilities.

·        File interaction telemetry capturing file read, write, copy, archive, and delete operations including file identifiers, path, sensitivity label where available, and associated user context.

·        User session telemetry capturing session initiation, termination, duration, device association, and concurrent session identifiers.

Memory and Execution Telemetry

·        In-memory execution telemetry capturing execution of scripts, automation frameworks, or API clients without persistent binaries where supported.

·        Authentication artifact telemetry capturing token issuance, token identifier, associated user identity, device binding, and token reuse across sessions or devices.

Crash and Fault Telemetry

·        Application and API error logs capturing permission-denied events, failed access attempts, object access errors, and abnormal termination events including associated user, object identifier, and timestamp.

·        Authentication failure telemetry capturing failed login attempts, token validation failures, and access boundary violations tied to user and session identifiers.

File and Persistence Telemetry

·        File system telemetry capturing creation of archives, export files, staging artifacts, and temporary data stores including file identifiers, size, and associated process or user.

·        Persistence telemetry capturing session continuation, token lifetime, credential reuse, and retention of access beyond defined thresholds.

Network and Outbound Communication Telemetry

·        Network flow telemetry capturing source IP, destination IP, domain, port, protocol, session duration, byte count (inbound and outbound), and session frequency.

·        DNS telemetry capturing query domain, timestamp, requesting host or user context, and resolution response.

·        Encrypted session metadata capturing TLS session attributes including destination domain, certificate metadata where available, session timing, and frequency patterns.

·        Outbound transfer telemetry capturing file transfers, API-based data movement, synchronization events, object counts where available, and destination classification (trusted vs untrusted).

Web and Application Telemetry (Conditional Availability)

·        SaaS activity logs capturing object-level actions including file access, download, upload, share, unshare, permission modification, and administrative actions with object identifiers and user context.

·        Access control telemetry capturing changes to ACLs, sharing states, external access enablement, delegated permissions, and inheritance relationships affecting effective access.

·        API activity logs capturing request endpoint, method, authentication type, object identifiers accessed, request sequence, pagination depth, request frequency, and response status.

·        Administrative audit logs capturing configuration changes including sharing policies, external access controls, logging configuration, and audit settings.

Identity and Authentication Telemetry

·        Authentication logs capturing login events including timestamp, user identifier, device identifier, source IP, authentication method, and MFA status.

·        Session telemetry capturing session identifiers, token issuance, token-to-user mapping, device binding, concurrent sessions, and geographic origin.

·        Privilege and role assignment logs capturing changes in group membership, role assignments, and access entitlements affecting sensitive data access.

·        Federation and cross-tenant authentication logs capturing external identity access, trust relationships, and delegated access events with tenant identifiers.

Data Access and Sensitivity Telemetry

·        Data access logs capturing object-level access including object identifiers, repository identifiers, access timestamp, user identifier, and action performed.

·        Data classification telemetry capturing sensitivity labels, tagging, or protection states associated with data objects at time of access.

·        Audit telemetry capturing modification of classification labels, tagging, or protection states including previous and new values.

·        Access control state telemetry capturing effective permissions applied to data objects at time of access.

Correlation and Identifier Requirements

·        All telemetry sources must include consistent user identifiers, session identifiers, and timestamps to enable cross-domain correlation.

·        Object identifiers must be consistently logged across SaaS, API, and data access telemetry to support sequence and aggregation detection.

·        Device identifiers or host identifiers must be present to support identity-to-device correlation.

·        Tenant or domain identifiers must be captured for cross-tenant and external access detection.

Telemetry Availability Requirements

·        Identity telemetry must include session-level detail, token usage, and device association with minimal data loss.

·        SaaS and application logs must provide object-level visibility for access, sharing, and permission changes.

·        API logging must include request-level detail including endpoints, authentication type, object identifiers, and sequence patterns.

·        Network telemetry must include flow-level data with byte counts and destination visibility.

·        Logging systems must ensure timely ingestion, consistent retention, and minimal delay between event generation and availability for detection.

·        Data classification or tagging must be consistently applied and logged to enable sensitivity-based detection prioritization.

Telemetry Limitations and Gaps

·        Absence or inconsistency of data classification reduces ability to distinguish high-value activity, increasing detection ambiguity.

·        Incomplete API logging or missing object-level fields prevents detection of enumeration, staging, or automation patterns.

·        Lack of token-to-identity binding limits detection of token misuse, reuse, or cross-session abuse.

·        Limited visibility into encrypted traffic prevents inspection of content, requiring reliance on metadata and behavioral indicators.

·        Inconsistent identifiers across systems reduce ability to perform cross-domain correlation and sequence detection.

·        Delayed log ingestion or insufficient retention reduces ability to detect temporal and low-and-slow attack patterns.

·        Gaps in SaaS audit logging or administrative visibility reduce detection of permission changes and exposure events.

Figure 4

S24 — Detection Opportunities and Gaps

Detection Opportunities

·        High-confidence detection of sensitive data access when object-level logging, accurate data classification, and identity/session telemetry are present with complete field-level visibility and minimal ingestion delay.

·        Reliable detection of unauthorized permission changes and exposure events when access control telemetry captures full ACL state transitions, sharing modifications, and external identity attribution.

·        Strong detection of bulk permission propagation and rapid sharing expansion when SaaS telemetry provides complete object counts, user counts, and high-fidelity timestamp data.

·        Effective identification of API-driven automation when API telemetry includes request sequencing, object identifiers, authentication type, and pagination depth with consistent coverage.

·        Detection of data staging behavior when access logs, API telemetry, and file interaction data provide visibility into multi-object retrieval, export operations, and intermediate staging activity.

·        High-confidence exfiltration detection when network telemetry provides flow-level visibility, byte counts, destination classification, and can be correlated with upstream data access activity.

·        Detection of exposure-first attack patterns when sharing logs and permission telemetry accurately capture effective changes in data accessibility state.

·        Identification of privilege escalation and access scope expansion when identity telemetry includes role changes, group membership updates, and entitlement tracking with historical baseline comparison.

·        Detection of temporal attack patterns including burst, low-and-slow, and sequence-based behavior when sufficient telemetry retention enables longitudinal analysis.

·        Cross-domain behavioral detection when consistent identifiers enable reliable correlation across identity, SaaS, API, and network telemetry.

Detection Gaps

·        Inability to reliably detect sensitive data access when classification or tagging is absent, inconsistent, or subject to manipulation, resulting in loss of prioritization context.

·        Reduced or absent detection of API-based enumeration, staging, or automation when API logs lack object identifiers, request sequencing, or authentication detail.

·        Limited visibility into token-based or non-interactive access when token-to-identity and token-to-device binding is incomplete or not logged.

·        Inability to detect content of encrypted exfiltration due to lack of payload visibility, requiring reliance on indirect metadata signals that may be ambiguous.

·        Detection blind spots in SaaS environments where audit logging is delayed, incomplete, sampled, or lacks object-level granularity.

·        Failure to detect gradual permission drift or low-and-slow exposure when longitudinal baselines are unavailable, immature, or insufficiently retained.

·        Loss of detection capability when correlation identifiers are inconsistent, missing, or cannot be joined across identity, SaaS, API, and network telemetry.

·        Inability to detect staging activity occurring entirely within SaaS environments when endpoint telemetry is unavailable and object-level logs are insufficient.

·        Limited detection of workflow abuse where export, reporting, or synchronization features are used within normal operational patterns without sufficient behavioral differentiation.

·        Inability to detect classification downgrade or sensitivity manipulation when audit telemetry for label or protection changes is not captured or retained.

·        Detection degradation when attackers influence or poison baseline models over time, reducing effectiveness of anomaly-based detection.

High-Impact Detection Gaps

·        Absence or inconsistency of data classification or sensitivity tagging, preventing prioritization and increasing both false positives and false negatives.

·        Lack of object-level SaaS and API telemetry, preventing detection of aggregation, staging, and enumeration behaviors.

·        Missing token-level telemetry and identity binding, enabling undetected token misuse, replay, and cross-session abuse.

·        Correlation failure due to inconsistent or missing identifiers across telemetry domains, preventing reconstruction of attack sequences.

·        Limited visibility into abuse of approved or trusted services, where exfiltration or exposure occurs within expected platforms without sufficient behavioral baselines.

·        Exposure pathways that are not logged or only partially logged, resulting in silent data exposure without observable signals.

·        Inadequate logging retention or delayed ingestion, preventing detection of temporal and low-and-slow attack patterns.

Detection Coverage Strength Assessment

·        Strong coverage only in environments with complete, real-time, object-level telemetry across identity, SaaS, API, and network domains with consistent correlation identifiers.

·        Moderate coverage in environments with partial SaaS or API visibility, where some behavioral signals can be detected but correlation is limited.

·        Moderate-to-weak coverage for low-and-slow or distributed attacks when baseline maturity or retention is insufficient.

·        Weak coverage in environments lacking data classification, object-level logging, or consistent identity binding, where detection becomes largely inferential.

·        Weak coverage for attacks leveraging trusted services, workflow features, or partially logged exposure mechanisms.

Detection Opportunity Prioritization

·        Prioritize detection strategies combining sensitive data access, permission modification, and exposure state changes for highest confidence and lowest noise.

·        Focus on API and automation detection where request-level telemetry enables identification of non-human behavior and structured access patterns.

·        Prioritize cross-domain correlation using consistent identifiers to reconstruct attack sequences across identity, data, and network layers.

·        Emphasize detection of exposure events as primary risk vector alongside exfiltration detection.

·        Deprioritize signals lacking sensitivity context, correlation capability, or measurable deviation due to high false positive risk.

·        Balance detection sensitivity against operational noise by requiring multi-signal correlation and measurable thresholds before alerting.

Detection Illusion Risks

·        Perceived high-confidence detection of sensitive data access may be invalid when classification accuracy is low or inconsistent, leading to misprioritized or missed detections.

·        Detection of exposure or permission changes may appear complete but fail when SaaS logging is delayed, sampled, or partially implemented.

·        API-based detection may appear reliable but degrade significantly when object identifiers, request sequencing, or authentication context are not fully logged.

·        Cross-domain correlation may be assumed but fail in practice due to inconsistent identifiers, resulting in fragmented or incomplete detection visibility.

·        Baseline-driven detection may appear effective but degrade over time due to baseline poisoning, environmental drift, or incomplete historical data.

·        Detection of exfiltration through trusted services may appear covered but fail when baseline usage patterns are not sufficiently mature to distinguish abuse from normal activity.

S25 Ultra-Tuned Detection Engineering Rules

Suricata

Detection Viability Assessment

·        Suricata operates at the network layer and is limited to packet inspection, flow metadata, and signature-based detection.

·        No native visibility into identity context, SaaS activity, object-level data access, permission changes, or data classification.

·        Encrypted traffic (TLS) significantly reduces payload inspection capability, which is critical for modern SaaS and API-driven environments.

Behavioral Opportunity Evaluation

·        Outbound communication monitoring based on destination, volume, and protocol behavior is possible.

·        Detection of known malicious infrastructure or suspicious domains is feasible through signature and reputation-based matching.

·        Basic anomaly detection of network flows (e.g., unusual destinations or traffic spikes) is possible but lacks contextual enrichment.

Candidate Detection Evaluation

·        Sensitive data access detection → Not observable (no data-layer visibility).

·        Permission modification or exposure detection → Not observable.

·        API-driven automation detection → Not observable.

·        Data staging detection → Not observable.

·        Exfiltration detection → Weakly observable through flow anomalies only.

Rejection Analysis

·        All high-value S22 signals require identity, data, or SaaS telemetry which Suricata cannot provide.

·        Network-only indicators lack sufficient context to bind activity to sensitive data or user behavior.

·        Encrypted traffic eliminates visibility into content, forcing reliance on indirect indicators with high false positive rates.

·        Flow-based anomaly detection alone cannot meet DRI ≥ 7.5 due to noise and lack of behavioral anchoring.

Final Disposition

·        No detection rules meet CyberDax DRI ≥ 7.5 threshold.

·        Suricata is excluded from S25 rule development for this scenario.

Operational Note

·        Suricata may still provide supporting telemetry for correlation in SIEM platforms, but should not be used as a primary detection engine for data exposure or SaaS-driven breach scenarios.

SentinelOne

Rule 1 — Sensitive Data Aggregation with Compression or Packaging Behavior

Rule Type

·        SentinelOne Deep Visibility Query

Detection Logic

·        Detect high-volume access to sensitive files combined with compression, archiving, or packaging behavior within a defined time window.

·        This rule requires both aggregation behavior and packaging intent to reduce overlap with normal user activity.

Detection Rationale

·        This rule is strongly anchored to the staging phase immediately prior to transfer or export.

·        It is resilient against simple tool substitution because multiple archive and packaging utilities are covered.

·        It avoids dependence on identity or SaaS telemetry and remains endpoint-native.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong behavioral anchoring to staging activity, clear packaging intent, and good resistance to basic tool variation.

TCR Assessment

·        Operational TCR: Moderate due to dependence on complete process execution, command-line, and file interaction telemetry.

·        Full-Telemetry TCR: High when process execution, command-line, and file activity visibility are consistently available and normalized.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_DIRECTORIES> using environment-specific high-value data locations such as legal, finance, executive, policy, HR, investigation, and synchronized local repository paths.

·        Set <BASELINE_FILE_ACCESS_THRESHOLD> using per-user or per-role historical file interaction baselines for sensitive directories.

·        Set <TIME_WINDOW_MINUTES> to detect burst aggregation behavior. Recommended starting range is 5 to 30 minutes.

·        Validate that SentinelOne captures process execution, command-line arguments, and file interaction telemetry consistently across the monitored endpoint population.

·        Allowlist known backup, packaging, archival, software distribution, and legitimate bulk document processing workflows.

·        Tune separately for administrators, developers, automation accounts, and packaging teams where legitimate archive creation is expected.

Detection Code (SentinelOne Deep Visibility)

event_type = "Process Creation"
AND process_name IN ("7z.exe","7za.exe","winrar.exe","rar.exe","powershell.exe","tar.exe","zip.exe")
AND command_line CONTAINS ANY ("-r","-a","compress","archive","zip","rar","tar")
AND file_operation_count > <BASELINE_FILE_ACCESS_THRESHOLD>
AND file_path CONTAINS ANY (<SENSITIVE_DATA_DIRECTORIES>)
WITHIN <TIME_WINDOW_MINUTES>

Rule 2 — Bulk Sensitive Data Movement to Staging Destinations with Source Diversity

Rule Type

·        SentinelOne Deep Visibility Query

Detection Logic

·        Detect bulk movement of sensitive data into staging destinations when both file write volume and diversity of source locations exceed baseline thresholds within a defined time window.

·        This rule requires destination risk context plus aggregation-like source diversity to avoid thin, location-only logic.

Detection Rationale

·        This rule captures pre-transfer staging where sensitive files are consolidated from multiple source locations into temporary, export, removable-media, sync, or network-accessible destinations.

·        The source-diversity requirement adds intent signal and reduces false positives from ordinary single-folder work activity.

·        It remains valid even when archive tooling is not used.

DRI Assessment

·        Meets DRI ≥ 7.5 with solid behavioral anchoring to staging activity through combined volume, destination risk, and source diversity, while retaining moderate evasion risk through highly distributed low-volume movement.

TCR Assessment

·        Operational TCR: Moderate due to dependence on complete source-path, destination-path, and file write telemetry.

·        Full-Telemetry TCR: High when source and destination relationships are consistently captured and normalized.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_DIRECTORIES> for monitored high-value source locations.

·        Define <HIGH_RISK_STAGING_PATHS> to include temp directories, export folders, user-controlled working directories, removable-media paths, sync folders, and network share destinations.

·        Set <BASELINE_FILE_COPY_THRESHOLD> using normal user and role-based bulk file movement behavior.

·        Set <BASELINE_DIRECTORY_DIVERSITY_THRESHOLD> using normal counts of unique source directories involved in legitimate file consolidation workflows.

·        Set <TIME_WINDOW_MINUTES> aligned to expected staging-burst behavior.

·        Allowlist legitimate backup, migration, synchronization, software deployment, and approved bulk export workflows.

·        Validate that SentinelOne captures both source and destination file path telemetry with sufficient fidelity for bulk-movement analysis.

·        Tune separately for administrators, support teams, and power users who routinely perform multi-directory file handling.

Detection Code (SentinelOne Deep Visibility)

event_type = "File Write"
AND source_file_path CONTAINS ANY (<SENSITIVE_DATA_DIRECTORIES>)
AND destination_path CONTAINS ANY (<HIGH_RISK_STAGING_PATHS>)
AND file_write_count > <BASELINE_FILE_COPY_THRESHOLD>
AND unique_source_directory_count > <BASELINE_DIRECTORY_DIVERSITY_THRESHOLD>
WITHIN <TIME_WINDOW_MINUTES>

Rule 3 — Structured Enumeration of Sensitive Data Locations

Rule Type

·        SentinelOne Deep Visibility Query

Detection Logic

·        Detect repeated structured enumeration of sensitive directories using command-line or scripting tools when execution frequency exceeds baseline thresholds within a defined time window.

·        This rule is intended to capture pre-staging discovery behavior and should be treated as a lower-confidence but still viable behavioral detection.

Detection Rationale

·        This rule captures discovery activity preceding aggregation and staging of high-value data.

·        It provides earlier detection opportunity than staging rules but carries greater overlap with legitimate administrative behavior.

·        Its value increases when correlated operationally with Rule 1 or Rule 2 outputs, even though the rule must stand on its own design merits.

DRI Assessment

·        Meets DRI ≥ 7.5 with moderate behavioral anchoring to pre-staging reconnaissance and higher dependence on environment-specific tuning to control noise.

TCR Assessment

·        Operational TCR: Moderate-Low due to dependence on command-line visibility and accurate process normalization.

·        Full-Telemetry TCR: Moderate because legitimate enumeration behavior varies significantly by role and workflow.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_DIRECTORIES> aligned to high-value local data locations.

·        Set <BASELINE_ENUMERATION_THRESHOLD> using historical command-line and scripting usage patterns for users and administrators.

·        Set <TIME_WINDOW_MINUTES> to detect burst discovery behavior rather than ordinary browsing.

·        Exclude known IT automation, indexing services, backup scanners, compliance tools, and approved administrative workflows.

·        Ensure command-line logging is enabled and normalized consistently across all relevant endpoints.

·        Apply stricter thresholds for administrator and engineering populations where legitimate scripted enumeration is more common.

Detection Code (SentinelOne Deep Visibility)

event_type = "Process Creation"
AND process_name IN ("powershell.exe","cmd.exe","bash.exe")
AND command_line CONTAINS ANY ("dir","ls","Get-ChildItem","-Recurse","-Include","find","forfiles")
AND target_path CONTAINS ANY (<SENSITIVE_DATA_DIRECTORIES>)
AND execution_count > <BASELINE_ENUMERATION_THRESHOLD>
WITHIN <TIME_WINDOW_MINUTES>

Splunk

Rule 1 — Sensitive Data Exposure Through Effective Accessibility-State Change

Rule Type

·        Splunk SPL Correlation Search

Detection Logic

·        Detect a sensitive data object transitioning from a restricted or internal-only access state to an externally accessible, anonymous, public, federated, or delegated external state.

·        This rule is anchored to effective exposure outcome rather than requiring a preceding read event.

·        The rule requires a measurable accessibility-state change and excludes approved external collaboration patterns.

Detection Rationale

·        This is the strongest exposure-first detection for this scenario because it targets the actual exposure event rather than inferred preparation or follow-on behavior.

·        It reduces false positives by requiring both sensitivity context and a real change in effective accessibility state.

·        It remains resilient even when the attacker exposes data without generating a clean prior access sequence.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong anchoring to exposure-state transition, low dependency on indirect inference, and strong resilience against timing-based evasion.

TCR Assessment

·        Operational TCR: Moderate-High due to dependence on complete object-level sharing and permission telemetry plus accurate sensitivity tagging.

·        Full-Telemetry TCR: High when prior state, new state, object identifier, destination domain, and actor context are fully logged and normalized.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS> using the organization’s data classification taxonomy.

·        Define <RESTRICTED_ACCESS_STATES> and <EXTERNAL_ACCESS_STATES> using normalized sharing and permission-state values.

·        Define <APPROVED_EXTERNAL_DOMAINS> and <APPROVED_EXTERNAL_COLLABORATION_PATTERNS> for sanctioned partners, legal workflows, and approved sharing models.

·        Normalize fields for object_id, principal_id, session_id, token_id, previous_access_state, new_access_state, dest_domain, and data_label.

·        Ensure the telemetry captures effective permission state, not just the action verb.

·        Tune by role to suppress expected external collaboration workflows for approved populations.

Detection Code (Splunk SPL)

index=<SPLUNK_INDEX> sourcetype=<SHARING_LOGS>
data_label IN (<SENSITIVE_DATA_LABELS>)
action IN ("share","permission_change","link_create","delegate_add","external_access_enable")
previous_access_state IN (<RESTRICTED_ACCESS_STATES>)
new_access_state IN (<EXTERNAL_ACCESS_STATES>)
| where NOT (
    dest_domain IN (<APPROVED_EXTERNAL_DOMAINS>)
    OR collaboration_pattern IN (<APPROVED_EXTERNAL_COLLABORATION_PATTERNS>)
)
| stats earliest(_time) as first_seen
        latest(_time) as last_seen
        values(action) as actions
        values(previous_access_state) as previous_access_state
        values(new_access_state) as new_access_state
        values(dest_domain) as dest_domain
        by principal_id, object_id, data_label

Rule 2 — API-Driven Structured Enumeration of Sensitive Data

Rule Type

·        Splunk SPL Correlation Search

Detection Logic

·        Detect non-interactive or token-based API access to sensitive data where behavior shows structured enumeration through high object diversity, repeated endpoint family use, bounded request sequencing, and pagination depth inconsistent with normal application behavior.

·        This rule is not anchored to simple request volume alone.

·        The rule is designed to survive rate-throttled or low-and-slow automation when structure remains observable.

Detection Rationale

·        This rule targets automated harvesting behavior common in large data theft operations.

·        It is stronger than a raw threshold model because it combines access diversity, API structure, and authentication context.

·        It is resilient to lower-rate execution because it emphasizes patterned access, not only burst intensity.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong anchoring to automation-consistent enumeration behavior and good resistance to request-rate evasion.

TCR Assessment

·        Operational TCR: Moderate due to dependence on detailed API logging, pagination fields, object identifiers, and authentication context.

·        Full-Telemetry TCR: High when request sequence, object identifiers, endpoint family, auth type, and page-depth data are consistently logged.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS> and ensure they are present in API access telemetry or joinable through object metadata.

·        Define <NON_INTERACTIVE_AUTH_TYPES> for OAuth app tokens, service tokens, PATs, delegated app auth, and equivalent non-human auth models.

·        Set <TIME_WINDOW_MINUTES> for bounded structured-access analysis.

·        Set <BASELINE_OBJECT_DIVERSITY_THRESHOLD>, <BASELINE_REQUEST_THRESHOLD>, and <BASELINE_PAGINATION_THRESHOLD> using historical per-role and per-client behavior.

·        Normalize principal_id, session_id, token_id, src_ip, api_endpoint_family, object_id, page_number, and auth_type.

·        Allowlist approved service accounts, approved integration clients, and sanctioned bulk-processing applications only where behavior is expected and documented.

Detection Code (Splunk SPL)

index=<SPLUNK_INDEX> sourcetype=<API_LOGS>
data_label IN (<SENSITIVE_DATA_LABELS>)
auth_type IN (<NON_INTERACTIVE_AUTH_TYPES>)
| bin _time span=<TIME_WINDOW_MINUTES>m
| stats count as request_count
        dc(object_id) as unique_objects
        dc(api_endpoint_family) as endpoint_family_count
        max(page_number) as max_page_number
        values(api_endpoint_family) as endpoint_families
        values(user_agent) as user_agents
        by principal_id, session_id, token_id, src_ip, _time
| where request_count > <BASELINE_REQUEST_THRESHOLD>
    AND unique_objects > <BASELINE_OBJECT_DIVERSITY_THRESHOLD>
    AND max_page_number > <BASELINE_PAGINATION_THRESHOLD>
    AND endpoint_family_count <= <MAX_EXPECTED_ENDPOINT_FAMILY_COUNT>
| where NOT principal_id IN (<APPROVED_SERVICE_ACCOUNTS>)

Rule 3 — Sensitive Data Access Followed by Abnormal Transfer Profile

Rule Type

·        Splunk SPL Correlation Search

Detection Logic

·        Detect a bounded sequence in which sensitive data access is followed by outbound transfer behavior whose destination, service type, volume, or frequency deviates from established baseline for the same role, principal, client, or workflow.

·        This rule requires access-plus-transfer correlation within a defined window using stable correlation keys and summary aggregation rather than fragile broad-session reconstruction.

·        The rule is designed to detect abuse of both clearly external destinations and trusted services used in abnormal ways.

Detection Rationale

·        This rule captures exfiltration behavior without collapsing into a volume-only network anomaly.

·        It is anchored on sensitive data interaction first, then abnormal outbound movement second.

·        It improves resilience against trusted-service abuse by using transfer-profile deviation rather than relying only on coarse destination classification.

·        The summary-based design is operationally stronger than transaction-heavy or join-fragile sequence patterns.

DRI Assessment

·        Meets DRI ≥ 7.5 with solid behavioral anchoring to bounded access-to-transfer sequence, while retaining moderate dependency on correlation fidelity and destination-profile baselining.

TCR Assessment

·        Operational TCR: Moderate due to dependence on network flow visibility, destination profiling, and preservation of session, token, or principal correlation fields.

·        Full-Telemetry TCR: High when access logs, network logs, session identifiers, destination service classification, and baseline profiles are fully available and normalized.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS> and ensure they are available in access telemetry.

·        Set <TIME_WINDOW_MINUTES> for bounded access-to-transfer correlation.

·        Define <BASELINE_TRANSFER_VOLUME> and <BASELINE_TRANSFER_FREQUENCY> per role, principal, application, and business workflow.

·        Define <ABNORMAL_DEST_SERVICE_TYPES> for service classes that are high-risk when used outside expected workflow, such as personal sync, consumer storage, unmanaged collaboration, or unsanctioned transfer services.

·        Normalize and preserve principal_id, session_id, token_id, src_ip, dest_domain, dest_service, dest_service_type, bytes_out, and data_label.

·        Create a correlation key hierarchy of session_id → token_id → principal_id + src_ip when session-level identifiers are not consistently present.

·        Exclude documented bulk-transfer workflows, backup jobs, approved sync clients, and sanctioned partner exchanges only after baseline validation is complete.

·        Implement destination deviation using baseline lookups or summary tables keyed by role, principal, service, and workflow rather than a simple static approved-domain list alone.

·        Populate the summary stage on a schedule aligned to <TIME_WINDOW_MINUTES> so access and transfer windows remain comparable.

Detection Code (Splunk SPL)

(
    search index=<SPLUNK_INDEX> sourcetype=<DATA_ACCESS_LOGS>
    data_label IN (<SENSITIVE_DATA_LABELS>)
    | eval corr_key=coalesce(session_id, token_id, principal_id . ":" . src_ip)
    | bin _time span=<TIME_WINDOW_MINUTES>m
    | stats earliest(_time) as access_time
            dc(object_id) as accessed_object_count
            values(data_label) as data_labels
            by corr_key, principal_id, src_ip, _time
)
| append
    [
    search index=<SPLUNK_INDEX> sourcetype=<NETWORK_LOGS>
    | eval corr_key=coalesce(session_id, token_id, principal_id . ":" . src_ip)
    | bin _time span=<TIME_WINDOW_MINUTES>m
    | stats sum(bytes_out) as total_bytes_out
            count as transfer_event_count
            values(dest_domain) as dest_domains
            values(dest_service) as dest_services
            values(dest_service_type) as dest_service_types
            by corr_key, principal_id, src_ip, _time
    ]
| stats min(access_time) as access_time
        max(total_bytes_out) as total_bytes_out
        max(transfer_event_count) as transfer_event_count
        values(dest_domains) as dest_domains
        values(dest_services) as dest_services
        values(dest_service_types) as dest_service_types
        values(data_labels) as data_labels
        max(accessed_object_count) as accessed_object_count
        by corr_key, principal_id, src_ip, _time
| where isnotnull(access_time)
    AND total_bytes_out > <BASELINE_TRANSFER_VOLUME>
    AND transfer_event_count > <BASELINE_TRANSFER_FREQUENCY>
| lookup <DESTINATION_BASELINE_LOOKUP> principal_id dest_services OUTPUT expected_volume expected_frequency approved_workflow
| where isnull(approved_workflow)
    OR total_bytes_out > expected_volume
    OR transfer_event_count > expected_frequency
    OR mvfind(dest_service_types, "<ABNORMAL_DEST_SERVICE_TYPES>") >= 0

Elastic

Rule 1 — Sensitive Data Exposure Through Effective Accessibility-State Change

Rule Type

·        Elastic Detection Rule — KQL

Detection Logic

·        Detect a sensitive data object transitioning from a restricted or internal-only access state to an externally accessible state.

·        Anchored to exposure outcome, independent of prior access events.

Detection Rationale

·        Direct detection of the actual exposure event.

·        Minimizes inference and reduces false positives through explicit state transition.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong outcome-based behavioral anchoring.

TCR Assessment

·        Operational TCR: Moderate-High

·        Full-Telemetry TCR: High

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS>, <RESTRICTED_ACCESS_STATES>, and <EXTERNAL_ACCESS_STATES>.

·        Normalize object, principal, and access state fields.

·        Allowlist approved collaboration workflows and domains.

·        Validate that effective permission state transitions are logged.

Detection Code (Elastic KQL)

event.dataset : <SHARING_LOGS> and
data.label : (<SENSITIVE_DATA_LABELS>) and
event.action : ("share" or "permission_change" or "link_create" or "delegate_add" or "external_access_enable") and
sharing.previous_access_state : (<RESTRICTED_ACCESS_STATES>) and
sharing.new_access_state : (<EXTERNAL_ACCESS_STATES>) and
not destination.domain : (<APPROVED_EXTERNAL_DOMAINS>) and
not sharing.collaboration_pattern : (<APPROVED_EXTERNAL_COLLABORATION_PATTERNS>)

Rule 2 — API-Driven Structured Enumeration of Sensitive Data

Rule Type

·        Elastic Detection Rule — Threshold with Precomputed Behavioral Metrics

Detection Logic

·        Detect structured API-based enumeration of sensitive data using object diversity, pagination depth, bounded endpoint usage, and stable client behavior.

·        Anchored to patterned access, not raw request volume.

Detection Rationale

·        Captures automated harvesting behavior even under throttled conditions.

·        Uses multiple behavioral constraints to reduce evasion and noise.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong anchoring to structured automation patterns.

TCR Assessment

·        Operational TCR: Moderate

·        Full-Telemetry TCR: High

Engineering Implementation Instructions

·        Define <NON_INTERACTIVE_AUTH_TYPES> and <SENSITIVE_DATA_LABELS>.

·        Generate stable correlation.actor_key prior to detection.

·        Precompute window metrics:

o   api.window_request_count

o   api.window_unique_object_count

o   api.window_endpoint_family_count

o   api.window_max_page_number

o   api.window_user_agent_variance_count

·        Set thresholds based on role-specific baselines.

·        Do not deploy without validated precomputed metrics.

Detection Code (Elastic KQL)

event.dataset : <API_LOGS> and
data.label : (<SENSITIVE_DATA_LABELS>) and
auth.type : (<NON_INTERACTIVE_AUTH_TYPES>) and
not principal.id : (<APPROVED_SERVICE_ACCOUNTS>) and
api.window_request_count > <BASELINE_REQUEST_THRESHOLD> and
api.window_unique_object_count > <BASELINE_OBJECT_DIVERSITY_THRESHOLD> and
api.window_max_page_number > <BASELINE_PAGINATION_THRESHOLD> and
api.window_endpoint_family_count <= <MAX_EXPECTED_ENDPOINT_FAMILY_COUNT> and
api.window_user_agent_variance_count <= <BASELINE_USER_AGENT_VARIANCE_THRESHOLD>

Rule 3 — Sensitive Data Access Followed by Abnormal Transfer Behavior

Rule Type

·        Elastic Detection Rule — EQL Sequence with Enriched Deviation Signals

Detection Logic

·        Detect sensitive data access followed by transfer behavior that is both:

o   not part of an approved workflow

o   and exhibits abnormal volume, abnormal frequency, or high-risk destination usage with sufficient transfer magnitude

Detection Rationale

·        Captures exfiltration while preventing false positives from legitimate large transfers.

·        Requires both intent (access) and abnormal outcome (transfer deviation).

·        Prevents over-triggering from destination type alone.

DRI Assessment

·        Meets DRI ≥ 7.5 with strong sequence anchoring and controlled detection scope.

TCR Assessment

·        Operational TCR: Moderate

·        Full-Telemetry TCR: High

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS> and <ABNORMAL_DEST_SERVICE_TYPES>.

·        Generate correlation.access_transfer_key before detection.

·        Precompute and enrich:

o   network.transfer_volume_abnormal

o   network.transfer_frequency_abnormal

o   destination.workflow_approved

·        Enforce minimum transfer magnitude threshold.

·        Do not deploy without validated enrichment pipeline.

Detection Code (Elastic EQL)

sequence by correlation.access_transfer_key with maxspan=<TIME_WINDOW_MINUTES>m
  [ any where
      event.dataset == <DATA_ACCESS_LOGS> and
      data.label in (<SENSITIVE_DATA_LABELS>)
  ]
  [ any where
      event.dataset == <NETWORK_LOGS> and
      destination.workflow_approved != true and
      (
        network.transfer_volume_abnormal == true or
        network.transfer_frequency_abnormal == true or
        (
          destination.service_type in (<ABNORMAL_DEST_SERVICE_TYPES>) and
          network.bytes_out > <BASELINE_TRANSFER_VOLUME>
        )
      )
  ]

QRadar

Rule 1 — Sensitive Data Exposure Through Effective Accessibility-State Change or External Exposure Action

Rule Type

·        QRadar Correlation Rule with AQL-backed logic

Detection Logic

·        Detect either:

o   a transition from restricted or internal state to external access state

o   or an exposure action involving sensitive data to a non-approved external domain when state-transition telemetry is unavailable

Detection Rationale

·        Primary path captures true exposure-state change.

·        Fallback path preserves detection value when SaaS telemetry lacks full state visibility.

·        This maintains strong anchoring to exposure outcome while improving resilience to incomplete logging.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong outcome anchoring and improved resilience to incomplete telemetry.

TCR Assessment

·        Operational TCR: Moderate-High due to dependency on SaaS audit completeness.

·        Full-Telemetry TCR: High when access-state transitions are fully logged.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS>, <RESTRICTED_ACCESS_STATES>, and <EXTERNAL_ACCESS_STATES>.

·        Define <APPROVED_EXTERNAL_DOMAINS> and <APPROVED_EXTERNAL_COLLABORATION_PATTERNS>.

·        Ensure DSM parsing captures principal_id, object_id, data_label, action, and dest_domain.

·        Validate whether access-state fields are present in each SaaS source.

·        If access-state fields are absent or unreliable, rely on the fallback path.

·        Tune to suppress approved partner-sharing and sanctioned collaboration workflows.

Detection Code (QRadar AQL)

SELECT
  principal_id,
  object_id,
  data_label,
  dest_domain,
  MIN(starttime) AS first_seen,
  MAX(starttime) AS last_seen,
  COUNT(*) AS event_count
FROM events
WHERE LOGSOURCETYPENAME(devicetype) IN (<SHARING_LOG_SOURCES>)
  AND data_label IN (<SENSITIVE_DATA_LABELS>)
  AND action IN ('share','permission_change','link_create','delegate_add','external_access_enable')
  AND dest_domain NOT IN (<APPROVED_EXTERNAL_DOMAINS>)
  AND (
        (
          previous_access_state IN (<RESTRICTED_ACCESS_STATES>)
          AND new_access_state IN (<EXTERNAL_ACCESS_STATES>)
        )
        OR
        previous_access_state IS NULL
      )
GROUP BY principal_id, object_id, data_label, dest_domain

Rule 2 — API-Driven Structured Enumeration of Sensitive Data

Rule Type

·        QRadar Correlation Rule with AQL aggregation

Detection Logic

·        Detect structured API enumeration using object diversity, pagination depth, and bounded endpoint usage under a stable actor identity.

Detection Rationale

·        Anchors on structured automation patterns rather than pure request count.

·        Resistant to throttling and low-and-slow enumeration.

·        Avoids thin, volume-only detection logic.

DRI Assessment

·        Meets DRI ≥ 7.5 with solid behavioral anchoring but platform-constrained aggregation fidelity.

TCR Assessment

·        Operational TCR: Moderate due to DSM parsing and aggregation limits.

·        Full-Telemetry TCR: High when API detail is complete and normalized.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS> and <NON_INTERACTIVE_AUTH_TYPES>.

·        Set thresholds: <BASELINE_REQUEST_THRESHOLD>, <BASELINE_OBJECT_DIVERSITY_THRESHOLD>, and <BASELINE_PAGINATION_THRESHOLD>.

·        Mandatory: precompute <ACTOR_KEY> using token ID, then session ID, then principal ID plus source IP.

·        Ensure DSM parsing captures object_id, api_endpoint_family, page_number, and auth_type.

·        Do not deploy without validated actor-key consistency across relevant API sources.

·        Scope large environments by source or platform if AQL aggregation cost becomes operationally excessive.

Detection Code (QRadar AQL)

SELECT
  actor_key,
  principal_id,
  sourceip,
  COUNT(*) AS request_count,
  COUNT(DISTINCT object_id) AS unique_object_count,
  COUNT(DISTINCT api_endpoint_family) AS endpoint_family_count,
  MAX(page_number) AS max_page_number
FROM events
WHERE LOGSOURCETYPENAME(devicetype) IN (<API_LOG_SOURCES>)
  AND data_label IN (<SENSITIVE_DATA_LABELS>)
  AND auth_type IN (<NON_INTERACTIVE_AUTH_TYPES>)
  AND principal_id NOT IN (<APPROVED_SERVICE_ACCOUNTS>)
GROUP BY actor_key, principal_id, sourceip
HAVING COUNT(*) > <BASELINE_REQUEST_THRESHOLD>
   AND COUNT(DISTINCT object_id) > <BASELINE_OBJECT_DIVERSITY_THRESHOLD>
   AND COUNT(DISTINCT api_endpoint_family) <= <MAX_EXPECTED_ENDPOINT_FAMILY_COUNT>
   AND MAX(page_number) > <BASELINE_PAGINATION_THRESHOLD>
LAST <TIME_WINDOW_MINUTES> MINUTES

Rule 3 — Sensitive Data Access Followed by Abnormal Transfer Behavior

Rule Type

·        QRadar CRE Sequence Rule with AQL-backed transfer-stage building block

Detection Logic

·        Detect sensitive data access followed by transfer behavior that is both not workflow approved and abnormal in volume, abnormal in frequency, or directed to a high-risk destination with sufficient transfer magnitude.

·        This rule requires both abnormal outcome and bounded sequence correlation.

·        High-risk destination type alone is not sufficient to trigger.

Detection Rationale

·        Captures exfiltration behavior while preventing false positives from legitimate large transfers or simple destination classification alone.

·        Requires both intent and abnormal transfer outcome.

·        Maintains stronger alignment between rationale, logic, and trigger conditions.

DRI Assessment

·        Meets DRI ≥ 7.5 with strong sequence anchoring and controlled detection scope.

TCR Assessment

·        Operational TCR: Moderate due to dependence on enrichment and correlation fidelity.

·        Full-Telemetry TCR: High when enrichment, correlation, and network visibility are complete.

Engineering Implementation Instructions

·        Define <SENSITIVE_DATA_LABELS>, <ABNORMAL_DEST_SERVICE_TYPES>, and <BASELINE_TRANSFER_VOLUME>.

·        Mandatory: precompute <ACCESS_TRANSFER_KEY>.

·        Mandatory: precompute enrichment fields transfer_volume_abnormal, transfer_frequency_abnormal, and workflow_approved.

·        Ensure the access-transfer key is propagated consistently across access and network logs.

·        Do not deploy without enrichment validation and correlation-key validation.

·        Validate that high-risk destination classification is normalized and not overly broad.

·        Exclude sanctioned bulk-transfer workflows only after baseline validation is complete.

Detection Code (QRadar AQL — Transfer Stage)

SELECT
  access_transfer_key,
  principal_id,
  sourceip,
  destinationdomain,
  destination_service_type,
  SUM(bytes_out) AS total_bytes_out,
  MAX(transfer_volume_abnormal) AS transfer_volume_abnormal,
  MAX(transfer_frequency_abnormal) AS transfer_frequency_abnormal,
  MAX(workflow_approved) AS workflow_approved
FROM events
WHERE LOGSOURCETYPENAME(devicetype) IN (<NETWORK_LOG_SOURCES>)
GROUP BY access_transfer_key, principal_id, sourceip, destinationdomain, destination_service_type
HAVING workflow_approved != true
   AND (
        transfer_volume_abnormal = true
        OR transfer_frequency_abnormal = true
        OR (
             destination_service_type IN (<ABNORMAL_DEST_SERVICE_TYPES>)
             AND SUM(bytes_out) > <BASELINE_TRANSFER_VOLUME>
           )
       )
LAST <TIME_WINDOW_MINUTES> MINUTES

Azure

Rule 1 — Sensitive Data Exposure via External Sharing, Permission Expansion, or External Access Grant

Rule Type

·        Microsoft Sentinel Analytics Rule — KQL (Scheduled Query)

Detection Logic

·        Detect external exposure of data through sharing events, permission changes, group-based exposure, or external access grants.

·        Detection does not depend solely on sensitivity labels and remains viable when label coverage is incomplete.

Detection Rationale

·        Captures both direct sharing and indirect exposure paths.

·        Resilient to missing or inconsistent sensitivity labeling.

·        Covers attacker use of existing guest accounts, group membership abuse, and externally accessible link creation.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong outcome-based exposure anchoring and improved resilience to incomplete telemetry.

TCR Assessment

·        Operational TCR: Moderate-High depending on Unified Audit Log completeness and workload coverage.

·        Full-Telemetry TCR: High when M365 audit logs are fully enabled, retained, and normalized.

Engineering Implementation Instructions

·        Ingest OfficeActivity from M365 Unified Audit Logs with SharePoint, OneDrive, and Teams coverage enabled.

·        Define <APPROVED_EXTERNAL_DOMAINS> for sanctioned partner and collaboration workflows.

·        Use sensitivity labels when available, but do not require them for rule viability.

·        Normalize UserId, ObjectId, TargetUserOrGroupName, TargetUserOrGroupType, and Operation.

·        Tune to suppress approved collaboration patterns and sanctioned guest-access models.

Detection Code (KQL)

OfficeActivity
| where Operation in (
    "SharingSet",
    "AddedToSharingLink",
    "AnonymousLinkCreated",
    "SecureLinkCreated",
    "AddedToGroup",
    "SharingInvitationCreated"
)
| where TargetUserOrGroupType in ("Guest","Anonymous")
| where not(TargetUserOrGroupName has_any (<APPROVED_EXTERNAL_DOMAINS>))
| summarize
    event_count = count(),
    first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated)
  by UserId, ObjectId, TargetUserOrGroupName, Operation

Rule 2 — Structured API or Application Enumeration of Data

Rule Type

·        Microsoft Sentinel Analytics Rule — KQL (Behavioral Aggregation)

Detection Logic

·        Detect structured enumeration through high object diversity, repeated request activity, bounded operation diversity, and stable client behavior over a defined time window.

Detection Rationale

·        Captures automation patterns rather than raw request count alone.

·        Resilient to throttling and low-and-slow API or application-driven harvesting.

·        Accounts for both application-driven and user-associated structured access.

DRI Assessment

·        Meets DRI ≥ 8.5 with strong behavioral anchoring to structured enumeration activity.

TCR Assessment

·        Operational TCR: Moderate due to dependence on API and workload log fidelity and application attribution.

·        Full-Telemetry TCR: High when OfficeActivity and Entra ID telemetry are consistently available.

Engineering Implementation Instructions

·        Define <BASELINE_REQUEST_THRESHOLD>, <BASELINE_OBJECT_DIVERSITY_THRESHOLD>, <MAX_OPERATION_VARIANCE>, and <MAX_CLIENT_VARIANCE> using historical baselines.

·        Normalize UserId, AppId, ClientIP, UserAgent, ObjectId, and Operation.

·        Allowlist approved applications and sanctioned service principals.

·        Tune separately for user-driven and app-driven activity where possible.

Detection Code (KQL)

OfficeActivity
| where Operation in ("FileAccessed","FileDownloaded","FilePreviewed")
| summarize
    request_count = count(),
    unique_objects = dcount(ObjectId),
    operation_variance = dcount(Operation),
    client_variance = dcount(ClientIP)
  by UserId, AppId, UserAgent, bin(TimeGenerated, <TIME_WINDOW_MINUTES>m)
| where request_count > <BASELINE_REQUEST_THRESHOLD>
  and unique_objects > <BASELINE_OBJECT_DIVERSITY_THRESHOLD>
  and operation_variance <= <MAX_OPERATION_VARIANCE>
  and client_variance <= <MAX_CLIENT_VARIANCE>
  and not(AppId in (<APPROVED_APPLICATION_IDS>))

Rule 3 — Sensitive Data Access Followed by Abnormal Download or Transfer Context

Rule Type

·        Microsoft Sentinel Analytics Rule — KQL (Correlation Query)

Detection Logic

·        Detect sensitive data access followed by download or sync activity within a bounded time window where abnormal transfer scale is present.

·        Risky session context acts only as a confidence amplifier and cannot independently trigger the rule.

Detection Rationale

·        Captures exfiltration-oriented behavior while avoiding false positives from normal collaboration or isolated risky session indicators.

·        Requires both access-to-download correlation and abnormal transfer behavior.

·        Aligns detection strictly with outcome-driven abnormal activity rather than environmental risk alone.

DRI Assessment

·        Meets DRI ≥ 7.5 with strong sequence anchoring and controlled abnormality requirements.

TCR Assessment

·        Operational TCR: Moderate due to dependence on correlation fidelity and telemetry completeness.

·        Full-Telemetry TCR: High when access, download, sign-in, and device telemetry are fully available and normalized.

Engineering Implementation Instructions

·        Define <BASELINE_DOWNLOAD_THRESHOLD>, <BASELINE_OBJECT_DIVERSITY_THRESHOLD>, and <TIME_WINDOW_MINUTES> using historical baselines.

·        Define <RISKY_SIGNIN_RISK_LEVELS> for risk amplification only.

·        Correlate using UserId + ClientIP + AppId where available.

·        Normalize and preserve access, download, and sign-in context fields.

·        Do not deploy as a pure volume or pure risk-context rule.

Detection Code (KQL)

let access_events =
    OfficeActivity
    | where Operation in ("FileAccessed","FilePreviewed")
    | project AccessTime=TimeGenerated, UserId, ClientIP, AppId, ObjectId;

let download_events =
    OfficeActivity
    | where Operation in ("FileDownloaded","FileSyncDownloadedFull")
    | summarize
        download_count = count(),
        distinct_objects = dcount(ObjectId),
        first_download = min(TimeGenerated)
      by UserId, ClientIP, AppId, bin(TimeGenerated, <TIME_WINDOW_MINUTES>m);

let signin_context =
    SigninLogs
    | extend SignInRisk = tostring(RiskLevelDuringSignIn)
    | summarize
        risky_signin = max(iff(SignInRisk in (<RISKY_SIGNIN_RISK_LEVELS>), 1, 0))
      by UserId=UserPrincipalName, ClientIP=IPAddress, AppId, bin(TimeGenerated, <TIME_WINDOW_MINUTES>m);

access_events
| join kind=inner download_events on UserId, ClientIP, AppId
| where first_download >= AccessTime and first_download - AccessTime <= <TIME_WINDOW_MINUTES>*1m
| join kind=leftouter signin_context on UserId, ClientIP, AppId
| where
    download_count > <BASELINE_DOWNLOAD_THRESHOLD>
    and distinct_objects > <BASELINE_OBJECT_DIVERSITY_THRESHOLD>
| extend risk_amplifier = iff(risky_signin == 1, 1, 0)

AWS

Rule 1 — S3 Exposure via High-Confidence Public or Cross-Account Access Indicators

Rule Type

·        CloudTrail Detection / SIEM Analytics (KQL-equivalent or native query engine)

Detection Logic

·        Detect high-confidence indicators that an S3 bucket or object has been made publicly accessible or exposed to non-approved external principals through ACL or policy modification events.

·        This rule detects exposure indicators and does not perform full semantic evaluation of bucket policy logic unless structured parsing is implemented upstream.

Detection Rationale

·        Captures common exposure paths including public ACL grants, permissive bucket policy changes, object ACL changes, and removal of public access protections.

·        Avoids false precision by treating policy inspection as indicator-based unless structured evaluation exists.

·        Maintains strong exposure anchoring while remaining realistic about detection-layer limitations.

DRI Assessment

·        DRI: 8.7

·        Behavioral Anchoring: Strong — tied to exposure configuration state

·        Evasion Resistance: Moderate-High — attacker must avoid detectable exposure indicators

·        Telemetry Dependency: Moderate — depends on CloudTrail management events

·        Artifact Fragility: Low — based on configuration changes, not transient artifacts

TCR Assessment

·        Operational TCR: Moderate-High

o   Dependent on CloudTrail management event logging and request parameter fidelity

·        Full-Telemetry TCR: High

o   Achieved with CloudTrail + S3 data events + structured policy parsing or enrichment

Engineering Implementation Instructions

·        Enable CloudTrail management events across all regions and accounts

·        Enable S3 data events where feasible

·        Define <APPROVED_EXTERNAL_ACCOUNTS> and <APPROVED_PUBLIC_BUCKETS>

·        Normalize userIdentity.arn, eventName, requestParameters, sourceIPAddress

·        Preferred: parse policy JSON into structured fields (principal, condition, external accounts)

·        If parsing is unavailable, treat this as an indicator-based detection

·        Tune to suppress sanctioned public buckets and approved cross-account access

Detection Code

CloudTrail
| where EventName in (
    "PutBucketAcl",
    "PutBucketPolicy",
    "PutObjectAcl",
    "DeletePublicAccessBlock",
    "PutPublicAccessBlock"
)
| extend policy_text = tostring(RequestParameters)
| extend has_public_indicator =
    policy_text contains "AllUsers"
    or policy_text contains "AuthenticatedUsers"
    or policy_text contains "\"Principal\":\"*\""
    or policy_text contains "\"Principal\": \"*\""
| extend removes_protection = EventName == "DeletePublicAccessBlock"
| where has_public_indicator or removes_protection
| where not(policy_text contains_any (<APPROVED_EXTERNAL_ACCOUNTS>))
| summarize
    event_count = count(),
    first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated)
  by UserIdentityArn, SourceIPAddress, EventName

Rule 2 — Structured Enumeration of Cloud Resources

Rule Type

·        CloudTrail Behavioral Aggregation

Detection Logic

·        Detect structured API enumeration through repeated requests, high resource diversity, and bounded API operation spread within a defined time window.

Detection Rationale

·        Captures automation-driven discovery and data harvesting behavior.

·        Resilient to throttling and low-and-slow attacker execution.

·        Avoids reliance on pure request volume.

DRI Assessment

·        DRI: 8.5

·        Behavioral Anchoring: Strong — structured enumeration pattern

·        Evasion Resistance: Moderate — attacker must trade speed for stealth

·        Telemetry Dependency: Moderate — depends on CloudTrail completeness

·        Artifact Fragility: Moderate — requires stable resource extraction

TCR Assessment

·        Operational TCR: Moderate

o   Dependent on consistent parsing of request parameters and resource identifiers

·        Full-Telemetry TCR: High

o   Achieved when all relevant API calls and resource identifiers are logged

Engineering Implementation Instructions

·        Define <BASELINE_REQUEST_THRESHOLD>, <BASELINE_RESOURCE_DIVERSITY_THRESHOLD>, <MAX_API_VARIANCE>

·        Extract stable resource identifiers (bucket names, object keys, instance IDs, IAM resources)

·        Normalize userIdentity.arn, eventName, requestParameters.bucketName, sourceIPAddress

·        Allowlist approved automation roles and service accounts

·        Validate resource extraction reliability before deployment

Detection Code

CloudTrail
| where EventName in (
    "ListBuckets",
    "ListObjectsV2",
    "GetObject",
    "DescribeInstances",
    "ListRoles"
)
| extend resource = tostring(RequestParameters.bucketName)
| summarize
    request_count = count(),
    unique_resources = dcount(resource),
    api_variance = dcount(EventName)
  by UserIdentityArn, SourceIPAddress, bin(TimeGenerated, <TIME_WINDOW_MINUTES>m)
| where request_count > <BASELINE_REQUEST_THRESHOLD>
  and unique_resources > <BASELINE_RESOURCE_DIVERSITY_THRESHOLD>
  and api_variance <= <MAX_API_VARIANCE>

Rule 3 — Abnormal High-Scale Object Access (Exfiltration Proxy)

Rule Type

·        CloudTrail Behavioral Detection

Detection Logic

·        Detect abnormal high-scale object access patterns through combined high request volume and high object diversity within a bounded time window.

·        Acts as an exfiltration proxy where direct transfer telemetry is unavailable.

Detection Rationale

·        Captures large-scale data access consistent with exfiltration behavior.

·        Requires both scale and diversity to avoid pure volume-based false positives.

·        Resilient to simple throttling but may increase attacker dwell time.

DRI Assessment

·        DRI: 7.6

·        Behavioral Anchoring: Moderate-High — tied to access scale

·        Evasion Resistance: Moderate — attacker can slow execution

·        Telemetry Dependency: Moderate — requires S3 data event logging

·        Artifact Fragility: Moderate — depends on object key extraction

TCR Assessment

·        Operational TCR: Moderate

o   Dependent on S3 data events being enabled

·        Full-Telemetry TCR: High

o   Achieved when all object access events are logged and correlated

Engineering Implementation Instructions

·        Enable S3 data events in CloudTrail

·        Define <BASELINE_REQUEST_THRESHOLD> and <BASELINE_OBJECT_DIVERSITY_THRESHOLD>

·        Normalize userIdentity.arn, requestParameters.key, sourceIPAddress

·        Tune to exclude known bulk-processing workflows

·        Do not deploy if S3 data events are not enabled

Detection Code

CloudTrail
| where EventName == "GetObject"
| extend object_key = tostring(RequestParameters.key)
| summarize
    request_count = count(),
    unique_objects = dcount(object_key)
  by UserIdentityArn, SourceIPAddress, bin(TimeGenerated, <TIME_WINDOW_MINUTES>m)
| where request_count > <BASELINE_REQUEST_THRESHOLD>
  and unique_objects > <BASELINE_OBJECT_DIVERSITY_THRESHOLD>

GCP

Rule 1 — Cloud Storage Exposure via Public or Unauthorized External Principal Access

Rule Type

·        Cloud Audit Logs Detection / SIEM Analytics

Detection Logic

·        Detect IAM policy changes on Cloud Storage resources that introduce:

o   public access through allUsers or allAuthenticatedUsers

o   or principals outside approved internal or sanctioned external domains

·        Detection is indicator-based unless structured IAM policy parsing is implemented upstream.

Detection Rationale

·        Captures both public exposure and non-public external exposure.

·        Addresses attacker behavior where access is granted to attacker-controlled or unapproved external identities instead of wildcard public principals.

·        Maintains outcome anchoring while avoiding false precision in policy evaluation.

DRI Assessment

·        DRI: 8.7

·        Behavioral Anchoring: Strong — exposure configuration state

·        Evasion Resistance: Moderate-High — attacker must avoid detectable IAM changes

·        Telemetry Dependency: Moderate — Admin Activity logs required

·        Artifact Fragility: Low — based on configuration change events

TCR Assessment

·        Operational TCR: Moderate-High

o   Dependent on IAM policy change logging and request parameter parsing quality

·        Full-Telemetry TCR: High

o   Achieved when IAM bindings are parsed into structured member and role fields

Engineering Implementation Instructions

·        Enable Admin Activity logs and retain them centrally.

·        Enable Data Access logs for Cloud Storage to support validation and downstream correlation.

·        Define <APPROVED_INTERNAL_PRINCIPAL_DOMAINS> and <APPROVED_EXTERNAL_PRINCIPALS>.

·        Normalize:

o   principalEmail

o   policy bindings / member identifiers

o   role assignments

·        Preferred implementation: parse IAM bindings into structured fields such as member, role, and condition state.

·        If parsing is unavailable, treat this as a high-confidence exposure-indicator rule rather than full IAM semantic evaluation.

·        Tune to suppress sanctioned public datasets, approved partner access, and documented cross-organization sharing models.

Detection Code

GCPAuditLogs
| where protoPayload.methodName in (
    "storage.setIamPermissions",
    "storage.buckets.setIamPolicy"
)
| extend policy = tostring(protoPayload.serviceData.policyDelta)
| extend has_public =
    policy contains "allUsers"
    or policy contains "allAuthenticatedUsers"
| extend has_unapproved_external =
    policy contains "@"
    and not(policy contains_any (<APPROVED_INTERNAL_PRINCIPAL_DOMAINS>))
    and not(policy contains_any (<APPROVED_EXTERNAL_PRINCIPALS>))
| where has_public or has_unapproved_external
| summarize
    event_count = count(),
    first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated)
  by principalEmail = protoPayload.authenticationInfo.principalEmail

Rule 2 — Structured Enumeration of GCP Resources

Rule Type

·        Cloud Audit Logs Behavioral Aggregation

Detection Logic

·        Detect structured API enumeration through:

o   high resource diversity

o   repeated request activity

o   bounded API operation spread

o   consistent source behavior

Detection Rationale

·        Captures automation-driven discovery and data harvesting.

·        Resilient to low-and-slow and distributed execution.

·        Expanded to cover broader GCP attack surface.

DRI Assessment

·        DRI: 8.5

·        Behavioral Anchoring: Strong

·        Evasion Resistance: Moderate

·        Telemetry Dependency: Moderate

·        Artifact Fragility: Moderate

TCR Assessment

·        Operational TCR: Moderate

o   Dependent on Data Access log coverage and API logging consistency

·        Full-Telemetry TCR: High

o   Achieved when all relevant APIs are logged

Engineering Implementation Instructions

·        Enable Data Access logs for:

o   Cloud Storage

o   Compute

o   IAM

o   BigQuery, if in scope

o   Secret Manager, if in scope

·        Define thresholds:

o   <BASELINE_REQUEST_THRESHOLD>

o   <BASELINE_RESOURCE_DIVERSITY_THRESHOLD>

o   <MAX_API_VARIANCE>

·        Normalize:

o   principalEmail

o   resourceName

o   methodName

o   caller IP, if available

·        Allowlist approved service accounts and documented automation workflows.

·        Validate resource extraction consistency before deployment.

Detection Code

GCPAuditLogs
| where protoPayload.methodName in (
    "storage.objects.list",
    "compute.instances.list",
    "iam.roles.list",
    "bigquery.tables.list",
    "secretmanager.secrets.list"
)
| extend resource = tostring(protoPayload.resourceName)
| summarize
    request_count = count(),
    unique_resources = dcount(resource),
    api_variance = dcount(protoPayload.methodName)
  by principalEmail = protoPayload.authenticationInfo.principalEmail,
     sourceIP = tostring(protoPayload.requestMetadata.callerIp),
     bin(TimeGenerated, <TIME_WINDOW_MINUTES>m)
| where request_count > <BASELINE_REQUEST_THRESHOLD>
  and unique_resources > <BASELINE_RESOURCE_DIVERSITY_THRESHOLD>
  and api_variance <= <MAX_API_VARIANCE>

Rule 3 — Abnormal High-Scale Object Access (Exfiltration Proxy)

Rule Type

·        Cloud Audit Logs Behavioral Detection

Detection Logic

·        Detect abnormal high-scale object access using:

o   high request volume

o   high object diversity

·        Acts as an exfiltration proxy in the absence of direct transfer telemetry.

Detection Rationale

·        Captures large-scale data access indicative of exfiltration.

·        Requires both scale and diversity to avoid pure volume triggers.

·        Resilient to simple throttling, though slower execution may reduce signal concentration.

DRI Assessment

·        DRI: 7.6

·        Behavioral Anchoring: Moderate-High

·        Evasion Resistance: Moderate

·        Telemetry Dependency: Moderate

·        Artifact Fragility: Moderate

TCR Assessment

·        Operational TCR: Moderate

o   Dependent on Data Access logs being enabled

·        Full-Telemetry TCR: High

o   Achieved when all object access events are logged and normalized

Engineering Implementation Instructions

·        Mandatory: enable Data Access logs for Cloud Storage.

·        Do not deploy if Data Access logs are not enabled.

·        Define <BASELINE_REQUEST_THRESHOLD> and <BASELINE_OBJECT_DIVERSITY_THRESHOLD>.

·        Normalize:

o   principalEmail

o   resourceName

·        Tune to exclude known bulk-processing workflows and sanctioned high-volume service activity.

Detection Code

GCPAuditLogs
| where protoPayload.methodName == "storage.objects.get"
| extend object = tostring(protoPayload.resourceName)
| summarize
    request_count = count(),
    unique_objects = dcount(object)
  by principalEmail = protoPayload.authenticationInfo.principalEmail,
     bin(TimeGenerated, <TIME_WINDOW_MINUTES>m)
| where request_count > <BASELINE_REQUEST_THRESHOLD>
  and unique_objects > <BASELINE_OBJECT_DIVERSITY_THRESHOLD>

S26 — Threat-to-Rule Traceability Matrix (Hardened Final)

Exposure / Initial Access Establishment

Threat Behavior

·        Adversary establishes unauthorized access to sensitive data through external sharing, public access configuration, or cross-account / external principal grants.

Primary Detection Signals

·        Access control state change

·        External or public exposure indicators

·        Unauthorized principal assignment

Detection Rule Mapping

·        Azure — Rule 1 (Primary — DRI ≥ 8.5)

·        AWS — Rule 1 (Primary — DRI ≥ 8.5)

·        GCP — Rule 1 (Primary — DRI ≥ 8.5)

Detection Coverage Assessment

·        Strong coverage for exposure state changes across all cloud platforms

Detection Gaps

·        No detection of pre-existing exposure conditions

·        No continuous validation of exposure persistence without additional controls

Discovery / Enumeration

Threat Behavior

·        Adversary performs structured enumeration of cloud resources and data stores using API-driven discovery.

Primary Detection Signals

·        High resource diversity

·        Repeated API access patterns

·        Bounded API operation variance

Detection Rule Mapping

·        Azure — Rule 2 (Primary — DRI ≥ 8.5)

·        AWS — Rule 2 (Primary — DRI ≥ 8.5)

·        GCP — Rule 2 (Primary — DRI ≥ 8.5)

Detection Coverage Assessment

·        Strong behavioral detection across all platforms

·        Resilient to low-and-slow execution

Detection Gaps

·        Distributed enumeration across multiple identities may reduce detection strength

·        Heavy reliance on Data Access or equivalent API logging completeness

Collection / Data Access

Threat Behavior

·        Adversary accesses sensitive data objects at scale through API calls or object retrieval mechanisms.

Primary Detection Signals

·        High-volume object access

·        High object diversity

·        Access patterns inconsistent with baseline behavior

Detection Rule Mapping

·        AWS — Rule 3 (Primary — DRI ≥ 7.5)

·        GCP — Rule 3 (Primary — DRI ≥ 7.5)

·        Azure — Rule 3 (Supporting — DRI ≥ 7.5, sequence-based)

Detection Coverage Assessment

·        Moderate-to-strong coverage via exfiltration proxy detection

·        Azure provides stronger sequence-based correlation

Detection Gaps

·        Low-and-slow access may evade detection thresholds

·        Dependence on Data Access logs (AWS/GCP) as mandatory telemetry

Exfiltration / Data Transfer

Threat Behavior

·        Adversary transfers or stages data outside of the environment or into attacker-controlled access paths.

Primary Detection Signals

·        Access-to-transfer sequence

·        Abnormal download behavior

·        High-scale object access acting as exfiltration proxy

Detection Rule Mapping

·        Azure — Rule 3 (Primary — DRI ≥ 7.5)

·        AWS — Rule 3 (Supporting — proxy detection)

·        GCP — Rule 3 (Supporting — proxy detection)

Detection Coverage Assessment

·        Strong in Azure (direct behavioral detection)

·        Moderate in AWS and GCP (proxy-based detection)

Detection Gaps

·        No direct network-level exfiltration detection in AWS/GCP without additional telemetry

·        Proxy detection may miss highly distributed or extremely low-volume exfiltration

Defense Evasion / Low-and-Slow Execution

Threat Behavior

·        Adversary reduces detection likelihood by throttling activity, distributing access, or blending into legitimate service behavior.

Primary Detection Signals

·        Consistent behavioral patterns despite reduced rate

·        Bounded API variance

·        Sustained structured access patterns

Detection Rule Mapping

·        Azure — Rule 2 (Primary — DRI ≥ 8.5)

·        AWS — Rule 2 (Primary — DRI ≥ 8.5)

·        GCP — Rule 2 (Primary — DRI ≥ 8.5)

Detection Coverage Assessment

·        Strong behavioral resilience across all platforms

Detection Gaps

·        Highly distributed activity across multiple identities may degrade detection effectiveness

·        Requires stable identity attribution and sufficient aggregation windows

Traceability Integrity Summary

·        All major attacker objectives are mapped to validated S25 rules only

·        Primary vs Supporting detection strength is explicitly defined

·        Coverage limitations are transparent and operationally meaningful

·        No false coverage claims or generic system mappings remain

S27 — Behavior & Log Artifacts

Exposure / Access Control Modification Artifacts

·        Azure (OfficeActivity):

o   Operation: SharingSet, AnonymousLinkCreated, SecureLinkCreated

o   TargetUserOrGroupType: Guest, Anonymous

·        AWS (CloudTrail):

o   EventName: PutBucketPolicy, PutBucketAcl, DeletePublicAccessBlock

o   RequestParameters: policy containing public or external principal indicators

·        GCP (Audit Logs):

o   methodName: storage.buckets.setIamPolicy

o   policyDelta: addition of allUsers, allAuthenticatedUsers, or non-approved principals

Enumeration / Discovery Artifacts

·        Azure:

o   Repeated FileAccessed / FilePreviewed events

o   High ObjectId diversity per user/app

·        AWS:

o   EventName: ListObjectsV2, ListBuckets, DescribeInstances

o   High RequestParameters diversity

·        GCP:

o   *methodName: .list operations across services

o   resourceName diversity with stable principalEmail

Data Access / Collection Artifacts

·        Azure:

o   FileAccessed and FileDownloaded sequences

·        AWS:

o   GetObject events with high object_key diversity

·        GCP:

o   storage.objects.get events with high resourceName diversity

Exfiltration / Transfer Artifacts

·        Azure:

o   FileDownloaded events following access events within bounded time window

·        AWS / GCP:

o   No direct transfer telemetry — inferred via:

§  high request_count

§  high object diversity

·        Correlated increase in bytes_out aligned to preceding object access window (AWS/GCP proxy signal)

Evasion / Low-and-Slow Artifacts

·        Repeated identical methodName values across multiple time bins for the same principalEmail or UserIdentityArn

·        Low API variance with sustained activity

·        Stable identity with repeated access patterns

S28 — Detection Strategy and SOC Implementation Guidance

Figure 5

Detection Strategy

·        Prioritize exposure-state detections (Rule 1 across platforms)

·        Use behavioral aggregation for enumeration (Rule 2)

·        Use scale + diversity for access/exfil detection (Rule 3)

·        Correlate across rules to identify attack progression

Alert Prioritization

·        Priority 1

o   Rule 1 alerts (direct exposure events)

·        Priority 2

o   Rule 2 alerts with high resource diversity

·        Priority 3

o   Rule 3 alerts without supporting context, requiring validation before escalation

·        Priority 1 escalation

o   Any Rule 3 alert combined with Rule 2 behavior

Triage Workflow

·        Validate identity:

o   user vs service account vs application

·        Confirm baseline alignment:

o   is activity expected for role?

·        Evaluate scope:

o   number of resources accessed

·        Check sequence:

o   exposure → enumeration → access

Correlation Guidance

·        Rule 1 → Rule 2

o   indicates attacker leveraging newly exposed data

·        Rule 2 → Rule 3

o   indicates transition from discovery to collection

·        Rule 1 → Rule 3

o   high-risk direct exfiltration path

Operational Requirements

·        Data Access logs mandatory for AWS and GCP

·        Identity normalization required across systems

·        Baselines must be environment-specific

S29 — Detection Coverage Summary

Coverage by Stage

·        Exposure

o   Direct detection — High confidence when telemetry completeness is maintained

·        Enumeration

o   Behavioral detection — High confidence

·        Collection

o   Behavioral detection — Moderate confidence

·        Exfiltration

o   Direct detection (Azure) — High confidence

o   Proxy detection (AWS/GCP) — Moderate confidence

Coverage Type

·        Direct Detection:

o   Exposure (all platforms)

o   Exfiltration (Azure only)

·        Behavioral Detection:

o   Enumeration (all platforms)

o   Collection (all platforms)

·        Proxy Detection:

o   Exfiltration (AWS, GCP)

Residual Gaps

·        No detection of pre-existing exposure

·        Distributed low-volume access may evade detection

·        No direct exfiltration telemetry in AWS/GCP

·        Detection dependent on Data Access logs

Confidence Assessment

·        High confidence: Exposure, Enumeration

·        Moderate confidence: Collection, Exfiltration (AWS/GCP)

S30 — Intelligence Maturity Assessment

Maturity Level

·        High — Behaviorally mature detection model with telemetry-dependent constraints

Justification

·        Detection anchored to attacker behavior, not static indicators

·        Coverage exists across all major attack stages

·        Behavioral models reduce reliance on signature-based detection

Strengths

·        Outcome-based exposure detection

·        Behavioral enumeration detection

·        Cross-platform consistency

·        Explicit telemetry dependency handling

Limitations

·        Reliance on Data Access logging for full coverage

·        Exfiltration detection is proxy-based in AWS/GCP

·        Identity fragmentation impacts correlation

Constraints Preventing Higher Maturity

·        Lack of native network exfiltration telemetry in AWS/GCP

·        Dependence on platform logging completeness

·        Limited cross-identity correlation without enrichment

Improvement Path

·        Add network telemetry for exfiltration validation

·        Implement identity correlation across sessions

·        Introduce continuous exposure validation

Final Assessment

·        Detection capability is high and operationally viable

·        Remaining limitations are driven by telemetry constraints, not detection design

S31 — Telemetry Dependencies

Identity and Authentication Telemetry

·        Required to detect valid account abuse, token misuse, and session anomalies

·        Must include session identifiers, token usage, device context, and authentication methods

SaaS and Application Telemetry

·        Required for visibility into object-level access, sharing activity, and permission changes

·        Must capture file access, sharing events, permission state transitions, and administrative actions

API and Audit Telemetry

·        Required to detect structured enumeration, automation, and large-scale data access patterns

·        Must include request endpoints, object identifiers, authentication type, and request sequencing

Data Classification and Sensitivity Telemetry

·        Required to distinguish high-value data from normal activity and enable prioritization

·        Must include consistent labeling or tagging at object level

Network and Outbound Communication Telemetry

·        Required to identify abnormal transfer behavior and destination deviation

·        Must include flow-level data, destination context, and transfer volume

Correlation and Identifier Consistency

·        Required to enable cross-domain detection across identity, SaaS, API, and network layers

·        Must include consistent user, session, object, and device identifiers

S32 — Detection Limitations

·        Detection is degraded when data classification is absent or inconsistent, reducing sensitivity-aware prioritization.

·        Lack of object-level SaaS or API telemetry prevents reliable detection of enumeration, aggregation, and exposure behavior.

·        Incomplete token-to-identity or session attribution limits detection of token reuse and cross-session abuse.

·        Encrypted traffic limits visibility into transfer content, requiring reliance on behavioral indicators.

·        Distributed or low-rate activity reduces signal concentration and may evade threshold-based detection.

·        Inconsistent identifiers across telemetry sources reduce correlation capability and sequence reconstruction.

·        Exposure through partially logged or unlogged mechanisms may remain undetected.

·        Abuse of trusted services and approved collaboration pathways introduces ambiguity and reduces detection confidence.

S33 — Defensive Control & Hardening Improvements

·        Enforce least privilege and strict entitlement management across all data-accessing identities.

·        Implement mandatory multi-factor authentication for all privileged and sensitive-data access paths.

·        Restrict external sharing, link-based access, and delegated permissions through centralized policy enforcement.

·        Enable full SaaS and API audit logging with object-level visibility.

·        Monitor and alert on access control state changes and exposure events as primary risk indicators.

·        Enforce session controls including token lifetime restrictions and device binding.

·        Validate and continuously audit access control configurations across repositories.

·        Establish immediate review and revocation processes for anomalous or excessive data access activity.

S34 — Defensive Control & Hardening Architecture

Figure 6

·        Identity layer functions as the primary control plane, enforcing authentication, session validation, and access governance for all data access paths.

·        SaaS and data layer provides object-level visibility into file access, sharing actions, permission changes, and exposure-state transitions where risk is introduced.

·        API monitoring layer captures structured enumeration, automated access patterns, and large-scale data interaction indicative of collection behavior.

·        Network layer provides supporting visibility into outbound transfer patterns, including abnormal destinations, transfer volume anomalies, and synchronization behavior.

·        Centralized logging and correlation layer enables reconstruction of access, exposure, and transfer sequences across identity, SaaS, API, and network telemetry.

·        Data classification layer provides sensitivity context required to prioritize high-impact exposure and distinguish critical data from baseline activity.

S35 — Defensive Control Mapping Matrix

·        Identity Controls: Enforce authentication, MFA, conditional access, and session management to prevent unauthorized access and limit credential or token misuse.

·        Access Controls: Enforce role-based access control, least privilege, and entitlement governance to restrict unnecessary data access and reduce exposure scope.

·        Sharing and Exposure Controls: Enforce restrictions on external sharing, link-based access, and delegated permissions to prevent unauthorized exposure of data.

·        Monitoring Controls: Enable SaaS, API, identity, and network telemetry collection to provide visibility into access, sharing, and transfer activity.

·        Detection Controls: Apply behavioral monitoring of access patterns, exposure-state changes, and transfer activity to identify anomalous behavior.

·        Governance Controls: Enforce data classification, audit policies, and access review processes to maintain control integrity and support prioritization.

S36 — CyberDax Intelligence Maturity Assessment

Maturity Level

·        Moderate-High

Strengths

·        Behavioral detection is effective when identity, SaaS, and API telemetry are complete and correlated

·        Exposure-state changes provide high-confidence indicators when access control visibility is present

·        Detection approach aligns with identity-centric and data-centric threat models

Limitations

·        Detection effectiveness is dependent on telemetry completeness and classification accuracy

·        Reduced capability in environments lacking object-level SaaS or API visibility

·        Correlation limitations reduce effectiveness in distributed or cross-system attack patterns

Constraints Preventing Higher Maturity

·        Lack of consistent object-level visibility across platforms

·        Incomplete identity, session, and token correlation

·        Limited visibility into trusted-service abuse and encrypted transfer channels

S37 — Strategic Defensive Improvements

·        Transition to an identity-first security model where all data access is continuously validated and governed.

·        Establish unified telemetry architecture with consistent identifiers across identity, SaaS, API, and network domains.

·        Implement organization-wide data classification as a foundational control for risk prioritization and detection accuracy.

·        Adopt continuous exposure validation to identify and remediate unintended data accessibility in near real time.

·        Mature security operations toward behavioral, longitudinal, and correlation-based detection models rather than event-driven alerting.

·        Integrate governance, risk, and security functions to ensure continuous validation of access control effectiveness and exposure risk.

S38 — Attack Economics & Organizational Impact Model

Figure 7

Initial Access Cost to Adversary

·        Low, due to reliance on valid credentials, token reuse, or pre-existing access pathways rather than exploit development or vulnerability chaining

Operational Cost

·        Moderate, driven by structured discovery, enumeration, and controlled data access across distributed repositories

Infrastructure Cost

·        Low, as operations leverage legitimate SaaS and cloud platforms with minimal attacker-controlled infrastructure

Scaling Efficiency

·        High, enabled by API-driven access, automation, and repeatable SaaS-native workflows across environments

Monetization Potential

·        High, due to sensitivity and institutional value of exposed European Commission data for resale or intelligence use

Time to Impact

·        Short, as exposure can be achieved through access or sharing state changes without requiring full exfiltration

Detection Risk

·        Low to Moderate, dependent on availability and quality of identity, API, and object-level telemetry rather than traditional indicators

Defensive Cost Burden

·        High, requiring investment in identity governance, SaaS visibility, data classification, and cross-domain telemetry correlation

S39 — Economic Impact & Organizational Exposure

Direct Financial Impact

·        Incident response, forensic investigation, legal review, remediation, and compliance-driven costs associated with exposure of sensitive institutional data

Indirect Financial Impact

·        Reputational damage, stakeholder trust erosion, and reduced institutional credibility affecting long-term operations

Regulatory Exposure

·        High, driven by EU data protection obligations, cross-border data handling requirements, and institutional accountability

Operational Impact

·        Increased workload for investigation, containment, access validation, and exposure-state verification across systems

Strategic Impact

·        Elevated geopolitical and intelligence risk from potential misuse or redistribution of exposed institutional data

Exposure Persistence Risk

·        High, as exposure conditions may remain active until access controls and sharing states are fully validated and remediated

Recovery Complexity

·        High, due to distributed cloud environments, multiple access pathways, and cross-system validation requirements

S40 — References

Vendor / Platform Documentation

·        European Commission, Commission responds to cyber-attack on its Europa web platform

o   https://ec.europa[.]eu/commission/presscorner/detail/en/ip_26_748

·        CERT-EU, European Commission cloud breach: a supply-chain compromise

o   https://cert[.]europa[.]eu/publications/security-advisories/2026-004

Threat Technique Framework

·        MITRE ATT&CK Framework

o   https://attack.mitre[.]org/

Security Vendor Analysis

·        Cybernews, Hackers steal EU Commission cloud data

o   https://cybernews[.]com/news/european-commission-aws-cloud-breach-stolen-data/

·        IT Pro, European Commission confirms data breach as ShinyHunters group claims responsibility

o   https://www.itpro[.]com/security/data-breaches/european-commission-confirms-data-breach-as-shinyhunters-group-claims-responsibility

Threat Tradecraft and Intrusion Patterns

·        TechCrunch, European cyber agency blames hacking gangs for massive data breach and leak

o   https://techcrunch[.]com/2026/04/03/europes-cyber-agency-blames-hacking-gangs-for-massive-data-breach-and-leak/

·        Cybernews, What’s inside ShinyHunters’ European Commission data breach

o   https://cybernews[.]com/security/european-commission-data-breach-shinyhunters/