Ransomware DeadLock usa blockchain Polygon para resistir a bloqueios
Análise da Microsoft detalha um criptografador em Rust que guarda configuração em contratos inteligentes e negocia pela rede Session. Ele também freia a criptografia para não travar a máquina e passar despercebido.
Ilustração editorial original — Plugged Ninja
A Microsoft Threat Intelligence publicou em 10 de agosto de 2026 uma análise técnica do ransomware DeadLock, uma operação de motivação financeira que se destaca menos pelo criptografador em si e mais pela forma como sustenta sua infraestrutura de extorsão: parte dela vive em contratos inteligentes na blockchain Polygon e em uma rede de mensagens descentralizada.
O DeadLock foi observado pela primeira vez em julho de 2025 e opera com dupla extorsão — criptografa o ambiente da vítima e ameaça publicar dados exfiltrados. Até julho de 2026, os operadores haviam listado mais de 80 organizações em seu site de vazamento, com mais da metade das vítimas declaradas na Europa. A Microsoft identificou impacto em empresas de tecnologia da informação, mineração, transporte e logística, manufatura, hotelaria e bens de consumo, na Europa, Ásia, América do Norte, América do Sul e África.
Um detalhe relevante para quem acompanha o ecossistema: o criptografador não pertence a um único grupo. A Microsoft observou o DeadLock sendo implantado por múltiplos atores, incluindo um afiliado dos ecossistemas de ransomware Lynx e INC.
Contexto: por que a infraestrutura importa tanto quanto o malware
Operações de ransomware dependem de três coisas para monetizar um ataque: um canal de negociação com a vítima, um lugar para hospedar dados vazados e uma forma de entregar instruções de recuperação. Historicamente, tudo isso ficava em domínios .onion ou em servidores convencionais — pontos que podem ser apreendidos, derrubados ou bloqueados por operações policiais.
O DeadLock tenta reduzir essa exposição movendo a camada de configuração para fora de infraestrutura tradicional. É uma evolução de arquitetura, não de criptografia. A Microsoft avalia que isso provavelmente aumenta a resiliência de partes da comunicação, da hospedagem de vazamentos e da negociação, permitindo que os operadores se recuperem de algumas tentativas de disrupção. Vale sublinhar a formulação cautelosa: trata-se de resiliência parcial, não de imunidade.
A arquitetura de recuperação descentralizada
O elemento mais distintivo do DeadLock é o arquivo RECOVERY_CHAT.<UID>.html, uma aplicação HTML autocontida que implementa um chat com criptografia de ponta a ponta, um blog paginado de vazamento de dados e um navegador de arquivos — tudo sem servidor de backend tradicional. A arquitetura tem três componentes.
Polygon como armazenamento de configuração
Em vez de depender de domínios, os operadores guardam dados de configuração em dois contratos inteligentes na blockchain Polygon:
| Contrato | Finalidade |
|---|---|
Proxy de chat (0x8EF7c3e5...19dAe) |
Armazena a URL do servidor proxy |
Blog (0x75798450...E6426C) |
Armazena as publicações do site de vazamento |
A página HTML emite requisições eth_call a endpoints públicos de RPC da Polygon — chamadas somente leitura, que não exigem carteira — para obter o endereço do proxy. O contrato do blog aceita parâmetros de deslocamento e limite para paginação e devolve dados estruturados: títulos, corpos, carimbos de tempo, URLs de imagem e links de anexos.
A vantagem operacional para o atacante é direta: a URL do proxy pode ser trocada alterando o contrato, sem tocar em nada do lado da vítima, e não há registro de domínio nem infraestrutura de DNS a manter. Para redundância, a página percorre seis endpoints RPC públicos diferentes.
Rede Session para o canal de negociação
As mensagens entre vítima e operador trafegam pela Session, uma rede de mensageria descentralizada com roteamento em camadas (onion routing) e arquitetura de enxame, que oferece anonimato para os dois lados. O servidor proxy — cuja URL vem da blockchain — atua como retransmissor entre o navegador da vítima e os nós da rede.
A identidade Session da vítima é derivada deterministicamente das credenciais de acesso fornecidas na nota de resgate: as mesmas credenciais produzem sempre o mesmo par de chaves, e nenhum cadastro é necessário. A consequência prática, registrada pela própria Microsoft, é que a identidade se torna irrecuperável se a vítima perder as credenciais — um detalhe que importa para equipes de resposta a incidentes que precisem preservar evidências antes de qualquer decisão sobre negociação.
O criptografador: aspectos técnicos
O DeadLock é escrito em Rust e combina técnicas já estabelecidas no meio com algumas escolhas de engenharia pouco comuns.
Esquema criptográfico
O desenho é híbrido, com criptografia de curva elíptica para encapsular chaves e cifra de fluxo para o conteúdo:
| Camada | Algoritmo | Função |
|---|---|---|
| Conteúdo de arquivos | XChaCha20 | Cifra de fluxo simétrica |
| Encapsulamento de chave | Curve25519 (ECDH) + XSalsa20-Poly1305 | Empacotamento assimétrico via NaCl crypto_box |
| Geração de aleatoriedade | Windows CryptoAPI | Material de chave |
Não há, nas informações divulgadas, qualquer indicação de falha criptográfica explorável. Isso significa que a recuperação de arquivos sem a chave do operador não é viável a partir do que se sabe hoje — a defesa continua sendo prevenção, detecção precoce e backups íntegros.
Limitação de recursos para não ser notado
O aspecto de engenharia mais curioso é um mecanismo de controle de consumo de recursos projetado para manter o sistema infectado responsivo durante a criptografia. Uma thread dedicada por lote de discos funciona como despachante: antes de enviar cada arquivo para criptografia, consulta a utilização de memória e CPU. Se o uso de memória ultrapassa 29% ou a carga de CPU passa de 70% (ociosidade abaixo de 30%), a thread pausa e tenta novamente até os recursos voltarem aos limites.
A intenção é evidente: um servidor que trava chama atenção; um servidor que continua respondendo enquanto criptografa em segundo plano compra tempo. Para defensores, isso reduz a utilidade de alertas baseados em pico de CPU e reforça a necessidade de detecção por comportamento de arquivo — taxa de escrita, entropia, renomeação em massa.
Geofencing por idioma
Como verificação de saída antecipada, o malware consulta os idiomas padrão e de interface do sistema. Se algum deles constar da lista de exclusão da configuração, o programa se autoexclui imediatamente, sem criptografar nada. A lista cobre 17 identificadores de idioma associados a países da ex-União Soviética e da Comunidade de Estados Independentes — russo, ucraniano, bielorrusso, tadjique, armênio, azeri, georgiano, cazaque, quirguiz, turcomeno, uzbeque, romeno da Moldávia — além de persa (Irã), siríaco (Síria) e árabe de Omã e do Iêmen.
É um padrão comum entre operações que se acredita atuarem a partir dessas regiões. Vale notar que geofencing por idioma é um indicador circunstancial de origem, não uma prova de atribuição.
Notas de resgate com lógica de tempo
O malware distribui dois tipos de nota. A nota em texto (HOW_RECOVER.<UID>.txt) é depositada em cada diretório criptografado, mas apenas na segunda passagem do laço de processamento — na primeira, é suprimida, provavelmente para priorizar velocidade de criptografia. A Microsoft aponta uma implicação prática para analistas: em testes com configuração mínima de discos, que dispare apenas uma iteração, a nota em texto nunca aparece. Quem estiver reproduzindo o comportamento em laboratório precisa considerar isso antes de concluir que a amostra está incompleta.
Impactos, possibilidades e limitações
O uso de blockchain como armazenamento de configuração é o ponto que merece atenção estratégica. Não é uma inovação em capacidade destrutiva — é uma mudança no custo de disrupção. Derrubar um domínio é uma operação conhecida; alterar dados gravados em um contrato público não é algo que uma ordem judicial resolva. Ao mesmo tempo, a escolha tem contrapartidas para o atacante: as chamadas são públicas e auditáveis, os endereços de contrato ficam permanentemente visíveis, e o rastro on-chain oferece a pesquisadores um ponto de observação estável que domínios efêmeros não davam.
Também há limites no que se pode concluir. A análise da Microsoft cobre o criptografador e a infraestrutura de recuperação; não descreve em detalhe os vetores de acesso inicial usados pelos afiliados. Como o DeadLock é operado por grupos distintos, é razoável supor que os caminhos de entrada variem — o que significa que a defesa contra o DeadLock passa, na prática, pela defesa contra ransomware operado por humanos em geral.
O número de mais de 80 vítimas publicadas vem do site de vazamento dos próprios operadores. Listas desse tipo costumam conter exageros, repetições e organizações que negociaram, e devem ser lidas como indicador de atividade, não como censo. A ZeroFox já havia registrado o mesmo patamar de cerca de 80 vítimas em junho de 2026, com concentração semelhante na Europa — o que sugere ritmo de publicação relativamente estável nos últimos meses.
Vale notar ainda que a Lynx, um dos ecossistemas ligados a afiliados que implantam o DeadLock, é amplamente considerada uma reformulação da operação INC, o que ajuda a explicar por que ambos aparecem associados ao mesmo criptografador.
Recomendações práticas
A Microsoft recomenda um conjunto de medidas que vale reproduzir e comentar:
- Ative a proteção entregue pela nuvem no Microsoft Defender Antivirus ou no equivalente do seu fornecedor, para cobrir variantes novas e desconhecidas.
- Execute EDR em modo de bloqueio, de forma que artefatos maliciosos sejam bloqueados mesmo quando o antivírus de terceiros não detecta ou quando o Defender está em modo passivo.
- Ative proteção contra adulteração (tamper protection), impedindo que atacantes desliguem os controles de segurança — passo frequente antes da implantação do criptografador.
- Revise higiene de credenciais e endurecimento conforme a orientação da Microsoft para ransomware operado por humanos, já que o acesso inicial e o movimento lateral costumam depender de credenciais válidas.
A esses pontos convém acrescentar: mantenha backups desconectados e teste a restauração; monitore comportamento de escrita em massa em vez de confiar apenas em picos de recurso; e consulte os indicadores de comprometimento publicados no aviso original antes de encerrar uma investigação.
Conclusão
O DeadLock não redefine a criptografia usada por ransomware nem introduz um vetor de ataque inédito. O que ele mostra é uma tendência de arquitetura: operadores movendo a camada de configuração e negociação para infraestrutura que não depende de domínios, servidores ou provedores identificáveis. Combinada ao controle de consumo de recursos, que atrasa a percepção humana do ataque, essa escolha aponta para operações desenhadas para durar mais e resistir melhor a intervenções.
O que observar a seguir: se outras famílias adotarem contratos inteligentes como camada de configuração, e se as redes de mensageria descentralizadas se consolidarem como canal padrão de negociação. Ambas as mudanças alterariam o cálculo de custo das operações de disrupção conduzidas por autoridades e provedores.
Fontes e referências
- Microsoft Threat Intelligence — DeadLock ransomware: Breaking down a Rust-based encryptor with decentralized recovery infrastructure (10 de agosto de 2026)
- ZeroFox — Flash Report: DeadLock’s Ransomware Leak Site Lists over 80 Victims (junho de 2026)
- ReliaQuest — Ransomware and Cyber Extortion in Q2 2026
- Group-IB — Cat’s out of the bag: Lynx Ransomware-as-a-Service