Attackers are persistently targeting Jira accounts with stolen credentials. What can we learn from this trend?
Attackers are persistently targeting Jira accounts with stolen credentials. What can we learn from this trend?
Since late 2024, attackers have been targeting organizations using Jira, the project management tool, taking over user accounts using compromised credentials. This has resulted in six public breaches in five months where criminals made off with sensitive data and documentation, profiting by extorting the victims and selling the data on criminal forums.
What happened?
Six attacks where stolen credentials were used to compromise the victim’s Jira tenant have been reported since November 2024, all attributed to operators belonging to the HELLCAT threat group.
Affinitiv (March 2025): Attackers stole a database containing over 470k unique emails and 780k records from marketing data analytics provider Affinitiv.
Ascom (March 2025): Attackers stole 44GB of data including source code for multiple products, details about various projects, invoices, confidential documents, and issues from the ticketing system from global telecommunications provider Ascom.
Jaguar Land Rover (March 2025): Attackers leaked ~700 internal documents totalling several GBs of data, including proprietary documents, source code, and employee and partner data, from vehicle manufacturer Jaguar Land Rover. The breach was linked to credentials stolen by infostealers in 2021. A second threat actor is now alleged to have re-compromized Jaguar using the same credentials and achieved a much bigger breach of ~350GB.
Orange (February 2025): Attackers stole almost 12,000 files totaling close to 6.5GB, which includes 380k unique email addresses, source code, invoices, contracts, customer and employee information, from telecommunications provider Orange. The attacker allegedly had access to the systems for over a month before exfiltrating company data.
Telefonica (January 2025): Attackers stole 2.3GB of documents, tickets, and various data from telecommunications provider Telefonica.
Schneider Electric (November 2024): Attackers stole 40GB of data including 75k unique email addresses, from manufacturing provider Schneider Electric, demanding a ransom payment of $125k.
So, hundreds of gigabytes of data and thousands of breached records — all from logging in with a single set of stolen credentials for each victim. There are clear signs that these attacks are ramping up in frequency and impact too, with three of the breaches occurring in March alone.
These attacks all follow the same pattern, revolving around initial access to Jira accounts using compromised credentials. Once inside, the attacker has been reported to use integrated Atlassian tools like MiniOrange to scrape customer and employee data. After dumping the data, they attempt to extort a ransom payment for the deletion of the data, and when that fails, sell it on criminal marketplaces such as dark web forums and Telegram channels. HELLCAT is also responsible for a Ransomware-as-a-Service (RaaS) offering using a custom ransomware strain.
Why are attackers targeting Jira?
It’s a goldmine for attackers
Apps like Jira are a goldmine for cyber attackers. For organizations using it, Jira is a central technology that underpins core business workflows. It’s used for pretty much all aspects of project management across functions, meaning it:
Stores huge amounts of sensitive data, from strategic business initiatives to sensitive customer data.
Contains detailed information on IT infrastructure and architecture. It often acts as an issue tracker for vulnerabilities, and frequently contains credentials and secrets accidentally pasted into tickets, enabling lateral movement and further exploitation.
Has deep integrations with other Cloud and DevOps technologies like GitHub repos (also a frequent target for attackers), Bitbucket, Jenkins, CircleCI, AWS, Azure, etc.
Can be exploited using native functionality by, for example, creating automated workflows containing malicious scripts or deployments, or inserting malicious links into tickets to phish users in-app.
Also provides access to the broader Atlassian suite through a compromised Jira account, e.g. Confluence, Bitbucket, Trello, Opsgenie, etc.
Compromised credentials are waiting to be exploited
Stolen credentials were the #1 attacker action in 2023/24, and the breach vector for 80% of web app attacks. Not surprising when you consider the fact that billions of leaked credentials are in circulation online, and attackers can pick up the latest drop for as little as $10 on criminal forums.
The criminal marketplace for stolen credentials is booming, fuelled by an unprecedented rise in infostealer activity as attackers look to replicate the success of high profile breaches in 2024 such as the attacks on Snowflake customers — where 165 customer tenants and hundreds of millions of breached records were compromised using credentials dating found in infostealer credential dumps dating as far back as 2020.
Like Snowflake, attackers have clearly noticed that compromised credentials are a reliable way to access Jira accounts. And the more these attacks succeed, the stronger the signal for other attackers to look for insecure identities.
But wait: This isn’t just a Jira problem
If an organization isn’t relying on Jira, they’re probably using a product with similar functionality such as ServiceNow, Asana, Zendesk, Notion, Oracle, etc. These alternatives are an equally viable target for attackers.
Attackers are already targeting these apps — we recently saw ServiceNow servers being exploited by threat groups — but actually given that most organizations access ServiceNow as a cloud app, it’s easier to go the route of identity attacks. Remember when a security researcher logged into Microsoft’s ServiceNow tenant with stolen credentials, accessing 1,000s of support ticket descriptions and attachments, and 250k+ employee emails?
Jira and many apps like it, fall into a category where it’s a core business app, but isn’t as well-secured (or can’t be configured as securely) as full enterprise cloud platforms — increasing the likelihood that accounts are using weak, breached, or reused credentials, and have gaps in MFA coverage. Again, there are clear similarities with the attacks on Snowflake customers last year. And more recently, breaches like the theft of 6 million Oracle records (including passwords) provide plenty of fuel for attackers looking to take advantage of unsecured accounts.
Using Push data, we compared the posture of accounts that use a password to log in when organizations first begin using our platform.
Clearly, this isn’t just a Jira problem — and it won’t be long before attackers take advantage.
These stats are in the ballpark of our average findings from across all apps — with 2 in 5 identities using a password to log in AND missing MFA, rising to 4 in 5 when a password is the sole login method. Considering the fact that organizations are using hundreds of apps (220+ on average), there are many, many more apps that can be targeted in a similar way to Jira.
Preventing account takeover with stolen credentials
To ensure that your workforce identities can’t be compromised using stolen credentials, you need to:
Ensure MFA is configured for all user accounts.
Ensure employees are not using weak, breached, or stolen passwords.
Where possible, ensure users are using SSO to log in via your preferred identity provider (IdP).
This is a tricky problem to solve in Jira itself. Jira doesn’t provide the capabilities to enforce these controls — to get access to some of the required functionality, like being able to require MFA for all users within your tenant, enforce SSO logins, or see if a user has MFA enabled, you need Atlassian Access — a separate tier of identity management product for Atlassian. Even then, you can’t do things like centrally administer password resets.
And as we’ve pointed out — this isn’t just a Jira problem. Very few apps provide this level of identity visibility and control (even at the premium tier) — so what about when the next app hits the headlines?
You could ingest a compromised credential TI feed to get some visibility of what’s out there, but then you’re relying on asking every user with a breached password to change it (not really reliable or enforceable!). When we recently reviewed a range of TI feeds against our identity data set, we found that less than 1% of the data was valid — like looking for a needle in a haystack.
Prevent account takeover with Push
Thankfully, there’s a better way. Push provides layered controls to harden your workforce identities against credential attacks, as well as other methods of account takeover like MFA-bypass phishing and session hijacking. Our lightweight, browser-based solution can be deployed in minutes across your entire user base.
So when a core business app like Jira comes under fire, you can quickly take action to prevent account takeover.
Here’s how Push users can protect themselves against the threat of stolen credentials:
Step 1: Deploy MFA across all accounts
Whenever an application comes under heavy scrutiny from attackers, it’s a good idea to deploy MFA across all accounts as a first response action. Push enables you to quickly find and close MFA gaps by prompting the user to configure MFA when they log in to the app.
Step 2: Detect when accounts are using stolen credentials and trigger a password change
Push integrates with commercial TI feeds to see when your employees are actually using a breached password to log in to one of their accounts, eliminating manual triage. You can also bring your own TI feed to maximize its value.
When a stolen credential (or any other password vulnerability) is found, the next time they log into the app they will be prompted to change it via the strong password enforcement feature.
Step 3: Ensure employees are using SSO (and remediate ghost logins)
Once you’ve secured your accounts against the risk of immediate account takeover, you can harden them further by ensuring that accounts are using your preferred SSO method and IdP.
[Insight box: It’s not enough to have users adopt SSO, however. Local username and password accounts can continue to exist and be used alongside SSO unless specifically configured (and configurable) within the app. These local accounts are a form of ghost login, providing backdoor access to your business apps without needing to breach your locked-down IdP accounts used for SSO. This is why it’s important to have MFA set at the application level if local accounts are used — you can’t just rely on your IdP being securely configured.]
Once you’ve migrated to SSO, it’s best practice to have your employees remove these local accounts so they don’t lie dormant for attackers to take advantage of in the future. You can set an app banner for all users accessing the app, instructing them to log in using SSO, and to disable their local password once they’ve done so.
Protect and defend your entire identity attack surface
Push provides comprehensive identity attack detection and response capabilities across every app and workforce identity.
We stop attacks like MFA-bypass phishing, credential stuffing, password spraying and session hijacking using stolen session tokens. You can also use Push to find and fix identity vulnerabilities across every app that your employees use like: ghost logins; SSO coverage gaps; MFA gaps; weak, breached and reused passwords; risky OAuth integrations; and more.
If you want to learn more about how Push helps you to detect and defeat common identity attack techniques, book some time with one of our team for a live demo.
