On March 22, the hacking group Lapsus$ published a Twitter post with a number of screenshots taken from a computer showing “superuser/admin” access to various systems at authentication firm Okta that took place in January this year.
Okta is the #1 platform in Identity-as-a-Service (IDaaS) category, which means that it manages access to internal and external systems with one login.
Thousands of organizations and governments worldwide use Okta as the gatekeeper to their SaaS environment and cloud services. This episode demonstrates the importance of insider attacks, and others like phishing, credential stuffing, password spray; to which we can all potentially fall victim or be affected by a ramification in another compromise.
In this article, we are going to see how it’s possible to analyze and audit current and past logs using Falco and Sysdig okta-analyzer.
Who is DEV-0537 aka lapsus$ group?
Apart from the last breach hack, we don’t know much about the threat actor DEV-0537 aka Lapsus$ group. What we know is that it’s a very recent group operating out of South America and it has been active since at least December 2021 and claiming a number of victims in recent months.
Their main targets are usually large organizations to steal data and extort payments. The main victims go from government institutions like the Brazilian Ministry of Health and various technology and gaming companies like Microsoft, Nvidia, Ubisoft, Samsung, and Okta is to add to this list.
Not much else is known about Lapsus$ itself, other than that unlike ransomware gangs, which use dark web websites to publish stolen data, Lapsus$ uses a Telegram channel to share information about its attacks – and information stolen from its victims – directly with anyone who is subscribed to it.
Okta data breach – What happened?
The hacker group Lapsus$ posted on its Telegram channel the following message, which shows screenshots of access to okta.com with Superadmin access. Checking the reported date on the screen it seems that the breach occurred at the end of January 2022, leaving many concerns.
After some investigations conducted by Okta, Okta’s CEO Todd McKinnon confirmed an event in January in their official statement.
In addition to the official statement, OKTA published a timeline of the incidents which took place from January 16 to January 21 when the threat actor had access to the Sitel environment.
Using the Telegram channel, the hacker group denies the official investigation statement published by Okta leaving many to wonder why Okta didn’t report the breach earlier and the real impacts and customers involved.
Understanding the impact of the Okta breach
Estimating the real impacts of this breach is pretty hard and customers may want to conduct their own analysis.
Based on what Okta stated and reported before, the maximum potential impact of the breach is 366, approximately 2.5% of customers whose Okta tenant was accessed by Sitel. Affected customers will receive a report that shows the actions performed on their Okta tenant by Sitel during the specific period of time, so they can perform their own investigations.
On the other hand, Lapsus$ responded using the Telegram channel stating that the potential impact to Okta customers is NOT limited and resetting passwords and MFA would result in total account compromise.
What is sure is that checking Okta logs for the past months and making sure there aren’t any suspicious logs might be a short activity that could save Okta customers from unpleasant surprises in the future.
In this article, we are going to have a look at who can audit the Okta logs easily without needing to ingest all the logs in a single system.
Don’t panic, what can we do now
If you are an Okta customer you may be wondering what we can do to assess what happened and if something malicious is still happening in our environment.
Based on the information shared by Okta there are some events we should monitor and assess in past logs to make sure nothing happened and nothing is happening. In particular, we suggest the following actions:
- Enable MFA for all the users. As we know just passwords aren’t enough to secure our account and we must need an additional level of protection.
- Investigate the following events:
- Check all password and MFA changes in our Okta instances.
- Make sure that all the password resets are valid.
It’s fundamental to check either past logs and current logs to be sure your environment is still safe and there aren’t suspicious activities. If any of these events trigger an alert, take action on those accounts and we recommend that you initiate a deep investigation.
Sysdig can help you on analyzing and audit current logs using Falco open source and past logs using Sysdig okta-analyzer, providing a solution for both cases.
Runtime detection with Falco
To address this new Okta challenge we need a smart and ready to use tool which is capable of consuming a huge amount of Okta logs to assess if something fishy is happening in our environment.
Falco has a great reputation as a tool for runtime security in Linux, Container, and Kubernetes environments. What we might not know yet is that Falco has recently extended its detection capabilities with the new Falco plugin framework, which allows us to create plugins for different data sources and use the usual Falco engine over those logs.
In response to this incident, the Falco Team has created a new plugin for Okta with which it’s possible to use Falco detection rules and get alerts over those suspicious events. Here is a quick example of how a Falco rule would detect and report MFA being removed from a user account.
- rule: removing MFA factor from user in OKTA desc: Detect a removing MFA activity on a user in OKTA condition: okta.evt.type = "user.mfa.factor.deactivate" output: "A user has removed MFA factor in the OKTA account (user=%okta.actor.name, ip=%okta.client.ip)" priority: NOTICE source: okta tags: [okta]
A lot of other rules are available ready to be used and created by the Sysdig Threat Research team to audit different types of security events. If you want to learn more about the Okta plugin, visit the new blog Analyze Okta Log Events with a Falco Plugin.
Sysdig okta-analyzer: Okta threat detection
Once we have the runtime detection part covered, we will want to quickly find out if we have been affected in the past by the Lapsus$ group.
Sysdig has released the following binaries that will allow us to collect Okta events from the date we choose. It should be noted that the data collection time will vary depending on the size of the company and the distance from the initial date from which we will start ingesting the data.
| Name | sha256 |
| okta-analyzer-darwin-amd64 | 52e43994b12d790ce2a784f73a68984b8a554384962936eb8cbab5f551af396b |
| okta-analyzer-darwin-arm64 | 1a5957248dc4b665a9be7334d76a8cd0871a2da7aa86affd668512a5f547d2f2 |
| okta-analyzer-linux-amd64 | 105e97b9bdc2cf6e5cb231bc0134548647a25d63c5a84a710718275d1392662b |
How to use okta-analyzer
To run the okta-analyzer, follow the simple instructions. The only thing we need is the Okta token, here you can find the process to obtain it.
Usage:
okta-analyzer [OPTIONS]
Application Options:
-f, --file= Okta Logs File
--apikey= Okta API Key
--url= Okta API base url (e.g. "https://mycompany.okta.com")
Help Options:
-h, --help Show this help message
It can used either with:
okta-analyzer -f <logs_file.json>
or with:
okta-analyzer --apikey $OKTA_API_KEY --url yourcompany.okta.com
Reporting to a post-analysis
Once the tool is run, Okta logs are ingested and processed by the Falco OOTB rules to detect suspicious events and generated a PDF with all the evidence to a deep-analysis. This provides a quick overview of how much you may be affected.
Conclusion
No one is safe from being a target, and it is necessary to be aware that any software or service we use must be audited to shorten detection times. In addition, this incident has highlighted the importance of taking measures against an insider or social engineering, which in the end is the weakest point in the chain.
Delegating part of your infrastructure might be crucial for your business. Actively keeping an eye on its behavior is too. We hope this threat is seen as a warning of the potential risk.
If you are concerned about this new threat, audit your Okta logs as soon as possible to detect if you are affected. In this article, we have offered you the steps to follow to make the process easier.