Windows Security Audit Logs Show Unexpected Privilege Use

Hafiz Omar 40 Reputation points
2026-10-23T02:09:12.7766667+00:00

Security logs show processes exercising privileges that are not expected for the logged-on user. How can I trace the process identity, token privileges, parent process, and relevant audit events to determine whether the behavior is legitimate?

Windows for business | Windows 365 Business
0 comments
Answer accepted by question author
Daphne Huynh (WICLOUD CORPORATION) 2,540 Reputation points Microsoft External Staff Moderator
2026-10-23T02:19:45.87+00:00

Welcome to Microsoft Q&A!

Thank you for taking the time to provide the detailed information.

Based on the description, this does not necessarily mean that the logged-on user directly exercised the privilege.

Windows records sensitive privilege-use events when privileged operations are requested. Event ID 4673 can provide information such as the account, Logon ID, Process ID, Process Name, and the privilege involved. Event ID 4674 is related to operations attempted on privileged objects.

The likely cause is that the privilege was exercised by a process running under a different security context than expected, such as an elevated process or service.

For this reason, I recommend correlating the privilege-use event with the corresponding process-creation events rather than relying only on the interactive username.

  1. Start with the 4673/4674 event at the time the activity occurred and note the Subject Security ID, Account Name, Logon ID, Process ID, Process Name, and Privileges.

In particular, the process information in Event 4673 can help identify which process requested the privileged operation.

  1. Correlate the event with Security Event ID 4688 (process creation) from approximately the same time. Use the Process ID and related process information to trace the process that was created and its creator/parent process. Where the applicable information is recorded, this can help establish the process chain and security context associated with the activity.

You should also correlate the Logon ID with the relevant logon and security events. This helps connect the privilege-use event to the security principal and logon session under which the process was operating.

  1. After reconstructing the activity, validate the following sequence:
Account/logon session → process → parent process → command line → privilege used

Compare that sequence with the expected application or administrative activity on the computer.

If the account, process chain, and privilege are consistent with an expected application, service, or administrative operation, the event is likely associated with legitimate activity.

If the executable, parent process, command, or security context cannot be accounted for, preserve the related Security events and continue investigating the activity as potentially unauthorized rather than evaluating the 4673/4674 event in isolation.

References:

4673(S, F) A privileged service was called. - Windows 10 | Microsoft Learn

Audit Sensitive Privilege Use - Windows 10 | Microsoft Learn

I hope this helps you trace the activity and determine whether the privilege use is expected.

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Was this answer helpful?

1 person found this answer helpful.
0 comments

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-10-23T02:09:36.81+00:00

    Use Security auditing to correlate four things: the privilege-use event, the process that used it, the token change, and the logon context.

    1. Enable the audit categories that expose privilege use and process lineage.
      • Audit Sensitive Privilege Use: records when sensitive privileges are used. Relevant events include:
        • 4672 – Special privileges assigned to new logon
        • 4673 – A privileged service was called
        • 4674 – An operation was attempted on a privileged object
      • Audit Process Creation: records new processes.
        • 4688 – A new process has been created
        • 4696 – A primary token was assigned to a process
      • Audit Process Termination: records process exit.
        • 4689 – A process has exited
      • Audit Token Right Adjustment: records token privilege adjustments.
        • 4703 – A user right was adjusted
    2. Start from the privilege-use event.
      • In Event Viewer > Windows Logs > Security, locate the suspicious 4673 or 4674 event.
      • Use the event time and the account shown in that event as the pivot point.
      • If the concern begins at logon, also check 4672 to see whether the session received special privileges at sign-in.
    3. Identify the process and parent process.
      • Find 4688 events at the same timestamp window.
      • Audit Process Creation is the event that provides the process creation record and is the primary source for identifying the program involved.
      • Correlate the suspicious privilege-use event with nearby 4688 events to determine which executable started at that time.
      • Then review earlier 4688 events in the same sequence to reconstruct the parent-child launch chain.
      • Use 4689 to confirm whether the process exited immediately or remained active.
    4. Check whether the token was changed after process start.
      • Review 4696 to see whether a primary token was assigned to a process.
      • Review 4703 to determine whether a user right was adjusted.
      • These two events help distinguish a normal process start from a process whose effective privileges were modified.
    5. Validate the logon context.
      • Review 4672 for the same account and time range. This event shows that special privileges were assigned to a new logon.
      • If the activity appears tied to remote or unexpected access, also review common Security logon events in the same log:
        • 4624 – Logon
        • 4634 – Logoff
      • This establishes whether the privilege use came from an expected interactive or other logon session.
    6. Interpret volume and noise correctly.
      • Audit Sensitive Privilege Use has High event volume.
      • Audit Non-Sensitive Privilege Use has Very High event volume.
      • Audit Process Tracking can generate a large number of events, but it is especially useful during incident response because it provides detailed process start and timing data.
      • On single-role infrastructure servers such as domain controllers, process tracking can be left enabled more safely because normal process traffic is lower.
    7. Decide whether the behavior is likely legitimate.
      • More likely legitimate when the sequence is consistent: expected logon, expected 4672, expected 4688 process creation, and no unusual 4696 or 4703 token changes.
      • More suspicious when privilege-use events appear without an expected process chain, when token assignment or right adjustment events appear unexpectedly, or when the logon context is not expected for that account.
    8. If the issue involves repeated authentication or service-account behavior, correlate lockout and failed-logon events as well.
      • 4740 identifies account lockouts and includes the caller computer name.
      • 4625 shows failed logons around the same time and can help identify the source workstation and failure details.

    If the goal is to keep this enabled through policy, Audit Sensitive Privilege Use can be configured through Group Policy at: Windows Settings > Security Settings > Advanced Audit Policy Configuration > System Audit Policies > Privilege Use

    For MDM-managed devices, the CSP setting is: ./Device/Vendor/MSFT/Policy/Config/Audit/PrivilegeUse_AuditSensitivePrivilegeUse with values:

    • 0 = Off/None
    • 1 = Success
    • 2 = Failure
    • 3 = Success+Failure
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.