DeadLock Ransomware: Attack Lifecycle, TTPs, IOCs, and Response

DeadLock is a Windows ransomware family that surfaced in mid-2025, combining file encryption with data theft under a double-extortion model. Deployments observed so far have been hands-on-keyboard rather than automated, and two documented techniques stand out: a Bring Your Own Vulnerable Driver (BYOVD) attack built on a signed Baidu antivirus driver, recorded in a late-2025 intrusion, and negotiation infrastructure whose address is stored and rotated through Polygon blockchain smart contracts, present in builds from August 2025 onward.

No public decryptor for DeadLock exists. This article is a standalone reference for incident response teams, MSPs, and security decision-makers. Contact professional incident response services if you suspect your systems are compromised.

DeadLock ransomware overview

Threat actor profile and evolution

DeadLock emerged in mid-2025. Samples recovered across its first months document that early stretch unusually well, and the year since has brought steady technical and extortion-focused change.

The earliest known sample carries a June 27, 2025 PE timestamp and first surfaced publicly on July 10, 2025; it was encryption-only in its own wording. It contacted victims through the Session messenger, offered a 1 MB test decryption, and demanded Bitcoin or Monero. Within weeks, a July build changed its note headline to claim data theft as well, marking the shift toward double extortion, although public reporting has not identified an exfiltration tool.

The August 2025 build was the turning point, introducing an HTML negotiation client, RECOVERY_CHAT.<ID>.html, and retrieving its proxy address from Polygon smart contracts rather than hardcoding it.

Then, after roughly eleven months of operating with no public leak site, the group surfaced one in June 2026, already populated with dozens of listings.

That leak site exists in two places at once. Clearnet sites and a Tor mirror carry the listings, and a "Blog" tab inside the ransom note renders the same posts from a second Polygon smart contract, with stolen files served through a Wasabi (S3-compatible) file browser.

Seizing a mirror closes one route without affecting the victim's local HTML copy. The page still needs a reachable Polygon endpoint to load the blog and resolve the chat proxy; the chat also needs that proxy to remain live, while images and leaked files depend on external hosting.

DeadLock appears to run no affiliate program of its own, and no affiliate rules or recruitment activity have surfaced. But it is not a single-actor tool either: public reporting places the encryptor in the hands of more than one group, including an affiliate connected to the Lynx and INC ransomware ecosystems, so the same payload arrives through different hands.

No code lineage to Babuk, Conti, LockBit, or any other leaked builder has been established. One trait is worth noting, though it settles nothing. The encryptor checks both the system and user interface languages and quietly self-deletes on seventeen locales, from Russian, Ukrainian, and Belarusian through Persian, Syriac, and two Arabic variants. Geofencing of this kind shows where the operators expect trouble, not where they are.

Otherwise, attribution stays low-confidence, and no law enforcement action against the group has been publicly reported to date.

Who DeadLock targets

DeadLock's claimed victims skew toward professional-services, manufacturing, and technology firms in Europe, with additional listings across the Americas, Africa, Asia, and the Middle East. Beyond those three, the sector mix thins out into energy and a long tail of others, and rankings vary with the taxonomy used. US organizations account for only a handful of listings so far, for reasons no public reporting explains.

The mix is unsurprising for a double-extortion operation: professional-services firms hold client material under contractual confidentiality, and manufacturing downtime creates immediate pressure to pay, so data theft and encryption each carry leverage on their own. Targeting otherwise looks financially opportunistic rather than sector-directed, with no observable exclusion of critical sectors.

One caution: the leak site went live already carrying dozens of listings, so the catalog likely mixes backfilled older cases with current activity, and its launch volume is not a monthly rate.

Leak-site listings are unverified attacker claims, not confirmed compromises, and should be corroborated against company disclosures, regulatory filings, or law enforcement confirmation before being treated as fact.

DeadLock attack lifecycle

The best-documented DeadLock intrusion ran for five days before encryption. That dwell time matters because the encryption event is the end of a long intrusion, not the beginning. The phases below reflect that incident.

Phase 1: Initial access

Investigators assessed that the operator entered using compromised valid accounts, but they did not identify how those credentials were obtained. No phishing template, exploited perimeter vulnerability, or initial access broker relationship has been publicly confirmed for DeadLock. This is the largest gap in the public record, and it means prevention keyed to a single entry vector would be guesswork. The vulnerability DeadLock does exploit, discussed below, is used after compromise, not to gain entry.

Phase 2: Persistence and remote access

Once inside, the operator established durable remote access:

• Remote Desktop enabled by setting the fDenyTSConnections registry value to 0, with an inbound firewall rule opened for TCP port 3389.
• The RemoteRegistry service started.
• AnyDesk installed silently with automatic startup, disabled updates, and an unattended access password.

AnyDesk was installed a day before encryption as an additional persistent channel, after RDP had already been enabled.

Phase 3: Discovery and lateral movement

In the documented intrusion, reconnaissance used built-in Windows tools:

• nltest to find domain controllers
• net localgroup /domain for privileged groups
• quser for active sessions
• ping to map reachable hosts

These are living-off-the-land binaries, which is why this phase generates almost no signal in tools tuned to detect malicious files rather than malicious sequences.

Movement between hosts was interactive, using Remote Desktop and the Microsoft Management Console rather than scripted propagation.

Phase 4: Defense evasion and the BYOVD attack

Before deploying encryption, the operator blinded endpoint defenses. Microsoft Defender real-time protection was switched off through SystemSettingsAdminFlows.exe, and then a custom loader named EDRGay.exe loaded a renamed vulnerable Baidu driver, DriverGay.sys (originally BdApiUtil.sys). Both files were dropped into the user's Videos folder.

Exploiting CVE-2024-51324, the loader opened a handle to the driver's device object, then passed the target process ID with IOCTL 0x800024b4, which the driver decodes as a terminate command and executes from kernel mode, where endpoint agents cannot defend themselves.

Because the driver is legitimately signed by Baidu, code-signing checks do not stop it: it has to be blocked from loading outright.

Phase 5: Inhibiting recovery

Recovery and forensics are dismantled on three fronts:

• A PowerShell script relaunches itself with administrative rights, tries to stop and disable every service not present in an allowlist, deletes all Volume Shadow Copies, then deletes itself.
• The encryptor separately carries a hardcoded service kill list that differs between builds: the documented 2025 build included entries for Veeam, Backup Exec, Acronis, Arcserve, and Carbonite; the current one directly targets Windows Volume Shadow Copy and backup services, among others.
• The current build wipes the Windows event logs and switches logging off, enumerating every registered channel through wevtapi.dll, including custom application channels a hardcoded list would miss, clearing each one, then disabling it in the registry.

Neither local restore points nor on-box event logs can be treated as a recovery or investigation plan against DeadLock: shadow copies are deleted, backup services are disabled, and the current build takes the event logs with it.

Phase 6: Encryption and extortion

In the intrusion above, the 2025 build dropped and ran an embedded .cmd loader in ProgramData, which re-launched the encryptor and deleted itself. The encryptor then hollowed into rundll32.exe and waited about 50 seconds to outlast sandbox detonations, using a custom C++ cipher seeded from the system clock.

The current build, documented publicly in August 2026, is a Rust rewrite. File content is encrypted with XChaCha20 under a unique per-file key; that key is then wrapped to the operator's public key using Curve25519 ECDH with XSalsa20-Poly1305, the NaCl crypto_box construction. Large files are only partly encrypted to run faster.

In both, files are renamed with a victim ID and .dlock. The current build skips system folders, executables, and boot files, so the machine stays bootable and the note readable. In the 2025 intrusion, the operator also replaced the desktop wallpaper and disabled the Windows command-line utilities, so a responder reaching the console may find the usual tools unavailable.

Negotiation then runs through the HTML client. Rather than hardcoding a proxy address, RECOVERY_CHAT.<ID>.html queries Polygon smart contracts, reads the current proxy URL from the blockchain, and relays Session messages through it. Because the operator updates that address through a smart-contract function, the group can rotate infrastructure without rebuilding or redistributing the ransom note, which makes blocking any single proxy host a short-lived defense.

Public analysis shows no evidence that DeadLock retrieves an encryption key from a command-and-control server; key material is generated locally. That is why isolating a host removes the operator's remote access to it but does not halt encryption already running.

Detection opportunities

The most durable detections key on behavioral sequences rather than static artifacts. High-value chains include:

• EDRGay.exe and DriverGay.sys written to disk, followed by a driver load and mass termination of security processes
• Elevated PowerShell stopping multiple services, then deleting all Volume Shadow Copies
• A local HTML file or browser reaching Polygon RPC endpoints, then posting to unusual PHP paths using Session methods such as get_snodes, poll, and store

The current build also throttles new encryption work when memory or CPU use crosses built-in thresholds, making detections that rely mainly on resource spikes less reliable.

Indicators of compromise and MITRE ATT&CK mapping

The HTML client resolves its infrastructure dynamically, so network indicators expire quickly and should be treated as historical unless confirmed live.

Some proxy hosts appear to be compromised legitimate websites rather than attacker-registered infrastructure, so validate network indicators before blocking them permanently.

Ready-made detection content already exists and is worth deploying before writing your own: rules published under Snort SIDs 65575, 65576, and 301358, plus four ClamAV signatures covering the loader, the driver, the shadow-copy deletion script, and the encryptor. Both are available at no cost, with the Snort rules distributed through the registered rule set. All of it dates from December 2025, before the Rust rewrite, so pair it with behavioral detection for the current build.

Host and file artifacts

Network and infrastructure

MITRE ATT&CK mapping

The mapping below follows the five-day intrusion documented above, except where a row says otherwise. Names follow MITRE ATT&CK v19.

What to do if DeadLock ransomware is active in your environment

If DeadLock is actively encrypting systems or has been confirmed in your environment, evidence preservation takes priority over restoration. Acting without a sequence can compress your recovery options and destroy forensic evidence needed for investigation and insurance claims.

1. Contain immediately. Isolate infected servers and endpoints at the network level rather than powering them off, because volatile memory may hold attacker tooling, session artifacts, and transient cryptographic material. Power a host down only as a last resort: it stops the spread but destroys memory evidence. Disable compromised accounts at the directory level and disconnect backup infrastructure before it is targeted. Isolation covers only that host and does not stop encryption already running on it; other compromised systems and cloud sessions need separate containment.
2. Preserve evidence. Do this before any remediation begins: capture memory on live systems, image affected disks, and export authentication logs before retention windows expire. Given the five-day dwell time, logs from the week before encryption can contain the earliest signs of it. Do not rely on on-host logs alone: because the current build wipes and disables the Windows event logs, the surviving record often lives in domain controller logs, firewall logs, EDR backend telemetry, and network flow data.
3. Scope backward and evict the operator. Investigate at least the five days preceding encryption, hunting AnyDesk installs, RDP authentications, domain reconnaissance, and driver loads. Then rotate privileged and service credentials, revoke remote access tokens, remove unauthorized AnyDesk, and close the firewall changes. Systems that saw hands-on-keyboard activity should be rebuilt rather than cleaned.
4. Assess data theft separately. The notes and leak site claim exfiltration, but no exfiltration tool or staging destination has been published. Review proxy, firewall, and file server telemetry across the full dwell period to determine what, if anything, actually left the network.

Can files encrypted by DeadLock be recovered?

As of August 2026, no public decryptor for DeadLock is available. It does not appear among the No More Ransom decryption tools, no vendor has announced a tool, and no confirmed cryptographic flaw has been published.

The 2025 C++ builds used a homegrown clock-seeded stream cipher, but the current build wraps a unique per-file key to the operator's public key through an established Curve25519 exchange, leaving no practical decryption path without that private key. Plan recovery as if the files are permanently encrypted.

Three recovery routes remain, in descending order of viability:

1. Rebuild and restore from clean backups: the copy must predate the initial intrusion, not merely the encryption. A snapshot created after AnyDesk was installed may restore the attacker's access along with the data. This is the most reliable path.
2. Selective recovery from cloud and off-box copies: SaaS version history, object-storage versioning, mail systems, replicas, and partner copies, each validated for integrity and last-safe-modification time. The encryptor shuts down the OneDrive, Dropbox, Google Drive, and ownCloud clients, which cuts both ways: it may stop newly encrypted versions from syncing upward, but it also means the newest copy in the cloud may predate the final hours of the intrusion. Check version history rather than assuming either way.
3. Forensic carving of deleted originals: this route rarely yields much against DeadLock because the encryptor writes and renames files in place, and the current build empties the recycle bin on every drive. Worth attempting only where unallocated space has not yet been overwritten.

Do not pay the ransom before consulting professionals. Decisions about ransom payment carry legal, operational, and financial consequences that should first be assessed with qualified legal counsel and an incident response team.

DeadLock's own note promises "Proof that all your data has been deleted" and a "Promise that we will not attack you again in the future," neither of which is verifiable or enforceable.

US organizations have two extra considerations. OFAC has warned that paying, or helping someone else pay, a sanctioned or blocked person can itself violate US sanctions, and DeadLock's attribution is far too thin to rule that out. Reporting the incident to the FBI's Internet Crime Complaint Center (IC3) or to CISA through StopRansomware remains voluntary for most organizations at the time of writing, but it is what opens the door to federal assistance.

Security checklist

The controls below are tied directly to DeadLock's observed tactics, not a generic ransomware checklist.

• Block the vulnerable driver explicitly. The built-in blocklist has been enabled by default since the Windows 11 2022 update, but it refreshes quarterly and does not cover every known vulnerable driver. Apply the current downloadable blocklist through App Control, enable memory integrity (HVCI), turn on the "Block abuse of exploited vulnerable signed drivers" ASR rule, and alert on new kernel driver loads (Sysmon Event ID 6). Other ransomware crews abuse the same driver.
• Constrain remote access. Restrict RDP to administrative jump hosts behind MFA, remove direct external exposure of TCP port 3389, and disable RemoteRegistry where it is not needed. Enabling RDP was the first persistence action observed in this incident.
• Control remote monitoring tools. Block unauthorized AnyDesk and other RMM software, allow only organization-approved custom clients, and restrict incoming sessions through AnyDesk's access control list to approved IDs. Legitimate AnyDesk was already deployed in the victim environment, so the tell was a new install, not the software's presence.
• Isolate and protect backups. Place backup infrastructure on a network segment whose credentials do not authenticate against the primary domain, and keep immutable or offline copies. DeadLock disables backup and recovery services and deletes existing shadow copies.
• Gate the encryption act itself. Enable Controlled Folder Access so untrusted processes cannot write to protected data folders, and separately enable the "Use advanced protection against ransomware" attack surface reduction rule, which uses client and cloud heuristics to block files that resemble ransomware. Test both in audit mode first. These are among the last controls standing between a missed intrusion and encrypted files, and both appear in the published mitigation guidance for DeadLock.
• Instrument for the sequence, not the hash. Every documented build carries a different hash, and the encryptor has already been rewritten from C++ to Rust, so alert on the chain: a new AnyDesk install, domain reconnaissance, Defender modification, a driver load, and shadow copy deletion. Enable tamper protection and PowerShell script block logging.

If DeadLock is active in your environment or you are working through the aftermath, containment and evidence preservation come first, and both get harder the longer they wait. Proven Data's ransomware recovery specialists provide 24/7 emergency response, forensic investigation of how the intrusion began, and coordinated restoration from validated clean copies.