Subscribe and get these articles emailed when published

HackerStorm Ref: OFA-2026-08-SFK

Executive Summary

Traditional vulnerability management focuses heavily on software flaws identified by CVEs. However, exploitable weaknesses can also arise from insecure configurations, identity controls, credential exposure and gaps in monitoring.

The 2024 Snowflake customer account intrusions illustrate this problem. Attackers used credentials stolen by infostealer malware to access customer environments and steal data. No Snowflake software vulnerability was required.

For vulnerability management teams, the lesson is to keep CVE-based prioritisation and recognise its limits. A process that tracks software vulnerabilities while overlooking exposed credentials, weak authentication and insecure SaaS configurations can miss significant risks.

This article examines the documented weaknesses associated with the Snowflake campaign and proposes ways to identify, prioritise, remediate and verify these risks within an operational vulnerability management process.

1. The Breach Snapshot

Organisations: About 165 Snowflake customer organisations.

Attack vector: Valid credentials stolen by infostealer malware.

Platform vulnerability: No software flaw. Weakness in default configuration (MFA optional).

Impact: Mass data theft and extortion, with more than $2.5 million in extortion payments (DOJ).

Victims include: AT&T, Ticketmaster and Advance Auto Parts.

Primary failure: Identity and Access Management (IAM), with contributing failures in Discovery and Network Segmentation.

2. Timeline of Key Events

Key events, from first observed credential exposure to the platform's MFA changes.

▸ November 2020: Earliest infostealer infection tied to a campaign credential (Mandiant). Exposed credentials then went unrotated for years (see Section 6).

▸ April 2024: UNC5537 begins the intrusion campaign. Credentials stolen as early as 2020 still work.

▸ May to June 2024: Snowflake, Mandiant and CrowdStrike disclose the campaign and publish indicators and hardening guidance.

▸ July 2024 to October 2026: Snowflake adds account-wide MFA enforcement options (July 2024), turns MFA on by default for human users in new accounts (October 2024), then phases in mandatory MFA and blocks passwords for legacy service users (see Snowflake release notes and documentation).

3. Exploit Chain Breakdown, Mapped to MITRE ATT&CK

▸ Initial Access (T1078, Valid Accounts): Infostealer-harvested credentials (Mandiant).

▸ Discovery (T1087, Account Discovery): FROSTBITE reconnaissance tool (Mandiant).

▸ Collection (T1213, T1074): Based on reporting, SQL-based staging through standard clients, including DBeaver.

▸ Exfiltration (T1567): Bulk data export.

▸ Impact (T1657, Financial Theft): Extortion and data sale.

Valid credentials gave direct access to the data. No privilege escalation was needed.

4. Where the Control System Broke

Identity Governance Failure

Mandiant found that affected accounts lacked three controls: MFA, credential rotation, and network allow lists. Before July 2024, Snowflake MFA was off by default and had to be enabled user by user. Credentials went unrotated, in some cases for years. Mandiant found that at least 79.7% of the accounts used in the campaign had prior credential exposure.

Bypassing central SSO: Based on reporting, some affected organisations may have had MFA enabled in their central identity provider, such as Okta or Microsoft Entra ID (formerly Azure AD). Local usernames and passwords created directly inside Snowflake would sit outside those central SSO and MFA policies. Where such local accounts existed, stolen credentials could be used against them without meeting the organisation's central controls.

Discovery Failure

Mandiant found that some initial infections came from contractor systems also used for personal activity, such as gaming and pirated software downloads. Credentials held by third parties sit outside a typical asset inventory. Their exposure is hard to see without an inventory that covers them.

Shadow IT and staging tenants: Dormant test, demo and staging environments are a likely blind spot. Temporary environments created years earlier and then forgotten typically lack ongoing identity governance. If they still hold stale copies of production data, they become easy targets for the same stolen-credential technique.

Segmentation and Network Failure

Affected accounts had no network allow lists. Logins were accepted from any IP address, including attacker infrastructure. An allow list tied to corporate egress ranges blocks stolen credentials used from outside those ranges.

Egress Monitoring Failure

Attackers staged and exported large volumes of data from victim tenants. IP allow lists cover only part of the problem. Defenders should assess whether their monitoring detects unusual SELECT * queries, COPY INTO staging activity and large exports, and whether suspicious activity triggers an appropriate response. The available evidence does not establish that these controls were absent or ineffective across every affected tenant.

Shared responsibility: The provider sets the platform defaults and decides which security controls are mandatory. The customer configures and enforces security on its own accounts. Both sides share this outcome: Snowflake left MFA optional, and affected customers did not switch it on.

5. Applying a Vulnerability Management Workflow

The Snowflake campaign illustrates why vulnerability management should consider exploitable weaknesses beyond software flaws. The following workflow provides a practical way to incorporate these risks into existing processes.

These findings can be tracked alongside conventional vulnerabilities, but should retain their own finding types and remediation criteria. A configuration weakness or exposed credential does not need a CVE to warrant action.

6. Exploitation Intelligence Context

CVE status: None. No KEV entry or EPSS score applies. The attack used valid passwords. The weakness was a configuration default: MFA was optional.

Exposure-to-exploitation interval: Up to approximately 41 months, from the earliest infostealer infection Mandiant observed (November 2020) to the first intrusions (April 2024). This is the longest gap observed for a credential in the campaign, not the typical one.

The pattern recurred: In August 2025, a different group used compromised OAuth tokens associated with the Salesloft Drift integration to access Salesforce customer data, without exploiting a vulnerability in the core Salesforce platform (GTIG). The incident illustrates the risk of trusted third-party integrations with excessive permissions. Review connected applications for excessive permissions, restrict scopes to what each integration requires, monitor token use and maintain a process to revoke compromised tokens. MFA alone does not prevent misuse of a stolen, valid token.

7. What Would Have Prevented This

The actions below should be prioritised according to actual exposure, business impact and available evidence. The timeframes are proposed response targets; some organisations will not be able to resolve every issue within them.

Tactical: 48-Hour Actions

▸ Enforce single sign-on (SSO) with MFA on every human identity in every SaaS tenant that supports it. Tie SSO to managed corporate devices. Where supported, apply device-based access policies alongside SSO and MFA to reduce the risk from stolen credentials. Verify enforcement with an authentication policy audit, and allow documented exceptions only.

▸ Apply network policies restricting tenant authentication to known egress ranges.

▸ Rotate all credentials for data platform accounts, prioritising service accounts and third-party users.

▸ Review login history and query history for unfamiliar client strings, new source IPs, and high-volume export statements over the past 90 days.

▸ Disable or audit all local (non-SSO) database passwords in SaaS platforms; force all human authentication through the central IdP.

Structural: 90-Day Transformation

▸ Ingest infostealer log intelligence and match it against your domains, contractor domains, and SaaS tenant identifiers on a continuous basis.

▸ Implement service-account lifecycle controls, including assigned ownership, managed credential rotation or expiry where appropriate, and approved non-password authentication methods such as key-pair authentication or OAuth. For OAuth integrations, restrict scopes and permissions to the minimum required, monitor token use and establish a revocation process.

▸ Deploy default-deny egress on sensitive data stores, with volume-based alerting on export operations.

▸ Extend asset inventory to third-party and non-human identities with access to production data.

▸ Conduct an inventory of legacy, demo and staging tenants, and enforce automated decommissioning of unmonitored environments.

▸ Implement egress thresholds and anomaly detection on bulk COPY INTO and export SQL commands.

Detection Engineering Notes

Queries against Snowflake account usage views:

▸ Alert on sessions where the client application string identifies DBeaver or other generic JDBC clients on accounts that historically authenticate through BI tooling.

▸ Flag repeated CREATE STAGE, COPY INTO, and large SELECT * sequences within a single session, the staging and export signature observed in this campaign.

▸ Correlate first-seen source IP with first-seen client fingerprint. Both appearing together on an existing account warrants review.

8. Two Years On

Platform default versus customer responsibility, as of October 2026.

▸ Identity. Platform default now: mandatory MFA in three phases, ending August to October 2026. Still the customer's job: verify enforcement per tenant, handle exceptions, rotate legacy credentials.

▸ Service accounts. Platform default now: passwords blocked for legacy service users in the final phase. Still the customer's job: migrate to key-pair authentication or OAuth integrations with appropriately restricted scopes and permissions, inventory non-human identities.

Enforcement is scheduled to finish about two and a half years after the campaign, and Snowflake labels its own dates as estimates.

The Operator Checklist

Seven questions for any team running SaaS data platforms:

☐ Are third-party identities in your asset inventory?

☐ Are SaaS tenants subject to enforced SSO with MFA and network allow lists?

☐ Are credentials subject to appropriate rotation or expiry controls, including for service accounts?

☐ Do you monitor egress on sensitive data stores?

☐ Do you ingest infostealer exposure feeds for your domains and SaaS tenants?

☐ Are local database passwords disabled in favour of strictly enforced central IdP or SSO authentication?

☐ Do you have an inventory of non-production, demo and legacy SaaS instances, and are they scrubbed of production data?

A negative answer identifies a potential control gap that warrants assessment. On its own, it does not establish that the organisation has the same exposure as the affected Snowflake customers.

Conclusion: Extending Vulnerability Management Beyond CVEs

The Snowflake campaign demonstrates that attackers can exploit weaknesses in identity controls, credential management and SaaS configuration without exploiting a software flaw.

For vulnerability management teams, the practical challenge is to identify these weaknesses, assess their exposure and business impact, assign remediation ownership and verify that corrective actions work. This work should complement established CVE discovery and prioritisation processes.

Providers and customers also have different responsibilities. Providers determine platform capabilities and defaults; customers must understand and securely configure their environments, identities and access. Effective risk reduction depends on examining both.

A mature vulnerability management process should therefore consider exploitable weaknesses wherever they arise, including those that have no CVE identifier.

What you should do next

Ensure you understand operational related failures because failures are opportunities for learning and improving.

Frequently Asked Questions (FAQs)

1. What does the Snowflake breach teach us about vulnerability management?

The 2024 Snowflake customer account intrusions demonstrate that serious security incidents can occur without exploiting a software vulnerability. Attackers used credentials stolen by infostealer malware to access customer environments and steal data. Vulnerability management should therefore address identity controls, exposed credentials, insecure configurations and monitoring gaps alongside conventional CVEs.

2. Why was the Snowflake incident not a CVE-based vulnerability?

The campaign did not depend on exploiting a software flaw in Snowflake. Instead, attackers used valid credentials that had been stolen by infostealer malware. Weaknesses in account security, including missing MFA, credential rotation and network allow lists, contributed to the exposure. These operational weaknesses can create significant risk without having a CVE identifier.

3. How can organisations identify vulnerabilities that have no CVE?

Organisations can extend their vulnerability management workflow to inventory SaaS tenants, local accounts, service accounts and third-party identities. They should assess authentication enforcement, credential exposure, network restrictions, excessive permissions and monitoring coverage. Findings should be prioritised by exposure, data sensitivity, privileges and potential business impact, then tracked through remediation and verification.

4. Can MFA alone prevent attacks involving stolen credentials or OAuth tokens?

No. MFA can reduce the risk of unauthorised logins using stolen passwords, but it does not by itself prevent misuse of an already-compromised session or valid OAuth token. Organisations should also enforce appropriate access policies, restrict OAuth scopes and permissions, monitor token activity and maintain a process to revoke compromised credentials and tokens.

5. How should vulnerability management teams prioritise operational weaknesses?

Teams should consider whether a weakness is externally accessible, whether credentials are exposed, what data or privileges are available, and the potential business impact. They should assign remediation ownership, set appropriate response targets and verify that controls work as intended. Operational weaknesses can be tracked alongside CVEs, but should retain finding types and remediation criteria suited to the specific risk.

About This Report

Reading Time: Approximately 15 minutes

Attribution Note

This analysis is based on publicly available reporting and security research summaries. Some technical details may change as additional information becomes available.

Author Information

Timur Mehmet | Founder & Lead Editor

Timur is a veteran Information Security professional with a career spanning over three decades. Since the 1990s, he has led security initiatives across high-stakes sectors, including Finance, Telecommunications, Media, and Energy. Professional qualifications over the years have included CISSP, ISO27000 Auditor, ITIL and technologies such as Networking, Operating Systems, PKI, Firewalls. For more information including independent citations and credentials, visit our About page.

Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Standards

This article adheres to Hackerstorm.com's commitment to accuracy, independence, and transparency:

• Fact-Checking: All statistics and claims are verified against primary sources and authoritative reports
• Source Transparency: Original research sources and citations are provided in the References section below
• No Conflicts of Interest: This analysis is independent and not sponsored by any vendor or organization
• Corrections Policy: We correct errors promptly and transparently. Report inaccuracies to This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Policy: Ethics, Non-Bias, Fact Checking and Corrections

Learn More: About Hackerstorm.com | FAQs

Source Transparency

▸ Mandiant / Google Threat Intelligence Group: UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion

▸ Google Threat Intelligence Group: Widespread Data Theft Targets Salesforce Instances via Salesloft Drift

▸ U.S. Department of Justice: Canadian Man Pleads Guilty to Hacking U.S. Cloud Storage Provider and Extorting Its Customers for Millions

▸ Snowflake documentation: Planning for the deprecation of single-factor password sign-ins

▸ Snowflake blog: Default Multi-Factor Authentication and Stronger Password Policies

▸ SEC filings: AT&T Form 8-K, 12 July 2024; Advance Auto Parts Form 8-K, June 2024

▸ TechTarget, reporting Mandiant findings: Mandiant: Exposed credentials led to Snowflake attacks

▸ Infosecurity Magazine: Snowflake Pledges to Make MFA Mandatory

▸ SecurityWeek: Millions Impacted by Breach at Advance Auto Parts Linked to Snowflake Incident

▸ The Stack, reporting Mandiant findings: Mandiant sees 165 Snowflake breach victims, hygiene failures