Image credit: World of Dictionary
A new player has entered the game
The ”Lapsus$” group, unknown before December 2021, has made multiple headlines in recent weeks, following multiple data breaches in big companies such as Nvidia, Microsoft and Samsung. The group’s first mention seems to be in December 2021, when they attacked the Brazilian ministry of health with a ransomware attack. During the following months, the group attacked multiple companies with ransomware attacks.
Screenshot below: Lapsus$ Telegram channel, created on December 10, 2022.
According to researchers the actor behind Lapsus$ seems to be a teenager. His identity was not made public yet as he’s a minor and no criminal charges have been made so far.
What we know so far on the Lapsus$ attack on Okta
The group’s latest victim was Okta, an identity and access management solution used by thousands of organizations around the world. In January 2022 Okta was alerted to a suspicious event related to Sitel, a company that provides workforce services to Okta and recently released the timeline of this investigation. Okta also posted a statement regarding the Lapsus$ claims to which Lapsus$ replied in their Telegram channel.
Screenshots below: Lapsus$ reply to Okta’s statement.
In order for Okta to be able to provide support, a support engineer might need access to the customer’s environment. To do this, a customer can provide Okta access as described in this guide. If an Okta engineer accesses a customer’s environment using this feature, this would show in the logs as an impersonation attempt. This access can only be granted by a Super Administrator and according to Okta, the support engineer cannot create or delete users, or download a customer’s database.
There is no way to know if there might be a vulnerability that could be exploited by an attacker in order to bypass these safeguards as this feature is not publicly available and cannot be tested by end users, white hats or even attackers.
Hunting for anomalies
There are multiple ways to search the logs for anomalies related to this attack. If done via the Okta UI, there is a 90 day retention that would limit the analysts performing the investigation. If an organization has a SIEM, it could be used to perform a better analysis of the logs, depending on the log retention configured on the SIEM.
Lapsus$ posted in their Telegram channel multiple screenshots to prove they have access to
different Okta customers, some of them were related to Cloudflare. Shortly after the screenshots were published, Cloudflare uploaded a blogpost containing their investigation.
Screenshots below: screenshots published on Lapsus$ official Telegram channel.
Some of the events mentioned by Cloudflare would make it difficult for analysts to find anomalies as they could create a lot of noise and eventually lead to alert fatigue. If these events indeed create too much noise, the use case that analysts should look for is when an Okta support engineer is granted access to a customer’s environment.
To do this, we can use the following query in Splunk environments:
index=[OktaIndex] sourcetype=OktaIM2:log eventType IN ("user.session.impersonation.grant", "user.session.impersonation.initiate") actor.alternateId="*@okta.com" | stats values(outcome.result) as result, values(client.userAgent.rawUserAgent) as rawUserAgent, values(client.ipAddress) as ipAddress, values(eventType) as eventType count by actor.alternateId
This Query can be used in Sumo Logic:
_sourceCategory=prod/okta/logs "impersonation"
| json field=_raw "eventType" as eventType nodrop
| json field=_raw "actor.alternateId" as User nodrop
| json field=_raw "client.userAgent.rawUserAgent" as userAgent nodrop
| json field=_raw "outcome.result" as Result nodrop
| json field=_raw "client.ipAddress" as ipAddress nodrop
| where eventType in ("user.session.impersonation.grant", "user.session.impersonation.initiate")
| where User contains "okta.com"
| count by User, eventType,ipAddress, userAgent, Result
This query will show any occurrence where an Okta support engineer was provided access to the organization’s environment by a Super Admin (MITRE ATT&CK T1078.002). This needs to be checked with the respective Okta admins to make sure the activity is legitimate.
If any illegitimate activity is found, it’s recommended to perform a full investigation of the organization’s incident response team or hire a cyber security incident response team.
Conclusions
This attack could very well be the next big supply chain attack (MITRE ATT&CK T1195.002), with a similar impact to the Solarwinds attack, only time will tell. In the meanwhile, Okta administrators and SOC analysts should make sure to monitor for any suspicious activity and follow the news.
We also recommend reading Microsoft’s blogpost following their analysis of Lapsus$ attack on them.