DeadLock Ransomware Uses Blockchain Smart Contracts to Survive Takedowns — Detection and Disruption Playbook

Ransomware operators have spent the last decade fighting a losing war against infrastructure takedowns. Law enforcement seizes domains, hosting providers suspend bulletproof servers, registrars revoke DNS — and crews rebuild. DeadLock, an encryption-based extortion operation, appears to have found a way off that treadmill: it is using blockchain-backed services — specifically smart contracts on a public, decentralized ledger — to store and distribute the addresses of its victim-communication and data-leak infrastructure.

This is not a theoretical evolution. Because no single registrar, hosting provider, or court order can remove data written to an immutable, replicated blockchain, the traditional takedown playbook fails against this design. For defenders, the implication is immediate and practical: you can no longer count on external disruption to degrade this actor's operations between campaigns. Detection must move left — to initial access, execution, and egress — and network controls must treat blockchain RPC traffic as an observable, governable behavior rather than exotic noise.

This post breaks down the technique from a defender's perspective, provides hunting content for Sigma, Microsoft Sentinel, and Velociraptor, and closes with a hardening script and a remediation checklist your IR and SOC teams can act on today.

Technical Analysis: How Blockchain-Backed Ransomware Infrastructure Works

What DeadLock is doing

Per the reporting from BleepingComputer, the DeadLock operation relies on decentralized, blockchain-backed services to protect two things that ransomware crews historically lose in takedowns:

1. Victim communication channels — the negotiation portal URLs (typically Tor-hosted) delivered in ransom notes and used to pressure victims.
2. Data-leak publication infrastructure — the sites where stolen data is advertised and dumped to enforce double-extortion leverage.

The core mechanism is the abuse of smart contracts on a public blockchain (reported as Polygon in related coverage of this technique) as a distributed, censorship-resistant configuration store. The operator publishes a contract whose state contains the current address of the negotiation/leak infrastructure. Any client — the malware, an affiliate's tooling, or a victim following the ransom note's instructions — can query the blockchain through a public RPC endpoint and read the current address, even if the previous server was seized hours earlier. When infrastructure is burned, the actor sends a single low-cost transaction updating the contract state, and every reader converges on the new location.

Why this defeats takedowns

• No registrar or host to pressure. Smart contract state lives on thousands of replicated nodes. There is no A record to sinkhole and no VPS to suspend.
• Immutable history, mutable pointer. The contract address never changes; only its stored value does. Blocking yesterday's negotiation site does nothing.
• Cheap and fast rotation. Updating a contract costs cents and confirms in seconds on networks like Polygon — faster than any abuse-desk process on the planet.
• Legitimate-looking egress. Reading contract state is a JSON-RPC eth_call over HTTPS to public RPC endpoints (e.g., polygon-rpc.com, *.infura.io, *.alchemyapi.io, rpc.ankr.com). This traffic rides port 443 and blends into a sea of legitimate Web3 development and wallet activity.

Attack chain (defender's view)

1. Initial access — DeadLock follows the standard ransomware-as-a-service pattern: exposed services, compromised credentials, or affiliate-delivered access. (No specific CVE has been publicly tied to this operation at time of writing; treat initial-access vectors as the standard ransomware TTP set: brute force, valid accounts, exploited public-facing applications.)
2. Staging and discovery — hands-on-keyboard enumeration, credential dumping, lateral movement.
3. Defense evasion — disabling or tampering with security tooling and deleting shadow copies to inhibit recovery.
4. Impact — mass file encryption, ransom note deployment containing instructions to reach the negotiation portal.
5. Resilient C2/leak resolution — blockchain RPC lookups (or instructions pointing victims to do so) to resolve the current negotiation/leak site, immune to takedown.

Exploitation status

This is an active, in-the-wild ransomware operation — not a proof of concept. There is no CVE and no CISA KEV entry associated with the blockchain technique itself (it is an infrastructure-design choice, not a software vulnerability). The defensive gap is architectural, not patchable: you cannot patch a smart contract. You detect the behaviors around it.

What is actually observable in your environment

The good news: this design creates detection surface. Enterprise workstations and servers have almost no legitimate reason to query blockchain RPC endpoints. That asymmetry is your hunt hypothesis.

Key observables:

• Outbound HTTPS to public blockchain RPC endpoints from servers, endpoints, or processes that are not known Web3 tooling.
• JSON-RPC method patterns (eth_call, eth_getStorageAt, eth_blockNumber) in TLS-inspected or proxy-logged payloads where you have visibility.
• Ransomware precursor behaviors: vssadmin delete shadows, bcdedit recovery tampering, mass file renames with consistent extension, ransom note files dropped across directories.
• Ransom notes containing blockchain contract addresses or RPC URLs — a high-fidelity forensic artifact unique to this technique.

Detection & Response

Sigma Rules

The following rules target (1) egress to public blockchain RPC infrastructure from non-browser processes, (2) classic ransomware recovery-inhibition behavior that precedes DeadLock-style encryption, and (3) ransom-note artifacts referencing blockchain contracts.

---
title: Outbound Connection to Public Blockchain RPC Endpoint
tid: 3f8a1c44-9b2e-4d7a-a1c6-5e8f2b3d9a01
status: experimental
description: Detects processes initiating network connections to well-known public blockchain RPC endpoints. Ransomware operations such as DeadLock abuse smart contracts on public chains (e.g., Polygon) to resolve takedown-resistant C2 and data-leak infrastructure. Enterprise endpoints and servers rarely have legitimate cause to contact these services outside of sanctioned Web3 development.
references:
  - https://www.bleepingcomputer.com/news/security/deadlock-ransomware-uses-blockchain-to-resist-infrastructure-takedown/
  - https://attack.mitre.org/techniques/T1071/001/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: network_connection
  product: windows
detection:
  selection_domain:
    DestinationHostname|contains:
      - 'polygon-rpc.com'
      - 'rpc.ankr.com'
      - 'infura.io'
      - 'alchemyapi.io'
      - 'mainnet.infura.io'
      - 'polygon-mainnet'
      - 'matic-mainnet'
      - 'quicknode.com'
      - 'chainstack.com'
      - 'publicnode.com'
  filter_browsers:
    Image|endswith:
      - '\chrome.exe'
      - '\msedge.exe'
      - '\firefox.exe'
      - '\brave.exe'
      - '\opera.exe'
  condition: selection_domain and not filter_browsers
falsepositives:
  - Sanctioned Web3/blockchain development workstations
  - Cryptocurrency wallet or node software approved by the business
level: high
---
title: Ransomware Recovery Inhibition via Shadow Copy or Boot Configuration Tampering
tid: 7c2e9b15-4d8f-4a3e-b6c1-2f5a8d9e4b07
status: experimental
description: Detects deletion of volume shadow copies or modification of boot recovery options, a near-universal precursor to ransomware encryption including DeadLock-style operations. Legitimate use of these commands is rare on end-user systems and should be correlated with process lineage.
references:
  - https://www.bleepingcomputer.com/news/security/deadlock-ransomware-uses-blockchain-to-resist-infrastructure-takedown/
  - https://attack.mitre.org/techniques/T1490/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.impact
  - attack.t1490
logsource:
  category: process_creation
  product: windows
detection:
  selection_vss:
    Image|endswith:
      - '\vssadmin.exe'
      - '\wmic.exe'
      - '\powershell.exe'
      - '\cmd.exe'
    CommandLine|contains:
      - 'delete shadows'
      - 'shadowcopy delete'
      - 'resize shadowstorage'
  selection_bcd:
    Image|endswith: '\bcdedit.exe'
    CommandLine|contains:
      - 'recoveryenabled no'
      - 'bootstatuspolicy ignoreallfailures'
  condition: selection_vss or selection_bcd
falsepositives:
  - Backup software performing shadow copy maintenance (verify process lineage)
  - System administrators during sanctioned maintenance windows
level: critical
---
title: Ransom Note Dropped Referencing Blockchain Contract Address
tid: 1a5d8c62-7f3b-4e9a-c2d4-8b6e1a3f5c09
status: experimental
description: Detects creation of text/HTML ransom notes containing hexadecimal smart contract addresses or blockchain RPC URLs, a distinctive artifact of takedown-resistant ransomware operations that store negotiation infrastructure on-chain.
references:
  - https://www.bleepingcomputer.com/news/security/deadlock-ransomware-uses-blockchain-to-resist-infrastructure-takedown/
  - https://attack.mitre.org/techniques/T1486/
author: Security Arsenal
date: 2026/01/15
tags:
  - attack.impact
  - attack.t1486
logsource:
  category: file_event
  product: windows
detection:
  selection_name:
    TargetFilename|contains:
      - 'readme'
      - 'decrypt'
      - 'recover'
      - 'restore_files'
      - 'how_to'
  selection_ext:
    TargetFilename|endswith:
      - '.txt'
      - '.hta'
      - '.html'
  selection_path:
    TargetFilename|contains:
      - '\Users\'
      - '\ProgramData\'
      - '\Public\'
  condition: selection_name and selection_ext and selection_path
falsepositives:
  - Legitimate software README files (tune paths; alert on velocity of creation across directories rather than single events)
level: high

Microsoft Sentinel / Defender KQL

This hunt correlates two signals over a 24-hour window: processes contacting known public blockchain RPC endpoints, and ransomware precursor behavior (shadow-copy deletion or recovery tampering). A host appearing in both result sets is a high-priority investigation. Adjust the domain list for any sanctioned Web3 tooling in your environment before productionizing.

let RpcDomains = dynamic(["polygon-rpc.com", "rpc.ankr.com", "infura.io", "alchemyapi.io", "quicknode.com", "chainstack.com", "publicnode.com", "matic-mainnet", "polygon-mainnet"]);
let BlockchainEgress =
    DeviceNetworkEvents
    | where TimeGenerated > ago(24h)
    | where RemoteUrl has_any (RpcDomains)
    | where InitiatingProcessFileName !in~ ("chrome.exe", "msedge.exe", "firefox.exe", "brave.exe")
    | summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated),
                Connections=count(), Endpoints=make_set(RemoteUrl),
                Process=make_set(InitiatingProcessCommandLine)
        by DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName;
let RansomwarePrecursor =
    DeviceProcessEvents
    | where TimeGenerated > ago(24h)
    | where (ProcessCommandLine has_any ("delete shadows", "shadowcopy delete", "resize shadowstorage"))
        or (FileName =~ "bcdedit.exe" and ProcessCommandLine has_any ("recoveryenabled no", "ignoreallfailures"))
    | summarize PrecursorFirstSeen=min(TimeGenerated), PrecursorCmds=make_set(ProcessCommandLine)
        by DeviceName, InitiatingAccountName=AccountName;
BlockchainEgress
| join kind=leftouter RansomwarePrecursor on DeviceName
| project DeviceName, InitiatingProcessFileName, InitiatingProcessAccountName,
          FirstSeen, LastSeen, Connections, Endpoints, Process,
          PrecursorFirstSeen, PrecursorCmds
| order by Connections desc;

A secondary query for environments ingesting proxy or firewall logs via CommonSecurityLog (useful for catching hosts without EDR coverage — including servers where the actual encryption happens):

let RpcDomains = dynamic(["polygon-rpc.com", "rpc.ankr.com", "infura.io", "alchemyapi.io", "quicknode.com", "chainstack.com", "publicnode.com"]);
CommonSecurityLog
| where TimeGenerated > ago(24h)
| where DestinationHostName has_any (RpcDomains) or RequestURL has_any (RpcDomains)
| summarize Connections=count(), Sources=make_set(SourceIP), Devices=make_set(DeviceName)
    by DestinationHostName, bin(TimeGenerated, 1h)
| where Connections > 0
| order by TimeGenerated desc;

Velociraptor VQL

This hunt artifact pulls two forensic views across the fleet: (1) running processes with active or recent connections to blockchain RPC infrastructure, and (2) evidence of shadow-copy deletion or boot tampering in process execution history. Deploy as a multi-host hunt; escalate any endpoint returning rows in both sections.

-- DeadLock-style blockchain C2 and ransomware precursor hunt
-- Section 1: Live connections to public blockchain RPC endpoints
LET rpc_conns = SELECT Pid, Name, CommandLine, Exe, Username
FROM pslist()
WHERE CommandLine =~ '(?i)(eth_call|eth_getStorageAt|smart.?contract|0x[a-f0-9]{40}|polygon|infura|alchemy|ankr|quicknode)'

-- Section 2: Network connections to known RPC endpoints (by IP resolution at hunt time)
LET net_hits = SELECT Pid, Name, Path, Status, Laddr, Raddr
FROM netstat()
WHERE Raddr.IP AND (Name =~ '(?i)(powershell|cmd|rundll32|regsvr32|wscript|cscript|mshta)'
   OR Path =~ '(?i)(Temp|AppData|ProgramData|Public)')

SELECT 'rpc_process_indicator' AS Section, Pid, Name, CommandLine AS Detail, Exe AS Path, Username
FROM rpc_conns
UNION ALL
SELECT 'suspicious_netstat' AS Section, Pid, Name, Raddr.String AS Detail, Path, '' AS Username
FROM net_hits

For post-incident triage on a suspected encryption host, sweep for ransom-note artifacts:

-- Sweep for ransom note files dropped in user-writable locations
SELECT FullPath, Size, Mtime, Ctime
FROM glob(globs=[
  'C:/Users/*/**/README*.txt',
  'C:/Users/*/**/*DECRYPT*.*',
  'C:/Users/*/**/*RECOVER*.*',
  'C:/ProgramData/**/*RESTORE*.*',
  'C:/**/HOW_TO_DECRYPT*.*'
], accessor='ntfs')
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Hardening and Verification Script

The script below does three things on Windows endpoints and servers: verifies that VSS and recovery options have not been tampered with, ensures ransomware-relevant controls are enabled (Controlled Folder Access, tamper protection visibility, attack surface reduction rules where Defender is present), and optionally adds DNS/firewall-level blocking guidance output for blockchain RPC domains. Run elevated; review before deploying fleet-wide via your RMM or GPO.

# Security Arsenal - DeadLock-Style Ransomware Hardening & Verification
# Run as Administrator. Audit-first: reviews before enabling CFA in production.

# --- 1. Verify VSS is healthy and shadow copies exist ---
Write-Host "[+] Checking Volume Shadow Copy service and existing shadows..." -ForegroundColor Cyan
Get-Service VSS | Select-Object Name, Status, StartType
$shadows = Get-CimInstance Win32_ShadowCopy -ErrorAction SilentlyContinue
if (-not $shadows) { Write-Warning "No shadow copies found. Verify backup strategy; ransomware crews delete these pre-encryption." }
else { $shadows | Select-Object DeviceObject, InstallDate }

# --- 2. Verify boot recovery options have not been tampered with ---
Write-Host "`n[+] Checking boot recovery configuration (ransomware often disables)..." -ForegroundColor Cyan
bcdedit /enum {current} | Select-String -Pattern "recoveryenabled|bootstatuspolicy"

# --- 3. Enable Controlled Folder Access (Defender ransomware protection) ---
# Start in AuditMode (1) to baseline; switch to Enabled (0) after tuning exclusions.
Write-Host "`n[+] Controlled Folder Access status..." -ForegroundColor Cyan
$cfa = Get-MpPreference | Select-Object -ExpandProperty EnableControlledFolderAccess
Write-Host "Current CFA state: $cfa (0=Enabled, 1=AuditMode, 2=Disabled)"
if ($cfa -eq 2) {
    Write-Warning "CFA is DISABLED. Enabling Audit Mode - review events 1123/1124 before enforcing."
    Set-MpPreference -EnableControlledFolderAccess AuditMode
}

# --- 4. Enable key ASR rules that disrupt ransomware precursors (audit mode) ---
$asrRules = @{
    "Block abuse of exploited vulnerable signed drivers" = "56a863a9-875e-4185-98a7-b882c64b5ce5"
    "Block credential stealing from lsass.exe"           = "9e6c4e1f-7d60-4729-baec-a3bb9d1d08d6"
    "Block process creations from PSExec/WMI commands"   = "d1e49aac-8f56-4280-b9ba-993a3d77406c"
}
foreach ($rule in $asrRules.GetEnumerator()) {
    Add-MpPreference -AttackSurfaceReductionRules_Ids $rule.Value -AttackSurfaceReductionRules_Actions AuditMode
    Write-Host "ASR audit enabled: $($rule.Key)"
}

# --- 5. Flag suspicious blockchain RPC resolution in DNS client cache ---
Write-Host "`n[+] Checking DNS cache for public blockchain RPC endpoints..." -ForegroundColor Cyan
$rpcPatterns = "polygon-rpc","infura","alchemyapi","rpc.ankr","quicknode","chainstack","publicnode"
$hits = Get-DnsClientCache | Where-Object { $e=$_.Entry; $rpcPatterns | Where-Object { $e -like "*$_*" } }
if ($hits) {
    Write-Warning "Blockchain RPC lookups found in DNS cache - investigate process origin:"
    $hits | Select-Object Entry, Data, TimeToLive | Format-Table
} else { Write-Host "No blockchain RPC entries in DNS cache." }

# --- 6. Output recommended egress-block domains for firewall/DNS filtering ---
Write-Host "`n[RECOMMENDED EGRESS BLOCKS - apply at DNS filter or proxy for non-Web3 hosts]" -ForegroundColor Yellow
$rpcPatterns | ForEach-Object { Write-Host "  *.$_  /  $_" }
Write-Host "`nDone. Correlate any findings with EDR timeline before containment actions." -ForegroundColor Cyan

Remediation and Defensive Recommendations

There is no patch for an architectural technique — the work here is detection engineering, egress control, and IR readiness. Prioritize the following:

1. Govern blockchain RPC egress (highest leverage, lowest cost)

• Default-deny blockchain RPC domains (polygon-rpc.com, rpc.ankr.com, *.infura.io, *.alchemyapi.io, *.quicknode.com, *.chainstack.com, *.publicnode.com) at your DNS filter and web proxy for all asset classes except explicitly sanctioned Web3 development systems. The legitimate business case for a file server or accounting workstation to call eth_call is effectively zero.
• Where you have TLS inspection, alert on JSON-RPC payloads containing eth_call, eth_getStorageAt, and eth_getCode to non-allowlisted destinations.
• Log and baseline before blocking if you have any blockchain-adjacent business units — but scope the exception to named hosts, not the network.

2. Disrupt the precursor chain, not just the payload

DeadLock's blockchain trick only matters if the intrusion reaches the encryption stage. The pre-impact behaviors are conventional and detectable:

• Alert on shadow copy deletion and bcdedit recovery tampering with process lineage (see Sigma rule above). Enable the ASR rules in the script in audit mode now, enforce after tuning.
• Alert on mass file modification velocity — a single process touching hundreds of files per minute across directories is a reliable encryption-stage signal in every modern EDR.
• Restrict and monitor vssadmin, wbadmin, and wmic execution to administrative accounts via WDAC or AppLocker policies.

3. Harden the initial-access surface

No novel exploit is implicated in this operation — which means the standard ransomware ingress gaps are doing the work:

• Enforce phishing-resistant MFA on all remote access (VPN, RDP gateways, VDI) and audit for exposed RDP/SMB.
• Patch public-facing applications on the cadence your vulnerability program already mandates; validate internet-facing asset inventory against what you think is exposed.
• Segment backup infrastructure off the domain, with immutable/offline copies and tested restore procedures. The entire double-extortion model — and the leak-site infrastructure this actor has made takedown-proof — only has leverage if you cannot recover and cannot tolerate disclosure.

4. Update your IR playbooks for blockchain-backed infrastructure

• Forensics: During ransomware triage, specifically extract ransom notes and search for hex contract addresses (0x + 40 hex chars) and RPC URLs. These are high-value, actor-specific indicators for attribution and for identifying the negotiation flow your legal/comms teams will face.
• Takedown assumptions: Do not build response timelines that assume the leak site or negotiation portal will disappear. Plan disclosure, legal, and communications workstreams on the assumption the infrastructure is persistent.
• Threat intel sharing: Share observed contract addresses and RPC endpoints with your ISAC/ISAO — blockchain indicators are public and queryable, making them unusually shareable and durable compared to traditional IOCs.
• Tabletop it: Add a scenario to your next ransomware exercise where the extortion site cannot be taken down and rotates faster than your legal takedown requests. Watch how your playbooks hold up.

5. SOC operationalization

• Deploy the Sigma rules above through your pipeline; convert the Sentinel KQL into an analytic rule with a 24-hour lookback and entity mapping on DeviceName.
• Run the Velociraptor hunt fleet-wide this week to establish a baseline — any pre-existing blockchain RPC chatter needs to be explained, allowlisted, or investigated before an incident forces the question.

The strategic lesson from DeadLock is bigger than one crew: ransomware operators are engineering around the takedown lever that defenders and law enforcement have relied on for years. If your detection program still treats infrastructure disruption as a safety net, this is the moment to retire that assumption.

Related Resources

Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub