IOE - Indicadores de Exposição

Quarta família de indicadores do capítulo 03, deslocando o foco do comprometimento consumado para a condição que o viabiliza.
O IOE registra o que o adversário enxerga antes de agir: serviços expostos, configurações incorretas e versões vulneráveis na superfície de ataque.
Dialoga com as notas de IOC deste capítulo, com o comparativo das famílias e com os temas de EASM e CTEM do capítulo 21.

1. Contexto e Posicionamento na Biblioteca

O capítulo 03 constrói um conjunto de linguagens para descrever a ameaça. O IOC (Indicator of Compromise, indicador de comprometimento) é evidência técnica de um evento que já aconteceu, o IOA (Indicator of Attack) observa comportamento em progresso e o IOB (Indicator of Behavior) descreve desvios da linha de base interna. O IOE (Indicator of Exposure, indicador de exposição) completa o conjunto invertendo o ponto de vista: em vez de observar o adversário, observa o que a própria organização oferece a ele. É a única família de indicadores que existe plenamente antes do primeiro acesso do invasor, e por isso concentra o maior potencial preventivo do capítulo.

No mapa da biblioteca, esta nota é a ponte entre o estudo de indicadores e a gestão de exposição. Ela alimenta o fluxo do controle INT.4 da seção 15, que converte exposição em hipótese de hunting, usa o vocabulário de EASM e CTEM aprofundado no capítulo 21 e se apoia na ideia de superfície de ataque externa apresentada nas fontes de coleta do capítulo 02. O objetivo prático é que o leitor saia daqui capaz de classificar um achado como exposição, priorizá-lo com critérios objetivos e transformá-lo em correção validada ou em detecção permanente.

2. O Conceito de Indicador de Exposição

Um IOE é qualquer característica observável da infraestrutura, do código ou da configuração que aumenta a probabilidade ou o impacto de um comprometimento, independentemente de existir um adversário explorando-a neste momento. A diferença conceitual central é simples de enunciar e profunda nas consequências: IOC é evidência de evento, IOA é evidência de etapa, IOE é evidência de condição. Uma condição é mais estável que um evento, então o IOE envelhece devagar e justifica investimento estrutural de correção, e não apenas triagem operacional.

É um erro comum reduzir IOE à saída do scanner de vulnerabilidades. A vulnerabilidade de software é apenas uma das classes; um bucket aberto sem CVE alguma, um subdomínio órfão, uma política DMARC inexistente e uma credencial publicada em repositório são exposições igualmente acionáveis. O ciclo de vida também difere: o IOC é procurado, casado com telemetria e respondido, enquanto o IOE é descoberto, priorizado, corrigido e revalidado, num ciclo que pertence tanto à engenharia quanto ao SOC.

Há também uma leitura do IOE pelo lado do adversário: as técnicas de reconhecimento e de desenvolvimento de recursos do MITRE ATT&CK, como varredura ativa de vítimas, coleta de identidade de vítima e aquisição de infraestrutura, descrevem exatamente o ato de mapear e colher exposições. Toda técnica de reconhecimento executada com sucesso contra a organização produz um IOE como subproduto, o que significa que a lista de exposições corrigidas é, ao mesmo tempo, uma medida de quantas etapas de reconhecimento o adversário concluiu com sucesso no período.

3. A Superfície Exposta como Sinal

A superfície de ataque externa é o conjunto de ativos alcançáveis da internet, incluídos aqueles que a organização esqueceu: ambientes de teste, subdomínios criados em campanhas passadas, servidores migrados sem desativação formal. O adversário não diferencia ativo governado de ativo órfão; ele varre faixas de endereços, consulta logs de Certificate Transparency e usa motores de busca de dispositivos da mesma forma que o defensor deveria. Nesse sentido, o IOE é a unidade atômica do achado de EASM (External Attack Surface Management): cada descoberta observável, endereçável e rastreável ao longo do tempo.

A coleta dessa superfície combina fontes de custo baixo e cobertura alta. Os logs de Certificate Transparency expõem cada certificado emitido para os domínios da marca, incluindo subdomínios que nunca entraram no inventário; a resolução sistemática de todos os subdomínios conhecidos revela apontamentos para recursos que não existem mais; e os motores de busca de dispositivos, quando consultados com o nome da organização, devolvem serviços que a rede interna desconhece. Monitorar marca em registros de domínios recém-criados fecha o quadro, porque a campanha de phishing quase sempre começa com um domínio parecido registrado na véspera.

O IOE também existe dentro do perímetro, e ignorar essa camada é armadilha frequente. Consoles de administração acessíveis da rede de estações, dispositivos OT com portas abertas entre VLANs e VPNs sem MFA são exposições que o adversário explora depois de obter o primeiro acesso. A gestão de exposição contínua, o CTEM (Continuous Threat Exposure Management), institucionaliza esse cuidado com o ciclo de escopo, descoberta, priorização, validação e mobilização, e o IOE é o dado bruto que atravessa todas as etapas.

4. Taxonomia de Exposições

Um mesmo ativo costuma produzir vários IOEs encadeados, e essa sobreposição é informativa. Um subdomínio órfão com certificado emitido e apontando para provedor de hospedagem gratuito soma três sinais que, isolados, seriam triviais e, juntos, configuram preparação de campanha de phishing contra a marca. O inventário de exposição deve guardar a categoria, a evidência e a data de descoberta de cada item, porque a correção sem registro impede a revalidação e a métrica de redução de exposição ao longo do tempo.

5. Exemplos Práticos de Identificação

# Servico de administracao remota publicado na borda
nmap -p 3389,22,445 --open 203.0.113.0/24

# Bucket de objetos com acesso anonimo habilitado
aws s3 ls s3://backup-financeiro-corp --no-sign-request

# Politica de e-mail do dominio auditada por DNS
dig +short TXT empresa.com.br
dig +short TXT _dmarc.empresa.com.br

# Consultas ilustrativas em motores de busca de dispositivos
port:3389 org:"Empresa Exemplo LTDA"
product:"Apache httpd 2.4.49"
ssl.cert.subject.CN:"portal.empresa.com.br"

A leitura dos resultados precisa produzir evidência, não apenas impressão. Cada linha retornada deve gerar um registro com endereço, serviço, versão, data e captura, porque a discussão com a equipe responsável pelo ativo fica objetiva com evidência em mãos. Consultas como as do segundo bloco também servem de rotina agendada: rodar a mesma query semanalmente e comparar o delta é a forma mais barata de descobrir que um ambiente novo subiu exposto na sexta-feira e ainda está aberto na segunda.

A rotina mínima de descoberta externa cabe em um checklist semanal, executável inclusive com automação simples:

• Resolver todos os subdomínios conhecidos da marca e comparar com o inventário, marcando apontamentos para recursos inexistentes como candidatos a takeover.
• Consultar os logs de Certificate Transparency em busca de certificados emitidos com o nome da marca, separando emissões legítimas de domínios parecidos criados em janelas de campanha.
• Varrer as faixas de endereço públicas da organização nas portas de gerência, comparando com o resultado da semana anterior para capturar o delta.
• Executar as consultas salvas no motor de busca de dispositivos e registrar novos serviços que citam a organização em organização, ASN ou certificado.
• Revisar novos registros de domínios parecidos com a marca, com atenção a TLDs baratos e a registros com privacy proxy recém-ativado.

6. Relação com EASM e CTEM

Programas de EASM industrializam a coleta de IOE com varredura contínua, resolução de certificados e correlação com inventário, transformando descoberta esporádica em telemetria permanente. O CTEM organiza o que fazer com essa telemetria: definir escopo por risco de negócio, descobrir continuamente, priorizar com contexto de exploração e adversário, validar hipóteses de exploração e mobilizar as equipes para a correção. CTI entra nas etapas de priorização e validação, porque exposição sem contexto de quem explora aquilo é ruído priorizado de forma aleatória.

A história recente mostra que o adversário escolhe exposição de forma sistemática. A exploração em massa do Citrix ADC na CVE-2019-19781 e do Fortinet na CVE-2018-13379, que expunha credenciais de VPN em configurações legíveis, virou porta de entrada padrão de operações de ransomware. Grupos como LockBit e ALPHV estruturaram suas operações sobre acesso inicial barato a aparelhos de borda desatualizados, e o Scattered Spider complementa o quadro atacando identidade e help desk. Para o defensor, isso significa que IOE de aparelho de borda desatualizado pesa mais que a média, independentemente do CVSS nominal.

7. Priorização de Correção

Priorizar por severidade de CVE isolada produz fila desalinhada do risco real. O modelo recomendado combina quatro critérios, com pesos que cada organização calibra, e a soma produz uma pontuação de 0 a 100 que ordena a fila de correção e dá argumento objetivo para prazo por item.

ioe:
  id: IOE-2025-0142
  descoberto_em: 2025-06-10
  ativo: portal.parceiros.empresa.com.br
  tipo: versao-vulneravel
  evidencia: "Apache httpd 2.4.49 em banner HTTP"
  criterios:
    exposicao: 35        # alcançavel da internet
    explorabilidade: 30  # CVE-2021-41773 com exploit publico e EPSS alta
    criticidade: 20      # portal de parceiros com dados de terceiros
    adversario: 10       # vetores equivalentes usados por ransomware
  pontuacao: 95
  destino: remedicao-imediata
  verificacao: revarredura em 72 horas

A validação do IOE, etapa em que o CTEM mais se diferencia de um relatório de scanner, consiste em provar que a exposição é explorável no contexto da organização. Uma traversal de diretório confirmada com requisição controlada que recupera apenas um arquivo inofensivo vale mais que dez alertas teóricos, e a demonstração segura de acesso anônimo a bucket, lida sem baixar conteúdo sensível, encerra a discussão sobre prioridade. Ferramentas de BAS (Breach and Attack Simulation) e o próprio purple team executam essas validações com contenção, e o resultado entra na ficha do IOE como evidência de explorabilidade confirmada.

O destino do IOE priorizado também passa pelo TIP e pelo SIEM: exposição confirmada e ainda não corrigida deve entrar em watchlist, para que qualquer interação anômala com aquele ativo durante a janela de risco dispare prioridade alta na triagem. A regra prática é que, enquanto a porta existe, o defensor precisa estar olhando para ela, e a automação é o único jeito sustentável de manter esse olhar em escala.

A correção só termina na revalidação: a revarredura do ativo corrigido, com a mesma consulta que o descobriu, é o que transforma tarefa fechada em exposição eliminada. Duas métricas consolidam o programa: o tempo médio de correção por classe de IOE e a proporção de itens revalidados com sucesso no primeiro ciclo. Sem essas métricas, o inventário cresce mais rápido que a correção e vira lista de vergonha em vez de programa.

8. Erros Comuns e Pontos de Atenção

• Reduzir IOE à saída do scanner de vulnerabilidades: o scanner não cobre ativos órfãos, política de e-mail, credenciais vazadas nem certificados irregulares; o inventário de exposição é mais amplo que a base de CVEs.
• Corrigir sem revalidar: tarefa fechada no ticket não é exposição eliminada; a revarredura com a consulta original é parte da correção, não etapa opcional.
• Tratar descoberta como evento único: a superfície muda a cada deploy e a cada contratação de fornecedor; descoberta é processo contínuo com cadência semanal, não projeto pontual.
• Silenciar a equipe de origem: exposição tratada como culpa produz esconde-jeito e inventário desonesto; o modelo de trabalho é risco compartilhado, com prazo negociado e evidência clara.
• Ignorar a exposição interna: nuvem entre contas, OT e consoles administrativas dentro do perímetro são IOE com o mesmo formato de registro e priorização.

9. Integração com o Restante da Biblioteca

As conexões diretas com o restante da biblioteca seguem quatro caminhos:

• Capítulo 02: as fontes de coleta de superfície externa, CT logs e motores de busca de dispositivos são as produtoras primárias de IOE.
• Capítulo 08: a hipótese derivada de exposição é executada como hunt orientado por inteligência, com a mesma anatomia de qualquer outra hipótese.
• Capítulo 21: EASM e CTEM aprofundam o ciclo de escopo, priorização e validação aqui resumido.
• Seção 15: INT.3 correlaciona exposição com campanha ativa, INT.4 converte IOE em hunt e o grupo MET mede o tempo de exposição.

O IOE fecha o ciclo com as demais famílias do capítulo: a exposição descoberta vira hipótese de hunting pelo fluxo do INT.4, e o comportamento observado enquanto a porta está aberta alimenta IOA e IOC. Um RDP exposto sem MFA, por exemplo, gera a hipótese verificável de força bruta seguida de sucesso, com consulta direta na telemetria de autenticação.

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4625 and LogonType in (3, 10)
| summarize falhas = count() by IpAddress
| where falhas > 20
| join kind=inner (
    SecurityEvent
    | where EventID == 4624 and LogonType in (3, 10)
) on IpAddress
| project TimeGenerated, Computer, IpAddress, TargetUserName

O princípio que amarra o ciclo é o alarme da porta corrigida: toda exposição remediada deve deixar uma detecção correspondente para trás, porque a mesma configuração errada tende a reaparecer em outro ativo e o adversário volta a tentar o caminho que já funcionou. A proporção de IOEs convertidos em hipótese testada e em regra de detecção é a métrica que mede se o capítulo inteiro está funcionando como sistema, e não como coleção de listas isoladas.