11–20 of 239 posts
> 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
These are some impressive mental gymnastics!
I wonder how many passwords and other creds were harvested from tickets alone.
Lapsus$ went after Okta's customers and in some cases successfully, it appears.
> 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.
> 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…
> 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…
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…
Lots more detail: https://blog.cloudflare.com/cloudflare-investigation-of-the-...
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…
> 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…
The idea that support can just trigger a reset email makes little sense. Perhaps Okta has some complex mechanisms that I am not aware of, but if this was any system I’ve ever worked on, an employee could take over an account if they so desired.