A semana foi marcada por acontecimentos que mostram como os impactos de um incidente cibernético podem continuar muito depois da invasão inicial.
Em Berlim, o grupo de ransomware Rhysida publicou dados obtidos durante o comprometimento de sistemas governamentais após as autoridades recusarem o pagamento do resgate. Nos Estados Unidos e na Europa, uma operação coordenada conseguiu interromper parte da infraestrutura da Sality, uma das botnets mais antigas ainda em atividade.
No setor de saúde, um ataque cibernético que já havia provocado interrupções operacionais levou uma fabricante de dispositivos médicos a retirar suas previsões financeiras para 2026. Enquanto isso, no mercado de ativos digitais, aproximadamente 4.000 bitcoins foram retirados de uma carteira ligada à Liquid Network, em um incidente cujo método de comprometimento ainda permanece sob investigação.
Apesar das diferenças entre os casos, todos reforçam um mesmo princípio: o impacto de um ataque não deve ser medido apenas pelo comprometimento técnico inicial, mas pelas consequências operacionais, financeiras, regulatórias e reputacionais que podem surgir posteriormente.
Ransomware publica dados roubados do governo de Berlim
O ataque envolvendo o governo estadual de Berlim entrou em uma nova fase depois que o grupo de ransomware Rhysida publicou aproximadamente 5,79 terabytes de informações que afirma ter obtido durante a invasão.
O material foi disponibilizado em 4 de setembro de 2026 depois que terminou o período estabelecido pelos criminosos para negociação.
O grupo havia exigido inicialmente 30 bitcoins, mas o governo de Berlim decidiu não realizar o pagamento.
Com a publicação dos arquivos, as autoridades passaram a concentrar esforços na identificação do conteúdo efetivamente exposto e das pessoas e organizações que podem ter sido afetadas.
Governo cria estrutura específica para analisar o vazamento
Diante do volume de informações publicado, Berlim estabeleceu uma unidade central de crise.
O objetivo é:
- Verificar a autenticidade dos arquivos;
- Identificar dados pessoais;
- Localizar documentos governamentais sensíveis;
- Determinar quais organizações foram afetadas;
- Avaliar possíveis riscos à população;
- Coordenar as notificações necessárias.
As autoridades também pediram que cidadãos não compartilhem arquivos supostamente provenientes do vazamento antes de sua verificação oficial.
Esse tipo de orientação é importante porque conjuntos de dados publicados por grupos criminosos podem conter não apenas informações confidenciais, mas também arquivos maliciosos adicionados posteriormente.
Conteúdo dos arquivos ainda precisa ser validado
Segundo o Rhysida, os dados disponibilizados incluiriam:
- Contratos;
- Mensagens de e-mail;
- Telefones;
- Senhas;
- Dados pessoais;
- Informações governamentais;
- Documentos classificados.
O governo de Berlim, entretanto, ainda não confirmou integralmente o conteúdo divulgado.
Por isso, a existência desses materiais deve ser apresentada como alegação dos criminosos até que a análise oficial determine quais arquivos realmente foram retirados dos sistemas públicos.
Publicação dos dados representa uma segunda etapa do ransomware
Um dos principais aprendizados do incidente é que recuperar os sistemas não encerra necessariamente um ataque.
Operações de dupla extorsão normalmente seguem uma sequência semelhante:
acesso inicial → reconhecimento → coleta de dados → exfiltração → possível criptografia → extorsão → publicação.
Mesmo quando a organização consegue restaurar seus servidores utilizando backups, os criminosos ainda podem ameaçar divulgar as informações obtidas.
Depois da publicação, surgem novos riscos:
- Fraudes;
- Phishing;
- Roubo de identidade;
- Exposição de credenciais;
- Engenharia social;
- Danos reputacionais;
- Obrigações regulatórias;
- Novas tentativas de invasão utilizando informações vazadas.
No caso de Berlim, essa segunda etapa já começou.
Como se preparar para incidentes envolvendo vazamento
Além de backups, organizações precisam possuir capacidade de responder especificamente à exfiltração de informações.
Entre as medidas recomendadas estão:
- Segmentar redes;
- Aplicar MFA em contas privilegiadas;
- Monitorar transferências anormais;
- Identificar rapidamente os dados acessados;
- Manter inventário das informações sensíveis;
- Criar planos específicos para vazamentos;
- Definir procedimentos de comunicação;
- Preservar logs para investigação;
- Rotacionar credenciais potencialmente comprometidas.
A organização precisa conseguir responder rapidamente a uma pergunta fundamental:
O que exatamente o invasor conseguiu acessar?
Sem essa visibilidade, torna-se muito mais difícil avaliar o impacto real do incidente.
Operação internacional interrompe botnet Sality
Outro destaque da semana foi uma operação coordenada para interromper a infraestrutura da Sality, uma das botnets mais antigas conhecidas.
A ameaça foi identificada originalmente em 2003 e permaneceu ativa por mais de duas décadas.
A operação envolveu a CrowdStrike, o FBI, o Departamento de Justiça dos Estados Unidos, autoridades europeias e outras organizações especializadas em segurança cibernética.
Embora ameaças como ransomware tenham ganhado maior visibilidade nos últimos anos, botnets antigas ainda podem representar riscos significativos.
Um dispositivo comprometido pode ser utilizado como:
- Proxy;
- Nó de retransmissão;
- Plataforma para distribuição de malware;
- Ponto de entrada para novas invasões;
- Infraestrutura para campanhas automatizadas.
Arquitetura P2P ajudou a Sality a sobreviver durante anos
Um dos principais motivos para a longevidade da Sality foi sua arquitetura peer-to-peer, ou P2P.
Em uma botnet tradicional, os dispositivos infectados podem depender de servidores centrais para receber comandos.
Nesse modelo, derrubar os servidores de comando pode interromper grande parte da operação.
A Sality distribui sua comunicação entre diferentes máquinas comprometidas.
Cada dispositivo pode participar da infraestrutura utilizada para localizar outros integrantes da rede.
Isso torna a estrutura mais resistente porque a remoção de um único servidor não é suficiente para desligar a botnet.
Pesquisadores utilizaram a própria arquitetura contra a botnet
Segundo a CrowdStrike, a operação exigiu engenharia reversa extensa.
Os pesquisadores identificaram características da própria arquitetura da Sality que poderiam ser utilizadas para interferir em sua comunicação.
A estratégia envolveu inserir informações falsas na rede distribuída.
Com isso, determinados sistemas comprometidos passaram a receber informações incorretas sobre a infraestrutura e acabaram se desconectando dos operadores.
A técnica permitiu atacar diretamente a lógica de funcionamento da botnet, em vez de depender apenas da apreensão de servidores.
Desmantelamento não significa necessariamente o fim da Sality
Um ponto importante é que interromper uma botnet descentralizada não garante que ela tenha sido eliminada definitivamente.
Os operadores podem tentar:
- Recuperar nós antigos;
- Atualizar o malware;
- Alterar os protocolos;
- Criar nova infraestrutura;
- Reconstruir a rede;
- Recuperar equipamentos ainda infectados.
Por isso, pesquisadores continuarão monitorando possíveis tentativas de reconstrução.
A Shadowserver também participou da operação e destacou que computadores ainda infectados podem continuar representando riscos.
Como reduzir o risco de dispositivos participarem de botnets
Algumas medidas continuam fundamentais:
- Manter sistemas atualizados;
- Atualizar equipamentos de rede;
- Monitorar conexões inesperadas;
- Utilizar soluções de proteção de endpoint;
- Detectar comunicações com infraestrutura suspeita;
- Isolar rapidamente máquinas comprometidas;
- Restringir privilégios administrativos;
- Utilizar autenticação forte.
Também é importante substituir equipamentos antigos que já não recebem atualizações de segurança.
Uma ameaça com mais de vinte anos de existência demonstra que sistemas abandonados podem manter infraestruturas criminosas funcionando por períodos extremamente longos.
Ataque cibernético provoca impacto financeiro em empresa do setor médico
Um incidente que atingiu a Boston Scientific em agosto continuou produzindo consequências durante setembro.
A empresa informou em 8 de setembro de 2026 que não espera mais atingir as projeções de vendas e lucro anteriormente estabelecidas para o terceiro trimestre e para o ano de 2026.
O ataque havia sido identificado em 25 de agosto e provocou interrupções em sistemas ligados à:
- Fabricação;
- Processamento de pedidos;
- Envio de produtos;
- Operações corporativas.
A companhia decidiu retirar suas projeções financeiras porque ainda não consegue determinar completamente o impacto econômico da interrupção.
Ciberataque ultrapassa a área de tecnologia
Esse caso demonstra claramente por que risco cibernético também é risco de negócio.
Um incidente pode começar em sistemas de TI, mas rapidamente atingir:
TI → produção → logística → pedidos → receita → projeções financeiras.
Para empresas industriais e fabricantes, a indisponibilidade de sistemas corporativos pode interromper processos que dependem diretamente de integrações digitais.
A consequência pode aparecer posteriormente em indicadores como:
- Receita;
- Margem;
- Produção;
- Volume de vendas;
- Custos de recuperação;
- Prazo de entrega;
- Confiança dos investidores.
Operações começaram a ser restauradas
Apesar dos impactos financeiros, a empresa informou que a recuperação operacional estava avançando.
Segundo a atualização divulgada:
- Principais centros de distribuição voltaram a processar pedidos;
- Instalações de esterilização permaneceram funcionando;
- A fabricação foi retomada na maioria das unidades;
- Parte relevante da distribuição voltou aos níveis normais.
A companhia afirmou que os efeitos ficaram concentrados em determinadas áreas de sua infraestrutura.
Produtos médicos não apresentaram sinais de comprometimento
Outro ponto importante é a diferenciação entre sistemas corporativos e os próprios produtos médicos.
Segundo a empresa, análises de qualidade não identificaram comprometimento dos produtos decorrente do incidente.
Os impactos conhecidos estavam relacionados principalmente a interrupções operacionais e a determinadas novas ativações de serviços de monitoramento remoto.
Não houve indicação de alteração causada pelo ataque nos dispositivos médicos já utilizados pelos clientes.
Essa distinção é importante para evitar associar automaticamente uma invasão à segurança dos próprios produtos.
Continuidade de negócios precisa incluir cenários cibernéticos
Empresas industriais e do setor de saúde devem testar situações nas quais sistemas corporativos permaneçam indisponíveis durante horas ou dias.
Um plano de continuidade precisa responder perguntas como:
- Como processar pedidos sem o sistema principal?
- Existe procedimento manual?
- Como liberar produtos?
- Como se comunicar com clientes?
- Quais fábricas podem continuar operando?
- Existem sistemas alternativos?
- Quanto tempo a organização consegue permanecer sem determinada aplicação?
Entre as principais recomendações estão segmentação, MFA, backups isolados, monitoramento contínuo e testes periódicos de recuperação.
Incidente provoca retirada de aproximadamente US$ 320 milhões em Bitcoin
Outro acontecimento relevante envolveu a Liquid Network, infraestrutura utilizada para transferências e liquidação de ativos relacionados ao Bitcoin.
Segundo a empresa, aproximadamente 4.000 bitcoins foram retirados de uma carteira pertencente à Liquid Federation.
O volume representava quase todo o saldo existente na carteira, que armazenava aproximadamente 4.200 BTC.
A empresa estimou a movimentação em cerca de US$ 320 milhões.
Depois de identificar o incidente, a rede suspendeu novas transações enquanto iniciava a investigação.
Incidente não significa comprometimento da rede Bitcoin
É importante diferenciar a infraestrutura afetada da própria rede Bitcoin.
A ocorrência está relacionada à Liquid Network e a uma carteira de sua estrutura federada.
Até o momento descrito no material, não havia indicação de comprometimento da blockchain principal do Bitcoin.
Essa distinção é relevante porque um incidente envolvendo uma aplicação construída sobre uma blockchain não significa necessariamente que o protocolo base tenha sido comprometido.
Fundos foram movimentados por meio de serviço autorizado
Segundo a empresa, as movimentações passaram pelo SideSwap, serviço autorizado a processar determinadas saídas da rede.
Um dos pontos mais interessantes da investigação é que, de acordo com a Liquid, a chave utilizada para autorizar as operações não teria sido comprometida.
Isso significa que o cenário não seria simplesmente o roubo direto de uma chave privada.
O método utilizado permanece sem confirmação.
Entre as possibilidades que ainda precisam ser investigadas estão:
- Vulnerabilidade em software;
- Falha operacional;
- Abuso de integração;
- Problema no processo de autorização;
- Comprometimento de componente intermediário;
- Manipulação de sistemas de custódia.
Nenhuma dessas hipóteses pode ser considerada confirmada neste momento.
Empresa classificou responsáveis como supostos white hats
A Liquid descreveu os responsáveis pela movimentação como supostos hackers de chapéu branco.
Normalmente, a expressão white hat é utilizada para profissionais que realizam pesquisas ou testes de segurança autorizados.
Entretanto, a própria empresa apresentou a classificação como algo ainda não confirmado e não divulgou informações que permitam determinar a identidade ou as intenções dos envolvidos.
Portanto, a retirada deve continuar sendo tratada como um incidente de segurança até que novas informações esclareçam as circunstâncias.
Suspender transações foi uma medida de contenção
A decisão de interromper temporariamente as operações reduz o risco de novas movimentações enquanto a investigação ocorre.
Durante esse período, equipes podem revisar:
- Sistemas de autorização;
- Integrações;
- Carteiras;
- Serviços externos;
- Controles de custódia;
- Registros de transações;
- Credenciais;
- Políticas de movimentação.
A contenção também permite verificar se outros ativos estão expostos ao mesmo mecanismo utilizado no incidente.
Segurança de ativos digitais vai além da chave privada
O incidente também reforça uma questão importante para organizações que administram criptomoedas.
Proteger uma chave é fundamental, mas não é suficiente.
Toda a cadeia precisa ser protegida:
usuário → sistema de autorização → aplicação → integração → carteira → custódia → blockchain.
Uma falha em qualquer um desses componentes pode permitir movimentações indevidas mesmo quando a chave principal permanece tecnicamente protegida.
Entre as principais medidas estão:
- Autorizações em múltiplas etapas;
- Segregação de funções;
- Limites para grandes transações;
- Aprovação manual para valores elevados;
- Monitoramento em tempo real;
- Isolamento da infraestrutura de custódia;
- Auditoria de terceiros;
- Planos específicos de resposta.
A investigação ainda precisa esclarecer exatamente como aproximadamente 4.000 BTC foram movimentados.
O que os acontecimentos desta semana têm em comum
Os quatro casos mostram que um incidente de segurança raramente termina quando o acesso inicial é bloqueado.
Em Berlim, o comprometimento evoluiu para uma crise relacionada à publicação dos dados.
Na Sality, mesmo depois de uma grande operação de desmantelamento, ainda existe a possibilidade de recuperação da infraestrutura.
No setor médico, um ataque ocorrido semanas antes continua produzindo impactos financeiros.
Na Liquid Network, a movimentação dos ativos foi interrompida, mas a causa técnica ainda precisa ser determinada.
Isso demonstra que a resposta a incidentes possui diferentes fases:
detecção → contenção → investigação → recuperação → avaliação do impacto → monitoramento posterior.
A organização que encerra o incidente assim que os sistemas voltam a funcionar pode deixar riscos importantes sem tratamento.
Impacto cibernético precisa ser medido em termos de negócio
Outro ponto importante é que indicadores puramente técnicos não conseguem demonstrar toda a dimensão de um incidente.
Um ataque pode provocar:
- Horas de indisponibilidade;
- Perda de receita;
- Interrupção de produção;
- Vazamento de dados;
- Exposição de credenciais;
- Multas;
- Custos jurídicos;
- Perda de ativos;
- Necessidade de comunicação pública;
- Alterações em previsões financeiras.
Por isso, organizações precisam conectar métricas de segurança a métricas empresariais.
Não basta informar que um servidor permaneceu offline durante oito horas.
É necessário entender qual processo dependia daquele servidor e qual foi o impacto causado ao negócio.
Conclusão
Os conteúdos desta semana demonstram que as consequências de um ataque cibernético podem continuar se desenvolvendo durante semanas ou até meses depois da invasão inicial.
O caso de Berlim mostra de maneira clara a segunda etapa de um ataque de ransomware baseado em dupla extorsão. Depois da contenção dos sistemas, a organização ainda precisa lidar com a publicação das informações, identificar pessoas afetadas e avaliar os riscos criados pelos dados expostos.
A operação contra a Sality mostra outro desafio: infraestruturas criminosas distribuídas podem sobreviver durante décadas quando sua arquitetura é suficientemente resiliente. Desmantelar servidores não significa necessariamente eliminar todos os dispositivos comprometidos.
Já o incidente no setor de tecnologia médica demonstra como um ataque pode sair dos indicadores técnicos e chegar diretamente aos resultados financeiros de uma empresa.
Quando fabricação, distribuição e processamento de pedidos dependem de sistemas digitais, indisponibilidade de TI passa rapidamente a significar indisponibilidade operacional.
O caso envolvendo ativos digitais reforça ainda outro princípio: proteger um componente isoladamente não significa proteger todo o processo.
Uma chave criptográfica pode permanecer intacta e, mesmo assim, uma falha em alguma etapa da cadeia de autorização ou processamento pode provocar perdas significativas.
Para as organizações, algumas prioridades se tornam cada vez mais claras:
- Reduzir o tempo de contenção;
- Entender quais dados foram acessados;
- Conhecer as dependências dos processos críticos;
- Testar planos de continuidade;
- Monitorar impactos após a recuperação;
- Proteger toda a cadeia de autenticação e autorização;
- Preservar evidências;
- Manter capacidade de resposta mesmo quando os sistemas principais estiverem indisponíveis.
A principal lição desta semana é que responder a um ataque não significa apenas remover o invasor.
É necessário compreender o que aconteceu, restaurar as operações, avaliar consequências futuras e acompanhar os riscos que permanecem depois que o incidente aparentemente terminou.
A verdadeira resiliência cibernética é medida pela capacidade da organização de continuar operando, recuperar-se de forma segura e reduzir a possibilidade de que o mesmo comprometimento produza novos impactos no futuro.
