Definição e Tipos (IP, Domínio, Hash, URL, Email, Certificados)

Nota de abertura do subcapítulo de IOCs no capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Define formalmente o IOC (Indicator of Compromise), decompõe a taxonomia de tipos e mostra onde cada tipo vale mais e onde envelhece rápido.
Dialoga com as notas de ciclo de vida, pontuação de qualidade e contextualização, e prepara o contraste com IOA e IOB.

1. Contexto e Posicionamento na Biblioteca

O IOC (Indicator of Compromise, indicador de comprometimento) é a menor unidade operacional da inteligência de ameaças técnica: um artefato observável, vinculado a atividade maliciosa confirmada ou fortemente suspeita, que pode ser procurado ou bloqueado em telemetria. Toda a esteira tática da biblioteca depende desse objeto, desde a coleta de dados no capítulo 02 até o hunting guiado por inteligência do capítulo 10. Sem uma compreensão precisa do que é e do que não é um IOC, as equipes acumulam listas de valores soltos que não suportam decisão operacional alguma.

Esta nota estabelece o vocabulário comum para as notas seguintes do subcapítulo. O ciclo de vida explica como um IOC nasce, é validado, enriquecido e expira; a pontuação de qualidade define quão confiável ele é; a contextualização transforma o valor bruto em inteligência acionável; e as plataformas descrevem onde ele vive operacionalmente. As notas de IOA e IOB, por sua vez, complementam o IOC com dimensões de ataque e de comportamento que sobrevivem melhor à rotação de infraestrutura do adversário.

2. Definição Formal e Propriedades do IOC

Formalmente, um IOC é um artefato forense, digital, cuja presença em um sistema ou rede indica, com alta probabilidade, um comprometimento em curso ou passado. A definição carrega dois requisitos que costumam ser ignorados no dia a dia. Primeiro, a condição de observabilidade: o artefato precisa ser detectável por alguma telemetria disponível, como logs de proxy, eventos de endpoint, telemetria DNS ou fluxos de rede. Segundo, a condição de vínculo com atividade maliciosa: o mesmo valor observado em contexto benigno não é um IOC, é apenas um dado sem significado.

Um valor isolado não é um IOC completo; é um observável. Essa distinção é central no STIX 2.1, que modela o observável como a característica técnica (um endereço IP, um hash de arquivo) e o indicador como a afirmação contextual sobre esse observável, incluindo padrão de detecção, janela de validade e nível de confiança. Quando um analista copia um domínio de um relatório sem registrar a origem, a época e a confiança, ele produz um observável morto, não um indicador.

Vale fixar também a fronteira com os vizinhos do capítulo. O IOA descreve a intenção e a progressão do ataque antes do impacto, como um processo do Office invocando PowerShell; o IOB descreve a assinatura comportamental de um conjunto de ações, como beaconing com intervalo estável; o IOE (Indicator of Exposure) descreve a exposição do ambiente que o adversário pode explorar. O IOC responde à pergunta o observou-se de malicioso aqui; os outros três respondem a como o ataque opera e onde estamos vulneráveis. Essa divisão orienta a escolha de telemetria e de ferramenta em cada caso.

Todo IOC maduro carrega um conjunto mínimo de propriedades, detalhado na nota de contextualização deste subcapítulo:

• Valor e tipo: o conteúdo técnico propriamente dito, como um endereço IPv4 ou um hash SHA-256, normalizado em minúsculas e sem decoração.
• Contexto de origem: fonte que observou ou publicou o indicador, data e hora da observação e campanha ou incidente associado.
• Semântica de uso: o papel do artefato na cadeia de ataque, como C2, staging de payload, exfiltração ou entrega de phishing.
• Gestão temporal: data de primeiro e último visto, janela de validade e política de expiração compatível com a volatilidade do tipo.
• Governança: TLP 2.0, confiança e pontuação, que determinam se o indicador pode circular internamente e ser compartilhado externamente.

A correspondência entre propriedades conceituais e campos do STIX 2.1 ajuda a padronizar a troca entre plataformas, tema da nota de plataformas deste subcapítulo. A tabela abaixo mapeia cada propriedade ao campo típico do objeto indicator.

3. Taxonomia de Tipos de IOC

A tabela abaixo organiza os tipos clássicos de IOC, com exemplo concreto, volatilidade relativa e posição aproximada na Pirâmide de Dor, do capítulo 04. Quanto mais alto o degrau da pirâmide, mais dor o indicador causa ao adversário quando você o detecta, e mais tempo ele permanece útil.

Antes de classificar, normalize. Cada tipo tem regra de canonização própria que evita falsos negativos por diferença de formato: IPs sem zeros à esquerda e sem porta anexada; domínios em minúsculas, sem ponto final e em forma unicode normalizada; hashes em minúsculas e sem prefixos de algoritmo; URLs com esquema reconstruído e query preservada; e endereços de e-mail com o local em maiúsculas preservado, já que esse trecho é sensível a caixa em alguns provedores. A normalização é o primeiro passo do ciclo de vida detalhado na próxima nota, e errar aqui contamina deduplicação, correlação e retrohunt.

antes:  hxxp://cdn-metrics-sync[.]example/p/upd.php
depois: http://cdn-metrics-sync.example/p/upd.php

antes:  203.0.113.47:443
depois: valor 203.0.113.47 com porta 443 registrada em campo separado

antes:  275A021BBFB6489E54D471899F7DB9D1663FC695EC2FE2A2C4538AABF651FD0F
depois: 275a021bbfb6489e54d471899f7db9d1663fc695ec2fe2a2c4538aabf651fd0f

3.1 Endereços IP

O IP é o tipo mais abundante e o mais volátil de IOC de rede. Ele brilha em cenários de C2 dedicado e de exfiltração, quando o adversário aluga servidores para uma campanha específica e o endereço não serve a mais ninguém. Nesses casos, bloqueio no firewall e detecção no proxy têm efeito imediato. O tipo envelhece mal por três razões: reatribuição dinâmica em provedores de nuvem, uso de CDNs e hosts compartilhados, e takedown rápido por provedores de hospedagem. Um IP publicado em feed hoje pode hospedar um negócio legítimo em dez dias, gerando falso positivo caro.

3.2 Domínios e Subdomínios

Domínios carregam mais contexto que IPs, porque o registro fica documentado no WHOIS e a resolução pode ser rastreada em passive DNS. Eles brilham em detecção de C2, de infraestrutura DGA (domain generation algorithm) e de phishing, especialmente quando combinados com idade de registro baixa e padrões de typo ou homoglifo. Envelhecem mal quando o adversário usa serviços de subdomínio compartilhado, no qual o mesmo hostname legítimo serve dezenas de campanhas, e quando o domínio é derrubado e depois reaproveitado por resposta a incidentes de terceiros.

3.3 Hashes de Arquivo

O hash é o IOC mais estável e o mais fácil de operar: SHA-256 e MD5 do payload identificado permitem bloqueio por EDR, triagem em sandbox e retrohunt em telemetria histórica. Os comprimentos canônicos facilitam a validação sintática: 32 dígitos hexadecimais para MD5, 40 para SHA-1 e 64 para SHA-256, em minúsculas. Ele brilha em campanhas com binários pouco variados e em respostas a incidentes, onde fixa a linha do tempo forense. Envelhece mal contra ferramentas que empacotam, compilam ou assinam cada amostra de forma única, prática comum em ransomware como serviço e em loaders de acesso inicial, que geram hashes novos por vítima. Por isso, o hash deve vir acompanhado de detecção mais forte, como regras YARA sobre famílias, detalhada no capítulo 18.

3.4 URLs e Artefatos de Rede

A URL identifica o caminho exato do payload ou do painel de C2 e é o tipo mais granular e mais fugaz da taxonomia. Ela brilha em detecção de entrega de phishing e de download de segunda etapa, quando o padrão de caminho, por exemplo /p/upd.php, revela o kit de ferramentas do adversário. Envelhece em horas, porque staging é derrubado quase imediatamente após a campanha. O uso correto é em retrohunt curto e em correlação de campanha, nunca em bloqueio estático de longo prazo. Artefatos de rede complementares, como impressões digitais TLS do tipo JA3 e JA3S, cabeçalhos HTTP exóticos e strings de User-Agent fixas de RATs, funcionam como IOCs fracos por si sós e fortes quando combinados a outros sinais. Esses artefatos derivados ocupam uma zona intermediária entre IOC e comportamento: mudam com a versão da biblioteca usada pelo malware, mas sobrevivem bem durante o ciclo de vida de uma família específica.

Uma prática útil é registrar a URL sempre em duas formas: a forma observada completa, para retrohunt exato, e a forma raiz com esquema e host, para correlação de campanha. Essa dupla representação evita o erro comum de considerar comprometido um host inteiro porque uma URL específica dele entregou payload.

3.5 E-mail e Artefatos de Phishing

Endereços de remetente, domínios de Message-ID, padrões de assunto e hashes de anexo formam o conjunto de IOCs de e-mail. Eles brilham na caça a campanhas de phishing e BEC (Business Email Compromise), porque o adversário reutiliza identidades e infraestrutura de envio por dias ou semanas. O remetente envelhece com a rotação de contas comprometidas; o assunto envelhece com a mudança de tema da campanha, embora sobreviva dentro da janela da onda; o anexo, via hash, herda a estabilidade do tipo hash. Domínios de resposta automática e cabeçalhos de rastreio (tracking pixels) são artefatos adicionais de alta valia para mapear a campanha.

3.6 Certificados Digitais

O certificado TLS usado pelo C2 ou pelo painel de phishing é um IOC subestimado. O fingerprint SHA-256 do certificado, o serial, o emissor e a combinação de domínio com issuer gratuito, por exemplo via Let's Encrypt em infraestrutura recém-registrada, permitem detecção tanto no proxy quanto no monitoramento de Certificate Transparency. Esse monitoramento tem um bônus operacional: os logs públicos de CT entregam o certificado no instante da emissão, muitas vezes dias antes do primeiro tráfego malicioso observado, o que cria janela proativa de bloqueio. O tipo brilha contra adversários que operam painéis de C2 com TLS próprio, comum em RATs modernos. Envelhece conforme o ciclo de renovação: certificados gratuitos de 90 dias forçam rotação, enquanto certificados comprados para domínio dedicado podem durar o ano inteiro da operação.

3.7 Artefatos de Host: Mutex, Registry e Nomes

Artefatos de host são IOCs que a própria amostra deixa na máquina: mutex de execução única, chaves de autorun, nomes de serviço, arquivos de configuração e caminhos fixos. Eles brilham em hunting de endpoint e em correções de cobertura, porque sobrevivem à reinfecção da mesma versão e raramente aparecem em ambientes legítimos. Um mutex global, por exemplo, é um artefato quase exclusivo de código malicioso, já que software legítimo raramente precisa desse mecanismo entre hosts. Envelhecem quando o malware é recompilado ou o operador muda a configuração, e por isso são fortes dentro da versão e fracos entre versões.

4. Exemplo Estruturado em STIX 2.1

O exemplo abaixo mostra um IOC de domínio em STIX 2.1, com contexto, validade e confiança explícitos. Repare que a diferença entre este objeto e uma linha em texto plano está exatamente nas propriedades da seção 2.

Três detalhes merecem atenção operacional. O campo pattern aceita outras linguagens além do padrão STIX, com pattern_type igual a sigma ou pcre, o que permite levar detecções comportamentais curtas junto do indicador. A janela valid_from a valid_until materializa a política de expiração no nível do objeto, e plataformas compatíveis deixam de exportar o indicador após o limite. O campo confidence, de 0 a 100, é a âncora que a nota de pontuação de qualidade vai decompor em confiabilidade da fonte, corroboração e idade.

{
  "type": "indicator",
  "spec_version": "2.1",
  "id": "indicator--7d6a1f9e-2c8b-4f3a-9a5d-6e1b0c4d8f22",
  "created": "2025-03-14T08:30:00.000Z",
  "modified": "2025-03-14T08:30:00.000Z",
  "name": "Dominio de C2 da campanha Tarja-2025-03",
  "description": "Dominio registrado em 2025-03-11 e usado como canal C2 de backdoor em fase de instalacao. Observado em proxy e em sandbox.",
  "indicator_types": ["malicious-activity"],
  "pattern": "[ domain-name:value = 'cdn-metrics-sync.example' ]",
  "pattern_type": "stix",
  "valid_from": "2025-03-11T00:00:00.000Z",
  "valid_until": "2025-06-11T00:00:00.000Z",
  "confidence": 85,
  "labels": ["c2", "backdoor", "tlp:amber"]
}

5. Onde Cada Tipo Brilha e Onde Envelhece Mal

A tabela consolida a decisão prática de quando usar cada tipo em detecção ativa, hunting ou contexto, evitando que o feed inteiro seja despejado uniformemente no SIEM.

Nenhum tipo deve ser avaliado isoladamente quando o objetivo é inteligência de campanha. A combinação de um hash com o IP que o distribuiu, o domínio que o entregou e o certificado que protegeu o canal produz um cluster muito mais difícil de substituir pelo adversário do que qualquer peça sozinha. É exatamente esse agrupamento que a nota de compartilhamento e as técnicas de clustering, no controle TH.9 da seção 15, exploram para revelar infraestrutura antes de ela ser reutilizada.

6. Erros Comuns e Pontos de Atenção

Os erros abaixo concentram a maioria dos problemas de qualidade observados em operações de CTI quando o tema é a natureza dos indicadores.

• Tratar todo valor extraído como IOC permanente, despejando URLs e IPs efêmeros em detecção de longo prazo; o correto é classificar por tipo e aplicar política de expiração proporcional.
• Copiar indicadores de relatório sem normalização, mantendo defanging como hxxp e colchetes; o pipeline de ingestão deve desfazer a máscara antes de qualquer busca.
• Usar hash MD5 sozinho como identidade do arquivo; MD5 é colidível, então o mínimo aceitável é SHA-256, com MD5 apenas para cruzamento com fontes antigas.
• Publicar IOCs de e-mail com remetente legítimo comprometido sem marcação TLP adequada, expondo dados pessoais de terceiros em violação à LGPD.
• Ignorar artefatos de host, como mutex e chaves de registry, que oferecem detecção barata e de altíssima especificidade dentro da versão do malware.
• Confundir observável com indicador, gerando bases gigantescas sem contexto; a nota de contextualização deste subcapítulo trata exatamente desse gate.
• Assumir que certificado gratuito significa malicioso, quando o emissor gratuito é usado pela maioria da web; o sinal relevante é a combinação de emissor gratuito com domínio recém-registrado e padrão de infraestrutura suspeito.
• Esquecer que defanging tem variações, como hxxp, [. ] e domínio[.]com, e construir parser que reconhece apenas um formato; a normalização deve cobrir as variantes conhecidas antes da deduplicação.
• Usar a notação de máscara em contexto de busca sem desfazê-la, o que retorna zero resultados; a regra operacional é mascarar apenas no texto humano e manter valor cru no pipeline e nas plataformas.

7. Integração com o Restante da Biblioteca

A taxonomia desta nota alimenta diretamente o ciclo de vida, que define TTLs por tipo, e a pontuação de qualidade, que pondera a idade de cada classe de indicador de forma diferente. A nota de contextualização e validação usa a condição de observabilidade daqui como critério operacional de gate antes da publicação. No capítulo 04, a Pirâmide de Dor dá a moldura estratégica para decidir em quais tipos investir esforço de detecção. Na seção 15, os controles PLT.1 e PLT.2 operacionalizam armazenamento e distribuição, o TH.10 executa hunting baseado em IOC e o SIM.4 testa se as detecções criadas a partir desses indicadores realmente disparam. O próximo passo de leitura é a nota de ciclo de vida, que mostra como cada tipo nasce, matura e morre na plataforma.