That's what the article implies, but I think it's overblown. They provide enough information (unfortunately) to identify the employee whose credentials were stolen, and she's a Sales Engineer. The data seems to have come from her own Snowflake account, which was used to build demos for customers or prospective customers. It's quite possible that those customers granted her access to some of their actual data, which was used in those demos, but it's a far cry from unfettered access to the customer's Snowflake database itself. It's also quite possible that the hacker exfiltrated fake-but-realistic data used for demo purposes and doesn't know the difference.

> They provide enough information (unfortunately) to identify the employee whose credentials were stolen, and she's a Sales Engineer.

I'm not previously familiar with Hudson Rock, nor how "standard" disclosures around this work, but identifying the breached employee felt like an extremely shitty move to me. If a single infected laptop of a sales engineer (i.e. not even an admin with extensive access rights) resulted in a breach this large, the root cause problem is not the sales engineer - and I'd note that Hudson Rock says as much in their article.

But don't you see, we fired the problem so no more worries!

Oh, what's that. How did we change our hiring process to avoid hiring a problem again?

Sorry, my phones buzzing and I need to go.

--

Although obviously yes the problem isn't with hiring, it's with the system where a what should be fairly untrusted device shouldn't be able to exfiltrate a ton of data without setting a flag off somewhere.

The problem isn't the employee or the hiring process. It's the security infrastructure! One compromised account, supposedly from sales, shouldn't bring down the whole company.

Exactly, how is an SE privileged enough to cause a problem? Or for the activities to go unnoticed?

Like I would be very humiliated to have a system under my care that had this problem.

By customer giving their account permission to access customer's dataset.

The prospective customer copies their data to Snowflake so Snowflake can demonstrate their awesomeness with the customer data.

This is the problem of Hudson Rock making conjecture or trying to be authoritative when tbey don't know the process.

One SE is working on many accounts. Snowflake SEs don't build within the client environment typically. They set up a demo account like you or I do with the $400 in credits. SEs are constantly starting these. Why? They expire after the fact. The SE builds in the created demo account and shows the client. After 30 days Snowflake locks the account (no credit card) and subsequently drops the demo instance and data.

For an SE to do the work the customer can do one or more of the following: The customer's SF instance shares data to that demo instance created by the SE AND/OR the customer has given access to that Snowflake SE through SSO.

Either way, this is more of orgs not being restrictive in their security posture. There is nothing novel about this exploit other than they found an SE who was working very hard and clients who had not properly scoped the security permissions of an employee/contractoe/guest.

In my experience with Snowflake support about a year ago, an administrator of the customer's account had to explicitly grant access to Snowflake in order for the Snowflake team to see or do anything -- and if I recall correctly the access had an expiry.

That’s if they were following procedure. But on these internal systems, there are often hacks around the procedure that folks with the right mindset can easily find.

If the threat actor has played it right, there is a high possibility that this will be the largest data breach in history.

There's no evidence of that at all. The screenshot shows a few Snowflake professional services demo accounts only. These are accounts used by the sales engineer to demo features to customers.

It's possible the attacker was able to deduce some information about certain customers, but they would not then be able to connect to those accounts to extract data as those accounts should not be accessible from the public Internet at all, and should require corporate authentication.

So the account was without 2FA protection?

...All with just one successful malware-as-a-service attack against the right employee. (Lumma was the malware-as-a-service used.)

Interestingly, there's another adjacent story on the frontpage about Pegasus being used against NGOs in Eastern Europe. The principle of least authority is important, but also device security is important!

https://news.ycombinator.com/item?id=40535912

yeah, the perpetrator is wrong: nothing in production was accessed, no customer data either. totally being mischaracterized in the hudson post.