Windows Event Log Analysis

Windows Event Logs are the primary source of forensic data on Windows systems. Every action—user logon, process creation, service start, registry modification—can generate an event. The Security log is especially important because it records security-relevant events like logon attempts, privilege use, and audit policy changes. SY0-701 expects you to know how to interpret these logs to detect malicious activity.

Windows uses the Event Tracing for Windows (ETW) framework to generate logs. When an auditable action occurs (e.g., a user logs on), the Security Reference Monitor (SRM) checks the audit policy. If auditing is enabled for that action, an event is written to the Security log. Each event contains: - Event ID: A numeric identifier (e.g., 4624 for successful logon). - Level: Information, Warning, Error, Critical. - Task Category: e.g., Logon, Account Management. - Keywords: e.g., Audit Success, Audit Failure. - Source: The provider that generated the event (e.g., Microsoft-Windows-Security-Auditing). - User: The account that performed the action. - Computer: The hostname. - Description: Detailed information in XML format.

The default log locations are: - Application: C:\Windows\System32\winevt\Logs\Application.evtx - Security: C:\Windows\System32\winevt\Logs\Security.evtx - System: C:\Windows\System32\winevt\Logs\System.evtx - Setup: C:\Windows\System32\winevt\Logs\Setup.evtx - Forwarded Events: Used when logs are collected from other systems.

Memorize these Event IDs—they appear on the exam:

Attackers know that logs are their enemy. Common techniques to evade detection: - Clearing Event Logs: Using wevtutil cl Security or Clear-EventLog -LogName Security. This generates Event ID 1102 (Security log cleared). Defenders should monitor for 1102. - Disabling Auditing: Changing audit policy via auditpol /set /subcategory:"Logon" /success:disable /failure:disable. Generates 4719. - Overwriting Logs: By default, Windows overwrites old logs when the log reaches maximum size (20 MB by default). Attackers can fill logs with noise to push out evidence. - Stopping Event Log Service: Stopping the Windows Event Log service (EventLog) prevents logging. This generates Event ID 7036 (service stopped). Defenders should alert on EventLog service changes.

Defenders deploy: - Centralized Logging: Forward logs to a SIEM (e.g., Splunk, ELK) using Windows Event Forwarding (WEF) or agents. This preserves evidence even if local logs are cleared. - Log Size and Retention: Increase log size (e.g., to 1 GB) and set retention policy (archive/overwrite as needed). - Audit Policy Configuration: Use Advanced Audit Policy (via auditpol or GPO) to enable detailed logging like Process Creation (include command line) and Account Logon. - Event ID Monitoring: Create alerts for critical Event IDs (e.g., 1102, 4719, 4720, 7045).

To view logs:

Get-WinEvent -LogName Security -MaxEvents 10

To filter for specific Event ID:

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} -MaxEvents 10

To export logs:

wevtutil epl Security C:\backup\Security.evtx

To clear logs (requires admin):

wevtutil cl Security

To check audit policy:

auditpol /get /category:*

To enable command line logging in process creation:

auditpol /set /subcategory:"Process Creation" /success:enable

Then enable the policy via GPO: Administrative Templates > System > Audit Process Creation > Include command line in process creation events.

While Windows Event Logs are proprietary, they align with common log management standards: - NIST SP 800-92: Guide to Computer Security Log Management. - ISO 27001: Requires logging and monitoring. - PCI DSS: Requirement 10 mandates audit trails.

SY0-701 does not test specific RFCs for event logs, but understanding these standards helps in scenario questions about compliance.

A SOC analyst sees multiple Event ID 4625 (failed logon) from a single source IP against multiple accounts, followed by a successful 4624 with Logon Type 3 (network). Then Event ID 4648 (logon with explicit credentials) appears, indicating the attacker used harvested credentials to authenticate to a server. The analyst uses a SIEM to correlate these events. The correct response is to isolate the compromised account, force password reset, and check for lateral movement. A common mistake is focusing only on failed logons and ignoring the successful 4624, missing the actual compromise.

An endpoint generates Event ID 4688 with command line powershell.exe -EncodedCommand <base64>. Shortly after, many files are modified (Event ID 4663 for file writes). The analyst identifies the encoded command as a download cradle for ransomware. The analyst should immediately isolate the host from the network, block the PowerShell execution policy via GPO, and check for persistence (Event ID 7045 for service install). A mistake is to ignore the encoded command because it looks benign; always decode and inspect.

An employee copies large amounts of data to a USB drive. This generates Event ID 4663 (file access) with access mask indicating Write or Read, and Event ID 4656 (handle to object requested). The analyst sees unusual volume of file reads from a sensitive share (Event ID 5140 for share access). The correct response is to verify with the employee's manager, review HR policies, and possibly disable the account. A common mistake is to assume all file access is normal; baseline user behavior to spot anomalies.