Bottom line

Attackers are getting in as people and applications, not around them. Mandiant tied identity issues to 83 percent of incidents in major cloud and SaaS environments. The entry points are a phone call to the help desk, an OAuth token from a third-party integration, or a key left in a vendor’s system. Multi-factor authentication is still worth having, but several of these patterns work because the victim, or the help desk, completes the authentication step for the attacker.

Key judgments

JudgmentConfidence and basis
Identity is the working access path in cloud and SaaS intrusions. Third-party compromise and stolen credentials each accounted for 21 percent of cases, vishing 17 percent and email phishing 12 percent.High. Direct observation across a large incident caseload. The caseload skews toward intrusions serious enough to need outside responders.
Voice phishing has overtaken email phishing as the leading social-engineering route. Across all Mandiant cases, vishing was 11 percent of initial vectors, second only to exploits at 32 percent. Email phishing fell to 6 percent from 14 percent.High. Primary investigation data, consistent across two Mandiant publications.
Attackers now target tokens and authorizations rather than passwords. Cases include device-code phishing, stolen integration tokens and long-lived OAuth tokens and session cookies that stay valid after logout.Moderate. Strong case evidence. No public source measures how common it is.
The help desk is an identity control point. Financially motivated groups impersonate employees to obtain MFA resets and tool authorizations.High. Described by Mandiant and in the joint FBI and CISA advisory on Scattered Spider.
Non-human credentials are a primary target. Cloud access keys, source-control tokens and hardcoded keys held by SaaS vendors are being harvested and reused.Moderate. Documented in several campaigns. Prevalence is not quantified.

Observed patterns

PatternHow it worksWhat defenders seeWhere to look
Help-desk reset by phoneA caller impersonates an employee and asks for an MFA reset, a new enrollment or authorization of a data tool. Interactive social engineering often defeats traditional MFA because the human completes it.A legitimate-looking reset ticket, then a new MFA method and a first sign-in from unfamiliar infrastructure.Correlate resets and enrollments with caller verification records. Alert on a new MFA method followed quickly by a new-device sign-in.
Device-code vishingThe attacker generates a device code for a legitimate Microsoft OAuth client and persuades the victim, by phone, to enter it on the genuine Microsoft sign-in page. The victim completes password and MFA. The attacker receives tokens that work without repeating MFA.Sign-ins using the device-code flow from users who never use it. No phishing site exists to block.Review device-code authentication events. Disable the flow where it is not needed. Enforce conditional access.
Integration token theftStolen OAuth tokens for a third-party app let the actor query a CRM directly. In the Salesloft Drift campaign the actor ran record counts, exported cases and accounts, then searched the data for cloud keys, passwords and Snowflake tokens.Valid API activity from a connected app. No login challenge, no password failure.Connected-app query volume and exports. Restrict app scopes and source IPs. Search business data for embedded secrets.
Federation and MFA persistenceThe actor registers its own MFA tokens or adds a federated identity provider to the SSO tenant, so access survives a password reset.Identity-provider configuration changes by an account that does not normally make them.Alert on any new federation trust or MFA method on privileged accounts.
Non-human credential theftCloud keys and personal access tokens are taken from repositories, SaaS data or vendors’ systems and reused from new locations.Valid key use from unfamiliar addresses or services.Secret scanning of SaaS and repository data. Short-lived credentials. Review of trust between code platforms and cloud roles.

Analysis

The control moved to the recovery workflow. The strongest authentication in the world does not help if a caller with a plausible story can have it reset. The joint advisory on Scattered Spider describes this directly: attackers phone help desks, obtain password and MFA resets, and in some cases add their own federated identity provider so that access outlasts any password change. It recommends phishing-resistant MFA, which resists push bombing and SIM swapping. That does not fix a reset process that trusts a voice.

Tokens are the real prize. A token is already authenticated. Mandiant reports attackers harvesting long-lived OAuth tokens and session cookies that can remain valid after logout. Google Threat Intelligence observed that token abuse against SaaS tenants produced bulk data access without standard login alerts. A detection program built on failed and unusual logins misses this class of activity almost by design.

Speed leaves little room for slow triage. Mandiant measured the median time from initial access to hand-off to a second threat group at 22 seconds, down from more than eight hours. Median dwell time across investigations was 14 days, and Mandiant warns that 90-day log retention is not enough to scope the longer intrusions. An identity foothold is sold, passed on or exploited quickly, and the evidence you need may be older than your logs.

The usual objective is data, not encryption. In cloud-related incidents Mandiant found data theft was the primary goal in 73 percent. Nearly half were silent exfiltration with no immediate extortion. Identity abuse is how that theft is achieved without malware.

What should change

  1. Treat the help desk as a privileged system. Set verification standards for MFA resets and enrollment, call back on known numbers, add extra checks for privileged users, and log every reset for review.

  2. Inventory OAuth grants and connected apps. Remove what is unused, restrict scopes and source IPs, and be able to revoke and rotate in bulk. Google Threat Intelligence recommends avoiding broad full-access scopes.

  3. Disable the device-code flow where there is no business need, and enforce conditional access around the rest.

  4. Shorten session and token lifetimes for sensitive applications, and confirm what revocation actually does.

  5. Manage non-human credentials as identities. Inventory them, rotate them, prefer short-lived credentials, and scan SaaS and repository data for embedded secrets.

  6. Monitor the identity provider itself. Federation changes, new MFA methods and new admin accounts should alert.

  7. Keep identity and SaaS logs longer than ninety days where you can.

Gaps and limits

Percentages come from different Mandiant data sets and should not be added together. The cloud and SaaS initial-vector figures cover about 90 percent of cases; the source does not account for the rest. The device-code vishing campaign has been attributed to ShinyHunters by press reporting that relies on unnamed sources, and Microsoft declined to share details, so treat the attribution as unconfirmed. No public source measures how often token theft, as opposed to password theft, is the first step.

Next step

A useful test is to pick one pattern from the table, such as a help-desk reset, and trace whether your current logging would show it, who would see it, and how quickly access could be revoked.

Sources

  • Google Cloud, Mandiant: M-Trends cloud.google.com

  • Google Cloud: Cloud Threat Horizons Report cloud.google.com

  • Google Threat Intelligence Group and Mandiant: Data Theft from Salesforce Instances via Salesloft Drift cloud.google.com

  • CISA and FBI: Scattered Spider joint cybersecurity advisory cisa.gov

  • BleepingComputer: Hackers target Microsoft Entra accounts in device code vishing attacks bleepingcomputer.com

How we label evidence

Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.