Security.evtx — Windows Security Event Log

Every logon attempt, every failed password, every process launched, every scheduled task created, every time an administrator clears the audit log — the Windows Security event log records it all. For investigators, Security.evtx is the authoritative record of who did what, when, and from where. It is the first artifact examined in every intrusion investigation, every insider threat case, and every privilege escalation incident.

What Is Security.evtx?

Security.evtx is the Windows Security event log — the primary audit log for the operating system. It is generated by the Local Security Authority Subsystem Service (LSASS) and written by the Windows Event Log service. Unlike the System and Application logs, which record operational events from services and software, the Security log records security-relevant events: authentication attempts, privilege use, audit policy changes, object access, and process creation. Every event in the Security log is the result of an audit policy configuration — if an audit category is not enabled, the corresponding events are not generated.

The EVTX format was introduced in Windows Vista, replacing the legacy EVT format from Windows NT/2000/XP. EVTX files are structured as a header followed by 64 KB chunks, each containing binary XML records with CRC32 integrity checksums. This format supports Unicode strings, structured XML data (including nested key-value pairs for event-specific fields), and per-chunk checksums that enable detection of record tampering. Each event record contains a System section (EventID, TimeCreated, Computer, Security) and an EventData section containing event-specific fields like LogonType, TargetUserName, IpAddress, and CommandLine.

The default configuration on Windows desktop editions generates a minimal set of events — primarily logon/logoff (4624/4634) and account management events. On domain controllers, a broader set is enabled by default. However, many of the most forensically valuable events — including process creation with command-line logging (4688), detailed object access (4663), and scheduled task creation (4698) — require explicit audit policy configuration via Group Policy or auditpol.exe. Organizations that have not configured Advanced Audit Policy will have significant gaps in their Security log.

Location & Format

File Paths

EVTX Binary Format

An EVTX file begins with a 4,096-byte file header containing the signature ElfFile\x00, the oldest and newest record numbers, the chunk count, and file-level flags. The remainder of the file consists of 64 KB chunks, each beginning with the signature ElfChnk\x00 and containing a chunk header, binary XML event records, and a CRC32 checksum over the chunk data. Each event record is a binary XML structure containing a System element (with EventID, TimeCreated, Computer, Channel, Security SID) and an EventData element with event-specific key-value pairs.

The binary XML encoding uses opcodes for element start, element end, attribute, and value tokens. Strings are stored as UTF-16LE with length prefixes. Templates are used to avoid repeating the same XML structure for events of the same type — the template defines the structure, and each record only stores the variable data. This encoding makes EVTX files compact but not human-readable without a parser.

Key Event IDs

LogonType Values

What It Reveals

Security.evtx provides answers to the foundational questions of any intrusion investigation. The following investigative questions are directly answerable from Security event log data:

• Who authenticated to this system, and from where? — Event ID 4624 records the TargetUserName, LogonType, IpAddress, and WorkstationName for every successful logon. Type 10 (RemoteInteractive) logons from unexpected IP addresses are the primary indicator of RDP-based lateral movement.
• Were there brute-force or password-spraying attacks? — Event ID 4625 clusters reveal failed authentication attempts. The Status and SubStatus fields distinguish between wrong password (0xC000006A), unknown user (0xC0000064), and account lockout (0xC0000234). High-volume 4625 events from a single IpAddress indicate brute force; low-volume 4625 events spread across many accounts indicate password spraying.
• What processes were executed, and by whom? — Event ID 4688 records NewProcessName, CommandLine (if configured), ParentProcessName, and SubjectUserName. This is the primary evidence for PowerShell-based attacks, LOLBin abuse, and malware execution.
• Was privilege escalation performed? — Event ID 4672 records when special privileges (SeDebugPrivilege, SeImpersonatePrivilege, SeTcbPrivilege) are assigned to a logon session. Event ID 4732 records when a user is added to a privileged group (Administrators, Domain Admins).
• Were scheduled tasks created for persistence? — Event ID 4698 contains the complete XML definition of a newly created scheduled task, including the command to execute, the trigger schedule, and the user context. This is one of the most common persistence mechanisms.
• Was there Kerberoasting activity? — Event ID 4769 with TicketEncryptionType 0x17 (RC4-HMAC) requested for a service account from a workstation IP (not a server) indicates Kerberoasting — an attacker requesting service tickets encrypted with a weak cipher to crack offline.
• Were new user accounts created? — Event ID 4720 records user account creation. An account created at 03:00 by a compromised service account is a strong indicator of persistence.
• Was the audit log cleared to destroy evidence? — Event ID 1102 is generated in the new, empty log after the Security log is cleared. It records the user who performed the clearance. This event cannot be suppressed — clearing the log always generates 1102.
• Were files accessed? — Event ID 4663 records object access attempts. Combined with a properly configured SACL, it can prove that a specific user accessed a specific file at a specific time — critical for data exfiltration and insider threat cases.
• Were explicit/alternate credentials used? — Event ID 4648 records when a process authenticates using credentials different from the current logon session. This detects runas usage, Pass-the-Hash, and credential theft tools.

Forensic Use Cases

1. Brute-Force and Password-Spraying Detection

An investigation reveals a compromised domain admin account. The Security log on the domain controller shows 4,200 Event ID 4625 entries for the account svc_backup over a 90-minute window, all from a single source IP that belongs to an employee workstation. The SubStatus code 0xC000006A (wrong password) is consistent across all failures. At 02:47:12 UTC, a single Event ID 4624 (Type 3) from the same source IP indicates the password was guessed correctly. Within 60 seconds, Event ID 4672 shows special privileges assigned, and 4688 events show cmd.exe spawning net group "Domain Admins" /add attacker_user /domain. The timeline from initial brute force to domain compromise is 92 minutes.

2. Lateral Movement via RDP

After an initial compromise, an attacker pivots through the network using stolen credentials. The Security log on each host shows Event ID 4624 with LogonType 10 (RemoteInteractive) from the source IP of the previously compromised host. By correlating 4624 Type 10 events across multiple systems, the investigator maps the complete lateral movement chain: Workstation A (initial access) to Server B (file server) to Server C (domain controller). Each hop is timestamped with sub-second precision. The TargetUserName field shows the attacker used three different accounts during the lateral movement, escalating from a standard user to a domain admin.

3. Kerberoasting Detection

An attacker with a compromised standard domain user account requests Kerberos service tickets for service accounts. The domain controller’s Security log shows Event ID 4769 entries with TicketEncryptionType 0x17 (RC4-HMAC) for service accounts svc_sql, svc_exchange, and svc_backup, all requested from a workstation IP within a 30-second window. Normal service ticket requests use AES-256 (0x12). The RC4 encryption type is specifically requested because it is weaker and the resulting ticket can be cracked offline. The investigator identifies the attacking workstation, the compromised user, and the targeted service accounts from a single query of the Security log.

4. Persistence via Scheduled Tasks

During an incident response engagement, the investigator finds Event ID 4698 in the Security log showing a scheduled task named WindowsUpdateCheck created at 03:14 UTC by user SYSTEM. The TaskContent XML within the event data reveals the task executes powershell.exe -ep bypass -enc [base64] every 4 hours. Decoding the Base64 reveals a PowerShell download cradle that fetches and executes a second-stage payload from an attacker-controlled domain. The task was created via schtasks.exe, which is also visible in Event ID 4688 with the full command line.

5. Log Tampering Detection

An attacker who has gained SYSTEM-level access attempts to cover their tracks by clearing the Security log using wevtutil cl Security. The act of clearing the log generates Event ID 1102 in the fresh, empty log — recording the username and timestamp of the clearance. The investigator also finds Event ID 7036 in the System log showing the Windows Event Log service was restarted. On systems with Windows Event Forwarding (WEF) configured, the forwarded copies of the pre-clearance events survive on the collection server, providing a complete record despite the local log destruction.

Acquisition Methods

Live System — wevtutil Export

:: Export a consistent copy of the Security log
wevtutil epl Security C:\Evidence\Security.evtx

:: Export with locale-independent rendering
wevtutil epl Security C:\Evidence\Security.evtx /lf:true

:: Export all event logs (recommended for complete collection)
for /f "tokens=*" %l in ('wevtutil el') do wevtutil epl "%l" "C:\Evidence\EventLogs\%l.evtx" 2>nul

:: Query recent Security events as XML (live triage)
wevtutil qe Security /q:"*[System[TimeCreated[timediff(@SystemTime) <= 86400000]]]" /f:xml > C:\Evidence\Security_Last24h.xml

Live System — KAPE and Velociraptor

:: Using KAPE (Kroll Artifact Parser and Extractor)
kape.exe --tsource C: --tdest C:\Evidence\KAPE_Output --target EventLogs

:: Using Velociraptor (remote collection via VQL)
:: Artifact: Windows.KapeFiles.Targets with target "EventLogs"
:: Or directly:
:: SELECT * FROM glob(globs="C:/Windows/System32/winevt/Logs/*.evtx")

:: Using PowerShell (live query for quick triage)
Get-WinEvent -LogName Security -MaxEvents 1000 | Export-Csv C:\Evidence\Security_Recent.csv -NoTypeInformation

Forensic Image — Direct Extraction

# Mount the forensic image (read-only)
mount -o ro,noexec,nodev /dev/sdb1 /mnt/evidence

# Copy all event logs
cp /mnt/evidence/Windows/System32/winevt/Logs/*.evtx /analysis/eventlogs/

# Verify file integrity (check for truncation)
ls -la /analysis/eventlogs/Security.evtx
# A Security.evtx that is exactly 20,971,520 bytes (20 MB) has reached
# its maximum configured size and has been rolling over

Parsing Tools & Analysis

Parsing with EvtxECmd (Eric Zimmerman)

:: Parse Security.evtx to CSV with event map resolution
EvtxECmd.exe -f C:\Evidence\Security.evtx --csv C:\Analysis\EvtxOutput --csvf Security_Parsed.csv

:: Parse all EVTX files in a directory
EvtxECmd.exe -d C:\Evidence\EventLogs --csv C:\Analysis\EvtxOutput

:: Output fields include:
::   TimeCreated, EventId, Level, Provider, Channel,
::   Computer, UserId, MapDescription, PayloadData1-6

Threat Hunting with Chainsaw

# Run Chainsaw with Sigma rules against collected event logs
chainsaw hunt /analysis/eventlogs/ \
    --sigma-rules /opt/sigma/rules/ \
    --mapping /opt/chainsaw/mappings/sigma-event-logs-all.yml \
    --output /analysis/chainsaw_results.json \
    --json

# Search for specific event IDs
chainsaw search /analysis/eventlogs/ \
    --kind evtx \
    --event-id 4624,4625,4672,4688,1102 \
    --output /analysis/key_events.json

Analysis Script — Failed Logon Clustering

# Identify brute-force attacks by clustering failed logon events

import pandas as pd

df = pd.read_csv('/analysis/EvtxOutput/Security_Parsed.csv', low_memory=False)

# Filter for failed logon events (4625)
failed = df[df['EventId'] == 4625].copy()
failed['TimeCreated'] = pd.to_datetime(failed['TimeCreated'])

# Group by source IP and target account
clusters = failed.groupby(['PayloadData3', 'PayloadData1']).agg(
    FailCount=('EventId', 'count'),
    FirstAttempt=('TimeCreated', 'min'),
    LastAttempt=('TimeCreated', 'max')
).sort_values('FailCount', ascending=False)

clusters.columns.name = None
print('=== Brute Force Candidates (>10 failures) ===')
print(clusters[clusters['FailCount'] > 10].head(20).to_string())

# Check if any attacking IPs also have successful logons
success = df[df['EventId'] == 4624]
attacker_ips = clusters[clusters['FailCount'] > 10].reset_index()['PayloadData3'].unique()
compromised = success[success['PayloadData3'].isin(attacker_ips)]

print(f'\n=== Successful logons from attacking IPs: {len(compromised)} ===')
for _, row in compromised.iterrows():
    print(f'  {row["TimeCreated"]}  {row["PayloadData1"]}  from {row["PayloadData3"]}  Type {row["PayloadData2"]}')

Sample Output

=== Brute Force Candidates (>10 failures) ===
                                         FailCount  FirstAttempt          LastAttempt
PayloadData3    PayloadData1
192.168.14.22   svc_backup                    4,217  2026-03-15 01:14:32   2026-03-15 02:46:58
10.0.50.8       administrator                   312  2026-03-14 22:08:11   2026-03-14 23:41:07
192.168.14.22   admin                            47  2026-03-15 00:52:14   2026-03-15 01:14:28

=== Successful logons from attacking IPs: 1 ===
  2026-03-15 02:47:12  svc_backup  from 192.168.14.22  Type 3

Retention & Persistence

Anti-Forensics Resilience

The Security event log is a high-value target for attackers who want to cover their tracks. Unlike SRUM.db or Windows.edb, which are rarely targeted because they are not widely known, the Security log is the first thing a sophisticated attacker will attempt to manipulate after gaining administrative access.

MITRE ATT&CK Detection Mapping

Security.evtx data provides evidentiary support for detecting the following MITRE ATT&CK techniques:

Related Artifacts & Case Studies

Corroborating Artifacts

Case Study

References

1. Eric Zimmerman, “EvtxECmd — EVTX Command Line Parser” — https://ericzimmerman.github.io/
2. Microsoft, “Advanced Security Auditing FAQ” — https://learn.microsoft.com/en-us/windows/security/threat-protection/auditing/
3. UltimateWindowsSecurity.com, “Windows Security Log Encyclopedia” — https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/
4. WithSecure, “Chainsaw — Rapid Windows Event Log Forensics” — https://github.com/WithSecureLabs/chainsaw
5. Yamato Security, “Hayabusa — Windows Event Log Fast Forensics Timeline Generator” — https://github.com/Yamato-Security/hayabusa
6. SANS Institute, “Windows Event Log Analysis Poster” — https://www.sans.org/posters/windows-forensic-analysis/
7. omerbenamram, “evtx — A cross-platform parser for the Windows EVTX format” — https://github.com/omerbenamram/evtx
8. SigmaHQ, “Sigma Detection Rules for SIEM” — https://github.com/SigmaHQ/sigma