People in ex-USSR also speak/write Russian, so while I have no doubt Russians frequent the forum, lots of others from their sphere of influence also visit that forum. Don't assume everyone on HN is a 5-eyes resident.
The screenshot shows the post in English. The website domain is Indian. The seller contact xmpp.cn in China. But no, we'll keep blaming Russia for everything.
>I agree. Every single security thing that happens is put on Russia.
This is transparently false. Both Russia and China have copped blame for various recent attacks. And the fact of the matter is that Russian hackers are extremely active at the moment, and were even before 2022.
>If we were pre-Ukraine, it’d be China getting all the blame (like it used to be).
Russia was behind the Solarwinds hack, which is the most widely covered one in the past decade. Ironically the Chinese were also independently exploiting Solarwinds to break into government agencies, but that didn't get much attention.
When they don’t know who did something, they say Russia.
I suppose it makes sense to say that I live in the UK. Depending on where you are in the world, you may be hearing blame on Russia passed a lot less.
But in the UK, it is constant. It is tiresome.
Regarding how active Russian hackers are, I bet they are not any more active than GCHQ, NSA etc. they are all at it. God, even Israel will sell their Pegasus to any dictator who will pay them the money.
This article is claiming that the Ticketmaster breach from a few days ago was actually a much broader hack affecting 400+ companies, all through a Snowflake employee's stolen credentials. This seems like a pretty big story that's only being reported on hudsonrock.com now.
I haven't heard of Hudson Rock before, does anyone know if they are a reputable source?
Great, so these companies do not give a flying fuck about their customer data in making sure the data stored at cloud storage companies are end to end encrypted.
To think these random cloud storage companies can access your bank information is utterly shocking.
Not surprised at all. Doesn't even depend on cloud vendors - I'm thinking back to the 2023 MOVEit vulnerability which resulted in the release of a ton of customer info from banks' own internal infrastructure.
It’s been a while since I’ve been a Snowflake customer, but I do recall that Snowflake has a mode where the customer owns their own encryption key for their data. Snowflake employees (even admins with the highest access) have no access to the customer’s data unless the customer grants explicit access. It’d take a pretty serious breach on their compute notes to exfiltrate data.
> I haven't heard of Hudson Rock before, does anyone know if they are a reputable source?
I first learned of Hudson Rock after their "CEO" started spamming every security-related subreddit with low-effort blogspam over a period of months alleging numerous breaches. They've had several accounts banned, both by Reddit moderators and administrators.
Personally, I would no consider them a reputable or reliable source.
Why in the world would obtaining a Snowflake employee’s credentials allow you to then obtain Snowflake’s customers’ data? Doesn’t this imply that people working at Snowflake can see all of the data that I put in it?
Admittedly I don’t have much experience with Snowflake, but as a baseline I expect better from a “cloud storage giant”.
From what the Hudson Rock article shows, they were able to use an SE’s creds to access their demo account. This is not a customer account and shouldn’t (but of course could) contain sensitive info. It’s not clear to me how this snowballed into a larger breach.
Perhaps customers had granted this SE access to their accounts and the data within. Or perhaps there’s a deeper hack. But this isn’t clear to me from what I’ve read.
I was just going to post the same thing. The files that they show in the screenshots are things like PROGRESSIVE_BID_CHANGE_202405271129.csv. Looks suspiciously like the Snowflake Sales Engineer's data for their job role closing a deal with Progressive, not Progressive's own data. And there's no reason to think that a SE would have broad access to customer data. There may be some overlap, but I doubt it contains sensitive customer data owned by Progressive.
You’re thinking “bid” is in reference to Snowflake bidding for progressive as a client?
I’d say thats not likely, I work in fintech and the first thing this filename indicates to me is a CSV feed of market data for bid prices (https://en.m.wikipedia.org/wiki/Bid_price)
This is a common type of dataset a firm would dump into a datalake to use as reference data lookups against other more sensitive data (for pricing trades, etc.)
Something similar happened at a previous employer. Contractor was hired to do a big data PoC, and they managed to cajole access to a prod data dump for a more impactful demo.
They then managed to load all this PII data into an ElasticSearch instance that was open to the internet and was discovered by threat actors.
I wouldn’t be surprised to find that something similar happened here, where an unscrubbed prod dataset was shared for a better demo.
No, that sounds about right. This is a new, agile, cloud-first company that grew very quickly and has faced significant turnover. You don't get such growth by doing everything right.
Looking at linked-in, the unlucky employee could be someone in a sales role, with only 7 months of tenure. Every company has a few sysadmins with a scary amount of reach, but that's not what happened here.
Edit: A ServiceNow access request flow with poor internal controls would explain it.
(new) sales person with an uber account that has access to carte blanche customer data. This is not only a disaster, if true, but also violates probably every certification under the sun, if they had any at all. Reminder Snowflake is a couple of sales persons from Oracle and a techie.
I'm not sure it does, perhaps it violates the spirit but not the letter.
You need a way to give your employees access to customer data; for support cases.
So you build a "request access" form in your ITSM.
Now you can tick off every box related to certification: There is a process. Only authorized persons have access. Every aspect of it can be audited.
Later, perhaps sales people (the 1000's of new joiners) start using it as well for lead generation. It's a lot easier to sell if you know how your product is used by other companies in the same industry.
Much later, someone's account is compromised, makes the same requests and it gets waved through. Why wouldn't it ? It is a valid request made by a current employee of the company. What other criteria would apply ? This is not a bank.
Aside all things stated that are wrong from security perspective - how about limit the qty and rate any such support account has access to? Breaching an account shouldn't give you access to dump everything out the gate. Even if that is the case, where are other measures alerting there's a stream of egress going on? This sounds like systemic issue which most certs are all about.
>> This is a new, agile, cloud-first company that grew very quickly and has faced significant turnover.
This is not really true of Snowflake, which is not some 2-person YOLO startup, and it's also pretty irrelevant as the weakest link is often a single employee regardless of the size or industry of the company. In my experience the support and security is way better than average - example: as a client of both Snowflake and Sisense, Snowflake reached out to me about the Sisense breach before Sisense did.
Its support and security posture could very well be better than average.
Looking a other breaches (Qlik Attunity, Microsoft AAD, ...) indicates that being better then average is not enough if you're a sufficiently attractive target.
It's not a new tiny company. It's about 12 years old with 7000 employees. They know they are dead if they are not hot on security, so at the moment I would take this story with a big pinch of salt. Quite possible certain customer configurations have been attacked, but that is a different thing.
At least based on the wording of the perpetrator, Snowflake really did have the system designed in a way where a single administrator account gives you carte blanche to everything.
> On may 31st, Snowflake released a statement in which they claim that they are investigating an industry-wide identity-based attacks that have impacted “some” of their customers.
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.
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.
...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!
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.
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.
The screenshots of the chat logs are really something. This firm claims to be in communication with the actual criminal, and the actual criminal says that using their firm would have helped prevent the breach.
I have updated my sense of the firm's trustworthiness accordingly.
Absolutely the case for me. I don't give Snowflake much here, but Hudson Rock sells this exact type of "protection" and so far including BBC, no other independent verification?
This from the GP's link does it:
“should have bought protection from Hudson Rock could have saved them this one”
This is just pure speculation, but it kind of looks like the hacker was being ignored by Snowflake, so they somehow got in touch with Hudson Rock and offered them this promotional opportunity (to break the news, more than the throwaway line in the article) with the goal of retaliating against Snowflake for failing to pay the ransom. And Hudson Rock agreed to play along and hype up the story, presenting it as a bigger breach than it really was. One wonders whether Hudson Rock was the first they went to, or just the first to take them up on the offer.
Are you trying to say that the threat actor is just going up to firms they're trying to extort and telling them lies? Criminals just going around lying to people? Don't they know that's against the law?
It's a common euphemism in ransomware and protection rackets in general. One of my favourites is the message the akira group leaves in infected machines that goes something like:
Congratulations, you have passed a surprise information
security audit and become a victim of ransomware.
[...]
We offer:
1) full decryption assistance
2) evidence of data removal
3) security report on vulnerabilities we found
4) guarantees not to publish or sell your data
5) guarantees not to attack you in the future
They're just a security consulting company that you didn't know you had on payroll!
Btw I looked at what they provide as evidence of data removal (2) and it's literally just the stdout of `rm -vrf data` lol. I mean, I get that it's impossible to provide evidence of absence, plus the victims have no leverage anyway, but I dig the theatrics.
>We believe this is the result of ongoing industry-wide, identity-based attacks with the intent to obtain customer data. Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelated cyber threat activity. To date, we do not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product.
It sounds like they found a way to bypass MFA on snowflake (because snowflake didn’t expire session cookies), and stole an employees credential, obtained via a “Lumma-type Infostealer” which I guess is just a key logger in browser extensions and fake versions of software…
something doesn't add up, because I don't see how this extrapolates from stealing privileged Snowflake employee credentials. How does that become a keylogger on a client's computer?
"they were able to sign into a Snowflake employee’s ServiceNow account using stolen credentials, thus bypassing OKTA which is located on lift.snowflake.com.
Following the infiltration, the threat actor claims that they were able to generate session tokens, which enabled them to exfiltrate massive amounts of data from the company"
Yes, but how should ServiceNow create session tokens if it is not part of the SSO system? I don't know enough about ServiceNow, but I think every large company has some products that are not part of their-SSO system. So that makes sense, but I am not sure about the next step.
Protecting customer data from compromised insiders can be pretty hard. They often need the access to do their jobs. Still, in this case it's was far too easy - just one session cookie and a password shouldn't itself by sufficient to compromise all your customers.
> To put it bluntly, a single credential resulted in the exfiltration of potentially hundreds of companies that stored their data using Snowflake, with the threat actor himself suggesting 400 companies are impacted
"Following an investigation, we have now confirmed that certain information relating to customers of Santander Chile, Spain and Uruguay, as well as all current and some former Santander employees of the group had been accessed. Customer data in all other Santander markets and businesses are not affected."
But this does not mention Snowflake so it's on 100% clear it's the same root cause. And if it is the root cause being discussed elsewhere here namely that a customer engineer with partial data for demos... could that really have had access to this level of data?
> Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelated cyber threat activity. To date, we do not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product. Throughout the course of our ongoing investigation, we have promptly informed the limited number of customers who we believe may have been impacted.
They are way too wishy-washy:
* "Research indicates": Their own research or just general security research out there.
* "...do not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product": I think they know exactly how it happened. They enumerate all possible scenarios and methods it didn't happen: misconfiguration, vulnerability, malicious activity within the product. But skillfully skip the explanation for how it actually happened.
They were contacted by the bad actor if hudsonrock is to be believed, so they probably had a good idea how it happened.
* If Hudson Rock is to be believed, with the chat screenshot, Snowflake was notified and asked for a ransom. It would seem odd that all their 400 customers were all hacked randomly at the same time, by only one hacker group just based on those customers' own bad credentials
* They enumerate all the possible ways they were not hacked, and seems to skips the exact one way they were hacked. It's like saying: "It wasn't A, C, D, E, or F" as the causes. Hmm, they skipped B it seems, I wonder why...
1. The attacker quoted in the Hudson Rock article did breach the sales engineer's account as described.
2. The data in those accounts, however, was just demo data (Snowflake unambiguously says the compromised employee account did not have sensitive data) and it seems possible the attacker is overstating the impact of their specific breach.
3. I've seen no evidence elsewhere that "400 customers" of Snowflake were breached. So it at least seems plausible that just Ticketmaster and Santander had their accounts breached because their own employee creds were stolen and that gave access to their Snowflake data.
I definitely agree the Snowflake announcement had too much corporate speak but from my plain reading of it they are explicitly denying that their employee's stolen creds resulted in a breach of real PII.
Don’t they hint at how it happened in what you quoted?
> performed with our customers’ user credentials that were exposed through unrelated cyber threat activity
Unless they are just making this up, they seem to think that credentials were obtained elsewhere. They also say at the end that they told customers to review their account settings. So they are directing the blame away from themselves.
You’re right that this seems to conflict with Hudson Rock. Unfortunately our sources are the company that allegedly was hacked and a company that shamelessly doxed an employee in the course of using this event to promote their product. I think we’ll need to wait for more details.
> You’re right that this seems to conflict with Hudson Rock. Unfortunately our sources are the company that allegedly was hacked and a company that shamelessly doxed an employee in the course of using this event to promote their product. I think we’ll need to wait for more details.
Fair point. Doxing the employee is shitty, no doubt. Makes Hudson Rock look bad as well. But at the same time, I was giving them some credibility as it would seems if they completely fabricated the screenshots, they might as well file for bankruptcy, given the market they seem to operate in.
The article doesn't seem very consistent with the headline of "hundreds of breached customers"
1. The password for lift/okta is only allowing access to a servicenow portal and not customer accounts, so the refresh token issue seems restricted to the servicenow portal and unrelated to any actual customer data being exposed from customer Snowflake accounts
2. The screenshot with 10 corporate accounts compromised shows 4 different Snowflake account credentials (one of which appears to be a personal demo account) so that might explain up to 3 customers being compromised but there's no details showing other customers being compromised.
Assuming all of the SE's credentials were compromised for all of the customers they were working with, we can probably say the total customers compromised would be in the low double digits (each customer account would have had to provision access to the SE individually)
Big leap to say that literally the entirety of Snowflake's customer base is compromised from a "refresh token issue" (in the internal Okta portal) that isn't even linked to any customer Snowflake account
Without knowing exactly how the compromised account is set up, and what access is granted, it may be difficult to say. At "security focused large telecom" I am aware of, you would be surprised what level of tech has access to what (though of course all access is logged).
Snowflake internal staff do not have access to read customer data, unless a customer grants it. Customers can use their own KMS to generate table keys.
Snowflake has a lot of security features. But still, customers may well misconfigure their own Snowflake accounts and therefore be vulnerable.
A well configured Snowflake account:
- does not allow any access from the public Internet. Network policies set by the customer should restrict access to corporate networks only.
- does not allow authentication unless with MFA or via corporate IDP / SAML
- has dynamic masking / tokenisation
Snowflake seems to have most of the Fortune 500 as customers. If Snowflake itself was somehow penetrated and all controls circumvented, it would certainly be huge and you'd be reading about a lot more than Santander and Ticketmaster.
At this point it seems more like the "AWS Hack" that affected CapOne back in the day (that was CapOne's fault, not AWS!).
They don't have customer key access and can't assume customer identity but ultimately yes, via a multi-eye approval process there is access to the prod infra - but this is extremely tightly secured, and not something a phishing attack on a single sales engineer could ever achieve.
Many enterprise customers additionally use standard third party crypto libraries to tokenise and/or encrypt sensitive fields before storage in any warehouse/database such as Snowflake or Redshift.
This is a similar principle to using client-side encryption for S3. The infra provider (AWS in that case) can never read the data.
It is not standard operating procedure, and demos wouldn't be done with production data. In fact, most enterprises would have contracts in place with Snowflake that explictly state that Snowflake staff can not be granted access to their Snowflake accounts (this is actually the default in the Snowflake enterprise professional services contract now).
You can understand it: Snowflake lawyers are naturally reluctant to have their staff be granted access to any customer's accounts.
It is however quite common to have Snowflake PS guys have limited access to customer dev environments.
However, such access, even in dev, should always be network restricted.
I don't work for Snowflake but I spend a lot of time working with them and their SE organisation.
When working and building demos with clients, SEs create demonstration environments on the same $400 Snowflake demo accounts anyone can. To build demos the client would grant access to that SE. The SE would take some of the data to the demo environment and then work on it. This is further confirmed by the name of the environment Hudson Rock just published.
As far as I can tell, this is a process issue of clients not expiring an ID of someone who they were sharing data with and a threat actor swiping credentials. There is nothing novel about this as there is no exploit.
Also congrats Hudson Rock you just outed a person who was taken due to having malware on their computer. This is no different then if you gave a contractor credentials and they had those swiped. Dicks.
Generally, I like the page and the openness of the API behind it. It is much more common for people to talk about haveibeenpwned as a source for leaked credentials, but the site claims to have over 20 million computer entries from log stealers ... and every computer has XX password.. But yes probably this was written in a hurry to catch the wave?
The entry seems written by someone lacking maturity.
The candor in the screencap'd chat conversation is novel, and will probably drive clicks.
But in its unedited form serves as dirty laundry, and including the language from the threat actor is both unnecessary and inappropriate.
I can't tell if the threat actor agreeing HR would have potentially helped avert this problem is a good endorsement or not.
On one hand testimony from a threat of a product's effectiveness would be good, but on the other, this is a little up close and personal of an endorsement from someone actively ransoming so many companies and putting so much data at risk.
> But in its unedited form serves as dirty laundry, and including the language from the threat actor is both unnecessary and inappropriate.
A threat actor has intent to hold a company ransom for $20 million and your first reaction is to feign offense that the word 'retarded' appeared in a chat log? These are not charm school graduates.
The whole blog post reeks of extreme self-congratulation and youre right, a total scum move to expose the victim. Altogether very weak performance from Hudson Rock.
Just because there isn’t a “novel exploit” doesn’t mean this isn’t a big deal.
Snowflake is susceptible to their SE’s having credentials stolen. These credentials can bypass MFA. And per the article, they have no expiry. That’s strikes one, two, and three.
Snowflake’s security practices lead to a situation where their customers are either required, or at minimum encouraged, to share access to broad datasets with Snowflake employees. That’s strike four.
Yes, there is also issue here that the customers are responsible themselves for not granting too broad access, and that’s on them. But it’s also on Snowflake for not having a better system that doesn’t require this access, or at minimum not having better oversight and control over this transitive access.
Once these accounts are granted access to a customer’s data, they aren’t “demo accounts” anymore. They’re real accounts, with real, very valuable data, and they should be treated as such.
Edit to add: it is worth noting that Snowflake claims the demo account did not have access to customer data and wasn’t the source of the leak, which is in contradiction with what the attackers claim.
Yes, that's also what I think must have happened—missing 2FA. But it seems it's also not mandatory within Snowflake accounts also, from what I understand from the general message.
I've never used Snowflake and assumed that because you push all your data into it, it probably has 2FA enabled by default. Is it optional?
My understanding was that you had to grant storage access (e.g. S3) and compute access (e.g. EC2) from your account to Snowflake, which would then use said resources to perform queries that you issue from their hosted web UI.
In that case it would mean stealing the Snowflake demo account of a SE should not expose your data unless you forgot to revoke their access to your underlying resources.
At the snowflake size you get custom price lists from cloud operators.
But I think there was also support for peering with client VPCs (or equivalents) which is why they support AWS, Azure, and GCP - you choose the location that is most fitting for linking with your cloud/physical workloads.
> So the customer data is actually stored on Snowflakes AWS accounts?
Yes.
> Also does that mean every data query to snowflake goes out/in to/from internet at egress/Ingress costs?
Yes. It's covered comprehensively in their docs, along with the caveats.
> What difference does it make what underlying storage / provider it uses then?
"Snowflake does not charge data ingress fees. However, a cloud storage provider might charge a data egress fee for transferring data from the provider to your Snowflake account."
unsaid: "...and you have to pay for that".
Note that when they say 'your Snowflake account' they mean our cloud account which we own, and which we run our workloads in, which we refer to as 'your' snowflake account.
Tangibly speaking, what means is that if you want to check up your billing; you go through snowflake; you can't login to a cloud console and see the actual charges the cloud vendor is charging.
> What difference does it make what underlying storage / provider it uses then?
They pass the specific underlying cloud vendor costs on to you (with, I guess, some markup, though you have no way of know what that is :)
Snowflake usually unloads data to an internal stage bucket in the same region as your snowflake account. If you use an s3 gateway endpoint getting that data is free of egress charges.
This was the case in ~2019 but are you sure this is still true? I think you can “bring your own account” with Snowflake, but I’m honestly not certain because their docs aren’t exactly clear about it…
You can definitely bring your own storage (e.g. store your data in your own s3 buckets and integrate it with snowflake) using storage integrations and external tables.
Personally believe this is the right approach as the data resides in a location fully under the company's control. You could ditch snowflake and the data still resides in your s3 buckets for reuse with a another platform (just remove the iam permissions for snowflake).
Yes, federated queries (external tables) are supported but that is a lot slower than ingesting the data into Snowflake's storage and querying it. Since Snowflake's pricing model is based on computation time, querying external tables are usually more costly because of worse performance.
I always wondered why snowflake doesn't just install a control plane on customers own cloud resources a la databricks. Seems like they'd be able to mitigate a lot of liability that way.
Having spent a lot of time in the Snowflake ecosystem, a few things to understand.
Snowflake is both a platform and a database. Customers can implement any level of security within the system. For example, when Snowflake introduced OAuth functionality, they put a lot of pressure for us to implement it in our tool. We're small enough and they are a significant partner so we priortised and got it into our platform so that a customer CAN implement it if they want too.
The keyword here is CAN. As a platform with database functionality, Snowflake allows customers to implement any level of security for access. So each instance of Snowflake https://XX123456.us-east-1.snowflakecomputing.com/ security is independent. So let's answer some questions
* "Was this a production breach", No, this was not a production breach. This is not when hackers went into the Azure and were able to elevate credentials and see all accounts.
* "But doesn't Snowflake use MFA", yes and on INTERNAL systems and the ability to connect to the PROD environment of SF it would absolutely have that. However, every customer has the ability to configure a user's credentials for access in their instance https://XX123456.us-east-1.snowflakecomputing.com/. Likely, the SE was granted access to the client's instance through the use of a user name and password.
* "But why not use MFA then Snowflake", this comes back to Okta. You have to create a trust relationship between providers. That's easy when you are only talking about your own employees. They all sit in your same directory. However, to set up a separate trust relationship for another domain, well now we have to get the security team of the client involved. All this so that someone can take a little bit of data and move it into another environment in order to do a demonstration. Not likely.
* "Well that just sounds stupid, my application has SSO enabled." True, but as also a database - Snowflake has to account for entire ecosystem that don't even support SSO-OAuth. For example, two major products that do not support SSO connections to Snowflake: Azure Machine Learning and Zapier. Both only support user name / password connections to Snowflake. So if you were an SE trying to show the value of Snowflake and its integration with AzureML; the ONLY way you could do that would be through user name / password functionality.
The issue in all of this is we are so used to thinking of SaaS as just an application. Databases have to support all sorts of application weirdness. Here is my gut thought on how this went down.
* The SE was working with multiple clients. These clients in an effort to save time and not wanting to have their security team involved and try and create a trust relationship with Snowflake went ahead and created a user name and password for the SE into the client environment vs setting up SSO. Again, this is ONLY controlled by the client.
* The SE at some point had active access to multiple instances of Snowflake to their various clients; with various levels of access depending upon the skill and fastidiousness of the client when they created the account for the Snowflake SE into their account. Again, how the SE is connecting to Snowflake is the same way any other user and application are doing so. I know this for a fact as SEs have to create their own throwaway demo instances https://XX123456.us-east-1.snowflakecomputing.com/. SEs don't have access into the backend of Snowflake.
* At some point this SE had malware installed on to their computer. At this point, this person was cooked and any customer who had given them access to the environment.
Calling the SE a "victim" is debatable. If you work environment is infected with malware, you screwed up.
"Typically, Lumma has been distributed disguised as cracked or fake popular software like VLC or ChatGPT. Recently though, threat actors have also delivered the malware through emails containing payloads in the form of attachments or links impersonating well-known companies."
I would not be suprised if this was a recruiter-attack-vector.
I just had a quick read through a couple more posts on HR, and a lot of them end with something along the lines of "heh, should have bought protection from us", reeks like a racket.
This is the description of one of Hudson Rock's main products, "Bayonet".
"Imagine getting access to a lead-generation platform featuring hundreds of thousands of compromised companies around the world with active vulnerabilities that you can convert into customers."
I've seen and dealt with a couple of these types of companies. It's a pretty sleazy tactic, and it's low skill/effort from a technical point of view as well.
Doing some more digging, this is where the data is sourced
"Hudson Rock acquires and purchases compromised data directly from top-tier threat actors operating in closed circle hacking groups. What sets our data apart is its quality in providing high accessibility to hacker groups looking for potential targets, and the speed in which we make it available to clients compared to other threat intelligence companies.
Our operational knowhow, and our boots-on-the-ground approach to cybercrime originates from the IDF's 8200 Cybercrime division, and its efforts to thwart nation-state adversaries and professional threat actors."
Care to explain how a conflict between two national groups that are indigenous to the same land is similar to a racial system of segregation including beaches and restrooms, based on race theory with different racial classifications?
Or are you using a word that describes something different just because it evokes negative emotions?
That screenshot where the attacker agrees that buying their services would help makes me have a very strong suspicion this attack is either faked, sponsored by or in some way Hudson Rock is in cahoots with the attackers. That screenshot is a pure 100% advertisement manufactured by Hudson Rock one way or another.
As they usually say.. I'd check whoever is running Hudson Rock's hard drive.
assuming seeing “dicks” upset you, and you think “cunts” would upset someone else, this seems less like equality and more like an attempt at hurting others due to hurt.
The salesforce.com servers are temporarily unable to respond to your request. We apologize for the inconvenience.
Thank you for your patience, and please try again in a few moments.
The OP Hudson Rock writes something that I understand is saying: This was more than a breach of one customer's credentials, they got some employee creds and they weren't protected by 2 factor so they got into other customer accounts using that engineer's creds.
The snowflake writeup reads to me as if a customer's account creds got compromised - and it implied to me that was the end of it, no central or other account access on thoes creds. Nothing about this use of some employee account info that didn't have 2 factor auth on it.
1. I'm sure snowflake wants all access creds of any kind for their internal employees to use 2fa.
2. It used to be at least as a customer you could create a name/password without 2fa to log in to your own info there if you wanted to, like say as a customer you create a db or table and want to access it.
So, just to be clear because I found your link filled with a bit too much corporate speak:
1. The linked Hudson Rock post is explicitly claiming that the breaches at Ticketmaster and Santander Bank were caused by a Snowflake employee whose credentials were compromised.
2. This bullet point, "We did find evidence that similar to impacted customer accounts, the threat actor obtained personal credentials to and accessed a demo account owned by a former Snowflake employee. It did not contain sensitive data." (emphasis mine) says pretty clearly to me, then, that Snowflake believes the Hudson Rock account to be false.
Wow that's what i call a anti-ad for Hudson-Rock, should have bought services from a public relation firm...yes i agree, it would have helped for sure.
234 comments
[ 1.3 ms ] story [ 262 ms ] threadJust russia being russia, as usual.
Typical propaganda.
If we were pre-Ukraine, it’d be China getting all the blame (like it used to be).
I’m not pro-Russia, I’m just anti-bullshit.
This is transparently false. Both Russia and China have copped blame for various recent attacks. And the fact of the matter is that Russian hackers are extremely active at the moment, and were even before 2022.
See for example: https://www.wired.com/story/notpetya-cyberattack-ukraine-rus...
>If we were pre-Ukraine, it’d be China getting all the blame (like it used to be).
Russia was behind the Solarwinds hack, which is the most widely covered one in the past decade. Ironically the Chinese were also independently exploiting Solarwinds to break into government agencies, but that didn't get much attention.
I suppose it makes sense to say that I live in the UK. Depending on where you are in the world, you may be hearing blame on Russia passed a lot less.
But in the UK, it is constant. It is tiresome.
Regarding how active Russian hackers are, I bet they are not any more active than GCHQ, NSA etc. they are all at it. God, even Israel will sell their Pegasus to any dictator who will pay them the money.
I haven't heard of Hudson Rock before, does anyone know if they are a reputable source?
To think these random cloud storage companies can access your bank information is utterly shocking.
Honestly this sort of thing shouldn't be shocking at all.
https://docs.snowflake.com/en/user-guide/security-encryption...
I first learned of Hudson Rock after their "CEO" started spamming every security-related subreddit with low-effort blogspam over a period of months alleging numerous breaches. They've had several accounts banned, both by Reddit moderators and administrators.
Personally, I would no consider them a reputable or reliable source.
Admittedly I don’t have much experience with Snowflake, but as a baseline I expect better from a “cloud storage giant”.
From what the Hudson Rock article shows, they were able to use an SE’s creds to access their demo account. This is not a customer account and shouldn’t (but of course could) contain sensitive info. It’s not clear to me how this snowballed into a larger breach.
Perhaps customers had granted this SE access to their accounts and the data within. Or perhaps there’s a deeper hack. But this isn’t clear to me from what I’ve read.
I’d say thats not likely, I work in fintech and the first thing this filename indicates to me is a CSV feed of market data for bid prices (https://en.m.wikipedia.org/wiki/Bid_price)
This is a common type of dataset a firm would dump into a datalake to use as reference data lookups against other more sensitive data (for pricing trades, etc.)
They then managed to load all this PII data into an ElasticSearch instance that was open to the internet and was discovered by threat actors.
I wouldn’t be surprised to find that something similar happened here, where an unscrubbed prod dataset was shared for a better demo.
Looking at linked-in, the unlucky employee could be someone in a sales role, with only 7 months of tenure. Every company has a few sysadmins with a scary amount of reach, but that's not what happened here.
Edit: A ServiceNow access request flow with poor internal controls would explain it.
You need a way to give your employees access to customer data; for support cases. So you build a "request access" form in your ITSM. Now you can tick off every box related to certification: There is a process. Only authorized persons have access. Every aspect of it can be audited.
Later, perhaps sales people (the 1000's of new joiners) start using it as well for lead generation. It's a lot easier to sell if you know how your product is used by other companies in the same industry.
Much later, someone's account is compromised, makes the same requests and it gets waved through. Why wouldn't it ? It is a valid request made by a current employee of the company. What other criteria would apply ? This is not a bank.
Many companies have processes that require 2 or more humans in the loop for sensitive prod data.
This is not really true of Snowflake, which is not some 2-person YOLO startup, and it's also pretty irrelevant as the weakest link is often a single employee regardless of the size or industry of the company. In my experience the support and security is way better than average - example: as a client of both Snowflake and Sisense, Snowflake reached out to me about the Sisense breach before Sisense did.
> On may 31st, Snowflake released a statement in which they claim that they are investigating an industry-wide identity-based attacks that have impacted “some” of their customers.
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
This gives credibility to both Ticketmaster and Santander stories.
Wow! Could be one of the biggest dumps of all time if the threat actors did everything correctly?
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.
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
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.
Like I would be very humiliated to have a system under my care that had this problem.
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.
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.
I have updated my sense of the firm's trustworthiness accordingly.
This from the GP's link does it: “should have bought protection from Hudson Rock could have saved them this one”
It might be that they genuinely geeked out.
Hudson reputation would forever be scarred (badly) if they tried to manipulate the narrative.
Going down this hole also means we discredit the perpetrator, even if he did specifically reach out to Hudson.
Just wanted to say this so we don’t immediately jump to conclusions.
“should have bought protection from Hudson Rock could have saved them this one”
“yes i agree it wouldve helped for sure”
Btw I looked at what they provide as evidence of data removal (2) and it's literally just the stdout of `rm -vrf data` lol. I mean, I get that it's impossible to provide evidence of absence, plus the victims have no leverage anyway, but I dig the theatrics.
If it's somehow real, omitting the hudsonrock message would be good sense.
I have mentally black listed this company.
> Snowflake’s single platform eliminates data silos
I guess so, especially now.
>We believe this is the result of ongoing industry-wide, identity-based attacks with the intent to obtain customer data. Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelated cyber threat activity. To date, we do not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product.
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
1. Employee installs a key logger
2. Snowflake does not expire session cookies
3. Malware steals their session cookie and password, so can bypass employee MFA/okta
4. ???
5. Somehow this one employee has admin access to 4000 snowflake instances
"they were able to sign into a Snowflake employee’s ServiceNow account using stolen credentials, thus bypassing OKTA which is located on lift.snowflake.com.
Following the infiltration, the threat actor claims that they were able to generate session tokens, which enabled them to exfiltrate massive amounts of data from the company"
You only have to "fail" once, as they say.-
"Following an investigation, we have now confirmed that certain information relating to customers of Santander Chile, Spain and Uruguay, as well as all current and some former Santander employees of the group had been accessed. Customer data in all other Santander markets and businesses are not affected."
https://www.santander.com/en/stories/statement
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
If https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... has not completely fabricated the story, Snowflake are tiny bit less than truthful.
> Research indicates that these types of attacks are performed with our customers’ user credentials that were exposed through unrelated cyber threat activity. To date, we do not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product. Throughout the course of our ongoing investigation, we have promptly informed the limited number of customers who we believe may have been impacted.
They are way too wishy-washy:
* "Research indicates": Their own research or just general security research out there.
* "...do not believe this activity is caused by any vulnerability, misconfiguration, or malicious activity within the Snowflake product": I think they know exactly how it happened. They enumerate all possible scenarios and methods it didn't happen: misconfiguration, vulnerability, malicious activity within the product. But skillfully skip the explanation for how it actually happened.
They were contacted by the bad actor if hudsonrock is to be believed, so they probably had a good idea how it happened.
The hacker alleges that they weren't even expiring refresh tokens, that is pretty huge if true, it's just a massive, glaring issue.
* If Hudson Rock is to be believed, with the chat screenshot, Snowflake was notified and asked for a ransom. It would seem odd that all their 400 customers were all hacked randomly at the same time, by only one hacker group just based on those customers' own bad credentials
* They enumerate all the possible ways they were not hacked, and seems to skips the exact one way they were hacked. It's like saying: "It wasn't A, C, D, E, or F" as the causes. Hmm, they skipped B it seems, I wonder why...
1. The attacker quoted in the Hudson Rock article did breach the sales engineer's account as described.
2. The data in those accounts, however, was just demo data (Snowflake unambiguously says the compromised employee account did not have sensitive data) and it seems possible the attacker is overstating the impact of their specific breach.
3. I've seen no evidence elsewhere that "400 customers" of Snowflake were breached. So it at least seems plausible that just Ticketmaster and Santander had their accounts breached because their own employee creds were stolen and that gave access to their Snowflake data.
I definitely agree the Snowflake announcement had too much corporate speak but from my plain reading of it they are explicitly denying that their employee's stolen creds resulted in a breach of real PII.
> performed with our customers’ user credentials that were exposed through unrelated cyber threat activity
Unless they are just making this up, they seem to think that credentials were obtained elsewhere. They also say at the end that they told customers to review their account settings. So they are directing the blame away from themselves.
You’re right that this seems to conflict with Hudson Rock. Unfortunately our sources are the company that allegedly was hacked and a company that shamelessly doxed an employee in the course of using this event to promote their product. I think we’ll need to wait for more details.
Fair point. Doxing the employee is shitty, no doubt. Makes Hudson Rock look bad as well. But at the same time, I was giving them some credibility as it would seems if they completely fabricated the screenshots, they might as well file for bankruptcy, given the market they seem to operate in.
I wrote a better version here: https://gist.github.com/titan-teej/924dcb42604a98b90d6419262...
TL;DR they don't check for users who can transitively gain admin access.
1. The password for lift/okta is only allowing access to a servicenow portal and not customer accounts, so the refresh token issue seems restricted to the servicenow portal and unrelated to any actual customer data being exposed from customer Snowflake accounts
2. The screenshot with 10 corporate accounts compromised shows 4 different Snowflake account credentials (one of which appears to be a personal demo account) so that might explain up to 3 customers being compromised but there's no details showing other customers being compromised.
Assuming all of the SE's credentials were compromised for all of the customers they were working with, we can probably say the total customers compromised would be in the low double digits (each customer account would have had to provision access to the SE individually)
Big leap to say that literally the entirety of Snowflake's customer base is compromised from a "refresh token issue" (in the internal Okta portal) that isn't even linked to any customer Snowflake account
Snowflake has a lot of security features. But still, customers may well misconfigure their own Snowflake accounts and therefore be vulnerable.
A well configured Snowflake account:
- does not allow any access from the public Internet. Network policies set by the customer should restrict access to corporate networks only. - does not allow authentication unless with MFA or via corporate IDP / SAML - has dynamic masking / tokenisation
Snowflake seems to have most of the Fortune 500 as customers. If Snowflake itself was somehow penetrated and all controls circumvented, it would certainly be huge and you'd be reading about a lot more than Santander and Ticketmaster.
At this point it seems more like the "AWS Hack" that affected CapOne back in the day (that was CapOne's fault, not AWS!).
Do engineers in Snowflake have access to production systems?
Many enterprise customers additionally use standard third party crypto libraries to tokenise and/or encrypt sensitive fields before storage in any warehouse/database such as Snowflake or Redshift.
This is a similar principle to using client-side encryption for S3. The infra provider (AWS in that case) can never read the data.
By default, no. But it is standard operating procedure for sales engineers to request and be given access to customer data so they can build demos.
You can understand it: Snowflake lawyers are naturally reluctant to have their staff be granted access to any customer's accounts.
It is however quite common to have Snowflake PS guys have limited access to customer dev environments.
However, such access, even in dev, should always be network restricted.
When working and building demos with clients, SEs create demonstration environments on the same $400 Snowflake demo accounts anyone can. To build demos the client would grant access to that SE. The SE would take some of the data to the demo environment and then work on it. This is further confirmed by the name of the environment Hudson Rock just published.
As far as I can tell, this is a process issue of clients not expiring an ID of someone who they were sharing data with and a threat actor swiping credentials. There is nothing novel about this as there is no exploit.
Also congrats Hudson Rock you just outed a person who was taken due to having malware on their computer. This is no different then if you gave a contractor credentials and they had those swiped. Dicks.
The candor in the screencap'd chat conversation is novel, and will probably drive clicks.
But in its unedited form serves as dirty laundry, and including the language from the threat actor is both unnecessary and inappropriate.
I can't tell if the threat actor agreeing HR would have potentially helped avert this problem is a good endorsement or not.
On one hand testimony from a threat of a product's effectiveness would be good, but on the other, this is a little up close and personal of an endorsement from someone actively ransoming so many companies and putting so much data at risk.
A threat actor has intent to hold a company ransom for $20 million and your first reaction is to feign offense that the word 'retarded' appeared in a chat log? These are not charm school graduates.
Agree with that.
Snowflake is susceptible to their SE’s having credentials stolen. These credentials can bypass MFA. And per the article, they have no expiry. That’s strikes one, two, and three.
Snowflake’s security practices lead to a situation where their customers are either required, or at minimum encouraged, to share access to broad datasets with Snowflake employees. That’s strike four.
Yes, there is also issue here that the customers are responsible themselves for not granting too broad access, and that’s on them. But it’s also on Snowflake for not having a better system that doesn’t require this access, or at minimum not having better oversight and control over this transitive access.
Once these accounts are granted access to a customer’s data, they aren’t “demo accounts” anymore. They’re real accounts, with real, very valuable data, and they should be treated as such.
Edit to add: it is worth noting that Snowflake claims the demo account did not have access to customer data and wasn’t the source of the leak, which is in contradiction with what the attackers claim.
Data stolen because of some crazy multi-exploit zero day chain. Well that is understandable, i don't blame the company.
Data stolen because no 2FA support? In 2024 that is just embarassing.
I've never used Snowflake and assumed that because you push all your data into it, it probably has 2FA enabled by default. Is it optional?
My understanding was that you had to grant storage access (e.g. S3) and compute access (e.g. EC2) from your account to Snowflake, which would then use said resources to perform queries that you issue from their hosted web UI.
In that case it would mean stealing the Snowflake demo account of a SE should not expose your data unless you forgot to revoke their access to your underlying resources.
Can someone explain if that is how it works?
What difference does it make what underlying storage / provider it uses then?
Also does that mean every data query to snowflake goes out/in to/from internet at egress/Ingress costs?
But I think there was also support for peering with client VPCs (or equivalents) which is why they support AWS, Azure, and GCP - you choose the location that is most fitting for linking with your cloud/physical workloads.
Yes.
> Also does that mean every data query to snowflake goes out/in to/from internet at egress/Ingress costs?
Yes. It's covered comprehensively in their docs, along with the caveats.
> What difference does it make what underlying storage / provider it uses then?
"Snowflake does not charge data ingress fees. However, a cloud storage provider might charge a data egress fee for transferring data from the provider to your Snowflake account."
unsaid: "...and you have to pay for that".
Note that when they say 'your Snowflake account' they mean our cloud account which we own, and which we run our workloads in, which we refer to as 'your' snowflake account.
Tangibly speaking, what means is that if you want to check up your billing; you go through snowflake; you can't login to a cloud console and see the actual charges the cloud vendor is charging.
> What difference does it make what underlying storage / provider it uses then?
They pass the specific underlying cloud vendor costs on to you (with, I guess, some markup, though you have no way of know what that is :)
Snowflake compute instance types cost about $.30-.40 an hour on EC2, so it's quite a markup.
As far as security I do believe they allow the customers to set their own storage keys, so there may be some isolation from a global breach.
See https://docs.snowflake.com/en/user-guide/data-load-s3-config...
Personally believe this is the right approach as the data resides in a location fully under the company's control. You could ditch snowflake and the data still resides in your s3 buckets for reuse with a another platform (just remove the iam permissions for snowflake).
For various reasons, you're not getting to touch the actual DB bits.
You can, IIRC, use snowflake-hosted connectors to access external data though.
And there's a "data marketplace" of sorts where clients can publish/consume datasets.
Snowflake is both a platform and a database. Customers can implement any level of security within the system. For example, when Snowflake introduced OAuth functionality, they put a lot of pressure for us to implement it in our tool. We're small enough and they are a significant partner so we priortised and got it into our platform so that a customer CAN implement it if they want too.
The keyword here is CAN. As a platform with database functionality, Snowflake allows customers to implement any level of security for access. So each instance of Snowflake https://XX123456.us-east-1.snowflakecomputing.com/ security is independent. So let's answer some questions
* "Was this a production breach", No, this was not a production breach. This is not when hackers went into the Azure and were able to elevate credentials and see all accounts.
* "But doesn't Snowflake use MFA", yes and on INTERNAL systems and the ability to connect to the PROD environment of SF it would absolutely have that. However, every customer has the ability to configure a user's credentials for access in their instance https://XX123456.us-east-1.snowflakecomputing.com/. Likely, the SE was granted access to the client's instance through the use of a user name and password.
* "But why not use MFA then Snowflake", this comes back to Okta. You have to create a trust relationship between providers. That's easy when you are only talking about your own employees. They all sit in your same directory. However, to set up a separate trust relationship for another domain, well now we have to get the security team of the client involved. All this so that someone can take a little bit of data and move it into another environment in order to do a demonstration. Not likely.
* "Well that just sounds stupid, my application has SSO enabled." True, but as also a database - Snowflake has to account for entire ecosystem that don't even support SSO-OAuth. For example, two major products that do not support SSO connections to Snowflake: Azure Machine Learning and Zapier. Both only support user name / password connections to Snowflake. So if you were an SE trying to show the value of Snowflake and its integration with AzureML; the ONLY way you could do that would be through user name / password functionality.
The issue in all of this is we are so used to thinking of SaaS as just an application. Databases have to support all sorts of application weirdness. Here is my gut thought on how this went down.
* The SE was working with multiple clients. These clients in an effort to save time and not wanting to have their security team involved and try and create a trust relationship with Snowflake went ahead and created a user name and password for the SE into the client environment vs setting up SSO. Again, this is ONLY controlled by the client.
* The SE at some point had active access to multiple instances of Snowflake to their various clients; with various levels of access depending upon the skill and fastidiousness of the client when they created the account for the Snowflake SE into their account. Again, how the SE is connecting to Snowflake is the same way any other user and application are doing so. I know this for a fact as SEs have to create their own throwaway demo instances https://XX123456.us-east-1.snowflakecomputing.com/. SEs don't have access into the backend of Snowflake.
* At some point this SE had malware installed on to their computer. At this point, this person was cooked and any customer who had given them access to the environment.
As for Hudson Rocks, th...
Calling the SE a "victim" is debatable. If you work environment is infected with malware, you screwed up.
"Typically, Lumma has been distributed disguised as cracked or fake popular software like VLC or ChatGPT. Recently though, threat actors have also delivered the malware through emails containing payloads in the form of attachments or links impersonating well-known companies."
I would not be suprised if this was a recruiter-attack-vector.
"Imagine getting access to a lead-generation platform featuring hundreds of thousands of compromised companies around the world with active vulnerabilities that you can convert into customers."
I've seen and dealt with a couple of these types of companies. It's a pretty sleazy tactic, and it's low skill/effort from a technical point of view as well.
"Hudson Rock acquires and purchases compromised data directly from top-tier threat actors operating in closed circle hacking groups. What sets our data apart is its quality in providing high accessibility to hacker groups looking for potential targets, and the speed in which we make it available to clients compared to other threat intelligence companies. Our operational knowhow, and our boots-on-the-ground approach to cybercrime originates from the IDF's 8200 Cybercrime division, and its efforts to thwart nation-state adversaries and professional threat actors."
https://cavalier.hudsonrock.com/docs
This would imply that they are financially engaging with and supporting cyber criminals.
Or are you using a word that describes something different just because it evokes negative emotions?
* Checkpoint
* Palo Alto Networks
* Waze
* Wiz
* Cybereason
Does your theory hold up? no, but why not generalize
As they usually say.. I'd check whoever is running Hudson Rock's hard drive.
or are you truly glad?
You started it?
you used the word for attention.
you got it.
buyer’s remorse?
Here is the latest from Snowflake on this issue: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
We'll keep updating that URL with any further news.
The snowflake writeup reads to me as if a customer's account creds got compromised - and it implied to me that was the end of it, no central or other account access on thoes creds. Nothing about this use of some employee account info that didn't have 2 factor auth on it.
1. I'm sure snowflake wants all access creds of any kind for their internal employees to use 2fa.
2. It used to be at least as a customer you could create a name/password without 2fa to log in to your own info there if you wanted to, like say as a customer you create a db or table and want to access it.
1. The linked Hudson Rock post is explicitly claiming that the breaches at Ticketmaster and Santander Bank were caused by a Snowflake employee whose credentials were compromised.
2. This bullet point, "We did find evidence that similar to impacted customer accounts, the threat actor obtained personal credentials to and accessed a demo account owned by a former Snowflake employee. It did not contain sensitive data." (emphasis mine) says pretty clearly to me, then, that Snowflake believes the Hudson Rock account to be false.
So is that a correct understanding then?
Are theirs HQ located in Hollywood?