Segurança OT: como detectar ataques Modbus em redes SCADA

Vi essa notícia no Olhardigital.com.br e meu primeiro instinto foi: “a gente ainda não aprendeu nada sobre segurança em sistemas industriais”. Ataques a redes de água nos EUA expondo falhas em SCADA e PLCs não são novidade — é o mesmo roteiro de Stuxnet (2010), do ataque à usina de tratamento de água na Flórida (2021, quando alguém tentou aumentar o hidróxido de sódio para níveis perigosos via TeamViewer), e de dezenas de incidentes em oleodutos, hospitais e fábricas. O que muda é a escala e a suspeita de envolvimento iraniano. O que não muda é a fragilidade operacional.

Neste artigo, quero ir além da manchete. Vou te mostrar por que sistemas industriais (OT/ICS) são alvos fáceis, qual é a superfície real de ataque em estações de tratamento de água, como um desenvolvedor pode simular e detectar essas falhas, e onde a maioria dos times de engenharia tropeça. Sem achismo — tudo baseado em protocolos reais como Modbus, DNP3 e IEC 60870-5-104.

Por que sistemas de água (e OT em geral) são tão vulneráveis

Na minha experiência em integrações industriais, percebo que existe um abismo cultural entre TI (Information Technology) e TO (Operational Technology). Quando programei pela primeira vez em CLP (Controlador Lógico Programável), levei um susto: a maioria desses dispositivos roda firmware proprietário, sem atualizações há anos, com portas seriais RS-485 expostas em redes TCP/IP através de gateways baratos. E ninguém coloca patch.

O contraste com TI é brutal:

Tempo de vida: um servidor web é trocado a cada 3-5 anos. Um PLC de tratamento de água pode rodar por 15-20 anos com o mesmo firmware.
Atualizações: em TI, patch Tuesday é sagrado. Em OT, atualizar pode significar parar o abastecimento — e ninguém quer ser o gerente que deixou uma cidade sem água.
Autenticação: credenciais default como admin/admin, vendor/1234 ainda são comuns em HMIs.
Criptografia: protocolos como Modbus TCP foram projetados em 1979. Não possuem autenticação nem criptografia. O tráfego é literalmente legível em texto claro.

Quando o prefeito de Braham, em Minnesota, disse que “têm quase certeza de que são atores iranianos”, o que ele está descrevendo é o modus operandi clássico de grupos APT (Advanced Persistent Threat) sondando redes OT através de internet scanning massivo. Ferramentas como Shodan e Censys indexam dispositivos Modbus na porta 502 e DNP3 na porta 20000 todos os dias. É um catálogo de alvos aberto.

A superfície técnica de ataque em estações de água

Vamos destrinchar o que realmente está em jogo. Uma estação de tratamento moderna tem, no mínimo, estes componentes expostos:

CLPs (PLCs): controlam dosagem química (cloro, flúor), bombas e válvulas. Marcas como Allen-Bradley, Siemens S7-1200, Schneider M340.
RTUs (Remote Terminal Units): fazem telemetria com subestações remotas e reservatórios.
HMI/SCADA: a interface visual que o operador usa. Frequentemente Windows com VNC ou RDP exposto.
Historian: banco de dados que registra tudo (PI System, Wonderware). Pode conter credenciais úteis para movimento lateral.
Engenharia remota: VPNs perpétuas para fornecedores darem suporte. Quando o fornecedor vai à falência ou é comprometido, a VPN continua ativa.

O ataque típico segue três fases. Primeiro, reconhecimento: varredura de IPs na porta 502 (Modbus) ou 102 (S7Comm). Segundo, enumeração: leitura de coils e holding registers para entender o processo. Terceiro, manipulação: escrita em registros críticos — por exemplo, alterar a dosagem de cloro ou desligar bombas.

Em 2016, o grupo CyberX descobriu que um botnet mirai-like infectou estações de água na Europa simplesmente porque rodavam Windows XP em HMIs conectadas à internet. O caso atual nos EUA é menos sofisticado em método, mas maior em coordenação.

Na Prática: como simular e detectar uma sondagem em uma rede OT

Vou te mostrar um experimento que rodei em ambiente controlado (com PLC simulado em Modbus) para detectar tentativas de leitura anômala. É um script Python usando pymodbus que monitora requisições suspeitas.

Passo a passo para reproduzir em lab:

Instale as dependências: pip install pymodbus scapy
Suba um servidor Modbus fake: python -m pymodbus.server --host 0.0.0.0 --port 5020
Rode o sniffer abaixo para capturar requisições

# detector_ot.py
# Monitora tráfego Modbus TCP e alerta quando detecta
# escritas em registros sensíveis (holding registers >= 40001)
from scapy.all import sniff, TCP, Raw
from collections import defaultdict
import time

WINDOW_SECONDS = 10
THRESHOLD_WRITES = 5  # mais de 5 escritas em 10s = suspeito
HOLDING_REGISTER_RANGE = (40001, 49999)  # faixa crítica

contador_escritas = defaultdict(list)
origens_suspeitas = set()

def analisar_pacote(pkt):
    if not pkt.haslayer(TCP) or not pkt.haslayer(Raw):
        return

    payload = pkt[Raw].load
    if len(payload) < 8:
        return

    # Modbus TCP: MBAP header (7 bytes) + PDU
    mbap = payload[:7]
    pdu = payload[7:]
    transacao = int.from_bytes(mbap[0:2], 'big')
    function_code = pdu[0]

    # 0x06 = Write Single Register, 0x10 = Write Multiple Registers
    if function_code not in (0x06, 0x10, 0x05):
        return

    src_ip = pkt[IP].src
    now = time.time()

    # filtra janela de tempo
    contador_escritas[src_ip] = [
        t for t in contador_escritas[src_ip]
        if now - t < WINDOW_SECONDS
    ]
    contador_escritas[src_ip].append(now)

    if len(contador_escritas[src_ip]) > THRESHOLD_WRITES:
        if src_ip not in origens_suspeitas:
            origens_suspeitas.add(src_ip)
            print(f"[ALERTA] {src_ip} excedeu {THRESHOLD_WRITES} escritas "
                  f"em {WINDOW_SECONDS}s — possível ataque OT")
            print(f"        Última transação MBAP: {transacao}")

print("[*] Sniffer Modbus iniciado. Ctrl+C para parar.")
sniff(filter="tcp port 502", prn=analisar_pacote, store=0)

Esse código é didático, mas em produção você conectaria isso a um SIEM (Splunk, Wazuh) e correlacionaria com listas de IPs maliciosos e geolocalização. A ideia central: em uma rede OT bem segmentada, não deveria haver tráfego Modbus originado de fora do segmento de controle. Se há, é anomalia.

Erros Comuns que devs e engenheiros cometem em projetos OT

Quando atuei em uma integração SCADA para uma indústria de alimentos, vi três padrões se repetirem até a exaustão. Vou listar os piores:

1. Expor a HMI na internet "só para o técnico acessar de casa". RDP ou TeamViewer aberto em modem 4G rural, sem MFA, sem VPN. É assim que hackers entram — não por exploit de zero-day, mas por credencial default.
2. Misturar rede corporativa com rede de controle. O laptop do engenheiro que navega no YouTube está no mesmo switch que o PLC que dosa cloro. Vírus de propaganda -> movimento lateral -> PLC comprometido.
3. Confiar em "air gap" (ilha de rede). O conceito de air gap morreu em 2010. Hoje, todo engenheiro leva notebook com Wi-Fi para dentro da planta. Stuxnet provou que basta um pendrive.
4. Coletar logs, mas nunca alertar. Existe SCADA com sistema de auditoria ativado, mas o time de TI não monitora. Logs em disco rígido que ninguém abre até o incidente virar manchete.
5. Tratar cibersegurança como "problema de TI". Em OT, o risco é operacional. Parar uma bomba pode significar contaminação. A análise de risco é qualitativamente diferente.

Boas práticas que funcionam de verdade

Não existe bala de prata, mas existem medidas com ROI alto e baixo custo. Na minha experiência, estas funcionam:

Segmentação com DMZ industrial: use firewalls com DPI (Deep Packet Inspection) que entendem Modbus/DNP3, como o Claroty ou o Nozomi Networks. Negue por padrão, libere por exceção.
Inventário de ativos passivo: escaneie a rede continuamente para descobrir dispositivos não autorizados. Surpreendentemente, acha-se sempre algo: roteadores de escritório plugados no barramento de campo.
Whitelisting de aplicação no HMI: desabilite USB, desabilite navegação, bloqueie executáveis não assinados via AppLocker ou WDAC (Windows Defender Application Control).
Princípio do menor privilégio em contas de serviço: se a estação de engenharia só precisa ler, não dê permissão de escrita em registros críticos.
Plano de resposta a incidente específico para OT: quem eu ligo se o PLC parar de responder? Como isolar a rede sem afetar o abastecimento? Quem avisa a agência reguladora?

Repito: essas medidas não impedem um APT estatal dedicado. Mas bloqueiam 90% das sondagens automatizadas e dos ataques oportunistas que aparecem em notícias como essa.

FAQ — Perguntas que devs realmente fazem

Modbus TCP e DNP3 são protocolos inseguros por design?
Sim. Ambos foram criados antes da internet ser onipresente. Modbus TCP (porta 502) não tem autenticação, criptografia nem integridade. DNP3 Secure Authentication v5+ adiciona criptografia, mas a maioria das implementações ainda roda DNP3 v3 legado. Em ambientes críticos, encapsule em TLS via VPN ou use gateways que traduzem para MQTT com TLS 1.3.

Como um dev web pode contribuir com segurança OT se nunca trabalhou com industrial?
Comece entendendo o NIST CSF (Cybersecurity Framework) e o ISA/IEC 62443. Depois, treine em simuladores como o OpenPLC ou o Conpot (honeypot ICS da Kaspersky). São open source. Você aprende os protocolos sem risco de quebrar nada real.

O ataque ao sistema de água dos EUA é realmente sofisticado ou é apenas ransomware oportunista?
Segundo o Olhardigital.com.br, a investigação ainda é preliminar e não há confirmação oficial de autoria. O que se sabe: as invasões afetaram sistemas administrativos e de monitoramento, não necessariamente o controle direto dos processos químicos — pelo menos até onde foi divulgado. Isso sugere reconhecimento e posicionamento, o que combina com APT, mas também pode ser crime oportunista explorando credenciais fracas.

Shodan realmente expõe esses sistemas?
Sim. Buscar port:502 country:US ou "Modbus" city:* retorna milhares de dispositivos. A maioria não deveria estar acessível. Se você trabalha em OT, faça uma busca agora mesmo e veja se aparece algum ativo seu. É um teste gratuito.

Qual certificação estudar para entrar na área de segurança OT?
GICSP (Global Industrial Cyber Security Professional) é o padrão da indústria. Para começar, o GRID do SANS Institute e o curso gratuito do ICS-CERT (CISA) são bons pontos de entrada.

O que aprendemos (de novo) com essa notícia

A manchete muda — desta vez foi água, em outras foram oleodutos (Colonial Pipeline 2021), frigoríficos (JBS 2021), hospitais (Universal Health Services 2020). O padrão permanece: ativos OT legados, mal segmentados, com credenciais fracas, conectados à internet por conveniência. O custo de um ataque de sucesso não é vazamento de dados — é impacto físico. Água contaminada, racionamento, pânico.

Se você é dev, considere migrar parte do seu foco para OT/ICS. A demanda explodiu, os salários são altos e a barreira de entrada (entender processos industriais + segurança + programação) afasta 90% dos candidatos. É um nicho onde quem entende Python + redes + segurança de infraestrutura se torna raro e valioso.

Para aprofundar, recomendo o livro Practical Industrial Cybersecurity da Packt, e o repositório awesome-industrial-control-system-security no GitHub. Tem décadas de conhecimento condensado.

Gostou? Me segue no GitHub (github.com/yuriaugusto) e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto — especialmente se trabalha em OT ou quer migrar para essa área.