How to Detect Interactive Logons by Service Accounts

A service account that signs in at a console or over Remote Desktop is almost never a service doing its job: it is a person, or an attacker, using a password that was meant only for software. Service accounts usually hold broad rights, rarely have MFA and often have passwords that have not changed in years, so interactive use is one of the cleanest identity signals a SOC can alert on. This guide shows how to build the list of service accounts to watch, which Windows and Entra ID events show interactive use, how to write and tune the rules, how to triage a hit and how to stop it happening with user rights assignments. It is for SOC analysts, detection engineers and Active Directory administrators. Logon types in general are explained in the Windows Logon Types and Authentication Events guide; this page is the focused detection runbook.

Key takeaways

Service accounts should only show network, batch or service logons: Microsoft's own hunting query treats an account with only logon types 3, 4 or 5 as a service account. Types 2, 7, 10, 11, 12 and 13 on such an account are the alert.
The list of accounts is the hard part: the rule is simple once you know which accounts are service accounts. Build the list from naming, SPNs, managed account types and observed behaviour, and keep it current.
Failures matter too: once you deny interactive rights, an attempt produces event 4625 with status 0xC000015B, "the user has not been granted the requested logon type", which is a high-confidence alert in itself.
Prevention is two user rights: Microsoft's countermeasure is to assign "Deny log on through Remote Desktop Services" to all service accounts; add "Deny log on locally" where the service does not need it.
Entra ID has the same problem: Microsoft recommends against using Entra user accounts as service accounts. Where they exist, any interactive sign-in in the sign-in logs deserves the same alert.

When you need this

Shared passwords: administrators who know a service account password and use it to "just fix something" on a server create exactly the activity an attacker hides behind.
After a credential exposure: service account passwords recovered by Kerberoasting or from scripts are used interactively for discovery and lateral movement. See the Kerberoasting and AS-REP Roasting Defence Guide.
Service account credentials on personal or user devices: the Okta support system breach began with a service account's credentials saved in an employee's personal browser profile. A sign-in by that account from a laptop is the signal. See the Okta Support System Breach 2023.
Before locking accounts down: a few weeks of detection output shows which service accounts are genuinely used interactively, so the deny rights do not break production.

Before you start

Item	Source	Fields you need
Successful logon	Windows Security log event 4624 (audit subcategory Audit Logon) on member servers, workstations and domain controllers; Sentinel `SecurityEvent`	Logon Type, New Logon Account Name and Security ID, Workstation Name, Source Network Address, Logon Process, Authentication Package, Elevated Token, Virtual Account
Failed logon	Event 4625	Status and Sub Status, especially 0xC000015B, 0xC0000070, 0xC000006A
Endpoint logon telemetry	Defender for Endpoint `DeviceLogonEvents`	LogonType (Interactive, RemoteInteractive, Network, Batch, Service and cached variants), AccountName, AccountSid, RemoteIP, RemoteDeviceName, IsLocalAdmin
Cloud sign-ins	Entra ID interactive sign-in logs (`SigninLogs`) and non-interactive user sign-ins	UserPrincipalName, AppDisplayName, IPAddress, DeviceDetail, ConditionalAccessStatus
Service account list	Active Directory, your inventory or CMDB, a SIEM watchlist	sAMAccountName, SID, UPN, owner, servers where it should run

Audit policy: confirm Audit Logon success and failure is enabled on every server class, not only domain controllers. Domain controllers see Kerberos authentication, but the logon type is recorded on the machine where the session starts.
Coverage gap: Microsoft notes that DeviceLogonEvents is not collected from Windows 7 or Windows Server 2008 R2 devices. Use Security log forwarding there.
Test: with a test service account, start a service (type 5), run a scheduled task (type 4), map a share (type 3) and then sign in over RDP (type 10). Confirm each arrives in the SIEM with the logon type you expect.

Step 1: build the service account list

Use several sources and record which one found each account, because no single method is complete.

Method	Finds	Misses
Naming convention (Microsoft suggests a prefix such as `svc-` and an owner in the description)	Accounts created under the convention	Older accounts and those named after people or applications
Accounts with a servicePrincipalName	Accounts used for Kerberos services such as SQL Server and IIS	Accounts used only for batch jobs or scripts
Managed account object types (gMSA, sMSA)	Managed service accounts; their logons show Virtual Account = Yes	Ordinary user accounts used as services
Behaviour: accounts seen only in logon types 3, 4 and 5 over 30 days	Undocumented service accounts	Accounts already misused interactively during the baseline
Service and task configuration on servers (the account each Windows service or scheduled task runs as)	The exact host-to-account mapping	Application-level credentials in config files

Store the result as a watchlist with account SID, name, owner and the hosts where the account is expected. Matching on SID rather than name survives renames. For a fuller inventory method, see the How to build a service account inventory from Active Directory guide.

Step 2: write the detection rules

Rule	Logic	Priority (ours)
Interactive or RDP logon by a service account	4624 with Logon Type 2, 10, 11 or 12 (or DeviceLogonEvents LogonType Interactive, RemoteInteractive or the cached variants) where the account is on the watchlist	High
Unlock by a service account	Logon Type 7 or 13 for a watchlist account	High (a service account should never have a desktop to unlock)
Denied logon type	4625 with status or sub status 0xC000015B for a watchlist account	High once deny rights are deployed
Logon from an unauthorised workstation	4625 with 0xC0000070 for a watchlist account restricted with "Log On To"	High
Service account on an unexpected host	Type 3, 4 or 5 logon on a host not in the account's expected host list	Medium
Bad password runs	Several 4625 events with 0xC000006A for a watchlist account; Microsoft recommends monitoring all 4625 events for service accounts	Medium (guessing, or a stale stored password)
Remote PowerShell by a service account	PowerShell commands whose parent is `wsmprovhost.exe` run by an account with no interactive history, as in Microsoft's published hunting query	Medium
Cloud interactive sign-in	Any interactive sign-in in Entra ID for a user account flagged as a service account, especially to the Azure portal, Microsoft 365 web apps or from a new IP	High
Privileged mismatch	Type 4 or 5 logon by a member of a domain administrative group, which Microsoft lists as a logon type mismatch to monitor	High (fix the account, not the alert)

A starting query for Sentinel with Windows Security events, assuming a watchlist named ServiceAccounts with a Sid column:

let svc = _GetWatchlist('ServiceAccounts') | project Sid = tostring(Sid);
SecurityEvent
| where EventID == 4624
| where LogonType in (2, 7, 10, 11, 12, 13)
| where TargetUserSid in (svc)
| project TimeGenerated, Computer, TargetUserName, LogonType, IpAddress, WorkstationName,
    AuthenticationPackageName, ElevatedToken

The Defender for Endpoint version filters DeviceLogonEvents on ActionType == "LogonSuccess" and LogonType in ("Interactive", "RemoteInteractive", "CachedInteractive", "Unlock", "CachedRemoteInteractive", "CachedUnlock"), the set used in Microsoft's hunting query. Confirm column names and values in your own workspace before enabling: SIEM schemas and connectors differ.

Step 3: tune before you page anyone

Run in report mode for two to four weeks and label every hit: genuine misuse, known administrative practice, or a mis-classified account.
Remove mis-classified accounts from the watchlist only after confirming with the owner that the account is used by a person. If it is, it is not a service account and should be converted to a named account.
Do not exclude by host. Excluding "the jump server" hides the exact place an attacker would use the account. Exclude specific account and host pairs with an expiry date and a ticket reference instead.
Raise severity for privileged accounts: combine with Elevated Token = Yes, IsLocalAdmin = true or membership of administrative groups.
Route alerts to the account owner as well as the SOC so every hit produces either a fix or an explanation.

Triage a hit

Who was at the keyboard? Find the source address and workstation, then the named user signed in on that source at the same time. A service account RDP session from an administrator's workstation is usually a shared password; from an unknown host it is an incident.
What did the session do? Process creation (4688 or DeviceProcessEvents) for the logon ID, new services or scheduled tasks, use of explicit credentials (4648) to reach other hosts.
Is the password known to too many people? Check the vault or password manager access log for who retrieved the credential recently.
Is it wider? Search the same account for any logon type on hosts outside its expected list, and the same source for other service accounts.

Respond and contain

Preserve: export the logon events, process events and session details for the logon ID before changes.
End the session on the host and, if misuse is confirmed or unclear, reset the account password and update every service that uses it in a planned sequence. See the Service Account Password Rotation Runbook Guide.
Apply the deny rights (below) to the account so the same route fails next time and produces 0xC000015B.
Hunt for persistence created by the session: services, tasks, new local administrators and changes to the account's own group memberships.
Rollback: if a deny right breaks a legitimate dependency, remove the account from that one GPO, record the exception with an owner and expiry, and keep the detection rule enabled for it.

Lock it down

Control	Setting	Effect	Caution
Deny log on through Remote Desktop Services	`SeDenyRemoteInteractiveLogonRight`, Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment	Blocks RDP logons; Microsoft's stated countermeasure is to assign it to all service accounts	Supersedes the matching Allow right
Deny log on locally	`SeDenyInteractiveLogonRight`, same path	Blocks console logons	Never apply to Everyone; test with the Allow log on locally setting; a few components need local logon
Log On To (workstation restriction)	Account property in Active Directory	Limits the computers the account can authenticate to; violations log 0xC0000070	Must list every host the service runs on
Group managed service account	gMSA with automatic password management	No human knows the password, so interactive misuse needs host compromise	Application must support it. See How to convert AD service accounts to gMSA
Entra workload identities	Managed identity or service principal with a certificate	No interactive sign-in path at all	Requires application change

Rollout: create a "Service accounts: deny interactive" group, link a GPO with both deny rights to a pilot OU of servers, add accounts that showed no interactive use during tuning, then widen by server tier. Changes apply at the account's next logon, with no restart.
Small organisations: a single GPO with both deny rights and a watchlist of fewer than a hundred accounts is enough; review it quarterly.
Large organisations: drive group membership from the inventory so new service accounts are denied by default, and track exceptions with expiry dates.

Verify it worked

Positive test: from a test host, attempt an RDP session with a test account on the watchlist before the deny rights apply. The Interactive or RDP rule should fire with the source address and logon type 10.
Blocked test: repeat after the GPO applies. The session must fail, and 4625 with 0xC000015B must arrive in the SIEM and raise the denied logon type alert.
Service still runs: restart the services and scheduled tasks that use the account and confirm type 5 and type 4 logons still succeed, so the lockdown has not broken production.
Cloud test: sign in interactively with a test Entra account tagged as a service account and confirm the cloud rule fires; then confirm a Conditional Access policy or account change blocks the next attempt if you chose to block.
Regression: keep these tests as a scheduled check, so a change to audit policy, log forwarding or the watchlist that silently breaks detection is caught.

Measures that show it is working

Interactive logons by watchlist accounts per month, trending to zero.
Percentage of service accounts covered by both deny rights.
Percentage of service accounts that are gMSA, managed identity or service principal rather than user accounts.
Service accounts found by behaviour that were missing from the inventory.
Median time from alert to owner response.

Common failure patterns

Watching names, not SIDs: renamed accounts drop out of the rule.
Logging only on domain controllers: the logon type is recorded on the target host; without member server logs you see authentication but not the RDP session.
Accepting "we always RDP as the service account": this is the practice to remove, not to exclude.
Deny rights without detection: blocked attempts (0xC000015B) are evidence of someone holding the password and should be alerted, not just prevented.
Forgetting the cloud side: on-premises rules miss an Entra user account used as a service account signing in to the portal.

Framework mapping

Framework	Reference	How this supports it
MITRE ATT&CK v20	T1078.002 Domain Accounts; T1078.003 Local Accounts; T1021.001 Remote Desktop Protocol	Detects valid service account credentials used for access and lateral movement
NIST SP 800-53 Rev 5	AC-2(11) Usage Conditions; AC-2(12) Account Monitoring for Atypical Usage; AC-6 Least Privilege; AU-6 Audit Record Review, Analysis, and Reporting	Restricts how service accounts may be used and monitors deviations
NIST CSF 2.0	PR.AA-01; PR.AA-05; DE.CM-03	Managed non-human identities, enforced permissions, activity monitoring

Practitioner checklist

Enable Audit Logon success and failure on all servers and forward 4624 and 4625.
Build a service account watchlist by SID from naming, SPNs, managed types, behaviour and service configuration.
Alert on logon types 2, 7, 10, 11, 12 and 13 for watchlist accounts.
Alert on 4625 with 0xC000015B and 0xC0000070 for watchlist accounts.
Add Entra interactive sign-ins by user-based service accounts.
Tune in report mode with owners, then page on High rules.
Assign Deny log on through Remote Desktop Services and Deny log on locally through a pilot-first GPO.
Move accounts to gMSA, managed identities or service principals where possible.

How to detect interactive logons by service accounts: Windows events, rules and lockdown steps