Periodic HTTPS Beacons and SMB Lateral Movement

The pattern favors malware beaconing, but it is not proven by proxy logs alone. The strong indicators are the fixed 60-second interval with jitter, the small POST and response sizes, the same unique JA3 on exactly 47 hosts and no others, the undocumented domain, and the user-agent mismatch with Windows 11. A legitimate business CDN would normally show a documented domain, a broader or explainable client population, and a JA3 consistent with the application or browser stack. The SMB connections from 10.30.5.22 to 14 hosts at 03:12 suggest lateral movement and raise the priority. The counterpoints are that the CDN provider is legitimately used, SNI is missing for 12% of sessions, and the logs cover only 14 days. I would validate by checking the business application's expected endpoints and JA3, reviewing endpoint process and scheduled-task telemetry on a sample of 47 hosts, and comparing the beacon timing across hosts. If the process is unsigned or the domain is not in the application inventory, I would treat it as confirmed beaconing.

Network IOCs include the domain cdn.telemetry-edge[.]net, IP 203.0.113.88, URI /api/v2/checkin, the user agent string, the JA3 fingerprint 51c64c77e60f3980eea90869b68c58a8, the 60-second beacon interval with jitter, and the 3.1 KB POST/800-byte response size pattern. I would hunt in proxy logs for the domain, URI, JA3, and user agent; in DNS logs for the domain and related siblings; in NetFlow for periodic 60-second connections to the IP; and in EDR for the process making the connections and any scheduled task or service. I would also pivot on the SMB connections from 10.30.5.22 to identify the 14 targets and check whether they beacon. Because proxy retention is only 14 days, I would prioritize live endpoint triage and network flow data with longer retention. I would not rely on the IP alone, because CDN fronting means it may be shared and short-lived.

I would prioritize 10.30.5.22 because it shows both beaconing and SMB fan-out, which suggests it may be the lateral-movement source. I would isolate it first through EDR or a network quarantine that preserves memory and remote-access capability, then isolate the other 46 beaconing hosts in waves to avoid disrupting the business all at once. I would block the domain and IP at the proxy and firewall, but keep a sinkhole or monitored deny rule to catch attempted reconnects. I would preserve proxy, DNS, EDR, and SMB logs before containment changes the environment, and collect memory from 10.30.5.22 if policy allows. I would check the 14 SMB targets for signs of execution, reset credentials used on the source host, and search for the same JA3 and URI across the estate. Because the actor may monitor the C2, I would expect containment to tip them off and would move quickly on credential resets and lateral-movement checks.