Sete agências federais dos Estados Unidos assinam o alerta, atualizado em 22 de julho de 2026, sobre controladores industriais comprometidos em serviços de água, energia e órgãos públicos. O detalhe que interessa a quem automatiza qualquer coisa não é a autoria do ataque. É o método: o acesso se deu por equipamentos alcançáveis pela internet, com o software de engenharia do próprio fabricante, e a alteração feita na lógica foi desligar as rotinas de parada e de alarme.

Declaração antes de tudo: este post é análise de alertas e documentação primários, não relato de operação industrial. Nunca operei um controlador lógico programável nem uma planta de tratamento. O que sigo aqui é o que os documentos oficiais afirmam, com a data em que foram consultados, e a leitura que faço deles vem identificada como leitura.

O que os documentos descrevem

Um controlador lógico programável (CLP) é o computador industrial que executa a lógica de uma máquina, de uma linha de produção ou de uma estação de tratamento de água. Ele lê sensores, aciona bombas e válvulas, e roda um programa que alguém escreveu e carregou. Esse programa vive num arquivo de projeto.

Dois documentos da Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) descrevem o que aconteceu com esses equipamentos nos últimos meses.

O primeiro é o comunicado de 30 de julho de 2026, dirigido ao setor de água e esgoto. A agência relata aumento significativo de ataques a CLPs e pede que os operadores retirem da internet os controladores expostos. Os invasores trocaram senhas para trancar os operadores fora do próprio equipamento e mudaram endereços de IP para desconectá-lo. O resultado, segundo o texto, foi a emissão de avisos de fervura de água e operação manual prolongada. O comunicado observa ainda que a exposição costuma incluir modems celulares instalados por fornecedores ou integradores, que podem não estar documentados nem entrar nas varreduras de rotina.

O segundo é o alerta conjunto AA26-097A, publicado em 7 de abril de 2026 e atualizado em 22 de julho, assinado por FBI, CISA, NSA, EPA, Departamento de Energia, Comando Cibernético e Departamento do Tesouro. Ele atribui a atividade a um grupo afiliado ao Irã e detalha o percurso técnico. Os invasores usaram infraestrutura alugada e o software de programação dos fabricantes para se conectar a controladores mal configurados, extraíram os arquivos de projeto dos equipamentos e devolveram versões alteradas.

O que essas versões alteradas faziam está descrito com todas as letras, e é o centro deste texto. Em tradução livre do alerta: as mudanças “desabilitaram lógica crítica de desligamento e de alarme, permitindo que sistemas entrassem em condições inseguras sem notificar os operadores das anomalias”.

Em uma das vítimas, o FBI observou algo ainda mais específico: o arquivo de projeto malicioso preservou a lógica que fazia o processo seguir adiante e acrescentou lógica que anulava as instruções responsáveis por manter os parâmetros de operação segura. O processo continuou funcionando. Só a proteção saiu.

A porta de entrada estava registrada

O tráfego malicioso foi observado em quatro portas: 44818, 2222, 102 e 502. Nenhuma delas é obscura. Todas constam do registro público de portas da IANA, a autoridade que administra esses números: 502 é o Modbus, 102 é o ISO-TSAP usado pelos equipamentos da Siemens, e 2222 e 44818 são as duas metades do EtherNet/IP. São as portas da frente da automação industrial, documentadas há décadas.

Os equipamentos citados como alvo também são de linha comum: CompactLogix e Micro850, da Rockwell Automation; Modicon M340, da Schneider Electric; e a série S7-1200, da Siemens. O alerta os nomeia porque foram os observados, não porque sejam falhos. A exposição direta à internet é que abre a porta, e essa é uma decisão de quem instala.

Vale registrar o contraponto histórico: esses protocolos nasceram para redes isoladas, numa época em que estar fisicamente dentro da planta era a autenticação. O Modbus é de 1979. A CISA descreve a consequência disso sem rodeios na sua ficha de mitigações primárias, de maio de 2025: equipamentos de tecnologia operacional “carecem de métodos de autenticação e autorização resistentes a ameaças modernas e são rapidamente encontrados” pela varredura de portas abertas em faixas públicas de IP. E completa, na mesma página, que os atacantes usam ferramentas “simples, repetíveis e escaláveis, disponíveis a qualquer um com um navegador de internet”.

Não é a primeira vez. Em novembro de 2023, campanha semelhante comprometeu ao menos 75 equipamentos Unitronics, dos quais pelo menos 34 no setor de água dos Estados Unidos. O alerta daquele episódio registra que os aparelhos estavam na internet, na porta padrão, com a senha padrão ou sem senha alguma.

O alvo foi o intertravamento

Aqui está a leitura que me parece transferível para fora da indústria.

Automação séria tem duas camadas de lógica. Uma faz o processo andar: liga a bomba, abre a válvula, avança a esteira. A outra impede que ele ande quando não deveria — o intertravamento, a condição que trava a operação quando uma medida sai da faixa segura, e o alarme que avisa o operador de que algo saiu. A primeira camada é o que o sistema faz. A segunda é o que ele se recusa a fazer.

O ataque descrito não roubou processo, não parou a produção e não pediu resgate. Ele removeu a segunda camada e deixou a primeira rodando, com as telas de supervisão mostrando números tranquilizadores. O sistema continuou obedecendo. Perdeu apenas a capacidade de discordar.

Isso reordena a pergunta que normalmente se faz sobre uma automação. A pergunta usual é o que ela consegue fazer. A pergunta que este caso impõe é outra: quais das suas verificações podem ser desligadas sem que ninguém perceba? Uma automação cuja checagem some em silêncio não fica um pouco menos segura. Ela passa a afirmar que está tudo bem, e isso é pior do que estar parada.

A mesma decisão, três ordens de grandeza abaixo

A consequência de uma estação de tratamento comprometida não se compara à de um servidor doméstico, e não é isso que proponho. O que se repete não é a gravidade, são as três decisões: o que fica alcançável, com que credencial, e o que acontece quando a verificação desaparece.

Elas aparecem inteiras em automação de pequeno porte, e aparecem no meu próprio projeto.

O arquivo de infraestrutura do pipeline editorial deste blog não publica no host as portas do n8n nem as do banco de dados. Só o proxy de borda escuta em 80 e 443, e todo o resto conversa pela rede interna. É a mesma frase da recomendação da CISA para o chão de fábrica, escrita em outro vocabulário. Não foi virtude: foi a leitura de um documento antes de subir o serviço.

A segunda decisão também já apareceu por aqui, e de forma desconfortável. A versão do n8n fixada nesse arquivo caía na faixa de uma falha de acesso não autenticado a arquivos, com nota máxima de gravidade. A instância nunca chegou a subir, então nada esteve exposto, mas provisionar com aquela versão teria colocado um serviço vulnerável na internet no primeiro dia. E, ao escrever sobre o n8n como servidor MCP, encontrei na documentação oficial o aviso de que aquele nó não usa nenhum método de autenticação por padrão.

A terceira é a que mais me interessa, porque é a que o alerta ilumina. Os gates que seguram a publicação deste blog já foram inventariados num post inteiro: o que cada um barrou de erro real, e o que nenhum deles pegou. O caso industrial acrescenta uma terceira pergunta, que não estava naquela lista nem na minha cabeça quando a escrevi. Não é o que o gate pegou, nem o que passou por ele. É o que aconteceria se o gate fosse retirado.

O contrato de conteúdo derruba a construção do site quando um campo sai do formato. É um intertravamento. Só que apagar essa checagem custa uma linha, e depois disso o site continuaria construindo, publicando e parecendo saudável. Nenhum erro apareceria, porque a ausência de uma verificação não gera erro. É a forma exata do ataque descrito nos alertas: o processo segue, o painel tranquiliza, e o que saiu de cena foi a capacidade de recusar.

O que dá para conferir hoje

Nada aqui é invenção minha. É a lista de mitigações dos próprios documentos, traduzida e reduzida ao que vale em qualquer escala.

  1. Levante o que responde num endereço público. Não o que se acredita ter exposto: o que responde. O comunicado de julho insiste nos acessos esquecidos, instalados por terceiros e ausentes da documentação.
  2. Acesso remoto passa por uma porta de entrada, nunca direto no equipamento. Rede privada virtual ou gateway na frente, sempre.
  3. Senha padrão trocada, e lista de endereços autorizados. Duas das cinco recomendações do comunicado de julho são exatamente isso.
  4. Backup limpo da configuração, guardado fora do equipamento. A CISA recomenda isso pelo motivo mais concreto possível: se o invasor trocar a senha, é o que resta para recuperar o controle.
  5. Identifique as suas verificações e teste se a ausência delas aparece. Se desligar a checagem não gera erro, alarme nem registro, ela não é uma proteção. É uma sugestão.

Vale citar a orientação mais elementar do alerta conjunto, porque diz muito sobre a natureza do problema: nos equipamentos da Rockwell, colocar a chave física do controlador na posição de execução. A última linha de defesa da automação industrial madura é uma chave de metal que nenhum pacote de rede gira.

Onde esta análise para

São documentos dos Estados Unidos, sobre a infraestrutura crítica de lá, e nada afirmam sobre a situação brasileira. A atribuição a um grupo específico é das agências, não minha. Os fabricantes citados aparecem porque foram os observados nas campanhas descritas, e os próprios alertas apontam a exposição direta à internet, e não os produtos, como a condição que tornou tudo possível. E, repito o que abri: não opero equipamento industrial. O que trago é a leitura de documentos primários por quem automatiza em outra escala.

O que fica

O ataque mais consequente descrito nesses alertas não precisou de genialidade técnica. Precisou de um equipamento alcançável, de uma credencial fraca e de alguém disposto a apagar a parte do programa que existia para dizer não.

Toda automação tem essa parte. Quem automatiza deveria saber nomeá-la, e deveria conseguir provar que ela ainda está lá.

Fontes

  • Aumento de ataques a CLPs no setor de água, troca de senhas para trancar operadores, mudança de IP, avisos de fervura de água, operação manual prolongada, modems não documentados e as mitigações recomendadas — comunicado da CISA de 30/07/2026 (agência governamental, fonte primária, nível 1), verificado em 2026-08-17.
  • Uso do software de engenharia dos fabricantes, extração e alteração dos arquivos de projeto, desativação da lógica de desligamento e alarme, lógica acrescentada que anulou os parâmetros de operação segura, portas 44818, 2222, 102 e 502, equipamentos e fabricantes observados e a orientação da chave física em posição de execução — alerta conjunto AA26-097A, de FBI, CISA, NSA, EPA, DOE, CNMF e Tesouro, publicado em 07/04/2026 e atualizado em 22/07/2026 (fonte primária, nível 1), verificado em 2026-08-17.
  • Ao menos 75 equipamentos Unitronics comprometidos, 34 deles no setor de água dos EUA, alcançados na porta padrão com senha padrão ou sem senha — alerta conjunto AA23-335A (fonte primária, nível 1), verificado em 2026-08-17.
  • Equipamentos de tecnologia operacional sem autenticação resistente a ameaças modernas, localizáveis por varredura de portas, e ferramentas de ataque disponíveis a qualquer um com um navegador — ficha de mitigações primárias da CISA, publicada em 06/05/2025 (fonte primária, nível 1), verificado em 2026-08-17.
  • Portas 502 (Modbus), 102 (ISO-TSAP), 2222 e 44818 (EtherNet/IP) como registros públicos — registro de nomes de serviço e portas da IANA (autoridade de registro, nível 1), verificado em 2026-08-17.
  • Aviso de que o nó MCP Server Trigger não usa autenticação por padrão — documentação oficial do n8n (fonte primária, nível 1), verificado em 2026-08-07.
  • Peça de análise: o autor não operou controlador industrial nem sistema de supervisão até a data de publicação. O que está descrito como prática própria refere-se à infraestrutura do pipeline editorial deste blog.