Hellcat Threat Actor Profile: Jira Credential Theft

Hellcat turned old infostealer logs into a repeatable way into corporate Jira servers, then extorted organisations with the project data, tickets and source code it found there. This profile covers the group as reported between late 2024 and spring 2025 by the security vendors whose own research documented it (Hudson Rock, SentinelOne and Cato Networks), by the victim organisations' public confirmations as reported in the press, and by ThaiCERT. No government advisory dedicated to Hellcat was found when this page was checked in November 2026, and MITRE ATT&CK has no group entry for it, so attribution here follows each vendor's wording and is described at group level only. The page is written for identity, collaboration platform and security operations teams who need to close the path the group used, not to study the group for its own sake.

Key takeaways

The signature move is a stolen Jira login. Hudson Rock describes exploiting Jira credentials harvested by infostealers as Hellcat's signature technique, and linked it to intrusions at Schneider Electric, Telefónica, Orange and Jaguar Land Rover.
The credentials were often old. In an April 2025 set of four claimed victims, Hudson Rock traced the logins to infostealer logs from 2022 and 2024 (Raccoon, RedLine, StealC and Lumma), and a second actor in the Jaguar Land Rover case claimed credentials dating to 2021 that were still valid.
Third-party accounts were part of the path. Hudson Rock reported that the Jaguar Land Rover login belonged to an employee of another company with third-party access to the Jira server, so an infected laptop the victim did not manage became the victim's problem.
Extortion led, encryption was secondary. SentinelOne describes Hellcat as a ransomware-as-a-service brand from mid-2024 with a small Windows encryptor, but the publicly confirmed incidents were data theft from ticketing and project systems followed by leaks and public pressure.
The fixes are identity hygiene. Enforced two-step verification or SSO on Jira, basic authentication turned off, rotation of any credential seen in an infostealer log, review of third-party accounts and alerting on bulk issue and user export break the documented chain.

Who they are

Hellcat (also written HellCat or HELLCAT) appeared on criminal forums in 2024. SentinelOne, in research published on 23 January 2025, describes it as a ransomware-as-a-service offering that emerged in mid-2024, run by operators it describes as senior members of the BreachForums community, and presented as a "reputable" brand in the crimeware economy. Cato Networks, writing on 28 January 2025, also describes a RaaS model with double extortion and public humiliation of victims, and lists critical infrastructure, government, education and energy organisations among its claimed targets in late 2024.

Item	What the sources say	Source
Name	Hellcat, HellCat, HELLCAT; reports also use "Hellcat ransomware"	SentinelOne, Hudson Rock, BleepingComputer
First seen	Mid-2024 as a RaaS brand	SentinelOne
Model	Ransomware-as-a-service with affiliates; double extortion	SentinelOne, Cato Networks
Related brand	SentinelOne found the Hellcat and Morpheus payloads were near identical, suggesting shared affiliates or a shared builder	SentinelOne
Leak infrastructure	Data leak site on Tor, with countdown timers for victims	SentinelOne, Hudson Rock
ATT&CK group ID	None as of November 2026	MITRE ATT&CK v20 (offline check)

Members have spoken to journalists under handles, and at least one member told BleepingComputer that a 2025 breach they claimed was not a Hellcat operation, which shows how loosely the brand and individual activity overlap. This page names no individuals. Treat any claim of attribution to Hellcat as the claimant's word unless the victim or a vendor's own research confirms it. See the Threat Actor Groups Guide for how vendor naming works and the Ransomware Groups Guide for the wider ecosystem.

Targeting and motivation

The motive is financial. The group picked organisations where a single collaboration platform held a lot of valuable material: project tracking, internal tickets, source code, invoices and contracts. Jira is attractive because, in Hudson Rock's words, it connects to many enterprise workflows and holds sensitive data; BleepingComputer notes that Jira instances often hold source code, authentication keys, customer information and internal discussions. That last point matters for identity teams, because secrets pasted into tickets turn a data theft into a second intrusion. See How to find secrets in Jira and Confluence.

SentinelOne reports that the operators said they focus on high-value "big game" targets and government entities. Victims reported in the public sources span manufacturing and energy management, telecommunications, automotive, IT services, scholarly publishing and online gaming, across Europe, North America and elsewhere. Sector matters less than whether an internet-reachable Jira server accepts a password alone.

Notable incidents

The table lists incidents where the victim confirmed a breach or where Hudson Rock tied the claim to specific infostealer data. Dates are as reported; data volumes are the attackers' claims unless stated.

When reported	Organisation	What was reported	Source
November 2024	Schneider Electric	Confirmed unauthorised access to an internal Jira project execution tracking platform; more than 40GB claimed; Hudson Rock matched the access to credentials on an employee machine infected by Lumma in October 2024	Schneider Electric Jira Breach 2024
January 2025	Telefónica	Confirmed a breach of its internal ticketing system; about 2.3GB of documents and tickets claimed; access with obtained employee credentials, after which passwords were reset	ThaiCERT
February 2025	Orange (Romanian operations)	Confirmed a cyberattack on a non-critical back-office application; the attacker claimed compromised credentials plus Jira and portal vulnerabilities, more than a month of access and about 6.5GB, and said it was not a Hellcat operation despite membership	BleepingComputer
March 2025	Jaguar Land Rover	Claimed by Hellcat with internal documents leaked; Hudson Rock traced access to infostealer-harvested Jira credentials of a third-party employee; a second actor then claimed access with credentials from 2021	Hudson Rock
March 2025	Ascom	Confirmed a breach of its technical ticketing system with business operations unaffected; about 44GB claimed	BleepingComputer
April 2025	Four organisations (publishing, IT services, communications, gaming)	All four tied by Hudson Rock to Jira credentials in infostealer logs from 2022 (Raccoon, RedLine) and 2024 (StealC, Lumma) that sat unused for weeks or months	Hudson Rock

The March 2025 Jaguar Land Rover intrusion is separate from the production shutdown that began at the end of August 2025, which a different group claimed; see the Jaguar Land Rover Cyberattack 2025. Do not merge the two when briefing leadership.

Tactics and techniques (MITRE ATT&CK)

ATT&CK has no Hellcat group entry, so the mapping below is NHI Mgmt Group's reading of the behaviour the sources describe, not a MITRE attribution. Upstream infostealer activity is listed because it is how the credentials were produced, even though the sources do not say Hellcat ran the stealers.

Stage	Technique (ATT&CK v20)	What the sources describe	Defensive anchor
Upstream	T1555.003 Credentials from Web Browsers	Raccoon, RedLine, StealC and Lumma logs holding Jira logins	EDR on managed and supplier devices; stealer log monitoring
Resource development	T1589.001 Gather Victim Identity Information: Credentials	Credentials taken from infostealer logs, some years old	Exposure monitoring tied to forced resets
Initial access	T1078 Valid Accounts	Logins to Jira with harvested employee and supplier credentials	Enforced 2SV or SSO with MFA; basic auth off
Initial access (claimed)	T1190 Exploit Public-Facing Application	Cato Networks and one Orange claim refer to exploiting Jira or portal flaws	Patch and reduce internet exposure of Jira
Collection	T1213 Data from Information Repositories	Bulk theft of issues, projects, attachments and user records; REST API scraping in the Schneider Electric case	Audit log alerting on bulk export and API volume
Impact	T1486 Data Encrypted for Impact	SentinelOne's analysis of a Windows encryptor that keeps original file names and extensions	Backup isolation; endpoint protection

SentinelOne describes the encryptor as a 64-bit Windows executable of about 18KB that skips system file types and the System32 folder, encrypts with the Windows cryptographic API, makes no persistence changes and drops a _README_.txt ransom note. Because file names and extensions stay the same, file-rename detections will not fire; content entropy and mass-write detections will. Indicators of compromise are in the SentinelOne report and change quickly, so take them from there rather than from this page.

How they abuse identities and credentials

Every confirmed incident above starts with an identity that should not have worked. Four identity weaknesses recur.

Password-only access to a collaboration server: Hudson Rock's recommendations start with MFA on all Jira accounts. Atlassian Data Center has built-in two-step verification, but enforcement is off by default.
Credentials that outlive the infection: logins from 2021 and 2022 stealer logs still worked in 2025. Hudson Rock advises treating an infostealer infection as a long-term risk, not a one-off clean-up.
Third-party identities with direct access: a third-party employee's Jira account, harvested from a device the victim did not manage, was enough. See the Third-Party Access Guide.
Service and migration accounts stored beside personal ones: the infected Schneider Electric machine also held credentials for accounts named cloud_migration and jira_migration. Non-human accounts with saved passwords on a laptop share the laptop's fate.

For the stealer side of this chain, read the Infostealer Threat Guide and the Lumma Stealer Guide. This page does not repeat them.

Detection and defence

Harden Jira and Confluence first

Atlassian Data Center: turn on two-step verification and enforce it. Atlassian documents enforcement for high-risk roles with the JVM property -Datlassian.authentication.2sv.enforcement.enabled=true and, from Jira 11.2 and Confluence 10.1, for all users with -Datlassian.authentication.2sv.enforcement.all.users.enabled=true. Test in non-production first, because enforcement can affect integrations.
Basic authentication: Atlassian notes that basic authentication is not protected by two-step verification and recommends disabling it. Move scripts to tokens owned by named service accounts.
Legacy login mode: the atlassian.authentication.legacy.mode property brings back a login form without two-step verification. Alert if it is ever set.
Atlassian Cloud: set two-step verification to Mandatory in an authentication policy for managed accounts, or enforce it at the identity provider when SSO is enforced. Existing sessions are not ended when enforcement starts, so revoke them after an exposure.
Exposure: put self-managed Jira behind SSO, VPN or an identity-aware proxy where possible, and apply Atlassian security updates promptly. See Jira Data Center Hardening and the Atlassian Cloud Security Guide.

Close the infostealer loop

Subscribe to an infostealer log or exposure feed and match it against corporate domains, Jira URLs and supplier domains that hold accounts on your systems.
On a match, reset the password, revoke sessions and tokens, and check the audit log for logins since the log date, not just since today.
Search back several years. The incidents above show credentials staying usable for three to four years.
Require suppliers with accounts on your collaboration tools to notify you of infected devices, and give their users SSO through your identity provider rather than local accounts.

The Infostealer Logs Monitoring and Response Guide covers feed choice and triage in depth.

What to log and alert on

Signal	Where	Why it matters for Hellcat-style intrusions
Successful login from new country, ASN or hosting provider for a Jira account	Jira audit log, proxy or IdP logs	Stolen credentials used from attacker infrastructure
Login by an account dormant for 90 days or more	Jira or IdP sign-in logs	Old supplier and staff accounts revived from stealer logs
High REST API request volume from one account, especially user search or issue search endpoints	Reverse proxy and access logs	Bulk scraping of users and issues
Bulk issue export or attachment download	Jira audit and access logs	Collection before extortion
Two-step verification disabled or unenrolled for a user	Jira audit log	Attempt to weaken controls
Company name on a leak site or forum	Threat intelligence or dark web monitoring	Often the first notice victims received

Metrics that show it is working

Two-step coverage: percentage of Jira and Confluence accounts, including supplier accounts, covered by enforced two-step verification or SSO with MFA (target 100%).
Basic auth exposure: number of accounts or integrations still using basic authentication (target zero).
Exposure response time: median hours from an infostealer log match to password reset and session revocation.
Dormant accounts: count of collaboration accounts with no login in 90 days that remain enabled.
Bulk export alerts triaged: percentage of bulk export or API volume alerts reviewed within one business day.

Responding to a suspected intrusion

Contain the identity: disable the account, reset its password, revoke sessions and personal access tokens, and do the same for any service account whose credentials might sit on the same device.
Scope the access: pull Jira audit and access logs back to the earliest infostealer log date for that account, and list projects, issues and attachments viewed or exported.
Hunt for secrets in what was taken: scan the accessed projects for API keys, passwords and tokens, then rotate everything found. See Credential Rotation at Scale.
Check for wider access: look for the same credentials on VPN, SSO and code hosting, and for Windows endpoints showing mass file writes without renaming.
Preserve evidence: keep audit logs, proxy logs, leak-site captures and any extortion messages for legal and regulator use.
Notify: assess personal data in the stolen records against breach notification rules, and inform affected suppliers and customers.

The Data Extortion Without Encryption Guide covers negotiation, leak monitoring and communications.

Common failure patterns

Two-step verification available but not enforced: the control exists in Jira, but enforcement is off by default and optional enrolment leaves the accounts attackers pick.
Resetting only after an incident: credentials were reset after a breach, not when the stealer log appeared, sometimes years earlier. Infostealer credentials without MFA were also the path in the Snowflake Breach 2024.
Supplier accounts outside the identity provider: local Jira accounts for supplier staff escape conditional access and offboarding.
Treating ticket systems as low-value: several victims described the system as non-critical, yet the stolen tickets held source code, contracts and customer data.
Secrets in tickets: credentials pasted into issues give the attacker a second way in after the first account is closed.
Leaving basic authentication on for scripts: it bypasses two-step verification entirely.

Framework mapping

Framework	Control	How it applies
NIST SP 800-53 Rev. 5	IA-2 Identification and Authentication (Organizational Users)	Multi-factor authentication on Jira and Confluence
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Reset credentials found in stealer logs; retire basic auth
NIST SP 800-53 Rev. 5	AC-2 Account Management	Disable dormant and supplier accounts
NIST SP 800-53 Rev. 5	AU-6 and SI-4	Review audit logs and monitor for bulk export
NIST CSF 2.0	PR.AA-01	Identities and credentials for users and services managed by the organisation
NIST CSF 2.0	DE.CM-01	Monitoring network services for adverse events

Practitioner checklist

Enforce two-step verification or SSO with MFA for every Jira and Confluence account, supplier accounts included.
Disable basic authentication and move integrations to tokens owned by named service accounts.
Alert if legacy login mode is enabled or a user's two-step verification is removed.
Match an infostealer exposure feed against your domains, Jira URLs and supplier accounts, and reset on every match.
Search stealer data back several years, not months.
Disable collaboration accounts with no login in 90 days.
Scan Jira and Confluence for secrets and rotate what you find.
Alert on bulk issue export, attachment download and high API volume per account.
Monitor leak sites and forums for your organisation's name.

Hellcat Threat Actor Profile: Jira Credential Theft, Extortion and Defences