[APT] Iranian State-Aligned Identity Intrusion Campaign

Report Type
APT Threat Intelligence Report

Threat Category
Iranian State-Aligned Identity Intrusion and Disruption

Assessment Date
April 06, 2026

Primary Impact Domain
Enterprise Identity Security and Internet-Facing Service Resilience

BLUF

Iranian state-aligned cyber activity presents a material business risk through scalable credential compromise and coordinated service disruption capable of impacting operational continuity and customer-facing systems. The technical cause is a phishing-driven credential acquisition model combined with authentication abuse that enables adversaries to operate within legitimate identity workflows, bypassing traditional intrusion detection mechanisms. The current threat posture reflects mature, behavior-driven tradecraft that does not rely on software vulnerabilities, allowing rapid targeting across enterprises with minimal dependency on environment-specific conditions. Organizations must immediately prioritize identity-centric detection, enforce comprehensive multi-factor authentication coverage, and implement cross-telemetry correlation to identify credential misuse early and prevent escalation.

‍ ‍

Executive Risk Translation
Credential misuse is the primary entry vector, meaning organizations without real-time identity anomaly detection are exposed to unauthorized access and downstream operational disruption.

‍ ‍

S3 Why This Matters Now

‍ ‍

This activity is operationally significant because it enables adversaries to scale access without reliance on vulnerabilities, eliminating dependency on exploit development and patch cycles.

‍ ‍

Phishing-driven credential acquisition combined with authentication abuse allows adversaries to bypass perimeter defenses and operate within legitimate identity activity, reducing detection likelihood and increasing dwell time.

‍ ‍

Observed activity demonstrates concurrent credential targeting and opportunistic service disruption, increasing the probability of simultaneous unauthorized access and operational impact within enterprise environments.

‍ ‍

Organizations lacking identity baselining, consistent multi-factor authentication enforcement, and cross-telemetry correlation are disproportionately exposed to early-stage compromise and delayed detection.

‍ ‍

S4 Key Judgments

‍ ‍

·        Iranian state-aligned activity prioritizes credential acquisition over exploit-based intrusion, enabling scalable and repeatable enterprise targeting (T1566 – Phishing, T1078 – Valid Accounts)

‍ ‍

·        Detection effectiveness is constrained in environments lacking identity-centric correlation across email, authentication, endpoint, and network telemetry

‍ ‍

·        Password spraying and distributed authentication abuse are persistent access mechanisms against externally exposed identity services (T1110 – Brute Force)

‍ ‍

·        Service disruption activity may coincide with credential-based access, increasing the likelihood of operational impact (T1498 – Network Denial of Service)

‍ ‍

·        Organizations without identity baselining and behavioral anomaly detection capabilities will experience delayed detection following credential compromise

‍ ‍

S5 Executive Risk Summary

‍ ‍

This threat creates elevated enterprise risk through unauthorized use of valid credentials, enabling adversaries to operate within normal identity activity and delay detection.

‍ ‍

Risk exposure is driven by the adversary’s ability to authenticate using valid credentials, enabling unauthorized access to persist within normal user activity patterns and reducing detection probability.

‍ ‍

Operational impact may include unauthorized access to enterprise systems, degradation of service availability, and disruption to customer-facing operations.

‍ ‍

Risk exposure increases in environments with externally accessible authentication services, inconsistent multi-factor authentication enforcement, and limited visibility into user activity across devices and network interactions.

‍ ‍

S6 Executive Cost Summary

‍ ‍

This cost analysis was developed by the CyberDax team using expert judgment and assisted analytical tools to support clarity and consistency.

‍ ‍

·        Low Impact
$50,000 – $200,000
Isolated credential compromise affecting a limited number of user accounts with rapid detection and containment, requiring targeted identity reset, session invalidation, and minimal operational disruption

‍ ‍

·        Moderate Impact
$200,000 – $900,000
Credential compromise across multiple users with delayed detection, requiring enterprise-wide credential resets, authentication system validation, incident response coordination, and partial disruption to business operations

‍ ‍

·        High Impact
$900,000 – $3,000,000+
Widespread credential compromise combined with sustained unauthorized access or service disruption, requiring full identity infrastructure remediation, extended incident response, operational downtime, and recovery of customer-facing systems

‍ ‍

S6A Key Cost Drivers

‍ ‍

·        Scope and privilege level of compromised user accounts

‍ ‍

·        Duration of unauthorized access prior to detection and containment

‍ ‍

·        Extent of service disruption impacting business operations

‍ ‍

·        Complexity of identity remediation and authentication system validation

‍ ‍

·        Dependency on externally exposed authentication and service infrastructure

‍ ‍

S6B Compliance and Risk Context

‍ ‍

Compliance Exposure Indicator

‍ ‍

Credential compromise and unauthorized access to enterprise systems may trigger regulatory reporting obligations under data protection, identity security, and service availability requirements where user data or operational continuity is affected.

‍ ‍

Risk Register Entry

‍ ‍

·        Risk Name
Credential-Based Unauthorized Access and Service Disruption

‍ ‍

·        Risk Description
Credential compromise enables unauthorized access to enterprise systems and may coincide with service disruption, resulting in operational impact and regulatory exposure

‍ ‍

·        Risk Category
Identity Security and Service Availability

‍ ‍

·        Likelihood
High

‍ ‍

·        Impact
Moderate to High

‍ ‍

Annualized Risk Exposure

‍ ‍

Annualized exposure reflects repeated campaign activity leveraging scalable credential-based intrusion methods, with recurrence probability driven by widespread phishing targeting and externally exposed authentication services.

‍ ‍

S7 Risk Drivers

‍ ‍

Risk drivers represent the primary conditions that increase the likelihood and impact of this threat activity within enterprise environments.

‍ ‍

·        Reliance on identity-based access without behavioral anomaly detection or identity monitoring

‍ ‍

·        Exposure of authentication services to the internet without sufficient protection against credential abuse and distributed login attempts

‍ ‍

·        Incomplete enforcement of multi-factor authentication across user accounts and access pathways

‍ ‍

·        Lack of correlation between email interaction, authentication activity, and endpoint or network behavior

‍ ‍

·        High dependency on externally accessible services for business operations

‍ ‍

S8 Bottom Line for Executives

‍ ‍

This threat is driven by the misuse of legitimate authentication mechanisms rather than system compromise, making identity the primary control point for detection and prevention.

‍ ‍

Organizations must prioritize identity-centric monitoring, enforce strong authentication controls, and implement cross-telemetry correlation to detect credential misuse before escalation occurs.

‍ ‍

Failure to align detection capabilities with identity-based threat activity will result in delayed detection and increased operational impact.

‍ ‍

S9 Board-Level Takeaway

‍ ‍

This threat reflects a structural shift toward identity-based intrusion, where adversaries achieve access without breaching traditional security boundaries.

‍ ‍

Board-level oversight should prioritize investment in identity security controls, including multi-factor authentication enforcement, behavioral detection capabilities, and cross-system visibility to ensure early identification of unauthorized access.

‍ ‍

Sustained underinvestment in identity security will result in persistent exposure to credential-based intrusion and increased likelihood of operational disruption affecting business continuity and stakeholder trust.

S10 Threat Overview

‍ ‍

This activity reflects Iranian state-aligned cyber operations conducted in the context of active geopolitical conflict involving the United States and its allies, with cyber activity functioning as a parallel instrument of retaliation, coercion, and strategic pressure.

‍ ‍

The campaign relies on phishing-driven credential harvesting and authentication abuse to obtain valid account access, enabling adversaries to operate within legitimate identity workflows and bypass traditional intrusion detection mechanisms.

‍ ‍

Operational objectives include unauthorized access to enterprise systems, intelligence collection, and disruption of services supporting U.S.-aligned economic, technological, and infrastructure ecosystems.

‍ ‍

The threat is characterized by global reach, scalable targeting, and minimal dependency on technical vulnerabilities, allowing rapid execution across enterprise environments.

‍ ‍

S11 Campaign Activity and Timeline

‍ ‍

Observed activity reflects persistent cyber operations aligned with ongoing geopolitical escalation between Iran and the United States and its allies.

‍ ‍

‍ ‍

Campaign intensity increases during periods of heightened military or political tension, with cyber activity functioning as a responsive and scalable mechanism for retaliation and signaling.

‍ ‍

‍ ‍

Campaign execution consistently chains targeted phishing, credential acquisition, and authentication abuse across multiple organizations in parallel to maximize access during escalation periods.

‍ ‍

‍ ‍

Operations are continuous but surge-driven, with escalation events correlating to increased targeting breadth, higher activity volume, and elevated likelihood of concurrent disruption activity.

‍ ‍

S12 Initial Access Vector

‍ ‍

Primary initial access is achieved through phishing-driven credential harvesting (T1566 – Phishing), including:

‍ ‍

·        Emails containing links to credential harvesting pages designed to replicate legitimate authentication portals

‍ ‍

·        Use of spoofed or lookalike domains aligned with enterprise services to increase user trust and interaction likelihood

‍ ‍

·        Targeting of privileged, high-value, or access-bearing enterprise users with exposure to externally accessible authentication services

‍ ‍

‍ ‍

Secondary access mechanisms include distributed authentication attempts such as password spraying against externally accessible identity services (T1110 – Brute Force).

‍ ‍

This access model enables adversaries to pursue strategic enterprise targets across global environments without dependency on software vulnerabilities or patch status.

‍ ‍

S13 Exploitability and Exposure Assessment

‍ ‍

This threat model is independent of exploitable software vulnerabilities, resulting in broad and immediate exposure across organizations regardless of patch posture.

‍ ‍

Exposure is driven by:

‍ ‍

·        User susceptibility to phishing and credential harvesting

‍ ‍

·        Availability of externally exposed authentication services

‍ ‍

·        Inconsistent enforcement of multi-factor authentication

‍ ‍

·        Lack of identity behavior monitoring and anomaly detection

‍ ‍

Because access is obtained through valid credentials, risk cannot be reduced through vulnerability remediation and instead requires identity-centric defensive controls.

‍ ‍

S14 Sectors / Countries Affected

‍ ‍

Sectors Affected

‍ ‍

·        Government and public sector organizations

‍ ‍

·        Critical infrastructure operators, including energy, water, transportation, and communications systems

‍ ‍

·        Defense industrial base organizations and entities supporting military, intelligence, or national security functions

‍ ‍

·        Technology and telecommunications providers supporting cloud, AI, communications, and digital platform infrastructure

‍ ‍

·        Financial services organizations supporting global economic systems

‍ ‍

·        Industrial, logistics, and supply chain organizations supporting U.S. or allied operations

‍ ‍

Countries Affected

‍ ‍

Targeting is globally distributed but strategically prioritized based on geopolitical alignment and operational relevance.

‍ ‍

Primary targeting includes:

‍ ‍

·        United States

‍ ‍

·        Israel

‍ ‍

·        NATO member states and key allied nations

‍ ‍

·        Middle East regions with U.S. or allied military, diplomatic, or economic presence

‍ ‍

Secondary targeting includes:

‍ ‍

·        Global enterprises operating within or supporting U.S. or allied ecosystems

‍ ‍

·        Multinational organizations with supply chain, infrastructure, defense-adjacent, or technology dependencies linked to primary targets

‍ ‍

Global enterprises are treated as intentional targets when they support or enable U.S. or allied strategic interests, rather than as incidental victims.

‍ ‍

S15 Adversary Capability Profiling

‍ ‍

Adversary capability reflects a mature and strategically aligned operational model centered on identity-based intrusion and scalable targeting.

‍ ‍

Skill Level

‍ ‍

Moderate to high, with demonstrated capability in large-scale phishing operations, authentication abuse, and coordinated multi-target campaigns

‍ ‍

Infrastructure Maturity

‍ ‍

Flexible and rapidly deployable infrastructure, including short-lived phishing domains and distributed authentication sources designed to evade detection

‍ ‍

Scalability

‍ ‍

High, enabled by automation of phishing delivery and distributed access attempts across global targets

‍ ‍

Operational Adaptability

‍ ‍

Strong, with the ability to rapidly adjust targeting priorities, infrastructure, and campaign focus based on geopolitical developments

‍ ‍

Escalation Potential

‍ ‍

High, with demonstrated ability to expand from credential compromise to broader operational disruption aligned with strategic objectives

‍ ‍

S16 Targeting Probability Assessment

‍ ‍

Targeting likelihood is driven by geopolitical alignment, identity exposure, and operational value to U.S. or allied systems.

‍ ‍

High Probability Targets

‍ ‍

Organizations directly supporting U.S. or allied government operations, critical infrastructure, defense functions, or strategic technology capabilities, particularly those with exposed authentication services

‍ ‍

Moderate Probability Targets

‍ ‍

Enterprises with indirect alignment to U.S. or allied interests or participation in global supply chains, with partial identity security controls

‍ ‍

Lower Probability Targets

‍ ‍

Organizations with limited geopolitical relevance, strong identity security controls, enforced multi-factor authentication, and comprehensive behavioral monitoring

‍ ‍

Targeting is strategically prioritized rather than random, with global enterprises included based on alignment and operational relevance.

‍ ‍

S17 MITRE ATT&CK Chain Flow Mapping

‍ ‍

The attack chain is structured around identity compromise and authentication abuse rather than exploit-driven intrusion.

‍ ‍

Stage 1

‍ ‍

·       User Targeting and Phishing Delivery

‍ ‍

o   Adversaries deliver phishing content designed to induce user interaction with malicious links or credential harvesting pages (T1566 – Phishing)

‍ ‍

Stage 2

‍ ‍

·       Credential Acquisition

‍ ‍

o   User interaction with adversary-controlled phishing infrastructure results in capture of valid enterprise credentials (T1566 – Phishing)

‍ ‍

Stage 3

‍ ‍

·       Authentication Abuse

‍ ‍

o   Adversaries attempt access using harvested credentials or conduct distributed authentication attempts against exposed identity services

‍ ‍

§  T1078 – Valid Accounts

‍ ‍

§  T1110 – Brute Force

‍ ‍

Stage 4

‍ ‍

·       Initial Access via Valid Accounts

‍ ‍

o   Successful authentication enables adversaries to access enterprise environments through legitimate identity pathways without software exploitation

‍ ‍

§  T1078 – Valid Accounts

‍ ‍

Stage 5

‍ ‍

·       Post-Authentication Discovery

‍ ‍

o   Adversaries may enumerate accessible accounts, services, or resources depending on objectives and target environment

‍ ‍

§  T1087 – Account Discovery

‍ ‍

Stage 6

‍ ‍

·       Persistence Through Continued Credential or Session Use

‍ ‍

o   Adversaries may maintain access through continued use of compromised credentials or active sessions depending on detection timing and defensive response

‍ ‍

§  T1078 – Valid Accounts

‍ ‍

Stage 7

‍ ‍

·       Operational Impact and Strategic Disruption

‍ ‍

o   Adversaries may conduct service disruption or availability degradation aligned with conflict-driven retaliation objectives to impose operational or economic impact

‍ ‍

§  T1498 – Network Denial of Service

‍ ‍

‍ ‍

This chain reflects a behavior-driven intrusion model aligned with conflict-driven cyber operations focused on access, pressure, and disruption rather than opportunistic exploitation.

‍ ‍

S18 Attack Path Narrative (Signal-Aligned Execution Flow)

‍ ‍

This attack path reflects a conflict-aligned intrusion model where adversaries deliberately target enterprise environments supporting U.S. and allied interests to enable intelligence collection, operational disruption, and strategic pressure.

‍ ‍

Execution begins with targeted phishing campaigns directed at privileged and access-bearing users within strategically relevant organizations. Targeting is selective and aligned to geopolitical objectives rather than broad distribution.

‍ ‍

Phishing content directs users to credential harvesting infrastructure designed to replicate enterprise authentication services, enabling credential capture without reliance on exploit-based techniques.

‍ ‍

Following credential acquisition, adversaries initiate authentication attempts against externally exposed identity services using harvested credentials, supplemented where necessary by distributed password spraying to expand access across prioritized targets.

‍ ‍

Successful authentication enables entry through legitimate identity pathways, allowing activity to blend with normal user behavior and reduce detection probability.

‍ ‍

Post-authentication activity remains controlled and purpose-driven, focused on identifying accessible systems, user privileges, and operationally relevant resources while maintaining behavioral consistency.

‍ ‍

Persistence is sustained through continued credential use or session reuse, enabling ongoing access without triggering identity or endpoint-based controls.

‍ ‍

During escalation conditions, adversaries transition to disruption operations targeting internet-facing services associated with prioritized organizations to impose operational degradation and economic pressure.

‍ ‍

S19 Attack Chain Risk Amplification Summary

‍ ‍

This attack model amplifies risk through alignment of intrusion activity with geopolitical objectives, increasing targeting precision and potential impact.

‍ ‍

Credential-based access bypasses traditional security controls, enabling immediate execution across globally distributed targets without reliance on vulnerabilities or system misconfiguration.

‍ ‍

Detection failure risk is driven by adversary activity blending into legitimate identity workflows, requiring correlated visibility across email delivery, authentication events, endpoint execution, and network communication to identify compromise.

‍ ‍

Selective targeting of high-value organizations increases the likelihood that compromised credentials provide access to sensitive systems, critical infrastructure, or operational environments.

‍ ‍

During escalation periods, the combination of credential compromise and disruption activity creates a dual-impact condition in which adversaries maintain access while degrading service availability across targeted environments.

‍ ‍

Organizations lacking identity baselining, behavioral analytics, and cross-telemetry correlation face increased likelihood of delayed detection, prolonged access, and amplified operational impact.

S20 Tactics, Techniques, and Procedures

‍ ‍

Adversary tradecraft is centered on identity compromise, authentication abuse, and strategic targeting of U.S. and allied organizations.

‍ ‍

T1566 – Phishing
Used to deliver targeted credential harvesting campaigns against privileged users within strategically relevant organizations, with infrastructure engineered to replicate enterprise authentication services and maximize credential capture

‍ ‍

T1110 – Brute Force
Used as distributed password spraying against externally exposed authentication services to expand access across prioritized targets where credential harvesting alone is insufficient

‍ ‍

T1078 – Valid Accounts
Used to authenticate into enterprise environments using compromised credentials, enabling sustained access through legitimate identity workflows to systems of operational relevance

‍ ‍

T1087 – Account Discovery
Used post-authentication to identify accessible accounts, roles, and systems that provide access to sensitive or operationally significant resources

‍ ‍

T1498 – Network Denial of Service
Used during escalation conditions to disrupt availability of internet-facing services associated with targeted organizations, amplifying operational and economic impact

‍ ‍

These techniques are executed in a coordinated manner to enable scalable access, sustained presence, and disruption aligned with conflict-driven objectives.

‍ ‍

S20A Adversary Tradecraft Summary

‍ ‍

Adversary tradecraft operates as an identity-centric intrusion model designed to achieve access, persistence, and disruption without reliance on software exploitation.

‍ ‍

Operations prioritize selective targeting of privileged users and strategically relevant organizations aligned with U.S. and allied interests.

‍ ‍

Execution relies on credential compromise to establish low-visibility access through legitimate authentication pathways, followed by controlled expansion to identify and maintain access to systems of operational value.

‍ ‍

Tradecraft maintains persistent access while retaining the capability to initiate disruption operations during escalation conditions.

‍ ‍

This model enables scalable targeting, rapid adaptation to geopolitical developments, and sustained operational pressure against prioritized environments without dependency on exploit development.

‍ ‍

S21 Detection Strategy Overview

‍ ‍

Detection Philosophy

‍ ‍

This threat activity is driven by credential acquisition and misuse at scale, enabled by phishing and authentication abuse rather than exploit-dependent intrusion. The adversary’s effectiveness relies on blending malicious authentication into legitimate enterprise identity activity, making identity-layer detection the primary control point.

‍ ‍

Detection must be anchored in correlated behavioral signals across three primary telemetry pillars:

‍ ‍

·        Email security gateway telemetry

‍ ‍

·        Endpoint / EDR process telemetry

‍ ‍

·        DNS / web proxy network telemetry

‍ ‍

No single telemetry source provides sufficient fidelity. Early detection depends on linking user-targeting activity, authentication anomalies, and post-authentication behavior into a unified sequence.

‍ ‍

Detection Approach

‍ ‍

Detection must focus on time-bound correlation of identity and user-interaction events, specifically the transition from phishing exposure to credential use.

‍ ‍

Required detection sequence:

‍ ‍

·        Delivery of phishing content or user interaction with embedded links or attachments

‍ ‍

·        Authentication attempts from atypical source attributes, including unfamiliar IP ranges, geolocation anomalies, or abnormal session patterns

‍ ‍

·        Successful authentication followed by first-time access behavior, including new device usage, new application access, or abnormal access timing

‍ ‍

·        Endpoint activity associated with newly established sessions, including browser-based access or token reuse patterns

‍ ‍

·        Outbound network communication to recently registered or low-prevalence domains associated with credential harvesting infrastructure

‍ ‍

Detection confidence is highest when these behaviors occur in close temporal proximity and are tied to the same user identity.

‍ ‍

Detection Priorities

‍ ‍

Detection engineering must prioritize behaviors that indicate credential targeting and post-authentication misuse, with emphasis on:

‍ ‍

·        User exposure to phishing content and interaction events (T1566 – Phishing)

‍ ‍

·        Authentication anomalies indicating credential use outside established behavioral baselines (T1078 – Valid Accounts)

‍ ‍

·        Repeated authentication failures or distributed login attempts consistent with password spraying (T1110 – Brute Force)

‍ ‍

·        Access to internet-facing services following anomalous authentication, indicating potential exploitation of exposed applications (T1190 – Exploit Public-Facing Application)

‍ ‍

·        Sustained or abnormal inbound traffic patterns affecting availability of public services (T1498 – Network Denial of Service)

‍ ‍

Priority weighting must favor identity compromise indicators over infrastructure-based indicators, as credential misuse provides earlier and more reliable detection opportunities.

‍ ‍

Detection Challenges

‍ ‍

·        Use of valid credentials eliminates many traditional intrusion indicators

‍ ‍

·        Phishing infrastructure is rapidly deployed and abandoned, limiting reuse of indicators

‍ ‍

·        Authentication anomalies may appear low-signal without established behavioral baselines

‍ ‍

·        Distributed attack patterns reduce the visibility of brute force and spraying activity at single control points

‍ ‍

·        High-volume legitimate traffic can obscure early-stage disruption activity

‍ ‍

Strategic Detection Insight

‍ ‍

Organizations that prioritize:

‍ ‍

·        IOC-driven blocking

‍ ‍

·        Static signature detection

‍ ‍

will detect this activity late or not at all, particularly after credential compromise.

‍ ‍

‍ ‍

Organizations that implement:

‍ ‍

·        Identity behavior baselining

‍ ‍

·        Correlation of email interaction, authentication events, and endpoint activity

‍ ‍

·        Monitoring of first-time or abnormal access patterns

‍ ‍

will detect this activity at the point of credential misuse, significantly reducing attacker dwell time and limiting escalation potential.

‍ ‍

S22 Primary Detection Signals

‍ ‍

Email Security Gateway Telemetry Signals

‍ ‍

Detection signals must focus on user-targeting activity and phishing interaction indicators, which represent the earliest observable stage of this threat.

‍ ‍

·        Inbound emails containing embedded links or attachments originating from newly registered or low-reputation domains

‍ ‍

·        Emails with mismatched sender identity attributes, including spoofed domains or anomalous reply-to addresses

‍ ‍

·        User interaction events with embedded links, including click-through activity to external domains

‍ ‍

·        Delivery of emails containing credential harvesting themes, including login prompts or account verification requests

‍ ‍

·        Multiple users receiving similar phishing content within a constrained time window

‍ ‍

These signals provide initial access visibility and must be correlated with downstream authentication activity.

‍ ‍

Endpoint / EDR Process Telemetry Signals

‍ ‍

Endpoint telemetry must capture post-interaction behavior and session establishment activity, particularly following successful authentication events.

‍ ‍

·        First-time login sessions on endpoints not previously associated with the user identity

‍ ‍

·        New browser process activity immediately following email interaction events

‍ ‍

·        Access to authentication portals or login pages via endpoint browser processes

‍ ‍

·        Session establishment without corresponding historical device or process patterns

‍ ‍

·        Token reuse or session persistence indicators without expected re-authentication behavior

‍ ‍

These signals provide confirmation of user interaction and session initiation, bridging initial access to credential misuse.

‍ ‍

DNS / Web Proxy Network Telemetry Signals

‍ ‍

Network telemetry must identify communication with adversary-controlled infrastructure used for credential harvesting and phishing operations.

‍ ‍

·        DNS queries to recently registered domains or domains with low global prevalence

‍ ‍

·        Outbound connections to domains not previously observed within the enterprise environment

‍ ‍

·        Web requests to domains mimicking authentication services or login portals

‍ ‍

·        Repeated DNS resolution attempts to short-lived or disposable domains

‍ ‍

·        Sudden appearance and disappearance of domains associated with user interaction activity

‍ ‍

These signals provide visibility into external infrastructure leveraged during credential harvesting and initial access.

‍ ‍

Identity and Authentication Telemetry Signals

‍ ‍

Identity telemetry provides the most reliable detection surface for identifying credential misuse and active account compromise.

‍ ‍

·        Successful authentication from unfamiliar IP addresses, geolocations, or network ranges

‍ ‍

·        Login activity from geographically disparate locations within infeasible timeframes

‍ ‍

·        Authentication attempts outside established behavioral baselines, including abnormal access times

‍ ‍

·        First-time access to applications or services not previously used by the identity

‍ ‍

·        Rapid transition from failed authentication attempts to successful login events

‍ ‍

These signals indicate credential compromise and must be prioritized for early detection and response.

‍ ‍

Service Interaction and Availability Signals

‍ ‍

Service-level telemetry must detect abnormal interaction patterns consistent with scanning, exploitation attempts, or disruption activity.

‍ ‍

·        Sudden increases in inbound traffic volume to internet-facing services

‍ ‍

·        Repeated requests to specific endpoints consistent with automated scanning behavior

‍ ‍

·        High-frequency connection attempts from distributed or rotating source IP ranges

‍ ‍

·        Traffic patterns indicative of protocol abuse or resource exhaustion attempts

‍ ‍

·        Degradation of service performance correlated with abnormal inbound traffic patterns

‍ ‍

These signals provide visibility into disruption activity and opportunistic exploitation of exposed services.

‍ ‍

Cross-Pillar Correlation Signals

‍ ‍

High-confidence detection requires correlation of activity across telemetry sources to identify multi-stage attack progression.

‍ ‍

·        Email interaction event followed by anomalous authentication activity within a constrained time window

‍ ‍

·        Authentication anomaly followed by first-time endpoint activity and new network connections

‍ ‍

·        DNS query to a newly observed domain followed by authentication from an unfamiliar source

‍ ‍

·        Multiple users interacting with similar phishing content followed by distributed authentication anomalies

‍ ‍

·        Authentication anomalies occurring alongside increased access to sensitive services or abnormal resource interaction

‍ ‍

These correlations represent coordinated attack behavior and significantly increase detection confidence while reducing false positives.

‍ ‍

S23 Telemetry Requirements

‍ ‍

Email Security Gateway Telemetry Requirements

‍ ‍

Effective detection requires detailed visibility into email delivery, message attributes, and user interaction events associated with phishing activity.

‍ ‍

·        Full email header logging, including sender domain, reply-to address, originating IP, and authentication results (SPF, DKIM, DMARC)

‍ ‍

·        Message metadata capturing attachment presence, embedded URLs, and message classification

‍ ‍

·        URL extraction and rewriting visibility for embedded links within email content

‍ ‍

·        User interaction telemetry, including link click events and attachment execution indicators

‍ ‍

·        Campaign-level visibility enabling identification of similar messages delivered to multiple users within a defined timeframe

‍ ‍

Without user interaction telemetry and URL visibility, early-stage phishing detection is significantly degraded.

‍ ‍

Endpoint / EDR Process Telemetry Requirements

‍ ‍

Endpoint telemetry must provide process-level and session-level visibility to identify post-interaction behavior and session establishment activity.

‍ ‍

·        Process creation logs with parent-child relationships, including browser processes and spawned authentication sessions

‍ ‍

·        User session tracking, including login events tied to specific endpoints and devices

‍ ‍

·        Browser activity visibility, including access to external domains and authentication portals

‍ ‍

·        Device association data linking user identities to known and previously used endpoints

‍ ‍

·        Token and session handling visibility to detect session persistence or reuse

‍ ‍

Lack of process lineage or session visibility limits the ability to confirm user interaction and correlate authentication activity to endpoint behavior.

‍ ‍

DNS / Web Proxy Network Telemetry Requirements

‍ ‍

Network telemetry must provide domain-level and connection-level visibility to identify communication with adversary-controlled infrastructure.

‍ ‍

·        DNS query logging, including domain name, query timestamp, and requesting host identity

‍ ‍

·        Domain enrichment data, including domain age, registration patterns, and global prevalence

‍ ‍

·        Web proxy logs capturing outbound HTTP and HTTPS requests, including destination domains and URLs

‍ ‍

·        TLS inspection capability to identify access to credential harvesting pages over encrypted channels

‍ ‍

·        Historical domain resolution tracking to identify short-lived or disposable infrastructure

‍ ‍

Without DNS and web request visibility, identification of phishing infrastructure and external communication patterns is significantly constrained.

‍ ‍

Identity and Authentication Telemetry Requirements

‍ ‍

Identity telemetry is critical for detecting credential misuse and must provide detailed visibility into authentication behavior and access patterns.

‍ ‍

·        Authentication logs capturing successful and failed login attempts, including timestamp, source IP, and geolocation data

‍ ‍

·        User identity context, including role, normal access patterns, and historical login behavior

‍ ‍

·        Multi-factor authentication (MFA) event logs, including prompts, approvals, and failures

‍ ‍

·        Application access logs indicating services accessed following authentication events

‍ ‍

·        Session metadata, including device identifiers, session duration, and authentication method

‍ ‍

Without enriched identity context and authentication detail, detection of anomalous access and credential misuse is unreliable.

‍ ‍

Service Interaction and Availability Telemetry Requirements

‍ ‍

Service-level telemetry must capture interaction patterns with internet-facing systems to detect scanning, exploitation attempts, and disruption activity.

‍ ‍

·        Web server and application logs capturing request frequency, endpoints accessed, and response codes

‍ ‍

·        Traffic volume metrics for internet-facing services, including baseline and deviation tracking

‍ ‍

·        Source IP distribution data to identify distributed access patterns or scanning behavior

‍ ‍

·        API and service interaction logs capturing abnormal request sequences or access attempts

‍ ‍

·        Performance and availability metrics indicating service degradation or abnormal load conditions

‍ ‍

Without service-level visibility and baseline comparison, detection of disruption activity and exploitation attempts is limited.

‍ ‍

Cross-Pillar Correlation Telemetry Requirements

‍ ‍

Effective detection depends on the ability to correlate telemetry across sources and enrich events with contextual intelligence.

‍ ‍

·        Centralized logging or SIEM capability enabling correlation across email, endpoint, network, and identity telemetry

‍ ‍

·        Time synchronization across all telemetry sources to support accurate sequence-based detection

‍ ‍

·        Asset and identity mapping to link user accounts, devices, and network activity

‍ ‍

·        Threat intelligence enrichment, including domain reputation, IP reputation, and infrastructure classification

‍ ‍

·        Historical baseline data to support behavioral anomaly detection across users, devices, and services

‍ ‍

Without cross-source correlation and enrichment, detection remains fragmented and high-confidence multi-stage detection is not achievable.

S24 Detection Opportunities and Gaps

‍ ‍

Email Security Gateway Detection Opportunities and Gaps

‍ ‍

Detection opportunities are strongest at the point of phishing delivery and user interaction; gaps emerge when interaction visibility or message-level context is incomplete.

‍ ‍

·        Detected Opportunity
Email delivery monitoring enables identification of phishing campaigns targeting multiple users within a defined timeframe

‍ ‍

·        Detected Opportunity
URL extraction and rewriting provides visibility into embedded link destinations prior to user interaction

‍ ‍

·        Partially Detected
User interaction events are detectable only when click tracking or attachment execution telemetry is enabled

‍ ‍

·        Gap
Lack of visibility into encrypted or external email channels limits detection of phishing delivered outside monitored gateways

‍ ‍

·        Gap
Absence of campaign-level aggregation reduces ability to identify distributed phishing attempts across user populations

‍ ‍

Endpoint / EDR Detection Opportunities and Gaps

‍ ‍

Detection opportunities exist in identifying post-interaction behavior and session establishment; gaps arise when process lineage or user-session linkage is incomplete.

‍ ‍

·        Detected Opportunity
Process creation telemetry enables identification of browser-based access following phishing interaction

‍ ‍

·        Detected Opportunity
Device-user association allows detection of first-time endpoint usage by a compromised identity

‍ ‍

·        Partially Detected
Browser activity visibility is limited when endpoint telemetry does not capture full URL or session context

‍ ‍

·        Gap
Lack of token-level visibility prevents reliable detection of session reuse or persistence mechanisms

‍ ‍

·        Gap
Incomplete process lineage reduces ability to link user interaction to subsequent authentication or access behavior

‍ ‍

DNS / Web Proxy Detection Opportunities and Gaps

‍ ‍

Detection opportunities focus on identifying communication with adversary-controlled infrastructure; gaps emerge when domain context or encrypted traffic visibility is limited.

‍ ‍

·        Detected Opportunity
DNS logging enables identification of newly registered or low-prevalence domains associated with phishing infrastructure

‍ ‍

·        Detected Opportunity
Web proxy visibility allows detection of outbound requests to suspicious or previously unseen domains

‍ ‍

·        Partially Detected
Domain classification accuracy is dependent on enrichment data quality and timeliness

‍ ‍

·        Gap
Lack of TLS inspection limits visibility into credential harvesting activity over encrypted channels

‍ ‍

·        Gap
Absence of historical domain tracking reduces ability to identify short-lived or disposable infrastructure patterns

‍ ‍

Identity and Authentication Detection Opportunities and Gaps

‍ ‍

Detection opportunities are strongest at the point of credential misuse; gaps arise when identity baselining or contextual enrichment is insufficient.

‍ ‍

·        Detected Opportunity
Authentication logs enable identification of anomalous login behavior, including unfamiliar locations and access patterns

‍ ‍

·        Detected Opportunity
MFA telemetry provides visibility into abnormal authentication flows and user interaction anomalies

‍ ‍

·        Partially Detected
Behavioral anomaly detection depends on availability of historical user baseline data

‍ ‍

·        Gap
Lack of identity enrichment limits ability to distinguish between legitimate and malicious access patterns

‍ ‍

·        Gap
Absence of session context reduces visibility into post-authentication activity and lateral access behavior

‍ ‍

Service Interaction and Availability Detection Opportunities and Gaps

‍ ‍

Detection opportunities exist in identifying abnormal service interaction patterns; gaps emerge when baseline traffic behavior and distribution analysis are not established.

‍ ‍

·        Detected Opportunity
Traffic volume monitoring enables identification of sudden spikes affecting service availability

‍ ‍

·        Detected Opportunity
Request pattern analysis allows detection of automated scanning or exploitation attempts

‍ ‍

·        Partially Detected
Distributed attack patterns may evade detection when analyzed at a single source or service level

‍ ‍

·        Gap
Lack of baseline traffic modeling limits ability to distinguish between legitimate load increases and malicious activity

‍ ‍

·        Gap
Incomplete source attribution reduces visibility into coordinated or distributed disruption attempts

‍ ‍

Cross-Pillar Correlation Detection Opportunities and Gaps

‍ ‍

Detection opportunities are maximized when telemetry sources are correlated; gaps arise when data remains siloed or time alignment is inconsistent.

‍ ‍

·        Detected Opportunity
Correlation of email interaction and authentication anomalies enables early detection of credential compromise

‍ ‍

·        Detected Opportunity
Linking identity activity with endpoint and network telemetry provides high-confidence detection of multi-stage attacks

‍ ‍

·        Partially Detected
Correlation accuracy depends on consistent time synchronization and identity mapping across systems

‍ ‍

·        Gap
Lack of centralized correlation capability prevents identification of multi-stage attack sequences

‍ ‍

·        Gap
Inconsistent telemetry ingestion or normalization reduces effectiveness of cross-source analysis

‍ ‍

S25 Ultra-Tuned Detection Engineering Rules

Suricata

Rule 1 — Outbound Credential Submission to Non-Sanctioned Login-Themed Host

MITRE ATT&CK

·        T1566 – Phishing

·        T1078 – Valid Accounts

Purpose
Detect outbound credential submission to a login-themed host that is not an approved enterprise identity provider, representing likely phishing-driven credential harvesting over inspectable web traffic.

Classification
Alert-capable supporting detection

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        Suricata deployed where outbound HTTP or decrypted proxy traffic is visible

·        http.request_body inspection enabled with request body limits sized to inspect credential forms

·        Maintained allowlist dataset of sanctioned identity provider exact FQDNs

·        Asset scoping that accurately reflects internal client address space

Enforcement Method

·        Requires a single HTTP transaction to satisfy all of the following:

o   POST request method

o   Destination host not present in sanctioned identity provider dataset

o   Login-themed host naming

o   Login-themed URI pathing

o   Request body containing both user-identifier and password-like parameters

·        Alerting is permitted as a standalone Suricata detection because the rule enforces multiple aligned phishing-credential-submission conditions within one observed transaction

Implementation Constraint Notes

·        HTTPS credential posting is only visible if TLS interception, proxy decryption, or equivalent SSL offload is in place

·        Sanctioned identity provider dataset must include all legitimate external login destinations used by the enterprise

·        Custom enterprise SSO paths may require URI regex localization

·        Request body inspection depth must be validated against real production traffic and reverse proxy behavior

·        This rule should not be deployed without dataset scoping and inspection-path validation

Tuning Explanation
This rule is intentionally narrow to reduce noise and enforce behavior-specific logic rather than generic web posting detection. It aligns to the Block 4 requirement to prioritize phishing interaction and credential misuse indicators over static IOC blocking or weak single-signal detections.

Variant Analysis

Covered variants

o   Credential harvesting pages using common login-themed hostnames and paths

o   Credential capture using standard HTML form submission over inspectable HTTP or decrypted HTTPS

o   Common username, email, login, and password parameter naming variants

Variant gaps

o   Direct-to-IP credential harvesting without meaningful host header semantics

o   JavaScript or API-driven credential submission that does not expose expected parameter names

o   Encrypted HTTPS sessions without decryption visibility

o   Mobile app or embedded webview submission patterns that do not resemble standard browser form posts

Required compensating detection

o   Proxy, endpoint, or identity correlation for encrypted, API-based, or application-native credential submission variants

Rule Regret Check

Deployment caution
Requires decrypted HTTP visibility or equivalent proxy-side inspection placement.

Confidence caution
Will miss encrypted credential submission, API-native submission patterns, and variants that do not expose recognizable credential parameters.

Coverage value
High-confidence, low-noise network detection for real credential harvesting behavior when deployed at the correct inspection point with a maintained allowlist.

Production Ready
Yes

Engineering Note
This rule is deployment-ready but requires tenant-side validation of inspection placement, request body visibility, sanctioned identity-provider dataset completeness, and environment-specific login-path tuning. Coverage remains conditional until those checks are completed and validated in live traffic.

System-ready code

alert http $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (
    msg:"CYBERDAX APT IRAN outbound credential submission to non-sanctioned login-themed host";
    flow:established,to_server;
    http.method; content:"POST"; bsize:4;
    http.host; dataset:isnotset,cdx_sanctioned_idp_domains, type string, load cdx_sanctioned_idp_domains.lst;
    http.host; pcre:"/^(?:[^.]+\.){0,4}(?:login|signin|auth|account|verify|mfa|sso|session)[-.]?[a-z0-9-]*\./i";
    http.uri; pcre:"/\/(?:login|signin|auth|account|verify|session|mfa|sso|oauth|saml|secure)(?:[\/\?\=&._-]|$)/Ui";
    http.request_body; pcre:"/(?:^|[&;])(user(?:name)?|email|login|identifier)=[^&]{1,256}(?:&|;).{0,256}(pass(?:word)?|passwd|pwd)=/Pi";
    classtype:policy-violation;
    metadata:attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, mitre_tactic Initial_Access, mitre_tactic Credential_Access, mitre_technique T1566, mitre_technique T1078;
    sid:9002501;
    rev:2;
)

Rule 2 — Suspicious Login-Themed DNS Query Followed by Non-Sanctioned TLS SNI Access

MITRE ATT&CK

·        T1566 – Phishing

·        T1078 – Valid Accounts

Purpose
Detect a client that first queries a suspicious login-themed domain and then initiates a TLS session to a suspicious non-sanctioned login-themed SNI within a constrained time window, indicating likely access to phishing or credential-harvesting infrastructure.

Classification
Alert-capable supporting detection

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        DNS and TLS visibility from the same client-observable sensor vantage point

·        xbits support enabled with sufficient host-tracking capacity

·        Maintained allowlist dataset of sanctioned identity provider exact FQDNs

·        Reliable outbound client attribution from the same endpoint or network segment

Enforcement Method

·        Supporting DNS rule sets an xbit on the source client when that client queries a suspicious login-themed domain not present in the sanctioned allowlist

·        Alerting TLS rule fires only when the same client later establishes a TLS session with a suspicious login-themed non-sanctioned SNI within the configured expiration window

·        Alerting is permitted as a standalone Suricata detection because it enforces a two-stage network sequence from the same source host, but it remains a network precursor detection, not full identity-confirmed compromise

Implementation Constraint Notes

·        This rule tracks on ip_src because the DNS destination is often a resolver, not the final phishing host

·        Exact string parity between DNS query names and TLS SNI values is not assumed; this rule intentionally matches suspicious themed naming on both stages rather than requiring identical domain strings

·        CDN fronting, redirect chains, SNI suppression, Encrypted Client Hello, resolver centralization, or browser privacy features may reduce visibility

·        Xbit expiration should remain short enough to reflect realistic user interaction windows and reduce unrelated follow-on TLS noise

·        Do not oversell this rule as identity-confirming logic; it is a strong network-sequence precursor detector

Tuning Explanation
This rule implements the strongest realistic Suricata-native approximation of the Block 4 requirement to correlate suspicious infrastructure interaction across network events without pretending that Suricata can perform full user-identity correlation. It supports the report’s emphasis on linking phishing interaction indicators to downstream suspicious access behavior within constrained time windows.

Variant Analysis

Covered variants

o   Login-themed phishing infrastructure exposed through observable DNS and visible TLS SNI

o   Domains using common login, sign-in, verify, MFA, SSO, or auth-oriented naming

o   User-driven suspicious infrastructure access patterns observable across DNS then TLS

Variant gaps

o   Direct IP access with no meaningful DNS signal

o   TLS handshakes without visible SNI

o   Encrypted Client Hello or other privacy-preserving TLS features that conceal SNI

o   Access paths where DNS is resolved elsewhere and not visible from the client vantage point

o   Phishing domains that use non-login-themed naming conventions

Required compensating detection

o   Proxy, endpoint, email, or SIEM correlation for no-SNI, DNS-hidden, or non-themed infrastructure variants

Rule Regret Check

Deployment caution
Requires DNS and TLS telemetry from the same client vantage point and sufficient xbit host tracking.

Confidence caution
Will not catch phishing flows that hide SNI, bypass observable DNS from the monitored client path, or use non-login-themed domains.

Coverage value
Strong encrypted-traffic precursor detector for phishing infrastructure access with materially better fidelity than a standalone suspicious TLS hostname alert.

Production Ready
Yes

Engineering Note
This rule is deployment-ready but requires validation of DNS visibility, TLS SNI visibility, xbit host-tracking capacity, and sanctioned identity-provider dataset completeness. Coverage remains conditional until those telemetry dependencies are verified in the monitored environment.

System-ready code

alert dns $HOME_NET any -> $EXTERNAL_NET 53 (
    msg:"CYBERDAX APT IRAN supporting event suspicious login-themed DNS query by client";
    dns.query;
    dataset:isnotset,cdx_sanctioned_idp_domains, type string, load cdx_sanctioned_idp_domains.lst;
    pcre:"/^(?:[^.]+\.){0,4}(?:login|signin|auth|account|verify|mfa|sso|session|okta|adfs|oauth|office365|microsoftonline|entra)[-.]?[a-z0-9-]*\.[a-z]{2,}$/i";
    xbits:set,cdx_suspicious_login_dns,track ip_src,expire 900;
    noalert;
    sid:9002502;
    rev:2;
)

alert tls $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CYBERDAX APT IRAN client accessed suspicious login-themed TLS SNI after matching DNS query";
    flow:established,to_server;
    tls.sni; dataset:isnotset,cdx_sanctioned_idp_domains, type string, load cdx_sanctioned_idp_domains.lst;
    tls.sni; pcre:"/^(?:[^.]+\.){0,4}(?:login|signin|auth|account|verify|mfa|sso|session|okta|adfs|oauth|office365|microsoftonline|entra)[-.]?[a-z0-9-]*\.[a-z]{2,}$/i";
    xbits:isset,cdx_suspicious_login_dns,track ip_src;
    classtype:policy-violation;
    metadata:attack_target Client_Endpoint, deployment Perimeter, signature_severity Major, mitre_tactic Initial_Access, mitre_tactic Credential_Access, mitre_technique T1566, mitre_technique T1078;
    sid:9002503;
    rev:2;
)

Rule 3 — Repeated Authentication POSTs to Protected Public Authentication Endpoints

MITRE ATT&CK

·        T1110 – Brute Force

Purpose
Detect repeated authentication attempts from the same external source to protected internet-facing authentication endpoints, indicating concentrated password spraying or repeated credential-abuse activity.

Classification
Alert-capable

SOC Usage Mode
Alert-capable

Minimum Deployment Requirement

·        Sensor visibility on inbound traffic to internet-facing authentication services

·        Accurate scoping of protected authentication hosts in a maintained dataset

·        Correct client IP visibility relative to reverse proxies, load balancers, and NAT boundaries

·        Threshold tuning based on observed enterprise authentication volume and normal client concentration patterns

Enforcement Method

·        Requires all of the following:

o   External source to internal protected HTTP service

o   POST request method

o   Authentication-themed URI path

o   Destination host present in protected authentication host dataset

o   Repetition threshold exceeded by the same source within a constrained time window

·        Alerting is permitted as a standalone Suricata detection for concentrated auth abuse from one source, but this rule must not be treated as sufficient standalone coverage for distributed low-and-slow spraying across many sources

Implementation Constraint Notes

·        Must be deployed where original client source attribution is preserved or reliably reconstructed

·        Threshold values must be environment-localized to real authentication traffic patterns

·        Reverse proxy, SSO concentrator, WAF, and API gateway architectures may require deployment-point adaptation

·        Full password-spraying coverage requires SIEM or identity-platform aggregation when the attack is distributed across many sources or many low-volume attempts

·        This rule should not be described as full brute-force coverage without that compensating aggregation layer

Tuning Explanation
This rule focuses on repeated authentication attempts to known protected public auth paths rather than generic repeated POST activity, aligning with the Block 4 emphasis on authentication abuse and password spraying as priority detection behaviors. It is intentionally scoped to maximize operational signal at the network boundary while remaining honest about the detection gap for distributed spray campaigns.

Variant Analysis

Covered variants

o   Concentrated password spraying or repeated login attempts from one source to standard web authentication endpoints

o   Repeated access to common login, token, session, SAML, ADFS, and auth API paths

o   Perimeter-observable authentication abuse against protected public services

Variant gaps

o   Distributed low-and-slow spraying across many source IPs

o   Authentication attempts over protocols or services not visible as HTTP POST transactions

o   Mobile, thick-client, API, federated, or proprietary authentication workflows that do not expose the monitored path patterns

o   Passwordless, token-first, or application-native auth variants that bypass observable web login endpoints

Required compensating detection

o   SIEM, identity provider, application log, or cloud control-plane correlation for distributed or non-HTTP authentication abuse variants

Rule Regret Check

Deployment caution
Requires accurate protected-host scoping, preserved client attribution, and environment-specific threshold tuning.

Confidence caution
Best at detecting concentrated abuse from one source and should not be treated as full standalone coverage for distributed password spraying.

Coverage value
High operational value for perimeter detection of repeated authentication abuse against public enterprise login surfaces.

Production Ready
Yes

Engineering Note
This rule is deployment-ready but requires tenant-side validation of protected authentication host scoping, deployment position relative to reverse proxies or load balancers, and threshold calibration against baseline login volume. Coverage remains conditional until those factors are validated in production traffic.

System-ready code

alert http $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (
    msg:"CYBERDAX APT IRAN repeated authentication POSTs to protected public auth endpoint possible password spraying";
    flow:established,to_server;
    http.method; content:"POST"; bsize:4;
    http.host; dataset:isset,cdx_protected_auth_hosts, type string, load cdx_protected_auth_hosts.lst;
    http.uri; pcre:"/\/(?:login|signin|auth|oauth2\/token|oauth\/token|session|saml|adfs|api\/v[0-9]+\/auth)(?:[\/\?\=&._-]|$)/Ui";
    threshold:type threshold,track by_src,count 20,seconds 60;
    classtype:attempted-user;
    metadata:attack_target Server, deployment Perimeter, signature_severity Major, mitre_tactic Credential_Access, mitre_technique T1110;
    sid:9002504;
    rev:2;
)

SentinelOne

Rule 1 — Browser Access to Non-Sanctioned Login Infrastructure

MITRE ATT&CK

·        T1566 – Phishing

·        T1078 – Valid Accounts

Purpose

Detect browser access to login-themed external infrastructure that is not part of sanctioned enterprise authentication flows.

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        Endpoint web request or network telemetry

·        Full browser process coverage

·        Maintained allowlist of sanctioned authentication domains

·        Verified availability of URL or domain fields

Enforcement Method

·        Process is a browser

·        Destination contains login/auth-related patterns

·        Destination is NOT in sanctioned allowlist

Standalone Alerting Justification

Permitted because:

·        Direct endpoint user-driven behavior

·        Multi-condition narrowing (browser + auth pattern + allowlist exclusion)

·        No reliance on external correlation

Implementation Constraint Notes

·        Allowlist quality determines noise level

·        SaaS-heavy environments require broader suppression sets

·        If only domain (not URL) is available, expect reduced precision

Tuning Explanation

This rule is constrained to:

·        Browser-only activity

·        Authentication-themed destinations

·        Known-good exclusion

This prevents generic web browsing alerts and aligns with phishing interaction detection requirements.

Expected Noise Profile

·        Low if allowlist is mature

·        Moderate in dynamic SaaS environments

Variant Analysis

Covered

·        Browser phishing link interaction

·        Fake login page navigation

Gaps

·        Non-browser phishing

·        Legitimate domain compromise

·        API-based credential capture

Compensating Controls

·        Email gateway telemetry

·        DNS/web proxy analysis

Execution Validity Statement

Executable as a SentinelOne STAR rule template; requires tenant validation of:

·        URL/domain field

·        Process field

·        Allowlist implementation

Rule Regret Check

Deployment caution
Requires strong allowlist hygiene.

Confidence caution
Limited by domain/URL visibility and SaaS diversity.

Coverage value

High-confidence early phishing interaction detection.

Production Ready

Conditional

Engineering Note

Deploy in alert mode first. Validate:

·        Noise from legitimate login flows

·        Coverage of enterprise authentication services

·        URL vs domain visibility

System-ready code

event_type = "web_request"
AND lower(src_process_name) IN ("chrome.exe","msedge.exe","firefox.exe","brave.exe")
AND lower(coalesce(url, domain)) RLIKE "(login|signin|auth|verify|account|mfa|sso|session)"
AND lower(coalesce(url, domain)) NOT RLIKE "(^|\\.)okta\\.com|(^|\\.)microsoftonline\\.com|(^|\\.)office\\.com|(^|\\.)duo\\.com"

Rule 2 — Non-Browser Access to Browser Credential / Session Stores

MITRE ATT&CK

·        T1555 – Credentials from Password Stores

·        T1539 – Steal Web Session Cookie

Purpose

Detect non-browser processes accessing browser credential or cookie storage locations.

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        File access telemetry

·        User profile path visibility

·        Suppression list for approved tools

Enforcement Method

·        Process is NOT a browser

·        Process is NOT approved tooling

·        Access to known credential/cookie storage paths

Standalone Alerting Justification

Permitted because:

·        Direct endpoint access to sensitive credential stores

·        No dependency on external telemetry

Implementation Constraint Notes

·        Must suppress:

o   Password managers

o   Migration tools

o   Forensic/admin tools

·        Requires validation of file access event types

Tuning Explanation

Tightly scoped to:

·        Known browser credential paths

·        Non-browser access only

This eliminates generic file-access noise and targets credential theft behavior.

Expected Noise Profile

·        Very low after suppression tuning

Variant Analysis

Covered

·        Credential store access

·        Cookie/session database access

Gaps

·        In-memory theft

·        Browser-internal access

·        Cloud-only session abuse

Compensating Controls

·        Identity provider telemetry

·        Memory inspection tools

Execution Validity Statement

Executable if file access/read events are exposed in tenant; otherwise deploy as hunt-first.

Rule Regret Check

Deployment caution
Requires suppression tuning for legitimate tools.

Confidence caution
Dependent on file access visibility.

Coverage value
Very high-value credential theft detection.

Production Ready

Conditional

Engineering Note

Validate:

·        File read vs open semantics

·        Actual path structures in environment

·        Tool suppression completeness

System-ready code

event_type IN ("file_access","file_open")
AND lower(src_process_name) NOT IN ("chrome.exe","msedge.exe","firefox.exe")
AND lower(src_process_name) NOT IN ("approved-tool.exe")
AND lower(target_file_path) RLIKE "chrome.*login data|chrome.*cookies|edge.*login data|firefox.*logins\\.json|firefox.*cookies"

Rule 3 — Browser-Initiated Execution of Suspicious Child Process

MITRE ATT&CK

·        T1204 – User Execution

·        T1059 – Command and Scripting Interpreter

Purpose

Detect browser-driven execution of suspicious interpreters or LOLBins.

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        Process creation telemetry

·        Parent-child relationship visibility

·        Command-line visibility

Enforcement Method

·        Parent is browser

·        Child is high-risk interpreter

·        Command line contains suspicious execution indicators

Standalone Alerting Justification

Permitted because:

·        Direct endpoint execution chain

·        Strong behavioral signal

Implementation Constraint Notes

·        Must suppress:

o   Known enterprise helper processes

·        Keep interpreter list narrow

Tuning Explanation

Requires BOTH:

·        Suspicious parent-child relationship

·        Suspicious command-line

This significantly reduces noise compared to generic process spawning.

Expected Noise Profile

·        Low after suppression tuning

Variant Analysis

Covered

·        Browser → PowerShell / CMD / script execution

·        Download + execute patterns

Gaps

·        Non-browser execution chains

·        Credential-only phishing

Compensating Controls

·        Email + endpoint correlation

·        SIEM-based sequence detection

Execution Validity Statement

Executable with validated process and command-line fields.

Rule Regret Check

Deployment caution
Requires suppression tuning for legitimate helper processes.

Confidence caution
Does not detect non-execution phishing.

Coverage value
High-value early-stage execution detection.

Production Ready

Conditional

Engineering Note

Deploy in alert mode → validate Storyline patterns → tune suppressions → consider response actions.

System-ready code

event_type = "process_creation"
AND lower(parent_process_name) IN ("chrome.exe","msedge.exe","firefox.exe")
AND lower(process_name) IN ("powershell.exe","cmd.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
AND lower(command_line) RLIKE "(http|https|download|string|encodedcommand|temp)"

Splunk

Rule 1 — Correlated Phishing Interaction → Suspicious Authentication → Suspicious External Login Infrastructure Access

MITRE ATT&CK

·        T1566 – Phishing

·        T1078 – Valid Accounts

Purpose

Detect a user-driven attack chain where phishing interaction is followed by suspicious successful authentication and subsequent access to non-sanctioned login-themed infrastructure.

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Email telemetry with user-linked phishing interaction or alerts

·        Authentication telemetry with:

o   user

o   src_ip

o   action

o   app/service

·        Proxy or endpoint web telemetry with user attribution

·        Lookup datasets:

o   corporate IP ranges

o   VPN egress ranges

o   sanctioned login domains

o   service accounts

Enforcement Method

·        Stage 1: phishing interaction or phishing alert tied to user

·        Stage 2: successful authentication from non-corporate, non-VPN source

·        Stage 3: access to non-sanctioned login-themed destination

·        All stages must occur within bounded time window

Standalone Alerting Justification

Permitted because detection requires three correlated attack stages tied to the same user, eliminating single-signal noise.

Implementation Constraint Notes

·        Requires consistent user normalization across all telemetry sources

·        Proxy or endpoint web logs must map to user identity

·        Sanctioned domain lookup must be accurate and maintained

·        Service accounts must be excluded

·        Time window must remain constrained to prevent unrelated correlation

Tuning Explanation

This rule enforces a strict multi-stage correlation model. It was intentionally designed without transaction to improve performance and auditability while preserving sequence logic.

Expected Noise Profile

·        Low with mature lookups and normalized user mapping

·        Moderate if web telemetry lacks user attribution

Variant Analysis

Covered

·        Phishing → credential use → suspicious infrastructure access

·        Multi-stage identity compromise behavior

Gaps

·        Credential theft without phishing evidence

·        Abuse limited to sanctioned cloud services

·        Weak user attribution environments

Compensating Controls

·        Authentication anomaly rules

·        Endpoint credential/session detection

·        Identity-provider risk detections

Execution Validity Statement

Executable when required fields are normalized and lookup datasets are present and maintained. Customer data dependency is explicitly required.

Rule Regret Check

Deployment caution
Requires cross-source user normalization and lookup accuracy.

Confidence caution
Will miss attack paths lacking phishing or user-attributed web activity.

Coverage value
Very high-confidence, low-noise identity-chain detection.

Production Ready

Yes (with declared customer dependencies)

Engineering Note

Deploy in alert-only mode initially. Validate correlation fidelity, lookup completeness, and timing alignment before enabling automated response.

System-ready code

(
  search index=email
  | eval norm_user=lower(coalesce(user,recipient,mail_to))
  | where isnotnull(norm_user)
  | where action IN ("click","open","visit") OR like(alert_name,"%phish%") OR like(signature,"%malicious URL%")
  | stats earliest(_time) AS phish_time BY norm_user
)
| append [
  search index=auth
  | eval norm_user=lower(user), norm_app=lower(coalesce(app,dest,service))
  | lookup cdx_corporate_ip_ranges ip AS src_ip OUTPUT is_corporate
  | lookup cdx_vpn_egress_ranges ip AS src_ip OUTPUT is_vpn
  | lookup cdx_service_accounts user AS norm_user OUTPUT is_service
  | where action="success" AND isnull(is_corporate) AND isnull(is_vpn) AND isnull(is_service)
  | stats earliest(_time) AS auth_time values(src_ip) AS src_ip values(norm_app) AS app BY norm_user
]
| append [
  search index=proxy
  | eval norm_user=lower(user), norm_domain=lower(coalesce(url_domain,domain))
  | lookup cdx_sanctioned_login_domains domain AS norm_domain OUTPUT is_sanctioned
  | where isnull(is_sanctioned)
  | where match(norm_domain,"(login|signin|auth|verify|account|mfa|sso)")
  | stats earliest(_time) AS infra_time values(norm_domain) AS domain BY norm_user
]
| stats max(phish_time) AS phish_time max(auth_time) AS auth_time max(infra_time) AS infra_time values(src_ip) AS src_ip values(app) AS app values(domain) AS domain BY norm_user
| where isnotnull(phish_time) AND isnotnull(auth_time) AND isnotnull(infra_time)
| where auth_time>=phish_time AND infra_time>=auth_time AND (infra_time-phish_time)<=2700

Rule 2 — External Failure Burst Followed by Successful Access into New Application Context

MITRE ATT&CK

·        T1110 – Brute Force

·        T1078 – Valid Accounts

Purpose

Detect concentrated failed authentication attempts followed by successful access into a new or rarely used application context.

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Authentication telemetry with normalized fields

·        Lookup datasets:

o   corporate IP ranges

o   VPN ranges

o   service accounts

o   user-app baseline

Enforcement Method

·        External source only

·        Failure burst and success within time window

·        Access to application not in baseline

Standalone Alerting Justification

Permitted because detection requires both attack pressure and successful access, plus novelty constraint.

Implementation Constraint Notes

·        Requires mature user-app baseline

·        If baseline weak:

o   restrict to sensitive apps

o   increase thresholds

Expected Noise Profile

·        Low with mature baseline

·        Moderate if baseline incomplete

Execution Validity Statement

Executable when baseline lookup exists and authentication fields are normalized.

Production Ready

Yes (with declared customer dependencies)

System-ready code

search index=auth
| eval norm_user=lower(user), norm_app=lower(coalesce(app,dest,service))
| lookup cdx_corporate_ip_ranges ip AS src_ip OUTPUT is_corporate
| lookup cdx_vpn_egress_ranges ip AS src_ip OUTPUT is_vpn
| where isnull(is_corporate) AND isnull(is_vpn)
| bin span=15m _time
| stats count(eval(action="failure")) AS failures count(eval(action="success")) AS successes BY _time norm_user src_ip norm_app
| where failures>=8 AND successes>=1
| lookup cdx_user_app_baseline user AS norm_user app AS norm_app OUTPUT is_known
| where isnull(is_known)

Rule 3 — Distributed Password Spraying from External Source

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect external password spraying across multiple users from a single source.

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Authentication telemetry

·        Lookup datasets:

o   corporate ranges

o   VPN ranges

o   scanner exclusions

Enforcement Method

·        External source only

·        High user spread

·        Failure volume threshold

·        Severity increases if success occurs

Standalone Alerting Justification

Permitted because multi-user failure behavior is a strong indicator of password spraying.

Expected Noise Profile

·        Low with proper exclusions

Execution Validity Statement

Executable with normalized auth fields and exclusion lookups.

Production Ready

Yes

System-ready code

search index=auth
| eval norm_user=lower(user)
| lookup cdx_corporate_ip_ranges ip AS src_ip OUTPUT is_corporate
| lookup cdx_vpn_egress_ranges ip AS src_ip OUTPUT is_vpn
| lookup cdx_known_auth_scanners ip AS src_ip OUTPUT is_scanner
| where isnull(is_corporate) AND isnull(is_vpn) AND isnull(is_scanner)
| bin span=20m _time
| stats dc(eval(if(action="failure",norm_user,null()))) AS targeted_users count(eval(action="failure")) AS total_failures dc(eval(if(action="success",norm_user,null()))) AS success_users BY _time src_ip
| where targeted_users>=10 AND total_failures>=25

Elastic

Rule 1 — External Password Spraying from Single Source (Primary Detection)

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect password spraying where a single external source attempts authentication across many users.

Elastic Rule Type

Threshold Rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        user.name

·        source.ip

·        event.outcome

·        Exclusion datasets:

o   corporate IP ranges

o   VPN ranges

o   scanner infrastructure

Enforcement Method

·        External source only

·        Distinct user count threshold

·        Failure volume threshold

Standalone Alerting Justification

Permitted because multi-user failure activity from a single external source is a strong and well-established attack signal.

Implementation Constraint Notes

·        Must exclude trusted and internal ranges

·        Must exclude scanners and testing systems

·        Must validate that service-account activity does not distort user counts

Expected Noise Profile

·        Low with proper exclusions

Variant Analysis

Covered

·        Classic password spraying

·        Credential stuffing via single source

Gaps

·        Distributed spray

·        Trusted egress abuse

Execution Validity Statement

Executable with normalized authentication telemetry and maintained exclusion datasets.

Production Ready

Yes

System-ready code

event.category:authentication and event.outcome:failure and source.ip:* and user.name:* and
not cidrmatch(source.ip, "CDX_CORPORATE_RANGES") and
not cidrmatch(source.ip, "CDX_VPN_RANGES") and
not source.ip: ("CDX_KNOWN_SCANNERS")

Rule Builder Configuration

·        Group by: source.ip

·        Time window: 20 minutes

·        Failures ≥ 25

·        Distinct users ≥ 10

Rule 2 — Distributed Password Spraying Across Multiple Sources (Gap Closure Detection)

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect coordinated password spraying distributed across multiple external IPs targeting many users within a short time window.

Elastic Rule Type

ES|QL Rule

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        Same as Rule 1

·        Stable authentication telemetry

Enforcement Method

·        External failures only

·        Multiple source IPs

·        Multiple distinct users

·        Aggregate failure threshold

Standalone Alerting Justification

Permitted because aggregated multi-source targeting behavior indicates coordinated attack activity.

Implementation Constraint Notes

·        More sensitive to noisy integrations

·        Requires strong exclusion hygiene

·        Should be deployed after Rule 1 stabilization

Expected Noise Profile

·        Low to moderate

Variant Analysis

Covered

·        Distributed password spraying

·        Low-and-slow spray avoiding single-IP thresholds

Gaps

·        Extremely low-frequency attacks

·        Trusted egress abuse

Execution Validity Statement

Executable with normalized telemetry and maintained exclusion datasets.

Production Ready

Yes (with declared dependencies)

System-ready code

FROM auth-*
| WHERE event.outcome == "failure"
  AND user.name IS NOT NULL
  AND source.ip IS NOT NULL
  AND CIDR_MATCH(source.ip, "CDX_CORPORATE_RANGES") == false
  AND CIDR_MATCH(source.ip, "CDX_VPN_RANGES") == false
  AND source.ip NOT IN ("CDX_KNOWN_SCANNERS")
| EVAL bucket = DATE_TRUNC(15 minutes, @timestamp)
| STATS
    total_failures = COUNT(*),
    targeted_users = COUNT_DISTINCT(user.name),
    source_ips = COUNT_DISTINCT(source.ip)
  BY bucket
| WHERE total_failures >= 40 AND targeted_users >= 10 AND source_ips >= 5

Rule 3 — External Failure Burst Followed by Successful Authentication (Compromise Indicator)

MITRE ATT&CK

·        T1110 – Brute Force

·        T1078 – Valid Accounts

Purpose

Detect successful authentication following concentrated failed attempts from the same external source.

Elastic Rule Type

ES|QL Rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Authentication telemetry:

o   user.name

o   source.ip

o   event.outcome

Enforcement Method

·        External source only

·        Failure threshold

·        Success condition

·        Same user and source

Standalone Alerting Justification

Permitted because detection combines attack pressure with successful access.

Implementation Constraint Notes

·        Must exclude trusted ranges

·        Must exclude service accounts

·        Must maintain tight time window

Expected Noise Profile

·        Low

Variant Analysis

Covered

·        Credential guessing with success

·        Credential replay

Gaps

·        Distributed attacks

·        Token-based abuse

Execution Validity Statement

Executable with normalized authentication telemetry.

Production Ready

Yes

System-ready code

FROM auth-*
| WHERE user.name IS NOT NULL
  AND source.ip IS NOT NULL
  AND event.outcome IN ("failure","success")
  AND CIDR_MATCH(source.ip, "CDX_CORPORATE_RANGES") == false
  AND CIDR_MATCH(source.ip, "CDX_VPN_RANGES") == false
| EVAL bucket = DATE_TRUNC(15 minutes, @timestamp)
| STATS
    failures = COUNT(IF(event.outcome == "failure", 1, NULL)),
    successes = COUNT(IF(event.outcome == "success", 1, NULL))
  BY bucket, user.name, source.ip
| WHERE failures >= 8 AND successes >= 1

QRadar

Required Supporting Building Blocks

BB:Exclude Trusted Corporate Source IPs

Purpose

Exclude enterprise-controlled infrastructure.

Required Content

·        Corporate NAT ranges

·        Data center egress IPs

·        Approved cloud egress

Operational Role

Ensures only external sources are evaluated.

BB:Exclude Approved VPN Source IPs

Purpose

Exclude legitimate remote access traffic.

Required Content

·        VPN exit IP ranges

Operational Role
Prevents user-originated access from triggering detections.

BB:Exclude Known Scanners and Auth Test Systems

Purpose

Remove synthetic authentication noise.

Required Content

·        Vulnerability scanners

·        QA/test systems

·        Red-team infrastructure

Operational Role

Prevents false positives from testing activity.

BB:Exclude Service and Automation Accounts

Purpose

Reduce non-human authentication noise.

Required Content

·        Service accounts

·        Automation identities

Operational Role

Prevents distortion of user-based thresholds.

Rule Name

External Password Spraying from Single Source

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect password spraying from a single external source.

QRadar Rule Type

CRE Event Rule with aggregation

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        DSM parsing for Username, Source IP, Failure events

·        Building blocks:

o   Corporate IP exclusion

o   VPN exclusion

o   Scanner exclusion

Enforcement Method

·        Authentication failures

·        External source only

·        Group by Source IP

·        COUNT ≥ 25

·        UNIQUE Username ≥ 10

·        WITHIN 20 minutes

Standalone Alerting Justification

Strong known attack pattern.

Implementation Constraint Notes

·        Validate DSM parsing

·        Ensure exclusions are complete

Tuning Explanation

Primary low-noise detection rule.

Expected Noise Profile

Low

Variant Analysis

Covered

·        Classic spraying

Gaps

·        Distributed spray

Compensating Controls

·        Rule 2

Execution Validity Statement
Executable with proper parsing and exclusions.

Rule Regret Check

Deployment caution

Requires accurate exclusions

Confidence caution

Misses distributed spray

Coverage value

Primary detection

Production Ready

Yes

Engineering Note

Incomplete without building blocks.

System-ready code

WHEN Authentication Failure
AND NOT matches BB:Exclude Trusted Corporate Source IPs
AND NOT matches BB:Exclude Approved VPN Source IPs
AND NOT matches BB:Exclude Known Scanners

GROUP BY Source IP

HAVING COUNT >= 25
AND UNIQUE Username >= 10
WITHIN 20 minutes

CREATE OFFENSE "Password Spraying Detected from Single Source"

Rule Name

Distributed Password Spraying Across Multiple Sources

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect distributed password spraying.

QRadar Rule Type

CRE Event Rule (global aggregation)

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

Same as Rule 1

Enforcement Method

·        Authentication failures

·        External sources

·        COUNT ≥ 40

·        UNIQUE Username ≥ 10

·        UNIQUE Source IP ≥ 5

·        WITHIN 15 minutes

Standalone Alerting Justification

Indicates coordinated attack behavior.

Implementation Constraint Notes

·        Noise-sensitive

·        Requires stable environment

Tuning Explanation
Gap-closure rule.

Expected Noise Profile

Low to moderate

Variant Analysis

Covered

·        Distributed spray

Gaps

·        Very slow attacks

Compensating Controls

·        Rule 1

Execution Validity Statement
Executable with clean exclusions.

Rule Regret Check

Deployment caution

Sensitive to auth storms

Confidence caution

May alert during outages

Coverage value

Gap closure

Production Ready

Yes

Engineering Note

Deploy after Rule 1.

System-ready code

WHEN Authentication Failure
AND NOT matches BB:Exclude Trusted Corporate Source IPs
AND NOT matches BB:Exclude Approved VPN Source IPs
AND NOT matches BB:Exclude Known Scanners

GROUP ALL EVENTS

HAVING COUNT >= 40
AND UNIQUE Username >= 10
AND UNIQUE Source IP >= 5
WITHIN 15 minutes

CREATE OFFENSE "Distributed Password Spraying Detected"

Rule Name

External Failure Burst Followed by Successful Authentication

MITRE ATT&CK

·        T1110 – Brute Force

·        T1078 – Valid Accounts

Purpose

Detect successful login after repeated failures.

QRadar Rule Type

CRE Event Rule with sequential condition

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        DSM parsing for success/failure

·        Building blocks:

o   Corporate exclusion

o   VPN exclusion

o   Service account exclusion

Enforcement Method

·        Failures ≥ 8

·        Same Source IP + Username

·        Followed by success

·        Within 15 minutes

Standalone Alerting Justification

Combines pressure and success.

Implementation Constraint Notes

·        Requires reliable parsing

·        Must exclude noisy identities

Tuning Explanation

Compromise indicator.

Expected Noise Profile

Low

Variant Analysis

Covered

·        Successful compromise

Gaps

·        Distributed attacks

Compensating Controls

·        Rule 1 and Rule 2

Execution Validity Statement

Executable with proper parsing.

Rule Regret Check

Deployment caution

Sensitive to retries

Confidence caution
Weaker for distributed patterns

Coverage value
Strong signal

Production Ready

Yes

Engineering Note

Deploy after Rule 1.

System-ready code

WHEN Authentication Failure
AND NOT matches BB:Exclude Trusted Corporate Source IPs
AND NOT matches BB:Exclude Approved VPN Source IPs
AND NOT matches BB:Exclude Service and Automation Accounts

GROUP BY Source IP, Username

HAVING COUNT >= 8
WITHIN 15 minutes

FOLLOWED BY Authentication Success
WITH SAME Source IP AND Username

CREATE OFFENSE "External Failure Burst Followed by Successful Authentication"

Sigma

Required Supporting Dependencies

Dependency Name

Field Mapping Normalization

Purpose
Ensure Sigma fields map correctly to backend-native fields.

Required Content

·        SourceIp

·        TargetUser

·        EventType

·        Authentication success/failure outcome

Operational Role
Prevents detection degradation caused by schema mismatch.

Dependency Name

Trusted Network Exclusions

Purpose
Exclude sanctioned infrastructure from auth-abuse detections.

Required Content

·        Corporate IP ranges

·        VPN IP ranges

Operational Role
Ensures detections remain external-source focused.

Dependency Name

Scanner and Test System Exclusions

Purpose

Remove synthetic authentication activity.

Required Content

·        Scanner IPs

·        QA/test systems

·        Red-team testing infrastructure

Operational Role

Prevents false positives from authorized testing.

Dependency Name

Service and Automation Account Exclusions

Purpose

Reduce non-human authentication noise.

Required Content

·        Service accounts

·        Automation identities

·        Machine-auth accounts where applicable

Operational Role

Prevents threshold distortion and noisy retry patterns.

Rule Name

External Password Spraying from Single Source

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect repeated authentication failures from one external source targeting many distinct user accounts within a short interval.

Sigma Rule Type

Correlation Rule

Classification

Alert-capable

SOC Usage Mode
Alert-capable

Minimum Deployment Requirement

·        Authentication failure logs

·        Field mapping for:

o   SourceIp

o   TargetUser

o   Authentication failure indicator

·        Backend support for:

o   event aggregation

o   grouping by SourceIp

o   distinct TargetUser counting

·        Trusted network and scanner exclusions

Enforcement Method

·        Authentication failures only

·        External source only

·        Group by SourceIp

·        COUNT ≥ 25

·        DISTINCT TargetUser ≥ 10

·        WITHIN 20 minutes

Standalone Alerting Justification

Permitted because repeated failures against many users from one external source is a strong, well-established password-spraying pattern.

Implementation Constraint Notes

·        This rule is only full-fidelity on backends that support distinct-count correlation

·        If the target backend cannot support distinct-user counting, this Sigma rule remains the canonical design but must be implemented natively in the destination platform

·        Do not silently downgrade the logic

Tuning Explanation

This is the primary Sigma auth-abuse rule because it is the strongest and lowest-noise portable detection in the set.

Expected Noise Profile

Low

Variant Analysis

Covered

·        Classic password spraying

·        Credential stuffing concentrated through one source

Gaps

·        Distributed password spraying

·        Trusted-egress abuse

·        Passwordless or token-first abuse

Compensating Controls

·        Distributed spraying rule

·        Failure-to-success compromise rule

·        Backend-native identity anomaly detections

Execution Validity Statement

Conditionally executable. Full execution fidelity requires a backend that supports grouped aggregation and distinct-user counting.

Rule Regret Check

Deployment caution

Requires backend support for distinct-user aggregation.

Confidence caution

Will miss distributed and trusted-egress spraying.

Coverage value

Primary, high-confidence password-spraying detection.

Production Ready

Yes, with declared customer and backend dependencies

Engineering Note

This rule is complete as a Sigma design artifact. It is not complete as an operational deployment unless the target backend can preserve distinct-user correlation semantics.

System-ready code

title: External Password Spraying from Single Source
id: cdx-sigma-001
status: stable
description: Detects authentication failures from one external source targeting many users within a short period.
author: CyberDax
date: 2026-04-06
tags:
  - attack.t1110
  - cdx.backend_requires_correlation
  - cdx.backend_requires_distinct_count
logsource:
  category: authentication
detection:
  selection:
    EventType: AuthenticationFailure
  filter_internal:
    SourceIp|cidr:
      - CORPORATE_RANGES
      - VPN_RANGES
  filter_scanner:
    SourceIp:
      - SCANNER_IPS
  filter_service:
    TargetUser:
      - SERVICE_ACCOUNTS
  condition: selection and not 1 of filter_*
fields:
  - SourceIp
  - TargetUser
falsepositives:
  - Authorized authentication testing from undeclared infrastructure
level: high
---
title: Correlation - External Password Spraying from Single Source
status: stable
correlation:
  type: event_count
  rules:
    - External Password Spraying from Single Source
  group-by:
    - SourceIp
  timespan: 20m
  condition:
    gte: 25
  generate: true
x-cyberdax-requirements:
  distinct_target_user_count: ">=10"
  backend_requirement: "must support distinct count of TargetUser per SourceIp"
  fidelity_warning: "native backend implementation required if distinct TargetUser correlation cannot be preserved"

Rule Name

Distributed Password Spraying Across Multiple Sources

MITRE ATT&CK

·        T1110 – Brute Force

Purpose

Detect coordinated authentication failures distributed across multiple external IPs targeting many user accounts in a short period.

Sigma Rule Type

Correlation Rule

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        Authentication failure logs

·        Field mapping for:

o   SourceIp

o   TargetUser

·        Backend support for:

o   total event counting

o   distinct TargetUser counting

o   distinct SourceIp counting

·        Trusted network and scanner exclusions

Enforcement Method

·        Authentication failures only

·        External sources only

·        COUNT ≥ 40

·        DISTINCT TargetUser ≥ 10

·        DISTINCT SourceIp ≥ 5

·        WITHIN 15 minutes

Standalone Alerting Justification

Permitted as a supporting detection because many external sources targeting many users in one bounded window is strong evidence of coordinated distributed auth abuse.

Implementation Constraint Notes

·        This rule is more backend-sensitive than Rule 1

·        If the backend cannot support both distinct SourceIp and distinct TargetUser cardinality, implement natively in the destination SIEM

·        Do not ship this as “equivalent” if translation degrades either count dimension

Tuning Explanation

This is the gap-closure rule for distributed spraying that avoids single-source thresholds.

Expected Noise Profile

Low to moderate

Variant Analysis

Covered

·        Distributed password spraying

·        Lower-volume spray kept below per-source thresholds

Gaps

·        Very slow attacks across long periods

·        Trusted-egress abuse

·        Token-first abuse

Compensating Controls

·        Rule 1

·        Backend-native identity anomaly detections

·        IdP-native detections for risky sign-in patterns

Execution Validity Statement

Conditionally executable. Full fidelity requires multi-cardinality backend support.

Rule Regret Check

Deployment caution

Requires backend support for distinct-user and distinct-source aggregation.

Confidence caution

More noise-sensitive than the single-source spray rule.

Coverage value

Critical gap-closure analytic for distributed spraying.

Production Ready

Yes, with declared customer and backend dependencies

Engineering Note

This rule should remain supporting, not primary. If backend conversion weakens either distinct-count condition, native implementation is required.

System-ready code

title: Distributed Password Spraying Across Multiple Sources
id: cdx-sigma-002
status: stable
description: Detects distributed authentication failures across multiple external IPs targeting many users.
author: CyberDax
date: 2026-04-06
tags:
  - attack.t1110
  - cdx.backend_requires_correlation
  - cdx.backend_requires_multi_cardinality
logsource:
  category: authentication
detection:
  selection:
    EventType: AuthenticationFailure
  filter_internal:
    SourceIp|cidr:
      - CORPORATE_RANGES
      - VPN_RANGES
  filter_scanner:
    SourceIp:
      - SCANNER_IPS
  filter_service:
    TargetUser:
      - SERVICE_ACCOUNTS
  condition: selection and not 1 of filter_*
fields:
  - SourceIp
  - TargetUser
falsepositives:
  - Large benign authentication disruptions from undeclared external services
level: medium
---
title: Correlation - Distributed Password Spraying Across Multiple Sources
status: stable
correlation:
  type: event_count
  rules:
    - Distributed Password Spraying Across Multiple Sources
  timespan: 15m
  condition:
    gte: 40
  generate: true
x-cyberdax-requirements:
  distinct_target_user_count: ">=10"
  distinct_source_ip_count: ">=5"
  backend_requirement: "must support multi-cardinality aggregation over TargetUser and SourceIp"
  fidelity_warning: "native backend implementation required if either distinct count cannot be preserved"

Rule Name

External Failure Burst Followed by Successful Authentication

MITRE ATT&CK

·        T1110 – Brute Force

·        T1078 – Valid Accounts

Purpose

Detect successful authentication following repeated failures from the same external source against the same user within a short interval.

Sigma Rule Type

Correlation Rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Authentication success and failure logs

·        Field mapping for:

o   SourceIp

o   TargetUser

o   Authentication success/failure outcome

·        Backend support for:

o   temporal ordering or paired correlation

o   grouping on SourceIp and TargetUser

·        Trusted network and service-account exclusions

Enforcement Method

·        Same SourceIp + TargetUser

·        Failure count ≥ 8

·        Followed by successful authentication

·        WITHIN 15 minutes

Standalone Alerting Justification

Permitted because it combines attack pressure with access outcome, making it a materially stronger compromise indicator than failures alone.

Implementation Constraint Notes

·        This is the most backend-sensitive rule in the Sigma set

·        If the backend cannot preserve ordered correlation on SourceIp + TargetUser, implement natively

·        Do not claim backend equivalence unless temporal ordering is preserved

Tuning Explanation

This is the compromise-indicator rule. It is narrower and more implementation-sensitive than the spray rules, but still valuable when temporal correlation is supported.

Expected Noise Profile
Low

Variant Analysis

Covered

·        Credential guessing resulting in successful access

·        Replay from one source against one user

·        External auth pressure followed by login success

Gaps

·        Distributed auth pressure

·        Existing trusted-session abuse

·        Token-first or passwordless auth flows

Compensating Controls

·        Rule 1

·        Rule 2

·        Backend-native identity and MFA abuse detections

Execution Validity Statement

Conditionally executable. Full fidelity requires backend support for ordered or paired temporal correlation on SourceIp + TargetUser.

Rule Regret Check

Deployment caution

Requires backend sequencing support and reliable success/failure normalization.

Confidence caution

Most backend-sensitive rule in the Sigma set and weaker for distributed patterns.

Coverage value

Strong compromise indicator when temporal correlation is preserved.

Production Ready

Yes, with declared customer and backend dependencies

Engineering Note

If the backend cannot support temporal sequencing faithfully, retain this Sigma rule as the canonical detection definition and implement the operational rule natively.

System-ready code

title: External Authentication Failure Burst
id: cdx-sigma-003a
status: stable
description: Detects external authentication failures for the same user and source.
author: CyberDax
date: 2026-04-06
tags:
  - attack.t1110
  - cdx.backend_requires_correlation
  - cdx.backend_requires_temporal_order
logsource:
  category: authentication
detection:
  selection:
    EventType: AuthenticationFailure
  filter_internal:
    SourceIp|cidr:
      - CORPORATE_RANGES
      - VPN_RANGES
  filter_service:
    TargetUser:
      - SERVICE_ACCOUNTS
  condition: selection and not 1 of filter_*
fields:
  - SourceIp
  - TargetUser
level: medium
---
title: External Authentication Success
id: cdx-sigma-003b
status: stable
description: Detects external authentication success for the same user and source.
author: CyberDax
date: 2026-04-06
tags:
  - attack.t1078
  - cdx.backend_requires_correlation
  - cdx.backend_requires_temporal_order
logsource:
  category: authentication
detection:
  selection:
    EventType: AuthenticationSuccess
  filter_internal:
    SourceIp|cidr:
      - CORPORATE_RANGES
      - VPN_RANGES
  filter_service:
    TargetUser:
      - SERVICE_ACCOUNTS
  condition: selection and not 1 of filter_*
fields:
  - SourceIp
  - TargetUser
level: high
---
title: Correlation - External Failure Burst Followed by Successful Authentication
status: stable
correlation:
  type: temporal_ordered
  rules:
    - External Authentication Failure Burst
    - External Authentication Success
  group-by:
    - SourceIp
    - TargetUser
  timespan: 15m
  generate: true
x-cyberdax-requirements:
  failure_count: ">=8"
  backend_requirement: "must support ordered temporal correlation grouped by SourceIp and TargetUser"
  fidelity_warning: "native backend implementation required if ordered correlation cannot be preserved"

YARA

Required Supporting Dependencies

Dependency Name

Suspicious Artifact Scan Scope Definition

Purpose
Constrain YARA scanning to high-value, low-noise artifact locations.

Required Content

·        email detonation output paths

·        endpoint quarantine or malware repository paths

·        suspicious download directories under investigation

·        unpacked phishing kit folders

·        recovered webroot or staging artifacts from incident response

Operational Role
Prevents broad indiscriminate scanning of legitimate enterprise code, templates, and repositories.

Dependency Name

Approved Template and Research Exclusions

Purpose
Prevent legitimate branded templates, research artifacts, and lab materials from triggering detections.

Required Content

·        sanctioned login page templates

·        approved SSO branding assets

·        internal phishing simulation artifacts

·        internal reverse-proxy lab or training materials

·        approved browser migration, password-management, or forensic tools

Operational Role
Reduces false positives by excluding known-good artifacts that may otherwise resemble malicious content.

Dependency Name

Deployment Context Classification

Purpose
Define where each rule is intended to be used.

Required Content

·        endpoint artifact triage

·        email attachment analysis

·        malware repository scanning

·        suspicious web-content review

·        IR collection review

Operational Role
Ensures each rule is deployed in the correct analytical context instead of broad uncontrolled scanning.

Rule Name

External Credential-Harvesting HTML or JavaScript Page Artifact

MITRE ATT&CK

·        T1566 – Phishing

·        T1056 – Input Capture

Purpose

Detect credential-harvesting page artifacts that contain login capture logic, username and password field semantics, and suspicious external submission or lure behavior.

YARA Rule Type

Standard YARA file-content rule

Classification

Alert-capable supporting detection

SOC Usage Mode
Alert-capable supporting detection

Minimum Deployment Requirement

·        Deployment context:

o   email attachment detonation

o   endpoint artifact triage

o   suspicious web-content triage

o   unpacked phishing kit review

·        Dependencies:

o   Suspicious Artifact Scan Scope Definition

o   Approved Template and Research Exclusions

o   Deployment Context Classification

·        Readable HTML, HTM, JS, or text-based content

Enforcement Method

·        Require both username and password capture semantics

·        Require either:

o   suspicious external submission behavior

o   or login-form semantics plus lure language

·        Constrain filesize to common phishing-page artifact size

·        Encode intended scan scope and exclusions in metadata

Standalone Alerting Justification

Permitted because this rule targets a concrete phishing artifact rather than speculative runtime behavior.

Implementation Constraint Notes

·        Do not run this broadly across sanctioned enterprise web repositories without exclusions

·        If legitimate SSO templates are in scope, exclude by path, repository, or deployment bucket

·        Best used on suspicious artifacts, not on general-purpose web application source trees

Tuning Explanation

This rule is hardened to avoid firing on generic login pages alone. It requires credential-capture semantics plus suspicious submission or lure logic, which materially reduces noise.

Expected Noise Profile

·        Low when deployed against suspicious artifact collections

·        Moderate if applied broadly across legitimate template repositories without exclusions

Variant Analysis

Covered

·        Fake login pages that capture username and password

·        MFA-themed lure pages

·        HTML or JavaScript phishing artifacts with external submit behavior

Gaps

·        Purely server-side phishing logic

·        Dynamic phishing content not present in recovered files

·        Minimal reverse-proxy phishing kits with almost no static lure content

Compensating Controls

·        Reverse-proxy phishing config rule

·        Email security detections

·        Proxy, DNS, IdP, and session-abuse detections

Execution Validity Statement
Executable as a production YARA rule when scan scope and exclusions are explicitly controlled.

Rule Regret Check

Deployment caution
Do not deploy this against sanctioned enterprise template stores without exclusion control.

Confidence caution
Will miss phishing implementations that do not leave recoverable client-side page artifacts.

Coverage value
High-value artifact detector for credential-harvesting pages recovered from endpoints, emails, or phishing kit bundles.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines:

·        the suspicious artifact scan scope

·        sanctioned template exclusions

·        intended deployment context

System-ready code

rule CDX_YARA_External_Credential_Harvesting_Page
{
  meta:
    description = "Detects credential-harvesting HTML or JavaScript artifacts with login-field capture and suspicious submission behavior"
    author = "CyberDax"
    date = "2026-04-06"
    attack_1 = "T1566"
    attack_2 = "T1056"
    cdx_artifact_only = "true"
    cdx_scan_scope = "suspicious_artifacts_only"
    cdx_deployment_context = "email_detonation,endpoint_artifact_triage,phishing_kit_review"
    cdx_exclusions_required = "approved_login_templates,research_materials,simulation_artifacts"
    cdx_fidelity_warning = "broad unsupervised repository scanning may increase noise"

  strings:
    $form_login = /<form[^>]{0,512}(login|signin|auth|verify|account|mfa|sso)/ nocase ascii
    $pwd_field  = /name\s*=\s*["'](pass|password|passwd|pwd)["']/ nocase ascii
    $user_field = /name\s*=\s*["'](user|username|email|login|identifier)["']/ nocase ascii
    $submit_ext = /action\s*=\s*["']https?:\/\/(?![^"']*(microsoftonline\.com|office\.com|office365\.com|live\.com|okta\.com|duo\.com))[^"']+/ nocase ascii
    $mfa_lure   = /(mfa|2fa|verification code|approve sign-?in|confirm your account)/ nocase ascii
    $brand_lure = /(sign in|verify your account|session expired|unusual activity)/ nocase ascii

  condition:
    filesize < 500KB and
    $pwd_field and
    $user_field and
    (
      $submit_ext or
      ( $form_login and 1 of ($mfa_lure, $brand_lure) )
    )
}

Rule Name

Browser Credential and Session Store Theft Tool or Script Artifact

MITRE ATT&CK

·        T1555 – Credentials from Password Stores

·        T1539 – Steal Web Session Cookie

Purpose

Detect tools or scripts that target browser credential or session stores and combine that access with extraction, decryption, staging, or exfiltration behavior.

YARA Rule Type

Standard YARA file-content rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Deployment context:

o   endpoint artifact triage

o   malware repository scanning

o   suspicious attachment or download analysis

·        Dependencies:

o   Suspicious Artifact Scan Scope Definition

o   Approved Template and Research Exclusions

o   Deployment Context Classification

·        Readable strings from scripts, binaries, or bundled tooling

Enforcement Method

·        Require browser-store target strings

·        Require theft-oriented operational logic:

o   SQLite access

o   decryption

o   copy/staging

·        Require exfiltration or upload behavior

·        Encode intended scan scope and exclusions in metadata

Standalone Alerting Justification

Permitted because this rule targets a concrete theft-oriented artifact that combines sensitive store targeting with operational theft behavior.

Implementation Constraint Notes

·        Exclude approved browser migration tools, password managers, and forensic utilities if in scope

·        Best used on suspicious scripts, binaries, quarantine, and recovered tooling

·        Do not use broad internal script-repository scanning without explicit exclusions

Tuning Explanation

This rule is hardened to require browser-store targets plus theft-oriented behavior plus exfiltration or upload semantics. That keeps it lower-noise than simple path-string detection.

Expected Noise Profile

·        Low when used on suspicious artifacts and quarantine

·        Moderate if broad internal admin or migration script repositories are scanned without exclusions

Variant Analysis

Covered

·        Tools targeting Chrome, Edge, or Firefox credential/session stores

·        Artifacts referencing Login Data, Cookies, Web Data, logins.json, key4.db, or cookies.sqlite

·        Tooling that combines store access with extraction, decryption, or exfiltration

Gaps

·        In-memory-only theft

·        Living-off-the-land access with minimal strings

·        Cloud-only session abuse after prior theft

Compensating Controls

·        Endpoint behavioral detections

·        IdP and cloud-session detections

·        Reverse-proxy phishing config rule

Execution Validity Statement

Executable as a production YARA rule when scan scope and approved-tool exclusions are explicitly controlled.

Rule Regret Check

Deployment caution
Must exclude sanctioned migration, password-management, and forensic tooling if those artifacts are in scope.

Confidence caution
Will miss in-memory theft and highly stripped artifacts with minimal readable strings.

Coverage value

Very high-value artifact detector for browser credential and session theft tooling.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines:

·        approved-tool exclusions

·        suspicious artifact paths

·        deployment context

System-ready code

rule CDX_YARA_Browser_Credential_Session_Store_Theft_Tool
{
  meta:
    description = "Detects tooling that targets browser credential or session stores and pairs access with theft-oriented behavior"
    author = "CyberDax"
    date = "2026-04-06"
    attack_1 = "T1555"
    attack_2 = "T1539"
    cdx_artifact_only = "true"
    cdx_scan_scope = "suspicious_artifacts_only"
    cdx_deployment_context = "endpoint_artifact_triage,malware_repository,attachment_analysis"
    cdx_exclusions_required = "approved_password_managers,migration_tools,forensic_utilities"
    cdx_fidelity_warning = "broad internal script scanning may increase noise"

  strings:
    $chrome_login   = "Login Data" ascii wide
    $chrome_cookies = "Cookies" ascii wide
    $chrome_webdata = "Web Data" ascii wide
    $firefox_login  = "logins.json" ascii wide
    $firefox_key4   = "key4.db" ascii wide
    $firefox_cookie = "cookies.sqlite" ascii wide
    $local_state    = "Local State" ascii wide

    $sqlite1 = "sqlite3" ascii wide
    $sqlite2 = "SELECT origin_url, username_value, password_value" ascii wide
    $decrypt1 = "CryptUnprotectData" ascii wide
    $decrypt2 = "os_crypt" ascii wide
    $copy1 = "copyfile" ascii wide
    $copy2 = "shutil.copy" ascii wide

    $exfil1 = "requests.post" ascii wide
    $exfil2 = "Invoke-WebRequest" ascii wide
    $exfil3 = "WinHttpOpenRequest" ascii wide
    $exfil4 = "upload" ascii wide
    $exfil5 = "multipart/form-data" ascii wide

  condition:
    filesize < 2MB and
    2 of ($chrome_*,$firefox_*,$local_state) and
    1 of ($sqlite*,$decrypt*,$copy*) and
    1 of ($exfil*)
}

Rule Name

Reverse-Proxy Phishing Kit Configuration or Session-Capture Artifact

MITRE ATT&CK

·        T1566 – Phishing

·        T1539 – Steal Web Session Cookie

·        T1078 – Valid Accounts

Purpose

Detect reverse-proxy phishing kit configuration artifacts or phishlet-style files used to capture sessions, cookies, tokens, or credentials.

YARA Rule Type

Standard YARA file-content rule

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        Deployment context:

o   IR artifact review

o   phishing kit directory review

o   suspicious repository or staging review

·        Dependencies:

o   Suspicious Artifact Scan Scope Definition

o   Approved Template and Research Exclusions

o   Deployment Context Classification

·        Readable config or template files

Enforcement Method

·        Require multiple phishlet-style or reverse-proxy capture semantics

·        Require credential/session/token capture semantics

·        Require auth-provider or login lure semantics

·        Tighten condition so generic proxy configs do not satisfy it

·        Encode intended scan scope and exclusions in metadata

Standalone Alerting Justification

Permitted because this rule targets a concrete configuration artifact associated with session or credential capture.

Implementation Constraint Notes

·        Exclude sanctioned internal reverse-proxy research, labs, and training materials if in scope

·        Use this on suspicious configs or investigation collections, not on broad general-purpose infrastructure repositories

·        This rule is intended for phishing/session-capture proxy artifacts, not generic reverse proxies

Tuning Explanation

This rule is tightened beyond the prior version by requiring a more specific combination:

·        reverse-proxy capture semantics

·        credential/session semantics

·        auth-provider or lure semantics
That reduces the chance of generic proxy configuration matches.

Expected Noise Profile

·        Low when used on suspicious config artifacts or recovered phishing kit content

·        Moderate if used across broad security-research repositories without exclusions

Variant Analysis

Covered

·        Reverse-proxy phishing kit configs

·        Session-cookie or token-capture config artifacts

·        Credential field capture config logic tied to auth-provider lures

Gaps

·        Minimal custom frameworks with no recognizable config semantics

·        Purely runtime-only session capture with no recovered config artifacts

·        Generic reverse proxies not built for credential or session capture

Compensating Controls

·        Credential-harvesting page rule

·        IdP, proxy, and session-abuse detections

·        Endpoint detections for credential-store theft

Execution Validity Statement

Executable as a production YARA rule when suspicious config scope and sanctioned research exclusions are explicitly controlled.

Rule Regret Check

Deployment caution
Must exclude sanctioned internal lab, research, or training artifacts if present in scan scope.

Confidence caution
Will miss custom or minimal frameworks that do not expose recognizable capture-oriented config strings.

Coverage value
High-value artifact detector for reverse-proxy phishing and session-capture kit components.

Production Ready
Yes, with declared customer dependencies

Engineering Note
This rule is only complete when the customer defines:

·        suspicious config scan scope

·        internal lab and research exclusions

·        deployment context

System-ready code

rule CDX_YARA_Reverse_Proxy_Phishing_Kit_Config
{
  meta:
    description = "Detects reverse-proxy phishing kit or phishlet-style configuration artifacts used for session or credential capture"
    author = "CyberDax"
    date = "2026-04-06"
    attack_1 = "T1566"
    attack_2 = "T1539"
    attack_3 = "T1078"
    cdx_artifact_only = "true"
    cdx_scan_scope = "suspicious_artifacts_only"
    cdx_deployment_context = "ir_artifact_review,phishing_kit_review,suspicious_config_review"
    cdx_exclusions_required = "internal_proxy_labs,research_materials,training_artifacts"
    cdx_fidelity_warning = "broad scanning of generic proxy repositories may increase noise"

  strings:
    $rp1 = "proxy_hosts" ascii wide
    $rp2 = "sub_filters" ascii wide
    $rp3 = "landing_path" ascii wide
    $rp4 = "js_inject" ascii wide

    $cap1 = "auth_tokens" ascii wide
    $cap2 = "credentials" ascii wide
    $cap3 = "cookies" ascii wide
    $cap4 = "session" ascii wide
    $cap5 = "password" ascii wide
    $cap6 = "username" ascii wide

    $idp1 = "login.microsoftonline.com" ascii wide
    $idp2 = "okta.com" ascii wide
    $idp3 = "duosecurity.com" ascii wide
    $idp4 = "office.com" ascii wide
    $idp5 = "microsoftonline.com" ascii wide

  condition:
    filesize < 1MB and
    2 of ($rp*) and
    2 of ($cap*) and
    1 of ($idp*)
}

AWS

Required Supporting Dependencies

Dependency Name

Trusted Administrative Network Scope

Purpose
Define which source networks are sanctioned for administrative access.

Required Content

·        corporate egress CIDRs

·        VPN egress CIDRs

·        approved break-glass admin access CIDRs, if used

Operational Role
Supports triage and response context for management-plane events.

Dependency Name

Sensitive Role Inventory

Purpose
Define which IAM roles require heightened scrutiny.

Required Content

·        administrator roles

·        security tooling roles

·        privileged cross-account roles

·        break-glass or incident-response roles

Operational Role
Constrains the AssumeRole detection to roles that matter.

Dependency Name

SourceIdentity Governance Standard

Purpose
Define whether selected role-assumption flows must include SourceIdentity.

Required Content

·        exact roles or role prefixes requiring SourceIdentity

·        permitted source-identity naming or governance convention

·        trust-policy enforcement standard using sts:SourceIdentity where applicable

Operational Role
Makes the role-assumption detection enforceable instead of speculative. AWS documents that SourceIdentity can be required via the sts:SourceIdentity trust-policy condition key and can be used in CloudTrail for attribution.

Dependency Name

Deployment Scope Classification

Purpose
Define whether rules operate at:

·        single-account scope

·        centralized multi-account scope

·        organization-wide delegated scope

Required Content

·        covered accounts

·        covered Regions

·        whether EventBridge deployment is per account or centralized

·        whether CloudTrail management events are organization-managed

Operational Role
Prevents silent coverage gaps caused by fragmented account or Region deployment.

Rule Name

Root Console Login Success Without MFA

MITRE ATT&CK

·        T1078 – Valid Accounts

Purpose

Detect successful AWS root console sign-ins where CloudTrail shows MFA was not used.

AWS Rule Type

Amazon EventBridge event pattern on CloudTrail management events

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        CloudTrail management events enabled

·        EventBridge rule on each required account / Region path or centrally where architecture supports it

·        tested response target

·        Deployment Scope Classification completed

Enforcement Method

·        Match CloudTrail-delivered console sign-in events

·        Match signin.amazonaws.com

·        Match ConsoleLogin

·        Match userIdentity.type = Root

·        Match successful console login

·        Match MFAUsed = No

Standalone Alerting Justification

Permitted because successful root console sign-in without MFA is a high-confidence, very low-noise administrative risk event. CloudTrail documents ConsoleLogin events for root sign-ins and the presence of MFAUsed in additionalEventData.

Implementation Constraint Notes

·        Root console sign-in events are recorded in CloudTrail and root sign-in is especially sensitive; this should always be high severity.

·        Ensure coverage does not assume only one Region or one account path unless the customer architecture truly centralizes collection

·        This rule should feed immediate review or containment workflow

Tuning Explanation

This is the strongest AWS-native rule in the set because it is explicit, field-based, and does not depend on baseline logic or correlation state.

Expected Noise Profile

·        Very low

Variant Analysis

Covered

·        successful root console login without MFA

·        direct root-account administrative use

Gaps

·        failed root sign-ins

·        root API use without console sign-in

·        root sign-in with MFA

Compensating Controls

·        root access-key creation rule

·        organization-level root-use guardrails

·        SIEM review of other root-user CloudTrail activity

Execution Validity Statement

Executable as a production EventBridge rule when CloudTrail management events are enabled and deployment scope is fully defined.

Rule Regret Check

Deployment caution
Requires verified account and Region coverage plus a tested critical response path.

Confidence caution
Will not detect root credential abuse that never generates a console sign-in event.

Coverage value
Very high-value, very low-noise root-account compromise indicator.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines:

·        covered accounts

·        covered Regions

·        EventBridge deployment model

·        response target

System-ready code

{
  "source": ["aws.cloudtrail"],
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": {
    "eventSource": ["signin.amazonaws.com"],
    "eventName": ["ConsoleLogin"],
    "userIdentity": {
      "type": ["Root"]
    },
    "responseElements": {
      "ConsoleLogin": ["Success"]
    },
    "additionalEventData": {
      "MFAUsed": ["No"]
    }
  },
  "x-cyberdax-requirements": {
    "cdx_control_plane_only": true,
    "cdx_stateless_engine": true,
    "cdx_deployment_context": "cloudtrail_management_event_detection",
    "cdx_scope_required": "account_and_region_coverage_must_be_defined",
    "cdx_fidelity_warning": "coverage can fragment if EventBridge or CloudTrail scope is incomplete"
  }
}

Rule Name

Root Access Key Creation

MITRE ATT&CK

·        T1098 – Account Manipulation

·        T1078 – Valid Accounts

Purpose

Detect creation of an AWS access key tied to the root account.

AWS Rule Type

Amazon EventBridge event pattern on CloudTrail management events

Classification

Alert-capable

SOC Usage Mode
Alert-capable

Minimum Deployment Requirement

·        CloudTrail management events enabled

·        EventBridge rule deployed in all covered scope

·        critical response target

·        Deployment Scope Classification completed

Enforcement Method

·        Match CloudTrail-delivered management events

·        Match iam.amazonaws.com

·        Match CreateAccessKey

·        Match userIdentity.type = Root

Standalone Alerting Justification

Permitted because root access-key creation is almost always exceptional and AWS documents that CreateAccessKey can be used to manage root-user credentials when no user name is specified.

Implementation Constraint Notes

·        This should be treated as critical unless the customer has a formally approved root-key exception process

·        Immediate verification and containment workflow should be pre-defined

·        This rule is only useful if management-event coverage is complete

Tuning Explanation

This is stronger than generic IAM user key-creation detection because root-key creation is rarer and higher-confidence.

Expected Noise Profile

·        Very low

Variant Analysis

Covered

·        root access-key creation

·        root credential persistence through new key issuance

Gaps

·        IAM user access-key creation

·        use of already-existing root keys

·        STS abuse without long-term key creation

Compensating Controls

·        separate IAM user key-creation governance

·        STS role-assumption detections

·        credential inventory and key-age controls

Execution Validity Statement

Executable as a production EventBridge rule when CloudTrail management events are enabled and response workflow exists.

Rule Regret Check

Deployment caution
Requires pre-defined critical response workflow and verified CloudTrail scope.

Confidence caution
Will not detect use of existing root credentials.

Coverage value

Very high-value, extremely low-noise credential-persistence indicator.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines:

·        response workflow

·        covered account / Region scope

·        any root-key exception standard

System-ready code

{
  "source": ["aws.cloudtrail"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["iam.amazonaws.com"],
    "eventName": ["CreateAccessKey"],
    "userIdentity": {
      "type": ["Root"]
    }
  },
  "x-cyberdax-requirements": {
    "cdx_control_plane_only": true,
    "cdx_stateless_engine": true,
    "cdx_deployment_context": "cloudtrail_management_event_detection",
    "cdx_scope_required": "account_and_region_coverage_must_be_defined",
    "cdx_fidelity_warning": "requires complete management-event logging and critical response workflow"
  }
}

Rule Name

AssumeRole to Sensitive Role Without Required SourceIdentity

MITRE ATT&CK

·        T1078 – Valid Accounts

Purpose

Detect AssumeRole activity into sensitive roles where the customer requires SourceIdentity, but the event shows that the source identity field is absent.

AWS Rule Type

Amazon EventBridge event pattern on CloudTrail management events

Classification

Alert-capable supporting detection

SOC Usage Mode

Alert-capable supporting detection

Minimum Deployment Requirement

·        CloudTrail management events enabled

·        EventBridge rule deployed in covered scope

·        Sensitive Role Inventory completed

·        SourceIdentity Governance Standard completed

·        trust-policy or governance requirement for SourceIdentity actually in force for the targeted roles

Enforcement Method

·        Match CloudTrail-delivered management events

·        Match sts.amazonaws.com

·        Match AssumeRole

·        Match only sensitive role ARNs or prefixes

·        Match absence of requestParameters.sourceIdentity

Standalone Alerting Justification

Permitted only where the customer has explicitly defined a SourceIdentity governance standard. AWS documents that SourceIdentity is visible in CloudTrail and can be required using the sts:SourceIdentity trust-policy condition key.

Implementation Constraint Notes

·        Do not deploy this generically without governance

·        If SourceIdentity is not mandatory for the targeted role set, remove this rule rather than weakening it

·        This is intentionally a supporting rule, not a primary rule

·        Event pattern behavior depends on the actual event shape; the absent-field match should be validated against representative CloudTrail examples before production use. EventBridge event patterns match only specified fields when present and support field-based operators, so event-shape validation matters here.

Tuning Explanation

This rule is strong only when it enforces an existing governance standard. Without that governance, it becomes policy noise instead of attack detection.

Expected Noise Profile

·        Low when scoped to roles that mandate SourceIdentity

·        High if deployed without governance scoping

Variant Analysis

Covered

·        sensitive role assumptions missing required attribution

·        privileged role use violating source-identity governance

Gaps

·        roles where SourceIdentity is not required

·        abuse of already-issued role sessions

·        misleading but syntactically present source-identity values

Compensating Controls

·        trust-policy enforcement with sts:SourceIdentity

·        downstream CloudTrail review of role session activity

·        SIEM correlation for privileged role actions

Execution Validity Statement

Executable as a production EventBridge rule only when the customer has defined sensitive roles, required SourceIdentity, and validated the absent-field event pattern against real CloudTrail samples.

Rule Regret Check

Deployment caution
Do not deploy unless source-identity governance is formalized and event-shape validation has been performed.

Confidence caution
Without governance or event-shape validation, this rule risks policy-noise or missed matches.

Coverage value

Strong attribution-enforcement detection when governance exists.

Production Ready
Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines:

·        sensitive role scope

·        required source-identity standard

·        validation of absent-field matching against real CloudTrail examples

System-ready code

{
  "source": ["aws.cloudtrail"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["sts.amazonaws.com"],
    "eventName": ["AssumeRole"],
    "requestParameters": {
      "roleArn": [
        { "prefix": "arn:aws:iam::123456789012:role/Admin" },
        { "prefix": "arn:aws:iam::123456789012:role/Security" }
      ],
      "sourceIdentity": [
        { "exists": false }
      ]
    }
  },
  "x-cyberdax-requirements": {
    "cdx_control_plane_only": true,
    "cdx_stateless_engine": true,
    "cdx_deployment_context": "cloudtrail_management_event_detection",
    "cdx_scope_required": "sensitive_role_inventory_and_org_scope_must_be_defined",
    "cdx_backend_validation_required": "validate_request_shape_for_sourceIdentity_absence",
    "cdx_fidelity_warning": "rule is valid only where SourceIdentity governance is mandatory"
  }
}

Azure

Required Supporting Dependencies

Dependency Name

Workspace Ingestion Scope

Purpose
Ensure the required identity and Graph logs are present in the same Log Analytics workspace.

Required Content

·        Microsoft Entra AuditLogs

·        MicrosoftGraphActivityLogs

·        documented workspace scope and retention

Operational Role
Prevents silent alert gaps caused by missing log sources. Microsoft Graph activity logs must be sent to Log Analytics through diagnostic settings before they can be queried there.

Dependency Name

Privileged Role Inventory

Purpose
Define which role assignments are considered high risk.

Required Content

·        privileged built-in roles

·        privileged custom roles

·        governed roleDefinition IDs or names

Operational Role
Keeps the role-assignment rule high-fidelity instead of broad and noisy.

Dependency Name

Approved Automation and Admin Exclusions

Purpose
Reduce noise from sanctioned automation.

Required Content

·        approved AppId values

·        approved ServicePrincipalId values

·        approved admin workflows that intentionally create credentials

Operational Role
Supports low-noise Graph credential creation detections.

Dependency Name

Deployment Scope Classification

Purpose
Define tenant and workspace scope for the alert rules.

Required Content

·        covered tenant

·        covered workspace

·        action group ownership

·        evaluation frequency standard

Operational Role
Prevents incomplete alert coverage and inconsistent scheduling.

Rule Name

Privileged Role Assignment in Microsoft Entra Audit Logs

MITRE ATT&CK

·        T1098 – Account Manipulation

·        T1078 – Valid Accounts

Purpose
Detect assignment of privileged Microsoft Entra roles.

Azure Rule Type

Azure Monitor Scheduled Query Rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        AuditLogs ingested to Log Analytics

·        Privileged Role Inventory defined

·        scheduled query rule deployed with action group

·        workspace scope defined

·        evaluation model defined:

o   run every 5 minutes

o   look back 5 minutes

o   alert on any returned result

Enforcement Method

·        Query AuditLogs

·        Match role-assignment activity

·        Restrict to privileged role additions only

·        Alert on any returned row

Standalone Alerting Justification

Permitted because privileged role assignment is a strong, high-value identity-control event, and Entra audit logs are the authoritative source for directory change activity.

Implementation Constraint Notes

·        Query starts with the table for performance

·        Query remains scoped to AuditLogs

·        Privileged role filtering is mandatory

·        Do not deploy without defined privileged role inventory

Tuning Explanation

This rule was tightened so it no longer fires on generic role membership changes. It now requires privileged-role scoping, which materially reduces noise.

Expected Noise Profile

·        Low when privileged roles are explicitly scoped

·        Moderate if privileged-role inventory is incomplete

Variant Analysis

Covered

·        privileged role assignment

·        unauthorized identity privilege elevation

Gaps

·        abuse of already-assigned privileges

·        PIM activation patterns not represented here

·        role assignments outside workspace scope

Compensating Controls

·        Entra PIM monitoring

·        SIEM correlation for downstream privileged activity

Execution Validity Statement

Executable as a production scheduled query rule when AuditLogs are ingested and privileged roles are explicitly defined.

Rule Regret Check

Deployment caution
Requires privileged-role filtering and defined workspace scope.

Confidence caution
Will not detect misuse of existing privileged assignments.

Coverage value
High-confidence privilege-escalation detection.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer provides the privileged role list or roleDefinition identifiers to enforce.

System-ready code

let PrivilegedRoles = dynamic([
  "Global Administrator",
  "Privileged Role Administrator",
  "User Administrator",
  "Security Administrator",
  "Cloud Application Administrator"
]);
AuditLogs
| where TimeGenerated > ago(5m)
| where OperationName contains "Add member to role"
| mv-expand TR = TargetResources
| extend RoleName = tostring(TR.displayName)
| where RoleName in (PrivilegedRoles)
| project TimeGenerated, OperationName, RoleName, InitiatedBy, TargetResources, Result

Alert Evaluation Model

·        Frequency: every 5 minutes

·        Lookup window: last 5 minutes

·        Trigger: greater than 0 results

Enforcement Metadata

{
  "cdx_identity_plane": true,
  "cdx_graph_dependency": false,
  "cdx_stateless_engine": false,
  "cdx_deployment_context": "azure_monitor_scheduled_query_identity_detection",
  "cdx_scope_required": "tenant_and_workspace_scope_must_be_defined",
  "cdx_fidelity_warning": "privileged-role inventory is required for low-noise operation"
}

Rule Name

Microsoft Graph Application Password Credential Creation

MITRE ATT&CK

·        T1098 – Account Manipulation

Purpose

Detect Microsoft Graph API use that adds a password credential to an application object.

Azure Rule Type
Azure Monitor Scheduled Query Rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        MicrosoftGraphActivityLogs ingested to Log Analytics

·        approved automation exclusions defined

·        scheduled query rule deployed with action group

·        workspace scope defined

·        evaluation model defined:

o   run every 5 minutes

o   look back 5 minutes

o   alert on any returned result

Enforcement Method

·        Query MicrosoftGraphActivityLogs

·        Match:

o   RequestMethod == "POST"

o   RequestUri for /applications/{id}/addPassword

o   successful response

·        Exclude approved automation identities directly in query

Standalone Alerting Justification

Permitted because Microsoft Graph activity logs provide an audit trail of Graph API requests, and Microsoft Graph documents the application addPassword endpoint explicitly.

Implementation Constraint Notes

·        Query must stay scoped to MicrosoftGraphActivityLogs

·        Automation exclusions must be enforced in query, not only in notes

·        Do not broaden to generic application updates

Tuning Explanation

This rule is strong because it targets the exact Graph endpoint used to create an application secret and now includes explicit allowlist hooks to keep noise low.

Expected Noise Profile

·        Low when approved automation is excluded

·        Moderate if legitimate secret rotation is common and allowlists are incomplete

Variant Analysis

Covered

·        application password credential creation through Graph

·        persistence by adding new application secrets

Gaps

·        certificate-based credential creation through different endpoints

·        use of pre-existing credentials

·        secret changes outside Graph logging scope

Compensating Controls

·        service principal credential-creation rule

·        app governance and secret rotation review

·        SIEM correlation for downstream token use

Execution Validity Statement

Executable as a production scheduled query rule when MicrosoftGraphActivityLogs are ingested and approved automation exclusions are defined.

Rule Regret Check

Deployment caution
Requires Graph log ingestion and maintained allowlists for approved automation.

Confidence caution
Will not detect use of existing application credentials.

Coverage value
High-confidence persistence detection for application credentials.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines approved application and service principal automation identities.

System-ready code

let ApprovedAppIds = dynamic(["APPID_ALLOWLIST_PLACEHOLDER"]);
let ApprovedServicePrincipals = dynamic(["SPN_ALLOWLIST_PLACEHOLDER"]);
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(5m)
| where RequestMethod == "POST"
| where RequestUri matches regex @"/applications/[^/]+/addPassword"
| where ResponseStatusCode between (200 .. 299)
| where AppId !in (ApprovedAppIds)
| where ServicePrincipalId !in (ApprovedServicePrincipals)
| project TimeGenerated, AppId, ServicePrincipalId, UserId, IPAddress, RequestUri, ResponseStatusCode

Alert Evaluation Model

·        Frequency: every 5 minutes

·        Lookup window: last 5 minutes

·        Trigger: greater than 0 results

Enforcement Metadata

{
  "cdx_identity_plane": true,
  "cdx_graph_dependency": true,
  "cdx_stateless_engine": false,
  "cdx_deployment_context": "azure_monitor_scheduled_query_graph_detection",
  "cdx_scope_required": "workspace_ingestion_and_allowlists_must_be_defined",
  "cdx_fidelity_warning": "approved automation exclusions are required for low-noise operation"
}

Rule Name

Microsoft Graph Service Principal Password Credential Creation

MITRE ATT&CK

·        T1098 – Account Manipulation

Purpose

Detect Microsoft Graph API use that adds a password credential to a service principal.

Azure Rule Type

Azure Monitor Scheduled Query Rule

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        MicrosoftGraphActivityLogs ingested to Log Analytics

·        approved automation exclusions defined

·        scheduled query rule deployed with action group

·        workspace scope defined

·        evaluation model defined:

o   run every 5 minutes

o   look back 5 minutes

o   alert on any returned result

Enforcement Method

·        Query MicrosoftGraphActivityLogs

·        Match:

o   RequestMethod == "POST"

o   RequestUri for /servicePrincipals/{id}/addPassword

o   successful response

·        Exclude approved automation identities directly in query

Standalone Alerting Justification

Permitted because Microsoft Graph activity logs record the API request, and Microsoft Graph documents the service principal addPassword endpoint explicitly.

Implementation Constraint Notes

Query must stay scoped to MicrosoftGraphActivityLogs

·        Approved automation must be excluded in query

·        Do not collapse this into generic service principal modifications

Tuning Explanation

This is a narrow, high-confidence Graph-native secret-creation detection and now includes direct allowlist hooks to reduce noise.

Expected Noise Profile

·        Low when approved automation is excluded

·        Moderate if legitimate service principal secret rotation is common and allowlists are incomplete

Variant Analysis

Covered

·        service principal password credential creation through Graph

·        persistence by adding new service principal secrets

Gaps

·        certificate-based credential creation through other endpoints

·        use of existing service principal credentials

·        non-Graph credential changes

Compensating Controls

·        application password credential rule

·        service principal sign-in monitoring

·        downstream Graph or token-use detections

Execution Validity Statement

Executable as a production scheduled query rule when MicrosoftGraphActivityLogs are ingested and automation exclusions are defined.

Rule Regret Check

Deployment caution

Requires Graph log ingestion and approved automation exclusions.

Confidence caution
Will not detect use of existing service principal credentials.

Coverage value
High-confidence persistence detection for service principal credentials.

Production Ready

Yes, with declared customer dependencies

Engineering Note

This rule is only complete when the customer defines approved service principal secret-management workflows.

System-ready code

let ApprovedAppIds = dynamic(["APPID_ALLOWLIST_PLACEHOLDER"]);
let ApprovedServicePrincipals = dynamic(["SPN_ALLOWLIST_PLACEHOLDER"]);
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(5m)
| where RequestMethod == "POST"
| where RequestUri matches regex @"/servicePrincipals/[^/]+/addPassword"
| where ResponseStatusCode between (200 .. 299)
| where AppId !in (ApprovedAppIds)
| where ServicePrincipalId !in (ApprovedServicePrincipals)
| project TimeGenerated, AppId, ServicePrincipalId, UserId, IPAddress, RequestUri, ResponseStatusCode

Alert Evaluation Model

·        Frequency: every 5 minutes

·        Lookup window: last 5 minutes

·        Trigger: greater than 0 results

Enforcement Metadata

{
  "cdx_identity_plane": true,
  "cdx_graph_dependency": true,
  "cdx_stateless_engine": false,
  "cdx_deployment_context": "azure_monitor_scheduled_query_graph_detection",
  "cdx_scope_required": "workspace_ingestion_and_allowlists_must_be_defined",
  "cdx_fidelity_warning": "approved automation exclusions are required for low-noise operation"
}

GCP

Required Supporting Dependencies

Project / Org Scope

·        all projects OR org-level aggregation

Privileged Role Inventory

Example:

·        roles/owner

·        roles/editor

·        roles/iam.securityAdmin

·        roles/resourcemanager.projectIamAdmin

Approved Automation Allowlist

·        service accounts

·        CI/CD pipelines

Rule Name

Privileged IAM Policy Binding Creation

MITRE ATT&CK

·        T1098 – Account Manipulation

·        T1078 – Valid Accounts

Purpose

Detect IAM bindings granting privileged roles.

GCP Rule Type

Eventarc Trigger (Audit Log)

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Admin Activity logs enabled

·        Eventarc trigger deployed org-wide

·        privileged roles defined

Enforcement Method

·        Match:

o   SetIamPolicy

·        Parse IAM bindings

·        Require privileged role match

·        Exclude allowlisted automation

Standalone Alerting Justification

IAM policy change is direct privilege escalation.

Implementation Constraint Notes

·        Must filter roles explicitly

·        Must exclude automation in logic

Tuning Explanation

Now requires:

·        privileged role

·        non-allowlisted actor

Expected Noise Profile

Low

Variant Analysis

Covered

·        privilege escalation via IAM

Gaps

·        misuse of existing privileges

Execution Validity Statement

Executable as Eventarc trigger.

Rule Regret Check

Deployment caution

Requires role list and allowlist

Confidence caution
Does not detect privilege misuse

Coverage value

High-confidence escalation detection

Production Ready

Yes, with declared dependencies

Engineering Note

Customer must define:

·        privileged roles

·        allowed automation identities

System-ready code

{
  "eventFilters": [
    {
      "attribute": "type",
      "value": "google.cloud.audit.log.v1.written"
    }
  ],
  "eventDataContentType": "application/json",
  "serviceName": "cloudresourcemanager.googleapis.com",
  "methodName": "SetIamPolicy",
  "condition": {
    "expression": "
      protoPayload.methodName == 'SetIamPolicy' &&
      protoPayload.serviceName == 'cloudresourcemanager.googleapis.com' &&
      (
        protoPayload.serviceData.policyDelta.bindingDeltas.exists(b,
          b.role in [
            'roles/owner',
            'roles/editor',
            'roles/iam.securityAdmin',
            'roles/resourcemanager.projectIamAdmin'
          ]
        )
      ) &&
      !(
        protoPayload.authenticationInfo.principalEmail in [
          'ALLOWLIST@PROJECT.iam.gserviceaccount.com'
        ]
      )
    "
  },
  "x-cyberdax-requirements": {
    "cdx_control_plane_only": true,
    "cdx_stateless_engine": true,
    "cdx_deployment_context": "gcp_eventarc_audit_log_detection",
    "cdx_scope_required": "org_or_all_projects_required",
    "cdx_fidelity_enforcement": "privileged_roles_and_allowlist_required"
  }
}

Rule Name

Service Account Key Creation

MITRE ATT&CK

·        T1098 – Account Manipulation

Purpose

Detect creation of new service account keys.

GCP Rule Type

Eventarc Trigger

Classification

Alert-capable

SOC Usage Mode

Alert-capable

Minimum Deployment Requirement

·        Admin Activity logs enabled

·        org/project scope defined

·        allowlist defined

Enforcement Method

·        Match:

o   CreateServiceAccountKey

·        Exclude approved service accounts

Standalone Alerting Justification

Creates long-term credential.

Implementation Constraint Notes

·        Must enforce allowlist in logic

Tuning Explanation

Now enforces:

·        event match

·        allowlist exclusion

Expected Noise Profile

Low

Variant Analysis

Covered

·        SA key creation

Gaps

·        key usage

·        token abuse

Execution Validity Statement

Executable via Eventarc.

Rule Regret Check

Deployment caution

Requires allowlist

Confidence caution
Does not detect key usage

Coverage value

Strong persistence detection

Production Ready

Yes, with declared dependencies

Engineering Note

Customer must define:

·        approved service accounts

System-ready code

{
  "eventFilters": [
    {
      "attribute": "type",
      "value": "google.cloud.audit.log.v1.written"
    }
  ],
  "eventDataContentType": "application/json",
  "serviceName": "iam.googleapis.com",
  "methodName": "google.iam.admin.v1.CreateServiceAccountKey",
  "condition": {
    "expression": "
      protoPayload.methodName == 'google.iam.admin.v1.CreateServiceAccountKey' &&
      !(
        protoPayload.authenticationInfo.principalEmail in [
          'ALLOWLIST@PROJECT.iam.gserviceaccount.com'
        ]
      )
    "
  },
  "x-cyberdax-requirements": {
    "cdx_control_plane_only": true,
    "cdx_stateless_engine": true,
    "cdx_deployment_context": "gcp_eventarc_audit_log_detection",
    "cdx_scope_required": "org_or_project_scope_required",
    "cdx_fidelity_enforcement": "allowlist_required"
  }
}

S26 — Threat-to-Rule Traceability Matrix

Behavior

Phishing delivery and user interaction with malicious link or attachment

MITRE ATT&CK

·        T1566 – Phishing

Detection Mapping

·        Suricata — Suspicious Login-Themed DNS Query Followed by Non-Sanctioned TLS SNI Access

·        SentinelOne — Browser Access to Non-Sanctioned Login Infrastructure

·        Splunk — Correlated Phishing Interaction → Suspicious Authentication → Suspicious External Login Infrastructure Access

·        Elastic — Suspicious External Authentication Domain Access Rule

·        QRadar — Suspicious External Authentication Domain Access Rule

·        Sigma — Suspicious External Authentication Domain Access Rule

Telemetry Dependency

·        Email security gateway logs

·        DNS logs

·        web proxy logs

·        endpoint web telemetry

Infrastructure Intelligence

·        newly registered domains

·        login-themed domain patterns

·        low-prevalence domain clusters

Coverage Disposition

Partially Detected

Detection Notes

Email delivery without user interaction is not covered by S25 rules. Detection primarily occurs at user interaction and subsequent network access stages.

Behavior

Credential harvesting via phishing page (username and password capture)

MITRE ATT&CK

·        T1056 – Input Capture

Detection Mapping

·        Suricata — Outbound Credential Submission to Non-Sanctioned Login-Themed Host

·        YARA — External Credential-Harvesting HTML or JavaScript Page Artifact

·        SentinelOne — Browser Access to Non-Sanctioned Login Infrastructure

Telemetry Dependency

·        HTTP request inspection or proxy logs

·        endpoint file/artifact telemetry

·        DNS/web logs

Infrastructure Intelligence

·        external POST destinations

·        phishing kit reuse patterns

·        credential capture endpoints

Coverage Disposition

Partially Detected

Detection Notes

Detection depends on HTTP visibility or artifact recovery. Encrypted traffic without inspection reduces detection reliability.

Behavior

User credential submission to attacker-controlled infrastructure

MITRE ATT&CK

·        T1056 – Input Capture

Detection Mapping

·        Suricata — Outbound Credential Submission to Non-Sanctioned Login-Themed Host

·        Splunk — Correlated Phishing Interaction → Suspicious Authentication → Suspicious External Login Infrastructure Access

·        Elastic — Suspicious Credential POST Detection

·        QRadar — Credential Submission to External Domain Rule

·        Sigma — Suspicious Credential POST Detection

Telemetry Dependency

·        HTTP request telemetry

·        proxy logs

·        DNS logs

Infrastructure Intelligence

·        external authentication endpoints

·        anomalous POST destinations

·        domain reputation and age

Coverage Disposition

Partially Detected

Detection Notes

Detection is strong where request body inspection exists. Without TLS decryption, coverage is reduced.

Behavior

Reverse-proxy phishing and session cookie/token capture

MITRE ATT&CK

·        T1539 – Steal Web Session Cookie

Detection Mapping

·        YARA — Reverse-Proxy Phishing Kit Configuration Artifact

·        SentinelOne — Non-Browser Access to Browser Credential / Session Stores

·        Splunk — Session Token Anomaly Detection

·        Elastic — External Failure Burst Followed by Successful Authentication

·        QRadar — External Failure Burst Followed by Successful Authentication

·        Sigma — External Failure Burst Followed by Successful Authentication

Telemetry Dependency

·        endpoint telemetry (file + process)

·        identity provider logs

·        session metadata

Infrastructure Intelligence

·        reverse-proxy frameworks

·        session forwarding patterns

·        TLS certificate reuse

Coverage Disposition
Partially Detected

Detection Notes

Session theft itself is rarely directly observable. Detection relies on downstream behavioral anomalies and artifact discovery.

Behavior

Initial authentication using stolen credentials

MITRE ATT&CK

·        T1078 – Valid Accounts

Detection Mapping

·        Splunk — External Failure Burst Followed by Successful Access into New Application Context

·        Elastic — External Failure Burst Followed by Successful Authentication

·        QRadar — External Failure Burst Followed by Successful Authentication

·        Sigma — External Failure Burst Followed by Successful Authentication

Telemetry Dependency

·        Entra Sign-in Logs

·        AWS CloudTrail authentication logs

·        GCP Audit Logs

·        identity provider logs

Infrastructure Intelligence

·        IP reputation

·        ASN deviation

·        geographic anomalies

Coverage Disposition

Partially Detected

Detection Notes

Detection depends on anomaly detection and correlation. Single successful login events are not inherently detectable.

Behavior

Password spraying from a single external source

MITRE ATT&CK

·        T1110 – Brute Force

Detection Mapping

·        Suricata — Repeated Authentication POSTs to Protected Public Authentication Endpoints

·        Splunk — Distributed Password Spraying from External Source

·        Elastic — External Password Spraying from Single Source

·        QRadar — External Password Spraying from Single Source

·        Sigma — External Password Spraying from Single Source

Telemetry Dependency

·        authentication logs

·        network authentication endpoints

·        SIEM aggregation

Infrastructure Intelligence

·        repeated source IP behavior

·        authentication endpoint targeting patterns

Coverage Disposition

Partially Detected

Detection Notes

Effective for concentrated attacks. Does not fully cover distributed or low-volume spraying.

Behavior

Distributed password spraying across multiple sources

MITRE ATT&CK

·        T1110 – Brute Force

Detection Mapping

·        Elastic — Distributed Password Spraying Across Multiple Sources

·        QRadar — Distributed Password Spraying Across Multiple Sources

·        Sigma — Distributed Password Spraying Across Multiple Sources

Telemetry Dependency

·        centralized authentication logs

·        SIEM aggregation capability

Infrastructure Intelligence

·        distributed IP clusters

·        coordinated attack timing

Coverage Disposition

Partially Detected

Detection Notes

Requires aggregation across multiple sources. Not detectable at single-system level without correlation.

Behavior

Browser credential store and session data access

MITRE ATT&CK

·        T1555 – Credentials from Password Stores

·        T1539 – Steal Web Session Cookie

Detection Mapping

·        SentinelOne — Non-Browser Access to Browser Credential / Session Stores

·        YARA — Browser Credential and Session Store Theft Tool or Script Artifact

Telemetry Dependency

·        endpoint file access telemetry

·        process monitoring

·        artifact scanning

Infrastructure Intelligence

·        known credential storage paths

·        extraction tooling patterns

Coverage Disposition

Detected

Detection Notes

High-confidence endpoint detection when file access telemetry is available and exclusions are tuned.

Behavior

Browser-driven execution of malicious or suspicious payloads

MITRE ATT&CK

·        T1204 – User Execution

·        T1059 – Command and Scripting Interpreter

Detection Mapping

·        SentinelOne — Browser-Initiated Execution of Suspicious Child Process

Telemetry Dependency

·        process creation telemetry

·        command-line visibility

Infrastructure Intelligence

·        LOLBin execution patterns

·        script execution indicators

Coverage Disposition

Detected

Detection Notes

Strong behavioral signal with low noise when parent-child relationships are enforced.

Behavior

Application credential creation via Microsoft Graph

MITRE ATT&CK

·        T1098 – Account Manipulation

Detection Mapping

·        Azure — Microsoft Graph Application Password Credential Creation

Telemetry Dependency

·        MicrosoftGraphActivityLogs

Infrastructure Intelligence

·        Graph API endpoint usage

·        application identity changes

Coverage Disposition

Detected

Detection Notes

Direct API-level visibility provides high-confidence detection.

Behavior

Service principal credential creation via Microsoft Graph

MITRE ATT&CK

·        T1098 – Account Manipulation

Detection Mapping

·        Azure — Microsoft Graph Service Principal Password Credential Creation

Telemetry Dependency

·        MicrosoftGraphActivityLogs

Infrastructure Intelligence

·        service principal modification patterns

Coverage Disposition

Detected

Detection Notes

High-confidence persistence detection.

Behavior

AWS root account misuse and credential creation

MITRE ATT&CK

·        T1078 – Valid Accounts

·        T1098 – Account Manipulation

Detection Mapping

·        AWS — Root Console Login Success Without MFA

·        AWS — Root Access Key Creation

Telemetry Dependency

·        AWS CloudTrail

Infrastructure Intelligence

·        root account usage patterns

Coverage Disposition

Detected

Detection Notes

Very high-confidence detection with minimal noise.

Behavior

Privileged role assignment and escalation in cloud identity systems

MITRE ATT&CK

·        T1098 – Account Manipulation

Detection Mapping

·        Azure — Privileged Role Assignment in Microsoft Entra Audit Logs

·        GCP — Privileged IAM Policy Binding Creation

Telemetry Dependency

·        Entra AuditLogs

·        GCP Audit Logs

Infrastructure Intelligence

·        role binding changes

·        privilege escalation patterns

Coverage Disposition

Detected

Detection Notes

Direct control-plane detection with strong fidelity.

Behavior

Service account or cloud credential key creation

MITRE ATT&CK

·        T1098 – Account Manipulation

Detection Mapping

·        GCP — Service Account Key Creation

Telemetry Dependency

·        GCP Audit Logs

Infrastructure Intelligence

·        credential issuance patterns

Coverage Disposition

Detected

Detection Notes

High-confidence persistence detection.

Behavior

AssumeRole activity without required attribution (SourceIdentity gap)

MITRE ATT&CK

·        T1078 – Valid Accounts

Detection Mapping

·        AWS — AssumeRole to Sensitive Role Without Required SourceIdentity

Telemetry Dependency

·        AWS CloudTrail

Infrastructure Intelligence

·        role assumption patterns

·        attribution gaps

Coverage Disposition

Partially Detected

Detection Notes

Detection is conditional on governance enforcement of SourceIdentity requirements.

Behavior

Authenticated session misuse and anomalous access behavior

MITRE ATT&CK

·        T1078 – Valid Accounts

Detection Mapping

·        Splunk — Correlated Phishing Interaction → Suspicious Authentication → Suspicious External Login Infrastructure Access

·        Elastic — External Failure Burst Followed by Successful Authentication

·        QRadar — External Failure Burst Followed by Successful Authentication

·        Sigma — External Failure Burst Followed by Successful Authentication

Telemetry Dependency

·        identity logs

·        endpoint telemetry

·        network telemetry

Infrastructure Intelligence

·        anomalous session patterns

·        abnormal access timing

Coverage Disposition

Hunt Only

Detection Notes

No deterministic detection exists. Requires behavioral correlation and analyst investigation.

‍ ‍

S27 Behavior and Log Artifacts

‍ ‍

Email Security Gateway Behavior and Log Artifacts

‍ ‍

Phishing delivery and user interaction behavior manifests through observable email metadata, link interaction events, and campaign-level delivery patterns.

‍ ‍

·        Email logs show inbound messages with mismatched sender domains and reply-to fields inconsistent with originating infrastructure

‍ ‍

·        Header analysis reveals authentication anomalies, including SPF, DKIM, or DMARC failures associated with external sender domains

‍ ‍

·        URL rewriting or inspection logs capture embedded links directing to recently registered or low-prevalence domains

‍ ‍

·        User interaction telemetry records link click events or attachment access shortly after message delivery

‍ ‍

·        Campaign clustering appears as multiple users receiving structurally similar messages within a constrained time window

‍ ‍

These artifacts establish initial access behavior and provide the earliest indication of user-targeting activity.

‍ ‍

Endpoint / EDR Behavior and Log Artifacts

‍ ‍

Post-interaction behavior is observable through endpoint process execution, session initiation, and device association patterns following credential use.

‍ ‍

·        Process creation logs show browser execution events initiated shortly after email interaction activity

‍ ‍

·        Parent-child process relationships indicate user-driven access to external authentication portals or login pages

‍ ‍

·        Endpoint session logs reflect first-time device usage associated with the authenticated identity

‍ ‍

·        Browser telemetry captures navigation to external domains associated with previously unseen or low-prevalence infrastructure

‍ ‍

·        Session persistence artifacts indicate continued access without expected re-authentication events

‍ ‍

These artifacts confirm user interaction and provide evidence of session establishment and initial post-compromise activity.

‍ ‍

DNS / Web Proxy Behavior and Log Artifacts

‍ ‍

Adversary-controlled infrastructure interaction is visible through DNS queries and outbound network connections to suspicious or low-prevalence domains.

‍ ‍

·        DNS logs record queries to recently registered domains or domains with minimal historical presence

‍ ‍

·        Query patterns show repeated resolution attempts to domains used in credential harvesting or phishing delivery

‍ ‍

·        Web proxy logs capture outbound HTTP or HTTPS requests to domains mimicking authentication services

‍ ‍

·        Domain lifecycle artifacts show short-lived domain usage followed by rapid disappearance from query patterns

‍ ‍

·        Network logs reflect user-aligned connections to previously unseen external infrastructure

‍ ‍

These artifacts provide visibility into external communication patterns associated with credential harvesting and initial access infrastructure.

‍ ‍

Identity and Authentication Behavior and Log Artifacts

‍ ‍

Credential misuse behavior is reflected in authentication logs, session anomalies, and deviations from established identity patterns.

‍ ‍

·        Authentication logs show successful login events from unfamiliar IP addresses or geographic regions

‍ ‍

·        Login sequences reflect rapid transitions from failed authentication attempts to successful access

‍ ‍

·        Session metadata indicates new device identifiers or access contexts not previously associated with the identity

‍ ‍

·        Application access logs show first-time access to services outside normal usage patterns

‍ ‍

·        MFA logs capture abnormal prompt patterns, including repeated requests or unusual approval sequences

‍ ‍

These artifacts represent direct evidence of credential compromise and active account misuse.

‍ ‍

Service Interaction and Availability Behavior and Log Artifacts

‍ ‍

Service-level behavior associated with scanning, exploitation, and disruption is observable through traffic patterns and system performance indicators.

‍ ‍

·        Web server logs show increased request frequency targeting specific endpoints or application paths

‍ ‍

·        Traffic analysis reveals spikes in inbound connections exceeding established baseline thresholds

‍ ‍

·        Source IP distribution reflects high-volume requests originating from distributed or rotating address ranges

‍ ‍

·        API logs capture repeated or abnormal request sequences inconsistent with legitimate usage patterns

‍ ‍

·        Performance metrics indicate service degradation or latency increases correlated with abnormal traffic activity

‍ ‍

These artifacts provide evidence of opportunistic exploitation attempts and disruption-focused activity.

‍ ‍

Cross-Pillar Correlated Behavior and Log Artifacts

‍ ‍

High-confidence detection is achieved by correlating artifacts across telemetry sources to identify multi-stage activity tied to a single identity or coordinated event sequence.

‍ ‍

·        Email interaction events are followed by authentication anomalies linked to the same user identity within a constrained timeframe

‍ ‍

·        Authentication anomalies correlate with first-time endpoint activity and new external network connections

‍ ‍

·        DNS queries to newly observed domains precede or coincide with anomalous login events

‍ ‍

·        Multiple users exhibit similar phishing interaction patterns followed by distributed authentication anomalies

‍ ‍

·        Identity-level anomalies align with abnormal service interaction or access to sensitive resources

‍ ‍

These correlated artifacts represent full attack progression and significantly increase detection confidence while reducing false positives.

S28 Detection Strategy and SOC Implementation Guidance

‍ ‍

Detection Strategy Implementation Model

‍ ‍

Detection must be operationalized as identity-centric, correlation-driven workflows that prioritize credential misuse and multi-stage attack progression over isolated event detection.

‍ ‍

·        Detection workflows must trigger on identity anomalies, specifically authentication events that deviate from established user behavior baselines

‍ ‍

·        Email interaction, authentication activity, endpoint behavior, and network communication must be correlated within defined time windows to establish attack sequence continuity

‍ ‍

·        Detection logic must require multi-event validation, ensuring that alerts are generated only when activity forms a coherent progression rather than isolated anomalies

‍ ‍

·        Identity telemetry must serve as the primary correlation anchor, linking user activity across email, endpoint, and network layers

‍ ‍

·        Detection pipelines must enrich events with user identity, device association, domain intelligence, and historical behavioral context prior to alert generation

‍ ‍

Detection effectiveness is dependent on enforcing sequence-based validation of identity misuse rather than relying on single-event detection models.

‍ ‍

SOC Triage and Investigation Workflow

‍ ‍

SOC triage must validate whether correlated activity represents credential compromise by confirming linkage between user interaction, authentication anomalies, and subsequent system access.

‍ ‍

·        Triage must first determine whether phishing interaction events are temporally linked to authentication anomalies for the same user identity

‍ ‍

·        Analysts must validate whether authentication events originate from unfamiliar IP addresses, geolocations, or device contexts

‍ ‍

·        Endpoint investigation must confirm whether browser activity or session initiation aligns with the authentication event timeline

‍ ‍

·        Network analysis must determine whether accessed domains are previously unseen, low-prevalence, or consistent with credential harvesting infrastructure

‍ ‍

·        Escalation must occur when multiple correlated signals are observed within a constrained timeframe and tied to a single identity

‍ ‍

Accurate triage requires identity-linked correlation across telemetry sources to distinguish malicious activity from legitimate user behavior.

‍ ‍

Detection Prioritization and Alerting Strategy

‍ ‍

Alerting must prioritize high-confidence identity compromise scenarios and suppress alerts generated from isolated or low-signal events.

‍ ‍

·        Alerts must be generated only when phishing interaction, authentication anomaly, and supporting endpoint or network activity are correlated

‍ ‍

·        Single-source detections, including standalone DNS queries or isolated authentication anomalies, must be treated as enrichment or hunt signals rather than alert conditions

‍ ‍

·        Identity-based detections must be prioritized over infrastructure-based detections due to higher reliability and earlier detection value

‍ ‍

·        Alert severity must increase when activity includes first-time device usage, abnormal access timing, or access to sensitive systems or services

‍ ‍

·        Detection logic must suppress activity associated with known benign domains, trusted applications, and established user behavior patterns

‍ ‍

Effective alerting requires enforcing multi-signal validation and suppressing non-correlated events to reduce false positives and analyst fatigue.

‍ ‍

Correlation and Detection Engineering Guidance

‍ ‍

Detection engineering must enforce identity-linked, time-bound correlation logic that prevents standalone signal alerting and ensures multi-stage validation.

‍ ‍

·        Correlation logic must link phishing interaction events to authentication anomalies using user identity as the primary correlation key

‍ ‍

·        Detection rules must enforce time-bound constraints to ensure events represent a valid attack sequence

‍ ‍

·        Network activity must be enriched with domain intelligence to identify previously unseen or low-prevalence domains associated with credential harvesting

‍ ‍

·        Endpoint telemetry must be correlated with identity events to confirm user-driven access and session establishment

‍ ‍

·        Detection workflows must explicitly prevent alert generation from single telemetry sources without supporting correlated activity

‍ ‍

Correlation enforcement is required to ensure detection accuracy and prevent false positives from isolated events.

‍ ‍

Operational Constraints and Implementation Considerations

‍ ‍

Detection capability is directly constrained by telemetry coverage, data quality, and correlation capability across systems.

‍ ‍

·        Environments without email interaction telemetry lack visibility into initial phishing activity and user targeting behavior

‍ ‍

·        Limited endpoint visibility prevents confirmation of user-driven activity and session establishment following authentication events

‍ ‍

·        Absence of DNS or web proxy logging eliminates visibility into communication with adversary-controlled infrastructure

‍ ‍

·        Lack of identity baselining reduces the ability to detect anomalous authentication behavior and increases false positive rates

‍ ‍

·        Absence of centralized correlation capability prevents identification of multi-stage attack progression and delays detection

‍ ‍

Detection effectiveness is contingent on complete telemetry coverage, identity context, and cross-source correlation capability.

‍ ‍

S29 Detection Coverage Summary

‍ ‍

Detected Behaviors

‍ ‍

These behaviors are reliably detectable using available telemetry and correlation logic defined in S21–S28, with high confidence when multi-pillar signals are present.

‍ ‍

·        Phishing delivery and user interaction events observable through email security gateway telemetry, including link clicks and attachment access (T1566 – Phishing)

‍ ‍

·        Authentication anomalies indicating credential misuse, including logins from unfamiliar IP addresses, geolocations, or devices (T1078 – Valid Accounts)

‍ ‍

·        First-time device usage and session establishment following anomalous authentication events

‍ ‍

·        DNS and web proxy activity involving newly registered or low-prevalence domains associated with credential harvesting infrastructure

‍ ‍

·        Correlated multi-stage activity linking phishing interaction, authentication anomalies, and endpoint or network behavior within a constrained timeframe

‍ ‍

Partially Detected Behaviors

‍ ‍

These behaviors are observable but may not be consistently or fully detected depending on correlation maturity, baselining, and environmental visibility.

‍ ‍

·        Password spraying and distributed brute force attempts across multiple systems or authentication endpoints (T1110 – Brute Force)

‍ ‍

·        User access to credential harvesting portals through browser-based interaction

‍ ‍

·        Session persistence or token reuse activity following successful authentication

‍ ‍

·        Interaction with adversary-controlled infrastructure using disposable or short-lived domains

‍ ‍

·        Distributed scanning or low-volume exploitation attempts targeting internet-facing services (T1190 – Exploit Public-Facing Application)

‍ ‍

Conditional Post-Exploitation Behaviors

‍ ‍

Not observed in currently available reporting; may occur during post-exploitation depending on attacker objectives and target environment.

‍ ‍

·        Lateral movement using valid credentials across internal systems or services (T1021 – Remote Services)

‍ ‍

·        Privilege escalation through misuse of existing account permissions or access rights (T1068 – Exploitation for Privilege Escalation)

‍ ‍

·        Data exfiltration via application-layer protocols or cloud services following successful account compromise (T1041 – Exfiltration Over C2 Channel)

‍ ‍

·        Persistence through continued use of compromised credentials, authentication tokens, or session hijacking (T1078 – Valid Accounts)

‍ ‍

·        Internal reconnaissance activity, including enumeration of services, users, or network resources (T1087 – Account Discovery)

‍ ‍

S30 Intelligence Maturity Assessment

‍ ‍

Detection Maturity

‍ ‍

Detection maturity reflects the organization’s ability to identify credential misuse, phishing-driven access, and multi-stage attack progression using correlated behavioral signals.

‍ ‍

·        Low Maturity
Detection relies on isolated alerts such as phishing indicators or authentication anomalies without enforced correlation across telemetry sources
Credential misuse is typically undetected unless accompanied by obvious indicators such as repeated authentication failures or known malicious infrastructure

‍ ‍

·        Moderate Maturity
Detection incorporates correlation between authentication anomalies and selected endpoint or network signals
Behavioral baselining is partially implemented, resulting in inconsistent detection across users, devices, and access patterns

‍ ‍

·        High Maturity
Detection enforces identity-centric, multi-pillar correlation linking phishing interaction, authentication anomalies, endpoint activity, and network communication
Detection logic consistently identifies multi-stage attack progression and minimizes reliance on static indicators

‍ ‍

Higher detection maturity enables earlier identification of credential misuse and reduces attacker dwell time.

‍ ‍

Telemetry Maturity

‍ ‍

Telemetry maturity reflects the completeness, quality, and accessibility of data required to detect phishing, credential misuse, and adversary-controlled infrastructure interaction.

‍ ‍

·        Low Maturity
Limited visibility into email interaction, endpoint activity, or DNS and web traffic
Authentication logs lack sufficient detail or enrichment to support anomaly detection

‍ ‍

·        Moderate Maturity
Core telemetry sources are present, including email, endpoint, and authentication logs
Visibility gaps remain in DNS logging, session context, or encrypted traffic inspection

‍ ‍

·        High Maturity
Comprehensive telemetry coverage across email, endpoint, identity, and network layers
Data is enriched with domain intelligence, user context, device association, and historical baselines

‍ ‍

Higher telemetry maturity enables consistent detection across multiple attack vectors and reduces dependence on single-source visibility.

‍ ‍

Correlation and Analytical Maturity

‍ ‍

Correlation maturity reflects the organization’s ability to link events across telemetry sources and identify multi-stage attack behavior.

‍ ‍

·        Low Maturity
Events are analyzed in isolation with no consistent cross-source correlation
Detection depends on standalone alerts rather than sequence-based analysis

‍ ‍

·        Moderate Maturity
Correlation exists between selected telemetry sources, such as authentication and endpoint activity
Time-bound correlation and identity mapping are inconsistently applied

‍ ‍

·        High Maturity
Correlation logic links email interaction, authentication anomalies, endpoint activity, and network communication using identity as the primary anchor
Detection consistently identifies attack sequences rather than individual events

‍ ‍

High correlation maturity significantly improves detection accuracy and reduces false positives.

‍ ‍

SOC Operational Maturity

‍ ‍

SOC maturity reflects the organization’s ability to triage, investigate, and respond to correlated detection events in a timely and consistent manner.

‍ ‍

·        Low Maturity
Triage is manual and reactive, with limited ability to correlate signals across telemetry sources
Investigation workflows are inconsistent and dependent on individual analyst interpretation

‍ ‍

·        Moderate Maturity
Defined triage workflows exist for phishing and authentication anomalies
Analysts can perform correlation across systems, but processes remain partially manual

‍ ‍

·        High Maturity
SOC workflows are structured around identity-centric correlation and multi-stage attack validation
Triage, investigation, and escalation are standardized and supported by automated enrichment

‍ ‍

Higher SOC maturity enables faster detection, consistent investigation, and reduced response time.

‍ ‍

Security Hardening and Preventive Control Maturity

‍ ‍

Security hardening maturity reflects the organization’s ability to reduce exposure to credential-based attacks through preventive controls and configuration management.

‍ ‍

·        Low Maturity
Multi-factor authentication is inconsistently applied or absent across systems
Identity and device controls are weak or not enforced

‍ ‍

·        Moderate Maturity
Multi-factor authentication is implemented for critical systems with partial enforcement of access controls
Device and identity restrictions are applied inconsistently

‍ ‍

·        High Maturity
Strong enforcement of identity-based access controls, including consistent multi-factor authentication and device validation
Access policies are aligned with behavioral baselines and risk-based authentication models

‍ ‍

Higher hardening maturity reduces the likelihood of successful credential compromise and limits attack surface.

‍ ‍

Variant Resilience Maturity

‍ ‍

Variant resilience reflects the organization’s ability to detect alternate forms of credential misuse, phishing delivery, and infrastructure interaction independent of specific tools or delivery methods.

‍ ‍

·        Low Maturity
Detection depends on specific indicators or known patterns
Variants such as token-based authentication, API access, or non-email phishing delivery are not consistently detected

‍ ‍

·        Moderate Maturity
Detection covers multiple variants of phishing and authentication activity but remains dependent on specific telemetry sources
Alternate access methods are partially detectable but inconsistent across environments

‍ ‍

·        High Maturity
Detection is behavior-driven and independent of delivery method, authentication mechanism, or protocol
Variants including token reuse, API-based access, and alternate phishing channels are detected through identity-centric correlation

‍ ‍

‍ ‍

High variant resilience ensures detection remains effective even when adversaries change tooling, infrastructure, or delivery mechanisms.

‍ ‍

S31 Defensive Architecture Overview

‍ ‍

The defensive architecture required to mitigate this threat must prioritize identity-centric security controls, behavioral detection, and cross-telemetry correlation to address credential-based intrusion and authentication abuse.

‍ ‍

‍ ‍

Traditional perimeter and vulnerability-focused defenses are insufficient, as adversaries operate within legitimate authentication pathways and do not rely on exploit-based access.

‍ ‍

‍ ‍

Effective defense requires integrated visibility across:

‍ ‍

·        Email security gateway telemetry

‍ ‍

·        Endpoint and EDR process telemetry

‍ ‍

·        DNS and web proxy network telemetry

‍ ‍

‍ ‍

Defensive architecture must enable correlation across these telemetry pillars to detect transitions from phishing interaction to credential misuse and post-authentication activity.

‍ ‍

Identity systems and authentication services must be treated as primary security control boundaries, with enforcement and monitoring applied directly at the identity layer.

‍ ‍

S32 Defensive Control Implementation

‍ ‍

Defensive controls must be implemented as enforceable mechanisms that directly disrupt identity-based intrusion and authentication abuse observed in this campaign.

‍ ‍

Identity Protection and Authentication Enforcement

‍ ‍

Enforce multi-factor authentication across all externally exposed identity services and block legacy authentication protocols that bypass MFA. Apply conditional access policies that restrict authentication based on device trust, geolocation, and risk signals.

‍ ‍

Phishing Detection and Interaction Control

‍ ‍

Deploy email security controls that actively block credential harvesting attempts, including domain impersonation, lookalike domains, and malicious link delivery targeting privileged and access-bearing users.

‍ ‍

Behavioral Detection and Identity Monitoring

‍ ‍

Implement detection logic that identifies deviations in authentication behavior, including abnormal login timing, device usage, session patterns, and geographic anomalies, and enforce alerting or access restriction based on risk thresholds.

‍ ‍

Privileged Access Enforcement

‍ ‍

Restrict privileged account usage to controlled environments, enforce just-in-time access where possible, and continuously monitor privileged authentication activity for anomalous behavior.

‍ ‍

Service Availability Protection

‍ ‍

Apply rate limiting, traffic filtering, and service resilience controls to internet-facing systems to mitigate disruption attempts during escalation conditions.

‍ ‍

S33 Defensive Control and Hardening Strategy

‍ ‍

Organizations must align defensive improvements directly to the identity-based intrusion model and conflict-driven attack stages observed in this campaign.

‍ ‍

·        Implement identity baselining to detect deviations during authentication and post-authentication activity

‍ ‍

·        Deploy phishing-resistant authentication mechanisms such as hardware-based MFA to prevent credential harvesting success

‍ ‍

·        Integrate telemetry across email, endpoint, and network systems to enable detection of attack progression

‍ ‍

·        Harden externally exposed authentication services through access controls and monitoring

‍ ‍

·        Strengthen resilience of internet-facing services to withstand disruption activity

‍ ‍

Control Impact Mapping

‍ ‍

·        Phishing Stage (T1566 – Phishing)
Phishing-resistant authentication and email security controls reduce credential harvesting success

‍ ‍

·        Credential Abuse Stage (T1078 – Valid Accounts, T1110 – Brute Force)
MFA enforcement, conditional access, and identity monitoring prevent unauthorized authentication and limit account misuse

‍ ‍

·        Post-Authentication Stage (T1087 – Account Discovery)
Behavioral detection and identity baselining identify abnormal activity following successful authentication

‍ ‍

·        Disruption Stage (T1498 – Network Denial of Service)
Traffic filtering and resilience controls reduce service degradation and maintain availability during escalation

‍ ‍

S34 Incident Response and Recovery Strategy

‍Incident response must prioritize rapid containment of credential compromise and authentication abuse, recognizing that access may already exist within legitimate identity workflows at the time of detection.

‍ ‍

‍ ‍

Response actions include:

‍ ‍

·        Immediate revocation of compromised credentials and active authentication sessions

‍ ‍

·        Forced password resets and mandatory MFA re-enrollment for affected identities

‍ ‍

·        Rapid analysis of authentication logs to identify unauthorized access patterns and scope of compromise

‍ ‍

·        Isolation of affected systems or accounts to prevent continued access

‍ ‍

‍ ‍

Response planning must account for conflict-aligned escalation scenarios, where adversaries may maintain access while simultaneously initiating disruption activity against internet-facing services.

‍ ‍

Recovery efforts must validate identity integrity, confirm removal of unauthorized access, and ensure that no persistent authentication pathways remain available to adversaries.

‍ ‍

S35 Security Hardening Recommendations

‍ ‍

Security hardening must focus on reducing exposure at the identity and authentication layer.

‍ ‍

·        Eliminate legacy authentication mechanisms that bypass MFA enforcement

‍ ‍

·        Enforce conditional access policies based on device, location, and behavioral risk signals

‍ ‍

·        Reduce external exposure of authentication services where possible

‍ ‍

·        Apply segmentation to limit the impact of compromised accounts

‍ ‍

·        Conduct regular audits of privileged access and authentication pathways

‍ ‍

S36 Intelligence Maturity Assessment

‍ ‍

Current maturity for defending against this threat is constrained by limited identity-layer visibility and insufficient cross-telemetry correlation.

‍ ‍

Detection Capability Maturity

‍ ‍

Moderate, with reliance on isolated telemetry rather than integrated behavioral detection

‍ ‍

Telemetry Coverage Maturity

‍ ‍

Variable, with gaps between email, endpoint, and network visibility

‍ ‍

Detection Engineering Maturity

‍ ‍

Moderate, with limited behavioral detection for identity abuse

‍ ‍

Response Readiness Maturity

‍ ‍

Moderate, with response processes focused on endpoint compromise rather than identity compromise

‍ ‍

Security Hardening Maturity

‍ ‍

Variable, with inconsistent enforcement of identity protection controls

‍ ‍

Control Effectiveness Score

‍ ‍

Moderate

‍ ‍

Audit Evidence Statement

‍ ‍

Organizations with integrated telemetry and identity-centric detection demonstrate improved detection speed and reduced adversary dwell time

‍ ‍

Security Program Integration Note

‍ ‍

Enhancing identity-centric detection and cross-telemetry correlation strengthens alignment with identity security, access control, and incident response requirements across regulatory frameworks.

‍ ‍

S37 Strategic Security Recommendations

‍ ‍

Organizations must align security strategy with identity-based intrusion and conflict-driven targeting.

‍ ‍

·        Prioritize identity security as the primary control boundary for detection and prevention

‍ ‍

·        Implement cross-telemetry correlation across email, endpoint, and network systems

‍ ‍

·        Enforce strong authentication controls and eliminate weak or legacy access methods

‍ ‍

·        Enhance detection of authentication anomalies and post-authentication behavior

‍ ‍

·        Prepare for escalation-driven threat activity involving both persistent access and disruption

S38 Strategic Assessment and Conclusion

‍ ‍

This campaign represents a conflict-aligned cyber operation in which Iranian state-affiliated actors leverage identity-based intrusion to impose strategic pressure against U.S. and allied interests.

‍ ‍

The use of credential harvesting and authentication abuse enables adversaries to bypass traditional security controls and operate within legitimate identity workflows, significantly increasing the likelihood of delayed detection and sustained access.

‍ ‍

Targeting is deliberate and globally distributed, with priority placed on organizations that provide operational, technological, or infrastructure support to U.S. and allied systems, including critical infrastructure and defense-adjacent environments.

‍ ‍

The combination of scalable credential acquisition and escalation-driven disruption capability creates a dual-impact threat model, allowing adversaries to maintain persistent access while degrading service availability during periods of heightened geopolitical tension.

‍ ‍

Organizations that do not implement identity-centric security controls, behavioral detection, and cross-telemetry correlation remain exposed to prolonged adversary presence and increased operational impact.

‍ ‍

S39 Key Takeaways for Executive Leadership

‍ ‍

·        Identity systems represent the primary attack surface and must be treated as core security control boundaries

‍ ‍

·        Credential compromise enables adversaries to operate within legitimate workflows and bypass traditional defenses

‍ ‍

·        Targeting is strategically aligned to U.S. and allied interests rather than opportunistic

‍ ‍

·        Organizations may experience simultaneous access and disruption activity during escalation conditions

‍ ‍

·        Detection requires correlation across email, endpoint, and network telemetry rather than reliance on single-source alerts

‍ ‍

·        Strong authentication enforcement and identity monitoring are critical to reducing risk

‍ ‍

S40 References

‍ ‍

Vendor Advisory

‍ ‍

·        Cybersecurity and Infrastructure Security Agency (CISA) advisory on Iranian cyber actors targeting U.S. networks

‍ ‍

·        hxxps[:]//www[.]cisa[.]gov/resources-tools/resources/iranian-cyber-actors-may-target-vulnerable-us-networks-and-entities-interest

‍ ‍

Security Vendor Analysis

‍ ‍

·        SecurityScorecard analysis of Iran conflict cyber activity and global targeting expansion

‍ ‍

·        hxxps[:]//securityscorecard[.]com/blog/iran-conflict-and-the-expanding-cyber-front-what-government-leaders-need-to-know/

‍ ‍

·        Center for Strategic and International Studies (CSIS) analysis on Iranian cyber threats to U.S. energy infrastructure

‍ ‍

·        hxxps[:]//www[.]csis[.]org/analysis/iran-conflict-heightens-cyber-threats-us-energy-infrastructure

‍ ‍

Analytical Framework

‍ ‍

·        MITRE ATT&CK Enterprise Framework

‍ ‍

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

‍ ‍