Periodic HTTPS from an OT Jump Host: Beacon or Vendor Agent?
Northbridge Manufacturing runs 1,200 endpoints with a segmented OT zone (VLAN 40) containing 60 Windows HMI and jump hosts. Egress from VLAN 40 is default-deny; only an allowlist of vendor update endpoints is permitted. On Tuesday the NDR sensor reports host 10.40.7.22 - an integrator jump host used by three contractors - opening HTTPS sessions to 185.199.108.153 every 300 seconds with roughly 8% jitter, 1.2 KB out and 900 B back per session. The JA3 fingerprint matches a public Cobalt Strike profile, but it also matches the remote-support agent installed on that host. EDR shows no signature hits, but four days ago services.exe spawned rundll32.exe with no command-line arguments, and no change ticket exists for that window. The vendor says its agent auto-updated the same day. Stopping the line costs about $40,000 per hour and the next change window is Saturday. The plant manager wants assurance before anyone touches the jump host.
1. What triage steps and data sources would you use in the first 60 minutes to decide whether this is beaconing or the vendor agent?
Read the worked answer
Start with the contradiction that matters most: VLAN 40 is default-deny with an allowlist, so a session to 185.199.108.153 is either allowlisted or the policy is not being enforced. Pull firewall rule-hit logs for that destination. If it is not allowlisted you have both an unauthorized channel and a control failure, and the vendor explanation becomes secondary until that is resolved.
Then do process attribution rather than fingerprint attribution. JA3 describes a TLS client implementation, not intent; shared JA3 values between malware and legitimate agents are common. On 10.40.7.22 capture, in this order: the socket-to-PID mapping, the full parent chain of that PID, the image path, Authenticode signer and SHA-256 hash, and loaded modules. The rundll32 spawned by services.exe is the anomaly that must be explained - rundll32 with no arguments is a standard service-installed DLL loader pattern, and 'no change ticket' means it needs a named owner either way.
Compare against peers: query netflow and proxy logs for all VLAN 40 hosts talking to the same IP or to any non-allowlisted destination. One host is suspicious; thirty hosts is an update pattern. Check DNS resolution (shared CDN IP or vendor-owned range), the vendor's published endpoint list, and contractor logons to that host in the same window. Capture memory before anything reboots.
2. The plant manager refuses isolation because of the $40,000/hour line cost. What containment decision do you recommend, and how do you frame it?
Read the worked answer
Uptime is a real constraint but it is not the deciding variable. The deciding variable is whether this host can pivot toward the PLC/HMI network. A jump host used by three contractors exists to be a pivot point, so the risk is asymmetric: hours of production loss versus a line-down or safety event caused by an attacker. Recommend containment within the same shift, not Saturday.
Sequence: (1) capture volatile state while the process is still running - memory image, netstat, process list, logged-on sessions; (2) block 185.199.108.153 and its /24 at the perimeter and alert on any other host that attempts it, which preserves production and simultaneously tests scope; (3) disable the three contractor accounts and force re-credentialing; scope any service account the beacon runs under; (4) apply EDR network containment to 10.40.7.22 after the integrator confirms which sessions can be dropped, cutting RDP while keeping the agent alive for telemetry; (5) rotate local admin and service credentials used on that host. Do not reboot or reimage before memory capture and DLL identification.
Frame it in writing: 'We are choosing between a controlled interruption now and an uncontrolled one later.' If leadership still declines, require a documented, time-boxed risk acceptance with a 24-hour review, not an open-ended Saturday window.
3. What detection and architecture changes would stop this class of ambiguity from recurring?
Read the worked answer
Three layers. First, make the allowlist enforcing and alerting: any VLAN 40 egress attempt to a non-allowlisted destination should generate a ticket, not a log line. That single control converts this entire investigation into a five-minute lookup.
Second, add process context to TLS detection. A JA3 match alone should never page anyone; alert on JA3 plus an unsigned or anomalously parented process plus a non-allowlisted destination. Pair it with simple beacon-periodicity analytics on the OT segment, tolerant of jitter, because fixed-interval low-volume flows are the durable signature regardless of tooling.
Third, reduce the pivot surface. The jump host should not have direct internet egress at all; integrator access should arrive through a gateway with MFA and session recording, with accounts created per engagement and expiring automatically. Require change tickets for service installation on OT-adjacent hosts and alert on rundll32 or regsvr32 parented by services.exe. Finally, extend EDR retention on the OT segment - a four-day-old process event should be reconstructable from telemetry, not inferred from a single alert.