Service Account RDP Logon Outside Backup Window
A SIEM rule alerts when a single account produces at least ten 4625 failures followed by a 4624 success within five minutes. At 13:22, svc_backup triggers it: 14 failures against DC-02 from 10.20.30.44, then a successful 4624 type 10. The same account authenticates to 12 member servers every night between 01:00 and 01:20 with type 3 logons from BKP-01, which is the approved backup host. The SOC has 300 users and receives about 40 of these alerts per day, mostly from a password-expiry help-desk script. svc_backup is a domain account with local administrator rights on all member servers and a 24-character password stored in the backup product. The 10.20.30.44 address belongs to workstation WS-042, assigned to a help-desk technician. DC-02 is a domain controller. There is no EDR alert on WS-042 or DC-02.
1. Is this alert a true positive? What evidence would confirm or refute credential misuse?
Read the worked answer
It is likely a true positive for credential misuse, but it must be confirmed rather than assumed. The baseline is type 3 logons from BKP-01 during the 01:00-01:20 backup window. The 13:22 event is a type 10 RemoteInteractive logon from a help-desk workstation to a domain controller, outside the window and from an unapproved host. That combination is inconsistent with backup behavior.
Confirm by examining DC-02 Security logs for the 4624 event fields: logon type, source workstation, authentication package, and logon ID. Check for 4672 special privileges and 4648 explicit-credential use. Review 4768/4769 Kerberos events and 4688 or Sysmon process creation around the logon. On WS-042, check EDR for RDP client launches, scripts that read stored credentials, and the technician's activity at 13:22. Interview the technician and determine whether any help-desk automation legitimately uses svc_backup; if so, identify the script owner and host. If no approved use exists, treat the account as compromised.
2. What containment and remediation actions do you take for the account and the hosts?
Read the worked answer
Contain the account first: disable or rename svc_backup only after coordinating with the backup owner, because disabling it can break backups. Reset its password twice, invalidate existing sessions, and rotate the credential in the backup product. Remove unnecessary local administrator rights from the account and restrict logon rights to BKP-01 and the backup service account policy. Check for new service principal names, scheduled tasks, or group membership changes made by the account.
For DC-02, preserve Security and PowerShell logs, check for new accounts, admin group changes, and SID history modifications. For WS-042, isolate it, capture memory, and review EDR and RDP cache for what the technician did. Determine whether the technician's credentials were also exposed. If svc_backup was used interactively, assume the password was known to an attacker or exposed on WS-042; hunt for type 3 and type 10 logons from other hosts. Do not close the alert merely because the SOC sees many password-expiry alerts.
3. How do you tune the rule without hiding real credential attacks?
Read the worked answer
Do not suppress all svc_backup alerts. Suppress only the known-good combination: account svc_backup, source host BKP-01, logon type 3, and the 01:00-01:20 window. Keep alerting on type 2, 10, or 11 logons by service accounts, on any logon from a workstation, and on successful logons after failures outside the approved window. Add a separate rule for service accounts performing interactive or RDP logons, and a rule for a service account authenticating to a domain controller from a non-approved host. For the help-desk script noise, identify the script host and account, then allowlist that specific source and logon type rather than the whole account. Review the suppression monthly and require a ticket or change record. Test the tuned rule against the 13:22 event to confirm it still fires, and document the baseline so future analysts understand why the exception exists.