DeadLock : le ransomware qui planque sa configuration C2 sur la blockchain Polygon pour survivre aux saisies de domaine

Rapport CTI technique du 16 août 2026

Résumé exécutif

Microsoft Threat Intelligence a publié le 10 août 2026 une analyse détaillée de DeadLock, une opération de ransomware à double extorsion active depuis juillet 2025 et qui revendiquait plus de 80 victimes sur son site de fuite au moment de la publication, réparties sur six continents avec une majorité en Europe. L'encrypteur, écrit en Rust, chiffre les répertoires ciblés avec des clés XChaCha20 individuelles par fichier et intègre un mécanisme de limitation basé sur la charge système pour rester discret pendant le chiffrement. Ce qui distingue DeadLock des opérations RaaS classiques, ce n'est pas l'encrypteur lui-même mais l'infrastructure de récupération : la page de contact des victimes interroge des smart contracts déployés sur la blockchain publique Polygon pour récupérer en temps réel l'adresse du proxy de chat et le contenu du blog de fuite, au lieu de dépendre d'un domaine ou d'un serveur unique saisissable par les forces de l'ordre.

Ce choix d'architecture ne rend pas DeadLock indestructible, il déplace le problème : les opérateurs peuvent mettre à jour l'adresse du proxy directement sur la blockchain sans redistribuer de nouvelle page HTML, et le contenu du blog hébergé par contrat résiste au retrait classique d'un hébergeur web. Le système reste néanmoins dépendant d'un service RPC Polygon joignable, avec rotation automatique entre six fournisseurs RPC publics en cas de défaillance, d'un proxy actif, et d'un stockage hors chaîne compatible Wasabi pour les fichiers volés. La messagerie de négociation transite par le réseau Session, à routage en oignon, ce qui complique également le suivi des communications entre opérateurs et victimes.

Chronologie

Date	Événement
Juillet 2025	Première observation de l'opération DeadLock (source Microsoft)
Juin 2026	Accélération de l'activité, publication de 75 nouvelles victimes sur la période, rythme comparable aux opérations RaaS établies
Juillet 2026	Plus de 80 victimes cumulées revendiquées sur le site de fuite DeadLock
10 août 2026	Publication du rapport technique complet par Microsoft Threat Intelligence
11-13 août 2026	Reprise par cybersecuritynews.com, SOC Prime, TechTimes, BankInfoSecurity, Infosecurity Magazine

Fiche d'acteur / campagne (format fiche CTI)

DeadLock | Pas de CVSS applicable (opération de ransomware, pas une CVE unique) | Cible : organisations multisectorielles (IT, mines, transport et logistique, industrie, hôtellerie, biens de consommation)

Description technique. DeadLock est un ransomware écrit en Rust qui suit un modèle de double extorsion classique dans son objectif mais atypique dans son infrastructure. L'encrypteur déchiffre d'abord un blob de configuration embarqué via un décodage XOR à clé de 8 octets, puis cible des répertoires non systèmes sélectionnés, en évitant une liste d'extensions et de noms de fichiers définie dans la configuration. Chaque fichier reçoit une clé XChaCha20 distincte, et les fichiers volumineux ne sont chiffrés que par blocs sélectionnés pour accélérer l'opération. Un mécanisme de limitation des ressources suspend le chiffrement quand l'utilisation mémoire dépasse 29 % ou la charge CPU 70 %, tout en doublant le nombre de threads de traitement par cœur disponible, un compromis pensé pour rester sous le radar d'un utilisateur ou d'un outil de supervision basique pendant l'attaque.

Avant le chiffrement, DeadLock termine les processus de sauvegarde, de sécurité, d'accès distant et de synchronisation cloud susceptibles de ralentir ou de contrecarrer l'opération, supprime le matériel de récupération existant, et efface les journaux d'événements Windows. Les fichiers chiffrés reçoivent l'extension .dlock, accompagnés d'une note et d'une page de chat de récupération au format HTML. Cette page ne contacte pas un serveur fixe : elle effectue des requêtes en lecture seule vers deux smart contracts Polygon distincts, l'un fournissant l'adresse courante du proxy de chat, l'autre stockant le contenu du blog de fuite, avec bascule automatique entre six fournisseurs RPC publics Polygon en cas d'indisponibilité de l'un d'eux.

Conditions d'exploitation. Microsoft n'a pas attribué de vecteur d'accès initial unique à DeadLock dans son rapport ; l'analyse porte principalement sur le comportement post-compromission de l'encrypteur et sur l'infrastructure de récupération. Le malware requiert une exécution sur l'hôte avec des droits suffisants pour demander une élévation administrateur, arrêter des services et modifier le papier peint du poste compromis.

PoC disponible : sans objet, il s'agit d'un ransomware opérationnel observé en conditions réelles et non d'une vulnérabilité avec preuve de concept publiable.

Patch/mitigation. Aucun correctif logiciel ne s'applique puisque DeadLock n'exploite pas une vulnérabilité unique documentée dans ce rapport ; la défense repose sur la détection comportementale et le durcissement de la surface d'attaque (voir checklist de remédiation).

Diagramme de la chaîne d'attaque

Diagramme reconstruit à partir du rapport Microsoft Threat Intelligence du 10 août 2026 et de la synthèse SOC Prime du 13 août 2026.

Analyse technique

Étape 1 : exécution et déchiffrement de la configuration

L'encrypteur Rust déchiffre son blob de configuration embarqué via un simple XOR à clé de 8 octets, une technique peu sophistiquée mais suffisante pour échapper à une inspection statique superficielle. Cette configuration contient la liste des extensions et noms de fichiers à exclure du chiffrement, ainsi que la liste des services et processus à arrêter.

Étape 2 : préparation du terrain et suppression des capacités de récupération

Avant de chiffrer quoi que ce soit, DeadLock demande une élévation de privilèges administrateur, termine les processus de sauvegarde, de sécurité, d'accès distant (type outils RMM ou VPN) et de synchronisation cloud, supprime les instantanés et sauvegardes locales disponibles, et vide les journaux d'événements Windows. Cette étape prive l'équipe de réponse à incident d'une bonne partie des preuves forensiques disponibles et des chemins de restauration rapide.

Étape 3 : chiffrement adaptatif et évasion comportementale

Le chiffrement proprement dit s'exécute avec un mécanisme de limitation des ressources : il se met en pause si l'utilisation mémoire dépasse 29 % ou la charge CPU 70 %, tout en exploitant deux threads par cœur CPU disponible pour le traitement des répertoires. Ce comportement adaptatif vise à maintenir le système suffisamment réactif pour ne pas déclencher d'alerte de performance pendant que le chiffrement progresse. Chaque fichier reçoit une clé XChaCha20 individuelle, et les gros fichiers ne sont chiffrés que par blocs, un compromis vitesse contre exhaustivité fréquent dans les encrypteurs modernes.

Étape 4 : dépôt de la note et bascule vers l'infrastructure décentralisée

Une fois le chiffrement terminé, DeadLock dépose une note de rançon, change le papier peint du poste compromis, et pointe la victime vers une page HTML de récupération. Cette page n'embarque aucune adresse de serveur fixe : au chargement, elle interroge en lecture seule les deux smart contracts Polygon pour obtenir l'adresse courante du proxy de chat et le contenu du blog de fuite, avec rotation automatique entre six fournisseurs RPC publics si l'un d'eux répond mal.

Étape 5 : négociation et publication via infrastructure décentralisée

Les communications de négociation passent par le réseau Session, un système de messagerie distribué à routage en oignon, ce qui limite la capacité des défenseurs à intercepter ou attribuer les échanges. Les fichiers volés sont accessibles via un navigateur de fichiers intégré à la page de récupération, pointant vers un stockage compatible Wasabi. Les opérateurs peuvent mettre à jour l'adresse du proxy directement sur la blockchain sans avoir à redistribuer de nouvelle page HTML aux victimes déjà infectées, ce qui rend la neutralisation par simple blocage de domaine ou saisie de serveur largement inefficace.

Indicateurs de compromission

Type	Valeur
SHA-256	a1fdf65020ce4a0f0940c793c6425baf8a0b994ec48b9baaf72788661a9d29f4 (encrypteur DeadLock)
Domaine de fuite	deadlock.liveblog365[.]com
Domaine de fuite	dlock.liveblog365[.]com
Domaine de fuite (Tor)	deadblogdbdu5wprek7wa2o4ce7rnt6u6ntqeud3hzjjcveosgpsqqqd[.]onion
Domaine de fuite	deadlockblog.great-site[.]net
Domaine de fuite	deadlockblog.medianewsonline[.]com
Extension de fichier chiffré	.dlock
Infrastructure C2	Smart contracts sur la blockchain Polygon (deux contrats : proxy de chat et contenu du blog de fuite)
Messagerie de négociation	Réseau Session (onion-routed)
Stockage des données exfiltrées	Stockage compatible Wasabi, accessible via navigateur de fichiers intégré à la page de récupération

MITRE ATT&CK

Aucune cartographie ATT&CK officielle n'accompagne le rapport Microsoft à la date de rédaction. Le tableau suivant est une lecture technique construite à partir des comportements confirmés, pas une attribution vendeur.

Tactique	Technique	ID	Justification
Privilege Escalation	Abuse Elevation Control Mechanism	T1548	Demande d'approbation administrateur avant chiffrement pour obtenir les droits nécessaires
Defense Evasion	Indicator Removal: Clear Windows Event Logs	T1070.001	Effacement des journaux d'événements Windows pendant l'exécution
Impact	Service Stop	T1489	Arrêt des processus de sauvegarde, sécurité, accès distant et synchronisation cloud avant chiffrement
Impact	Inhibit System Recovery	T1490	Suppression du matériel de récupération et des instantanés locaux
Impact	Data Encrypted for Impact	T1486	Chiffrement XChaCha20 par fichier avec extension .dlock
Command and Control	Web Service	T1102	Utilisation de smart contracts Polygon comme point de récupération de configuration C2
Command and Control	Multi-hop Proxy	T1090.003	Messagerie de négociation routée via le réseau Session (onion-routed)
Exfiltration	Exfiltration Over Web Service	T1567	Hébergement et distribution des données volées via stockage compatible Wasabi

Remédiation : checklist opérationnelle

Activer la protection cloud-delivered et le mode blocage EDR (Microsoft Defender ou équivalent) sur l'ensemble du parc, avec tamper protection pour empêcher l'arrêt des services de sécurité par le ransomware.
Déployer des règles Attack Surface Reduction (ASR) et Controlled Folder Access (CFA) pour restreindre l'écriture non autorisée dans les répertoires sensibles et l'exécution de processus suspects.
Surveiller spécifiquement les alertes de type changement de papier peint inattendu et suppression de sauvegardes, deux signaux comportementaux caractéristiques de DeadLock identifiés par Microsoft.
Isoler immédiatement tout hôte présentant un pic d'activité disque cohérent avec un chiffrement par blocs suivi d'une pause liée à la charge système, plutôt que d'attendre la note de rançon.
Renforcer l'hygiène des identifiants et limiter l'usage de PSExec et WMI aux comptes de service strictement nécessaires, ces deux outils étant des vecteurs de mouvement latéral courants dans ce type d'opération.
Protéger les sauvegardes hors ligne ou immuables, séparées du domaine d'administration principal, pour survivre à la suppression du matériel de récupération local.
Bloquer ou journaliser le trafic sortant vers les fournisseurs RPC Polygon publics connus depuis les postes utilisateurs, ce trafic étant atypique en dehors d'un contexte métier lié à la blockchain.
Tester et répéter les procédures de réponse à incident en amont, la vitesse de containment étant le facteur déterminant face à un encrypteur qui supprime activement les preuves forensiques.