Phorpiex Relay Cluster Exposed by Misplaced TLS Certificate on Spam Domain

A Spam Botnet's Paper Trail: How Coordinated Domain Registration and a Misplaced TLS Certificate Expose a Phorpiex Relay Cluster

Five mail-themed domains provisioned across two registrar accounts, a freshly compiled 18 KB loader carrying an XOR-obfuscated C2 address, and a TLS certificate whose subject field names a spam-trap tracking domain — together these artefacts paint a Phorpiex spam botnet operation whose infrastructure cohesion is unusually legible. The campaign, tracked by CTX Team under identifier CTX3busakohs3, is active as of mid-June 2026, with the core dropper first appearing on June 4 and the relay cluster's most recently issued certificate dated June 2. What makes this operation analytically interesting is not the malware family itself — Phorpiex is a well-understood commodity loader — but the degree to which the operator's domain provisioning choices, mail-authentication posture, and certificate handling leave a coherent fingerprint across otherwise independent sources.

Two Registrar Clusters, One Operator Posture

The campaign's domain infrastructure divides cleanly into two operationally distinct clusters, each bound by shared registrar accounts, nameservers, and resolving IPs.

The first and more operationally significant cluster — kemfra.com, mail.kemfra.com, and popmailset.org — was provisioned via 101domain GRS Limited across a five-day window between April 6 and April 11, 2021. The tight registration window is itself a signal: all three domains were stood up under the same registrar account within days of each other, and kemfra.com and popmailset.org share all three authoritative nameservers — ns1.101domain.com, ns2.101domain.com, and ns5.101domain.com — confirming they were configured from the same account. kemfra.com and its mail subdomain share A-record 104.248.39.236, completing a self-contained mail relay unit: the parent domain points to the IP, the subdomain resolves to the same address, and kemfra.com's MX record points back to mail.kemfra.com. The registrant fields across all three domains are replaced with hex-encoded strings (e.g. "1792841c8fca05fe", "b9fb2ac055e6b632") routed through Digital Privacy Corporation, a consistent operational security pattern [T1583.001].

The most operationally significant signal in this cluster sits on its TLS layer. The certificate currently served by kemfra.com — serial 5ef50ceddb12adc5f4fcefe60fcbd0545cd, issued by Let's Encrypt E7, valid from May 27, 2026 through August 25, 2026 — carries a subject CN of "spamtraplove.malbeacon.com." That subject field names a subdomain of malbeacon.com, a platform that tracks spam botnet beacons and spam-trap interactions. The subject/host mismatch is anomalous: a certificate served by kemfra.com should carry kemfra.com as its subject CN. The presence of "spamtraplove.malbeacon.com" instead indicates that kemfra.com is sharing IP infrastructure — or was at the time of certificate issuance — with a domain that malbeacon has instrumented as a spam-trap lure or botnet beacon tracker. This is a direct external attribution signal embedded in the certificate's own metadata, corroborating that kemfra.com is an active node in a tracked spam operation rather than a dormant registrant. The certificate's 89-day validity window is consistent with the Let's Encrypt short-lived cert pattern seen across the broader infrastructure — a rolling issuance cycle that limits exposure if any single certificate is burned.

The second cluster — rebekamail.com and asdfooff.org — is bound by shared A-record 77.74.177.73 and identical Dynadot nameservers (ns1.dyna-ns.net and ns2.dyna-ns.net). rebekamail.com was registered via DYNADOT LLC on November 22, 2023; asdfooff.org via Dynadot Inc on January 15, 2024 — a roughly two-month gap that suggests sequential provisioning rather than a single batch registration. Both domains configure self-referencing MX records (mx1.rebekamail.com, mx2.rebekamail.com; mx1.asdfooff.org, mx2.asdfooff.org) alongside DMARC records set to p=reject and SPF records publishing "v=spf1 +a +mx -all." This combination — self-hosted MX, strict DMARC rejection policy, and a tight SPF directive that explicitly permits only the domain's own A and MX records — is the mail-authentication posture of a carefully configured legitimate mail server. The operator is not deploying these records to protect recipients; they are deploying them to improve the deliverability of outbound spam by presenting a hardened authentication profile to receiving mail servers that perform DMARC and SPF checks before accepting or filtering inbound messages.

rebekamail.com is independently categorised as phishing by three vendors — alphaMountain.ai, Webroot, and Forcepoint ThreatSeeker — providing external validation of the domain's malicious use. Its registrant fields are replaced with hex strings ("1f8f4166599d23ee", "473daf17453d83cd") routed through Super Privacy Service LTD c/o Dynadot, mirroring the hex-obfuscation pattern on the 101domain cluster.

The hosting IP for this pair, 77.74.177.73, falls within AS 200107, a netblock registered to Kaspersky Lab Switzerland GmbH under RIPE NCC, with a geographic assignment to Russia. The IP itself carries 0/91 detections. The WHOIS record for the netblock (77.74.176.0/21) lists the organisation as Kaspersky Lab Switzerland GmbH with a Zurich address, but the country field is set to RU and the netblock was created in RIPE on December 20, 2021. The combination of a major security vendor's organisational name on the netblock with a Russian geographic assignment and zero IP-level detections is an outlier that warrants attention: this pattern is consistent with a resold or sub-allocated address range being used to blend phishing infrastructure into a netblock that carries reputational cover from its registered owner. CTX Team has not confirmed whether this represents a compromised allocation or deliberate co-option, and the claim that this is intentional blending is an inference from the available evidence rather than a confirmed fact.

The Certificate Anomaly That Ties the Cluster Together

Beyond the kemfra.com subject CN anomaly, the broader certificate landscape across the campaign's domains reveals a consistent short-lived issuance pattern with two additional anomalies worth noting.

kemfra.com and tannercos.com share Let's Encrypt E7 as their certificate issuer, both with 89-day validity windows. tannercos.com (created April 24, 2022) carries a clean E7 certificate with subject CN "tannercos.com" and a valid_from of December 21, 2025 — its presence in the same issuer cohort as kemfra.com is a weaker signal than the subject CN anomaly, but it places both domains on the same certificate authority intermediate at overlapping time windows.

formdmail.com and ellprop.com share Let's Encrypt R12 as their issuer, again with 89-day windows. formdmail.com (registered via NAMECHEAP INC, created June 2, 2020) carries a certificate whose subject CN is "spekkio-search.fangamer.com" — a subdomain of fangamer.com, a legitimate gaming merchandise retailer. This mismatch is structurally similar to the kemfra.com anomaly but points toward CDN-layer or shared-hosting certificate reuse rather than spam-trap tracking: formdmail.com is likely sharing a hosting IP with a fangamer.com subdomain, and the certificate was issued to that subdomain rather than to formdmail.com itself. The WHOIS registrant fields on formdmail.com are again hex-obfuscated, routed through Withheld for Privacy ehf (Reykjavik), with the same hex string "3432650ec337c945" appearing in multiple registrant fields — a string that also appears in the kemfra.com and ellprop.com WHOIS records, suggesting either a shared privacy proxy template or a common registrant identity across these domains.

The recurrence of "3432650ec337c945" as a hex-encoded registrant field value across kemfra.com, formdmail.com, and ellprop.com is a low-confidence cohort signal — privacy proxy services often populate these fields with templated or account-specific hex strings, so the match may reflect a shared proxy account rather than a single human operator. CTX Team treats this as a possible linkage axis rather than a confirmed binding.

The GoDaddy-registered legacy trio — artjconsultants.com (created January 10, 2007), 7gtech.com (created May 8, 2008), and asapbox.com (created August 9, 2016) — carries 0/91 detections across all three domains with no operational ties to the relay infrastructure. Their presence alongside the purpose-built relay cluster is best explained by co-option or compromise of legitimate aged domains rather than purpose-built attacker provisioning. These domains should be treated as lower-confidence indicators; the infrastructure analysis that follows focuses on the 101domain and Dynadot clusters where the evidence density is highest.

The Loader: Eighteen Kilobytes, Zero Imports, One Rule Hit

The payload side of this campaign is represented by two files sharing a single IE cache subdirectory path, with a 27-day gap between their first appearances suggesting an iterative build cycle rather than a one-shot deployment.

The first artefact — d6cd50a9, a 7-byte ASCII text file named n[1].txt — was first seen on May 8, 2026, staged in the IE cache path C:\Users\user\AppData\Local\Microsoft\Windows\INetCache\IE\MCXUJQJD. It carries 0/76 detections and has not been processed by any sandbox. Its role in the chain is inferred from context: the shared MCXUJQJD subdirectory path with the subsequent EXE, Phorpiex's documented practice of fetching a numbered configuration or URL list before downloading the main payload, and the numeric alt_name "416558930" on the text file, which is consistent with Phorpiex's numbered download scheme. No behavioural claims about this file can be made from direct observation; it is an undetected text artefact whose function is suggested by its position in the download chain.

The second artefact — 99148a1f, an 18 KB Win32 GUI PE32 executable named 5[1].exe — was first seen on June 4, 2026, in the same MCXUJQJD subdirectory. Its threat label is "trojan.phorpiex/mint," with popular names phorpiex, mint, and zard. Both sandboxes that processed the sample returned malicious verdicts: Yomi Hunter classified it as MALWARE, and C2AE named the family as Phorpiex with 50% confidence. The detection ratio is 52/76, with engines including APEX, AVG, AhnLab-V3, CrowdStrike, ESET-NOD32, F-Secure, and Fortinet flagging the sample. Eighteen engines — including ALYac, Acronis, Webroot, and Zoner — still miss it.

The loader's build profile is consistent with Phorpiex's known small-loader architecture. The PE timestamp is June 4, 2026 — the same date as first submission, indicating the sample was compiled and submitted the same day. The imphash is edd9caae8565fbe43a73e0ad530f325e. The import count is zero, which points to dynamic API resolution at runtime: the loader resolves Windows API calls by walking the PEB loader list or using a custom hash-based lookup rather than declaring imports in the PE header, a technique that defeats import-table-based static detection and hinders automated analysis. The PE sections show a .text entropy of 5.95 and a .data entropy of 1.56 — the low .data entropy is consistent with storage of a short XOR key or a small plaintext configuration block rather than a packed payload, while the moderate .text entropy reflects compiled code rather than a compressed or encrypted blob.

The YARA rule SUSP_XORed_URL_In_EXE, from Florian Roth's Nextron Systems signature-base, fires on this sample. The rule is designed to detect XOR-encoded URLs within PE executables — a technique Phorpiex has used to conceal its C2 or payload staging URLs from static string scanners [T1027]. The combination of zero static imports and an XOR-obfuscated URL means the loader presents a minimal static surface: no import table to analyse, no plaintext URL to extract. The EXE is unsigned, carrying no Authenticode signature, which removes code-signing as a detection or trust vector. The numeric temp-path names — %TEMP%\2707321215.exe and C:\Users\user\AppData\Local\Temp\1849122987.exe — are consistent with Phorpiex's documented convention of assigning random numeric filenames to downloaded executables [T1204.001].

The loader's execution model is a two-stage download chain: a link delivered via the spam relay infrastructure [T1566.002] directs a victim to retrieve the text configuration file into the IE cache, after which the loader binary is fetched to the same cache subdirectory and executed. The IE cache path (INetCache\IE) is the legacy Internet Explorer temporary internet files location, used by older browser-initiated downloads and by some downloader families that invoke WinINet APIs directly. Its appearance here is consistent with a downloader that uses WinINet rather than modern browser APIs, which is characteristic of Phorpiex's loader generation.

The C2 Endpoint and the VPS Outlier

The inferred C2 endpoint for the Phorpiex loader is 130.12.180.190, hosted on AS 202412 (Omegatech LTD) in the Netherlands under RIPE NCC. This is the only IP in this infrastructure carrying a negative reputation score: 18/91 detections and a reputation of -1, with one community vote marking it malicious. The WHOIS record lists the /24 network (130.12.180.0/24) under Netiface LLC PRIVATE-NETWORK and Virtualine Technologies LANEDONET, with a WHOIS date of May 15, 2026.

Omegatech LTD is a small VPS provider with no shared registrar, nameserver, or A-record cohort linkage to the mail relay clusters. Its presence as the sole negatively-reputed IP among infrastructure otherwise dominated by zero-detection domains and IPs is consistent with its serving a different operational function — runtime C2 rather than spam relay. The inference that 130.12.180.190 is the Phorpiex loader's C2 endpoint is grounded in the sandbox Phorpiex verdict, the XOR-obfuscated URL in the loader (which would resolve to a C2 address at runtime), and the IP's anomalous reputation profile [T1071]. CTX Team has not observed direct network traffic between the loader and this IP; the C2 attribution is an inference from converging circumstantial signals rather than a confirmed network observation.

The three remaining IPs — 96.102.157.181 (AS 7922, Comcast Cable Communications, the United States, 0/91 detections), 123.49.12.146 (AS 17494, Bangladesh Telecommunications Company Limited, 1/91 detections), and 77.74.177.73 (AS 200107, discussed above) — each appear on a unique ASN with no cross-IP cohort linkage. The Comcast and BTCL IPs carry no negative reputation and no shared infrastructure with the mail relay cluster; their inclusion likely reflects victim-side or relay-path telemetry rather than attacker-controlled infrastructure.

The DGA-tagged domain wfyndrzv.com — carrying 0/91 detections and a last_modified of October 26, 2019 — is an outlier among indicators otherwise dominated by manually registered, mail-themed domains. Its presence alongside purpose-built relay infrastructure suggests the possibility that the operator maintains or has tested an algorithmic C2 fallback mechanism separate from the registered domain cluster. This is a low-confidence inference: the domain may represent a different generation of the operation, a dormant fallback, or simply a false positive. Current evidence is too thin to draw firm conclusions, and CTX Team treats it as a flag for further investigation rather than a confirmed campaign element.

Operational Security Discipline and Its Limits

The operator behind this cluster demonstrates a level of mail-infrastructure discipline that goes beyond the minimum required to send spam. Deploying hardened DMARC (p=reject) and tight SPF (+a +mx -all) across multiple domains, configuring self-referencing MX records, using privacy proxy services with hex-obfuscated registrant fields, and distributing registrations across at least two registrar accounts (101domain GRS Limited and Dynadot) are all choices that reflect awareness of how spam filters and threat intelligence platforms evaluate sender reputation and domain provenance.

The privacy proxy pattern is consistent across the confirmed relay domains: rebekamail.com routes through Super Privacy Service LTD c/o Dynadot with hex registrant strings; kemfra.com routes through Digital Privacy Corporation with hex strings; formdmail.com routes through Withheld for Privacy ehf with hex strings. The hex-encoding of registrant fields is a deliberate obfuscation of the underlying registrant identity, replacing human-readable names and addresses with opaque tokens that defeat simple WHOIS-based attribution.

Against this backdrop, the kemfra.com certificate anomaly stands out as an operational security failure rather than a deliberate choice. Serving a TLS certificate whose subject CN is "spamtraplove.malbeacon.com" on a domain that the operator intended as a spam relay node is not a feature — it is an exposure. The certificate was issued by Let's Encrypt E7 on May 27, 2026, nine days before the Phorpiex dropper's first submission. The most plausible explanation is that kemfra.com was sharing a hosting IP with a malbeacon-instrumented domain at the time of certificate issuance, and the certificate was issued to the malbeacon subdomain rather than to kemfra.com itself — a consequence of shared hosting or IP reuse that the operator did not anticipate would expose the domain's association with a tracked spam botnet. Let's Encrypt's automated issuance process does not validate the intent of the certificate requestor; it validates control of the domain. If kemfra.com was co-hosted with "spamtraplove.malbeacon.com" at the time of the ACME challenge, the certificate would be issued to whichever domain completed the challenge — in this case, the malbeacon subdomain.

The result is that an operator who took care to obfuscate registrant fields, deploy hardened mail authentication, and XOR-encode the loader's C2 URL inadvertently left a direct external attribution signal in the certificate metadata of one of their relay domains. This is the kind of operational security gap that arises not from carelessness about individual choices but from incomplete awareness of how those choices interact across sources that the operator may not have modelled as part of their threat surface.

What the Infrastructure Maturity Signals About This Campaign's Trajectory

The analytical significance of this campaign is not the Phorpiex dropper — an 18 KB unsigned loader with a well-understood family profile and 52/76 detection coverage is not a novel threat. The significance is the infrastructure layer behind it, and what that layer reveals about the operator's operational maturity and the campaign's likely trajectory.

A spam botnet operator who provisions mail relay domains in coordinated registration windows, deploys DMARC p=reject and SPF +a +mx -all to improve deliverability, distributes registrations across multiple registrar accounts to reduce single-point takedown exposure, and routes registrant identity through multiple privacy proxy services is not operating at the low end of the commodity spam ecosystem. These are deliberate, informed infrastructure choices that reflect an operator who understands how mail authentication and domain reputation systems work and is actively engineering around them. The fact that the Phorpiex dropper itself is a commodity loader does not contradict this; commodity loaders are chosen precisely because they are reliable, well-tested, and widely available, not because the operator lacks sophistication.

The 27-day gap between the text configuration file's first appearance (May 8, 2026) and the EXE's compilation and submission (June 4, 2026) is consistent with an iterative build cycle: the operator staged a configuration or URL list, then compiled and deployed the loader against it. This is not a one-shot campaign; it is an ongoing operation with an active development cadence. The freshness of the dropper — PE timestamp and first submission both on June 4, 2026, nine days before CTX Team's last observation — places this campaign in active deployment at the time of writing.

The presence of a DGA-tagged domain alongside manually registered infrastructure is the most forward-looking signal here, even at low confidence. If the operator is testing or transitioning toward algorithmic C2 generation as a fallback mechanism, the infrastructure picture becomes significantly harder to disrupt through domain-level takedowns. Manual registration clusters can be actioned through registrar abuse processes; DGA-generated domains require either pre-computation of the generation algorithm or sinkholing at scale. The operator's current reliance on manually registered, mail-themed domains with hardened authentication records suggests the primary delivery mechanism remains spam relay rather than DGA-driven C2, but the presence of wfyndrzv.com in the same indicator set raises the question of whether that posture is evolving.

The campaign's regional tags — Honduras, Kyrgyzstan, and the United States — are consistent with Phorpiex's historically opportunistic delivery model: the botnet sends to whatever addresses are in the operator's list, without sector discrimination. The downstream payload — whether cryptocurrency theft, sextortion spam relay, or secondary malware distribution — remains unconfirmed. What is clear is that the delivery infrastructure is active, the loader is freshly compiled, and the operator has invested meaningfully in the mail-relay layer that gets the initial link in front of victims. For organisations operating mail gateways that evaluate sender reputation and DMARC alignment, the deliberate hardening of the relay cluster's authentication posture is the most operationally relevant signal: this operator has specifically engineered their infrastructure to pass the checks that commodity spam typically fails.