Bulletproof-Hosting Tradecraft: Two-Hour DGA Certificates, Role-Separated Nodes, and Brand-Impersonation TLS

Bulletproof-Hosting Tradecraft: Two-Hour DGA Certificates, Role-Separated Nodes, and Brand-Impersonation TLS

Date: June 2026 (observation window); confirmed offline as of September 2026

TLP:CLEAR — unrestricted distribution

Source: State of the Attack

Atomic indicators: withheld from this report — see “Requesting indicators” at the end.

On a known bulletproof-hosting provider, three nodes sat side by side on the same /24 and ran three distinct, complementary roles: a fake-update dropper, a brand-impersonation TLS relay, and a command-and-control node that served algorithmically-named TLS certificates, each valid for exactly two hours and different at each of our checks. We assess with moderate confidence that a single operator ran all three, based on their co-location and complementary roles. We did not observe a shared indicator — certificate, credential, or client fingerprint — that ties the three nodes to one controller. The dropper node went dark during the observation window; the C2 node was still serving a fresh two-hour certificate at our later checks, but a September 2026 recheck found it offline too. The cluster is fully dark now, but the tradecraft is still operational: the same techniques will show up on the next provider, the next address block, the next set of throwaway IPs. This report documents the behavioral signatures and techniques that survive infrastructure changes.

The tradecraft outlasts the indicators

The atomic indicators here — IPs, certificate fingerprints, payload URLs — don’t last. The C2 node served a different certificate at every check, and the bulletproof provider recycles IPs between tenants faster than a blocklist can keep up. Blocking that window’s IPs will do nothing about the next one’s. What stays constant is how the cluster was built and run. Every signature below is written to fire on the tradecraft, so it keeps working as infrastructure rotates to the next cluster.

Key terms

• /24 — a block of 256 consecutive IP addresses under one network operator. Three malware nodes sharing a /24 were hosted side by side, not scattered across the internet.
• Bulletproof hosting — a provider that refuses takedown requests and tolerates abuse. Operators pay a premium for uptime that survives complaints.
• DGA (Domain Generation Algorithm) — algorithmically generated names (here, TLS certificate subject/issuer fields) with no semantic content, used to make blocking by name impractical.
• Self-signed certificate — a certificate that vouches for itself rather than chaining to a trusted certificate authority. Nothing external confirms it.
• Brand impersonation (certificate) — a certificate whose label strings (subject, issuer) print a trusted brand’s name without being issued by that brand’s real authority. The labels are cosmetic — whether the certificate is self-signed or forged some other way is a separate question from what the labels claim.
• MSI — Windows Installer Package format. Windows treats MSI installers with elevated trust compared to raw executables, making MSI a preferred container for malicious installers.

The three operational roles

Role 1 — Dropper delivery

The dropper node serves files with Windows-update-themed names (two MSI installers and one PE executable) over HTTPS with a self-signed certificate. The host also runs a full mail and web stack — Apache, nginx, OpenSSH on Ubuntu, with SMTP, IMAP, POP3, DNS, and HTTPS all running — enough services that it passes as an ordinary mail/hosting box rather than a single-purpose dropper. Defenders hunting for a “lone HTTPS dropper” signature miss this cover choice.

We were unable to retrieve the payloads: the web services were taken offline mid-investigation while SSH stayed open, which we read as a deliberate pause rather than a takedown.

Role 2 — Brand-impersonation TLS relay

The second node presents a TLS certificate whose subject/issuer label strings impersonate Apple — CN=www.apple.com, O=Apple Inc., issuer label Apple Public EV Server RSA CA 1 - G1 — paired with a Server: AkamaiGHost response header mimicking Apple’s CDN.

What we know and don’t know about this certificate. The issuer field named Apple Public EV Server RSA CA 1 - G1, a real Apple intermediate certificate authority, and the subject read CN=www.apple.com, O=Apple Inc.. Printing a real authority’s name in an issuer field takes no access to Apple at all. We checked the certificate’s SHA-1 fingerprint, a hash that identifies that exact certificate: it is absent from Certificate Transparency, the public append-only logs that trusted certificate authorities write each certificate they issue into. Apple’s authority therefore did not issue this certificate through normal issuance, which rules out a genuine Apple certificate served from someone else’s server. It does not rule out a certificate signed with a stolen Apple intermediate key — very rare in practice, but our data can’t rule it out. During the investigation, the node went offline and we were unable to investigate further. The defender takeaway still holds: a certificate claiming a major brand’s identity that is missing from Certificate Transparency was not issued through that brand’s normal channel. This is a huntable signal. (See the primer at the end for how certificate trust works.)

Role 3 — DGA-rotated C2

The third node presents a certificate with both CN and Issuer populated by algorithmically generated names — random consonant-vowel strings, for example qzvbnpqrst, not a recognizable brand or company name — with no organization metadata, and the two names differ, so its issuer is a random-looking name rather than a public certificate authority. Each certificate we saw had a validity window of exactly two hours, set when it was issued. How often the node actually swaps to a new one is a separate question: we checked the node three times over roughly six weeks, not continuously. All three certificates carried that same two-hour validity window — one of them not yet valid when we captured it, its window opening two days later.

What the two-hour validity defeats. Changing certificates defeats any blocklist keyed to a single certificate’s hash or serial number. Internet-wide scanners such as Censys and Shodan record the certificate each host presents, and threat-intel lists built from those records go stale once the certificate changes. The change does nothing against Certificate Transparency, which only logs certificates issued by public authorities and never sees this node’s, or against JA3 and JA4, which fingerprint the TLS handshake rather than the certificate.

Detection that survives the rotation. The DGA pattern is the signature, not any single fingerprint: both subject and issuer are random consonant-vowel strings with no human-language structure and no organization name, on a cert valid for exactly two hours. That shape held on every certificate we saw.

What defenders should look for (all behavioral — survive infrastructure rotation)

1. TLS certificates with a DGA-pattern subject AND issuer, valid for exactly 2 hours. Both fields random consonant-vowel sequences with no org metadata. Short validity alone isn’t unusual. Service-mesh and workload-identity systems can issue certificates valid for hours too. What separates this pattern from legitimate automation is the random, organization-less subject and issuer together.
2. A certificate claiming a major brand’s identity that is absent from CT logs and served from outside that brand’s IP footprint. The CT absence is the tell — a genuine brand cert would be logged.
3. AkamaiGHost (or any CDN-edge) response header from a host that does not resolve to that CDN’s published IP ranges.
4. Bulletproof-provider /24 ranges hosting three+ co-tenant nodes in different malware roles. Cross-correlating role-separated nodes on one /24 is a stronger signal than any single-node check.
5. MSI/PE installers fetched from a bare IP over self-signed HTTPS. Legitimate updates come from named domains under known publisher orgs.

What will NOT detect this

• Certificate-fingerprint blocklists — the C2 node’s certificate changed between our checks, so a list keyed to one certificate’s hash goes stale.
• CA-revocation checks (OCSP/CRL). The C2 certificates name no public authority as issuer, so no authority can revoke them. The Apple look-alike could only be revoked if it turned out to be signed with a stolen Apple key and that theft became known; its absence from Certificate Transparency is the more reliable signal.
• Domain reputation — delivery is over bare IPs, so there are no domains to score.
• AV signature scan of payloads — payloads weren’t retrievable and the operator can recompile per campaign.

MITRE ATT&CK

• T1036.005 — Masquerading: Match Legitimate Resource Name or Location (update-themed filenames, Apple/Akamai label + header impersonation)
• T1587.003 — Develop Capabilities: Digital Certificates (brand-impersonation certificate)
• T1608.003 — Stage Capabilities: Install Digital Certificate (DGA-named certificate deployed on the C2 node)
• T1583.003 — Acquire Infrastructure: Virtual Private Server (bulletproof)
• T1071.001 — Application Layer Protocol: Web Protocols (HTTPS delivery)

Recommendations

1. Alert on 2-hour-validity TLS certificates with DGA-pattern subject AND issuer at egress inspection points. This is the single highest-confidence signature in the cluster.
2. Flag brand-identity certificates absent from CT logs. Build a check that compares a presented brand CN= against CT-log presence and the brand’s known IP footprint; absence plus off-footprint means it was not issued through the brand’s normal channel, treat it as hostile.
3. Treat any CDN-edge response header (e.g. AkamaiGHost) from a host outside that CDN’s published IP ranges as suspicious. Akamai also runs edge caches inside other providers’ networks, so check against Akamai’s published ranges directly rather than by ASN alone.
4. Block known abuse-tolerant bulletproof ASNs by default on managed-endpoint URL filters — low cost (no legitimate enterprise traffic), high value.
5. Do not rely on certificate “identity” labels for trust. A cert is only as trustworthy as its chain and CT presence, never its printed subject/issuer.

Primer: how TLS certificate trust works

If the Role 2 finding raised the question of how a certificate can say it is Apple’s without being Apple’s, here’s how it works.

A TLS certificate is a signed statement binding a name (its subject, e.g. www.apple.com) to a public key. The subject and issuer fields are just text: anyone can generate a certificate that prints any name in them. What makes a certificate trustworthy is not those labels but two things a look-alike cannot fake:

1. The chain. A legitimate certificate is signed by a Certificate Authority (CA) whose own certificate chains up to a root your operating system or browser already trusts. A self-signed certificate signs itself, so it chains to nothing and no independent authority vouches for it.
2. Certificate Transparency (CT). Public CAs must log every certificate they issue to append-only, publicly auditable CT logs. A genuine www.apple.com certificate is therefore discoverable in those logs. A certificate that claims to be Apple’s but is absent from CT was not issued through a real CA’s normal process. It either borrowed the label or was signed outside that process, for example with a stolen key.

So two certificates can print identical subject and issuer text while one is genuine and one is a forgery. You do not tell them apart by reading the labels. You tell them apart by checking the chain and the CT logs. For the Role 2 certificate we could run only the CT check; it showed the certificate was not issued through Apple’s normal channel, and the chain check that would show who signed it was never run.

Requesting indicators

Atomic indicators aren’t included here. The cluster is dead; the durable value is the technique. Vetted parties (law enforcement, national CERTs, enterprise SOCs) can contact State of the Attack for the full record.

State of the Attack is tracking role-separated, DGA-rotated bulletproof clusters like this one across other providers.