Signed, Sealed, Compromised: A Supply-Chain Installer at a Logistics Firm
Northline Freight runs 6,200 Windows 11 endpoints and a three-person security team. Software updates are pushed through SCCM, and the endpoint protection platform (EPP) is configured to trust binaries signed by approved publishers. Last Tuesday, a remote-monitoring agent received a routine update. The installer was validly signed; the certificate chain resolved to a subsidiary of the vendor and was not revoked. Within 36 hours, fourteen hosts began making outbound TLS connections to a newly registered autonomous system, and helpdesk saw slow logons on six of them. No antivirus signature fired. The EPP console shows the installer's child process spawning a signed Windows utility that writes a service and deletes its own installation files. The vendor says the update was legitimate, but cannot explain the network traffic. Operations refuses to block the agent because it supports 900 warehouse scanners.
1. Explain why the publisher-trust and signature-based controls failed here, and identify two behavioral detection opportunities that would not depend on file reputation. Show your reasoning, including what each detection would and would not catch.
Read the worked answer
Publisher trust is transitive: the EPP asked whether the binary was signed by an approved publisher, and the answer was yes. A signature proves origin and integrity since signing; it says nothing about intent. Because the update arrived through SCCM and had a valid chain, application control in audit mode and reputation lookups also had no reason to flag it.
Two behavioral opportunities:
Service creation by an installer that then removes its own files. Detect a newly created service whose binary path sits outside standard program directories and whose parent installer exits within minutes. This catches signed and unsigned loaders, but misses fileless persistence that never creates a service.
Rare parent-child plus first-seen egress. Detect a signed system utility spawned by an installer and making outbound TLS to an ASN with no prior presence in the estate. Baseline by process signer and destination reputation. This catches the call-home, but misses a loader that reuses an approved destination or waits before beaconing.
Neither rule is sufficient alone. Both can start in audit mode and be tuned by signer and destination rarity before blocking.
2. At hour 36 you have 14 suspect hosts, 900 scanners depending on the agent, and no confirmed malware family. Set out your containment and scoping sequence for the next 24 hours, with priorities and explicit decision points.
Read the worked answer
Priority is to stop spread and preserve scoping ability, not to clean immediately.
Hours 0-2: network-contain the 14 hosts through the EPP rather than shutting them down. Containment preserves memory and disk; shutdown loses volatile evidence. Do not block the agent estate-wide, because that disables 900 scanners. Freeze the update channel at SCCM and vendor level instead.
Hours 2-4: confirm the common denominator. Pull the installer hash, signer, and SCCM package ID. Check whether the package was deployed beyond the 14 hosts. Query EDR for all executions of the hash and all connections to the ASN over 30 days. If the package reached other systems, expand the suspect list before containing them.
Hours 4-8: determine persistence on two representative hosts. Collect service registry keys, scheduled tasks, and autoruns. If a malicious service is confirmed, contain every host carrying it, not only those with network traffic.
Decision point: if the vendor confirms a compromised build pipeline, treat every host that received the update as compromised. If the installer is clean elsewhere and traffic is limited to 14, contain those and monitor.
Reset credentials used on the 14 hosts, starting with local admin and service accounts. Do not reimage before capturing the service binary and network indicators.