HOWLR: A Client-Driven Approach to BGP Hijack Detection CONSTANTINE DOUMANIDIS, ANYA KALOGERAKOS, and MARIA APOSTOLAKI, Prince-
arXiv:2606.21845v1 [cs.NI] 20 Jun 2026
ton University, USA BGP hijacking enables impersonation attacks in which adversaries divert traffic at the prefix level and serve malicious content to unsuspecting clients. Detecting such attacks has traditionally been the responsibility of network operators, leaving end hosts exposed for hours. We argue that end hosts can detect prefix-level impersonation independently, exploiting a fundamental asymmetry: a BGP hijack diverts traffic for an entire IP prefix, but impersonating every co-hosted service within that prefix is prohibitively difficult at scale, especially if each service is authenticated by a different Certificate Authority. We propose HOWLR, a tool that operationalizes this insight by using co-hosted, TLS-authenticated services as witnesses: if a client can no longer authenticate them, it has evidence of an ongoing attack. This work evaluates the feasibility of this method by quantifying the existence and diversity of witnesses in the wild. We show that HOWLR can protect 89% of Tor relay prefixes, and 75% of Bitcoin pool gateway prefixes.
1
Introduction
Because BGP does not authenticate route announcements by default, adversaries can divert traffic through their infrastructure — a BGP hijack. Despite numerous efforts to prevent them, such attacks remain common: in 2024 alone, BGPWatch reported 5,673 possible hijack events [47]. Particularly dangerous are impersonation attacks, in which the attacker impersonates the legitimate destination rather than dropping traffic or returning it to the legitimate destination. In impersonation attacks, the affected end hosts assume they are communicating with the legitimate destination, allowing adversaries to gain confidential information and/or inject malicious content. For instance, a BGP-enabled impersonation attack targeting the Korean provider Kakao in 2022 allowed the attacker to serve malicious content, ultimately resulting in the theft of 2 million US dollars from users of KLAYswap [39]. Similarly, an attacker hijacked an Amazon prefix to obtain a valid TLS certificate for a Celer subdomain and redirect users of the Celer Bridge from the legitimate UI endpoint hosted on Amazon to attacker-controlled servers. As a result, users unknowingly approved malicious transactions, leading to the immediate theft of $235,000 in user funds. In a BGP-enabled impersonation attack, a client connected to the impersonated service has little ability to detect malicious behavior—especially when the communication lacks authentication or the attacker has already obtained a bogus certificate, as in the examples above. Solutions for detecting BGP hijacks typically operate at the network level and are deployed by network operators. This is because most defenses rely on analyzing BGP advertisements, which requires access to diverse BGP data feeds—resources that are generally unavailable to end-users, are slow and still suffer from blind spots [49, 4]. Analyzing more accessible data, such as RouteViews [44], is not adequately diverse, is only updated every 15 minutes, and could create a bottleneck if used by all end-hosts. Data-plane detections, which can be initiated by end hosts, such as sending traceroutes or pings, can be incomplete or subject to tampering [33]. There is a clear and dangerous gap between the victims of BGP-enabled impersonation attacks (i.e., clients unknowingly connected to bogus servers) and the entities capable of detecting them (i.e., network providers). In this paper, we argue for a practical, end-host-based detection approach built on a simple but powerful observation: end hosts can detect BGP-enabled impersonation attacks by leveraging the mismatch between the broad impact of BGP hijacks and the limited scalability of successful impersonation. Because routers discard IP prefix announcements that exceed a certain maximum length (typically /24 for IPv4, and /48 for IPv6), an attacker cannot hijack a single IP Authors’ Contact Information: Constantine Doumanidis; Anya Kalogerakos; Maria Apostolaki, Princeton University, Princeton, New Jersey, USA.
2
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
address on which the target service is hosted. Instead, they must divert traffic for an entire /24 block, affecting at least 28 host addresses. While diverting this many clients requires only a single BGP prefix announcement, impersonating them all is significantly harder. Concretely, the attacker would need to convince all their prospective connections that they are communicating with the legitimate destinations. For destinations that host authenticated services, impersonation would require either compromising the service’s private key or deceiving a Certificate Authority (CA) into issuing a fraudulent certificate [5]. Although recent attacks and research have shown such compromises are possible, they do not scale to large numbers of servers. While an attacker might attempt to relay traffic for non-targeted services back to their legitimate destinations, doing so would require complex routing configurations and would constrain the attacker’s location to highly connected ones who are unlikely to risk their reputation. Leveraging these insights, we develop HOWLR, a detection mechanism that enables end hosts to detect whether a BGP-enabled impersonation attack is happening on a service they are connected to, independently of network-level monitoring. To achieve this, HOWLR connects to servers hosted at the same prefix as the service of interest and authenticates. We call such servers witnesses, and they are primarily TLS-enabled websites due to their reliability and prevalence. At runtime, a local daemon periodically validates these witnesses against a pre-established database; a simultaneous failure in witness authentication serves as a high-confidence alert of prefix-level interception, prompting the end host to take defensive action. The feasibility of such an approach depends on the empirical density and diversity of witnesses, namely cryptographically authenticatable services, within any given destination prefix. We conduct a measurement study to characterize the cohabitation patterns of such witnesses across the broader routed IPv4 address space. We find that witnesses exist in a substantial fraction of service-hosting prefixes; crucially, all measured popular destination prefixes contain witnesses authenticated by at least two distinct Certificate Authorities, providing the necessary heterogeneity for robust detection. HOWLR can effectively protect a broad range of security-sensitive applications. For instance, it protects 89% of prefixes hosting Tor relays —a frequently targeted [36, 34, 24] service that is vulnerable to BGP hijacks [42, 46]. Likewise, it protects 75% of Bitcoin mining pool gateway prefixes, another high-value target for adversaries capable of routing attacks [2]. 2
Background
We begin this section with a motivating example that illustrates the threat targeted by HOWLR. To make the motivation more engaging, we highlight a recent real-world attack rather than a hypothetical one. We then describe the threat model manifested in this attack and argue that it captures a broader class of practical threats. Finally, we discuss why existing detection mechanisms are inadequate—a fact underscored by the continued success of such attacks in the wild. 2.1 Motivating Example Figure 1a illustrates the infamous attack against the Celer bridge (CBridge) that resulted in 235,000 USD in assets being stolen [16]. CBridge is a service that facilitates quick and inexpensive cryptocurrency and assets transfers between different blockchains. The attacker targeted clients of CBridge, such as those displayed on the left side of Fig. 1a. These clients were originally using CBridge by visiting its front-end website, which was served by Amazon (AS 16509). During the attack, clients were redirected to an attacker-controlled server serving a malicious copy of the CBridge UI. To achieve this, the attacker first compromised a router belonging to QuickHost (AS 209243) and hijacked the Amazon prefix where CBridge’s server was hosted (44.224.0.0/24). Having diverted traffic originally destined to CBridge to QuickHost, the attacker (i) obtained a valid certificate from
HOWLR : A Client-Driven Approach to BGP Hijack Detection
3
Amazon
Clients
HOWLR Client
Internet
5. Compare & Alert
Internet QuickHost
Malicious Server
Etisalat
Paths to legitimate website Hijacked paths to adversary AS
GoGetSSL
44.235.216.69
Witness A
Amazon
44.235.216.139
2. Find witnesses & get certificates
44.235.216.165
QuickHost
Adversary
Witness B
3. Build witness DB Witness
Tet
Celer Bridge
1. Resolve prefix
AT&T
CBridge
AT&T
Certificate
44.235.216.139 44.235.216.165
4. Poll Witnesses Witness DB
(1a) Real example of BGP-enabled impersonation at- (1b) HOWLR resolves the IP address of the target tack [16]: The attacker, operating from QuickHost, service (Step 1), and enumerates its prefix to identify launched a subprefix hijack to divert clients’ requests witnesses and retrieve their certificates (Step 2), which to CBridge through her own server, impersonating the it stores in a local database (Step 3). HOWLR periodilegitimate service. Before serving malicious content, cally polls witnesses for their certificates (Step 4), and she obtained a valid TLS certificate, making it appear compares retrieved and stored certificates (Step 5). as though clients were securely connected to the real HOWLR alerts the user if it detects discrepancies that site. indicate an interception attack.
GoGetSSL, a trusted Certificate Authority hosted under Tet (AS 12578); and (ii) served the clients whose traffic was diverted a malicious copy of the CBridge website that enabled the assets theft. This example highlights two critical vulnerabilities in the Internet’s infrastructure in practice: (i) BGP hijacks can succeed even against security-conscious operators, and (ii) it is possible to acquire a bogus certificate for a legitimate website. While the exact mechanics are not central to our work, we provide additional context on how the attacker managed to divert Amazon traffic and acquire the bogus certificate. First, the attacker was able to divert traffic to an Amazon prefix for approximately 3 hours, despite the fact that Amazon’s prefixes are seemingly protected by RPKI. As explained by CertiK [9], the attacker evaded detection by announcing a longer prefix (compared to the /11 originally advertised) with an Amazon AS as the origin, and QuickHost as the next hop. Second, the attacker was able to obtain a fraudulent certificate by leveraging the ongoing BGP hijack. Specifically, she exploited the automated domain validation process to convince GoGetSSL—a trusted Certificate Authority—that she owned the CBridge domain. This allowed her to issue a valid TLS certificate for the impersonated service. This attack has been previously described in detail in [5]. 2.2
Threat Model
The above attack generalizes to a broader threat model in which an attacker hijacks a prefix and impersonates a service. This model underpins several real-world incidents [8, 39] and has been analyzed in the literature [5, 13]. We now break down the two steps of the model, namely BGP hijack and impersonation, and argue for the practicality of each. BGP hijack: The attacker exercises control over a BGP-speaking router by either compromising the infrastructure of a network operator [28, 1], or by establishing her own Autonomous System (AS) [43, 7]. Although the latter option necessitates a modest financial investment - a conservative estimate places the annual operational costs for a small AS at approximately 2,500 USD - these expenditures can be recouped by the substantial revenue the attacker stands to generate as a result of her successful attack [39]. Using her access to a BGP-speaking router, the adversary issues malicious BGP announcements to hijack the IP prefixes of the services that she wishes to target. In particular, the adversary can perform more specific prefix or forged-origin subprefix hijacks that allow her to divert traffic destined for the victim prefixes to her own AS. The success of these attacks depends on the RPKI status of the victim prefixes. IP prefixes shorter than /24, that are not covered
4
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
by a Route Origin Authorization (ROA) can be effortlessly targeted using a more specific prefix hijack. In this scenario, the attacker redirects all traffic to the victim prefix by announcing a longer prefix, exploiting the longest-prefix preference of BGP routers. IP prefixes covered by ROAs are also not immune to hijack attacks. ROAs are often observed to feature an overly permissive maxLength attribute, rendering many covered prefixes vulnerable to forged-origin subprefix hijack attacks [14], allowing the adversary to again intercept all victim traffic. Even when a prefix is properly protected by RPKI in theory, it is not necessarily safe from hijack attacks in practice [19] since approximately 43% of ASes currently do not enforce route origin validation [20]. The adversary can also attempt to completely evade RPKI validation by making an equally specific prefix announcement with the genuine origin, and itself prepended as a next hop, which will allow her to statistically divert 50% of traffic destined for the victim prefix [41, 15]. Impersonation: The attacker’s goal is to convince clients connected to the targeted service or host within the hijacked prefix that they are communicating with the legitimate destination. For services that do not employ some form of authentication, such as DNS servers without DNSSEC or web servers without TLS certificates, this becomes trivial. The attacker simply responds to connected clients with malicious content. For services that employ some form of server authentication, such as websites, the attacker can obtain access to the private key to the certificate served by the victim service, or convince a legitimate Certificate Authority (CA) to issue a new one for her [5]. While recent incidents have shown that fooling a CA into issuing a fraudulent certificate is possible, doing so for all co-hosted services within a prefix is not practical: it requires independently repeating the attack for each domain and even each relevant CA. Moreover, CAs that do not rely on automated domain validation are altogether immune to this technique, making full-prefix impersonation infeasible in practice. We therefore consider this out of scope for our threat model. 2.3
Traditional Hijack Detection Limitations
Traditional BGP hijack detection relies on network operators, is often slow, and is agnostic to the criticality of the targeted services. Many approaches require access to diverse BGP data streams [29, 27, 23], multiple vantage points [38, 22], and collaboration with other ASes [17] —resources typically inaccessible to end users. Detection is also slow, since many methods rely on wide temporal windows [29, 31, 35] or on aggregated BGP data sources like RouteViews [44], which publishes BGP updates only every 15 minutes. Even in the case of methods that can be adapted to run in real-time using live BGP data feeds, researchers expect increased false positives [37]. Finally, these methods are oblivious to the specific applications being targeted, making the timely detection, user alert, and incident response process inefficient. Independent of the detection method, mitigation remains a slow and manual process that leaves users exposed for prolonged periods of time. This is because removing malicious routes from BGP routing tables often requires manual coordination between network operators, such as contacting affected ASes and installing filters. Consequently, response times often lag for hours, as seen in recent high-profile incidents [16, 1]. During this time, users of the targeted services remain unaware and vulnerable. Incidents such as the one in §2.1 highlight the urgent need to make timely hijack detection accessible to end hosts. 3
Overview
In this section, we introduce HOWLR, a lightweight detection mechanism that enables a client to identify when its connection to a target service is being impersonated. HOWLR relies on the insight that during an interception attack, services hosted in the same IP prefix as the target service cannot be authenticated. By detecting this failure, the client can take timely action to mitigate the
Unprotected
Light
Strong
30 20 10 0
5
Prefixes CDF
IP Prefixes
HOWLR : A Client-Driven Approach to BGP Hijack Detection
1 0.5
Random Prefixes Popular Services
0 BTC Nodes Pool Gateways
Tor Relays
Application
0
50 100 150 200 Number of Witnesses
250
(2a) HOWLR can protect the prefixes of 65% of Bitcoin (2b) Prefixes that host popular services are more likely nodes, 75% of pool gateways and 96% of Tor relays. to have witnesses, compared to random prefixes.
risk. For instance, in a web browser, this could mean preventing a spoofed malicious website from loading; in a P2P network it could mean removing the impersonated peer from the active peer set. HOWLR requires only that the client be able to initiate connections to other hosts within the target service prefix. HOWLR operates in two steps: witness discovery, and active monitoring. At initialization, HOWLR takes as input the target service IP prefix-specifically, the longest prefix that BGP routers will propagate (/24 for IPv4 or /48 for IPv6). HOWLR then enumerates the IP addresses in the prefix and attempts to connect to the corresponding hosts. For each responsive host, it scans it for open ports, and then attempts to perform a TLS handshake on each open port to retrieve any offered certificates. HOWLR validates the certificates it retrieves, and adds valid ones and their corresponding hosts to its witness database for the target prefix. Once witness discovery is complete, HOWLR actively monitors witnesses by periodically, or on-demand, performing TLS handshakes with them and comparing the retrieved certificates with the ones that in the witness database. If HOWLR cannot authenticate the witnesses —e.g., due to certificate mismatches or failed connections— HOWLR raises an alert, triggering a response according to the client’s configuration. Example application: We retroactively apply HOWLR to the CBridge incident discussed in Section 2.1 and show how it could have protected clients. Suppose that the client under AT&T in Figure 1b deployed HOWLR when it first accessed the bridge prior to the attack. In Step 1 HOWLR observes the domain names of CBridge that the client loads, and resolves them to their IP addresses. In Step 2 HOWLR enumerates the IP addresses in Amazon’s 44.235.216.0/24 prefix, where the bridge is hosted, and looks for witnesses. Among others, it identifies witnesses A and B, the web servers of PIXELL AI, a video enhancement SaaS, and AdRoll, an advertising platform, and obtains their certificates, issued by Amazon and GlobalSign. While we lack historical certificate data from the time of the attack, scans today suggest that multiple witnesses would have been available. In Step 3, HOWLR stores the IP addresses, certificates, and identification timestamps of the witnesses in its database. Now assume that the adversary launches her hijack by announcing 44.235.216.0/24 as described in Section 2.1. In Step 4, when HOWLR polls witnesses, its traffic will be redirected to QuickHost. The attacker can either drop HOWLR’s traffic or attempt to serve bogus certificates obtained by fooling a CA into issuing new ones [5]. In Step 5, HOWLR detects the mismatch between the adversary’s certificate set and the one in its database and raises an alert, preventing the user from accessing the malicious bridge website, which would have led to the theft of their assets. 4
Measuring Witnesses in the wild
HOWLR introduces a client-driven approach to detecting BGP-enabled impersonation by validating the integrity of an entire IP prefix, rather than individual hosts. This is made possible through
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
Prefixes CDF
6
1
1
1
0.5
0.5
0.5
0
0 10 −1
100
101
ASes CDF
Avg. Concurrent IPs/Prefix
0 10 −1
102
100
101
100 101 102 103 104 105 106
Avg. Concurrent CAs/Prefix
Avg. Concurrent Certs/Prefix
1
1
1
0.5
0.5
0.5
0
0 100 101 102 103 104 105 106
0 100 101 102 103 104 105
Avg. Concurrent IPs/AS
100101102103104105106107
Avg. Concurrent CAs/AS Global
Europe
N. America
Africa
S. America
Oceania
Avg. Concurrent Certs/AS Asia
Fig. 3. Distribution of IPv4 prefixes / ASes over average concurrent witness IPs/CAs/Certificates for witnesshosting prefixes / ASes between April 15 - May 15, 2026.
witnesses—services that cohabitate a prefix and serve as indirect signals of authenticity. In this section, we outline the requirements for such witness-based detection to succeed, and demonstrate through measurements that these requirements are met across real-world prefixes. Requirements for Witness-Based Validation For HOWLR to reliably detect prefix-level impersonation attacks, clients must be able to identify a set of witnesses that satisfy three core properties: Prefix-locality: The witness must reside within the same /24 prefix as the target service. Since BGP hijacks are typically carried out at the prefix level, prefix-local witnesses will be co-affected by a hijack, enabling detection through shared inconsistencies. Authenticatability: The witness must expose a cryptographic identity—such as a TLS certificate or SSH key—that HOWLR can verify. Public key infrastructure (PKI), and in particular CA-signed TLS certificates, are attractive in this context: they are widely deployed, easy to validate through standard handshakes, and difficult to obtain fraudulently at scale. Operational Independence: To ensure resilience, the witness set should ideally span multiple administrative domains and CAs. This redundancy increases both availability by avoiding coordinated outages (e.g., maintenance, power loss, DoS attacks) and robustness against compromise (e.g., a single CA being tricked into issuing fraudulent certificates [5]). Measuring Witnesses Availability We now examine whether real-world prefixes satisfy these requirements. Specifically, we evaluate the availability of prefix-local, authenticatable, and operationally independent witnesses across the IPv4 prefix space. Methodology: A comprehensive investigation of witness availability requires enumerating over all IP addresses, establishing reachability to the corresponding hosts, iterating over all ports, and attempting TLS handshakes to retrieve certificates and verify their validity. Tools like ZMap [12] can perform internet-wide scans, however, doing so at our desired granularity would be impractical given the time and resource requirements. Furthermore, such scans require special considerations
2,000 1,000 0
1 2 3 4 5 6 7 8 9 1011
1 2 3 4 5 6 7 8 9 10111266
Certificate CAs in /24 Prefix
Certificates per IP
3,000 2,000 1,000 0 443 2083 2087 2096 8443 2053 995 993 465 2078 2080 8883 5228 5030 5031
30 20 10 0
7
Certificates
IP Addrs.
IP Prefixes
HOWLR : A Client-Driven Approach to BGP Hijack Detection
Port Number (4a) 57% of sampled /24 prefixes (4b) More than 82% of hosts with (4c) 82% of certificates are served with witnesses have certificates is- certificates only serve a single cer- on port 443. Other ports contributed minimally. sued by 2+ unique CAs. tificate.
as they can overwhelm the scanned networks and hosts, and can trigger Denial-of-Service (DoS) defenses that undermine the fidelity of the results. We address these challenges using a two pronged approach: (i) We perform a small scale, but comprehensive, low-rate port scan and certificate retrieval over a sample of 100 /24 prefixes: 50 that host popular online services [21, 48], and 50 that are randomly drawn [32] and expose at least one public service. (ii) We process 5 months of newly issued certificates that were submitted to the Let’s Encrypt "Willow" and Cloudflare "Nimbus" Certificate Transparency (CT) logs. We validate these certificates and identify the hosts that serve them via DNS resolution. Our small scale scan gives us witness availability insights at a fine grain, while processing CT logs allows us to answer questions on broad scale witnesses availability. Prefix-local and authenticatable witnesses: Our fine-grain scan indicates high witness availability for services hosted on common infrastructure, and more limited coverage of randomly selected prefixes. As shown in Figure 2b, all popular-service prefixes have at least two TLS-authenticated witnesses, and more than half contain 35 or more. By contrast, only 40% of random prefixes feature any valid witnesses. This gap suggests that service popularity correlates with co-residency on richly instrumented infrastructure—an encouraging trend for protecting high-value targets. Our CT log scans yield further insights about the distribution of witnesses across witness-hosting prefixes and ASes: 30% of /24 witness prefixes are home to at least 3 certificate-hosting IPs at any given time, and 58% of witness prefixes host more than a single certificate, as shown in Figure 3. On the AS level, 50% of witness ASes host at least 3 witnesses, with 49% of them hosting at least 5 different certificates. However, trends on both prefix and AS levels do not generalize across regions. As can be seen in Figure 3, witness-hosting prefixes and ASes in Europe tend to host more certificates compared to witness prefixes and ASes in Africa and South America. For example, while 50% of European witness ASes host 8 or more certificates, only 10% of witness ASes in Africa do so. Overall coverage: Our study of CT log certificates indicates a limited spread of witnesses across the internet. In particular, witnesses from our CT log scan span just 17.4% of the routable IPv4 space. This can be attributed to internet service centralization, and the limitations of the CT log measurement method. Services on the internet that serve TLS certificates tend to be hosted in large hosting and infrastructure providers, rather than be distrubuted across the broader network, which concentrates witnesses in a smaller subset of the IP prefix space. Furthermore, our methodology is limited by its source of data: while we process certificates from two of the largest CT logs, not all issued certificates are included in them. Furthermore, certificates are resolved to their prefixes via DNS resolution which can bias results through mechanisms such as GeoDNS, Global Server Load Balancing (GSLB), and the EDNS Client Subnet (ECS) extension. Regardless, our CT log study provides an informed lower bound on internet-wide witness coverage. While counterintuitive, our CT log observations allow us to confirm the efficacy of our approach. In particular, we find that HOWLR can detect 83% of real world prefix hijacks that took place in
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
1 0.8 0.6 0.4 0.2 0
Baseline T1 T2 T3 T4
102 103 104 Witness Discovery Time (Seconds)
Witnesses
Fraction of Prefixes
8
150
Baseline
T1
T2
T3
T4
100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
IP Prefix
(5a) Witness discovery time for variants: T1-stop host (5b) HOWLR variants miss a minimal number of witscan on certificate found, T2-also port 443 first, T3- nesses compared to the baseline. also skip port 80 if no cert. on 443, T4-only scan 443.
May 2026. We derive this by obtaining a dataset of the 1902 prefixes observed in high-confidence BGP hijack incidents through Cloudflare Radar [10]. Authentication granularity: We also use our fine-grain scans to examine whether individual hosts offer multiple certificates, which could increase redundancy within a prefix. As Figure 4b shows, 82% of certificate-bearing hosts serve only a single certificate — implying that host diversity, not intra-host redundancy, is key. Finally, we wish to understand what services are better suited to act as witnesses. We find that 82% of valid certificates are served on port 443 (Fig. 4c), typically used for HTTPS traffic. Taken together, these results suggest that the requirements of prefix-locality and authenticatability are broadly satisfied in the wild—especially for service-rich prefixes. Operational independence via CA diversity: CA hosting provides an added layer of protection: attackers must deceive or compromise multiple CAs to convincingly impersonate an entire witness set. To quantify the existence of independent witnesses, we analyze the diversity of CAs observed within each prefix. Our fine-grain scans show that 57% of prefixes in our sample contain certificates issued by at least two distinct CAs (Figure 4a). At the same time, our CT log scans indicate that just 4% of witness prefixes host certificates from two or more CAs. These results indicate that CA diversity is mostly observed in environments that host popular services.
5
HOWLR Design
Having shown that real-world prefixes offer sufficient witness coverage, we turn to validating whether HOWLR can operate efficiently in practice. We implement a lightweight client-side daemon that performs witness discovery and periodic validation using public scan data. Minimizing overhead: To reduce scanning cost, HOWLR integrates with public host indexing platforms (e.g., Censys [11] or CT logs [40, 26]) to pre-filter for responsive hosts and open ports to perform TLS handshakes, minimizing unnecessary probing. Improving efficiency: To improve witness discovery efficiency, we incorporate two practical tweaks into our implementation, each informed directly by our earlier measurement findings (§4). First, we adopt an early-stopping strategy: once a host yields a valid certificate, HOWLR halts further port probing for that host. This is motivated by our observation that 82% of hosts with certificates serve only one (Figure 4b), meaning additional probes are unlikely to uncover further useful authentication signals. Second, we prioritize port 443 during scanning, as it accounts for the vast majority (82%) of discovered certificates (Figure 4c). Lower-yield ports—such as port 80—are deprioritized or skipped entirely when unlikely to contribute. To quantify the impact of these tweaks, we evaluate four variants: T1 stops probing after the first valid certificate per host; T2
HOWLR : A Client-Driven Approach to BGP Hijack Detection
9
builds on T1 by prioritizing port 443; T3 further skips port 80 if port 443 does not yield a certificate; and T4 restricts scanning solely to port 443. Performance: As shown in Figure 5a, these tweaks significantly reduce runtime. On a single thread, T1 reduces worst-case scan time from 260 to under 39 minutes, while T4 brings it down to just 4 minutes. In terms of accuracy, the tweaks result in minimal witness loss (Figure 5b). Across all prefixes, < 2 witnesses were missed in 83.6% of cases. The worst-case drop—13 witnesses in a high-density prefix—still left HOWLR with 15 usable witnesses. These results show that HOWLR can operate in real-time in practice, and even coarse-grained probing (T4) is sufficient for building a meaningful witness set in most prefixes. 6
Evaluation
Level of Protection Methodology: In this section, we evaluate HOWLR’s ability to provide protection to prefixes of four privacy-sensitive applications. We define two levels of protection that HOWLR offers: Light and Strong. HOWLR offers Light protection if it can find at least 3 witnesses in the given prefix. To offer Strong protection, HOWLR needs to find a set of at least 8 witnesses that serve certificates from 2 or more different CAs between them. Bitcoin nodes: Bitcoin node operators can employ HOWLR to improve the security of their connections. For example, an adversary capable of hijacking and impersonating the connections to a node can seek to eclipse it, enabling selfish mining and double spend attacks [18]. HOWLR can detect that the node’s connections are being impersonated and alert the node operators to seek new peers. We evaluate HOWLR’s ability to protect a node’s connections to its peers by sampling 200 random node IPs from a Bitcoin node tracker [3]. Our results, indicate that HOWLR can provide Light protection to 59% of nodes, and Strong protection to 49%. Bitcoin mining pool gateways: Mining pool gateways are the Bitcoin nodes used by pools to propagate their freshly mined blocks. With each block offering a mining reward of over 337,000 USD at the time of writing, there is great incentive for pools to ensure that their blocks are quickly disseminated to other influential nodes in the network using low latency connections. An adversary seeking to damage a pool gateway’s ability to broadcast blocks can hijack and impersonate its connections to other influential nodes. HOWLR can detect the impersonation attack and alert gateway operators to adjust their peers. We assess HOWLR’s ability to protect connections to 44 nodes we inferred to be mining pool gateways using timing analysis. HOWLR extends Strong protection to 68% of inferred gateway pool prefixes, and Light protection to 75% of inferred gateway prefixes. We believe HOWLR extends better protection to pool gateways compared to random Bitcoin nodes because the former are more likely to be hosted on professional infrastructure and share a prefix with other services that can act as witnesses, rather than run by individual residential users. DNS Servers: Despite efforts pushing for adoption, authentication in DNS is still widely not deployed [30]. An adversary can use BGP-enabled impersonation to redirect DNS clients to malicious servers. HOWLR can validate the destination prefix before each DNS request, to ensure that the response does not originate from an impersonating adversary. We evaluate HOWLR’s ability to protect DNS clients by looking for witnesses in the prefixes of 200 sampled DNS servers [45]. We find that HOWLR can provide Light protection to 40% of prefixes, and Strong protection to 12% of prefixes. Popular Websites: BGP-enabled impersonation attacks in which the adversary obtains a bogus certificate and serves a malicious copy of a website have been both studied in the literature [5], and observed in the wild [8]. HOWLR can alert users to such impersonation by observing witness
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
Prefix Index
100% 80% 60% 40% 20% 0% 20
40 Poll Sequence
60
Offline Witnesses
10
102 100
500 0 0
1
2 3 4 5 Day Number
6
(6b) Witnesses that go offline over time.
Latency (ms)
104
1,000 500 0
010 10 -2 0 20 -3 0 30 -4 0 40 -5 0 50 -6 0 60 -7 0 70 -8 0 80 -9 90 0 -1 00
Witnesses # (Log)
(6a) Heatmap illustrating per-prefix witness availability over time.
1,000
All
#1
#2
#5
#10 #25
Witness Rank Uptime (%) (6c) 96% of witnesses have 99+% uptime.
(6d) Mean poll latency distribution by witness latency rank within witness prefixes.
failures. We evaluate HOWLR on protecting the top 200 websites on the Tranco list [25]. HOWLR provides Light protection to 87% of prefixes, and Strong to 55%. Tor Relays: To further understand HOWLR’s ability to protect prefixes that host security and privacy sensitive applications that can be the target of routing attacks, we identify witnesses for a sample of 200 random relays. Our findings, illustrated in Figure 2a, show that HOWLR can offer Strong protection to 64% of relay prefixes, and Light to 89%.
Witness Reliability Methodology: We evaluate the reliability of HOWLR witnesses over time by finding and monitoring witnesses for the aforementioned applications over the course of 6 days. We identify 30217 witnesses spanning the 714 prefixes, which we poll in 15 minute intervals. Witnesses that fail 10 consecutive polls are discarded from the witness set. Witness Latency: HOWLR performs periodic witness polling in the background to maintain the witness set. However, there are applications (e.g web browsing) where a user might wish to also poll witnesses on demand. Figure 6d shows the latency distribution for all witnesses, and for witnesses according to their latency rank within their prefix. Given that witness polls can be parallelized, our results indicate including more witnesses in the witness set adds minimal overhead. Witness Uptime: HOWLR depends on witnesses maintaining a high uptime. Figure 6c illustrates the probability of a witness being online during poll time; 96% of our final witness set was online for 99+% of polls. Figure 6a shows the fraction of online witnesses for 40 sample prefixes over the span of 72 poll sequences. Witnesses . Finally, Figure 6b shows the number of witnesses from our witness set go offline over time. At the end of our 6 day monitoring period, just over 4% of our witness set had gone offline, indicating that HOWLR does not require frequent witness re-discovery.
HOWLR : A Client-Driven Approach to BGP Hijack Detection
7
11
Limitations
HOWLR ’s effectiveness depends on the presence of authenticatable, witnesses in the destination prefix. While our findings (§4, §6) show this is often the case, it is not universal. HOWLR also assumes a benign initial state when establishing the witness set. If initialized during an attack, adversarial witnesses may be incorporated. While an attacker could attempt to introduce malicious witnesses within the destination prefix, doing so requires control over infrastructure in that prefix, or the cloud provider that presides over that prefix allowing customers to hand-pick prefixes, which is not always feasible. Finally, HOWLR does not defend against routing adversaries capable of forwarding traffic (e.g., [6]), which can preserve consistency across witnesses. Such attacks are more complex in their requirements and may be mitigated using additional signals such as latency or observed path anomalies. 8
Future Directions
Online security through HOWLR-native browsers: When a browser visits a website and verifies its TLS certificate, it could trigger HOWLR to discover witnesses within the same IP prefix to detect potential BGP hijacks. However, browsers currently lack a notion of IP prefixes and would require mechanisms to infer or query them. Additionally, probing other services in the prefix may introduce privacy concerns, increase page load latency, or trigger firewall and rate-limiting defenses. Finally, the browser would need to maintain a distributed database of verifiable services per prefix. Research Question: What mechanisms can enable prefix-wide validation with minimal impact on latency and resource usage? HOWLR-Mesh: checking reachability from the Internet’s edge: Rather than relying on individual hosts to discover and verify witnesses, a set of distributed clients (trust anchors) could periodically verify reachability and authenticity among themselves. Collectively, they could build a public map of validated Internet connectivity, similar to PingMesh in datacenters. Such a system could leverage proof-of-stake protocols, where participants attest to verified reachability and are incentivized accordingly. This may also address the scarcity of stable witnesses by encouraging hosts without public services to participate by exposing verifiable identities. Research Question: How can we design a decentralized system that continuously validates Internet reachability and authenticity across distributed vantage points and exposes disruptions (e.g., BGP hijacks) in real time? Identifying witnesses beyond TLS certificates: While this work focuses on websites due to the ease of TLS verification, other observable traits can serve as fingerprints, including open ports, hardware characteristics, or latency profiles. This enables multi-modal verification strategies that may be client-specific and raise the bar for adversaries attempting to impersonate a prefix. Research Question: Can combining such signals make destinations harder to convincingly fake during a hijack? Acknowledgments We thank Censys [11] for granting us access to their TLS certificate history data, which was used to verify the effectiveness of HOWLR. References [1]
[2] [3]
Lawrence Abrams. 2024. Hacker hijacks orange spain ripe account to cause bgp havoc. https://www.bleepingcompu ter.com/news/security/hacker-hijacks-orange-spain-ripe-account-to-cause-bgp-havoc/. Accessed: 2025-06-03. (2024). Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. 2017. Hijacking bitcoin: routing attacks on cryptocurrencies. In 2017 IEEE symposium on security and privacy (SP). IEEE, 375–392. ayeowch. 2014. Bitnodes.io. Online; accessed July 7 2025. (2014). https://bitnodes.io.
12
[4]
[5] [6]
[7] [8]
[9]
[10] [11] [12] [13] [14] [15] [16]
[17]
[18] [19] [20]
[21] [22] [23] [24] [25]
[26] [27]
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
Henry Birge-Lee, Maria Apostolaki, and Jennifer Rexford. 2025. Global bgp attacks that evade route monitoring. In Passive and Active Measurement. Cecilia Testart, Roland van Rijswijk-Deij, and Burkhard Stiller, (Eds.) Springer Nature Switzerland, Cham, 335–357. isbn: 978-3-031-85960-1. Henry Birge-Lee, Yixin Sun, Anne Edmundson, Jennifer Rexford, and Prateek Mittal. 2018. Bamboozling certificate authorities with {bgp}. In 27th USENIX Security Symposium (USENIX Security 18), 833–849. Henry Birge-Lee, Liang Wang, Jennifer Rexford, and Prateek Mittal. 2019. Sico: surgical interception attacks by manipulating bgp communities. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 431–448. Nick Bouwhuis. 2023. Setting up a personal asn. nick.bouwhuis.net. https://nick.bouwhuis.net/posts/2023-02-12-setti ng-up-a-personal-asn/. Russel Brandom. 2018. Hackers emptied ethereum wallets by breaking the basic infrastructure of the internet. The Verge. accessed 16 August 2024. Retrieved Aug. 16, 2024 from https://www.theverge.com/2018/4/24/17275982/myeth erwallet-hack-bgp-dns-hijacking-stolen-ethereum. CertiK. 2023. Bgp hijacking: how hackers circumvent internet routing security to tear the digital fabric of trust. CertiK Blog. Online; accessed July 8 2025. https://www.certik.com/resources/blog/bgp-hijacking-how-hackers-circu mvent-internet-routing-security-to-tear-the. Inc. Cloudflare. 2026. Cloudflare radar. Cloudflare Radar. (2026). Retrieved June 4, 2026 from https://radar.cloudflare .com. Zakir Durumeric, David Adrian, Ariana Mirian, Michael Bailey, and J. Alex Halderman. 2015. A search engine backed by Internet-wide scanning. In 22nd ACM Conference on Computer and Communications Security. (Oct. 2015). Zakir Durumeric, Eric Wustrow, and J Alex Halderman. 2013. {Zmap}: fast internet-wide scanning and its security applications. In 22nd USENIX Security Symposium (USENIX Security 13), 605–620. Artyom Gavrichenkov. 2015. Breaking https with bgp hijacking. Black Hat. Briefings. Yossi Gilad, Omar Sagga, and Sharon Goldberg. 2017. Maxlength considered harmful to the rpki. In Proceedings of the 13th International Conference on emerging Networking EXperiments and Technologies, 101–107. Sharon Goldberg. 2014. Why is it taking so long to secure internet routing? Commun. ACM, 57, 10, (Sept. 2014), 56–63. doi:10.1145/2659899. Dan Goodin. 2022. How 3 hours of inaction from amazon cost cryptocurrency holders $235,000. Ars Technica. accessed 16 August 2024. Retrieved Aug. 16, 2024 from https://arstechnica.com/information-technology/2022/09/how-3-hour s-of-inaction-from-amazon-cost-cryptocurrency-holders-235000/. Andreas Haeberlen, Ioannis Avramopoulos, Jennifer Rexford, and Peter Druschel. 2009. Netreview: detecting when interdomain routing goes wrong. In 6th USENIX Symposium on Networked Systems Design and Implementation (NSDI 2009). USENIX, 437–452. Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg. 2015. Eclipse attacks on {bitcoin’s} {peer-to-peer} network. In 24th USENIX security symposium (USENIX security 15), 129–144. Bryton Herdes, Mingwei Zhang, and Tanner Ryan. 2024. Cloudflare 1.1.1.1 incident on june 27, 2024. https://blog.clo udflare.com/cloudflare-1111-incident-on-june-27-2024/. Accessed: 2025-06-03. (2024). Tomas Hlavacek, Haya Shulman, Niklas Vogel, and Michael Waidner. 2023. Keep your friends close, but your routeservers closer: insights into {rpki} validation in the internet. In 32nd USENIX Security Symposium (USENIX Security 23), 4841–4858. Josh Howarth. 2025. Most visited websites in the world (february 2025). Exploding Topics. Online; accessed July 6 2025. https://explodingtopics.com/blog/most-visited-websites. Xin Hu and Z Morley Mao. 2007. Accurate real-time identification of ip prefix hijacking. In 2007 IEEE Symposium on Security and Privacy (SP’07). IEEE, 3–17. Yiyi Huang, Nick Feamster, Anukool Lakhina, and Jim Xu. 2007. Diagnosing network disruptions with network-wide analysis. ACM SIGMETRICS Performance Evaluation Review, 35, 1, 61–72. Bagueros Isabela. 2020. Tor security advisory: exit relays running sslstrip in may and june 2020. The Tor Project Blog. Online; accessed July 8 2025. https://blog.torproject.org/bad-exit-relays-may-june-2020/?utm_source=chatgpt.com. Victor Le Pochat, Tom Van Goethem, Samaneh Tajalizadehkhoob, Maciej Korczyński, and Wouter Joosen. 2019. Tranco: a research-oriented top sites ranking hardened against manipulation. In Proceedings of the 26th Annual Network and Distributed System Security Symposium (NDSS 2019). (Feb. 2019). doi:10.14722/ndss.2019.23386. Let’s Encrypt. [n. d.] Certificate transparency (ct) logs. Online; accessed June 6 2026. (). https://letsencrypt.org/docs/c t-logs/. Jun Li, Dejing Dou, Zhen Wu, Shiwoong Kim, and Vikash Agarwal. 2005. An internet routing forensics framework for discovering rules of abnormal bgp events. SIGCOMM Comput. Commun. Rev., 35, 5, (Oct. 2005), 55–66. doi:10.1145 /1096536.1096542.
HOWLR : A Client-Driven Approach to BGP Hijack Detection
[28]
[29] [30]
[31]
[32] [33] [34]
[35]
[36] [37] [38] [39] [40] [41]
[42] [43] [44] [45] [46] [47]
[48] [49]
13
Pat Litke, Joe Stewart, and Dell SecureWorks Counter Threat Unit. 2014. Bgp hijacking for cryptocurrency profit. Dell SecureWorks. Online; Internet Archive 21 December 2014. https://web.archive.org/web/20141221001200/https: //www.secureworks.com/cyber-threat-intelligence/threats/bgp-hijacking-for-cryptocurrency-profit#expand. Jianning Mai, Lihua Yuan, and Chen-Nee Chuah. 2008. Detecting bgp anomalies with wavelet. In NOMS 2008-2008 IEEE Network Operations and Management Symposium. IEEE, 465–472. Q Misell, Florian Steurer, Johannes Zirngibl, Anja Feldmann, and Tobias Fiebig. 2025. Measuring the deployment of dnssec bootstrapping using authenticated signals. In Proceedings of the 2025 ACM Internet Measurement Conference, 1002–1009. Bahaa Al-Musawi, Philip Branch, and Grenville Armitage. 2015. Detecting bgp instability using recurrence quantification analysis (rqa). In 2015 IEEE 34th International Performance Computing and Communications Conference (IPCCC). IEEE, 1–8. NoVirusThanks Company Srl. [n. d.] Ipvoid: random ip generator. Online; accessed July 6 2025. (). https://www.ipvoi d.com/random-ip/. Venkata N. Padmanabhan and Daniel R. Simon. 2003. Secure traceroute to detect faulty or malicious routing. SIGCOMM Comput. Commun. Rev., 33, 1, (Jan. 2003), 77–82. doi:10.1145/774763.774775. Arntz Pieter. 2021. Was threat actor kax17 de-anonymizing the tor network? MalwareBytes Labs. Online; accessed July 8 2025. https://www.malwarebytes.com/blog/news/2021/12/was-threat-actor-kax17-de-anonymizing-the-tor-n etwork. B Aditya Prakash, Nicholas Valler, David Andersen, Michalis Faloutsos, and Christos Faloutsos. 2009. Bgp-lens: patterns and anomalies in internet routing updates. In Proceedings of the 15th ACM SIGKDD international conference on Knowledge discovery and data mining, 1315–1324. Dingledine Roger. 2015. Did the fbi pay a university to attack tor users? The Tor Project Blog. Online; accessed July 8 2025. https://blog.torproject.org/did-fbi-pay-university-attack-tor-users/. Tal Shapira and Yuval Shavitt. 2022. Ap2vec: an unsupervised approach for bgp hijacking detection. IEEE Transactions on Network and Service Management, 19, 3, 2255–2268. Xingang Shi, Yang Xiang, Zhiliang Wang, Xia Yin, and Jianping Wu. 2012. Detecting prefix hijackings in the internet with argus. In Proceedings of the 2012 Internet Measurement Conference, 15–28. Aftab Siddiqui. 2022. Klayswap – another bgp hijack targeting crypto wallets. MANRS. accessed 16 August 2024. Retrieved Aug. 16, 2024 from https://manrs.org/2022/02/klayswap-another-bgp-hijack-targeting-crypto-wallets/. Nick Sullivan. [n. d.] Introducing certificate transparency and nimbus. Online; accessed June 6 2026. (). https://blog.cl oudflare.com/introducing-certificate-transparency-and-nimbus/. Yixin Sun, Maria Apostolaki, Henry Birge-Lee, Laurent Vanbever, Jennifer Rexford, Mung Chiang, and Prateek Mittal. 2021. Securing internet applications from routing attacks. Commun. ACM, 64, 6, (May 2021), 86–96. doi:10.1145/3429 775. Yixin Sun, Anne Edmundson, Laurent Vanbever, Oscar Li, Jennifer Rexford, Mung Chiang, and Prateek Mittal. 2015. {Raptor}: routing attacks on privacy in tor. In 24th USENIX Security Symposium (USENIX Security 15), 271–286. Daryll Swer. 2022. How i set up my own autonomous system. APNIC Blog. Online; accessed June 5, 2025. https://blog .apnic.net/2022/07/01/how-i-set-up-my-own-autonomous-system/. The University of Oregon. [n. d.] Route Views Project. (). http://www.routeviews.org/routeviews/. Trickest. [n. d.] Resolvers: the most exhaustive list of reliable dns resolvers. Online; accessed June 6 2026. (). https://g ithub.com/trickest/resolvers. Laurent Vanbever, Oscar Li, Jennifer Rexford, and Prateek Mittal. 2014. Anonymity on quicksand: using bgp to compromise tor. In Proceedings of the 13th ACM Workshop on Hot Topics in Networks, 1–7. Jilong Wang and Changqing An. 2024. BGPWatch — A comprehensive platform for detecting and diagnosing hijacking incidents. APNIC Blog. accessed 15 May 2025. Retrieved May 15, 2025 from https://blog.apnic.net/2024/02/07/bgpwat ch-a-comprehensive-platform-for-detecting-and-diagnosing-hijacking-incidents/. Wikipedia. 2025. List of most-visited websites — Wikipedia, the free encyclopedia. http://en.wikipedia.org/w/index.p hp?title=List%20of%20most-visited%20websites&oldid=1298817684. Online; accessed July 6 2025]. (2025). Ying Zhang, Zheng Zhang, Zhuoqing Morley Mao, Charlie Hu, and Bruce MacDowell Maggs. 2007. On the impact of route monitor selection. In Proceedings of the 7th ACM SIGCOMM Conference on Internet Measurement (IMC ’07). Association for Computing Machinery, San Diego, California, USA, 215–220. isbn: 9781595939081. doi:10.1145/12983 06.1298336.
14
Constantine Doumanidis, Anya Kalogerakos, and Maria Apostolaki
Layer
Error Description
Count
%
TCP TLS TCP TCP TCP TLS TLS TLS TLS TLS TCP/TLS
TCP Dial Timeout Connection Reset (Read) Read Timeout Connection Refused No Route to Host Unexpected EOF TLS: Internal Error TLS: Handshake Failure TLS: Unrecognized Name Not a TLS Handshake Other
154991 38.26 138872 34.28 69077 17.05 15401 3.8 9545 2.36 6039 1.49 4691 1.16 2458 0.61 2377 0.59 1174 0.29 473 0.12
Table 1. Distribution of witness poll failure errors.
Ethics This work involves measurements of public-facing hosts on the internet, and proposes a system for detecting routing-based impersonation attacks. We consider the ethical implications of both our data collection and the potential deployment of HOWLR. Our analysis relied on commercially accessible datasets (e.g., Censys) and data collected from our own isolated scans. The data we use consists of service metadata (e.g., TLS certificates) and does not include user-generated content or personally identifiable information. HOWLR performs lightweight reachability and authentication checks to services within a prefix. These interactions resemble standard client behavior (e.g., TLS handshakes) and are designed to minimize overhead. To minimize the potential effects our measurements may have had to remote hosts, we implemented strict rate limiting. While HOWLR is designed to detect impersonation attacks, similar techniques could be used to map service deployments within prefixes or probe infrastructure characteristics. We do not release any tools that enable large-scale probing beyond what is already possible with existing scanning platforms, and we advocate for responsible use of such techniques. Our study does not identify or exploit specific vulnerable systems. Appendix Witness Poll Failures: More than 55% of witness polling failures are attributed to timeout errors possibly stemming either from the witness being unavailable, or intervention by middleboxes. We also frequently encountered instances where the connection to the witness was either interrupted during the TLS handshake (34%) or directly refused (3.8%). For a summary of the most frequent failures see Table 1.