SSOGEN / Free tools / Event ID 4672: Decode Special Privileges, Free in Your Browser
Free tool
Event ID 4672: Decode Special Privileges, Free in Your Browser
Event ID 4672 is logged when a new logon session is given one or more sensitive privileges, and every SYSTEM logon triggers it, so it is noisy. Paste the event into this free decoder to see what each privilege allows and which ones deserve a question, with nothing uploaded.
Paste an event and read it
Paste the text from Event Viewer, or the XML from its Details tab. To see the output first, press Special privileges (4672) to load an Acme sample.
From Event Viewer: open the event, then copy the General text, or the XML from the Details tab (XML View). Events 4624, 4625, 4634, 4647, 4648, 4672, 4740, 4768, 4769, 4771 and 4776 are recognized.
Private by design. Decoding happens in this page and nothing is sent anywhere. Event text holds account names, host names and IP addresses: use a copy you are allowed to look at, and remove anything you must not share.
Free, in your browser. No sign-up and no limit. The page makes no network request when you decode, so the event never leaves your computer. Event text still holds account names, so use a copy you are allowed to read.
For each privilege it finds, the decoder prints Microsoft’s meaning.
- Flags. Four privileges get a second look: SeDebugPrivilege, SeTcbPrivilege, SeCreateTokenPrivilege and SeEnableDelegationPrivilege.
- Account type. It says whether the account looks like a system or machine account, which is the first filter in the next section.
What event 4672 is
Event ID 4672 is the Windows Security log entry for “special privileges assigned to new logon”. Microsoft’s page says it is generated for new account logons when any of 13 sensitive privileges is assigned to the new logon session. Expect many of them: every logon of the SYSTEM (Local System) account triggers it.
The event is not an alarm. It is a list of who signed in and which powerful rights came with the session. This free decoder reads a pasted event and explains each privilege in it.
Why 4672 is noisy, and how to filter it
Microsoft puts 4672 in the Audit Special Logon subcategory (Audit Special Logon, read 2026-10-11).
- Events. 4964 (special groups assigned to a new logon) and 4672 (special privileges assigned).
- Volume. Low on a client computer and medium on domain controllers and network servers.
- Auditing. Microsoft recommends Success auditing for all three computer types. The subcategory has no failure events, so there is nothing to enable for Failure.
Service and machine logons cause the volume. Microsoft’s monitoring recommendations for 4672 give the filter in two parts:
- Look at events where the Subject Security ID is not one of the well-known principals LOCAL SYSTEM, NETWORK SERVICE or LOCAL SERVICE, and is not an administrative account expected to have the listed privileges.
- If you keep a list of privileges that should never be granted, or only to a few accounts (Microsoft’s example is SeDebugPrivilege), search the event’s privilege list for those names.
After you drop the three system principals, a short list of people and service accounts remains. Each one either belongs on your list of privileged accounts or does not.
The decoder applies the same first step to the account it reads and reports which side it falls on.
The decoder cannot know your list. It treats a computer account (a name ending in $) as a machine account; that is a convention, not a line from Microsoft’s page.
The 13 privileges, and what each lets the holder do
These are the privileges Microsoft says can trigger the event, with the meaning from Microsoft’s description in plain words. Holding any one of them is enough to produce a 4672.
| Privilege | Group Policy name | What it lets the holder do |
|---|---|---|
| SeTcbPrivilege | Act as part of the operating system | Marks the holder as part of the trusted computer base; a process can impersonate any user without authentication |
| SeCreateTokenPrivilege | Create a token object | Create a token that can be used to get access to any local resource |
| SeDebugPrivilege | Debug programs | Debug and adjust the memory of a process owned by another account; attach a debugger to any process or to the kernel |
| SeEnableDelegationPrivilege | Enable computer and user accounts to be trusted for delegation | Set the Trusted for Delegation setting on a user or computer object |
| SeAssignPrimaryTokenPrivilege | Replace a process-level token | Assign the primary token of a process, replacing the default token of a started subprocess |
| SeImpersonatePrivilege | Impersonate a client after authentication | Impersonate other accounts |
| SeLoadDriverPrivilege | Load and unload device drivers | Load or unload drivers and other code into kernel mode (not Plug and Play drivers) |
| SeBackupPrivilege | Back up files and directories | Bypass file, directory and registry permissions to read for backup; read access to any file regardless of its ACL |
| SeRestorePrivilege | Restore files and directories | Write to any file regardless of its ACL, and set any valid user or group as the owner of a file |
| SeTakeOwnershipPrivilege | Take ownership of files or other objects | Take ownership of any securable object, including Active Directory objects, files, printers, registry keys, processes and threads |
| SeSecurityPrivilege | Manage auditing and security log | Set object access auditing options, view the security log and clear it |
| SeAuditPrivilege | Generate security audits | Add entries to the security log |
| SeSystemEnvironmentPrivilege | Modify firmware environment values | Modify the nonvolatile RAM of systems that store configuration there |
The table comes from the field description on Microsoft’s event 4672 page, read 2026-10-11. Two points matter when you read it.
Several privileges carry the same risk.
- Backup and Restore. Together they mean read and write on any file, whatever the ACL says.
- Security. The holder can clear the log that would record it.
- Take ownership. The holder can own anything.
The useful question for an investigator is which combination is present, on which account, rather than which single privilege.
Impersonation is part of the design. Microsoft’s page on the impersonate right explains that a service running in a client’s security context “is” the client to some degree.
Services started by the Service Control Manager get the built-in Service group, and this right with it, by default, so SeImpersonatePrivilege on a service account is expected.
The risk, in Microsoft’s words: an attacker holding it could create a service, mislead a client into connecting and then impersonate that client to raise their own access.
Which accounts normally hold which
Microsoft’s user-rights pages state the default holders for several of these privileges. Use them as your baseline, noting that they are the Windows defaults and your Group Policy may differ.
| Privilege | Default holders on Microsoft’s page | Microsoft’s advice |
|---|---|---|
| SeDebugPrivilege | Administrators | Grant it only to trusted users; remove accounts that do not need it |
| SeImpersonatePrivilege | Administrators, Local Service, Network Service, Service | On member servers, only Administrators and the Service groups |
| SeTcbPrivilege | Not defined by default | Do not assign to any user account; a service that needs it should log on as Local System, which includes it |
| SeBackupPrivilege | Administrators and Backup Operators; on domain controllers also Server Operators | Only the IT team that backs up data, or the backup software’s service accounts |
| SeLoadDriverPrivilege | Administrators; on domain controllers also Print Operators | Member servers: Administrators only. Domain controllers: Domain Admins only |
Sources: the Microsoft pages for Debug programs, Impersonate a client after authentication, Act as part of the operating system, Back up files and directories and Load and unload device drivers, all read 2026-10-11.
The default holders of the other eight privileges are outside the sources this page read, so the table leaves them out.
The baseline separates two kinds of finding. SeTcbPrivilege has no default holder, and Microsoft’s advice is to give it to nobody but Local System.
A named person or service account on a 4672 with SeTcbPrivilege is therefore a different finding from a member of Backup Operators with SeBackupPrivilege.
SeDebugPrivilege: Administrators, and only Administrators
The event page gives the shortest rule in this whole family: “We recommend that SeDebugPrivilege always be granted to Administrators, and only to Administrators.”
It adds that developers who debug their own applications do not need the right, and that it “provides complete access to sensitive and critical operating system components”.
The Debug programs page explains the risk. The right can capture sensitive information from system memory or change kernel and application structures. Some attack tools use it to extract hashed passwords and other private security information, or to insert malware.
The check is simple: find the account in the event and confirm whether it is an administrator.
- Administrator. The event is normal.
- Not an administrator. Someone granted a debugging right to a non-administrator, and you need to know who and why.
The decoder warns on this privilege because it has the clearest rule, not because the privilege is wrong in itself.
The 4624 and 4672 pairing
A 4672 says what a session holds, not how the session started. For that you need the 4624 (an account was successfully logged on) from the same moment.
Microsoft’s 4672 page says its Logon ID is a hexadecimal value that helps you correlate the event with recent events holding the same Logon ID, and names 4624 as the example. The 4624 page says the same in reverse.
To pair them:
- Copy the Logon ID from the 4672, for example 0x671101.
- Find the 4624 whose New Logon Logon ID is the same value. (The 4624 also has a Logon ID under Subject, which belongs to the caller that asked for the logon, so match on the New Logon block.)
- Read the 4624 for what the 4672 leaves out: the logon type, the source address and workstation, the authentication package and the process.
For step 3, use Microsoft’s logon types table on the 4624 page:
- type 2 is interactive at the keyboard;
- 3 is over the network;
- 4 is batch;
- 5 is a service started by the Service Control Manager;
- 7 is a return to a locked workstation;
- 10 is Remote Desktop;
- 11 is a cached interactive logon.
A service account with powerful privileges on a type 5 logon is routine. The same privileges on a type 10 logon from an unfamiliar address are not.
Elevated Token on the 4624
Windows 10 and later add an Elevated Token field to the 4624, which Microsoft describes as a Yes or No flag. Yes means the session is elevated and has administrator privileges.
- Monitoring. To catch every logon of an account with administrator privileges, Microsoft advises monitoring 4624 with Elevated Token equal to Yes.
- Linked Logon ID. The 4624 also has this field: the value of the paired logon session, or 0x0 if there is none.
The two events complement each other. Elevated Token = Yes on a 4624 identifies an administrator session, and the 4672 with the same Logon ID lists the specific rights it received.
If a 4624 shows Elevated Token = Yes but no 4672 exists for that Logon ID, check two things:
- the Audit Special Logon subcategory is enabled on that machine;
- you are searching the right machine, because the 4672 is logged where the session was created.
A worked example
Load the Special privileges (4672) sample. It is a fictional Acme event: the account ACME\ops.admin, Logon ID 0x671101, with six privileges: SeSecurityPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeTakeOwnershipPrivilege, SeDebugPrivilege and SeImpersonatePrivilege.
Read it in three passes:
- The account. ops.admin is not LOCAL SYSTEM, NETWORK SERVICE or LOCAL SERVICE, so it is in the group Microsoft says to review. The decoder reports it as not a system account.
- The privileges. The decoder warns on SeDebugPrivilege. The rest are read-and-write rights on files plus the security log, which is the expected shape for an administrator account.
- The next step. Search for the 4624 with Logon ID 0x671101 and read the logon type and source address.
If ops.admin signed in at a server from the helpdesk network, the pair is ordinary. If the 4624 shows a type 3 network logon from an address nobody recognizes, those six privileges are what an intruder now holds.
The account matters as much as the privileges. Give the same six privileges to someone on the sales team, and the finding becomes a non-administrator holding Debug programs, Microsoft’s most clearly restricted right.
The privilege the list leaves out
Microsoft’s User Rights Assignment page, read 2026-10-11, lists 45 rights with their constant names. Only 13 can trigger 4672.
The rest, such as log on locally, log on as a service, shut down the system or change the time zone, never produce this event, however powerful the account that holds them.
Real logs can contain names outside the 13.
In a Microsoft Q&A thread read 2026-10-11, a user asks about a 4672 whose privilege list included SeDelegateSessionUserImpersonatePrivilege.
That name is in Microsoft’s User Rights table (as “Obtain an impersonation token for another user in the same session”) but not in the event page’s list of 13.
When the decoder meets a privilege name outside its list, it says “not in the decoder’s list” instead of guessing. Look the name up in the user rights table; an unlisted name is not a sign of trouble.
How to find the event
- On the computer you care about (the event is written where the session is created), open Event Viewer, then Windows Logs, then Security. Reading this log requires an administrator account.
- Filter the current log by event ID 4672, or search for an account name.
- Open the event and copy the text from the General tab, or the XML from the Details tab, then paste it above.
Microsoft files the event under the Audit Special Logon subcategory, event version 0, for Windows Vista and Windows Server 2008 and later.
Where this meets SSO
Single sign-on decides who signs in. Event 4672 records what a Windows session may do once it has signed in.
The two meet at privileged accounts. Accounts that appear here with SeDebugPrivilege or SeBackupPrivilege are the ones whose sign-ins you most want to see in one place. They are also the first candidates for just-in-time access, so the rights exist only during an approved window.
- SSOGEN’s record. The SSO audit log page describes SSOGEN’s own record of sign-ins, kept separately from your Windows logs.
- Kerberos tickets. For how Windows hands out the tickets that usually precede a domain logon, see event ID 4768 and the Kerberos authentication page.
- Failed logons. See event ID 4625.
- Successful logons. The matching success event is covered on the event ID 4624 page.
Questions people ask
What is event ID 4624?
How do I turn off Microsoft Windows security auditing?
What is SeTcbPrivilege?
What does Event ID 4729 mean?
Where to go next
- Browse the other free tools.
- Open the event ID 4625 decoder for failed logons.
- Read the event ID 4768 decoder for the Kerberos side of a domain sign-in.
Sources, all read 2026-10-11: Microsoft Learn pages for events 4672 and 4624, Audit Special Logon, Audit Security Group Management, User Rights Assignment, auditpol set and the five user-rights pages linked above.
Microsoft and Windows are trademarks of their owner; SSOGEN is not affiliated with Microsoft.