Signed Backup Agent and LSASS Access on Payment Servers
EDR alerts on three application servers at 01:30 during an approved maintenance window: 'LSASS memory access by signed process.' The process path is C:\Program Files\VendorBackup\vbagent.exe, signed by a valid certificate, and the same binary ran on 40 other servers without alerting. The detection rule is a community Sigma rule with a 35% false-positive rate in your estate because the backup agent accesses LSASS for VSS. The vendor's support portal states the agent does not read LSASS memory. The servers host a payment reconciliation application, and change freeze starts at 06:00. The EDR console shows the process was launched by a scheduled task created 20 minutes earlier, not the normal service account. The SOC has packet capture only at the firewall, not east-west.
1. Is this a true positive, false positive, or undetermined? What is your reasoning?
Read the worked answer
Treat this as undetermined but leaning true positive. The signed binary and the 40 other non-alerting servers matter, but signatures prove publisher identity, not benign behavior. The strongest anomaly is the scheduled task created 20 minutes before execution, outside the normal service account context. A legitimate backup agent should be launched by its service or scheduler, not a newly created task. The vendor's statement that the agent does not read LSASS memory conflicts with the alert and must be resolved with the vendor and the binary hash, not assumed. Check the task XML for creator, run level, command line, and whether it calls comsvcs.dll or a renamed procdump. Check the EDR access mask and whether the process opened LSASS with read rights. Because the servers host payment reconciliation, escalate to incident response and preserve memory and task files before the 06:00 change freeze. Do not suppress on the path alone; that would hide the exact behavior you need to detect.
2. What validation steps would you take before suppressing or escalating, given the change freeze?
Read the worked answer
Before suppressing or escalating, validate at three levels. Host: collect the scheduled task XML, process tree, command line, hash, signer, parent process, and EDR access telemetry from all three servers; compare with the 40 hosts where no alert fired. Identity: identify who or what created the task and whether the account is approved for maintenance. Vendor: obtain a written confirmation and hash comparison from the vendor, not a portal FAQ. Network: firewall capture will not show east-west LSASS access, so rely on EDR and host logs; if the host has packet capture, collect it. Given the change freeze and payment application, escalate and isolate the three servers from each other and from the payment network if the behavior is confirmed or cannot be explained within the window. If the vendor confirms the exact binary and task pattern as a known maintenance action, treat it as a false positive but keep monitoring until the change freeze ends.
3. How would you tune the rule without losing detection coverage?
Read the worked answer
Tune by context, not by filename. Add conditions that require the LSASS access to come from a non-approved parent, a newly created scheduled task, an unexpected user context, or a hash outside the vendor allowlist. Keep the original rule active in monitor-only mode for the backup servers for a defined period, such as 14 days, and alert on any deviation from the approved task XML. Do not globally exclude C:\Program Files\VendorBackup\ because an attacker can write there or rename a binary. Test the revised rule with a benign backup run and a controlled LSASS-access simulation, and record results. If the vendor cannot explain the behavior, do not tune at all; convert the rule to high severity and add a hunting query for new scheduled tasks on payment servers.