The differences between a local account, domain account, SYSTEM, and service identity

1. Core mechanism

A service identity is not a special account type

SCM logs on the account configured for the service and attaches the resulting access token to the service process. The process uses that token when it accesses local objects.

The configured identity may be a predefined account, a regular user account, a managed service account, or a virtual account. The phrase 'service account' alone identifies neither its authority nor its network behavior.

Code running in the process is bounded by the rights in its token; labeling the account as a service identity does not expand that boundary.

Separate the local token from the network identity

LocalSystem is highly privileged on the local host, but a remote resource does not see a forest-wide SYSTEM principal. It sees the computer account's credentials.

NetworkService also acts as the computer account on the network despite its lower local privilege. LocalService presents anonymous credentials. Local privilege alone does not determine network impact.

The remote resource establishes its own logon context and evaluates access against the rights it has granted to the presented principal.

State and data flow

1. The service configuration specifies the account under which the service runs.
2. SCM logs on that account and creates an access token.
3. The token is attached to the service process; local-resource requests are evaluated in that token’s SID/privilege context. The requested access still requires a separate resource decision.
4. When the service accesses a remote resource, the selected identity's network-credential behavior applies.
5. The remote host makes its own logon and access decisions for the presented principal.
6. Analysts correlate local and remote telemetry without losing account-authority or logon-context information.

2. Exploitation

Broken trust assumption

The broken assumption is that a service will perform only its intended application work and will not use the local or network authorizations given to its identity for other resources.

Technical prerequisites

• Permission to run code in the service process or change the service configuration.
• The token attached to the service process includes the rights required for the target local operation.
• For remote impact, the target resource has actually granted the required rights to the computer account or configured domain service account.

Exploitation mechanism

Code running with the service process token can access local resources and may reach remote resources using the identity's supported network credentials. LocalSystem does not confer forest-wide authorization: remote access remains bounded by the rights the target resource grants to the presented computer or domain principal.

High local privilege does not cross the network unchanged

Running code as LocalSystem is powerful on the target host, but a remote resource sees the computer account. If that account has not been granted access, the remote request is denied.

NetworkService can present the same computer identity on the network despite having fewer local privileges. The process owner alone therefore cannot define the impact boundary.

Domain-account impact depends on actual assignments

The impact of a domain service account depends on its memberships, user-right assignments, and relevant resource ACLs. The account's 'service' label creates no additional authorization.

Managed-account password handling is outside this lesson's mechanism. The focus here is how an identity is carried into process and network contexts.

3. Defense & Detection

Telemetry scope

• Audit Logon / Success auditing is required for 4624 service logon records.
• 4624 LogonType 5 shows the service logon launched by SCM; it is not an attack indicator by itself.
• For access to a remote resource, inspect the network-logon context on the remote host as well; the local Type 5 event does not prove remote access.
• Preserve the 4624 Version field; fields such as VirtualAccount, ElevatedToken, and TargetLinkedLogonId depend on Version 2.

Events and relevant fields

• 4624 / TargetUserSid, TargetUserName, TargetDomainName: the principal and authority context of the logon.
• 4624 / TargetLogonId: a correlation key for related events on the same host.
• 4624 / LogonType 5: service logon launched by Service Control Manager.
• 4624 / LogonProcessName, AuthenticationPackageName, ProcessId, ProcessName: context for how the logon was generated; interpret these fields against the event version and provider schema.
• 4624 / Version 2: adds VirtualAccount, ElevatedToken, and TargetLinkedLogonId; do not assume these fields exist in older versions.

Type 5 is context, not a verdict

4624 LogonType 5 reports that a service logon session was created. Normal boot and service restarts produce the same record, so the event alone does not prove malicious intent.

The event becomes useful when compared with the expected service-account-host inventory. TargetDomainName is especially important for distinguishing identical short account names.

Verify remote impact on the remote host

The Type 5 record on the service host identifies the service logon. Telemetry from the remote host shows which principal arrived and what access it received.

LocalSystem and NetworkService are expected to use the computer account on the network, while LocalService is expected to behave anonymously. Do not turn observed field values into a fixed allowlist until they have been verified in a lab on the supported operating-system build and with the relevant collector.

Detection logic · Sigma

title: Beklenmeyen servis logon kimligi
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
    LogonType: 5
  condition: selection
fields:
  - TargetUserSid
  - TargetUserName
  - TargetDomainName
  - TargetLogonId
  - LogonProcessName
  - AuthenticationPackageName
  - ProcessName
falsepositives:
  - Isletim sistemi acilisi ve beklenen servis yeniden baslatmalari
level: low

Query assumptions

• LogonType can be stored as number or text in the target backend; mapping should be verified.
• The rule selects all service logon records as a starting point; identifying unexpected accounts requires an inventory.
• Version 2 fields are not part of the selection condition, so older records must not be excluded.
• The rule was not run on a real SIEM or data set.

False positives

• Normal service startup during operating-system boot.
• Planned service restart, maintenance and failover operations.
• Expected service logons created by software installation or updates.

Hardening

• Choose the least-privileged local and network identity that each service requires; avoid LocalSystem and broadly authorized domain accounts unless necessary.
• Do not grant interactive logon rights to service identities; constrain user rights and resource ACLs to the intended workload.
• Inventory local and remote dependencies before changing an identity; pilot the change and prepare a rollback path.
• For workloads that require managed passwords, evaluate managed service account options with the product and compatibility considerations in 08.04.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" />
    <EventID>4624</EventID>
    <Version>2</Version>
    <Channel>Security</Channel>
    <Computer>APP01.besiktas.example</Computer>
  </System>
  <EventData>
    <Data Name="TargetUserSid">S-1-5-21-111111111-222222222-333333333-1201</Data>
    <Data Name="TargetUserName">svc-reader</Data>
    <Data Name="TargetDomainName">BESIKTAS</Data>
    <Data Name="TargetLogonId">0x456</Data>
    <Data Name="LogonType">5</Data>
    <Data Name="LogonProcessName">synthetic-example</Data>
    <Data Name="AuthenticationPackageName">synthetic-example</Data>
  </EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4624</EventID><Version>2</Version><Channel>Security</Channel><Computer>WS01</Computer></System>
  <EventData><Data Name="TargetUserSid">S-1-5-21-101010101-202020202-303030303-1001</Data><Data Name="TargetUserName">tunahan</Data><Data Name="TargetDomainName">WS01</Data><Data Name="TargetLogonId">0x7a31</Data><Data Name="LogonType">2</Data><Data Name="AuthenticationPackageName">Negotiate</Data><Data Name="WorkstationName">WS01</Data><Data Name="IpAddress">-</Data><Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data></EventData>
</Event>

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4624</EventID><Version>2</Version><Channel>Security</Channel><Computer>WS01.iyelabs.example</Computer></System>
  <EventData><Data Name="TargetUserSid">S-1-5-21-111111111-222222222-333333333-1105</Data><Data Name="TargetUserName">tunahan</Data><Data Name="TargetDomainName">IYELABS</Data><Data Name="TargetLogonId">0x8b42</Data><Data Name="LogonType">2</Data><Data Name="AuthenticationPackageName">Negotiate</Data><Data Name="WorkstationName">WS01</Data><Data Name="IpAddress">-</Data><Data Name="LogonGuid">{11111111-2222-3333-4444-555555555555}</Data></EventData>
</Event>

Two reality checks

Assumption: SYSTEM is the most powerful account throughout the domain or forest.

In fact: LocalSystem's broad privilege applies on the local computer. For network access it presents the computer account's credentials, and the remote resource applies only the rights actually granted to that principal.

Assumption: All services use the same 'service account' security context.

In fact: SCM can run each service under a configured user, managed, virtual, or predefined account. The local token and network behavior depend on the selected identity.

Sources

• Microsoft · Service User Accounts
  SCM logging on the configured account and attaching the token to the service process.
• Microsoft · LocalSystem Account
  Local privilege and computer identity behavior on the network.
• Microsoft · NetworkService Account
  Low local privilege and the computer account's network credentials.
• Microsoft · LocalService Account
  Low local privilege and anonymous network credential behavior.
• Microsoft · Access Tokens
  Access token contents; process/thread identity, SIDs, and privileges.
• Microsoft · 4624(S) An account was successfully logged on
  Event Description, Event Versions, logon types and Field Descriptions.
• Microsoft · Security identifiers
  How SIDs work; local and domain security authorities.
• Microsoft · Local accounts
  Introduction and “Local accounts”: how local accounts are defined on a device and how the local security context works.
• Microsoft · Security Principals
  “How security principals work”, “Security identifiers”, and “Access tokens”.
• Microsoft · Credentials Processes in Windows Authentication
  “Windows credentials authentication overview”: local SAM and domain/DC authentication paths.
• Microsoft · 4624(S): An account was successfully logged on
  Event Description, Version 2 XML, New Logon fields, and Account Domain behavior for local accounts.
• Microsoft · Windows LAPS overview
  Introduction and Benefits: unique per-device local-administrator passwords and rotation.