Event ID 4672: Special privileges assigned to new logon

Event 4672 lives in the Security channel and belongs to the Audit Special Logon subcategory, under Advanced Audit Policy Configuration, Logon/Logoff. Windows raises it every time a new logon session's access token is built with at least one of thirteen privileges Microsoft classifies as sensitive: SeAssignPrimaryTokenPrivilege, SeAuditPrivilege, SeBackupPrivilege, SeCreateTokenPrivilege, SeDebugPrivilege, SeEnableDelegationPrivilege, SeImpersonatePrivilege, SeLoadDriverPrivilege, SeRestorePrivilege, SeSecurityPrivilege, SeSystemEnvironmentPrivilege, SeTakeOwnershipPrivilege, and SeTcbPrivilege.

The event has a small field set: SubjectUserSid, SubjectUserName, SubjectDomainName, and SubjectLogonId identify the account and session, and PrivilegeList spells out which of the thirteen privileges landed in that token. There is no target-account block and no logon-type field on 4672 itself; that context always lives on the paired 4624.

The SubjectLogonId is the field that does the real work. It is a hexadecimal session identifier that ties 4672 back to the 4624 that created the session, and forward to 4634 or 4647 when the session ends, and to 4673 if the account actually exercises one of the granted privileges (opening a privileged handle, for instance). An analyst reading 4672 in isolation only knows a token was built with elevated rights; joining on LogonId is what turns that into a story: who authenticated, from where, with what logon type, and what they did with the privilege afterward.

Volume is dominated by NT AUTHORITY\SYSTEM. SYSTEM's token already carries almost the entire sensitive-privilege list, so every service start, every scheduled task running as SYSTEM, and every kernel-mode driver load produces a fresh 4672. Domain controllers add their own baseline: machine account logons for replication, Group Policy processing, and Kerberos ticket issuance all touch SeTcbPrivilege or SeSecurityPrivilege in the process.

NETWORK SERVICE and LOCAL SERVICE contribute a smaller but steady stream tied to built-in Windows services that need to impersonate callers (IIS application pools, print spooler helpers, WMI providers). None of this volume is remarkable on its own; it is the cost of a functioning Windows estate and the reason 4672 is one of the noisiest IDs in the Security log on servers and domain controllers.

What is worth an analyst's attention is the same event firing against an account that is not SYSTEM, not a well-known service SID, and not a machine account. A help-desk technician's interactive logon producing SeDebugPrivilege is unusual, because that right is normally reserved for local Administrators debugging processes, not for a standard support account. A batch or scheduled-task account suddenly holding SeBackupPrivilege and SeRestorePrivilege, when its job has never needed filesystem-ACL bypass before, points at a group-membership change somewhere upstream rather than at the 4672 event itself, which only reports the consequence.

Attackers light this event up in a handful of recognizable ways. Credential theft against LSASS (Mimikatz and its descendants) requires SeDebugPrivilege on the attacking process, so a 4672 carrying that privilege against an account outside the expected admin set is a leading indicator of an in-progress dump attempt, especially when it is followed by a 4673 targeting lsass.exe. Potato-family local-privilege-escalation tools (JuicyPotato, RoguePotato, PrintSpoofer) abuse SeImpersonatePrivilege, which service accounts typically already hold, to coerce a SYSTEM-level token; the 4672 here looks routine on its own but becomes meaningful when paired with an unexpected child process spawned moments later.

Bring-your-own-vulnerable-driver techniques used to kill EDR agents need SeLoadDriverPrivilege, a right almost never exercised outside of driver installers and virtualization software, making any unscheduled instance worth a look. Ransomware operators taking ownership of files ahead of encryption, or deleting shadow copies to block recovery, ride on SeTakeOwnershipPrivilege and SeBackupPrivilege respectively. And lateral movement using stolen Domain Admin credentials (pass-the-hash, pass-the-ticket, or plain credential reuse) shows up as a 4672 for a genuine admin account, but from a source workstation or at an hour that does not match that admin's normal pattern once you correlate the LogonId back to 4624.

Start triage by removing the accounts that are supposed to be here. SubjectUserName values of SYSTEM, NETWORK SERVICE, and LOCAL SERVICE, plus any account name ending in a dollar sign (computer accounts and, on some estates, service accounts provisioned with machine-style naming), account for the overwhelming majority of 4672 volume on any server or domain controller. Filtering these out first is not optional; without it, every hunt drowns before it starts.

On a domain controller, machine-account 4672 entries tied to replication, LDAP binds, and Group Policy refresh are expected background noise, as is a genuine Domain Admin logging on interactively during business hours from their known jump box. Confirm the last part by joining SubjectLogonId to the matching 4624 and checking LogonType (2 for interactive, 10 for RemoteInteractive/RDP) and the source workstation or IP against what that admin normally uses. A privileged logon that checks out on all three, expected account, expected source, expected hour, is a true positive for "privilege granted," but a false positive for "something is wrong."

The pattern worth escalating is the mismatch. A standard user account or a low-privilege service account receiving SeDebugPrivilege or SeImpersonatePrivilege for the first time in its history is the single strongest signal 4672 offers, particularly on a workstation rather than a server, since workstations rarely need any of these thirteen rights outside of local Administrator sessions.

Pair that with the LogonId trail: if the 4624 behind the 4672 shows an unfamiliar source IP, an off-hours timestamp, or a logon type that does not match how that account is supposed to authenticate (a service account showing LogonType 10, for example), the privilege grant is riding on top of a suspicious authentication event, not a benign one.

Use 4673 as the tiebreaker when the account itself looks ambiguous. A 4672 with no corresponding 4673 for hours or days means the privilege was granted but never exercised, which lowers urgency without eliminating it as a finding worth a baseline update. A 4673 that follows within seconds and names a sensitive target, lsass.exe under SeDebugPrivilege, the SAM or NTDS.dit path under SeBackupPrivilege, is close to unambiguous evidence the privilege is being actively used for something an analyst should look at immediately.

Finally, baseline the volume itself per host. A domain controller or admin jump box that produces hundreds of 4672 events an hour is normal for that host; the same count on a line-of-business workstation that historically logs two or three a month is not, regardless of which account or privilege is involved. Building that per-host baseline, and alerting on deviations from it, catches automated enumeration, repeated persistence-mechanism restarts, and compromised-service reuse that individual-event filtering on account name or privilege name alone will miss.