Two Weeks In: What Certus Is Already Surfacing

Certus has been ingesting Certificate Transparency logs continuously for two weeks, with five days of uninterrupted full-volume ingestion. One pretrained model. No calibrated infrastructure features yet. No graph relationships. No temporal signals beyond what the character distribution alone can tell you.

In that window, the system scored 5.27 million domains and flagged two that were later independently confirmed as malicious by external threat feeds — with lead times of 35 and 61 hours respectively.

This post covers what we found, what remains undetermined, where a single-vector model over-flagged and why, and what those outcomes tell us about CT monitoring as an early detection surface.

Why Certificate Transparency Logs

When a domain operator obtains a TLS certificate, that certificate is logged to a public Certificate Transparency ledger, a requirement of modern browser trust policy. This creates an observable record of every new domain that goes through certificate issuance, at the moment of issuance.

For threat detection, this matters because obtaining a TLS certificate is an operational step for a wide class of threats. C2 infrastructure needs encrypted channels. Phishing pages benefit from browser trust indicators; a valid certificate reduces user friction. Malware operators are increasingly professionalizing their infrastructure. In practice, this means that a meaningful proportion of malicious domains appear in CT logs before they appear in threat feeds, before they appear in blocklists, and before they reach users.

The question is whether you can score them in time for that lead to be actionable. That's what Certus is built to answer.

The Confirmed Detections

brfwhb.ru.com — AsyncRAT Command-and-Control

On February 23 at 02:22 UTC, Certus flagged brfwhb.ru.com with a CNN confidence score of 0.977, alongside www.brfwhb.ru.com at 0.999. Both resolved cleanly at the time of scoring. The domains were active infrastructure.

Sixty-one hours later — two and a half days — ThreatFox published a confirmed record classifying the domain as win.asyncrat, threat type botnet_cc, confidence 100.

The CharCNN flagged it on character patterns alone. "brfwhb" is a six-character zero-vowel consonant sequence — unpronounceable, statistically anomalous, and consistent with programmatic domain generation. The model doesn't know what AsyncRAT is. It knows that this string doesn't look like anything humans name things.

AsyncRAT is an open-source .NET remote access trojan with over 21,000 IOCs tracked on ThreatFox. Its C2 servers commonly use TLS — which means the operational step of obtaining a certificate is essentially mandatory infrastructure setup. That step lands the domain in CT logs before the C2 channel goes live. It's a structural property of how this malware family operates, and it creates a detection window.

The .ru.com TLD is worth noting: it's operated by CentralNic in London, not Russia's ccTLD, and requires no identity verification. The Forescout 2025 domain abuse report found 88.2% of malware-associated domains use permissive-registration namespaces like this. The character signal and the TLD context pointed the same direction; the threat feed confirmed both.

xmrwallet-com-scam.pages.dev — Monero Wallet Phishing

On February 24 at 16:29 UTC, Certus flagged xmrwallet-com-scam.pages.dev at CNN confidence 0.997. The domain resolved cleanly. Thirty-six hours later, OpenPhish confirmed it as an active phishing URL.

The CharCNN flagged it for different reasons than the AsyncRAT case. Where brfwhb is suspicious because of what it lacks — vowels, pronounceability, any human naming pattern — this domain is suspicious because of what it contains. xmrwallet is a brand reference. com is a TLD fragment embedded in a subdomain. scam is an explicit threat keyword, hyphen-concatenated. This combination — brand name, TLD lookalike, threat term — is heavily represented in phishing training data. The pattern is recognizable from the string alone.

The underlying attack is straightforward and effective. xmrwallet.com is a legitimate non-custodial Monero web wallet where users authenticate by entering their seed phrase. A convincing phishing clone captures the seed phrase on first interaction, transferring full wallet control to the attacker. Monero's built-in privacy features make any transferred funds effectively untraceable. The theft is irreversible and unrecoverable.

There's a detail worth noting: a domain containing the word "scam" may also be performing search-engine manipulation. A user searching "xmrwallet.com scam" to check whether the site is legitimate could land on the phishing page itself. The name is both a classifier signal and possibly part of the attack.

Three Signals That Remain Undetermined

Confirmed detections are the clearest result, but they're not the only result worth reporting. Three additional clusters were flagged with high CNN confidence, and OSINT investigation found corroborating infrastructure signals in each case. None have been independently confirmed by any threat feed as of this writing. To be precise about what that means: these are analyst triage candidates, not confirmed malicious infrastructure. Confirmation lag in external feeds is a real thing. Newly provisioned infrastructure may not appear for days or weeks after it goes active.

84651.ru — A pure-numeric .ru domain with Cloudflare nameservers and wildcard DNS. Certus scored 223 unique domains, 64 at CNN confidence above 0.9. The subdomain naming references major Russian consumer brands — Avito, Ozon, Citilink, RuStore, and the Federal Tax Service — with systematic update./www. prefix stacking up to several levels deep. The hosting IP sits on an ASN whose parent network range appears on the Spamhaus DROP list. Registered January 31, 2026.

3dpen-2.ru — A domain with 160+ certificate issuances. The subdomain structure is what stands out: chains like sbermarket.nalozhka.wwwsber.pcth4fhald9kmja.molki.liveproxy.3dpen-2.ru — brand names stacked with embedded random tokens under a liveproxy tier. This pattern is consistent with Adversary-in-the-Middle frameworks documented in public reporting on tools like Evilginx. Hosted on DDoS-Guard infrastructure, returning 503 during our investigation window.

n8ndjalil.ru — The most unusual of the three. The domain generated 1,744 CT log entries covering 797 unique subdomains — all email and DNS infrastructure terms: smtp, imap1, mx, postmaster, exchange, multiplied with prefix chains up to eight levels deep. All mail ports were closed during investigation. HTTPS returned 403. SPF was configured, DMARC set to p=none, DKIM absent. The domain was registered July 2025, issued a handful of test certificates through August, went silent, then generated 362 certificates in a single day in January 2026. The infrastructure profile is consistent with pre-operational staging — though that interpretation remains unconfirmed.

Where the Model Over-Flagged: 0emm.com

On February 24, the pipeline flagged a burst of wildcard certificate activity: 9 certificates covering 432 anchor domains with high SAN fan-out, issued by Google Trust Services between 02:52 and 04:56 UTC. The pretrained CharCNN scored 19 of 27 unique observed domains above 0.9 confidence. The names were 10-character alphanumeric strings — tight entropy clustering, systematic subdomain variants.

It looked, from the character patterns alone, like something worth investigating. Infrastructure investigation resolved it quickly: every domain was registered via MarkMonitor — Google's corporate registrar — with Google's internal authoritative nameservers and A records pointing to Google LLC IP ranges. Batch registration dated June 2017. Parent domain 0emm.com registered in 2000. This is Google's managed enterprise domain portfolio undergoing routine certificate rotation.

The CharCNN was correct that the character patterns are unusual by normal domain standards — programmatically generated names from a corporate portfolio don't look like human-named domains. But character patterns alone can't distinguish Google's internal naming conventions from a DGA. That's exactly what additional model dimensions are designed to address: infrastructure features would weight MarkMonitor registration as a strong benign signal; graph features would identify the shared Google IP space across hundreds of domains; temporal features would recognize the 2017 batch registration.

We don't maintain manual whitelists. This is intentional. Signal training handles discrimination as labeled data accumulates — benign patterns are labeled through independent validation, and the models learn the difference structurally rather than through enumerated exclusion lists.

What This Tells Us

Two confirmed detections in a two-week-old pipeline, from one pretrained model, with no calibrated infrastructure or temporal features. Lead times of 36 and 61 hours ahead of public threat feeds. Three clusters of high-confidence signals with corroborating infrastructure context awaiting independent confirmation. One over-flagged cluster that illustrates exactly what additional model dimensions are designed to resolve.

The core premise holds: CT log monitoring captures malicious infrastructure at a structural operational step, certificate issuance, that precedes broad detection for a meaningful class of threats. The pretrained CharCNN alone is sufficient to surface real signal. The confirmed detections demonstrate that. The undetermined clusters demonstrate that confirmation lag in external feeds is real, and that early surfacing for analyst triage has value even before confirmation arrives.

The multi-model expansion is in calibration now. Infrastructure features will correctly downweight false positives like the 0emm cluster and add corroborating weight where infrastructure context supports suspicion. Temporal features will capture registration behavior and issuance cadence. Graph features will track co-occurrence patterns across certificates and shared infrastructure.

The longer Certus runs, the sharper it gets. These are early results. We expect to keep reporting them.

Detection Timeline