The 3ve Ad Fraud BGP Hijack Operation (2018)

In November 2018, the FBI and an international coalition of tech companies dismantled what was then the largest and most sophisticated digital advertising fraud operation ever uncovered. The scheme was called 3ve (pronounced "Eve"), and it was remarkable not just for its scale — 12 billion fake ad impressions per day, over $36 million in stolen ad revenue — but for its technical ingenuity. One of its three sub-operations weaponized BGP hijacking, a technique previously associated with nation-state espionage and routing disruption, to power industrial-scale ad fraud. It was the first major documented case of BGP hijacking being used not to intercept traffic or cause outages, but to steal money from the digital advertising ecosystem.

The Scale of Digital Ad Fraud

To understand why 3ve existed, you need to understand the economics of programmatic advertising. When you visit a webpage with ads, a real-time auction takes place in milliseconds: advertisers bid for the right to show you their ad. The winning bidder pays a small amount — typically a fraction of a cent — and the publisher (the website) gets paid. This happens billions of times per day across the internet.

The fraud is straightforward in concept: generate fake "impressions" — make it look like real humans on real websites are seeing real ads — and collect the payments. The challenge is making the fraud look legitimate. Ad verification companies like White Ops (now HUMAN Security) analyze traffic patterns to detect bots. They check whether the browser is real, whether the user behavior looks human, whether the IP addresses come from residential connections or suspicious data centers.

3ve's innovation was attacking this problem from three angles simultaneously, each sub-operation using a different technique to evade detection. The most technically sophisticated of these — 3ve.3 — used BGP hijacking to solve one of ad fraud's hardest problems: making data center traffic look like it comes from real users across the internet.

The Three Sub-Operations

3ve was not a single botnet but three coordinated operations, each with distinct infrastructure and evasion techniques. Understanding all three reveals why the BGP hijacking component was so critical.

3ve.1: The Boaxxe Botnet (Residential Proxy)

The first sub-operation used the Boaxxe (also known as Miuref) botnet, which had infected over one million home computers. But rather than running the ad fraud directly on the infected machines, 3ve.1 used them as proxies. The actual ad fraud traffic was generated by servers in commercial data centers, then tunneled through the infected home computers' internet connections. To ad verification systems, the traffic appeared to originate from diverse residential IP addresses — exactly what legitimate web browsing looks like.

3ve.2: The Kovter Botnet (Hidden Browsers)

The second sub-operation deployed the Kovter malware on roughly 700,000 computers. Kovter was a fileless malware that stored itself entirely in the Windows registry, making it difficult to detect with traditional antivirus software. It ran a hidden browser instance on each infected machine, visiting fabricated websites and generating fake ad impressions. Because the browsing happened on real consumer PCs with real residential IP addresses, the traffic patterns closely mimicked legitimate human web activity.

3ve.3: BGP Hijacking and Fake Data Centers

The third and most technically sophisticated sub-operation is where BGP hijacking entered the picture. Instead of infecting real computers, 3ve.3 took a fundamentally different approach: the operators rented servers in commercial data centers and ran custom browsing software on them. But data center IP addresses are relatively easy for ad verification companies to identify and flag. The operators needed their traffic to appear to come from a large, diverse set of IP addresses that looked like legitimate networks.

Their solution was to hijack unused IP address space via BGP.

How the BGP Hijacking Worked

The 3ve.3 operators identified blocks of IP addresses that were allocated to organizations but not actively being announced in BGP — effectively dormant address space. They then found compliant or compromised autonomous systems willing to originate BGP announcements for these prefixes. Once the hijacked prefixes were routed to the internet, the operators configured their data center servers to use these stolen IP addresses as source addresses for their fraudulent ad traffic.

The scheme worked because of a fundamental property of BGP: it operates on trust. When an autonomous system announces a prefix, neighboring networks generally accept the announcement and propagate it further. There was no widespread mechanism in 2018 to verify that the announcing AS was actually authorized to originate those routes. RPKI existed in theory but had negligible deployment at the time.

The operators hijacked over 1,000 IP prefixes at various points during the scheme's operation. They were careful to target dormant address space — blocks where the legitimate holder was unlikely to notice the hijack because they were not actively using the addresses. The WHOIS registration for these addresses still showed the original legitimate organization, which made the addresses appear trustworthy to ad verification systems that checked IP reputation databases.

The Technical Anatomy of the BGP Abuse

The 3ve.3 BGP hijacking operation involved several layers of technical sophistication beyond simply announcing someone else's prefixes.

Selecting Target Prefixes

The operators needed IP blocks that were:

• Allocated but unannounced — registered to a real organization in RIR databases (ARIN, RIPE, etc.) but not currently visible in the global BGP routing table
• Diverse in registration — belonging to many different organizations across multiple regions, so the traffic would not cluster around a single entity
• Small enough to avoid attention — typically /24 blocks, the smallest size generally propagated in the global routing table

This reconnaissance could be performed by comparing RIR allocation data against live BGP feeds from route collectors — any prefix that appeared in allocation records but not in the routing table was a potential target.

Originating the Hijacked Routes

To inject the hijacked prefixes into the global routing table, the operators needed access to BGP-speaking infrastructure. According to the indictment and subsequent analysis, they used a combination of:

• Complicit hosting providers that operated their own AS numbers and were willing to announce arbitrary prefixes for paying customers without verifying authorization
• Compromised BGP sessions at data centers where security controls on route announcements were weak or nonexistent

Once a complicit or compromised AS originated a hijacked prefix, neighboring networks accepted and propagated the route through normal BGP path selection. Within minutes, the hijacked prefix was reachable across large portions of the internet, with traffic for those IP addresses routing to infrastructure controlled by the 3ve operators.

Rotating Prefixes to Avoid Detection

The operators did not hijack all 1,000+ prefixes simultaneously. Instead, they rotated through them — announcing a set of prefixes for a period, withdrawing them, and announcing different ones. This rotation served two purposes:

1. Evading BGP monitoring — sustained hijacking of a single prefix is more likely to be noticed by the legitimate holder or by BGP monitoring services. Short-lived hijacks are harder to catch.
2. Diversifying IP footprint — by cycling through many different prefixes, the fraudulent traffic appeared to come from a constantly changing set of networks, making pattern detection harder for ad verification systems.

Fabricating the Illusion of Legitimacy

Hijacking IP space was only the first step. The 3ve.3 operators built an elaborate facade to make their fraudulent traffic pass scrutiny.

Counterfeit Websites

The operators created thousands of fake websites that spoofed the domains of premium publishers. These counterfeit sites loaded real ad tags from major ad exchanges, so when the custom browsing software visited them, legitimate ad auctions were triggered and real ads were served. The advertisers paying for these impressions believed their ads were appearing on reputable websites being viewed by real users.

Anti-Detection Browser

The custom browsing software running in the fake data centers was designed to mimic human behavior. It simulated mouse movements, scrolling patterns, and page interaction timing. It presented realistic browser fingerprints — user agent strings, screen resolutions, installed plugins — that matched what ad verification systems expected from real users. Each instance used a different hijacked IP address as its source, so the traffic appeared geographically and topologically diverse.

WHOIS Camouflage

Because the hijacked IP addresses were still registered to their legitimate owners in WHOIS databases, any reverse lookup on the source IP of fraudulent traffic returned a real organization's information. An ad verification system checking whether 192.0.2.100 was a data center IP or a legitimate corporate network would find WHOIS records showing it belonged to, say, a university or a regional ISP — not a fraud operation. This layer of camouflage was only possible because BGP allowed the prefixes to be hijacked without altering the WHOIS registration.

Why BGP Made This Possible

The 3ve case exposed a fundamental weakness in the internet's routing architecture. Several properties of BGP made this fraud scheme viable:

• No origin authentication — In 2018, fewer than 5% of prefixes had RPKI Route Origin Authorizations (ROAs). Any AS could announce nearly any prefix without cryptographic challenge.
• Dormant space is invisible — If an IP block is not being announced, its legitimate holder has no BGP-level visibility into whether someone else starts announcing it. Without active monitoring, hijacks of unused space can persist indefinitely.
• No notification mechanism — BGP has no built-in way to alert a prefix holder that their address space is being announced by another AS. Detection depends entirely on external monitoring systems.
• Weak prefix filtering — Many networks in 2018 did not implement strict prefix filtering, accepting routes from customers and peers without verifying authorization. This allowed hijacked prefixes to propagate widely.

The AS path for a hijacked prefix would typically show the complicit AS as the origin, with the path propagating through its upstream providers. Any network operator examining the route would see a seemingly normal BGP announcement — a prefix originated by an AS with a legitimate-looking path. Without RPKI validation, there was no automated way to flag it as unauthorized.

The Takedown: Operation 3ve

The investigation that brought down 3ve was a coordinated effort involving the FBI, the Department of Homeland Security, Google, White Ops (now HUMAN Security), and over a dozen technology and advertising companies. It was one of the largest joint operations between law enforcement and the private sector targeting cybercrime.

Detection

White Ops researchers first identified anomalous patterns in ad traffic that did not match known botnets. The traffic was too sophisticated for simple bot detection — it passed many standard verification checks. The breakthrough came from correlating multiple data sources: BGP routing data showed prefixes being announced and withdrawn in suspicious patterns; ad impression logs showed traffic from IP ranges that should have been dormant; and network forensics revealed the same data center infrastructure behind seemingly unrelated traffic sources.

Coordinated Shutdown

On October 22, 2018, a coordinated global action took place. The FBI seized 31 domains and 89 servers used by the 3ve operators. Google removed fraudulent ad accounts. White Ops worked with ISPs and hosting providers to sinkhole the Boaxxe and Kovter botnets, redirecting infected machines' traffic to controlled servers. Upstream transit providers were notified about the hijacked BGP prefixes, and many withdrew the routes.

On November 27, 2018, the Department of Justice unsealed a 13-count indictment against eight individuals from Russia, Kazakhstan, and Ukraine. The charges included wire fraud, computer intrusion, aggravated identity theft, and money laundering. The indictment described the full technical architecture of all three sub-operations in unusual detail for a cybercrime case.

Impact and Aftermath

The key figures from the indictment:

• $36 million+ in fraudulent ad revenue collected
• 12 billion fake ad impressions generated per day at peak
• 1.7 million infected computers across the Boaxxe and Kovter botnets
• 1,000+ IP prefixes hijacked via BGP at various points
• 5,000+ counterfeit websites fabricated
• 8 individuals indicted

Lessons for BGP Security

3ve demonstrated that BGP hijacking was not just a threat to network availability or data interception — it could be monetized at massive scale. The case strengthened the argument for several BGP security measures that were already under discussion but had seen slow adoption.

RPKI Adoption Accelerated

RPKI deployment increased significantly after 2018. If the hijacked prefixes had valid ROAs signed by their legitimate holders, and if networks along the path performed Route Origin Validation (ROV), the hijacked announcements would have been flagged as RPKI-invalid and dropped. By 2025, over 50% of global prefixes have ROAs, and major networks including Cloudflare, Google, and most large transit providers enforce ROV — rejecting or deprioritizing RPKI-invalid routes.

BGP Monitoring Became Standard

The case highlighted the importance of monitoring your own prefix announcements. Services like RIPE RIS, BGPStream, and commercial BGP monitoring tools allow organizations to receive alerts when their IP space is announced by an unexpected AS. After 3ve, more organizations began actively monitoring their prefixes — including organizations with dormant IP space that had previously assumed it was "safe" because it was not being used.

Prefix Filtering Tightened

Transit providers and IXPs improved their prefix filtering practices. The Mutually Agreed Norms for Routing Security (MANRS) initiative, which promotes filtering, anti-spoofing, coordination, and global validation, gained significant membership growth in the years following 3ve. Networks that follow MANRS guidelines would refuse to propagate a BGP announcement that cannot be verified against IRR (Internet Routing Registry) records or RPKI data.

The Broader Significance

Before 3ve, BGP hijacking was primarily discussed in the context of nation-state surveillance (intercepting traffic), censorship (blocking access to services), or cryptocurrency theft (redirecting DNS or blockchain traffic). The 3ve case proved that BGP hijacking could be a tool for financial crime at industrial scale, opening a new category of threat that combined network infrastructure abuse with advertising technology fraud.

The case also exposed how siloed security analysis can miss cross-domain attacks. Ad fraud detection systems were looking at traffic patterns, browser fingerprints, and IP reputation — but not at BGP routing anomalies. BGP monitoring systems were looking for route hijacks that disrupted connectivity — but not for hijacks of dormant space used for fraud. It was only when researchers correlated data across both domains that the full picture emerged.

Today, the defenses are significantly stronger. RPKI deployment continues to grow. Major ad verification companies now incorporate BGP data into their fraud detection models. And the 3ve indictment itself served as a deterrent, demonstrating that BGP hijacking for profit could lead to federal criminal charges and international cooperation for enforcement.

But the fundamental architecture of BGP remains trust-based. As long as networks can announce prefixes without universal cryptographic verification, some form of hijacking will remain possible. 3ve showed what motivated criminals can build on top of that gap.

Investigate BGP Routes

You can use the looking glass to examine real BGP routing data — check which AS originates a prefix, verify RPKI validation status, and inspect AS paths. Understanding how legitimate routing looks is the first step in recognizing when something is wrong:

• Look up 8.8.8.8 — Google DNS: verify origin AS and RPKI status
• Look up 1.1.1.1 — Cloudflare DNS: see AS path and validation
• Explore AS15169 — Google's announced prefixes and neighbors
• Explore AS13335 — Cloudflare's routing and peering