ASN, BGP e Relacionamentos de Rede

Nota da seção "06 - Análise de Infraestrutura" do capítulo 03 (Indicadores de Ameaças: IOC, IOA, IOB, IOE).
Explica ASN e anúncio BGP, mostra como consultar quem anuncia cada prefixo, como ler histórico de rotas, identificar hijacking e reconhecer hospedagem à prova de balas.
Dialoga com as notas de DNS Passivo, Hosting e CDN e Pivoting da mesma seção, e com o Diamond Model do capítulo 04.

1. Contexto e Posicionamento na Biblioteca

Todo indicador de rede termina, mais cedo ou mais tarde, em um endereço IP, e todo endereço IP só alcança a internet porque algum sistema autônomo o anuncia. O ASN (Autonomous System Number, número de sistema autônomo) é a identidade de rede que responde à pergunta que o IP isolado esconde: qual organização controla esta porção da internet, sob qual política de roteamento, e que mais ela anuncia ao mundo. Enquanto o DNS passivo da nota anterior mostra onde os nomes apontaram e a nota de Hosting e CDN mostra o que fisicamente habita cada endereço, a leitura de ASN e BGP mostra quem tem o comando de roteamento daquele espaço, e essa camada sobrevive à troca de domínios e de endereços com mais frequência que qualquer outra.

Na biblioteca, esta nota fecha a tríade de fontes de infraestrutura da subpasta e prepara o pivoting formalizado na nota seguinte, onde o ASN aparece como vértice denso que exige janela temporal e raridade para gerar arestas confiáveis. Os dados de anúncio alimentam o enriquecimento do pipeline CTI.5 na seção 15, a leitura de reputação de rede usada no TH.10 e a distinção entre origem e edge de CDN que a nota de Hosting construiu. O leitor deve sair daqui capaz de resolver qualquer IP para seu ASN, ler o histórico de anúncios de um prefixo, reconhecer sinais de hijacking e usar reputação de rede como fator ponderado, nunca como veredito.

2. ASN, Prefixos e o Anúncio BGP

Um sistema autônomo é um conjunto de redes operando sob administração única e política de roteamento comum, identificado por um ASN de 32 bits atribuído por um dos cinco RIRs (Registries Regionais de Internet): ARIN, RIPE NCC, APNIC, LACNIC e AFRINIC. Cada sistema autônomo anuncia blocos de endereços, os prefixos, por meio do BGP (Border Gateway Protocol), e é esse anúncio que torna o bloco alcançável. A relação entre o ASN e o prefixo anunciado, o chamado origin AS, é o dado central desta nota: quando o analista pergunta quem anuncia o quê, está perguntando qual origem está propalando cada prefixo para o mundo, com qual histórico e com qual estabilidade.

Três nuances do modelo importam diretamente para CTI. Primeiro, anúncio e posse são coisas diferentes: um prefixo pode ser alocado a uma organização e anunciado por outra, comportamento legítimo em serviços gerenciados e armadilha clássica na análise. Segundo, um mesmo prefixo pode ser anunciado por múltiplas origens, situação chamada de MOAS, que em roteamento comercial é normal e em contexto de campanha é sinal de hijacking ou de migração furtiva. Terceiro, a data de alocação do ASN e do prefixo pelo RIR é pública e datada, o que permite distinguir uma rede consolidada de um operador recém-chegado que já nasceu anunciando infraestrutura hostil.

Para o CTI, três registros complementares ao anúncio valem consulta rotineira. A alocação do ASN e dos prefixos junto ao RIR é pública e datada, e permite distinguir rede consolidada de operador recém-chegado; o mercado de transferência de ASN e de blocos, formalizado nos últimos anos, permite que operadores comprem espaço com histórico limpo, o que reduz o valor da idade como sinal isolado; e os registros de roteamento comunitários, como o RADb, mostram as políticas de roteamento declaradas, úteis para confirmar se um anúncio é esperado ou anômalo. Nenhum desses registros prova intenção, e todos datam a infraestrutura, que é justamente o que a análise temporal da campanha precisa.

3. Consultando Quem Anuncia o Quê

A ferramenta de referência para resolver IP em ASN é o serviço IP-to-ASN do Team Cymru, acessível pelo protocolo WHOIS na porta 43, com modo verbose que devolve AS, prefixo, país, registro regional e data de alocação. O modo em lote aceita listas inteiras em uma única sessão, o que o torna adequado a enriquecimento de pipeline. Para explorar a rede, o kit de BGP da Hurricane Electric, no bgp.he.net, apresenta por ASN o número de prefixos anunciados, os pares de troca de rotas e há quanto tempo o anúncio está no ar, e os looking glasses públicos permitem conferir rotas de pontos de vista arbitrários. As APIs do RIPEstat empacotam essas consultas em formato JSON previsível para automação.

# IP para ASN com detalhes, via Team Cymru
whois -h whois.cymru.com " -v 203.0.113.44"

# Consulta em lote por sessao unica na porta 43
printf 'begin\nverbose\n203.0.113.44\n198.51.100.12\nend\n' \
  | nc whois.cymru.com 43

# Panorama do prefixo: origens que o anunciam e bloco alocado
curl -s "https://stat.ripe.net/data/prefix-overview/data.json?resource=203.0.113.44" \
  | jq '.data | {origens: [.asns[] | {asn, holder}], blocos: [.block.resources[]]}'

# Prefixos anunciados por um ASN especifico
curl -s "https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS204915" \
  | jq -r '.data.prefixes[].prefix'

Os looking glasses complementam o quadro quando a pergunta é de ponto de vista: ver a rota que um prefixo tem na tabela de um AS específico, testar alcançabilidade de um vantage diferente ou conferir se a propalação chegou ao mundo. O uso corriqueiro do analista é confirmar que o anúncio observado no Team Cymru aparece de forma consistente em pontos de vista independentes, porque uma origem vista por um único lugar pode ser efeito de propagação parcial ou de anúncio restrito a peer específico, e ambos os casos mudam a interpretação da janela temporal.

# Endpoints RIPEstat usados na rotina de enriquecimento
prefix-overview      # origens e blocos de um IP ou prefixo
announced-prefixes   # todos os prefixos anunciados por um ASN
routing-history      # linha do tempo de anuncios do prefixo
ris-prefixes         # prefixos vistos pela rede de sondas RIS

A leitura do resultado deve sempre cruzar três campos antes de qualquer conclusão: o ASN de origem, a data de alocação do bloco e a identidade do holder. Um prefixo alocado na semana, anunciado por um ASN jovem e hospedando páginas de credenciais configura um perfil de risco que nenhum campo isolado produz, e é esse cruzamento que o enriquecimento automático deve registrar junto ao indicador, com carimbo de tempo, conforme a disciplina de metadados estabelecida pela nota de Hosting e CDN.

4. Histórico de Anúncios e Sinais Temporais

O histórico de anúncios BGP é uma linha do tempo de roteamento, e o RIPEstat a expõe por prefixo e por ASN: quando o anúncio começou, quantas origens o prefixo teve, em que momento houve troca de origem e períodos em que o prefixo desapareceu da tabela global. Cruzado com a linha do tempo de resolução do DNS passivo, esse histórico conta a biografia da infraestrutura: o domínio que resolveu pela primeira vez na mesma semana em que o prefixo foi anunciado indica infraestrutura recém-comprada para a campanha, enquanto a resolução sobre prefixo maduro sugere aluguel em rede compartilhada, com todas as cautelas que a nota de Hosting impõe.

O sinal temporal mais produtivo é o ASN jovem em operação hostil. Operadores profissionais compram ASN e espaço de endereçamento próprios quando precisam de controle total do roteamento, e o perfil típico é um registro recente em RIR, alocação de um ou poucos prefixos, anúncio imediato e padrão de uso compatível com phishing ou C2 em poucos dias. O inverso também informa: a troca de origem de um prefixo historicamente estável, com o novo ASN sem histórico, é o retrato de migração furtiva ou de apropriação de rota, e merece alerta mesmo antes de qualquer evidência de conteúdo malicioso.

O exemplo abaixo ilustra a leitura cruzada que caracteriza essa seção. O conteúdo é fictício, mas a sequência de marcos é o perfil canônico de infraestrutura comprada para uma campanha, e é ele que o pipeline de enriquecimento deve capturar automaticamente.

2025-03-01  ASN novo alocado ao holder em RIR europeu
2025-03-03  Prefixo /24 do novo ASN comeca a ser anunciado
2025-03-03  Certificado TLS emitido para o dominio da campanha
2025-03-04  Primeira resolucao visivel em base de pDNS
2025-03-05  Primeira entrega de e-mail da campanha observada

Quatro marcos em cinco dias deixam pouca margem para leitura benigna: registro, roteamento, certificado e resolução nascem juntos, e o quinto marco confirma o propósito de entrega. O mesmo padrão, observado com espaçamento de meses entre os marcos, descreve uma empresa real que provisionou infraestrutura aos poucos, e é a distância entre os marcos, e não cada marco isolado, que carrega o sinal.

5. Hijacking de Prefixo e Ameaças ao Roteamento

O hijacking de prefixo ocorre quando um sistema autônomo anuncia blocos que não lhe pertencem, e o BGP, por desenho, aceita a propalação se ela parecer mais específica ou mais curta. As consequências operacionais variam: o anúncio mais específico intercepta o tráfego do prefixo legítimo e permite inspeção ou roubo em trânsito; o anúncio igualmente específico por múltiplas origens fragmenta o tráfego de forma instável; e o vazamento acidental, o route leak, propala rotas inteiras por engano de configuração, como no episódio de 2008 em que um provedor paquistanês, ao implementar filtro interno, anunciou o prefixo do YouTube e retirou o serviço de grande parte do mundo. Para o CTI, o hijacking importa em três frentes: logs de origem podem registrar tráfego interceptado e não a origem real, a geolocalização por rede vira mentira durante o evento, e campanhas sofisticadas já operaram em espaço anunciado de forma abusiva justamente para confundir resposta e derrubada.

A defesa analítica combina detecção e contexto, e começa por nomear os eventos de roteamento com precisão, porque cada um tem leitura diferente. A tabela abaixo organiza os eventos que o monitoramento de roteamento produz, com a assinatura na tabela global e a interpretação correta para CTI.

Serviços de monitoramento de roteamento como o BGPStream alertam sobre MOAS súbitos, troca de origem e anúncio de prefixo não alocado, e a validação RPKI, na qual o operador legítimo publica ROAs que autorizam apenas sua própria origem, transforma anúncio inválido em sinal objetivo de manipulação. A organização que depende de provedores de nuvem deve ainda acompanhar os avisos de roteamento de seu provedor, porque o prefixo dela pode ser alvo mesmo sem que a equipe tenha tocado em qualquer configuração de roteamento.

6. Bulletproof Hosting e Ranges Problemáticos

Bulletproof hosting é o modelo de negócio no qual o provedor ignora notificações de abuso, não remove conteúdo reportado e, em muitos casos, protege ativamente o inquilino. O fenômeno é recorrente na literatura do setor, e conjuntos de ASNs aparecem repetidamente em relatórios públicos de campanhas de ransomware, stealer e phishing, com operadores que migram de registro para registro quando sancionados ou pressionados. O analista deve conhecer essa cartografia, mas usá-la com a precisão que a nota de Hosting exige: redes inteiras não são maliciosas, e o mesmo ASN que hospeda C2 documentado hospeda VPNs de consumidores e negócios legítimos que apenas alugaram espaço na rede errada.

A reputação de rede entra na operação como fator ponderado, e não como veredito, e se apoia em fontes objetivas. As listas DROP e EDROP do Spamhaus publicam espaços anunciados de forma abusiva ou apropriados, prontos para consumo em firewall e em enriquecimento; feeds comerciais atribuem risco por ASN e por prefixo; e a contagem própria de eventos de abuso observados pela organização constrói a reputação interna mais honesta de todas. O padrão de uso recomendado é o escore, com sinais medidos e pesos explícitos.

O escore é operacional, e não doutrinal: um IP em rede de risco alto soma pontos na triagem, um domínio recém-registrado nesse mesmo espaço soma mais, e a combinação, e não cada item, define a prioridade. A revisão dos pesos é trimestral, porque redes mudam de população e de operador, e um peso congelado envelhece para o lado do erro tanto quanto para o lado do acerto.

7. Uso Operacional: Pivoting, Reputação e Enriquecimento

No SIEM, o enriquecimento por ASN se materializa como lookup: uma tabela de mapeamento atualizada periodicamente e uma tabela de reputação alimentada por DROP, feeds e eventos internos. A consulta abaixo, em SPL, junta as duas camadas ao tráfego do dia e destaca destinos em redes hostis.

index=network earliest=-24h
| lookup asn_map ip AS dest_ip OUTPUT asn, as_name
| lookup reputacao_asn asn OUTPUT classificacao, risco
| where classificacao="hostil" or risco>=4
| stats count dc(src_ip) as clientes values(dest_port) as portas by dest_ip, asn, as_name
| sort - clientes

A mesma lógica em Sentinel usa watchlist com _GetWatchlist, e o princípio é idêntico em qualquer plataforma: o ASN é atributo derivado com data de validade, e o registro do carimbo de tempo do mapeamento é o que permite, meses depois, distinguir o que a rede era quando o evento aconteceu do que ela passou a ser.

let redes_hostis = _GetWatchlist('ASN-hostis')
| project ASN = tostring(['ASN']);
DeviceNetworkEvents
| where Timestamp > ago(1d)
| where ASN in ((redes_hostis))  // campo ASN enriquecido na ingestao
| summarize chamadas = count(), clientes = dcount(DeviceName)
    by RemoteIP, ASN, InitiatingProcessFileName
| order by chamadas desc

Essa disciplina de metadados é a mesma exigida pela nota de Hosting e pela nota de Pivoting, e é o que impede que mudanças de mercado sejam lidas como laços de atribuição.

8. Limitações e Erros Comuns

• Tratar mapeamento IP-ASN como imutável: remanejamentos de prefixo acontecem, e o carimbo de tempo do mapeamento é obrigatório em qualquer registro analítico.
• Confundir posse com anúncio: o holder do bloco e a origem do anúncio são papéis diferentes, e o inquilino hostil pode estar em rede de terceiro legítimo.
• Aplicar reputação de ASN como veredito: redes grandes e baratas misturam populações, e bloquear ASN inteiro de nuvem causa dano operacional imediato.
• Ignorar anycast e CDN: um mesmo prefixo anunciado globalmente atende milhares de inquilinos, e a leitura por ASN precisa da camada de SNI e certificado da nota de Hosting.
• Ler histórico BGP sem contexto de incidentes conhecidos: hijackings passados poluem o histórico do prefixo, e o evento de roteamento documentado explica o que pareceria rotação criminosa.
• Raspar o bgp.he.net sem controle: o site limita acesso automatizado; correção: usar as APIs do RIPEstat e o serviço do Team Cymru para automação, reservando a interface para exploração manual.
• Usar geolocalização por ASN como localização física: a geografia do registro não é a do servidor, e afirmar país de origem apenas pela rede produz erro em relatório formal.

9. Integração com o Restante da Biblioteca

A leitura de ASN é o terceiro eixo da subpasta de infraestrutura e amarra as duas notas anteriores: o DNS passivo fornece a linha do tempo de resolução que o histórico de anúncios contextualiza, e a classificação de hospedagem fornece a distinção entre origem e edge que evita atribuir a rede o que pertence ao inquilino. No capítulo 04, o Diamond Model trata o ASN como vértice de infraestrutura densa, e a nota de Pivoting e Correlação codifica a regra de travessia: vértice denso exige raridade e janela temporal para gerar aresta confiável. Na seção 15, o enriquecimento alimenta o CTI.5, a reputação pondera a triagem do TH.10 e o bloqueio seletivo dos ranges isolados aparece nas regras de resposta do AUT.5.

O ativo de longo prazo que esta nota deixa é a tabela de inteligência de redes própria da organização: para cada ASN relevante observado, os campos mínimos são identidade do holder, data de alocação, campanhas em que apareceu, eventos de abuso contados internamente, classificação vigente e data de revalidação. Revisada trimestralmente, essa tabela vira memória institucional que sobrevive à troca de analistas e a feeds que mudam de política, e é ela que transforma a consulta pontual de ASN, técnica ensinada aqui, em capacidade contínua de leitura do roteamento global.