Beaconing in the Noise

Strongest → weakest, with what each does and does not establish:

1. Self-signed certificate on a host claiming to be a content-delivery network (strongest). A legitimate CDN cannot operate on a self-signed certificate - no client would trust it, and no vendor ships that. This is close to conclusive that the endpoint is not what the SNI claims. It does not tell you which process on the host is talking.
2. Pattern mismatch with the claimed function. Fixed 1.2-second sessions carrying ~1.4 KB out and ~900 B in, every five minutes, versus real update traffic at 30-60 minute intervals moving megabytes. Machine-generated check-in with no payload delivery is inconsistent with updating anything. This proves the traffic is not what it says it is; it does not prove command-and-control versus, say, unwanted adware telemetry.
3. Jittered 280-330 second interval. Human-configured jitter to evade periodicity detection. Suspicious, but many legitimate agents jitter too - this is corroborating, never sufficient.
4. Identical JA3 across every session. Proves the same client software made every connection and gives you a pivot to hunt across the estate. It does not prove malice - legitimate tools also have stable fingerprints. Its real value is the mismatch with the vendor JA3 your 60 known-good hosts present for the same claimed service.
5. DNS on the same 300-second cadence with short TTL and no caching (weakest of the network facts). Suggests the client re-resolves each time, which is common in commodity malware and in DGA-adjacent designs, but plenty of legitimate software ignores TTL. On its own it means very little.
6. "Uncategorized" reputation (not an indicator at all). Attacker infrastructure is usually new; categorisation lags by weeks and is trivially gamed.

What the network evidence collectively proves: a host is running software that is lying about its identity and behaving like an automated check-in. What it does not prove: the process, the operator, or whether any data is actually leaving.

Order by perishability - capture the volatile host evidence first, because logs will still be there.

1. EDR / Sysmon network-connection events mapped to PID for 10.20.4.77 in the last 48 hours. This is the fastest route to a name: executable path, hash, signer, parent process, command line, and user context. If the process is a signed Microsoft binary living in C:\Windows\System32, the story changes completely from if it is an unsigned binary in %APPDATA%.
2. Memory and autoruns triage of that process - scheduled tasks, services, run keys, WMI subscriptions, and any injected module. Persistence tells you whether killing it is enough.
3. Proxy and web logs (90 days retained) - full URI paths, method (POST versus GET), response sizes, and whether the outbound volume ever spikes. A check-in that occasionally POSTs hundreds of kilobytes is exfiltration; one that never exceeds 1.4 KB is tasking only.
4. DNS logs across the estate for update.windows-cdn[.]net and for the same JA3/ASN - this scopes the incident. One host is an incident; fourteen hosts is a campaign.
5. PCAP (48 hours) to confirm the payload shape and extract certificate details for indicator sharing.

The sequencing judgement: normally you avoid blocking early so the adversary does not know you see them. Here, the calculation is different - the host is confirmed to be running something that is lying about its identity, and the cost of leaving it live outweighs the intelligence value of watching. But do the host-telemetry capture first, then isolate. And scope from logs, which are retained, rather than from the live host, which is perishable. Capture, then contain, then hunt.

"Uncategorized" is the expected state of attacker infrastructure, not evidence of innocence.

• Reputation categories are built from historical web-crawl and customer telemetry. A domain registered two weeks ago has no history, so it defaults to uncategorized. The absence of a bad category means "unknown," never "good."
• Category-based allowlisting is defeated by exactly this. If your proxy policy permits uncategorized traffic - a very common default configuration - this connection is permitted by design.
• Shared hosting and domain fronting mean the address and the SNI may not describe the real destination at all. Judging by domain name is judging by the least reliable field in the session.

Note the direction of the logic: only one field here is nearly dispositive, and it is the self-signed certificate on a host impersonating a CDN. Reputation is the weakest field and cannot offset it. A clean reputation check does not survive a contradictory certificate.

I would stand down only on all of the following together:

1. Process attribution shows a signed, expected binary whose signer matches the vendor, launched by a legitimate updater parent.
2. The certificate chains to a trusted CA with a name matching the service, or the anonymity is fully explained by a documented corporate proxy doing TLS inspection.
3. The traffic pattern matches the vendor's documented behaviour - and if the 300-second check-in is real, the vendor documents it and other hosts on your network show the same pattern.
4. No other indicator arises from memory or autoruns triage.

Absent any one of those, this stays an open incident. The certificate alone is enough to justify isolation while you finish the investigation.