DCRat Campaign Hides C2 Traffic Behind Fake Google Analytics TLS Cert

AGoogle Analytics Mask on an Attacker's Domain: How a DCRat Campaign Hides C2 Traffic in Plain Sight

A single attacker-controlled domain is currently staging a DCRat remote-access trojan behind a TLS certificate whose subject common name reads *.google-analytics.com — a deliberate impersonation of Google's telemetry infrastructure designed to make outbound C2 traffic appear, to any network sensor performing only certificate-level inspection, as routine analytics beaconing. The domain, cooperitious.com, is not a freshly minted lookalike: it was registered on 2008-03-15 and has sat dormant for the better part of eighteen years before being re-weaponised onto a bulletproof Netherlands host. That combination — a certificate that lies about who it belongs to, a domain old enough to evade age-based heuristics, and a payload that lies about whether it is validly signed — forms the operational core of a campaign CTX Team has attributed to Manic Menagerie, with targeting concentrated on Germany.

The evasion philosophy running through this campaign is not brute-force but architectural: each layer of the stack exploits a specific gap between what a security control checks and what it actually validates. The TLS certificate passes CN-level inspection. The payload passes a superficial is-signed check. The delivery domain passes domain-age scoring. None of those checks reaches the truth. Understanding how the three layers interlock is the analytical value of this campaign — the infrastructure is small (one domain, one IP, one payload), but the technique density is high.

---

The Certificate That Claims to Be Google Analytics

The most immediately striking element of this campaign is the TLS certificate served by cooperitious.com. Issued on 2026-05-25 by WR2 under Google Trust Services (serial 49eb929a62c2e35e121a6f654a3ebd2a), the certificate carries a subject CN of *.google-analytics.com and twenty subject alternative names spanning the full breadth of Google's analytics and tag-management estate: google-analytics.com, region1.google-analytics.com, ssl.google-analytics.com, www.google-analytics.com, googletagmanager.com, www.googletagmanager.com, app-measurement.com, urchin.com, service.urchin.com, and a series of regional measurement subdomains.

The operational logic is straightforward. Many enterprise egress-filtering and TLS-inspection deployments maintain an allowlist of Google telemetry domains — traffic to *.google-analytics.com is frequently excluded from deep inspection or automatically classified as benign telemetry. A network sensor that evaluates the certificate's CN or SANs rather than the actual destination hostname would classify a connection to cooperitious.com as Google Analytics traffic. The certificate is not forged in the cryptographic sense — it was legitimately issued by Google Trust Services — but its subject fields are a lie about the domain it is protecting. This is the network-layer evasion component of the campaign: the attacker obtained a real certificate from a trusted CA and used it to dress an attacker-controlled domain in Google's identity.

The certificate has an 83-day validity window, expiring on 2026-08-17. That lifespan is short enough to limit exposure if the certificate is burned but long enough to sustain an operation across a multi-month targeting cycle. Critically, the same 83-day window appears on the C2 IP directly.

The domain itself adds a second evasion dimension that the certificate alone does not provide. Cooperitious.com was registered on 2008-03-15 via Squarespace Domains II LLC — a lifespan of 6,671 days at the time of this analysis. Domain-age heuristics that flag newly registered lookalike domains as suspicious would not touch it. The domain's DNS infrastructure further deepens the Google-adjacent camouflage: its nameservers are ns-cloud-a1.googledomains.com through ns-cloud-a4.googledomains.com, meaning DNS resolution itself passes through Google's infrastructure. An analyst or automated system observing only the DNS layer would see Google nameservers resolving a domain with a Google Analytics TLS certificate — a coherent, superficially legitimate picture that only breaks down when the A-record destination is examined.

That A-record points to 45.159.189.135, a host in AS14576 (Hosting Solution Ltd.), sitting in the RIPE-registered netblock NL-ITHOSTING-POOL (45.159.188.0/22). The WHOIS administrative contact for this netblock lists an address in Tallinn, Estonia (Padriku tee 12/3-4), though the IP is geolocated to the Netherlands. CTX Team characterises AS14576 as bulletproof-adjacent — a provider whose infrastructure appears in attacker-controlled deployments without generating significant reputation-based blocking. The IP itself scores 0/91 on VirusTotal with zero community votes, meaning it carries a clean reputation that extends the operational lifespan of the C2 channel. That clean score is not evidence of legitimacy; it is evidence that the infrastructure has not yet been widely reported, which is itself operationally useful.

---

A Self-Signed Fallback and the Single-Session Provisioning Pattern

While cooperitious.com presents the Google Analytics certificate to browsers and network sensors performing SNI-based inspection, the raw IP 45.159.189.135 tells a different story when queried directly. Its most recent TLS certificate (serial 80e5cabdf41b68e0ba718f4a1224efa3) carries both issuer and subject set to invalid2.invalid, with the organisational unit field reading "No SNI provided - please fix your client." This is a self-signed fallback certificate consistent with a raw-IP TLS listener that does not expect — and does not negotiate — SNI. The practical implication is a C2 architecture with two modes: connections routed through the domain receive the Google Analytics certificate and blend into allowlisted telemetry traffic; connections made directly to the IP over port 443 receive the self-signed fallback, consistent with direct-IP C2 beaconing as used by DCRat implants that embed a raw IP address rather than a hostname in their configuration.

The timing of these two certificates is the most operationally significant infrastructure signal in this campaign. The domain certificate was issued at 2026-05-25 08:36:19 UTC. The IP certificate was issued at 2026-05-25 09:42:12 UTC — sixty-six minutes later, on the same calendar date, with an identical 83-day validity window terminating on 2026-08-17. CTX Team's cohort analysis confirms that this simultaneous provisioning of matching certificates on both the domain and the raw IP on the same date establishes that the entire infrastructure node — domain, IP, delivery path, and C2 listener — was set up in a single operational deployment session rather than assembled piecemeal. This is a disciplined, repeatable infrastructure pattern: an operator who provisions both the delivery layer and the C2 layer in a single session, with matching certificate lifespans, is working from a playbook rather than improvising.

The A-record binding cooperitious.com to 45.159.189.135 collapses what might otherwise appear to be two separate infrastructure elements into one operator-controlled node. There is no redundancy, no backup domain, no secondary IP — the entire campaign rests on this single node. That concentration is both a strength (minimal footprint, low noise) and a structural vulnerability: disrupting either the domain or the IP collapses the entire operation.

One additional DNS detail is worth noting. The domain's nameservers — all four Google Cloud DNS entries — were not changed when the domain was re-weaponised. The SPF record (v=spf1 a mx include:websitewelcome.com ~all) references websitewelcome.com, a legacy hosting provider, suggesting the domain's DNS configuration predates the current operator's control and was inherited rather than freshly constructed. This is consistent with the hypothesis that cooperitious.com was either hijacked from its original registrant or acquired as a dormant asset and re-pointed to the attacker's infrastructure without a full DNS rebuild.

---

The Payload: Three Lies in a Single Executable

The file staged at cooperitious.com/meta.exe is a 2,381 KB Win32 PE32 console executable (sha256 89461345334fb1db1b572a54413ae22fad734f727c156c32762b5ac2c4099a2c) labelled trojan.lazy/gencbl by the VirusTotal consensus and attributed to the DCRat family. Its PE timestamp reads 2022-04-18; it was first submitted to VirusTotal on 2022-04-20 — a two-day gap between compilation and first observation consistent with rapid deployment after build. The filename meta.exe is a generic masquerade, plausibly social-engineered as a system utility or update component.

The file carries three distinct deception mechanisms layered on top of each other.

The first is the broken authenticode chain [T1553.002]. VirusTotal tags the file simultaneously as signed and invalid-signature — a combination that accurately describes the situation: the PE authenticode structure is present, the signature fields are populated, but as the dossier signing narrative states directly, "A certificate chain could not be built to a trusted root authority." The file presents as signed to any check that evaluates only the presence of a signature structure, but the signature is cryptographically invalid because the chain terminates before reaching a trusted root. This technique targets the gap between EDR and AV products that log "file is signed" as a trust signal and those that actually validate the chain. The former class of product — or any analyst who glances at the signed VT tag without reading the invalid-signature tag beside it — would treat this file as carrying a valid code-signing credential.

The second deception is the high-entropy overlay [T1027]. The file's PE section table contains an unnamed section with entropy 8.0 and a size of 2,324,480 bytes — accounting for over 95% of the total 2.38 MB file. An entropy of 8.0 is effectively the theoretical maximum for a byte stream, consistent with either strong encryption or compression applied to a secondary payload appended as an overlay. The .rsrc section (107,520 bytes, entropy 6.61) is the only other meaningfully sized section; the remaining three sections carry zero entropy and null sizes, suggesting they are structural placeholders. The imphash for this file is a2833106949ae6e20c40ed0128f9df4b and the vhash is 02605f0f0f0f6f7bz4!z. The near-maximum-entropy unnamed section is consistent with a packed or encrypted secondary stage — the actual DCRat implant — appended to a loader stub, a construction that defeats static signature matching against the embedded payload and raises the cost of static analysis considerably.

The third deception is the anti-analysis capability embedded in the binary itself. VirusTotal tags detect-debug-environment and overlay co-occur on this sample, indicating the payload actively checks for sandbox or debugger environments before proceeding [T1497]. The spreader tag indicates self-propagation logic is present, consistent with DCRat's known capability set. These are static tag assessments — no sandbox execution verdict is available for this sample, meaning the dynamic behaviour should be treated as probable rather than confirmed. The single submission from a single source on 2022-04-20, with no resubmissions since, means there is no subsequent dynamic telemetry to draw on.

Industry detection stands at 46 of 77 engines flagging the file as malicious, with 27 engines returning clean and four marking the type as unsupported. Among the engines that do flag the file are a broad cross-section of the major AV vendors. Among those that do not flag it — the 27 returning clean — are Avira, ClamAV, DrWeb, F-Secure, Malwarebytes, SentinelOne, and TrendMicro, among others. The detection gap is not trivial: several of those missing engines are deployed in enterprise environments as primary endpoint controls. A 46/77 detection ratio is not a low-confidence signal, but the 35% miss rate across a sample of this age and this level of VT exposure is notable.

---

Attack Chain: From Lure URL to C2 Beaconing

Walking the analyst's attack mechanism chain in sequence clarifies how the three evasion layers interact operationally.

The campaign's initial access stage [T1566] centres on the URL cooperitious.com/meta.exe — a payload staged at a predictable, fixed path on the attacker-controlled domain. The precise delivery vector is not directly evidenced; current evidence is too thin to conclude whether it was phishing, a drive-by redirect, or malvertising. What is evidenced is the staging infrastructure and its camouflage. A link or redirect pointing to cooperitious.com would, in any environment where the domain's TLS certificate is evaluated at the CN or SAN level, appear to reference Google Analytics infrastructure. The meta.exe filename is generic enough to function as a social-engineering lure across multiple pretexts — a browser update, a system utility, a software installer — without requiring the attacker to tailor the filename to a specific target profile.

At the execution stage [T1204.002], the victim runs the 2.38 MB PE32 console executable. The broken authenticode chain is the first evasion mechanism to engage: any EDR product or AV engine that evaluates the signed tag without validating the chain would classify this as a signed binary and apply reduced scrutiny. The PE timestamp of 2022-04-18 and first-seen date of 2022-04-20 establish that the sample was deployed within two days of compilation — a rapid build-to-deploy cycle consistent with an operator working against a specific target window rather than pre-positioning a long-lived tool.

Defense evasion [T1027] is layered on top of execution rather than preceding it. The near-maximum-entropy unnamed section — 2,324,480 bytes at entropy 8.0 — means that static analysis of the file's content encounters an encrypted or compressed blob rather than readable code, defeating signature-based detection of the embedded payload. The detect-debug-environment tag indicates the loader stub checks for analysis environments before unpacking or executing the secondary stage, meaning sandboxes that do not adequately emulate a production endpoint may receive a benign execution path rather than the actual DCRat payload. This combination — static obfuscation plus runtime anti-analysis — is a standard DCRat deployment pattern, but its presence here is confirmed by static evidence rather than dynamic execution.

Command-and-control communication [T1071.001] is directed to 45.159.189.135 over TLS. The raw-IP listener presents the invalid2.invalid self-signed certificate to direct connections, while the domain-routed path presents the Google Analytics certificate to connections that arrive via cooperitious.com. Both paths terminate at the same physical host. The 83-day certificate lifespan on both certificates, provisioned in the same session on 2026-05-25, means the C2 infrastructure has a defined operational window running through mid-August 2026 before certificate rotation would be required. Whether the operator intends to rotate at expiry or simply abandon the node is not determinable from current evidence.

---

DCRat, Manic Menagerie, and the Isolated Build Question

The payload is attributed to DCRat — Dark Crystal RAT — a commodity Windows remote-access trojan with a well-documented capability set that includes keylogging, credential theft, screenshot capture, file exfiltration, and remote shell access. The spreader tag on this sample suggests self-propagation capability is compiled in, consistent with DCRat variants that include network spreading modules. The dual motivation tags in the threat metadata — espionage and financial gain — are consistent with an actor that may pursue both intelligence collection and monetisation objectives: DCRat's credential-harvesting and remote-access capabilities serve both purposes, and the Germany regional tag indicates the current operational focus is on a high-value Western European target environment. No industry sector can be excluded from the target surface.

CTX Team attributes this campaign to Manic Menagerie. No widely-reported prior campaign with confident public attribution for this specific cluster comes to mind, and the historical arc for this actor is thin. The attribution rests on the threat feed metadata rather than a rich body of prior public reporting, and should be treated accordingly — the actor label is a tracking designation rather than a fully corroborated identity.

The payload's build fingerprint raises a specific analytical question. The file's imphash (a2833106949ae6e20c40ed0128f9df4b) is not shared with any other indicator in the set, and the file was submitted to VirusTotal only once, from a single source, on 2022-04-20 — with no resubmissions since. CTX Team's outlier analysis flags this as an isolated build: no shared imphash, signer, or threat label with any peer in the indicator set. This isolation, combined with the single-source single-submission profile, suggests limited distribution or targeted deployment rather than broad commodity spreading — a finding that sits in tension with the spreader tag, which implies the binary contains self-propagation logic. One resolution of this tension is that the spreader capability is present but was not activated in the observed deployment, or that the propagation occurred in an environment not connected to public telemetry. Another is that the sample was deployed in a narrow, targeted operation where the intended propagation surface was small. Neither interpretation can be confirmed from the available static evidence.

The file's meaningful name in the VT corpus is 9fd620186e41d2dfb27002e265c718f5.virus — a hash-derived filename indicating the sample was submitted as a raw binary rather than under its operational name, which is consistent with a researcher or automated system pulling it from the staging URL rather than recovering it from an endpoint.

---

What This Campaign Signals About the Evolving Evasion Landscape

The operational significance of this campaign extends beyond its specific IOCs. The technique at its centre — obtaining a legitimate TLS certificate from a trusted CA with subject fields that impersonate a high-trust third-party service — is not new in concept, but its execution here is precise. Google Trust Services issued a certificate whose CN is *.google-analytics.com for a domain that is not Google's. The certificate is technically valid; the deception is in the subject fields, not the cryptographic structure. This exploits a specific architectural assumption baked into many enterprise security stacks: that a certificate issued by a trusted CA accurately represents the identity of the domain it protects. That assumption holds for the CA's issuance process in the narrow sense — the domain owner requested and received a certificate — but breaks down when the subject fields are chosen to impersonate a different, trusted service.

The re-weaponisation of an 18-year-old dormant domain compounds this. Domain-age scoring is a widely deployed heuristic for identifying newly registered infrastructure used in phishing and malware delivery campaigns. Cooperitious.com, registered in 2008, would score as a long-established domain under any age-based model. The combination of an aged domain, a legitimate CA-issued certificate with a deceptive CN, and Google Cloud DNS nameservers creates a profile that passes multiple independent heuristic checks simultaneously — not by defeating any single check, but by satisfying the surface conditions each check evaluates.

The broken-chain authenticode signature on the payload operates on the same principle at the file layer. The PE structure is present; the signed tag fires; the chain validation fails silently in products that do not surface the failure as a distinct signal. The high-entropy overlay then defeats static content analysis of the payload itself. Three distinct evasion mechanisms, each targeting a different control layer, each exploiting a gap between what is checked and what is validated.

The single-session provisioning of matching 83-day certificates across both the domain and the raw IP is the operational detail that most clearly signals a disciplined, repeatable deployment methodology. An operator who provisions delivery infrastructure and C2 infrastructure simultaneously, with coordinated certificate lifespans, is not improvising — they are executing a playbook. The 83-day window is long enough to sustain a targeting cycle but short enough to limit the blast radius of certificate revocation. The clean VT reputation of the C2 IP (0/91 at the time of this record) means the infrastructure node retains operational runway through at least mid-August 2026 unless actively disrupted.

For organisations in Germany — the sole regional indicator in this campaign — the most immediate implication is that egress filtering policies which grant implicit trust to *.google-analytics.com at the TLS layer, without validating that the actual destination hostname matches the certificate subject, create a durable blind spot that this operator has deliberately engineered their infrastructure to exploit. The aged domain and the Google nameserver configuration mean that passive domain-reputation signals will not close that gap. The analytical question this campaign poses for the broader threat landscape is whether the technique of obtaining legitimate CA-issued certificates with deceptive subject fields — as opposed to self-signed certificates or stolen certificates — will become a more common infrastructure primitive as operators seek to exploit the implicit trust extended to specific high-value domain namespaces in enterprise security policy.