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

141–150 of 235 posts

Re: Hacker confirms access through infostealer infection [withdrawn]

#141

Post by Galanwe »

adovenmuehle wrote: post #133
Galanwe wrote: post #127

Earlier quoted context omitted.

I don't quite understand how Snowflake works. 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…

No, Snowflake runs it's own storage and compute (on either AWS, GCP, or Azure depending on what you pick).

So the customer data is actually stored on Snowflakes AWS accounts?

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?

Re: Hacker confirms access through infostealer infection [withdrawn]

#142

Post by p_l »

foobiekr wrote: post #80
hn_throwaway_99 wrote: post #65

Earlier quoted context omitted.

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

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.

Re: Hacker confirms access through infostealer infection [withdrawn]

#143

Post by wannacboatmovie »

bredren wrote: post #136
BlackjackCF wrote: post #95

Earlier quoted context omitted.

This was a really effective anti-ad for Hudson Rock.

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

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

Re: Hacker confirms access through infostealer infection [withdrawn]

#144

Post by vermilingua »

fragmede wrote: post #139
bbayles wrote: post #92

Earlier quoted context omitted.

It's also possible that the firm is being trolled by the "threat actor."

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?

You joke, but these threat actors live and die by their reputation. Either they’re being honest, or this is a one-off or exit.

Re: Hacker confirms access through infostealer infection [withdrawn]

#145

Post by hn_throwaway_99 »

fhoffa wrote: post #104

Hi, Felipe at Snowflake here. 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.

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.

So is that a correct understanding then?

Re: Hacker confirms access through infostealer infection [withdrawn]

#146

Post by weinzierl »

"To understand how the hack was carried out, the threat actor explains that 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."

I'm unfamiliar with ServiceNow and their website seems to be just marketing bable.

Can someone explain the role of ServiceNow in this scenario and why it important?

Re: Hacker confirms access through infostealer infection [withdrawn]

#147

Post by skybrian »

I don't know anything about Snowflake or enterprise sales, but I'm wondering how that sales process works. A sales representative sets up a demo account. Then what, they load it with real customer data, with the customer's cooperation?

It seems like if a potential customer screws this up then they are wrong, but also, sales might be wrong to encourage them to share their data insecurely, and a sales process that encourages insecure sharing of enterprise data by potential customers might be bad company policy.

Perhaps doing it right would be tricky when it requires educating the customer. And it might get in the way of sales.

Re: Hacker confirms access through infostealer infection [withdrawn]

#148

Post by tmpz22 »

zamalek wrote: post #119

> Okta Just how many pwns involve this keyword? Between Okta itself being pwned and it allowing stupid shit like ignoring expiry, I am strongly inclined to believe that rolling your own login system might be the strongest security posture these days. Last I heard, Okta doesn't use any form of FIDO internally: how completely and utterly worthless.

Okta is a single point of failure but its still probably way better then what the average developer will throw together under deadline.

Re: Hacker confirms access through infostealer infection [withdrawn]

#149

Post by redwood »

teej wrote: post #101
redwood wrote: post #56

It's unclear if it's customer metadata or real customer data data?

Santander claims: "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

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?

Re: Hacker confirms access through infostealer infection [withdrawn]

#150

Post by p0seidon »

bredren wrote: post #136
BlackjackCF wrote: post #95

Earlier quoted context omitted.

This was a really effective anti-ad for Hudson Rock.

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

> The entry seems written by someone lacking maturity.

Agree with that.

Post reply on HN