Service Account Logon from a Residential IP

This is a strong true positive. A service account with domain-wide backup rights logging on interactively from a residential ISP violates the documented service-account restriction and has no change ticket. The sequence - password spraying, successful logon, unsigned DLL load, then large outbound transfer - is consistent with credential compromise and data staging or exfiltration. To confirm, correlate authentication logs with the source IP, check whether 198.51.100.77 appears in any approved vendor or remote-access inventory, inspect the EDR process tree for the parent of rundll32.exe, and review proxy or firewall logs for the cloud bucket destination. Refuting evidence would be a documented vendor maintenance window, a matching approved change, or a confirmed backup application component with a signed DLL and known destination. None is present in the setup. The analyst should not wait for perfect proof before escalating, because 410 GB is already leaving. The reasoning is that the combination of policy violation, persistence-like DLL behavior, and ongoing egress shifts the burden of proof: the activity must be treated as malicious until the business owner and vendor disprove it.

Scope determination should start with the compromised account's privileges: domain-wide backup rights and 22 shares mean the attacker could read nearly anything the backup service can read. Pull authentication logs for svc_backup across all domain controllers for the past 30 days, not just the alert window, and look for other source IPs, times, and systems. Review file server audit logs for access to the 22 shares, especially bulk reads or archive creation. Inspect the cloud bucket logs if available to identify what was uploaded and whether the bucket is attacker-controlled. Check EDR for the unsigned DLL on other hosts and for lateral movement from FS-03. Difficulty comes from three factors: backup accounts often have broad read access, which makes impact assessment expansive; file access auditing may be incomplete, so absence of logs is not proof of no access; and the data may include contracts with different notification obligations. The analyst should document uncertainty explicitly and avoid concluding 'no evidence of access' when logging is absent. Scope is a probability statement, not a binary.

The first containment action should be to disable svc_backup and revoke its active sessions and tokens, then block the external destination at the firewall or proxy. This stops further authenticated access and egress with minimal disruption to the investigation. Isolating FS-03 through EDR network containment should follow quickly, because the unsigned DLL suggests code execution on that host. Preserving memory and logs before isolation is important, but not at the cost of allowing ongoing exfiltration. The tradeoff is tipping off the attacker: disabling the account may cause them to accelerate, delete logs, or switch accounts. However, 410 GB has already moved, and continued monitoring risks more loss. The analyst should also avoid immediately reimaging FS-03, because the host is evidence. A defensible sequence is: disable account, revoke sessions, block destination, isolate FS-03, preserve evidence, then hunt for additional compromised accounts. Document each action with timestamps. The reasoning is that containment should target the attacker's access paths in order of reversibility and impact, while preserving the ability to investigate.