Segurança para IoT Industrial (IIoT): anatomia de um gateway recrutado em botnet com pivô para OT

Por que o IIoT é um vetor de sabotagem, não apenas de vazamento

O IoT industrial nasceu de uma promessa legítima: instrumentar máquinas, esteiras, bombas, motores e sensores de campo para extrair telemetria em tempo real, prever falhas, otimizar consumo e operar remotamente plantas inteiras. Para entregar isso, fabricantes e plataformas de IIoT espalham gateways e sensores que vivem em dois mundos ao mesmo tempo: de um lado conversam com a nuvem do fabricante por MQTT, HTTPS ou protocolos proprietários; do outro lado falam Modbus, OPC-UA, PROFINET ou EtherNet/IP com os controladores lógicos programáveis (PLC) e os sistemas de supervisão (SCADA) que comandam o processo físico do cliente.

Essa dupla cidadania é exatamente o que torna o IIoT um problema de segurança de outra natureza. Um vazamento de dados em um SaaS comum custa multa e reputação. Um comprometimento de gateway IIoT pode custar a integridade física de um processo industrial: uma bomba que para, uma válvula que abre fora de hora, uma esteira que acelera, um forno que passa do setpoint. O risco deixa de ser confidencialidade e passa a ser disponibilidade e segurança operacional — em alguns contextos, segurança de pessoas. O fabricante de IIoT, portanto, carrega uma responsabilidade que extrapola o seu próprio ambiente: o seu firmware é a porta de entrada para o chão de fábrica de cada cliente.

Some-se a isso o ciclo de vida hostil do equipamento de campo: dispositivos que ficam em operação por 5, 10, 15 anos, raramente atualizados, frequentemente sem janela de manutenção, rodando firmware que ninguém mais lembra como compilar. A superfície de ataque do IIoT não é só ampla — ela é persistente no tempo e difícil de remediar. É por isso que a segurança precisa ser projetada no firmware e na arquitetura desde o início, não acrescentada depois.

As quatro ameaças que definem o risco do fabricante de IIoT

Firmware inseguro e comprometimento de gateway

O firmware é o coração do dispositivo e o lugar onde os erros mais caros se acumulam. Os padrões recorrentes que a Decripte encontra em auditorias de firmware IIoT incluem: credenciais embutidas no binário (usuário e senha de manutenção iguais em toda a frota); chaves criptográficas e certificados hardcoded e compartilhados entre dispositivos; atualização de firmware sem assinatura digital, permitindo que um atacante envie uma imagem maliciosa; serviços de depuração (UART, JTAG, telnet, SSH com senha fraca) acessíveis no equipamento; bibliotecas de terceiros desatualizadas com vulnerabilidades conhecidas; e ausência de Secure Boot, deixando o dispositivo executar qualquer código que esteja na flash.

Exposição de telemetria e controle remoto

A telemetria que sai do dispositivo costuma trafegar por MQTT, e brokers MQTT mal configurados são uma fonte clássica de exposição: tópicos sem ACL, autenticação anônima permitida, ausência de TLS, e — o pior — canais de comando que aceitam ordens sem verificar quem está mandando. Quando o canal de controle remoto não tem autenticação forte por dispositivo, qualquer um que descubra a topologia pode publicar um comando e atuar sobre o processo físico. Telemetria exposta também vaza inteligência operacional do cliente: ritmo de produção, paradas, capacidade — informação sensível que pode habilitar espionagem industrial.

Botnet de dispositivos IIoT e pivô para o OT

Gateways com firmware vulnerável e expostos à internet são alvo natural de recrutamento automatizado em botnet — usada para DDoS, mineração, proxy de tráfego malicioso ou como ponto de apoio persistente dentro da rede do cliente. Mas o gateway comprometido não é o objetivo final do atacante sofisticado: é o trampolim. A partir dele, o adversário enumera a rede industrial, descobre PLCs falando Modbus sem autenticação (o protocolo não tem autenticação nativa), mapeia o SCADA e ganha capacidade de manipular o processo. Quando a rede do dispositivo IIoT está plana com a rede de controle, o pivô IoT-OT é trivial — e a segmentação correta é a diferença entre um incidente contido em um dispositivo e um incidente que para uma planta inteira.

Pentest de firmware e de protocolo: ver o que o scanner não vê

Scanner de rede e teste de aplicação web não enxergam o que importa em IIoT. A segurança real do dispositivo está dentro do binário do firmware, na implementação do protocolo industrial e na arquitetura física do hardware. Por isso a Decripte conduz pentest dedicado de firmware e de protocolo IoT, combinando análise estática e dinâmica com teste sobre o hardware real.

O resultado não é uma lista genérica de findings. É um diagnóstico priorizado por impacto real: quais falhas permitem comprometimento remoto sem acesso físico, quais permitem comprometer a frota inteira a partir de um dispositivo, e quais abrem o pivô para o OT do cliente. Cada achado vem com prova de conceito e com o caminho de remediação no firmware e na arquitetura — para que a correção entre no ciclo de desenvolvimento e não dependa de um patch heroico em campo.

Segurança OT/ICS: segmentar o caminho IoT-OT

Auditar o firmware fecha a porta da frente. Segmentar a rede garante que, mesmo se uma porta ceder, o estrago fique contido. A premissa central da Segurança OT/ICS da Decripte é simples de enunciar e difícil de implementar bem: nenhum gateway IIoT comprometido deve conseguir alcançar diretamente um PLC ou um SCADA. Para isso aplicamos o modelo de zonas e condutos da norma IEC 62443, a referência internacional para segurança de sistemas de automação e controle industrial.

Na prática, isso se traduz em uma arquitetura de camadas inspirada no modelo Purdue: a telemetria e o controle do dispositivo IIoT passam por uma DMZ industrial; os dispositivos de campo vivem em zonas segmentadas com condutos explicitamente definidos entre elas; o tráfego entre IoT e OT é mediado por firewalls com inspeção de protocolo industrial (capazes de entender e filtrar Modbus, OPC-UA); e a comunicação norte-sul (dispositivo para nuvem) é separada da comunicação leste-oeste (dispositivo para controlador). Um gateway que vira parte de uma botnet pode até gerar tráfego de saída — mas não consegue falar Modbus com o PLC porque o conduto simplesmente não existe.

SOC 24x7: vigilância sobre a frota e o caminho industrial

Firmware blindado e rede segmentada reduzem drasticamente a superfície de ataque, mas não eliminam o risco residual. Dispositivos de campo são numerosos, distribuídos e operam sem supervisão humana. Por isso o SOC 24x7 da Decripte mantém vigilância contínua sobre a telemetria da frota e sobre o caminho IoT-OT, correlacionando sinais que isoladamente parecem ruído e juntos denunciam um comprometimento.

O que o SOC observa em um ambiente IIoT: padrões de beaconing (dispositivos chamando endereços externos em intervalos regulares, assinatura típica de comunicação com servidor de comando e controle); volume e destino anômalos de tráfego de saída (sinal de recrutamento em botnet ou exfiltração); tentativas de enumeração e varredura partindo de um dispositivo de campo em direção à rede de controle; falhas de autenticação mTLS em massa; e comandos de atuação que fogem do baseline operacional. Cada um desses sinais dispara investigação, e quando confirmado, aciona a esteira de resposta a incidentes.

Resposta a incidentes em OT: contenção sem parar a produção

Responder a um incidente em ambiente industrial exige uma disciplina que a resposta a incidentes de TI tradicional não tem. Em TI, a reação instintiva é isolar e derrubar o ativo comprometido. Em OT, derrubar o ativo errado pode parar uma linha de produção, danificar equipamento ou criar condição insegura. A contenção precisa ser cirúrgica e ciente do processo físico que está por trás do dispositivo.

A Resposta a Incidentes da Decripte para IIoT parte de um princípio: conter o adversário preservando, sempre que possível, a continuidade operacional do cliente. Isso significa cortar o caminho do atacante — revogar a identidade do dispositivo, bloquear o conduto IoT-OT, derrubar o canal C2 — sem necessariamente desligar abruptamente um equipamento que está atuando sobre um processo físico em andamento. Onde o desligamento é inevitável, ele é coordenado com a equipe de operação do cliente, em janela controlada, com plano de recuperação já definido.

Conformidade e governança da telemetria operacional

A telemetria que um fabricante de IIoT coleta pode incluir dados que merecem tratamento sob a LGPD — desde identificadores de operadores e padrões de turno até informações que, combinadas, revelam comportamento de pessoas. A Decripte estrutura o tratamento desses dados de forma alinhada à LGPD e às orientações da ANPD: base legal definida, minimização de coleta, retenção justificada e segurança no armazenamento e no trânsito. Para o cliente industrial, isso significa que o fornecedor de IIoT não é um passivo de conformidade, mas um parceiro que entende e respeita o regime de dados.

Além da LGPD, fabricantes que vendem para indústrias reguladas (energia, água, óleo e gás, manufatura crítica) enfrentam exigências contratuais de segurança cada vez mais rigorosas. Conseguir demonstrar alinhamento ao modelo da IEC 62443, manter relatórios de pentest de firmware atualizados e operar um SOC com SLA de resposta deixa de ser diferencial e vira requisito de venda. A Decripte ajuda o fabricante a construir e evidenciar essa postura — que se converte diretamente em capacidade comercial.

Como começar a fechar sua exposição hoje

O primeiro passo não exige contrato nem compromisso. O plano gratuito de Gestão de Ameaças da Decripte, em decripte.com.br/intelligence-center, faz um diagnóstico inicial da sua exposição externa — o que da sua frota e da sua plataforma está visível e atacável a partir da internet. É o ponto de partida para entender o tamanho real do problema antes de decidir onde investir.

A partir do diagnóstico, a evolução natural combina Pentest de firmware e protocolo para descobrir as falhas profundas, Segurança OT/ICS para segmentar o caminho IoT-OT, e SOC 24x7 com Resposta a Incidentes para vigiar e reagir. Os planos pagos estão em decripte.io/planos, e cada um se justifica por uma camada específica do risco IIoT.

Exemplo real descaracterizado: gateways de um fabricante de IIoT recrutados em botnet com pivô para o OT do cliente

Como a Decripte responde a um incidente de IIoT

Resposta a incidentes em ambiente industrial precisa neutralizar o adversário sem provocar dano físico ou parada de produção. A esteira da Decripte para IIoT é desenhada para isso: cirúrgica, ciente do processo e rápida.

1. Detectar por correlação no SOC 24x7: beaconing simultâneo, tráfego de saída anômalo, enumeração da rede de controle e falhas de autenticação em massa são unidos em um diagnóstico, não tratados como alertas soltos.
2. Confirmar o vetor e o alcance: a equipe estabelece como o dispositivo foi comprometido (firmware, credencial, interface exposta) e se o pivô para o OT já começou, priorizando as plantas em risco real.
3. Conter de forma cirúrgica em até 1h: revogar a identidade do dispositivo (mTLS), cortar o canal de comando e controle e bloquear o conduto IoT-OT, preservando a continuidade operacional sempre que possível.
4. Coordenar com a operação do cliente: onde o desligamento de equipamento é inevitável, ele acontece em janela controlada, com a equipe de chão de fábrica e plano de recuperação definido.
5. Erradicar a raiz: auditar o firmware comprometido, identificar a falha de origem e definir a correção (credenciais únicas, Secure Boot, update assinado, fechamento de interfaces).
6. Recuperar com hardening: reprovisionar dispositivos com identidade forte, resegmentar a rede pela IEC 62443 e validar que nenhum PLC ou SCADA foi alterado antes de retomar a produção.
7. Consolidar lições: incorporar pentest recorrente, identidade por dispositivo como padrão e monitoramento contínuo da frota, fechando o ciclo para que o mesmo vetor não se repita.

Como a Decripte estrutura a segurança de um fabricante de IIoT

Responder bem a um incidente é necessário, mas o objetivo é precisar responder cada vez menos. A Decripte constrói uma base que reduz a superfície de ataque do dispositivo, contém o estrago por arquitetura e mantém vigilância contínua sobre a frota e o caminho industrial.

Recommended plans for IoT Industrial (IIoT)

Frequently asked questions

Sector terms

IIoT (IoT Industrial)

Internet das Coisas aplicada à indústria: sensores, gateways e dispositivos de campo que conectam máquinas e processos físicos a plataformas de telemetria e controle, normalmente ligando o chão de fábrica (OT) à nuvem.

OT (Tecnologia Operacional)

Sistemas que monitoram e controlam processos físicos industriais — PLCs, SCADA, sistemas de supervisão. Diferente da TI, uma falha em OT pode causar parada de produção, dano a equipamento ou condição insegura.

Pivô IoT-OT

Técnica em que o atacante compromete um dispositivo IIoT e o usa como trampolim para alcançar a rede de controle industrial do cliente, manipulando PLCs e o SCADA a partir do gateway comprometido.

IEC 62443

Norma internacional para segurança de sistemas de automação e controle industrial. Define, entre outros conceitos, o modelo de zonas e condutos usado para segmentar redes OT e isolar o caminho entre dispositivos e controladores.

mTLS (TLS mútuo)

Autenticação em que cliente e servidor apresentam certificados, garantindo identidade forte por dispositivo. Em IIoT, permite que cada gateway tenha credencial única e revogável, em vez de uma chave compartilhada por toda a frota.

Secure Boot

Mecanismo que garante que o dispositivo só execute firmware autêntico e assinado digitalmente, impedindo que um atacante substitua a imagem por código malicioso na memória flash do equipamento.