SafePay Makes Backup Recovery an Incident-Response Problem
A backup is useful only if the organisation can still reach it, trust it and restore from it after an intrusion. The October SafePay advisory makes that distinction concrete: investigators describe attackers stopping Windows shadow-copy services and resetting network storage that held backups. Recovery planning therefore has to cover the backup platform and its administration, alongside the machines it protects.
The joint advisory published on 20 October draws on FBI investigations as recent as August 2026. Its authors include the FBI, CISA, the US Secret Service, Germany’s Landeskriminalamt Rheinland-Pfalz, the UK National Crime Agency and the North West Regional Organised Crime Unit. They assess that SafePay actors, active since August 2024, have compromised at least 600 separate victims across multiple critical infrastructure sectors. That is a cumulative agency assessment, not a count of new October attacks or an independently verified total.
Recovery systems are part of the intrusion
According to the advisory, SafePay operators combine stolen or guessed credentials with exploitation of known vulnerabilities. Once inside, they obtain administrative access, move through the network and use legitimate remote-management and file-transfer tools. Investigators describe data theft before encryption, followed by ransom demands and pressure involving threatened publication. A successful restore would therefore address availability without resolving the separate consequences of stolen information.
The backup observations deserve their own response. The agencies report factory resets of network-attached storage containing backups and, in some cases, deletion of all network-connected backups. They also describe interference with Windows Volume Shadow Copy Service. These are reported techniques, not a claim that every victim lost every copy. Nor does a factory reset establish that all underlying data has been securely erased. The operational question is which recovery copies and management accounts remained beyond the attacker’s reach.
Five older flaws, with different exposure conditions
The advisory names five vulnerabilities in Cisco, Veeam and SonicWall products. Their presence in an October threat report does not make them newly disclosed flaws, and the list does not mean every affected product was involved in every intrusion. Match the precise product, installed build and enabled features to the vendor’s advisory before deciding whether an estate is exposed.
Cisco’s CVE-2020-3259 is an information-disclosure issue in ASA and Firepower Threat Defense web services. Cisco limits the affected configurations to specified AnyConnect and WebVPN features on vulnerable releases; Firepower Management Center is excluded. Software fixes exist, but Cisco lists no workaround for this flaw.
The separate Cisco issue, CVE-2023-20269, needs particularly careful wording. Cisco says it can facilitate brute-force activity or access through a clientless SSL VPN session under specified conditions. It is not a direct authentication bypass: establishing that session requires valid credentials, including a valid second factor where MFA is configured. The clientless route applies to ASA 9.16 and earlier with the relevant settings; FTD does not support that route.
Veeam’s CVE-2023-27532 concerns its core backup service, used by both Backup & Replication and Cloud Connect. An unauthenticated attacker within the backup network perimeter can obtain encrypted stored credentials and potentially gain access to the backup host. Veeam’s temporary TCP 9401 restriction is specifically for an all-in-one appliance without remote backup infrastructure components. It should not be converted into a universal instruction to block that port across every deployment.
Veeam also describes CVE-2024-40711 as permitting unauthenticated remote code execution. Its September 2024 bulletin identifies Backup & Replication 12.1.2.172 and earlier version 12 builds as affected, with the correction starting in 12.2.0.334. That historical fix floor is not a recommendation to install an old build today. Choose a currently supported release suitable for the deployment and check the vendor’s complete upgrade guidance.
SonicWall’s CVE-2024-40766 affects SonicOS management access and SSL VPN, with generation-specific affected and fixed versions. Its guidance combines upgrading affected products with restricting management and VPN exposure. It also calls for password changes for locally managed SSL VPN accounts on Gen 5 and Gen 6 firewalls, plus MFA and login monitoring. Unsupported appliances need an explicit replacement decision: the advisory says some end-of-life units will receive no software update.
Protect the route back to service
The joint advisory recommends offline backups, regularly tested recovery, and encrypted, immutable copies covering the infrastructure needed to restore operations. It also recommends multiple copies kept physically separate or appropriately segmented. Translate those recommendations into a recovery inventory: identify the data, configurations, keys and supporting services needed, who can administer each copy, and what evidence shows that a restore works. A successful backup job alone cannot answer those questions.
Separate administration matters as much as a second storage destination. If the same compromised accounts can delete both production data and the recovery copies, placing them on different devices may leave a common failure path. Review privileges, remote access and network reachability with the teams responsible for those systems. Treat immutability as a property to verify for the actual repository and retention settings, rather than an assurance inferred from a product label.
Contain the incident before declaring recovery
Where an intrusion is suspected, the agencies recommend identifying and isolating compromised systems, collecting enough evidence to establish scope, and using that understanding to guide eviction. This includes compromised accounts and devices, not just encrypted files. Their sequence allows hunting and response to overlap; it does not mean leaving an active attacker undisturbed until every question is answered.
Plan restoration around a sufficiently understood incident and known recovery dependencies. Preserve relevant logs and evidence through the organisation’s incident-response process, and verify which accounts, remote-management tools and backup services the attacker could use. Legitimate tools are not malicious simply because they appear in this advisory. Likewise, its historical network indicators need corroboration with current telemetry, rather than automatic assumptions about an address’s present owner.
The useful test is whether the organisation can demonstrate a controlled return to service while accounting for persistence, credentials and possible data theft. Patching closes known routes, and backups can restore data, but neither alone establishes that an intrusion has ended. The SafePay report provides a reason to join those checks into one recovery decision.
