Windows Security EVTX Log Fields: Reference With Examples

  <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
    <System>
      <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
      <EventID>4624</EventID>
      <TimeCreated SystemTime="2024-03-20T07:58:01.123456789Z" />
      <Computer>WKS-ALICE.contoso.com</Computer>
      <Security UserID="S-1-5-18" />
    </System>
    <EventData>
      <Data Name="SubjectUserName">ALICE$</Data>
      <Data Name="SubjectDomainName">CONTOSO</Data>
      <Data Name="TargetUserName">alice.johnson</Data>
      <Data Name="TargetDomainName">CONTOSO</Data>
      <Data Name="LogonType">2</Data>
      <Data Name="IpAddress">10.1.1.50</Data>

What it records

Each record in a Windows Security event log is one audited event: a logon, a failed logon attempt, a privilege assignment, a process creation, an account or group change, a scheduled task registration. Rendered as XML, every record has the same two halves. The System section identifies the record — the provider that wrote it, the EventID, the TimeCreated timestamp in UTC, the Computer the log belongs to, and the SID of the security context under Security UserID. The EventData section holds the event-specific payload as Data elements, each with a Name attribute such as TargetUserName, LogonType, IpAddress, Status or SubStatus.

Which Data elements appear depends entirely on the event ID. A 4624 describes who logged on, how and from where; a 4625 adds Status, SubStatus and FailureReason; a 4688 carries NewProcessName, CommandLine and ParentProcessName; a 4728 carries MemberName and MemberSid. Treat EventID as the schema selector before reading anything else.

Where to get it

The live log is %SystemRoot%\System32\winevt\Logs\Security.evtx, which cannot be copied while in use without a backup API. Practical sources:

# Export the Security log to a portable .evtx file
wevtutil epl Security C:\export\Security.evtx

# Render failed logons as XML
wevtutil qe Security /q:"*[System[(EventID=4625)]]" /f:xml /c:50

# Or read an exported file in PowerShell
Get-WinEvent -Path C:\export\Security.evtx -FilterXPath "*[System[(EventID=4625)]]" |
  ForEach-Object { $_.ToXml() }

At scale the same records arrive through Windows Event Forwarding, an EDR agent, or the Azure Monitor Agent, where they land in Microsoft Sentinel’s SecurityEvent table with the Data names exposed as columns.

Parsing pitfalls

• Binary on disk, XML only when rendered. Anything that reads EVTX as text finds nothing useful. The XML in these samples is the rendered form.
• No message text in the record. The readable description comes from the provider’s message resources, so exports and SIEM rows show field values only.
• Named Data elements are not guaranteed. When a template is missing or a provider emits positional values, you get bare <Data> elements and must rely on order instead of names.
• Hex case varies. 0xC000006D renders uppercase here and lowercase elsewhere; compare case-insensitively (in KQL, =~).
• Placeholder values. IpAddress and WorkstationName are often -; addresses may arrive IPv6-mapped. Strip and normalise before joining on them.
• Client-supplied fields lie. WorkstationName and the account name are whatever the client sent.
• Status is not one thing. On 4625 it is an NTSTATUS value; on 4768 and 4771 it holds a Kerberos code, and on 4776 the sample shows 0x0 for a successful validation. Interpret it per event ID.
• Event IDs repeat across providers. Always filter on Provider Name as well.
• UTC. SystemTime is UTC with sub-second precision, while Event Viewer shows local time — a common source of timeline drift.

Detection ideas

• Password spraying: one IpAddress producing 4625 events with SubStatus 0xc000006a across many distinct TargetUserName values in a short window, as in the malicious sample — the basis of the 4625 password-spray rule.
• Name guessing: the same burst but with 0xc0000064, meaning the names do not exist.
• Brute force that succeeded: a run of 4625 for one account followed by a 4624 with LogonType 3 from the same address, then 4672 showing privileged rights.
• Persistence after takeover: 4720 creating an account and 4728 adding it to a privileged group by the same SubjectUserName, followed by 4698 registering a scheduled task.
• Kerberos failures: 4771 and 4768 with a non-zero Status on a domain controller, read against the Kerberos failure codes.

The browser log analyzer runs these checks on an exported XML file locally.