Our threat intelligence team recently published a detailed analysis of residential proxy abuse\u2014tracking the actors, mapping the infrastructure and documenting the scale at which these networks are being exploited. It is excellent research, and if you haven\u2019t read it, you should. But I want to make an argument that goes beyond what threat intelligence alone can do, because I think the more important conversation is about what we can actually prevent.<\/p>\n
Threat intelligence tells you what is happening. DNS tells you what happens next\u2014and more importantly, it is the layer where you can stop it.<\/p>\n
A residential proxy routes internet traffic through a real consumer IP address\u2014a home broadband connection, a mobile device, a domestic router. For the recipient of that traffic, it looks entirely legitimate. It passes every IP reputation check. It bypasses geolocation filtering. It looks, to every downstream control, like an ordinary person browsing the web.<\/p>\n
That is enormously useful to threat actors. State-sponsored groups use residential proxies to conduct intelligence operations behind a veil of legitimacy. Ransomware operators use them to route command-and-control traffic through infrastructure that won\u2019t trigger IP blocklists. Credential thieves use them to run large-scale stuffing attacks against corporate VPNs and government portals without triggering rate limits.<\/p>\n
The National Cyber Security Centre\u2019s (NCSC) April 2026 advisory on APT28 made this concrete in a way that should concern everyone in the security community: Russian military intelligence has been systematically compromising U.K. consumer customer premise equipment (CPE) devices\u2014routers, gateways, set-top boxes\u2014to build residential proxy infrastructure at scale. The subscriber doesn\u2019t know. The ISP can\u2019t see it at the IP layer. And the intelligence operation runs undetected behind a pool of legitimate British residential addresses.<\/p>\n
It is worth being precise about how residential proxy networks are built, because the countermeasures depend on the enrollment vector.<\/p>\n
The first is the hostile-state CPE compromise scenario described above, exploiting default credentials and unpatched firmware to turn subscriber gateway hardware into a relay node.<\/p>\n
The second is the malicious SDK route. Our research into the Kimwolf threat actor documented how proxy-monetization SDKs, embedded in widely distributed consumer apps and browser extensions, silently enroll devices as proxy endpoints. The user thinks they\u2019re getting a free VPN. The proxy operator is selling their IP address and bandwidth\u2014and in the Kimwolf case, using the enrolled device to probe local enterprise networks for further vulnerable targets.<\/p>\n
The third is the deceptive-but-voluntary route\u2014free privacy tools, ad blockers and \u201csecure browsing\u201d extensions that are upfront (in the small print) about using your connection in exchange for the free service, but where meaningful consent is effectively absent.<\/p>\n
Each of these enrollment vectors has a DNS signature. And that is where the opportunity lies.<\/p>\n
Every residential proxy operator, regardless of how they have structured their infrastructure, shares a single dependency: they must operate domains. Enrollment endpoints, tasking channels, persistence mechanisms, the entire operational architecture of a residential proxy network runs on DNS. Enrolled devices query those domains to register, to receive instructions, to relay traffic, to phone home.<\/p>\n
This creates an exploitable chokepoint that no other security layer can match. If a device cannot resolve the domain names associated with proxy operator control infrastructure, it cannot be enrolled, cannot be tasked and cannot be maintained as a proxy endpoint. Blocking at the DNS layer requires no endpoint access. It doesn\u2019t depend on identifying the malicious process. It works regardless of whether the device is managed or unmanaged, patched or unpatched, enterprise or consumer.<\/p>\n
This is the case for Protective DNS (PDNS) as the primary countermeasure, not instead of threat intelligence, but built on top of it. Intelligence identifies proxy operator infrastructure during its staging phase, before it has been used against any victim. PDNS converts that intelligence into a block at the resolver level, applied across every device that resolves through the protected infrastructure. The intelligence and the enforcement mechanism are not separable, but it is the enforcement that creates the protection.<\/p>\n
There are really two distinct problems here, and governments need to address both.<\/p>\n
The first is about employees of public sector and critical infrastructure organizations. A government worker connecting to a corporate system from home, on a network where the CPE has been quietly enrolled as a proxy endpoint by APT28, is issuing DNS queries that are being resolved by adversary-controlled infrastructure. Nothing about the device has been compromised. No malware has been installed. The attack exploits the implicit trust that every operating system places in the DNS resolver advertised by the local network.<\/p>\n
The fix is conceptually simple: ensure managed government devices only resolve DNS through verified, trusted PDNS infrastructure, using encrypted DNS transport\u2014DNS over TLS or DNS over HTTPS\u2014that prevents interception even when the underlying network is hostile. This is what Zero Trust DNS means in practice. Not identity-based access controls for applications. Not endpoint compliance checks. DNS itself, locked down to a trusted resolver that cannot be circumvented by a compromised gateway.<\/p>\n
The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-81r3, published in March 2026, now recommends exactly this for U.S. federal systems. The same logic applies to every government network in every jurisdiction.<\/p>\n
The second conversation is about citizens. Ordinary people cannot be expected to manage their own DNS security. The answer here is ISP-level PDNS\u2014a resolver service provisioned to subscribers by their ISP that filters out proxy operator infrastructure, malicious domains and command-and-control endpoints before any connection is established. The subscriber does nothing differently. The protection is automatic. And crucially, the DNS telemetry generated by an ISP resolver monitoring millions of subscriber queries is the most valuable national-scale detection resource for residential proxy compromise that currently exists.<\/p>\n
Sceptics might argue that ISP-level PDNS at national scale is a concept rather than a proven reality. The evidence from two allied nations suggests otherwise, and the results are striking.<\/p>\n
Ukraine implemented its national PDNS in 2023, deploying it across more than 320 Ukrainian internet service providers to provide DNS-layer phishing filtering for all subscribers. The results were immediate. Ukrainian citizens reported a 30 to 40 percent reduction in financial phishing fraud in the first month of operation alone. Not in the first year. In the first month.<\/p>\n
Latvia has gone further. At CYBERUK 2026 in Glasgow, the U.K. government\u2019s premier cybersecurity conference, Baiba Kaskina, general manager of CERT.LV, Latvia\u2019s national cybersecurity authority, delivered what amounted to a challenge to every government and regulator in the room.<\/p>\n
2.5 billion. In three months. From a country of under two million people.<\/p>\n
Neither of these programs is experimental. They are operational, measurable and directly applicable to larger nations with more complex ISP ecosystems. Estonia and Lithuania operate equivalent programs. The Baltic states have collectively demonstrated that national ISP PDNS works\u2014not in theory, but in practice, with outcomes that any government seeking to disrupt residential proxy networks and protect citizens from DNS-based fraud should find impossible to ignore.<\/p>\n
The question for governments and regulators and governments in other countries is not whether ISP-level PDNS is technically feasible. It demonstrably is. The question is whether there is the political will to require it.<\/p>\n
The residential proxy threat does not resolve itself through voluntary action. The evidence from every national PDNS deployment to date is that regulatory mandate or government funding is the critical enabler. ISPs have legitimate business reasons to be cautious about implementing new DNS infrastructure\u2014operational cost, complexity and concerns about government overreach on subscriber traffic are all real factors. Without a clear regulatory signal, the commercial incentive to act is weak.<\/p>\n
This is where regulators and policymakers have a specific, non-delegable role.<\/p>\n
For communications regulators, the residential proxy problem provides a compelling, evidence-backed rationale for DNS security obligations within telecommunications security frameworks. The model already exists: ISPs are required to block child sexual abuse material at the DNS layer in multiple jurisdictions. The extension of that DNS-layer enforcement obligation to known proxy operator infrastructure, malicious domains and residential proxy API endpoints is technically straightforward and legally analogous.<\/p>\n
The U.K.\u2019s Telecoms Security Act and the Code of Practice developed under it create exactly the kind of framework within which such obligations can be established. Measure M24.05, which requires providers to block anomalous or potentially malicious CPE activity, is directly applicable to the DNS hijacking and CPE compromise described in the NCSC\u2019s APT28 advisory. An ISP operating PDNS at the resolver level is the network-level control that implements that measure. Ofcom has the tools. The question is whether it will use them.<\/p>\n
For national governments and cyber policy bodies, the ask is similarly specific. PDNS should be positioned not as an optional security enhancement but as a baseline national security infrastructure control, as NIST SP 800-81r3 now formally recommends. Government PDNS for public sector agencies should be extended and deepened. National PDNS via ISP infrastructure should be actively funded, mandated or incentivized. And the passive DNS telemetry generated by ISP resolvers should be recognized as a national intelligence asset, with governance frameworks that enable its contribution to national threat intelligence pools without creating disproportionate privacy risks for subscribers.<\/p>\n
The HardenStance Telco Strategies for Consumer Security 2026 report identifies Protective DNS as the fastest-growing consumer security service being deployed by telecommunications operators globally, with over 80 network-based security contracts awarded in 2023\u20132025, more than endpoint security and home router security combined. The market is forecast to exceed $600 million by 2030. Regulatory drivers are explicitly identified as the primary factor behind this momentum. Policy shapes markets. The market is ready to move.<\/p>\n
Threat intelligence without a law enforcement consumer is analysis in a vacuum. One of the most significant but least discussed dividends of national ISP PDNS is what it does for security services and law enforcement, not just as a protective measure, but as an intelligence and investigation platform.<\/p>\n
When a national PDNS service is deployed across ISP infrastructure, it becomes, in effect, a nationwide threat intelligence sensor network. Every DNS query blocked, every residential proxy API endpoint queried from a subscriber device, every anomalous query pattern consistent with CPE compromise\u2014all of this generates telemetry that, properly aggregated and analyzed, provides security services with a near\u2013real-time picture of the national threat landscape that no other single data source can match.<\/p>\n
For security services like the Government Communications Headquarters (GCHQ), the National Security Agency (NSA) and their Five Eyes partners, this telemetry is operationally significant. The APT28 advisory documented a systematic campaign of CPE compromise targeting U.K. residential infrastructure. The ability to detect anomalous DNS patterns from compromised subscriber devices at ISP resolver level\u2014patterns consistent with proxy enrolment, command-and-control DNS signaling and the specific proxy operator infrastructure that Infoblox Threat Intel has catalogued\u2014gives security services an early warning capability that endpoint monitoring and perimeter controls cannot provide.<\/p>\n
For law enforcement, the value is equally concrete. Residential proxy infrastructure is the operational backbone of ransomware, investment fraud, credential theft and access broker operations. Disrupting those networks requires being able to identify them: to map proxy operator infrastructure, detect compromised subscriber devices and attribute proxy activity to specific threat actors and criminal organizations.<\/p>\n
DNS telemetry from national PDNS deployments provides law enforcement with exactly this capability. The patterns are observable. The DNS evidence is forensically robust. And Infoblox Threat Intel\u2019s DNS infrastructure analysis, which tracks proxy operator domains through registration patterns, name server configurations and infrastructure clustering during the staging phase, provides the pre-attack intelligence picture that operational law enforcement targeting requires.<\/p>\n
The Kimwolf investigation is a concrete example of this workflow. By tracking the DNS signaling domains that Kimwolf operators used to task enrolled proxy endpoints, Infoblox researchers were able to map the threat actor\u2019s infrastructure, identify the residential proxy services they relied upon and provide indicators enabling blocking across customer environments. The same analytical approach, applied to telemetry from a national ISP PDNS service, would provide law enforcement with a continuously updated map of the residential proxy ecosystem as it operates against a specific nation\u2019s subscriber base.<\/p>\n
This is the broader strategic case for national PDNS that goes beyond citizen protection. It is the case for PDNS as the platform that turns DNS from a vulnerability into a national intelligence asset.<\/p>\n
Infoblox Threat Defense\u2122 is built for exactly this architecture. For government agencies and enterprises, it provides PDNS enforcement with a false positive rate of 0.0002% and detection of 90 percent of threats before the first query is ever seen by a victim, on average 68 days ahead of the rest of the industry. For ISPs and national programs, it provides the resolver infrastructure and passive DNS telemetry capability to operate protection at subscriber scale.<\/p>\n
Infoblox Threat Intel, the research engine behind that protection, contributes a preemptive signal that reactive intelligence cannot: by analyzing domain registration patterns, name server behavior, certificate characteristics and infrastructure clustering during the staging phase of proxy operator operations, we identify and block proxy infrastructure before it is weaponized. The Kimwolf research is an example of this in action. The intelligence and the enforcement are two halves of the same capability.<\/p>\n
Threat intelligence that identifies residential proxy operators is valuable. But standing alone, without the DNS enforcement layer to act on it, it is a description of a problem rather than a solution to one. The complete answer is PDNS, backed by high-quality DNS-focused threat intelligence, deployed at government agency level for managed devices and at ISP level for citizens\u2014closing the DNS resolution pathways that make residential proxy networks viable, and generating the national-scale telemetry that makes the intelligence picture whole.<\/p>\n
Craig Sanderson is principal cybersecurity strategist at Infoblox. Infoblox Threat Intel research on residential proxy abuse, including the Kimwolf investigation, is available at infoblox.com\/threat-intel<\/a>. The Infoblox technical and policy briefing on residential proxies and DNS is available on request.<\/p>\n