Misconfigured TLS Certificate Exposes North Korea's Hangro VPN Network

North Korea's Hangro VPN platform — used to connect officials and trade representatives abroad with systems inside the country — has leaked an unusually detailed picture of its own infrastructure through a basic certificate mistake.

What happened

A newly observed TLS certificate tied to Hangro's management service (port 6006) listed five public IP addresses: three inside North Korea and two in Russia's Far East. It also included 100.100.100.170, an address from carrier-grade NAT space that was never meant to appear in a public-facing certificate. Publishing it effectively handed out a piece of Hangro's internal addressing plan.

The same management certificate showed up across all five hosts — 175.45.176.21, 175.45.176.22, 175.45.176.32 in North Korea, and 188.43.136.115 and 188.43.136.116 in Russia — pointing to a jointly administered deployment, though the underlying research stops short of claiming a single centralized control system.

Analysts also traced an older Hangro client configuration to a Chinese IP address, 218.25.43.212, registered under a technical contact using a Silibank email address, with several related Chinese network ranges tied to the same registry record. That points to a DPRK-linked presence inside Chinese address space — not Chinese ownership of North Korean infrastructure.

Why it matters

Separately, the newer service on port 6006 looks more carefully built than Hangro's older VPN and mail layer: it completes a full TLS 1.3 handshake and requires a client certificate. The older services, on ports 465 and 7443, fail signature checks entirely — every certificate in Hangro's 2024 chain, including the root, fails verification against itself. That points to private keys that don't match their public certificates.

Normally that kind of failure would get a service blocked by any competent TLS client. But Hangro's own client reportedly trusts certificates bundled with the installer rather than validating the signature chain properly — so the platform keeps functioning behind a setup that a standard browser, mail client, or security product would reject outright.

None of this confirms Hangro has been used in a specific intrusion campaign. What it does confirm is a familiar lesson: certificate reuse, weak key handling, and careless metadata are often enough to map infrastructure that operators tried hard to keep private — even when they're gating access with client certificates and non-standard ports.

What to do

• Alert on connections to the IP addresses and network ranges below, and flag any Hangro-related hostnames in DNS or proxy logs.
• Inspect TLS certificates on ports 6006 and 6008 for the fingerprints listed, and treat any match as worth investigating.
• Use certificate transparency logs, passive DNS, and handshake fingerprinting to catch new infrastructure if the operators relocate or expand.
• Avoid attributing activity to a single registry contact alone — treat it as one data point inside a wider, and partly shared, DPRK infrastructure ecosystem.

Key indicators

This kind of infrastructure exposure is exactly what a continuous attack-surface and certificate-transparency monitoring program is built to catch early — well before a client's own perimeter is the one making the mistake.