Ransomware mira NAS Synology; vetor ainda em disputa

CORREÇÃO DO REGISTRO. A Synology não é a organização comprometida: não encontrei evidência de invasão da infraestrutura dela. Ela é a fabricante que avisou os clientes. As vítimas são donos de NAS com DSM desatualizado e exposto, entre pessoas físicas, pequenas empresas e organizações maiores, sem número apurado. Por isso o selo passa de 'claimed' para 'confirmed' e o veredito de 'unverified' para 'real', no sentido de que o incidente existe, não no de que a escala seja conhecida. Também não há alegação de ator com contagem de registros: o ransomware cifra, e nenhuma fonte lida descreve exfiltração, então claimed_records e verified_records ficam nulos. A manchete do registro (um título de notícia) também foi substituída pelo nome da vítima.

O QUE CADA PARTE DIZ. A Synology (fonte A) diz que atacantes miram dispositivos com DSM desatualizado para cifrar dados e extorquir, e remete ao SA-24:20, de 2024, que cobre CVE-2024-10441 (execução de código), CVE-2024-50629 (leitura de arquivos) e CVE-2024-10445 (escrita de arquivos). Li a declaração apenas por reproduções: BleepingComputer, iThome, CSIRTCAN e uma documentação de incidente no GitHub que cita o texto original. Segundo essas reproduções, o comunicado não cita C3RB3R, .L0CK3D, número de vítimas nem versão corrigida. O título do BleepingComputer atribui o nome da família à Synology, mas o corpo do texto diz que a empresa ainda não informou qual falha é explorada. A identificação da família vem de análise de terceiros e da nota de resgate. A 360 diz que, desde outubro, atendeu vários casos, identificou o C3RB3R como variante do Cerber e atribuiu a entrada a duas falhas divulgadas em setembro.

ONDE AS VERSÕES DIVERGEM. Há três narrativas sobre a entrada. (1) Synology: falha de

2024. (2) 360: CVE-2026-13639 e CVE-2026-13684, corrigidas em 18/09/2026 (SA-26:13), ou seja, a janela entre patch e exploração é de cerca de duas a seis semanas, o padrão clássico de 1-day. (3) Solar: um dispositivo em DSM 7.4.1-90080 Update 1, na prática atual, com a entrada ainda sob investigação e sem descartar falha nova, pacote, credencial ou serviço exposto. O SA-26:13 lista 7.4-90075 como piso corrigido para o DSM 7.4. Não verifiquei como o build 7.4.1-90080 se ordena em relação a ele. Pelo que li, o caso da Solar não se encaixa bem em nenhuma das duas teses, e isso é um dado, não uma conclusão. Uma análise (ZimaSpace) observa que as capacidades descritas no SA-26:13 (leitura/escrita de arquivos, DoS) não documentam, por si, como o executável foi lançado.

CLAIMS NÃO SUSTENTADOS. A HKEPC afirmou 'duas falhas RCE com CVSS 10.0, sem credenciais'. O SA-26:13 traz 9.8 e descreve leitura/escrita de arquivos e DoS. Relatos repassados também citam Docker/GitLab e o PHP2Shell como vetores, mas nenhuma fonte lida mostra a Synology ligando o SA-26:14 à campanha, e a empresa nega relação com PHP. Postagens que falam em '0-day' e 'milhares de NAS' não trazem número rastreável: viralizaram entre os dois comunicados oficiais e antes de qualquer contagem. Note-se que o SA-26:14 trata de falhas reais de RCE em Mail Station, Calendar e PHP. É risco legítimo, só que sem prova de ligação com esta campanha.

O QUE A EVIDÊNCIA DE CAMPO MOSTRA. Os arquivos recebem a extensão .L0CK3D e uma nota read-me3.txt com o cabeçalho 'C3RB3R INSTRUCTIONS', que remete a um site Tor e a uma ferramenta paga, 'C3rb3r Decryptor'. A nota é do BleepingComputer; o valor, cerca de US$ 2.952 em bitcoin dobrando após cinco dias, é relato de fonte secundária de baixa confiança. O site Tor oferece teste de descriptografia de um arquivo de até 1.024 KB. Em um repositório de pesquisa colaborativa, num caso com Hyper Backup, 164.136 de 202.378 arquivos tinham o sufixo .L0CK3D e 38.242 não tinham. O mesmo material observa criptografia intermitente em arquivos grandes. Esses dados vêm de um caso único, relatado por terceiros, e não generalizam. As fontes secundárias discordam do esquema criptográfico (ChaCha8 com RSA-2048 num relato, RSA-4096 com AES ou ChaCha20 em outro). Até 30/10/2026, nenhuma fonte lida confirma decriptador gratuito.

POR QUE ISSO IMPORTA. O padrão se repete: NAS exposto, patch não aplicado e backup no mesmo equipamento, sobretudo em dispositivos que não aparecem no inventário de TI. O próprio BleepingComputer registra que avisos desse tipo da Synology são raros: o anterior foi em agosto de 2019, por ataques de força bruta com o eCh0raix. A coincidência temporal com o SA-26:14 explica parte do ruído, mas não prova relação.

As vítimas são proprietários de NAS Synology com DSM desatualizado e exposto, entre pessoas físicas e empresas. O dano relatado é a perda de acesso a arquivos compartilhados, repositórios de código, imagens de banco de dados e backups locais, inclusive Hyper Backup no mesmo equipamento, segundo relatos de campo. Não há número confirmado de dispositivos, nem notificação regulatória que eu tenha encontrado (ANPD, SEC ou equivalente). Também não há evidência lida de exfiltração de dados nem de pagamento de resgate.