DeadLock Ransomware: Smart Contracts for Malicious Purposes

Introduction

DeadLock is a ransomware family discovered in July 2025. It is notable for not being associated with any known affiliate programs and for lacking a Data Leak Site (DLS). This, combined with the limited number of reported victims, has resulted in low exposure for the group.

However, Group-IB specialists have discovered an interesting use of Polygon smart contracts for proxy server address rotation or distribution. This finding warrants public attention, especially since the abuse of this specific blockchain for malicious purposes has not been widely reported.

In addition, the recent discovery of similar techniques show that the abuse of smart contracts for malicious purposes could become an emerging trend. For example, Google recently reported that the North Korean (DPRK) threat actor UNC5342 used a technique dubbed “EtherHiding,” which consists of leveraging transactions on public blockchains to store and retrieve malicious payloads. On the other hand, another recent campaign used Ethereum smart contracts to host the URLs where malicious commands are located downloading the second stage malware.

Key discoveries

• DeadLock ransomware uses Polygon smart contracts for decentralized proxy server address rotation.
• Anydesk has been observed to be the main remote monitoring and management tool.
• Learn to track DeadLock’s stealthy infrastructure.
• Recent reported abuses of smart contracts for malicious purposes demonstrates the effectiveness of this technique, while its wide variants make it very desirable to threat actors

Who may find this blog interesting:

• Cybersecurity analysts and corporate security teams
• Malware analysts
• Threat intelligence specialists
• Cyber investigators
• Computer Emergency Response Teams (CERT)
• Law enforcement investigators
• Cyber police forces

Group-IB Threat Intelligence Portal:

Group-IB customers can access our Threat Intelligence portal for detailed information about DeadLock ransomware analysis, usage of smart contracts and new activity detected.

Threat Actor Profile

Ransomware Description

DeadLock sets all the encrypted files extension to .dlock, changes files icons in addition to the victim’s wallpaper instructing the victim to open the ransom note to follow the instructions.

Figure 1. Screenshot of a system infected with DeadLock ransomware.

DeadLock does not own a Data Leak Site (DLS) to publicly extort victims with public data disclosure. However, based on information found within some of the ransom notes DeadLock drops, the infected system’s data is assumed to be stolen as well. In addition, DeadLock threatens victims with the selling of stolen data if their demands are not satisfied.

Different ransom notes have been observed throughout Group-IB’s investigations, marking an evolution of DeadLock’s TTPs.

First sample (3c1b9df801b9abbb3684670822f367b5b8cda566b749f457821b6481606995b3) detected on June 27th, 2025 does not mention any data exfiltration activity:

Second sample (3cd5703d285ed2753434f14f8da933010ecfdc1e5009d0e438188aaf85501612) from July 17th, 2025 highlights that data was not only encrypted but also stolen:

In the last observed sample (c9cc95ff8f2998229394dfd31c2bd6b723e826a3ca5e008d2b5be19ba419ae2c) from August 12th, 2025, the ransom note has been significantly expanded to include veiled threats of exposure for stolen data as well as other “value added services” such as an incident report, security recommendations, and even a promise that the victim will not be targeted again.

The last ransom note also instructs the user to open an HTML file dropped by the payload. This HTML file (analyzed in detail below) contains an embedded chat to Session messenger and threatens to sell stolen data if no payment is made.

Figure 2. HTML file with embedded Session private messenger to contact the threat actor.

TTPs: Tactics, Techniques, and Procedures

Initial access vectors and other important stages of the attacks remain unknown at this point; however, sample analysis shines some light into the toolset DeadLock might be using.

Based on ransom note changes listed above, we can conclude that there have been at least 3 different versions of DeadLock ransomware:

Further analysis shows that the second and third samples share similar relevant strings referring to Windows processes:

References to the same processes or services and listed in the same exact order were also found on a PowerShell script discovered during Group-IB’s hunting activities for this research. The submission date also matches with the creation date of one of the samples. These findings suggest that this PowerShell script could be part of the DeadLock toolset.

The Powershell Script

The main purpose of the PowerShell script is to stop services that are not whitelisted. It is noteworthy that almost all whitelisted services are Windows native services, except for AnyDesk. The presence of AnyDesk, a non-native process on this whitelist, makes this unique list of strings relevant and suggests that DeadLock might be using AnyDesk as the main remote control application. ThreatScene has also reported the usage of AnyDesk by DeadLock ransomware on a DFIR investigation.

This is the full list of whitelisted services:

Core functionality of the PowerShell script:

• Ensures it runs with admin rights. If not, it attempts to relaunch itself with admin rights.

• Attempts to stop all the services not whitelisted on $servicesNotToStop and ensures they are not executed automatically after reboot.

• It deletes all Volume Shadow Copies

• Forces the script to delete itself

The PowerShell script also has a commented code snippet which attempts to delete some of the shared resources, apart from killing services and processes.The observed attempts of deleting file shares, shadow copies, etc. is a common practice among ransomware groups, which in addition to the fact that the whitelisted processes and services are referenced in the same exact order on multiple samples reinforces the conclusion that this script might have been used by DeadLock ransomware.

Proxy Address Rotation & Polygon Smart Contract

In the last observed sample, DeadLock drops an HTML file which acts as a wrapper for Session, an end-to-end encrypted and decentralized instant messenger.

The main purpose of the HTML file is to facilitate direct communication between the DeadLock operator and the victim as an alternative to downloading the Session app.

The HTML sends and receives messages from a server that acts as a middleware or proxy.   While DeadLock initially leveraged allegedly compromised servers, recent evidence suggests the group now operates its own infrastructure.

The most interesting part of this is how server addresses are retrieved and managed by DeadLock. Group-IB researchers uncovered JS code within the HTML file that interacts with a smart contract over the Polygon network. This RPC list contains the available endpoints for interacting with the Polygon network or blockchain, acting as gateways that connect applications to the blockchain’s existing nodes.

The function also iterates through all the rpcList as a fallback mechanism in case some of the rpc URLs are blocked.

0x8EF7c3e531d871D3B9D559722DE77EB1dEc19dAe is the Polygon address of a smart contract. The smart contract code is not human-readable in this case, but it can be observed that a wallet has been interacting with the contract’s setProxy function.

Figure 3. The smart contract used by DeadLock on the Polygon network.

By analyzing the transaction data, it can be observed that the wallet executing the transaction is passing an URL as an argument for setProxy.

Figure 4. setProxy transaction of the smart contract passes a URL string.

At the time of writing this report, if the same method is executed on the contract, we get the following response:

Which, if properly decoded the same way the JS code does:

The output is an URL address hXXp://138.226.236[.]51/prrq.php, which matches the value passed as the argument to the setProxy method.

Note that the eth_call method does not create a transaction on the blockchain — it is a “read” operation for interacting with a smart contract. As such, executing this function incurs no network costs.

sendProxy

The proxy variable retrieved from the smart contract is then used by another function within the JS code named sendProxy.

sendProxy sends POST requests to the proxy server, including a method parameter. The available and used methods are as follows:

• ping
• get_snodes
• get_swarms
• poll
• store

An OSINT investigation was conducted to determine whether these methods correspond to any known repositories or public APIs, but no matches were identified. Notably, the term “swarms” is associated with Session, the decentralized messaging platform used by DeadLock. Similarly, “snodes” likely refers to service nodes or Session nodes, which aligns with the platform’s architecture.

The store method is utilized by another function called sendMessage, which is invoked by handlerSend — a function responsible for processing and transmitting user input.

This indicates that handlerSend is responsible for processing a user’s message and initiating the sending process.

The sendMessage function encrypts the user’s text input and transmits a JSON object to the proxy server.

The JSON object contains a key named destination, whose value is 05084f9b14b02f4ffa97795a60ab1fafaf5128e3259c75459aaaeaebc80c14da78. This value exactly matches DeadLock’s Session ID.

Proxy Tracking

As the smart contract DeadLock uses to set the proxy address is already known, a historical list of proxy server addresses can be retrieved by tracking the transactions to this contract and decoding the input data.

In addition, because the method used by the smart contract to set the proxy value is known as well, transactions containing that specific method can also be tracked to identify additional smart contracts.

• https://polygonscan.com/advanced-filter?mtd=0x46eb0d6f%7eSet+Proxy

Searching by smart contract bytecode also reveals additional smart contracts utilized by DeadLock:

• https://polygonscan.com/find-similar-contracts?a=0x8EF7c3e531d871D3B9D559722DE77EB1dEc19dAe&m=exact

Although several copies of the exact contracts were found on other addresses, only the following addresses contain recorded transactions:

The contract creation date also aligns with the creation date of the most recently observed sample.

The creator of all the contracts is the single address, 0x8f2fef1339E0d90362F3cEAd9C27B661d964a022. The only associated activities for this address are contract creation and set proxy transactions. This address was funded by a wallet linked to the Fixed Float exchange on the same day the contract was created, Aug-10-2025. Since contract creation and set proxy transactions incur blockchain costs — even if minimal — the DeadLock operator needed to fund the address to afford these operations.

Known Proxy Servers

Active proxy servers servers respond to HTTP GET requests with the following body:

When analyzing past proxy servers, it is observed that the initial servers utilized software associated with legitimate web pages, suggesting DeadLock may have exploited misconfigurations or vulnerabilities to hijack them.

In contrast, the two most recent servers do not host any known webpages, displaying only a Vesta control panel on port 2083 and SSH on port 22. Both servers share the same SSH fingerprint and SSL certificates.

Port 80 is running Apache/2.4.29 (Ubuntu) which serves the proxied requests.

Figure 5. Group-IB Graph: Links between known proxy servers and shared identifiers used by DeadLock.

Conclusion

DeadLock seems to have reactivated its operations by recently setting up a new proxy server. Although it’s low profile and yet low impact, it applies innovative methods that showcases an evolving skillset which might become dangerous if organizations do not take this emerging threat seriously.

This exploit of smart contracts to deliver proxy addresses is an interesting method where attackers can literally apply infinite variants of this technique; imagination is the limit. As Google reported recently, DPRK actors have used the Ethereum blockchain to hide malicious payloads, a technique dubbed as “Etherhiding”.

Recommendations

Although ransomware groups have gained notoriety for targeting companies in critical sectors, they are a threat to organizations across all industries. In addition to having new members in its network, ransomware affiliate programs equip members with upgraded tools and techniques. That being said, it is essential that businesses take specific steps immediately to keep their mission-critical operations and data secure. We recommend the following:

• Add more layers of security: Multi-factor authentication (MFA) and credential-based access solutions help businesses secure their critical assets and high-risk users, making it harder for attackers to be successful.
• Stop ransomware with early detection: Leverage enterprise behavioral detection capabilities such as Group-IB’s Endpoint Detection and Response (EDR)  solution to help identify ransomware indicators across your managed endpoints, promptly alerting your teams to any suspicious activity for further scrutiny. This proactive approach enables agile detection, investigation and remediation of both known and unknown threats on your endpoints.
• Have a backup strategy: Data backup processes should be conducted regularly as they reduce damage and help organizations avoid data loss following ransomware attacks.
• Leverage an advanced malware detonation solution: Organizations should leverage AI-infused, advanced analytics-based solutions to detect intrusions in real-time. Learn how Group-IB’s Managed XDR coupled with Threat Intelligence helps businesses to: gain insights into the unique Tactics, Techniques, and Procedures (TTPs) used by Advanced Persistent Threats (APTs) and other cybercriminal groups and pivot their security strategies accordingly; and enable multi-layered cybersecurity (endpoint, email, web, and network) through automated threat detection and response.
• Patch it up: The longer a vulnerability remains unpatched, the greater the risk that it will be exploited by cybercriminals. Security patches should therefore be prioritized, and organizations should also set up a process to regularly review and apply patches as they become available.
• Employee Training: The human factor remains one of the greatest vulnerabilities in cybersecurity. Educate employees about the risks relating to the organization’s network, assets, devices, and infrastructure. Organizations should conduct training programs and security drills to help employees identify and report the tell-tale signs of cybercrime (e.g. phishing emails).
• Control vulnerabilities: Do not turn a blind eye to emerging vulnerabilities. Checking your infrastructure annually with a technical audit or security assessment is not only a good habit, it also adds a much-needed layer of protection. Infrastructural integrity and digital hygiene processes should be monitored continually.
• Never pay the ransom: Group-IB’s Incident Response experts do not recommend rushing to pay ransoms. Financially-motivated threat actors are driven to make you pay more. Even if one attacker returns your data, another will find out about your willingness to pay, which will lead to an increase in the number of attempted attacks on your company. The best you can do is to contact incident response experts as quickly as possible.

MITRE ATT&CK

Indicators of Compromise (IOCs)

Network IOCs

• hxxp://138.226.236.51/prrq[.]php
• hxxp://94.74.164.207/prrq[.]php
• hxxps://94.74.164.207/prrq[.]php
• hxxps://biggoalsports[.]co.za/minif[.]php
• hxxps://nmsneustadtl[.]ac.at/xml[.]php
• hxxps://envisionreg[.]com/wp-activate[.]php
• 138.226.236[.]51
• 94.74.164[.]207

File Hashes

• 3cd5703d285ed2753434f14f8da933010ecfdc1e5009d0e438188aaf85501612
• c9cc95ff8f2998229394dfd31c2bd6b723e826a3ca5e008d2b5be19ba419ae2c
• 3c1b9df801b9abbb3684670822f367b5b8cda566b749f457821b6481606995b3
• be1037fac396cf54fb9e25c48e5b0039b3911bb8426cbf52c9433ba06c0685ce

DISCLAIMER: All technical information, including malware analysis, indicators of compromise and infrastructure details provided in this publication, is shared solely for defensive cybersecurity and research purposes. Group-IB does not endorse or permit any unauthorized or offensive use of the information contained herein. The data and conclusions represent Group-IB’s analytical assessment based on available evidence and are intended to help organizations detect, prevent, and respond to cyber threats.

Group-IB expressly disclaims liability for any misuse of the information provided. Organizations and readers are encouraged to apply this intelligence responsibly and in compliance with all applicable laws and regulations.

This blog may reference legitimate third-party services such as Polygon and others, solely to illustrate cases where threat actors have abused or misused these platforms.