STM sofre ataque cibernético e portal fica fora do ar por duas semanas

O Superior Tribunal Militar (STM) identificou um "incidente de segurança cibernética" em seu portal eletrônico no dia 2 de julho e, desde então, o site institucional permanece fora do ar — já são duas semanas de indisponibilidade. Segundo a Corte, as equipes de tecnologia isolaram os sistemas afetados, acionaram os protocolos de segurança e iniciaram os procedimentos de investigação. O STM afirmou que o ataque não comprometeu os sistemas internos nem o andamento processual, mas o próprio tribunal reconheceu que o episódio ocorre "em um contexto de ataques cibernéticos registrados recentemente contra outras instituições públicas". O caso foi comunicado às autoridades competentes. A previsão inicial era restabelecer o portal ainda nesta quarta-feira (15).

Fonte: G1 · Metrópoles

Por que isso importa. O STM não é um alvo isolado — a própria Corte menciona que o ataque se insere numa onda recente contra órgãos públicos brasileiros. O padrão é conhecido: uma superfície de ataque mal mapeada (portal exposto, subdomínio esquecido, API sem autenticação adequada), combinada com uma resposta que, embora protocolada, não consegue restaurar o serviço em tempo hábil. Duas semanas de portal indisponível significam que o incidente foi detectado, mas a recuperação revelou dependências ou lacunas que prolongaram a interrupção. Este é exatamente o tipo de cenário que mostra que ter um plano de resposta no papel não é suficiente — é preciso testar se a recuperação funciona na prática, sob pressão e com sistemas reais.

O que as organizações devem testar e monitorar continuamente. A primeira lição é mapear a superfície de ataque real: todo domínio, subdomínio, portal, API e painel administrativo exposto precisa ser conhecido e monitorado — não adianta proteger o que está no inventário se há portas que ninguém sabe que existem. A segunda é validar os controles de acesso com testes ofensivos periódicos: um portal institucional não deveria permitir que um atacante comprometesse o servidor a ponto de exigir duas semanas de recuperação. A terceira é testar o plano de resposta a incidentes com simulações reais — o tempo entre detecção e restauração do serviço é a métrica que separa um incidente contido de uma crise prolongada. Para qualquer organização com sistemas críticos — seja um tribunal, uma fintech ou uma operadora de pagamentos — a pergunta não é se vai ser atacada, mas quanto tempo leva para voltar a operar com segurança depois do ataque.