DEV Community

StarkMan
StarkMan

Posted on

Windows Event Logging You Will Actually Use in an Investigation

#windows #logging #detection

Windows Event Logging You Will Actually Use in an Investigation

Most estates collect far more Windows event data than they query and far less than they need when an investigation starts. The problem is not volume. It is that the useful fields are frequently missing because a policy setting was never enabled.

The settings that decide what exists

Three audit policy categories determine whether the events that answer basic investigation questions exist at all.
Process creation. Without process creation auditing and a command-line inclusion setting, there is no record of what ran. A command line that shows an encoded payload, a script interpreter or a lateral movement tool is frequently the single most useful artefact in an incident.
Logon auditing. Success and failure for logon events, plus the special logon category, provide the session timeline. The fields that matter, logon type, source address, and the identity of the session, come from this category.
PowerShell script block logging. Script block logging records the text of PowerShell that executes, including within many obfuscation patterns, and it is independent of whether transcription is enabled.
Advanced audit policy configured through Group Policy replaces the legacy categories. Where the legacy categories are left in place, the advanced settings are frequently overridden and silently ineffective.

The events worth an alert and a query

A small number of event IDs carry disproportionate value, and the worth of the whole log is defined by whether an analyst can query across them.

  • Process creation with a command line matching a known tool pattern, not a signature.
  • Service installation, which frequently appears when persistence is established.
  • Scheduled task creation or modification, another persistence location.
  • Account creation and group membership change, which describe the privilege being built.
  • Explicit credential use, which records when a credential was used in a way that leaves a trace.
  • Log clearing, which is rare in normal operations and notable when it occurs. The point of the list is not that these are the only events that matter. It is that each answers a question an investigation asks in the first hour, and each is worth verifying as present before it is needed.

Retention and access

Detection without retention is a delay, not a control. Two questions decide whether the collected data is usable.
How long the log is retained in a queryable form. Many incidents are discovered weeks after the initial access, and a retention window shorter than that discovery time means the earliest events are gone.
Who can read it, and whether the read is logged. An attacker with access to the platform that stores the logs can remove the evidence of their own activity. Store a copy where the production administrative identity cannot delete it.

A verification exercise worth doing once a quarter

The fastest way to find the gaps is to attempt an investigation on a system where nothing has happened.

  1. Identify the logon that opened a session on a sample server, and note whether the source address is present.
  2. Identify the process that started a known service, and note whether the command line is present.
  3. Identify a group membership change from the previous month and confirm that it is queryable.
  4. Confirm that a log-clearing event from the sample estate appears in the platform.
  5. Confirm that the same events exist for a workstation as for a server, because the policy scope is frequently not what the team assumes. Each item that fails is a configuration change, not a project, and the exercise takes an afternoon.

References

Top comments (0)