Early in the morning of March 22nd a threat group known as LAPSUS$ posted screenshots on their Telegram account that allegedly show access to Okta internal systems such as Slack, Cloudflare, Jira, Salesforce and other “Okta cards.”
Okta’s CEO Todd McKinnon apparently confirmed an event in January in a tweet:: “In late January 2022, Okta detected an attempt to compromise the account of a third party customer support engineer working for one of our subprocessors. The matter was investigated and contained by the subprocessor.”
What can you do?
As is the case with any breach event or alleged breach event, the protocol should be to review your potential exposure to the event and be clear about the language that you use both internally and with your customers, colleagues and executives. A basic “shields up” protocol for Okta customers could include:
reviewing admin events/logs
- on the Settings->Account page
verify that “Give Access to Okta Support” is disabled
“Give Directory Debugger Access to Okta Support” is disabled.
audit/review the API tokens that have been created in the recent period
If this threat group has elected to target your organization, they will want to establish persistent remote access by compromising a privileged user credential, bypassing MFA or creating their own administrator-level access.
A good practice to ensure that you have in place, however, is to not treat security investigations as an adhoc process. Continuous monitoring of privileged credentials (admin activity, API tokens) for anomalous behavior is key to having what is called observability. Your SOC (Security Operations Center) is key to detecting signs of account compromise, whether your SOC is in-house or outsourced. Some of the most advanced threat actors are able to move laterally within 18 minutes of “patient zero” so an automated MDR/EDR/XDR platform is essential.