Ransomware C3RB3R no Synology: Origens, Recuperação e Como Se Manter Seguro

Ransomware C3RB3R começou a aparecer em unidades Synology NAS por volta de 28 de outubro de 2026 e, dentro de um dia, era o único assunto no r/synology. Os arquivos voltam renomeados com uma extensão .L0CK3D (um zero, não a letra O), cada pasta recebe uma nota de resgate read-me3.txt e um portal Tor pede Bitcoin. As informações mais rápidas e úteis não vieram de sites de notícias em inglês. Vieram de fóruns de língua chinesa, onde a Synology tem uma enorme base de usuários, e de três repositórios do GitHub escritos por vítimas que realmente recuperaram seus dados, ou provaram que não conseguiram. Este guia reúne o que foi confirmado sobre o ransomware C3RB3R até agora: de onde veio, como ele entra, o único caminho de recuperação que funcionou e o design de backup que executamos para que um ataque como esse nos custe uma restauração em vez de um resgate.

Atualização, 31 de outubro de 2026: A Synology definiu agora o ponto de entrada. Num e-mail aos clientes a 30 de outubro, confirmou que o ransomware C3RB3R explora apenas a vulnerabilidade corrigida em Synology-SA-24:20, corrigida em dezembro de 2024, e que a campanha não está relacionada com a vulnerabilidade PHP2Shell corrigida no mesmo mês. Adicionámos a própria lista de verificação de quatro passos da Synology, a nossa interpretação do motivo pelo qual os ataques ocorreram quando ocorreram e uma camada extra que utilizamos e pela qual a maioria dos proprietários já paga: a proteção contra ransomware do Active Insight.

Ponto SynoPower Club:Uma vítima em um grupo chinês de NAS tinha mais de 50 TB em uma única caixa e nenhuma snapshot. O encriptador foi lento o suficiente para que apenas suas fotos de 2024 fossem atingidas, e essas por acaso tinham uma cópia fria em um drive na nuvem. Outra perdeu cinco anos de repositórios privados do GitLab, porque o RAID 6 mais três backups viviam todos na mesma máquina. O ransomware C3RB3R não venceu o armazenamento deles, venceu o design de backup deles. Executamos nossos sites públicos como Docker dentro do Virtual DSM, tiramos snapshots de todo o convidado a partir do host, replicamos para um segundo NAS e exportamos para USB e nuvem em um cronograma. Se um convidado for criptografado hoje à noite, nós o revertemos para a última snapshot e o atacante não ganha nada.

O que é o ransomware C3RB3R?

O ransomware C3RB3R é uma versão para Linux da família Cerber, uma linha de ransomware que existe desde 2016 e tem como alvo dispositivos NAS esporadicamente há anos. A 360 atribui a onda de outubro de 2026 na Synology a ele. Em uma caixa DSM infectada, o encriptador do ransomware C3RB3R é executado como um binário x86-64 estaticamente vinculado e compactado com UPX chamado libgldEle exclui seu próprio arquivo após iniciar, portanto, o processo em execução exibe (excluído) ao lado do caminho do executável.

O que você vê como proprietário de uma caixa atingida pelo ransomware C3RB3R é consistente em todos os relatórios:

• Arquivos renomeados para nome.ext.L0CK3DAlguns relatórios escrevem como LOCK3D, mas as análises do GitHub citam o zero.
• Uma nota de resgate chamada nota de resgate read-me3.txt em cada pasta criptografada, com o cabeçalho C3RB3R INSTRUCTIONS.
• Uma página Tor intitulada C3rb3r Decryptor. A captura de tela de uma vítima mostrou 0,03696 BTC (cerca de US$ 2.952) se pago dentro de cinco dias, dobrando para 0,07392 BTC (cerca de US$ 5.904) depois disso, com uma contagem regressiva.
• Persistência por meio de entradas cron correspondentes a /etc/cron.d/synot*, que se recriam e sobreviveram a uma atualização do DSM em pelo menos um caso.
• Arquivos de backup no mesmo volume criptografados junto com todo o resto, incluindo destinos do Hyper Backup e dumps de banco de dados.

Onde começou: r/synology e os fóruns chineses

O ransomware C3RB3R apareceu pela primeira vez em inglês no r/synology, onde as vítimas postaram com cerca de um dia de diferença entre si por volta de 28 e 29 de outubro de 2026. Em questão de horas, os leitores diziam que uma nova thread aparecia cada vez que recarregavam o subreddit. Vale a pena ler três dessas threads na íntegra, porque cada uma adiciona uma peça diferente:

• A análise forense. Um proprietário de DS918+ no DSM 7.2.1-69057 Update 5, com a interface web acessível pela internet, desligou a caixa e examinou os discos no modo somente leitura em um host Proxmox. O log de autenticação do DSM continha uma solicitação de login cujo campo de conta carregava linhas injetadas de LD_PRELOAD e LD_DEBUG_OUTPUT além de um comando de shell codificado e um arquivo em /etc/cron.dIsso corresponde à técnica publicada da CVE-2024-10441. Um backup 3-2-1 significou que o ataque custou uma restauração, não um resgate. Leia aqui: Bem, finalmente aconteceu. Meu primeiro incidente real de ransomware.
• O usuário exclusivo do Photos. Este proprietário acreditava que o DSM estava atualizado e usava apenas o Synology Photos, mas o UPnP no roteador estava ativado. Após uma redefinição de modo 2, as pastas cobertas pela Snapshot Replication retornaram. As pastas sem snapshots não retornaram, e a unidade USB do Hyper Backup local foi criptografada junto com o NAS. Leia aqui: Atingido pelo ransomware c3rb3r esta manhã.
• A discussão sobre o QuickConnect. O autor da postagem original só percebeu depois que o DSM se degradou e uma reinstalação revelou os arquivos criptografados. Nas respostas, outro leitor com senha forte, 2FA e QuickConnect ativado disse que também havia sido atingido, e outros apontaram que usuários de aplicativos específicos podem desativar o acesso ao DSM no QuickConnect completamente. Leia aqui: Atingido pelo ransomware C3RB3R.

Lidos juntos, o padrão é claro. O ransomware C3RB3R precisava de uma página de login do DSM que pudesse alcançar, nada mais. Senhas e 2FA não ajudaram, porque a exploração é executada antes da autenticação. A análise forense deixou claro: a solicitação atingiu um aplicativo vulnerável e outro aviso de senha não teria corrigido isso.

O trabalho técnico mais aprofundado ocorreu em chinês. Vítimas em grupos do WeChat e do Xiaohongshu publicaram notas de resgate, compararam cronogramas e direcionaram-se umas às outras para os repositórios do GitHub abordados abaixo. Uma comunidade taiwanesa da Synology no Facebook reuniu os mesmos links de recuperação para os usuários locais. Faz sentido: a Synology é uma empresa taiwanesa e suas maiores comunidades de usuários falam chinês, por isso foi de lá que veio o maior volume de casos do ransomware C3RB3R e, consequentemente, a identificação de padrões mais rápida.

A própria Synology publicou um aviso de segurança em 29 de outubro de 2026, afirmando ter identificado atores de ameaças explorando uma vulnerabilidade corrigida em dezembro de 2024 em versões desatualizadas do DSM, e instando todos a atualizarem imediatamente.

Como o Ransomware C3RB3R Entra

Durante os primeiros dois dias, existiam dois pontos de entrada candidatos. Desde então, a Synology confirmou o mais antigo. O seu e-mail de 30 de outubro afirma que os ataques exploram apenas a vulnerabilidade abordada em Synology-SA-24:20 e que o ransomware C3RB3R não tem nada a ver com o PHP2Shell. A tabela abaixo mostra ambos os candidatos conforme foram debatidos, porque o par 360 ainda vale a pena ser corrigido.

	A Synology diz	A 360 diz
Consultivo	Synology-SA-24:20 (Pwn2Own 2024)	Synology-SA-26:13
CVE	CVE-2024-10441, CVSS 9.8, execução remota de código não autenticada no daemon de plugin do sistema	CVE-2026-13639 (lógica de login) e CVE-2026-13684 (SCGI), ambos CVSS 9.8
Corrigido	Novembro a dezembro de 2024	18 de setembro de 2026
Compilações corrigidas	DSM 7.2.2-72806 Atualização 1, 7.2.1-69057 Atualização 6, 7.2-64570 Atualização 4, 7.1.1-42962 Atualização 7	DSM 7.4-90075, 7.3.2-86009 Atualização 4, 7.2.2-72806 Atualização 9, 7.2.1-69057 Atualização 12

As evidências forenses apontam para a falha mais antiga em pelo menos algumas vítimas. A análise mais detalhada no Reddit correlacionou os seus próprios logs sobreviventes ao exploit publicado do CVE-2024-10441, observando também que a Synology não tinha confirmado e que o mesmo dispositivo também estava abaixo do nível de correção SA-26:13. A análise de soimy menciona que os logs de memória do convidado infectado apontam para injeção de variável de ambiente através do plugin de login do DSM, consistente com o CVE-2024-10441, e uma prova de conceito pública que explora o campo de nome de usuário de login apareceu no GitHub dias antes do surto. Dois dos três casos de resgate documentados eram executados em hardware não genuíno com um bootloader do DS918+, um deles no DSM 7.2-64570 Update 3, o que fica exatamente a uma atualização de distância da correção do CVE-2024-10441. Hardware clonado não pode receber atualizações oficiais facilmente, tornando-o o alvo mais vulnerável do grupo.

A conclusão prática não mudou: atualize para uma versão que cubra ambos os avisos e pare de expor o DSM à internet. Mas uma questão permanecia. Se a falha foi corrigida em dezembro de 2024, por que razão tantos dispositivos dispararam com o ransomware C3RB3R dentro dos mesmos dois dias em outubro de 2026, incluindo alguns cujos proprietários acreditavam estar atualizados?

Plantado Cedo, Detonado no Momento Certo

A nossa interpretação, sendo esta a nossa leitura e não algo afirmado pela Synology, é de que a invasão pelo ransomware C3RB3R e a encriptação são dois eventos distintos. As evidências apontam nessa direção:

• O backdoor veio primeiro. No caso do Xiaohongshu abaixo, uma shell de backdoor esteve presente no NAS durante 37 dias e ativou o telnet como root antes que um único ficheiro fosse encriptado.
• Sobrevive a atualizações. As entradas do cron sob /etc/cron.d/synot* recriam-se a si mesmas, e pelo menos uma vítima encontrou-as ainda ativas após atualizar para o DSM mais recente. A atualização fechou a falha, mas deixou o intruso no interior.
• As detonações foram sincronizadas. Os dispositivos afetados pelo ransomware C3RB3R que tinham sido comprometidos em momentos diferentes, em versões diferentes, começaram a encriptar num intervalo de cerca de 48 horas entre si.

Esse padrão encaixa-se num operador que instalou implantes do ransomware C3RB3R em dispositivos não corrigidos ao longo de meses e depois escolheu quando premir o gatilho remotamente. O momento escolhido foi a semana do PHP2Shell, quando todos os administradores da Synology estavam ocupados a aplicar correções, muitos dispositivos tinham acabado de ser atualizados e os proprietários se sentiam seguros por o terem feito. A Synology é clara em como o PHP2Shell não foi a via de entrada. Foi o disfarce. A lição é que um dispositivo exposto enquanto não corrigido deve ser tratado como comprometido até ser verificado, que é exatamente o que o primeiro passo da lista de verificação da Synology solicita.

Primeira Resposta ao Ransomware C3RB3R em 4 Passos

Se você encontrar extensão .L0CK3D arquivos agora mesmo, a ordem dos próximos dez minutos decide se a recuperação é possível. A chave que desbloqueia seus arquivos existe apenas dentro do processo em execução do ransomware C3RB3R. Uma reinicialização, um kill -9 ou uma reinstalação do DSM irá destruí-la.

Os comandos das etapas 2 e 3 são parecidos com estes. Leia os repositórios antes de executar qualquer coisa, pois os detalhes dependem do binário que você possui.

# Etapa 2: encontre o criptografador (seu executável aparece como excluído)

ls -l /proc/*/exe 2>/dev/null | grep deleted

# Congele-o. Nunca use kill -9 aqui.

kill -STOP <PID>	grep State /proc/<PID>/status # deve mostrar T (stopped)	# Procure pela persistência que o traz de volta	ls -l /etc/cron.d/ | grep synot
Você Pode Descriptografá-lo? Os Três Casos de Resgate no GitHub	Não existe um descriptografador universal para o ransomware C3RB3R, e qualquer pessoa que esteja vendendo um está apenas especulando. O que existe são três estudos de caso detalhados que informam exatamente quando a recuperação funciona.	Repositório	Máquina
Resultado	Motivo	Repositório	soimy/c3rb3r-rescue
DSM em uma máquina virtual Proxmox VE executando o GitLab	Recuperado	Uma cópia de 16 GiB da RAM do convidado mantinha a chave de sessão de 48 bytes. O GitLab foi restaurado com 80 projetos e 9.253 objetos LFS.	O encriptador já tinha encerrado cerca de 30 horas antes. A varredura completa da RAM e da swap não encontrou nenhuma chave.

O terceiro repositório é o mais importante para ler, porque seu título é a sua lição: "nunca reiniciado" não significa recuperável. O que importa é se o processo do ransomware C3RB3R ainda está ativo. Assim que ele é encerrado, ele zera seu buffer de chave, e a chave desaparece. Uma chave recuperada em uma vítima também é inútil em outra, porque cada execução gera uma nova chave de sessão.

Por que a chave reside apenas na memória

A análise do Benjamin-zlt detalha o formato de arquivo do ransomware C3RB3R e explica tanto por que isso funciona quanto por que geralmente não funciona.

• Cada arquivo recebe sua própria chave ChaCha8 aleatória. Essa chave é encapsulada com uma chave mestre de sessão usando AES-256-CBC e armazenada em um trailer de 588 bytes no final do arquivo.
• A chave mestre de sessão tem 48 bytes: um IV de 16 bytes mais uma chave AES de 32 bytes. Ela nunca é gravada no disco. Um ponteiro global dentro do processo em execução aponta para ela.
• O trailer também carrega um blob encapsulado com a chave pública do atacante (RSA-2048), portanto, sem o processo em execução, apenas o atacante pode recuperar a chave de sessão.
• Nem todo arquivo é totalmente encriptado. Em uma amostra de 400 arquivos, cerca de 56% usaram o modo segmentado, 31% tiveram apenas o primeiro 1 MiB encriptado e 13% foram encriptados de ponta a ponta. Arquivos parcialmente encriptados ainda não são legíveis, mas a triagem do rodapé indica o que sobrou.

Portanto, a vulnerabilidade no ransomware C3RB3R é estreita e limitada no tempo: o encriptador mantém a chave mestre na memória durante toda a sessão. Congele-o enquanto estiver em execução e você poderá extrair a chave. Se perder essa janela, resta apenas o blob da chave pública, que foi projetado para ser inquebrável.

A história de uma vítima: 50 TB e nenhum snapshot

Um relato detalhado publicado no Xiaohongshu em 29 de outubro de 2026 pelo usuário 柯基爱好者 acompanha um membro do seu grupo de NAS durante a noite. Ele notou a nota do ransomware C3RB3R, confirmou o cabeçalho C3RB3R INSTRUCTIONS e esteve prestes a comprar Bitcoin antes que o grupo o direcionasse para os casos no GitHub.

Ele usou então um assistente de codificação com IA via SSH para investigar. O assistente encontrou e congelou o encriptador, garantindo que nada novo fosse encriptado a partir daquele momento. Também descobriu que um provável shell de backdoor estava ativo no NAS há 37 dias e havia habilitado o telnet como root, o que significa que a invasão inicial e a encriptação ocorreram com mais de um mês de diferença. O assistente escreveu um script de coleta de evidências e, corretamente, aguardou sua confirmação antes de executar qualquer coisa como root.

A sorte dele foi que o ransomware C3RB3R é lento. Com mais de 50 TB para processar, o encriptador havia alcançado apenas suas fotos de 2024, que possuíam uma cópia de segurança em nuvem. Ele moveu os dados de trabalho para um NAS menor e reservou o volume encriptado para depois. Seu próprio resumo foi direto: ele não tinha snapshots, e com snapshots isso teria sido fácil de resolver. Uma segunda vítima no X resumiu a mesma lição do outro lado: RAID 6 mais três conjuntos de backup, todos no mesmo equipamento, todos encriptados juntos.

Como mantemos o ransomware C3RB3R longe dos nossos backups

Cada história de perda de dados acima tem o mesmo padrão: os backups podiam ser acessados a partir da máquina comprometida. O ransomware C3RB3R encripta tudo o que o DSM comprometido consegue gravar, portanto, a solução é manter pelo menos uma cópia em algum lugar onde o DSM não possa gravar de forma alguma. É assim que fazemos para os sites que hospedamos, e isso se alinha à regra 3-2-1-1-0.

Regra	Significado	Como fazemos
3	Três cópias dos dados	A VM em execução, uma réplica em um segundo NAS e uma exportação agendada
2	Dois tipos de mídia	Volumes do NAS mais uma unidade USB e um armazenamento em nuvem
1	Uma cópia fora do local (off-site)	Exportações sincronizadas com o Google Drive via Cloud Sync
1	Uma cópia offline ou imutável	Snapshots da VM no lado do host que o convidado não pode tocar, além da exportação em USB desconectada
0	Zero erros na restauração	Nós realmente restauramos e inicializamos a partir das réplicas quando movemos VMs entre hosts

Execute o Docker dentro do Virtual DSM, não no host

Nossos contêineres do WordPress não são executados no NAS físico. Eles rodam dentro de um convidado Virtual DSM, e o convidado é protegido pelo Virtual Machine Manager no host. Se o ransomware C3RB3R obtiver acesso root dentro do convidado, ele dominará apenas aquele convidado e nada mais. Os snapshots do convidado residem no armazenamento do host, fora do sistema de arquivos do convidado, portanto, o ransomware dentro da VM não pode vê-los, muito menos encriptá-los ou excluí-los. A recuperação é uma reversão de snapshot realizada em questão de minutos.

O VMM Pro adiciona os recursos que transformam isso em um backup real: um plano de proteção que tira snapshots da VM e a replica para um segundo NAS no cluster, garantindo cobertura caso um host falhe. Nosso cluster é composto por um DS1621xs+ e um DS1525+ que se replicam mutuamente. Escrevemos sobre a exportação agendada e o Cloud Sync para o Google Drive parte separadamente, e a comparação entre o VMM gratuito e o VMM Pro explica quais partes exigem a licença.

Se você executa o Docker diretamente no DSM, use snapshots imutáveis

Nem todos querem uma camada de VM. Se seus contêineres executam no host, a defesa contra o ransomware C3RB3R são os snapshots imutáveis. Ative-os no Snapshot Replication para a pasta compartilhada que contém os dados dos seus contêineres. Eles exigem o DSM 7.2 ou posterior e um volume Btrfs e, durante o período de bloqueio, ninguém pode excluí-los, incluindo uma conta de administrador assumida pelo invasor. Dois detalhes determinam o sucesso ou fracasso disso:

• Use bind mounts em uma pasta compartilhada como /volume1/docker/app. Volumes nomeados do Docker ficam em /volume1/@docker, que não é uma pasta compartilhada e não pode receber snapshots.
• Faça o dump de bancos de dados para um arquivo antes do snapshot. Um snapshot de um MariaDB em execução é uma cópia equivalente a uma queda de energia. Um mysqldump na mesma pasta compartilhada oferece um ponto de restauração limpo que o snapshot então bloqueia.
• Escolha um período de bloqueio mais longo do que um invasor possa permanecer em silêncio. A vítima acima teve um backdoor por 37 dias antes de a criptografia começar. Sete dias de snapshots imutáveis não teriam retrocedido até um estado limpo.

A Nossa Camada Extra: O Active Insight Tira um Snapshot Quando a Encriptação Começa

Eis a camada que a maioria dos guias omite. O Active Insight, o serviço de monitorização na nuvem da Synology, pode monitorizar a atividade de ficheiros nas suas pastas partilhadas e, assim que determina que está perante um ransomware, reage por si próprio. A Synology documenta isto no seu guia de segurança do NAS: quando é detetado um evento de ransomware, o Active Insight envia uma notificação do evento e tira automaticamente um snapshot da pasta partilhada, e nos modelos compatíveis, esse snapshot é imutável.

Por que razão isto é importante para o ransomware C3RB3R em particular: o encriptador do ransomware C3RB3R é lento. A vítima com mais de 50 TB ainda ia nas fotos de 2024 quando se apercebeu. Um snapshot tirado quando o padrão de encriptação surge pela primeira vez congela tudo o que ainda não foi tocado, o que pode ser a maior parte do volume. Também não importa como o ransomware C3RB3R entrou, porque monitoriza o que acontece aos ficheiros, e não a página de início de sessão. No nosso DS1621xs+, a página Atividade de Ficheiros mostra a proteção contra ransomware como Protegido.

Leia os limites antes de confiar nele. Estes provêm da documentação da Atividade de Ficheiros:

• A monitorização da atividade de ficheiros está desativada por predefinição. Registe o NAS no Active Insight no Painel de Controlo e, em seguida, ative a monitorização para cada anfitrião no portal do Active Insight.
• Necessita do Snapshot Replication, DSM 7.2 ou posterior, Active Insight 3.0.2 ou posterior, pelo menos 1 GB de memória e uma licença do Active Insight atribuída a esse NAS.
• No máximo um snapshot automático por pasta partilhada por dia. Trata-se de uma rede de segurança criada após a deteção, e não de uma substituição para snapshots imutáveis agendados.
• Não coberto: Pastas de gravação do Surveillance Station e pastas partilhadas em unidades USB externas.
• A imutabilidade depende do modelo. Num modelo sem snapshots imutáveis, um atacante com acesso root ainda pode eliminar o snapshot automático, pelo que deve combiná-lo com o agendamento de snapshots imutáveis acima.

Quer a mesma configuração? O SynoPower Club vende licenças originais para ambos os componentes: uma licença do Virtual DSM (VDSM) para executar seus serviços Docker em um convidado isolado e uma Licença VMM Pro para planos de proteção, replicação entre NAS e migração ao vivo. As chaves são entregues por e-mail.

Onde encontrar mais recursos oficiais

O ransomware C3RB3R no Synology é público há apenas dois dias no momento em que este texto foi escrito e ainda não há cobertura oficial em vídeo, portanto, esta seção lista fontes primárias em vez de tutoriais.

• O aviso de segurança da Synology de 29 de outubro de 2026, que indica aos utilizadores de versões desatualizadas do DSM para atualizarem imediatamente e ativarem as atualizações automáticas, seguido a 30 de outubro por um e-mail aos clientes a confirmar a SA-24:20 como a única vulnerabilidade envolvida.
• Synology-SA-24:20 e Synology-SA-26:13 são as tabelas de versão. Verifique sua compilação no Painel de Controle, depois em Atualizar e Restaurar, em relação a ambas.
• DSM em uma máquina virtual Proxmox VE executando o GitLab é o melhor índice de todos os casos conhecidos, incluindo os não abordados aqui, e a explicação mais clara de quando a perícia em memória é inútil.
• As três threads do r/synology indicadas acima, especialmente a análise forense, que inclui os comandos de investigação de disco somente leitura passo a passo: Bem, finalmente aconteceu.

Lista de Verificação da Própria Synology (30 de outubro de 2026)

O e-mail da Synology termina com quatro passos. Eles são curtos e cada um deles é importante contra o ransomware C3RB3R:

1. Verifique a existência de intrusos. O ransomware C3RB3R deixa persistência agendada para trás, por isso execute uma verificação no Security Advisor e, em seguida, procure no Agendador de Tarefas por scripts que não tenha criado e em Utilizador e Grupo por contas de administrador que não tenha adicionado. Se algo parecer errado, entre em contacto com o Suporte Synology.
2. Atualize tudo. Instale o DSM mais recente no Painel de Controlo, Atualização e Restauro, e depois atualize todos os pacotes no Centro de Pacotes.
3. Ative as atualizações automáticas em Atualização e Restauro, para que as futuras correções de segurança sejam aplicadas assim que forem lançadas.
4. Mantenha uma cópia de segurança num local externo. Utilize o Hyper Backup e o Snapshot Replication para manter uma cópia num local separado e verifique regularmente se as tarefas de cópia de segurança são efetivamente concluídas.

O primeiro passo é aquele que as pessoas ignoram. Se o seu dispositivo estava acessível a partir da Internet antes da correção de dezembro de 2024, o ransomware C3RB3R pode já ter ganho uma posição de entrada e atualizar hoje não lhe diz se alguém já está no interior.

Uma Ferramenta Gratuita que Executa a Verificação por Si

Se estiver familiarizado com o terminal, o primeiro passo pode agora ser um único comando. synology-nas-cli é uma ferramenta de linha de comandos de código aberto sob a licença MIT, lançada a 30 de outubro de 2026 pelo programador independente Akari Sora. A ferramenta inicia sessão no DSM através da sua API web e audita o sistema contra esta campanha. O projeto está no GitHub: akari-sora/synology-nas-cli.

Lemos todo o seu código antes de colocar o link. Utiliza apenas a biblioteca padrão do Python e não comunica com nada para além do seu NAS, do servidor de downloads da Synology, do PyPI e do kit de ferramentas de resgate soimy. Não envia qualquer telemetria e a auditoria básica é apenas de leitura. Eis o que ela verifica:

• Nível de patch. A sua versão do DSM em relação ao Synology-SA-26:13, que também cobre a correção anterior SA-24:20, e os seus pacotes instalados em relação ao SA-26:14.
• Exposição. QuickConnect, encaminhamento de portas UPnP no router, a firewall do DSM, AutoBlock, SMB1 e a conta de administrador integrada.
• Vestígios do ransomware C3RB3R. As strings de início de sessão injetadas no registo de ligações, /etc/cron.d/synot* entradas, os libgld e qnetd binários, contas root adicionais, chaves SSH e notas de resgate nas suas partilhas.
• Instantâneos. Pastas partilhadas que não possuem um agendamento de snapshots a funcionar.

Também pode corrigir a maior parte do que encontrar. Se os ficheiros estiverem a ser encriptados neste momento, o seu comando contain congela o encriptador com SIGSTOP, o mesmo passo da segunda etapa da nossa lista de primeira resposta. O seu comando rescue aciona depois o kit de ferramentas soimy para capturar a memória e procurar a chave.

nas incident                 # auditoria apenas de leitura

Leia estas notas antes de permitir que ele altere qualquer coisa:

• É totalmente novo. O projeto tem apenas alguns dias, provém de um único programador, não está afiliado à Synology e teve pouca revisão externa. Comece com a auditoria apenas de leitura e a execução de teste (dry run).
• A correção da firewall pode bloqueá-lo. Altera a firewall do DSM para negar tudo, exceto as redes que listar. Execute-o a partir de um computador na mesma LAN e saiba onde fica o botão RESET.
• Desativa o QuickConnect. Essa é a definição mais segura, mas se a sua família aceder ao Synology Photos ou ao Surveillance Station através do QuickConnect, configure primeiro uma VPN ou o Tailscale.
• A verificação profunda, o contain e o rescue são executados como root. Funcionam através de uma tarefa temporária no Agendador de Tarefas, pois essa é a única forma de ler registos exclusivos do root e congelar processos.
• O README sugere entregar a tarefa a um agente de IA. Se o fizer, mantenha a palavra-passe num gestor de palavras-passe em vez de no chat, e confirme a correção você mesmo.
• O resgate de memória apenas funciona enquanto o encriptador estiver ativo. Aplica-se a mesma regra dos três casos do GitHub.

Para o restante do panorama de reforço de segurança, nossos guias sobre executar um site público em um Synology NAS e sobre o que o Threat Prevention pode e não pode ver cobrem a parte de rede, e o guia de patch do PHP2Shell cobre o outro problema crítico que surgiu na mesma semana.

Limites e Notas de Segurança do Ransomware C3RB3R

Atualizar não remove uma infecção existente. Pelo menos uma vítima descobriu que a persistência do cron ainda estava ativa após a atualização para o DSM mais recente. Se você esteve exposto sem ter aplicado o patch, verifique /etc/cron.d, o Agendador de Tarefas, os scripts de inicialização e os serviços ativados, como o telnet, e depois redefina todas as credenciais.

Estar atualizado não é o mesmo que estar limpo. Uma vítima do Reddit acreditava que o DSM estava atualizado e outra foi atingida mesmo com 2FA e uma palavra-passe forte ativadas. Um dispositivo que foi comprometido antes de ser corrigido pode carregar o implante através de todas as atualizações posteriores. Trate qualquer página de início de sessão do DSM acessível a partir da Internet como um alvo, incluindo as publicadas por UPnP que nunca configurou deliberadamente. Utilize uma VPN ou Tailscale para acesso remoto e desative o UPnP no router.

RAID e backups locais não são backups contra o ransomware C3RB3R. Qualquer local em que o DSM comprometido possa gravar será criptografado, incluindo destinos do Hyper Backup na mesma máquina e compartilhamentos de rede montados.

Não pague antes de ler os casos. Pagar os operadores do ransomware C3RB3R financia a próxima onda e não garante nada. Se o criptografador ainda estiver em execução, o caminho pela memória RAM livre é sua melhor chance. Caso contrário, as únicas opções realistas são suas próprias cópias externas.

Cuidado com o que você cola em um assistente de IA. Ferramentas de IA ajudaram várias vítimas aqui, mas não forneça a elas senhas, chaves recuperadas, dumps completos de memória ou dados corporativos. Deixe que elas proponham comandos e execute você mesmo tudo o que exigir acesso root.

Hardware clonado envolve riscos adicionais. Várias vítimas documentadas executavam o DSM em hardware não oficial, onde as atualizações oficiais são difíceis ou impossíveis de aplicar. Se esse for o seu caso, assuma que você está sem patch e mantenha-o totalmente fora da internet.

Referências

• Aviso de segurança da Synology sobre ataques de ransomware no DSM, 29 de outubro de 2026.
• Synology-SA-24:20 DSM (Pwn2Own 2024), CVE-2024-10441 e as compilações corrigidas do DSM.
• Synology-SA-26:13 DSM, CVE-2026-13639 e CVE-2026-13684, publicado em 18 de setembro de 2026.
• Resgate bare-metal do ransomware C3RB3R por Benjamin-zlt, o formato de arquivo, a estrutura da chave e o fluxo de trabalho do SIGSTOP.
• synology-nas-cli por Akari Sora, uma ferramenta de auditoria e resposta de código aberto para esta campanha.
• IT-Connect sobre a campanha do C3RB3R, resumindo a atribuição da 360 e o cronograma.
• Centro de Conhecimento da Synology: melhorar a segurança do seu Synology NAS, incluindo como o Active Insight cria uma snapshot de uma pasta partilhada quando deteta ransomware.

Perguntas frequentes

Faça com que o próximo ataque do ransomware C3RB3R custe apenas uma restauração, e não um resgate. Execute seus serviços Docker dentro do Virtual DSM e proteja todo o guest com planos de proteção do VMM Pro, replicados para um segundo NAS. O SynoPower Club vende licenças genuínas para ambos, com chaves entregues por e-mail.