---
title: 'Identifier Hijacking: Mechanisms & Defenses'
url: https://www.emergentmind.com/topics/identifier-hijacking
type: topic
---

# Identifier Hijacking: Mechanisms & Defenses

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 [2205.05473][1702.05349][2605.26665][2410.23678][2603.05023]. 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 [2205.05473][1702.05349][2405.19871][2605.26665][2410.23678][2603.05023].

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 [1610.09417][1704.03138][1906.10478][2406.06483].

| 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 [1412.5052][2205.10174][2307.07610].

## 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 [2205.05473].

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 [2205.05473].

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@` [2205.05473].

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 [1412.5052].

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 [1702.05349][1607.00096].

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 [1702.05349].

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 [1702.05349][1609.05702]. 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 [1607.00096]. 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 [1801.02918]. 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 [2405.19871].

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** [2403.19368].

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 [2307.07610].

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 [2205.10174].

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 [2205.10174].

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 [2605.26665].

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 [2605.26665]. 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 [2410.23678]. 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 [2311.09948].

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 [2603.05023].

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 [1610.09417][1704.03138]. 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 [1906.10478][2406.06483].

Across these domains, several defensive principles recur. First-party knowledge of legitimate bindings reduces ambiguity, as in ARTEMIS for one’s own prefixes [1702.05349]. Validation should be separated from detection, as HEAP shows for routing alarms [1607.00096]. Namespace changes should require authenticated control, as in TSIG-backed secure DNS updates rather than non-secure updates [2405.19871]. Protocol layers should enforce consistent identifier binding across DNS, SNI, certificates, and HTTP authority [2307.07610]. Account systems should verify identifiers before activation and revoke all attacker-planted state during recovery [2205.10174]. Loader security should authenticate the identifier-to-object binding itself rather than only file integrity [2605.26665]. LLM and dialogue systems should treat role metadata as structured, authenticated state rather than inferring it from user-controllable text [2410.23678].  

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.

Source: https://www.emergentmind.com/topics/identifier-hijacking