The Service Account That Started Logging In Interactively

The 71 may be both overstated and understated. Overstated because the peer group is contaminated: 18 of 40 service accounts regularly log on interactively, so interactive RDP is not rare in that cohort and the model may see it as normal for the group. Understated because comparing svc_bkp01 to other service accounts ignores its own 90-day history, in which it never made interactive logons; the account-specific baseline is the stronger signal. UEBA often blends peer and self-baseline, and a contaminated peer group can mask a real deviation. The migration also creates a legitimate change window, which can explain new behavior, but the change ticket says outbound API only, so the observed RDP contradicts the approved change. The contractor's vault checkout two days ago adds a potential misuse path. The analyst should not rely on the score alone: treat the account-specific anomaly, the ticket mismatch, and the vault checkout as a triad. Recalculate the score with a clean service-account cohort or with an account-only baseline to see the true deviation.

Triage in this order. Confirm the RDP logons from the account's authentication logs: source IP, workstation, time, and whether they succeeded. Compare with the vault checkout record: who checked out the password, for what ticket, and when it was returned. Contact the backup operator and contractor through the manager; ask whether the vendor validation was authorized and whether they used RDP. Check the four application servers and two admin workstations for new local admins, scheduled tasks, or service creation. Review the backup platform's API logs to see whether the agent actually needed RDP. If the contractor checked out the password outside the approved change window, treat it as potential credential misuse and disable the account, rotate the password, and isolate the source workstation. If the vendor confirms RDP validation and the change record was incomplete, still require a retroactive approval and check for unauthorized changes. The help-desk locked-account ticket may be a symptom of password misuse or a benign lockout; verify the caller. Do not close as benign until the ticket mismatch and vault checkout are explained.

Policy: service accounts should not be interactive; require a documented exception with a business owner, expiry, and a specific source-host allowlist. Change management: any new backup agent that uses RDP must be reviewed by security, and the change ticket must list protocols and accounts. Vault: require dual approval for service-account checkout and alert on checkout outside a change window. Detection: add a rule for interactive logons by service accounts, but score it with an account-specific baseline and a clean peer group; exclude known legacy accounts via a watchlist with expiry. Add a correlation rule for vault checkout followed by interactive logon by the same account within 24 hours. UEBA tuning: create separate cohorts for backup, database, and legacy automation service accounts; do not mix interactive legacy accounts with non-interactive ones. Validate by replaying 90 days of history and measuring false positives on the 18 legacy accounts. If the rule would flood, scope it to accounts with no interactive history in 90 days. Document the migration exception and review it after 30 days.