News

366 Okta Customers Affected by Lapsus Attack

• By Kurt Mackie
• 03/23/2022

Update (02/25): Seven individuals connected with the Lapsus$ hacker group, including its suspected leader, were arrested on Thursday in the surrounding areas of London.

Okta issued a follow-up statement on Wednesday regarding an attack by the Lapsus$ group, indicating that 366 of its customers (about 2.5 percent) at maximum may have been affected.

Identity services provider Okta had earlier this week explained that a third-party support engineer's laptop had been hacked by Lapsus$ back in January, but the actions of this contractor were limited. Okta's services weren't breached by this attack and none of its customers needed to take corrective actions, Okta had indicated. The Lapsus$ attackers had leaked screenshots to imply access to Okta's network.

In the Wednesday announcement, Okta described the contractor whose laptop was breached as having worked for Sitel, a company that provides "contract workers for our Customer Support organization."

Okta acted on Jan. 21, a day after receiving a security alert relating to multifactor authentication (MFA), to suspend the contractor's account. It received a summary report on the attack on March 17 from Sitel, but didn't receive the full report until March 22.

"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," said David Bradbury, chief security office at Okta, in the announcement. "Upon reflection, once we received the Sitel summary report we should have moved more swiftly to understand its implications."

Cloudflare's Advice
One of the Okta's customers identified in the screenshots that were released by Lapsus$ was an employee at Cloudflare, a Web performance and security company.

Cloudflare uses Okta to authenticate its employees, but it also uses FIDO hardware tokens, so an attacker would need to change those tokens as well as passwords for a successful attack to take place, Cloudflare explained in a March 22 post.

Cloudflare, though, did take action following notification the breach. It forced password resets for 144 Cloudflare employees who had reset their passwords over the past few months.

Cloudflare noted that it stores Okta log data in its own systems as an extra layer of security, "even though logs are available in the Okta console," which ensures that forensic information can't be altered. Part of its forensic efforts was to check e-mail logs for password reset attempts by an attacker.

Cloudflare had advice for other Okta customers that may have been affected. In summary, Cloudflare recommended:

• Enabling MFA for all user accounts
• Investigate all password and multifactor changes
• Force new password resets based on those investigations
• Ensure that "only valid MFA keys are present in the user's account configuration"
• Have layers of security in place.

Microsoft's Advice
Microsoft also was recently attacked by the Lapsus$ group, but described it as being limited to "a single account" with limited access, even though Lapsus$ apparently released Bing and Cortana source code.

It was also alleged that signing certificates for the source code were leaked, but Microsoft indicated in a released statement there were no security implications to the leak, per its investigations, according to a spokesperson:

We've investigated the claims related to "signing certificates" and found no evidence to support this. Our investigation continues, but so far, we have reviewed each leaked certificate and confirmed they do not pose a security risk.

In its advice, Microsoft similarly advised turning on MFA for all users, as described in its Tuesday article about Lapsus$ attack methods. Microsoft uses the label, "DEV-0537," to describe Lapsus$.

Microsoft also advised using FIDO tokens, Windows Hello "or the Microsoft Authenticator app with number matching" as security measures to take. Number matching with the Authenticator app was previewed back in November. Microsoft is planning to enable number matching "by default for all tenants a few months after general availability (GA)."

Organizations also should "avoid telephony-based MFA methods to avoid risks associated with SIM-jacking." SIM swapping, or assigning a person's phone number to a new mobile phone SIM card, is one of the attack methods used by DEV-0537, according to Microsoft.

Organizations should use "Azure AD Password Protection," Microsoft indicated, which refers to policies that can be set to block the use of easily guessed passwords. 

Organizations should avoid using text messaging with MFA verifications. This repeated use of "simple push messages" apparently has been leveraged by the attackers to gain credentials. Former Microsoft employee Kevin Beaumont flatly stated that organizations should "disable MFA push requests" in a Feb. 26 Twitter post.

Organizations also should not set location-based exclusions for MFA or permit credential or MFA sharing between end users.

Microsoft's Tuesday security article also had lots of advice about endpoint security, VPN authentications (use OAuth or SAML) and the use of various cloud-based protections to impose conditional access challenges and protect against risky sign-ins. Organizations should also educate end users about phishing and other "social engineering" attack methods.

Microsoft described DEV-0537 as a criminal group that tries to extract payments for not leaking compromised data. The group also tries to monitor the incident response communications of its victims, so organizations should check those groups for "unauthorized attendees."

"Organizations should develop an out-of-band communication plan for incident responders that is usable for multiple days while an investigation occurs," Microsoft's Tuesday announcement added.