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

Updated Okta Statement on Lapsus$

okta.com

Post reply on HN
Print view View original

181–190 of 239 posts

Re: Updated Okta Statement on Lapsus$

#181

Post by mimikatz »

jeremyjh wrote: post #121
mimikatz wrote: post #8

I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is cons…

It is really clever wording, but it is possible for the statements to be true, while being deliberately misleading. What they initially detected, and what the 3rd-party investigation found, were two different things. Okta initially "detected an unsuccessful attempt" - the successful attempts were not detected initially but the detected event did lead to an investigation. Now, JUST this week (presumably, in the last 7…

Thanks, I get it now.

Re: Updated Okta Statement on Lapsus$

#182

Post by Closi »

haswell wrote: post #107
jclulow wrote: post #94

Earlier quoted context omitted.

If through compromising those workers outside parties gain access to sensitive systems, and that situation is not promptly detected and corrected, then the system _is_ compromised. Okta is not just a bunch of software, it's also staff and processes, and the result is a trusted service they provide to customers. If that service is compromised, it doesn't really seem to matter how?

> If that service is compromised, it doesn't really seem to matter how? I hear what you're saying, but the how does really matter, and will change how customers perceive the issue and make decisions about how to react. e.g. "databases were open to the Internet and all data has been siphoned" lands quite differently than "a staff member abused their privileges but the scope of abuse was limited to xyz". If I'm a custo…

How it happened doesn't change the fact that they have been breached.

If I was a bank and claimed that I haven't been robbed, an insider just transferred billions of pounds out of the bank and then fled, I think everyone would rightly say "What are you talking about, you have been robbed!"

It doesn't matter if it was done by a guy in a black and white stripey t-shirt, or if it was done by a rogue internal employee, a bank robbery is a bank robbery.

In fact, the ability of an internal staff member to transfer lots of money out of the bank probably signifies a more significant and systemic issue - particularly if i've lost my money and the bank refuses to acknowledge they have been breached/robbed (it was just an internal rogue staff member, not a robbery! our security hasn't been breached!).

A bit of a stretched analogy - but i'm sure everyone gets the point. Security isn't just about technical security - it's the whole process involved in making sure these things don't happen. A banks 'technical' security might be great, but the bank would still be considered horribly insecure if a staff member can transfer any money out of an account. Equally an auth service might be 'technically' secure, but the ability of a single rogue staff member to impose a lot of damage suggests more systemic issues.

Re: Updated Okta Statement on Lapsus$

#183

Post by winrid »

ricardobeat wrote: post #154
evan_ wrote: post #140

Earlier quoted context omitted.

Confusing analogy, doormen frequently do have a key to every apartment in the building. Anyway I agree it would be bad practice but that doesn't mean it's not done.

> doormen frequently do have a key to every apartment in the building Really? That's insane. I'd like to hear more about that.

I've actually had a landlord give the keys to one of the tenants since they didn't have a doorman. The tenant in question was actually a registered sex offender too, but the judge is friends with the landlord so no harm done. Crazy world.

Re: Updated Okta Statement on Lapsus$

#184

Post by djrogers »

duncan-donuts wrote: post #69
smcl wrote: post #7

> In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider It looked kinda successful though...

> The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is consistent with the screenshots that we became aware of yesterday. Yeah, it was.

You can take my laptop from me and have access to it without having compromised my Okta account. In that scenario you wouldn't have my okra password or my MFA - what you would have is transient access to everything I'd already auth'd to until it times out and requests that you auth again.

Re: Updated Okta Statement on Lapsus$

#185

Post by tialaramex »

Spooky23 wrote: post #144
politelemon wrote: post #79

Earlier quoted context omitted.

8600 channels? Wouldn't that overwhelm you? I'm trying to think up scenarios where an org would need so many, but I can't. Is this normal?

Channel sprawl is very normal. While my day job has a broad scope in the org, I’m a “member” of over 900 MS Teams. I’d guess that 3% are active and i interact with 0.

900 teams? That's a lot, are you sure you don't mean 900 channels (or whatever Teams calls them) instead?

Re: Updated Okta Statement on Lapsus$

#186

Post by sleepybrett »

Spooky23 wrote: post #144
politelemon wrote: post #79

Earlier quoted context omitted.

8600 channels? Wouldn't that overwhelm you? I'm trying to think up scenarios where an org would need so many, but I can't. Is this normal?

Channel sprawl is very normal. While my day job has a broad scope in the org, I’m a “member” of over 900 MS Teams. I’d guess that 3% are active and i interact with 0.

At a previous job a new slack channel was spun up for every incident, no matter how minor by automation. So yeah a few thousand doesn't sound that weird to me.

Re: Updated Okta Statement on Lapsus$

#187

Post by hudsonjr »

ttt2022 wrote: post #173
adam0c wrote: post #163

Copy / Paste from Lapsuss telegram ;) https://www.okta.com/blog/2022/03/updated-okta-statement-on-... I do enjoy the lies given by Okta. 1. We didn't compromise any laptop? It was a thin client. 2. "Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider." - I'm STILL unsure how its a unsuccessful attempt? Logged in to superuser portal with the…

> kkkkkkkkkkkkkkk "kkkkkkk" is the Brazilian way of typing "hahaha". Is Lapsus from South America?

I believe they are Brazil. Also a month or two back there were claims that a member accidentally doxxed themselves a couple times, and they were in Spain.

Re: Updated Okta Statement on Lapsus$

#188

Post by codebje »

giaour wrote: post #16
koolba wrote: post #4

> Support engineers do have access to limited data - for example, Jira tickets and lists of users - that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords. This means they could have reset anybody’s credentials and logged in. There would a record of it if the audit logs are valid, but saying no act…

It's been a minute since I was an admin in an Okta directory, but don't all resets use a self-service flow? In order to log in to someone's account, I think you need to compromise their email, too.

Super admins can set a temporary password. But they can also change a user's email address, disable password and email change notifications, lock out all other admins... They have complete control of the org.

It's pretty clear there is no super admin breach here. None of the screenshots show an admin interface - the app portal shot clearly shows a distinct lack of the "Admin" button. No user directory shots. There is a single image of a password reset confirmation, but those are also in documentation so it's hardly a smoking gun.

It seems far more likely that a support engineer had their laptop compromised and their limited access was used to try and make a mountain out of a molehill. Not like a ransomware group would have reason to over-exaggerate their access and ability, right?

Re: Updated Okta Statement on Lapsus$

#189

Post by ralmeida »

vault wrote: post #17
mimikatz wrote: post #8

I don't understand how they can say "unsuccessful attempt to compromise the account of a customer support engineer" . then can say "Following the completion of the service provider’s investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer’s laptop. This is cons…

If somebody uses my laptop, my Gmail account is not compromised; I'm being dolphined. Of course 5 days is quite a long time, but this is just to clarify what you didn't understand.

If someone has access to your laptop with a logged-in Gmail account, they could change your password and log you out of your other devices, effectively gaining total control of your account and locking you out.
Post reply on HN