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

121–130 of 239 posts

Re: Updated Okta Statement on Lapsus$

#121

Post by jeremyjh »

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 72 hours to explain why disclosures have not already been sent) "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."

Re: Updated Okta Statement on Lapsus$

#123

Post by viraptor »

intunderflow wrote: post #51
templapsusread wrote: post #31

Earlier quoted context omitted.

they edited and added more content https://img.guildedcdn.com/ContentMedia/372280f522049aa0b0eb...

To note in some of the earlier screenshots you can see they have the EC2 Instances menu open in their tabs - that's a bit concerning, why does a support engineer need AWS EC2 access?

If it's just a tab heading, we don't know if they have access or not. You can always open that page as long as you can log in. But it may show "you don't have permissions to display the instances". If you're thinking instead "why does a support engineer need AWS access" - cloudwatch metrics/logs come to mind.

Re: Updated Okta Statement on Lapsus$

#124

Post by benatkin »

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

I think they're meaning it like a login attempt here. If you submit a login form 5 times, that's 5 login attempts. Another similar example is free throw attempts. https://www.statmuse.com/nba/ask/most-free-throw-attempts-pe...

I wouldn't have realized that unless I'd read far enough to see that Entity A did compromise Account B. Since the author didn't define what an attempt in this context means, I think it would be proper to assume that attempt meant the overall effort to compromise the account.

Re: Updated Okta Statement on Lapsus$

#125

Post by GauntletWizard »

kichik wrote: post #113
ev1 wrote: post #104

Earlier quoted context omitted.

I do security (albeit not CISO or compliance-style, but commercial anticheat), and in my opinion, if a support agent's account was used by a third party to view anything about my account without permission - any undisclosed email address or name, their system was compromised and it is a data breach. IMO, support agents also should not have the ability to view or access a customer's account without some form of time l…

Yeah, the screenshots they admit are real clearly show Slack, JIRA and AWS being open. What did the attackers see there? Were the customers whose data was viewed notified? How can Okta tell if that data is sensitive or not without taking to their customers?

A competent security response to this would have been "Yes, they compromised one of our support technicians. We've initiated an audit and are sending out e-mails containing all of the actions that support representative performed for each customer to that customer's administrator"

Re: Updated Okta Statement on Lapsus$

#126

Post by dboreham »

t0bia_s wrote: post #109

Reply from Lapsus$ on Telegram: 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 ability to reset the Password and MFA of ~95% of clients isn't succes…

Posting a key in Slack is obviously not good opsec, but whether this is a big problem depends whether those keys allowed access to anything sensitive. They could be keys allowing access to random test data, or public data, etc. They could have been revoked immediately they were posted.

Re: Updated Okta Statement on Lapsus$

#127

Post by hackmiester »

dboreham wrote: post #116

The post could use some review/edit. This: "a customer support engineer working for a third-party provider" actually means "one of our customer support engineers, who happens to be an employee of another company, working for us under contract".

Don't believe for a moment that this misdirection is unintentional. It's one big reason you might have contract workers instead of employees in this role, actually.

Re: Updated Okta Statement on Lapsus$

#128

Post by sodality2 »

creativenolo wrote: post #36
chockchocschoir wrote: post #14

Earlier quoted context omitted.

The text is a bit ambiguous (and probably on purpose, I'm sure it passed through multiple layers where multiple lawyers have reviewed it too). Okta says Lapsus$ were unable to "obtain" the passwords, but they didn't say they were unable to set their own passwords (for example). Neither is the MFA tokens mentioned, although they do mention MFA in the text.

Then they'd have obtained it, no? It seems pertinent a support engineer could trigger a password reset if they were worried a password had been compromised for a user.

I think "obtain" here is specifically meant to mean "get existing passwords in plaintext", not "get a valid password via resetting it to a known one".

Re: Updated Okta Statement on Lapsus$

#130

Post by MattGaiser »

mardifoufs wrote: post #115
different_sort wrote: post #83

Earlier quoted context omitted.

Maybe I’m just an unimpressed security professional but I’ve still not seen evidence I’d call a breach. At least not a significant one if you want to argue sublantics. Workers at organizations get compromised all the time. This doesn’t mean their systems/products are compromised.

If you follow the lapsus telegram, you will see they are claiming they got AWS API keys from the corporate slack. That might be more dangerous than accessing the support console

I can see a Slack breach being far more damaging than policy should effectively permit it to be because plenty of people use it to share things they technically should not.
Post reply on HN