Identifier Hijacking: Mechanisms & Defenses

• Identifier hijacking is the unauthorized capture or alteration of the binding that makes identifiers authoritative, affecting systems from IP routing to software modules.
• The threat spans multiple domains—DNS, cloud platforms, dynamic linking, and conversational roles—with studies reporting significant compromises such as 68% of IPv4 space.
• Effective defenses require validated binding mechanisms, rigorous verification of ownership, and secure management objects to mitigate the risk of unauthorized control.

Identifier hijacking denotes the unauthorized capture of an identifier, or of the binding that makes an identifier authoritative inside a technical system. In the Internet control plane, this includes takeover of IP address space, AS numbers, domains, certificates, and virtual infrastructure through compromise of the management objects that define ownership; in routing, it includes false claims over the prefix-origin association; in software and application systems, it extends to domain-layer name bindings, account-identifier bindings, loader resolution of shared objects, conversational role markers, and tracking labels (Dai et al., 2022, Chaviaras et al., 2017, Ozkan et al., 26 May 2026, Chen et al., 2024, Calatrava et al., 5 Mar 2026). This suggests a unifying view: the attack surface is often not the resource alone, but the mechanism that binds an identifier to a principal, object, route, role, or trajectory.

1. Conceptual scope and representative forms

The literature uses the term most directly for cases in which the attacker seizes an explicit identifier or an ownership-relevant association. Representative targets include RIR/LIR accounts, IPv4 and IPv6 allocations, ASNs, domains, certificates, cloud accounts, BGP prefix-origin bindings, authoritative DNS zone contents, cloud resource names, DT_NEEDED-style shared-library references, LLM speaker-role markers, and distributed-tracking labels (Dai et al., 2022, Chaviaras et al., 2017, Nosyk et al., 2024, Ozkan et al., 26 May 2026, Chen et al., 2024, Calatrava et al., 5 Mar 2026).

A useful distinction emerges between direct hijacking and adjacent phenomena. Some papers describe direct takeover of an existing identifier-binding relation, such as control of a domain’s authoritative data, a prefix’s legitimate origin, or a shared object chosen by the loader. Others show that systems may manufacture effective identifiers from artifacts not intended as identifiers, such as browsing semantics or the IPv4 ID field. Those cases are better understood as identifier inference, identity correlation, or identifier repurposing rather than classic hijacking (Guha, 2016, Guha, 2017, Klein et al., 2019, Daymude et al., 2024).

Setting	Identifier under attack	Typical mechanism
Internet resource management	LIR/SSO accounts, IPv4/IPv6 allocations, ASNs, domains, certificates, cloud accounts	password-recovery redirection and account takeover
Interdomain routing	IP prefix and legitimate origin AS	bogus origin or subprefix advertisement
Authoritative DNS	domain name and zone contents	unsolicited DNS UPDATE
Cloud platforms	cloud hostname or service name named in DNS	re-registration of a released resource
Dynamic linking	path, SONAME, dlopen() target, or Build-ID	resolution of the wrong shared object
LLM dialogue systems	speaker role, turn ownership, conversation state	fabricated assistant turn and new user turn
Distributed tracking	target label	spoofed track matched under the consensus metric

A recurring misconception is that identifier hijacking is only a synonym for BGP prefix hijacking. The surveyed work shows a broader pattern: the attacker often wins by controlling administrative, naming, or selection state that downstream components already trust (Schlamp et al., 2014, Sudhodanan et al., 2022, Anderson et al., 2023).

2. Internet resource ownership and management-plane takeover

A central formulation appears in the study of Internet resource management fabric. Rather than directly attacking a victim’s routing, DNS zone, cloud VM, or certificate issuance workflow, the attacker first hijacks the account that manages those resources and then changes ownership-relevant state. The relevant management objects include LIR/SSO accounts, IPv4 and IPv6 allocations, ASNs, reverse-DNS delegations, RPKI objects such as ROAs, registry data documenting routing authority, registrar accounts controlling domain names and nameserver settings, CA accounts through which certificates are requested or revoked, and IaaS accounts controlling VMs, disks, subscriptions, and related resources (Dai et al., 2022).

The threat model in that work is deliberately weak. The attacker is off-path, does not initially sit on the network path, and does not need malware on the victim device. The main capability is DNS cache poisoning against the provider’s mail infrastructure or password-recovery workflow. Three poisoning families are evaluated: BGP-assisted interception of DNS traffic (“HijackDNS”), SadDNS-style port inference using ICMP side channels, and IPv4 fragmentation-based poisoning (“FragDNS”). The end-to-end workflow is target discovery, poisoning of the provider resolver, triggering of password recovery, reception of the reset link at an attacker-controlled host, password reset, login, and subsequent persistence through creation of new privileged users, alteration of contact information, or disabling of notifications (Dai et al., 2022).

The scale measurements are consequential. The study states that network adversaries can take over and manipulate at least 68% of the assigned IPv4 address space and 31% of the top Alexa domains. It further reports extraction of customer email addresses from WHOIS for 74.62% of ASes in RIR datasets and 10.60% of owners in the Alexa Top 100K registrar dataset; across the study, account-associated email addresses were extractable for 41% of customers. Where addresses were not public, over 24% of observed account emails used one of ten common local parts such as hostmaster@ or domain@ (Dai et al., 2022).

A related ownership-hijacking model targets abandoned Internet resources rather than live accounts. When domains referenced in RIR database objects expire, attackers can re-register those domains and thereby recover the contact identities associated with inetnum, aut-num, and related objects. The paper identifies this as hijacking of network ownership information stored in RIR databases. In the RIPE service region, the measurement found 214 expired domains tied to resource-holder groups; after combining registry inactivity and BGP inactivity, 13 effectively abandoned groups remained, comprising 73 /24 networks and 7 ASes vulnerable to stealthy abuse (Schlamp et al., 2014).

These two lines of work emphasize a common structural point. The decisive identifier is often not the prefix or hostname in isolation, but the management object or ownership metadata that other operators consult when deciding who is authorized to use it. This suggests that identity takeover in the Internet control plane is frequently an attack on the governance layer rather than only on packet forwarding.

3. Routing-plane identifier hijacking

In interdomain routing, the identifier under attack is the association between an IP prefix and the AS authorized to originate it. BGP lacks built-in authentication of route advertisements, so an AS can falsely announce reachability to a prefix it does not own. The literature distinguishes exact-prefix hijacking, sub-prefix hijacking, and more elaborate path manipulations, while repeatedly noting that sub-prefix hijacking is often more globally effective because longest-prefix matching dominates forwarding (Chaviaras et al., 2017, Schlamp et al., 2016).

The ARTEMIS line of work frames prefix hijacking as an instance of identifier hijacking in which the defended AS already knows the ground truth for its own resources. ARTEMIS continuously receives live control-plane observations from Looking Glass servers via Periscope, RIPE RIS streaming, and BGPmon, and compares the observed origin AS against the legitimate origin configured for each protected prefix. Detection is therefore based on observing an announcement with an illegitimate origin AS for one of the defended prefixes, after which mitigation is triggered automatically by de-aggregation into more-specific prefixes (Chaviaras et al., 2017).

The reported timings define a fast, first-party response loop. One evaluation reports hijack detection in less than 1 minute, mitigation initiation within seconds, and complete mitigation in around 5–6 minutes. Earlier PEERING-based experiments reported sub-prefix hijack detection always within 10 seconds and exact-prefix detection around 30 seconds on average, with end-to-end mitigation in at most about two minutes when ARTEMIS acts automatically (Chaviaras et al., 2017, Sermpezis et al., 2016). A key limitation is explicit: prefix de-aggregation is effective for prefixes larger than /24, but may fail for /24 because more specific advertisements are often filtered.

The literature also addresses the problem of validation rather than raw detection. HEAP formalizes Internet routing as a language of observable routes and then uses IRR evidence, topology reasoning, and Internet-wide TLS key continuity to rule out benign incidents. In one evaluation it legitimized 56.93% of observed strict subMOAS events, 81.15% of those affecting top-1M website networks, and 8.24% of publicly reported BGPmon alarms (Schlamp et al., 2016). The implication is that routing identifier conflicts are common, but many are not malicious hijacks.

Operational studies show why stronger routing defenses remain underdeployed. A survey of 75 network operators found that 71% had not deployed RPKI and only 12% used the full functionality of RPKI (ROA + ROV). Detection was heavily outsourced: 61.3% used a third-party detection service and 78.6% effectively relied on third parties in some form. For mitigation, 62.7% would both announce more specific prefixes and contact the offending network or its providers (Sermpezis et al., 2018). This suggests that deployability, trust, and false-positive tolerance remain central constraints on routing-plane anti-hijack mechanisms.

4. DNS, cloud, and domain-layer binding failures

Authoritative DNS exposes a direct namespace-control variant. DNS dynamic updates were originally devised without authentication, and non-secure deployments accept RFC 2136 update messages from unauthorized clients. This permits “zone poisoning”: unauthorized modification of authoritative A, AAAA, MX, TXT, NS, or CNAME records. In a scan over 353,870,510 unique domain names, 3,855,615 unique nameserver IPv4 addresses, and 5,032,117,394 domain–nameserver pairs, the study found 381,965 vulnerable domains, 5,575 vulnerable nameserver IPs, and 679,930 vulnerable domain–NS pairs. The attack consequences include domain hijacking, email interception, malicious delegation, and compromise of domain control validation for certificate issuance (Nosyk et al., 2024).

Cloud platforms expose a closely related, but operationally distinct, problem: dangling resource abuse. Here the victim leaves a DNS record pointing to a released cloud resource, and the attacker re-registers the released resource. The paper defines a hijack as “the appropriation of a (sub)domain name through the re-registration of a released cloud resource pointed to by a dangling DNS record.” It reports 20,904 instances of hijacked resources and shows that attackers predominantly target resources reclaimable through freetext identifiers rather than random cloud IP allocation. Contrary to earlier assumptions, no IP-based takeovers were found in the abuse dataset. The most common abuse was blackhat search engine optimization, comprising 75% of observed abuse, and more than $\frac{1}{3}$ of hijacks persisted for more than 65 days (Frieß et al., 2024).

At the application edge, domain-layer identifier hijacking can arise even without DNS takeover when different protocol layers disagree about the authoritative name. “Domain name misinformation” is defined operationally by a mismatch in which the encrypted HTTP Host value does not match the TLS server_name value and is not covered by the TLS certificate’s subject or subjectAltName. Domain fronting, domain faking, and domainless fronting all exploit this looseness. The paper further shows an endpoint-side attack in which LD_PRELOAD hooks browser I/O and rewrites the HTTP Host field just before encryption, allowing an adversary to man-in-the-middle traffic to a CDN that supports fronting while leaving DNS, SNI, certificate validation, and destination IP apparently normal (Anderson et al., 2023).

These cases show that authoritative control over a name is often distributed across multiple layers: DNS, TLS SNI, certificate SAN/CN, HTTP authority, cloud platform routing, and certificate validation. A plausible implication is that identifier hijacking becomes especially likely when one layer authenticates a name but another layer routes on a different one.

5. Account lifecycle and software-resolution variants

Account systems introduce an identity-binding problem at creation and recovery time. The account pre-hijacking study shows that an attacker who knows only the victim’s email address can act before the victim creates an account, planting state that later yields access after the victim creates or recovers the account. The paper identifies five attack classes—Classic-Federated Merge, Unexpired Session, Trojan Identifier, Unexpired Email Change, and Non-verifying IdP—and reports that at least 35 of 75 popular services were vulnerable to one or more such attacks (Sudhodanan et al., 2022).

The common failure is premature or incomplete verification of ownership of the claimed identifier. In some services, the attacker creates a classic account with the victim’s email and later survives a federated merge; in others, old sessions remain valid after password reset; in others, the attacker leaves behind a federated identity, alternate recovery identifier, or pending email change. The paper’s root-cause statement is explicit: failure to verify ownership of the claimed identifier. The corresponding mitigation requirements are likewise explicit: strict identifier verification before allowing further actions, revocation of other sessions and authentication tokens on password reset, cancellation of pending email changes, and explicit review of linked federated identities, alternate email addresses, and phone numbers (Sudhodanan et al., 2022).

At the software-runtime level, shared library hijacking is reformulated as a loader-resolution authenticity failure. The issue is not necessarily that a trusted library file is modified, but that the dynamic linker resolves a symbolic dependency such as a SONAME, a DT_NEEDED entry, a dlopen() target, or an internally requested module to the wrong ELF shared object. The proposed defense is a loader-centric verification framework integrated through LD_AUDIT, with two identity models: path-bound identity and location-independent Build-ID-based identity, each combined with SHA-256 and an authenticated manifest (Ozkan et al., 26 May 2026).

The identity policy is expressed as approved pairs such as $\langle \text{Build-ID}, \text{SHA256} \rangle$. At runtime, each DSO load event is checked against the signed manifest before execution continues. The paper argues that this closes a gap left by file-centric integrity systems: a malicious library can be syntactically valid, untouched since creation, and even acceptable to a file-integrity mechanism, yet still be the wrong object for the dependency resolution event (Ozkan et al., 26 May 2026). This is a direct analogue of identifier hijacking at the loader boundary: the symbolic reference is rebound to an attacker-controlled artifact.

6. Boundary cases, generalized forms, and defensive principles

Several papers broaden the idea of identifier hijacking beyond classic ownership claims. In LLM systems, “Pseudo-Conversation Injection” is a goal-hijacking attack that fabricates an assistant response to the original prompt and then appends a malicious new user prompt, inducing the model to treat the initial task as already completed. The paper explicitly frames the weakness as one of role identification: models “cannot reliably distinguish between genuine and fabricated roles within a conversation.” Targeted, universal, and robust pseudo-conversation strategies all outperform a baseline “ignore the previous” attack, with targeted pseudo-conversation reaching 92.0% ± 0.7 on ChatGPT 4o and 84.5% ± 0.4 on Qwen 2.5 in the reported evaluation (Chen et al., 2024). A related ICL paper shows that tiny suffixes attached to in-context demonstrations can hijack the demonstration channel and force attacker-chosen class outputs, with attack success rates reaching 100 on several GPT2-XL tasks (Zhou et al., 2023).

In distributed multi-target tracking, “label hijacking” names an identity-level false-data-injection attack on track-consensus-based DMTT. The attacker injects spoofed tracks so that a victim label is first captured by the spoofed track and then transferred to an impostor target, causing the network to continue believing it tracks the victim while actually following another trajectory. The attack is implemented entirely through the kinematic matching layer, using the same OSPA/OSPA$^2$-based track-consensus logic that normally enforces identity agreement (Calatrava et al., 5 Mar 2026).

Other works are better read as adjacent rather than direct instances. Semantic identification attacks on web browsing use page semantics or category distributions to link sessions from the same user even in the absence of cookies, device IDs, or network identifiers. The papers are explicit that this is not classic identifier hijacking, but identifier inference or identity correlation: behavior becomes a surrogate identifier (Guha, 2016, Guha, 2017). Likewise, the IP ID field can be turned into a device identifier because modern operating systems derive it from long-lived secret kernel state; the same field has a long history as a side channel for off-path inference and fragment injection. In that setting, the attacker hijacks either the semantic role of the IPv4 Identifier in reassembly or the information leaked by IPID evolution, rather than stealing an existing application-layer identifier (Klein et al., 2019, Daymude et al., 2024).

Across these domains, several defensive principles recur. First-party knowledge of legitimate bindings reduces ambiguity, as in ARTEMIS for one’s own prefixes (Chaviaras et al., 2017). Validation should be separated from detection, as HEAP shows for routing alarms (Schlamp et al., 2016). Namespace changes should require authenticated control, as in TSIG-backed secure DNS updates rather than non-secure updates (Nosyk et al., 2024). Protocol layers should enforce consistent identifier binding across DNS, SNI, certificates, and HTTP authority (Anderson et al., 2023). Account systems should verify identifiers before activation and revoke all attacker-planted state during recovery (Sudhodanan et al., 2022). Loader security should authenticate the identifier-to-object binding itself rather than only file integrity (Ozkan et al., 26 May 2026). LLM and dialogue systems should treat role metadata as structured, authenticated state rather than inferring it from user-controllable text (Chen et al., 2024).

Taken together, these results support a broad but technically precise conclusion: identifier hijacking is fundamentally a binding-authenticity problem. Whether the identifier is a prefix, a domain, an email address, a cloud hostname, a shared-library reference, a speaker role, or a target label, the attack succeeds when a system accepts a false reassociation as if it were the legitimate one.