
Emotet C2 Uses Auto-Rotating Certs and Zero-Detection Japan Node
An Emotet-attributed phishing campaign targeting Canadian telecoms hides its command-and-control infrastructure behind automated 89-day Let's Encrypt wildcard certificates and a fully undetected shared-hosting node on SAKURA Internet in Japan. The architecture combines WordPress-path URL blending with hosting distributed across AWS and Japanese infrastructure, keeping network-layer detection ratios near zero.
Automated Cert Rotation and a Zero-Detection Japanese Node: Inside Emotet's Canadian Telecom C2 Architecture
A 143-kilobyte Word document disguised as a Windows system file sits at the entry point of a campaign targeting Canadian telecommunications organisations — but the more operationally significant story lies in what happens after that document executes. The command-and-control infrastructure behind this Emotet-attributed operation combines automated 89-day Let's Encrypt wildcard certificate rotation across operator-controlled domains with a fully undetected hosting node on SAKURA Internet's shared infrastructure in Japan, producing a network-layer evasion posture that registers near-zero detections on its most active assets. CTX Team's analysis reveals a C2 architecture built for low-maintenance, long-duration operation: scripted ACME certificate renewal, WordPress core directory path mimicry for beacon blending, and hosting deliberately distributed across geographically and administratively distinct providers. The infrastructure fingerprint is more analytically distinctive than the lure document itself.
The Lure: A Word Document Wearing a System DLL's Name
The campaign's entry point is a phishing attachment [T1566.001] that CTX Team has identified as Inf_890-5.doc, a 143 KB Microsoft Word document first submitted to VirusTotal on 2019-05-23. The file's most immediately notable property is its reported filename, set to C:\Windows\System32\ntdll.dll — a deliberate attempt to make the document appear to be a trusted Windows system component rather than an Office attachment. The analyst-identified tradecraft signal here is straightforward: naming a malicious document after ntdll.dll, one of the most fundamental libraries in the Windows runtime, is designed to suppress manual inspection by anyone who glimpses the file's metadata or a directory listing.
The Office metadata embedded in the document reinforces the social-engineering layer. The document's internal properties record an author of "Kaela Beahan," a subject field of "protocol," and a comments field reading "help-desk New Mexico" — fabricated corporate context intended to make the attachment plausible in a workplace phishing scenario. The creation timestamp is Mon May 20 15:47:00 2019, and the document was last saved at the same moment, suggesting it was created and immediately weaponised rather than repurposed from a legitimate file.
Detection coverage for this file is meaningful but not universal: 39 of 76 engines flag it as malicious, with Microsoft, Kaspersky, and FireEye among those returning positive verdicts. The file is tagged "exploit" and "apt" in threat metadata. Notably, 23 engines return clean verdicts and 12 report the type as unsupported, meaning a significant fraction of the scanning ecosystem either cannot process the file or does not flag it. Engines including CrowdStrike Falcon, ESET-NOD32, Cylance, Malwarebytes, and McAfee are among those not flagging the sample at time of analysis.
Without a sandbox verdict, the precise execution mechanism — whether an embedded macro, an exploit targeting a specific Office vulnerability, or a combination — cannot be directly confirmed. The "exploit" tag and the broad AV consensus across engines such as Elastic, Invincea, and Cynet are consistent with embedded macro or exploit code triggering payload execution [T1204.002], but this inference should be treated as analytical rather than directly evidenced. What is directly evidenced is the masquerading technique [T1036]: the filename spoofing and the WordPress-path URL structure discussed below both reflect a consistent operator preference for blending malicious artefacts into expected system and web-server noise.
The file carries fuzzy hashes — vhash 1368d0356750d136448d50e5b2c9a890, ssdeep 3072:977HUUUUUUUUUUUUUUUUUUUTkOQePu5U8qJF6j4QM+OyDUBDTWcn9:977HUUUUUUUUUUUUUUUUUUUT52VMF68d — but no import hash is available, and the file carries no code-signing data. This means build-pipeline clustering against peer samples is unreliable. Two additional file hashes appear in the indicator catalog — fed0c75618acde43a7376ff7c5db4927f4be8ab3bcb73bfa86c86ae78aeab7c2 and e24ab9007c6e25ede1a545ac974ce8048235df4363c761e668a47f8af4c7cb59 — but carry no metadata. Any claims about their function or relationship to the Word document would be unsupported speculation.
The Certificate Architecture: 89-Day Wildcard Rotation as Operational Discipline
The infrastructure layer is where this campaign's operational maturity becomes visible. CTX Team has identified two distinct fingerprints binding the C2 domain set: a shared Let's Encrypt wildcard certificate rotation pattern across operator-controlled .com domains, and a structurally separate SAKURA Internet-hosted node presenting a shared-namespace certificate from a Japanese certificate authority.
The first fingerprint covers hashkorea.com and lucy-jade.com. Both domains independently obtained 89-day Let's Encrypt certificates with wildcard subject alternative names — *.hashkorea.com on a certificate issued by Let's Encrypt's E8 intermediate (serial 5bff37e04f95db8866eb4a6fa7909cfb3fd, valid 2026-05-04 to 2026-08-02) and *.lucy-jade.com on a certificate issued by Let's Encrypt's R3 intermediate (serial 4edca7cb751f61aae69c8bf2208fce27757, valid 2021-07-25 to 2021-10-23). The 89-day validity window is the maximum Let's Encrypt issues, and it is the standard output of scripted ACME-protocol renewal — the kind of certificate lifecycle management that runs as a cron job or systemd timer rather than requiring any manual operator action.
The operational significance of the wildcard SAN is worth dwelling on. A certificate covering *.hashkorea.com is valid for any subdomain the operator chooses to instantiate: wp.hashkorea.com, api.hashkorea.com, cdn.hashkorea.com, or the observed C2 path structure. The operator can stand up new beacon endpoints under a valid, trusted TLS certificate without touching the certificate itself — the cert rotates automatically every 89 days, and new subdomains are covered the moment DNS resolves. This is a build-once, rotate-automatically infrastructure model that minimises both manual overhead and the exposure window created by certificate revocation.
hashkorea.com was registered on 2019-11-21 via TurnCommerce, Inc. DBA NameBright.com, making it approximately 2,369 days old at time of analysis. Its nameservers are nsg1.namebrightdns.com and nsg2.namebrightdns.com, consistent with the NameBright registrar. The domain currently resolves to two AWS A-records: 13.223.25.84 and 54.243.117.197. The SPF record is set to v=spf1 -all, rejecting all mail — a configuration that has no legitimate email use and is consistent with a domain operated purely for infrastructure purposes. An AfterNic verification TXT record (afternic-verification-G9G3tM8T8EwEizzPzjGJWF) suggests the domain may have been acquired through a secondary market, which would be consistent with the operator purchasing an aged domain to inherit its registration history.
lucy-jade.com presents a temporal anomaly that warrants explicit hedging. The domain's WHOIS creation date is 2023-04-13, but the most recent TLS certificate on record — the R3-issued wildcard cert — has a valid_from date of 2021-07-25, nearly two years before the domain was registered. This is a temporal impossibility under normal circumstances: a certificate cannot predate the domain it covers. CTX Team assesses this as most likely a data-source artefact or certificate record reuse rather than evidence of pre-registration infrastructure staging, but the inconsistency cannot be resolved and should be treated with corresponding caution. What is not in doubt is the structural parallel: lucy-jade.com carries the same 89-day wildcard Let's Encrypt pattern as hashkorea.com, uses gname.net nameservers, resolves to 104.253.249.209, and has WHOIS administrative contact data pointing to Hong Kong. Its detection ratio is 2 of 91 engines — effectively invisible to network-layer scanning.
The cohort significance of this shared certificate pattern is that it points toward a single operator managing a C2 domain portfolio through scripted ACME renewal. The two different Let's Encrypt intermediates (E8 and R3) are consistent with the same ACME client obtaining certificates at different points in time — Let's Encrypt has rotated its intermediate CAs over the years, and a long-running automated renewal pipeline would naturally produce certificates from different intermediates depending on when each renewal cycle ran.
The SAKURA Node: Zero Detections and a Shared-Hosting Wildcard
The second infrastructure fingerprint is structurally distinct from the .com domain cluster and represents the campaign's most operationally clean asset. IP address 59.106.27.194 sits on ASN 9370, operated by SAKURA Internet Inc., within the network range 59.106.0.0/17 — a shared hosting and VPS range registered with APNIC and allocated to SAKURA's Osaka-based operations. The IP carries zero detections across 91 VirusTotal engines and has a community reputation score of zero, meaning it has not been flagged by any contributor to the platform's collective intelligence.
The TLS certificate presented by this IP is the key fingerprint. Rather than an operator-controlled wildcard cert like those on the .com domains, 59.106.27.194 presents a certificate covering *.sakura.ne.jp, issued by Gehirn RSA Domain Validation Secure Server CA 2 — a certificate authority operated by Gehirn Inc., a Japanese hosting and infrastructure company. The certificate's serial is 7a88f56a4009f66fd9a646fe1ce327f1, and it was last observed on 2026-06-02. The subject alternative names on this certificate extend well beyond *.sakura.ne.jp to cover a range of shared-namespace domains including *.180r.com, *.2-d.jp, *.dojin.com, and others — a multi-domain certificate covering SAKURA's shared hosting namespace.
This certificate structure confirms that the actor is not operating dedicated infrastructure at this node. A *.sakura.ne.jp certificate is issued to SAKURA's shared hosting customers as part of the platform's default TLS offering; it covers the shared namespace rather than any operator-controlled domain. The actor is renting a commodity shared-hosting or VPS account on SAKURA's platform and receiving the platform's default certificate as part of that service. This is consistent with Emotet's historically distributed, rented-server C2 model, where operators abuse low-cost hosting accounts across multiple providers rather than maintaining dedicated infrastructure that can be cleanly attributed and taken down.
No shared certificate serial or A-record binding links 59.106.27.194 and the .com domain cluster. Their co-appearance in the same indicator set is the primary connection, supplemented by the campaign-level context. The SAKURA node's structural distinction from the domain cluster — different hosting provider, different certificate authority, different geographic jurisdiction, different detection profile — is consistent with a deliberate tiering strategy: the operator-controlled .com domains with their automated Let's Encrypt certs handle one layer of C2 communication, while the SAKURA node provides a separate, currently undetected channel that does not share infrastructure fingerprints with the primary cluster.
Beacon Paths and the WordPress Mimicry Layer
The application-layer tradecraft reinforces the network-layer evasion posture. The primary observed C2 endpoint is hashkorea.com/wp-includes/sp0d763, where the path structure is the operative detail. The /wp-includes/ directory is a core WordPress installation path — it contains WordPress's core PHP libraries and is present on every standard WordPress installation. URL-based detection rules and web proxies that pattern-match against known malicious paths are less likely to flag traffic to /wp-includes/ than to an obviously anomalous path, because the directory name is indistinguishable from legitimate WordPress traffic at the path level.
The specific endpoint identifier sp0d763 does not correspond to any known WordPress core file, but the path prefix provides the camouflage. An analyst or automated system scanning HTTP/HTTPS traffic logs and seeing requests to hashkorea.com/wp-includes/sp0d763 would need to know that hashkorea.com is not a legitimate WordPress installation — knowledge that requires prior intelligence about the domain rather than pattern-matching on the URL alone. This is the analyst-identified tradecraft signal: WordPress-path URL structure used for C2 endpoint blending [T1036].
A second C2 URL, phigvelers.com/Library/7tak1867, appears in the indicator catalog. The /Library/ path mimics a directory structure common in macOS and various web application frameworks. phigvelers.com cannot be further characterised beyond its structural presence in the indicator set. Its path structure follows the same application-layer mimicry logic as the hashkorea.com endpoint.
The combination of WordPress-path blending with valid wildcard TLS certificates on all C2 nodes produces a layered evasion architecture [T1553.004]. A TLS-inspecting proxy that treats certificate validity as a trust signal will see valid Let's Encrypt certificates on the .com domains and a valid Gehirn-issued certificate on the SAKURA IP. None of these certificates are self-signed, none are expired, and none carry obvious anomalies at the certificate level. The evasion is structural rather than exploitative: the operator has built infrastructure that looks legitimate to automated inspection systems because it uses the same certificate authorities and hosting providers that legitimate services use.
The defense-evasion posture is most visible in the detection distribution across the infrastructure set. hashkorea.com registers 9 of 91 engine detections — low but not invisible. lucy-jade.com registers 2 of 91. The SAKURA IP registers 0 of 91. The pattern is consistent with a tiering strategy where the most recently stood-up or least-used nodes have the lowest detection ratios, and the operator's automated cert rotation ensures that even flagged domains can be cycled out and replaced with fresh infrastructure under the same wildcard certificate without disrupting the underlying C2 capability.
Emotet Attribution and the Espionage Motivation Tension
The Emotet Group — tracked across the industry under aliases including TA542, Mummy Spider, Gold Crestwood, Mealybug, and ATK104 — is the attributed actor in this dataset, with the campaign tagged as targeting the telecommunications sector in Canada. The attribution is grounded in the indicator set's threat metadata and the document lure's consistency with Emotet's well-documented phishing-document initial-access methodology.
The dataset's motivation tag of "espionage" sits in tension with Emotet's established profile as a financially motivated cybercriminal platform. Emotet has historically operated as a malware-as-a-service loader, delivering banking trojans and ransomware precursors to downstream customers rather than conducting intelligence collection. The espionage tag applied to a Canadian telecommunications target is analytically notable: telecommunications infrastructure holds significant intelligence value, and the sector has been a consistent target of state-aligned actors. However, the tension between the espionage motivation tag and Emotet's canonical financial alignment cannot be resolved. The pattern may suggest either a tasked use of Emotet infrastructure for intelligence collection by a downstream customer, or a metadata labelling artefact. Current evidence for the espionage interpretation is thin, and it should be treated as a low-confidence inference rather than an established finding.
No widely-reported prior campaign with confident attribution to this specific infrastructure cluster comes to mind. CTX Team has not identified prior named operations or dated attribution reports that would allow a confident historical parallel to be drawn.
Data Gaps and What Remains Uncharacterised
The most significant analytical limitation is the two unanalysable file hashes. fed0c75618acde43a7376ff7c5db4927f4be8ab3bcb73bfa86c86ae78aeab7c2 and e24ab9007c6e25ede1a545ac974ce8048235df4363c761e668a47f8af4c7cb59 appear in the indicator catalog with no associated metadata. If these represent second-stage loaders, implant modules, or post-exploitation tools delivered after the Word document executes, the full capability picture of this campaign remains uncharacterised. The Word document is the initial-access vehicle; what it drops and executes is the operational payload, and that layer is currently a black box.
The Word document also lacks sandbox verdicts, import hash data, and code-signing information. Without sandbox verdicts, the execution chain from document open to C2 beacon cannot be directly traced through behavioural telemetry; it must be inferred from AV consensus and threat tags. Without import hash data, the document cannot be clustered against peer samples through build-pipeline fingerprinting. Without code-signing data, the supply-chain framing that would apply to a signed binary does not apply here.
The lucy-jade.com temporal anomaly — a certificate predating the domain's registration by nearly two years — is a data-quality issue that affects confidence in the domain's certificate history. The 89-day wildcard pattern is still valid as a structural observation, but the specific certificate dates for lucy-jade.com should be treated with caution pending clarification of the data-source inconsistency.
CTX Team assesses overall confidence in this campaign's infrastructure characterisation as medium, reflecting strong signal on the domain certificate patterns and the SAKURA node's hosting fingerprint, offset by the unanalysable file hashes and the lack of sandbox-derived behavioural data.
The Industrialisation of C2 Certificate Management
The operational significance of this campaign extends beyond the specific indicators. The infrastructure architecture documented here — automated 89-day Let's Encrypt wildcard cert rotation, WordPress-path URL blending, distributed hosting across AWS and Japanese shared infrastructure, a zero-detection node on a commodity hosting platform — reflects an operator who has industrialised the certificate management and hosting diversification aspects of C2 infrastructure to the point where the marginal cost of standing up a new beacon endpoint is effectively zero.
This matters for how defenders and analysts think about TLS-based trust signals. The conventional heuristic that a valid, CA-issued TLS certificate is a positive trust indicator was already under pressure from the widespread adoption of free certificate authorities; this campaign's infrastructure demonstrates how automated ACME renewal makes that heuristic actively exploitable at scale. An operator running scripted cert rotation across a portfolio of domains does not need to think about certificate management as an operational overhead — it is a solved problem that runs in the background. The wildcard SAN pattern extends this further: a single certificate renewal covers the entire subdomain space, meaning new C2 endpoints can be instantiated under valid TLS without any certificate-related operational action.
The geographic and administrative distribution of the hosting — AWS in the United States for the primary .com domain cluster, SAKURA Internet in Japan for the undetected IP node — means that infrastructure takedown requires coordinated action across multiple providers and jurisdictions. Neither provider is inherently suspicious; both are legitimate hosting platforms used by millions of legitimate customers. The SAKURA node's zero detection ratio is a direct consequence of this strategy: a shared-hosting IP on a major Japanese provider, presenting a platform-issued certificate, generates no inherent suspicion signals at the network layer.
The espionage motivation tag, if it reflects actual tasking rather than a labelling artefact, would represent a notable shift in how Emotet-attributed infrastructure is being used. Telecommunications organisations in Canada hold both commercial and national-security-relevant data — network topology, subscriber records, lawful intercept infrastructure, roaming agreements with international carriers. An Emotet loader delivering a financially motivated payload to a telecom is a known pattern; an Emotet loader delivering an intelligence-collection implant to the same target is a different operational picture entirely. The two unanalysable file hashes are the most important gap in resolving that question. Until the second-stage payload is characterised, the full intent of this campaign — financial, espionage, or both — remains open.
What the infrastructure evidence does establish, independent of motivation, is that the operators behind this campaign have reached a level of C2 management maturity where the traditional indicators of compromise at the network layer — suspicious certificate issuers, anomalous hosting providers, flagged IP reputation — are systematically neutralised by design choices made at infrastructure build time. The lure document is a well-understood artefact; the C2 architecture behind it is the more durable operational investment.