Event 4672: Special privileges assigned to new logon.
Quick Answer
Event 4672 is generated when an account logs on with administrative or other special privileges. This event immediately follows a successful logon (4624) for accounts with elevated rights, making it critical for tracking privileged account usage and detecting privilege escalation.
Technical Details
Event ID: 4672
Windows Security- Privilege Use
Event Description
Special privileges (e.g., SeDebugPrivilege) were assigned to a new logon session.
Key Log Fields
SubjectUserName- Account name that received special privilegesSubjectDomainName- Domain of the accountSubjectUserSid- SID of the accountSubjectLogonId- Logon ID to correlate with 4624 eventsPrivilegeList- List of special privileges assigned (e.g., SeDebugPrivilege, SeTcbPrivilege, SeBackupPrivilege)
MITRE ATT&CK® Mapping (4)
Adversaries may modify access tokens to operate under a different user or system security context to perform actions and bypass access controls. Windows uses access tokens to determine the ownership of a running process. A user can manipulate access tokens to make a running process appear as though it is the child of a different process or belongs to someone other than the user that started the process. When this occurs, the process also takes on the security context associated with the new token. An adversary can use built-in Windows API functions to copy access tokens from existing processes; this is known as token stealing. These token can then be applied to an existing process (i.e. [Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001)) or used to spawn a new process (i.e. [Create Process with Token](https://attack.mitre.org/techniques/T1134/002)). An adversary must already be in a privileged user context (i.e. administrator) to steal a token. However, adversaries commonly use token stealing to elevate their security context from the administrator level to the SYSTEM level. An adversary can then use a token to authenticate to a remote system as the account for that token if the account has appropriate permissions on the remote system.(Citation: Pentestlab Token Manipulation) Any standard user can use the <code>runas</code> command, and the Windows API functions, to create impersonation tokens; it does not require access to an administrator account. There are also other mechanisms, such as Active Directory fields, that can be used to modify access tokens.
Adversaries may duplicate then impersonate another user's existing token to escalate privileges and bypass access controls. For example, an adversary can duplicate an existing token using `DuplicateToken` or `DuplicateTokenEx`.(Citation: DuplicateToken function) The token can then be used with `ImpersonateLoggedOnUser` to allow the calling thread to impersonate a logged on user's security context, or with `SetThreadToken` to assign the impersonated token to a thread. An adversary may perform [Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001) when they have a specific, existing process they want to assign the duplicated token to. For example, this may be useful for when the target user has a non-network logon session on the system. When an adversary would instead use a duplicated token to create a new process rather than attaching to an existing process, they can additionally [Create Process with Token](https://attack.mitre.org/techniques/T1134/002) using `CreateProcessWithTokenW` or `CreateProcessAsUserW`. [Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001) is also distinct from [Make and Impersonate Token](https://attack.mitre.org/techniques/T1134/003) in that it refers to duplicating an existing token, rather than creating a new one.
Adversaries may create a new process with an existing token to escalate privileges and bypass access controls. Processes can be created with the token and resulting security context of another user using features such as <code>CreateProcessWithTokenW</code> and <code>runas</code>.(Citation: Microsoft RunAs) Creating processes with a token not associated with the current user may require the credentials of the target user, specific privileges to impersonate that user, or access to the token to be used. For example, the token could be duplicated via [Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001) or created via [Make and Impersonate Token](https://attack.mitre.org/techniques/T1134/003) before being used to create a process. While this technique is distinct from [Token Impersonation/Theft](https://attack.mitre.org/techniques/T1134/001), the techniques can be used in conjunction where a token is duplicated and then used to create a new process.
Adversaries may circumvent mechanisms designed to control elevate privileges to gain higher-level permissions. Most modern systems contain native elevation control mechanisms that are intended to limit privileges that a user can perform on a machine. Authorization has to be granted to specific users in order to perform tasks that can be considered of higher risk.(Citation: TechNet How UAC Works)(Citation: sudo man page 2018) An adversary can perform several methods to take advantage of built-in control mechanisms in order to escalate privileges on a system.(Citation: OSX Keydnap malware)(Citation: Fortinet Fareit)
Event Comparison
Event 4672 always follows 4624 for privileged accounts. The combination of these events provides complete context for administrative logons.
What This Event Means
Event 4672 records when security-sensitive privileges are assigned to a new logon session, typically occurring milliseconds after a successful authentication event. This event lists all the special privileges granted to the user's access token, including powerful rights like SeDebugPrivilege (attach to processes), SeBackupPrivilege (read any file), and SeTakeOwnershipPrivilege (take ownership of files). Unlike Event 4624 which logs all logons, Event 4672 only appears for accounts that possess special privileges, making it an excellent filter for tracking administrative activity. Security teams use this event to monitor usage of privileged accounts, detect unauthorized privilege escalation, and identify compromised credentials being used with elevated rights. The event is particularly valuable for detecting lateral movement by threat actors who have compromised domain administrator credentials or other privileged accounts. When you see Event 4672 from unexpected source IPs, during off-hours, or on systems where privileged accounts shouldn't be used, it warrants immediate investigation.
Security Implications
- Privileged account logons from workstations or unexpected systems indicate potential credential theft
- Event 4672 appearing during off-hours for administrator accounts suggests unauthorized access
- Multiple privileged logons from the same source to different systems in short timeframes indicate lateral movement
- Service accounts generating interactive logons with 4672 may indicate account compromise
- Privileges like SeDebugPrivilege being used outside patch/maintenance windows can signal malicious debugging or memory dumping
Detection Strategies
Create a baseline of normal privileged account usage patterns, including typical logon times, source systems, and target destinations. Alert immediately on any privileged logon outside established patterns. Monitor for privileged accounts authenticating from user workstations rather than administrative jump boxes. Track the volume and frequency of privileged logons per account to detect potential credential sharing or compromise. Correlate 4672 with 4624 to ensure the source IP and logon type are appropriate for administrative activity. Look for unusual combinations like administrator accounts with Type 3 network logons from systems outside the administrative network segment. Cross-reference privileged logons with ticketing systems to verify legitimate administrative work. Detection queries for common SIEM platforms will be included in future documentation updates.
Note: Comprehensive SIEM detection queries for Splunk SPL, Microsoft KQL, and Elastic Query DSL will be added in future updates.
Real-World Attack Examples
The Kaseya VSA ransomware attack involved compromised admin credentials generating 4672 events before deploying REvil ransomware across managed endpoints
NotPetya malware propagation relied on stolen admin credentials that produced widespread 4672 events during lateral movement
APT28 (Fancy Bear) campaigns frequently abuse compromised domain admin accounts, visible through suspicious 4672 events from unexpected source IPs