LAPSUS$ has already responded on 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…
- Getting access to a list of accounts (and by extension any new accounts) of an organisation. This would perhaps allow an attacker to beat a new employee through the enrollment process if the attacker were to find out that all new employees get their temporary password set as P@S$w0rd until they enroll for the first time and are required to set a real password. Alternatively, social engineering attacks would be made easier to attempt contact with new employees directly to "help" them with onboarding ("Employee: Why does my MFA token keep resetting? Attacker: You didn't know that you have to first register it at company.oktamfa.com/register?").
- Resetting MFA for a user so that the attacker could then login to an organisation's user account they already know the password for (from other sources assuming password reuse), re-enrolling MFA in the process and therefore effectively bypassing MFA.
- Sending a reset password link via e-mail to a user. The user would be able to continue logging in with their credentials so it does not appear this would cause a denial of service opportunity [1] [2]. For more sophisticated attackers (states) perhaps this is also an opportunity to capture the cleartext reset URL token to gain access to the account if the attacker has access tot he network path the e-mail is sent over.
- Resetting a user password to a temporary one that is e-mailed to the user in plaintext. Would create an annoyance to users in that their current credentials would stop working all of a sudden and they'd have to check their e-mail for the temporary password to use and reset their account [1] [2]. Despite [2] indicating that temporary passwords can be viewed by an administrator of an organisation setting a temporary password, the statement at [3] indicates Okta staff are not able to view the temporary passwords generated and can only send them via e-mail to the user. This is a potential temporary denial of service (lower impact) or for more sophisticated attackers (states) perhaps an opportunity to capture the cleartext password via e-mail if they have access to the network path the e-mail is sent over.
- Getting and elevating access to other internal systems via information mistakenly published for internal Okta employees in Jira or Slack.
- Being able to find and exploit a vulnerability in the administration/superuser systems, Jira, Slack or other internal systems used by Okta to gain greater access.
If LAPSUS$ had already gained some of these higher levels of access, it appears they would have already revealed it.
[1] https://help.okta.com/en/prod/Content/Topics/users-groups-pr...
[2] https://help.okta.com/en/prod/Content/Topics/users-groups-pr...
[3] https://www.okta.com/blog/2022/03/updated-okta-statement-on-...