Plesk Default Certificate Exposes All Eight LummaStealer C2 Domains

One Certificate, Eight Domains, One Exposed Server: LummaStealer's Plesk Fingerprint Problem

Eight command-and-control domains serving an active LummaStealer campaign share a single Let's Encrypt TLS certificate whose subject common name reads admiring-poincare.37-77-150-150.plesk.page — the auto-generated Plesk control-panel hostname for the raw IP address 37.77.150.150, hosted on Proton66 OOO (ASN 198953) in Russia. The operator registered all eight .su domains in a single batch on 2025-09-19, pointed them at one server, and then allowed Plesk to issue a default certificate that encodes the physical server's IP address directly in its subject field. That single oversight collapses what was designed as an eight-hostname rotation pool into one attributable node — and the certificate has since been renewed, confirming the infrastructure remains live and operator-maintained through at least mid-2026.

CTX Team's analysis of this campaign, tracked under identifier CTX4eca7io63e, maps the full C2 fabric: nine domains in total, seventeen URL paths, and one hosting IP, all net-new additions to the observable indicator set. The dropper delivering LummaStealer to technology-sector targets in Spain and Mexico is a PE64 binary impersonating the Windows cabinet extractor WEXTRACT.EXE, carrying a Mozilla Corporation code-signing chain that fails full authenticode verification — a grafted certificate designed to satisfy signature-trust heuristics without actually being valid. Together, the infrastructure fingerprint and the payload's dual-layer evasion design paint a picture of an operator who is cost-efficient and operationally aware in some dimensions, and careless in others.

The Plesk Certificate That Named the Server

The primary C2 cluster is bound by four overlapping axes simultaneously, and the tightest of them is a single TLS certificate. Let's Encrypt R12 certificate serial 5ee1c638d84322bfe85a6b9e451a954406e, issued 2026-05-06 with an 89-day validity window running to 2026-08-04, appears on every one of the eight .su domains — bendavo.su, ozonelf.su, squatje.su, conxmsw.su, exposqw.su, narroxp.su, squeaue.su, and vicareu.su — and on the hosting IP 37.77.150.150 itself. The certificate's subject CN is admiring-poincare.37-77-150-150.plesk.page, and that string is also the sole subject alternative name. This is not an attacker-chosen hostname; it is the default Plesk panel certificate that the server management software auto-provisions when an administrator does not configure a custom TLS identity for the panel. The IP address is embedded in the hostname by design, so that Plesk can generate a valid certificate for its own management interface without requiring a separately registered domain.

The consequence for attribution is significant. An analyst who observes any single one of the eight .su domains in network telemetry can pivot on the certificate serial to recover all eight domains and the hosting IP in a single query. The cert serial functions as a high-confidence grouping key: the nine-node set (eight domains plus the IP) shares one certificate, one A-record, one pair of authoritative nameservers (ns1.reg.ru and ns2.reg.ru), and one registrant identity. WHOIS records across all eight .su domains show registrant email [email protected] and registrant name token 4c58731460c07301, confirming a single operator account at reg.ru provisioned the entire pool in one batch on 2025-09-19.

The domain registrations predate the dropper's first appearance in telemetry by approximately ten weeks — the PE64 file was first submitted on 2025-11-24 — indicating deliberate infrastructure staging ahead of the campaign's operational phase. The shared R12 certificate was then issued a further six months after the domains were registered, in May 2026, showing the operator has actively maintained and re-certificated the infrastructure rather than abandoning it. The .su domain pool has now been live for over eight months, a lifespan that makes the cert-serial and A-record pivot points durable rather than ephemeral detection signals.

Detection coverage on the domains themselves is moderate but not overwhelming: bendavo.su, ozonelf.su, and squatje.su each score 20 of 91 engines on VirusTotal; conxmsw.su, exposqw.su, narroxp.su, and squeaue.su score 19 of 91; vicareu.su scores 18 of 91. The hosting IP 37.77.150.150 scores 14 of 91 with a reputation score of -12. The relatively low engine counts across the domain set, despite active Proofpoint Emerging Threats IDS rule coverage, suggest the domains are not yet broadly propagated through commercial threat-intelligence feeds — which is consistent with the infrastructure being net-new to this observation window.

A Fallback Channel Built to Survive the Primary Cluster's Takedown

The ninth domain in the indicator set, resusct.qpon, sits entirely outside the .su infrastructure on every measurable axis, and that structural isolation appears deliberate. Where the eight .su domains share a registrar (reg.ru), nameservers (ns1.reg.ru / ns2.reg.ru with TTL 21600), a hosting IP (37.77.150.150, Proton66 OOO ASN 198953), and a Let's Encrypt R12 certificate, resusct.qpon uses registrar Dynadot (registrar ID 472), nameservers ns1.dyna-ns.net and ns2.dyna-ns.net with a TTL of only 300 seconds, a separate hosting IP (157.230.44.113), and a self-signed certificate with issuer CN localhost (serial 139e09ef17a2717d549a2426901ac4b8a310b0f6, issued 2025-11-06, one-year validity).

The self-signed localhost certificate is particularly telling. A certificate issued to localhost is not a browser-facing TLS identity — it is consistent with a raw-socket or non-HTTP C2 channel where the malware client does not validate the server's certificate against a trusted CA but instead uses the TLS layer purely for transport encryption. The 300-second TTL on the dyna-ns.net records, compared to the 21600-second TTL on the reg.ru records for the .su pool, further suggests the operator wanted the ability to rapidly redirect the .qpon domain to a new IP if the current hosting is taken down — a more agile DNS posture than the static .su pool.

Despite the structural separation, the Proofpoint Emerging Threats IDS rule ET MALWARE Win32/Lumma Stealer Related CnC Domain in DNS Lookup (resusct .qpon) fires against the same dropper sample that contacts bendavo.su, confirming the .qpon domain is not a separate campaign but a fallback channel within the same operation. The operator has therefore implemented a dual-TLD C2 redundancy design: a primary pool of eight interchangeable .su hostnames against one backend, and a structurally isolated .qpon fallback on separate hosting and a different registrar. If the Proton66 node is blocked or the .su domains are sinkholes, the .qpon channel provides a secondary path to the same implant.

The registrant identity for resusct.qpon is also anonymised, but differently from the .su pool: the WHOIS shows registrant company 473daf17453d83cd and registrant email 29e2c061f3c9524es@ — a truncated or obfuscated address that differs from the [email protected] identity used for the .su domains. The operator appears to have used separate registration identities for the two infrastructure clusters, which is consistent with intentional compartmentalisation at the registrar level even while the two clusters serve the same malware family.

The Dropper: WEXTRACT.EXE Impersonation and a Certificate That Doesn't Verify

The payload delivery mechanism documented in this campaign combines two evasion layers that target different points in a typical endpoint security stack. The first is LOLBin identity spoofing [T1036]: the PE64 dropper (SHA-256 225a57964f4fe0de2712292ccb159249a8eb69c043005b6394c5ff6ef44b76c0, 1,389 KB) presents itself as WEXTRACT.EXE .MUI, the Windows cabinet self-extractor, complete with Microsoft Internet Explorer 11 version strings (11.00.22621.1 (WinBuild.160101.0800)), internal name Wextract, original name WEXTRACT.EXE .MUI, and copyright string © Microsoft Corporation. All rights reserved.. An endpoint control that relies on file-name or metadata allowlisting for the legitimate WEXTRACT.EXE LOLBin would see a plausible match.

The second layer is a grafted code-signing chain [T1036.001]. The binary carries a Mozilla Corporation → DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 chain. The leaf certificate — signer serial 0F 0E F7 C2 D8 19 27 3E 8C 13 F0 16 D2 E0 9B 25, valid from 2025-01-09 to 2027-01-08 — names Mozilla Corporation as the subject and was issued by DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1. Each individual certificate in the chain reports a status of "Valid." The overall authenticode verification, however, fails: the dossier records the verdict as "The digital signature of the object did not verify." The file carries both the signed and invalid-signature tags simultaneously, indicating the authenticode chain was either grafted from a legitimately signed Mozilla binary onto this payload, or the binary was modified after signing in a way that breaks the hash-over-content check while leaving the certificate chain structurally intact.

The practical effect is that a security product performing only certificate-chain validation — checking that each certificate in the chain is issued by a trusted CA and has not expired — will see a Mozilla Corporation signature backed by DigiCert's root infrastructure and may treat the file as trusted. A product that performs full authenticode verification, computing the hash of the signed content and comparing it against the signature, will catch the mismatch. The 44 of 77 engine detection rate on VirusTotal, with 28 engines returning undetected, reflects this split: engines that rely on chain-level trust are more likely to miss the file than those performing content-hash validation.

The build provenance adds a third evasion layer [T1027]. The .rsrc section of the PE64 is 1,347,584 bytes — 94.8% of the file's 1,421,312-byte total — and registers a Shannon entropy of 7.94, consistent with an encrypted or strongly compressed embedded payload. The .text section, by contrast, shows entropy of 6.11 across 32,768 bytes, and the .rdata, .data, .pdata, and .reloc sections are all low-entropy, suggesting the loader stub itself is minimal and unobfuscated while the actual payload is entirely contained within the high-entropy resource section. The imphash for the file is 4cea7ae85c87ddc7295d39ff9cda31d1; no other file in the indicator set shares this value, making the dropper an isolated artefact with no confirmed peer variants.

The PE timestamp embedded in the header reads 2013-02-08 — a date that predates the file's actual first submission by over twelve years and is almost certainly a deliberate timestamp stomp [T1070.006] intended to confuse timeline-based heuristics.

Execution, Persistence, and C2 Beacon: The Attack Chain in Detail

When a victim executes the WEXTRACT.EXE impersonator, the loader stub extracts the high-entropy .rsrc payload and launches it in memory [T1059]. CAPE Sandbox explicitly names the extracted payload as Lumma; three of four sandboxes return malicious verdicts, with only the C2AE sandbox returning an unknown verdict — a result that may reflect partial sandbox-evasion success. The executes-dropped-file and overlay tags in the sandbox behavioural profile confirm the in-memory extraction and execution pattern.

Before committing to full execution, the payload performs environment profiling consistent with sandbox-evasion behaviour [T1497, T1497.003]. The checks-disk-space sandbox tag is a well-documented heuristic used by information-stealing malware to detect virtualised analysis environments, which typically present with small or unrealistically uniform disk configurations. The spreader tag suggests the payload also enumerates connected resources or network shares, though the specific mechanism is not directly observable from the sandbox logs. One of four sandboxes returning an unknown verdict is consistent with at least partial evasion of automated analysis.

Persistence is established via a registry run key or startup folder mechanism [T1547.001]. The persistence tag appears in the sandbox behavioural profile, and MITRE T1547 and T1547.001 are both present in the campaign's technique mapping. The specific registry key path is not directly observable — this stage is inferred from the sandbox tags and MITRE mapping rather than from a direct registry-write log.

Once resident, the Lumma payload initiates C2 communications across the dual-TLD pool [T1071]. The Proofpoint Emerging Threats IDS rule ET MALWARE Win32/Lumma Stealer Related CnC Domain in DNS Lookup (bendavo .su) fires on DNS resolution of the primary C2 domain, and ET MALWARE Observed Win32/Lumma Stealer Related Domain (bendavo .su) in TLS SNI fires on the subsequent TLS handshake — confirming that the C2 channel uses HTTPS rather than raw TCP, with the domain name appearing in the TLS SNI field. A third IDS rule, ET MALWARE Win32/Lumma Stealer Related CnC Domain in DNS Lookup (resusct .qpon), fires on the fallback channel DNS lookup. The fourth rule, ET DNS Query for .su TLD (Soviet Union) Often Malware Related, is a broader heuristic that fires on any .su query but provides additional low-severity signal for network defenders monitoring DNS logs. Two Sigma rules also match the sample at high and medium severity respectively.

The C2 traffic to the .su pool terminates at 37.77.150.150, Proton66 OOO, ASN 198953, a Russian hosting provider whose network block 37.77.150.0/24 was allocated to the organisation in May 2024. Proton66 OOO is registered in St. Petersburg, Russian Federation. The seventeen URL paths in the indicator catalog — including paths such as /asdsa, /rewd, /qwe, /bcdf, /casc, /asd, /vcsf, and /asdasd across the various .su domains — represent the specific C2 endpoints the implant contacts, though no HTTP response metadata was captured for any of them.

LummaStealer as a Service: What the Payload Tells Us About the Operator

LummaStealer — also detected under the labels DarkGate and jggoj by various engines, reflecting the overlapping detection taxonomy common to commodity stealer families — is an information-stealing malware sold as a service. Its primary function is credential and session-token harvesting: browser-saved passwords, authentication cookies, cryptocurrency wallet files, and similar high-value data that can be monetised through direct use or resale on criminal markets. The operator's motivation in this campaign is most likely financial, consistent with the malware family's known purpose and the targeting of technology-sector organisations in Spain and Mexico — regions with significant concentrations of technology companies whose employees hold valuable credentials to cloud platforms, development environments, and financial services. This assessment is inferred from the malware family's documented purpose and the campaign's regional and industry targeting. No named threat actor or group is attributed to this campaign.

The dropper's design choices reflect a degree of operational sophistication that is worth noting. The combination of LOLBin impersonation, a grafted-but-structurally-valid code-signing chain, high-entropy payload embedding, and timestamp stomping represents four independent evasion layers applied to a single file — each targeting a different detection heuristic. The 44 of 77 detection rate, while not low in absolute terms, is notable because the file was first submitted on 2025-11-24 and the detection count has had months to accumulate; a freshly deployed variant would likely have a substantially lower initial detection rate against engines that rely on signature matching rather than behavioural analysis.

The spreader sandbox tag deserves particular attention. LummaStealer variants have been observed in configurations that attempt lateral movement or credential reuse across network-connected resources, though the specific behaviour triggering this tag is not directly observable. If the spreader behaviour is genuine rather than a false-positive sandbox artefact, the campaign's impact within a compromised organisation could extend beyond the initially infected endpoint.

No named threat actor or group is attributed to this campaign. The operator is identified only by the anonymised reg.ru registrant account ([email protected], name token 4c58731460c07301) and their infrastructure choices. No widely-reported prior campaign with confident attribution comes to mind for this specific infrastructure cluster; the historical arc for this operator, if one exists, is not established.

The Seventeen Unverified Hashes: A Significant Blind Spot

The indicator catalog for this campaign lists eighteen file SHA-256 hashes in total. Only one — 225a57964f4fe0de2712292ccb159249a8eb69c043005b6394c5ff6ef44b76c0 — carries any metadata: a file type, size, detection ratio, signer information, sandbox verdicts, or threat label. The remaining seventeen hashes carry no metadata whatsoever and cannot be clustered, attributed, or assessed.

This is a material limitation on the campaign's assessable footprint. The substantiated execution chain rests on a single file IOC. If the seventeen unverified hashes represent additional dropper variants — different packers, different signing chains, different file sizes — distributed in parallel to the confirmed sample, the true breadth of the dropper family could be substantially larger than the single confirmed file suggests. Alternatively, they could represent stager components, second-stage payloads, or entirely unrelated artefacts that were associated with the campaign indicator set through a different analytical path. Without metadata, none of these possibilities can be distinguished.

The ten strong indicators in this dataset — one file with 44 of 77 detections and three of four malicious sandbox verdicts; eight domains with 18–20 of 91 detections and confirmed IDS rule attribution; and one IP with 14 of 91 detections and certificate linkage — provide a high-confidence foundation for the infrastructure analysis. The seventeen unverified file hashes represent a separate, unresolved question about the campaign's payload diversity.

What the Plesk Fingerprint Signals About Operator Maturity

The infrastructure pattern documented in this campaign — bulk same-day domain registration, single-server Plesk hosting on a bulletproof-adjacent Russian autonomous system, and a shared TLS certificate that inadvertently encodes the server IP in its subject field — represents a cost-efficient but operationally noisy C2 provisioning style. The Plesk certificate leakage is an unforced error. A more operationally mature actor provisioning virtual hosts on a Plesk server would either configure a custom certificate for each domain, use a wildcard certificate that does not reference the underlying IP, or place a CDN or reverse-proxy layer in front of the origin server to prevent direct IP exposure. None of those steps were taken here. The result is that the entire eight-domain primary C2 pool collapses into a single attributable node through one certificate serial pivot.

The addition of the structurally isolated .qpon fallback domain on Dynadot with dyna-ns.net nameservers and a self-signed localhost certificate tells a different story: the operator is aware of single-point-of-failure risk at the domain level and has taken steps to mitigate it by placing a fallback channel on entirely separate hosting with a different registrar and a different TLD. The awareness of domain-level risk without corresponding awareness of certificate-level risk is a specific gap in the operator's operational security model — one that is common among actors who understand domain rotation as a concept but have not internalised the certificate as a cross-domain binding artefact.

The eight-month persistence of the .su domain pool — registered September 2025, certificates renewed May 2026, infrastructure confirmed active through the end of May 2026 — indicates the operator is not rotating infrastructure aggressively. This is consistent with a campaign targeting a defined set of organisations over an extended period rather than a rapid spray-and-rotate operation. The certificate renewal in particular is significant: it requires the operator to actively maintain access to the reg.ru account and the Plesk server, confirming the infrastructure has not been abandoned or seized. For network defenders, the cert serial 5ee1c638d84322bfe85a6b9e451a954406e and the A-record 37.77.150.150 are therefore durable pivot points rather than ephemeral indicators likely to rotate within days.

The broader implication is about the economics of commodity stealer infrastructure. LummaStealer's as-a-service model means the operator purchasing access to the builder and C2 panel does not necessarily have deep operational security expertise — they are buying a capability, not building one. The Plesk fingerprint leakage is the kind of mistake that emerges when an operator who understands the malware's evasion capabilities does not have equivalent understanding of the infrastructure layer those capabilities depend on. The payload goes to considerable lengths to defeat endpoint detection through LOLBin impersonation, certificate grafting, high-entropy packing, and timestamp stomping; the C2 infrastructure then exposes the entire server through a default certificate that the operator did not think to customise. That asymmetry between payload sophistication and infrastructure hygiene is a pattern that tends to persist in commodity malware operations, and it is precisely the kind of gap that makes infrastructure-first analysis productive even when the payload itself is well-obfuscated.

Technology-sector organisations in Spain and Mexico represent the identified targeting footprint, and the dropper's dual-layer evasion design — LOLBin metadata spoofing combined with a structurally valid but non-verifying code-signing chain — is specifically calibrated to defeat endpoint controls that rely on file-name heuristics or certificate-chain trust without performing full authenticode content-hash validation. Organisations whose endpoint security posture depends on signature-trust allowlisting rather than behavioural detection are the most directly exposed to this delivery mechanism. The seventeen unverified file hashes remain an open question: if they resolve to additional dropper variants with different signing chains or packing methods, the evasion surface is wider than the single confirmed sample suggests, and the campaign's true detection gap across the industry may be larger than the 44 of 77 figure implies.