Executive Summary
DeadLock is a ransomware operation that combines three technically distinctive architectural choices absent from most contemporary RaaS offerings: a Rust-based cross-platform encryptor, decryption key management infrastructure hosted on the Polygon blockchain, and operator communications via Session — a decentralised, end-to-end encrypted messaging network with no central server for law enforcement to compel. These choices reflect deliberate engineering decisions to make the operation resilient to law enforcement takedown, infrastructure seizure, and forced decryption.
Microsoft’s analysis of the group, published 10 August 2026, attributes more than 50% of DeadLock’s observed victim population to European enterprises, with manufacturing, financial services, and healthcare as primary target sectors. The group implements geofencing that prevents encryption of systems in CIS countries — a standard operational security practice among Russia-adjacent threat actors.
DeadLock is not operationally affiliated with a previously known group, but its encryptor code shows influence from the Lynx/INC Ransom ecosystem, and several intrusions have been observed where former affiliates of INC Ransom pivoted to DeadLock following INC’s decline in early 2026. This suggests DeadLock is either a rebranding by former INC affiliates or a new operation specifically recruiting from that talent pool.
Threat Actor Profile
First observed: February 2026
Classification: Ransomware-as-a-Service (RaaS)
Primary geography: Europe (50%+), North America (30%), Asia-Pacific (20%)
Primary sectors: Manufacturing, financial services, healthcare, professional services
Victim count (public): 63 confirmed victims as of August 2026
Ransom range: $50,000-$2.5M depending on organisation revenue
Attribution confidence: Moderate — no confirmed attribution to a nation-state; criminal operation with possible Russia nexus based on geofencing behaviour
Technical Analysis: Rust Encryptor
DeadLock’s encryptor is written in Rust, continuing the trend established by groups including Cicada3301, RansomHub, and Embargo. The Rust implementation delivers several operational advantages: cross-platform compilation from a single codebase (DeadLock produces Windows, Linux/ESXi, and NAS targeting variants from the same source), superior performance for high-volume file enumeration and encryption, and reduced memory safety vulnerabilities that might otherwise be exploited in incident response or sandbox analysis.
The encryption scheme uses ChaCha20-Poly1305 symmetric encryption for file data, with per-file symmetric keys wrapped using the victim’s RSA-4096 public key. This is functionally identical to the key management architecture used by most sophisticated ransomware groups. What differs is where the RSA private key is stored.
In traditional ransomware operations, the RSA private key is held by the operator’s backend infrastructure — typically a Tor-accessible server. Law enforcement takedown of that server potentially recovers keys that can be used to decrypt victim systems. DeadLock stores the operator’s RSA key material on the Polygon blockchain, encoded in transaction data across multiple transactions on a wallet controlled by the operator.
The practical implication: law enforcement cannot seize or compel a decryption server because the key material exists only on the blockchain and in the memory of the operator’s clients. The blockchain is immutable and globally distributed — there is no single point of failure for law enforcement to target. This is a direct architectural response to the Hive and LockBit infrastructure takedowns, which disrupted those operations by seizing backend decryption infrastructure.
Blockchain-Based Recovery Infrastructure
The Polygon blockchain implementation is the most technically novel element of DeadLock’s architecture. When the encryptor executes on a victim system, it generates a victim-specific ID and performs a lookup against a Polygon smart contract that contains the operator’s public key material and recovery configuration. The decryption client, provided after ransom payment, reads the victim-specific decryption configuration from the blockchain using the victim ID as a lookup key.
This design creates several properties:
Immutability: Once the operator writes recovery information to the blockchain, it cannot be deleted — not by law enforcement, not by the operator. Victims can theoretically verify that a decryption key has been published for their victim ID before making payment.
Transparency: All blockchain transactions are publicly visible. Security researchers can monitor the DeadLock operator’s wallet for patterns — victim deployment cadence, infrastructure changes, operational gaps — using standard blockchain analysis tools.
Decentralisation: The Polygon network is distributed across thousands of nodes. There is no server for law enforcement to seize or court order to compel. Disrupting the blockchain infrastructure would require disrupting the Polygon network itself — operationally infeasible.
The operator pays transaction fees (gas) in MATIC (Polygon’s native currency) for each victim deployment, creating a blockchain-visible cost structure that security researchers have used to estimate victim volume even before DLS publication.
Session Messaging Integration
DeadLock uses Session for operator-to-affiliate and operator-to-victim communications, replacing the conventional Tor-based negotiation portals used by most RaaS operations. Session is a decentralised, end-to-end encrypted messaging application that routes messages through a distributed node network without a central server. Unlike Tor onion services, Session has no single operator and no server infrastructure that can be compelled to disclose communications.
From a victim’s perspective, the negotiation experience differs from conventional RaaS: rather than a Tor browser link to a negotiation portal, victims receive a Session ID (a 66-character public key) and instructions to install Session to begin negotiations. This reduces the friction of Tor installation for victims but eliminates the centralised chat infrastructure that has been a source of intelligence for law enforcement in previous operations.
Session also provides the affiliate communication channel. The core operator team communicates with affiliates through Session group channels rather than forum-based RaaS panels — reducing the profile of the operation in monitored underground forums and complicating efforts to identify and track affiliates.
Intrusion Chain
Microsoft’s analysis documents a consistent intrusion pattern across multiple DeadLock incidents:
Initial access: Purchased from IABs or via direct exploitation of internet-facing systems. Fortinet VPN appliances (exploiting CVE-2024-55591 and CVE-2025-24472, also used by Gunra) appear in multiple DeadLock intrusions, suggesting shared IAB sourcing with other operations buying from the same access pool.
Persistence and lateral movement: Post-access tooling includes Cobalt Strike Beacon (still widespread despite detection coverage), Sliver, and victim-specific living-off-the-land techniques. Active Directory enumeration via BloodHound is standard. Lateral movement targets ESXi and NAS environments specifically for encryption of virtualised workloads.
Data exfiltration: Rclone to attacker-controlled cloud storage, with a staging window of 4-10 days before encryption. Financial records, intellectual property, and personally identifiable information are prioritised.
Deployment: Encryptor is deployed via Group Policy Object (GPO) in Active Directory environments, achieving domain-wide encryption in a single execution cycle. ESXi encryptor targets VMware infrastructure directly. NAS encryptor variant targets Synology, QNAP, and NetApp devices.
The deployment timeline from initial access to encryption in documented incidents ranges from 5 days (fastest observed) to 23 days, with a median of approximately 11 days.
Geofencing and Operator Nationality
DeadLock’s encryptor performs a locale and keyboard layout check at execution time and terminates without action on systems configured for CIS country locales or Cyrillic keyboard layouts. This is consistent with Russian criminal group operational security practice — avoiding targets in Russia and neighbouring states to reduce domestic law enforcement attention.
The geofencing check covers: Russia, Ukraine, Belarus, Kazakhstan, Moldova, Georgia, Azerbaijan, Armenia, Kyrgyzstan, Tajikistan, Turkmenistan, Uzbekistan. Systems outside these regions are encrypted without additional checks.
Attribution to Russia or a specific Russia-adjacent jurisdiction has not been confirmed by a government source. Microsoft’s analysis characterises DeadLock as a criminal operation with a “probable Eastern European nexus” based on operational patterns, linguistic artefacts in early build strings, and geofencing behaviour.
Target Sector Analysis
European manufacturing is the most heavily represented victim sector in DeadLock’s public victim disclosures — consistent with the broader pattern of ransomware groups targeting industrial companies with high downtime sensitivity and complex regulatory reporting requirements. Healthcare victims (hospital groups, clinical networks, diagnostic laboratories) follow. Financial services victims are present but less frequently disclosed, likely reflecting non-disclosure agreements that are more common in that sector.
DeadLock’s ransom demands scale with reported victim revenue, with demands in the $50,000-$150,000 range for mid-market organisations and demands up to $2.5M for enterprises with significant annual revenue. Payment rates in known incidents are not publicly available.
Defensive Implications
Blockchain monitoring: The Polygon smart contract used for DeadLock’s recovery infrastructure is publicly visible. Blockchain threat intelligence feeds that monitor for ransomware-associated wallet activity provide early warning of new victim deployments and infrastructure expansion. Organisations with established threat intelligence programmes should integrate blockchain analytics for known ransomware-associated wallets.
IAB exposure assessment: Multiple DeadLock intrusions use access purchased from the same IAB pool as other operations (particularly Fortinet VPN credential compromise). Organisations running unpatched FortiOS or FortiProxy at internet-facing positions should assess for prior compromise, particularly against CVE-2024-55591 and CVE-2025-24472.
ESXi and NAS prioritisation: DeadLock’s encryptor specifically targets virtualised infrastructure. ESXi hosts and NAS devices must be included in backup architecture and incident response planning — they are primary targets for maximum encryption impact in minimum execution time.
Session monitoring: Network security tools that monitor for Session application traffic (p2p messaging network identifiable by characteristic traffic patterns to Session service node endpoints) can provide a detection opportunity when DeadLock operators communicate with victim networks or when a victim endpoint installs Session as part of the negotiation process.
Active Directory GPO monitoring: Alert on new GPO creation or modification, particularly GPOs with startup scripts targeting executable files or remote UNC paths. Domain-wide ransomware deployment via GPO is detectable before encryption execution if GPO change monitoring is in place.
Comparison to Peer Groups
DeadLock occupies a technically sophisticated position in the current ransomware landscape. Its blockchain-based key management represents a genuine architectural innovation designed to address the most effective law enforcement disruption technique used against Hive and LockBit. The Session communications model similarly addresses communication infrastructure seizure. These choices signal a technically capable operator who has studied previous law enforcement operations in detail.
The operation is likely to persist longer than conventionally architected RaaS groups before facing infrastructure-based disruption. Law enforcement options are narrower: identification and arrest of operators or affiliates, or blockchain-level disruption of the Polygon infrastructure, which is orders of magnitude more difficult than seizing a Tor hidden service. The most realistic disruption path is through affiliate identification and arrest — which requires infiltrating the affiliate recruitment channels on Session.
For defenders, the practical implication is that DeadLock will not be shut down by a server takedown the way Hive was. Sustained attention to the detection and pre-encryption response window is the primary protection — the decryption infrastructure being on a blockchain doesn’t change the value of catching the intrusion before the encryptor runs.