Auditing the Windows Secondary Logon Service: the seclogon RunAs surface attackers quietly abuse

Nearly every Windows admin has used runas /user:administrator cmd or shift-right-clicked "Run as a different user." Both rely on the Secondary Logon service (seclogon), a small, almost-forgotten component that lets a process spawn a child under a different set of credentials without the user logging off. It is convenient, it is enabled by default, and it is a surface that attackers understand far better than most defenders do. This post walks through what seclogon actually does, why it shows up in real intrusions, and exactly what to audit on each endpoint.

What the service actually does

Seclogon exposes an RPC interface that performs an interactive-style logon on behalf of a caller and launches a process with the resulting token. When you run a tool "as administrator (other user)," your original process hands the target username and password to seclogon, which calls LogonUser under the hood and returns a fresh process running in a new logon session. The key properties that matter for security:

• It runs as LocalSystem and brokers token creation for other callers — a classic high-value privilege boundary.
• It accepts cleartext credentials at call time, which means those secrets transit through LSASS and live briefly in memory.
• It is reachable programmatically, not just from the GUI, via the CreateProcessWithLogonW API.

Why attackers care

Seclogon has shown up repeatedly in offensive tradecraft, in three distinct ways.

1. Local privilege escalation via the service itself

Because seclogon runs as SYSTEM and handles handles/tokens on behalf of lower-privileged callers, flaws in its handle management have produced real escalation bugs over the years (for example the UAC/seclogon race conditions and leaked-handle primitives that let a standard user duplicate a SYSTEM token). The lesson is not any single CVE — it is that a SYSTEM service brokering token creation is exactly the kind of component you want patched and monitored.

2. A built-in credential-prompt and RunAs primitive

Red teams use CreateProcessWithLogonW to run payloads under stolen credentials without touching LogonUser directly, and to spawn processes in a way that can look like legitimate admin activity. If you have a cleartext password or a cracked hash's plaintext, seclogon turns it into an interactive process on the box.

3. Credential exposure in memory

Every RunAs invocation pushes a plaintext password through the logon pipeline. On hosts where WDigest is still enabled or Credential Guard is off, those secrets become loot for an LSASS dump. Seclogon usage is therefore a signal: frequent RunAs activity on a server is both an operational smell and an attacker opportunity.

What to audit on every endpoint

A good seclogon posture is less about ripping the service out and more about knowing its state and watching how it is used. Concretely:

1. Service state. Confirm whether seclogon is running and its start type. Many locked-down server builds set it to Disabled because interactive RunAs has no business on a headless box.
2. Who is allowed to use it. The privilege "Replace a process level token" and local admin membership govern who can meaningfully abuse secondary logon. Audit both.
3. Logon telemetry. Ensure Logon/Logoff auditing is on so RunAs generates Event ID 4624 with Logon Type 2 (interactive) or 9 (NewCredentials) and a 4648 ("logon using explicit credentials"). Those 4648 events are the single best indicator of RunAs and CreateProcessWithLogonW use.
4. Downstream credential hygiene. Seclogon is only dangerous as a credential source if those credentials are recoverable — so verify WDigest is disabled and LSASS protections (RunAsPPL, Credential Guard where supported) are in place.

Here is a quick local triage you can run or roll into a baseline:

Get-Service seclogon | Select-Object Status, StartType

# Is RunAs being used? 4648 = explicit-credential logon
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4648} -MaxEvents 20 |
  Select-Object TimeCreated, @{n='Target';e={$_.Properties[5].Value}}

# WDigest plaintext guard (want: UseLogonCredential = 0 or absent)
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' `
  -Name UseLogonCredential -ErrorAction SilentlyContinue

Should you disable it?

On servers and kiosk-style endpoints where no one legitimately runs tools as a different interactive user, disabling the Secondary Logon service removes the RunAs and CreateProcessWithLogonW path entirely — a clean attack-surface reduction. On admin workstations where RunAs is part of the workflow, leave it enabled but monitor 4648 activity and lock down credential recoverability instead. There is no one-size answer; the point is to make the decision deliberately per machine role rather than leaving a SYSTEM broker on by inertia.

Where WinSentinel fits

WinSentinel is free and gives you full power on a single machine — all 64 audit modules, no limits. Its service-posture and credential-exposure checks flag seclogon's start type, surface whether WDigest plaintext caching and LSASS protections are configured, and correlate RunAs/explicit-credential logon activity so you can see the surface instead of guessing at it. Every finding maps to a concrete remediation and a score delta, so "is seclogon handled correctly on this box?" becomes a yes/no answer rather than a research project.

For organizations running many Windows machines, WinSentinel Pro adds fleet orchestration on top: a central node, agent management, compliance rollups, and drift alerts — so if a server that had seclogon disabled suddenly has it running again, you find out from a drift alert instead of the next incident. The single-machine checks are the same; Pro is about seeing them across the whole estate and catching regressions before they matter.

Seclogon is a tiny service with a big blast radius: it runs as SYSTEM, brokers token creation, and traffics in cleartext passwords. Audit its state, watch Event ID 4648, and harden what makes its credentials recoverable.