Disclaimer: This article is provided strictly for educational purposes and authorized security testing. Only run these techniques against systems you own or have explicit written permission to assess. Unauthorized access to computer systems is illegal in virtually every jurisdiction and can carry severe penalties.
Introduction
Detection engineering on Windows draws on three overlapping but distinct telemetry sources, and mixing them up leads to either coverage gaps or wasted ingestion budget: the Security event log (native Windows auditing, driven by Advanced Audit Policy), Sysmon (a free Sysinternals kernel driver and service that adds a much richer, configurable event schema), and ETW (Event Tracing for Windows, the low-level kernel tracing framework that actually underlies both of the above and that commercial EDR agents consume directly for the highest-fidelity, hardest-to-tamper-with visibility). None of the three is a strict superset of another, and a mature environment layers all three deliberately rather than picking one.
Getting this right matters because event volume, cost, and detection value trade off differently for each. The Security log is free and always present but schema-limited; Sysmon is free and rich but requires deployment and config management, and is a well-known target for tampering; ETW is the most authoritative source but is typically only fully exploited by paid EDR agents rather than raw SIEM ingestion, since consuming it directly requires writing a provider-aware collector.
Attack Prerequisites
Building layered telemetry coverage requires the following to be in place:
- Administrative rights to configure Advanced Audit Policy (
auditpol.exeor GPO) and to install/configure the Sysmon service and driver on managed endpoints. - A log forwarding pipeline — Windows Event Forwarding (WEF/WEC), Winlogbeat, or an EDR agent’s log shipper — with enough throughput and retention for the added Sysmon/Security volume.
- A maintained Sysmon configuration (not the default, which is far too permissive/verbose) such as a fork of SwiftOnSecurity’s or Olaf Hartong’s
sysmon-modularbaseline. - ETW consumer capability for anything beyond what Sysmon/Security already expose — either an EDR agent that subscribes to providers like Microsoft-Windows-Threat-Intelligence, or manual
logman/custom ETW session tooling for specific investigations. - SIEM ingestion capacity planning, since Sysmon alone can multiply endpoint event volume by an order of magnitude over the bare Security log.
How It Works
The Security log is populated by the LSASS/kernel audit subsystem according to the Advanced Audit Policy categories enabled via GPO — Logon/Logoff, Object Access, Account Logon (Kerberos), Process Creation/Tracking, and others. It has a fixed, non-extensible schema: 4624 (logon), 4625 (failed logon), 4688 (process creation), 4769 (Kerberos service ticket request), and so on. Critically, 4688 does not include the process command line unless the separate GPO setting “Include command line in process creation events” is explicitly enabled — a very common gap in unhardened environments.
Sysmon is a kernel driver plus user-mode service, configured by an XML rule file with include/exclude filtering per event type, that adds a much richer schema than native auditing: Event ID 1 (ProcessCreate, with hashes and a ProcessGuid for correlation), 3 (NetworkConnect), 7 (ImageLoad), 8 (CreateRemoteThread), 10 (ProcessAccess), 11 (FileCreate), 13 (RegistryEvent), and 22 (DNSQuery), among others. The ProcessGuid/LogonGuid fields let an analyst stitch a full process tree and correlate across event types in a way the Security log’s ProcessId reuse makes unreliable at scale.
ETW is the substrate both of the above sit on: kernel and user-mode providers publish structured events that any authorized session can subscribe to. The Security log and Sysmon are effectively curated, filtered views of a small slice of what ETW exposes. Commercial EDR agents typically get their highest-fidelity, tamper-resistant visibility by subscribing directly to providers such as Microsoft-Windows-Threat-Intelligence (the ETW-TI provider Microsoft exposes specifically for security products, covering things like AMSI content and suspicious memory operations) rather than relying on Sysmon, because Sysmon’s driver can itself be stopped, unloaded, or tampered with by an attacker with sufficient privilege, whereas ETW-TI consumption backed by a protected-process EDR agent is considerably harder to blind.
Practical Example / Configuration
A trimmed but real Sysmon configuration excerpt targeting process creation and DNS query visibility with sensible noise exclusion:
<Sysmon schemaversion="4.90">
<EventFiltering>
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="exclude">
<Image condition="end with">\SenseIR.exe</Image>
<ParentImage condition="end with">\svchost.exe</ParentImage>
</ProcessCreate>
</RuleGroup>
<RuleGroup name="" groupRelation="or">
<NetworkConnect onmatch="include">
<DestinationPort condition="is">445</DestinationPort>
<DestinationPort condition="is">5985</DestinationPort>
<DestinationPort condition="is">3389</DestinationPort>
</NetworkConnect>
</RuleGroup>
<RuleGroup name="" groupRelation="or">
<DnsQuery onmatch="exclude">
<QueryName condition="end with">.microsoft.com</QueryName>
</DnsQuery>
</RuleGroup>
<RuleGroup name="" groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="end with">\lsass.exe</TargetImage>
</ProcessAccess>
</RuleGroup>
</EventFiltering>
</Sysmon>
Deployed with sysmon64.exe -accepteula -i sysmon-config.xml, and updated in place with sysmon64.exe -c sysmon-config.xml, which itself generates a loggable Sysmon Event ID 16 (configuration change) — a signal worth monitoring in its own right.
Walkthrough / Exploitation
Building layered coverage from a cold environment:
1. Baseline via Advanced Audit Policy: enable Process Creation (4688),
Logon/Logoff (4624/4625), Kerberos Authentication/Service Ticket
Operations (4768/4769), and set the "Include command line in process
creation events" GPO so 4688 is actually useful.
2. Deploy Sysmon fleet-wide with a maintained, version-controlled config
(start from sysmon-modular, trim to your log volume budget).
3. Forward both sources to the SIEM via WEF/WEC or an agent (Winlogbeat/
Elastic Agent Windows integration), preserving ProcessGuid/LogonId.
4. On high-value assets (domain controllers, jump hosts, CI/CD runners),
layer an EDR agent that consumes ETW-TI directly for AMSI/memory-level
visibility Sysmon cannot provide.
5. Correlate: join Sysmon Event 1 ProcessGuid to Security 4688 by
timestamp+PID+Image to cross-validate, since either source alone can be
individually tampered with or gapped.
6. Tune volume iteratively: exclude known-noisy vendor paths in the Sysmon
config rather than disabling whole event categories.
Note: Sysmon is a well-documented tampering target:
fltmc unload SysmonDrv, stopping theSysmon64service, or simply uninstalling it (sysmon64.exe -u) all blind it, and each of those actions is itself an event worth alerting on (Sysmon Event ID 4/5 service state changes, or the Security log’s own 7040 service-state-change event for the Sysmon service).
Opsec: ETW sessions can silently drop events under buffer pressure — check the session’s lost-event counters, not just whether the provider is enabled. A misconfigured buffer size on a busy host quietly produces gaps that look identical to “nothing happened.”
Detection and Defense
Treat telemetry integrity itself as something to detect tampering against:
- Monitor Sysmon service/driver state — Security log 7040 for the Sysmon service, Sysmon’s own Event ID 4 (Sysmon service state changed) and 16 (configuration change).
- Cross-validate sources — a host generating Sysmon Event 1 but no corresponding Security 4688 (or vice versa) for the same process is itself an anomaly worth alerting on.
- Protect the Sysmon binary/service with WDAC/AppLocker and, where available, EDR self-protection, since an unprotected Sysmon install is trivially stoppable by anyone with local admin.
- Prefer ETW-TI-backed EDR on crown-jewel assets rather than relying on Sysmon alone, since it is materially harder to blind.
- Don’t rely on the Security log alone — without the command-line GPO and without Sysmon’s richer schema (network, image load, registry), 4688 alone misses most of the detail modern detections depend on.
Real-World Impact
SwiftOnSecurity’s publicly maintained Sysmon configuration is one of the most widely deployed baselines in the industry and is the de facto starting point cited across countless SOC runbooks and blog write-ups. The Microsoft-Windows-Threat-Intelligence ETW provider is documented by Microsoft and referenced repeatedly by security researchers analyzing how modern EDR products achieve visibility into AMSI and in-memory activity that neither the Security log nor Sysmon alone can see, and Sysmon-unloading techniques are a recurring theme in both red-team tooling and post-incident forensic write-ups where an attacker with local admin disabled logging before further action.
Conclusion
No single Windows telemetry source is sufficient on its own: the Security log is free but schema-limited, Sysmon is rich but configurable and tamperable, and ETW is authoritative but usually only fully exploited through a commercial agent. A defensible architecture layers all three — native auditing as the always-on floor, a maintained Sysmon config for process/network/registry depth, and ETW-TI-backed EDR on the assets that matter most — and treats the health of the pipeline itself, not just the events it produces, as something to monitor.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments