Canadian authorities responding to a US request have arrested a man in southern Ontario for his alleged role in hacks of over 100 organizations that use the Snowflake cloud database.
Following a request by the United States, a man was arrested on a provisional arrest warrant on Wednesday 30 October, Ian McLeod, a senior advisor to the Department of Justice of Canada, said in an email to CSO, adding, “as extradition requests are considered confidential state-to-state communications, we cannot comment further on this case.”
The US Justice Department declined to comment.
Canadian federal and provincial authorities haven’t released the court documents relating to the arrest, so CSO isn’t naming the accused.
The news first broke when Bloomberg News, citing unnamed sources, linked the arrest to the Snowflake attacks. Those attacks include copying records of 560 million Ticketmaster customers and nearly 110 million AT&T customers earlier this year.
Mandiant tracks the threat actor or actors behind the Snowflake attacks as UNC5537. On Tuesday, Austin Larsen, a Mandiant senior threat analyst, said this person or persons has proven to be one of the most consequential threat actors of 2024. The April attack by the threat actor systematically compromised misconfigured SaaS instances across over a hundred organizations, he noted. “The operation, which left organizations reeling from significant data loss and extortion attempts, highlighted the alarming scale of harm an individual can cause using off-the-shelf tools.”
In a separate statement, Mandiant said it continues to respond to a high proportion of intrusions where the initial access was obtained using stolen credentials.
Mandiant and Snowflake have been jointly investigating this cluster of attacks. As of June, they had notified 165 organizations that their data had potentially been exposed.
Mandiant’s investigation found no evidence that there was unauthorized access to customers’ data from a breach of the Snowflake IT environment. “Instead, every incident Mandiant responded to associated with this campaign was traced back to compromised customer credentials,” it said.
“These credentials were primarily obtained from multiple infostealer malware campaigns that infected non-Snowflake owned systems. This allowed the threat actor to gain access to the affected customer accounts and led to the export of a significant volume of customer data from their Snowflake customer instances. The threat actor has subsequently begun to extort many of the victims directly and is actively attempting to sell the stolen customer data on recognized cybercriminal forum,” Mandiant said.
Most of the stolen credentials, it added, came from infostealer infections that in some cases dated as far back as 2020.
Cybersecurity experts have been talking about Snowflake attacks for some time. In September, after more attacks, Brian Soby, CTO of AppOmni, said, “what we saw in the Snowflake ecosystem is most definitely not unique to that solution. This scenario could have easily played out in any major SaaS application, as the core vulnerabilities are the same; they center around a lack of meaningful visibility into the security configuration of applications and a lack of effective monitoring capability.”
“Organizations need to take a real look at their security programs and whether their security strategies extend through their SaaS applications, or simply stop at the front door,” he added. “If you’re a big user of SaaS in your business, yet your security architecture basically stops at single sign on (SSO) or a secure access service edge (SASE) to get users to the front door of applications, you need to realize that your security strategy offers no meaningful defense to this wave of attacks.”
The customer is responsible for correctly configuring its SaaS instances, Soby explained.
“This issue is within the control and responsibility of the customer, and not the SaaS vendors,” he said. “It’s the provider’s responsibility to create and operate a secure product that is patched, isn’t susceptible to injection or other classes of application attacks, and to provide the features for customers to secure their usage of the product in line with their needs. It’s the customer’s responsibility to use those security features as intended and as required by their policies. There’s probably not a single impacted organization here that’s operating these systems according to their own security policies.”