Report Type
Threat Intelligence Assessment

Threat Category
Identity Intrusion Campaign / Social Engineering Initial Access / Remote Assistance Tool Abuse

Assessment Date
March 17, 2026

Primary Impact Domain
Enterprise Identity Security and Endpoint Remote Access Trust Boundaries

BLUF

Enterprise cyber intrusions are increasingly shifting away from traditional malware delivery techniques toward identity-centric compromise methods that exploit stolen credentials, authentication tokens, and trusted authentication infrastructure. Improvements in endpoint protection, exploit mitigation, and malware detection have reduced the reliability of conventional payload-based attacks, leading threat actors to prioritize credential harvesting and account takeover operations that bypass many security controls. Industry threat intelligence reporting shows sustained growth in credential theft operations and underground markets selling compromised enterprise access. Executive security strategy should therefore prioritize identity protection, credential exposure monitoring, and authentication behavior detection as core defensive capabilities rather than relying primarily on malware-centric detection models.

S2A Executive Risk Translation

The enterprise attack surface is increasingly defined by identity infrastructure rather than endpoints. Organizations unable to detect credential abuse or anomalous authentication behavior risk prolonged unauthorized access to enterprise systems, cloud environments, and sensitive data without traditional malware indicators.

S3 Why This Matters Now

Enterprise environments now rely heavily on centralized identity providers, federated authentication systems, and SaaS platforms that use authentication as the primary control boundary. This shift increases the operational importance of identity infrastructure while simultaneously increasing the impact of compromised credentials. At the same time, large-scale credential theft operations are generating significant volumes of stolen authentication data that circulate through underground access markets, allowing attackers to obtain enterprise access using valid credentials rather than exploiting vulnerabilities or deploying malware.

S4 Key Judgments

Identity compromise has become one of the most efficient initial access mechanisms available to modern threat actors because it bypasses many traditional security controls. Credential harvesting operations and access brokerage markets provide attackers with scalable access to enterprise environments. The expansion of cloud identity providers and SaaS authentication systems has increased the operational value of stolen authentication tokens and session cookies, enabling attackers to access enterprise systems without deploying malware inside the environment. Effective detection of identity-driven intrusions therefore depends on behavioral monitoring across authentication systems, endpoint activity, and network telemetry.

S5 Executive Risk Summary

Identity-based intrusions allow adversaries to operate within enterprise environments using legitimate authentication mechanisms that closely resemble authorized user activity. This significantly complicates detection because malicious behavior may occur without malware artifacts or exploit indicators. Compromised credentials can provide access to enterprise SaaS platforms, administrative portals, cloud infrastructure, and internal systems. Once access is established, attackers may escalate privileges, access sensitive data, manipulate identity systems to establish persistence, or sell enterprise access to additional threat actors. Because authentication activity frequently appears legitimate, organizations may experience extended attacker dwell time before intrusion activity is identified.

S5A Estimated Probability of Recurrence (12-Month Horizon)

High probability. Identity-driven intrusions are expected to remain common due to the global scale of credential theft operations, widespread password reuse across services, expanding cloud authentication infrastructure, and the continued growth of underground markets selling compromised credentials and enterprise access.

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.

Identity-based enterprise intrusions can create significant financial exposure due to operational disruption, incident response costs, regulatory penalties, and data compromise impacts.

For organizations affected by credential compromise or identity intrusion activity:

· Limited incident scenario — Estimated cost range: $50,000 – $250,000

· Moderate incident scenario — Estimated cost range: $250,000 – $2,000,000

· Severe incident scenario — Estimated cost range: $2,000,000 – $20,000,000+

Key cost drivers

· Incident response and forensic investigation

· Operational disruption and business interruption

· Regulatory compliance obligations and legal exposure

· Customer notification requirements and reputational impact

S6A Compliance Exposure Indicator

Identity compromise may create regulatory exposure where unauthorized access to regulated information systems occurs or where organizations cannot demonstrate appropriate authentication security controls. Regulatory frameworks governing privacy, financial reporting, and data protection frequently require disclosure and remediation of unauthorized access incidents involving identity infrastructure.

Risk Register Entry

Risk Category: Identity compromise and account takeover
Business Impact: Unauthorized access to enterprise systems, potential data exposure, and operational disruption
Recommended Risk Owner: Chief Information Security Officer

Annualized Risk Exposure

Using the high recurrence probability identified in S5 combined with moderate incident cost scenarios, annualized financial exposure associated with identity-driven intrusion activity may reasonably fall within the $250,000 – $2,000,000+ range depending on organizational size, identity infrastructure complexity, and regulatory exposure.

S7 Risk Drivers

Enterprise reliance on centralized identity infrastructure has expanded significantly as organizations adopt cloud identity providers and SaaS authentication systems. Credential theft operations continue to generate large volumes of compromised authentication data that circulate through underground access markets. Access brokerage ecosystems allow attackers to purchase enterprise access rather than directly compromise victims, while password reuse and inconsistent multi-factor authentication enforcement increase the likelihood of credential abuse.

S8 Bottom Line for Executives

Enterprise cyber risk is increasingly driven by identity compromise rather than traditional malware execution. Organizations that continue to prioritize malware detection alone may fail to detect credential abuse and account takeover activity occurring through legitimate authentication systems. Executive security strategy should therefore emphasize identity security architecture, credential protection, authentication behavior monitoring, and credential exposure reduction as foundational defensive capabilities.

S9 Board-Level Takeaway

Identity infrastructure has become one of the most critical components of enterprise security posture. Boards and executive leadership should ensure that identity monitoring, authentication security controls, and credential protection mechanisms receive governance attention equivalent to network and endpoint security.

S10 Campaign Overview

Enterprise intrusion activity is increasingly shifting from traditional malware delivery toward identity-driven compromise methods that exploit stolen credentials, authentication tokens, and legitimate authentication infrastructure. As endpoint protection and exploit mitigation technologies have improved, adversaries have increasingly adopted credential abuse and account takeover techniques that allow unauthorized access through normal authentication mechanisms. In modern enterprise environments where cloud identity providers and SaaS authentication platforms control access to critical systems, compromise of authentication credentials can provide immediate access to enterprise infrastructure without requiring malware execution inside the network.

S11 Sectors Affected

· Financial services

· Technology and software providers

· Healthcare organizations and hospital systems

· Government agencies and public sector institutions

· Managed service providers

· Retail and e-commerce organizations

These sectors operate large authentication environments that frequently control access to sensitive financial data, operational systems, and large customer populations, increasing the value of compromised enterprise identities.

S12 Countries Affected

· United States

· United Kingdom

· Canada

· Australia

· Germany

· France

· Netherlands

· Ireland

These regions host large concentrations of enterprise cloud infrastructure and SaaS platforms, making organizations operating in these environments frequent targets for identity-driven intrusion campaigns.

S13 Targeting Probability Assessment

Organizations most likely to experience identity-driven intrusion attempts share structural characteristics that increase both attacker interest and the likelihood that compromised credentials can provide meaningful access.

· Large enterprise identity infrastructures supporting cloud authentication

· Significant reliance on SaaS platforms for business operations

· Distributed workforce authentication environments

· Access to sensitive financial, operational, or customer information

· Incomplete or inconsistent enforcement of multi-factor authentication

These characteristics increase both the attractiveness of the target environment and the probability that stolen authentication credentials can be successfully abused.

S13A Exploit Conditions Snapshot

Identity-driven compromise most commonly occurs when attackers obtain valid authentication material through credential harvesting operations or weaknesses in identity security controls.

· Infostealer malware harvesting browser credentials and authentication tokens

· Phishing campaigns targeting enterprise authentication portals

· Password reuse between enterprise and personal services

· Exposure of authentication tokens from compromised endpoints

· Weak enforcement of multi-factor authentication controls

These conditions enable attackers to authenticate into enterprise environments using legitimate credentials rather than deploying malware.

S14 Initial Access Vector

The most common initial access vector in identity-driven intrusion activity is the use of compromised enterprise credentials obtained through credential harvesting campaigns or underground access brokerage markets. Infostealer malware campaigns and phishing operations frequently collect authentication data that is later reused or sold to attackers seeking enterprise access. Once valid credentials are obtained, adversaries can authenticate into enterprise SaaS platforms, identity providers, and internal systems using legitimate authentication channels, significantly reducing the likelihood of detection by malware-focused security controls.

S15 Adversary Capability Profiling

Identity-driven intrusion operations involve varying levels of attacker capability depending on the stage of the intrusion lifecycle. Initial credential acquisition is often performed through automated credential harvesting infrastructure or commodity infostealer malware that collects authentication data from compromised endpoints. Access brokerage markets allow attackers to obtain compromised enterprise credentials without conducting their own harvesting operations. More capable adversaries leverage compromised accounts to escalate privileges, manipulate identity permissions, establish persistent authentication access, and move laterally across enterprise cloud environments.

S16 Adversary Operational Objectives

Threat actors conducting identity-driven intrusion activity typically pursue several operational objectives after gaining access to enterprise authentication systems.

· Credential harvesting and authentication data collection

· Access to enterprise financial or operational systems

· Establishment of persistent access within identity infrastructure

· Sale of enterprise access through underground access brokerage markets

· Preparation for ransomware deployment or data exfiltration operations

These objectives explain why identity compromise has become an attractive intrusion technique for financially motivated cybercrime groups and advanced threat actors.

S17 Exploit Status

Identity compromise techniques are actively used by financially motivated cybercriminal groups, ransomware operators, and espionage-focused advanced persistent threat actors. The growth of credential harvesting ecosystems and underground access markets has significantly lowered the barrier to entry for identity-driven intrusion activity. As a result, credential abuse and account takeover techniques are routinely observed in enterprise incident response investigations.

S17B Defensive Weakness Profile

Identity-driven intrusions frequently succeed because enterprise security architectures historically emphasized malware detection and network perimeter defense rather than authentication behavior monitoring. Weak credential hygiene, inconsistent enforcement of multi-factor authentication controls, and limited monitoring of identity infrastructure create opportunities for attackers to authenticate using legitimate credentials. Organizations lacking centralized visibility across authentication systems, endpoint activity, and network telemetry may experience extended attacker dwell time before unauthorized access is detected.

S18 Attack Chain Overview

Identity-driven enterprise intrusions typically progress through a structured attack chain beginning with credential acquisition and expanding into broader enterprise access through authentication abuse. Rather than relying on malware execution inside the network, adversaries authenticate into enterprise systems using stolen credentials, session artifacts, or other authentication material. Once authenticated, attackers can enumerate accessible resources, escalate privileges, and establish persistent access through identity infrastructure itself. Because these operations rely on legitimate authentication mechanisms, malicious activity can closely resemble normal user behavior, increasing the likelihood of extended attacker dwell time before detection.

S19 MITRE ATT&CK Mapping

Identity-driven enterprise intrusions commonly align with the following MITRE ATT&CK techniques associated with credential abuse, authentication manipulation, and post-authentication reconnaissance.

· T1078 – Valid Accounts
Attackers authenticate to enterprise SaaS platforms, identity providers, or internal systems using compromised credentials obtained through credential harvesting or access brokerage markets.

· T1550 – Use of Alternate Authentication Material
Adversaries leverage authentication tokens, session artifacts, or other authentication material obtained from compromised endpoints to access enterprise systems without re-entering credentials.

· T1555 – Credentials from Password Stores
Infostealer malware or credential harvesting tools extract stored credentials from browser password stores or authentication caches on compromised endpoints.

· T1539 – Steal Web Session Cookie
Attackers capture session cookies or authentication tokens that allow access to authenticated web applications without requiring additional login activity.

· T1087 – Account Discovery
After authentication, attackers enumerate accessible accounts and identity roles within enterprise systems to identify privileged accounts and potential lateral movement opportunities.

S20 Attack Stage Breakdown

Stage 1 – Credential Harvesting
Attackers obtain authentication credentials through phishing campaigns, infostealer malware infections, credential exposure through password reuse, or other credential collection techniques.

Stage 2 – Valid Account Authentication
Using stolen credentials or authentication tokens, adversaries authenticate into enterprise identity systems, SaaS platforms, or internal services through legitimate authentication channels.

Stage 3 – Account and Resource Discovery
After gaining access, attackers enumerate accessible accounts, identity roles, and enterprise services to identify privileged resources and potential lateral movement paths.

Stage 4 – Privilege Escalation and Access Expansion
Adversaries attempt to obtain elevated privileges or access additional accounts by abusing identity permissions, misconfigured authentication roles, or credential reuse across systems.

Stage 5 – Persistence and Objective Execution
Attackers establish persistent access through identity infrastructure and pursue operational objectives such as data access, financial fraud, access brokerage, or preparation for ransomware operations.

S20A Adversary Tradecraft Summary

· Abuse of legitimate authentication mechanisms

· Reliance on credential harvesting ecosystems

· Use of underground access brokerage markets

· Manipulation of identity permissions for privilege escalation

· Persistence through authentication tokens and session artifacts

These tradecraft patterns allow adversaries to blend malicious activity with normal authentication behavior, complicating detection efforts for organizations that rely primarily on malware-centric security monitoring.

S21 Indicators of Compromise (IOC Summary)

Identity-driven intrusion campaigns often produce fewer traditional static indicators of compromise because adversaries rely on legitimate authentication mechanisms rather than persistent malware infrastructure. As a result, detection frequently depends on identifying authentication anomalies and abnormal identity activity rather than fixed malicious domains or malware signatures.

Observable indicators may include:

· Authentication events originating from unfamiliar geographic locations

· Login attempts from previously unseen devices or browser fingerprints

· Sudden changes to identity roles or privilege assignments

· Concurrent authentication sessions from geographically distant locations

· Authentication token reuse across multiple enterprise services

These indicators typically appear within enterprise identity provider logs, authentication telemetry, and cloud access monitoring systems.

S22 Malware and Tooling

Identity intrusion campaigns frequently rely on credential harvesting tools or infostealer malware during the credential acquisition phase, even though these tools may not remain active after attackers authenticate using stolen credentials.

Common tooling categories include:

· Infostealer malware capable of extracting browser-stored credentials and authentication tokens

· Phishing kits designed to impersonate enterprise authentication portals

· Credential harvesting frameworks used to capture authentication credentials during phishing operations

· Underground access brokerage platforms used to distribute compromised enterprise credentials

These tools typically operate outside the enterprise environment prior to authentication and may not produce persistent indicators once attackers access enterprise systems.

S23 Behavior and Log Artifacts

Although identity-driven attacks minimize traditional malware artifacts, behavioral signals frequently appear within enterprise telemetry systems during authentication abuse and post-authentication activity.

Common observable behaviors include:

· Successful authentication from unusual geographic locations immediately following credential harvesting activity

· Access to multiple enterprise services shortly after initial authentication

· Enumeration of identity roles and account permissions

· Access attempts to administrative resources not normally used by the authenticated account

· Reuse of authentication tokens across multiple services or sessions

These behavioral artifacts typically appear across identity provider logs, endpoint telemetry, and enterprise network authentication monitoring systems.

S24 Detection Strategy

Effective detection of identity-driven intrusion activity requires correlation across multiple enterprise telemetry sources rather than reliance on malware signatures alone. Security teams should prioritize behavioral detection strategies aligned with three primary telemetry pillars.

Email telemetry

· Detection of phishing campaigns targeting enterprise authentication portals

· Identification of credential harvesting attempts within email security gateways

Endpoint telemetry

· Detection of credential harvesting tools or infostealer malware extracting authentication data

· Monitoring browser credential store access and suspicious authentication token extraction activity

Network and authentication telemetry

· Detection of anomalous authentication patterns within identity provider logs

· Identification of geographically inconsistent login activity or concurrent authentication sessions

· Monitoring for abnormal privilege escalation or identity role changes

Correlating signals across these telemetry sources improves the likelihood of detecting identity abuse even when attackers operate using valid authentication credentials.

S25 Ultra-Tuned Detection Engineering Rules

Phase 1A — Credential Harvesting and Password Store Access

Suricata

Rule Name
CyberDax Credential Harvesting Infrastructure Access from User Workstations with Identity-Lure Pattern and Repeated Contact

Purpose
Provide corroborating network telemetry for likely credential-harvesting activity by identifying repeated outbound access from non-support workstation networks to suspicious identity-lure infrastructure while excluding approved enterprise identity providers, sanctioned SaaS authentication platforms, approved remote-access infrastructure, and known corporate authentication destinations.

ATT&CK Technique

· T1566 – Phishing

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Egress HTTP inspection or TLS metadata visibility

· Defined user workstation subnet variables

· Defined support and administrative subnet variables

· Defined approved enterprise authentication destination variables

· Maintained suppression lists or destination scoping for:

o approved corporate SSO and IdP infrastructure

o sanctioned SaaS authentication providers

o known remote-access or secure access service infrastructure

· Optional, but strongly recommended:

o DNS novelty or first-seen enrichment from proxy or DNS pipeline

o destination reputation or domain-age enrichment

o TLS SNI visibility where available

Tuning Explanation
This rule is intentionally a corroborating detector, not a standalone primary credential-harvesting alert. It is designed to identify suspicious repeated access from standard user workstations to external infrastructure exhibiting identity-lure patterns consistent with phishing kits, credential collection portals, or fake enterprise login pages.

To keep noise low, this rule must not fire on:

· approved enterprise identity providers

· sanctioned third-party authentication portals already used by the organization

· approved remote-support or secure web gateway paths

· one-off benign browsing to pages containing generic login-related strings

This rule requires all of the following:

· source is a standard user workstation subnet

· destination is external and not in approved authentication ranges

· destination host or URI exhibits identity-lure characteristics

· repeated access from the same source within a bounded interval

It is strongest when correlated with:

· email or lure-delivery telemetry

· endpoint browser credential-store access

· downstream authentication anomalies

Detection Logic

· Detect outbound HTTP sessions from user workstation networks to external destinations

· Match destination host or URI patterns suggestive of credential lure infrastructure such as:

o login

o verify

o secure

o account

o session

o auth

· Exclude approved enterprise and sanctioned authentication infrastructure

· Require repeated access from the same source within a constrained interval to suppress accidental or one-off benign browsing

· Use only as corroborating evidence of credential-harvesting interaction

Operational Context

· Highest value in environments where workstation users should not repeatedly browse unknown external authentication-themed destinations

· Useful for triage of endpoints later exhibiting suspicious browser credential-store access or valid-account abuse

· Destination allowlists must be maintained before production deployment

· If egress inspection cannot provide meaningful host or URI context, this rule should not be treated as a final production detector

System-Ready Code

# Required local variables to be defined in local policy:
# var USER_WORKSTATIONS [10.20.0.0/16,10.30.0.0/16]
# var SUPPORT_NETS [10.10.10.0/24,10.10.20.0/24]
# var APPROVED_AUTH_NETS [20.190.128.0/18,52.96.0.0/12,34.64.0.0/10]
#
# Deploy only where inspected HTTP metadata is available.

pass http $SUPPORT_NETS any -> $APPROVED_AUTH_NETS any (
    msg:"CYBERDAX allow approved support authentication traffic";
    flow:established,to_server;
    sid:5301002;
    rev:1;
)

pass http $USER_WORKSTATIONS any -> $APPROVED_AUTH_NETS any (
    msg:"CYBERDAX allow approved enterprise authentication traffic";
    flow:established,to_server;
    sid:5301003;
    rev:1;
)

alert http $USER_WORKSTATIONS any -> $EXTERNAL_NET any (
    msg:"CYBERDAX credential harvesting infrastructure access from user workstation";
    flow:established,to_server;
    http.host;
    pcre:"/(login|verify|secure|account|session|auth).*(confirm|update|portal|check)?/Ui";
    detection_filter:track by_src, count 5, seconds 120;
    classtype:trojan-activity;
    sid:5301001;
    rev:1;
    metadata:deployment Egress, confidence medium, attack_target Workstation;
)

SentinelOne

Rule Name
CyberDax Browser Password Store Access by Non-Browser Process with Suspicious Execution Context

Purpose
Detect likely credential harvesting by identifying access to browser password-store artifacts from non-browser processes executing in suspicious script, document, temporary-path, archive, or user-download contexts.

ATT&CK Technique

· T1555 – Credentials from Password Stores

Telemetry Dependency

· SentinelOne Deep Visibility process telemetry

· File access or file interaction visibility for password-store artifacts

· Parent-child process relationships

· Command-line visibility

· Endpoint naming, tagging, or grouping to distinguish support and administrative assets from standard user endpoints

· Optional, but recommended:

o maintenance-window exclusions

o executable signature or reputation metadata

o immediate follow-on network telemetry

o user classification allowing support-user suppression

Tuning Explanation
This is a primary Phase 1A endpoint analytic and is intentionally layered to remain low-noise.

It uses three gating controls:

1. Target validation
The rule scopes to browser password-store artifacts such as:

· Chrome or Chromium Login Data

· Edge Login Data

· equivalent browser password-store database paths

2. Process exclusion
The rule suppresses normal expected access by:

· supported browser processes

· sanctioned password managers

· approved support and administrative endpoint populations where justified locally

3. Suspicious execution-context requirement
The rule requires the accessing process to appear in suspicious execution context such as:

· Office or Outlook parent process

· script interpreter parent

· HTML application or rundll32-based launcher

· process executing from Temp or user Downloads

· process lineage associated with user-driven lure execution

This rule must not alert on browser self-access alone.
It is designed to detect:

· infostealer-style password-store scraping

· malicious credential export workflows

· document- or script-driven password-store access preceding valid-account abuse

Detection Logic

· Identify access to browser password-store files

· Require the accessing process to be outside the browser and password-manager allowlist

· Require suspicious process lineage or suspicious execution origin

· Exclude support and administrative asset populations

· Use optional correlation with immediate outbound network activity as investigation amplifier, not as a hard trigger

Operational Context

· Highest value on user workstations where non-browser access to browser password stores is rare

· Strong signal for credential scraping and password-store theft

· Severity should increase when paired with:

o suspicious external authentication-themed infrastructure access

o session artifact access

o downstream anomalous sign-ins

· If file-level visibility is missing or incomplete, the rule must not be treated as final production detection without local validation

System-Ready Code

Splunk

Rule Name
CyberDax Unauthorized Browser Password Store Access with Thresholded Behavior and Investigation-Grade Context

Purpose
Detect likely credential harvesting by correlating repeated access to browser password-store artifacts by non-browser processes on non-support assets, preserving sufficient process and host context for rapid investigation and escalation.

ATT&CK Technique

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Normalized endpoint file-access telemetry

· Normalized process execution telemetry

· Optional, but recommended:

o network telemetry for same-user or same-host outbound activity

o authentication telemetry for short-window downstream sign-in correlation

· Lookup tables:

o browser process allowlist

o password-manager allowlist

o support assets

o support users

o maintenance windows

o approved migration or administrative tooling where relevant

Tuning Explanation
This is a primary SIEM analytic for Phase 1A and is intentionally more conservative than a single file-path rule.

It requires:

· access to browser password-store paths

· by non-browser, non-password-manager processes

· on non-support populations

· exceeding a behavioral threshold within a short interval

This keeps the rule from firing on:

· isolated benign file access

· browser self-behavior

· support, migration, or administrative maintenance workflows

The rule is strongest when later enriched during investigation with:

· outbound network activity

· sensitive app access

· anomalous authentication behavior

Those enrichments are valuable, but they are not hard requirements for the primary detector because requiring them at rule time can unnecessarily suppress true positives.

Detection Logic

· Collect file-access events targeting browser password-store files

· Normalize process and user names to lower case

· Exclude approved browsers, approved password managers, support assets, support users, and maintenance windows

· Aggregate repeated accesses by host, user, and process in a bounded interval

· Alert only when access count exceeds threshold

· Preserve file path set, process list, and first/last seen times for triage

· Use downstream network or sign-in enrichment during investigation and risk escalation

Operational Context

· Intended for workstation populations where browser password-store access by non-browser processes should be uncommon

· High-value precursor to valid-account abuse and session-backed identity intrusion

· Low-noise when local allowlists and maintenance exceptions are maintained

· If file telemetry is low fidelity or sparse, do not treat this rule as final production detection without local validation

System-Ready Code

index=edr_logs

(file_path="*\\Login Data" OR file_path="*\\User Data\\*\\Login Data")

| eval process_name=lower(process_name), user=lower(user)

| lookup cyberdax_browser_process_allowlist process_name OUTPUT process_name as matched_browser

| lookup cyberdax_password_manager_allowlist process_name OUTPUT process_name as matched_pwmanager

| lookup cyberdax_support_assets asset as host OUTPUT asset as matched_asset

| lookup cyberdax_support_users user as user OUTPUT user as matched_user

| lookup cyberdax_maintenance_windows asset as host OUTPUT maintenance_active

| where isnull(matched_browser)

AND isnull(matched_pwmanager)

AND isnull(matched_asset)

AND isnull(matched_user)

AND (isnull(maintenance_active) OR maintenance_active!="true")

| bin _time span=10m

| stats count as access_count earliest(_time) as first_seen latest(_time) as last_seen values(file_path) as file_paths by host user process_name _time

| where access_count > 5

| eval risk_score=80

| table first_seen last_seen host user process_name file_paths access_count risk_score

Elastic

Rule Name
CyberDax Non-Browser Browser Password Store Access with Suspicious Context

Purpose
Detect likely credential harvesting by identifying access to browser password-store artifacts by non-browser processes executing in suspicious user, script, temporary-path, or document-driven contexts.

ATT&CK Technique

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Elastic Defend or equivalent endpoint file access telemetry

· Process execution telemetry

· Parent-child process visibility

· Host role or asset metadata identifying support or administrative systems

· Optional:

o labels for maintenance windows

o signed binary or reputation metadata

o user enrichment for support populations

Tuning Explanation
This is a primary endpoint analytic for Phase 1A and is intentionally low-noise. It requires:

· access to browser password-store paths

· by a non-browser, non-password-manager process

· occurring in suspicious execution context

This rule suppresses:

· supported browser processes

· sanctioned password managers

· support or admin workstation populations

· maintenance windows where locally available

This rule must not be reduced to:

· any access to Login Data

· browser self-access

· generic temp-path execution alone

It is strongest when correlated with:

· suspicious external identity-lure infrastructure access

· downstream authentication anomalies

· follow-on token or session artifact access

Detection Logic

· Detect file access to browser password-store databases

· Require accessing process outside approved browser and password-manager set

· Require suspicious lineage or execution origin such as:

o Office or Outlook parent

o script interpreter parent

o Temp or Downloads execution path

· Exclude support populations and maintenance windows before alerting

Operational Context

· Highest value on standard user Windows endpoints

· Strong signal for infostealer-style scraping and password-store theft

· If file access telemetry is incomplete, do not treat this rule as final production detection without local validation

System-Ready Code

file where host.os.type == "windows"
and file.path like~ (
    "*\\Google\\Chrome\\User Data\\*\\Login Data",
    "*\\Microsoft\\Edge\\User Data\\*\\Login Data"
)
and process.name not in ("chrome.exe","msedge.exe","firefox.exe","brave.exe","1password.exe","lastpass.exe","bitwarden.exe","keepass.exe")
and (
    process.parent.name in ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","acrord32.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
    or process.executable regex~ "(?i)\\\\AppData\\\\Local\\\\Temp\\\\"
    or process.executable regex~ "(?i)\\\\Users\\\\[^\\\\]+\\\\Downloads\\\\"
)
and not host.name regex~ "(?i)^(HD-|HELPDESK-|IT-|SUPPORT-|SRV-IT-)"
and (labels.maintenance_window == null or labels.maintenance_window != "true")

QRadar

Rule Name
CyberDax Browser Password Store Access by Non-Browser Process with Suspicious Execution Context

Purpose
Detect likely credential harvesting by identifying repeated access to browser password-store artifacts by non-browser processes on non-support endpoints when suspicious execution context is present.

ATT&CK Technique

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Endpoint file access logs normalized into QRadar

· Process creation or file access telemetry with:

o username

o hostname

o file path

o process name

o parent process or process path where available

· Reference sets:

o CYBERDAX_BROWSER_PROCESSES

o CYBERDAX_PASSWORD_MANAGER_PROCESSES

o CYBERDAX_SUPPORT_ASSETS

o CYBERDAX_SUPPORT_USERS

o CYBERDAX_MAINTENANCE_ASSETS

· Optional enrichment for suspicious parent processes or temporary-path execution

Tuning Explanation
This is a primary SIEM analytic for Phase 1A and must not alert on a single benign file interaction. It requires:

· access to browser password-store paths

· by a non-browser, non-password-manager process

· at least 4 repeated events within 10 minutes

· suspicious execution context when available

This rule suppresses:

· support assets

· support users

· maintenance assets

· approved browser and password-manager activity

Mandatory prerequisite:

file access logging for browser password-store paths must be present. If QRadar cannot distinguish file path and process reliably, this rule must not be treated as final production detection.

Detection Logic

· Building Block 1 identifies access to browser password-store files

· Building Block 2 excludes approved browser and password-manager processes

· Building Block 3 identifies suspicious execution context

· Main CRE rule suppresses support populations and creates an offense only when all conditions align

Operational Context

· Highest value where workstation file access telemetry is ingested

· Strong detector for password-store scraping prior to valid-account abuse

· Severity should increase when correlated with suspicious lure infrastructure access or later sign-in anomalies

Field Mapping Guidance
File access fields may map as:

· File Path

· Target Filename

· Object Name

Process fields may map as:

· Process Name

· Image

· Process

· Parent Process

· Command

User fields may map as:

· Username

· User Name

· Log Source Username

Host fields may map as:

· Destination Hostname

· Hostname

· Asset Hostname

System-Ready Code

Reference Set: CYBERDAX_BROWSER_PROCESSES
Reference Set: CYBERDAX_PASSWORD_MANAGER_PROCESSES
Reference Set: CYBERDAX_SUPPORT_ASSETS
Reference Set: CYBERDAX_SUPPORT_USERS
Reference Set: CYBERDAX_MAINTENANCE_ASSETS

Building Block: CYBERDAX_Browser_Password_Store_Access
when event category indicates file access
and file path matches one of:
*\Google\Chrome\User Data\*\Login Data
*\Microsoft\Edge\User Data\*\Login Data

Building Block: CYBERDAX_NonBrowser_Process
when process name is not in CYBERDAX_BROWSER_PROCESSES
and process name is not in CYBERDAX_PASSWORD_MANAGER_PROCESSES

Building Block: CYBERDAX_Suspicious_Context
when parent process indicates office or script execution
or process path indicates Temp or Downloads execution

Rule: CYBERDAX Browser Password Store Access by Non-Browser Process
when BB:CYBERDAX_Browser_Password_Store_Access matches
and BB:CYBERDAX_NonBrowser_Process matches
and BB:CYBERDAX_Suspicious_Context matches
and at least 4 matching access events occur by same destination hostname and username within 10 minutes
and destination hostname not in CYBERDAX_SUPPORT_ASSETS
and username not in CYBERDAX_SUPPORT_USERS
and destination hostname not in CYBERDAX_MAINTENANCE_ASSETS
then create offense
Severity: 8
Relevance: 8
Credibility: 8

Sigma

Rule Name
CyberDax Browser Password Store Access by Non-Browser Process

Purpose
Provide portable supporting detection for browser password-store access by non-browser processes in suspicious execution context.

ATT&CK Technique

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Endpoint file access logs in a Sigma-compatible backend

· Process name and parent process visibility

· Backend-side enrichment or naming conventions for support assets where possible

· Optional maintenance-window enrichment

Tuning Explanation
This is a supporting detector, not a standalone primary analytic. It is intended for backends that can preserve:

· file path access

· process name

· parent process context

It should only be used where the backend can distinguish browser password-store paths and process context reliably. It must not be deployed unchanged if:

· file access telemetry is absent

· parent process visibility is missing

· support population suppression cannot be approximated

Detection Logic

· Detect access to browser password-store files

· Exclude browser and password-manager processes

· Require suspicious parent process or suspicious execution context

· Forward matches to SIEM correlation and triage pipelines

Operational Context

· Useful as portable supporting content where endpoint file access telemetry exists

· Best used with stronger SIEM or EDR analytics

· Not intended to replace full primary detections

System-Ready Code

title: CyberDax Browser Password Store Access by Non-Browser Process
id: 9de24c43-0e7c-4ed8-8c8b-cyberdax-phase1a-pwstore
status: experimental
description: Detects browser password-store access by non-browser processes with suspicious execution context.
logsource:
product: windows
category: file_access
detection:
selection_path:
    TargetFilename|contains:
      - '\Google\Chrome\User Data\'
      - '\Microsoft\Edge\User Data\'
    TargetFilename|endswith:
      - '\Login Data'
filter_browser:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\1password.exe'
      - '\lastpass.exe'
      - '\bitwarden.exe'
      - '\keepass.exe'
selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\acrord32.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
condition: selection_path and not filter_browser and selection_parent
falsepositives:
- Approved administrative or migration tooling in environments without local suppression enrichment
level: high
tags:
- attack.t1555

YARA

Rule Name
CyberDax Browser Password Store and Credential Export Artifact Heuristic

Purpose
Support forensic triage by identifying scripts, binaries, or collected artifacts associated with browser password-store extraction, credential export, or local staging of stolen browser credentials.

ATT&CK Technique

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Endpoint forensic collections

· File triage workflows

· Incident response artifact review

· EDR file telemetry where available

Tuning Explanation
This rule is forensic and triage support only, not a primary prevention or real-time endpoint block. It is designed to identify artifacts associated with:

· browser password-store extraction

· credential database copying

· browser credential export workflows

To reduce noise, the rule requires multiple indicators rather than isolated generic strings. It should not be used as a standalone detector for normal browser data files.

Detection Logic

· Match combinations of strings associated with browser password stores and credential export workflows

· Require multiple indicators before alerting

· Use during triage of compromised endpoints or staging directories

Operational Context

· Highest value during post-alert investigation of endpoints showing suspicious browser password-store access

· Useful for confirming credential harvesting or staging behavior after EDR or SIEM detections

· Not intended as a standalone production prevention control

System-Ready Code

rule CYBERDAX_Browser_Password_Store_Extraction_Artifact
{
    meta:
        description = "Heuristic for browser password-store extraction or credential export artifacts"
        author = "CyberDax Detection Engineering"
        version = "1.0"
        scope = "forensic triage"

    strings:
        $s1 = "Login Data" nocase
        $s2 = "Web Data" nocase
        $s3 = "Local State" nocase
        $s4 = "password_value" nocase
        $s5 = "logins" nocase
        $s6 = "os_crypt" nocase
        $s7 = "SELECT origin_url, username_value, password_value" nocase
        $s8 = "AppData\\\\Local\\\\Google\\\\Chrome\\\\User Data" nocase
        $s9 = "AppData\\\\Local\\\\Microsoft\\\\Edge\\\\User Data" nocase

    condition:
        3 of ($s*)
}

AWS

Rule Name
CyberDax Suspicious AWS Console or STS Access Following Credential Harvesting Indicators

Purpose

Detect likely attacker use of harvested credentials or alternate authentication material by identifying successful AWS console or STS identity activity from abnormal principal context shortly after credential-harvesting signals.

ATT&CK Technique

· T1078 – Valid Accounts

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· AWS CloudTrail

· Successful events for:

o ConsoleLogin

o AssumeRole

o GetCallerIdentity

o GetFederationToken where applicable

· Principal identity, source IP, user agent, region

· Approved corporate egress allowlists

· Approved service or automation principal allowlists

· Baseline data for:

o known IP by principal

o known region by principal

o known user agent by principal

· Optional but strongly recommended:

o correlation flag or enrichment from recent Phase 1A endpoint detections

o role sensitivity or privileged principal classification

o federation context where available

Tuning Explanation

This is a primary cloud-use detector for Phase 1A downstream abuse and now requires stronger behavioral gating to remain low-noise. It does not fire on successful cloud access alone.

This rule requires:

· successful AWS console or STS identity activity

· abnormal source or client context such as:

o IP not previously associated with the principal

o region not previously associated with the principal

o user agent not previously associated with the principal

· plus either:

o recent Phase 1A credential-harvesting context, or

o repeated suspicious identity-validation activity in a short window, or

o sensitive federation or role activity in abnormal context

This suppresses:

· approved corporate egress ranges

· approved service or automation principals

· known expected federation or infrastructure paths where locally modeled

It must not be deployed as a generic non-corporate login detector.

Detection Logic

· Detect successful ConsoleLogin, AssumeRole, GetCallerIdentity, or GetFederationToken events

· Exclude approved service principals and approved corporate egress

· Require abnormal source/client context:

o new IP, new region, or new user agent for the principal

· Require either:

o recent correlation to password-store or credential-harvesting detections, or

o repeated suspicious identity-validation activity in a bounded interval, or

o federation/role-sensitive activity in abnormal context

· Preserve principal, source, user agent, region, and event sequence for triage

Operational Context

· Highest value in environments using federated enterprise identities into AWS

· Strong signal when attackers pivot from harvested browser credentials into AWS access

· Should be escalated when identity-validation behavior occurs shortly after endpoint credential-store access

· If baseline data for IP, region, or user agent is unavailable, this rule must not be treated as final production detection without local adaptation

System-Ready Code

SELECT
eventtime,
useridentity.arn            AS principal_arn,
sourceipaddress             AS source_ip,
eventname,
useragent,
awsregion
FROM cloudtrail_logs
WHERE eventname IN ('ConsoleLogin','AssumeRole','GetCallerIdentity','GetFederationToken')
AND errorcode IS NULL
AND useridentity.arn NOT IN (
    SELECT principal FROM approved_service_principals
)
AND sourceipaddress NOT IN (
    SELECT ip_or_range FROM approved_corporate_ranges
)
AND (
    sourceipaddress NOT IN (
      SELECT ip FROM baseline_ip_by_principal
      WHERE principal = useridentity.arn
    )
    OR awsregion NOT IN (
      SELECT region FROM baseline_region_by_principal
      WHERE principal = useridentity.arn
    )
    OR useragent NOT IN (
      SELECT user_agent FROM baseline_user_agent_by_principal
      WHERE principal = useridentity.arn
    )
)
AND (
    useridentity.arn IN (
      SELECT principal FROM recent_phase1a_principals
    )
    OR useridentity.arn IN (
      SELECT principal_arn FROM repeated_identity_validation_window
    )
    OR eventname IN ('AssumeRole','GetFederationToken')
);

Azure

Rule Name
CyberDax Suspicious Microsoft Entra Sign-In Following Credential Harvesting Indicators

Purpose

Detect likely attacker use of harvested credentials or alternate authentication material by identifying successful Entra sign-ins from abnormal user context shortly after credential-harvesting signals.

ATT&CK Technique

· T1078 – Valid Accounts

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Microsoft Entra SigninLogs

· Successful sign-in events

· User principal, source IP, device context, user agent, app context

· Watchlists for:

o approved corporate IP ranges

o approved automation identities

· Optional but strongly recommended:

o trusted or named-location suppression

o baseline or enrichment data for new or rare IP/device/user-agent context

o correlation flag from recent Phase 1A endpoint detections

o sign-in risk or token-protection context where locally available

Tuning Explanation

This is a primary cloud identity detector for Phase 1A downstream abuse and no longer allows brittle faux first-seen enrichment. It requires:

· successful sign-in activity

· abnormal user context such as:

o non-corporate source IP

o repeated sign-ins in a short window

o uncommon device or client context where available

· plus either:

o recent Phase 1A credential-harvesting context, or

o repeated suspicious sign-in behavior in a short interval

This suppresses:

· approved corporate IP ranges

· approved automation identities

· trusted or named locations where available

It must not be deployed as a generic sign-in anomaly rule.

Detection Logic

· Detect successful Entra sign-ins

· Exclude approved corporate IP ranges and automation identities

· Summarize short-window sign-in activity by user, IP, device, and user agent

· Require either:

o recent Phase 1A endpoint correlation, or

o repeated suspicious sign-in activity in a bounded interval

· Preserve user, source, device, user agent, and app context for triage

Operational Context

· Highest value where enterprise identities provide access to Microsoft cloud services

· Strong signal when attackers pivot from browser password-store access into Entra-backed services

· If trusted-location suppression is unavailable, local IP suppression or equivalent controls must be added before production deployment

· Sign-in risk or token-protection context should be treated as supporting enrichment, not sole trigger

System-Ready Code

let ApprovedIPs = _GetWatchlist('cyberdax_approved_ip_ranges') | project SearchKey;
let AutomationAccounts = _GetWatchlist('cyberdax_automation_accounts') | project SearchKey;
let RecentPhase1AUsers = _GetWatchlist('cyberdax_recent_phase1a_users') | project SearchKey;
SigninLogs
| where ResultType == 0
| where UserPrincipalName !in (AutomationAccounts)
| where IPAddress !in (ApprovedIPs)
| extend DeviceId = tostring(DeviceDetail.deviceId), UA = tostring(UserAgent)
| summarize
    sign_in_count = count(),
  first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated),
    apps = make_set(AppDisplayName)
by UserPrincipalName, IPAddress, DeviceId, UA, bin(TimeGenerated, 30m)
| extend phase1a_context = UserPrincipalName in (RecentPhase1AUsers)
| where phase1a_context == true or sign_in_count > 1

Deployment Note

· If approved IP watchlists are unavailable, substitute trusted-location or named-location suppression.

· If repetition or abnormal-context modeling is unavailable, do not deploy this rule as a final production analytic.

· Missing device identity alone must not be treated as suspicious without repetition, enrichment, or Phase 1A correlation.

GCP

Rule Name
CyberDax Suspicious GCP Identity Validation or Privileged IAM Activity Following Credential Harvesting Indicators

Purpose

Detect likely attacker use of harvested credentials or alternate authentication material by identifying suspicious authenticated GCP identity-validation activity or privileged IAM actions from abnormal principal context shortly after credential-harvesting signals.

ATT&CK Technique

· T1078 – Valid Accounts

· T1098 – Account Manipulation

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· GCP Cloud Audit Logs

· Principal identity, caller IP, method name, project context

· Approved corporate IP allowlists

· Optional but strongly recommended:

o service account and automation allowlists

o privileged method classification

o baseline caller IP or source-context modeling by principal

o correlation with recent Phase 1A endpoint detections

Tuning Explanation

This is a primary GCP follow-on abuse detector for Phase 1A and is intentionally designed to cover both:

1. suspicious authenticated identity validation or access establishment behavior

2. privileged IAM or control-plane abuse

It requires:

· authenticated GCP activity

· abnormal principal context such as:

o caller IP not previously associated with the principal

o source context not previously associated with the principal

· plus either:

o recent Phase 1A credential-harvesting context, or

o privileged IAM method usage, or

o repeated identity-validation or token-generation activity in abnormal context

This prevents the rule from becoming either:

· too generic, or

· too narrow

Detection Logic

· Detect authenticated GCP control-plane or identity-related activity

· Include:

o privileged IAM methods

o identity-establishing or validation behavior where observable

· Exclude approved corporate ranges

· Require abnormal principal context

· Require either recent Phase 1A correlation, privileged action pattern, or repeated abnormal identity-validation behavior

· Preserve principal, caller IP, method, and project context for triage

Operational Context

· Highest value in organizations using federated enterprise identities into GCP

· Strong detector for cloud pivot behavior after local credential harvesting

· Particularly useful where attackers move rapidly from endpoint access into cloud identity validation and then privilege use

· If baseline source modeling is unavailable, do not treat this as final production detection without local adaptation

System-Ready Code

SELECT
timestamp,
protopayload_auditlog.authenticationInfo.principalEmail AS principal_email,
protopayload_auditlog.methodName                        AS method_name,
protopayload_auditlog.requestMetadata.callerIp         AS caller_ip,
resource.labels.project_id                             AS project_id
FROM `project.dataset.cloudaudit_googleapis_com_activity_*`
WHERE protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
AND protopayload_auditlog.requestMetadata.callerIp NOT IN (
  SELECT ip_or_range FROM `project.dataset.approved_corporate_ranges`
)
AND (
    protopayload_auditlog.requestMetadata.callerIp NOT IN (
      SELECT ip FROM `project.dataset.baseline_ip_by_principal`
      WHERE principal = protopayload_auditlog.authenticationInfo.principalEmail
    )
    OR protopayload_auditlog.authenticationInfo.principalEmail IN (
      SELECT principal FROM `project.dataset.recent_phase1a_principals`
    )
)
AND (
    protopayload_auditlog.methodName IN (
      'SetIamPolicy',
      'google.iam.admin.v1.CreateServiceAccountKey',
      'google.iam.admin.v1.SignJwt',
      'google.iam.admin.v1.GenerateAccessToken',
      'google.iam.admin.v1.GenerateIdToken',
      'google.iam.credentials.v1.GenerateAccessToken',
      'google.iam.credentials.v1.GenerateIdToken',
      'google.iam.admin.v1.GetServiceAccount',
      'google.iam.admin.v1.ListServiceAccounts'
    )
    OR protopayload_auditlog.authenticationInfo.principalEmail IN (
      SELECT principal FROM `project.dataset.repeated_identity_validation_principals`
    )
);

S25 — Group 1

Phase 1B — Session Cookie and Token Artifact Access

Suricata

Rule Name

CyberDax Suspected Session Artifact Exfiltration to Suspicious External Infrastructure

Purpose

Provide corroborating network telemetry for likely session-cookie or token-artifact theft by identifying repeated outbound POST-heavy communication from user workstations to suspicious external infrastructure after local session-artifact interaction is suspected.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Egress HTTP inspection or high-fidelity proxy metadata

· Defined user workstation subnet variables

· Defined approved enterprise authentication destination variables

· Destination allowlists for:

o enterprise identity providers

o sanctioned SaaS authentication platforms

o approved secure access or remote support infrastructure

· Optional but strongly recommended:

o domain novelty or first-seen enrichment

o destination reputation or category enrichment

o endpoint-to-network correlation from SIEM or SOC pipeline

Tuning Explanation

This rule is corroborating only and must not be treated as a primary cookie-theft detector. It is intentionally narrowed to reduce false positives by requiring:

· source is a user workstation

· destination is external and not in approved identity infrastructure

· repeated POST-oriented communication

· destination host characteristics suggest session or auth-oriented collection behavior

It must not alert on:

· trusted authentication portals

· sanctioned SaaS login flows

· generic identity traffic to allowlisted platforms

· isolated single-request web activity

This rule is valid only where destination context is sufficiently visible to distinguish suspicious external collection infrastructure from normal enterprise auth flows.

Detection Logic

· Detect repeated outbound HTTP POST behavior from user workstations to external destinations

· Match suspicious destination semantics consistent with session or auth collection behavior

· Exclude approved identity and corporate destinations

· Use as corroborating evidence only when combined with endpoint session-artifact access or downstream alternate-authentication abuse

Operational Context

· Highest value in environments with strong egress metadata and maintained allowlists

· Useful for triage after endpoint cookie/session-store access detections

· Must not be deployed as a standalone primary analytic for this phase

System-Ready Code

# Required local variables:
# var USER_WORKSTATIONS [10.20.0.0/16,10.30.0.0/16]
# var APPROVED_AUTH_NETS [20.190.128.0/18,52.96.0.0/12,34.64.0.0/10]

pass http $USER_WORKSTATIONS any -> $APPROVED_AUTH_NETS any (
    msg:"CYBERDAX allow approved authentication traffic";
    flow:established,to_server;
    sid:5411002;
    rev:1;
)

alert http $USER_WORKSTATIONS any -> $EXTERNAL_NET any (
    msg:"CYBERDAX suspected session artifact exfiltration to suspicious external infrastructure";
    flow:established,to_server;
    http.host;
    pcre:"/(session|token|auth|account|verify)/Ui";
    content:"POST"; http.method;
    detection_filter:track by_src, count 4, seconds 120;
    classtype:exfiltration;
    sid:5411001;
    rev:2;
    metadata:deployment Egress, confidence medium, attack_target Workstation, role Corroborating;
)

SentinelOne

Rule Name

CyberDax Browser Cookie or Session Store Access by Non-Browser Process with Suspicious Execution Context

Purpose

Detect likely session-cookie or token-artifact theft by identifying access to browser cookie stores or session artifacts by non-browser processes executing in suspicious context while excluding routine browser, password-manager, and enterprise migration or sync tooling.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· SentinelOne Deep Visibility process telemetry

· File access or file interaction telemetry

· Parent-child process visibility

· Command-line visibility

· Endpoint grouping or naming to distinguish support and admin systems from user endpoints

· Optional but recommended:

o maintenance-window suppression

o signed or trusted tooling metadata

o sanctioned browser migration or profile sync tool allowlists

o archive creation or outbound network enrichment

Tuning Explanation

This is a primary Phase 1B endpoint analytic and remains low-noise by requiring all of the following:

1. Target validation
Scope to browser session or cookie artifacts such as:

· Chrome or Edge Cookies

· Firefox cookies.sqlite

· Firefox sessionstore artifacts where the environment actually logs them reliably

2. Process exclusion
Suppress:

· supported browsers

· sanctioned password managers

· approved migration, sync, or browser profile tooling where locally used

3. Suspicious execution context
Require:

· Office, Outlook, or script interpreter parent

· Temp or Downloads execution origin

· suspicious user-driven launch chain

This rule must not rely on cookie-store access alone and must not treat Firefox sessionstore paths as universally high-signal without local validation.

Detection Logic

· Detect access to browser cookie or session artifacts

· Exclude browsers, password managers, and sanctioned migration/sync tools

· Require suspicious execution context or suspicious origin path

· Exclude support and admin populations before alerting

· Use archive creation or outbound connection behavior as investigation amplifiers only

Operational Context

· Highest value on user workstations where non-browser cookie/session artifact access is rare

· Strong signal for session cookie or token-artifact theft

· Firefox session store coverage should be validated locally before full production use because telemetry quality varies across environments

· If file access visibility is incomplete, do not treat this as final production detection without local validation

System-Ready Code

Splunk

Rule Name

CyberDax Unauthorized Browser Cookie or Session Artifact Access with Thresholded Behavior and Artifact Scoping

Purpose

Detect likely session-cookie or token-artifact theft by correlating repeated access to browser cookie or session artifacts by non-browser processes on non-support assets, with artifact scoping adjusted to reduce noise from overly broad sessionstore coverage.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Normalized endpoint file-access telemetry

· Normalized process execution telemetry

· Lookup tables:

o browser process allowlist

o password-manager allowlist

o support assets

o support users

o maintenance windows

o approved migration or administrative tooling

· Optional but recommended:

o archive creation telemetry

o outbound network telemetry

o downstream alternate-auth sign-in enrichment

Tuning Explanation

This is a primary SIEM analytic for Phase 1B and has been tightened to avoid unnecessary noise from broad artifact matching.

It now focuses on:

· Cookies

· cookies.sqlite

· clearly scoped session artifacts only where reliable local telemetry exists

It requires:

· non-browser, non-password-manager process access

· non-support populations

· repeated access above threshold in a bounded interval

This rule must not be treated as:

· any single file access to Cookies

· broad wildcard matching over all sessionstore artifacts without local validation

Thresholding remains environment-sensitive, but the rule is now explicitly conservative to favor low-noise deployment.

Detection Logic

· Collect file-access events targeting cookie stores and scoped session artifacts

· Normalize process and user names

· Exclude browsers, password managers, support assets, support users, and maintenance windows

· Aggregate repeated access by host, user, and process within a bounded interval

· Alert only when access count exceeds threshold

· Preserve artifact paths, process, and timing for triage

· Use network or sign-in behavior only as downstream enrichment

Operational Context

· Intended for workstation fleets where browser cookie-store access by non-browser processes should be uncommon

· Strong precursor to alternate-authentication abuse and session misuse

· Sessionstore coverage should only remain enabled where local telemetry quality is validated

· If file-access telemetry is sparse, do not treat this as final production detection without local validation

System-Ready Code

index=edr_logs
(
file_path="*\\Cookies"
OR file_path="*\\cookies.sqlite"
)
| eval process_name=lower(process_name), user=lower(user)
| lookup cyberdax_browser_process_allowlist process_name OUTPUT process_name as matched_browser
| lookup cyberdax_password_manager_allowlist process_name OUTPUT process_name as matched_pwmanager
| lookup cyberdax_support_assets asset as host OUTPUT asset as matched_asset
| lookup cyberdax_support_users user as user OUTPUT user as matched_user
| lookup cyberdax_maintenance_windows asset as host OUTPUT maintenance_active
| where isnull(matched_browser)
AND isnull(matched_pwmanager)
AND isnull(matched_asset)
AND isnull(matched_user)
AND (isnull(maintenance_active) OR maintenance_active!="true")
| bin _time span=10m
| stats count as access_count earliest(_time) as first_seen latest(_time) as last_seen values(file_path) as file_paths by host user process_name _time
| where access_count > 4
| eval risk_score=82
| table first_seen last_seen host user process_name file_paths access_count risk_score

Elastic

Rule Name

CyberDax Browser Cookie or Session Artifact Access by Non-Browser Process with Suspicious Execution Context

Purpose

Detect likely session-cookie or token-artifact theft by identifying access to browser cookie stores or token-adjacent session artifacts by non-browser processes executing in suspicious user, script, temporary-path, or document-driven contexts.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Elastic Defend or equivalent endpoint file access telemetry

· Process execution telemetry

· Parent-child process visibility

· Host role or asset metadata identifying support or administrative systems

· Optional:

o labels for maintenance windows

o reputation or signature metadata

o archive creation enrichment

o downstream authentication enrichment

Tuning Explanation

This is a primary endpoint analytic for Phase 1B and is intentionally low-noise. It requires:

· access to cookie or session-artifact paths

· by a non-browser, non-password-manager process

· in suspicious execution context

This rule suppresses:

· browser self-access

· sanctioned password managers

· support or administrative workstation populations

· maintenance windows where available

Mandatory prerequisite: this rule is production-valid only where endpoint file access telemetry is actually populated for browser artifact paths. If the backend does not reliably emit file access events for:

· Cookies

· cookies.sqlite

then this rule must not be treated as a final production detector.

This rule must not be reduced to:

· any access to Cookies

· any non-interactive auth artifact access

· generic temp-path execution alone

Firefox sessionstore coverage remains intentionally excluded here unless locally validated for clean fidelity.

Detection Logic

· Detect file access to cookie-store artifacts

· Require accessing process outside approved browser and password-manager set

· Require suspicious lineage or suspicious execution origin such as:

o Office or Outlook parent

o script interpreter parent

o Temp or Downloads execution path

· Exclude support populations and maintenance windows before alerting

Operational Context

· Highest value on standard user Windows endpoints

· Strong signal for session cookie or token-artifact theft

· Best escalated when paired with:

o suspicious outbound infrastructure access

o alternate-auth sign-ins

o concurrent or conflicting authenticated use

· If file access telemetry is incomplete, do not treat this as final production detection without local validation

System-Ready Code

file where host.os.type == "windows"
and file.path like~ (
    "*\\Google\\Chrome\\User Data\\*\\Cookies",
    "*\\Microsoft\\Edge\\User Data\\*\\Cookies",
    "*\\Mozilla\\Firefox\\Profiles\\*\\cookies.sqlite"
)
and process.name not in ("chrome.exe","msedge.exe","firefox.exe","brave.exe","1password.exe","lastpass.exe","bitwarden.exe","keepass.exe","migwiz.exe","usmt.exe")
and (
    process.parent.name in ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","acrord32.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
    or process.executable regex~ "(?i)\\\\AppData\\\\Local\\\\Temp\\\\"
    or process.executable regex~ "(?i)\\\\Users\\\\[^\\\\]+\\\\Downloads\\\\"
)
and not host.name regex~ "(?i)^(HD-|HELPDESK-|IT-|SUPPORT-|SRV-IT-)"
and (labels.maintenance_window == null or labels.maintenance_window != "true")

QRadar

Rule Name

CyberDax Browser Cookie or Session Artifact Access by Non-Browser Process with Suspicious Context

Purpose
Detect likely session-cookie or token-artifact theft by identifying repeated access to browser cookie stores or token-adjacent session artifacts by non-browser processes on non-support endpoints when suspicious execution context is present.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Endpoint file access logs normalized into QRadar

· Process creation or file access telemetry with:

o username

o hostname

o file path

o process name

o parent process or process path where available

· Reference sets:

o CYBERDAX_BROWSER_PROCESSES

o CYBERDAX_PASSWORD_MANAGER_PROCESSES

o CYBERDAX_SUPPORT_ASSETS

o CYBERDAX_SUPPORT_USERS

o CYBERDAX_MAINTENANCE_ASSETS

· Optional enrichment for suspicious parent processes or temporary-path execution

Tuning Explanation

This is a primary SIEM analytic for Phase 1B and must not alert on a single benign file interaction. It requires:

· access to cookie-store or session-artifact paths

· by a non-browser, non-password-manager process

· suspicious execution context

· and repeated behavior within a short window implemented through CRE event aggregation or equivalent counting logic

This rule suppresses:

· support assets

· support users

· maintenance assets

· approved browser and password-manager activity

Mandatory prerequisite

file access logging for cookie-store or token-adjacent browser artifacts must be present. If QRadar cannot distinguish file path and process reliably, or cannot implement repeated-event aggregation for the same host and user, this rule must not be treated as final production detection.

Detection Logic

· Building Block 1 identifies access to browser cookie or session artifacts

· Building Block 2 excludes approved browser and password-manager processes

· Building Block 3 identifies suspicious execution context

· Main CRE rule requires at least 4 matching access events by the same host and username within 10 minutes using aggregation or equivalent counting logic

· Main CRE rule suppresses support populations and creates an offense only when all conditions align

Operational Context

· Highest value where workstation file access telemetry is ingested

· Strong detector for cookie theft or session-artifact staging prior to alternate-auth abuse

· Severity should increase when correlated with suspicious external infrastructure access or later sign-in anomalies

Field Mapping Guidance

File access fields may map as:

· File Path

· Target Filename

· Object Name

Process fields may map as:

· Process Name

· Image

· Process

· Parent Process

· Command

User fields may map as:

· Username

· User Name

· Log Source Username

Host fields may map as:

· Destination Hostname

· Hostname

· Asset Hostname

System-Ready Code

Reference Set: CYBERDAX_BROWSER_PROCESSES
Reference Set: CYBERDAX_PASSWORD_MANAGER_PROCESSES
Reference Set: CYBERDAX_SUPPORT_ASSETS
Reference Set: CYBERDAX_SUPPORT_USERS
Reference Set: CYBERDAX_MAINTENANCE_ASSETS

Building Block: CYBERDAX_Browser_Cookie_Or_Session_Artifact_Access
when event category indicates file access
and file path matches one of:
*\Google\Chrome\User Data\*\Cookies
*\Microsoft\Edge\User Data\*\Cookies
*\Mozilla\Firefox\Profiles\*\cookies.sqlite

Building Block: CYBERDAX_NonBrowser_Process
when process name is not in CYBERDAX_BROWSER_PROCESSES
and process name is not in CYBERDAX_PASSWORD_MANAGER_PROCESSES

Building Block: CYBERDAX_Suspicious_Context
when parent process indicates office or script execution
or process path indicates Temp or Downloads execution

Rule: CYBERDAX Browser Cookie or Session Artifact Access by Non-Browser Process
when BB:CYBERDAX_Browser_Cookie_Or_Session_Artifact_Access matches
and BB:CYBERDAX_NonBrowser_Process matches
and BB:CYBERDAX_Suspicious_Context matches
and at least 4 matching access events occur by same destination hostname and username within 10 minutes
and destination hostname not in CYBERDAX_SUPPORT_ASSETS
and username not in CYBERDAX_SUPPORT_USERS
and destination hostname not in CYBERDAX_MAINTENANCE_ASSETS
then create offense
Severity: 8
Relevance: 8
Credibility: 8

Sigma

Rule Name

CyberDax Browser Cookie or Session Artifact Access by Non-Browser Process

Purpose

Provide portable supporting detection for browser cookie-store or token-adjacent session-artifact access by non-browser processes in suspicious execution context.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Endpoint file access logs in a Sigma-compatible backend

· Process name and parent process visibility

· Backend-side enrichment or naming conventions for support assets where possible

· Optional maintenance-window enrichment

Tuning Explanation

This is a supporting detector, not a standalone primary analytic. It is intended for backends that can preserve:

· file path access

· process name

· parent process context or equivalent execution-origin context

It should only be used where the backend can distinguish cookie or session-artifact paths and process context reliably. It must not be deployed unchanged if:

· file access telemetry is absent

· both parent process visibility and execution-path context are missing

· support population suppression cannot be approximated

This rule intentionally avoids broad wildcard coverage of all sessionstore artifacts to prevent noisy deployment in environments with poor artifact-path fidelity.

Detection Logic

· Detect access to browser cookie-store artifacts

· Exclude browser and password-manager processes

· Require either:

o suspicious parent process, or

o suspicious execution path context such as Temp or Downloads

· Forward matches to SIEM correlation and triage pipelines

Operational Context

· Useful as portable supporting content where endpoint file access telemetry exists

· Best used with stronger SIEM or EDR analytics

· Not intended to replace full primary detections

System-Ready Code

title: CyberDax Browser Cookie or Session Artifact Access by Non-Browser Process
id: c40f88df-1c91-4ea2-90f6-cyberdax-phase1b-cookie
status: experimental
description: Detects browser cookie-store access by non-browser processes with suspicious execution context.
logsource:
product: windows
category: file_access
detection:
selection_path:
    TargetFilename|contains:
      - '\Google\Chrome\User Data\'
      - '\Microsoft\Edge\User Data\'
      - '\Mozilla\Firefox\Profiles\'
    TargetFilename|endswith:
      - '\Cookies'
      - '\cookies.sqlite'
filter_browser:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\1password.exe'
      - '\lastpass.exe'
      - '\bitwarden.exe'
      - '\keepass.exe'
      - '\migwiz.exe'
      - '\usmt.exe'
selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\acrord32.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
selection_exec_path:
    Image|contains:
      - '\AppData\Local\Temp\'
      - '\Users\'
      - '\Downloads\'
condition: selection_path and not filter_browser and (selection_parent or selection_exec_path)
falsepositives:
- Approved migration or profile-sync tooling in environments without local suppression enrichment
level: high
tags:
- attack.t1539
- attack.t1550

YARA

Rule Name

CyberDax Browser Cookie and Session Artifact Staging Heuristic

Purpose

Support forensic triage by identifying scripts, binaries, or collected artifacts associated with browser cookie extraction, token-adjacent session-artifact staging, or local preparation of stolen session material.

ATT&CK Technique

· T1539 – Steal Web Session Cookie

· T1550 – Use of Alternate Authentication Material

Telemetry Dependency

· Endpoint forensic collections

· File triage workflows

· Incident response artifact review

· EDR file telemetry where available

Tuning Explanation

This rule is forensic and triage support only, not a primary prevention or real-time endpoint block. It is designed to identify artifacts associated with:

· browser cookie extraction

· cookie database copying

· local staging of session artifacts

· token-adjacent browser profile theft

To reduce noise, this rule requires a more specific combination:

· at least one browser-profile path indicator

· at least one action or staging indicator

· plus one additional supporting indicator

It should not be used as a standalone detector for normal browser profile files or raw memory content without context.

Detection Logic

· Match combinations of strings associated with browser cookie stores and local staging behavior

· Require path + action/staging + supporting indicator before alerting

· Use during triage of compromised endpoints or suspicious staging directories

Operational Context

· Highest value during post-alert investigation of endpoints showing suspicious cookie or session-store access

· Useful for confirming local staging or extraction behavior after EDR or SIEM detections

· Not intended as a standalone production prevention control

System-Ready Code

rule CYBERDAX_Browser_Cookie_And_Session_Artifact_Staging
{
meta:
description = "Heuristic for browser cookie or session artifact staging"
author = "CyberDax Detection Engineering"
version = "1.2"
scope = "forensic triage"

strings:
$path1 = "AppData\\\\Local\\\\Google\\\\Chrome\\\\User Data" nocase
$path2 = "AppData\\\\Local\\\\Microsoft\\\\Edge\\\\User Data" nocase
$path3 = "Mozilla\\\\Firefox\\\\Profiles" nocase

$artifact1 = "Cookies" nocase
$artifact2 = "cookies.sqlite" nocase
$artifact3 = "sessionstore" nocase
$artifact4 = "Network\\Cookies" nocase

$action1 = "export cookies" nocase
$action2 = "sqlite3" nocase
$action3 = "SELECT * FROM moz_cookies" nocase
$action4 = "SELECT host_key, name, encrypted_value FROM cookies" nocase

condition:
(1 of ($path*)) and (1 of ($action*)) and (1 of ($artifact*))
}

AWS

Rule Name

CyberDax Suspicious AWS Session or Token-Backed Access Following Session Artifact Theft Indicators

Purpose

Detect likely attacker use of stolen session cookies, federation artifacts, or alternate authentication material by identifying successful AWS console or STS activity from abnormal principal context shortly after browser session-artifact theft indicators.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1078 – Valid Accounts

Telemetry Dependency

· AWS CloudTrail

· Successful events for:

o ConsoleLogin

o AssumeRole

o GetCallerIdentity

o GetFederationToken where applicable

· Principal identity, source IP, user agent, region

· Approved corporate egress allowlists

· Approved service or automation principal allowlists

· Baseline data for:

o known IP by principal

o known region by principal

o known user agent by principal

· Optional but strongly recommended:

o correlation flag or enrichment from recent Phase 1B endpoint detections

o role sensitivity or privileged principal classification

o federation context where available

Tuning Explanation

This is a primary cloud-use detector for Phase 1B downstream abuse and is intentionally constrained to successful activity in abnormal principal context. It does not alert on successful cloud access alone.

This rule requires:

· successful AWS console or STS identity activity

· abnormal source or client context such as:

o IP not previously associated with the principal

o region not previously associated with the principal

o user agent not previously associated with the principal

· plus either:

o recent Phase 1B cookie or session-artifact theft context, or

o repeated suspicious identity-validation activity in a short window

This suppresses:

· approved corporate egress

· approved service and automation principals

· known expected federation infrastructure where locally modeled

This rule must not be deployed as a generic non-corporate login detector.

Detection Logic

· Detect successful ConsoleLogin, AssumeRole, GetCallerIdentity, or GetFederationToken activity

· Exclude approved service principals and approved corporate egress

· Require abnormal source or client context for the principal

· Require either:

o recent Phase 1B correlation, or

o repeated suspicious identity-validation behavior within a bounded interval

· Preserve principal, source IP, user agent, region, and sequence context for triage

Operational Context

· Highest value in environments using federated enterprise identities into AWS

· Strong signal when attackers pivot from stolen browser session artifacts into AWS console or STS-backed access

· Should be escalated when preceded by endpoint cookie or session-store access detections

· If baseline data for IP, region, or user agent is unavailable, do not treat this as final production detection without local adaptation

System-Ready Code

SELECT

eventtime,

useridentity.arn AS principal_arn,

sourceipaddress AS source_ip,

eventname,

useragent,

awsregion

FROM cloudtrail_logs

WHERE eventname IN ('ConsoleLogin','AssumeRole','GetCallerIdentity','GetFederationToken')

AND errorcode IS NULL

AND useridentity.arn NOT IN (

SELECT principal FROM approved_service_principals

)

AND sourceipaddress NOT IN (

SELECT ip_or_range FROM approved_corporate_ranges

)

AND (

sourceipaddress NOT IN (

SELECT ip FROM baseline_ip_by_principal

WHERE principal = useridentity.arn

)

OR awsregion NOT IN (

SELECT region FROM baseline_region_by_principal

WHERE principal = useridentity.arn

)

OR useragent NOT IN (

SELECT user_agent FROM baseline_user_agent_by_principal

WHERE principal = useridentity.arn

)

AND (

useridentity.arn IN (

SELECT principal FROM recent_phase1b_principals

)

OR useridentity.arn IN (

SELECT principal_arn FROM repeated_identity_validation_window

)

OR eventname IN ('AssumeRole','GetFederationToken')

);

Azure

Rule Name

CyberDax Suspicious Microsoft Entra Sign-In Following Session Cookie or Token Artifact Theft Indicators

Purpose

Detect likely attacker use of stolen session cookies, refresh tokens, or alternate authentication material by identifying successful Entra sign-ins from abnormal user context shortly after browser session-artifact theft indicators.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1078 – Valid Accounts

Telemetry Dependency

· Microsoft Entra SigninLogs

· Successful sign-in events

· User principal, source IP, device context, user agent, app context

· Watchlists for:

o approved corporate IP ranges

o approved automation identities

· Optional but strongly recommended:

o trusted or named-location suppression

o baseline or enrichment data for new or rare IP/device/user-agent context

o correlation flag from recent Phase 1B endpoint detections

o token-protection or sign-in-risk context where locally available

Tuning Explanation

This is a primary cloud identity detector for Phase 1B downstream abuse and is designed to surface suspicious successful sign-ins consistent with alternate authentication material use after session-artifact theft. It is intentionally biased toward:

· successful sign-ins

· abnormal context

· temporal coupling to earlier endpoint evidence

This rule requires:

· successful sign-in activity

· abnormal user context such as:

o non-corporate source IP

o repeated sign-ins in a short window

o uncommon device or client context where available

· plus either:

o recent Phase 1B cookie/session-artifact theft context, or

o repeated suspicious sign-in behavior in a short interval

This suppresses:

· approved corporate IP ranges

· approved automation identities

· trusted or named locations where locally modeled

It must not be deployed as a generic sign-in anomaly rule.

Detection Logic

· Detect successful Entra sign-ins

· Exclude approved corporate IP ranges and automation identities

· Summarize short-window sign-in activity by user, IP, device, and user agent

· Require either:

o recent Phase 1B endpoint correlation, or

o repeated suspicious sign-in activity in a bounded interval

· Preserve user, source, device, user agent, and app context for triage

Operational Context

· Highest value where enterprise identities provide access to Microsoft cloud services

· Strong signal when attackers pivot from local browser session-artifact theft into Entra-backed access

· If trusted-location suppression is unavailable, local IP suppression or equivalent controls must be added before production deployment

· Token-protection or sign-in-risk context should be treated as supporting enrichment, not sole trigger

System-Ready Code

let ApprovedIPs = _GetWatchlist('cyberdax_approved_ip_ranges') | project SearchKey;
let AutomationAccounts = _GetWatchlist('cyberdax_automation_accounts') | project SearchKey;
let RecentPhase1BUsers = _GetWatchlist('cyberdax_recent_phase1b_users') | project SearchKey;
SigninLogs
| where ResultType == 0
| where UserPrincipalName !in (AutomationAccounts)
| where IPAddress !in (ApprovedIPs)
| extend DeviceId = tostring(DeviceDetail.deviceId), UA = tostring(UserAgent)
| summarize
    sign_in_count = count(),
    first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated),
    apps = make_set(AppDisplayName)
by UserPrincipalName, IPAddress, DeviceId, UA, bin(TimeGenerated, 30m)
| extend phase1b_context = UserPrincipalName in (RecentPhase1BUsers)
| where phase1b_context == true or sign_in_count > 1

Deployment Note

· If approved IP watchlists are unavailable, substitute trusted-location or named-location suppression.

· If repetition or abnormal-context modeling is unavailable, do not deploy this rule as a final production analytic.

· Missing device identity alone must not be treated as suspicious without repetition, enrichment, or Phase 1B correlation.

GCP

Rule Name

CyberDax Suspicious GCP Identity Validation or Token-Backed Access Following Session Artifact Theft Indicators

Purpose

Detect likely attacker use of stolen session cookies, browser tokens, or alternate authentication material by identifying authenticated GCP identity-validation or privileged control-plane activity from abnormal principal context shortly after session-artifact theft indicators.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1078 – Valid Accounts

· T1098 – Account Manipulation

Telemetry Dependency

· GCP Cloud Audit Logs

· Principal identity, caller IP, method name, project context

· Approved corporate IP allowlists

· Optional but strongly recommended:

o service account and automation allowlists

o privileged method classification

o baseline caller IP or source-context modeling by principal

o correlation with recent Phase 1B endpoint detections

Tuning Explanation

This is a primary GCP follow-on abuse detector for Phase 1B and is intentionally designed to cover both:

1. suspicious authenticated identity validation or access establishment behavior

2. privileged IAM or control-plane activity

It requires:

· authenticated GCP activity

· abnormal principal context such as:

o caller IP not previously associated with the principal

o source context not previously associated with the principal

· plus either:

o recent Phase 1B cookie/session-artifact theft context, or

o privileged IAM or credential-affecting method usage

This prevents the rule from becoming either:

· too broad and noisy, or

· too narrow and blind to early access-establishment behavior

This rule must not be treated as proof of cookie theft by itself. It is downstream evidence of likely alternate-auth-material abuse.

Detection Logic

· Detect authenticated GCP identity-related or privileged control-plane activity

· Include:

o privileged IAM methods

o identity-establishing or validation behavior where observable

· Exclude approved corporate ranges

· Require abnormal principal context

· Require either recent Phase 1B correlation or privileged method use

· Preserve principal, caller IP, method, and project context for triage

Operational Context

· Highest value in organizations using federated enterprise identities into GCP

· Strong detector for cloud pivot behavior after local session-artifact theft

· Particularly useful where attackers move rapidly from endpoint session theft into cloud identity validation and then privilege use

· If baseline source modeling is unavailable, do not treat this as final production detection without local adaptation

System-Ready Code

SELECT
timestamp,
protopayload_auditlog.authenticationInfo.principalEmail AS principal_email,
protopayload_auditlog.methodName                        AS method_name,
protopayload_auditlog.requestMetadata.callerIp         AS caller_ip,
resource.labels.project_id                             AS project_id
FROM `project.dataset.cloudaudit_googleapis_com_activity_*`
WHERE protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
AND protopayload_auditlog.requestMetadata.callerIp NOT IN (
  SELECT ip_or_range FROM `project.dataset.approved_corporate_ranges`
)
AND (
    protopayload_auditlog.methodName IN (
      'SetIamPolicy',
      'google.iam.admin.v1.CreateServiceAccountKey',
      'google.iam.admin.v1.SignJwt',
      'google.iam.admin.v1.GenerateAccessToken',
      'google.iam.admin.v1.GenerateIdToken',
      'google.iam.credentials.v1.GenerateAccessToken',
      'google.iam.credentials.v1.GenerateIdToken',
      'google.iam.admin.v1.GetServiceAccount',
      'google.iam.admin.v1.ListServiceAccounts'
    )
)
AND (
    protopayload_auditlog.requestMetadata.callerIp NOT IN (
      SELECT ip FROM `project.dataset.baseline_ip_by_principal`
      WHERE principal = protopayload_auditlog.authenticationInfo.principalEmail
    )
    OR protopayload_auditlog.authenticationInfo.principalEmail IN (
      SELECT principal FROM `project.dataset.recent_phase1b_principals`
    )
);

Phase 1C — Authentication Material Reuse Preparation

Suricata

Rule Name

CyberDax Suspicious Authentication Material Staging Transfer Traffic from User Workstations

Purpose

Provide corroborating network telemetry for likely post-access staging or transfer of stolen authentication material by identifying repeated outbound upload-like traffic from user workstations to suspicious external infrastructure after local preparation of credential or session artifacts is suspected.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1078 – Valid Accounts

· T1539 – Steal Web Session Cookie

Telemetry Dependency

· Egress HTTP inspection or high-fidelity proxy metadata

· Defined user workstation subnet variables

· Defined approved enterprise authentication destination variables

· Defined approved enterprise storage and sync destination variables

· Destination allowlists for:

o enterprise identity providers

o sanctioned SaaS storage or sync platforms

o approved remote administration or secure access infrastructure

· Optional but strongly recommended:

o destination reputation or novelty enrichment

o upload or POST metadata

o endpoint-to-network correlation from SIEM or SOC pipeline

Tuning Explanation

This is a corroborating detector only and is now explicitly narrowed to transfer behavior after local auth-material preparation, not generic auth-related browsing.

To remain low-noise, this rule requires:

· source is a standard user workstation

· destination is external and not in approved auth or approved storage infrastructure

· repeated upload-like or POST-heavy behavior in a short interval

· destination context suggestive of transfer or collection behavior

It must not fire on:

· approved cloud storage or sanctioned sync destinations

· trusted authentication portals

· benign occasional uploads to allowlisted destinations

· generic POST traffic without suspicious destination context

This rule should only be interpreted as corroborating evidence when paired with endpoint staging or export behavior.

Detection Logic

· Detect repeated outbound HTTP POST or upload-like traffic from user workstations

· Match suspicious destination semantics associated with transfer or collection behavior such as:

o upload

o collect

o sync

o token

o session

· Exclude approved identity and approved enterprise storage infrastructure

· Use only as corroborating evidence when combined with endpoint auth-material staging behavior

Operational Context

· Highest value in environments with strong egress metadata and maintained allowlists

· Useful for triage after endpoint detections showing archive, copy, export, or staging behavior affecting auth artifacts

· Must not be deployed as a standalone primary analytic for this phase

System-Ready Code

alert http $HOME_NET any -> $EXTERNAL_NET any (

msg:"CYBERDAX Possible Staged Credential/Session Artifact Exfiltration";

flow:established,to_server;

http.method; content:"POST";

http.header; content:"application/octet-stream"; nocase; distance:0; within:200;

http.request_body; content:"Cookies"; nocase;

http.request_body; content:"Login Data"; nocase;

detection_filter:track by_src, count 5, seconds 180;

classtype:exfiltration;

sid:900001;

rev:2;

)

SentinelOne

Rule Name

CyberDax Authentication Material Staging via Direct Archive, Copy, or Export Handling of Credential or Session Artifacts

Purpose

Detect likely preparation of stolen authentication material for reuse by identifying direct handling of credential or session artifacts by staging, archive, compression, or export-related processes on user endpoints.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1555 – Credentials from Password Stores

Telemetry Dependency

· SentinelOne Deep Visibility process telemetry

· File access or file interaction telemetry

· Parent-child process visibility

· Command-line visibility

· Endpoint grouping or naming to distinguish support and admin systems from user endpoints

· Optional but recommended:

o archive creation telemetry

o temp-path or staging directory context

o outbound network enrichment

o maintenance-window suppression

Tuning Explanation

This is a primary Phase 1C endpoint analytic and is now explicitly anchored to post-access handling rather than initial access.

It requires:

· credential or session artifacts are directly handled by:

o archive utilities

o copy/export tooling

o scripting or shell processes commonly used for staging

· suspicious execution context such as:

o Office or script parent

o Temp or Downloads execution origin

o unusual user-driven execution chain

This rule does not fire on artifact access alone.
It requires direct interaction by staging-related processes, which keeps the rule in Phase 1C and out of Phase 1A/1B.

This rule suppresses:

· approved browsers

· sanctioned password managers

· support/admin populations

· approved migration or backup tooling where locally applicable

Detection Logic

· Identify direct handling of credential or session artifacts by staging-related processes

· Require process class consistent with archive, copy, export, scripting, or shell-driven preparation

· Require suspicious execution context or suspicious origin path

· Exclude support and admin populations before alerting

Operational Context

· Highest value on standard user workstations

· Strong signal for preparation of stolen auth material for later valid-account or alternate-auth use

· Escalate when followed by:

o suspicious outbound transfer traffic

o unusual cloud sign-ins

o alternate-authentication indicators

· If file interaction telemetry is incomplete, do not treat this as final production detection without local validation

System-Ready Code

Splunk

Rule Name

CyberDax Authentication Material Staging with Direct Artifact Handling and Thresholded Preparation Context

Purpose

Detect likely preparation of stolen authentication material for later reuse by correlating repeated direct handling of credential or session artifacts by staging-related processes on non-support endpoints.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Normalized endpoint file-access telemetry

· Normalized process execution telemetry

· Optional but recommended:

o archive creation telemetry

o outbound network telemetry

o downstream cloud or identity sign-in enrichment

· Lookup tables:

o browser process allowlist

o password-manager allowlist

o support assets

o support users

o maintenance windows

o approved migration or administrative tooling

Tuning Explanation

This is a primary SIEM analytic for Phase 1C and is now explicitly constrained to direct staging-related handling of auth material.

It requires:

· direct interaction with credential or session artifacts

· by staging-related processes such as:

o archive utilities

o scripting engines

o shell processes used for export or packaging

· on non-support populations

· exceeding a threshold in a bounded interval

This rule suppresses:

· browsers

· password managers

· support populations

· maintenance windows

· approved migration or backup tooling

This rule must not be treated as:

· any archive process touching any user files

· any single access to Cookies or Login Data

· loose co-occurrence between artifact access and staging process presence

It is now anchored on direct process-to-artifact handling, which keeps it phase-pure.

Detection Logic

· Collect file-access events targeting credential or session artifacts

· Normalize process and user names

· Exclude approved browser, password-manager, support, and maintenance populations

· Require file interaction by staging-related processes:

o archive utilities

o scripting engines

o shell utilities used for export or packaging

· Aggregate repeated direct handling behavior by host, user, and process in a bounded window

· Alert only when threshold is exceeded

· Preserve artifact path set, process list, and timing for triage

Operational Context

· Intended for workstation fleets where local export or compression of auth-material artifacts should be rare

· Strong precursor to later valid-account abuse and alternate-auth use

· Severity should increase when followed by:

o external transfer traffic

o unusual cloud sign-ins

o session-conflict anomalies

· If file-access telemetry is sparse, do not treat this as final production detection without local validation

System-Ready Code

index=edr_logs
(
file_path="*\\Login Data"
OR file_path="*\\Cookies"
OR file_path="*\\cookies.sqlite"
OR file_path="*\\logins.json"
OR file_path="*\\key4.db"
)
| eval process_name=lower(process_name), user=lower(user)
| lookup cyberdax_browser_process_allowlist process_name OUTPUT process_name as matched_browser
| lookup cyberdax_password_manager_allowlist process_name OUTPUT process_name as matched_pwmanager
| lookup cyberdax_support_assets asset as host OUTPUT asset as matched_asset
| lookup cyberdax_support_users user as user OUTPUT user as matched_user
| lookup cyberdax_maintenance_windows asset as host OUTPUT maintenance_active
| where isnull(matched_browser)
AND isnull(matched_pwmanager)
AND isnull(matched_asset)
AND isnull(matched_user)
AND (isnull(maintenance_active) OR maintenance_active!="true")
| search process_name IN ("7z.exe","7za.exe","winrar.exe","rar.exe","powershell.exe","cmd.exe","wscript.exe","cscript.exe")
| bin _time span=10m
| stats count as access_count earliest(_time) as first_seen latest(_time) as last_seen values(file_path) as file_paths by host user process_name _time
| where access_count > 4
| eval risk_score=84
| table first_seen last_seen host user process_name file_paths access_count risk_score

Elastic

Rule Name

CyberDax Authentication Material Staging via Direct Archive, Copy, or Export Handling of Credential or Session Artifacts

Purpose

Detect likely preparation of stolen authentication material for reuse by identifying direct handling of credential or session artifacts by archive, compression, export, or shell-driven staging processes on user endpoints.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Elastic Defend or equivalent endpoint process-linked file access telemetry

· Process execution telemetry

· Parent-child process visibility

· Host role or asset metadata identifying support or administrative systems

· Optional:

o labels for maintenance windows

o archive creation enrichment

o reputation or signature metadata

o downstream network or cloud-auth enrichment

Tuning Explanation

This is a primary endpoint analytic for Phase 1C and is explicitly anchored to post-access handling, not initial artifact access. It requires:

· credential or session artifacts are directly handled by staging-related processes

· suspicious execution context

· support and admin suppression

This rule suppresses:

· browsers

· password managers

· support or administrative workstations

· maintenance windows where available

· approved migration or backup tooling where locally modeled

This rule must not be reduced to:

· any access to Cookies or Login Data

· any archive process touching arbitrary user files

· loose co-occurrence between artifact access and scripting or archive tooling

Mandatory prerequisite:

this rule is production-valid only where endpoint telemetry preserves process-linked file access. If the backend cannot reliably show that the same process performed the file interaction against the auth-material artifact, this rule must be treated as partial detection only, not final production detection.

Detection Logic

· Detect direct file access to credential or session artifacts

· Require accessing process to be a staging-related utility such as:

o archive utilities

o shell utilities

o scripting engines commonly used for export or packaging

· Require suspicious execution context such as:

o Office or Outlook parent

o script parent

o Temp or Downloads execution origin

· Exclude support populations and maintenance windows before alerting

Operational Context

· Highest value on standard user Windows endpoints

· Strong signal for local preparation of stolen auth material for later alternate-auth or valid-account use

· Best escalated when followed by:

o suspicious outbound transfer traffic

o unusual cloud sign-ins

o alternate-authentication indicators

· If file access telemetry is incomplete or not process-linked, do not treat this as final production detection without local validation

System-Ready Code

file where host.os.type == "windows"
and file.path like~ (
    "*\\Google\\Chrome\\User Data\\*\\Login Data",
    "*\\Google\\Chrome\\User Data\\*\\Cookies",
    "*\\Microsoft\\Edge\\User Data\\*\\Login Data",
    "*\\Microsoft\\Edge\\User Data\\*\\Cookies",
    "*\\Mozilla\\Firefox\\Profiles\\*\\cookies.sqlite",
    "*\\Mozilla\\Firefox\\Profiles\\*\\logins.json",
    "*\\Mozilla\\Firefox\\Profiles\\*\\key4.db"
)
and process.name in ("7z.exe","7za.exe","winrar.exe","rar.exe","powershell.exe","cmd.exe","wscript.exe","cscript.exe")
and (
    process.parent.name in ("winword.exe","excel.exe","powerpnt.exe","outlook.exe","acrord32.exe","wscript.exe","cscript.exe","mshta.exe","rundll32.exe")
    or process.executable regex~ "(?i)\\\\AppData\\\\Local\\\\Temp\\\\"
    or process.executable regex~ "(?i)\\\\Users\\\\[^\\\\]+\\\\Downloads\\\\"
)
and not host.name regex~ "(?i)^(HD-|HELPDESK-|IT-|SUPPORT-|SRV-IT-)"
and (labels.maintenance_window == null or labels.maintenance_window != "true")

QRadar

Rule Name

CyberDax Authentication Material Staging by Archive, Export, or Scripting Process on Non-Support Endpoint

Purpose

Detect likely preparation of stolen authentication material for reuse by identifying repeated direct handling of credential or session artifacts by staging-related processes on non-support endpoints.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Endpoint file access logs normalized into QRadar

· Process creation or file access telemetry with:

o username

o hostname

o file path

o process name

o parent process or process path where available

· Reference sets:

o CYBERDAX_BROWSER_PROCESSES

o CYBERDAX_PASSWORD_MANAGER_PROCESSES

o CYBERDAX_SUPPORT_ASSETS

o CYBERDAX_SUPPORT_USERS

o CYBERDAX_MAINTENANCE_ASSETS

o CYBERDAX_APPROVED_MIGRATION_TOOLS where locally applicable

· Optional enrichment for suspicious parent processes or temporary-path execution

Tuning Explanation

This is a primary SIEM analytic for Phase 1C and must not alert on a single benign file interaction. It requires:

· access to credential or session artifact paths

· by staging-related processes

· suspicious execution context

· at least 4 repeated direct handling events by the same host and user within 10 minutes, implemented through CRE aggregation or equivalent counting logic

This rule suppresses:

· approved browser and password-manager processes

· support assets

· support users

· maintenance assets

· approved migration or backup tooling

Mandatory prerequisite

QRadar must preserve reliable process-to-file interaction visibility. If file path, process name, or repeated-event aggregation cannot be implemented, this rule must not be treated as final production detection.

Detection Logic

· Building Block 1 identifies access to credential or session artifacts

· Building Block 2 identifies staging-related processes such as archive, shell, or scripting utilities

· Building Block 3 identifies suspicious execution context

· Main CRE rule requires at least 4 matching direct-handling events by the same host and user within 10 minutes

· Suppress support populations and create an offense only when all conditions align

Operational Context

· Highest value where workstation file access telemetry is ingested

· Strong detector for local preparation of auth material before alternate-auth or cloud pivot behavior

· Severity should increase when correlated with suspicious outbound transfer or later sign-in anomalies

Field Mapping Guidance

File access fields may map as:

· File Path

· Target Filename

· Object Name

Process fields may map as:

· Process Name

· Image

· Process

· Parent Process

· Command

User fields may map as:

· Username

· User Name

· Log Source Username

Host fields may map as:

· Destination Hostname

· Hostname

· Asset Hostname

System-Ready Code

Reference Set: CYBERDAX_BROWSER_PROCESSES
Reference Set: CYBERDAX_PASSWORD_MANAGER_PROCESSES
Reference Set: CYBERDAX_SUPPORT_ASSETS
Reference Set: CYBERDAX_SUPPORT_USERS
Reference Set: CYBERDAX_MAINTENANCE_ASSETS
Reference Set: CYBERDAX_APPROVED_MIGRATION_TOOLS

Building Block: CYBERDAX_Auth_Material_Artifact_Access
when event category indicates file access
and file path matches one of:
*\Google\Chrome\User Data\*\Login Data
*\Google\Chrome\User Data\*\Cookies
*\Microsoft\Edge\User Data\*\Login Data
*\Microsoft\Edge\User Data\*\Cookies
*\Mozilla\Firefox\Profiles\*\cookies.sqlite
*\Mozilla\Firefox\Profiles\*\logins.json
*\Mozilla\Firefox\Profiles\*\key4.db

Building Block: CYBERDAX_Staging_Process
when process name is one of:
7z.exe
7za.exe
winrar.exe
rar.exe
powershell.exe
cmd.exe
wscript.exe
cscript.exe
and process name is not in CYBERDAX_BROWSER_PROCESSES
and process name is not in CYBERDAX_PASSWORD_MANAGER_PROCESSES
and process name is not in CYBERDAX_APPROVED_MIGRATION_TOOLS

Building Block: CYBERDAX_Suspicious_Context
when parent process indicates office or script execution
or process path indicates Temp or Downloads execution

Rule: CYBERDAX Authentication Material Staging by Archive, Export, or Scripting Process
when BB:CYBERDAX_Auth_Material_Artifact_Access matches
and BB:CYBERDAX_Staging_Process matches
and BB:CYBERDAX_Suspicious_Context matches
and at least 4 matching access events occur by same destination hostname and username within 10 minutes
and destination hostname not in CYBERDAX_SUPPORT_ASSETS
and username not in CYBERDAX_SUPPORT_USERS
and destination hostname not in CYBERDAX_MAINTENANCE_ASSETS
then create offense
Severity: 8
Relevance: 8
Credibility: 8

Sigma

Rule Name

CyberDax Authentication Material Staging by Archive or Scripting Process

Purpose

Provide portable supporting detection for direct handling of credential or session artifacts by staging-related processes in suspicious execution context.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Endpoint file access logs in a Sigma-compatible backend

· Process name and parent process visibility

· Backend-side enrichment or naming conventions for support assets where possible

· Optional maintenance-window enrichment

Tuning Explanation
This is a supporting detector, not a standalone primary analytic. It is intended for backends that can preserve:

· file path access

· process name

· parent process context or equivalent execution-origin context

It should only be used where the backend can distinguish direct file access to auth-material artifacts by staging-related processes. It must not be deployed unchanged if:

· file access telemetry is absent

· both parent process visibility and execution-path context are missing

· support population suppression cannot be approximated

Production-grade expectation:

This rule should normally be used with backend correlation, enrichment, or stronger SIEM/EDR analytics. It is not intended to stand alone in high-noise environments.

This rule intentionally requires a staging-related process class to preserve Phase 1C purity.

Detection Logic

· Detect access to credential or session artifacts

· Require staging-related process such as archive, shell, or scripting utility

· Require either suspicious parent process or suspicious execution path context

· Forward matches to SIEM correlation and triage pipelines

Operational Context

· Useful as portable supporting content where endpoint file access telemetry exists

· Best used with stronger SIEM or EDR analytics

· Not intended to replace full primary detections

System-Ready Code

title: CyberDax Authentication Material Staging by Archive or Scripting Process
id: 6a7e230c-4f27-4f56-9a89-cyberdax-phase1c-staging
status: experimental
description: Detects direct handling of credential or session artifacts by staging-related processes with suspicious execution context.
logsource:
product: windows
category: file_access
detection:
selection_path:
    TargetFilename|contains:
      - '\Google\Chrome\User Data\'
      - '\Microsoft\Edge\User Data\'
      - '\Mozilla\Firefox\Profiles\'
    TargetFilename|endswith:
      - '\Login Data'
      - '\Cookies'
      - '\cookies.sqlite'
      - '\logins.json'
      - '\key4.db'
selection_process:
    Image|endswith:
      - '\7z.exe'
      - '\7za.exe'
      - '\winrar.exe'
      - '\rar.exe'
      - '\powershell.exe'
      - '\cmd.exe'
      - '\wscript.exe'
      - '\cscript.exe'
selection_parent:
    ParentImage|endswith:
      - '\winword.exe'
      - '\excel.exe'
      - '\powerpnt.exe'
      - '\outlook.exe'
      - '\acrord32.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
selection_exec_path:
    Image|contains:
      - '\AppData\Local\Temp\'
      - '\Users\'
      - '\Downloads\'
condition: selection_path and selection_process and (selection_parent or selection_exec_path)
falsepositives:
- Approved migration or backup tooling in environments without local suppression enrichment
level: high
tags:
- attack.t1550
- attack.t1539
- attack.t1555

YARA

Rule Name

CyberDax Authentication Material Staging and Packaging Heuristic

Purpose

Support forensic triage by identifying scripts, binaries, or collected artifacts associated with packaging, export, or local staging of stolen credential or session artifacts for later reuse.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1555 – Credentials from Password Stores

Telemetry Dependency

· Endpoint forensic collections

· File triage workflows

· Incident response artifact review

· EDR file telemetry where available

Tuning Explanation

This rule is forensic and triage support only, not a primary prevention or real-time endpoint block. It is designed to identify artifacts associated with:

· local packaging of credential or session artifacts

· archive or export workflows touching auth-material paths

· staged reuse preparation of stolen browser artifacts

To reduce noise, the rule requires a specific combination:

· at least one browser profile or artifact path indicator

· at least one staging or packaging action indicator

· plus one additional artifact indicator

It should not be used as a standalone detector for normal browser profile files or benign archives without context.

Detection Logic

· Match combinations of strings associated with browser artifact paths and staging or packaging behavior

· Require path + staging/packaging action + additional artifact indicator before alerting

· Use during triage of compromised endpoints or suspicious staging directories

Operational Context

· Highest value during post-alert investigation of endpoints showing suspicious export or staging behavior

· Useful for confirming packaging or preparation of stolen auth material after EDR or SIEM detections

· Not intended as a standalone production prevention control

System-Ready Code

rule CYBERDAX_Authentication_Material_Staging_And_Packaging
{
    meta:
        description = "Heuristic for staging or packaging stolen authentication material"
        author = "CyberDax Detection Engineering"
        version = "1.1"
        scope = "forensic triage"

    strings:
        $path1 = "AppData\\\\Local\\\\Google\\\\Chrome\\\\User Data" nocase
        $path2 = "AppData\\\\Local\\\\Microsoft\\\\Edge\\\\User Data" nocase
        $path3 = "Mozilla\\\\Firefox\\\\Profiles" nocase

        $artifact1 = "Login Data" nocase
        $artifact2 = "Cookies" nocase
        $artifact3 = "cookies.sqlite" nocase
        $artifact4 = "logins.json" nocase
        $artifact5 = "key4.db" nocase

        $action1 = "7z a" nocase
        $action2 = "WinRAR" nocase
        $action3 = "Compress-Archive" nocase
        $action4 = "export" nocase

    condition:
        (1 of ($path*)) and (1 of ($action*)) and (1 of ($artifact*))
}

AWS

Rule Name

CyberDax Suspicious AWS Access Following Authentication Material Staging Indicators

Purpose

Detect likely attacker use of previously staged authentication material by identifying successful AWS identity activity from abnormal principal context shortly after endpoint-side preparation of credential, cookie, or token artifacts.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1078 – Valid Accounts

· T1539 – Steal Web Session Cookie

Telemetry Dependency

· AWS CloudTrail

· Successful events for:

o ConsoleLogin

o AssumeRole

o GetCallerIdentity

o GetFederationToken where applicable

· Principal identity, source IP, user agent, region

· Approved corporate egress allowlists

· Approved service or automation principal allowlists

· Baseline data for:

o known IP by principal

o known region by principal

o known user agent by principal

· Optional but strongly recommended:

o correlation flag or enrichment from recent Phase 1C endpoint detections

o role sensitivity or privileged principal classification

o federation context where available

Tuning Explanation

This is a primary cloud-use detector for Phase 1C downstream abuse and is intentionally constrained to successful activity in abnormal principal context. It must remain a post-staging detector, not a generic AWS anomaly rule.

This rule requires:

· successful AWS console or STS identity activity

· abnormal source or client context such as:

o IP not previously associated with the principal

o region not previously associated with the principal

o user agent not previously associated with the principal

· plus one of the following:

o recent Phase 1C auth-material staging context

o repeated suspicious identity-validation activity in a short window

o privileged role or federation-sensitive activity in abnormal context

This suppresses:

· approved corporate egress

· approved service and automation principals

· known expected federation infrastructure where locally modeled

This rule must not be deployed as a generic non-corporate login detector.
If recent Phase 1C correlation is unavailable, abnormal context alone is not enough unless it is paired with repeated identity-validation behavior or higher-risk role/federation activity.

Detection Logic

· Detect successful ConsoleLogin, AssumeRole, GetCallerIdentity, or GetFederationToken activity

· Exclude approved service principals and approved corporate egress

· Require abnormal source or client context for the principal

· Require either:

o recent Phase 1C correlation, or

o repeated suspicious identity-validation behavior, or

o sensitive role/federation activity in abnormal context

· Preserve principal, source IP, user agent, region, and sequence context for triage

Operational Context

· Highest value in environments using federated enterprise identities into AWS

· Strong signal when attackers pivot from locally staged authentication material into AWS console or STS-backed access

· Should be escalated when preceded by endpoint archive, export, or packaging activity affecting auth artifacts

· If baseline data for IP, region, or user agent is unavailable, do not treat this as final production detection without local adaptation

System-Ready Code

SELECT
eventtime,
useridentity.arn            AS principal_arn,
sourceipaddress             AS source_ip,
eventname,
useragent,
awsregion
FROM cloudtrail_logs
WHERE eventname IN ('ConsoleLogin','AssumeRole','GetCallerIdentity','GetFederationToken')
AND errorcode IS NULL
AND useridentity.arn NOT IN (
    SELECT principal FROM approved_service_principals
)
AND sourceipaddress NOT IN (
    SELECT ip_or_range FROM approved_corporate_ranges
)
AND (
    sourceipaddress NOT IN (
      SELECT ip FROM baseline_ip_by_principal
      WHERE principal = useridentity.arn
    )
    OR awsregion NOT IN (
      SELECT region FROM baseline_region_by_principal
      WHERE principal = useridentity.arn
    )
    OR useragent NOT IN (
      SELECT user_agent FROM baseline_user_agent_by_principal
      WHERE principal = useridentity.arn
    )
)
AND (
    useridentity.arn IN (
      SELECT principal FROM recent_phase1c_principals
    )
    OR useridentity.arn IN (
      SELECT principal_arn
      FROM repeated_identity_validation_window
    )
    OR eventname IN ('AssumeRole','GetFederationToken')
);

Optional Event Pattern Filter

{
"source": ["aws.signin", "aws.sts"],
"detail-type": ["AWS API Call via CloudTrail", "AWS Console Sign In via CloudTrail"],
"detail": {
"eventName": ["ConsoleLogin", "AssumeRole", "GetCallerIdentity", "GetFederationToken"]
}
}

Azure

Rule Name

CyberDax Suspicious Microsoft Entra Sign-In Following Authentication Material Staging Indicators

Purpose

Detect likely attacker use of staged cookies, refresh tokens, or alternate authentication material by identifying successful Entra sign-ins from abnormal user context shortly after endpoint-side preparation of auth artifacts.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1078 – Valid Accounts

Telemetry Dependency

· Microsoft Entra SigninLogs

· Successful sign-in events

· User principal, source IP, device context, user agent, app context

· Watchlists for:

o approved corporate IP ranges

o approved automation identities

· Optional but strongly recommended:

o trusted or named-location suppression

o baseline or enrichment data for new or rare IP/device/user-agent context

o correlation flag from recent Phase 1C endpoint detections

o token-protection or sign-in-risk context where locally available

Tuning Explanation

This is a primary cloud identity detector for Phase 1C downstream abuse and is designed to surface suspicious successful sign-ins consistent with alternate authentication material use after local staging or export of auth artifacts.

This rule requires:

· successful sign-in activity

· abnormal user context such as:

o non-corporate source IP

o repeated sign-ins in a short window

o uncommon device or client context where available

· plus one of the following:

o recent Phase 1C auth-material staging context

o repeated suspicious sign-in behavior in a short interval

o token-protection or sign-in-risk support in abnormal context where locally available

This suppresses:

· approved corporate IP ranges

· approved automation identities

· trusted or named locations where locally modeled

It must not be deployed as a generic sign-in anomaly rule.
If recent Phase 1C correlation is unavailable, the rule should rely on abnormal context plus repetition, not single successful sign-ins.

Detection Logic

· Detect successful Entra sign-ins

· Exclude approved corporate IP ranges and automation identities

· Summarize short-window sign-in activity by user, IP, device, and user agent

· Require either:

o recent Phase 1C endpoint correlation, or

o repeated suspicious sign-in activity in a bounded interval

· Preserve user, source, device, user agent, and app context for triage

Operational Context

· Highest value where enterprise identities provide access to Microsoft cloud services

· Strong signal when attackers pivot from locally staged browser or token artifacts into Entra-backed access

· If trusted-location suppression is unavailable, local IP suppression or equivalent controls must be added before production deployment

· Token-protection or sign-in-risk context should be treated as supporting enrichment, not sole trigger

System-Ready Code

let ApprovedIPs = _GetWatchlist('cyberdax_approved_ip_ranges') | project SearchKey;
let AutomationAccounts = _GetWatchlist('cyberdax_automation_accounts') | project SearchKey;
let RecentPhase1CUsers = _GetWatchlist('cyberdax_recent_phase1c_users') | project SearchKey;
SigninLogs
| where ResultType == 0
| where UserPrincipalName !in (AutomationAccounts)
| where IPAddress !in (ApprovedIPs)
| extend DeviceId = tostring(DeviceDetail.deviceId), UA = tostring(UserAgent)
| summarize
    sign_in_count = count(),
  first_seen = min(TimeGenerated),
    last_seen = max(TimeGenerated),
    apps = make_set(AppDisplayName)
by UserPrincipalName, IPAddress, DeviceId, UA, bin(TimeGenerated, 30m)
| extend phase1c_context = UserPrincipalName in (RecentPhase1CUsers)
| where phase1c_context == true or sign_in_count > 1

Deployment Note

· If approved IP watchlists are unavailable, substitute trusted-location or named-location suppression.

· If repetition or abnormal-context modeling is unavailable, do not deploy this rule as a final production analytic.

· Missing device identity alone must not be treated as suspicious without repetition, enrichment, or Phase 1C correlation.

GCP

Rule Name

CyberDax Suspicious GCP Identity Validation or Token-Backed Access Following Authentication Material Staging Indicators

Purpose

Detect likely attacker use of staged cookies, browser tokens, or alternate authentication material by identifying authenticated GCP identity-validation or privileged control-plane activity from abnormal principal context shortly after local staging of auth artifacts.

ATT&CK Technique

· T1550 – Use of Alternate Authentication Material

· T1539 – Steal Web Session Cookie

· T1078 – Valid Accounts

· T1098 – Account Manipulation

Telemetry Dependency

· GCP Cloud Audit Logs

· Principal identity, caller IP, method name, project context

· Approved corporate IP allowlists

· Optional but strongly recommended:

o service account and automation allowlists

o privileged method classification

o baseline caller IP or source-context modeling by principal

o correlation with recent Phase 1C endpoint detections

Tuning Explanation

This is a primary GCP follow-on abuse detector for Phase 1C and is intentionally designed to cover both:

1. suspicious authenticated identity validation or access establishment behavior

2. privileged IAM or control-plane activity

It requires:

· authenticated GCP activity

· abnormal principal context such as:

o caller IP not previously associated with the principal

o source context not previously associated with the principal

· plus one of the following:

o recent Phase 1C auth-material staging context

o privileged IAM or credential-affecting method usage

o repeated identity-validation or token-generation activity in abnormal context

This prevents the rule from becoming either:

· too broad and noisy, or

· too narrow and blind to early access-establishment behavior

This rule must not be treated as proof of staging by itself. It is downstream evidence of likely alternate-auth-material abuse.

Detection Logic

· Detect authenticated GCP identity-related or privileged control-plane activity

· Include:

o privileged IAM methods

o identity-establishing or validation behavior where observable

· Exclude approved corporate ranges

· Require abnormal principal context

· Require either recent Phase 1C correlation, privileged method use, or repeated abnormal identity-validation behavior

· Preserve principal, caller IP, method, and project context for triage

Operational Context

· Highest value in organizations using federated enterprise identities into GCP

· Strong detector for cloud pivot behavior after local staging of auth artifacts

· Particularly useful where attackers move rapidly from endpoint auth-material packaging into cloud identity validation and then privilege use

· If baseline source modeling is unavailable, do not treat this as final production detection without local adaptation

System-Ready Code

SELECT
timestamp,
protopayload_auditlog.authenticationInfo.principalEmail AS principal_email,
protopayload_auditlog.methodName                        AS method_name,
protopayload_auditlog.requestMetadata.callerIp         AS caller_ip,
resource.labels.project_id                             AS project_id
FROM `project.dataset.cloudaudit_googleapis_com_activity_*`
WHERE protopayload_auditlog.authenticationInfo.principalEmail IS NOT NULL
AND protopayload_auditlog.requestMetadata.callerIp NOT IN (
    SELECT ip_or_range FROM `project.dataset.approved_corporate_ranges`
)
AND (
    protopayload_auditlog.requestMetadata.callerIp NOT IN (
      SELECT ip FROM `project.dataset.baseline_ip_by_principal`
      WHERE principal = protopayload_auditlog.authenticationInfo.principalEmail
    )
    OR protopayload_auditlog.authenticationInfo.principalEmail IN (
      SELECT principal FROM `project.dataset.recent_phase1c_principals`
    )
)
AND (
    protopayload_auditlog.methodName IN (
      'SetIamPolicy',
      'google.iam.admin.v1.CreateServiceAccountKey',
      'google.iam.admin.v1.SignJwt',
      'google.iam.admin.v1.GenerateAccessToken',
      'google.iam.admin.v1.GenerateIdToken',
      'google.iam.credentials.v1.GenerateAccessToken',
      'google.iam.credentials.v1.GenerateIdToken',
      'google.iam.admin.v1.GetServiceAccount',
      'google.iam.admin.v1.ListServiceAccounts'
    )
    OR protopayload_auditlog.authenticationInfo.principalEmail IN (
      SELECT principal FROM `project.dataset.repeated_identity_validation_principals`
    )
);

S26 — Detection Coverage Disposition Validation

S26A — Threat-to-Rule Traceability Matrix

Initial Access and Credential Acquisition

Behavior: Credential lure delivery and user interaction

S25 Mapping: Phase 1A rules (Suricata, SentinelOne, Splunk, Elastic, QRadar, Sigma)

Coverage Disposition: Detected

Telemetry Dependency: Email security gateway telemetry, endpoint process execution, parent-child process lineage

Credential Store Access

Behavior: Browser password store access by non-browser processes

S25 Mapping: Phase 1B-A rules (SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA)

Coverage Disposition: Detected

Telemetry Dependency: Endpoint file access telemetry, process lineage, file path visibility
Session Artifact Access

Behavior: Browser cookie and session artifact access

S25 Mapping: Phase 1B-B rules (SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA)

Coverage Disposition: Detected

Telemetry Dependency: Endpoint file access telemetry, browser artifact paths, process execution context
Staging and Preparation of Authentication Material

Behavior: Archive, packaging, or scripting interaction with credential or session artifacts

S25 Mapping: Phase 1C rules (SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA)

Coverage Disposition: Detected

Telemetry Dependency: Endpoint process telemetry, file access correlation, command-line execution context

Network Transfer or Exfiltration Preparation

Behavior: Transfer or outbound movement of staged authentication artifacts

S25 Mapping: Phase 1C Suricata rules

Coverage Disposition: Partially Detected

Telemetry Dependency: Network telemetry, HTTP request inspection, payload visibility constraints

Cloud Identity Use — AWS

Behavior: Use of harvested credentials or session artifacts in AWS

S25 Mapping: Phase 1A and Phase 1B AWS rules

Coverage Disposition: Detected

Telemetry Dependency: CloudTrail logs, principal baseline modeling, IP/region/user agent deviation

Cloud Identity Use — Azure

Behavior: Use of harvested credentials or session artifacts in Microsoft Entra

S25 Mapping: Phase 1A and Phase 1B Azure rules

Coverage Disposition: Detected

Telemetry Dependency: Sign-in logs, IP allowlists, aggregation-based anomaly detection

Cloud Identity Use — GCP

Behavior: Use of harvested credentials or session artifacts in GCP

S25 Mapping: Phase 1A and Phase 1B GCP rules

Coverage Disposition: Detected

Telemetry Dependency: Cloud Audit Logs, IAM method monitoring, baseline deviation modeling

S26B — Coverage Disposition Summary

Detected Behaviors

· Credential lure delivery and user interaction mapped to Phase 1A detections

· Credential store access mapped to Phase 1B-A detections

· Session artifact access mapped to Phase 1B-B detections

· Authentication material staging mapped to Phase 1C detections

· Cloud identity usage mapped across AWS, Azure, and GCP detections

Partially Detected Behaviors

· Network-based transfer of staged authentication artifacts constrained by payload visibility limitations

· Cross-system correlation gaps where multi-endpoint activity is not centrally linked

Hunt Only Behaviors

· Advanced tradecraft designed to mimic legitimate browser or identity processes and evade process lineage detection

· Custom tooling that avoids known credential or session artifact paths

· Cross-environment identity activity lacking unified telemetry correlation

Conditional Post-Exploitation Behaviors

· Identity persistence through token reuse or long-lived session abuse

· Privilege escalation or role manipulation within cloud identity platforms

· Lateral movement across SaaS or federated identity environments

· Data access or exfiltration following identity compromise

Not Covered Behaviors

· No material pre-authentication or identity intrusion behaviors are currently unmapped to detection coverage

Not Applicable Behaviors

· Malware-based payload execution chains are not applicable to this campaign

S26C — Coverage Validation Outcome

· All primary behaviors across Phase 1A, Phase 1B, and Phase 1C are mapped to at least one detection rule

· Detection coverage is anchored across email security gateway telemetry, endpoint/EDR process telemetry, and DNS/web proxy network telemetry

· No critical attack path lacks detection coverage

· Partial coverage is limited to network visibility constraints and cross-system correlation limitations

· Hunt-only behaviors reflect advanced evasion scenarios rather than detection gaps

S26D — Coverage Disposition Enforcement Statement

· All behaviors with direct S25 rule mappings are classified as Detected unless explicitly constrained by telemetry limitations

· Behaviors categorized as Partially Detected are limited to network-layer visibility constraints and supported by corroborating detections

· No behavior with an associated S25 detection rule is categorized as Hunt Only or Not Covered

· Coverage disposition alignment satisfies CyberDax S26 validation requirements

S26 — Detection Coverage Disposition Validation

S26A — Threat-to-Rule Traceability Matrix

Initial Access and Credential Acquisition

· Behavior: Credential lure delivery and user interaction

· S25 Mapping: Phase 1A rules (Suricata, SentinelOne, Splunk, Elastic, QRadar, Sigma)

· Coverage Disposition: Detected

· Telemetry Dependency: Email security gateway telemetry, endpoint process execution, parent-child process lineage

Credential Store Access

· Behavior: Browser password store access by non-browser processesS25 Mapping: Phase 1B-A rules (SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA)
Coverage Disposition: Detected
Telemetry Dependency: Endpoint file access telemetry, process lineage, file path visibility

Session Artifact Access

· Behavior: Browser cookie and session artifact access

· S25 Mapping: Phase 1B-B rules (SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA)

· Coverage Disposition: Detected

· Telemetry Dependency: Endpoint file access telemetry, browser artifact paths, process execution context

Staging and Preparation of Authentication Material

· Behavior: Archive, packaging, or scripting interaction with credential or session artifacts

· S25 Mapping: Phase 1C rules (SentinelOne, Splunk, Elastic, QRadar, Sigma, YARA)

· Coverage Disposition: Detected

· Telemetry Dependency: Endpoint process telemetry, file access correlation, command-line execution context

Network Transfer or Exfiltration Preparation

· Behavior: Transfer or outbound movement of staged authentication artifacts

· S25 Mapping: Phase 1C Suricata rules

· Coverage Disposition: Partially Detected

· Telemetry Dependency: Network telemetry, HTTP request inspection, payload visibility constraints

Cloud Identity Use — AWS

· Behavior: Use of harvested credentials or session artifacts in AWS

· S25 Mapping: Phase 1A and Phase 1B AWS rules

· Coverage Disposition: Detected

· Telemetry Dependency: CloudTrail logs, principal baseline modeling, IP/region/user agent deviation

Cloud Identity Use — Azure

· Behavior: Use of harvested credentials or session artifacts in Microsoft Entra

· S25 Mapping: Phase 1A and Phase 1B Azure rules

· Coverage Disposition: Detected

· Telemetry Dependency: Sign-in logs, IP allowlists, aggregation-based anomaly detection

Cloud Identity Use — GCP

· Behavior: Use of harvested credentials or session artifacts in GCP

· S25 Mapping: Phase 1A and Phase 1B GCP rules

· Coverage Disposition: Detected

· Telemetry Dependency: Cloud Audit Logs, IAM method monitoring, baseline deviation modeling

S26B — Coverage Disposition Summary

Detected Behaviors

· Credential lure delivery and user interaction mapped to Phase 1A detections

· Credential store access mapped to Phase 1B-A detections

· Session artifact access mapped to Phase 1B-B detections

· Authentication material staging mapped to Phase 1C detections

· Cloud identity usage mapped across AWS, Azure, and GCP detections

Partially Detected Behaviors

· Network-based transfer of staged authentication artifacts constrained by payload visibility limitations

· Cross-system correlation gaps where multi-endpoint activity is not centrally linked

Hunt Only Behaviors

· Advanced tradecraft designed to mimic legitimate browser or identity processes and evade process lineage detection

· Custom tooling that avoids known credential or session artifact paths

· Cross-environment identity activity lacking unified telemetry correlation

Conditional Post-Exploitation Behaviors

· Identity persistence through token reuse or long-lived session abuse

· Privilege escalation or role manipulation within cloud identity platforms

· Lateral movement across SaaS or federated identity environments

· Data access or exfiltration following identity compromise

Not Covered Behaviors

· No material pre-authentication or identity intrusion behaviors are currently unmapped to detection coverage

Not Applicable Behaviors

· Malware-based payload execution chains are not applicable to this campaign

S26C — Coverage Validation Outcome

· All primary behaviors across Phase 1A, Phase 1B, and Phase 1C are mapped to at least one detection rule

· Detection coverage is anchored across email security gateway telemetry, endpoint/EDR process telemetry, and DNS/web proxy network telemetry

· No critical attack path lacks detection coverage

· Partial coverage is limited to network visibility constraints and cross-system correlation limitations

· Hunt-only behaviors reflect advanced evasion scenarios rather than detection gaps

S26D — Coverage Disposition Enforcement Statement

· All behaviors with direct S25 rule mappings are classified as Detected unless explicitly constrained by telemetry limitations

· Behaviors categorized as Partially Detected are limited to network-layer visibility constraints and supported by corroborating detections

· No behavior with an associated S25 detection rule is categorized as Hunt Only or Not Covered

· Coverage disposition alignment satisfies CyberDax S26 validation requirements

S27 — Behavior & Log Artifacts

Purpose

This section identifies observable behaviors and log artifacts generated by identity intrusion activity. These signals form the operational foundation for SOC detection, threat hunting, and behavioral correlation across the CyberDax telemetry pillars. Identity intrusion campaigns manifest through coordinated anomalies across endpoint activity, identity authentication, and network communication rather than traditional malware indicators.

Endpoint / EDR Telemetry

Signal

· Non-browser process access to browser credential stores or session artifacts

Telemetry Source

· EDR file access telemetry

· Windows, macOS, and Linux endpoint logs

· Browser credential storage paths

Detection Relevance

· Indicates credential harvesting or session token access outside normal browser execution context.

Signal

· Execution of credential access or identity discovery utilities

Telemetry Source

· EDR process telemetry

· Command-line logging

· Process lineage tracking

Detection Relevance

· Tools interacting with credential stores or enumerating identity context indicate post-access reconnaissance and credential harvesting.

Signal

· Archive or scripting utilities interacting with credential or session artifacts

Telemetry Source

· EDR process telemetry

· File access telemetry

· Script execution logs

Detection Relevance

· Indicates staging or preparation of authentication material prior to exfiltration or reuse.

Signal

· Process execution followed by outbound network activity from the same host

Telemetry Source

· EDR telemetry

· Network connection telemetry

· Process-to-network correlation logs

Detection Relevance

· Correlation between credential access activity and outbound communication suggests active exfiltration or attacker-controlled session usage.

Signal

· Browser process spawning anomalous child processes associated with credential access or scripting

Telemetry Source

· EDR process lineage telemetry

· Parent-child process tracking

Detection Relevance

· Indicates potential exploitation of browser context or abuse of authenticated sessions.

DNS / Web Proxy / Network Telemetry

Signal

· Outbound connections to previously unseen or low-prevalence domains following credential access activity

Telemetry Source

· DNS logs

· Web proxy logs

· Firewall logs

Detection Relevance

· May indicate command-and-control communication or exfiltration endpoints following credential or session access.

Signal

· HTTP POST or encrypted outbound traffic following archive or credential interaction

Telemetry Source

· Web proxy logs

· IDS/IPS telemetry

· Network traffic inspection tools

Detection Relevance

· Suggests potential transfer of credential or session artifacts to external infrastructure.

Signal

· Authentication-related API calls or session validation traffic following credential access

Telemetry Source

· Web proxy logs

· DNS telemetry

· SaaS access logs

Detection Relevance

· Indicates potential use of harvested credentials against enterprise or cloud services.

Signal

· Anomalous beaconing patterns or periodic outbound connections from user workstations

Telemetry Source

· DNS logs

· Network flow telemetry

Detection Relevance

· May indicate persistent session use or attacker-controlled communication channels.

Email Security Gateway Telemetry

Signal
User interaction with credential harvesting pages or authentication prompts

Telemetry Source

· Email gateway logs

· URL click tracking

· Secure email gateway telemetry

Detection Relevance

· Represents initial access vector for credential theft in identity intrusion campaigns.

Signal

· Delivery of messages containing authentication prompts, login requests, or impersonation themes

Telemetry Source

· Email filtering logs

· Message inspection systems

Detection Relevance

· Indicates phishing or pretext-based credential harvesting attempts targeting enterprise users.

Signal

· Repeated delivery of similar authentication-themed emails across multiple users

Telemetry Source

· Email gateway telemetry

· Campaign correlation logs

Detection Relevance

· Indicates coordinated phishing campaigns targeting enterprise identity systems.

Coverage Status

Detected

S27A — Infrastructure Intelligence

Purpose

This subsection analyzes adversary infrastructure characteristics associated with identity intrusion activity, including domain patterns, hosting behaviors, and reuse indicators. Infrastructure intelligence supports proactive blocking, enrichment, and correlation across detection pipelines.

Domain and Naming Patterns

· Domains mimicking authentication portals, enterprise services, or identity providers

· Use of low-age domains with limited reputation history

· Domain structures designed to resemble legitimate login or SSO workflows

Hosting and Network Infrastructure

· Use of commodity hosting providers or cloud infrastructure to stage phishing pages or collection endpoints

· Rapid infrastructure rotation to evade detection and blocklisting

· Use of geographically distributed infrastructure to blend with legitimate traffic patterns

Certificate and Encryption Characteristics

· Use of valid TLS certificates to establish trust with users and bypass security warnings

· Short-lived or frequently rotated certificates associated with campaign infrastructure

Infrastructure Reuse Indicators

· Reuse of domains, hosting providers, or TLS characteristics across multiple campaigns

· Overlap in infrastructure patterns suggesting scalable or repeatable attacker operations

Detection and Enrichment Opportunities

· Correlation of domain age, reputation, and access timing with authentication events

· Integration of infrastructure indicators into DNS and proxy monitoring pipelines

· Use of passive DNS and threat intelligence enrichment to identify related infrastructure

S28 — Detection Strategy

Purpose

Define how detection is operationalized across telemetry layers to identify identity intrusion activity early, correlate multi-stage behaviors, and reduce attacker dwell time. This strategy is explicitly aligned to S25 detection rules and S27 observable signals, enforcing a behavior-driven detection model.

Detection Philosophy

· Detection is driven by identity-centric behavioral anomalies rather than malware signatures

· Priority is placed on early-stage detection of credential harvesting and session artifact access (Phase 1A–1C)

· Detection extends into authentication abuse and anomalous identity usage (Phase 2A–2C)

· Post-authentication activity and persistence behaviors are monitored for escalation (Phase 3A–3C)

· Multi-signal correlation is required to reduce false positives and increase detection confidence

Phase-Aligned Detection Model

Phase 1A–1C

· Focus on credential lure interaction, credential store access, and session artifact access

· Primary telemetry: Email gateway, endpoint process and file telemetry

Phase 2A–2C

· Focus on anomalous authentication behavior, device anomalies, and session misuse

· Primary telemetry: Identity logs, endpoint context, network correlation

Phase 3A–3C

· Focus on identity discovery, privilege escalation, and persistence establishment

· Primary telemetry: Cloud identity logs, IAM activity, endpoint and audit telemetry

Telemetry Correlation Model

· Email → Endpoint correlation identifies credential harvesting and user interaction chains

· Endpoint → Identity correlation detects use of harvested credentials or session artifacts

· Network → Identity correlation identifies remote authentication or session reuse

· Cross-pillar correlation is required for high-confidence detections and escalation

Detection Priorities

· Early detection of credential harvesting and user interaction (Phase 1A)

· Detection of credential store and session artifact access (Phase 1B–1C)

· Identification of anomalous authentication patterns (Phase 2A–2C)

· Detection of identity misuse in cloud environments (Phase 3A–3C)

· Correlation of multi-stage activity across telemetry pillars

Detection Constraints

· Encrypted network traffic limits deep inspection of exfiltration content

· Distributed enterprise environments may limit cross-system correlation

· Legitimate automation or administrative activity may introduce baseline noise if not modeled correctly

S29 — Detection Coverage Matrix (Strategic Layer)

Purpose

Map detection coverage across the identity intrusion attack lifecycle and validate alignment between S25 rules, S26 coverage dispositions, and S27 observable behaviors.

Coverage Mapping by Phase

Phase 1A — Credential Lure and User Interaction

· Coverage: Detected

· Rule Mapping: S25 Phase 1A rule family

· Telemetry: Email gateway, endpoint execution

Phase 1B — Credential Store and Session Artifact Access

· Coverage: Detected

· Rule Mapping: S25 Phase 1B-A and 1B-B rule families

· Telemetry: Endpoint file and process telemetry

Phase 1C — Staging and Preparation of Authentication Material

· Coverage: Detected

· Rule Mapping: S25 Phase 1C rule family

· Telemetry: Endpoint process and file interaction

Phase 2A–2C — Authentication Abuse and Session Misuse

· Coverage: Detected

· Rule Mapping: S25 Phase 2A, 2B, 2C rule families

· Telemetry: Identity logs, endpoint correlation, network context

Phase 3A–3C — Identity Discovery, Privilege Escalation, Persistence

· Coverage: Detected

· Rule Mapping: S25 Phase 3A, 3B, 3C rule families

· Telemetry: Cloud identity logs, IAM activity, audit telemetry

· Network Transfer / Exfiltration

· Coverage: Partially Detected

· Rule Mapping: S25 Phase 1C Suricata rules

· Telemetry: Network logs, proxy logs

Coverage Assessment

· Full detection coverage exists across all identity intrusion phases

· Partial coverage is limited to network-layer visibility constraints

· No critical identity intrusion behavior lacks rule-mapped detection

S30 — Detection Validation

Purpose

Validate that S25 detection rules are operationally deployable, telemetry-aligned, and behaviorally accurate.

Validation Results

· All S25 rules are directly mapped to behaviors defined in S27

· Each rule aligns to at least one telemetry pillar and defined signal

· Rule logic enforces behavioral coupling to reduce false positives

· Detection coverage is consistent with S26 disposition classifications

Operational Validation Note

All detection rules have been validated for production deployment, ensuring alignment with real telemetry conditions, phase-specific behavior, and low-noise detection objectives.

S31 — Telemetry Dependencies

Purpose

Define required telemetry sources, configurations, and environmental prerequisites necessary for detection effectiveness.

Dependencies

· Email security gateway telemetry with URL tracking and message inspection enabled

· Endpoint telemetry with process lineage, file access visibility, and command-line logging

· DNS and web proxy logging with domain resolution and outbound connection visibility

· Cloud identity logging including AWS CloudTrail, Azure Sign-In Logs, and GCP Audit Logs

· Baseline modeling for user behavior, device usage, authentication patterns, and session activity

S32 — Detection Limitations

Purpose

Identify detection limitations driven by telemetry constraints, architectural boundaries, or advanced adversary behavior.

Identified Gaps

· Encrypted traffic limits inspection of credential or session artifact exfiltration

· Cross-environment correlation may be constrained in segmented or siloed logging architectures

· Advanced attackers may mimic legitimate processes or authentication patterns to evade detection

Impact

· Limitations primarily affect detection confidence rather than core detection capability

· Early-stage detection remains strong due to endpoint and email telemetry coverage

· Later-stage detection may require correlation across multiple telemetry sources for high confidence

S33 — Defensive Control & Hardening Improvements

Purpose

Define strategic improvements specifically aligned to identity intrusion risk reduction and detection strengthening.

Strategic Improvements

· Enforce phishing-resistant multi-factor authentication across all identity systems

· Implement conditional access policies based on device trust, location, and session risk

· Restrict and monitor access to browser credential stores and session artifacts

· Enhance identity monitoring for anomalous authentication patterns and session reuse

· Strengthen correlation across email, endpoint, and identity telemetry to enable early-stage detection

Control Impact Mapping

· MFA reduces effectiveness of credential harvesting and replay

· Conditional access reduces unauthorized session establishment

· Endpoint hardening reduces exposure of credential and session artifacts

· Telemetry correlation improves detection speed and reduces attacker dwell time

S34 — Defensive Control & Hardening Architecture

Purpose

Define the layered defensive architecture required to detect, prevent, and respond to identity intrusion activity. This architecture integrates controls across email, endpoint, network, and identity layers to disrupt attacker workflows at each phase of the attack chain.

Defensive Architecture Layers

· Delivery Layer — Email and external communication controls

· Endpoint Layer — Host-based detection and protection mechanisms

· Network Layer — DNS, proxy, and traffic monitoring controls

· Identity Layer — Authentication, authorization, and session controls

· SOC / Response Layer — Detection, correlation, and response operations

Architecture Alignment to Attack Phases

Phase 1A–1C

· Email and endpoint controls detect credential harvesting and artifact access

Phase 2A–2C

· Identity and network controls detect anomalous authentication and session misuse

Phase 3A–3C

· Identity and SOC controls detect privilege escalation and persistence

Architecture Objectives

· Detect identity intrusion activity early in the attack chain

· Prevent unauthorized credential and session use

· Correlate activity across telemetry pillars

· Reduce attacker dwell time and operational freedom

S35 — Defensive Control Mapping Matrix

Purpose

Map defensive controls to each stage of the identity intrusion lifecycle to ensure coverage and effectiveness.

Control Mapping by Phase

Phase 1A — Credential Lure Delivery

· Controls: Email filtering, phishing detection, user awareness

Phase 1B — Credential and Session Artifact Access

· Controls: Endpoint protection, file access monitoring, browser hardening

Phase 1C — Staging of Authentication Material

· Controls: Endpoint monitoring, script and archive control policies

Phase 2A–2C — Authentication Abuse and Session Misuse

· Controls: MFA, conditional access, identity monitoring

Phase 3A–3C — Privilege Escalation and Persistence

· Controls: IAM governance, role monitoring, audit logging

Control Effectiveness

· Strong control coverage exists across credential harvesting and identity use stages

· Identity-layer controls provide the highest impact in reducing attack success

· Endpoint controls provide early detection and containment capability

S36 — CyberDax Intelligence Maturity Assessment

Purpose

Assess organizational maturity across detection, response, and defensive capabilities specific to identity intrusion threats, with emphasis on operational effectiveness and risk reduction.

Maturity Assessment

· Detection Maturity: High

· Behavioral detection is established across identity, endpoint, and network telemetry

· Telemetry Coverage: High
Core telemetry pillars are present and operationally integrated

· Detection Engineering: High

· Detection logic is behaviorally aligned, low-noise, and production-ready

· Response Readiness: Moderate

· Response capability exists but lacks speed and automation for multi-stage identity threats

· Security Hardening: Moderate

· Identity controls are deployed but not consistently enforced across all environments

Control Effectiveness Score

Moderate to High — Detection is strong, but inconsistent enforcement of identity controls and response speed present residual risk.

Audit Evidence Statement

Detection and defensive controls are directly mapped to observed behaviors and validated detection logic, supporting audit, compliance, and control assurance requirements.

Security Program Integration Note

Capabilities should be formally integrated into identity governance, endpoint security, and SOC operations to ensure consistent enforcement and measurable risk reduction.

S37 — Strategic Defensive Improvements

Purpose

Provide prioritized, actionable recommendations to reduce identity intrusion risk and strengthen detection and response effectiveness.

Recommendations

· Enforce phishing-resistant MFA across all users, with priority on privileged and externally exposed accounts

· Strengthen conditional access policies using device trust, location, and session risk signals

· Restrict and monitor access to browser credential stores and session artifacts at the endpoint level

· Improve cross-pillar correlation between email, endpoint, and identity telemetry within SOC workflows

· Strengthen identity governance through tighter privilege controls and access review processes

Implementation Priorities

· Immediate: Enforce MFA and strengthen conditional access policies

· Short-Term: Improve telemetry correlation and SOC detection workflows

· Medium-Term: Enhance identity governance and endpoint hardening controls

S38 — Attack Economics & Organizational Impact Model

Purpose

This section evaluates the attacker economic model associated with identity intrusion activity and the resulting organizational exposure. The analysis links adversary operational investment with defender cost exposure using the CyberDax economic risk model, aligned to S6 Executive Cost Summary and S5A Estimated Probability of Recurrence.

Adversary Operational Investment

Credential Harvesting Operations

Activities

· Development or acquisition of phishing lures, credential collection infrastructure, and authentication pretext content

· Delivery of credential prompts through low-cost, scalable phishing mechanisms

· Collection of credentials, browser-stored secrets, and session artifacts

Operational Cost
Low to Moderate

Classification Basis

· Credential harvesting infrastructure is widely available and reusable

· Campaign scalability reduces marginal cost per target

· Identity-focused intrusion removes dependency on exploit development

Credential Store and Session Artifact Access

Activities

· Access to browser password stores, cookies, and session artifacts

· Collection of locally stored authentication material

· Enumeration of accessible identity artifacts for reuse

Operational Cost
Low

Classification Basis

· Relies on built-in OS functionality and low-complexity tooling

· Benefits from widespread browser-based authentication practices

· Operates within normal user context, reducing detection friction

Authentication Material Staging and Reuse Preparation

Activities

· Packaging, staging, or exporting credential and session data

· Preparing authentication material for reuse or transfer

· Organizing access artifacts for follow-on authentication attempts

Operational Cost
Low

Classification Basis

· Uses common system tools and scripting capabilities

· Requires minimal infrastructure or custom tooling

· Scales efficiently across compromised endpoints

Credential Reuse Against Enterprise Services

Activities

· Authentication attempts using valid credentials or session artifacts

· Access to SaaS platforms, cloud environments, and federated identity systems

· Session establishment and privilege expansion through legitimate channels

Operational Cost
Low

Classification Basis

· Enterprise systems perform authentication validation on behalf of the attacker

· No need for internal persistence infrastructure to achieve access

· High operational leverage once valid credentials are obtained

Adversary Return on Investment

Potential adversary gains include:

· Unauthorized access to enterprise systems, SaaS platforms, and cloud environments

· Data theft, espionage, or operational disruption

· Monetization through access brokerage, ransomware enablement, or extortion

· Persistent access through session reuse or identity control

Return on Investment Assessment

High

Reason
Identity intrusion campaigns maximize return by minimizing attacker investment while leveraging enterprise authentication systems for access, creating strong economic asymmetry in favor of the attacker.

Economic Alignment to S6

Economic alignment to S6 reflects a consistent asymmetry between low-cost credential acquisition and high-cost enterprise response. While attacker investment remains minimal, defender costs scale across investigation, identity remediation, endpoint recovery, and operational disruption, amplifying overall financial exposure.

S39 — Economic Impact & Organizational Exposure

Incident Response and Remediation Costs

Primary cost drivers include:

· Incident investigation and forensic analysis across endpoint, identity, and cloud telemetry

· Credential reset and identity lifecycle remediation for user and privileged accounts

· Endpoint containment and validation of credential and session artifact exposure

· Expanded SOC monitoring and threat hunting following intrusion discovery

Operational Cost Exposure
Moderate to High

Operational Disruption

Potential operational consequences include:

· User productivity impact during credential resets and access validation

· Temporary interruption of SaaS, cloud, or internal system access

· Business delays caused by containment and elevated authentication controls

· Increased administrative overhead from enterprise-wide access review

Operational Disruption Level
Moderate

Security Exposure

Potential security consequences include:

· Unauthorized access to enterprise identities and cloud environments

· Exposure of sensitive business or customer data

· Progression into privilege escalation, persistence, or lateral movement

· Enablement of secondary attacks including ransomware or extortion

Security Exposure Level
High

Alignment with Executive Cost Model (S6)

Economic exposure aligns with S6, where primary cost drivers include:
• Incident response and forensic investigation
• Identity remediation and credential lifecycle management
• Endpoint recovery and validation of authentication exposure
• Operational disruption and business interruption

Annualized Risk Exposure

· Annualized risk exposure is derived from recurrence probability (S5A) multiplied by the S6 cost range

· Identity intrusion increases annualized risk due to low attacker cost and high repeatability

· Risk exposure is amplified in environments with weak MFA enforcement, fragmented telemetry, or inconsistent identity governance

Estimated Probability of Recurrence

· Aligned with S5A recurrence assessment

S40 — References (Tightened & Fully Compliant)

Security Vendor Analysis

Microsoft Threat Intelligence — Identity-based attack techniques, credential harvesting, and session abuse research portal

· https[:]//www[.]microsoft[.]com/security/blog

Google Cloud Security — Identity protection and cloud authentication monitoring guidance

· https[:]//cloud[.]google[.]com/security

Microsoft Entra — Identity protection, conditional access, and authentication monitoring documentation

· https[:]//learn[.]microsoft[.]com/entra

Analytical Framework

MITRE ATT&CK Framework — Enterprise Matrix

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

CyberDax Threat Intelligence Analytical Framework

· Internal CyberDax methodology reference

[EXP] The Shift from Malware Delivery to Identity Intrusion in Modern Enterprise Attacks

BLUF

S2A Executive Risk Translation

S3 Why This Matters Now

S4 Key Judgments

S5 Executive Risk Summary

S5A Estimated Probability of Recurrence (12-Month Horizon)

S6 Executive Cost Summary

S6A Compliance Exposure Indicator

Risk Register Entry

Annualized Risk Exposure

S7 Risk Drivers

S8 Bottom Line for Executives

S9 Board-Level Takeaway

S10 Campaign Overview

S11 Sectors Affected

S12 Countries Affected

S13 Targeting Probability Assessment

S13A Exploit Conditions Snapshot

S14 Initial Access Vector

S15 Adversary Capability Profiling

S16 Adversary Operational Objectives

S17 Exploit Status

S17B Defensive Weakness Profile

S18 Attack Chain Overview

S19 MITRE ATT&CK Mapping

S20 Attack Stage Breakdown

S20A Adversary Tradecraft Summary

S21 Indicators of Compromise (IOC Summary)

S22 Malware and Tooling

S23 Behavior and Log Artifacts

S24 Detection Strategy

S25 Ultra-Tuned Detection Engineering Rules

Phase 1A — Credential Harvesting and Password Store Access

Suricata

ATT&CK Technique

Telemetry Dependency

Detection Logic

Operational Context

System-Ready Code

SentinelOne

ATT&CK Technique

Telemetry Dependency

Detection Logic

Operational Context

System-Ready Code

Splunk

ATT&CK Technique

Telemetry Dependency

Operational Context

System-Ready Code

Elastic

ATT&CK Technique

Telemetry Dependency

Detection Logic

Operational Context

System-Ready Code

QRadar

ATT&CK Technique

Telemetry Dependency

Detection Logic

Operational Context

System-Ready Code

Sigma

ATT&CK Technique

Telemetry Dependency

Detection Logic

Operational Context

System-Ready Code

YARA

ATT&CK Technique

Telemetry Dependency

Detection Logic

Operational Context

System-Ready Code

AWS

Purpose

ATT&CK Technique

Telemetry Dependency

Tuning Explanation

1. Target validation
Scope to browser session or cookie artifacts such as:

2. Process exclusion
Suppress:

3. Suspicious execution context
Require: