Event ID 4672: Special Privileges Assigned to New Logon — Admin Logons

What it records

Event 4672, in the Audit Special Logon subcategory, is written when a logon session is created with powerful privileges attached. Microsoft’s definition: “This event generates for new account logons if any of the following sensitive privileges are assigned to the new logon session” — followed by a list that includes SeTcbPrivilege (act as part of the operating system), SeBackupPrivilege and SeRestorePrivilege (back up and restore files and directories), SeCreateTokenPrivilege, SeDebugPrivilege (debug programs), SeEnableDelegationPrivilege, SeAuditPrivilege, SeImpersonatePrivilege, SeLoadDriverPrivilege, SeSecurityPrivilege (manage auditing and security log), SeSystemEnvironmentPrivilege, SeAssignPrimaryTokenPrivilege and SeTakeOwnershipPrivilege.

The record is small. The Subject section names the account the privileges were assigned to — Security ID, Account Name, Account Domain — and its Logon ID. Privileges lists the sensitive privileges the session received. There is no source address, no logon type and no process name: those live in the 4624 written for the same logon, which is why 4672 is almost always read together with it.

In practice 4672 marks administrator logons. Members of the local Administrators group hold privileges such as SeDebugPrivilege and SeBackupPrivilege, so their logons produce a 4672 alongside the 4624; standard users’ logons do not. Microsoft also warns about the volume: “You typically will see many of these events in the event log, because every logon of SYSTEM (Local System) account triggers this event.”

When it matters

Pattern	Reading
Subject is SYSTEM, LOCAL SERVICE or NETWORK SERVICE	Expected — Microsoft’s own example of the noise
A user account Microsoft would call unexpected: not an administrator that should hold these privileges	Microsoft’s first monitoring recommendation; check how it became privileged
SeDebugPrivilege for an account that has no reason to debug processes	Microsoft’s example of a privilege to watch; it allows access to LSASS memory
A privileged logon on a workstation or server the admin never uses	Possible lateral movement with administrative credentials
Privileged logon with logon type 3 (network) or 10 (remote interactive) from an unusual source	Remote administration or an attacker using stolen admin credentials
A new account that starts appearing in 4672 shortly after it was created	Check for account creation (4720) and group additions (4732) just before

The useful question is never whether a 4672 exists — there are thousands — but which privileged sessions are new. An account that has not logged on with administrative rights before, a known admin logging on to a server they never touch, or a privileged session from an address outside the admin network are the cases worth working.

How to investigate

Remove the service noise and see who holds privileged sessions, and where:

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4672
| where SubjectUserSid !in ("S-1-5-18", "S-1-5-19", "S-1-5-20")
| where SubjectUserName !endswith "$"
| summarize Sessions = count(), Hosts = dcount(Computer), HostList = make_set(Computer, 20),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by SubjectUserName, SubjectDomainName
| order by Hosts desc

Join each privileged session to its 4624 to get the logon type and the source:

let privileged = SecurityEvent
    | where TimeGenerated > ago(1d) and EventID == 4672
    | where SubjectUserSid !in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and SubjectUserName !endswith "$"
    | project PrivTime = TimeGenerated, PrivComputer = Computer, LogonId = SubjectLogonId, Privileges = PrivilegeList;
SecurityEvent
| where TimeGenerated > ago(1d) and EventID == 4624
| join kind=inner privileged on $left.Computer == $right.PrivComputer, $left.TargetLogonId == $right.LogonId
| project PrivTime, Computer, Account = TargetUserName, LogonType, IpAddress, WorkstationName, AuthenticationPackageName, Privileges
| order by PrivTime desc

Watch the privileges Microsoft singles out, such as SeDebugPrivilege, for accounts outside your admin list:

SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID == 4672 and PrivilegeList has "SeDebugPrivilege"
| where SubjectUserSid !in ("S-1-5-18", "S-1-5-19", "S-1-5-20") and SubjectUserName !endswith "$"
| summarize Sessions = count(), Hosts = make_set(Computer, 20) by SubjectUserName
| order by Sessions desc

For a session that should not exist, follow the Logon ID into the processes it started: 4688 events carry the same value in their Subject Logon ID. Then check how the account got its rights — recent group membership changes such as 4732, or a freshly created account — and whether the same credentials logged on elsewhere. Explicit-credential use in 4648 on the source host often shows the hop that preceded the privileged logon.