> A person who should not have had access to the system gained near full admin access for five whole days.

"This is an application built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles. They are unable to create or delete users. They cannot download customer databases."

not being able to create or delete users seems a far cry from "near full admin access."

Why? We only know that they are not able to create new users.

But at least changing passwords of existing accounts seemed possible according to the screenshots, perhaps disabling 2FA as well.

As long as Okta does not provide a list of what the user was able to do, we don't know

At my own workplace (a SaaS service), we cannot change passwords, we can only send reset links (and the reset email goes to the end user).

I can't see any place in the screenshots where they are setting a user's password, only sending reset links (which would do nothing if the support user does not have access to system email or end users email).

Also at my workplace, 2FA is not enforced by an IdP (like Okta), but by our own application (and therefore could not be disabled at the IdP level).

How do you send a reset password email with a SSO platform that gates email?

If you have 2FA a OTP can be sent to a trusted device or app to allow a password reset without having access to email?

Is your workplace Okta? They built a custom internal tool. Until they enumerate exactly what the attacker had access to it’s hard to infer anything.

The article specifically addresses this, right? They log every interaction from support engineers and are going to report to the affected customers what actions were performed.

As others have mentioned, the slack access is potentially more concerning.

Based on the screenshots and Okta's description (which absolutely needs to be more clear), the attacker couldn't directly change passwords, they could only trigger password reset emails.

The linked article states that SuperUser is the name of their internal software. It's a confusing name, but at no point did the attacker have access to "near full admin access", based off the report.

The relevant question is "near-full admin access of a system that does what?"

If Okta has implemented a BeyondCorp model, the attackers had access with known limits. It doesn't matter how much access if the machine they've accessed is itself untrusted. That's the punchline of an episode of Star Trek: Lower Decks where they allowed an evil computer to take over the lighting systems on a starship; while they repaired the ship, all the computer could do was flick the lights on and off angrily.

On the topic of 'leet hacking skillz' I personally find it strange that so many Silicon Valley companies only care abut leetcode for the interview process.

You can be a security expert and no tech company will care unless you cram leetcode non-stop.

On the plus side the lack of security focus makes for a lot of opportunities for the stock market when betting against overvalued tech companies with this problem!

security design is pretty much the only thing that resembles real engineering in software. other than safety critical systems, it's pretty much the most common thing that can actually go wrong and harm people.

one day there will probably be professional engineering certifications for software engineers, and those certifications will largely center around building secure software and systems. (with maybe some focus on safety critical systems as well)

it's funny when you think about how young the field is.