VULONE Research | November 2026
Executive summary
VULONE identified a publicly reachable, Korean-language control panel designed to bring hostname selection, DNS configuration and HTTPS certificate issuance into one workflow.
The application, hosted at 27.102.137[.]144:3000, contains a specific clue: its example IP address, 118.193.68[.]242, appears in an indicator index associated with earlier Kimsuky phishing research.
The panel provides a possible view into the preparation of phishing infrastructure, before a website is placed in front of a target. Its controls describe how an operator could select a web address, point it at a server and request a certificate from a single interface.
The association with Kimsuky remains provisional. The address overlap is concrete, but it does not establish common ownership. We did not verify successful certificate issuance or identify a victim compromised through the panel.
The clue inside the form
On 9 November, a server at 27.102.137[.]144:3000 returned an application titled “ZeroSSL + Dynu automation console.”
An administrator login precedes the main interface. The form behind it asks for a hostname, a domain suffix and the destination IP address. Its purpose is immediately recognizable: prepare a name and certificate for a web service.
The IP field is where the investigation becomes more specific. Its placeholder is 118.193.68[.]242, an address listed in an index of previously reported Korean credential-harvesting infrastructure attributed to Kimsuky.
An example value can reveal the environment in which a tool was developed or used. It can also remain inside a copied template. Here, the address gives investigators a concrete connection to examine, beyond broad similarities such as interface language, hosting location or choice of DNS provider.
One interface for names, DNS and certificates
The main page is headed “SSL certificate issuance automation system.”
The user enters the first part of a hostname and chooses its suffix from a provider menu. A separate field, labelled “A Record,” accepts the IP address that the hostname should resolve to. The main button offers to begin certificate issuance and download. An activity log sits beneath the controls.
These are ordinary administration tasks. Their combination is what makes the application interesting: the interface is designed to bring several parts of infrastructure preparation into one place.
118.193.68[.]242.| Component | Intended function |
|---|---|
| Hostname field | Choose the first part of the web address |
| Provider menu | Select the domain suffix |
| A record field | Set the server address |
| Certificate action | Start the issuance and download workflow |
| Activity log | Display progress |
The provider menu contains two groups. Dynu offers ten suffixes, including .dynu.net, .dynu.org and .dynuddns.net. ChangeIP Premium adds .cdncp.net, .racui.com and .bepolut.com.
The original code analysis records references to /api/v1/build-ssl and /api/v1/download-cert, consistent with the functions described by the interface. It also identifies hard-coded values in a browser-side login check. We are withholding those values.
The distinction between interface and backend matters. Browser-side login logic does not establish whether the server independently checks authorization. Likewise, a certificate button and an API reference establish intended functionality, not a successful issuance. We did not verify that either certificate operation completed.
The connection to earlier Kimsuky research
The form’s example IP appears in the Lazarus.day entry for “850 Hostnames, 6 Servers, 1 Kill Chain: Mapping Kimsuky’s 2026 Korean Credential Harvesting Machine”.
This is an exact address overlap between the application and a previously reported infrastructure indicator. It supports investigating whether the panel belonged to the same operational environment.
It does not settle that question. The address could originate from a reused configuration, a copied tool or an earlier deployment. Lazarus.day is also a secondary index, so its listing should not be treated as independent corroboration of the original attribution.
Our assessment is therefore a possible association with reported Kimsuky infrastructure. The panel’s intended function is clearer than the identity of its operator.
Why the preparation workflow matters
Phishing investigations often begin with a link delivered to a target. By then, the hostname has been selected, DNS configured and the website prepared.
A setup panel exposes an earlier stage of that process.
Combining DNS and certificate tasks could reduce the effort needed to replace an address. A new hostname can point to an existing deployment, or a deployment can move to a different server. Those changes do not necessarily require rebuilding the application that visitors encounter.
This panel describes a workflow that could support such replacement. We have not established that it produced any particular phishing hostname or certificate.
Its investigative value lies in the details that can be compared against independent records: the embedded address, supported domain suffixes and intended certificate operations. Dated DNS observations and exact certificate matches could help determine whether those elements belong to one deployment process.
The provider names alone cannot answer that question. Dynu, ChangeIP and certificate services support legitimate customers. Their appearance in this interface does not make their wider infrastructure malicious.
Implications for defenders
The useful monitoring unit is a specific relationship: a hostname, its destination, its certificate and the time each was observed.
For this investigation, 27.102.137[.]144:3000 identifies the observed console, while 118.193.68[.]242 is the historical indicator embedded in its form. These addresses have different roles and should not be presented as interchangeable, confirmed command servers.
A valid certificate establishes neither a site’s legitimacy nor its operator’s identity. Conversely, use of a shared DNS provider is insufficient grounds to attribute or block every customer under that provider’s domains.
The finding adds a possible infrastructure-preparation tool to an existing research lead. It does not establish a new victim, a confirmed expansion of Kimsuky’s network or the scale of an operation.
Methodology
The investigation began on 9 November 2026 and used existing internet-scan records, certificate information, DNS observations, threat-intelligence sources and earlier reporting. Collection also included a direct page retrieval and HEAD requests. Subsequent examination of the live server included access to the interface after login.
No successful certificate issuance, certificate download or access to victim data was demonstrated. Wider historical and certificate-based relationships are excluded from the attribution assessment because their underlying records were not available for independent review.
Service observations describe the collection period and should not be interpreted as confirmation of continued availability.
Research and analysis by VULONE. Questions, corrections or additional evidence: vulone.com.
