North Korea’s Hangro Revisited
by Robin Dost
Sometime around July 2026 a new certificate hierarchy went live on the servers behind Hangro, North Koreas state VPN and mail product.
It sits on port 6006 on hosts in Pyongyang and in the Russian Far East.
It is built to a completely different standard from the 2024 hierarchy still running beside it and its server certificate enumerates every machine the operators consider part of the system.
Including one they probably did not mean to publish 🙂
Pulling that thread led to six network assignments in Chinese address space that all trace back to a single registry contact, a twenty-five year old mail service and a certificate chain in which not one signature verifies, including a self-signed root against itself.
Read this more as an update, not as a full discovery piece of mine.
Hangro has been documented since January 2025 and a good deal of what follows builds on somebody elses work.
Where I am confirming, extending or correcting.
Where things stood
Nick Roy has been documenting Hangro since January 2025, with a second part in July and an infrastructure update that November.
He also wrote about futurere.com.kp and one of these IP addresses back in 2019.
Hangro is a VPN client that also ships a mail client and a real-time chat system.
The window title reads HangroVPN - 안개, fog, with menu entries 항로전자우편 for mail and 항로실시간대화체계 for chat. 항로 is a navigational route, a sea lane or a flight path.
A course through the fog, for a product that connects people abroad back home.
Hangro client window, 안개 in the title bar. Credit Nick Roy / nkinternet.com.
A page on ps.ppokkugi.com carrying the Hangro icon describes it as: 조국으로부터 떨어져계시는 방문자들을 위한 봉사.
A service for visitors who are away from the fatherland.
RFA reported in September 2022 what it is for.
In August that year, North Korean trade representatives in Jilin, Liaoning and Heilongjiang were ordered to install it, distributed through the consulate in Shenyang at 350 US dollars a seat.
A source in Dandong described it as the only email channel between the authorities and the company.
The known endpoints were 175.45.176.21, .22 and .32 in North Korean address space and 188.43.136.115 and .116 in Russian address space, all serving the same CN=hangro.net.kp certificate from an internal CA called hrra2024.
The driver gives the lineage away
Roy identified Hangro as SoftEther-derived from sample analysis.
There is a second route to the same conclusion that needs no sample at all and it sits in public driver databases.
Two aggregator sites carry metadata for a network driver called HangroVPN Adapter – VPN:
Hardware ID NeoAdapter_VPN
Version 1.1.0.7105 24 January 2013
Version 4.2.8 9 September 2014, 0.81 MB
Seen on Microsoft Windows 7 Ultimate K, Dell Inspiron 570NeoAdapter_VPN is SoftEthers own hardware ID. It appears verbatim in the upstream repository, in the Neo6 driver INF.
Hangro took SoftEthers Neo adapter, renamed the device description from “VPN Client Adapter” to “HangroVPN Adapter” and left the hardware ID untouched.
Two details ride along.
The telemetry that produced this entry came from a machine running Windows 7 Ultimate K, the Korean market edition.
And the 4.2.8 release on 9 September 2014 lands two weeks before the distribution directories discussed further down were last modified.
The 2024 hierarchy
Reassembled from issuer references and key identifiers, the intended structure is four levels deep:
HBS2024 self-signed 2024-02-14 5y CA:TRUE
└─ isca2024 2024-02-19 5y CA:TRUE pathlen:1
└─ hrra2024 2024-05-20 5y CA:TRUE pathlen:0
├─ hrpostfix 360C 2024-05-27 01:44:33 5y
├─ hangro.net.kp 360F 2024-05-27 03:39:46 5y
└─ hrdovecot 3610 2024-05-27 03:39:54 5yThe leaf names describe the product. hrpostfix is SMTP, hrdovecot is IMAP and POP, hangro.net.kp is the VPN.
Adjacent serial numbers, three of them issued inside a two hour window and one shared extension template across all four: clientAuth, serverAuth and emailProtection, with no subject alternative names at all.
Mail and VPN provisioned together from the same authority, which is what the bundled product looks like from the outside.
The hangro.net.kp certificate, SHA-256 b8810eae6ead0ec3a606300c5e3fe9c7af23f836719596e9519f73b4e1e7ad01, is served byte for byte identically from the North Korean and the Russian hosts.
The same certificate and the same key, on both sides of the border.
Nothing here holds the key it claims
The most useful failure in this deployment is not in the certificates. It is in the handshake and it takes one command to see.
On ports 465 and 7443 the connection dies at tls_process_key_exchange: bad signature, with no cipher negotiated. That is the client checking the servers signature over the key exchange parameters against the public key in the certificate the server has just presented. No trust enters into it. The server signs, the client checks that signature with the key the server itself supplied and it does not match.
On port 6006, on the same machines, the same check passes. TLS 1.3, CERT verify succeeds, TLS_AES_256_GCM_SHA384 over x25519 with RSASSA-PSS, ALPN negotiates HTTP/1.1 and the server then closes with a certificate_required alert because no client certificate was offered.
So on the 2026 management layer the server demonstrably holds the private key matching the certificate it presents and on the 2024 VPN and mail layer it demonstrably does not.
It is a property of the handshake.
The same fault, one level up
Every signature in the 2024 hierarchy fails against the public key of its stated issuer.
All eight of them, including HBS2024 against itself.
Beyond that I checked each signature directly against the original tbsCertificate bytes, the declared SHA-384 hash and the issuers public key as supplied, with no trust store, no name matching and no expiry checks and I sliced the tbsCertificate out of the DER by hand to take the parser out of the loop.
It reproduces against the live hosts, so it is not an artifact of how a scan database stored the files.
The signatures themselves look entirely normal. r and s between 379 and 384 bits, correctly DER encoded, inside the curve order.
These are real ECDSA signatures that are simply not signatures over these bytes with these keys.
A brute force across all eight public keys, five hash algorithms and both r/s orderings found nothing, which means the keys that produced them are not in the collection at all.
One fault or two
My first explanation was that somebody swapped public keys into finished certificates without re-signing.
That one is dead.
On all nine certificates the stored subject key identifier matches the SHA-1 of the embedded public key and a naive swap would have left a stale identifier behind.
What fits both observations is simpler than it first looked for me.
If the private key actually in use at each level does not correspond to the public key printed in the certificate at that level, the two failures are one fault seen from two angles.
At the leaf it shows up as a key exchange the client cannot verify.
At the CA level it shows up as a chain in which no parent can verify its child.
So, one broken assumption, two symptoms and nothing else about the deployment has to be wrong for it to be true.
I want to be careful about how much that carries.
This explanation accounts for both observations, so I consider it the most likely.
But I cannot confirm it without access to the signing setup.
The Hangro client is not verifying the certificate signatures.
None of the certificates in this chain would pass that check.
The client trusts them because they were installed as trusted certificates, without cryptographically verifying the chain.
The 2026 layer and the inventory it published
Port 6006 presents something built to a different standard entirely:
CN = MANAGER SERVER, OU = Manager SERVER, O = KEVIN, ST = KEVIN, L = KEVIN, C = KV
issuer: CN = KEVIN ROOT CA, OU = ROOT, O = KEVIN, C = KV
RSA 4096, sha256WithRSAEncryption
valid 2026-07-26 to 2036-07-23RSA-4096 instead of EC P-384, SHA-256 instead of SHA-384, ten years instead of five and a separate root sharing nothing with the 2024 chain.
The DN fields carry placeholder text and C=KV is not an assigned ISO 3166-1 country code.
Port 6008 carries a second certificate from the same family and it is a far cruder object:
subject=C=DK, ST=kevin, L=kevin, O=kevin, OU=kevin, CN=kevin, emailAddress=kevin
issuer= C=KV, ST=kevin, L=kevin, O=kevin, OU=kevin, CN=kevin, emailAddress=kevin.com
notBefore=Jun 17 01:06:52 2026 GMT
notAfter= Jun 14 01:06:52 2036 GMT
SHA256 18:16:94:39:C5:45:15:4B:83:64:C3:D8:4E:6A:9D:A8:
3B:CE:50:47:43:E4:F9:F3:21:EC:CB:D8:1E:9F:C0:6BX.509 v1, with no extensions of any kind.
No SAN, no basic constraints, no key usage.
Every DN field is the literal string kevin, including an emailAddress that is not an email address.
Subject and issuer differ only in the country code and in whether that address has a .com on the end, so this is not self-signed either.
It was issued by some second kevin certificate that does not appear anywhere.
It also predates the management certificate by six weeks.
Something was stood up on 17 June and the properly constructed hierarchy with a real CA and an inventory in its SAN followed on 26 July.
And it sits only on the Russian side.
The same certificate answers on 6008 on both 188.43.136.115 and 188.43.136.116 and neither North Korean host exposes that port at all.
Everything else in this deployment is mirrored across the border.
This one thing is not.
The SAN is why it matters:
| Addresses | |
|---|---|
| North Korea | 175.45.176.21, 175.45.176.22, 175.45.176.32 |
| Russia | 188.43.136.115, 188.43.136.116 |
| Shared address space | 100.100.100.170 |
Five public addresses across two countries in one certificate. The sixth entry sits in 100.64.0.0/10, which is RFC 6598 carrier-grade NAT space and is not routable from the internet.
It should never have been in a public certificate and it is a look at how the deployment is addressed internally.
The same certificate, TLS fingerprint 5a2f81451d6c921a7ab845b1856f67d71c76196cc34ace5ef7c7e8e471c3214b, is served on 6006 from 175.45.176.21 in Pyongyang and from both Russian hosts.
One identical management surface on both sides of the border.
I could not find this hierarchy described anywhere in public reporting.
All three of Roys Hangro pieces predate the certificates validity start by eight months or more and nothing published since, up to and including his 6 September 2026 piece on the new Khasan road checkpoint, touches it.
That is not the same as nobody having seen it in a scan database, so i guess the accurate phrasing is “not previously described”.
What it does not establish is a proven central control plane.
I have not seen what runs behind the mutual TLS gate.
A shared certificate, matching SAN entries and identical service exposure across two jurisdictions make jointly administered infrastructure the obvious reading and that is as far as the evidence goes.
“KEVIN” matched nothing in any North Korean or Chinese software context I could find.
The Russian leg
188.43.136.0/24 is registered at RIPE as KPOST-NET2, TTK-DV in Khabarovsk, status ASSIGNED PA, object created 12 September 2017.
That lands three weeks before TransTeleCom’s North Korean transit went live, which looked like an excellent paragraph until I searched for siblings:
| Network | Netname | Created | Registry description |
|---|---|---|---|
188.43.88.0/24 | KPOST-NET | 2013-08-12 | TTK-DV, Khabarovsk |
188.43.136.0/24 | KPOST-NET2 | 2017-09-12 | TTK-DV, Khabarovsk |
80.237.84.0/24 | KPOST-NET | 2024-09-07 | TTK-DV, Hasan |
62.33.81.0/24 | KPOST-NET | 2025-04-23 | Skyfreight_Limited, Vladivostok |
A KPOST network existed in 2013, four years before the transit link, so the timing coincidence dissolves.
The family is more interesting than the coincidence was.
Hasan is the crossing into Tumangang, the physical end of the Russian route into North Korea; 80.237.87.0/24, SKYFREIGHT-NET, sits there too and the KPOST netname appearing on a block described as Skyfreight in Vladivostok links the two sets.
Does KPOST mean Korea Post?
Nothing I found resolves it, maybe you know more (text me).
Netnames are chosen by the provider and prove (almost) nothing on their own.
The /24 has no org attribute, so the tenant is not disclosed.
The parent 188.43.0.0/16 belongs to Joint Stock Company TransTeleCom, so the provider is known and the customer is not.
The shared contact, AMIK1-RIPE, also appears on several entirely ordinary TTK-DV networks in the region, which is the counterweight.
A registry contact is a provider function, not evidence of involvement in what a customer runs.
And Khabarovsk is what the database says, not a measured location.
The Chinese leg: one contact, six networks
The Hangro clients default target, 218.25.43.212, sits in 218.25.43.208/28, sixteen addresses inside China Unicom AS4837, registered at APNIC as Changtongshuju, described as Liaoning Clear channel data Communication, Inc.
The company is real.
A 2012 Chinese utility model patent names 辽宁畅通数据通信有限公司 in Shenyangs Tiexi district – the Liaoning Equity Exchange Center lists it as CTD Communication, Inc., company ID 912101007157691129, founded July 2001.
A provincial technology bureau wrote up a site visit in 2020.
On the face of it, an ordinary regional ISP.
Roy noted in Part 1 that the registry record for this address reveals a contact email.
It is worth writing out what the record says:
person: Jo Myong Chol
nic-hdl: JM878-AP
e-mail: postmaster@silibank.com
address: No.17 Wenhua Road,Heping,Shenyang,China
phone: +86-24-23994010
fax-no: +86-24-23994012
country: CN
mnt-by: MAINT-CNCGROUP-LN
last-modified: 2008-09-04T07:54:15Z
source: APNIC
Does that record hold up
Two things are worth checking before leaning on it.
Was silibank.com actually Silibanks own domain when the object was written and does the phone number place this person at Silibank?
The domain, yes.
Silibanks own contact pages carry webmaster@silibank.com in the Japanese section captured on 5 December 2001, in the Korean signup guide captured on 5 January 2006 and again in 2013.
Twelve years of continuous use, with the 2008 registry object sitting in the middle of it.
Whatever became of the domain later, it belonged to Silibank when this record was created.
The phone, no.
| Source | Number |
|---|---|
| Silibank contact page, 2001 and 2013 | 0086-24-2322 8877 Ext.8504 |
| Silibank signup guide, 2006 | 0086-24-2325 2189 |
APNIC object JM878-AP, 2008 | +86-24-2399 4010 |
All three are Shenyang and all three are different exchanges.
Silibank used 2322 and 2325.
The registry contact used 2399, which is also the exchange that produced a false positive earlier in the pivot, on an unrelated Shenyang industrial group.
Jo Myong Chol is a technical contact using a verified Silibank address and by his phone number he was not sitting in Silibanks office.
A Korean personal name with a Silibank email on six Chinese network assignments is still what the record says.
How far that contact reaches
Asking where else a registry object appears is harder than it should be. e-mail: is not an inverse key in any RIR template.
Only abuse-mailbox: and the notify attributes are and those live in role objects instead of person objects.
RIPEs Solr full-text index returns numFound=0 for silibank, because it covers RIPE-sourced objects only and is blind to the GRS mirrors.
ARINs POC search returns nothing for the domain and rejects an @ in the email parameter.
APNIC offers neither.
What works is a two-stage pivot through the maintainer:
- Pull every resource under
MAINT-CNCGROUP-LNout of the APNIC bulk dumps: 976 resources, 1.169 distinct handles. - Resolve each handle against live whois, because APNIC removed the person object class from its public dumps and the email exists nowhere else.
- Filter, then join the hits back against
inetnum,routeandaut-num.
About twenty minutes, bottlenecked on APNICs rate limit for personal data.
JM878-AP is the administrative and technical contact on six networks:
| Range | CIDR | Addresses |
|---|---|---|
| 218.24.140.88 – 218.24.140.95 | 218.24.140.88/29 | 8 |
| 218.24.161.240 – 218.24.161.247 | 218.24.161.240/29 | 8 |
| 218.25.43.208 – 218.25.43.223 | 218.25.43.208/28 | 16 |
| 218.25.125.144 – 218.25.125.159 | 218.25.125.144/28 | 16 |
| 218.25.171.88 – 218.25.171.89 | 218.25.171.88/31 | 2 |
| 61.189.49.233 – 61.189.49.240 | not aligned | 8 |
Fifty-eight addresses.
The Hangro callback block is the third row.
The last range is not on a CIDR boundary, it runs .233 to .240 and crosses the /29 edge at .239, where a clean allocation would have been .232 to .239.
Somebody typed it by hand and nobody fixed it.
It also sits in a different /16 from the other five.
All six are maintained by China Unicom Liaoning and announced through AS4837 inside the 218.24.0.0/15 and 61.189.0.0/16 aggregates.
None carries a more specific announcement of its own.
Across all 1.169 handles under that maintainer, nothing else shares the email, the street address or the phone number.
Two candidates came up and both were discarded by me: A Shenyang industrial group matching only on the +86-24-2399 prefix, which is a telephone exchange and not a subscriber and seven role objects matching on “Wenhua Road”, which is about as distinctive as “Main Street” 😁.
The Silibank trail through Liaoning runs through exactly one contact object.
Worth saying precisely what this is.
It is Chinese address space assigned to a DPRK-linked entity in Shenyang.
It is not address space delegated to North Korea as a country.
That is 175.45.176.0/22 under AS131279.
The accurate phrase is DPRK-used assignments in Chinese address space.
Every object involved carries a last-modified date of 4 September 2008.
What was actually running there
Passive DNS across all six ranges produces six names:
| Address | PTR |
|---|---|
218.25.43.211 | mail.silibank.com |
218.25.125.150 | lnnk.com |
218.25.125.158 | dns.chinact.net, mail.chinact.net |
218.25.171.88 | mx2.sompo-japanchina.com, aeoncredit.com.cn |
218.24.140.94 | mall.dssodr.com |
61.189.49.234 | hero-huishan.com, hero-huishan.cn |
None of them forward-resolves to these addresses any more.
mail.silibank.com on .211 is two addresses from the Hangro callback on .212, with the clients TestIP at .209 in between.
Silibanks mail server and Hangros default endpoint were neighbours in the same /28.
lnnk.com turned out to be 辽宁诺康生물制药有限责任公司, Liaoning Nuokang Bio-Pharmaceutical, a real Shenyang pharmaceutical company that was NASDAQ-listed for a while.
Sompo is a Japanese insurance group, AEON Credit a Japanese financial services firm, both with Chinese subsidiaries.
I think this mix suggests something worth stating as a hypothesis:
Silibank may have operated in Shenyang as a provider and not only as a mail relay, with JM878-AP as the administrative contact for its customer assignments.
The customer profile fits.
Silibanks known user base was substantially Japanese, its 2001 website carried a dedicated Japanese section and two Japanese corporations appear in these blocks.
The allocations are also small and scattered, a /31 and two /29s, which looks like individual customers rather than one estate.
218.25.43.208/28, the Hangro block, is currently effectively dead. 218.25.125.144/28 is not:
| Address | Services |
|---|---|
.147 | 23/telnet, 161/snmp, 500/IKE, 2031/ssh, 8443/http, 8888/http – tagged VPN, login page, remote access |
.148 | 2031/ssh, 4042/ssh, 8089/http – OpenBSD OpenSSH, PHP, jQuery |
.149 | 80–85, 8081, 8100, 9817 |
.152 | 123/ntp |
.154 | 3306/mysql, 8089/http, 8090/http – Windows, MySQL, Apache, PHP |
.158 | 7196/http, 8732, 54679 – Windows, dns.chinact.net |
That is a structured environment.
A VPN appliance, two SSH hosts, a load balancer, a database server, DNS and NTP.
SSH on the non-standard port 2031 appears on two of them, which is a house convention rather than a coincidence.
.149 is the most informative.
Every one of its eight HTTP ports returns HAProxys stock 503 page with a SERVERID persistence cookie being cleared, meaning no backend is available.
Port 81 is the exception. Behind the same proxy sits a JBoss Web instance serving nothing but its default welcome page, Last-Modified: Tue, 10 Jan 2017 05:07:28 GMT.
A load balancer still health-checking a pool that looks like it died years ago, with one JBoss from January 2017 as the last thing answering.
That mtime is the firmest dating point we have for the Chinese side.
But to be clear here: .158 looks like CTDs own nameserver, so a working environment here is what a functioning regional ISP looks like.
It does not by itself indicate North Korean activity.
The North Korea connection still rests on the registry contact and on 218.25.43.208/28 and that block is the dead one, but our initial pivot point.
The domain in that contact address
postmaster@silibank.com sounds authoritative.
The Wayback Machine holds captures of silibank.com from 2 November 2001 to May 2026 and the shape of the record tells a story in four acts.
2001 to 2005. Just under six hundred captures. Silibank was founded at the 12th September of 2001, so the archive starts within weeks of the service going live.
A Japanese-language section at /silibank/japan/ from December 2001 with its own stylesheet and KIEC branding under /kiec/ in 2002.
2006 to 2014. Single-digit captures for the whole period.
The fog era.
A capture held by archive.today 18.12.2014 shows the site serving an open directory listing with exactly two entries, fog/ and moranbong/, both last modified 23 September 2014, from:
Apache/2.4.10 (Win32) OpenSSL/1.0.1i PHP/5.5.15
fog is 안개, the word in the clients own title bar and silibank.com/fog/update_files/ is where Roy later found the installers. Moranbong is a Pyongyang landmark and Popband and as far as I can tell nobody has looked at what was in that one.
Wayback tells a different story about the same paths, which is worth knowing before you go hunting.
It requested both on 16 March 2015 and got 404s, identical response bodies for each and it never archived a single installer. Across all URLs in its record of this domain there is no .exe, no .zip, no update_files.
But the original Hangro binaries are not sitting in a public archive waiting to be pulled.
That server banner quietly answers a question Roy left open. In Part 2 he noted the GOST identifiers in the Hangro client, gost94, GOST R 34.10-94 and GOST89 and wrote that they “suggest potential Russian influence”.
He put it no more strongly than that and in the same piece he traces the codebase to SoftEther out of the University of Tsukuba, so this was a flag rather than a claim.
The flag can come down.
Those are the algorithm names registered by engines/ccgost, the GOST engine that shipped inside OpenSSLs own source tree throughout the 1.0.x branch and was dropped in 1.1.0. A build against 1.0.x carries them whether or not anybody intended to speak Russian.
And OpenSSL 1.0.1i, released in August 2014, is what this operations own web server was running.
That dates the toolchain they were working with rather than the machine the client was compiled on, but it is the same operation and the same era and it is a far more ordinary explanation than a Russian cryptographic lineage.
2019 to 2022. The domain reappears running a Chinese animal feed business on DedeCMS, with product categories for sheep, cattle, pig and goose feed. Hundreds of captures. There is also a mirrored set of URL paths shifted one letter down the alphabet, so /product/yangsiliao/ also exists as /qspevdu/zbohtjmjbp/, which is a doorway-page trick and nothing to do with North Korea.
2023 onward. The current registration was created 19 November 2023 at Namecheap on registrar default nameservers. By July 2025 the archive is picking up a default Ubuntu Apache page.
So the APNIC record for the Chinese block the client ships pointed at lists a contact address in a domain that left North Korean hands somewhere in the second half of the 2010s, spent several years selling livestock feed and is now parked.
Two thoughts follow.
If you are building attribution on registry contacts, check whether the domain still belongs to whoever you think it does.
And anyone holding silibank.com today is positioned to receive mail addressed to the administrative contact of a Chinese network block.
The search that came back empty
The obvious next move was to take the certificates and look for them anywhere else. Both PKIs, by issuer, by subject, by fingerprint, by presented chain, across Censys and Shodan and Co, with the six known addresses excluded.
Nothing.
No host outside the addresses already in that SAN carries either certificate, within what those platforms see.
Two way on reading that.
Shodans coverage of the unusual ports in this deployment is thin enough that its silence carries little weight on its own.
And absence in a scan database is absence from a scan database.
In Censyss visibility this certificate family is confined to the North Korean and Russian hosts.
It does not appear on the Chinese side at all.
Whatever the Shenyang networks were for, they are not part of the certificate-bound deployment that runs between Pyongyang and Khabarovsk today.
The return leg
Almost every published investigation into DPRK operations maps the infrastructure up to the dead drop and stops there. Trellix’s embassy campaign is the clearest example and also the most honest about it. The malware pushes collected files into a tony/ directory in a private GitHub repository under the accounts blairity and landjhon, base64 encoded through the GitHub API and it takes its orders from text files such as onf.txt in the same repository that point at payloads hosted on Dropbox.
Both directions of the channel are documented and both of them terminate at a US provider.
The report states that it has no evidence of how the data moved from GitHub onward.
That is the gap and it is the whole question.
A stolen ministry document sitting in a private GitHub repository has not yet reached anybody who can act on it.
The same applies in reverse, a tasking has to originate somewhere inside the state apparatus before it appears in onf.txt.
I spent a while looking for the channel before concluding that the question is badly posed.
There is no single link. Treating “the return leg” as one pipe is what makes it look unfindable.
Sort it by what actually has to move and it separates into layers that are individually evidenced.
| Layer | What moves through it | What supports it |
|---|---|---|
| Commercial dead drop | Collection out of the victim, taskings in to the implant | GitHub, Dropbox and webmail C2, documented in detail |
| A person in China | Material from the dead drop toward the border | Operator activity 62% UTC+08:00, Chinese holiday alignment |
| Star-CO mail over the Shenyang leased line | Bulk into the country | SIZE 10000000000, ETRN enabled, 24-hour leased line announced 2004 |
| Hangro | Interactive access to the domestic side from a seat abroad | One certificate spanning both countries, distribution through the consulate |
| Courier over Dandong–Sinuiju | Anything too sensitive to put on a wire | Plausible, not instrumentable, stated here as an assumption |
Direct from 175.45.176.0/22 | Occasional and the loudest option available | Observed, rare |
The pickup happens in China
Trellix’s timezone analysis of the operator activity splits 62 percent to UTC+08:00 and 35.5 percent to UTC+09:00, Monday to Friday, roughly 8am to 6pm.
The gaps line up with Qingming and Labour Day Golden Week and not with Korean holidays.
Whoever empties the dead drop is working Chinese office hours on a Chinese calendar.
For most of this material, the “channel into North Korea” is a person in Shenyang or Dandong with a browser and the leg worth mapping begins after that.
Some operators never left
Mandiant assesses APT38, Andariel and TEMP.Hermit as likely operating in close proximity in Sinuiju.
Sinuiju sits on the Yalu directly opposite Dandong, at the point where the countrys fibre physically crosses. For that population the question of a return channel does not arise.
They are already inside and their problem is the outbound direction, which is the one everybody already watches.
The bulk leg is the mail system and it is measurable
I measured this part before I started on Hangro, in a piece about a North Korean mail server presenting a .cc domain and at the time I read it as an oddity rather than as part of anything. It reads differently now.
| Host | Address | Advertised SIZE | Ports |
|---|---|---|---|
smtp.star-co.net.kp | 175.45.178.56 | 10000000000 | 25, 587 |
smtp1.star-co.net.kp | 175.45.178.57 | 10000000000 | 25, 587 |
mail.silibank.net.kp | 175.45.177.33 | ~100 MB | 25 |
Ten billion bytes, a round decimal number, identical on both Star-CO relays. Postfix ships with message_size_limit = 10240000, ten megabytes. Gmail accepts 25 MB and Exchange Online caps at 150 MB. This is three orders of magnitude above anything a mail system needs and it is not a value that drifts into a configuration file by itself. Somebody typed it.
The contrast inside the same country is the part I had not weighted properly. Silibank, the older externally facing service, sits at roughly 100 MB on port 25 alone. Star-CO runs a hundred times that with submission open alongside it. Two mail systems, one state, two entirely different design intentions.
ETRN is enabled on these hosts and that is the detail that turns an anomaly into a description of the link.
ETRN exists so that a site which is not continuously reachable can ask the far end to flush its queue. Nobody enables it on a well-connected modern mail server. Together with a ten gigabyte message ceiling it describes a channel built to move large objects across a connection that is expected to be up most of the time and not all of it. SMTP here is doing the job of a file transfer protocol, which is a reasonable choice in an environment with no Dropbox, no object storage and a policed border, because a queue survives an outage and a download does not.
Silibanks own announcements describe the same arrangement being built twenty years earlier. In 2004 the service announced a relay “by leased line between PyongYang of DPRK to ShenYang of China”, with the Shenyang mail server connected to the Pyongyang mail server “during 24 hours”.
Hangro is the seat, not the pipe
Mail moves objects.
It does not give somebody abroad a session on the domestic network and that is the function Hangro fills.
One certificate covering addresses in Pyongyang and in Khabarovsk, an (possible) identical management surface on 6006 on both sides of the border and distribution through the consulate in Shenyang at 350 dollars a seat, ordered onto the machines of trade representatives.
That is a channel for a delegation, not for an operator.
Which also explains a negative result that puzzled me.
No public incident report places a Hangro client on a compromised machine.
The forensics that gets published covers IT workers and intrusion operators and they run Astrill, AnyDesk, RustDesk, Chrome Remote Desktop and VS Code tunnels, because their job requires them to look like they are in Austin.
A tunnel home is the one artifact that would unmask them instantly. The people who do hold Hangro are diplomats, officials and trade representatives and their laptops do not get handed to a SOC.
What this closes and what it does not
It closes the shape of the question.
The return leg is not missing, it is distributed and each layer has a different mission, a different user population and a different level of observability.
The reason nobody has published it end to end is that no single vantage point sees more than one layer.
Incident response sees the dead drop.
Sanctions reporting sees the money.
Scanning sees the border infrastructure.
The MSMT report, written with state access, still gets criticised for offering snapshots of transactions instead of a mapping of the flows, which is a fair indication of how hard the join is.
What it does not close is attribution of traffic.
I have measured what the channels are built for and I have not observed a single document crossing one of them.
A ten gigabyte message limit is a statement about intended workload, unfortunatly it’s not evidence of a payload.
The courier row in that table is an assumption and I have labelled it as one.
So far, the only indication of a possible link between Star-COs mail infrastructure and Hangro is a similarity in their certificates. The smtp1 certificate uses X.509 v1, has no extensions and has the serial number 0x1000.
The same format and similarly round hexadecimal serial numbers appear in Hangros certificate hierarchy.
This is worth investigating, but it does not establish a connection.
What holds
- A certificate hierarchy of eight EC certificates in which not one signature verifies, including the root against itself, confirmed five ways offline and reproduced against the live services.
- Mail and VPN certificates issued from the same authority within a two hour window, on one extension template, which is what a bundled product looks like from the outside.
- A second, newer RSA hierarchy deployed in July 2026, gated behind mutual TLS and identical on hosts in two countries, whose certificate enumerates the deployment including one internal address that should never have left the network. Whether that hierarchy verifies is unknown, because its root has not surfaced.
- A demonstrable split in key possession between the two layers on the same machines.
The SoftEther lineage confirmed at driver level, through a hardware ID in a public driver database rather than through sample analysis. - Six network assignments in Chinese address space, 58 addresses, all tracing to one registry contact with a Silibank address, unchanged since 2008, one of which the client still ships configured to reach.
- A family of KPOST networks in the Russian Far East going back to 2013, including one whose registry description places it at the Hasan border crossing.
- And a negative: the certificates appear nowhere outside the hosts the operators listed themselves.
A service becomes a channel
Step back from the certificates for a moment and look at what the dates describe.
In 2001 Silibank was a business.
Its website had sections in Korean, Japanese and Chinese.
And the member area offered a signup guide, an application form, a password change page, an address registration page and a fee calculator.
Reporting from the period puts the tariff at ten euro-cents per kilobyte, a one-euro minimum per message and three months prepaid in advance.
You could read the price list before deciding whether to join.
This was one of two email gateways for an entire country and it was selling access to itself.
By September 2014 the same domain was serving a VPN client out of a directory called fog.
By November 2016 the Shenyang office could no longer be reached.
In August 2022 the successor product was ordered onto the machines of North Korean trade representatives in three Chinese provinces, handed out through a consulate at 350 dollars a seat.
In November 2023 the domain lapsed and somebody else registered it.
A fee calculator exists because you have customers.
A signup form exists because people can choose to join. Neither is necessary once the people you serve have been assigned to you instead.
That is the shape of the whole thing.
One function, moving mail between North Koreans abroad and the centre, carried across twenty-five years and three technology generations.
A store-and-forward relay exchanging batches every ten minutes over a leased line from a hotel room in Shenyang.
A downloadable client distributed from the same domain and a certificate-bound VPN and mail deployment running between Pyongyang and Khabarovsk, with a management layer added in July 2026.
What changed here is that it stopped being something you could buy and became something you are issued.
I have not found anyone who noticed the public half go dark.
Silibank was never a security story and by the time the fields attention turned to North Korean networks it had been reduced to a hostname that still resolved.
Downloads
All certificates can be downloaded here:
Credit
Hangro would not be a subject at all without Nick Roy.
He has been documenting North Korean infrastructure at nkinternet.com for years, three pieces on Hangro alone and that body of work is where this one starts.
What makes it so useful is that he publishes the full working record.
The scans, the registry objects, the addresses he resolved, the leads that closed.
That is what makes a subject continuable by somebody else (like me) and it is the only reason this article could extend the picture.
If you follow North Korean networks, read him.
Work with us
If you need infrastructure analysed or a set of hosts, certificates and registry objects watched over time, that is the kind of work we do at Malwarebox.
Same for anything else pointing in this direction.
The Work With Us page is the way in.
