Identity & access

Harden cloud identities after phishing disruption

After disruption of a phishing-service ecosystem, do not assume that stolen credentials, tokens, or established access have been eliminated. Require phishing-resistant multifactor authentication for privileged and high-risk cloud users, disable weaker fallback methods where feasible, and monitor for session replay, risky sign-ins, new authentication registrations, suspicious consent changes, mailbox manipulation, and anomalous cloud-account activity.

Harden high-value accounts against relationship-based phishing

Organizations should prioritize phishing-resistant, origin-bound authentication for policy experts and other high-value users, reduce reliance on methods susceptible to relay, and independently verify unfamiliar contacts claiming to be officials, researchers, or technology-company staff. Targeted accounts should be reviewed for credential or session misuse using available sign-in and session evidence, with local escalation criteria.

Contain and investigate AWS Loom identity exposure

Organizations using affected Loom deployments should restrict ingress and untrusted registrations, preserve application and cloud audit evidence, revoke exposed integration tokens, remove unknown registrations, review managed-role policy history, and install the vendor-confirmed fixed release.

Certificate persistence checks before Active Directory trust rotation

Organizations responding to Active Directory compromise should preserve evidence and investigate both directory and certificate-service persistence before rotating trust. Rotation should use clean administrative systems, while repeated credential resets and forest rebuilding should remain conditional on established compromise and recovery-integrity findings.

Identity controls for passkey-themed cloud takeover

Organizations should restrict device-code authentication to approved users and applications, enforce phishing-resistant Conditional Access, and monitor authentication-method additions. On corroborated takeover indicators, revoke sessions and tokens, remove unauthorized methods and grants, disable only identities or applications confirmed compromised, and review subsequent cloud-data access.

Targeted containment for Microsoft 365 session exposure

Organizations responding to reported Microsoft 365 session exposure should preserve sign-in and audit evidence, confirm affected identities through correlation, revoke linked user and application sessions, disable confirmed accounts, and review account and OAuth changes. Targeting or exposure reports alone do not establish compromise of every named tenant.

Mailbox compromise response beyond password resets

For mailbox compromise and payment-fraud response, reset passwords only as one step. Revoke active session material, inspect mailbox persistence and forwarding, strengthen authentication, and verify payment or bank-change requests through an independent channel.

Identity session and approval workflow hardening

Organizations should treat phishing-kit takedowns as disruption rather than remediation and harden Microsoft 365 and Entra sessions, OAuth grants, MFA, and session persistence. High-risk finance, payroll, HR, vendor-bank, and help-desk approvals should require out-of-band dual control instead of relying on voice, video, email, or chat alone.

Token and session revocation before password resets

→For exposed automation tokens, credential-based tenant compromise, or MFA phishing, revoke API tokens, workflow credentials, OAuth grants, sessions, remembered devices, recovery factors, and newly enrolled authenticators before relying on password resets.

When SaaS or automation credential exposure is confirmed, a password reset alone is not sufficient. Revoke or invalidate exposed tokens, OAuth grants, sessions, remembered devices, recovery factors, and suspicious newly enrolled authenticators before treating the account or workflow as restored.

Revoke reusable identity trust before rotating passwords

→For credential-based intrusions, revoke active sessions, refresh tokens, OAuth grants, SAML sessions, remembered devices, API keys, and weak trust paths before or alongside scoped password rotation; move targeted privileged users toward phishing-resistant MFA.

In credential-driven incidents, prioritize revoking reusable trust artifacts, then rotate exposed credentials and strengthen MFA for targeted privileged accounts. Present this as a response pattern, not confirmation that every named scenario occurred.

AI-agent and SaaS identity token-broker lockdown

→Yes. Treat AI-agent automation and SaaS identity flows as token-broker control planes tonight: restrict device-code authentication and OAuth consent, review high-risk app scopes, rotate automation and API tokens, use task-scoped least-privilege agent roles, require human approval for privileged tool calls, patch affected agent-framework deployments as vendor updates are available, and log tool-call provenance.

Treat AI-agent automation and SaaS identity flows as token-broker control planes. Restrict device-code authentication and OAuth consent, review high-risk app scopes, rotate automation and API tokens, enforce least privilege and human approval for privileged tool calls, apply vendor updates as available, and log tool-call provenance. Do not imply confirmed tenant compromise without corroboration.

Reusable trust artifact revocation for automation exposure

→Respond to automation and token-abuse exposure by revoking reusable trust artifacts, not resetting passwords only. Pause exposed or autonomous workflows that can cross trust zones, revoke sessions and API tokens, rotate workflow-stored and connector secrets, restrict device-code and OAuth consent paths, segment automation runners, and log which identity called which API.

When automation, connector, or token abuse is plausible, organizations should revoke sessions and API tokens, rotate workflow and connector secrets, pause risky autonomous workflows, restrict consent paths, segment runners, and improve identity-to-API logging rather than relying on password resets alone.

Harden hotel network use for high-risk travel

→Yes. For executive, diplomatic, defense, energy, media, government, and similar high-risk travel, use separate or managed devices, phishing-resistant MFA, avoid sensitive logins over unmanaged hotel networks, and revoke or refresh tokens after travel.

High-risk travelers should temporarily harden hotel network use with managed or separate devices, phishing-resistant authentication, avoidance of sensitive logins over unmanaged networks, and token refresh after travel. Keep campaign attribution cautious.

Microsoft 365 calendar and Graph abuse telemetry

→Instrument Microsoft 365 and Graph telemetry to hunt for unusual calendar creation and attachment activity, far-future events, abnormal Graph API use, OAuth and Entra token changes, suspicious endpoint configuration files, and DNS-tunnel fallback behavior.

SOC teams should add hunting coverage for abnormal Microsoft 365 calendar and Graph activity, unusual OAuth or Entra token behavior, suspicious endpoint configuration files, and fallback DNS tunneling patterns associated with SaaS abuse.

Google synced passkeys need stricter enterprise controls

→Keep passkeys, but tighten policy for high-risk roles. Use physical security keys or enterprise-managed device-bound passkeys for privileged users, restrict consumer-synced passkeys where endpoint compromise risk is material, audit enrollment and recovery, and isolate the endpoint before session revocation or passkey removal.

Passkey cryptography is not treated as broken. For high-risk enterprise users, favor hardware-backed or managed device-bound passkeys, restrict consumer-synced passkeys where endpoint trust is weak, audit enrollment and recovery, and handle endpoint compromise before revoking sessions or removing suspicious passkeys.

Restrict Microsoft Entra OAuth Device Code Flow

→Block Microsoft Entra OAuth Device Code Flow where there is no known business dependency. Where it is needed, limit use to named users, named applications, managed devices, expected locations, Conditional Access, monitoring, and rapid session or refresh-token revocation for suspicious use.

Do not treat OAuth Device Code Flow sign-ins as harmless merely because MFA completed. Block the flow where there is no business dependency, and tightly scope any exceptions to known users, applications, managed devices, expected locations, Conditional Access, monitoring, and rapid token revocation for suspicious use. Use cautious wording for vendor attribution unless primary guidance is attached.

Limit OAuth apps and AI agent delegated authority

→Disable unapproved OAuth apps and broad AI agent connectors, revoke grants and refresh tokens where exposure exists, require fresh explicit authorization with admin policy checks, issue scoped short-lived identities, and require semantic confirmations for high-risk actions.

Do not let unapproved OAuth apps or AI agent connectors retain broad delegated access after weak consent flows. Revoke unapproved grants, require fresh explicit authorization with admin policy checks, use scoped short-lived identities, and require clear user confirmation for high-risk actions.

Trust-chain recovery instead of password-only reset

→Do not close identity recovery with password resets alone. Revoke active sessions, invalidate refresh tokens where possible, rotate machine keys and signing or sealing secrets, review OAuth grants, rotate service account and API secrets, restrict risky device-code flows, and enforce phishing-resistant authentication for administrators and developers.

After incidents that may involve sessions, cloud tokens, machine keys, service secrets, OAuth grants, or privileged developer and administrator credentials, recovery should include trust-chain cleanup as well as password resets. Apply platform-specific rotations and revocations where affected exposure is confirmed.

Identity containment beyond password resets

→For suspected cloud identity, SaaS, VPN, or contractor credential abuse, identity teams should revoke sessions, refresh tokens, remembered devices, app passwords, OAuth grants, VPN sessions, and privileged access; move administrators to phishing-resistant authentication; audit SSO and federation paths; bind VPN and contractor access to managed devices; and add identity detections.

For suspected cloud identity, SaaS, VPN, or contractor credential abuse, teams should revoke sessions and tokens, audit federation and privileged paths, require stronger administrator authentication, and add detections rather than relying only on password resets.

Immediate validation of cloud and SaaS delegated-trust boundaries

→Audit Entra logs for suspicious app or client identifiers and token-theft signs, revoke risky sessions and refresh tokens, force reauthentication, audit OAuth grants, check IoT certificate-to-device policy boundaries, review Splunk secret exposure, and remove broad AI-agent production access until reviewed.

Validate delegated-trust boundaries where tokens, OAuth grants, device certificates, Splunk secrets, or AI-agent privileges could cross their intended scope. Review logs and grants, revoke risky sessions or refresh tokens, force reauthentication where warranted, and reduce broad production access until reviewed.

Reset durable trust after credential and token exposure

→A password reset is not enough when durable trust may be exposed; revoke or constrain refresh tokens, active sessions, OAuth consents, device-code flow, MFA recovery objects, SaaS sessions, developer tokens, endpoint keychain secrets, and downstream credentials where exposure is plausible.

After phishing, helpdesk social engineering, stealer exposure, or supply-chain token theft, do not stop at a password reset. Where exposure is plausible, revoke or constrain durable trust objects such as refresh tokens, sessions, OAuth grants, recovery paths, SaaS sessions, developer tokens, endpoint secrets, and downstream credentials.

Revoke delegated trust before relying on password resets

→Revoke active sessions, refresh tokens, OAuth grants, device-code sessions, suspicious enterprise applications, connected-app access, and exposed cloud keys before relying on password resets; then re-consent under tighter controls and reissue scoped credentials.

When an incident indicates that sessions, OAuth grants, connected apps, device-code sessions, or cloud keys may have been exposed or abused, revoke those delegated-trust artifacts before treating password resets as sufficient. Re-consent and reissue credentials only under tighter controls and scoped permissions.

Revoke delegated identity trust before credential rotation

→Treat OAuth grants, sessions, refresh tokens, connected-app tokens, exposed cloud principals, STS sessions, service-account delegation, and guest access as attacker-held trust state; revoke or freeze them before relying on password or key rotation, then re-consent only approved apps and hunt SaaS-to-SaaS access.

During identity, SaaS, and cloud recovery, revoke or freeze delegated trust artifacts such as OAuth grants, refresh tokens, active sessions, connected-app tokens, STS sessions, service-account delegation, exposed principals, and guest access before treating password or key rotation as sufficient. Re-consent only approved apps and hunt SaaS-to-SaaS access.

Handle MFA phishing as session and token compromise

→For Evilginx-style AiTM or Microsoft device-code phishing exposure, start with trust-state destruction: revoke sessions and refresh tokens, review OAuth grants and enterprise app consent, restrict or disable device-code flow where feasible, hunt for token replay, and prioritize phishing-resistant authentication for sensitive users.

For suspected or confirmed Evilginx-style AiTM or Microsoft device-code phishing exposure, respond as potential session/token compromise: revoke tokens and sessions, review OAuth consent, constrain device-code flows where feasible, hunt token replay, and move sensitive users toward phishing-resistant authentication.

Lock down Entra passkey and device-code abuse paths

→Restrict passkey/FIDO2 registration by group and trusted context, block or tightly scope device-code flow, alert on authentication-method changes, remove suspicious enrolled methods, and revoke sessions or refresh tokens where abuse is suspected.

For reported passkey, device-code, AiTM, and session-abuse patterns, Microsoft 365 and Entra teams should restrict passkey/FIDO2 enrollment to approved groups and trusted contexts, tightly scope or disable device-code flow where feasible, monitor authentication-method changes, remove suspicious methods, and revoke sessions or tokens; this is framed as a roundtable-recommended control posture rather than definitive Microsoft-attributed guidance.

Revoke durable trust artifacts after M365 or Entra compromise

→For affected Microsoft 365 or Entra tenants and users, reset credentials and also revoke sessions and refresh tokens, remove unknown passkeys and MFA methods, audit OAuth and device-code grants, review app consents, constrain device-code authentication, require phishing-resistant authentication for high-risk users, and allowlist browser extensions.

For suspected or confirmed Microsoft 365 and Entra compromises, response should include durable-trust cleanup beyond password resets: revoke sessions and refresh tokens, remove unknown passkeys and MFA methods, review OAuth/device-code grants and app consents, constrain risky flows, and require stronger authentication for high-risk users.

Microsoft 365 OAuth phishing requires token and consent revocation

→Revoke Microsoft 365 user sessions and refresh tokens for exposed users, remove suspicious enterprise apps and service principals, revoke delegated OAuth grants, disable broad user consent, constrain device-code authorization, and require admin-reviewed consent for new OAuth permissions.

For Microsoft 365 OAuth or device-code phishing exposure, remediation should include session and refresh-token revocation, suspicious app and service-principal removal, delegated grant revocation, and tighter consent controls rather than relying on password resets alone.

Prioritize identity trust-state revocation over password resets

→In the first 30 minutes of suspected identity exposure or token abuse, prioritize revoking sessions and refresh tokens, removing suspicious OAuth grants and service principals, restricting device-code auth, requiring phishing-resistant MFA for admins and high-risk users, and alerting on MFA, Conditional Access, OAuth, device, and impossible-travel anomalies.

For reported identity exposure involving sessions, OAuth grants, device-code flows, AiTM-style phishing, or help-desk abuse, make trust-state revocation the first response priority rather than relying on password resets alone. Revoke sessions and refresh tokens, remove suspicious grants and service principals, restrict device-code auth, require phishing-resistant MFA for high-risk roles, and monitor MFA, Conditional Access, OAuth, device, and impossible-travel anomalies.

Treat OAuth, token, and infostealer exposure as attacker-held trust state

→Treat ARToken, Klue OAuth, infostealer, and related credential exposures as attacker-held trust-state incidents rather than password-reset incidents. Revoke live sessions and refresh tokens, remove suspicious OAuth grants, kill remembered devices, rotate connected-app and integration secrets, revoke app passwords and personal access tokens, and review Microsoft 365, Salesforce, GitHub/GitLab, CI/CD, cloud, package, and mailbox activity for token use after supposed containment.

When OAuth grants, refresh tokens, sessions, app passwords, personal access tokens, or infostealer-derived credentials may be attacker-held, organizations should revoke live trust state and review downstream SaaS, developer, CI/CD, cloud, and mailbox activity after reset actions.

Handle Bluekit-style Microsoft AiTM phishing as session and token compromise

→IAM and SOC teams should treat Bluekit-style Microsoft AiTM phishing as session/token compromise rather than password reset alone: revoke risky Microsoft sessions, invalidate refresh tokens, remove suspicious MFA methods and OAuth grants, enforce conditional access, force reauthentication, and move privileged or high-risk users to phishing-resistant authentication.

For Bluekit-style Microsoft AiTM phishing, response should focus on session and token containment rather than password reset alone: revoke risky sessions, invalidate refresh tokens, review MFA methods and OAuth grants, tighten conditional access, force reauthentication, and prioritize phishing-resistant authentication for privileged or high-risk users. Avoid claims about Bluekit scale or attribution unless independently sourced.