Hackers Found a Domain the Internet Was Never Supposed to Distrust—Now They're Using It to Phish You

There are domains the internet was designed to trust unconditionally. The .arpa top level domain is one of them. Reserved exclusively for technical infrastructure operations like reverse DNS lookups, .arpa was never meant to host websites, serve content, or interact with end users in any way. It exists in the plumbing layer of the internet, invisible to most people and deliberately excluded from the threat models of most security tools.

Hackers found a way to weaponize that implicit trust. In March 2026, researchers at Infoblox published findings on a phishing campaign that abuses .arpa domains and IPv6 reverse DNS records to host credential harvesting sites and brand impersonation pages. The technique bypasses URL filtering, domain reputation scoring, and email security gateways because .arpa is treated as critical infrastructure that should never be blocked. Multiple outlets including BleepingComputer, CybersecurityNews, and ThaiCERT have confirmed the campaign.

What .arpa Is and Why It Exists

The .arpa domain is a special use top level domain managed by the Internet Assigned Numbers Authority (IANA). It serves a single purpose: infrastructure operations. The most important of these is reverse DNS, the process of resolving an IP address back to a hostname.

When you send an email, the receiving mail server often performs a reverse DNS lookup on your sending IP address. This check is a fundamental part of how email authentication works. For IPv4 addresses, these lookups happen under the in-addr.arpa zone. For IPv6 addresses, they happen under ip6.arpa.

The key detail is that .arpa is not a registrable domain in the traditional sense. You cannot go to a registrar and buy a .arpa address like you would a .com or .net. Ownership of records under .arpa is delegated through the IP address allocation system. If you control an IP address block, you can create reverse DNS records for it. This is normally a routine administrative task. But in the IPv6 world, where address space is vast and tunnel brokers hand out prefixes freely, this administrative capability becomes an attack surface.

How the Attack Works

The attack chain is technically elegant and exploits multiple layers of internet infrastructure. Here is how it unfolds step by step.

First, the attackers sign up for an IPv6 tunnel broker service. Providers like Hurricane Electric offer free IPv6 tunneling, which assigns users a routable /48 or /64 IPv6 prefix. This is a legitimate service used by developers and network engineers who need IPv6 connectivity through an IPv4 only network. The registration process is minimal and often requires nothing more than an email address.

Second, because the attackers now control an IPv6 address block, they gain the ability to create reverse DNS records for any address within that block. These records live under the ip6.arpa zone. The attackers configure their reverse DNS entries to point to hostnames they control, effectively creating functional domain names within the .arpa namespace.

Third, the attackers delegate DNS authority for their ip6.arpa subzones to Cloudflare nameservers. Cloudflare provides free DNS hosting, and the attackers use it to manage their .arpa records with high availability and performance. This also gives their phishing infrastructure the benefit of Cloudflare's global CDN.

Fourth, the attackers generate SSL certificates for their .arpa hostnames. Certificate authorities will issue certificates for any domain that passes domain validation, and .arpa hostnames are no exception. With a valid HTTPS certificate, the phishing pages display the familiar padlock icon in the browser, reinforcing the appearance of legitimacy.

Finally, the attackers create deeply nested, randomized subdomains under their ip6.arpa zones. An example URL might look something like https://a3f2.b7c1.d4e8.9.0.1.2.3.4.5.6.7.8.9.a.b.ip6.arpa. These addresses are long, complex, and nearly impossible for a human to evaluate at a glance. They are also generated programmatically, allowing the attackers to spin up and discard phishing pages rapidly.

Why Security Tools Miss It

The reason this technique works is not a single vulnerability but a systemic blind spot. Security products have been trained, configured, and optimized to evaluate threats within the standard domain name system. The .arpa TLD exists outside that evaluation framework for several compounding reasons.

Implicit trust. Most URL filtering systems, secure web gateways, and email security appliances treat .arpa as infrastructure. Blocking .arpa domains risks breaking reverse DNS lookups, which would disrupt email delivery, network diagnostics, and other critical operations. As a result, .arpa is typically allowlisted or simply excluded from threat analysis altogether.

No WHOIS data. Traditional domain reputation systems rely on WHOIS records to assess risk. They check registration dates, registrant information, and historical ownership changes. The .arpa namespace has none of this. There are no registrars, no registration dates, and no ownership records in the conventional sense. Reputation scoring engines have no data to work with, so these domains receive either a neutral or trusted score by default.

No threat intelligence coverage. Threat intelligence feeds and blocklists are built from observed malicious activity on registrable domains. Because .arpa has historically never been used for hosting content, it rarely appears in threat intelligence databases. The domains are effectively invisible to the global security ecosystem.

Certificate transparency does not help. Even though the SSL certificates are logged in public certificate transparency logs, the volume of legitimate ip6.arpa certificates makes it impractical to flag every new one as suspicious. Automated monitoring would generate overwhelming false positives.

What the Phishing Campaigns Look Like

The phishing emails themselves use proven social engineering tactics. Infoblox documented campaigns that impersonate well known brands, promise free gifts or rewards, and warn recipients about expired cloud storage or account suspensions. The lures are designed to create urgency and bypass critical thinking.

One technique is particularly effective: the messages use a single image as the entire email body. The image contains what appears to be formatted text, logos, and call to action buttons, but it is actually a single graphic file with a hidden hyperlink covering the entire image. When the recipient clicks anywhere on the email, they are redirected to the .arpa hosted phishing page.

This image based approach serves two purposes. First, it prevents email security scanners from parsing the text content, since there is no text to analyze. Keyword based filters and natural language processing engines see nothing suspicious. Second, it prevents the recipient from seeing the destination URL before clicking. The .arpa domain only appears in the browser address bar after the click, and by that point most users are already interacting with the fake login page.

The phishing landing pages themselves are convincing replicas of login portals from major email providers, cloud storage services, and enterprise platforms. With valid SSL certificates and fast loading times courtesy of Cloudflare, they are nearly indistinguishable from the real thing.

How to Defend Against .arpa Phishing

Defending against this technique requires security teams to address the blind spot directly. Here are concrete steps for organizations and individuals.

• Monitor DNS queries for anomalous .arpa activity. Configure your DNS resolver or security information and event management (SIEM) system to alert on outbound requests to ip6.arpa hostnames that resolve to web content. Legitimate reverse DNS queries follow predictable patterns. Queries that resolve to A or AAAA records pointing to web servers are a strong indicator of abuse.
• Block web traffic to .arpa hostnames at the proxy layer. There is no legitimate reason for a browser to load a webpage hosted on an ip6.arpa domain. Configure your secure web gateway or proxy to block HTTP and HTTPS requests to any .arpa hostname. This is a low risk, high impact control.
• Enforce DMARC, SPF, and DKIM at reject level. While these email authentication protocols do not directly prevent .arpa abuse, they reduce the ability of attackers to spoof trusted sender domains in the phishing emails that deliver .arpa links. Set your DMARC policy to p=reject and ensure all legitimate sending sources are covered.
• Scrutinize image only emails. Configure your email gateway to flag or quarantine messages where the body consists entirely of a single image with no parseable text. This is a well established indicator of phishing regardless of the destination domain.
• Review IPv6 tunnel broker usage. If your organization uses Hurricane Electric or similar tunnel brokers, audit who has access and what reverse DNS records have been created. If you do not use IPv6 tunneling, consider blocking traffic to known tunnel broker endpoints at your network perimeter.
• Train users to inspect URLs after clicking. Security awareness training should emphasize checking the address bar after clicking any email link. If the URL contains ip6.arpa or shows an unusually long, randomized hostname, close the tab immediately and report the email.

The Bigger Lesson

The .arpa phishing technique reveals a fundamental tension in internet security. The protocols and domains built for infrastructure trust were designed in an era when the attack surface was orders of magnitude smaller. Reverse DNS, IPv6 tunneling, and certificate issuance all work exactly as designed. The problem is that their designers never anticipated they would be chained together to host phishing pages.

This is the pattern that repeats across every major phishing innovation: attackers find a gap between what security tools inspect and what the underlying internet infrastructure permits. The gap between allowlisted infrastructure domains and actual threat coverage is now a proven attack vector.

The Infoblox research should serve as a wake up call for security teams and vendors alike. Any domain that receives implicit trust from security tools without active monitoring is a liability. The .arpa namespace is just the latest example. If your threat model assumes that infrastructure domains are safe, it is time to update that assumption. The attackers already have.