Episódio Segurança Legal #421 — Alerta da Defesa Civil. Este artigo é derivado do episódio #421 do podcast Segurança Legal, apresentado por Guilherme Goulart e Vinícius Serafim, e foi produzido com apoio de IA. Assista ao episódio completo no YouTube.
Entre 19 e 20 de junho de 2026, alguém com credenciais legítimas de agentes da Defesa Civil disparou cerca de dez alertas falsos pelo Sistema Nacional de Defesa Civil, que usa a infraestrutura de cell broadcast para atingir todos os celulares de uma região. Aproximadamente 30 milhões de pessoas receberam avisos de nível extremo na madrugada de sábado. A falha central não foi sofisticada: um sistema de alto impacto estava protegido apenas por usuário e senha, sem segundo fator e sem controle de acesso adequado.
O caso interessa menos pelo autor e mais pelo que ele expõe sobre a segurança de sistemas públicos críticos. Vamos separar o que é ruído do que é lição técnica.
O que aconteceu, em termos técnicos
O cell broadcast é um canal desenhado para emergências: enchentes, deslizamentos, tornados, situações em que a mensagem precisa se sobrepor a qualquer outra coisa no aparelho, inclusive no modo silencioso. É a mesma tecnologia que, na Europa, avisa populações inteiras antes de uma catástrofe climática. Por natureza, um alerta desses presume que o que está sendo comunicado é sério o bastante para justificar a interrupção.
No incidente, esse canal foi usado para disparar alertas falsos, alguns acompanhados de avisos de deslizamento e tornado, outros com conteúdo de piada. O sistema foi retirado do ar por volta de 1h da manhã. Durante o ataque, a equipe bloqueou credenciais e novas credenciais foram usadas para retomar os disparos, o que aponta para comprometimento de mais de um acesso. A Polícia Federal investiga a autoria, sem descartar a participação de usuários autorizados.
A falha não foi sofisticada: faltou o básico de controle de acesso
Pelas informações públicas, dois problemas se destacam, ambos no terreno mais básico da segurança de aplicações, o que o OWASP trata como controle de acesso.
O primeiro é a ausência de segundo fator de autenticação. Se o comprometimento de uma única credencial foi suficiente para disparar mensagens a 30 milhões de pessoas, então não havia camada adicional entre a senha e o disparo. Para um sistema com esse alcance, usuário e senha são insuficientes, por melhor que seja a senha. Um código por aplicativo autenticador, ou mesmo um fator mais fraco enviado por outro canal, já teria elevado bastante o custo do ataque.
O segundo é a falta de segregação por escopo. Uma reportagem técnica sobre o caso indica que uma mesma conta não deveria conseguir enviar alertas para mais de uma região. Se essa regra existia mas foi descumprida, é provável que ela não estivesse codificada no sistema, dependendo de configuração manual. Quando uma regra de integridade é crítica, o próprio sistema deve impedir sua violação, não confiar em quem faz a atribuição de acessos. Há relato de que havia um captcha, mas do tipo que pede o resultado de uma conta matemática, trivial de contornar e irrelevante diante da falha de autenticação.
A causa raiz: modelagem de ameaças que não foi feita
Falhas assim raramente são um esquecimento pontual. Elas indicam que a etapa anterior ao desenvolvimento não aconteceu: a modelagem de ameaças. Modelar ameaças é, antes de escrever código, mapear o que pode dar errado num sistema, quais são os atores capazes de atacá-lo, qual o impacto de cada cenário e, a partir disso, especificar quais mecanismos de segurança são obrigatórios. Só depois vêm a implementação e o teste efetivo desses mecanismos.
Um sistema que atinge 30 milhões de pessoas, por um canal cuja entrega o destinatário não pode recusar, e cujo propósito é comunicar risco de vida, tem um perfil de impacto altíssimo. Uma modelagem de ameaças minimamente feita teria colocado autenticação forte e segregação de privilégios como requisitos não negociáveis. A ausência desses controles sugere que a modelagem foi mal feita ou simplesmente não existiu. Sem ela, a implementação fica solta, guiada pela intuição de quem está codificando naquele momento.
O problema é estrutural, não isolado
Este não é um ponto fora da curva. O Tribunal de Contas da União vem apontando há anos baixa maturidade de segurança em órgãos públicos. Em fiscalização sobre serviços de hospedagem web, e-mail e DNS, o TCU concluiu que a maioria dos índices de práticas de segurança apresenta nível de maturidade baixo ou intermediário, deixando a maioria das organizações e seus clientes expostos a ataques. As causas identificadas foram diretas: falta de recursos ou investimento, de pessoal e de capacitação, além de baixa efetividade na implementação das normas.
O volume de incidentes acompanha esse diagnóstico. Considerando os órgãos do Executivo federal, o TCU registrou um aumento de 3.402 incidentes de segurança da informação em 2022 para 5.302 em 2024. É o mesmo padrão que encontramos em campo. Quando fazemos um pentest, é comum a equipe do cliente acreditar que o sistema está seguro, e não por incompetência: o entendimento de quem desenvolve é voltado para a funcionalidade e a entrega, não para as formas como aquilo pode ser quebrado. Essa é justamente a lacuna que um olhar externo e especializado preenche.
Pesquisa de segurança não é o mesmo que invasão
Vale separar duas coisas que a cobertura do caso costuma embaralhar. Encontrar uma falha e explorá-la para causar impacto, disparando alertas falsos, é crime, e o autor responde por isso. Isso é diferente de pesquisa de segurança feita de boa-fé, em que se identifica uma vulnerabilidade, notifica-se o responsável pelos canais oficiais, não se explora a falha para causar dano e, esgotado um prazo razoável sem correção, comunica-se o problema com a devida prova de que houve tentativa de aviso. A primeira conduta destrói a confiança num sistema que pode salvar vidas. A segunda ajuda a corrigi-lo antes que alguém mal-intencionado chegue lá.
Perguntas frequentes
O que causou o ataque ao sistema de alertas da Defesa Civil?
Pelas informações públicas, o comprometimento de credenciais legítimas de agentes, combinado com a ausência de segundo fator de autenticação e de segregação de privilégios por região. Uma única credencial comprometida foi suficiente para disparar alertas em escala nacional, o que indica falhas básicas de controle de acesso.
O que é modelagem de ameaças e por que ela importa aqui?
Modelagem de ameaças é a análise, feita antes do desenvolvimento, do que pode dar errado num sistema, de quem pode atacá-lo e do impacto de cada cenário, para então definir os controles de segurança obrigatórios. No caso da Defesa Civil, uma modelagem adequada teria tornado autenticação forte e segregação de acesso requisitos inegociáveis, dado o alcance do sistema.
Segundo fator de autenticação teria evitado o ataque?
Não há garantia absoluta, mas teria elevado muito o custo do ataque. Se o comprometimento de uma só senha permitiu disparar mensagens a milhões de pessoas, uma camada adicional de verificação romperia a cadeia mais provável do ataque. Para sistemas de alto impacto, autenticação por fator único é inadequada.
Isso é um problema só do setor público?
A baixa maturidade é mais visível em sistemas públicos por causa de restrições de recurso e pessoal, apontadas em auditorias do TCU. Mas o padrão de subestimar o risco por falta de uma visão de segurança aparece também no setor privado, sempre que a prioridade é a entrega da funcionalidade e a segurança fica para depois.
Avalie a exposição dos seus sistemas críticos
Se sua organização opera sistemas de alto impacto e ainda não passou por uma modelagem de ameaças ou por um teste independente de segurança, podemos conversar sobre o escopo. Fazemos modelagem de ameaças e pentest para identificar, antes de um incidente, o que precisa estar protegido e como.
Vinícius Serafim é sócio e consultor da BrownPipe Consultoria, especialista em pentest e segurança de aplicações. A BrownPipe atua desde 2012 em segurança da informação e proteção de dados. Este conteúdo foi produzido com apoio de IA e é derivado do episódio #421 – Alerta da Defesa Civil do podcast Segurança Legal, apresentado por Guilherme Goulart e Vinícius Serafim. Assista ao episódio completo no YouTube: youtu.be/MxZVb6xFl6c.