Stolen Credentials in SaaS Environments

Two routes to a valid login

Route one: credentials that were already out there

Mandiant’s investigation of the Snowflake customer campaign found that the actor, tracked as UNC5537, logged in with stolen customer credentials, mainly taken from infostealer infections on systems that had nothing to do with Snowflake. At least 79.7% of the accounts used in the campaign had prior credential exposure. Some credentials had not been rotated in as long as four years. The affected accounts had no MFA, so a valid username and password was enough. About 165 potentially exposed organizations were notified.

Two further details matter for defenders. Access was not limited to trusted locations by network allow lists. And in several investigations, the first infection was on a contractor’s system that was also used for personal activity such as gaming and pirated software. Those devices held administrator-level access to several organizations.

Route two: credentials captured live

Mandiant and GTIG describe ShinyHunters-branded campaigns that work differently. Attackers phone employees and help desks, often posing as IT staff or vendors, and send them to victim-branded sign-in pages that collect SSO credentials and MFA codes in real time. They then enroll their own device in the victim’s MFA. Where that fails, they talk the help desk into a reset, using data that is often publicly known or taken from earlier breaches, such as employee IDs, SSNs and manager names.

The cleanup is deliberate. In observed cases the attackers deleted the identity provider’s “security method enrolled” notification, and used the ToogleBox Recall add-on, authorized through OAuth, to find and delete other security emails. The new MFA device and the notification of it were both hidden from the user.

Access in these cases appears opportunistic. What the attackers could reach depended on which apps the stolen SSO session was connected to. One session could open data in several platforms.

The two routes need different fixes. Old credentials fail on hygiene: no MFA, no rotation, no location limits. Live capture fails on authentication that a person can be talked into approving, and on a help desk that can be talked into a reset.

What happens after login

Once inside, the attackers use each platform’s own features rather than malware. Mandiant lists the pattern below, and the logs that record it. Some of those logs need extra licensing, which is a decision to make before an incident, not during one.

Mandiant’s hunting logic is worth turning into detections, after testing against your own field mappings:

• An MFA enrollment or reset shortly after a sign-in or password reset.

• A new country and a new MFA factor on the same login.

• Three or more different users enrolling MFA from one IP address within ten minutes.

• Google Takeout exports above roughly 500 MB.

• Deletion of identity-provider security notification emails.

• Bulk SharePoint or OneDrive downloads with PowerShell user agents.

• Sign-in domains that imitate your own SSO or internal portals.

What we know, what we assess, what we do not know

Documented

• In the Snowflake campaign, most accounts used had prior credential exposure, and the affected accounts had no MFA. No platform vulnerability was involved.

• In the ShinyHunters-branded campaigns, GTIG said the intrusions relied on social engineering, not flaws in vendors’ products.

• Actors in the Drift incident searched stolen Salesforce data for AWS keys, passwords and Snowflake tokens, which means SaaS data can hold the next set of credentials.

Our assessment

• Identity is now the practical perimeter for SaaS. With no endpoint footprint, the first evidence of intrusion is a log entry in a platform few teams monitor closely.

• Phishing-resistant authentication closes the live-capture route, but does nothing about old credentials in infostealer logs. The two controls are not substitutes.

• The weakest link is often process, not technology: a help desk reset, a contractor device, an unreviewed app authorization.

Not established by the sources used here

• How many organizations have the SaaS audit logs they would need to reconstruct an intrusion. No source quantifies this.

• How long attackers dwell in a SaaS tenant before exporting data. The cases describe activity, not typical timelines.

What should change

Where to apply this

Pick the SaaS application that holds your most valuable data and answer three questions. Could a valid password alone get in from any network? Would you see a new MFA device within minutes? Would you see an export of the whole customer table? A “no” to any of them is your first piece of work.

Sources

1. Mandiant. UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion

2. Mandiant. Proactive Defense Against ShinyHunters-Branded Data Theft Targeting SaaS

3. Mandiant and Google Threat Intelligence Group. Tracking the Expansion of ShinyHunters-Branded SaaS Data Theft

4. Google Threat Intelligence Group. Widespread Data Theft Targets Salesforce Instances via Salesloft Drift

5. Verizon. Data Breach Investigations Report (latest edition)