01 - Fontes Abertas (OSINT)

1. Contexto e Posicionamento na Biblioteca

O OSINT (Open Source Intelligence) é a inteligência produzida a partir de informações publicamente acessíveis, coletadas, processadas e analisadas pelo próprio time. No ciclo de inteligência, ele atende primeiro aos requisitos do capítulo 01, porque praticamente todo PIR (Priority Intelligence Requirement) começa com uma pergunta que pode ser respondida por dados abertos: quais IPs hospedam o loader da campanha, que infraestrutura o grupo reutiliza, quais variações do phishing estão circulando. A força do OSINT está no custo marginal baixo e na verificabilidade, já que qualquer colega pode refazer a mesma consulta e auditar o raciocínio.

Esta nota trata especificamente da coleta, deixando a avaliação crítica da confiabilidade para a nota 07 e a normalização de indicadores para o capítulo 03. A regra prática que orienta a nota é simples: fonte aberta não significa fonte gratuita de responsabilidade, e o volume enorme de feeds públicos só vira inteligência quando filtrado por requisitos, deduplicado e validado contra a telemetria interna do capítulo 04.

2. Panorama das Categorias de Fontes Abertas

A grandeza do ecossistema aberto engana iniciantes, e a solução é organizar por categoria de dado e objetivo de uso, em vez de assinar dezenas de listas. As categorias cobrem o ciclo do ataque de formas diferentes: algumas expõem infraestrutura, outras expõem o artefato, outras expõem o comportamento do operador. A tabela abaixo é o mapa mínimo para estruturar a coleta.

Cada categoria pede cadência própria. Feeds de IOC giram em horas e perdem valor rápido, repositórios de malware crescem de forma contínua, e bancos como Shodan mudam de forma mais lenta, o que permite consultas dirigidas em vez de sincronização diária. Definir essa cadência por categoria evita tanto o processamento desperdiçado quanto a informação que chega tarde demais para acionar detecção.

3. Ferramentas e Serviços Essenciais

Um kit OSINT funcional para CTI cabe em meia dúzia de serviços, cada um com papel claro. O Shodan e o Censys indexam a internet com base em banners de serviço, certificados e metadados, e são a ferramenta padrão para responder a pergunta inversa de quem caça: dado um endereço IP do meu incidente, que infraestrutura parecida existe sob o mesmo operador? O VirusTotal agrega análise de arquivos, URLs e domínios de dezenas de motores e é indispensável para enriquecer artefatos, com atenção ao fato de que a submissão de amostras sensíveis pode expor o incidente da organização a pesquisadores e ao próprio adversário.

O ecossistema do abuse.ch cobre a ponta técnica: URLhaus distribui URLs de distribuição de malware em CSV e API, MalwareBazaar publica amostras com tags e assinaturas YARA comunitárias, ThreatFox expõe IOCs associados a relatos de pesquisadores e YARAify indexa regras e amostras. O GreyNoise complementa ao separar ruído de sinal, porque distingue scanners massivos e banners do que parece mirado no seu ambiente. Nenhum desses serviços substitui análise, mas juntos respondem à maioria das perguntas táticas de um SOC em minutos.

# Consultas de referência para infraestrutura do adversário
Shodan:  ssl.cert.subject.CN:"painel-adversario.example" org:"Hosting X"
Shodan:  http.title:"Painel de controle" -port:80 country:BR
Censys:  services.tls.certificates.leaf.subject.common_name: *.campanha.example
crt.sh:  https://crt.sh/?q=%25.campanha.example  (histórico de certificados)
GreyNoise: consultar IP antes de classificar como IOC (scanner conhecido ou não)

A integração com o MISP ou com o TIP da organização deve ser feita por API com chaves dedicadas por fonte, como detalhado na nota 03 deste capítulo. O trecho abaixo ilustra o padrão de ingestão incremental com controle de deduplicação, que vale para praticamente qualquer feed aberto com suporte a consulta por intervalo de tempo.

import requests, csv, io

# Ingestão incremental do feed URLhaus com filtro por período e dedup
resp = requests.get("https://urlhaus.abuse.ch/downloads/recent/", timeout=30)
novos = set()
for linha in csv.DictReader(io.StringIO(resp.text), comment_char="#"):
    if linha["dateadded"] >= ULTIMO_CHECKPOINT:
        chave = (linha["url"], linha["url_status"])
        if chave not in vistos:
            novos.add(chave)
            vistos.add(chave)
publicar_no_misp(novos, fonte="URLhaus", tlp="TLP:CLEAR")

A correspondência entre PIR e kit de fontes evita a coleção desorganizada de assinaturas, e a tabela abaixo oferece exemplos prontos de composição. O mesmo exercício deve ser feito para os PIRs reais da organização no capítulo 01, e o resultado é o cardápio efetivo do programa de coleta aberta.

4. Técnicas de Coleta e Boas Práticas de Automação

Coleta madura segue quatro princípios operacionais que separam um feed genérico de um pipeline confiável. Primeiro, ingestão incremental com checkpoint persistido, evitando reprocessar a coleção inteira a cada execução. Segundo, deduplicação por chave canônica do artefato, porque o mesmo domínio aparece em dezenas de feeds com rótulos diferentes. Terceiro, enriquecimento no ponto de entrada, aplicando ponto de validade, TLP padrão e tag de origem, o que reduz drasticamente o custo de decisão depois. Quarto, limites de taxa e cache respeitosos, já que serviços públicos derrubam chaves que martelam a API.

A priorização por requisito também se aplica aqui. Um PIR sobre phishing bancário pede URLhaus, OpenPhish e monitoramento de certificados, enquanto um PIR sobre ransomware de nicho pede MalwareBazaar, repositórios de amostras e monitoramento de sites de vazamento. As fontes que não servem a nenhum requisito ativo saem da coleta e entram como fonte esporádica de consulta manual, decisão registrada para revisão trimestral junto com a nota 07.

# Exemplo de coleta programada: baixar KEV e feeds abertos com cache e rate limit
curl -s https://urlhaus.abuse.ch/downloads/csv_recent/ -o /coleta/urlhaus.csv
curl -s https://threatfox.abuse.ch/export/json/recent/ -o /coleta/threatfox.json
curl -s "https://api.abuseipdb.com/api/v2/blacklist?confidenceMinimum=90" \
     -H "Key: ${ABUSEIPDB_KEY}" -o /coleta/abuseipdb.jsonl

A tabela abaixo consolida a cadência recomendada por família de fonte, que deve ser ajustada conforme o PIR e a capacidade de processamento do time. Cadências mais rápidas que a utilidade real do dado desperdiçam cota de API e geram alertas de mudança trivial, enquanto cadências lentas demais deixam a janela de detecção aberta em campanhas curtas.

5. Coleta Manual e Investigação por Pivô

A coleta automatizada cobre volume, mas a investigação por pivô é onde o OSINT entrega valor analítico que nenhum feed entrega sozinho. O raciocínio de pivô parte de um artefato do ambiente e expande para infraestrutura conectada: um hash de amostra leva ao embed de C2, o C2 leva ao certificado TLS, o certificado leva a outros hosts do mesmo operador e o conjunto todo vira uma assinatura mais durável que qualquer endereço isolado. Essa expansão é o que alimenta a Pirâmide de Dor tratada no capítulo 04, porque deslocar a detecção do IP barato para o certificado e o comportamento caro ao adversário.

Um fluxo de trabalho mínimo para incidente de phishing ilustra o padrão. Recebida uma URL suspeita, o analista captura a página em ambiente seguro, extrai o endereço de hospedagem e o certificate transparency do domínio, consulta RDAP para data de registro e registrante, consulta passive DNS para histórico de resolução e só então decide se o caso é bloqueio tático ou pivô mais profundo. Cada passo é anotado com horário e ferramenta, porque a trilha de proveniência será necessária na nota 07 e, se o caso virar legal, na cadeia de evidência.

# Sequência de pivô documentada para um domínio de phishing
domínio: portal-cobranca-falsa.example
 1. RDAP: registrar "REGISTRAR-ANON", criado em 2025-03-02 (padrão de domínio novo)
 2. crt.sh: certificado emitido 2025-03-02 para *.portal-cobranca-falsa.example
 3. PassiveDNS: mesmo IP hospeda 4 domínios com padrão "cobranca-*" em 30 dias
 4. VirusTotal: 3/90 motores, tags phishing, primeira submissão 2025-03-03
 5. Correlação interna: nenhum acesso nos logs de proxy; IOC entra em watchlist
Resultado: watchlist de 5 domínios e 1 IP, detecção por padrão de certificado

6. OPSEC do Analista e Riscos de Contaminação

A regra número um do analista OSINT é que consulta também é exposição. Consultar um domínio do adversário a partir da rede corporativa pode acionar DNS corporativo, proxy e logs que o próprio atacante monitora, revelando que a vítima está investigando. O padrão mínimo é sair por infraestrutura neutra ou pelo ambiente de laboratório, nunca pelo IP da empresa, e preferir serviços de enriquecimento que fazem a consulta por você, como APIs de VirusTotal ou passive DNS, em vez de resolver o domínio diretamente.

Contaminação por artefato é o segundo risco, e casos públicos são instrutivos porque ferramentas legítimas já entregaram payloads em produção. A disciplina recomendada inclui executar em máquina virtual isolada, com snapshot anterior, sem credenciais reais, sem acesso de saída à rede corporativa e com apenas uma amostra por vez. Amostras nunca são abertas fora do ambiente controlado, e links de phishing são verificados por serviços de captura de tela ou em VM descartável, não no navegador do analista.

O ambiente de coleta merece desenho deliberado de rede. O laboratório de OSINT deve ter egress permitido apenas para os serviços de que precisa, com bloqueio explícito dos intervalos de IP da empresa e dos provedores de e-mail corporativo, para que um payload que tente beaconar não descubra nada sobre a vítima real. GreyNoise e honeypots próprios da nota 05 ajudam a calibrar o que é varredura genérica, e a conexão do laboratório deve sair por IP que a organização aceita queimar publicamente, nunca por IP de produção.

7. Erros Comuns e Pontos de Atenção

Os erros abaixo aparecem em quase toda implantação de OSINT e têm correção barata quando pegos cedo. Trate a lista como checklist de revisão do pipeline, não como teoria.

• Assinar feeds por medo de ficar de fora em vez de por requisito; efeito: volume alto, acionamento baixo e custo de triagem; correção: cada fonte precisa estar vinculada a pelo menos um PIR ou caso de uso documentado.
• Consumir IOC sem validade nem contexto; efeito: falsos positivos permanentes e bloqueio de infraestrutura legítima; correção: exigir validade, tag de origem e TLP na ingestão, conforme o capítulo 03.
• Ignorar license e atribuição; efeito: risco jurídico em redistribuição interna e externa; correção: mapear licença por fonte e registrar restrição no TIP.
• Tratar pesquisa em rede social como fonte primária; efeito: induzir atribuição por eco entre pesquisadores; correção: separar fato observado de comentário de terceiros na anotação.
• Deixar o pipeline coletar sem monitorar acionamento; efeito: fonte morta consumindo espaço e atenção; correção: métrica mensal de IOC acionado por fonte, alimentando o capítulo 11.

8. Integração com o Restante da Biblioteca

O OSINT é a matéria-prima que alimenta a esteira inteira. Os indicadores coletados aqui são normalizados e datados pelo capítulo 03, a avaliação de confiabilidade de cada fonte entra no modelo da nota 07, e o cruzamento com telemetria interna da nota 04 transforma IOC externo em observação real dentro do ambiente, que é o gatilho clássico de hunting do capítulo 06. Fontes abertas também sustentam o trabalho de detecção, porque amostras de MalwareBazaar e regras comunitárias de YARA alimentam o capítulo 18.

Um ponto de amarração final com o capítulo 22 (Compartilhamento e Colaboração): tudo que a organização valida com telemetria própria vira candidato a contribuição de volta para a comunidade, em TLP adequado. O ciclo de consumo aberto e devolução validada é o que constrói reputação de analista e de organização, e reputação é a moeda que abre acesso às fontes fechadas tratadas na próxima nota.