A Suspicious Scheduled Task Before Peak Season
A national retailer with 6,000 endpoints across 400 stores has EDR and a SIEM, but only 30 days of EDR retention and no network flow data from stores. An alert shows a scheduled task named 'GoogleUpdateTaskMachineUA' created on a point-of-sale server by cmd.exe running an encoded PowerShell command. The EDR vendor's threat-intel team says the task name is used by a ransomware affiliate that also uses Rclone for exfiltration. The SOC has contained the server but not the store network. The IR lead wants to hunt enterprise-wide before deciding on isolation. PCI scope includes the POS environment; the business is entering peak season and store downtime is costly. The CISO asks for a hunt plan by 08:00 and a recommendation on isolation.
1. Formulate the hunt hypotheses and identify the minimum data sources needed.
Read the worked answer
Hypotheses: (1) the same scheduled-task name or creation pattern exists on other POS servers; (2) encoded PowerShell with the same command-line fragment or parent-child relationship appears elsewhere; (3) Rclone, archiving, or large outbound transfers occurred from POS or store systems; (4) the actor moved laterally over SMB from the contained server; and (5) persistence was established through scheduled tasks or services beyond the one host. The first three are directly testable with existing EDR and SIEM data; lateral movement is harder without network flow.
Minimum sources: EDR process-creation and scheduled-task telemetry, PowerShell script-block logging (event 4104) if enabled, file-creation events, and SIEM authentication logs. With 30-day EDR retention, prioritise the POS subnet and the 14 days around the alert; do not start with an unfocused 400-store sweep. Define success criteria before hunting: a confirmed second host, a matching command line, or a Rclone execution. If none is found, that is a bounded negative, not proof of cleanliness. Document query logic so the hunt is repeatable.
2. Should you isolate the store network now? Provide a decision framework.
Read the worked answer
Do not treat isolation as a binary all-or-nothing decision. The contained server should stay contained with EDR network isolation and blocked C2. For the store network, set thresholds: isolate the POS VLAN at a store if a second host shows the same task, if outbound C2 or Rclone traffic is observed, or if encryption canaries trigger. If the evidence is limited to one server, maintain enhanced monitoring and credential resets while preserving business operations. Consider PCI obligations and customer risk, but also the cost of peak-season downtime.
Before any isolation, preserve volatile evidence where feasible: memory, process list, scheduled-task XML, and EDR triage package. Coordinate with the business and legal; a store outage may itself create safety or contractual issues. Use staged containment: block known C2, restrict SMB between POS and developer networks, enforce least privilege, and rotate credentials. Reassess every two hours with the IR lead and SOC. The recommendation should state the thresholds explicitly so the decision is auditable rather than reactive.
3. How would you measure hunt success and feed results back into detection?
Read the worked answer
Measure coverage and decision value: percentage of in-scope POS hosts queried, percentage of relevant event types available, number of hypotheses tested, confirmed true positives, and time from alert to hunt conclusion. Track whether the hunt reduced uncertainty - for example, by excluding lateral movement across 380 stores - not just whether malware was found. Record data gaps such as missing network flow and 30-day retention; these are findings for the CISO. If a second host is found, measure containment time and scope accuracy.
Feed results back into detection engineering: convert the scheduled-task and encoded-PowerShell patterns into Sigma rules with the observed false-positive context; add Rclone and archive-creation detections; update the EDR watchlist with the task name but avoid over-blocking legitimate Google updater tasks. Send a sanitised summary to the intel team and, if appropriate, the sector ISAC. Hold an after-action review within five days and assign owners for retention, network visibility, and POS segmentation improvements. The hunt is successful if it changes a decision or a detection, even when it finds nothing.