Microsoft Threat Intelligence tracks DeadLock ransomware as an emerging financially motivated operation distinguished by its use of decentralized infrastructure to support victim communications and data leak operations. Its recovery ecosystem combines the Session messaging network with blockchain-backed services that store and deliver resources used throughout the extortion process. This architecture likely increases the resilience of portions of its communication, leak-hosting, and negotiation infrastructure, allowing DeadLock operators to recover from some disruption efforts while maintaining continuity for victims. Microsoft has observed DeadLock ransomware being deployed by multiple groups including an affiliate of the Lynx and INC ransomware ecosystems.
First observed in July 2025, DeadLock operators employ double extortion tactics, encrypting victim environments while threatening to publicly release exfiltrated data. As of July 2026, the operators have published more than 80 compromised organizations on their data leak site, called the DeadLock blog, with more than half of the claimed victims in Europe. Microsoft identified DeadLock ransomware impacting organizations across information technology (IT), mining, transportation and logistics, manufacturing, hospitality, consumer goods, and other sectors in Europe, Asia, North America, South America, and Africa.
The DeadLock encryptor includes a resource-aware throttling mechanism designed to maintain system responsiveness during encryption. In addition to its encryption capabilities, the ransomware also appears to implement language or country-based geofencing designed to avoid running in environments associated with former Soviet and Commonwealth of Independent States (CIS)-linked countries as well as select Middle Eastern countries, a pattern commonly observed among ransomware operators believed to operate from those regions. Together, these capabilities demonstrate how DeadLock combines established ransomware tradecraft with decentralized infrastructure designed to improve operational resilience.
In this blog, we present a technical analysis of the DeadLock ransomware encryptor, covering its execution flow, defense evasion techniques, encryption design, and post-encryption behaviors, including a decentralized recovery chat system. We also provide indicators of compromise (IOCs), Microsoft Defender detections, and mitigation guidance to help organizations defend against this threat and similar ransomware activity.
Pre-encryption
Configuration parsing
Before performing any malicious activity, the DeadLock encryptor decrypts an embedded configuration blob using XOR decoding with an 8-byte key.
Below are the malware’s configuration fields and their values.
| Field | Value |
| Victim UID | <redacted> |
| Malware public key | 03bf50bbf97c4e951e66ff12b689a37a3ce675b4921e254eae76da77573843e4a9 |
| Encryption rule | 1000,05052429880,025124288000,010524288000,F991114288000 |
| Language exclude list | Geofencing language IDs (see Language geofencing) |
| Process stop list | Processes to terminate (see Process and service termination) |
| Service stop list | Services to stop and delete (see Process and service termination) |
| File exclude list | Extensions and file names to avoid encrypting (see Directory traversal) |
| Directory exclude list | Pre-traversal filter with directories to avoid encrypting (see Directory traversal) |
| Sub-path Exclude List | Sub-paths to avoid encrypting during traversal (see Directory traversal) |
| Text ransom note | Full text ransom note content (see Ransom notes deployment) |
| HTML recovery chat | Full HTML/JS interactive chat page (see Recovery chat: Technical architecture) |
Language geofencing
As an early exit check, the malware queries the system’s default and user interface (UI) languages. If either language matches the exclude list in the configuration, the malware self-deletes immediately without performing any encryption.
The following languages trigger this exit behavior:
| LANGID | Language | Country |
| 1049 | Russian | Russia |
| 1058 | Ukrainian | Ukraine |
| 1059 | Belarusian | Belarus |
| 1064 | Tajik (Cyrillic) | Tajikistan |
| 1065 | Persian | Iran |
| 1067 | Armenian | Armenia |
| 1068 | Azeri (Latin) | Azerbaijan |
| 1079 | Georgian | Georgia |
| 1087 | Kazakh | Kazakhstan |
| 1088 | Kyrgyz | Kyrgyzstan |
| 1090 | Turkmen | Turkmenistan |
| 1114 | Syriac | Syria |
| 2072 | Romanian (Moldova) | Moldova |
| 2092 | Azeri (Cyrillic) | Azerbaijan |
| 2115 | Uzbek (Cyrillic) | Uzbekistan |
| 8193 | Arabic | Oman |
| 9217 | Arabic (Yemen) | Yemen |
Command-line processing and privilege elevation
The encryptor’s behavior branches based on command-line arguments and the current privilege level. If a target directory path is provided as the command-line argument, the malware skips all preparation steps and jumps directly to encryption. This feature allows the operator to invoke the encryptor with specific targets for focused encryption. If no sub-commands are provided and the process is already elevated, the malware proceeds normally through all execution phases.
The more interesting case occurs when no command-line argument is provided while the process is not elevated. In this scenario, the malware attempts to gain administrator privileges through a batch-script-based elevation technique. It generates a randomly named .cmd file (8 uppercase characters, such as ESYEKQSY.cmd) and executes it using ShellExecuteW with the RunAs verb, which triggers the Windows User Account Control (UAC) consent dialog. If the user denies the prompt, the malware retries up to 10 times before giving up and exiting.
During dynamic analysis, the sample did not successfully relaunch itself with elevated privileges. As a result, full pre-encryption preparation appears to require execution from an already elevated context. When invoked with a target path, the malware bypasses preparation and proceeds directly to encrypt accessible files. This behavior is specific to the analyzed sample and may change in later variants.
Token privilege escalation
When running with administrator privileges, the malware further expands its access by enabling SeDebugPrivilege, SeRestorePrivilege, SeBackupPrivilege, SeTakeOwnershipPrivilege, SeAuditPrivilege, and SeSecurityPrivilege. These privileges increase the malware’s ability to interact with system processes, protected files, and security-related settings, helping it overcome common access restrictions and maximize the scope of files and resources it can target during the encryption phase.
Recycle bin emptying
The malware silently empties the recycle bin on all drives without any UI or confirmation dialog, eliminating a potential source of file recovery for victims.
Custom icon registration
To visually brand encrypted files, the malware writes an embedded .ico file to C:\ProgramData\<UID>.ico and registers it as the default icon for files with the extension .dlock.
To associate the custom icon with encrypted files, the ransomware creates the HKLM\SOFTWARE\Classes\.dlock\DefaultIcon registry key and sets its (Default) value to the path of the dropped icon file.
Below is the malware’s embedded .ico file.
Process and service termination
Before starting encryption, the malware terminates processes and disables services that could interfere with file access or provide defensive capabilities. This approach ensures that locked files become accessible for encryption while simultaneously disrupting the environment’s ability to detect, respond to, or recover from the attack.
For services, the malware enumerates all active Win32 services and compares them against the stop list in the configuration. For each matching service, DeadLock sets its start type to DISABLED and sends a stop command to terminate that service. Notable targets include windefend (Windows Defender), vss/swprv/wbengine (Volume Shadow Copy and Backup services), mssearch, Hyper-V services (vmcompute, vmms), and Active Directory services (adws, ntds, kdc). Below is the full service stop list in the malware configuration:
For processes, the malware enumerates all running processes and terminates any matching its stop list while skipping its own process ID. Targeted processes include security tools (msmpeng, securityhealthservice, smartscreen), backup and cloud sync applications (onedrive, dropbox, googledrivefs, owncloud), remote access tools (anydesk, putty, mstsc, rustdesk), shell and system processes (explorer, powershell, taskmgr, cmd), and search/indexing services. Below is the full process stop list in the malware configuration:
Event log clearing
To eliminate forensic evidence, the malware employs three complementary methods that collectively ensure every event log channel on the system is cleared of existing entries, disabled from recording future events, and has its access permissions locked down:
- Direct clearing: Clears the following log channels via the classic Event Log API: Application, Security, Setup, Servicing, Eventlog, Forwarded Events, Windows PowerShell, and System.
- Registry-based disabling: Enumerates every sub-key under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels. For each channel, sets Enabled to 0 (disabling all future logging) and overwrites ChannelAccess with a restrictive Security Descriptor Definition Language (SDDL) string that limits access to SYSTEM, built-in administrators, and local admin.
- Modern API enumeration: Uses wevtapi.dll to enumerate all registered event log channel paths (including custom application channels not in the hardcoded list) before clearing each one.
By combining API-based clearing, registry manipulation, and full channel enumeration, the malware covers multiple log sources, including third-party application logs and custom diagnostic channels, to minimize existing forensic evidence on the infected device.
Directory traversal
To maintain system stability and ensure the victim can access ransom instructions, the malware excludes specific directories, file extensions, and file names from encryption. This selective encryption model is a common ransomware design pattern where the system must remain operational enough for the victim to receive instructions and facilitate payment.
Extensions and file names from the configuration’s file exclude list are skipped during encryption:
For directory processing, the malware uses a two-tier directory exclusion system applied at different stages of the encryption pipeline. Tier 1 provides rough filtering that saves significant time by avoiding traversal overhead, while tier 2 provides granular path-specific exclusions within directories that are traversed. Both prevent encryption, but they operate at different stages of the traversal pipeline.
In its pre-traversal phase (tier 1), the malware checked at the drive batch level before threads are spawned for traversal. If a top-level directory matches against the configured directory exclude list (\users\*\appdata, program files (x86)\, program files\, and programdata\), the entire tree is skipped without being walked.
In its during-traversal phase (tier 2), the malware checked the file name during recursive directory enumeration and applied to both subdirectories and files as they are encountered. In this tier, the directory and file names are checked against the configured sub-path exclude list below.
Encryption
Resource-aware throttling
One of the more distinctive aspects of the DeadLock encryptor is its resource-aware throttling mechanism, designed to keep the infected system responsive during encryption. The malware spawns a dedicated monitoring/dispatch thread per drive batch that acts as a gatekeeper for file encryption dispatch. Before dispatching each new file to be encrypted, this thread polls system resource utilization and checks against hardcoded thresholds:
- Polls memory and CPU idle before each file dispatch
- Calculates memory usage percentage and CPU idle percentage
- If memory usage exceeds 29% or CPU load exceeds 70% (idle < 30%), the dispatch thread pauses via a waitable timer and retries until resources return below thresholds
- Once thresholds are within limits, atomically sets a dispatch flag on the work queue and signals waiting encrypting worker threads
With this mechanism, worker threads already encrypting files are not interrupted, and only the dispatch of new files is gated. This means partially encrypted files are expected to complete, and the throttling manifests as reduced parallelism rather than stop/start behavior. This approach can prevent system hangs that would alert the user and reduce the likelihood of behavioral detection by maintaining normal-looking resource consumption patterns.
Thread architecture
For the encryption work itself, the malware spawns directory processing threads, with the thread count being 2 times the CPU core number. Each thread recursively traverses directories, dropping ransom notes and dispatching files for encryption. Individual file encryption threads are tasked with handling the actual cryptographic operations.
Cryptographic scheme
The DeadLock ransomware implements a hybrid cryptographic design that combines Curve25519 elliptic-curve cryptography with the XChaCha20 stream cipher for file encryption. Key encapsulation uses the Networking and Cryptography Library (NaCl) crypto_box construction, which pairs an asymmetric key exchange with authenticated encryption to securely wrap each file’s symmetric key.
| Layer | Algorithm | Purpose |
| File content encryption | XChaCha20 | Symmetric stream cipher |
| Key encapsulation | Curve25519 Elliptic Curve Diffie-Hellman (ECDH) + XSalsa20-Poly1305 | Asymmetric key wrapping (NaCl crypto_box) |
| Random generation | Windows CryptoAPI | All key material random generation |
The configuration’s operator public key 03bf50bbf97c4e951e66ff12b689a37a3ce675b4921e254eae76da77573843e4a9 is 33 bytes. The leading 03 byte is a SEC1 compressed point format prefix borrowed from Bitcoin/secp256k1. The malware validates this prefix byte against a lookup table that accepts 00, 02, 03, 04, and 05, mapping each to an expected key length.
After format validation, only the remaining 32 bytes are used in the actual Curve25519 ECDH scalar multiplication. This SEC1 prefix is non-standard for Curve25519, which natively uses bare 32-
