Dangles, Doubles e Barium Meals

Nota 02 do bloco CI Ofensiva (Detectar, Enganar, Neutralizar), capítulo 13 (Contra-Inteligência).
Introduz o vocabulário clássico do engano de contraespionagem (dangle, double, barium meal) e sua tradução cibernética: credenciais canário, repositórios isca, honeytokens e documentos marcados.
Dialoga com a nota 01 (Operações de Contraespionagem) e a nota 03 (Decepção e Manipulação do Adversário) deste bloco, e com a nota 05 do capítulo 02 (Honeypots e Honeynets).

1. Contexto e Posicionamento na Biblioteca

O engano de contraespionagem tem séculos de vocabulário próprio, e esse vocabulário é mais preciso do que a terminologia improvisada do marketing de segurança. Dangle, double e barium meal descrevem três funções operacionais distintas: a oferta que atrai, o agente controlado que alimenta e a cadeia de iscas que revela o caminho do adversário. Traduzir esse vocabulário para o ciberespaço corporativo evita que o programa de engano construa sensores soltos quando o que se precisa é de um sistema integrado de manipulação de percepção.

Esta nota situa-se entre a operação da nota 01, que define quem autoriza e até onde se vai, e a teoria da decepção da nota 03, que explica por que o engano funciona. O capítulo 02 já tratou honeypots como fonte de coleta; aqui a mesma família de recursos muda de papel: a isca deixa de ser sensor e passa a ser instrumento de contraespionagem, com exigências adicionais de verossimilhança, correlação e governança. A distinção é prática, não cosmética: um honeypot coleta o que aparece; um dangle bem desenhado influencia o que o adversário faz depois.

2. O Vocabulário Clássico do Engano

O dangle é a informação ou o canal aparentemente acessível que a organização deixa ao alcance do adversário para observar o que ele faz com ela. O termo vem da prática clássica de deixar documentação sensível aparentemente desprotegida, cuja captação denuncia interesse e cuja leitura pode ser rastreada. No desenho, o dangle é passivo: não persegue, não convida, apenas permanece visível o suficiente para ser encontrado por quem procura. A qualidade do dangle está na verossimilhança e na cadeia de custódia do sinal: cada acesso deve ser rastreável de ponta a ponta.

O double é o agente que já foi detectado e agora opera sob controle do lado que o descobriu, fornecendo informação selecionada para o adversário. Em ambiente corporativo não existe agente humano controlado em sentido estrito, mas existe o equivalente funcional: canal de comunicação que a organização sabe monitorado e mantém vivo, conta comprometida que é observada em vez de bloqueada, ou endpoint que permanece no ambiente do atacante com coleta reforçada. O risco do double é o reverso da moeda: informação selecionada demais revela que o canal é controlado, e informação errada demais destrói a credibilidade do canal.

O barium meal é a isca em cadeia, nome emprestado do exame médico em que o contraste ingerido revela o trajeto interno por imagens. Na prática, são múltiplas iscas encadeadas de modo que morder a primeira conduz à segunda e à terceira, e o padrão de mordidas revela a anatomia do ataque. O valor do barium meal sobre a isca solta é o caminho: em vez de um evento isolado de acesso, o defensor obtém a sequência completa de exploração, com cada elo confirmando a intenção e refinando o perfil do operador.

3. Tradução Cibernética dos Conceitos

A tradução cibernética do dangle é o honeytoken: credencial canário em repositório de configuração, chave de API falsa em gerenciador de segredos, documento marcado em compartilhamento de arquivo, subdomínio canário em registro público. Nenhum usuário legítimo tem razão para usá-los, de modo que qualquer interação é sinal de alta fidelidade. O double traduz-se em canal observado: conta de serviço comprometida mantida viva sob monitoramento intensivo, caixa de correio isca que recebe o adversário ou host que continua operando dentro da sessão do atacante com coleta de memória e rede. O barium meal traduz-se na rede de honeytokens encadeados da seção 5, em que documento marcado contém credencial canário, e a credencial aponta para repositório isca.

A regra de desenho que separa tradução madura de token solto é a pergunta de hipótese: cada isca deve responder a uma hipótese explícita do programa, do tipo "se este token for usado, então houve leitura do repositório de configuração por agente externo". A nota 05 do capítulo 02 já registrou o formato mínimo de registro por token; aqui o registro ganha o campo de encadeamento, que liga cada isca à anterior e à seguinte na cadeia do barium meal.

4. Rastreando Quem Mordeu a Isca

Rastrear a mordida exige três camadas de registro que precisam estar prontas antes da isca ser plantada. A primeira é o registro no ponto de interação: autenticação no repositório isca, resolução DNS do token, beacon do documento marcado, com timestamp, origem e identidade apresentada. A segunda é o registro no caminho: proxy, firewall, gateway de e-mail e logs de rede que permitem reconstruir a rota entre a origem e a isca. A terceira é o registro do contexto: qual hipótese a isca testava e qual elo da cadeia ela ocupa, sem o qual o evento fica órfão no SIEM.

// Uso de credencial canário correlacionado com a rota de origem
SecurityEvent
| where EventID == 4624
| where TargetUserName in~ ("svc_backup_legado", "srv_integracao_2019")
| join kind=leftouter (
    DeviceNetworkEvents
    | summarize ultimo_contato = arg_max(Timestamp, RemoteIP) by DeviceName
) on Computer
| project TimeGenerated, Computer, TargetUserName, IpAddress, LogonType, ultimo_contato
| extend cadeia = iff(IpAddress has "10.", "interno_comprometido", "origem_externa")

A leitura do resultado pede disciplina de atribuição, porque quem mordeu a isca nem sempre é quem planejou o ataque. Origem externa pode ser máquina intermediária; conta interna pode ser máquina já comprometida operada remotamente. A prática recomendada é documentar a mordida como evento de alta fidelidade de interesse, e não como atribuição: o perfil do operador é construído pela sequência de mordidas ao longo da cadeia, não por um único endereço IP. A nota 02 do capítulo 05 governa os limites dessa inferência e vale aqui na íntegra.

5. Rede de Honeytokens em Camadas: Exemplo Prático

O barium meal corporativo típico cruza quatro camadas do ambiente. Na camada de perímetro, tokens de DNS e faces externas isca denunciam reconhecimento dirigido. Na camada de rede interna, compartilhamentos e serviços isca denunciam movimento lateral. Na camada de identidade, contas canário denunciam roubo e uso de credenciais. Na camada de dados, documentos marcados e repositórios isca denunciam exploração e estagio de exfiltração. O inventário abaixo ilustra uma malha mínima encadeada, com o campo de encadeamento explicitando a cadeia.

# Inventário de honeytokens em camadas com encadeamento de barium meal
camada_perimetro:
  - token: dns-canario-01
    tipo: dns
    plantado_em: registro_esquecido_de_subdominio_historico
    hipotese: reconhecimento_dirigido_contra_a_marca
    alerta: critica
    encadeia_com: repositorio-isca-01
camada_rede_interna:
  - token: share-isca-financeiro-01
    tipo: acesso_a_arquivo
    plantado_em: "compartilhamento corporativo, pasta Reconciliacao"
    hipotese: exploracao_de_compartilhamento_por_adversario_com_sessao
    alerta: critica
    encadeia_com: documento-marcado-01
camada_identidade:
  - token: credencial-canario-backup-01
    tipo: credencial
    plantado_em: "repositorio de configuracao legado, appsettings"
    hipotese: leitura_do_repositorio_por_agente_externo
    alerta: critica
    encadeia_com: repositorio-isca-01
camada_dados:
  - token: documento-marcado-01
    tipo: documento_com_beacon
    plantado_em: share-isca-financeiro-01
    conteudo: planilha_sintetica_de_clientes_com_credencial_canario
    hipotese: estagio_pre_exfiltracao
    alerta: critica
    encadeia_com: credencial-canario-backup-01
  - token: repositorio-isca-01
    tipo: repositorio_de_codigo
    plantado_em: forge_interno_espelhado_sem_dado_real
    conteudo: projeto_sintetico_com_chaves_falsas
    hipotese: coleta_de_fonte_e_secrets_pelo_adversario
    alerta: critica
    encadeia_com: nenhum_ultimo_elo

A cadeia do exemplo funciona como o exame de contraste: o adversário que abre o documento marcado encontra a credencial canário, que conduz ao repositório isca, e cada elo acrescenta um traço ao perfil. Um operador que percorre os três elos demonstra método de coleta, interesse financeiro e capacidade de interpretar arquivos de configuração, informação que nenhuma isca solta entregaria. O custo do programa é baixo, e o ganho é a anatomia completa do caminho que ele seguiria em um ambiente real.

6. Riscos, Ética e Governança

O primeiro risco é a queima da isca: operador experiente reconhece contexto implausível e a malha vira informação contra o defensor. Mitigação exige verossimilhança (a isca responde a uma pergunta que o adversário realmente faria), rotação periódica e proibição de iscas decorativas sem hipótese. O segundo risco é o envolvimento de inocentes: funcionário legítimo que tropeça no token, scanner de segurança da própria organização, parceiro com acesso legítimo. A governança exige inventário de tokens compartilhado com o time de segurança ofensiva interna e com o time de IAM, para que testes autorizados não gerem crises falsas e para que nenhuma isca use identidade de pessoa real.

O terceiro risco é jurídico e envolve dado pessoal e terceiros. Documentos marcados podem reportar de volta informações sobre quem abriu, e sessões em terreno isca podem conter dados pessoais do próprio adversário ou de terceiros; o tratamento segue LGPD, retenção limitada e parecer prévio, como registrado na nota 01. O quarto risco é ético-organizacional: isca não é armadilha disciplinar, e o programa precisa declarar por escrito que honeytokens existem para detectar adversários, não para flagrar funcionários, porque o dia em que a malha é usada contra colaborador interno sem processo formal, a confiança no programa morre e as denúncias espontâneas de erro humano desaparecem.

7. Erros Comuns e Pontos de Atenção

• Plantar token sem hipótese declarada; efeito: alerta sem contexto e resposta improvisada; correção: registro com hipótese, elo da cadeia e dono antes da implantação.
• Usar identidade de pessoa real em conta canário; efeito: risco disciplinar e ético, além de confusão em investigação; correção: contas exclusivamente sintéticas registradas no IAM.
• Encadear iscas sem caminho plausível; efeito: operador percebe o labirinto e queima a malha inteira; correção: cada elo deve estar no caminho natural da próxima pergunta.
• Monitorar só o ponto de interação; efeito: mordida registrada sem rota e sem contexto; correção: três camadas de registro, no ponto, no caminho e no contexto.
• Confundir mordida com atribuição; efeito: conclusões precipitadas sobre quem ataca; correção: perfil construído pela sequência da cadeia, com confiança declarada.
• Deixar a malha sem revisão; efeito: iscas datadas, contextos que não fazem mais sentido e queima por abandono; correção: revisão trimestral com rotação programada.
• Usar a malha para vigilância interna; efeito: perda de confiança e risco trabalhista; correção: termo de governança que limita o uso a adversários externos.
• Expor todas as iscas de uma vez; efeito: padrão de implantação perceptível; correção: distribuição gradual alinhada ao ciclo de vida real dos ativos imitados.

8. Integração com o Restante da Biblioteca

A malha de honeytokens vive da infraestrutura e da telemetria do capítulo 02: os canarytokens e honeypots da nota 05 fornecem as peças, o pipeline de coleta fornece o transporte e o enriquecimento, e a avaliação de fontes da nota 07 do mesmo capítulo calibra a confiabilidade, que aqui é a mais alta possível, porque interação com isca não tem explicação benigna plausível. No capítulo 03, cada mordida gera IOCs de origem, e a pirâmide de dor da nota 05 orienta a prioridade: o que a malha entrega melhor são comportamentos e ferramentas, o topo da pirâmide.

Para o resto do capítulo 13, esta nota é o arsenal da operação da nota 01 e a parte tática da decepção da nota 03: o MAGPIE de lá define alvo, objetivo e evento, e os dangles, doubles e barium meals daqui são os instrumentos que executam o plano. No capítulo 15, os controles de coleta e detecção formalizam o transporte dos sinais, e o CTI.10 fecha o ciclo da proteção por contra-inteligência. O ponto técnico final: a malha é um sistema com ciclo de vida, não um conjunto de tokens, e o programa que trata cada isca como hipótese testável é o único que sobrevive ao primeiro operador competente que a morder.