← All actors

SafePay

Aliases: SafePay ransomware

Source profile review date: 2026-06-21

Added to the source registry: 2024-11-19 · Source snapshot: 2026-09-15

Source metadata is not independently verified. The registry date is not necessarily the first attack date. Source synopses are translated automatically where needed; the feed may contain outdated assessments.

Research status: Existing researched dossier

Locally generated translation; linguistic review is still pending.

Executive summary

SafePay is a rapidly growing double-extortion group that affects organizations through access, data diary, disruption and pressure via a leak site.

SafePay is particularly relevant through the combination of quick victim building, claims about large service providers, VPN--like access paths and data extortion. The file helps organizations to check whether remote access, identity, data access and recovery tools are sufficiently separate.

Latest five known victim claims

Loading stored claims…

    These are public claims attributed to the group, not independently confirmed breaches. Dates indicate publication or discovery, not necessarily the attack date.

    Management summary

    SafePay is part of the modern generation of ransomware groups that rely not only on encryption, but also on data storage, company disruption and publication claims. For organisations, the most important lesson is that the incident is often well advanced before a ransom note becomes visible. By then, accounts have been abused, systems explored, data selected and possibly already removed.

    The risk translation is concrete: an organisation is more at risk when external access, VPN, identity, endpoint protection and backup management are not sufficiently separated. SafePay-cases show precisely that an attacker with valid access and control rights does not need much exotic malware to cause much damage. Therefore, the defense should focus on early recognition of abnormal access and data movement.

    For governance and security teams, SafePay is a useful scenario for chain risk. Claims around large service providers show that ransomware impact does not stop at the first organization. If a supplier is hit, customer processes, data exchange and operational continuity can be indirectly affected.

    Grouping and development

    SafePay became public as a fast-growing ransomware and extortion name in 2024 and 2025. The group is linked to double extinction in public reporting: data is stolen, systems can be encrypted and victims are pressured through publication on a leak site.

    The group seems to be working most pragmatically, with the victim's value, access quality and sensitive data being more important than a specific sector. Public victimology includes production, care, education, government-related services and technology chains.

    Because SafePay is relatively young, technical attribution should remain cautious. Not every claim on a leak site proves the same initial access or payload. However, the behavior pattern is clear enough to prioritize defense measures: remote access, privilege usage, data exfil, security tampering and recovery.

    Operation and attack chain

    The known attack chain fits human-operated ransomware. The actor gets access via valid accounts, vulnerable or poorly monitored external access, possibly through VPN or previously captured credentials. Next comes internal exploration: domain structure, file shares, cloud links, management accounts, security tooling and backup environments are mapped.

    After reconnaissance, the actor searches for data with extortion value. Think of customer files, contracts, HR-data, financial information, technical documentation, e-mail archives and chain partners' data. Theft is often more important than encryption, because publication pressure also works when recovery is technically possible.

    SafePay reporting mentions manual adjustments to security settings. That's an important defense signal. If threat protection, EDR, antivirus or logging is suddenly disabled on servers or endpoints, it should be treated as a possible pre-ransomware phase. Then do not wait for file encryption.

    In the impact phase, encryption can be used, but the damage is also in disruption of critical platforms. Service providers may have downstream customers affected by this. Therefore, research should always look at access to management interfaces, service accounts, identity platforms, backups and systems that manage customer environments.

    Known IOCs and artifacts

    Public HardSafePay -IOC- lists are more limited than in some older families. Therefore, use mostly behavioural indicators: new or abnormalVPN- sessions, login from hosting providers, security-setting changes, massive file access, archiving, outbound data streams, remote management tools and attempts to hit recovery points or backup chains.

    Concrete artifacts are leak-site claims, ransom notes, encryption tracks, evidence files displayed to victims, security-tampering events and data-tasting folders. These artifacts must be linked to account, host, time and source by incident. A leak-site claim is extortion information, not complete technical truth.

    For retro-hunting, old indicators are useful, but structural detection should look mainly at behavior. SafePay is precisely an example of why only hash blocks are insufficient: operators use valid accounts, legitimate management protocols and normal infrastructure at a different time or with an abnormal purpose.

    Victim pattern and lessons

    Public claims around SafePay show wide sector interest. Ingram Micro was associated with SafePay and supply-chain impact in 2025; Conduent was also mentioned in reports on large amounts of stolen data. Such cases are relevant because they show that service providers and data-rich organisations are additional pressure points.

    The lesson for organizations is that chain dependency should be visible. Which suppliers can access data or systems? What accounts have wide access? Which platforms affect customers when they fail? Ransomware groups use this dependence as a leverage tool.

    An organization should not wait until its own name is on a leak site. Use victims in the same sector as scenario: what data would be most pressured, which external access paths exist, which management interfaces are accessible and how quickly can we prove whether data has been removed?

    How to arm yourself

    Limit VPN and remote access with MFA, conditional access, device compliance and tight logging. Remote accounts may not automatically have wide domain rights. Monitor impossible travel, new countries, new devices and sessions outside normal working hours.

    Make security-tampering hard visible. EDR- shutdown, Defender-policy changes, service stops and logging changes should escalate immediately. Control actions must run via jump hosts and not from random workstations.

    Protect data layer and backup layer separately. Detect bulk access, compression, Rclone-like behaviour, cloud sync abuse and access to backup repositoryes. Immutable or offline backups are only valuable when the accounts and management interfaces are not easy to handle with the regular domain.

    Indicators of compromise (IOCs)

    Indicators are historical observations, not proof of a current infection. Validate source, age and context before hunting or blocking; legitimate administrative tools can produce false positives.

    TypeValueSourceContext
    behaviordouble extortion with leak-site pressurepublic SafePay reportingCore model: data diary, threat with publication and possible encryption.
    behaviorsecurity protection or policy tampering before impactCheck Point / public case reportingRelevant detection logic aroundEDR /AV andWindows Security settings.
    caseIngram Micro claim and operational disruptionBleepingComputer / TechRadar reporting 2025Public claim; validate technical details by source.
    caseConduent data theft reportingpublic breach reporting 2025/2026Illustrative for equity and government chain risk.

    Sources

    Evidence and limitations

    Attribution describes the source assessment, not a verified identity. A leak-site listing alone does not prove encryption, data theft, a particular vulnerability or an affiliate relationship. Missing information is left explicit.