Table of Contents
How compromised credentials turned into a cloud security crisis
The breaches linked to Santander and Ticketmaster put Snowflake under an uncomfortable spotlight. The central issue was not an alleged flaw in Snowflake’s cloud platform, according to the company. It was the far more familiar and persistent problem of compromised credentials attached to customer accounts that were not sufficiently protected.
That distinction matters, but it should not be used to minimize the incident. Cloud providers can be technically secure while their customers remain exposed through weak identity controls. When an attacker has a valid username, password, session token, or an already authenticated connection, they may not need to “break into” the platform in the conventional sense. They can simply enter through an account that the service recognizes as legitimate.
Hackers claimed they accessed data through an employee’s compromised account. Snowflake denied internal vulnerabilities and attributed the issue to poorly secured customer accounts. Those positions describe two sides of the same cloud-security reality: responsibility is shared, but the consequences are not neatly divided. Data stored centrally in a major cloud service can become a highly attractive target when account protections are uneven across hundreds or thousands of customers.
Cybersecurity firm Hudson Rock said a threat actor bypassed Okta’s authentication system. Using stolen credentials, the attacker accessed a Snowflake employee’s ServiceNow account and generated session tokens to extract data. Session tokens are particularly consequential in incidents like this because they can allow an attacker to operate as an authenticated user without repeatedly presenting a password. The attack therefore shifts from a one-time credential theft into a persistent access problem.
Hudson Rock reported that the breach affected hundreds of companies. The threat actor claimed access to data from organizations including Anheuser-Busch, State Farm, Mitsubishi, and more. Hudson Rock’s assessment was blunt:
“One stolen credential caused potential exposure for 400 companies storing data with Snowflake.”
Evidence also showed access to more than 2,000 customer instances on Snowflake’s Europe servers. That scale is what separates this episode from a typical account takeover. A compromised identity is dangerous in any environment, but it becomes much more serious when the account can reach an extensive collection of customer systems and data stores. The risk is not merely that one organization may lose control of information. It is that a single weak point can become a route into a broad ecosystem.
Extortion followed the access
The hacker attempted to blackmail Snowflake, demanding $20 million. Snowflake ignored the threats. Extortion has become a predictable next step after large-scale data access: the attacker’s leverage comes not only from what may have been taken, but from the prospect of disclosure, disruption, or reputational damage to the organizations whose data was exposed.
Investigations later found that the breach stemmed from malware, specifically Lumma Infostealer, which compromised corporate credentials in October. Infostealer malware is designed to harvest valuable information from infected systems, and credentials are among the most useful items it can collect. For attackers, stolen credentials reduce cost and risk. They do not have to develop an exotic exploit if they can obtain valid access details and find an account without additional safeguards.
Mandiant Consulting supported affected customers during the investigation. According to Mandiant’s CTO, the attackers likely used credentials stolen by malware to infiltrate Snowflake accounts. The recommendation was straightforward: use multi-factor authentication, or MFA, and IP-based restrictions to limit the ability to exploit accounts at scale.
Those controls address different parts of the problem. MFA adds a second check beyond a password, making a stolen credential less useful on its own. IP-based restrictions can narrow where an account is permitted to connect from, helping organizations detect or block access attempts originating outside expected networks. Neither measure eliminates risk entirely, especially where session tokens are involved, but both can force attackers to overcome more obstacles and make abnormal access easier to spot.
Snowflake’s CISO, Brad Jones, confirmed that unauthorized account access was detected on May 23, 2024. The company had observed increased threat activity since mid-April. The gap between early signs of activity and confirmed unauthorized access is a reminder that security teams often have to distinguish ordinary account behavior from malicious use. In a cloud environment with many customers and a large volume of legitimate queries, that is difficult work. It also makes logging, alerting, and active account monitoring essential rather than optional.
The tools reveal an operational attack, not a one-off event
Snowflake notified affected customers and recommended urgent measures, including MFA activation. It also released a bulletin with Indicators of Compromise, or IoCs, and tools intended to help customers protect their accounts. Publishing IoCs is important because it gives defenders concrete signs to search for in their own environments rather than leaving them to rely on general warnings.
One IoC identified a custom data-extraction tool called RapeFlake. Another highlighted the use of DBeaver Ultimate, a data management tool, to connect to and retrieve database information. The presence of both a custom tool and a legitimate data-management product illustrates a recurring challenge in incident response. Malicious activity does not always look like obviously malicious software. Attackers may use ordinary administrative or database tools because they blend into workflows that security teams already expect to see.
That is why detection cannot stop at blocking known malware. Organizations need to examine how accounts behave: whether they access unfamiliar customer instances, retrieve unusually large volumes of information, connect from unexpected locations, or use tools in ways that do not match their normal role. A valid account performing an invalid task is often harder to identify than a clearly unauthorized login attempt.
Snowflake continued to deny that a platform vulnerability caused the breaches. The reporting instead points to credential misuse and the absence of MFA as pivotal factors. That does not make this solely a customer hygiene story. Major cloud services are now central repositories for sensitive business information, and their customers need clear security defaults, practical guidance, and rapid support when account-based threats emerge. Snowflake’s notifications, security bulletin, and account-protection tools were part of that response.
The lesson is about identity, not just cloud infrastructure
The broader lesson from the Snowflake-linked incidents is that cloud security increasingly depends on identity security. Companies may invest heavily in storage, encryption, backups, and network protection, then leave a critical account protected by a password that malware can steal. That imbalance gives attackers an easier route than attacking the underlying infrastructure directly.
Organizations using cloud services should enable MFA on all accounts, monitor accounts for unusual activity, and restrict access through IP-based controls. These are not decorative policy requirements. They are practical barriers against the kind of mass exploitation described here. They also create useful signals for investigators when something does go wrong.
The cases involving Santander and Ticketmaster show why the stakes extend beyond one provider or one victim. When cloud services hold data for many organizations, a failure in credential protection can have consequences across industries. The most important response is not panic about cloud computing itself. It is a more disciplined approach to who can access sensitive data, how that access is verified, and how quickly suspicious behavior is investigated.
For related coverage, see Judge finds NSO Group liable for hacking WhatsApp, published December 22, 2024 by SquaredTech.
More news: Tech News
