noticias
Ataques DDoS derrubam Threema e expõem um limite da segurança: criptografia não garante disponibilidade
**Categoria editorial:** Segurança Digital / Cibersegurança
Ataques DDoS derrubam Threema e expõem um limite da segurança: criptografia não garante disponibilidade
Matéria completa
Um serviço pode usar criptografia ponta a ponta, reduzir a coleta de metadados e ainda assim ficar praticamente inútil quando seus servidores deixam de responder. Foi exatamente essa distinção entre **confidencialidade** e **disponibilidade** que uma série de ataques distribuídos de negação de serviço colocou diante dos usuários do Threema em agosto de 2026.
O mensageiro suíço sofreu ataques DDoS de grande escala que atingiram tanto sua própria infraestrutura quanto a **Nine**, empresa utilizada como parceira de colocation. Na noite de terça-feira, 11 de agosto, o Threema ficou indisponível entre 19h30 e 23h30 no horário da Europa Central de verão. Os ataques continuaram na manhã seguinte e provocaram novas interrupções breves até que a operação normal fosse restabelecida às 12h23 de quarta-feira.
A empresa afirma que o incidente afetou a disponibilidade do serviço, não a segurança do conteúdo das comunicações. Não há indicação, até o momento, de que os atacantes tenham obtido mensagens, chaves criptográficas, contas ou acesso aos sistemas internos.
Esse detalhe muda completamente a natureza do episódio.
O Threema não foi necessariamente “hackeado” no sentido popular da palavra.
Ele foi impedido de funcionar.
O que aconteceu com o Threema
Os primeiros problemas foram percebidos por usuários na noite de 11 de agosto.
Com base nas informações disponíveis naquele momento, a empresa atribuiu inicialmente a instabilidade a uma falha de rede em seu parceiro de colocation. A investigação posterior mostrou que Threema e Nine estavam enfrentando uma sequência de ataques DDoS.
A própria companhia admite que não conseguiu determinar se era o alvo principal da campanha ou se os ataques atingiam múltiplos serviços.
Essa incerteza precisa ser preservada.
Não há, nas informações públicas divulgadas até agora, atribuição do ataque a um grupo criminoso, governo ou outro agente específico.
Também não foram publicados detalhes suficientes sobre volume de tráfego, tamanho da botnet, protocolos utilizados ou origem das conexões para caracterizar tecnicamente toda a campanha.
O que a empresa revelou é que os padrões do ataque mudavam continuamente, obrigando os mecanismos de defesa a se adaptar enquanto a ofensiva ainda estava ocorrendo.
É justamente esse comportamento que torna determinadas campanhas de DDoS difíceis de bloquear.
DDoS não precisa quebrar a criptografia
Um ataque distribuído de negação de serviço, conhecido pela sigla DDoS, tenta consumir recursos suficientes para que usuários legítimos não consigam acessar um serviço.
Isso pode ser feito enviando volumes enormes de pacotes, abrindo conexões, explorando protocolos capazes de amplificar tráfego ou provocando tarefas computacionalmente caras nos servidores.
O objetivo imediato não é necessariamente entrar na máquina.
É fazê-la parar de atender quem deveria.
Uma analogia simples ajuda.
Imagine uma central telefônica capaz de atender dez mil chamadas simultaneamente. Se milhões de chamadas artificiais começarem a chegar de milhares de números diferentes, a infraestrutura pode ficar ocupada mesmo que nenhuma dessas chamadas consiga acessar qualquer informação interna.
A porta permanece trancada.
O problema é que ninguém mais consegue chegar até ela.
Por que ser distribuído torna o ataque mais difícil
Um ataque comum vindo de um único endereço pode ser relativamente simples de bloquear.
Quando milhares ou milhões de dispositivos participam simultaneamente, a defesa muda de escala.
As fontes também podem variar.
Máquinas comprometidas, servidores alugados, dispositivos conectados à internet e infraestruturas intermediárias podem ser utilizados para gerar ou amplificar tráfego.
Bloquear tudo indiscriminadamente não é uma solução, porque usuários legítimos estão misturados naquele fluxo.
A defesa precisa separar o que é tráfego real do que pertence ao ataque enquanto ambos chegam pela mesma infraestrutura.
O Threema descreveu justamente essa dinâmica: conforme os mecanismos de proteção eram ajustados, os padrões ofensivos também mudavam.
É uma disputa de recursos e adaptação.
Se o atacante consegue produzir tráfego mais rapidamente do que a infraestrutura consegue filtrar, o serviço degrada.
A criptografia continuou cumprindo sua função
O caso também corrige uma confusão frequente em discussões sobre aplicativos seguros.
Criptografia ponta a ponta protege o conteúdo da comunicação durante o caminho entre os participantes.
Ela não cria largura de banda infinita.
Não impede queda de energia.
Não mantém um data center conectado durante uma falha de roteamento.
E não neutraliza automaticamente uma avalanche de tráfego contra a infraestrutura que transporta as mensagens.
Isso não torna a criptografia menos importante.
Significa apenas que segurança não é uma característica única.
Profissionais normalmente analisam pelo menos três propriedades fundamentais: confidencialidade, integridade e disponibilidade.
O DDoS atacou principalmente a última delas.
As mensagens podiam continuar criptograficamente protegidas e, ao mesmo tempo, impossíveis de entregar.
O problema atingiu também a infraestrutura ao redor do serviço
Há outro ponto importante na ocorrência.
Os ataques não atingiram apenas uma aplicação isolada.
A Nine, parceira de colocation do Threema, também estava sob pressão.
Colocation significa, de forma simplificada, que uma empresa mantém seus próprios equipamentos ou capacidade computacional dentro da infraestrutura física de um operador especializado que fornece elementos como espaço, energia, conectividade e rede.
Isso cria dependências.
Mesmo uma aplicação cuidadosamente projetada continua sujeita à infraestrutura situada abaixo dela.
Cabos, roteadores, provedores de trânsito, sistemas de filtragem e parceiros de data center formam parte da cadeia necessária para que uma mensagem saia de um telefone e chegue ao outro.
Um incidente nessa camada pode derrubar um serviço sem tocar no código do aplicativo.
O painel de status também falhou — por outro motivo
Durante a ocorrência, usuários enfrentaram ainda uma situação particularmente incômoda: a página utilizada para acompanhar o estado do Threema não forneceu corretamente as informações no início do incidente.
A empresa afirma que isso aconteceu por um problema técnico independente do ataque DDoS.
A página chegou a ser retirada temporariamente do ar enquanto a falha era corrigida.
Pode parecer detalhe, mas não é.
Um sistema de status existe justamente para continuar informando quando o serviço principal enfrenta problemas.
Se ambos dependem demais da mesma infraestrutura ou se a página não consegue refletir corretamente a ocorrência, usuários ficam sem o serviço e sem uma maneira confiável de descobrir o que está acontecendo.
Para organizações, essa segunda falha frequentemente aumenta mais a percepção de caos que a interrupção original.
O Threema anunciou que ampliará sua página de status com histórico de incidentes e um feed RSS, criando um canal adicional para acompanhar ocorrências.
O caso do Threema OnPrem é particularmente interessante
Enquanto usuários da infraestrutura convencional enfrentavam interrupções, organizações que utilizavam **Threema OnPrem** não foram afetadas por essa onda de ataques.
A razão é arquitetural.
Nessa modalidade, a organização opera a infraestrutura necessária em seu próprio ambiente, em vez de depender dos servidores centrais utilizados pelo serviço convencional.
Isso não significa que instalações OnPrem sejam imunes a DDoS.
Elas podem ser atacadas.
O que aconteceu neste episódio é que estavam fora do caminho específico afetado pela campanha contra Threema e Nine.
A distinção é importante porque demonstra uma das vantagens da descentralização de infraestrutura.
Uma falha central não derruba necessariamente todas as instalações independentes.
O preço dessa autonomia também existe: alguém precisa administrar servidores, atualizações, capacidade, monitoramento, segurança e continuidade operacional.
Infraestrutura própria troca dependência externa por responsabilidade interna.
O Threema adicionou filtragem antes do tráfego chegar aos servidores
Depois do incidente, a empresa colocou em produção uma camada adicional especializada de proteção DDoS.
O mecanismo foi ativado em 14 de agosto, às 18h05 no horário da Europa Central.
A ideia central é **filtrar o tráfego malicioso upstream**, isto é, antes que ele alcance a infraestrutura que precisa ser protegida.
Essa diferença é fundamental.
Imagine uma conexão de 10 gigabits por segundo recebendo um ataque de 100 gigabits.
Colocar um firewall atrás dessa conexão não resolve o problema.
Quando o tráfego chegar ao firewall, o canal externo já estará saturado.
A filtragem precisa acontecer antes do gargalo.
Provedores especializados mantêm redes muito maiores capazes de absorver tráfego, analisar padrões e encaminhar ao destino apenas aquilo considerado legítimo.
É um tipo de defesa que protege não somente o servidor, mas o caminho até ele.
Não existe proteção DDoS perfeita
Mesmo infraestruturas gigantescas ocasionalmente enfrentam interrupções provocadas por ataques.
O motivo está na própria natureza do problema.
Defender um serviço significa aceitar milhões de usuários legítimos enquanto se tenta identificar milhões de requisições maliciosas que podem ter sido produzidas para parecer normais.
Bloquear pouco deixa passar o ataque.
Bloquear demais derruba os próprios usuários que se pretendia proteger.
O atacante ainda pode mudar de estratégia.
Se uma camada começa a filtrar determinado padrão, a campanha pode mudar protocolos, distribuição geográfica, frequência ou características das requisições.
É por isso que mitigação de DDoS é menos parecida com instalar uma parede e mais com operar continuamente um sistema de tráfego durante uma enchente.
O ataque mostra a diferença entre segurança e resiliência
O Threema construiu sua reputação principalmente em torno de privacidade e segurança das comunicações.
Isso torna o episódio particularmente didático.
Uma organização pode investir muito em criptografia, tratamento de dados e redução de metadados e ainda descobrir que usuários dependem de outro atributo igualmente essencial: conseguir comunicar-se quando realmente precisam.
Essa questão ganha peso em ambientes empresariais, órgãos públicos, equipes de emergência e organizações que escolhem mensageiros seguros para comunicação crítica.
Uma ferramenta utilizada apenas para conversas ocasionais pode tolerar algumas horas de indisponibilidade.
Um canal definido como meio alternativo de comunicação durante uma crise não pode presumir que a própria infraestrutura estará disponível.
Resiliência exige redundância.
Um mensageiro seguro não deve ser o único caminho em uma emergência
Esse é um dos aspectos menos discutidos do caso.
Empresas adotam aplicativos seguros para reduzir risco de espionagem, vazamento e interceptação.
Às vezes, o aplicativo passa gradualmente de “canal seguro” para “único canal”.
É aí que surge uma nova fragilidade.
Se funcionários não possuem outra forma de comunicação durante a indisponibilidade, um ataque contra o provedor deixa de afetar somente mensagens.
Pode interromper decisões operacionais.
Planos de continuidade precisam considerar a perda total da ferramenta principal.
Isso pode significar manter canais independentes, listas de contato externas, telefonia, sistemas secundários ou, em ambientes com requisitos maiores, infraestrutura separada.
Ter dois aplicativos instalados no mesmo telefone não representa necessariamente redundância se ambos dependem do mesmo provedor de internet, da mesma identidade corporativa ou da mesma infraestrutura de nuvem.
Redundância real exige independência suficiente para que uma única falha não derrube tudo.
Disponibilidade também é uma questão econômica
Defesa contra DDoS custa dinheiro.
Redes capazes de absorver ataques muito maiores que o tráfego normal precisam ser construídas e mantidas mesmo quando não estão sendo utilizadas em capacidade máxima.
Isso cria um desequilíbrio econômico curioso.
Para o atacante, comprometer milhares de dispositivos e distribuí-los em uma botnet pode produzir capacidade ofensiva relevante.
Para o defensor, estar preparado significa contratar largura de banda, serviços de mitigação, sistemas de detecção e equipes capazes de responder rapidamente.
Uma empresa pode ser forçada a manter infraestrutura dimensionada não apenas para seus clientes, mas para clientes inexistentes criados artificialmente por um atacante.
O custo do abuso acaba parcialmente transferido para quem precisa defender o serviço.
Ataques de disponibilidade podem ter efeitos políticos
Serviços de comunicação protegida também ocupam um espaço sensível em países onde privacidade digital, protestos, jornalismo e liberdade de expressão enfrentam restrições.
Por isso, DDoS contra mensageiros seguros merece atenção mesmo quando nenhuma mensagem é violada.
Se um atacante não consegue ler uma comunicação, impedir que ela aconteça ainda pode produzir valor.
Esse princípio é conhecido há muito tempo em segurança.
Interromper infraestrutura pode ser suficiente para causar dano operacional, econômico ou político.
No caso específico do Threema, porém, não há evidência pública que permita atribuir esse episódio a uma motivação desse tipo.
A própria empresa mencionou apenas que ataques sofisticados podem envolver adversários com recursos técnicos e financeiros elevados, inclusive atores estatais em determinados cenários.
Isso não significa que um Estado tenha conduzido esta campanha.
A identidade e a motivação permanecem desconhecidas.
O incidente não é evidência contra a criptografia
Sempre que um serviço focado em segurança sofre uma interrupção, aparece a tentação de transformar o episódio em contradição.
“Se é tão seguro, como caiu?”
A pergunta mistura conceitos diferentes.
Um cofre extremamente resistente ainda pode estar dentro de um prédio cuja entrada foi bloqueada.
Isso não significa que o cofre foi aberto.
Do mesmo modo, o fato de usuários não conseguirem acessar um serviço não demonstra falha da criptografia.
Para avaliar seriamente o incidente, é necessário perguntar qual propriedade foi comprometida.
Até agora, a evidência disponível aponta para disponibilidade.
Não para confidencialidade do conteúdo.
Análise da equipe
O ataque ao Threema é um bom lembrete de que segurança digital não termina no algoritmo criptográfico.
A indústria gosta de comunicar segurança através de elementos fáceis de compreender: cadeados, criptografia ponta a ponta, chaves e promessas de privacidade.
Só que sistemas reais funcionam sobre camadas muito menos fotogênicas.
Roteadores precisam responder.
Links precisam ter capacidade.
DNS precisa funcionar.
Data centers precisam permanecer conectados.
Provedores precisam filtrar tráfego.
Equipes precisam perceber a anomalia.
Páginas de status precisam continuar informando.
Se qualquer uma dessas etapas falha, uma aplicação matematicamente bem protegida pode simplesmente desaparecer da tela do usuário.
O episódio também favorece uma discussão mais madura sobre arquitetura.
A ausência de impacto nas instalações OnPrem mostra o benefício de não concentrar toda comunicação na mesma infraestrutura.
Mas transformar isso em argumento de que “servidor próprio é sempre melhor” seria igualmente simplista.
Ambientes OnPrem transferem para cada organização o trabalho e os custos necessários para manter segurança, redundância, atualização e capacidade.
A decisão correta depende de risco, equipe, orçamento e criticidade.
O ponto central é outro: dependências precisam ser conhecidas.
Não existe resiliência quando ninguém sabe de quais peças o serviço depende até que uma delas pare.
O que deve ser acompanhado daqui para frente
A primeira questão é saber se a nova filtragem upstream implementada pelo Threema conseguirá absorver novas campanhas sem interrupções perceptíveis.
O segundo ponto é a transparência operacional.
A expansão da página de status, incluindo histórico de incidentes e RSS, permitirá avaliar ocorrências futuras e entender melhor o comportamento da infraestrutura.
Também será importante observar se Threema ou Nine publicam posteriormente detalhes adicionais sobre a campanha, como vetor de ataque, intensidade de tráfego ou origem predominante das conexões.
Essas informações ajudariam a dimensionar tecnicamente a ofensiva.
A identidade do responsável permanece desconhecida.
O mesmo vale para a motivação.
Até que surjam novas evidências, qualquer tentativa de ligar o episódio a governos, grupos políticos ou operações específicas seria especulação.
O que já está confirmado é suficiente para uma conclusão mais útil.
Criptografia protege uma conversa de quem tenta lê-la.
Resiliência protege a possibilidade de a conversa acontecer.
Um mensageiro realmente seguro precisa das duas coisas.
👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis