Hunting em OT e ICS

Nota 17 do capítulo 08 (Técnicas de Hunting por TTPs) e última do capítulo, levando a caça aos ambientes industriais onde disponibilidade vence confidencialidade.
Cobre o modelo Purdue, a telemetria passiva com Zeek ICS e NDR de OT, a anatomia dos protocolos Modbus, DNP3 e S7comm, as TTPs de manipulação de PLC e HMI e as hipóteses seguras sem varredura ativa.
Fecha o arco com as notas 12 a 16; conecta-se à matriz ATT&CK for ICS, ao comparativo de ambientes da nota 16 e aos controles DAT.2, TH.2, IR.3 e MET.2 do capítulo 15.

1. Contexto e Posicionamento na Biblioteca

OT (Operational Technology) é a tecnologia que observa e comanda o processo físico: bombas, fornos, linhas de envase, subestações. Os ICS (Industrial Control Systems) são o conjunto de PLCs, RTUs, servidores SCADA e HMIs que executa esse comando, e a tríade de segurança se inverte em relação ao IT: disponibilidade e segurança de pessoas e ativos vêm antes da confidencialidade. Uma detecção errada que pare produção pode custar mais que o incidente que se tentava evitar, e é por isso que a consequência para a caça é doutrinária: hipóteses são testadas de forma passiva, sem sondar equipamento, e todo achado é validado com a engenharia de controle antes de virar ação. Stuxnet em 2010, Industroyer em 2016, TRITON em 2017 e Pipedream em 2022 provam que o adversário chega a esse domínio com ferramenta dedicada, e a matriz ATT&CK for ICS formaliza as técnicas com a série T08xx.

O posicionamento na biblioteca fecha o arco do capítulo 08: notas 12 a 14 cobriram rede e protocolos de IT, nota 15 cobriu o vetor humano, nota 16 cobriu o ambiente orquestrado, e esta nota mostra que a mesma disciplina de hipótese sobrevive onde os sensores não podem tocar o ativo. Tanto aqui quanto lá, o método é o do capítulo 07, mas as restrições mudam o conteúdo das hipóteses: em OT, o que não se pode fazer define tanto quanto o que se quer achar. A nota também devolve uma lição ao resto da biblioteca: se a caça funciona em um domínio onde tocar o ativo é proibido, o hábito passivo que ela exige, de observação sem interferência e validação com o dono do processo, volta para o IT como disciplina de coleta e de triagem.

2. Modelo Purdue, Zonas e Prioridades

O modelo Purdue organiza o ambiente industrial em níveis, e cada nível define o que se pode observar e como. No nível 0 estão sensores e atuadores; no 1, PLCs, RTUs e controladores DCS; no 2, servidores SCADA e HMIs (Human-Machine Interface); no 3, operações, com historian, MES e estações de engenharia; no 3.5, a DMZ industrial com jump hosts e servidores de patch; e nos níveis 4 e 5, o IT corporativo. O padrão IEC 62443 adiciona zonas e condutos, e a escolha de onde colocar sensor passa por eles: os condutos entre os níveis 3, 3.5 e 2 entregam a maior visibilidade com o menor risco, porque transportam praticamente todo comando relevante.

A proibição de varredura ativa nos níveis baixos não é conservadorismo: há casos documentados de varreduras que derrubaram linhas de produção e estudos acadêmicos que demonstraram impacto em equipamento por interações TCP inesperadas. PLCs são computadores de tempo real de propósito único, com firmware velho e pilhas de rede sensíveis, e o ganho marginal de um inventário ativo não compensa o risco. A alternativa é o inventário passivo, que a seção 3 constrói, e que frequentemente supera em qualidade o inventário ativo porque reflete o tráfego real e não o que responde a probe. A leitura do modelo Purdue para o programa de caça é, portanto, uma matriz de prioridades: começa-se pelo conduto do nível 3 para o nível 2, segue-se para o 3.5 e o conduto do SIS, e só depois se discute telemetria no nível 2, sempre passiva.

3. Telemetria Passiva com Zeek ICS e NDR de OT

A coleta passiva usa TAP ou SPAN nos condutos críticos e alimenta dois consumidores: um NDR de OT comercial, como Nozomi, Claroty ou Dragos, que entrega inventário e profundidade de protocolo; e o Zeek com os analisadores ICS, aberto e transparente, que serve de contraprova e de base para consultas próprias. O Zeek base traz modbus.log, dnp3.log e enip.log; a coleção ICSNPP do Idaho National Laboratory agrega parsers para OPC UA, BACnet, CIP e outros, além de versões estendidas de Modbus e DNP3; para S7comm, plugins da comunidade e os NDR dedicados cobrem o protocolo Siemens. O TAP ótico de leitura em espelhamento é preferível ao SPAN quando o switch de OT não garante buffer para picos de tráfego, porque um SPAN sobrecarregado descarta pacotes silenciosamente e distorce o baseline.

O primeiro produto da telemetria passiva é o inventário: MAC por OUI, IPs, unit_ids Modbus vistos, conjunto de function codes por dispositivo, pares de comunicação por conduto. Esse inventário é o baseline do TH.2 adaptado ao OT e costuma ser, por si só, uma entrega que a engenharia de controle não possui. Os schemas dos logs ICS são rasos mas os campos são ricos: no modbus.log, function, unit_id, address e quantity bastam para todas as hipóteses de escrita; no dnp3.log, fc_request e fc_response separam leitura de controle. A retenção de pcap nos condutos críticos, com data diode quando a segregação exigir, transforma qualquer achado posterior em evidência completa.

A implantação do sensor segue a mesma regra de passividade: porta de monitoramento sem endereço IP de gestão acessível a partir do OT, sincronização de relógio por fonte dedicada e nenhum componente que inicie conexão para dentro da zona observada. O bloco abaixo resume a montagem mínima de um sensor Zeek com os parsers ICSNPP e a captura integral do conduto para evidência, com rotação diária e compressão.

# Sensor Zeek no conduto entre os níveis 3 e 3.5, interface de monitor sem IP de gestão
zkg install icsnpp/icsnpp-modbus icsnpp/icsnpp-dnp3 icsnpp/icsnpp-s7comm icsnpp/icsnpp-opcua-binary
cat >> /opt/zeek/share/zeek/site/local.zeek <<'EOF'
@load policy/protocols/modbus
@load policy/protocols/dnp3
@load policy/protocols/enip
@load icsnpp-modbus
@load icsnpp-dnp3
@load icsnpp-s7comm
@load icsnpp-opcua-binary
redef LogAscii::use_json = T;
EOF
zeekctl deploy
# Captura integral do conduto para evidência, rotação diária e retenção de 30 dias
tcpdump -i ens1f1 -G 86400 -W 30 -w '/pcap/conduto_ot_%Y%m%d.pcap' \
  'port 502 or port 20000 or port 102 or port 44818 or port 4840'

4. Anatomia dos Protocolos: Modbus, DNP3 e S7comm

Modbus/TCP é o protocolo mais simples e o mais presente em plantas legadas: um cliente envia requisições com function code, endereço inicial e quantidade, e o servidor responde com os dados. As funções 1 a 4 leem coils, discrete inputs, holding registers e input registers, e são o tráfego volumétrico normal da operação; as funções 5, 6, 15 e 16 escrevem pontos de processo, e são raras, agendadas e autorizáveis. As funções 90 e 91, do padrão Modicon de download e upload de programa, são o mecanismo pelo qual Stuxnet reprogramou PLCs, e por isso figuram em praticamente toda hipótese de reprogramação. Para a caça, o triângulo function, unit_id e address é a assinatura completa: ele diz quem falou, com que verbo e sobre qual ponto do processo.

DNP3 organiza-se em master e outstations, com filas de evento e confirmação explícita, e é o padrão de subestação e utilities. O ciclo legítimo de comando é Select e depois Operate, com confirmação em cada passo, e por isso a aparição de Select sem Operate, de Operate sem Select ou de Direct Operate fora do conjunto master são anomalias de gramática, não apenas de origem. O campo fc_request do dnp3.log expõe o verbo da transação, e o par origem e fc_request basta para isolar comando de controle sem tocar o outstation. Em plantas utilities, o outstation responde por rádio ou serial gateado para TCP, e a observação no gate evita perder o início da sessão.

S7comm é o protocolo de engenharia e operação dos PLCs Siemens e é o mais estruturado dos três: o campo ROSCTR distingue job, ack e ack_data, e a função 0x28 carrega jobs de programação como download, upload e insert de bloco. Uma sessão de engenharia legítima é longa, autenticada e seguida de transferência de blocos, e o baseline precisa registrar qual estação faz isso e quando; uma sessão curta que já abre com download é o oposto do padrão e merece hipótese própria. As funções 0x1A e 0x1B, de download e insert de bloco, são o equivalente S7 das funções 90 e 91 de Modbus, e a mesma unidade de normalidade se aplica: quem pode transferir bloco, para qual PLC e em que janela.

As linhas abaixo ilustram o que a caça lê nos logs, com valores sintéticos no formato dos arquivos Zeek: no modbus.log, a escrita de 24 registers em um unit_id de processo; no dnp3.log, um comando de controle direto cuja origem não pertence ao conjunto master. Esses dois formatos cobrem a maior parte das hipóteses desta nota e são a gramática mínima que o time precisa dominar antes de brigar por profundidade de protocolo com o NDR.

1745685123.441022  CsK2ab3xDQ9  10.40.12.77  49212  10.40.12.9  502  tcp  9  16  40210  24
1745685400.654321  CyT8za1vAB2  10.40.9.30   10422  10.40.9.5   20000  tcp  DIRECT_OPERATE

5. TTPs Específicas de OT

A tabela abaixo concentra as técnicas da série T08xx com maior retorno em caça passiva. A lógica comum é que manipulação de processo exige comando de escrita em algum ponto, e escrita é rara e registrável em ambiente industrial bem operado.

Os casos públicos mapeiam direto nas hipóteses da seção 6. Stuxnet reprogramou PLCs Modicon usando os function codes de download de programa, 90 e 91, que ficaram célebres na literatura; Industroyer implementou os protocolos de subestação, entre eles DNP3 e IEC 60870-5-104, para abrir disjuntores; TRITON atacou o sistema instrumentado de segurança (SIS) via protocolo TriStation, provando que o conduto do SIS precisa de observação própria; e Pipedream trouxe interação nativa com PLCs Schneider e OMRON e abuso de HMI baseada em CODESYS. Cada caso reforça a mesma leitura: o adversário precisa chegar ao comando, e o caminho até o comando atravessa condutos observáveis. A consequência prática é que o catálogo de caça em OT é curto no topo: reprogramação, comando sem autor, sessão de engenharia sem ticket e participante novo na zona de controle cobrem o grosso do comportamento observado em casos públicos.

6. Hipóteses de Caça Seguras (Somente Passivas)

As hipóteses abaixo respeitam a doutrina passiva e compartilham a mesma unidade de normalidade: o par dispositivo e endereço, com escritor autorizado e janela permitida. O workshop com a engenharia de controle define, para cada classe de dispositivo, quem pode escrever, o que pode escrever e quando, e as janelas de manutenção aprovadas viram o calendário contra o qual toda escrita é avaliada. A formulação segue o formato SE-ENTÃO do controle TH.6 do capítulo 15, mas com a cláusula de execução restrita a consultas sobre logs e pcap coletados, jamais com conexão ao ativo.

A primeira consulta isola as escritas Modbus, funções 5, 6, 15 e 16, e os downloads de programa, funções 90 e 91, que em planta bem operada são eventos raros e agendados. A segunda isola comandos de controle DNP3, e a terceira compara os pares de comunicação do dia com o baseline para achar participantes novos na zona de controle. Nenhuma das três emite pacote para a planta: tudo é leitura de log produzido pelo sensor passivo, e a execução pode ocorrer em cópia no ambiente de análise sem qualquer rota de volta ao conduto.

cat modbus.log | zeek-cut id.orig_h unit_id function address quantity |
  awk '$3 == 5 || $3 == 6 || $3 == 15 || $3 == 16 || $3 == 90 || $3 == 91 { print }' |
  sort | uniq -c | sort -rn | head -25
cat dnp3.log | zeek-cut id.orig_h id.resp_h fc_request |
  awk '$3 ~ /Operate|Select/ { print $1, $2, $3 }' | sort | uniq -c | sort -rn | head -20
cat conn.log | zeek-cut id.orig_h id.resp_h | sort -u > pares_hoje.tsv
comm -13 pares_baseline.tsv pares_hoje.tsv | head -25

A leitura cruza cada escrita com o calendário de manutenção e com o ticket de mudança; escrita sem ticket é o achado típico, e a maioria dos achados reais em OT termina em falha de processo de mudança, não em intrusão. Esse resultado é valor, não ruído: cada escrita sem ticket corrigida encurta a fila do dia em que a escrita for do adversário. Restrições de compartilhamento merecem o mesmo cuidado: log de OT revela topologia de processo sensível, e a integração com o SIEM corporativo passa por data diode ou SIEM dedicado com classificação TLP definida antes da primeira exportação.

7. Caso de Caça: Mudança de Lógica em PLC

O caso da biblioteca acompanha uma linha de envase com PLC Modicon no nível 1. O baseline de escritas, construído em 90 dias passivos, mostra função 16 apenas da estação de engenharia eng-ws-02, em janelas de manutenção com ticket, sobre unit_ids 3, 7 e 9. A caça mensal encontra, num domingo às 03h12, três escritas de função 16 com 24 registers cada, do host 10.40.12.77, segmento de outra linha, para o unit_id 9, sem ticket e fora de janela. O conn.log confirma que o host nunca havia falado com esse PLC no baseline, e as linhas abaixo reproduzem o formato do achado no modbus.log.

1745685123.441022  CsK2ab3xDQ9  10.40.12.77  49212  10.40.12.9  502  tcp  9  16  40210  24
1745685124.102943  CsK2ab3xDQ9  10.40.12.77  49214  10.40.12.9  502  tcp  9  16  40260  24
1745685125.733851  CsK2ab3xDQ9  10.40.12.77  49216  10.40.12.9  502  tcp  9  16  40310  24

A validação segue passiva e coordenada. O historian mostra que os registers escritos são os de receita da linha e que a velocidade máxima do processo mudou após as 03h12; a engenharia confirma que a receita foi alterada e que ninguém solicitou a mudança; o questionamento rotineiro revela que um técnico usou o laptop de outra linha para acelerar o processo sem pedir autorização, encurtando margem de segurança que o projeto exigia. A resposta respeitou a doutrina: o host foi isolado no conduto com aprovação da engenharia e em janela, o evento virou caso de IR com o pcap retido como evidência, a margem de segurança foi restaurada antes do próximo turno e a revisão de acesso cruzado entre linhas entrou no plano de correção. A conversão em detecção criou a regra permanente ilustrada abaixo, de escrita de função 15, 16, 90 ou 91 por origem fora das estações de engenharia aprovadas, com a caça mensal mantida para os casos que a regra não cobre, porque regra vê padrão conhecido e caça vê novidade.

title: Escrita Modbus por origem fora das estacoes de engenharia
logsource:
    product: zeek
    service: modbus
detection:
    selection_funcao:
        function: [15, 16, 90, 91]
    filter_engenharia:
        id.orig_h:
            - '10.40.3.51'
            - '10.40.3.52'
    condition: selection_funcao and not filter_engenharia
fields:
    - id.orig_h
    - unit_id
    - address
    - quantity
level: high

A lição do caso orienta o programa: a primeira safra de caça em OT encontra falha de gestão de mudança, não APT, e isso é positivo em duas frentes. Primeiro, cada correção encurta o caminho do adversário futuro; segundo, a utilidade imediata constrói a confiança com o time de engenharia, sem a qual nenhuma caça em OT sobrevive, porque são eles que validam o que é normal no processo. O caso também calibra expectativa com a gestão: o valor de um programa de caça em OT no primeiro ano se mede mais em risco de processo eliminado do que em intrusão detectada, e as métricas da seção 8 existem para tornar esse valor visível.

8. Métricas e Maturidade do Programa de Caça em OT

O programa de caça em OT precisa de métricas próprias porque as métricas de IT premiam velocidade, e em OT o gargalo é validação e confiança com a engenharia. O controle MET.2 do capítulo 15 fornece o formato de KPI de hunting, e a adaptação abaixo troca volume de hipóteses executadas por cobertura de condutos e qualidade de baseline, que são os fatores que realmente limitam a caça passiva. As metas iniciais são deliberadamente modestas, e a meta de regra permanente por trimestre evita a armadilha de caçar em loop sem consolidar nada em detecção.

A maturidade evolui por estágios verificáveis: no primeiro estágio o programa entrega inventário passivo e baseline de escritas; no segundo, executa o catálogo da seção 6 com cadência mensal e pareamento com a engenharia; no terceiro, converte achados recorrentes em regras permanentes e alimenta o CTI com casos reais da planta; no quarto, replica o catálogo entre unidades industriais reutilizando a unidade de normalidade. Cada estágio precisa de evidência para ser declarado, e a evidência é sempre artefato: inventário assinado pela engenharia, ata de workshop, regra em produção, relatório no formato do capítulo 03.

9. Erros Comuns e Pontos de Atenção

• Varredura ativa nas zonas de controle; efeito: risco real de parada de produção e perda de confiança do time OT; correção: passividade total nos níveis 0 a 2 e varredura apenas em laboratório ou DMZ.
• Copiar limiares de IT para OT; efeito: eventos raros e normais viram alerta e a fila perde credibilidade; correção: workshop com engenharia definindo escritores autorizados, endereços e janelas por dispositivo.
• Ignorar o calendário de paradas; efeito: comissionamento legítimo vira incidente falso; correção: cruzar toda caça com calendário de manutenção e tickets de mudança.
• Exportar log de OT direto para o SIEM corporativo sem avaliar segregação; efeito: exposição de topologia de processo sensível; correção: data diode ou SIEM dedicado com TLP definido antes da primeira exportação.
• Tratar o NDR de OT como fonte única; efeito: dependência de fornecedor e cegueira a protocolos não cobertos; correção: Zeek como contraprova aberta e inventário passivo independente.
• Caçar sem dono na engenharia; efeito: achados não viram ação porque ninguém pode intervir no processo; correção: co-análise formal com engenharia de controle em todas as fases.
• Esquecer o SIS na cobertura; efeito: o caminho do TRITON fica invisível porque a observação só cobre o sistema de controle; correção: sensor passivo também no conduto do sistema instrumentado de segurança, quando existir.
• Subestimar a manutenção remota de fornecedores; efeito: canal clássico de acesso inicial em casos públicos fica fora das hipóteses; correção: hipótese dedicada a sessões de fornecedor, com agenda aprovada e jump host como único caminho.
• Deixar o baseline envelhecer; efeito: mudanças legítimas viram falso positivo e a engenharia para de responder; correção: revalidação trimestral do baseline em workshop com calendário de paradas na mesa.

10. Integração com o Restante da Biblioteca

A matriz ATT&CK for ICS, tratada com o ATT&CK Enterprise na nota 01 do capítulo 04, é o vocabulário comum entre esta nota e o programa de CTI, e as TTPs da série T08xx alimentam hipóteses e relatórios do mesmo jeito que a série T1xxx. O DAT.2 e o TH.2 do capítulo 15 definem a coleta passiva e o baseline que aqui viram inventário e calendário de mudança; o TH.6 estrutura a formulação SE-ENTÃO das hipóteses da seção 6; o IR.3 orienta a contenção, que em OT precisa ser negociada com a engenharia e executada em janela; e o MET.2 fornece o formato dos indicadores da seção 8. O capítulo 26 completa o quadro com a arquitetura dos ambientes modernos, onde fronteiras IT e OT se dissolvem parcialmente, e o capítulo 12 concentra as boas práticas de cultura que fazem a ponte entre SOC e chão de fábrica.

A nota 16, de hunting em containers e Kubernetes, é o par mais instrutivo desta nota para leitura comparada, porque os dois ambientes quebram a suposição de agente onipresente que sustenta o hunting clássico de endpoint. Em containers, o plano de controle API server e os logs de audit substituem o agente; em OT, o conduto observado substitui o agente; nos dois casos, a unidade de normalidade muda de processo e host para identidade com verbo permitido, ou dispositivo com escritor autorizado. Um analista que exercita as duas notas entende que o desenho da telemetria é derivado do risco de tocar o ativo, e não do conforto da ferramenta, e leva essa lição de volta para o IT tradicional, onde a tentação de caçar com varredura e probe é maior justamente porque quase nunca foi cobrada a conta por isso.

O aprendizado estrutural que encerra o capítulo 08 é a generalização da unidade de normalidade: em rede IT a unidade é o par de hosts com serviços esperados; em cluster é a identidade com verbos permitidos; em OT é o dispositivo com endereços, escritores autorizados e janelas. Formular hipóteses nessa gramática comprime todas as consultas desta nota em um modelo portátil entre plantas, e é o que permite que o catálogo de caça de OT cresça reutilizável, como o de IT, em vez de recomeçar a cada unidade industrial. Para o analista que segue para os capítulos de resposta e métricas, o compromisso desta nota é o critério de saída de qualquer caça em OT: um achado só encerra quando a engenharia de controle emitiu parecer, o risco de processo foi tratado e a hipótese virou regra, hipótese reformulada ou motivo documentado de descarte.