← Back to Cybersecurity News Center
Severity
HIGH
CVSS
7.5
Priority
0.755
×
Tip
Pick your view
Analyst for full detail, Executive for the short version.
Analyst
Executive
Executive Summary
Since October 2025, two threat actor groups, CORDIAL SPIDER and SNARKY SPIDER, have conducted data theft and extortion campaigns targeting enterprise SaaS environments by intercepting credentials and hijacking identity sessions without touching endpoints. Both groups exploit SSO trust chains and identity provider flows to move laterally across connected SaaS applications, deliberately avoiding endpoint detection tools. Organizations relying primarily on EDR solutions face a structural detection gap: these attacks leave no host-based evidence, making credential theft and SaaS data exfiltration nearly invisible to traditional security monitoring.
Impact Assessment
CISA KEV Status
Not listed
Threat Severity
HIGH
High severity — prioritize for investigation
Actor Attribution
HIGH
CORDIAL SPIDER, SNARKY SPIDER
TTP Sophistication
HIGH
14 MITRE ATT&CK techniques identified
Detection Difficulty
HIGH
Multiple evasion techniques observed
Target Scope
INFO
Enterprise SSO/IdP platforms (generic), SaaS applications (generic), organizations using CrowdStrike Falcon Shield environments
Are You Exposed?
⚠
Your industry is targeted by CORDIAL SPIDER, SNARKY SPIDER → Heightened risk
⚠
You use products/services from Enterprise SSO/IdP platforms (generic) → Assess exposure
⚠
14 attack techniques identified — review your detection coverage for these TTPs
✓
Your EDR/XDR detects the listed IOCs and TTPs → Reduced risk
✓
You have incident response procedures for this threat type → Prepared
Assessment estimated from severity rating and threat indicators
Business Context
These campaigns target the data stored in SaaS platforms — email, documents, customer records, financial data — and follow theft with extortion demands, creating direct financial exposure and potential regulatory liability. Because the attacks operate entirely within identity and SaaS layers, existing endpoint security investments provide no protective value against this specific threat vector. Organizations that cannot detect or contain SaaS-native credential attacks face extended dwell time, broader data exfiltration, and reputational damage from customer or partner data exposure.
You Are Affected If
You use SSO-federated SaaS applications (Microsoft 365, Google Workspace, Salesforce, or similar) where a single compromised identity grants access to multiple platforms
Your MFA implementation allows device self-enrollment without out-of-band verification or admin approval
Your security monitoring relies primarily on endpoint telemetry (EDR) without dedicated IdP and SaaS audit log coverage
Your organization has a help desk or IT support function that accepts verbal or email-based MFA reset requests without strong identity verification
Privileged SaaS accounts (tenant admins, global admins, data owners) are accessible via SSO without additional step-up authentication controls
Board Talking Points
Two active criminal groups are stealing enterprise data by hijacking login sessions inside cloud applications — our standard endpoint security tools cannot see or stop this type of attack.
Security leadership should assess within 30 days whether our identity and cloud application monitoring can detect unauthorized account access of this kind, and prioritize closing that gap if it exists.
Organizations that do not address this exposure risk undetected data theft followed by extortion demands, with no forensic record of how the breach occurred.
Technical Analysis
CORDIAL SPIDER and SNARKY SPIDER operate as SaaS-native threat actors, active since at least October 2025.
Both groups use adversary-in-the-middle (AiTM) phishing frameworks to intercept session tokens and credentials in transit, bypassing MFA by capturing post-authentication session cookies rather than defeating MFA directly.
Techniques include voice phishing (vishing) for initial access, manipulation of MFA device registration (T1098.005 , T1621 ) to establish persistent authentication, and abuse of SSO trust relationships to pivot across federated SaaS applications (T1078.004 , T1199 ) without generating endpoint telemetry.
Additional observed techniques span internal spearphishing (T1534 ), email collection via cloud APIs (T1114.003 ), cookie theft (T1539 ), application access token abuse (T1550.001 ), and use of hidden window artifacts (T1564.008 ). Relevant CWEs: CWE-287 (Improper Authentication), CWE-306 (Missing Authentication for Critical Function), CWE-384 (Session Fixation). No CVE is assigned; this campaign exploits architectural trust weaknesses, not a discrete software vulnerability. There is no patch; mitigation requires identity hygiene and SaaS-layer detection controls.
Action Checklist IR ENRICHED
Triage Priority:
IMMEDIATE
Escalate to legal counsel and initiate breach notification assessment immediately if investigation confirms that CORDIAL SPIDER or SNARKY SPIDER accessed mailboxes, cloud storage, or SaaS applications containing PII, PHI, or regulated financial data, as bulk data access via hijacked OAuth tokens and email forwarding rules (T1114.003) is a confirmed exfiltration vector for both groups and likely triggers GDPR 72-hour notification, HIPAA Breach Notification Rule, or SEC Material Cybersecurity Incident reporting depending on data classification and organizational profile.
1
Step 1: Containment — Audit all active SSO sessions and MFA-registered devices across your IdP (Entra ID, Okta, Ping) immediately. Revoke suspicious sessions and unrecognized MFA devices, especially those registered from unexpected geolocations or outside change-control windows. Prioritize privileged accounts and SaaS admin roles. Terminate sessions where device fingerprint or IP differs from the authentication origin. (Cite: NIST AC-2 — Account Management / NIST AC-12 — Session Termination / CIS 5.1 — Establish and Maintain an Inventory of Accounts / CIS 6.2 — Establish an Access Revoking Process / D3-CRO — Credential Rotation / D3-LAM — Local Account Monitoring)
IR Detail
Containment
NIST 800-61r3 §3.3 — Containment Strategy
NIST IR-4 (Incident Handling)
NIST AC-17 (Remote Access)
CIS 5.1 (Establish and Maintain an Inventory of Accounts)
CIS 6.2 (Establish an Access Revoking Process)
Compensating Control
In Entra ID: run 'Get-MgUserAuthenticationMethod -UserId <UPN>' via Microsoft Graph PowerShell to enumerate all registered MFA methods per account; export with 'Get-MgAuditLogSignIn' filtered on 'riskState eq atRisk' or 'isRisky eq true'. In Okta: use the Okta System Log API endpoint '/api/v1/logs?filter=eventType+eq+"user.mfa.factor.activate"' scoped to the incident window, then cross-reference against your change-control calendar manually. Session revocation in Entra: 'Revoke-MgUserSignInSession -UserId <UPN>'; in Okta: POST to '/api/v1/users/{userId}/sessions?oauthTokens=true' with DELETE method. A 2-person team should divide: one works privileged/admin accounts, the other SaaS-connected service accounts.
Preserve Evidence
Preserve BEFORE revoking sessions: full Entra ID sign-in log export for the last 90 days (Microsoft Graph 'auditLogs/signIns', retention limit is 30 days for non-P2 tenants — export immediately to Azure Storage or CSV); Okta System Log export covering all 'user.authentication.sso', 'user.mfa.factor.activate', and 'policy.evaluate_sign_on' events; screenshot or API export of all currently active sessions including device ID, IP, user-agent string, and geolocation for every privileged account. Capture MFA device registration timestamps — CORDIAL SPIDER and SNARKY SPIDER register adversary-controlled MFA devices during the AiTM session hijack window, so registration events timestamped during the identified phishing campaign period (October 2025 onward) are primary forensic anchors.
2
Step 2: Detection — Query IdP logs for anomalous MFA device registrations, impossible-travel authentication events, and SSO token reuse from new device fingerprints. Review SaaS audit logs (Microsoft 365, Google Workspace, Salesforce) for unexpected OAuth app authorizations, email forwarding rule creation (T1114.003), and bulk data access. Correlate against IdP sign-in logs; endpoint telemetry will not surface these identity-layer events. Enable and verify audit log collection is active across all IdP and SaaS platforms before querying. (Cite: NIST AU-2 — Event Logging / NIST AU-6 — Audit Record Review, Analysis, And Reporting / NIST AU-12 — Audit Record Generation / CIS 8.2 — Collect Audit Logs / D3-LAM — Local Account Monitoring / D3-MFA — Multi-factor Authentication)
IR Detail
Detection & Analysis
NIST 800-61r3 §3.2 — Detection and Analysis
NIST SI-4 (System Monitoring)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST AU-2 (Event Logging)
CIS 8.2 (Collect Audit Logs)
Compensating Control
Microsoft 365 — use the Unified Audit Log via 'Search-UnifiedAuditLog -RecordType ExchangeAdmin -Operations "New-InboxRule","Set-InboxRule"' to surface T1114.003 email forwarding rules; also query '-RecordType AzureActiveDirectory -Operations "Add service principal credentials","Consent to application"' for OAuth grants. Google Workspace — pull Admin SDK Reports API for 'login' and 'token' event types filtering on 'is_suspicious:true'. For impossible-travel detection without SIEM: export Entra sign-in logs to CSV and use a PowerShell script calculating time-delta and geolocation-distance between consecutive authentications per UPN — flag any delta under 2 hours with distance over 500 miles. Apply the public Sigma rule 'azure_ad_mfa_device_registration_from_new_country.yml' (available in SigmaHQ repository) against exported logs using 'sigma convert' with a grep/jq backend. MITRE ATT&CK T1114.003 (Email Forwarding Rule), T1550.001 (Application Access Token), T1606.002 (SAML Token forgery) should frame hunting queries.
Preserve Evidence
Capture before analysis is complete: raw Entra ID sign-in JSON exports (preserve 'deviceDetail.deviceId', 'deviceDetail.browser', 'location.countryOrRegion', 'conditionalAccessStatus', 'mfaDetail.authMethod' fields — these fingerprint AiTM proxy sessions where the intercepted token is replayed from a new device ID); Microsoft 365 Unified Audit Log entries for 'MailboxLogin', 'New-InboxRule', and 'ModifyFolderPermissions' operations correlated to accounts flagged in Step 1; Salesforce event log files ('/services/data/vXX.0/sobjects/EventLogFile') for 'Login', 'URI', and 'API' event types showing bulk object access or report exports; OAuth application grant records from Entra 'servicePrincipalSignIns' and Google Workspace token audit log showing app name, scope, and grant timestamp.
3
Step 3: Eradication — Remove all unauthorized MFA devices and OAuth application grants identified during triage. Enforce conditional access policies requiring compliant, managed devices for SaaS authentication. Disable legacy authentication protocols that bypass MFA. Restrict SSO federation trust scope to limit lateral movement across connected SaaS applications. Apply least-privilege access enforcement to OAuth scopes and SaaS roles. (Cite: NIST AC-3 — Access Enforcement / NIST AC-6 — Least Privilege / NIST AC-20 — Use Of External Systems / CIS 6.3 — Require MFA for Externally-Exposed Applications / CIS 6.5 — Require MFA for Administrative Access / D3-CH — Credential Hardening / D3-UAP — User Account Permissions / D3-MFA — Multi-factor Authentication)
IR Detail
Eradication
NIST 800-61r3 §3.4 — Eradication
NIST IR-4 (Incident Handling)
NIST SI-2 (Flaw Remediation)
NIST AC-17 (Remote Access)
CIS 6.3 (Require MFA for Externally-Exposed Applications)
CIS 4.4 (Implement and Manage a Firewall on Servers)
Compensating Control
MFA device removal in Entra: 'Remove-MgUserAuthenticationMethod -UserId <UPN> -AuthenticationMethodId <MethodId>' for each unauthorized FIDO2 key, authenticator app registration, or phone number added outside the change window. OAuth grant revocation: 'Remove-MgServicePrincipalAppRoleAssignment' and 'Revoke-MgOauth2PermissionGrant' for all non-approved app grants identified in Step 2. Legacy auth blocking without Entra P1: create an Entra Conditional Access policy (available in free tier for blocking legacy auth) targeting 'Exchange ActiveSync Clients' and 'Other Clients' with block grant control. SSO federation scope restriction: in Entra, audit app registrations via 'Get-MgServicePrincipal -All | Where-Object {$_.ReplyUrls -ne $null}' and remove redirect URIs for unrecognized external tenants. Document every removed artifact with timestamp for chain-of-custody.
Preserve Evidence
Before executing eradication, preserve: a full export of the OAuth application grant table from Entra ('Get-MgOauth2PermissionGrant -All' to CSV) and Okta application assignments API response — these establish the post-compromise application trust state that CORDIAL SPIDER and SNARKY SPIDER leverage for cross-SaaS lateral movement; Entra Conditional Access policy evaluation logs (sign-in log field 'appliedConditionalAccessPolicies') showing which policies were in place and which were bypassed during the attack window; Okta System Log entries for 'application.lifecycle.update' and 'user.session.access_admin_app' events showing SaaS application access chains used for lateral movement.
4
Step 4: Recovery — Re-validate all privileged account MFA enrollments through out-of-band confirmation. Monitor IdP and SaaS audit logs continuously for 30 days post-remediation for re-registration attempts or new OAuth grants. Confirm no email forwarding rules or inbox delegation remain from the compromise window. Ensure audit log retention covers the full post-incident monitoring window per your retention policy. (Cite: NIST AC-2 — Account Management / NIST AU-6 — Audit Record Review, Analysis, And Reporting / NIST AU-11 — Audit Record Retention / NIST AU-4 — Audit Storage Capacity / CIS 5.1 — Establish and Maintain an Inventory of Accounts / CIS 6.5 — Require MFA for Administrative Access / D3-CRO — Credential Rotation)
IR Detail
Recovery
NIST 800-61r3 §3.5 — Recovery
NIST IR-4 (Incident Handling)
NIST AU-6 (Audit Record Review, Analysis, and Reporting)
NIST SI-7 (Software, Firmware, and Information Integrity)
CIS 6.5 (Require MFA for Administrative Access)
CIS 6.1 (Establish an Access Granting Process)
Compensating Control
Out-of-band MFA re-enrollment: generate a Temporary Access Pass (TAP) in Entra ID for each privileged account ('New-MgUserAuthenticationTemporaryAccessPass') and walk each account owner through re-enrollment on a confirmed managed device via in-person or video-verified session — do not use email for this communication as inbox access may still be compromised. For 30-day continuous monitoring without SIEM: configure Entra ID diagnostic settings to stream sign-in and audit logs to an Azure Storage Account (free tier sufficient for log storage); run a daily scheduled PowerShell task querying 'Get-MgAuditLogSignIn' for 'user.mfa.factor.activate' and 'appId' values not in your approved OAuth app allowlist, outputting alerts to a shared mailbox. For email rule verification: 'Get-InboxRule -Mailbox <UPN> | Select-Object Name,ForwardTo,RedirectTo,DeleteMessage,Enabled' across all affected mailboxes; repeat weekly for 30 days.
Preserve Evidence
Capture as recovery baseline: a clean-state export of all MFA registrations post-re-enrollment ('Get-MgUserAuthenticationMethod -UserId <UPN>' for all privileged accounts) to serve as the verified baseline for future comparison; Microsoft 365 'Get-InboxRule' output for all affected accounts confirming zero forwarding rules, to be retained as the remediation-complete artifact; Entra audit log entry for each TAP issuance and subsequent MFA re-registration event, establishing the verified re-enrollment chain of custody required under NIST IR-5 (Incident Monitoring).
5
Step 5: Post-Incident — This campaign exposes a structural detection gap in endpoint-centric architectures. Conduct a SaaS and identity attack surface review. Implement SaaS Security Posture Management (SSPM) or equivalent IdP/SaaS-layer detection to gain visibility into MFA registration changes, OAuth grant activity, and IdP sign-in anomalies. If visibility gaps exist, prioritize architectural control investment over configuration-only remediation. Map SSO federation dependencies using operational dependency mapping to understand lateral movement blast radius. (Cite: NIST AC-4 — Information Flow Enforcement / NIST AU-13 — Monitoring For Information Disclosure / CIS 5.4 — Restrict Administrator Privileges to Dedicated Administrator Accounts / CIS 7.1 — Establish and Maintain a Vulnerability Management Process / D3-ODM — Operational Dependency Mapping / D3-MFA — Multi-factor Authentication / D3-CH — Credential Hardening)
IR Detail
Post-Incident
NIST 800-61r3 §4 — Post-Incident Activity
NIST IR-4 (Incident Handling)
NIST IR-8 (Incident Response Plan)
NIST SI-4 (System Monitoring)
NIST RA-3 (Risk Assessment)
CIS 7.1 (Establish and Maintain a Vulnerability Management Process)
CIS 8.2 (Collect Audit Logs)
Compensating Control
For teams who cannot procure a commercial SSPM tool: implement free detection coverage using (1) Microsoft Sentinel free ingestion tier for Entra ID and Microsoft 365 logs with the community Sigma-to-KQL ruleset from the 'Azure-Sentinel' GitHub repository, specifically rules targeting 'AiTM phishing' and 'OAuth consent grant' patterns; (2) Okta's free System Log with a lightweight Python polling script using the Okta SDK to alert on 'user.mfa.factor.activate' outside business hours or from new countries; (3) a quarterly manual SaaS application grant audit using 'Get-MgOauth2PermissionGrant' cross-referenced against an approved-app allowlist maintained in a shared spreadsheet. Lessons-learned session should specifically address the CORDIAL SPIDER and SNARKY SPIDER TTPs of AiTM credential interception and SSO trust chain abuse — document detection gaps that allowed initial access to persist undetected and assign control owners for each gap.
Preserve Evidence
Post-incident documentation artifacts required: a timeline reconstruction of the full attack chain from initial AiTM phishing lure through SSO session hijack, MFA device registration, OAuth grant, and SaaS lateral movement — sourced from IdP log exports preserved in Steps 1-4; a control gap analysis document mapping where CORDIAL SPIDER and SNARKY SPIDER TTPs (T1114.003, T1550.001, T1606.002) were not covered by existing detection controls; Entra ID and Okta log retention confirmation showing whether pre-incident logs were available for the October 2025 campaign start date — log retention gaps are a finding requiring remediation under NIST AU-11 (Audit Record Retention).
Recovery Guidance
Re-validate the integrity of SSO federation trusts and OAuth application grant tables weekly for the first 30 days post-remediation, as both CORDIAL SPIDER and SNARKY SPIDER have demonstrated persistence through re-registration of adversary-controlled MFA devices and re-authorization of malicious OAuth apps following initial remediation. Confirm that Entra ID or Okta diagnostic log streaming is fully operational and that retention covers at least 90 days before closing the incident, since the October 2025 campaign start date indicates these actors operate with long dwell times that exceed default 30-day IdP log retention windows. Verify that all SaaS application admin consoles (Microsoft 365, Google Workspace, Salesforce) have been audited for backdoor admin account creation or delegated access grants independent of the primary IdP, as SaaS-native admin access can survive IdP-level remediation.
Key Forensic Artifacts
Entra ID Sign-In Logs (Graph API 'auditLogs/signIns'): preserve the 'deviceDetail.deviceId', 'deviceDetail.browser', 'tokenIssuerType', and 'mfaDetail.authMethod' fields — AiTM proxy sessions used by CORDIAL SPIDER and SNARKY SPIDER produce sign-in records where a valid MFA claim is present but the device ID is unrecognized and the IP is a residential proxy or VPN exit node, creating a detectable fingerprint against the legitimate user's historical device baseline.
Okta System Log (API '/api/v1/logs'): events of type 'user.mfa.factor.activate', 'user.session.start', and 'policy.evaluate_sign_on' timestamped from October 2025 onward — specifically, MFA factor activations where the enrolling IP differs from the user's established authentication geography, indicating adversary-controlled device registration during a hijacked session.
Microsoft 365 Unified Audit Log — 'New-InboxRule' and 'Set-InboxRule' operations: CORDIAL SPIDER and SNARKY SPIDER create inbox forwarding rules (MITRE T1114.003) as a persistence and exfiltration mechanism post-SSO compromise; preserve the full rule definition including ForwardTo, RedirectTo, and MarkAsRead parameters, which reveal the external collection address and confirm whether the actor intended silent exfiltration.
OAuth Application Grant Records (Entra 'Get-MgOauth2PermissionGrant' and 'Get-MgServicePrincipalAppRoleAssignment'): snapshot the full grant table including appId, consentType, scope, and principalId at time of discovery — both groups authorize malicious or over-privileged OAuth apps during the compromised session to maintain SaaS access independently of the IdP session, and the grant table is the primary artifact establishing cross-SaaS lateral movement scope.
SaaS Audit Logs — Salesforce Event Log Files and Google Workspace Token Audit Log: Salesforce '/services/data/vXX.0/sobjects/EventLogFile' entries for 'Report', 'ReportExport', and 'API' event types reveal bulk data access consistent with the exfiltration phase of SNARKY SPIDER and CORDIAL SPIDER campaigns; Google Workspace token audit events with 'token_revoke' actions absent despite active forwarding rules indicate the OAuth grant persisted through the compromise window and must be correlated with Drive access logs for exfiltration scope assessment.
Detection Guidance
Detection for CORDIAL SPIDER and SNARKY SPIDER requires IdP and SaaS-layer telemetry.
Endpoint logs will not surface these activities.
All detection depends on audit logging being active and complete — verify this first per NIST AU-2 (Event Logging) and CIS 8.2 (Collect Audit Logs).
Ensure audit records capture the full event context required by NIST AU-3 (Content Of Audit Records): what occurred, when, where, who initiated it, and from what source address.
Key detection signals and their control mappings:
1. MFA device registration anomalies (T1098.005 , T1621 ): Query Entra ID, Okta, or Ping system logs for 'device enrollment' and 'authenticator registered' events outside approved change windows or from unexpected IP ranges. Supported by NIST AU-6 (Audit Record Review, Analysis, And Reporting) — review IdP audit records for indications of compromise. D3-LAM (Local Account Monitoring) applies: analyze account-level changes including MFA device additions for unauthorized activity.
2. Session cookie hijacking indicators (T1550.001 , T1557 ): SSO token use from a device fingerprint or IP differing from the authentication session origin indicates post-authentication session theft. Detection requires per-session device binding data in IdP sign-in logs. Map rules to NIST AU-6 and AU-14 (Session Audit) — AU-14 supports the capability to review user session activity. D3-CH (Credential Hardening) countermeasure: enforce token binding or device-bound session controls to reduce cookie reuse.
3. Unauthorized OAuth application grants (T1199 , T1078.004 ): Alert on OAuth applications granted to user accounts, especially with mail read, files read, or admin scopes. Review via Microsoft Graph audit logs or equivalent SaaS admin consoles. Supported by NIST AC-20 (Use Of External Systems) — control and monitor external system access grants. NIST AU-6 provides the review and analysis requirement. D3-UAP (User Account Permissions) countermeasure: restrict and audit OAuth permission grants.
4. Email forwarding rule creation (T1114.003 ): Query Exchange Online unified audit log or Google Workspace admin audit for inbox rules created via EWS, Graph API, or admin console that forward or redirect mail externally. NIST AU-2 requires these event types to be identified and logged. NIST AU-6 requires periodic review. D3-SFA (System File Analysis) is partially applicable — monitor configuration state of mailbox rules as a persistent attacker mechanism.
5. Impossible-travel and concurrent session anomalies (T1078 ): Flag authentication events where the same account authenticates from geographically implausible locations within the same session window. NIST AC-10 (Concurrent Session Control) supports limiting and monitoring concurrent sessions per account. NIST AU-6 supports the review and alerting requirement.
6. Vishing precursors (T1566.004 , T1621 ): Monitor help desk ticketing systems for MFA reset requests or device re-enrollment requests for privileged accounts, particularly those not initiated through self-service channels. These are behavioral precursors to MFA hijacking. No direct KB control covers help desk abuse specifically; flag for analyst review under NIST AU-6 as an anomalous event pattern requiring investigation.
Note on KB coverage gaps: NIST IA-family controls (e.g., IA-5 for authenticator management, IA-11 for re-authentication) are directly relevant to MFA device registration and session token controls but are not present in the KB reference data provided. Practitioners should consult NIST SP 800-53 Rev. 5 IA-family controls for complete authenticator management guidance. The KB controls cited above represent the closest verified mappings available from the provided reference set.
Platform Playbooks
Microsoft Sentinel / Defender
CrowdStrike Falcon
AWS Security
🔒
Microsoft 365 E3
3 log sources
Basic identity + audit. No endpoint advanced hunting. Defender for Endpoint requires separate P1/P2 license.
🛡
Microsoft 365 E5
18 log sources
Full Defender suite: Endpoint P2, Identity, Office 365 P2, Cloud App Security. Advanced hunting across all workloads.
🔍
E5 + Sentinel
27 log sources
All E5 tables + SIEM data (CEF, Syslog, Windows Security Events, Threat Intelligence). Analytics rules, playbooks, workbooks.
Hard indicator (direct match)
Contextual (behavioral query)
Shared platform (review required)
MITRE ATT&CK Hunting Queries (4)
Sentinel rule: Phishing email delivery
KQL Query Preview
Read-only — detection query only
EmailEvents
| where Timestamp > ago(7d)
| where ThreatTypes has "Phish" or DetectionMethods has "Phish"
| summarize Attachments = make_set(AttachmentCount), Urls = make_set(UrlCount) by NetworkMessageId, Timestamp, SenderFromAddress, RecipientEmailAddress, Subject, DeliveryAction, DeliveryLocation, ThreatTypes
| sort by Timestamp desc
Sentinel rule: Privilege escalation / account modification
KQL Query Preview
Read-only — detection query only
AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName has_any ("Add member to role", "Add app role assignment", "Add owner to application", "Reset user password")
| extend Target = tostring(TargetResources[0].userPrincipalName), Actor = tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, OperationName, Actor, Target, Result
| sort by TimeGenerated desc
Sentinel rule: Sign-ins from unusual locations
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where ResultType == 0
| summarize Locations = make_set(Location), LoginCount = count(), DistinctIPs = dcount(IPAddress) by UserPrincipalName
| where array_length(Locations) > 3 or DistinctIPs > 5
| sort by DistinctIPs desc
Sentinel rule: Supply chain / cross-tenant access
KQL Query Preview
Read-only — detection query only
SigninLogs
| where TimeGenerated > ago(7d)
| where HomeTenantId != ResourceTenantId
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, Location, HomeTenantId, ResourceTenantId
| sort by TimeGenerated desc
No actionable IOCs for CrowdStrike import (benign/contextual indicators excluded).
No hard IOCs available for AWS detection queries (contextual/benign indicators excluded).
Compliance Framework Mappings
T1534
T1566
T1098.005
T1621
T1556.006
T1566.004
+8
AT-2
CA-7
SC-7
SI-3
SI-4
SI-8
+5
164.312(d)
164.308(a)(5)(i)
MITRE ATT&CK Mapping
T1534
Internal Spearphishing
lateral-movement
T1566
Phishing
initial-access
T1621
Multi-Factor Authentication Request Generation
credential-access
T1556.006
Multi-Factor Authentication
credential-access
T1557
Adversary-in-the-Middle
credential-access
T1539
Steal Web Session Cookie
credential-access
T1078
Valid Accounts
defense-evasion
T1550.001
Application Access Token
defense-evasion
T1199
Trusted Relationship
initial-access
Guidance Disclaimer
The analysis, framework mappings, and incident response recommendations in this intelligence
item are derived from established industry standards including NIST SP 800-61, NIST SP 800-53,
CIS Controls v8, MITRE ATT&CK, and other recognized frameworks. This content is provided
as supplemental intelligence guidance only and does not constitute professional incident response
services. Organizations should adapt all recommendations to their specific environment, risk
tolerance, and regulatory requirements. This material is not a substitute for your organization's
official incident response plan, legal counsel, or qualified security practitioners.
View All Intelligence →