\n<\/p>\n
Cloud data analysis company Snowflake is at the center of a recent spate of alleged data thefts, as its corporate customers scramble to understand if their stores of cloud data have been compromised.\u00a0<\/p>\n
The Boston-based data giant helps some of the largest global corporations \u2014 including banks, healthcare providers and tech companies \u2014 store and analyze their vast amounts of data, such as customer data, in the cloud.<\/p>\n
Last week, Australian authorities sounded the alarm<\/a> saying they\u00a0had become aware of \u201csuccessful compromises of several companies utilising Snowflake environments,\u201d without naming the companies. Hackers had claimed on a known cybercrime forum that they had stolen hundreds of millions of customer records from Santander Bank and Ticketmaster, two of Snowflake\u2019s biggest customers. Santander confirmed a breach of a database<\/a> \u201chosted by a third-party provider,\u201d but would not name the provider in question. On Friday, Live Nation confirmed that its Ticketmaster subsidiary was hacked and that the stolen database was hosted on Snowflake<\/a>.\u00a0<\/p>\n Snowflake acknowledged in a brief statement<\/a> that it was aware of \u201cpotentially unauthorized access\u201d to a \u201climited number\u201d of customer accounts, without specifying which ones, but that it has found no evidence there was a direct breach of its systems. Rather, Snowflake called it a \u201ctargeted campaign directed at users with single-factor authentication\u201d and that the hackers used \u201cpreviously purchased or obtained through infostealing malware,\u201d which is designed to scrape a user\u2019s saved passwords from their computer.<\/p>\n Despite the sensitive data that Snowflake holds for its customers, Snowflake lets each customer manage the security of their environments, and does not automatically enroll or require its customers to use multi-factor authentication, or MFA, according to Snowflake\u2019s customer documentation<\/a>. Not enforcing the use of MFA appears to be how cybercriminals allegedly obtained huge amounts of data from some of Snowflake\u2019s customers, some of which set up their environments without the additional security measure.\u00a0<\/p>\n Snowflake conceded that one of its own \u201cdemo\u201d accounts was compromised because it wasn\u2019t protected beyond a username and password, but claimed the account \u201cdid not contain sensitive data.\u201d It\u2019s unclear if this stolen demo account has any role in the recent breaches.\u00a0<\/p>\n TechCrunch has this week seen hundreds of alleged Snowflake customer credentials that are available online for cybercriminals to use as part of hacking campaigns, suggesting that the risk of Snowflake customer account compromises may be far wider than first known.\u00a0<\/p>\n The credentials were stolen by infostealing malware that infected the computers of employees who have access to their employer\u2019s Snowflake environment.<\/p>\n Some of the credentials seen by TechCrunch appear to belong to employees at companies known to be Snowflake customers, including Ticketmaster and Santander, among others. The employees with Snowflake access include database engineers and data analysts, some of whom reference their experience using Snowflake on their LinkedIn pages.<\/p>\n For its part, Snowflake has told customers to immediately switch on MFA for their accounts. Until then, Snowflake accounts that aren\u2019t enforcing the use of MFA to log in are putting their stored data at risk of compromise from simple attacks like password theft and reuse.\u00a0<\/p>\n A source with knowledge of cybercriminal operations pointed TechCrunch to a website where would-be attackers can search through lists of credentials that have been stolen from various sources, such as infostealing malware on someone\u2019s computer or collated from previous data breaches. (TechCrunch is not linking to the site where stolen credentials are available so as not to aid bad actors.)<\/p>\n In all, TechCrunch has seen more than 500 credentials containing employee usernames and passwords, along with the web addresses of the login pages for the corresponding Snowflake environments.\u00a0<\/p>\n The exposed credentials appear to pertain to Snowflake environments belonging to Santander, Ticketmaster, at least two pharmaceutical giants, a food delivery service, a public-run freshwater supplier, and others. We have also seen exposed usernames and passwords allegedly belonging to a former Snowflake employee.\u00a0<\/p>\n TechCrunch is not naming the former employee because there\u2019s no evidence they did anything wrong. (It\u2019s ultimately both the responsibility of Snowflake and its customers to implement and enforce security policies that prevent intrusions that result from the theft of employee credentials.)\u00a0<\/p>\n We did not test the stolen usernames and passwords as doing so would break the law. As such, it\u2019s unknown if the credentials are currently in active use or if they directly led to account compromises or data thefts. Instead, we worked to verify the authenticity of the exposed credentials in other ways. This includes checking the individual login pages of the Snowflake environments that were exposed by the infostealing malware, which were still active and online at the time of writing.<\/p>\n The credentials we\u2019ve seen include the employee\u2019s email address (or username), their password, and the unique web address for logging in to their company\u2019s Snowflake environment. When we checked the web addresses of the Snowflake environments \u2014 often made up of random letters and numbers \u2014 we found the listed Snowflake customer login pages are publicly accessible, even if not searchable online.<\/p>\n TechCrunch confirmed that the Snowflake environments correspond to the companies whose employees\u2019 logins were compromised. We were able to do this because each login page we checked had two separate options to sign in.<\/p>\n One way to login relies on Okta, a single sign-on provider that allows Snowflake users to sign in with their own company\u2019s corporate credentials using MFA. In our checks, we found that these Snowflake login pages redirected to Live Nation (for Ticketmaster) and Santander sign-in pages. We also found a set of credentials belonging to a Snowflake employee, whose Okta login page still redirects to an internal Snowflake login page that no longer exists.<\/p>\n Snowflake\u2019s other login option allows the user to use only their Snowflake username and password, depending on whether the corporate customer enforces MFA on the account, as detailed by Snowflake\u2019s own support documentation<\/a>. It\u2019s these credentials that appear to have been stolen by the infostealing malware from the employees\u2019 computers.<\/p>\n It\u2019s not clear exactly when the employees\u2019 credentials were stolen or for how long they have been online.\u00a0<\/p>\n There is some evidence to suggest that several employees with access to their company\u2019s Snowflake environments had their computers previously compromised by infostealing malware. According to a check on breach notification service Have I Been Pwned, several of the corporate email addresses used as usernames for accessing Snowflake environments were found in a recent data dump containing millions of stolen passwords<\/a> scraped from various Telegram channels used for sharing stolen passwords.<\/p>\n Snowflake spokesperson Danica Stanczak declined to answer specific questions from TechCrunch, including whether any of its customers\u2019 data was found in the Snowflake employee\u2019s demo account. In a statement, Snowflake said it is \u201csuspending certain user accounts where there are strong indicators of malicious activity.\u201d <\/p>\n Snowflake added: \u201cUnder Snowflake\u2019s shared responsibility model, customers are responsible for enforcing MFA with their users.\u201d The spokesperson said Snowflake was \u201cconsidering all options for MFA enablement, but we have not finalized any plans at this time.\u201d<\/p>\n When reached by email, Live Nation spokesperson Kaitlyn Henrich did not comment by press time.<\/p>\n Santander did not respond to a request for comment.<\/p>\n Snowflake\u2019s response so far leaves a lot of questions unanswered, and lays bare a raft of companies that are not reaping the benefits that MFA security provides.\u00a0<\/p>\n What is clear is that Snowflake bears at least some responsibility for not requiring its users to switch on the security feature, and is now bearing the brunt of that \u2014 along with its customers.<\/p>\n The data breach at Ticketmaster allegedly involves upwards of 560 million customer records, according to the cybercriminals advertising the data online. (Live Nation would not comment on how many customers are affected by the breach.) If proven, Ticketmaster would be the largest U.S. data breach of the year so far, and one of the biggest in recent history.<\/p>\n Snowflake is the latest company in a string of high-profile security incidents and sizable data breaches caused by the lack of MFA.\u00a0<\/p>\n Last year, cybercriminals scraped around 6.9 million customer records from 23andMe accounts<\/a> that weren\u2019t protected without MFA, prompting the genetic testing company \u2014 and its competitors<\/a> \u2014 to require users enable MFA by default<\/a> to prevent a repeat attack.<\/p>\n And earlier this year, the UnitedHealth-owned health tech giant Change Healthcare admitted hackers broke into its systems and stole huge amounts of sensitive health data<\/a> from a system not protected with MFA. The healthcare giant hasn\u2019t yet said how many individuals had their information compromised but said it is likely to affect a \u201csubstantial proportion of people in America.\u201d<\/p>\n Do you know more about the Snowflake account intrusions? Get in touch. To contact this reporter, get in touch on Signal and WhatsApp at +1 646-755-8849, or by email.<\/a> You can also send files and documents via SecureDrop<\/a>.<\/em><\/p>\n<\/div>\nHow we checked the data<\/h2>\n
Missing MFA resulted in huge breaches<\/h2>\n
\n