Cyber Decision LedgerTechnology
SaaS collaboration
14 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
Identity session and approval workflow hardening
Treat phishing-kit takedown as disruption, not remediation: revoke risky Microsoft 365 and Entra sessions and refresh tokens, inspect OAuth grants, require phishing-resistant MFA for high-risk roles, shorten session persistence, and move payment, payroll, vendor-bank, HR, and help-desk approvals to out-of-band dual control rather than relying on voice, video, email, or chat alone.
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.
Microsoft 365 account compromise containment
Do not rely on password reset alone after suspected or confirmed Microsoft 365 AiTM, payroll, or finance mailbox compromise. Revoke active sessions and refresh tokens, remove suspicious forwarding and inbox rules, review OAuth and device-code grants, re-register MFA or device trust from clean devices, and add out-of-band payment controls.
After Microsoft 365 account compromise involving AiTM, payroll, or finance workflows, reset passwords only as part of a broader containment plan: revoke sessions and tokens, remove attacker-created mailbox or access artifacts, review application and device grants, recover MFA from clean devices, and verify payment changes out of band.
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.
Stolen-trust response for OWAReaper access
On-prem Exchange and Microsoft 365 identity teams should treat OWAReaper-related access as a stolen-trust incident, not just a password-reset event: patch or mitigate affected Exchange exposure, restrict OWA, revoke sessions and refresh tokens, audit EWS and Outlook add-in tokens, remove suspicious OAuth grants and mailbox permissions, clear OWA browser storage, inspect mailbox rules and forwarding, and scope mailbox-only versus tenant compromise from observed post-access activity.
When OWAReaper-related access is suspected, treat the case as stolen trust: patch or mitigate Exchange exposure, restrict OWA, revoke active sessions and refresh tokens, audit mailbox and add-in access, remove suspicious grants or permissions, clear browser-stored trust artifacts, and inspect mailbox rules and forwarding. Broader tenant compromise should be stated only when post-access evidence supports it.
ServiceNow AI Platform exploitation triage before notification
Do not treat exploitation risk by itself as a breach-notification event. Preserve tenant, admin, audit, prompt, output, ticket, and credential evidence; conduct governance and vendor-risk triage; and escalate to notification analysis only if unauthorized access or data exposure is found.
Reported exploitation risk in a workflow or AI platform should trigger evidence preservation and tenant-specific triage. It should not be described as a reportable breach unless unauthorized access or data exposure is confirmed through the review.
Isolate applicable self-managed ShareFile Storage Zone Controllers
Isolate or power down applicable self-managed/on-prem ShareFile Storage Zone Controllers, preserve logs and configuration, and restore only after applicable vendor mitigation is validated or a clean rebuild is completed.
For applicable self-managed ShareFile Storage Zone Controller deployments covered by the cited reporting, isolate or power down exposed controllers while preserving logs and configuration. Restore only after validated vendor guidance or a clean rebuild; this wording does not assert compromise of every deployment.
Treat suspected AiTM and SaaS abuse as session and OAuth trust compromise
For suspected Microsoft 365 AiTM, Salesforce, OAuth, or help-desk social-engineering exposure, handle the event as potential attacker-held session, refresh-token, or connected-app trust rather than password-only compromise. Revoke sessions, invalidate refresh tokens, review OAuth and connected apps, inspect risky sign-ins, Salesforce exports and API volume, review new MFA enrollments or reset events, verify high-risk help-desk resets through pre-registered channels, and enforce phishing-resistant authentication for admin and high-risk roles.
When Microsoft 365 AiTM, Salesforce, OAuth, or help-desk social-engineering exposure is suspected, treat it as potential session or trust-state compromise, not a password-only event. Revoke sessions and refresh tokens, review OAuth and connected apps, inspect risky sign-ins and SaaS export/API activity, verify MFA and help-desk reset changes, and require phishing-resistant authentication for admin and high-risk roles.
Contain exposed ShareFile Storage Zone Controllers
Isolate or power off exposed or affected ShareFile Storage Zone Controllers now, reroute file-transfer workflows, and preserve logs or evidence where feasible.
Organizations with exposed or affected ShareFile Storage Zone Controllers should take an immediate containment posture, including isolation or power-off, workflow rerouting, and evidence preservation, while awaiting authoritative vendor or CISA scope details.
Restrict Microsoft 365 trust-enrollment and session-persistence paths
Restrict new passkey, security-key, authenticator, phone, and recovery-method enrollment for high-risk users to managed devices, trusted networks, or verified help-desk workflows; limit broad device-code authentication where feasible; revoke suspicious sessions, refresh tokens, OAuth grants, and attacker-added authentication methods.
Microsoft 365 tenants should harden trust-enrollment and session-persistence controls now: restrict new authentication-method registration for high-risk users, limit device-code authentication where feasible, and review or revoke suspicious sessions, refresh tokens, OAuth grants, and added authentication methods. Named campaign details in the source packet are treated as source-reported rather than independently confirmed.
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.
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 identity and messaging incidents as trust-state compromise
Treat current identity and messaging incidents as active trust-state compromise: revoke Microsoft 365 and IdP sessions and refresh tokens, invalidate suspicious OAuth grants, remove unknown MFA methods and linked messaging devices, rotate exposed Salesforce/API/OAuth connected-app secrets, and force re-authentication for high-risk users after revocation.
For identity or messaging incidents involving tokens, OAuth grants, MFA methods, linked devices, or connected apps, handle containment as trust-state compromise rather than only a password reset. Revoke active trust artifacts, remove suspicious access paths, rotate exposed secrets, and require re-authentication after revocation.
Treat session and token abuse as trust-artifact compromise, not only password-reset work
Treat FortiBleed, Kali365, and Klue/Salesforce containment as token and session compromise: revoke active sessions, refresh tokens, OAuth grants, service principals, connected-app and integration tokens first; then rotate secrets, hunt for persistence, and restore access only under stronger trust controls.
For incidents involving valid sessions, OAuth grants, service principals, connected apps, or integration tokens across Fortinet, Microsoft 365, and Salesforce-linked tools, treat password resets as insufficient. Revoke active trust artifacts first, then rotate credentials, hunt for persistence, and restore access under stronger controls.
Contain Salesloft Drift/Salesforce OAuth token abuse
For organizations using the affected Salesloft Drift/Salesforce integration, treat potential OAuth-token abuse as urgent containment: revoke Salesloft Drift OAuth access and refresh tokens, disconnect or reauthorize the Salesforce integration until assessed, and review Salesforce API/Event Monitoring logs, SOQL/query activity, exports, and CRM/support records for exposed secrets.
Organizations that use the affected Salesloft Drift/Salesforce integration should urgently revoke or rotate Drift OAuth access and refresh tokens, disconnect or reauthorize the Salesforce integration while assessing exposure, and review Salesforce API/Event Monitoring, SOQL/query and export activity, and CRM/support records for exposed secrets. Scope impact claims to tenant evidence and integration presence.