Atlassian's Response to the LAPSUS$ Okta Incident

[#1]

On March 22, identity and access management company Okta disclosed the account compromise of a third-party customer support engineer that occurred in January 2022. LAPSUS$ claimed responsibility for the hack and in an attempt to substantiate their claims, released screenshots of tools that would only be available to Okta employees. Those screenshots included a ticket from Okta’s Jira cloud instance accessed via Okta's own identity service.

Atlassian does not use Okta as an identity provider and while LAPSUS$ may have been able to access Okta’s Atlassian products, Atlassian has found no evidence of a compromise to our systems or cloud products. However, if your company has any integration with Okta, we ask that you reach out to Okta for more information regarding the disclosed incident and perform your own investigation if necessary.

We will continue to monitor the situation as it evolves and provide updates as necessary.

[Ed Letifov _TechTime - New Zealand_]

@Dan Hranj considering that the screenshot with the ticket clearly has ".atlassian.net" in the URL (see https://twitter.com/vxunderground/status/1506114493067186183/photo/2) I think it's a bit misleading to brand this an "internal Jira instance", or at least requires rephrasing, as it seems to imply that the instance is an on-premises one i.e. Server/DC not one in Atlassian Cloud.

[Leandro Rezende]

https://www.microsoft.com/security/blog/2022/03/22/dev-0537-criminal-actor-targeting-organizations-for-data-exfiltration-and-destruction/

There are some references in this article about LAPSUS$ using Jira and Confluence as a target in the companies.

[Dan Hranj]

@Leandro Rezende - Once an attacker gains a foothold in an environment they will naturally look for ways to move laterally, escalate privileges, and steal data and Atlassian products may be a target.

All non-cloud customers should strive to apply security patches to internal server and data center products in a timely manner.

We also encourage all customers to use strong passwords with two-factor authentication and restrict access to data with the principle of least privilege in mind.

[Ed Letifov _TechTime - New Zealand_]

Considering the fact that in this case the attacker allegedly could reset passwords and 2FA this last encouragement is really moot, since it would be the password and 2FA on OKTA side – both for Atlassian Cloud instances and Server/DC with SAML SSO app.

[Leandro Rezende]

Very important to have 2FA as a token (some Authenticator app, not message) with controls of trusted devices.