Windows Security Audit Policy and Event Log Investigation in Practice — Becoming an IT Team That Can Read Event 4625

“An account has been locking out repeatedly since last night. Please find out why.” “I want to check whether anyone has been trying to sign in with a departed employee’s account.” “Can you tell me who did what, and when, on this server?” — these are the requests that IT staff at small and medium-sized businesses, or developers who have delivered a system to a client, suddenly receive one day. And the thing they end up relying on is Windows’ Security event log.

But when you actually open Event Viewer, two realities are waiting for you. The event you want to see was never recorded (the audit policy wasn’t enabled), or it’s buried under a mountain of events you can’t read (drowned in noise and bloat). Security auditing is something you can capture “if you enable it,” but unless you design what to capture and how far, it won’t help you when you actually need it.

This article lays out the mechanics of audit policy (the two systems — basic and advanced), the subcategories you should enable at minimum in a small-to-midsize environment, how to read the standard event IDs — 4624/4625/4740/4688 and others — Security log capacity design, and how to investigate with PowerShell, all based on primary sources as of August 2026. If the NTLM auditing, SMB signing, BitLocker, and firewall articles this site has covered are all about “hardening your defences,” this article is about “making it possible to confirm afterwards what happened” — a sequel that ties them together.

1. The Bottom Line First

• Audit policy has two systems — “basic” and “advanced (Advanced Audit Policy)” — and you must not mix them. Microsoft explicitly states that using both leaves your audit results in an unpredictable state. Standardise on the advanced side (40-plus subcategories).¹
• Check the current state with auditpol /get /category:*. This lists what’s actually in effect right now, regardless of whether it came from a GPO or a local setting.²
• “Enable everything” is something you must never do. Enabling subcategories that generate huge event volumes buries the events that actually matter under noise, and it affects performance too. Start from Microsoft’s baseline recommendations and add only what you need.³⁴
• A successful sign-in is 4624; a failed one is 4625. For 4624, read “what kind of sign-in it was” from the logon type (2 = Interactive, 3 = Network, 10 = RemoteInteractive, and so on).⁵
• For 4625, the Status/Sub Status code tells you the reason for failure. The standard ones are 0xC0000064 = non-existent user name, 0xC000006A = wrong password, 0xC0000072 = disabled account, and 0xC0000234 = account locked out.⁶
• Where an event gets recorded is fixed. 4624/4625 are recorded on the machine being accessed; credential validation (4776) and Kerberos pre-authentication failure (4771) are recorded on the domain controller. Look at the wrong machine and you’ll mistakenly conclude “there’s no log.”⁶⁷⁸
• Half of Security log design is the container itself — maximum size and retention. If retention is set to overwrite, old events disappear first. Check the maximum size and record count with Get-WinEvent -ListLog Security, and expand it by working backwards from the number of days you actually need to keep.⁹¹⁰
• Command-line logging for process creation (4688) is powerful, but it comes at the cost of secrets landing in the log in plain text. Audit your scripts before you enable it.¹¹¹²

2. Audit Policy Basics — Do Not Mix “Basic” and “Advanced”

Windows audit policy comes in two systems.¹

• Basic audit policy: the nine category settings under “Local Policies > Audit Policy.” This is the older system, dating from before Windows Vista.
• Advanced Audit Policy Configuration: the 40-plus subcategory settings under “Security Settings > Advanced Audit Policy Configuration.” It breaks each basic category down into several subcategories — for example, the single basic category “Audit account logon events” corresponds to four subcategories on the advanced side. Enabling one basic category has the same effect as enabling every one of its corresponding subcategories, which records a large volume of events you may not actually be interested in.¹

The important point is that these two systems are not compatible with each other. Microsoft states plainly: “Don’t use both basic and advanced audit policy — doing so can result in unexpected auditing results.” When advanced audit policy is applied via Group Policy, that computer’s existing audit settings are first cleared and then the advanced settings are applied; from that point on, only the advanced side can reliably control auditing. In environments that use the advanced side, enable the security option “Audit: Force audit policy subcategory settings to override audit policy category settings” so that the basic settings can’t overwrite it (this is enabled by default on standalone machines).¹⁴

Checking the current state is a single command, run from an administrative command prompt.²

rem list the audit settings currently in effect, by subcategory
auditpol /get /category:*

rem back up the current settings to CSV before making changes, and restore them
auditpol /backup /file:C:\logs\auditpol-backup.csv
auditpol /restore /file:C:\logs\auditpol-backup.csv

The output of auditpol is “the policy that is actually in effect as a result,” regardless of whether it originates from a GPO or a local setting. It’s also useful for cross-checking when a setting distributed via GPO doesn’t seem to have taken effect. Note that a change to the audit settings themselves is recorded as event 4719, so “auditing got turned off without anyone noticing” can also be traced after the fact.¹²

3. A Decision Table for the Minimum Subcategories to Enable

The reason “just enable everything, to be safe” is a bad move is clear. For example, Microsoft warns that auditing success for the privilege-use subcategories generates such an enormous volume of events that it becomes hard to find other entries in the security log, and it can also have a significant impact on performance.⁴ The log’s container (Section 5) is finite, so the more noise you record, the more it eats into the retention period for the events you actually need. Audit design is really about deciding what not to record.

Microsoft publishes baseline and stronger recommendations broken down by workstation and server, and these are the starting point.³ From there, the table below is organised around the small-to-midsize-environment perspective of “what do we minimally want to be able to read during an incident.”

Conversely, it’s generally safest not to touch file system or registry object-access auditing, privilege use, or the packet-filter subcategories (5152 and so on) by default. These are useful when you scope them to a targeted SACL configuration or a time-limited investigation, not as something left permanently on across the board — doing so will eat your log alive.⁴

4. How to Read the Standard Event IDs

4.1. 4624 — Successful Sign-ins Are Sorted by Logon Type

4624, “An account was successfully logged on,” is recorded on the machine where the logon session was created (the machine being accessed).⁵ Because it’s a high-volume event, the first step in reading it is to sort by Logon Type.⁵

Other fields worth checking alongside this are the account name under “New Logon,” the source address under “Network Information,” the “Authentication Package” (NTLM or Kerberos), and “Elevated Token” (whether the session has administrative privilege). If you want to track only sign-ins with administrative privilege, event 4672 (Special privileges assigned to new logon), recorded under the same Logon ID, is also useful.⁵

4.2. 4625 — Pin Down the Failure Reason With the Status/Sub Status Code

4625, “An account failed to log on,” is recorded on the machine where the logon was attempted.⁶ Rather than trusting the wording of the “Failure Reason” field, the reliable way to read it is by the hexadecimal Status/Sub Status code. The standard ones are as follows.⁶

• 0xC0000064: Non-existent user name. A rapid succession of these in a short window can indicate an account-enumeration attack
• 0xC000006A: Wrong password. Repeated failures against a specific account can indicate a password-guessing attack
• 0xC000006D: Invalid user name or authentication information
• 0xC000006F: Outside the allowed logon hours
• 0xC0000070: From a workstation that isn’t permitted
• 0xC0000072: Account disabled by an administrator (attempts against a departed employee’s account show up here)
• 0xC000015B: The requested logon type isn’t allowed on this machine
• 0xC0000193: Expired account
• 0xC0000234: Locked out

“Who, from where, and why it failed” is pinned down by the trio of the target account, the source (workstation name / IP address), and this code. Section 6 includes PowerShell that extracts all three together in one go.

4.3. 4740 — The Source of a Lockout Is the “Caller Computer Name”

4740, “A user account was locked out” (subcategory: User Account Management). The key field in this event is “Caller Computer Name,” which records the computer that originated the logon attempt that triggered the lockout.¹⁶ The standard procedure is to identify the machine of origin from this field, and then hunt for old credentials still stored on that machine. In most cases the cause is something that keeps using old credentials after a password change — saved credentials, a disconnected RDP session left hanging, or a service or scheduled task configured with the old password.

There’s one thing to watch out for. 4625 is recorded on the computer that received the logon attempt. If the cause is a network logon from the originating machine to, say, a file server, no 4625 is left on the originating machine’s own Security log; instead the trail is left in 4625 on the destination server, or, for a domain account, in 4776 (NTLM) or 4771 (Kerberos pre-authentication failure) on the DC.⁷⁸ When “there’s nothing in the log on the originating machine,” go and look at the receiving side.

4.4. The 4720 Family — Account Creation, Modification, and Group Additions

The account management events form a run of adjacent numbers: 4720 (user account created)¹⁷, 4726 (deleted), 4738 (modified), and, on the group side, member added/removed. Note that which event ID fires for a group membership change depends on the type of group. It’s 4732/4733 for local groups, 4728/4729 for global groups, and 4756/4757 for universal groups.¹⁴ Domain Admins is a global group, so an addition to it shows up as 4728 — if you alert only on 4732, you’ll miss precisely the event you most want to catch. Day to day this is mostly a record of help-desk work, but “a standard user was suddenly added to an administrative group” or “an account nobody recognises was just created” warrants investigation even as a single occurrence. Microsoft itself gives unexpected additions of members to privileged groups as an example of an event worth alerting on individually.³

4.5. 4688 — Process Creation. Command-Line Logging Is a Separate Switch

4688, “A new process has been created,” records the creating account, the new process’s executable path, the parent process, and the token elevation type every time a process is created.¹¹ It’s an event with high investigative value that can answer “who ran what on this server.”

By default, however, command-line arguments are not recorded. Only once you separately enable the Group Policy setting “Include command line in process creation events” (Administrative Templates > System > Audit Process Creation) does the “Process Command Line” field of 4688 get populated with arguments.¹¹¹² This is effectively essential for tracing suspicious launches such as powershell -EncodedCommand ..., but enable it only after understanding the risk of secret exposure described in Section 7.

4.6. 4698 — Scheduled Task Creation

4698, “A scheduled task was created,” records the task name and the full XML of the task definition (including the command it runs). Because registering a scheduled task is a common technique malware uses to survive a reboot, Microsoft recommends monitoring task-creation events.¹⁵ Even in environments that use scheduled tasks heavily for business purposes, creation itself is not something that happens every day, so the noise level stays comparatively small.

Another one worth remembering is 1102, “The audit log was cleared.” Clearing the Security log always leaves this event behind, so if you find “the log is empty,” it lets you distinguish an incident from a routine operation.¹⁸

5. Designing the Log’s Container — Maximum Size and Retention

Before you add more audit policy, check the receiving vessel. The Security log has a maximum size and a retention mode: in overwrite mode (the typical configuration), once the maximum size is reached, new events overwrite the oldest ones. Conversely, in retention mode (do-not-overwrite), once the log fills up, it’s the new events that get discarded instead.¹⁰ Either behaviour can leave you with “the log I needed just isn’t there,” so understanding the current state comes first.

# Check the Security log's container: retention mode, maximum size, current record count
Get-WinEvent -ListLog Security |
    Select-Object LogName, LogMode, MaximumSizeInBytes, RecordCount

# How many days are actually being retained right now (timestamp of the oldest event)
Get-WinEvent -LogName Security -Oldest -MaxEvents 1 |
    Select-Object TimeCreated

Get-WinEvent -ListLog returns the log’s configuration and record count together.⁹ The difference between “the oldest event’s timestamp” and the current time is the actual retention period; if that falls short of your requirement (how many days back you want to be able to investigate), expand the maximum size. You can configure this with wevtutil sl Security /ms:<byte count>, or distribute it via Group Policy.¹⁰

There is also a security option called “Audit: Shut down system immediately if unable to log security audits” (commonly known as CrashOnAuditFail). When enabled, if the system becomes unable to record an audit event, it stops with STOP error C0000244. It exists for authentication requirements that absolutely cannot afford to lose an audit trail, and it is disabled by default. Microsoft itself warns that this can be turned into a DoS, with an attacker deliberately generating a flood of events to stop a server — so it is not something to enable casually in a typical small-to-midsize environment.¹⁹

6. Practical Investigation — Filtering, Get-WinEvent, and Export

6.1. Narrowing Down in Event Viewer

For a one-off investigation, Event Viewer is enough. Open the Security log and specify an event ID (say, 4625) and a time range with “Filter Current Log.” Save conditions you check repeatedly as a “Custom View” so they’re a single click away next time. If you want to narrow down by a specific account rather than just an event ID, you can edit the XPath query directly on the XML tab of the filter dialog.

6.2. Extraction With Get-WinEvent

For investigations with large record counts, multiple conditions, or scheduled runs, switch to PowerShell’s Get-WinEvent. The key point is to use -FilterHashtable, which applies the filter on the server side.⁹

# Get sign-in failures (4625) from the last 24 hours
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
}

# Shape "who, from where, and why" into a table
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4625
    StartTime = (Get-Date).AddDays(-1)
} | ForEach-Object {
    $x = [xml]$_.ToXml()
    $d = @{}
    $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    [pscustomobject]@{
        Time      = $_.TimeCreated
        Account   = "$($d.TargetDomainName)\$($d.TargetUserName)"
        LogonType = $d.LogonType
        Source    = "$($d.WorkstationName) $($d.IpAddress)"
        Status    = $d.Status
        SubStatus = $d.SubStatus
    }
} | Group-Object Account, Status, SubStatus, Source |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Once you have this pattern of pulling EventData out of an event’s XML representation, you can reuse it as-is for 4624 or 4688. The design of Get-WinEvent filtering — when to use FilterHashtable versus XPath, and how to fix a slow query — is covered in detail in “Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes.”

6.3. Exporting With wevtutil

The rule for the logs on the machine under investigation is to export them and secure a copy first, before they get overwritten.¹⁰

rem preserve the whole Security log as an evtx
wevtutil epl Security C:\logs\security-20260801.evtx

rem export only the 4625 events, narrowed down with XPath
wevtutil epl Security C:\logs\security-4625.evtx /q:"*[System[(EventID=4625)]]"

An exported .evtx can be analysed on another machine in exactly the same way, with Get-WinEvent -Path C:\logs\security-20260801.evtx.⁹ The habit of preserving before analysing is the same mindset as “secure the dump first” during crash investigation (see “An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg”).

7. Pitfalls — Four That Are Easy to Hit in the Field

(1) Secrets end up in the 4688 command line. Enabling command-line logging puts every process’s arguments into the Security log in plain text. Microsoft states explicitly that “any user with read access to security events would be able to read the command-line arguments for every successfully created process. Command-line arguments may contain sensitive or private information such as passwords.” ¹² If even one line-of-business application or script launches something like myapp.exe /user:admin /password:P@ssw0rd, that’s a secret disclosed to everyone who can view the log. Before enabling this, audit for places that pass secrets as command-line arguments and fix them. Wherever you export or forward the log to also needs to be handled at the same level of confidentiality.

(2) Operating without knowing what happens when the log fills up. In overwrite mode, old evidence quietly disappears; in do-not-overwrite mode, new events get discarded; and with CrashOnAuditFail enabled, the whole system stops (Section 5).¹⁰¹⁹ The right approach is to know which behaviour you’ve chosen, and to put a mechanism in place — scheduled exports, or a log collection platform — that collects the data before it’s overwritten.

(3) Domain controllers and workstations require you to look at different logs. 4624/4625 are recorded on the machine that was accessed.⁵⁶ Credential validation for a domain account (NTLM’s 4776), on the other hand, is recorded on the machine that has authority over the credential — for a domain account, that’s the DC⁷ — and Kerberos pre-authentication failure (4771) is recorded only on a DC.⁸ “No 4625 on the file server” does not mean “there was no attack”; you only get the full picture once you also cross-check 4776/4771 on the DC. See “NTLM and Kerberos Explained with Diagrams” for how each authentication protocol actually flows.

(4) Clock drift breaks correlation. Lining up logs from several machines to trace “which workstation produced a 4625 right before this 4740” only works if every machine’s clock agrees. In a domain environment, Kerberos itself imposes an upper bound on clock drift (5 minutes by default), beyond which authentication itself starts to fail.²⁰ From an investigative standpoint, a drift of even a few seconds — never mind five minutes — can lead you to misread the order of events, so checking w32time’s synchronisation status should be the very first step of your investigation procedure. Also keep in mind that event timestamps are stored in UTC and displayed according to the viewing machine’s own time zone, so remember to convert time zones when reading an .evtx brought back from an overseas site or a server configured for UTC.

8. Summary

• Audit policy has two systems, “basic” and “advanced,” and mixing them produces unpredictable results. Standardise on the advanced side, check the current state with auditpol /get /category:*, and design from there.
• “Enable everything” kills your investigation through noise and bloat. Start from Microsoft’s baseline recommendations and work through the decision table in Section 3, built around logon, account management, and process creation.
• 4624 is read by logon type, 4625 by Status/Sub Status code, 4740 by Caller Computer Name, and 4688 by parent process and command line — each event has a specific field you need to check.
• The log’s container (maximum size and retention mode) is half of audit design. Check how many days are actually being retained, size it by working backwards from your requirement, and export or aggregate it before it’s overwritten.
• Audit for the risk of secret exposure before enabling command-line logging for 4688. Where each event gets recorded, and clock synchronisation, are prerequisites for cross-machine correlation.
• Start an investigation with Event Viewer’s filters; switch to Get-WinEvent -FilterHashtable for anything repeated; preserve with wevtutil epl. Never break the order of “preserve first, then analyse.”

Related Articles

• Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes
• Will NTLM Deprecation Stop Your Business Apps? — How to Collect Audit Logs, and the Order in Which to Kill Dependencies
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• SMB Signing and LDAP Channel Binding — Closing the “Other Half” of Your NTLM Defences in Practice
• An Introduction to Windows Event Log and ETW — Putting Your Business App’s Logs on the OS’s Standard Mechanisms
• An Introduction to Collecting Windows Crash Dumps - WER/ProcDump/WinDbg

Related Consulting Areas

KomuraSoft LLC handles consultations on Windows audit policy and log design, investigations into “when, who, and what” based on event logs, and root-cause analysis of the authentication- and audit-related trouble that business applications run into. It’s fine to start from the stage of “I’ve been told to look at the logs, but I don’t know where to begin.”

• Bug Investigation & Root-Cause Analysis
• Technical Consulting & Design Review
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

We haven't configured any audit policy, so why are 4624 and 4625 already showing up in the Security log?

Because Windows has audit subcategories that are enabled by default. The "Logon" subcategory, for instance, has had both success and failure auditing enabled by default since Windows 10 version 1809, so 4624 (success) and 4625 (failure) get recorded even if you have configured nothing yourself. With the defaults left as they are, though, many of the events you actually want during an investigation — credential validation (4776) or process creation (4688), for example — are not recorded. You can check what is enabled on your own environment with `auditpol /get /category:*`. From there, the standard practice is to explicitly enable whatever subcategories are missing on the advanced audit policy side.

I want to investigate a failed sign-in, but I can't find event 4625 in the Security log on the target server. Where should I look?

First confirm the basic principle: 4625 is recorded on "the computer where the logon was attempted." For a failed sign-in at a user's workstation, that's the workstation; for a failed access attempt against a file server, that's the file server. Next, use `auditpol /get /category:*` to check whether failure auditing is enabled for the "Logon" subcategory. For domain accounts, the trail often shows up instead in credential validation (4776) or Kerberos pre-authentication failure (4771) on the domain controller, and when you can't pin down which workstation is involved, it is often quicker to start from the DC side. If you still can't find anything, check whether older events have already been overwritten (compare the log's maximum size against the timestamp of the oldest event).

Should we enable command-line logging for process creation (4688)?

It has very high investigative value, but it is a setting you should only enable once you understand the risk. Once enabled, the command-line arguments of every process are recorded in the Security log in plain text. If even one script or line-of-business application passes a password or an API key as a command-line argument, that secret becomes visible to everyone who can read the Security log. Microsoft itself documents this caution explicitly. The recommended order is to first check whether your own scripts pass secrets as command-line arguments, fix any that do, and only then enable the setting.

How large should the Security log's maximum size be?

The correct approach is to work backwards from "how many days do we want to keep on hand," not to pick a one-size-fits-all number. You can check the current setting and how it's actually behaving with `Get-WinEvent -ListLog Security`; the difference between the timestamp of the oldest event and the current time is "how many days are actually being retained right now." Adding more audit subcategories increases event volume, so always re-check this actual retention span after changing your settings. Incident response not infrequently needs logs from weeks or months back, so it's reassuring to either export the log regularly before it gets overwritten, or aggregate it onto a separate machine with a log collection mechanism.

How do I investigate the cause of an account lockout (4740)?

The first clue is the "Caller Computer Name" field in the 4740 event. It records the computer that originated the failed logon attempt that triggered the lockout. Note, however, that the failure record itself (4625) is left on the side that received the logon attempt, not on the machine of origin. If it originated from a network logon, follow it chronologically through 4625 on the destination server, or, for a domain account, through 4776/4771 on the domain controller. Once you've identified the machine of origin, check it for anything still holding old credentials from before the password change — saved credentials, a disconnected Remote Desktop session left hanging, or a service or scheduled task configured with the old password. If lockouts keep recurring, also check whether clock synchronisation has drifted.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.