Log Dejargonizer

Windows Security Log · Event 4672

Event 4672: Special privileges assigned to new logon

A session started with administrative rights. It fires immediately after the matching 4624 and is the cheapest way to answer the question that actually matters: who signed in with privilege, and where.

Also written as 4672Event ID 4672Admin logon 4672

What it means for you

On a personal computer

Your own account on a home PC is usually an administrator, so this fires whenever you sign in. It also fires constantly for Windows' own SYSTEM processes. On its own it is not a sign of anything wrong.

For an analyst

Filter out SYSTEM, LOCAL SERVICE, and NETWORK SERVICE and what remains is a clean feed of privileged human sign-ins. SeDebugPrivilege appearing for a non-administrative account is worth an immediate look — it is what credential dumping needs.

What it looks like

Sanitised. Addresses come from the RFC 5737 documentation ranges.

Sample
Special privileges assigned to new logon.

Subject:
  Security ID:    CORP\jbrooks-adm
  Account Name:   jbrooks-adm
  Account Domain: CORP
  Logon ID:       0x3E9A11

Privileges:
  SeSecurityPrivilege
  SeTakeOwnershipPrivilege
  SeLoadDriverPrivilege
  SeBackupPrivilege
  SeRestorePrivilege
  SeDebugPrivilege
  SeSystemEnvironmentPrivilege
  SeImpersonatePrivilege

The fields that decide it

Everything else in the log line is context.

SubjectUserName
The account that received the privileges. SYSTEM and the service accounts dominate the volume and are usually filtered out.
SubjectLogonId
The session identifier. Match it against the 4624 for the same session to find the source address and logon type.
PrivilegeList
The specific rights granted.
  • SeDebugPrivilegeAllows reading and modifying the memory of any process. This is what credential dumping needs, and few accounts have a legitimate reason to hold it.
  • SeBackupPrivilegeRead any file regardless of its permissions. Legitimate for backup software, and a well-known route around file access controls.
  • SeRestorePrivilegeWrite any file regardless of its permissions.
  • SeTakeOwnershipPrivilegeTake ownership of any object, bypassing its access controls.
  • SeTcbPrivilegeAct as part of the operating system. Very rarely legitimate for a user account.
  • SeLoadDriverPrivilegeLoad a kernel driver, the route to disabling security tooling from below.
  • SeImpersonatePrivilegeImpersonate another user after authentication. Normal for service accounts and central to several privilege-escalation techniques.

Ordinary reasons this happens

Most of the time it is one of these.

  • Any administrator signing in normally.
  • SYSTEM, LOCAL SERVICE, and NETWORK SERVICE starting the operating system's own processes — this is the majority of the volume.
  • Backup software authenticating with an account that holds backup and restore rights.
  • Management and deployment agents running under privileged service accounts.
  • On a home or standalone machine, the everyday user account, which is usually an administrator.

When it is not ordinary

A compromised account being used with administrative rights.

What gives it away4672 for an account that has no history of privileged sign-ins, or on a machine it never administers.

ATT&CK T1078.002

Preparation for credential dumping.

What gives it awaySeDebugPrivilege granted to an account outside your normal administrator group.

ATT&CK T1003

Access control bypass using backup rights.

What gives it awaySeBackupPrivilege or SeRestorePrivilege on an account that is not backup software, particularly on a file server or domain controller.

ATT&CK T1078

A newly created account being used immediately with privilege.

What gives it awayA 4672 shortly after a 4720 and a 4732 for the same account — created, added to a privileged group, then used.

ATT&CK T1136.001

What to do next

  1. Filter out SYSTEM, LOCAL SERVICE, and NETWORK SERVICE first. Everything left is worth reading.
  2. Take the Logon ID and find the matching 4624 for the source address and logon type.
  3. Check whether that account has any history of privileged sign-ins on that machine.
  4. Read the privilege list for SeDebugPrivilege in particular.
  5. On domain controllers, treat every non-service 4672 as something you should be able to explain.

Queries to run

kql Privileged sign-ins by real accounts, rarest first. The tail is where the interesting entries live. 
SecurityEvent | where EventID == 4672 | where SubjectUserName !in~ ('SYSTEM','LOCAL SERVICE','NETWORK SERVICE') and SubjectUserName !endswith '$' | summarize count() by SubjectUserName, Computer | order by count_ asc
kql Debug privilege on a real account. Short list, high value. 
SecurityEvent | where EventID == 4672 and PrivilegeList has 'SeDebugPrivilege' | where SubjectUserName !endswith '$' and SubjectUserName != 'SYSTEM' | project TimeGenerated, Computer, SubjectUserName, SubjectLogonId
splunk 
index=wineventlog EventCode=4672 NOT Account_Name IN ("SYSTEM","LOCAL SERVICE","NETWORK SERVICE") | stats count values(dest) as hosts by Account_Name

Common questions

Why does Event 4672 appear every time I turn on my computer?

Because Windows' own SYSTEM account receives administrative privileges to start the operating system, and on most personal machines your user account is an administrator too. Both produce 4672 at every sign-in, and neither indicates a problem.

What is SeDebugPrivilege and why does it matter?

It allows a process to read and modify the memory of any other process on the system, including the one that holds cached credentials. It is required for legitimate debugging, and it is also what credential-dumping tools need, so seeing it granted to an account outside your administrator group is worth investigating immediately.

How do I use Event 4672 to track administrator logins?

Collect 4672, filter out SYSTEM and the built-in service accounts, and join what remains to the matching 4624 on Logon ID. That gives you a clean list of privileged sign-ins with source addresses, at a fraction of the volume of collecting all authentication.

Read next

Mentioned by

Vendor documentation

Last reviewed 28 August 2026