Sumário executivo

O TLD ip6.arpa existe para uma finalidade: pesquisas reversas de DNS. Ele nunca foi projetado para hospedar sites, veicular conteúdo ou apontar para endereços IPv4. Isso o torna invisível para a maioria das ferramentas de segurança — e é exatamente por isso que os agentes de ameaças começaram a usá-lo.

Em fevereiro de 2026, Infoblox documentaram a conhecida exploração desse ponto cego. Os atacantes estavam colocando registros curinga A dentro das zonas de DNS reverso ip6.arpa e, em seguida, incorporando essas zonas como URLs em e-mails de phishing. Como o ip6.arpa não tem reputação de domínio, os gateways de e-mail e os scanners de URL passam por eles sem inspeção.

Após uma investigação mais aprofundada, executamos uma verificação global do BGP com 127.906 prefixos IPv6 para validar e ampliar as descobertas da Infoblox. Confirmamos que a campanha original ainda está ativa e encontramos uma segunda campanha independente em execução em uma infraestrutura completamente diferente: um servidor em Frankfurt, Alemanha, com um ASN diferente, sem proxy da Cloudflare.

Essa segunda zona, 0.d.7.2.7.0.1.b.e.0.a.2.ip6.arpa, é resolvida para 85.215.34.119. Ele estava ativo durante nossa janela de verificação, está ativo desde pelo menos 29 de janeiro de 2026 e, no momento da escrita, permanece ativo com os registros NS da Cloudflare em vigor.

Como o ataque funciona

Entender por que os agentes de ameaças usam essa técnica ajuda a entender o que o ip6.arpa deve fazer. Quando um servidor de e-mail recebe um e-mail, ele geralmente realiza uma pesquisa reversa de DNS no IP do remetente, consultando o namespace ip6.arpa para encontrar o nome do host associado. As ferramentas de segurança tratam esse namespace como um encanamento de infraestrutura, não como uma fonte de URLs maliciosos.

Primeiro, eles obtêm um prefixo IPv6/48 gratuito de um provedor de túneis como a Hurricane Electric. Isso lhes dá controle administrativo sobre a zona DNS reversa ip6.arpa correspondente — uma zona que, pelo design da RFC, só deveria conter registros PTR mapeando endereços de volta para nomes de host.

<malicious-ip>Em vez disso, eles definiram um registro curinga A: * IN A. Agora, todos os subdomínios possíveis nessa zona são resolvidos para o servidor. Um URL como xqjerorqxs.d.d.e.0.6.3.0.0.0.7.4.0.1.0.2.ip6.arpa é um DNS tecnicamente válido, resolve para um IP real e parece aos scanners automatizados uma consulta de PTR de rotina em vez de um link de phishing.

Cada e-mail de phishing incorpora um prefixo de subdomínio diferente gerado aleatoriamente. Cada destinatário recebe um URL exclusivo. Como a zona tem um registro curinga A, todas elas são resolvidas sem que o invasor registre nada. As listas de bloqueio em massa são inúteis: quando um analista extrai e bloqueia um subdomínio, todas as outras vítimas já receberam um diferente.
‍

Qualquer resposta de registro A de uma zona ip6.arpa é uma violação de RFC. Não há nenhum caso de uso legítimo. Taxa de falsos positivos: 0%.

Análise da infraestrutura e campanhas observadas

Para investigar mais detalhadamente, testamos a tabela de roteamento BGP IPv6 global. Na primeira etapa, retirou todos os prefixos //48 e mais específicos do BGP.tools no total, converteu cada um em sua zona de nibble ip6.arpa correspondente e verificou os servidores de nomes da Cloudflare. Um NS da Cloudflare em uma zona ip6.arpa é o sinal de preparação: o atacante delegou a zona, pronto para adicionar registros A quando uma campanha for lançada.

O primeiro estágio retornou 384 zonas com o Cloudflare NS. O estágio dois acionou 100 sondas de subdomínio geradas aleatoriamente em cada uma dessas zonas. Um curinga Uma resposta de registro confirmou que uma zona é ativamente maliciosa.

Das 127.906 zonas testadas: 384 suspeitas, 2 confirmadas como maliciosas.

O primeiro impacto foi a zona documentada pela Infoblox: d.d.e.0.6.3.0.0.0.7.4.0.1.0.2.ip6.arpa, correspondente ao prefixo IPv6 da Hurricane Electric 2001:470:63 d: :/48. Ele estava ativo durante nossa verificação, com 100 das 100 sondas de subdomínio retornando registros A para os IPs edge da Cloudflare 104.21.3.194 e 172.67.131.33.

Essa zona esteve intermitentemente ativa e inativa em várias execuções de escaneamento em 12 de março de 2026, o que é consistente com a ativação baseada em campanha. O invasor ativa o curinga ao enviar e-mails de phishing e desativa entre campanhas, tornando o monitoramento passivo não confiável.

O segundo sucesso não estava na reportagem da Infoblox. A zona 0.d.7.2.7.0.1.b.e.0.a.2.ip6.arpa corresponde ao prefixo IPv6 2a0e:b 107:27 d0: :/48 e resolve para 85.215.34.119 — um único IP não CloudFlare em Frankfurt, Alemanha, hospedado na infraestrutura IONOS SE.

Diferentemente da Campanha A, essa zona não usa o Cloudflare como proxy. O IP do servidor de origem está diretamente exposto. Atualmente, a pilha de servidores é nginx + Plesk em um servidor gerenciado.

Conclusões

A semelhança estrutural entre a Campanha A e a Campanha B confirma fortemente a reutilização da técnica. Ambos usam os mesmos registros curinga A que aceitam prefixos arbitrários de subdomínio, ambos usam o Cloudflare NS para delegação de zona e ambos estavam ativos no mesmo dia.

Ambas as zonas maliciosas confirmadas representam 2 das 384 que passaram pela Fase 1 do nosso escaneamento. Os 382 restantes têm registros NS da Cloudflare nas zonas ip6.arpa, mas nenhum registro A ativo. Eles são encenados.

Essa é a descoberta mais significativa do ponto de vista defensivo. Um invasor não precisa registrar um domínio ou configurar um servidor no dia em que lança uma campanha. Eles podem organizar a infraestrutura em semanas

com antecedência, delegue a zona, aponte para a Cloudflare e espere. Quando estão prontos para enviar e-mails de phishing, eles adicionam o registro curinga A. A campanha é lançada em segundos. Quando terminam, eles o removem. A zona fica quieta novamente, mas continua armada.

O monitoramento dessas 382 zonas para ativação do registro A é diretamente acionável. Qualquer organização que executa o monitoramento de DNS pode alertar sobre as respostas do registro A de qualquer zona*.ip6.arpa. Qualquer uma dessas 382 zonas ativadas é um sinal de zero falso-positivo de que uma campanha foi lançada.

Note: As of 2026-03-12, the wildcard A record on 0.d.7.2.7.0.1.b.e.0.a.2.ip6.arpa remains active and resolving to 85.215.34.119. The DNS infrastructure for Campaign B is fully operational. However, no phishing email, TDS redirect chain, or phishing landing page directly linked to this zone has been observed by our team. Active probes of 85.215.34.119 returned a Plesk default page. This does not rule out a TDS-gated or referrer-filtered landing page that would only activate via the correct attack chain. The malicious intent is confirmed by DNS,  a wildcard A record on ip6.arpa has no legitimate use case under any RFC but downstream victim-facing infrastructure has not been directly observed.

Impacto

• Evasão das defesas tradicionais: Os invasores podem contornar com sucesso gateways de e-mail e scanners de URL baseados em reputação porque o namespace ip6.arpa é tratado universalmente pelas ferramentas de segurança como um encanamento de infraestrutura benigno, em vez de um host de conteúdo malicioso.
• Ineficácia completa das listas de bloqueio: Ao colocar registros curinga A (* IN A) em suas zonas IPv6 delegadas, os agentes de ameaças podem gerar um subdomínio exclusivo e aleatório para cada vítima alvo. Quando um analista identifica e bloqueia um URL malicioso, a lista já está obsoleta.
• Pré-preparação silenciosa da infraestrutura de ataque: Os agentes de ameaças estão armando a infraestrutura com semanas de antecedência, delegando zonas a CDNs comerciais (como a Cloudflare) e deixando-as inativas.

Recomendações

• Implemente bloqueio estrito de anomalias de DNS: configure zonas de política de resposta (RPZ) e monitores de DNS para bloquear e alertar sobre qualquer resposta de registro A ou AAAA para domínios.arpa. De acordo com o design do RFC, as zonas ip6.arpa devem retornar somente registros PTR. Qualquer resolução de registro A nesse namespace é uma violação explícita da RFC.
• Melhore a extração de URL e Regex do Email Gateway: Atualize os gateways de segurança de e-mail para extrair e inspecionar agressivamente os hiperlinks ocultos nas tags de imagem (uma tática de evasão comum nesta campanha). Aplique regras de regex personalizadas (por exemplo, [\ w] {6,}\. ([\ da-f]\.) {8,} ip6\ .arpa) para identificar e bloquear subdomínios do padrão DGA prefixados para reverter cadeias de DNS.
• Monitor de delegações de zonas anormais (Infraestrutura em estágios): monitore ativamente a telemetria de DNS para zonas.arpa delegadas que são resolvidas por meio de servidores de nomes CDN comerciais (por exemplo, Cloudflare NS). Isso é operacionalmente anormal e fornece um sinal de alerta precoce, permitindo que os defensores rastreiem e bloqueiem a infraestrutura preparada antes que os registros curinga A sejam ativados.
• Aplique heurística a iscas e caminhos de rede: Ajuste a heurística de filtragem de e-mail para sinalizar mensagens em que o único conteúdo clicável é uma imagem sem texto de URL visível, pois isso se correlaciona altamente com esse estilo de ataque. Além disso, trate os e-mails recebidos retransmitidos por meio de blocos de rede conhecidos e gratuitos do provedor de túneis IPv6 como um sinal de risco.

Conclusão

A técnica de abuso ip6.arpa documentada pela Infoblox em fevereiro de 2026 não é uma campanha isolada. Nossa análise global independente descobriu que ele era usado ativamente para sugerir campanhas independentes.

As 382 zonas escalonadas que encontramos são a descoberta operacionalmente mais significativa. Eles não são artefatos históricos, mas podem ser tratados como armas carregadas. Um invasor que já tenha feito o trabalho de delegar uma zona ao Cloudflare NS pode lançar uma campanha com uma única alteração no registro de DNS, mais rápido do que qualquer lista de bloqueio pode responder.

Indicadores de compromisso