Most ransomware crews want attention. A leak site, a countdown timer, a threatening moniker. DeadLock took another approach. First seen in the wild in June 2025, the group ran a quiet, one-on-one extortion operation over Session messenger, with no public leak site and no naming and shaming, for months before researchers caught up with it. Cynet’s CyOps team analyzed a recovered DeadLock sample to understand how it operates – and how its approach has evolved.
A ransom note / product roadmap mashup
One of the clearest signs of that evolution is the ransom note itself.
- June 27, 2025 (v1): Pure encryption. No mention of stolen data.
- July 17, 2025 (v2): The note is rewritten to claim data theft, marking a shift to double extortion.
- August 12, 2025 (v3): The message becomes a full “customer service” pitch, promising a file list, proof of deletion, an explanation of the intrusion, security recommendations, and a pledge not to attack the victim again. It also introduces an HTML companion file with embedded chat.
- February 2026 onward: That HTML file evolves into a three-tab victim portal with About, Chat, and Blog sections, effectively bringing DeadLock’s negotiation channel and leak operation onto the compromised host.
What DeadLock does on a host
DeadLock is a 32-bit Windows executable designed to minimize its static footprint by resolving key functionality at runtime. Its imports include APIs associated with sandbox and timing checks, memory-mapped file access, low-level I/O, process and service control, and volume enumeration.
The binary also contains functionality associated with SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, and SeTakeOwnershipPrivilege, suggesting it can elevate its token privileges before encryption.
During Cynet’s analysis, DeadLock used a self-deleting batch launcher and enumerated storage beyond the user’s visible drives. The sample mounted the normally hidden System Reserved partition as drive Z: and dropped its recovery HTML there, confirming that its volume-enumeration logic reaches system partitions as well.
Encrypted files receive a victim-specific identifier and the .dlock extension. DeadLock also drops its plaintext ransom note and interactive HTML portal and can replace the desktop wallpaper and encrypted-file icon.
Detection
Cynet ran the sample in detection mode, with prevention disabled, so the ransomware could execute its full chain while the platform logged its activity.
Multiple detection mechanisms triggered. Cynet’s AV engine identified the malicious binary, while its Unauthorized File Operation mechanism caught suspicious .dlock file activity — including an encrypted file written inside the EFI boot partition.
Patience pays off
DeadLock’s low profile didn’t equate to low activity. The Blog tab embedded in its HTML victim portal gave Cynet a direct view into the group’s extortion history. At the time of analysis, it contained 29 pages covering 87 victims across multiple sectors in the EU and U.S. Each entry included an organization name, description, timestamp, and a link to leaked data.
That patience and discipline appear to have paid off. Despite operating as a closed group without a known affiliate program, DeadLock built a sizable victim list while attracting far less attention than ransomware crews that relied on public leak sites. Meanwhile, its increasingly sophisticated victim portal suggests an operation that spent its quieter months refining its approach rather than standing still.
Key takeaways for defenders
- Monitor unusual privilege use. DeadLock contains functionality associated with SeDebugPrivilege, SeBackupPrivilege, SeRestorePrivilege, and SeTakeOwnershipPrivilege. Their use by a process that has no legitimate reason to require them warrants investigation.
- Don’t ignore hidden and system partitions. DeadLock reached the System Reserved partition and wrote ransom-related material there. Detection and file-monitoring strategies should extend beyond ordinary user data volumes.
- Treat unexpected Session contact as an incident indicator. DeadLock has relied heavily on direct negotiations over Session rather than conventional public extortion channels.
- Prioritize behavioral detection alongside signatures. DeadLock dynamically resolves functionality and incorporates anti-analysis techniques, making activity such as privilege changes, volume mounting, suspicious file writes, and encryption behavior especially valuable detection opportunities.
- Maintain resilient backups. DeadLock is mapped to system-recovery inhibition, reinforcing the need for offline or immutable backups that ransomware running on an endpoint cannot modify.
DeadLock shows why ransomware visibility cannot depend on watching leak sites. A disciplined group can operate at scale long before it generates attention.
Infrastructure evolution
DeadLock’s infrastructure has continued to evolve. Microsoft subsequently reported that its HTML recovery application can retrieve victim-communication proxy addresses through Polygon smart contracts. That allows operators to rotate the proxy by updating blockchain-hosted information rather than replacing victim-facing domains, increasing the resilience of its communication infrastructure.
Earlier Group-IB research, covered by The Register, had already identified DeadLock’s use of Polygon smart contracts to conceal and rotate proxy infrastructure. The newer Microsoft analysis expands the picture, including blockchain-backed resources supporting both communication and leak operations.
That evolution fits the broader pattern visible in Cynet’s analysis: DeadLock is investing in making the entire extortion operation harder for defenders to disrupt.
More from Cynet
Ransomware Prevention: 4-Step Plan to Stop Ransomware Attacks in Their Tracks