Lapsus$ hacks: statements from Okta and Microsoft

Sicherheit (Pexels, allgemeine Nutzung)[German]Yesterday, two hacks of big players in the IT scene by the Lapsus$ gang became known. The group claimed a hack of the authentication service OKTA, possibly affecting customers. And Microsoft is investigating reports that 37 GB of data (source codes, certificates etc.) from Microsoft Bing, Bing Maps, Cortana etc. were published by the Lapsus$ group. Both companies have now released statements.


Advertising

The hack at Okta

Yesterday, in the article Authentication service OKTA hacked by Lapsus$?, I reported that the US authentication service OKTA was investigating suspicions that they had been hacked by the Lapsus$ group. In the meantime, there is the following statement from David Bradbury, Chief Security Officer at Okta, dated 22 March 2022, about the hack.

Updated Okta Statement on LAPSUS$

The Okta service has not been breached and remains fully operational. There are no corrective actions that need to be taken by our customers.

In January 2022, Okta detected an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party provider. As part of our regular procedures, we alerted the provider to the situation, while simultaneously terminating the user's active Okta sessions and suspending the individual's account. Following those actions, we shared pertinent information (including suspicious IP addresses) to supplement their investigation, which was supported by a third-party forensics firm.

Following the completion of the service provider's investigation, we received a report from the forensics firm this week. The report highlighted that there was a five-day window of time between January 16-21, 2022, where an attacker had access to a support engineer's laptop. This is consistent with the screenshots that we became aware of yesterday.

The potential impact to Okta customers is limited to the access that support engineers have. These engineers are unable to create or delete users, or download customer databases. Support engineers do have access to limited data – for example, Jira tickets and lists of users – that were seen in the screenshots. Support engineers are also able to facilitate the resetting of passwords and multi-factor authentication factors for users, but are unable to obtain those passwords.

We are actively continuing our investigation, including identifying and contacting those customers that may have been impacted. There is no impact to Auth0 customers, and there is no impact to HIPAA and FedRAMP customers.

We take our responsibility to protect and secure our customers' information very seriously. We are deeply committed to transparency and will communicate additional updates when available.

So it states that Okta as a service was not attacked and was still fully functional. There would be no corrective actions to be taken by our customers. In January 2022, Okta discovered an unsuccessful attempt to compromise the account of a customer support engineer working for a third-party vendor. There was, according to statements, a five-day window between 16 and 21 January 2022 when an attacker had access to the laptop of a support engineer (from Costa Rica, according to my information). The January 2021 timeframe is consistent with what I wrote in the article Authentication service OKTA hacked by Lapsus$? – although it is unclear to me how the statement "unsuccessful attempt to compromise account" and "access to support technician's laptop" fit together. And Okta's statement that Lapsus$ did not have access to the service should be taken with a grain of salt (whistling in the forest). The Lapsus$ group has posted a rebuttal, which can be found on this website.

Lapsus$ OKTA statement

Lapsus$ OKTA statement /2

Lapsus$ claims to have compromised a thin client so that they had access to a super user portal. There it was possible to reset the passwords and multi factor authentication of 95% of the customers. So there seems to be more to come – the entire screenshot of the Lapsus$ posts can be read on this website.


Advertising

Bleeping Computer has compiled the findings in this article –  CloudFlare was one of the Okta customers affected. They use Okta for internal authentication, according to their statement. Since it appeared that an Okta support employee with access to things like resetting a password for an Okta customer account had been compromised, CloudFlare we decided to review all employee accounts that had reset their password or changed their multi-factor authentication (MFA) in any way since 1 December to date. Since 1 December 2021, 144 Cloudflare employees had reset their password or changed their MFA. CloudFlare enforced a password reset for all affected accounts and notified employees of the change. The CloudFlare statement is quite worth reading.

In this tweet, someone posted a quick check on how Okta customers should test if they have been compromised by this hack. The logs are to be checked for "Impersonation Grant" events. This is logged when someone turns off the "Okta Support Access" feature (this should always be disabled unless needed JIT).

Statement from Microsoft

Yesterday, in the article Lapsus$ allegedly publishes source code of Microsoft Azure, Bing and Cortana, I also reported that the Lapsus$ group claims to have captured data and source codes from various Microsoft products. It is said that 37 GBytes of data (source codes, certificates, etc.) from Microsoft Bing, Bing Maps, Cortana, etc. are involved, which are now being published by the Lapsus$ group. Microsoft has now also taken a stand, as the following tweet shows. 

Lapsus$-Microsoft-Hack statement

In this article, Microsoft explains at some length how the Lapsus$ attackers proceed. In the text desert, there is then a reference that Lapsus$ claims to have had access to Microsoft's repository and to have siphoned off data. The "beef" is found in the following passage:

Our investigation has found a single account had been compromised, granting limited access. Our cybersecurity response teams quickly engaged to remediate the compromised account and prevent further activity. Microsoft does not rely on the secrecy of code as a security measure and viewing source code does not lead to elevation of risk. The tactics DEV-0537 used in this intrusion reflect the tactics and  techniques discussed in this blog. Our team was already investigating the compromised account based on threat intelligence when the actor publicly disclosed their intrusion. This public disclosure escalated our action allowing our team to intervene and interrupt the actor mid-operation, limiting broader impact.

The internal investigation found that a single account had been compromised, granting limited access. Microsoft's cybersecurity response teams would have acted quickly to clean up the compromised account and prevent further activity. And Microsoft does not rely on secrecy of code as a security measure, and viewing source code does not increase risk, according to the statement from Redmond. But if developer certificates have been stolen, as they say, that wouldn't be so funny, I guess. The colleagues from Bleeping Computer also have their thoughts on this.

Similar articles:
Ubisoft hacked by Lapsus$ cyber gang (March 2022)
Cyber attacks on Nvidia and McDonalds (Feb. 25, 2022)
Samsung bestätigt Hack, Quellcodes durch Lapsus$ geleakt
Lapsus$ allegedly publishes source code of Microsoft Azure, Bing and Cortana
Authentication service OKTA hacked by Lapsus$?


Cookies helps to fund this blog: Cookie settings
Advertising


This entry was posted in Security and tagged . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *