A Two-Tier Certificate Strategy Behind a Freshly Rotating C2 Cluster

A Two-Tier Certificate Strategy Behind a Freshly Rotating C2 Cluster

Four IP addresses and three domains now tracked under a single command-and-control cluster show something that rarely shows up this cleanly in raw infrastructure data: two entirely different levels of operational care, running side by side on the same campaign. On one tier, listener IPs are still wearing the certificates they shipped with — an OpenSSL install default, a Chinese vendor's untouched template — the kind of TLS hygiene nobody bothers to fix on infrastructure meant to be thrown away. On the other, domains carry wildcard certificates and dynamic-DNS routing built specifically to let the operator reshuffle hostnames without re-issuing anything. The newest asset in the set, r9zvm9uk.com, was registered a mere seven days before this data was collected. Together the four IPs and three domains read less like a finished kill chain and more like a cluster still being assembled in real time.

That distinction — sloppy versus deliberate — is the actual story here, because it tells a more precise story about how this infrastructure was built than any single indicator could. Two IPs betray an operator who didn't bother to touch the certificate defaults; a third bundles five randomly-styled hostnames under one purchased certificate; and the domain layer shows wildcard issuance and CDN/dynamic-DNS fronting layered on top of a throwaway registration. No file indicators accompany this cluster — there is no payload, no signer, no sandbox verdict to draw on — so everything below is read directly off the certificates, the WHOIS records, and the DNS resolution chains themselves.

Sloppy TLS Hygiene on Two Unrelated Hosting Providers

The clearest signature in this cluster is also the least sophisticated one. 107.149.158.93, sitting on PEG TECH INC's network (AS398823, ARIN-registered, Santa Clara, California), serves a certificate whose issuer and subject common name both read "Internet Widgits Pty Ltd" — the literal placeholder text OpenSSL ships in its self-signed certificate template, complete with a validity window (2020-02-23 to 2023-02-22) that had already lapsed years before this listener was observed serving it. Four of 89 antivirus engines flag the address, a modest ratio that likely reflects how little traffic this kind of throwaway node generates rather than how benign it is.

A second, unrelated IP shows the identical failure mode with a different flavor. 149.104.32.43, hosted through CNSERVERS LLC (AS40065), presents a certificate whose issuer and subject fields are both stamped "default," with organizational metadata pointing to Beijing and a decade-long validity window running from 2019-04-13 to 2029-04-10. Nobody customized this either. What makes the pairing meaningful is that PEG TECH INC and CNSERVERS LLC are unconnected hosting providers on unrelated networks — there is no shared registrar, no shared certificate serial, no shared A-record binding them. The only thing tying these two listeners together is a habit: neither operator replaced a certificate's default subject before putting the box into service.

That habit is itself an inference worth stating plainly rather than dressing up. A production web service that expects to earn trust from a browser replaces its default certificate immediately; a listener that expects to talk only to malware, briefly, before rotation doesn't bother. Two unrelated ASNs converging on the same shortcut is more consistent with reused commodity tooling or bulletproof-hosting habits shared across unrelated infrastructure resellers than with one disciplined operator building a bespoke stack — though, absent any shared serial or A-record to confirm a common supplier, that remains a reading of the pattern rather than a proven link. From inside a defended network, this is also the detail that would most likely surface first: an EDR or proxy log flagging outbound HTTPS to an IP whose certificate subject is a template string is a much cheaper detection than waiting for behavioral telemetry that, in this case, doesn't exist at all.

One Certificate, Five DGA-Style Domains Behind a Single Listener

A third IP in the cluster shows the opposite instinct — not carelessness, but bulk provisioning. 64.112.78.42, hosted on Hurricane Electric LLC's network (AS6939), fronts a Certum DV TLS G2 R39 CA certificate (issued by Asseco Data Systems S.A., valid 2025-12-06 through 2027-01-05) whose subject alternative names bundle five separate hostnames under one purchase: atukjhesk.com, abfrkjesk.com, nbfjhertyrxiang.com, npicjrgytwxiang.com, and www.atukjhesk.com. None of the four core domains register any VirusTotal detections on this listener, and the naming convention — consonant clusters with no dictionary structure — is consistent with algorithmically generated or randomly hand-typed hostnames rather than a brand or service name an operator intended a victim to recognize.

Buying one commercial certificate to cover five throwaway-looking hostnames is a specific choice with a specific payoff: it collapses five certificate-issuance events (and five opportunities for a certificate-transparency log to flag suspicious activity) into one, at the cost of tying all five domains together the moment anyone inspects that certificate's SAN list — which is precisely what happened here. This is the kind of tradeoff an operator makes when speed and cost matter more than resilience to takedown: cheaper to buy once, but a single certificate revocation or blocklist entry now kills five hostnames simultaneously rather than one.

Wildcard Certificates and a Seven-Day-Old Dynamic-DNS Pivot

Two of the three domains in this catalog took a different route still: rather than bundling several hostnames onto one certificate, each independently obtained a wildcard-SAN certificate that lets it mint new subdomains without touching a certificate authority again. 18link.vip, registered back on 2024-03-03 and now roughly 928 days old, resolves through Cloudflare nameservers and carries a Google Trust Services "WE1" certificate covering both 18link.vip and *.18link.vip, issued 2026-08-08 and valid through 2026-11-06. cdn.cdnkdjs.com, registered through NAMECHEAP INC on 2025-04-26 (roughly 504 days old), independently carries a Let's Encrypt "YR1" certificate covering *.cdnkdjs.com and cdnkdjs.com, issued 2026-07-15 and valid through 2026-10-13 — and its DNS resolution chains through two CNAME hops, dizhi91.cdnxxx.com and 013c723c.cdnxxx.com, before landing on its A-records.

These two domains share no certificate authority, no registrar, and no direct linkage in the record — the wildcard pattern is a convergence in method, not a shared asset, and should be read that way: two independent builds that happened to reach for the same low-friction tool for subdomain flexibility, roughly three weeks apart on the calendar. What the wildcard buys the operator is the ability to spin up host1.cdnkdjs.com today and host2.cdnkdjs.com next week without a new certificate-issuance event ever appearing in a transparency log tied to a new hostname — only the original wildcard grant shows up, once. The CNAME routing through cdnxxx.com adds a further layer: a defender resolving cdn.cdnkdjs.com sees a redirect chain rather than a flat A-record, which slows attribution of the domain to whatever infrastructure actually terminates the connection.

The freshest piece of this cluster breaks from both patterns above. r9zvm9uk.com was created on 2026-09-13 — seven days old at the point this data was collected — through Dominet (HK) Limited, with an Alibaba Cloud abuse contact and nameservers at ns1.dyna-ns.net and ns2.dyna-ns.net rather than Cloudflare or Namecheap. Its DNS record resolves via a CNAME to kegymmtv.jixingcdn.com before hitting an A-record at 104.160.179.228, and it already carries a small number of detections (2/89) despite its youth. No certificate metadata is attached to it at all — dynamic-DNS-fronted domains frequently skip a dedicated TLS certificate entirely, routing HTTPS termination through whatever CDN sits in front of them, which also means this domain leaves no certificate-transparency trail for a defender to hunt against.

Reading the three domains as a set produces the clearest cross-evidence judgment in this cluster: two domains aged in the hundreds of days, dressed with wildcard certificates and CDN-grade hosting, sit next to one domain that is a week old and routed through dynamic DNS. That is not one domain family aging naturally — it is a tiering pattern, where older, better-reputed domains provide cover traffic or fronting while a disposable, freshly-minted domain absorbs the operational risk. This reading is an inference built by combining domain age, registrar identity, and nameserver choice across three otherwise unconnected records, not a fact stated anywhere in a single dossier — but the spacing (928 days, 504 days, 7 days) is difficult to explain any other way.

From Link to Listener: What the Data Can and Cannot Confirm

Because this catalog carries no file indicators, the front end of the intrusion chain has to be inferred from domain shape alone, and that inference should be labeled as such rather than dressed up as observation. The short, vanity-style structure of 18link.vip and the brand-new registration of r9zvm9uk.com are consistent with link-based lures feeding a redirect chain [T1566.002], with a victim's click driving execution [T1204.001] — but nothing in this record captures an email, a landing page, or a delivered file, so this stage remains a plausible read of the infrastructure's shape rather than a confirmed step.

Where the evidence turns solid is the back end. All three certificate-bearing IPs — 107.149.158.93, 149.104.32.43, and 64.112.78.42 — serve HTTPS listeners using asymmetric TLS key exchange over standard web ports, matching command-and-control conducted over ordinary application-layer traffic [T1071.001] inside an encrypted channel [T1573.002]. That is a direct, evidenced conclusion: the certificates are real artifacts on real listeners, not a behavioral inference. What sits between initial access and that C2 tier — the fronting layer built from cdn.cdnkdjs.com's CNAME hops through cdnxxx.com and r9zvm9uk.com's dynamic-DNS resolution through dyna-ns.net and jixingcdn.com, alongside the wildcard certificates on both older domains — is best read as a defense-evasion layer consistent with non-standard routing and rapid infrastructure rotation [T1571], though again the record shows the routing itself, not an observed evasion event in traffic.

From inside a target environment, this chain would surface unevenly. A proxy inspecting outbound TLS handshakes would flag the two default-certificate listeners almost immediately — a certificate subject of "default" or "Internet Widgits Pty Ltd" is a gift to any inspection pipeline capable of parsing certificate metadata. The wildcard-fronted domains and the dynamic-DNS pivot would not surface the same way at all; they were built specifically to look like ordinary CDN traffic, and a defender relying on domain reputation alone would see an aged domain with a legitimate-looking wildcard cert and move on. That asymmetry — cheap detection on the careless half of the infrastructure, real difficulty on the deliberate half — is itself informative: it suggests the operator invested selectively, hardening the pieces meant to survive longer while treating the raw listener IPs as fully disposable.

Unattributed Infrastructure, Still Being Assembled

No actor or malware family is attached to this cluster in the available record, and stretching toward attribution on TLS-certificate hygiene alone would be speculation the evidence doesn't support — so this reads as unattributed infrastructure, full stop. What the data does support is a read on operational maturity. The certificate-hygiene split documented above, layered with the domain-age tiering and the presence of a genuinely orphaned outlier — 194.1.140.1, hosted through Intrahost Solutions Ltd (AS214124) on a Cyprus-registered RIPE allocation, carrying zero detections and no certificate data at all — points toward a cluster still in active construction rather than a completed, static kill chain. An IP with no TLS fingerprint and no detection history contributes nothing to the certificate-based patterns traced above; it may simply be infrastructure staged for a role that hadn't started at the point this snapshot was taken.

That reading is reinforced by the overall shape of the cluster: four IPs spread across four unconnected autonomous systems in the United States and the Netherlands, three domains spread across three different registrars (unregistered/NameSilo-style registration on 18link.vip, NAMECHEAP INC on cdn.cdnkdjs.com, Dominet (HK) Limited on r9zvm9uk.com), and not one shared certificate serial or shared A-record anywhere in the set. An operator running a mature, centralized build tends to leave exactly that kind of connective tissue — shared certs, shared hosting, shared registrars — because building once and reusing is cheaper than building fresh every time. Its absence here, combined with the seven-day-old domain sitting next to assets thirteen to twenty-six times older, is most consistent with an operator acquiring hosting and certificates piecemeal, from whatever provider and CA is cheapest and fastest at the moment of need, rather than running a single hardened supply chain.

What that pattern signals for defenders tracking C2 infrastructure more broadly is a familiar but sharpening trend: the barrier to running credible-looking TLS-fronted command-and-control has fallen far enough that operators no longer need internal consistency to stay functional. A cluster can mix an OpenSSL demo certificate with a wildcard grant from a major public CA and a dynamic-DNS pivot registered a week earlier, and each piece still does its job independently. The industry vertical tagged against this record — containers and packaging — offers little targeting signal on its own, and no region is specified in the underlying data, so exposure here reads as broad rather than narrowly aimed. The more durable takeaway is about the infrastructure itself: cheap, disposable, and assembled from parts, this cluster is a reminder that certificate hygiene — or the lack of it — remains one of the few places where an otherwise anonymous C2 build still leaves a legible trail.