Lapsus$ Attacks: Microsoft Says Group Pays Employees For Initial Access; Okta Provides Attack Timeline

• Microsoft acknowledges Lapsus$ accessed source code, downplays risk to customers and risk of elevation
• Lapsus$ uses extensive social engineering, including paying victims’ employees for initial access and convincing help desks to reset credentials
• Group uses VPNs, RDP, VDI and identity providers such as Azure AD, Okta in attacks
• Okta says 2.5% of customers potentially impacted after third-party support account compromised
• Okta details attack timeline, revealing gap in disclosure

In a blog detailing how the Lapsus$ hacking group accessed “a single account” and stole Microsoft source code, Microsoft says the group gains initial access in a variety of ways, including paying employees at targeted organizations, or their suppliers or business partners, for access to credentials and multifactor authentication approval.

Microsoft’s blog, published March 22, comes three days after the Lapsus$ hacking group posted screenshots of a compromised Microsoft developer’s account and after the group published stolen source code of Bing, Cortana and other projects.

However, Microsoft says no customer code or data was involved in Lapsus$’ compromise of a single account, which granted the threat actor limited access.

“Our cybersecurity response teams quickly engaged to remediate the compromised account and prevent further activity,” Microsoft said in a blog penned by the company’s Threat Intelligence Center, Detection and Response Team and Microsoft 365 Defender Threat Intelligence Team.

The company does not detail exactly how the Microsoft employees’ account was compromised, but says the tactics described in the blog were used in the intrusion. Further, Microsoft says it was already investigating the compromised account based on threat intelligence when Lapsus$ posted the screenshots.

“This public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact,” Microsoft said in the blog.

Microsoft says it has been tracking the group’s “large-scale social engineering and extortion campaign” in recent weeks. According to the blog, Lapsus$ has been observed attacking multiple organizations with these tactics, including some “destructive elements.” The group spends a considerable amount of time gathering knowledge about the targeted organization, including information about operations, employees, team structures, help desks, crisis response workflows and supply chain relationships.

Unlike ransomware actors, Lapsus$, which Microsoft calls DEV-0537, uses a pure extortion and destruction model without actually deploying ransomware. The group has shown a disregard for covering its tracks, announcing attacks on social media and advertising their intent to buy credentials from targeted organization.

In these instances, Lapsus$ recruited employees or employees of a target organization’s suppliers or business partners after advertising that they wanted to buy credentials. For a fee, the insiders provide their credentials and approve the MFA prompt. Or, the user installed remote management software like AnyDesk on their corporate machine and gave the group full control of their authenticated system.

In addition to bribing employees or business partners to give them initial access, other tactics out of the norm include phone-based social engineering, SIM-swapping to facilitate account takeover, accessing personal email accounts of employees at targeted organizations and intruding in crisis communication calls of their targets. The group has also been observed mapping a target user with MFA prompts and calling the organization’s helpdesk to reset a targeted user’s credentials.

Microsoft’s blog also contains several recommended steps to thwart these attacks, including strengthening MFA implementation and avoiding SMS- or email-based authentication, requiring healthy and trusted endpoints, leveraging new authentication options for VPNs, strengthening cloud security postures and improving awareness of social engineering attacks.

Read: What We Know So Far About Okta, Microsoft and Lapsus$

Okta: Up to 2.5% of customers impacted

After initial access is gained, Lapsus$ accesses internet-facing systems and applications, such as VPNs, RDP, virtual desktop infrastructure and identity providers such as Azure Active Directory and Okta, the latter of which also became embroiled in the crisis when screenshots showing a purported breach were posted to the group’s pages.

Late Tuesday, Okta’s Chief Security Officer David Bradbury posted a detailed timeline of the company’s response to the compromise. In the blog, Bradbury says the screenshots were taken from a computer used by Sitel, one of Okta’s third-party customer support engineers. On Jan. 20, Okta’s security team was alerted that a new MFA factor had attempted to be added to a Sitel customer support engineer’s Okta account, Bradbury wrote. That attempt was unsuccessful, but the account, Sitel was notified and a forensic firm was hired to investigate.

According to Bradbury, the “maximum potential impact” is 366 (approximately 2.5% of) customers whose Okta tenant was accessed by Sitel.

Here is the timeline (times in UTC) provided by Bradbury:

• January 20, 2022, 23:18 –  Okta Security received an alert that a new MFA factor was added to a Sitel employee’s Okta account from a new location.
• January 20, 2022, at 23:46 – Okta Security investigated the alert and escalated it to a security incident.
• January 21, 2022, at 00:18 – The Okta Service Desk was added to the incident to assist with containing the user’s account.
• January 21, 2022, at 00:28 – The Okta Service Desk terminated the user’s Okta sessions and suspended the account until the root cause of suspicious activity could be identified and remediated.
• January 21, 2022, at 18:00 – Okta Security shared indicators of compromise with Sitel. Sitel informed us that they retained outside support from a leading forensic firm.
• January 21, 2022 to March 10, 2022 – The forensic firm’s investigation and analysis of the incident was conducted until February 28, 2022, with its report to Sitel dated March 10, 2022.
• March 17, 2022 – Okta received a summary report about the incident from Sitel
• March 22, 2022, at 03:30 – Screenshots shared online by LAPSUS$
• March 22, 2022, at 05:00 – Okta Security determined that the screenshots were related to the January incident at Sitel
• March 22, 2022, at 12:27 – Okta received the complete investigation report from Sitel

Here is the remainder of Bradury’s statement:

I am greatly disappointed by the long period of time that transpired between our notification to Sitel and the issuance of the complete investigation report. Upon reflection, once we received the Sitel summary report we should have moved more swiftly to understand its implications.

Our investigation determined that the screenshots, which were not contained in the Sitel summary report, were taken from a Sitel support engineer’s computer upon which an attacker had obtained remote access using RDP. This device was owned and managed by Sitel. The scenario here is analogous to walking away from your computer at a coffee shop, whereby a stranger has (virtually in this case) sat down at your machine and is using the mouse and keyboard. So while the attacker never gained access to the Okta service via account takeover, a machine that was logged into Okta was compromised and they were able to obtain screenshots and control the machine through the RDP session.

It’s important to understand that the access that a support engineer has is limited to basic duties in handling inbound support queries. Support engineers use a number of customer support tools to get their job done including Okta’s instances of Jira, Slack, Splunk, RingCentral, and support tickets through Salesforce. The majority of support engineering tasks are performed using an internally-built application called SuperUser or SU for short, which is used to perform basic management functions of Okta customer tenants. This does not provide “god-like access” to all its users. This is an application built with least privilege in mind to ensure that support engineers are granted only the specific access they require to perform their roles. They are unable to create or delete users. They cannot download customer databases. They cannot access our source code repositories.

The report from the forensic firm highlighted that there was a five-day window of time between January 16-21, 2022 when the threat actor had access to the Sitel environment, which we validated with our own analysis.

In trying to scope the blast radius for this incident, our team assumed the worst case scenario and examined all of the access performed by all Sitel employees to the SuperUser application for the five-day period in question. Over the past 24 hours we have analyzed more than 125,000 log entries to ascertain what actions were performed by Sitel during the relevant period. We have determined that the maximum potential impact is 366 (approximately 2.5% of) customers whose Okta tenant was accessed by Sitel.

Because of the access that the support engineers had, the information and the actions were constrained. While it is not a necessary step for customers, we fully expect they may want to complete their own analysis. For transparency, these customers will receive a report that shows the actions performed on their Okta tenant by Sitel during that period of time. We think this is the best way to let customers assess the situation for themselves.

As with all security incidents there are many opportunities for us to improve our processes and our communications. I’m confident that we are moving in the right direction and this incident will only serve to strengthen our commitment to security.

If you enjoyed this article and want to receive more valuable industry content like this, click here to sign up for our digital newsletters!