Honeypots e Honeynets

Nota 05 do capítulo 02 (Fontes de Dados e Coleta), tratando a coleta ativa com infraestrutura isca.
Cobre a tipologia de honeypots, honeytokens e tarpits, os casos de uso em CTI, os riscos legais e de pivô e a integração com o pipeline.
Dialoga com a nota 01 (OSINT), a nota 04 (telemetria interna) e com os capítulos 06 (Fundamentos de Threat Hunting) e 13 (Contra-Inteligência).

1. Contexto e Posicionamento na Biblioteca

Honeypots são a única fonte de coleta em que o defensor controla o alvo inteiro. Nenhum usuário legítimo tem motivo para interagir com um honeypot, de modo que toda interação é, por definição, anomalia, e o sistema pode dedicar atenção total ao registro fino do que o atacante faz. Essa inversão da razão sinal-ruído é o que torna a fonte singular: enquanto o SOC caça agulha em palheiro, o honeypot é palheiro construído para que a agulha seja o único objeto presente.

Na biblioteca, esta nota ocupa a fronteira entre coleta e contra-inteligência. Do lado da coleta, o honeypot entrega amostras, credenciais queimadas, ferramentas e comportamento de varredura que alimentam o pipeline das notas anteriores; do lado da contra-inteligência do capítulo 13, ele entrega informação sobre quem procura a organização e como, incluindo o valor estratégico de desacelerar e enganar. A nota mantém o foco na coleta, mas marca as passagens para o capítulo 13, e dialoga com a nota 04 porque a telemetria do honeypot entra no SIEM como qualquer outra fonte.

2. Tipologia de Iscas

A taxonomia clássica separa por profundidade de interação, e essa separação define custo, risco e tipo de inteligência produzida. Honeypots de baixa interação simulam serviços com respostas limitadas, baratos de operar e praticamente sem risco de comprometimento, ideais para mapear varredura e automação; honeypots de alta interação oferecem sistemas reais, muitas vezes com falsos documentos, credenciais e aplicações deliberadamente convincentes, e entregam a inteligência mais rica ao custo de risco operacional real. Entre as duas pontas ficam os tarpits, que não simulam nada útil, apenas prendem conexões de varredura em respostas lentas, e os honeytokens, que não são sistemas, e sim elementos de dados plantados com valor aparente, cujo uso denuncia o atacante.

O T-Pot merece destaque como forma de entrada prática, porque empacota dezenas de honeypots de baixa e média interação, incluindo Cowrie para SSH e Telnet, com dashboard, ELK integrado e captura de amostras, e roda em um único host isolado. Canarytokens, da mesma família do Thinkst Canary, cobre o oposto da escala: tokens individuais de credencial falsa, URL de webhook, documento com beacon de abertura ou consulta DNS, espalhados pelo ambiente real a custo praticamente zero. Um programa maduro combina os dois extremos: sensores externos que mapeiam o ruído da internet e honeytokens internos que denunciam movimento dentro do perímetro.

O posicionamento no espaço de endereços é a variável de desenho mais subestimada. Sensores em IPs nunca anunciados, sem DNS e sem certificado, capturam exclusivamente varredura automática e servem como termômetro do ruído de fundo; sensores em IPs que já aparecem em registros públicos, com banners de VPN ou de appliance simulado, atraem interesse dirigido. A combinação das duas famílias, muitas vezes dentro do mesmo intervalo reservado, conhecido como darknet ou grey space, permite ao analista distinguir varredura indiscriminada de interesse específico no espaço de endereços da organização, e essa distinção é um dos sinais mais valiosos que a fonte produz.

3. Casos de Uso em CTI

O caso de uso mais imediato é coleta de artefatos frescos. Um Cowrie exposto à internet recebe constantemente tentativas de força bruta e, em horas, o binário que o atacante solta na sessão; esse payload alimenta MalwareBazaar, gera regra YARA e vira material de detecção antes de atingir qualquer sistema de produção. Na prática de mercado, sensores de baixa interação bem posicionados capturam o ruído automatizado de campanhas de botnet e mineradores, e o padrão de IPs e portas coletado sustenta watchlist de infraestrutura que a nota 01 normaliza.

O segundo caso de uso é calibrar o que é ruído, e aqui a fonte complementa o GreyNoise em vez de substituí-lo. O honeypot próprio mostra exatamente o que está sendo lançado contra o espaço de IP da organização, com a granularidade de quem varre o seu bloco e não a internet inteira. Essa distinção muda decisões: banner de scanner massivo conhecido vira contexto de fundo, enquanto interação com honeytoken interno de credencial de banco de dados é alerta de prioridade máxima, porque não existe razão benigna para o uso.

O terceiro caso, mais avançado, é a coleta de TTPs de operadores humanos. Sessões longas em honeypot de alta interação registram a sequência de comandos do operador, as ferramentas que ele baixa, os caminhos que ele procura e a lógica de exploração, material que sustenta análise de attribution e mapeamento ATT&CK com profundidade difícil de obter em log de produção. Honeytokens de documento, quando abertos, revelam inclusive interesse específico da campanha, como tratam os casos públicos de phishing que usam arquivos de aparente confidencialidade alta para despistar a vítima.

A tabela abaixo amarra cada caso de uso ao produto de inteligência que ele alimenta e ao destino no pipeline, e serve de checklist de justificativa: toda isca implantada deve estar associada a pelo menos um destes casos, com dono e revisão.

# Coleta do Cowrie: sessões de SSH para extração de comandos e artefatos
docker logs cowrie 2>&1 | jq -r 'select(.eventid == "cowrie.command.input") | [.timestamp, .input] | @tsv'
docker logs cowrie 2>&1 | jq -r 'select(.eventid == "cowrie.session.file_download") | .shasum'

4. Riscos Legais e de Pivô

O risco de pivô é o critério que separa implantação profissional de honeypot casual. Por definição, o atacante que entra no honeypot deve conseguir comprometê-lo, e a única coisa que impede o avanço é a arquitetura de rede ao redor. O padrão mínimo profissional inclui: honeypot em segmento dedicado, sem rota para redes de produção; egress controlado com whitelist mínima, de modo que o atacante não use o sensor para atacar terceiros; nenhuma credencial real em nenhum arquivo do sensor; e captura integral de tráfego para auditoria do próprio sensor. A regra de ouro é que o honeypot é ambiente sacrificável por desenho, reconstruído a cada comprometimento e nunca parte de nenhum serviço real.

Os riscos legais variam por jurisdição, mas três vetores são recorrentes e exigem parecer antes da implantação. O primeiro é responsabilidade por dano a terceiro, caso o atacante use o sensor como base de ataque externo, mitigado pelo egress restrito e por contrato com o provedor que aceita o uso do endereço para honeypot. O segundo é o tratamento de dados capturados, porque sessões podem conter informação pessoal de terceiros e credenciais de serviços do próprio atacante, e a captura integral precisa estar alinhada à LGPD e à política de retenção. O terceiro é a diferença entre observação e incitação: deixar serviço exposto é observação passiva aceitável, enquanto interagir ativamente com o atacante, pagar resgate ou adquirir dados levantam questões muito mais sérias, e a linha entre as duas precisa estar escrita na política do programa.

A fronteira da interação ativa merece exemplo concreto porque é onde times entusiastas erram. Responder automaticamente a credenciais falsas dentro do próprio sensor é engajamento de honeypot normal; iniciar sessão reversa para o atacante, tentar corromper a ferramenta dele ou publicar dados capturados dele em comunidade são decisões de política, não de ferramenta, e cada uma pede aprovação jurídica e registro. A regra editorial da biblioteca é conservadora e clara: o honeypot coleta, nunca contra-ataca, e todo material capturado com identificação possível de indivíduo é tratado como dado pessoal até prova em contrário.

5. Projeto e Implantação Prática

A implantação mínima profissional cabe em três projetos paralelos: sensor externo, sensor interno e tokens. O sensor externo nasce de um host dedicado na borda, com T-Pot ou pilha Cowrie mais Suricata, endereços reservados para iscas e egress bloqueado por padrão. O sensor interno é uma máquina virtual de baixo custo, com serviços que fazem sentido no contexto da organização, como SMB simulado e portas de administração típicas, e que nunca recebe dados reais. Os tokens completam a malha com cobertura fina: credenciais em repositórios, chaves de API falsas em gerenciador de segredos, documentos iscas em compartilhamentos de arquivo e endereços DNS que só existem para denunciar resolução.

O trecho abaixo mostra o esqueleto de um Cowrie isolado, com foco nos itens que garantem segurança de implantação, e vale como modelo de checklist: volume dedicado, rede sem rota para produção, egress limitado e captura integral para o SIEM.

# docker-compose reduzido do Cowrie com segurança de implantação
services:
  cowrie:
    image: cowrie/cowrie:latest
    restart: unless-stopped
    networks:
      honeynet: {}
    volumes:
      - ./etc/cowrie.cfg:/cowrie/cowrie-git/cowrie.cfg:ro
      - ./var/lib/cowrie:/cowrie/cowrie-git/var/lib/cowrie
    logging:
      driver: json-file
      options:
        max-size: "50m"
networks:
  honeynet:
    internal: true   # sem rota direta para redes de produção

Dois indicadores acompanham a implantação desde o primeiro dia, e alimentam a revisão trimestral. O primeiro é volume de interação por sensor, que valida que a isca está visível e atrativa; queda súbita indica problema de rede ou de banner datado. O segundo é razão entre interação automatizada e dirigida, que muda quando a organização entra em alvo específico, e é o sinal de alerta mais precoce que a fonte oferece. Ambos entram no painel do capítulo 11 como métricas de cobertura de coleta, não como métricas de detecção, para que o sensor seja julgado pelo que coleta e não pelos casos que por acaso atinge.

6. Integração com o Pipeline de Coleta

O honeypot só vira fonte de CTI quando seus eventos entram no pipeline com o mesmo tratamento das demais fontes. O padrão de integração tem quatro passos: coleta estruturada dos logs do sensor, normalização para o modelo comum do SIEM, extração automática de observáveis para o TIP e avaliação de fonte pela nota 07. A marcação de origem honeypot em cada observável é essencial, porque a pontuação de confiabilidade do material de honeypot é distinta da telemetria de produção: qualquer interação é suspeita, mas o contexto de varredura de fundo precisa ser separado da interação dirigida.

# Registro de sensor no inventário de fontes de coleta
sensor: hp-externo-borda-01
tipo: honeypot_baixa_interacao
tecnologia: T-Pot (Cowrie, dionaea, suricata)
posicao: rede dedicada, sem rota para produção
objetivos: [varredura, payload_botnet, credenciais_automatizadas]
saidas: [SIEM normalizado, TIP com tag honeypot]
tlp_padrao: "TLP:AMBER"
revisao: trimestral

Honeytokens pedem um desenho de alerta próprio, porque o valor está na velocidade da resposta. Cada token é ligado a alerta de prioridade máxima com playbook específico, e o registro do token documenta onde foi plantado, em qual contexto plausível e qual é a hipótese que o uso do token confirma. O exemplo clássico é o token de credencial de backup inserido em repositório de configuração: qualquer uso indica credencial exposta e pede investigação imediata do caminho entre o repositório e o uso. Token que fica meses sem alerta definido vale tão pouco quanto honeypot sem coleta, e token em contexto implausível pode até queimar o programa, porque o operador experiente percebe a isca.

O inventário de posicionamento é o que transforma tokens esparsos em malha de cobertura, e o trecho abaixo mostra o registro mínimo por token. A lógica de posicionamento é imitar onde credenciais e dados valiosos realmente vivem na organização: repositórios de código, compartilhamentos de arquivo, gerenciadores de segredos, planilhas de credenciais de sistema legado e cadernos de configuração de serviço. Cada local plantado deve ter contexto verossímil, porque token solto em pasta vazia denuncia a isca por ausência de vizinhança.

- token: canary-token-dns-01
  tipo: dns
  plantado_em: "repositório de configuração legado, arquivo appsettings"
  contexto: "chave de API de serviço que existiu até 2023"
  hipotese: "uso indica leitura do repositório ou exfiltração do arquivo"
  alerta: severidade_critica, playbook_token_uso
- token: canary-file-share-02
  tipo: acesso_a_arquivo
  plantado_em: "compartilhamento financeiro, pasta Reconciliacao"
  contexto: "planilha com nomes de contas bancárias falsas"
  hipotese: "acesso indica exploração de compartilhamento por adversário"
  alerta: severidade_critica, playbook_token_uso

7. Erros Comuns e Pontos de Atenção

• Expor honeypot sem egress restrito; efeito: sensor usado para atacar terceiros e responsabilidade legal; correção: whitelist de saída e coordenação formal com o provedor.
• Usar credenciais reais ou dados verdadeiros na isca; efeito: comprometimento útil ao atacante e perda de dados; correção: apenas dados sintéticos verossímeis, revisados antes da publicação.
• Tratar honeypot como substituto de detecção de produção; efeito: cegueira para o tráfego que não toca a isca; correção: registrá-lo como fonte complementar na matriz da nota 04.
• Plantar honeytoken em contexto implausível; efeito: operador identifica a isca e aprende com ela; correção: desenhar o token como resposta natural a uma atividade que o atacante faria.
• Não revisar legalmente a captura; efeito: risco de conformidade com LGPD e prova inutilizável; correção: parecer jurídico antes da implantação e política de retenção documentada.
• Coletar sem responder; efeito: alerta de honeytoken acionado sem playbook; correção: cada token com dono, severidade máxima e rota de resposta definida.
• Deixar o sensor parado por meses sem manutenção; efeito: banner e comportamento datados perdem poder de captura; correção: ciclo de atualização e teste do sensor junto com a revisão trimestral.
• Colocar a isca no mesmo hypervisor ou subnet de sistemas críticos; efeito: comprometimento do sensor ameaça ativos reais por escape de isolamento; correção: infraestrutura dedicada ou isolamento formal de virtualização.
• Esquecer de registrar o sensor no inventário de ativos; efeito: isca sem dono, sem patch e sem resposta a incidente própria; correção: sensor é ativo gerenciado, com dono e ciclo de vida no CMDB.

8. Integração com o Restante da Biblioteca

O material de honeypot alimenta as notas anteriores do capítulo como qualquer outra fonte: os artefatos vão para o OSINT de saída da nota 01, os observáveis entram no capítulo 03 com tag de origem e a telemetria do sensor vive no SIEM da nota 04. A diferença está na proveniência, porque material de isca carrega certeza de intenção que nenhuma outra fonte entrega, e essa certeza é o que a nota 07 usa para calibrar a pontuação.

Na fronteira com os capítulos seguintes, o honeypot é a ponte natural entre coleta e as duas disciplinas centrais da biblioteca. Para o hunting do capítulo 06, a interação com isca externa é hipótese pronta de atividade dirigida, e o histórico do sensor serve de dataset de treino para distinguir varredura de fundo de interesse específico. Para a contra-inteligência do capítulo 13, a mesma infraestrutura muda de papel: a isca passa a informar o adversário sobre o que a organização quer que ele acredite, e o programa de coleta se transforma em instrumento de manipulação de percepção, com os mesmos controles desta nota servindo de alicerce.