Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hacker confirms access through infostealer infection [withdrawn]

hudsonrock.com

Post reply on HN
Print view View original

61–70 of 235 posts

Re: Hacker confirms access through infostealer infection [withdrawn]

#61

Post by squigz »

WhackyIdeas wrote: post #47
proactivesvcs wrote: post #4

Earlier quoted context omitted.

BBC News report of a substantial hack of Santander bank; linked to Snowflake. https://www.bbc.co.uk/news/articles/c6ppv06e3n8o

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.

> 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.

Re: Hacker confirms access through infostealer infection [withdrawn]

#62

Post by flir »

deinonychus wrote: post #49
bbayles wrote: post #9

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.

That particular exchange is bizarre and cartoonish. I don’t know what to make of it. “should have bought protection from Hudson Rock could have saved them this one” “yes i agree it wouldve helped for sure”

[flagged]

Re: Hacker confirms access through infostealer infection [withdrawn]

#63

Post by rdtsc »

Snowflake says it's not their fault, it's customer's fault apparently:

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.

Re: Hacker confirms access through infostealer infection [withdrawn]

#64

Post by skilled »

itscrush wrote: post #60
chairmanwow1 wrote: post #41

Earlier quoted context omitted.

in that you trust them less?

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”

We should thread carefully on 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.

Re: Hacker confirms access through infostealer infection [withdrawn]

#65

Post by hn_throwaway_99 »

gregates wrote: post #25
skilled wrote: post #7

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. https://community.snowflake.com/s/question/0D5VI00000Emyl00…

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 w…

> 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.

Re: Hacker confirms access through infostealer infection [withdrawn]

#67

Post by ActionHank »

rdtsc wrote: post #63

Snowflake says it's not their fault, it's customer's fault apparently: 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 unrelate…

Or they had no idea and assumed that customers had a breach, so blamed them without doing a proper in-depth analysis.

The hacker alleges that they weren't even expiring refresh tokens, that is pretty huge if true, it's just a massive, glaring issue.

Re: Hacker confirms access through infostealer infection [withdrawn]

#68

Post by WhackyIdeas »

dralley wrote: post #57
WhackyIdeas wrote: post #51

Earlier quoted context omitted.

I agree. Every single security thing that happens is put on Russia. 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.

>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. See for example: https://www.wired.com/story/notpetya-cyberattack-ukraine-rus... >If we were pre-Ukraine, it’d be China getting all the blam…

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.

Re: Hacker confirms access through infostealer infection [withdrawn]

#69

Post by coredog64 »

i_k_k wrote: post #12
abadpoli wrote: post #5

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”.

There’s something missing here. 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…

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.

Post reply on HN