LSASS Alert on the Billing Cluster
At 02:14 on a Saturday, the EPP console raises a high-severity alert: a process on BILL-APP-03 accessed LSASS memory and was blocked. BILL-APP-03 is a Windows Server 2019 host running a licensed billing application used by 400 concurrent users in three time zones. Rebooting requires a four-hour maintenance window; the next one is 36 hours away. Ten minutes earlier, the same host logged a PowerShell command with an encoded argument launched under a service account that also runs the backup agent. A helpdesk ticket from Friday says the backup agent was updated. The on-shift analyst is six months into the role. A second alert shows the same service account authenticating to two file servers in the last hour. No data exfiltration alert has fired. The billing app has no vendor support contract for out-of-hours changes.
1. Walk through the first 30 minutes of triage. What do you verify, what do you decide, and what do you deliberately not do yet?
Read the worked answer
First establish whether this is credential access or a backup-agent false positive.
- Pull the process tree, command line, signer, and parent for the LSASS access. Backup agents commonly read LSASS; a procdump-style tool does not. Compare the signer and hash against the vendor's known binaries.
- Decode the PowerShell command. If it downloads or executes code, the service account is suspect regardless of the LSASS alert.
- Scope the service account: query authentication events across all servers for the last 24 hours, not only the two file servers. Check for new services, scheduled tasks, and remote process creation on those hosts.
- Preserve volatile data on BILL-APP-03: running processes, network connections, logon sessions, and a memory capture if policy allows.
Do not reboot, reimage, or stop the billing application yet. Do not reset the service account before understanding dependencies; the reset can break backups and destroy the logon-session evidence you need. Do not close the alert as a backup false positive until the encoded PowerShell is explained.
Escalate to the incident lead if the signer is not the backup vendor or if the account authenticated to hosts outside its baseline. The analyst's tenure is a reason to pair, not a reason to wait.
2. Assume the alert is confirmed malicious. Recommend a containment and credential strategy that respects the four-hour reboot constraint. Explain the trade-offs.
Read the worked answer
Network-contain BILL-APP-03 through the EPP, allowing only the billing application's required flows if selective isolation is available. That stops lateral movement while keeping users online. If selective isolation is not available, isolate fully and invoke business continuity; 400 users without billing is a business decision, not an analyst one.
Reset the service account password twice with a long random value and rotate it in the backup product. Existing Kerberos tickets survive a password reset, so purge the account's tickets or wait out the maximum ticket lifetime. Check whether the account had domain-wide rights.
Hunt persistence before the reboot: services, scheduled tasks, WMI subscriptions, and startup folders. A reboot may clear memory-resident code but leave persistence behind.
Collect memory and disk evidence before the maintenance window. The reboot is a deadline, not a reason to skip collection.
Trade-off: selective isolation may leave the attacker a path through allowed application ports. Document those flows and monitor them at the network layer. Full isolation is safer technically and costlier operationally; make that trade explicit.
3. What would change your assessment if the process were signed by the backup vendor?
Read the worked answer
A valid vendor signature raises the probability of a false positive but does not prove one. Signed malware and abused signed binaries exist.
I would verify the signature chain, file version, and hash against the vendor's published build, then check whether the LSASS access pattern matches the vendor's documented behavior. The encoded PowerShell is independent evidence: a legitimate backup update does not explain it.
I would downgrade the LSASS alert only if the binary is authentic, the behavior matches the vendor's documentation, and the PowerShell is explained by a known administrative task. Otherwise the investigation continues. The decision rests on the combination of indicators, not on the signer alone.