Updated Okta Statement on Lapsus$
1–10 of 239 posts
Re: Updated Okta Statement on Lapsus$
#2Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...
Re: Updated Okta Statement on Lapsus$
#3It feels like a lawyer heavily tweaked this to sound better than it really is.
Re: Updated Okta Statement on Lapsus$
#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 action is needed may be a stretch.
Re: Updated Okta Statement on Lapsus$
#5More than a little concerning that they apparently investigated this in January, and while there's a lot of talk about what could or could not have happened, they don't seem to know what actually happened, and no customers were notified (but now: "[we are] identifying and contacting those customers that may have been impacted).
Re: Updated Okta Statement on Lapsus$
#6> Support engineers are also able to facilitate the resetting of passwords and MFA factors for users, but are unable to obtain those passwords.
Very ambiguous statement, not really fitting in with the whole "deeply committed to transparency" image they are trying to emit.
What does "facilitate" really refer to here? If it was just triggering it, they would have said so, presumably. And why is only passwords mentioned as what couldn't be obtained and not the tokens from MFA as well, does that mean they could obtain those tokens?
I wonder how it fits in with the groups own statements that they still have active access. Gonna be interesting to see what Lapsus$ replies to this statement.
Re: Updated Okta Statement on Lapsus$
#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...
Re: Updated Okta Statement on Lapsus$
#8I 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 consistent with the screenshots that we became aware of yesterday." and the screenshots of the attackers looking at Okta's support portal.
Re: Updated Okta Statement on Lapsus$
#9I mean, ultimately, it is now up to Lapsus$ to confirm this. If everything they say (and the Cloudflare post, also) is true then I don't think anyone should be worried.
Re: Updated Okta Statement on Lapsus$
#10> 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…
> This means they could have reset anybody’s credentials and logged in
Does it? It specifically says "but are unable to obtain those passwords," which reads to me like they are able to trigger a password reset email to the user, but are not actually able to set the password themselves.