The Signed Binary That Beacons
During a hypothesis-driven hunt, an analyst finds a scheduled task named 'Adobe Updater' on 12 workstations in the finance department. The task runs every 300 seconds with 20% jitter and launches a signed executable from a vendor certificate, but the binary resides in C:\ProgramData\Adobe\Updater\ and has a different hash than the approved version. DNS queries resolve a domain registered nine days ago through a privacy registrar. Proxy logs show HTTPS beaconing with fixed-size uploads. The sandbox is unavailable for two days, and the team's VirusTotal API quota allows 10 lookups per day. EDR shows the parent process as svchost.exe, which is unusual for this task. The hunt hypothesis was 'adversary persistence via scheduled tasks on finance endpoints.' The SOC has a four-hour containment SLA for confirmed malware.
1. Walk through the analysis steps to determine whether this is a true positive. What evidence carries the most weight, and what would you not rely on?
Read the worked answer
The analyst should build a timeline and compare behavior across the 12 hosts: task creation time and author, XML definition, execution interval, binary path, file creation time, signer chain and revocation status, hash prevalence in the software inventory, parent process, user context, and network destinations. The strongest evidence is the combination of an unusual parent process, a non-standard binary path, a hash mismatch against the approved version, periodic beaconing with jitter, fixed-size uploads, and a domain registered only nine days earlier. Each item alone is weak; together they form a coherent persistence and command-and-control pattern.
A valid signature is not proof of safety. Signed malware, stolen certificates, and abused update mechanisms exist, so the analyst should verify the certificate chain and whether the signing identity matches the expected vendor product, then check whether the file is revoked or unknown to the software inventory. VirusTotal absence or a low detection count should not be treated as exculpatory, especially with a 10-lookup daily quota and a two-day sandbox outage. The team should use internal evidence first: proxy JA3 or TLS metadata if available, DNS history, authentication events, and EDR process trees. Because the SLA is four hours, the decision should not wait for the sandbox. If the behavioral chain holds, escalate as a probable incident, isolate the 12 hosts, preserve volatile and disk evidence, block the domain, and reset credentials used on those systems.
2. How should the team capture knowledge from this hunt regardless of outcome, and which ATT&CK mappings and detection changes follow?
Read the worked answer
The knowledge phase should record the hypothesis, query logic, data sources, time window, findings, confidence, analyst decisions, and gaps. If the case is confirmed, the mapping should include T1053.005 for scheduled task persistence, T1071.001 for web-protocol command and control, T1027 for obfuscation or encoded content if present, T1583.001 for acquired infrastructure, and possibly T1553.002 for code-signing abuse. If it is a false positive, the record should explain why a legitimate vendor updater used an unusual path and hash, and the allowlist or tuning change should be documented so the same hunt is not repeated blindly.
Detection engineering should convert the behavior into rules: scheduled task creation with suspicious parent processes, binaries running from ProgramData with update-like names, domains younger than 30 days, beacon periodicity with jitter, and fixed-size upload patterns. The rules must be tested against known benign Adobe updater behavior to avoid a flood of false positives. The hunt library should include a reusable query and a decision tree for signed-binary abuse. Measurement should capture time to detect, time to escalate, and false-positive rate. The reasoning is that a hunt's value is not only the incident it finds; it is the durable detection and knowledge that reduce future dwell time. A null result with a documented gap is still an improvement input.
3. At hour four, the sandbox is still unavailable. What escalation and containment decision would you make, and how would you communicate uncertainty?
Read the worked answer
At hour four, the decision should be based on the weight of internal evidence and the risk of waiting. The combination of scheduled task persistence, unusual parent process, hash mismatch, young domain, and periodic beaconing is sufficient for a probable-malware escalation under the four-hour SLA. Waiting for the sandbox would extend attacker dwell time on 12 finance workstations and risk credential theft or lateral movement. The appropriate action is to isolate the 12 hosts through EDR or network containment, preserve memory and disk evidence before or during isolation where operationally possible, block the domain at DNS and proxy, and initiate credential resets for accounts that logged on to those hosts.
Communication should state confidence plainly: 'probable malicious persistence and command and control, based on behavioral evidence; sandbox confirmation pending.' The incident lead should distinguish confirmed facts from inferences and note the missing logs and sandbox gap. If later analysis shows a false positive, the team should document why the behavioral threshold was met and whether the threshold needs tuning. The judgment is that containment is reversible and evidence-preserving, while delay is not. The team should not overclaim 'confirmed malware' without sandbox or reverse-engineering evidence, but it also should not let an unavailable tool override a risk-based SLA.