Os dois frameworks anteriores descrevem o ataque como processo — uma sequência de fases ou de comportamentos. O Diamond Model muda o ângulo: em vez de perguntar "que passos o atacante deu?", ele pergunta "quais são os elementos de um evento de intrusão e como eles se relacionam?". É um modelo analítico, nascido na comunidade de inteligência de ameaças, e sua força é conectar peças aparentemente soltas de um incidente numa imagem coerente do adversário. Fecha nosso trio de lentes: Kill Chain (fases), ATT&CK (comportamentos) e Diamond (relações).

Quatro vértices que se puxam

O modelo se chama "diamante" porque desenha quatro vértices interligados. No topo, o adversário — quem está atacando. Na base, a vítima — quem é atacado. À esquerda, a capacidade — as ferramentas e técnicas usadas (um malware, um exploit, uma técnica de phishing). À direita, a infraestrutura — os recursos físicos e lógicos que sustentam o ataque (servidores de comando e controle, domínios, endereços IP, contas de e-mail). A ideia central e poderosa é que esses quatro vértices estão conectados, e descobrir um deles frequentemente te leva aos outros. Se você identifica um servidor de C2 (infraestrutura), pode descobrir que malware se conecta a ele (capacidade), quais vítimas foram afetadas, e eventualmente atribuir a um adversário. Puxa-se um fio e o novelo inteiro começa a se desenrolar.

Indicadores de Comprometimento: as pegadas

Isso conecta diretamente ao conceito prático mais importante desta aula: os Indicadores de Comprometimento (IoCs). Um IoC é qualquer artefato observável que sinaliza que um sistema pode ter sido comprometido — são as pegadas que o atacante deixa. Eles vivem, em sua maioria, nos vértices de capacidade e infraestrutura do diamante, e são o pão com manteiga da detecção. Exemplos concretos de IoCs incluem o hash de um arquivo malicioso conhecido, um endereço IP ou domínio de C2, um caminho de arquivo ou chave de registro que certo malware sempre cria, um padrão suspeito em logs, ou um user-agent incomum em requisições web.

Um indicador como dado estruturado

Vale ver um IoC como dado estruturado, já que você vai lidar com eles o resto da carreira. Numa forma simplificada de descrição de ameaça, um indicador aparece assim:

tipo:    sha256
valor:   e3b0c44298fc1c149afbf4c8996fb924...
contexto: hash de dropper associado ao malware X

tipo:    domínio
valor:   painel-atualizacao-sistema[.]net
contexto: C2 observado na campanha Y

tipo:    ip
valor:   203.0.113.45
contexto: servidor de exfiltração

(Repare no [.] no domínio — é a convenção de "desarmar" indicadores em relatórios, para ninguém clicar por acidente. Detalhe pequeno, hábito profissional.) O objetivo é que esses indicadores sejam compartilháveis: uma organização que sofre um ataque publica os IoCs, e outras podem varrer seus próprios ambientes procurando as mesmas pegadas. Existem formatos padronizados para essa troca — o STIX para descrever a ameaça e o TAXII para transportá-la — que permitem que ferramentas de defesa consumam inteligência automaticamente.

A Pirâmide da Dor e o custo de trocar

Aqui, porém, entra a lição mais sofisticada da aula, resumida na chamada Pirâmide da Dor (de David Bianco). Nem todos os IoCs têm o mesmo valor, porque nem todos custam o mesmo para o atacante trocar. Um hash de arquivo está na base da pirâmide: é trivial para o atacante mudar um byte e gerar um hash novo, tornando seu indicador inútil. IPs e domínios são um pouco mais custosos de rotacionar, mas ainda relativamente fáceis. No topo da pirâmide estão as TTPs — táticas, técnicas e procedimentos (exatamente o que o ATT&CK cataloga): o jeito de o atacante operar. Mudar um hash é fácil; mudar toda a metodologia de ataque é caríssimo e doloroso. Por isso, detecção baseada em comportamento (TTPs) é muito mais robusta do que detecção baseada em indicadores atômicos (hashes, IPs). Quem defende com base em hash está sempre um passo atrás; quem defende com base em comportamento força o atacante a reinventar-se.

O rastro que você mesmo deixa

Para o pentester, entender IoCs e o Diamond Model é entender o rastro que você mesmo deixa. Cada ferramenta que você roda, cada payload que você entrega, cada conexão de C2 que você abre gera indicadores potenciais. Um teste que simula um adversário sofisticado precisa considerar sua própria "pegada" — é o embrião da OPSEC ofensiva que veremos no Bloco XVIII. E no relatório, mapear os IoCs que você gerou ajuda o cliente a responder à pergunta crucial: "minha equipe teria detectado isso?". Se você atravessou o ambiente inteiro sem disparar um alerta, o achado mais valioso do seu teste talvez nem seja uma vulnerabilidade técnica, e sim a cegueira de detecção que você acabou de expor.

Fontes e leituras recomendadas

Exercícios

  1. Nomeie os quatro vértices do Diamond Model e explique por que estarem conectados é analiticamente útil.

    ✓ Resposta:

    Adversário, vítima, capacidade e infraestrutura. Estarem conectados é útil porque descobrir um vértice (ex.: um servidor de C2, na infraestrutura) frequentemente permite chegar aos demais (o malware que se conecta a ele, as vítimas e, por fim, o adversário).

  2. O que é um Indicador de Comprometimento? Dê três exemplos de tipos diferentes.

    ✓ Resposta:

    É um artefato observável que sinaliza possível comprometimento — uma "pegada" do atacante. Exemplos: hash de um arquivo malicioso, domínio/IP de C2 e uma chave de registro ou caminho de arquivo característico de certo malware.

  3. Explique a convenção de escrever domínios como exemplo[.]net em relatórios.

    ✓ Resposta:

    É "desarmar" o indicador inserindo colchetes no ponto, para que o domínio não vire link clicável e ninguém acesse acidentalmente a infraestrutura maliciosa ao ler o relatório.

  4. Segundo a Pirâmide da Dor, por que detecção baseada em TTPs é mais robusta do que baseada em hashes de arquivo?

    ✓ Resposta:

    Porque trocar um hash é trivial para o atacante (basta alterar um byte), enquanto mudar toda a sua metodologia de operação (TTPs) é caro e doloroso; detecção comportamental força esse custo alto sobre o adversário.

  5. Por que um pentester deve se preocupar com os IoCs que ele próprio gera durante um teste?

    ✓ Resposta:

    Porque cada ferramenta, payload e conexão de C2 que ele usa gera indicadores; considerá-los é essencial para simular um adversário realista, praticar OPSEC e avaliar no relatório se a equipe do cliente teria detectado a atividade.