On May 27, a threat actor group called ShinyHunters announced that it was selling 560 million records stolen in a data breach. The records include names, email addresses, physical addresses, and partial credit card numbers. This personally identifiable information (PII) can be used to conduct sophisticated phishing attacks, which could lead to future leaks.
Experts identified the SaaS platform Snowflake as the source of the breach. On June 2, the company’s CISO, Brad Jones, issued a joint statement with cybersecurity experts CrowdStrike and Mandiant stating that the breach was not caused by a vulnerability in the platform but rather a targeted incident aimed at users with single-factor authentication. Threat actors leveraged credentials they had either purchased previously or obtained using malware.
Snowflake’s investigation found that the breach came through compromised user accounts that used single-factor authentication. Once the threat actor found an active username and password with a high level of access, they had everything they needed to exfiltrate the data.
Like most SaaS platforms and applications, Snowflake relies on the shared responsibility model for security. Snowflake ensures that the application is secure, while customers are responsible for their configurations and user access control.
Here are several actions and configuration changes organizations can take to prevent similar attacks on Snowflake and other SaaS applications.
Multi-factor authentication (MFA) is the most important step you can take to prevent breaches in SaaS application. It’s not infallible, but the extra layer of authentication makes you 99% less likely to be attacked, according to U.S. cyber defense agency CISA. It is important to enforce MFA on all accounts rather than make it optional, and absolutely critical to do so for high-privileged accounts.
Single Sign-On (SSO) reduces potential points of compromise by minimizing the attack surface. Enforcing SSO is a significant security upgrade, as it enhances posture and prevents unauthorized access to critical applications.
Your network policy rules should define trusted traffic locations. Users who try to access an application without going through your VPN, cloud workload NAT, or approved IP addresses should not be granted access. Confirm that the network policy is in active mode.
High-privilege users are high-risk, as their accounts can provide threat actors with greater levels of access. Review user permissions to ensure that only those who actually need wide range access have it.
Dormant accounts increase the attack surface by providing threat actors with an unmonitored entryway into an application. Disabling or deprovisioning these accounts prevents threat actors from using them to breach an application.
Snowflake wrote that they “did find evidence that a threat actor obtained personal credentials to and accessed demo accounts belonging to a former Snowflake employee. It did not contain sensitive data. Demo accounts are not connected to Snowflake’s production or corporate systems. The access was possible because the demo account was not behind Okta or Multi-Factor Authentication (MFA), unlike Snowflake’s corporate and production systems.” Had the company stored actual data in their demo account, this breach could have been much larger.
Monitor SaaS applications for any indications of compromise (IOC). While we don’t have access to the IOCs in this instance, an attack like this most likely included access from a suspicious ASN, changes in the user’s OS or browser, or other signs that point toward a threat actor.
There was some evidence in early reports that part of this breach followed a hack of an employee’s ServiceNow account.
We will continue to monitor this breach and share updates as they arise. Regardless of whether ServiceNow was used in this attack, it’s a good time to ensure your ServiceNow is configured securely. Here are some steps to take.
A SaaS Security Posture Management (SSPM) platform alerts security teams and app owners when their configurations put Snowflake or any other application at risk. Introducing an SSPM into your SaaS environment goes a long way toward preventing these types of breaches.
Additionally, threat detection capabilities add an additional layer of protection. In Snowflake’s June 3 update, they indicated the issue originated with targeted attacks coming from a range of IP addresses. A SaaS-centric Identity Threat Detection & Response (ITDR) mechanism most likely would have alerted security teams that massive amounts of data were being downloaded by an account that had accessed the application through an atypical IP address.
This breach serves as a stark reminder that no SaaS application is immune. This year has already brought major breaches in Microsoft, Salesforce, GitHub, Slack, Azure Cloud, and others. SSPMs enable you to take control of SaaS security, monitor configurations, and prevent breaches from taking place.
While Adaptive Shield users have already received guidance on securing their Snowflake account and known Indicators of Compromise (IOC) have been integrated into our threat detection platform, your Snowflake instances could be exposed.
Don’t wait for a breach! Click here for a complimentary Snowflake security assessment from Adaptive Shield. Identify weaknesses and ensure your data remains safe. ️
Request a FREE SSPM demo and see how Adaptive Shield can continuously monitor your Snowflake environment for suspicious activity.
The post Breach Debrief Series: Snowflake MFA Meltdown Creates Data Leak Blizzard appeared first on Adaptive Shield.
*** This is a Security Bloggers Network syndicated blog from Adaptive Shield authored by Maor Bin. Read the original post at: https://www.adaptive-shield.com/blog/breach-debrief-series-snowflake-mfa-meltdown-creates-data-leak-blizzard/