Defense Evasion: Hiding from Logs and Monitoring

One of the most dangerous capabilities in an attacker's arsenal is the ability to erase or manipulate the evidence of their presence. As a penetration tester, I always emphasize to clients that detection is only as good as the integrity of your log data. If an attacker can clear, modify, or disable your logging infrastructure, they can operate with impunity even in an environment with excellent detection rules. This post covers MITRE ATT&CK techniques T1070 (Indicator Removal) and T1562 (Impair Defenses), helping defenders build resilient logging architectures that withstand attacker manipulation.

Why Log Integrity Matters

Logs are the foundation of every detection, investigation, and response capability in modern security operations. Your SIEM correlation rules, your threat hunting queries, and your incident response playbooks all depend on the assumption that log data is complete and accurate. When an attacker tampers with logs, the consequences cascade throughout your entire security program. Alerts that should have fired never trigger. Investigations miss critical evidence. Incident response teams cannot reconstruct the full scope of a breach. Understanding how attackers target logging infrastructure helps defenders build protections that preserve the integrity of this critical data source.

Log Manipulation Techniques

Attackers target logs at multiple levels, from wholesale deletion to surgical modification. Each technique requires specific defensive countermeasures.

• Clearing event logs (T1070.001) - The most obvious approach is simply clearing Windows Event Logs using wevtutil, PowerShell Clear-EventLog, or direct API calls. This is crude but effective against organizations that only monitor local logs. The act of clearing logs itself generates Windows Event ID 1102 (audit log cleared) in the Security log, which defenders should alert on with the highest priority. Any legitimate reason for clearing logs should be documented and approved through change management.
• Selective log deletion - More sophisticated attackers do not clear entire logs, which is conspicuous, but instead delete specific entries that contain evidence of their activity. Tools exist that can parse Windows Event Log files and remove individual records while maintaining file integrity. Defenders should monitor for unusual modifications to .evtx files and implement log integrity checks that detect gaps in event record sequences.
• Timestamp manipulation (T1070.006) - Also known as timestomping, this technique modifies file timestamps to make malicious files appear as if they have existed since the operating system was installed. Attackers use tools that modify the creation, modification, and access times of files. Defenders can detect timestomping by comparing NTFS $STANDARD_INFORMATION timestamps with $FILE_NAME timestamps, as most timestomping tools only modify the former. Sysmon Event ID 2 (File creation time changed) specifically tracks this activity.
• Log source disabling (T1562.002) - Rather than deleting logs after the fact, attackers may disable logging services entirely. This includes stopping the Windows Event Log service, disabling Sysmon, modifying audit policies, or killing EDR agent processes. Defenders should implement watchdog monitoring that alerts when any logging service stops unexpectedly and ensure that critical logging services are protected from being stopped by non-administrative processes.

Anti-Forensics Techniques

Beyond log manipulation, attackers employ broader anti-forensic techniques designed to minimize all evidence of their presence on compromised systems.

• Memory-only payloads (T1620) - By executing malicious code entirely in memory without ever writing to disk, attackers leave minimal forensic artifacts. Memory-only payloads evade many traditional forensic techniques that rely on disk analysis. Defenders should invest in memory forensics capabilities and ensure their EDR performs regular memory scanning. Tools like Volatility enable memory analysis during incident response, but the key is capturing memory before the system is rebooted or the process terminates.
• Secure deletion and artifact cleanup - Attackers delete their tools, temporary files, and other artifacts after use, often using secure deletion methods that overwrite data to prevent recovery. Common cleanup targets include dropped executables, staging directories, scheduled tasks, and persistence mechanisms. Defenders should monitor for file deletion patterns that indicate cleanup activity, particularly the deletion of recently created files from temporary directories.
• Prefetch and artifact manipulation - Windows Prefetch files, Amcache entries, ShimCache data, and other forensic artifacts can reveal evidence of program execution even after the program is deleted. Sophisticated attackers know to clean these artifacts as well. Defenders should centrally collect these artifact sources so that even if local copies are manipulated, the previously collected versions remain available for investigation.

Detection Strategies for Log Tampering

Detecting log tampering requires a combination of integrity monitoring, behavioral analysis, and architectural resilience. Here are the specific indicators I recommend monitoring.

• Event ID 1102 (Security log cleared) - This is the most critical indicator. In well-managed environments, security logs should never be manually cleared. Any occurrence of this event should trigger an immediate investigation with the highest priority.
• Gaps in log sequences - Windows Event Log entries have sequential record numbers. Gaps in these sequences may indicate selective log deletion. Implement monitoring that tracks expected event rates and alerts when the event volume drops significantly below baseline, which may indicate that logging has been disrupted.
• Unusual timestamp patterns - Files with creation timestamps older than the operating system installation or with identical timestamps across multiple attributes that normally differ may have been timestomped. Correlate Sysmon Event ID 2 with other file creation events to identify suspicious timestamp modifications.
• Missing expected logs - Establish baselines for expected log volumes and types from each system. A domain controller that suddenly stops generating authentication logs, or a web server that stops producing access logs, indicates either a system failure or deliberate log disabling. Both scenarios require immediate investigation.
• Service and process monitoring - Alert on the stopping or modification of critical logging services including the Windows Event Log service, Sysmon, EDR agents, and audit policy changes. Event ID 7045 (service installation) and Event ID 4719 (system audit policy change) are valuable indicators.

Defense Recommendations for Log Resilience

Building a logging infrastructure that is resilient to attacker manipulation requires architectural decisions that go beyond simply deploying a SIEM. Here are my recommendations based on years of testing organizational defenses.

• Central log collection with SIEM - Forward all logs to a central SIEM in near-real-time. Once logs are received by the SIEM, they become immutable from the attacker's perspective. Even if the attacker clears local logs, the previously forwarded copies remain intact. Configure log forwarding with minimal delay to reduce the window during which logs exist only locally.
• Log integrity monitoring - Implement file integrity monitoring on log file directories to detect unauthorized modifications. Track the size, hash, and modification times of log files and alert on unexpected changes. Solutions like OSSEC and Wazuh provide this capability integrated with broader security monitoring.
• Protected log storage with write-once policies - Store log archives in write-once storage that prevents modification or deletion even by administrators. Cloud-based log storage with object lock policies or on-premises WORM storage ensures that historical logs cannot be tampered with regardless of the attacker's access level.
• Multiple independent detection sources - Do not rely on a single telemetry stream. Combine Windows Event Logs, Sysmon, EDR telemetry, network logs, and cloud-based analytics. If an attacker disables one source, the others continue to provide visibility. The overlap between sources also enables detection of tampering itself.
• Protected audit policies - Use Group Policy to enforce audit policies and prevent local modification. Implement monitoring for changes to audit policy settings and ensure that any legitimate changes go through an approved change management process.

Building Forensic Readiness

Beyond real-time detection, organizations should prepare for the possibility that anti-forensic techniques will be used during an incident. Maintain memory acquisition capabilities that can be deployed quickly during an investigation. Implement automated artifact collection that continuously captures forensic data before an incident occurs. Train your incident response team on anti-forensic techniques so they know what artifacts to look for and understand the limitations of their analysis when evidence has been manipulated. Organizations that invest in forensic readiness before an incident occurs are dramatically better positioned to investigate and respond effectively when an attacker attempts to cover their tracks.