DeadLock ransomware: Breaking down a Rust-based encryptor with decentralized recovery infrastructure

What Happened

A new type of ransomware called DeadLock has been discovered. It locks victims' files and also steals their data, threatening to publish it if the victim does not pay. What makes DeadLock unusual is how it communicates with victims: instead of using traditional websites that can be shut down by law enforcement, it stores its configuration on a blockchain (a permanent public database) and uses a privacy-focused messaging app called Session for negotiations. This makes it much harder to disrupt. The ransomware is designed to avoid encrypting files on computers in Russia and neighboring countries, suggesting the operators are based in that region. It also carefully manages computer resources during encryption to avoid triggering security alerts. Over 80 organizations have been listed as victims since mid-2025. Organizations should ensure their security tools are active, maintain offline backups, and train staff to recognize the initial access methods that ransomware groups use to get into networks.

Key Takeaways

• DeadLock is a Rust-based ransomware using decentralized infrastructure: Polygon blockchain smart contracts for configuration storage, Session messenger for encrypted victim communication, and Wasabi S3 for data leak hosting
• The encryptor implements resource-aware throttling that pauses file dispatch when memory usage exceeds 29% or CPU load exceeds 70%, maintaining system responsiveness to avoid behavioral detection
• DeadLock uses a hybrid cryptographic scheme combining Curve25519 ECDH key exchange with XChaCha20 stream cipher encryption, using NaCl crypto_box for key encapsulation with per-file ephemeral keypairs
• The malware implements language-based geofencing that exits without encrypting if the system language matches CIS or select Middle Eastern countries, and clears all Windows event logs via three complementary methods
• DeadLock has been deployed by affiliates of the Lynx and INC ransomware ecosystems and has published over 80 victims on its data leak site since July 2025

Affected Systems

• Windows (Vista and later for primary wallpaper path)
• Windows XP (alternate wallpaper path)

Vulnerabilities (CVEs)

None identified.

Attack Chain

1. Initial Access: DeadLock ransomware deployed by affiliates of Lynx and INC ransomware ecosystems with elevated privileges
2. Execution: Encryptor decrypts embedded XOR configuration, checks language geofencing against CIS countries, enables debug/restore/backup privileges, empties recycle bin, terminates security tools and services, clears all Windows event logs
3. Impact: Encrypts files using hybrid Curve25519/XChaCha20 cryptography with resource-aware throttling (pauses if memory >29% or CPU >70%), appends .dlock extension, implements tiered partial encryption based on file size
4. Post-encryption: Deploys text ransom notes (HOW_RECOVER) and HTML recovery chat (RECOVERY_CHAT), sets custom BMP wallpaper, self-deletes binary via batch script
5. Extortion: HTML recovery chat retrieves proxy URL from Polygon blockchain smart contracts, routes encrypted messages through Session messenger network, provides browsable access to leaked data on Wasabi S3

Detection Availability

• YARA Rules: No
• Sigma Rules: No
• Snort/Suricata Rules: No
• KQL Queries: No
• Splunk SPL Queries: No
• EQL Queries: No
• Other Detection Logic: No
• Platforms: Microsoft Defender Antivirus, Microsoft Defender for Endpoint, Microsoft Defender for Cloud Apps

Microsoft Defender Antivirus detects this threat as Ransom:Win32/Deadlock.*. Microsoft Defender for Endpoint generates alerts for ransomware behavior, wallpaper changes, backup deletion, and data exfiltration. No custom YARA, Sigma, Snort, Suricata, KQL, SPL, or EQL rules are provided in the article.

Detection Engineering Assessment

Required Log Sources

• Sysmon Event ID 1 (Process Create)
• Sysmon Event ID 11 (File Create)
• Sysmon Event ID 13 (Registry Value Set)
• Sysmon Event ID 4 (Sysmon Service State Changed)
• Windows Security Event Log (before clearing occurs)
• EDR process telemetry
• DNS resolution logs

Hunting Hypotheses

Control Gaps

• Traditional network-based C2 detection would not identify blockchain-based configuration retrieval via public Polygon RPC endpoints
• Event log clearing eliminates post-compromise forensic evidence from Windows Event Logs, requiring EDR or Sysmon telemetry that may be forwarded off-host
• Security tool termination (windefend, msmpeng, smartscreen) reduces real-time detection capability if tamper protection is not enabled
• Decentralized Session messenger communication bypasses traditional network communication monitoring and domain-based blocking
• Resource-aware throttling maintains normal-looking resource consumption patterns, reducing the likelihood of behavioral detection based on CPU or memory spikes

Key Behavioral Indicators

• Files with .dlock extension appearing on disk in multiple directories
• Creation of registry key HKLM\SOFTWARE\Classes.dlock\DefaultIcon
• Registry modifications under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels setting Enabled to 0
• Processes enabling SeDebugPrivilege, SeRestorePrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege simultaneously
• Randomly named .cmd files (8 uppercase characters) created and executed via ShellExecuteW with runas verb
• Custom .ico file written to C:\ProgramData\ directory
• BMP wallpaper file written to C:\ProgramData\ and registered in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Wallpaper
• Multiple Windows services set to DISABLED start type in rapid succession including windefend, vss, swprv, wbengine
• Mass process termination targeting security tools, backup applications, and remote access tools
• Recycle bin emptied silently on all drives via SHQueryRecycleBin and SHEmptyRecycleBin APIs

False Positive Assessment

Recommendations

Immediate Mitigation

Infrastructure Hardening

• Consider implementing network segmentation to limit the blast radius of ransomware encryption, particularly separating critical servers and backup systems from general workstation networks.
• Evaluate whether your organization's DNS filtering can alert on or block queries to public Polygon RPC endpoints, though this may impact legitimate blockchain application usage.
• Consider maintaining immutable or offline backups that cannot be modified or deleted by endpoint processes, as DeadLock targets VSS, backup services, and recycle bins.
• If supported by your SIEM, consider forwarding Windows Event Logs and Sysmon telemetry to a centralized, append-only log store to preserve forensic evidence even if the malware clears local logs.

User Protection

• Consider enabling EDR in block mode so that malicious artifacts are remediated even when the primary antivirus is in passive mode or has been disabled by the attacker.
• Evaluate whether automatic attack disruption or equivalent automated containment features are available in your XDR platform to contain attacks in progress and limit impact.
• Consider enabling attack surface reduction rules or equivalent endpoint hardening policies, particularly rules that block process creations from PSExec and WMI commands, and rules that block untrusted executables.

Security Awareness

• Consider incorporating training on the initial access vectors used by Lynx and INC ransomware affiliates into existing security awareness programs, as DeadLock is deployed by these affiliate ecosystems.
• If applicable, remind users not to approve unexpected UAC elevation prompts, as DeadLock attempts privilege elevation via randomly named .cmd files that trigger UAC consent dialogs.
• Consider educating incident response teams on the decentralized infrastructure model used by DeadLock, including Polygon blockchain smart contracts and Session messenger, as traditional takedown approaches may be less effective against this architecture.

MITRE ATT&CK Mapping

Additional IOCs

• Registry Keys:
  • HKLM\SOFTWARE\Classes\.dlock\DefaultIcon - Registry key created by the malware to associate a custom .ico file with the .dlock encrypted file extension. The Default value is set to the path of the dropped icon file.
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Wallpaper - Registry key set by the malware to persist the custom ransom BMP wallpaper as the desktop background.
  • HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels - Registry path where the malware enumerates all sub-keys to disable event logging. For each channel, it sets Enabled to 0 and overwrites ChannelAccess with a restrictive SDDL string.
• Command Lines:
  • Purpose: Privilege elevation via UAC consent prompt using a randomly named .cmd file (8 uppercase characters) executed with ShellExecuteW and the RunAs verb. Retries up to 10 times if the user denies the prompt. | Tools: cmd.exe, ShellExecuteW | Stage: Pre-encryption | ShellExecuteW(..., "runas", <random>.cmd, ...)
  • Purpose: Self-deletion of the malware binary after encryption completes. The batch script loops until the binary is deleted, then removes itself. | Tools: cmd.exe | Stage: Post-encryption cleanup | if exist <malware_path> (del <malware_path>) else (goto e)