On 22 March 2022, authentication provider Okta confirmed an attempted compromise of an account related to a third-party customer support engineer, who had been working for one of their subprocessors. The statement from Okta followed several screenshots that had been posted by the Lapsus$ cyber extortion group, who have risen in prominence in recent months; Lapsus$ have targeted several enterprise technology companies, breaching significant amounts of data and posting onto their dedicated Telegram data leak channel.
The screenshots shared by Lapsus$ claimed to highlight Okta’s internal systems, including one that appears to show Okta’s Slack channels, and another with a Cloudflare interface. The dates on the screenshots appear to indicate that the activity had taken place on 21 January 2022. Okta has since clarified the steps they had taken to remediate the malicious activity, with the scale of the activity limited to 5 days in January 2022. This reportedly only affected a third-party subprocessor’s account and did not result in a wider breach of Okta’s service.
With the incident likely representing an unwelcome surprise to Okta’s customers base, this blog aims to identify what we know so far.
In a recent update, Okta clarified a timeline of activity related to the reported breach. Okta Security initially received an alert that a new MFA factor was added to a Sitel employee’s Okta account from a new location on 20 January 2022. Sitel is an Okta sub-processor that provides Okta with contract workers for our Customer Support organization. The following day, Okta raised the detection as a security incident before freezing the account at 00:28 UTC on 21 January 2022. The incident was then referred to a leading forensic firm, with the reports on the malicious activity being sent to Okta on 17 March 2022. Lapsus$ then published the screenshots of the activity 5 days later on 22 March 2022.
Okta has confirmed that Lapsus$ had access to the support engineer’s computer for a period of five days between 16-21 January 2022. Forensic examination of the incident identified the activity was conducted after Lapsus$ compromised a machine logged in to the support engineer’s account via a compromised Remote Desktop protocol session (RDP). We’ve spoken long and hard about the risks of RDP, with the exploitation of susceptible remote services representing one of the most common initial access used by both cybercriminals and nation-state-associated threat groups.
What’s the risk from this incident?
Overall, the statement released by Okta indicates that the privileges of the affected support engineer account were limited in nature, permitting basic duties in handling inbound support queries. The “superuser” application that was pictured in Lapsus$’ screenshots was an in-house application used by support staff to handle most queries; this should not be confused with administrator or superuser level of access to Okta’s organization. Subsequent updates from Okta have clarified that approximately 366 customers may have been potentially affected by the breach and that their data “may have been viewed or acted upon.” According to Okta, any customers affected by this breach have already been contacted by email.
From the details received from Okta, the window of opportunity for the compromised account was short. Lapsus$ have suggested that they had maintained access for two months following 21 Jan 2022, however, there is no evidence to corroborate these claims at this time. Cybercriminal actors often conduct PR exercises in order to bolster their claims. For Lapsus$ this was highlighted by several of the group’s initial posts stating “you have suffered from a ransomware attack”.
While many researchers have included Lapsus$ in the spectrum of ransomware activity, so far we have not observed any ransomware being used in Lapsus$ incidents. The initial suggestions of this malware type were likely made in order to increase the fear and pressure on targeted organizations. With Okta, it is realistically possible that Lapsus$ have exaggerated the scale of the access in order to bolster their claims or otherwise enhance their reputation.
Lapsus$ also responded on their data leak channel on Telegram to the statement made by Okta, refuting many of the observations and indicating that the scale of the compromise was far greater than has been reported. In particular they seemed to take offense to the suggestions that the attempt to compromise the account were unsuccessful, and support engineer accounts were unable to obtain passwords that they had reset for other users. Overall, the sentiment of Lapsus$ claims were that the breach was not limited in nature, with Lapsus$ also having clarified that their activity had not targeted Okta databases, but instead went after Okta’s customers. If true, this does raise the risk associated with the breach overall.
Meet Lapsus$ – an increasingly common adversary
Lapsus$ have stormed into significance in recent months with a series of high-profile breaches affecting several high-end technology companies. We’ve previously identified their activity following attacks made against Samsung and Nvidia, however, in addition to the attack against Okta, this week has also seen Lapsus$ release data related to Microsoft. This included a 37GB archive related to Microsoft’s Bing and Cortana applications, in addition to other unspecified source code related to Microsoft.
The significance of Microsoft’s breached data will likely be determined in the coming weeks and months, with Lapsus$ themselves also unlikely to have had the time to process and understand all of the data they have stolen. A breach of source code can be severe for a technology company, potentially allowing threat actors to gain an inside look at important intellectual property, system code, and other proprietary data. Code leaks allow cyber attackers to illegally gain confidential user data and corporate information, which can result in serious financial, reputational, and business losses. Access to source code can otherwise identify security weaknesses or gaps that a capable threat actor could exploit for more sophisticated follow-on campaigns.
In terms of making a name for themselves, stealing source code from Microsoft is probably one of the most brazen and outlandish attacks that a cyber extortionist can accomplish. They’ve targeted the enterprise-level companies and are likely fully aware that while their footprint will have dramatically increased, so will the target on their backs. Little is known of the origins of the group, however, given that Lapsus$’ initial activity was directed towards several organizations in Brazil, some researchers have speculated that the group is based in South America. South American cybercrime is something that doesn’t always make the headlines, but difficult socioeconomic conditions and booming internet use make this region particularly fertile for cybercrime. Microsoft is continuing to investigate the breach however and further details are likely to emerge in the coming weeks.
What are the TTPs associated with Lapsus$?
A recent update from Microsoft on their efforts to track Lapsus$—who Microsoft has designated DEV-0537—has illuminated several of the tactics, techniques, and procedures (TTPs) associated with the group. There is some fantastic detail contained within the blog, which I highly recommend reading in detail to understand the nature of the threat posed by Lapsus$.
Much of the TTPs associated with Lapsus$ are conducted through extensive use of social engineering, including over-the-phone-based attacks targeting help desks, SIM-swapping for account takeover, requesting insiders to assist in facilitating access, and other credential-based intrusions. The group are notoriously brazen about their activity and have previously announced their plans for insiders at specified companies; announcing which organizations they intend to target certainly distinguish the group from other cyber extortionists, who likely appreciate that such a public discussion of their plans will likely decrease the likelihood of a successful breach.
Their tactics include phone-based social engineering; SIM-swapping to facilitate account takeover; accessing personal email accounts of employees at target organizations; paying employees, suppliers, or business partners of target organizations for access to credentials and multifactor authentication (MFA) approval; and intruding in the ongoing crisis-communication calls of their targets.
Insider threats are an attack vector that isn’t often discussed, however, can be extremely useful for a determined threat actor. A malicious insider could facilitate long-term access, upload malicious software, exfiltrate data, and do so while slipping past many of the detection mechanisms that are in place for other more technical intrusions. Following the COVID-19 pandemic, many workers have been forced to adapt their working practices, take reduced hours, or potentially even lose their jobs. While insiders will likely have their own motivations, Lapsus$ has previously offered significant financial sums to those willing to work for them; with the current financial uncertainty across the world, there likely isn’t a better time to recruit disgruntled employees.
The methods used by Lapsus$ to bypass MFA were not technical, but instead relied on either the use of insiders or through session token replay; this involves the use of stolen passwords to trigger simple-approval MFA prompts, hoping that the legitimate user of the compromised account eventually consents to the prompts. Mitigating the latter of these attacks will come down to user awareness, being vigilant for suspicious activity associated with their MFA, and knowing of the risks of blindly accepting requests without knowing where they are from. This falls under the same spectrum of clicking links in emails or enabling office macros from an unknown source—just don’t do it.
What should you be doing right now?
Security teams will undoubtedly be attempting to discover if they’ve been impacted in any way by the Okta breach, and what steps should be taken to dictate the risk. We’ve compiled a list of recommendations for organizations and end users below.
- Review Okta logs for suspicious activity. Pay particular attention to the following events:
- eventType eq “user.mfa.factor.deactivate”
- eventType eq “user.mfa.factor.reset_all”
- eventType eq “user.account.update_password”
- eventType eq “user.lifecycle.activate”
- eventType eq “system.api_token.create”
- Enable end user notifications for suspicious login attempts, passwords resets, and MFA resets. Ensure users are aware of the process of how to escalate when required.
- Use strong forms of multifactor authentication. Hardware tokens are best, however if using push notifications then enable the use of number matching / number challenges.
- Telephony based MFA should be avoided due to the risks of SIM swapping attacks.
- Remain vigilant for any communications from Okta. The notification will reportedly come via email, so be sure to monitor any email channels used for external communications.
- Review detection opportunities for tools known to be used by Lapsus$, notably DSync and Mimikatz. The group have been reported using several other methods of living off the land (LOTL) so legitimate tools should also be considered.
- Lapsus$ is also known to exploit vulnerabilities in Confluence, JIRA, and GitLab. Ensure any vulnerabilities affecting these services are patched.
Digital Shadows continues to monitor the ongoing situation regarding Okta, in addition to our efforts at tracking the Lapsus$ threat actor. To stay in the know about recent developments for this group, sign up for a 7-day free trial of Threat Intelligence with SearchLight. SearchLight clients receive real-time, actionable intelligence updates relating to new attack types, including analysis from our team of global analysts and intelligence on new posts to platforms across open and closed sources.