by Robin Dost
Today I stumbled over a rather accidental finding during a routine analysis of North Korean infrastructure that I would like to share with you.
Since North Korea does not exactly use the internet for legitimate purposes and is well known for a long history of attacks against (critical) infrastructure, I consider it reasonable to treat essentially all North Korean internet-facing infrastructure as a threat entity by default. Infrastructure changes often reveal far more about a threat actor than individual malware samples ever will and the same applies to nation states like North Korea. That is precisely why this infrastructure deserves continuous observation.
For clarity: no offensive actions were performed during this analysis. Everything shown here is based exclusively on publicly accessible data and very basic reconnaissance.
Even if the target happens to be North Korean infrastructure, operating within legal boundaries remains mandatory. Germany unfortunately does not always make this easy, but whatever.
Enough about that. Let’s get into the analysis.
Initial Discovery
Due to a historic DNS leak, we currently have a surprisingly large collection of publicly reachable websites hosted inside North Korea. I scanned these sites for email addresses because I was curious about the current state of their mail infrastructure. I had looked into this years ago but lost track of it over time. Back then, heavy geofencing was common and many services were blocked outright, so the obvious question was whether this still applies today (it does not)
For this quick assessment, I focused on two sites:
Both pages expose email addresses:
The addressesryongnamsan@star-co.net.kp andmab@silibank.net.kp
point to the domains star-co.net.kp and silibank.net.kp.
If these addresses are actively used, we should also find corresponding mail servers.
Indeed, this yields four SMTP hosts worth inspecting:
- smtp.star-co.net.kp
- smtp1.star-co.net.kp
- mail.star-co.net.kp
- mail.silibank.net.kp
I verified reachability on the typical mail ports (25, 465, 587).
smtp.star-co.net.kp
smtp1.star-co.net.kp
mail.star-co.net.kp (offline)
mail.silibank.net.kp
I verified reachability on the typical mail ports (25, 465, 587)
| Mailserver | IP-Address | Open Mail Ports | Running |
| smtp.star-co.net.kp | 175.45.178.56 | 25,587 | Postfix |
| smtp1.star-co.net.kp | 175.45.178.57 | 25,587 | Postfix |
| mail.star-co.net.kp | 175.45.178.55 | Postfix | |
| mail.silibank.net.kp | 175.45.177.33 | 25 | Postfix |
So far, nothing spectacular, until we look at the TLS certificate.
The Certificate That Shouldn’t Exist (At Least Not Like This
You can download the original certificate here:
Certificate:
Data:
Version: 1 (0x0)
Serial Number: 4096 (0x1000)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=KP, ST=Pyongyang, L=Junggu, O=DevelopTeam, CN=StarJV Certificate Authority, emailAddress=postmaster@star-co.net.kp
Validity
Not Before: Nov 23 08:48:45 2024 GMT
Not After : Nov 23 08:48:45 2027 GMT
Subject: C=KP, ST=Pyongyang, L=Junggu, O=StarJVC, OU=DevelopTeam, CN=mail.nisp.cc, emailAddress=postmaster@star-co.net.kp
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:82:f5:13:18:cd:33:41:c6:c4:36:b2:55:33:
5a:e3:e3:d7:3a:a5:34:78:2f:96:60:41:83:e5:7f:
13:cd:fc:97:a2:dd:86:92:3d:f6:ce:bd:fd:ac:73:
ad:79:5c:52:8d:c4:2f:be:39:c9:a8:17:b8:a0:f2:
85:42:03:5a:26:95:dc:ce:15:ec:80:fa:16:56:2e:
bc:cf:89:f6:5a:ad:d9:60:18:17:3b:a3:63:62:3f:
8b:96:33:ad:86:f5:af:3b:73:d2:17:eb:20:9d:84:
89:03:2a:97:e5:a6:c2:2a:75:ef:1d:04:2b:16:92:
ff:50:95:87:a3:d1:df:5f:e0:0e:5b:1a:86:5d:e7:
23:90:7a:b2:33:6d:d1:7e:49:2b:c0:bf:25:95:b7:
37:e0:83:0a:85:96:04:35:1b:e6:35:fd:b9:c1:08:
39:f8:92:7f:1b:c9:f6:84:d5:07:7d:64:65:a5:58:
76:09:f4:e0:4e:6c:bc:19:bb:a8:09:5c:90:db:5d:
1c:43:79:35:b1:8f:15:d2:df:b4:b0:89:d4:32:e3:
37:4f:ad:51:5c:49:94:6f:99:22:19:d0:c2:37:cf:
1c:76:8c:d0:45:7d:5c:79:74:f3:2a:49:d3:5c:f6:
d9:4f:d8:f5:fd:d7:4c:b5:0c:d6:17:72:22:44:0a:
30:65
Exponent: 65537 (0x10001)
Signature Algorithm: sha256WithRSAEncryption
Signature Value:
4e:d0:bd:4a:89:48:95:2a:58:51:2e:7e:52:53:87:8c:ed:a9:
ed:1a:ea:b8:0a:53:75:bb:d1:3b:7f:25:76:b6:f9:bb:38:fe:
d9:07:96:ff:2e:af:58:8e:8c:7e:a5:3d:8a:a1:bc:82:ab:8f:
39:b9:bf:37:03:1e:6e:40:8f:59:ac:29:e3:46:4a:2e:fb:b3:
59:29:fa:b3:e3:ba:e8:6e:3d:31:a7:ab:41:66:9b:42:8a:98:
65:94:53:bc:24:5c:3d:83:dc:cb:15:64:02:80:7c:2a:31:c1:
f3:18:70:d9:82:54:14:bf:b2:33:d4:d8:61:53:56:d8:06:f6:
e7:b8:15:03:b4:0c:a3:13:f6:fd:0d:08:a0:50:b8:b8:a4:a7:
1f:d1:a2:56:ba:6e:b8:c4:cf:18:c6:f0:11:f5:18:6b:df:d5:
91:e0:41:30:35:96:4c:34:1b:25:c1:01:69:f7:b2:d2:36:c9:
2d:10:a7:81:c2:bb:b4:b0:38:99:9b:81:7d:bd:30:9f:e6:d7:
f0:c1:0b:cb:b6:ef:fe:34:94:7a:cd:40:f7:56:87:87:fb:50:
39:d9:4a:1b:78:f9:81:ff:a0:54:b4:8f:90:21:c0:0c:50:73:
1b:78:59:31:06:fb:d9:d9:0d:43:f3:b9:b8:63:2e:a7:cc:86:
bf:cb:22:67:a8:7d:af:ee:68:41:ab:f3:53:7f:b0:fd:d5:bf:
6c:18:9e:db:b4:ab:23:39:78:93:69:7f:95:a3:9f:dd:3a:14:
f1:16:32:b6:83:58:e2:34:d2:e2:49:04:aa:21:62:20:e3:2a:
28:b0:9d:8d:6a:6f:0d:f6:9f:5c:c6:11:51:56:93:35:82:19:
bd:af:81:bc:ff:6e:30:57:37:fc:cb:fa:20:01:de:c4:66:2c:
f7:44:d5:9e:b8:9c:d9:f4:8e:99:68:4d:47:b6:d4:5b:05:8d:
9f:d6:6f:8c:6e:8d:8a:d8:ab:4b:63:8d:e3:5b:65:81:e5:3a:
79:82:f2:00:c4:54:57:e1:00:f2:1b:22:59:41:71:df:49:89:
76:c7:01:54:70:35:4b:25:fa:1e:95:a5:4e:82:e2:ef:c8:e3:
b2:c0:5c:7b:bb:28:6f:0c:db:48:5f:4b:70:96:5c:df:f4:7c:
e7:42:f1:82:f6:99:6e:db:de:c7:e7:ff:01:f8:1a:84:62:2e:
1d:e2:11:b1:ba:f0:b0:c2:a7:2f:36:27:4d:fb:ed:c9:4b:42:
c3:bd:cf:b3:65:99:67:68:38:1d:eb:fe:2a:c7:b9:62:80:a3:
f5:f2:b2:c1:0f:53:7c:06:ed:61:7e:b8:e6:fc:89:36:ea:c0:
5b:2f:6d:6d:88:48:30:9a
Several anomalies immediately stand out:
External Identity Domain (mail.nisp.cc)
- Observations
- TLS CN =
mail.nisp.cc - Domain is outside of
.kp - No MX records exist
- The domain appears to be used purely for identity, not routing
According to WHOIS (if we trust it), the domain was registered in 2025 via juming.com, a registrar I would generously describe as “economically efficient” rather than reputable.
Beyond that, there is essentially no public footprint for this domain.
Inference
There appears to be a deliberate separation between:
- Routing identity:
.kpdomains - Cryptographic identity:
.ccdomain
Imo, this is a deliberate architectural decision and not an accident
Private State PKI (StarJV Certificate Authority)
Observations
- Custom internal CA visible in the certificate
- Not publicly trusted
- Self-managed
- Extremely primitive X.509 v1 structure
Inference
- Active internal PKI operation
- Low compliance and security maturity
- No external trust anchor available or desired
X.509 Version 1 Certificate
Observations
- Certificate is Version 1 (no extensions, no SAN, no policy constraints)
Inference
- Outdated or minimal PKI toolchain
- No modern security modeling
- Functionality prioritized over governance
Primitive Serial Number (0x1000)
Observations
- Serial number equals exactly 4096
Inference
- Manual or simplistic CA automation
- No randomness
- Likely very small PKI scale
Multi-Identity on a Single Host
Observations
- PTR:
ryongnamsan.edu.kp - SMTP banner:
star-co.net.kp - TLS CN:
mail.nisp.cc
Inference
- Central gateway role
- Multi-tenant usage
- Organizational consolidation
No MX Records for nisp.cc
Observations
- Domain exists, but has no mail routing
Inference
- Domain serves exclusively as an identity anchor
- No end-user mail usage
- Reduced abuse exposure
Extremely Large Mail Size (~10 GB)
Observations
SMTP SIZE = 10,000,000,000 bytes
Honestly, I laughed out loud when I saw this.
This configuration seems consistently on both active Star-CO SMTP servers (smtp and smtp1.star-co.net.kp), which looks like this is intentional rather than a misconfiguration. In contrast, the Silibank mail server uses a much more reasonable limit of ~100 MB.
It is therefore reasonable to assume that these mail servers are being used to transfer very large files. In theory, this could even serve as a transport channel for bulk data movement, including data returning from North Korean remote workers abroad. This remains speculative, but the transport capacity itself is undeniable.
If you want to make yourself vulnerable to a denial-of-service attack, you should implement this feature yourself!
Inference
- Expectation of large payload transfers
- SMTP likely used as a general-purpose transport channel
- No restrictive transport policies
Legacy Features Enabled (VRFY, ETRN)
Observations
- User verification enabled
- Legacy store-and-forward mechanisms active
Inference
- Weak hardening discipline
- Legacy configuration not cleaned up
- Reliance on network isolation as primary security model
Unknown SMTP Extension (BBBBBBBB)
Observations
- Non-standard SMTP extension
Inference
- Bug, custom patch, or QA deficiency
- Poor implementation hygiene
Recent Activity (Domain 2025 / Certificate 2024)
Observations
- Domain registered recently
- Certificate relatively fresh
Inference
- Active modernization or reorganization
- Not a purely legacy environment
Temporal Correlation & Strategic Context
We do not perform this kind of analysis purely for entertainment value. The objective is to generate intelligence that may become operationally relevant over time. That means we also need to ask why these infrastructure changes occurred when they did.
Based on available timestamps:
- Certificate issuance: 23 Nov 2024
- Domain registration: 21 Aug 2025
November 2024: Certificate Issuance
This period coincides with a phase of increased North Korean geopolitical activity:
- Formalization of a comprehensive strategic partnership with Russia
- Ongoing missile testing and military signaling
- Escalating rhetoric toward South Korea, the US, and Japan
- Partial reopening of diplomatic channels post-pandemic
Interpretation
The certificate appears to have been issued ahead of this intensified phase. A plausible explanation is preparatory technical groundwork, stabilizing externally reachable infrastructure before increased international activity or visibility
August 2025: Domain Registration
In this period we saw:
- Continued military demonstrations
- Publicized return of North Korean personnel from Russia
- Increased diplomatic engagement with Russia and China
- Rising international visibility
There is no single triggering political event on this exact date. However, the broader trend shows increased outward-facing engagement.
Interpretation
Registering an externally usable domain such as nisp.cc may reflect a desire to make services more reliably reachable and interoperable internationally during a phase of expanding external activity.
Possible Infrastructure Bridging Function
Even without explicit political announcements, infrastructure often moves first.
It is entirely plausible that North Korea:
- began improving external visibility of selected services
- equipped gateways with internationally compatible identities
- prepared controlled external access paths for future operational needs
Such changes rarely happen accidentally in centralized environments.
Final Thoughts: Why This Matters
Threat intelligence too often focuses narrowly on malware families, campaigns, and short-lived indicators of compromise. When dealing with nation states, this Much of todays threat intelligence still revolves around malware samples, campaign names, and short-lived indicators. That perspective is fundamentally insufficient when dealing with nation states.
States themselves act as long-term threat actors. Their infrastructure evolves far more slowly than malware and when it does change, it usually means someone made a deliberate decision, signed off on a budget, and probably sat through far too many internal meetings.
Infrastructure artifacts quietly expose things most actors would rather not advertise:
- organizational maturity (or the lack thereof)
- centralization models
- operational priorities
- capacity planning assumptions
- risk tolerance
- and governance culture
A single TLS certificate, a misaligned identity domain, or an absurdly permissive transport policy can easily reveal more about an actors operational reality than dozens of shiny malware samples ever could. Sometimes the most valuable intelligence comes from reading what a system accidentally tells you about itself.
This small case demonstrates how even boring protocol metadata can function as durable intelligence signals when correlated properly. Observing infrastructure drift across threat actors or states allows us to detect strategic movement long before it becomes visible in campaigns, headlines, or incident reports.
And as a small bonus observation: while geopolitical ambition clearly scales, PKI maturity and configuration hygiene appear to lag slightly behind. Infrastructure may evolve governance apparently takes its time ^-^