BGP Hijacking Case Study: KLAYswap

On February 3, 2022, attackers stole $1.9 million in cryptocurrency from users of KLAYswap, a South Korean exchange.

Without ever breaching KLAYswap's servers, they managed to redirect legitimate traffic, routing users to a malicious server that injected bad code directly into their browsers.

This case study examines how BGP hijacking works and how to protect your infrastructure.

A browser requests script.js. The dashed path to the real server is unused; a red /24 route sends the request to the attacker's server, which returns script.js with a padlock and a valid certificate.

The Target: Third-Party Scripts

KLAYswap's web app loaded Kakao's JavaScript SDK using a single HTML tag:

<script src="https://developers.kakao.com/sdk/js/kakao.min.js"></script>

Every visitor's browser fetched this file directly from Kakao and executed it with full access to KLAYswap's page context.

BGP Hijacking: Spoofing Kakao's IP Addresses

Networks use the Border Gateway Protocol (BGP) to share routing information.

When choosing paths, routers always prioritize the most specific prefix (for instance, a /24 route overrides a broader /21 block).

At the time, Kakao's servers operated within 211.249.216.0/21 and 121.53.104.0/23, IP blocks owned by ISP Dreamline (AS9457) and assigned to Kakao.

On February 3, an attacker broadcast two unauthorized /24 subnets within Kakao's range.

The fraudulent route claimed AS9457 as its origin and entered the global internet via Zayo (AS6461).

A RIPE RIS collector (rrc00) recorded 1,735 BGP announcements for these two prefixes, all sharing the same tail end:

211.249.221.0/24   AS path: … 6461 9457
121.53.104.0/24    AS path: … 6461 9457

MANRS: "AS9457 has no direct relationship with AS6461 (Zayo), yet it is shown as a direct peer in the AS_Path of the above announcement."

A brief test announcement went live at 10:04 Korean Standard Time (KST) for under two minutes. The main attack began at 11:09, stabilized by 11:27:44, and persisted until the malicious routes were withdrawn between 12:59 and 13:08 KST.

Obtaining a Valid HTTPS Certificate

To serve malicious scripts securely over HTTPS without triggering browser warnings, the attacker needed a valid TLS certificate for developers.kakao.com. According to S2W's post-mortem, they obtained one using ZeroSSL's free 90-day tier.

Certificate Authorities (CAs) verify domain control by sending an automated challenge to the domain's web server. Because the attacker hijacked the web server's IP address, ZeroSSL's validation request was routed directly to the attacker's machine.

While the exact validation method was never disclosed, it was likely a plaintext HTTP file challenge since only web traffic was redirected.

S2W noted that the issued precertificate appeared in Certificate Transparency logs at 11:27:57 KST, just 13 seconds after the hijacked BGP route stabilized.

Domain Validation Doesn't Help

In March 2022, Princeton's Henry Birge-Lee noted that "Let's Encrypt is the only certificate authority using multiple vantage point validation."

Since then, CA/Browser Forum Ballot SC-067 made Multi-Perspective Issuance Corroboration (MPIC) mandatory.

As of September 15, 2025, CAs must reject certificate requests if remote validation checks from various vantage points fail to reach the required quorum.

However, MPIC would not have prevented this incident. As outlined in the Baseline Requirements, MPIC primarily protects against equally specific prefix hijacks.

Because the attacker announced a more-specific /24 prefix, the fake route propagated globally.

Every validation vantage point worldwide would have been diverted to the attacker's server.

Domain ownership checks from Europe, Asia and North America all follow the same /24 route to the attacker's server, and the certificate is issued. The real server, announced as a /21, is never reached.

A similar exploit targeted software vendor Softaculous in August 2026, even with MPIC fully enforced:

Virtualizor's incident statement: "The attacker's server was able to obtain a valid TLS certificate from a public certificate authority (Let's Encrypt) for our domains, because the certificate authority's automated domain-ownership validation was also routed through the hijack."

Targeted Payload and Execution

S2W discovered that the hijacked server served a modified Kakao SDK bundled with malicious KLAYswap code. According to KLAYswap's incident report, the altered script modified transaction requests to transfer user tokens directly to the attacker's contract or grant approval for token drainage.

To stay undetected, the server reportedly checked the HTTP Referer header and delivered the malicious payload only to visitors arriving from KLAYswap.

Other Kakao services, such as QR check-ins, Kakao Map, and Daum, suffered only outages or slowdowns during the attack.

The first fraudulent transfer occurred at 11:31:41 KST. Although the malicious BGP routes were withdrawn by 13:08 KST, thefts continued until 18:01 KST because users kept open browser tabs running the cached script. In total, KLAYswap recorded 407 malicious transactions across 325 wallets. S2W valued the stolen assets at $1,910,172.95 (approx. 2.28 billion KRW).

Defensive Measures: RPKI and SRI

1. Strict Route Origin Authorizations (ROAs). Resource Public Key Infrastructure (RPKI) allows network operators to publish Route Origin Authorizations (ROAs).

ROAs are cryptographic statements defining which Autonomous System (AS) is authorized to originate a given IP prefix and its maximum prefix length (maxLength).

Networks executing Route Origin Validation (ROV) automatically drop unauthorized routes.

On February 3, 2022, no ROA in APNIC records covered Kakao's prefixes.

A strict ROA would likely have stopped this attack. Even if an attacker forges the authorized origin AS, setting an explicit prefix length limit blocks more-specific subnets:

ROA (example):    211.249.216.0/21  maxLength 21  origin AS7625
2022 route:       211.249.221.0/24  origin AS9457  ->  Invalid (unauthorized origin)
Forged origin:    211.249.221.0/24  origin AS7625  ->  Invalid (exceeds maxLength)

Permissive ROAs that allow /24 subnets fail to prevent these attacks. Both the Celer Bridge hijack (August 2022) and the Softaculous hijack (August 2026) forged legitimate origin ASNs and remained RPKI-valid.

RFC 9319 explicitly advises operators to avoid overly permissive maxLength settings for this exact reason.

Decision tree for the announced route 211.249.221.0/24. With no ROA it is NotFound and spreads. With maxLength 24 it is Valid despite the faked origin and spreads. With maxLength 21 the /24 is too specific, so it is Invalid and dropped.

RPKI adoption in South Korea remains low. Analysis of October 4, 2026 data shows that only 2.52% of 22,039 routed Korean IPv4 prefixes were RPKI-valid.

Measured by address space instead, APNIC reported ~2% RPKI coverage across Korean IPv4 space in March 2026.

2. Subresource Integrity (SRI). SRI allows browsers to verify that fetched external assets match an expected cryptographic hash.

If an asset is tampered with, the browser blocks execution. SRI would have completely neutralized the attacker's modified script.

In 2022, using SRI with Kakao's SDK required extra effort. Kakao's docs advised fetching the latest script version directly, and monthly SDK updates meant an SRI hash on an unversioned URL would break repeatedly unless developers hosted a local copy.

However, since SDK 2.0.0 (released September 20, 2022), Kakao publishes versioned URLs alongside official integrity hashes:

<script src="https://t1.kakaocdn.net/kakao_js_sdk/${VERSION}/kakao.min.js"
  integrity="${INTEGRITY_VALUE}" crossorigin="anonymous"></script>

Security Checklist for Web Applications

Audit all third-party scripts: Inventory every external JavaScript asset loaded by your web applications.

Enforce Subresource Integrity (integrity attributes) or self-host pinned copies.
Monitor Certificate Transparency (CT) logs: Track public CT logs for unauthorized certificate issuances targeting your domains.

In this incident, the attacker's certificate appeared in CT logs before token transfers began.
Enforce CAA records: Publish Certificate Authority Authorization (CAA) records to specify which CAs are authorized to issue certificates for your domains.
Configure strict ROAs: If you manage IP prefixes, publish RPKI ROAs and restrict maxLength strictly to the prefix sizes you actually announce.

As of October 4, 2026, no ROA covers the prefixes hijacked in 2022 or the active /24 subnets currently hosting developers.kakao.com (211.183.215.0/24 and 203.133.190.0/24).

References

S2W TALON — Post-mortem of KLAYswap Incident through BGP Hijacking (11 February 2022, Korean)
KLAYswap — KLAYswap Incident Report (Feb 03, 2022) (February 2022)
MANRS — KLAYswap – another BGP hijack targeting crypto wallets (17 February 2022)
Princeton CITP — Attackers exploit fundamental flaw in the web's security to steal $2 million in cryptocurrency (9 March 2022)
CA/Browser Forum — Baseline Requirements, §3.2.2.9 and ballot SC-067 (retrieved 2026-10-05)
Virtualizor — Security incident statement (31 August 2026)
Doug Madory, APNIC Blog — Latest BGP hijack targets hosting software vendor (22 September 2026)
Doug Madory, APNIC Blog — What can be learned from BGP hijacks targeting cryptocurrency services (7 November 2022)
IETF — RFC 9319: The Use of maxLength in the RPKI (October 2022)
APNIC Blog — NIR updates at APRICOT 2026 (6 March 2026)
Kakao Developers — JavaScript SDK: Getting started (retrieved 2026-10-05, Korean)
RIPE NCC — RIS raw data, rrc00, 3 February 2022 and RPKI ROA archive