Fog Ransomware Profile Guide: VPN Access, Backup Attacks and How to Defend

Fog is a ransomware operation that walks in through remote access accounts the victim already has, goes straight for backup servers and virtual machine storage, and can finish encryption within hours. Arctic Wolf Labs first documented it in June 2024, after incident response cases that began in early May 2024 against US education and recreation organisations. Later reporting from Arctic Wolf, Sophos X-Ops and Symantec showed the operation moving beyond schools, using SonicWall SSL VPN accounts, a Veeam Backup and Replication vulnerability, phishing and, in one 2025 case, an unusual espionage-style toolset. This guide is for security operations, infrastructure and incident response teams who need to know what Fog intrusions look like and which controls break the chain. It works at group level only and relies on the reporting vendors' primary research.

Key takeaways

• Remote access credentials are the usual front door. Every early Arctic Wolf case began with compromised VPN credentials, and in later SonicWall cases Arctic Wolf could not confirm MFA on any compromised account.
• Backups are a primary target, not collateral damage. Operators harvested credentials from Veeam, deleted backups from object storage and removed volume shadow copies before encryption.
• The window can be under two hours. Arctic Wolf saw encryption 1.5 to 2 hours after initial access in some SonicWall intrusions, so detection has to happen at login and discovery, not at encryption.
• Two KEV entries matter most. CVE-2024-40766 (SonicWall SonicOS) and CVE-2024-40711 (Veeam Backup and Replication) are both on the CISA KEV catalogue with known ransomware use.
• The playbook overlaps with Akira. Arctic Wolf saw Akira in about 75% and Fog in about 25% of one cluster of SonicWall intrusions, so controls that stop one also stop the other.

Who Fog is and how the research describes it

Arctic Wolf Labs began tracking Fog deployments on 2 May 2024 and published "Lost in the Fog: A New Ransomware Threat" on 4 June 2024. In that first set of cases every victim was in the United States, roughly 80% in education and 20% in recreation. Arctic Wolf described Fog as a ransomware variant rather than a named group: the structure of the operators was unknown, shared code across payloads suggested a common source, and the evidence tying all cases to one actor was not conclusive. It assessed the operators as financially motivated.

The profile then widened. Between early August and mid-October 2024 Arctic Wolf saw at least 30 intrusions that began with SonicWall SSL VPN access; Akira was deployed in about 75% of them and Fog in about 25%, and Arctic Wolf said Fog victims were no longer concentrated in education. Sophos X-Ops tracked a cluster it calls STAC5881, in which compromised VPN access and exploitation of CVE-2024-40711 on Veeam servers led to Fog or Akira in several cases. In June 2025 Symantec described a May 2025 Fog attack on a financial institution in Asia that used tools rarely seen in ransomware cases and kept access after encryption, and it raised the possibility that espionage was a goal.

For how Fog fits among other operations, affiliate models and rebrands, see the Ransomware Groups Guide. The closely related operation is covered in the Akira Threat Actor Profile.

Initial access routes

All four reports start with something the victim exposed to the internet. Treat these as the routes to close first.

Arctic Wolf states it does not have definitive evidence that CVE-2024-40766 itself was exploited in the SonicWall cases; credentials obtained elsewhere, such as from earlier breaches, were not ruled out. The safe reading is that both patching and credential hygiene are required. Buying VPN access from brokers is a common route for ransomware operators in general; see the Initial Access Brokers Guide and, for appliance hardening, the Edge Device Security Guide.

Tactics and techniques (MITRE ATT&CK)

ATT&CK has no software or group entry for Fog as of November 2026, so the mapping below comes from the technique IDs and behaviour the reporting vendors published, checked against ATT&CK v20. Arctic Wolf's original mapping of Windows Defender being disabled used T1562.001, which ATT&CK v20 revoked; the current equivalent is T1685 Disable or Modify Tools.

Two details are worth noting for planning. First, Arctic Wolf saw no exfiltration in its first cases, but its October 2024 report describes data taken from HR and accounts payable folders going back up to 30 months, and Symantec saw 7-Zip archives and file sync tools in 2025. Plan for double extortion. Second, Symantec saw a service named SecurityHealthIron created days after encryption to relaunch a C2 tool, so recovery is not finished when the ransomware stops.

How Fog abuses identities and credentials

Almost every step in the published cases is an identity step. The table maps each to the identity control that would have changed the outcome.

For the credential mechanics see the Pass-the-Hash and Pass-the-Ticket Guide. For keeping the backup platform's own accounts out of reach, see the Backup Identity Isolation Guide and the Veeam Backup and Replication Hardening Guide.

Detection and defence

Because encryption can follow access within hours, the useful detections sit early in the chain. Arctic Wolf's own recommendations are to keep perimeter appliance firmware current, monitor VPN logins from hosting providers not expected in the environment, keep secure off-site backups and watch for common post-compromise activity on endpoints.

Signals to monitor

• VPN logins: successful logins from VPS or hosting ASNs, from new countries, or to local appliance accounts; logins outside working hours followed by internal RDP. See the VPN and Firewall Log Detection Guide.
• Discovery bursts: network scanners, AdFind, NLTest or share enumeration launched from a VPN-assigned address or a server that does not normally run them.
• Backup server activity: interactive logons to the Veeam server, PowerShell touching the Veeam credentials store (Arctic Wolf recommends script block logging, event 4104, to catch the strings Veeam-Get-Creds.ps1 uses), new local administrators, deletion jobs against backup repositories or object storage.
• Remote execution: PsExec service installs (system event 7045), SMBExec or Impacket patterns, and remote management tools such as AnyDesk appearing on servers.
• Defence changes: Microsoft Defender real-time protection turned off (Defender operational event 5001) on servers.
• Recovery inhibition: vssadmin shadow copy deletion, mass service stops, and large archive files or Rclone and sync clients appearing on file servers.

Hardening steps, in order

1. Close the front door this week: confirm SonicOS and Veeam versions against the vendor fixes for CVE-2024-40766 and CVE-2024-40711, enforce MFA on every VPN account, reset local appliance account passwords, and disable unused accounts.
2. Restrict remote access sources: block or flag VPN logins from hosting ASNs where there is no business reason, and limit appliance management interfaces to trusted networks.
3. Isolate backups: remove the backup server from the production domain, put immutable or offline copies in place, require MFA for the backup console and test a restore of a full virtual machine.
4. Remove credential reuse: deploy unique local administrator passwords, tier privileged accounts and limit logons to domain controllers and hypervisor hosts.
5. Tune detections: turn on PowerShell script block logging, alert on the signals above and test them in a purple team exercise using the ATT&CK IDs in this guide.
6. Rehearse response: run a tabletop where VPN access to encryption takes two hours; check who can disable VPN accounts and isolate the hypervisor tier out of hours.

Roll back carefully: blocking hosting ASNs can break legitimate cloud-hosted users or partners, so start in alert-only mode for a week, review hits, then enforce with an exception list.

Responding to a suspected Fog intrusion

The CISA, MS-ISAC, NSA and FBI #StopRansomware Guide advises isolating impacted systems immediately, taking the network offline at the switch level if several subnets are affected, coordinating out of band, and hunting for precursor access before restoring. For Fog specifically:

• Revoke remote access first: disable the VPN accounts involved, reset all local appliance accounts and terminate active sessions.
• Protect what is left of the backups: isolate the backup server and repositories before anything else is restored, and assume Veeam-stored credentials are compromised.
• Hunt for persistence after encryption: new local administrators, new services (Symantec's SecurityHealthIron example), remote management tools and C2 beacons.
• Assume data was taken: look for archives and sync tool traffic and start the notification assessment early.
• Preserve evidence: VPN appliance logs roll over quickly; export them before resetting the device.

The full process is in the Ransomware Response and Recovery Guide; for hypervisor encryption see the ESXi Ransomware Playbook and for a compromised backup platform see If your backup and cyber recovery platform is compromised.

Framework mapping

Common failure patterns

• MFA on the main VPN but not on local appliance accounts: the SonicWall cases used accounts local to the device, outside the central identity provider.
• Patching the firewall and stopping there: credentials taken before the patch still work; reset them after patching.
• Backup server joined to the production domain: once a domain admin hash is taken, the backup server and its stored credentials fall with it.
• Detection tuned for encryption: alerts that fire on mass file changes come too late when the whole intrusion takes two hours.
• Restoring before hunting: post-encryption persistence means a quick rebuild can hand access straight back.
• Treating Fog and Akira as separate problems: the overlap in access route and tooling means one control set covers both.

Practitioner checklist

• Confirm SonicOS and Veeam Backup and Replication versions are past the fixes for CVE-2024-40766 and CVE-2024-40711.
• Enforce phishing-resistant MFA on every VPN account, including local appliance accounts.
• Reset local VPN appliance passwords after patching and remove dormant accounts.
• Alert on VPN logins from hosting provider ASNs and new geographies.
• Take the backup server off the production domain and keep an immutable or offline copy.
• Deploy unique local administrator passwords and tier privileged accounts.
• Turn on PowerShell script block logging and alert on local account creation on servers.
• Alert on shadow copy deletion, Defender being disabled and PsExec service installs.
• Run a two-hour, access-to-encryption tabletop with infrastructure and backup owners.

Standards and references

• Arctic Wolf Labs: Lost in the Fog: A New Ransomware Threat
• Arctic Wolf Labs: Increased Fog and Akira Ransomware Activity Linked to SonicWall SSL VPN
• Sophos X-Ops: Veeam exploit seen used again with a new ransomware, Frag
• Symantec: Fog Ransomware: Unusual Toolset Used in Recent Attack
• CISA, MS-ISAC, NSA and FBI: #StopRansomware Guide
• Veeam: KB4649 Vulnerabilities Resolved in Veeam Backup and Replication 12.2
• CISA: Known Exploited Vulnerabilities Catalog
• MITRE: ATT&CK Enterprise Matrix

Related NHI Mgmt Group resources: Ransomware Groups Guide · Akira Threat Actor Profile · Backup Security and Immutable Backup Guide · Cybersecurity for Higher Education Guide · Edge Device Exploitation by Threat Actors Guide