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 and incident response are only as good as the log data available to reconstruct what happened — an EDR alert without correlating authentication, network, and command-line logs tells an analyst *that* something happened, not the full chain of *how* and *what else* the actor touched. A logging strategy is the deliberate decision, made before an incident rather than during one, about which sources to collect, at what fidelity, for how long, and how to protect the logs from the very actors they are meant to catch.
Over-collection and under-collection both fail in practice: logging everything at maximum verbosity drowns analysts and SIEM budgets in noise with no corresponding gain in detection, while under-collection leaves the exact blind spot an attacker needs. The OWASP Logging Cheat Sheet frames the right target well — log security-relevant events (authentication, access-control decisions, input-validation failures, administrative actions) with enough context to answer who, what, when, and from where, while explicitly never logging secrets, full session tokens, or unmasked sensitive personal data.
Attack Prerequisites
A logging gap becomes an attacker’s advantage under conditions like these:
- A log source that is not collected at all — PowerShell script block logging, command-line auditing, or DNS query logging disabled by default on most systems until explicitly enabled.
- Logs retained only locally, so an attacker with local admin/root can clear or tamper with the only copy before it is ever analyzed.
- No centralization — logs exist on individual hosts but are never forwarded to a SIEM, so no cross-host correlation is possible during an investigation.
- Retention shorter than realistic dwell time — logs rotated out before an intrusion that has been present for weeks or months is discovered.
How It Works
A useful logging strategy is built from a taxonomy of sources mapped to the attack surface: endpoint telemetry (Sysmon or EDR process creation, network connections, image loads, registry modifications), identity telemetry (Active Directory / Entra ID sign-in and audit logs, Kerberos ticket events), network telemetry (firewall/NetFlow, DNS query logs, proxy logs), and cloud/application telemetry (CloudTrail, Azure Activity Log, application-level auth and authorization-failure events). Each source answers a different question during an investigation, and ATT&CK-mapped detections typically require correlating two or more of them — a Kerberoasting attempt, for example, is visible as an unusual Event ID 4769 pattern on the DC, but confirming which host initiated it requires network or endpoint telemetry as well.
Fidelity matters as much as source selection. Windows Security auditing enabled at default settings misses process command lines entirely; enabling Include command line in process creation events (feeding Event ID 4688) or deploying Sysmon with a tuned configuration turns a bare “a process started” event into one that shows exactly what was executed — the difference between noticing powershell.exe ran and noticing it ran a base64-encoded download cradle.
Log integrity is a security control in its own right: logs are one of the first things a capable attacker attempts to manipulate (clearing the Windows Security log generates Event ID 1102, itself a strong detection signal) or evade (operating only within log sources that are not collected). Forwarding logs off-host in near real time, before an attacker with local privileges can delete them, converts local logs from an easily-erased record into a durable one.
Practical Example / Configuration
A minimal Sysmon configuration fragment targeting the two event types with the highest detection value per unit of log volume — process creation with command lines, and process access to LSASS:
<Sysmon schemaversion="4.90">
<EventFiltering>
<RuleGroup name="" groupRelation="or">
<ProcessCreate onmatch="exclude">
<Image condition="end with">svchost.exe</Image>
</ProcessCreate>
</RuleGroup>
<RuleGroup name="" groupRelation="or">
<ProcessAccess onmatch="include">
<TargetImage condition="end with">lsass.exe</TargetImage>
<GrantedAccess condition="is">0x1010</GrantedAccess>
</ProcessAccess>
</RuleGroup>
</EventFiltering>
</Sysmon>
A corresponding Sigma rule that turns “Security log cleared” — one of the highest-fidelity anti-forensics indicators available — into a SIEM alert:
title: Windows Security Event Log Cleared
id: 4c6ec21a-1c5f-4c6c-8e4a-2f2c3a5e0e4b
status: stable
logsource:
product: windows
service: security
detection:
selection:
EventID: 1102
condition: selection
level: high
tags:
- attack.defense-evasion
- attack.t1070.001
Walkthrough / Exploitation
Building a logging program in practice follows a repeatable sequence:
1. Identify crown-jewel assets and the attack scenarios most relevant
to them (map to ATT&CK techniques applicable to your environment).
2. For each scenario, identify the minimum log source(s) that would
make it visible -- work backward from the detection, not forward
from "turn everything on."
3. Enable the source at sufficient fidelity (command-line auditing,
PowerShell Script Block Logging / Event ID 4104, Sysmon).
4. Forward to a central SIEM with a retention policy matched to
realistic dwell time and any compliance requirement (e.g. PCI DSS
requires at least one year, with the last three months readily
available for analysis).
5. Build and test the detection; validate with a purple team exercise
that the log source and rule actually fire on the real technique.
For an existing environment, a quick audit is to pick five ATT&CK techniques relevant to the org and, for each, ask whether a log source exists today that would surface it — gaps found this way are usually the highest-value additions to prioritize next.
Note: Volume and cost are real constraints, not an excuse to skip high-value sources. Tiered storage (hot SIEM index for recent, cheap cold storage such as S3/Glacier for older data that is still queryable during an investigation) lets an org keep long retention without paying hot-tier prices for data rarely queried.
Opsec: Log forwarding pipelines are themselves a target — an attacker who can modify the forwarder configuration or drop the local buffer before shipment achieves the same effect as clearing the log. Monitor forwarder health/heartbeat as its own detection, and treat gaps in expected log flow as a signal, not just an ops ticket.
Detection and Defense
- Centralize before an attacker can tamper locally — forward logs off-host in near real time rather than relying on periodic pulls.
- Monitor for anti-forensics directly: Event ID 1102 (Security log cleared), Event ID 104 (System log cleared / Sysmon service stop), and gaps in expected log volume from a host.
- Enable command-line and script-block logging: Event ID 4688 with command-line auditing, and PowerShell Event ID 4104 for deobfuscated script block content.
- Store logs immutably where feasible (WORM/object-lock storage) so even an attacker with log-pipeline access cannot retroactively alter delivered records.
- Set retention against realistic dwell time, not just compliance minimums — industry breach reports consistently show intrusions discovered well after typical 30-90 day retention windows.
Real-World Impact
Mandiant’s annual M-Trends reporting has repeatedly shown median attacker dwell time measured in weeks to months, and post-incident reviews frequently find that relevant telemetry existed on disk locally but was never centralized or was rotated out before analysts could use it. The SolarWinds/SUNBURST intrusion (publicly disclosed December 2020) is a widely documented case where detection was significantly complicated by gaps in cloud identity and authentication logging across the affected organizations, reinforcing that log coverage decisions made in advance directly shape how quickly a future intrusion can be found.
Conclusion
A logging strategy is a bet placed before an incident about which questions you will need to answer during one. Map sources to the attack scenarios that matter for the environment, centralize and protect logs before an attacker can reach them, and validate coverage with real exercises rather than assuming a tool is collecting what its default configuration happens to enable.
You Might Also Like
If you found this useful, these related deep-dives cover adjacent techniques and their defenses:
Comments