Polymer

Download free DLP for AI whitepaper

Summary

  • Atlassian suffered a breach after attackers discovered employee credentials for a third-party app in a public code repository.
  • The threat group, SiegedSec, used the credentials to access the app and steal information relating to company property and employees.
  • The breach serves as a reminder to organizations to bolster data security in cloud apps.
  • Use tools like cloud data loss prevention (DLP) to discover and secure sensitive information in code repositories.

Atlassian received a nasty surprise late last week, after the hacking group SiegedSec leaked stolen company data on Telegram, including confidential floor maps of its offices in Sydney and San Francisco and, more concerningly, sensitive information about its employees.

Like quite a few recent breaches, the hacking group didn’t actually break into Atlassian’s IT infrastructure. Instead, they targeted one of the company’s third-party cloud software providers: Envoy. 

The whole incident offers some notable lessons around securing employee credentials, which all organizations would do well to learn from.

So, let’s dive in!

How did the Atlassian breach happen?

The breach came to light after SigedSec shared a public message, aimed at Atlassian, alerting them to the breach, stating: “”We are leaking thousands of employee records as well as a few building floor plans. These employee records contain email addresses, phone numbers, names, and lots more.”

Following the announcement, Atlassian jumped into action, investigating how the breach happened and what was stolen in further detail. Quickly, the company’s security team traced the breach to one of its third-party vendors, Envoy, which it uses for in-office functions. 

It shared a statement with the media explaining: “On February 15, 2023 we learned that data from Envoy, a third-party app that Atlassian uses to coordinate in-office resources, was compromised and published. Atlassian product and customer data is not accessible via the Envoy app and therefore not at risk.”

Note there’s good news for customers in there – no customer data was stolen or exploited. However, the same can’t be said for Atlassian employees, whose date was compromised. 

Enter Envoy, who adamantly denied its systems had been compromised. In a followup statement, Envoy said: “We’re investigating this right now and are not aware of any compromise to our systems. Our initial research shows that a hacker gained access to an Atlassian employee’s valid credentials to pivot and access the Atlassian employee directory and office floor plans held within Envoy’s app,” 

Further analysis by the two companies found that the hacking group discovered and used Atlassian employee credentials for Evoy’s app to steal the leaked data. 

How did the hacking group get their hands on these credentials? Well, after a little digging, Atlassian realized it had accidentally published the credentials in a public repository, making it all too easy for the attackers to find and abuse them to access the Evoy app. 

What can we learn from the Atlassian and Envoy breach?

There are two standout lessons from this security incident. Firstly, Atlassian should have brushed up on its code repository data security practices. Organizations should never store sensitive information, like credentials, PII or PHI, in public code repositories

However, it’s an extremely common practice. In fact, security researchers recently scanned GitHub for sensitive information like API keys, private keys, certificates, username and passwords, and found over two million sensitive records publicly exposed.

So, lesson one is to bolster your approach to data security in applications like GitHub, Bitbucket and Jira. Use tools like Polymer data loss prevention (DLP) to automate the process of discovering and securing sensitive information in these applications so that, even if they’re accidentally configured to public, threat actors won’t be able to find or steal a thing. 

The second lesson from this incident centers around improving credentials security. While Envoy hasn’t mentioned whether or not the hackers overcame multi-factor authentication (MFA) to access the app, we have a sneaking suspicion MFA wasn’t in action on this employee’s account. 

Organizations should take note. Using MFA is a simple but effective way to enhance application security. However, it’s also just a foundational step. On top of MFA, organizations should again look to cloud DLP to enhance data security in SaaS apps. 

For example, with Polymer DLP, should a hacker manage to compromise an employee cloud account, they still wouldn’t be able to get away with any data. Using the principles of zero trust, our tool enforces granular data security. It quickly analyzes a range of factors, like a user’s location, the context of their request, and more to determine whether the person in question is legitimate. 

If the tool believes the account has been compromised, it will block access to sensitive information and sound the alarm for the security team to take a further look. With Polymer DLP, your sensitive data stays safe, even if your employee credentials don’t. 
Curious to find out about your sensitive data sprawl in apps like Slack and GitHub? Try a free risk scan today.

Polymer is a human-centric data loss prevention (DLP) platform that holistically reduces the risk of data exposure in your SaaS apps and AI tools. In addition to automatically detecting and remediating violations, Polymer coaches your employees to become better data stewards. Try Polymer for free.

SHARE

Get Polymer blog posts delivered to your inbox.