Audit-Mode Endpoints, a Low-Prevalence Beacon, and a Latency-Sensitive Server Farm

Immediate containment decision: Audit mode gives you telemetry but no blocking, so treat this as containment-by-indicator, not containment-by-policy.

1. Validate the binary before acting. Compare the file's SHA-256 to the legitimate vendor updater; check signature validity and, critically, whether the same hash appears on the 3 desktops. A legitimate updater running on 14 servers is a benign explanation; a re-signed or side-loaded copy is not. Submit for file analysis/reputation and check prevalence across the fleet.
2. Block by indicator, not by policy. Create a custom detection / IOC entry on the hash and the C2 domain in the existing policy. IOCs enforce regardless of Audit/Protect mode, so the servers get blocking without enabling file scanning on every write - this is the key move that satisfies both security and the latency constraint.
3. Add compensating controls on the servers: application allow-listing (so only the updater path can execute from that directory), device control, and network egress restriction to the C2 domain at the firewall.
4. Negotiate a narrow Protect policy with scan exclusions for the trading application's data and binary paths, tested on one non-production server with latency measured. Offer it as data, not as a demand.

Audit-only stays for broad scanning; IOC enforcement, allow-listing and network controls close the gap.

Change: move network isolation from a change-ticket action to a pre-approved SOC playbook with defined authority, executed through Secure Endpoint isolation from the console. Four hours of dwell time for a confirmed beacon is the bigger risk by orders of magnitude.

Design the guardrails before granting the authority:

• Criteria: isolation is authorized only when a detection meets a written threshold (e.g. confirmed malicious hash, IOC hit, or C2 correlation in XDR) - not on a single low-confidence verdict.
• Selective isolation exceptions: isolation can be configured to still permit the management/SOC channel and specified business IPs, so the box is not stranded and remote support is not locked out.
• Break-glass: documented path for the business owner to request release, with a named approver and a post-incident review.
• Logging: every isolation is ticketed automatically with who/what/when, so auditability is preserved.

Risks and mitigations:

• Isolating a critical server and causing an outage - mitigate with the exception list and by starting with desktop-scope authority, expanding to servers after two weeks of review.
• Analyst error/misuse - mitigate with dual approval for servers only, and a weekly review of all isolations.
• Alert fatigue driving over-isolation - mitigate by tuning detections in the same window.

Scope the hunt by behavior and infrastructure, not by hostname.

Queries to run:

• Domain/DNS: all endpoints that resolved the rare domain, including those that never executed the binary - this finds staging and blocked attempts. Use DNS/Umbrella or the endpoint's DNS telemetry, not just the endpoint console.
• Hash and near-hash: the exact SHA-256 across the whole fleet (including macOS and Windows), plus the vendor's related files if the signer is abused.
• Process ancestry: the parent process that launched the binary - if it is a scheduled task, service, or a specific updater path, that ancestry is the real indicator.
• Network: outbound connections to the resolved IPs, JA3/TLS fingerprint, and beacon periodicity in flow data going back 90 days.
• Lateral indicators: authentication events from the 14 servers to other hosts (failed and successful), new service creation, and any credential access telemetry.

Data sources: Secure Endpoint file/process trajectory, XDR correlations, firewall/proxy flow logs, DNS logs, and Windows security event logs for the server OU.

Output: a scope statement - confirmed, suspected, and cleared host lists - plus the earliest observed timestamp, which determines whether this is a 3-day or 60-day incident and drives the containment and notification decision.