Lookalike attack success does not rely on exploiting software flaws or compromised infrastructure. It plays on human tendencies to read what we expect, accept what we see and mentally autocorrect what we read.

By designing domain names that resemble common services, roles or contexts, attackers exploit how people recognize and trust familiar patterns. These attacks bypass technical controls and succeed inside the human decision-making loop. Ambiguity is not accidental. It is the design principle that allows lookalike domains to remain effective and long-lived.

This analysis builds on earlier empirical work on lookalike domains, including Infoblox’s 2023 report A Deep3r Look at Lookal1ke Attacks, which documented the scale, prevalence and technical variation of real-world campaigns. Rather than revisiting that taxonomy, this work focuses on the structural and cognitive properties that make lookalike domains effective, persistent and difficult to classify, and on what DNS data can and cannot reveal about attacker intent before overtly malicious activity occurs.

1. At a Glance

Cyberattacks are commonly described in terms of technical exploits such as vulnerabilities, malware or compromised infrastructure. Security teams invest heavily in patching, endpoint protection and network monitoring, all aimed at stopping attacks before they reach critical systems. Threat actors use lookalike domains to sidestep all of that in phishing and other campaigns. They do not need to compromise systems when they can compromise judgment.

A lookalike attack uses a domain name crafted to resemble something familiar, such as a bank, an internal company portal or a trusted vendor. In a moment of inattention, a person accepts it as legitimate and acts accordingly. The victim clicks, logs in, opens a document or initiates a download before realizing anything is wrong.

This is not a niche edge case. Attacks that rely on human interaction consistently bypass technical controls by exploiting perception and trust rather than system vulnerabilities. Phishing is the most common example, but it is not the only one. The domain name is the lure. The human is the exploit surface.

What makes lookalike attacks particularly difficult to address is their inherent ambiguity. A domain that embeds a well‑known brand name may belong to a legitimate content delivery network, a third‑party service provider or an attacker preparing a phishing campaign. At the moment of registration, and often for days or weeks afterward, these cases are indistinguishable from a user perspective. Attackers are aware of this and use it deliberately, maintaining plausible deniability for as long as possible.

Despite this ambiguity, lookalike attacks leave observable traces. DNS infrastructure, the system that resolves every domain name on the internet, records which names are being queried, how they are structured and which legitimate entities they reference. With the right analytical lens, this data reveals which targets attackers are emphasizing, how the deception is structured and who the attack is meant to influence, even before any overtly malicious activity occurs.

A domain name alone does not tell us what is malicious. It tells us what attackers want their victims to believe. That is a different, and often more useful, kind of signal.

If you take away one idea: Lookalike attacks exploit human trust, not technical weaknesses. They require a fundamentally different detection model and organizational response from malware-driven threats.

2. The Real Target

Not all malicious domains are created equal. To understand an attack and how to defend against it, it helps to start with a deceptively simple question. Does it involve a human at all?

Figure 1 illustrates a way to create two broad classes of malicious domains: system‑targeted attacks that operate without human involvement, and human‑targeted attacks that rely on perception and trust.

Figure 1. Classes of malicious domains: system-targeted vs. human-targeted

Attacks on Systems

Some malicious domains are never meant to be read, recognized or trusted by humans at all. They exist solely to support automated activity, such as malware command‑and‑control (C2), infrastructure coordination or large‑scale abuse. In these cases, the domain name does not need to look legitimate or meaningful. It only needs to resolve.

Domain generation algorithms (DGAs) are a well‑known example. Malware can algorithmically produce large numbers of candidate domains and attempt to resolve them until one becomes reachable, without any human involvement. Other system‑targeted attacks operate at this same layer, including search engine poisoning, DNS cache poisoning and malware infrastructure that rotates domains and IP addresses to evade disruption. In all these cases, domains serve as operational endpoints rather than signals of trust.

Detection of system‑targeted domains relies on statistical, behavioral and infrastructural properties rather than semantics, because no human reader is expected. High lexical entropy, rapid churn, abnormal resolution patterns and lack of meaningful brand association are often more informative than what a name appears to reference. These properties reflect how domains are used by automated systems, not how a person would interpret them.

Attackers also adapt their domain generation techniques. Methods originally developed for automated infrastructure, including registered and dictionary‑based domain generation, are increasingly used to produce large volumes of human‑plausible names at scale. These domains may appear more natural than traditional algorithmically generated strings, not because a human is absent from the loop, but because a human is expected to be fooled.

This shift highlights the distinguishing constraint of human‑targeted attacks. The success of the domain depends not on resolution alone, but on how the name is read, interpreted and trusted. The way a domain is generated does not determine whether it is system‑targeted or human‑targeted. What matters is whether a human is expected to interpret and trust the name. (Infoblox Research, Registered DGAs: The Prolific New Menace No One Is Talking About).

Human in the Crosshairs

Lookalike and phishing domains operate on entirely different logic. These domains must be seen, recognized and trusted by a real person under normal cognitive load. A phishing email targeting bank customers must produce a domain that, on a quick glance in a mobile browser, looks like it belongs to that bank. A credential-harvesting page impersonating a corporate VPN login must feel familiar enough that an employee entering their password does not pause to question it.

The attack is not optimizing for technical evasion. It is optimizing for believability.

This makes the design constraints entirely different. The attacker must choose a name that is registerable, memorable, plausible and just different enough from the real thing to be unique. Too obvious a fake fails immediately. Too far from the original and it loses its persuasive power. The narrow band in between is where lookalike domains live.

Where Automation Fails

These two classes of attacks place fundamentally different demands on detection. For system‑targeted domains, statistical and behavioral analysis is effective because the domain name itself carries little meaning. High lexical entropy, lack of recognizable structure and unusual resolution patterns are strong indicators of automated activity.

The primary signal lies in how domains are used, rather than in what they appear to represent.

When a human reader is involved, this changes the nature of that signal. The domain must be seen, interpreted and trusted by a person at a glance. Importance shifts from statistical properties to semantic plausibility. The domain name is no longer an arbitrary label, but a crafted message intended to be understood quickly and with minimal scrutiny.

This difference limits the effectiveness of purely statistical approaches. A carefully constructed lookalike domain, whether crafted manually or generated at scale, can exhibit entirely normal characteristics by statistical measures. It may have a plausible name, consistent structure and expected resolution patterns. At the same time, many legitimate services, including content delivery networks (CDNs) and third‑party providers, produce domain patterns that deviate from simple expectations. Treating every deviation as suspicious would lead to unacceptable levels of false positives.

These limitations persist regardless of how domains are generated. Automated techniques, including registered or dictionary‑based domain generation, can produce large volumes of human‑plausible names. This does not make the problem more amenable to statistical detection. It reinforces that, for human‑targeted attacks, the relevant signal is semantic and contextual rather than structural.

Lookalike and brand‑referential domains therefore belong squarely in the human‑targeted class. The challenge is not identifying unusual strings but interpreting what a familiar‑looking name is meant to communicate, and to whom.

DNS as Early Signal

There is a second, less obvious implication. Human-targeted attacks must embed their targeting intent into the domain name itself, because the name is what the victim sees. An attacker who wants to harvest PayPal credentials cannot use a random-looking string. The domain has to reference PayPal in some recognizable way. This constraint, imposed by the need to deceive humans, is exactly what makes these domains visible in DNS traffic.

The targeting is structural. It is written directly into the name. And it remains observable long before and long after any malicious activity occurs.

3. Anatomy of a Lookalike

Lookalike attacks do not have a single form. They span several dimensions of manipulation, including character‑level tricks, keyword association and structural deception. All of them exploit the same underlying vulnerability: the way humans read and recognize domain names. Figure 2 shows several common dimensions of lookalike attacks. While not exhaustive, it highlights how different techniques exploit the same underlying cognitive shortcuts.

Figure 2. Dimensions of lookalike attacks: one target, many variants

For any popular brand, attackers may use many viable approaches and combinations of tricks: a homograph embedded in a subdomain, a keyword suffix on a visually substituted name, a typosquat or a real domain name with an alternate top-level domain (TLD). The choice of technique depends on the intended delivery channel, the target audience and the level of scrutiny expected. A phishing email to unsophisticated users might use a simple keyword suffix; a spear-phishing campaign targeting security-aware employees might use a carefully crafted homograph. The common thread is the attacker’s model of the victim’s perception, not the technical construction of the name.

That perception operates on predictable principles.

Perception as the Attack Surface

The brain does not read text the way a parser does. Consider this well-known demonstration:

Aoccdrnig to rscheearch, the huamn biran deos not raed ervey lteter by istlef, but the wrod as a wlohe.

Most readers process that sentence without difficulty. The brain autocorrects. It matches the overall shape and context of a word against familiar patterns and fills in the rest. This is not a flaw; it is an essential cognitive efficiency that allows fluent reading at normal speed.

Attackers exploit exactly this mechanism when crafting domain names. A person glancing at paypa1.com or arnazon.com in a browser bar, in a moment of normal inattention, often resolves the visual discrepancy automatically before consciously registering it. The brain saw what it expected to see.

Domain names compound this vulnerability in two ways. First, attention is front-loaded: the beginning of a string receives the most scrutiny, and focus dissipates toward the end. Figure 3 illustrates this left‑to‑right decay in attention when people read domain names. Second, most people have no trained expectation of what a domain name “should” look like beyond the brand label—so the surrounding structure (the TLD, the subdomain path) is processed with even less care. A name that feels right is accepted as right.

Figure 3. Left-to-right attention decay in domain names

Attackers exploit this systematically. One of the particularly popular patterns is domain embedding, shown in Figure 4, where a trusted brand is placed early in a longer fully qualified domain name and interpreted before the actual registrable domain.

Figure 4. Anatomy of an embedded-domain lookalike

Consider:

login.paypal.com.secure-verification.net

A parser reads this right-to-left. The actual domain is secure-verification.net. A human reads left-to-right and sees login.paypal.com as a completely legitimate‑looking subdomain path, long before their attention reaches the part that matters.

Generalizing the pattern:

[prefix] . <embedded-domain> . [suffix] . <imposter-domain>

The prefix and suffix are optional labels added to reinforce the deception (“login”, “secure”, “verify”, “support”). The <embedded-domain> is the trusted brand being impersonated, possibly including its TLD. The <imposter-domain> is where the attacker actually controls resolution.

It is worth noting that the mechanics of domain embedding, including how legitimate services use this pattern and how it can be abused to conceal malicious activity inside trusted infrastructure, are explored in depth in a separate post: Hiding in Plain Sight: Abusing Composite Domain Names. In that context, an attacker misuses an existing service, such as a translation proxy or an email gateway, to route victims through infrastructure that already carries trust.

The situation here is different. The attacker registers the imposter domain themselves. The embedded brand serves purely as a lure for the human reader, while the DNS mechanics play only an incidental role.

This distinction has a practical consequence. An attacker who sets up a wildcard DNS record on their imposter domain (*.secure-verification.net) gets every possible brand-referencing subdomain for free. login.paypal.com.secure-verification.net, vpn.company.com.secure-verification.net and others. None of these need to be configured individually. The attacker creates one domain; the wildcard does the rest. Each variation is a one-off, never-before-seen query in DNS—appearing as an isolated event with no prior history—yet all share the same structural intent.

Variations on the Same Cognitive Exploit

Domain embedding is one pattern, but the same underlying idea appears across several other forms. In each case, the attacker designs the domain to align with how people read, type, and interpret names under normal attention constraints, not with how systems parse them.

• Homographs and Visual Substitutions: Visually misleading domains like paypa1.com, g00gle.com and arnazon.com replace characters with visually similar alternatives. Typical substitutions include 1 for l, 0 for o, vv for w and rn for m. When viewed quickly, especially on mobile devices, the reader often resolves these differences automatically. The name is perceived as the intended brand rather than examined character by character.
• Typosquatting: Common misspellings appear in domains such as amazom.com and gooogle.com, which fall within the range of typing errors users routinely make under time pressure. Because the result still looks plausible, users often proceed without noticing the mistake. This targets motor habits and inattention rather than visual similarity.
• Keyword‑Adjacent Domains: Examples include paypal-blocked-account.com and facebook-activate-account.com, where a recognizable brand is combined with urgency‑laden terms like blocked, verify or activate. The domain itself is easy to read and technically correct, but the language is chosen to trigger action before careful scrutiny occurs.
• Topic‑Cluster Domains: Coordinated sets of thematically related domains are used together, for example home-security-services.com and home-protection-services.com. Each domain appears individually legitimate, but taken collectively they reveal deliberate targeting of a specific concern. This exploits contextual trust built through repetition rather than deception within a single name.

All of these succeed for the same reason: They are calibrated for human cognitive shortcuts, not technical analysis. A security system that checks for exact matches misses all of them.

Impersonation vs. Acting on Behalf

Not every lookalike domain claims to be the target brand. Some claim merely to act on its behalf, for example, as an authorized service, a partner or a support channel. This distinction matters because the two approaches carry different social signals and create different detection challenges.

Direct impersonation aims to convince the victim that they are interacting with the real organization. The domain is constructed to disappear into familiarity. Acting-on-behalf domains take a softer approach. They do not deny being a third party, but they imply a relationship that grants them legitimacy. A domain like paypal-support-services.com or microsoft-partner-login.com never explicitly claims to be the real thing, yet it benefits from the brand’s authority by association.

DNS alone cannot reliably distinguish between these two strategies. Both produce structurally similar domain names. Both reference the same target brands. The difference lies in the intended victim’s interpretation, which is invisible in DNS data. This is one reason detection must be treated as risk discovery rather than verdict rendering.

4. Choosing the Target: Social Groups and Brand Selection

Attackers do not start by choosing a trick. They start by choosing an audience. In lookalike attacks, the brand or domain name is selected not because it looks convincing in the abstract, but because it anchors trust for a particular social group. PayPal users, customers of a local bank, employees of a specific company or users of a government service all carry different expectations and habits. The lookalike domain communicates a simple message: This is for you.

For that reason, brand choice is an expression of social intent. Frequently impersonated brands are rarely accidental. They correspond to populations that are large, reachable and easy to identify. A global payment service offers an enormous pool of plausible targets. Yet some of the most damaging attacks aim at far smaller groups. A campaign focused on a finance department may impersonate an internal accounting system or a familiar vendor portal. Outside the organization, the domain appears unremarkable. Inside, it carries immediate meaning and authority.

Taken together, these cases form a continuum. Some lookalike attacks are optimized for scale, with minimal effort applied across many victims. Others are optimized for precision, with significant effort concentrated on a handful of high‑value individuals. Across this entire range, the constant is the role of the domain name as a signal of trust to the intended audience. Because that signal is encoded in the name itself, it is visible in DNS regardless of scope.

This distinction matters operationally. The risk posed by a lookalike domain does not increase with traffic volume. A single query directed at a single executive can outweigh thousands of hits from a generic phishing campaign.

5. The Attacker Dilemma

Lookalike attacks are shaped by a set of deliberate tradeoffs. Understanding these tradeoffs explains patterns that might otherwise appear accidental or inconsistent.

Plausibility Requires Restraint
A domain that looks obviously fake fails immediately. Attackers introduce the smallest deviation necessary to register a unique name while remaining convincing. Minor differences are subconsciously normalized by victims, especially under time pressure or limited attention.

Takedown Risk Shapes Uptime Strategy
Phishing infrastructure typically has a short active lifetime, often measured in tens of hours. Figure 5 illustrates a common lifecycle, where domains alternate between parked states and short active campaign windows before being reused. Attackers compensate by leaving domains dormant or pointed at benign content during preparation and cooldown periods, often referred to as “aging” the domains. Malicious destinations are used only during active campaigns, reducing exposure and delaying enforcement.

Figure 5. Lookalike domain lifecycle: parked → active campaign → parked → reuse

Infrastructure Is Reused for Efficiency
The same imposter domain may embed different target brands over time or support multiple campaigns across regions. Ownership and intent are fluid rather than fixed. What matters operationally is current use, not the static existence of the domain.

Ambiguity Is Intentional
A domain that could plausibly belong to a legitimate CDN, a reseller service or a benign third‑party provider is far harder to block than one that is clearly malicious. Maintaining uncertainty slows classification and response, extending operational lifetime. Attackers design for deniability on purpose.

This final point has direct consequences for detection. Systems that wait for certainty before acting will always lag behind. Effective defense in this space is about risk discovery and prioritization, not binary verdicts.

Ambiguity is not a bug in lookalike attacks. It is the feature that keeps them alive.

6. DNS as a Sensor of Social Intent

Passive DNS, the record of domain resolution requests and responses observed above the resolver, provides a powerful signal for understanding lookalike attacks. Its value lies in early visibility into attacker intent, but its limitations must be understood and respected.

What DNS Reveals

• Naming Strategy: Structural patterns used in domain construction, including embedded domains, prefix and suffix decoration and homographs
• Brand Targeting: Which legitimate organizations are referenced in domain names and how frequently those references appear across campaigns
• Infrastructure Relationships: Imposter domains that share hosting, reuse structural patterns or repeatedly appear alongside known malicious infrastructure
• Temporal Behavior: How domains appear, go idle and resurface over time; short‑lived, intermittent activity is behaviorally distinct from stable infrastructure

Aggregation is essential. A single suspicious domain is ambiguous. Multiple domains embedding the same brand, deployed by related infrastructure and observed across time, form a meaningful signal.

What Domain Names Alone Cannot Reveal

• Definitive Malicious Intent: A domain embedding paypal.com may belong to PayPal’s own CDN, a legitimate third‑party service, a cybersquatter or a phishing campaign. DNS alone cannot distinguish these cases.
• User Impact: DNS records a resolution request, not whether a user clicked, was deceived or suffered loss.
• Complete Campaign Scope: Without corroborating telemetry, DNS cannot reconstruct the full path, reach or impact of an attack.

These limitations are not weaknesses to apologize for. They are what make DNS analysis credible. DNS offers early, structural visibility into social targeting intent, not post‑hoc attribution or proof of harm.

7. Targets and Imposters: A Dual-Role Model

Thinking clearly about lookalike domains requires separating two roles that are often conflated. Figure 6 presents a dual‑role model that separates targets from imposters, clarifying how trust signaling and delivery infrastructure operate independently.

Figure 6. Targets and imposters: a dual-role model

A target is a domain, brand or naming construct that serves as a trust anchor for a specific social group the attacker intends to reach. In most cases, this is a legitimate and well‑known service such as PayPal, Facebook, a regional bank or a corporate IT portal, because these names carry pre‑existing trust with their users. However, legitimacy is not a defining property. A target can also be a grey‑area service, a shady platform or even a domain intentionally created or monitored by security teams for research, measurement or infiltration purposes.

What defines the target role is not innocence or intent, but recognizability. The target is the reference point that tells the recipient, “this is relevant to you.” A target says nothing about whether the referenced domain itself is malicious. It reflects visibility, familiarity and social meaning, not morality.

An imposter is the domain that operationalizes the deception. It is the entity that ultimately resolves the interaction, whether by hosting content, proxying requests or routing traffic, and it is where control over the user experience resides. In many cases, imposter domains are registered and operated directly by attackers. In other cases, they may consist of legitimate services, shared platforms or intermediary infrastructure that is temporarily abused, misconfigured or intentionally repurposed.

As with targets, impostership is not a permanent property of a domain. A domain’s role as an imposter is defined by how it is used in a given context and at a given time. The same infrastructure may function as an imposter in one campaign and play a neutral or even defensive role in another.

Together, targets and imposters describe a relationship, not a moral classification. One expresses who the message is meant for, the other determines where the interaction resolves.

This framing has practical value. It separates the question of who is being attacked (target) from imposter attribution, and it acknowledges that neither role is a permanent verdict.

Example: When Imposters and Targets Overlap

In practice, the same domain can act as both an imposter and a target, depending on context. Large infrastructure providers such as cloudflare.net, googleusercontent.com or GitHub‑hosted domains routinely embed vast numbers of customer‑controlled subdomains. Some of these subdomains are known to host malicious content, phishing pages or malware distribution sites, making the parent domain functionally equivalent to an imposter in specific events. At the same time, these platforms are themselves frequent targets of impersonation, as attackers craft lookalike domains that reference Cloudflare, Google or GitHub services to exploit the trust users place in those ecosystems.

This overlap does not indicate malicious intent on the part of the platform. It illustrates the core principle of the dual‑role model: impostership and targethood are contextual relationships, not intrinsic properties. A domain can serve as a delivery point for abuse in one situation, a trust anchor for a user population in another and a neutral infrastructure component the rest of the time. Treating these roles as fixed labels rather than situational roles leads to misclassification and brittle detection decisions.

The Benign Overlap Problem

Many legitimate services use structurally similar patterns:

• CDNs and ad networks embed client domains in their fully qualified domain names (FQDNs).
• Third-party analytics and survey platforms reference brand domains in query strings.
• Wildcard DNS configurations and sinkholes produce patterns that resemble embedding.

A detection approach that ignores this overlap will generate so much noise that the signal may become unusable. Modeling the service landscape, including known CDNs, wildcard resolvers and established third‑party patterns, is therefore as important as modeling attacker behavior.

8. Brand Protection vs. Internal Security: Same Detection, Different Response

Lookalike domain detections serve two distinct organizational interests that are often handled by separate teams. Although these functions are typically treated independently, they rely on the same underlying detection signals and fail in predictable ways when detection and response are not deliberately separated.

Brand protection focuses on domains that impersonate an organization to the outside world, targeting customers, partners or public reputation. The immediate risk is borne by individual users who fall for the deception, such as through account compromise or fraud. Consequences for the organization are typically indirect, emerging as reputational, legal or regulatory exposure over time. Responses rely on monitoring, abuse reporting and takedown requests coordinated with registrars, hosting providers and legal teams.

Internal security focuses on domains targeting an organization’s own employees, such as fake VPN portals or spoofed IT help desk pages. The risk is direct compromise. Because the organization controls the environment, responses can be immediate and technical, including blocking, authentication enforcement, containment and incident response.

The DNS detection logic in both cases is the same. The same structural patterns, brand‑embedding techniques and temporal signals apply regardless of whether the intended victim is a customer or an employee. What differs is not how the domain is identified, but what the organization does after identification.

Brand impersonation puts individual users at risk, with harm localized to those who engage with the deception. There is no effective way to directly protect users beyond warning, monitoring and often slow takedown processes. Internal impersonation is fundamentally different. A single successful deception can lead to systemic compromise affecting employees, infrastructure, partners and downstream customers.

Effective programs account for this asymmetry. Detection is shared and centralized, because the signal is the same. Response is separate, explicitly owned and calibrated to the actual risk surface. Treating brand protection and internal security as interchangeable response problems either creates unnecessary disruption or leaves high‑impact attacks unchecked.

9. What a Domain and DNS Signals Can and Cannot Tell Us

Domain names and DNS‑adjacent data provide early structural signals about how an attack is designed and who it is intended to influence. Naming patterns, brand references, delegation behavior, hosting relationships and temporal activity all support inference about targeting and intent, often before any overtly malicious activity occurs.

At the same time, these signals are inherently limited. A domain name alone cannot definitively establish malicious intent. Many legitimate services exhibit patterns that resemble those used by attackers, and human‑targeted lookalike domains are explicitly designed to remain plausible within this ambiguity.

Additional context from related data sources, such as registrar behavior, certificate usage, hosting history and infrastructure relationships, can increase confidence, but it does not remove uncertainty. For lookalike attacks that rely on human interpretation, ambiguity is not a failure of analysis. It is a fundamental property of the attack.

Domain‑based analysis is most effective when used to surface risk and intent rather than to render final verdicts. It supports prioritization, investigation and informed response, but it cannot replace judgment or eliminate ambiguity by design.

Lookalike attacks scale because human cognition scales. Every new brand, every new user population and every new communication channel expands the attack surface, not due to technological change, but because the pool of trusted targets grows. DNS offers a persistent, structural view into how that targeting is expressed. Its value lies in being used honestly, with responses designed for ambiguity rather than certainty.

Lookalike attacks are difficult to address not because the signals are weak, but because the ambiguity is intentional. What matters is not simply whether a domain is valid or invalid, but what it is designed to communicate and to whom.

The post Human Judgment Hacks: How Lookalike Domains Work appeared first on Infoblox Blog.

Authors: Nick Sundvall, David Brunsdon

On January 13, we published our findings on the Kimwolf Botnet inside our enterprise customer networks. We were alarmed to find ~25% of our customers had the Kimwolf domain in their networks, driven by residential proxies. Today, we follow up on that reporting by looking at the impact of residential proxies across our customer base by compiling billions of DNS resolutions and the associated network telemetry. Surprisingly, we found that over 65% of Infoblox Threat Defense Cloud customers made queries to the domains used to access or orchestrate residential proxy networks in 2026. The stunning prevalence of these services within customer environments warrants attention from both network defenders and policy makers who should consider how the risks posed by residential proxies could be impacting their security posture.

With residential proxies in the corporate environment, access is granted to an organization’s IP space. If threat actors were to abuse the residential proxy to attack a third party, the third party’s incident response would, correctly, identify your residential proxy as the source. Untangling that, by proving that you were the conduit and not the threat actor, costs time, creates legal exposure, and can damage your reputation.

At Infoblox, we have a unique perspective into the use of residential proxies, as illustrated in Figure 1. Devices on our customers’ networks use our recursive resolvers, not just for typical, user-initiated traffic, but also to resolve the domains used to orchestrate the residential proxies, and even to resolve the domains accessed by the external proxy users. This means that content filtering policies are enforced unilaterally, with malicious or unwanted domains handled and reported on based upon the customer’s security configuration. This visibility into the use of residential proxies is clearly advantageous; however, it is not without its challenges. Actors leveraging residential proxies are unlikely to adhere to acceptable use policies, and their activity often includes access to suspicious, malicious, or policy-violating domains. As a result, this traffic can generate a disproportionate volume of security alerts, effectively surfacing abuse that would otherwise remain obscured and increasing the analytical burden on defenders.

Figure 1: Infoblox visibility into residential proxies.

We used our visibility into DNS queries and a newfound appreciation of residential proxies to evaluate the breadth and depth of their use in our cloud customer environment. In addition to 65% of the customer base querying residential proxy related domains, we saw steady growth in these queries in 2025, with a 25% increase over the year to over 500 billion per month. Despite actions taken against one service, IPIDEA, in January 2026 and heightened awareness of the risks associated with these services, we have seen no reduction in their use. Indeed, we saw curious traffic anomalies around the time that action was taken against IPIDEA.

While there are many potential sources for these queries, from mobile apps to browser extensions to rogue TVs, we saw clear trends in the dominant services being contacted, both in volume of queries and breadth of customers. The most seen proxy service is associated with scraping for AI models, but we also saw applications that network owners may be unaware are active on devices; much less are part of residential proxy pools. In a bit of irony, users of residential proxies are impacted by customer protective DNS policies, which may restrict access to malicious domains. The purpose of this blog is not to point fingers, but to raise awareness of how present they can be in a network and the impact they can have on DNS volumes.

During the last several months, we have collaborated with Synthient to better understand residential proxies and identify how these services, and the malicious actors who sometimes promote them, impact global networks. Each of us has a different perspective on the traffic, and Synthient has written “Who Are the Victims of Residential Proxies?” from theirs.

So, What Are Residential Proxies?

A residential proxy routes internet traffic through devices that belong to everyday consumers such as home routers, mobile devices, IoT devices, and devices with applications embedded with proxyware. Related obfuscation tools such as Tor and commercial VPNs will produce anonymized traffic. The destination knows the connection is masked, even if it doesn’t know by whom. Residential proxies produce laundered (disguised) traffic—the destination believes it knows exactly who is connecting, but it is wrong.

This is exactly what makes residential proxies valuable to attackers:

• They evade IP reputation systems that protect datacenter infrastructure
• They bypass fraud detection and verification controls
• They allow abuse traffic to blend into “normal” consumer noise

Residential proxies can source their IP addresses ethically by being up-front to users about what their apps are doing and how it may impact them. But in many cases, these proxies are installed non-consensually and can be implanted maliciously as proxyware, which in this case, is an attack similar to cryptojacking. With cryptojacking, the attacker consumes energy and CPU time, but with unauthorized proxyware, it’s bandwidth and IP space that is taken. Actors love to embed proxyware in devices and applications that are internet accessible, and that are always on.

Application developers can embed software development kits (SDKs) provided by the residential proxy networks into their products to monetize their software, allowing them to receive a small amount of money on each installation. Because of this, devices are frequently enrolled without the owner’s knowledge, typically through free applications such as:

• VPNs
• Streaming apps
• Screensavers
• “Productivity” apps such as PDF viewers and break reminders

Low-cost IoT devices, such as digital picture frames or media streaming devices, have also become a popular home to these SDKs. Some of these devices come with proxyware pre-installed, while others receive the capabilities through updates from unofficial app stores.

Another concern is the potential for probing internal networks, as the Kimwolf Botnet did. An ethically designed residential proxy would block routing to internal IP addresses, but if the app allows for it, threat actors would be able to launch attacks on internal devices.

From the end user’s perspective, nothing looks wrong, and the bandwidth consumed is not always significant, so they may not notice anything out of the ordinary. However, when crossing over into a corporate environment, from a network defender’s perspective, the unwelcome traffic carries risks that the end user does not fully realize.

In this report, we examine the queries to the different residential proxy services. We are not stating whether we believe specific proxies are “ethical” vs. “non-ethical” or malicious vs. benign. That said, many residential proxy services operate in a grey space, and we have observed activities from some organizations that raise questions about their stated commitments to ethical practices. Moreover, many of these proxies use lookalike domains that look like other residential proxies, which lowers our confidence in their legitimacy as well as our confidence in attribution.

One thing our research could not determine was exactly how much residential proxy usage is intentional. Details such as how a provider sources their IP addresses are not always clear, and many use confusing or buried disclosures in their policies. In one provider’s policies we reviewed, the substantive description of the proxy arrangement appeared only after navigating through three separate documents from two affiliated companies. A concern remains that the residential proxy market is supported in significant part by users who may not fully understand the nature of their participation.

A Growing Presence in Customer Traffic

Across our customer base, residential proxy–related DNS traffic is both significant and increasing. Between January 2025 and April 2026, we observed that the total number of monthly queries to residential proxy domains steadily grew from nearly 400 billion to over 500 billion—an increase of ~25% (as shown in Figure 2). There are likely several explanations for this: certainly, the rise in AI-related training, which often requires scraping websites, is a major driver of residential proxy demand. Residential proxies bypass many anti-scraping measures, as the traffic appears to be coming from the devices of real people.

Figure 2: Graph showing the total number of queries to residential proxies by month

Figure 3 shows the number of queries from our cloud customers to domains associated with Infatica. For over two weeks, there is a relatively low volume, tens of thousands of queries per day, which then quickly ramps up to around 1 million queries per day. Interestingly, this spike happens shortly before Google took down IPIDEA.

Figure 3: Graph of the number of queries to Infatica domains during January 2026. The dips in volume on the 24th, 25th, and 31st are likely due to those days being weekends when fewer enterprise employees were working.

During the days around the takedown of IPIDEA, some kind of chaos ensued of a nature we are not confident in explaining. Figure 4 demonstrates the number of customers observed calling out to ipinfo[.]ipidea[.]io. While a spike in total queries to that domain occurred at the same time, it’s the number of customer networks impacted growing by 265% in a single day that is particularly remarkable. We asked several experts in the residential proxy space about the jump, but none had an explanation.

Figure 4: Graph of the number of customers querying ipinfo[.]ipidea[.]io. A large increase in customers querying the domain (over 265%) occurs on January 23rd. The number of customers querying the domain begins a dramatic drop around the announcement by Google on January 28th.

As seen in Figure 5, several well-known residential proxy providers stand out due to the number of cloud customer networks they appeared in.

Figure 5: Graph of the percentage of cloud customers that have queried each proxy service or botnet

• Brightdata is by far the most frequently observed proxy service we see, appearing in over 50% of cloud customers. Both Brightdata and Oxylabs offer residential proxies for businesses, advertising that they can be used for web scraping to train AI.
• Hola VPN is advertised as a free VPN, but it is in fact a residential proxy service offered in conjunction with an affiliated company, and the free browser extension provides the supply side of the proxy network. Users who install Hola become “peers” whose IP addresses are used as exit points for the affiliated company’s commercial customers.
• Honeygain is a residential proxy that pays users to allow others to use their residential IP address as a proxy. Honeygain also runs CareBuzz, which is a similar product but claims to give the revenue to a charity of the user’s choosing.
• Grass is a residential proxy that states that it “turns your unused internet into rewards automatically” and pays out the rewards in cryptocurrency, namely the $GRASS token. Grass was reportedly pre-installed on Superboxes, Android TV streaming devices, adding users to the network without their knowledge. According to previous reporting by Krebs on Security, the CEO of Grass said he had no connection with Superbox and “It looks like these boxes are distributing an unethical proxy network which people are using to try to take advantage of Grass”. Regardless of how Grass is distributed, it has a large presence across our customer base.

Figure 6 illustrates a broad impact of residential proxies across our customer base, with at minimum 40% of our customers in each vertical market containing such traffic.

Figure 6: Graph of what percentage of each industry has queried residential proxies

Over 90% of our pharmaceutical and food & beverage customers have queried residential proxy indicators. Perhaps even more concerning is that over 60% of government and banking customers have as well.

To look deeper into the usage of residential proxies, we created a heatmap (Figure 7), which illustrates the popularity of specific residential proxy services in various industry vertical markets. The appearance of education at the top seems unsurprising, because there could be many students on higher-education networks willingly trading access to their network for monetary compensation. After education, however, the results are more concerning from a security professional’s perspective: pharmaceutical, electronics, industrial, and healthcare all show strong residential proxy use. In our experience, companies in these verticals tend to have a much lower tolerance for risk, so these network defenders might want to take note of services that appear in their network traffic. Some of the residential proxy services might have a valid business reason, while others may not.

Figure 7: Heatmap of proxies in various industries

Every organization has unique security concerns, but we recommend the following:

• Risk-averse organizations should consider mechanisms, including Protective DNS, to detect and block unauthorized residential proxies within the network.
• Review your DNS query logs, if you have them, for the presence of queries to known residential proxy domains.
• Review installed applications, browser extensions, and IoT devices within your network for residential proxy usage.
• If you use Protective DNS, check your current response policies. Risk-averse organizations should consider blocking bogon resolutions, as well as suspicious and malicious domains
• Check your IP addresses with Synthient or another organization tracking residential proxies.

The post Residential Proxies in the Wild appeared first on Infoblox Blog.

In April 2026, Salesforce announced Headless 360 at TrailblazerDX with the pitch “No browser required.” Every capability in the platform now sits behind an Application Programming Interface (API), a Model Context Protocol (MCP) server or a Command-Line Interface (CLI), so AI agents can use the entire system without using an interface. “Headless” went from engineering jargon to a word leaders are hearing in board meetings.

What does “headless” mean, and does your company need to go there?

If your honest answer is “I have no clue,” you are in good company. Most businesses are still building internal AI agents that don’t yet interact with the outside world. The few external-facing agents that do exist typically live behind a corporate boundary within a product website and require logging in using human credentials. That setup is just step one of the journey to headless. From inside the company’s four walls, “headless” still sounds like a buzzword in search of a problem.

The need for “headless” only shows up at stages two and three, where agents stop being gated by your human-facing website and start talking to your software directly. The graphic below lays out all three stages, and the rest of this post walks through them with one shoe-buying example.

* Image created using Gemini

The Setup: Your company sells running shoes. A human shopper has asked her shopping agent to find the best deal on a pair of trail runners under $150, delivered by Friday. The shopper agent is now standing at your door, ready to do business on her behalf. What happens next depends on which step you are on.

Step 1: The Shopper Agent Uses Your Website (AG2UI)

Let’s call this Step Agent-to-UI, or AG2UI.

You have done nothing to accommodate the shopper agent, so the agent does what the human shopper would do. It opens your website, dismisses the cookie banner, navigates the menus, picks a size and tries to check out. If you have ever watched an agent fumble through dropdowns and popups, you know it is painful. A human webpage is foreign territory for an agent.

This is where most companies are. During the shopping process, your site asks for user login or payment authentication, and the shopper agent stalls. The human shopper has to take over and finish the transaction by hand.

Step 2: You Open a Doorway Built for Agents (A2MCP)

In step two, you stop asking the shopper agent to pretend to be a human. This is precisely the problem the Model Context Protocol (MCP) was built to solve. Let’s call this Step Agent-to-MCP, or A2MCP.

MCP provides a structured way for agents to call your tools, query your data and get clean answers back. You publish a menu of available capabilities, like a search_shoes tool, an add_to_cart tool and a checkout tool. Each tool specifies exactly what inputs it requires and what outputs it returns. The agent simply picks the right tool and calls it directly.

If you are familiar with the term “API,” you already understand the human-engineering equivalent. An API is a structured way for software to talk to software instead of clicking through a webpage. Think of MCP as the universal standard for exposing those APIs in a format that AI agents can seamlessly consume.

In our running shoes example, the shopper agent no longer scrapes your webpage. It knows it needs to call search_shoes(size=8, type=”trail”, max_price=150) and get back a clean list. It knows it can now call add_to_cart and checkout directly. Because each call is a structured request rather than a webpage to interpret, the whole transaction runs at machine speed.

Step 3: Your Agent Talks to the Shopper Agent (A2A)

Step two is a real upgrade, but it has a quiet limitation. MCP is structured around the shopper agent making a call and your software responding. Your software does not start its own conversation, ask follow-up questions or surface a deal the shopper agent did not think to ask for. It can be smart inside each call, but it does not initiate. It also needs to be set up, it is not automatically discovered and used.

In step three, your software stops being a passive responder and becomes a seller. For example, your agent recognizes the shopper from prior purchases, sees that size eight is low in stock and proactively offers the shopper agent an upgrade to a comparable model with free expedited shipping if the order is placed today. When the shopper agent mentions it is also looking at a competitor, your agent applies a loyalty discount to close the gap. None of those moves come from the shopper agent asking. They come from your side actively trying to win the sale, the same way a good salesperson would on a showroom floor. Let’s call this Step Agent-to-Agent, or A2A.

Stages 2 and 3 are “headless” because they do not force the shopping agent to use a browser.

Why Do You Need to Go Headless?

The progression through these three stages makes the reason clear. Going from step one to step two takes your software from human speed to machine speed, since the shopper agent can now act through structured calls instead of clicking through your webpage. Going from step two to step three lets your software meaningfully compete and leverage a much richer context, instead of acting as a passive lookup that only returns what was asked for.

If you stay on step one, the shopper agent leaves without making a call and picks a competitor that has gone headless. You might not even know about a lost opportunity because there is no abandoned cart to follow up. Your customers will be using agents to shop, you have no other options but to go headless and the only question is when you should start.

What’s Keeping Us From Going Headless?

Companies starting this headless journey will stay stuck on step one until we collectively solve one important pre-condition: agent identity and trust. Before you let a shopper agent connect with your MCP or your agent, you need to know with certainty that it is not malicious and that it really represents the shopper it claims to. The same is true on the shopper’s side: she wants the best deal, and she also wants to make sure her credit card is not handed to the wrong party. Today, agents answer those questions with static API keys and hardcoded tokens that would horrify any security architect doing the same for human users. That approach cannot scale to agentic commerce, and if you are a less well-known brand, your chance of getting discovered by a shopper agent is close to zero.

The good news is that you already own the infrastructure to fix it. The same Domain Name System (DNS) that tells the world nordstrom.com is really Nordstrom can be extended to your agents. Your inventory agent becomes inventory.agents.yourcompany.com. Your checkout agent becomes checkout.agents.yourcompany.com. You own that namespace the same way you own your storefront, and you can carry it across mobile, web, APIs, MCP, A2A or whatever protocol comes next, with no vendor lock-in and no dependence on where the agent was built or deployed.

This concept is already being turned into reality by emerging standards such as DNS for AI discovery (DNS-AID). DNS-AID names agents and MCPs in a way so they are tied to the domain name of an organization, conveying trust and driving accountability when the agent misbehaves. Adjacent efforts extend security mechanisms such as DNS Security Extension (DNSSEC) to cryptographically prove that an agent really belongs to the domain it claims. OWASP’s Agent Name Service and GoDaddy’s ANS implementation leverages the same domain-based foundation to enhance agent and MCP authentication and trust.

Once the foundation of identity and trust is established, organizations will be able to fully complete their transition to going headless.

The Bottom Line

Ultimately, moving from human-speed websites (step one) to machine-speed endpoints like MCP (step two) and proactive agent-to-agent negotiations (step three) is a necessary evolution. While verifiable identity and trust remain the gatekeepers to completing this full transition, the shift is inevitable, and businesses must get their infrastructure ready now. By opening these direct doorways and securing them with a domain-based identity, your business remains reachable and competitive when the customer at your door is an AI agent. Organizations that embrace this transition will win the next decade of agentic commerce.

The post “Headless”? What Is It and Do I Need to Go There? appeared first on Infoblox Blog.

Attack surface management has spent the last few years catching up to a problem that keeps getting larger. The SANS 2025 Attack Surface Management (ASM) Survey, authored by SANS principal instructor Chris Dale and based on responses from 235 cybersecurity professionals, frames it well in its title: “Hackers Don’t Wait—Why Should We?” The data behind that question is what makes this survey particularly relevant to where Infoblox is taking Digital Risk Protection Services (DRPS), part of Infoblox Exposure Management.

Where our Sapio research examined how 550 security leaders are responding to AI-driven external threats, the SANS findings tell a complementary story about what teams now expect from the platforms they buy: unified coverage, business-aligned risk and action; NOT more alerts.

What 235 Security Pros Just Told SANS They Want

A few data points from the survey stand out for how directly they map to the gap Digital Risk Protection Services is built to close:

• 55 percent of respondents explicitly demand ASM solutions that provide unified coverage of both external and internal assets, significantly outpacing those who prioritize external-only or internal-only coverage. Teams are done buying separate tools for separate sides of the perimeter.
• 37 percent rank understanding their external attack surface as their top desired outcome, signaling that external exposure is no longer a secondary concern but the primary use case driving ASM investment.
• 89 percent expect ASM platforms to quantify risk for every asset and demonstrate business impact, not just produce findings. The bar has moved from technical reporting to executive-grade risk intelligence.
• More than two-thirds (67 percent) expect explicit mitigation recommendations directly from their ASM platform. Identifying exposure isn’t enough. Teams expect platforms to accelerate remediation and reduce operational overhead.
• Only 28 percent of existing ASM platforms effectively identify sensitive data across the environment, a significant gap given how often sensitive data exposure leads to breach, fraud and regulatory penalties.
• About a third (35 percent) want current information on vulnerabilities, including whether each is actively exploited or has publicly available proof-of-concept exploits, reinforcing that real-world exploitability, and not raw counts, is what drives prioritization.

The throughline is hard to miss. Security leaders are moving away from fragmented, alert-driven tools and toward unified, automated, business-aligned risk operations. They want platforms that connect external visibility to internal context, translate findings into business risk, and shorten the distance between discovery and disruption.

Why Most Attack Surface Tools Miss the Half That Hurts

Most ASM offerings still center on internet-facing assets the organization owns: domains, IPs, certificates, exposed services, cloud misconfigurations. That’s important, but it’s only half of the external risk story. The other half lives on attacker-controlled infrastructure: lookalike domains, phishing kits, fraudulent ads, rogue mobile apps, executive impersonation, leaked credentials and brand abuse across the open web, social platforms and the deep and dark web.

Three operational realities make this side particularly painful:

• Visibility without Action: Traditional ASM surfaces what exists; it rarely disrupts what’s actively abusing it. The 37 percent of respondents naming external exposure as their top outcome are explicit that visibility alone isn’t enough.
• Sensitive-Data Blind Spots: With only 28 percent of ASM tools effectively detecting sensitive-data exposure, leaked credentials and customer data circulate on dark web forums and paste sites long before defenders are aware.
• Manual Takedown Drag: Even when external threats are found, removing them traditionally requires analyst-driven evidence collection, registrar coordination and weeks of follow-up, which is work that doesn’t scale against attackers who leverage AI to spin up new infrastructure in minutes.

From Findings to Disruption

Digital Risk Protection Services is built for exactly the operating model SANS respondents describe: unified coverage, automated action, measurable business outcomes and tight integration with the workflows teams already run.

• On Unified Internal and External Coverage (55 percent): Digital Risk Protection Services pairs Axur-powered external discovery and disruption with Protective DNS, part of Infoblox Threat Defense. External attacker infrastructure is taken down on the outside while managed users, devices and workloads are blocked at the DNS layer on the inside, providing one continuous loop and not two disconnected programs.
• On External Exposure as the Top Desired Outcome (37 percent): Digital Risk Protection Services continuously discovers brand abuse, phishing infrastructure, fraudulent ads, rogue apps and impersonation across web, social, ads, app stores and underground forums, then validates real abuse with multi-modal AI that catches campaigns keyword- and domain-similarity tools miss.
• On Risk Quantification and Business Impact (89 percent): Every action is tracked with defensible evidence, clear status and full audit history, designed to support the executive-friendly reporting and outcome metrics SANS respondents say they need to justify investment.
• On Explicit Mitigation Recommendations (67 percent): Digital Risk Protection Services doesn’t stop at findings. AI-driven validation initiates evidence-backed automated takedowns end to end, with sub-four-minute first notifications to service providers after threats are detected, a roughly nine-hour median time from attack confirmation to removal, a 98.9 percent success rate, 86 percent of removals fully automated and 15-day stay-down monitoring to prevent recurrence.
• On the Sensitive-Data Discovery Gap (only 28 percent effective): Digital Risk Protection Services continuously monitors paste sites, dark web forums, breach databases and underground marketplaces for exposed credentials, payment data, source code and sensitive records, correlated back to the affected brand and prioritized by likelihood of fraud or account takeover.
• On the Speed of Attacker Innovation: Pairing automated external takedown with DNS-layer blocking compresses the exposure window. Managed users are protected within minutes while removal proceeds, and DNS intelligence expands every confirmed takedown into the broader attacker campaign rather than chasing one-off domains.

One Loop, Inside and Out

Digital Risk Protection Services is the first phase of Infoblox Exposure Management. The next phases, which will include External Attack Surface Management (now available in early access) and Cyber Asset Attack Surface Management, directly address the unified internal-and-external operating model the SANS data shows the market is asking for. Outside-in discovery of internet-facing assets, DNS- and DDI-powered ownership context, and integrated risk quantification will close the loop from external threat to internal accountability, in the same continuous cycle.

The Bottom Line

If your team is investing in attack surface management, the SANS 2025 data is a clear signal of where the market is heading: unified coverage of internal and external assets, business-aligned risk, automated mitigation and faster time to action. Digital Risk Protection Services delivers that today on the side of the perimeter where threats originate and connects it to the DNS-layer enforcement and internal context Infoblox is uniquely positioned to provide.

Read the SANS 2025 Attack Surface Management Survey, then talk to us about how Digital Risk Protection Services can help you act on what the research is telling you.

The post The Half of Your Attack Surface Nobody Owns appeared first on Infoblox Blog.

The attack surface isn’t just expanding. It’s outrunning the security models built to defend it. That’s the clearest takeaway from Securing the Expanding Attack Surface in the Age of AI, a new Infoblox research report based on a global survey of 550 cybersecurity professionals across 10 countries and six critical industries.

The data will feel familiar to anyone inside a security organization right now: more exposure, more AI-driven attacks, more tooling and still not enough real risk reduction. Security leaders are no longer debating whether to shift toward preemptive, intelligence-driven security; they’re doing it, and they’re looking for solutions that can disrupt threats before they reach users, customers and brands, especially the ones that originate outside the enterprise perimeter. This is exactly the problem Infoblox acquired Axur to solve, and why we’re scaling Axur’s proven capabilities globally as Digital Risk Protection Services (DRPS), part of Infoblox Exposure Management.

The Signals Are Hard to Ignore

A few numbers from the report stand out for how they connect:

• 96% of organizations report challenges managing threat exposure as cloud, software as a service (SaaS), IoT/OT and shadow IT grow faster than teams can inventory.
• 87% have already experienced adversarial AI-driven attacks, most commonly AI-driven phishing (61%) and AI-crafted malware (51%).
• 43% now rank deepfakes and AI-generated phishing as their top threat concern, surpassing ransomware (29%).
• More than half prioritize phishing infrastructure takedown and credential leak detection as their most critical digital risk protection use cases.
• 67% cite poor DNS hygiene as an exposure concern, and 88% report additional exposure concerns tied to misconfigured or unmanaged DNS.
• 82% have increased their use of preemptive security tools year over year.

The biggest challenge isn’t finding vulnerabilities. It’s knowing which ones are actually exploitable in the real world (34%), compounded by budget constraints (29%), fragmented tooling (28%) and gaps in intelligence, skills and tooling that leave over half of teams overwhelmed by the pace of AI-driven threats. Meanwhile, attackers have industrialized everything outside the perimeter, standing up convincing phishing, fake apps and impersonation campaigns faster than manual defenses can respond. Organizations don’t need more alerts about external threats. They need those threats disrupted before they reach their users and customers.

Preemptive Security Is Becoming the Operating Model

Security leaders are moving decisively toward preemptive, intelligence-driven approaches. Prevention (43%) and predictive threat intelligence (39%) lead the list of most appealing preemptive concepts, with AI-assisted security operations (36%) close behind. Organizations expect preemptive tools to account for 49% of their security tool mix over the next 12 months, up an average of 12% year over year, and they want those tools to plug into workflows they already run, with security information and event management (SIEM)/security orchestration, automation and response (SOAR) integration (32%) and executive-friendly reporting (30%) ranked as the highest-value additions to digital risk and exposure management solutions.

Why We Acquired Axur, and Why Now

When a market tells you that damaging attacks begin outside the enterprise, that AI has made them faster and more convincing, and that perimeter controls aren’t built to disrupt the infrastructure that creates them, you have two choices: wait or accelerate. We accelerated.

Axur was purpose-built for this problem, continuously discovering brand abuse, phishing infrastructure, impersonation, fraud and credential exposure across the open web, social, ads, app stores, marketplaces and the deep and dark web, then automating evidence-backed takedowns end to end. The metrics tell the story: sub-four-minute first notifications to internet service providers after a threat is detected, nine-hour median takedown times after those notifications are sent, a 98.9% success rate in removing attacks permanently, 86% of takedowns automated with no human involvement required and 15-day stay-down monitoring to prevent reappearance.

For the full acquisition rationale and the “better together” vision, see Scott Harrell’s Why the Axur Acquisition Marks a Turning Point for Preemptive Security and Mukesh Gupta’s deep dive on turning external risk into protection at scale.

How Digital Risk Protection Services Maps to What the Research Says Teams Need

The survey is, in many ways, a blueprint for what Digital Risk Protection Services, the first offering within Infoblox Exposure Management, is designed to do.

• On the top digital risk priorities, such as phishing takedown, credential leak detection and AI-evasive impersonation: Digital Risk Protection Services continuously discovers external threats, validates real abuse with multi-modal AI that catches impersonation keyword- and domain-similarity tools miss, and automates takedowns across web, social, ads, apps and the deep and dark web.
• On DNS hygiene and the compressed window between exposure and impact: Paired with Protective DNS, part of Infoblox Threat Defense, Digital Risk Protection Services delivers “instant block + fast takedown,” a combination no one else brings to market, so managed users are protected in minutes while attacker infrastructure is removed, and DNS intelligence expands visibility into the related infrastructure behind each discovered threat.
• On integration, reporting and measurable outcomes: Digital Risk Protection Services plugs into existing SIEM/SOAR and incident workflows with proof-rich evidence and audit-ready reporting, and it extends into a broader exposure management strategy with External Attack Surface Management (EASM) and Cyber Asset Attack Surface Management (CAASM) as the next phases.

The Takeaway for Security Leaders

The expanding attack surface, the normalization of AI-driven attacks, the persistent gap between vulnerability data and real-world exploitability, and the sharp move toward preemptive control all point in the same direction: the programs that succeed will be the ones that disrupt external threats earlier, enforce protection immediately and prove real risk reduction. That’s exactly what Digital Risk Protection Services is built to deliver at global scale.

Download the Securing the Expanding Attack Surface in the Age of AI report for the full findings, then talk to us about how Digital Risk Protection Services can help you act on what the research tells you.

The post What 550 Security Leaders Just Told Us about the Age of AI, and Why Preemptive Digital Risk Protection Can’t Wait appeared first on Infoblox Blog.

Authors: Maël Le Touz, Elena Puga

Executive Summary

Modern smartphones are extremely secure and can be remotely locked and turned into a worthless brick if they are stolen. iPhones in particular can be remotely secured using a feature called Activation Lock, preventing all future use in case the device is stolen. Even individual components can be locked by the owner.

And yet, iPhones are stolen … a lot. Figures indicate over 7.35 million are stolen in the United States yearly. So, how do the thieves monetize them?

After a friend reached out for help, we discovered a thriving underground marketplace, organized on Telegram, focused on one thing: unlocking high-end phones—mostly iPhones. By combining technical tooling and social engineering, thieves now have a way to unlock devices at scale and make phone theft profitable.

These so-called “unlocking tools” create a market for stolen phones by allowing anyone with a pulse to try to turn a bricked “lost or stolen” device into easy money.

Despite the fact that there are no publicly disclosed vulnerabilities for late model iPhones, threat actors use clever techniques to convince the owner to enter their passcode. SMS phishing (smishing) is one of them, and our DNS telemetry shows steadily growing and persistent activity.

We initially assumed thieves would be interested in the phone’s data. Those devices, after all, hold potentially priceless personal and corporate information. Interestingly, we discovered the opposite. Thieves are after a quick buck, and the value of the data is secondary to the value of the hardware. It seems like their phishing domains are often detected, and some of the tools sold in these forums contain mechanisms to detect DNS blocks and automatically request delisting from Google Safe Browsing.

This paper will detail how, by analyzing DNS clusters, we were able to pivot from an initial text to reveal a thriving marketplace enabling and ultimately driving phone theft. We will then explain how this underground economy functions and how smishing is only one tool in the toolbox they use to gain access to stolen phones.

From Smishing to Panels

When somebody loses access to their iPhone, they can set a message on the locked screen, directing the finder to contact a specific phone number to return the device. See Figure 1. Users will usually choose their spouse’s or parent’s phone number. It’s this helpful feature that offers the scammers a way to reach out to the phone’s owner and manipulate them into unlocking it.

Figure 1. Lost iPhone displaying a contact number

This is how one of our friends was contacted when their iPhone was stolen in Asia. Shortly afterwards, they received a text with a link to a URL hosted on applemaps-support[.]live.

Lookalike domains targeting Apple are nothing new: we detect over 800,000 a year. But the timing of the text was suspicious, and whoever sent the message clearly had the device in their possession.

At first glance, the page on applemaps-support[.]live closely resembles the real Apple Findmy page, but this is of course a decoy—the website is not operated by Apple. The phone appeared to be moving on the spoofed map (see Figure 2) but before we could do anything else, a pop-up appeared asking for the PIN code to unlock the phone. Had our friend given their passcode, the thief would have immediately gained full control of the device.

Figure 2. iPhone phishing page shows stolen phone moving

Pivoting on DNS characteristics of the domain, we quickly identified a cluster of related phishing pages, all using Apple lookalike domains.

Discovery of an iPhone Unlocking Marketplace

Not all the domains in the cluster hosted phishing content. In several cases, threat actors had inadvertently exposed their own admin login page at the root of several websites. Other pages on the same domains advertised “phone unlocking tools.” This made us curious: Could these unlocking services be connected to smishing attacks targeting iPhone owners who had lost their devices?

Indeed, we soon identified dozens of Telegram groups functioning as a large underground marketplace focused on unlocking phones. Different sellers offer their services to end users looking to unlock phones. The products are sold under different names, but always offer the same features:

• An unlocking tool: a Windows binary able to automatically “jailbreak” old phones. The same tool also offers a way to extract identifying information from a plugged-in device,
• An ‘FMI OFF’ (Find My iPhone Off) or ‘iCloud Webkit:’ a phishing and smishing kit designed to convince legitimate owners to forfeit their iCloud/Apple Account and screen lock passcode,
• Social engineering tools: scripts, AI voice calling software and pre-recorded sound files in different languages impersonating Apple and asking for the passcode

The tools are typically offered on a pay-as-you-go basis, where customers will pay a small fee per unlock attempt or smishing link sent. End users will routinely ask for technical help and share videos of successful attacks (as in Figure 3)

Figure 3. Buyer asking for help on how to unlock a likely stolen iPhone XR. An unlocking tool can be seen in the background.

Figure 4 shows the relationship between vendors and patrons.

Figure 4. Diagram showing the organization of the ‘FMI OFF’ kit trade

The sale of unlocking services is key. Those tools are often branded to a particular Telegram group. With such software, criminals can automatically unlock older phone models but also extract identifying information that will then be used to craft smishing attacks targeting the device’s owner.

Of course, nobody in those Telegram groups discloses how they obtained the device(s) they are seeking to unlock. Some pretend they’ve simply forgotten the password to an old device, but that does not explain the need for the “FMI OFF,” or the social engineering features included in the tools.

Technical Capabilities of Unlocking Tools

The unlocking tools available offer varying levels of sophistication. The more complex ones connect to a license server (presumably to prevent unauthorized reselling) under a pay-as-you-go model: unlocking a recent iPhone can cost anywhere from $5 to $50 depending on the seller. The average price is below $10.

Under the hood, the tools are just crude graphical user interfaces (GUIs) running different command-line tools (Figure 5) based on open-source utilities designed to jailbreak iPhones and extract information.

Figure 5. Unlocking app offering a very simple GUI

While there are only a handful of functionally distinct “unlocking tools,” they are distributed and resold under different names by individuals located all over the world, making it seem like there is a plethora of options. We found sellers in Bangladesh, India, Pakistan, Venezuela, Mexico, Brazil, and other countries, as shown in Figure 6 below.

Figure 6. Local resellers of unlocking software

At the time of writing, the latest phone models and iOS versions above 17.0 are not affected by any publicly disclosed vulnerabilities enabling unauthorized access. Some entrepreneurial individuals try to exploit this gap in the iPhone unlocking market by advertising trojanized versions of tools or demanding exorbitant fees for an elusive “zero day exploit” that doesn’t really exist. If it did, such an exploit would be worth seven figures or more rather than a few hundred dollars.

Unlocking the latest phones requires a different approach: smishing! In this case, the proffered unlocking tools can extract information including device serial number, original activation country, and linked Apple Account. This data will then be used to craft a credible smishing message and landing page. This information gathering can also be done using specific Telegram bots, conveniently operated by the same groups, as shown in Figure 7.

Figure 7. Threat actor using a Telegram bot to find owner information about a given iPhone. The bot is able to check a stolen credentials database and identify linked devices on iCloud. Access to the bot requires payment in advance.

How Smishing Fits into the Supply Chain

Besides unlocking tools, developers have also created dozens of different smishing templates, as shown below in Figure 8, covering Apple but also other major brands like Xiaomi and Samsung. All are offered in a variety of languages.

Figure 8. Image generated by a reseller showing the templates they offer

End users—those looking to unlock phones—will craft the attack by personalizing their chosen template based on information harvested from the unlocking tools such as the victim’s name, email, and whether the passcode has four or six digits. Users can also insert a specific location on the “lost iPhone map,” and specify a specific language. All of this is an effort to make the attack appear more credible.

They will then prepare the smishing text, including the link to the now-personalized phishing page. Figure 9 shows examples.

Figure 9. Examples of smishing texts

The text is sent to the contact number displayed on the locked phone’s screen. The malicious link can be sent over WhatsApp, text or email, directly from the smishing template pages as in Figure 10.

Figure 10. WhatsApp smishing message received by a victim; it’s carefully crafted to look like it was sent from an official Apple account

Once the victim enters their credentials, the information is sent back to the attacker via Telegram. The login details are then immediately used to remove all linked devices from the given Apple Account, as shown in the video (Figure 11) below. Figure 12 displays both the smishing configuration panel and how the smishing page would render when browsed.

Figure 11. A short video by a threat actor demonstrating the customization of a phishing page.

Figure 12. Threat actor generating a link to a malicious landing page (left) and showing what the target page looks like (right)

Scale of Operations Observed via DNS

After expanding our initial cluster from applemaps-support[.]live and pivoting on DNS fingerprints, we identified over 10,000 domains associated with these tools. Interestingly, the domains were registered at different times and used very different hosting infrastructure. This corroborates our assessment that multiple groups are involved, based on our observations of the marketplaces.

One thing these domains all had in common was that they were all either lookalikes of the Apple brand or had generic customer-support-themed domain names such as viewlocation[.]app or find-your-phone[.]help. The word map below in Figure 12 illustrates the relative frequency of the most common keywords.

Figure 13: Most frequent words observed in domain names associated with these campaigns

By stepping back in time in our data, we can observe a small, but growing amount of traffic from our resolvers to verified smishing domains. The query count is comparatively low, but this is expected considering the targeted nature of the attack, along with the pay-as-you-go model used by the tool developers. However, 2025 saw traffic to these domains increase by 350% compared to the previous year, as shown in Figure 14.

Figure 14. Yearly traffic volume observed for campaign-related domains

Detection Avoidance

One interesting quirk we found in some of these tools is the ability to automatically contest detection by security products.

By querying a specific attacker-controlled endpoint hosting the list of smishing domains, and using a headless Chrome browser to attempt connection, the tools can automatically check if any domains have been blocked. If connection to a domain fails, they assume it has been blocked by Google Safe Browsing. The tools will then randomly select an excuse from a list of semi-plausible reasons (“we are a charity for homeless pets,” “my daughter’s dance studio website was flagged,” “the dog ate my homework,” etc.) and submit it to Google to try to have the block removed. It’s difficult to assess how effective this method really is, but at the time of writing most of the smishing domains were not being blocked by Google Safe Browsing.

Figure 15 shows the script code and list of justifications, and Figure 16 shows the output.

Figure 15. List of supporting reasons the threat actor’s script will choose from to contest a block on a domain

Figure 16. Threat actor running the script and its output

What We Learned

What we initially assumed was simple smishing revealed an ecosystem perfectly designed to solve a single problem: turning stolen iPhones into valuable, sellable goods.

Today, a locked device is almost worthless on the black market, while an unlocked, high-end model is easy to resell and can fetch hundreds of dollars. With this in mind, an underground marketplace has emerged which covers the entire digital supply chain from cracking to smishing. As is now commonly the case, the tools are designed to be simple and intuitive enough to offer a very low barrier to entry. This maximizes the potential user base and amplifies their reach.

Interestingly, and somewhat counter-intuitively, our findings show that the data stored on the device is considered to have little value. All the tools we analyzed wipe the device by default as soon as access is attained. Just reselling the device offers the most favorable trade‑off between risk and profit.

Acquiring a phone could be free (depending on how you do it). Unlocking it using one of these underground tools could cost less than a hundred U.S. dollars. Even older iPhone models can still be sold for hundreds of dollars.

As for the tool developers, their pricing model is based on individual unlock attempts, making volume a critical driver of revenue. The low barrier to entry, affiliate resellers and Telegram channels filled with success stories are, of course, intentional.

The growth of this ecosystem can be easily observed in DNS, reflected in the sharp increase in traffic to associated domains we have seen over the past year. As the ecosystem grows, risk increases accordingly—not only in the digital realm, but in the physical world as well. Unlocking capabilities directly translate into real-world theft, turning abstract online activity into tangible personal danger. With a phone in nearly every pocket, there’s no shortage of potential victims.

Sample List of Indicators

The full list of indicators is available on our open Github repository.

The post Lookalike Domains Expose the iPhone Theft Economy appeared first on Infoblox Blog.

How a five-symbol alphabet exposes three “independent” clusters as a single campaign

The Missing Dimension

When analyzing bulk-registered domains for threat intelligence, clusters are commonly identified by two complementary methods: infrastructure signals (name server configuration, registrar, hosting) and naming properties (structural patterns, vocabulary, character composition). Both approaches are well established. Infrastructure signals work because provisioning large numbers of domains is invariably done through automation, and automation tools leave consistent fingerprints. Name servers, registrar choices, and tool-level configurations tend to be uniform across everything a given tool registers, making them reliable grouping criteria. Naming analysis has attracted considerable research attention. Character n-grams, entropy metrics, word-list membership, and domain length distributions are all routinely applied to characterize and separate domain clusters.

What receives far less attention is the numeric component of the domain name when one is present. When a domain name contains digits, for example, chat-21004430.com, connect-02043120.com, the number is typically acknowledged at a surface level: how many digits it contains, whether they are leading or trailing, the digit-to-character ratio, perhaps a rough range check. Deeper statistical analysis of the numeric component, including its digit alphabet, its distributional properties, the encoding choices embedded in its generator, is largely absent from published threat analysis.

That gap is worth closing. The numeric component is not just noise appended to make domains unique. It encodes decisions baked into the generator at design time, decisions that stay constant regardless of which infrastructure cluster the domain lands on, which registrar was used, or when registration happened. That invariance, if detectable, makes the numeric component a particularly reliable provenance indicator for the cluster merge problem: determining whether multiple distinct clusters are actually produced by the same generator.

The case we walk through here involves three clusters, each detected independently by our system, and each appearing to be a self-contained campaign. Our goal is to show that despite appearing unrelated, all three were produced by the same generator. And we’ll do it through the numbers. Infrastructure analysis does its job. It correctly identifies three separate clusters. Naming analysis finds strong but not conclusive overlap. It is the numeric component that settles the question, and it does so through a single observation.

What’s in a Number?

Before getting into the case, it helps to highlight critical distinction. All numbers are equal, but not all numbers in domain names are made equal.

When a domain generation system produces a digit string, it can take two fundamentally different approaches.

Character-level generation treats digits as characters with no numeric meaning. The generator samples from a character alphabet that happens to include some or all of 0–9, the same way it might sample from a–z. The resulting string 31004430 is not the number 31 million. It is a sequence of eight characters, each independently drawn. Digit frequency, range, and distributional properties carry no special information beyond what any character-frequency analysis would reveal. Much of what gets labeled “random-looking” domain number analysis in practice is implicitly assuming this model.

Numeric generation treats the digit string as the representation of an actual number, whether decimal, fixed-width, or expressed in some other base. The generator is working in a numeric space: sampling integers, incrementing a counter, hashing an input, or encoding an index. The digit string you see in the domain name is simply that number rendered in a particular format. And this matters a lot. The choice of number space, how it is sampled, zero-padding conventions, and the base used all leave statistical traces that are specific to that generator and show consistently across every domain it produces.

The two approaches aren’t always easy to tell apart at a glance. A practical test is whether the digit string shows properties that only make sense at the numeric level: a restricted digit alphabet, a leading‑digit distribution that breaks Benford’s Law, uniform coverage of a bounded range, or consistent fixed‑width formatting that points to a specific number space. When those show up, numeric analysis is the right tool to reach for.

There’s a subtlety worth calling out, though. In the case analyzed below, with fixed width strings where all eight positions are filled and digits are drawn uniformly, the two approaches produce output that looks exactly the same from the outside. A generator that samples a random integer from a base‑5 space and formats it as an eight‑digit string is indistinguishable from one that just rolls each digit independently from {0, 1, 2, 3, 4}. Same alphabet. Same length. Same flat distribution.

So, the data can’t tell us how the generator works internally. What it can tell us is that the generator is constrained to a fixed‑width quinary space and samples it uniformly—and that constraint is unusual enough to be diagnostic regardless of implementation.

In the cluster we’re looking at, that constraint is hard to miss. And it’s exactly what turns the link between three separate infrastructure clusters into something you can actually prove, not just suspect.

Three Clusters, One Pattern

Here’s what detection system hands us: three separate clusters, each containing a few thousand .com domains. Treated in isolation, each looks like a coherent cluster. The question is whether they’re related.

A first look at the domains themselves makes you lean toward yes but isn’t sufficient for attribution.

The resemblance is obvious at a glance: the same composition structure, use of overlapping vocabulary, and suspiciously similar-looking numbers. But resemblance isn’t attribution. Any two bulk-registration campaigns targeting the same brand might independently land on {word}-{number}.com. The words connect, join, and link are generic enough that separate actors could pick them without coordination. And those eight-digit numbers could plausibly be random noise added to ensure uniqueness.

So, we have three clusters, clearly similar domains, and reasonable grounds for suspicion. How do you get from suspicion to something you can actually stand behind?

Even at the structural level, the three clusters look suspicious right away. Every single domain across all three follows the same template: {word}-{number}.com. No variation, no outliers across nearly 7,000 domains. The word component is drawn from a fixed vocabulary of nine terms:

chat, connect, engage, interact, join, link, meet, network, sales

All nine words show up in all three clusters at nearly identical rates, roughly 11 percent each. That’s not what you would expect from three teams independently building communication-themed infrastructure. That’s a generator pulling uniformly from a fixed word list.

Figure 1. Left: Domain count per cluster. Right: Word usage proportion per cluster. All nine words appear in all three clusters at nearly identical rates (~11 percent each), consistent with uniform random selection from a fixed vocabulary.

Vocabulary overlap is useful, but it doesn’t close the case on its own. Generic terms like connect or link are plausible independent choices for anyone building a communications-themed persona. What turns the coincidence into provenance is the numeric component.

The Number That Shouldn’t Look Like This

Each domain carries an eight-character numeric suffix: chat-21004430.com, connect-02043120.com, meet-30101420.com. These strings look random. But before accepting that, it’s worth asking a very simple question: which digits are actually used?

Across 6,958 domains and 55,664 individual digit positions, the answer is unambiguous.

Figure 2. Frequency of each digit (0–9) across all 55,664 digit positions in the numeric component. Digits 5 through 9 are completely absent. The expected frequency if digits were drawn uniformly from 0–9 would be approximately 10 percent each (dashed line).

The absence of five digits isn’t just a frequency curiosity. It carves the entire decimal number line into isolated islands. Read naively as decimal integers, the domain numbers can never fall in the ranges such as 5,000,000–9,999,999, or 15,000,000–19,999,999, or 25,000,000–29,999,999, and so on. Every range containing a forbidden digit is structurally unreachable. Once converted to their true integer values (treating the strings as base-5 notation), those gaps disappear, and the underlying uniform distribution becomes immediately visible.

Figure 3. Top row: Sorted scatter of all domain numbers—as decimal readings (left) and as true base-10 integers after base-5 conversion (right). Bottom row: Stacked histograms of the same data. The left column exposes the staircase structure imposed by the absent digits 5–9; the right column shows the uniform distribution that was always underneath.

Digits 5 through 9 do not exist anywhere in this dataset. The generator is producing numbers in base-5, the quinary number system, which uses only the symbols {0, 1, 2, 3, 4}. An eight-character base-5 string addresses a space of 5⁸ or 390,625 distinct values. The 6,958 unique numbers in this cluster represent approximately 1.8 percent coverage of that space, consistent with uniform random sampling from it.

Notably, base‑5 is an extremely uncommon choice in computer systems, which overwhelmingly favor bases aligned with powers of two (binary, octal, hexadecimal) or decimal for human interfaces.

The ~20 percent of domain numbers that begin with 0 (for example, connect-02043120.com) are not errors. They are fixed-width representations of base-5 values smaller than 10000000 base-5, zero-padded to maintain consistent domain name length. This is a formatting decision embedded in the generator.

The Statistical Fingerprint

The digit restriction alone is enough, but there’s a second layer of confirmation in the distribution of the digits that do appear.

Figure 4. Left: Observed frequency of each digit (0–4) across all positions, compared to the expected uniform rate of 20 percent. Right: Leading digit distribution compared to Benford’s Law. Naturally occurring numbers follow Benford’s Law (digit 1 appears ~30 percent of the time; digit 4 only ~10 percent). These domain numbers show an approximately uniform distribution across 0–4, the fingerprint of uniform algorithmic sampling.

Numbers that occur naturally, such as counters, prices, and identifiers that humans assign, tend to follow predictable patterns. The most familiar example is Benford’s Law. In any large collection of naturally occurring numbers, digit 1 appears as the leading digit about 30 percent of the time, digit 2 about 18 percent, and so on, with higher digits becoming progressively rarer. The intuition is simple: in bounded real-world contexts, smaller numbers occur more frequently than larger ones.

These domain numbers don’t follow that pattern at all. Digits 1 through 4 each appear as the leading digit in 19–21 percent of cases, producing a flat, uniform distribution with no preference for any particular digit. That’s the distribution you get from uniform random sampling within a bounded numeric space, not from anything a human would generate, or any natural process would produce.

Restricted alphabet plus uniform distribution equals a generator fingerprint. Two independent actors don’t accidentally build the same one.

Simultaneous Operations Confirm Coordination

There’s one additional piece of evidence. All three clusters have their domains registered within the same narrow window, primarily November and December 2024, in large daily batches of several hundred to over 2,000 domains per day.

Figure 5. Daily domain registrations across all three clusters, November–December 2024. Registration activity overlaps substantially, consistent with a single operator running parallel provisioning jobs rather than three independently timed campaigns.

Campaigns do occasionally overlap in time by chance. At this point, however, the numeric evidence has already made the case, and the registration timeline just confirms it.

Numeric Analysis as a Merge Criterion

Four lines of evidence support attribution to a single generator: structural pattern, vocabulary, numeric encoding, and registration timing. But they are not equally decisive:

The digit alphabet is what elevates resemblance to attribution. Pattern-based clustering groups domains by structure, and infrastructure correctly separates clusters, but neither of them tells you whether those clusters belong to one campaign. The numeric component does.

That’s the practical value here: numeric analysis characterizes the generator, not the deployment. The generator properties don’t change based on which account the domain was registered under, which registrar was used, what name servers are configured in, or when it went live. Two clusters from the same generator will share numeric properties even when every other signal points in different directions.

Conclusion

Numeric components of domain names are frequently undervalued. In practice, they are often treated as noise and either removed prior to analysis or reduced to coarse abstractions such as a binary “contains digits” flag, generic n‑gram features, or entropy scores. This case argues strongly for more careful treatment.

The choices baked into a number format, including its length, its digit alphabet, and how its values are distributed, are decisions made when the generator was built. They travel with every domain that generator ever produces, across every deployment, every registrar, and every registration batch.

Here, a generator that works in base-5, one that simply cannot produce digits 5 through 9, is what ties three separately detected clusters into a single campaign. The odds of three independent actors independently landing on the same unusual encoding are, to put it generously, not meaningful.

Amusing, perhaps. But unmistakable.

Analysis performed on a cluster of 6,958 domains, registered November–December 2024. All domain names, name server configurations, and registration dates are drawn from passive DNS and public WHOIS data.

The post Amusing Numerology: Analysis of the Numbers in Domain Names appeared first on Infoblox Blog.

Hybrid and multi-cloud environments, distributed workforces and escalating cyberthreats are reshaping how organizations manage their networks. At the center of it all are the foundational services that keep everything connected: DNS, DHCP and IP address management (DDI).

During our recent Winter Product Lookback Session, we highlighted several new innovations across Infoblox Universal DDI, Infoblox Threat Defense and Infoblox Universal Asset Insights. But beyond the individual feature updates, the session revealed several broader trends shaping the future of network operations.

Here are the four key takeaways:

1. Unified Visibility Is Essential for Hybrid and Multi-Cloud Networks

As organizations expand across on-premises infrastructure, cloud platforms and remote sites, visibility often becomes fragmented. Distributed tools and devices make it difficult for teams to understand what’s happening across the entire network.

New updates to Universal DDI work to solve this challenge. For example, the new Infoblox Universal IP Address Management experience introduces a “network perspective” that organizes IP spaces from different environments into a unified hierarchy. This makes it easier to identify overlapping address space, enforce policies and maintain consistency across hybrid networks.

Infoblox also introduced new capabilities for managing Microsoft DNS and DHCP environments through the Universal DDI agent. This allows teams to centralize visibility and governance while continuing to run their existing Microsoft infrastructure.

The goal is simple: give teams a single, authoritative view of network services across environments.

2. Security and Resilience Are Moving Closer to the DNS Layer

Because every connection begins with a DNS query, DNS infrastructure has become a critical security control point.

Enhancements to DNS Infrastructure Protection help organizations defend against DNS-based distributed denial-of-service (DDoS) attacks, including amplification, reflection and query floods, while maintaining service availability. By identifying malicious traffic patterns and filtering attacks in real time, organizations can prevent outages that disrupt business operations.

At the same time, upcoming updates to NIOS 9.1 expand built-in security and observability features, including:

• DNS encryption using DNS-over-TLS (DoT) and DNS-over-HTTPS (DoH)
• High-speed DNS telemetry with dnstap logging
• Event-driven notifications via outbound APIs

Together, these capabilities reinforce a growing trend: security and visibility are increasingly embedded directly into critical network services.

3. Asset Intelligence Is Vital for Both Operations and Security

Many organizations struggle with asset visibility because their configuration management database (CMDB) and network discovery tools are working off sprawling, and often outdated, data.

New capabilities in Universal Asset Insights aim to close that gap. For example, the new ServiceNow CMDB reconciliation feature compares configuration records with assets discovered on the network, highlighting discrepancies such as:

• Devices present in ServiceNow but not detected on the network
• Assets discovered on the network but missing from the CMDB
• Configuration mismatches between systems

Additional integrations with platforms like Cisco Meraki, Juniper Mist and Aruba Central also enable faster discovery of network devices and connected assets.

The result is a more accurate asset inventory that organizations can trust for both operational decisions and security investigations.

4. Automation Is Becoming the Default for Network Operations

Manual workflows can’t keep up with the speed of modern infrastructure changes. That’s why automation is becoming central to how organizations manage network services.

The latest Infoblox Terraform provider for NIOS now supports full API coverage, allowing teams to automate DNS, DHCP and IP address provisioning within infrastructure-as-code workflows. This reduces manual handoffs between cloud and network teams while helping prevent configuration errors and IP conflicts.

As infrastructure becomes increasingly dynamic, automation is quickly shifting from a convenient “nice to have” to a necessity.

Looking Ahead

The updates covered in this last Product Lookback Session reflect a broader shift in network operations and security. Organizations are looking for ways to simplify visibility, strengthen security at the DNS layer, improve asset intelligence and automate foundational services across hybrid environments.

This momentum is only accelerating. Through initiatives like Infoblox Labs, customers can preview and activate emerging capabilities before general availability, helping shape the future of the platform.

If you missed the session, you can watch the on-demand recording and continue the conversation in the Infoblox Community.

Ready for the next deep dive into Infoblox’s product roadmap? Registration is now live for the Spring Product Lookback Session on May 28. Save your spot today.

The post 4 Trends Shaping the Future of Network Operations appeared first on Infoblox Blog.