Most ransomware groups actively seek publicity. Leak portals, countdown clocks, and intimidating names are common parts of their strategy. DeadLock followed a very different model. The group was first observed in June 2025 and spent months conducting private, one-to-one extortion negotiations through the Session messenger. It operated without a public leak site and avoided publicly naming or shaming affected organizations until researchers eventually brought its activity into focus. Cynet’s CyOps team examined a recovered DeadLock sample to determine how the ransomware functions and how its tactics have changed over time.
A ransom note that doubles as a product roadmap
The evolution of DeadLock is particularly visible in the way its ransom note changed over time.
- June 27, 2025 (v1): The initial version focused exclusively on encryption. It contained no claim that data had been stolen.
- July 17, 2025 (v2): The note was revised to include claims of data theft, indicating DeadLock’s transition toward a double-extortion model.
- August 12, 2025 (v3): The message developed into something resembling a complete “customer service” offering. It promised victims a list of files, evidence that stolen data had been deleted, details about how the compromise occurred, security recommendations, and an assurance that the organization would not be attacked again. This version also added an accompanying HTML file with an integrated chat function.
- February 2026 onward: The HTML component later expanded into a three-tab victim portal containing About, Chat, and Blog sections. In practice, this moved both DeadLock’s negotiation interface and its leak operation directly onto the compromised system.
How DeadLock operates on a host
DeadLock is a 32-bit Windows executable built to reduce its static footprint by resolving important functionality dynamically at runtime. Its imported APIs are associated with sandbox and timing checks, memory-mapped file operations, low-level I/O, management of processes and services, and enumeration of storage volumes.
The executable also includes functionality related to SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, and SeTakeOwnershipPrivilege. This indicates that DeadLock may increase the privileges assigned to its token before beginning the encryption process.
In Cynet’s analysis environment, DeadLock launched through a self-deleting batch file and inspected storage beyond the drives normally visible to a user. The ransomware assigned the normally hidden System Reserved partition to drive letter Z: and placed its recovery HTML file on that volume. This behavior confirmed that DeadLock’s volume-enumeration capabilities extend to system partitions rather than being limited to ordinary user-accessible drives.
Files affected by the encryption process are renamed with a victim-specific identifier and the .dlock extension. DeadLock additionally creates a plaintext ransom note and an interactive HTML portal. It is also capable of changing the desktop wallpaper and replacing the icon associated with encrypted files.
Detection
Cynet executed the DeadLock sample with prevention functionality disabled and the platform operating in detection mode. This configuration allowed the ransomware to complete its entire execution chain while Cynet recorded the resulting activity.
Several detection technologies were triggered during execution. Cynet’s antivirus engine detected the malicious executable. Its Unauthorized File Operation mechanism separately identified suspicious file activity involving the .dlock extension, including the creation of an encrypted file within the EFI boot partition.
Patience produced results
DeadLock’s limited public visibility did not mean that the operation itself was inactive. The Blog section included in its HTML victim portal provided Cynet with direct insight into the group’s previous extortion activity. At the time the sample was analyzed, the portal contained 29 pages documenting 87 victims from multiple industries across the EU and the United States. Every listing contained the affected organization’s name, a description, a timestamp, and a link to leaked information.
This patient and controlled operating model appears to have been effective. DeadLock accumulated a substantial number of victims despite functioning as a closed group with no publicly known affiliate program. At the same time, it received considerably less attention than ransomware operations that depended on publicly accessible leak sites. The increasingly advanced victim portal also indicates that DeadLock used its period of lower visibility to improve and mature its operating model rather than remaining static.
Key takeaways for defenders
- Monitoring abnormal privilege use. DeadLock includes functionality associated with SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, and SeTakeOwnershipPrivilege. The use of these privileges by a process with no legitimate operational need for them should be considered grounds for investigation.
- Coverage of hidden and system partitions. DeadLock accessed the System Reserved partition and stored ransom-related content on it. File monitoring and detection controls therefore need coverage beyond conventional user-data volumes.
- Unexpected Session communication as a potential incident indicator. DeadLock has made extensive use of direct communication through Session instead of relying primarily on traditional public extortion infrastructure.
- Behavioral detection in addition to signature-based controls. DeadLock resolves functionality dynamically and uses anti-analysis techniques. As a result, behaviors such as privilege modification, volume mounting, unusual file creation, and large-scale encryption provide particularly valuable detection signals.
- Resilient backup architecture. DeadLock has been mapped to techniques intended to inhibit system recovery. Offline or immutable backups therefore remain important because ransomware executing on an endpoint should not be able to alter or destroy them.
DeadLock demonstrates why ransomware monitoring cannot rely exclusively on observing public leak sites. A carefully managed operation can reach considerable scale before attracting significant outside attention.
Infrastructure evolution
DeadLock has also continued to modify its supporting infrastructure. Microsoft later reported that the ransomware’s HTML recovery application is capable of retrieving proxy addresses used for victim communications through Polygon smart contracts. This design enables the operators to change the proxy by modifying blockchain-hosted data instead of replacing domains exposed to victims. As a result, the communication infrastructure becomes more resilient to disruption.
Earlier research from Group-IB, reported by The Register, had already documented DeadLock’s use of Polygon smart contracts to hide and rotate its proxy infrastructure. Microsoft’s subsequent analysis broadened that understanding by describing blockchain-backed resources that support both communication channels and leak-related operations.
This development is consistent with the broader trend identified in Cynet’s analysis. DeadLock continues to invest in making its overall extortion ecosystem more difficult for defenders to disrupt.
