Blog home DeadLock ransomware: Breaking down a Rust-based encryptor with decentralized recovery infrastructure Search Research August 10 20 min read DeadLock ransomware: Breaking down a Rust-based encryptor with decentralized recovery infrastructure By Microsoft Threat Intelligence / 1x Share Link copied to clipboard! Tags Credential theft Extortion Ransomware Windows Threats intelligence Cybercrime Ransomware Content types Research Products and services Microsoft Defender Microsoft Defender for Cloud Apps Microsoft Defender for Endpoint Topics Threat intelligence In this article Pre-encryption Encryption Post-encryption Defending against DeadLock ransomware Indicators of compromise 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. Figure 1. DeadLock icon for encrypted files 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: Figure 2. Service stop list 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: Figure 3. Process stop list 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 D