Event ID 4673: A privileged service was called

Event 4673 is a Security log record that something called a privileged service. It belongs to two subcategories, Audit Sensitive Privilege Use and Audit Non Sensitive Privilege Use, and each has a Success and a Failure form. Microsoft's examples are a caller using SeSystemtimePrivilege, SeCreateGlobalPrivilege or SeTcbPrivilege. Which subcategory carries a given event depends on the privilege: SeTcbPrivilege is on the sensitive list, SeChangeNotifyPrivilege on the non-sensitive one.

The useful question is who writes the record. The Win32 function PrivilegedServiceAuditAlarm, in Microsoft's words, "generates an audit message in the security event log", and a protected server uses it to log attempts by a client to use a set of privileges. Its parameters are a subsystem name, a service name, the privileges the client tried to use, and a flag for whether the attempt worked. Those line up with the ObjectServer, Service and PrivilegeList fields and with the Success and Failure forms. The function does not check the client's token. The server typically runs PrivilegeCheck first and reports what it found. Read a 4673 as a subsystem (the LSA, the Service Control Manager, the SAM) saying that a client leaned on a privilege while calling it. Microsoft does not publish a list of every caller, so the only complete catalogue is the baseline you build from your own logs.

Microsoft's sample shows the shape of a normal one. lsass.exe, running as the machine account, calls LsaRegisterLogonProcess() and uses SeTcbPrivilege. The ObjectServer there is "NT Local Security Authority / Authentication Service".

Three events describe a privilege at three different moments, and they are easy to mix up. Event 4672 lists the sensitive privileges a new logon session holds. Event 4703 records token privileges being enabled or disabled, and Microsoft notes it is logged from Windows 10 onward under Audit Authorization Policy Change. Microsoft's Win32 documentation explains why both exist. A token carries the privileges at logon, an operation checks that the token holds the privilege and that it is enabled, and most privileges are disabled by default. Event 4673 is the use. MITRE's token manipulation page lists several malware families that switch on SeDebugPrivilege through AdjustTokenPrivileges. That step shows up as a 4703 where you audit it. A 4673 comes later, and only if the service being called reports the use.

The fields are few. SubjectUserSid, SubjectUserName, SubjectDomainName and SubjectLogonId identify the caller. ObjectServer names the subsystem, and Microsoft lists Security, Security Account Manager, NT Local Security Authority / Authentication Service, SC Manager, Win32 SystemShutdown module and LSA. Service is optional and names the function. PrivilegeList holds the privileges requested. ProcessId is hexadecimal and matches the new process ID in a 4688, and ProcessName is the executable. There is no object name and no access mask. Those belong to 4674.

The subcategory you enable decides which privileges you ever see. Audit Sensitive Privilege Use covers 13 privileges, with Backup and Restore producing events only when the "Audit: Audit the use of Backup and Restore privilege" policy is on. Microsoft rates its volume High and recommends Success and Failure on every computer type, especially when a user account used the privilege. Audit Non Sensitive Privilege Use covers 21 privileges, rates the volume Very High, advises against Success auditing and leaves Failure optional, with SeShutdownPrivilege and SeRemoteShutdownPrivilege as the examples worth it.

Some noise is documented. A Microsoft support article describes event 4673 logged twice every minute on Windows 8.1 and Windows Server 2012 R2 when Sensitive Privilege Use is set to Failure, fixed by hotfix 3078584. A Microsoft Q&A thread from 2024 shows a Failure 4673 from msedge.exe under a local user account, with SeProfileSingleProcessPrivilege and Service set to a hyphen, and an Elastic forum poster reports floods of the same privilege tied to Chromium. The poster says Microsoft knows about it. We found no Microsoft page that confirms it, so treat that as a field report.

Start by removing who is supposed to be there. Microsoft's guidance is to watch for subjects that are not LOCAL SYSTEM, NETWORK SERVICE or LOCAL SERVICE and are not an administrative account expected to hold the listed privileges. If you keep a list of rights that should never be used, SeDebugPrivilege being Microsoft's example, alert on every use. If a subject has an allowed list, alert on anything outside it.

Four shapes are worth a rule. The first is LsaRegisterLogonProcess() from a binary that is not a logon process. Microsoft says the function establishes a connection to the LSA and verifies the caller is a logon application, and that it does so by checking for SeTcbPrivilege. Microsoft describes that privilege as letting a process impersonate any user without authentication. The legitimate callers on your estate should be a short list you can enumerate, and a binary under C:\Users\Public is not on it. The second is a sensitive privilege used under a person's account instead of a machine or service account. The third is a burst of Failure events for sensitive privileges from one user, which can mean someone is trying rights they were never given. The fourth is a process and privilege pair that has never appeared on that host before, which is how you catch the quiet cases that match no signature.

Expect false positives from management agents, backup software, antivirus and EDR sensors, which run as SYSTEM and exercise privileges as part of the job. Browsers and collaboration apps show up in most of the Failure noise threads. Fix that at the collector by dropping known process and privilege pairs, and leave the sensitive subcategory switched on.

When one fires, work outward. ProcessId and the time lead to the 4688 for that process, which gives the parent. Check whether a 4703 for the same process came first, and look at what the account's 4672 granted at logon. Be careful with SubjectLogonId. In Microsoft's samples the machine account running as SYSTEM appears as 0x3e7 and LOCAL SERVICE as 0x3e5, so a join on logon ID to the 4624 says little for system sessions. Hash the file named in ProcessName and look at its signature.

Know what the event cannot say. It carries no command line and no target. A privilege used is not a privilege abused, and Microsoft does not map attack tools to service names. If a tool worries you, run it in a lab with the subcategory on and read the events it produces before you write a rule around it.

The simulated event on this page copies the shape of Microsoft's own sample on purpose. The subject is the machine account running as SYSTEM, the logon ID is 0x3e7, the ObjectServer is the LSA authentication service, the Service is LsaRegisterLogonProcess() and the privilege is SeTcbPrivilege. Every field a filter on principal would look at is identical to the benign case.

One field is different. ProcessName points at a binary in C:\Users\Public\Libraries instead of lsass.exe. That is the whole signal, and it is why a rule keyed on the privilege alone drowns while a rule keyed on the privilege together with the process works. Run the first detection query on this page against it.