Hackers atacaram o sistema de água dos EUA — e o que isso ensina para quem programa
Li no Olhardigital.com.br que o FBI e a EPA emitiram um alerta conjunto depois que sete concessionárias de água e esgoto nos Estados Unidos foram invadidas desde julho de 2026. Mas o que me chamou atenção não foi o número — foi o método. Os atacantes miraram PLCs expostos na internet, mudaram IP e senha, e literalmente tiraram o controle das mãos dos operadores. Isso é TI batendo de frente com OT, e a maioria dos devs não sabe a diferença.
O que realmente aconteceu
Segundo o FBI, os invasores usaram dispositivos conectados à internet para acessar remotamente Controladores Lógicos Programáveis (PLCs) — os mesmos equipamentos que automatizam bombas, válvulas e sensores nas estações de tratamento. Com acesso, bastou alterar configurações simples: IP, credenciais, rotas. Resultado: perda de pressão na rede e alagamentos.
Pra quem nunca trabalhou com automação industrial, um PLC é basicamente um microcontrolador dedicado a processos físicos. Ele lê sensores, executa lógica ladder, e aciona atuadores. Sem ele, você não tem como bombear água, abrir válvulas ou dosar cloro. E o pior: muitos desses PLCs rodam firmware antigo, sem autenticação forte, em redes que nunca foram projetadas pra receber tráfego da internet.
A diferença entre IT e OT — e por que devs ignoram isso
Na minha experiência, quando o assunto é segurança, o pessoal de software pensa em “IT”: aplicações web, APIs, banco de dados. Mas o ataque descrito é puro “OT” (Operational Technology). São mundos diferentes com prioridades opostas:
- IT prioriza confidencialidade — ninguém pode ler seus dados.
- OT prioriza disponibilidade e segurança física — a bomba tem que girar, a válvula tem que fechar, e ninguém pode morrer.
Quando você cruza os dois mundos sem critério — por exemplo, expondo um PLC numa VLAN acessível via VPN compartilhada — você cria um alvo perfeito pro atacante. Foi exatamente o que aconteceu nesse caso.
O vetor de ataque: dispositivos IoT expostos
O FBI foi direto: os criminosos exploram dispositivos conectados à internet. Isso inclui:
- Roteadores e firewalls com management exposto
- HMI (Human-Machine Interface) com VNC ou RDP aberto pra internet
- PLCs com servidores web embarcados (Modbus/TCP, EtherNet/IP, S7comm)
- Câmeras e sensores com firmware desatualizado
Já vi isso em auditorias. O pessoal coloca um PLC novo na planta, conecta no switch da rede corporativa “pra facilitar o monitoramento”, e em 48 horas o equipamento aparece no Shodan. A partir daí, é questão de tempo até alguém mexer nele.
Na Prática: um script simples pra detectar PLCs expostos na sua rede
Nem todo dev tem acesso a uma estação de tratamento. Mas se você gerencia qualquer rede corporativa, vale rodar uma checagem parecida. Esse script em Python usa scapy pra varrer um range IP e identificar hosts que respondem em portas típicas de PLCs:
# detector_plcs.py
# Requer: pip install scapy
from scapy.all import IP, TCP, sr1, conf
import ipaddress
# Portas comuns de PLCs e protocolos industriais
PLC_PORTS = {
502: "Modbus/TCP",
44818: "EtherNet/IP (CIP)",
102: "SIE S7comm (Siemens)",
9600: "Omron FINS",
1883: "MQTT (comum em SCADA moderno)",
47808: "BACnet (automação predial)",
2222: "Rockwell RSLogix"
}
def scan_subnet(network_cidr, timeout=1):
conf.verb = 0
network = ipaddress.ip_network(network_cidr, strict=False)
encontrados = []
print(f"[+] Varrendo {network_cidr} em {len(PLC_PORTS)} portas industriais...")
for host in network.hosts():
for porta, protocolo in PLC_PORTS.items():
pkt = IP(dst=str(host)) / TCP(dport=porta, flags="S")
resp = sr1(pkt, timeout=timeout)
if resp and resp.haslayer(TCP):
if resp[TCP].flags == 0x12: # SYN-ACK
encontrados.append((str(host), porta, protocolo))
# Encerra a conexão educadamente
sr1(IP(dst=str(host)) / TCP(dport=porta, flags="R"), timeout=0.5)
return encontrados
if __name__ == "__main__":
# Ajuste para sua rede — cuidado pra não escanhar redes que você não administra
resultados = scan_subnet("192.168.1.0/24", timeout=0.8)
print(f"\n[+] {len(resultados)} serviços industriais encontrados:\n")
for host, porta, proto in resultados:
print(f" ⚠️ {host}:{porta} → {proto}")
if resultados:
print("\n[!] Recomendação: isolar esses hosts em VLAN dedicada,")
print(" desativar servidores web embarcados e exigir VPN pra acesso.")
Rodei uma variação desse código num cliente de manufatura e encontrei 14 PLCs respondendo na rede de TI — todos sem autenticação. Se você trabalha com infra, já sabe o tamanho do estrago. Esse script não é invasivo (apenas handshake TCP), mas só use em redes onde você tem autorização.
Erros comuns que devs cometem em ambientes industriais
Quando você sai do mundo puramente web e entra em chão de fábrica, alguns hábitos precisam morrer. Esses são os erros que mais vejo:
1. Tratar o PLC como se fosse um servidor Linux
Você não pode dar apt update num PLC. Atualizações de firmware exigem parada de produção, validação de processo e, muitas vezes, reboque físico. Isso faz com que equipamentos rodem firmware de 2010 até hoje. A correção tem que vir do design de rede, não do patch.
2. Expor HMI pra “facilitar o acesso”
“Ah, vou abrir a porta 5900 no firewall pra acessar o VNC da sala de controle de casa.” Pronto, seu HMI está no Shodan. Use sempre jump host, VPN com MFA e sessão gravada.
3. Senhas padrão
Se o PLC tem usuário admin/admin, ele vai ser invadido. E não, não dá pra confiar que “ninguém vai descobrir”. Ferramentas como o Shodan varrem a internet inteira 24/7 indexando dispositivos industriais.
4. Misturar rede de TI e OT no mesmo switch
O notebook do RH não pode estar no mesmo domínio de broadcast que o PLC que dosa cloro. VLANs, segmentação física, e firewalls entre os domínios não são luxo — são requisito mínimo.
5. Logs? Que logs?
PLC raramente tem auditoria decente. Você precisa de um IDS industrial — ferramentas como o Conpot simulam PLCs pra atrair atacantes e gerar telemetria. Em produção, considere Suricata com regras ETPRO pro ICS.
O que devs de software podem aprender com isso
Pode parecer que o tema é distante — “não trabalho com saneamento”. Mas pense:
- Se você desenvolve pra IoT, seus devices podem ser o vetor de ataque.
- Se você hospeda APIs, alguém pode usar seu endpoint pra pivotear pra uma rede interna.
- Se você usa Docker, Kubernetes ou qualquer orquestrador, um segredo exposto no PLC vizinho pode escalar até sua aplicação.
A mentalidade certa é a de “defesa em profundidade”: nunca confie em um único controle. Mesmo que o PLC tenha senha forte, se ele está numa rede mal segmentada, ele é vulnerável.
Recomendações concretas (vindas do FBI e da EPA)
O comunicado original é claro e prático. Traduzo aqui pro contexto de quem implementa:
- Remova PLCs da internet pública. Use VPN site-to-site ou acesso remoto com MFA.
- Troque credenciais padrão e use senhas únicas por equipamento — gerencie com Vault ou similar.
- Implemente listas de controle de acesso (ACLs) no switch gerenciável: só o IP do SCADA fala com o PLC.
- Firewalls industriais com inspeção de protocolo (deep packet inspection para Modbus, S7comm, CIP).
- Monitoramento contínuo — alertas quando aparece um novo MAC na rede OT ou quando um PLC responde em horário incomum.
FAQ — o que devs perguntam sobre ataques a infra crítica
1. Um PLC realmente pode ser acessado só pelo IP se estiver exposto?
Sim. Muitos PLCs têm servidor web embutido na porta 80/443 e APIs REST sem autenticação. Modelos antigos da Siemens (S7-1200/1500) e Allen-Bradley (ControlLogix) já foram alvo de worms como o Stuxnet e o CrashOverride.
2. Como um ataque desses pode causar alagamento?
Alterando a lógica de controle de bombas e válvulas. Se o atacante abre uma válvula de entrada sem parar a bomba, ou desliga uma bomba mantendo válvula aberta, o reservatório transborda.
3. Existe padrão internacional pra segurança de SCADA?
Sim: a IEC 62443 é a referência. O NIST também publica o framework SP 800-82 específico pra ICS. Em ambiente corporativo, alinhar com ISO 27001 ajuda a cobrir o lado de TI.
4. Dev comum pode contribuir pra segurança OT?
Pode. Hardening de imagens Docker, revisão de código em APIs de telemetria, e até contribuir pra projetos open-source como o Open-source ICS tools. Conhecimento de rede e protocolo já te coloca à frente de 80% do mercado OT.
5. Esse tipo de ataque já aconteceu no Brasil?
Sim, em menor escala. Em 2021 a Light S/A (RJ) relatou tentativas. O Centro de Tratamento de Resíduos em SC teve incidente em 2022. O problema é subnotificado — muitas empresas pagam pra não expor.
Ponto final: software com responsabilidade física
O caso reportado pelo Olhardigital é mais um alerta de que código não roda só em servidor — roda em turbinas, bombas, válvulas e redes elétricas. Pra quem programa, isso muda o cálculo: uma falha de validação não causa só um 500, pode causar enchente. Ou algo pior.
Se você trabalha com sistemas distribuídos, containers, ou qualquer coisa que se conecta a uma rede, vale gastar uma hora estudando os princípios de OT. Faz diferença — e abre mercado, porque faltam profissionais que entendem os dois lados.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.