Detecting indicator removal (T1070)

What is indicator removal (T1070)?

Indicator removal T1070 is a MITRE ATT&CK® defense evasion technique where adversaries delete, modify, or overwrite artifacts that could identify their presence, attribute their tools, or enable forensic reconstruction of their activity. The goal is to eliminate the evidence trail that an incident responder would use to understand the scope, timeline, and method of an intrusion.

Indicator removal is the anti-forensics tactic. An attacker who successfully clears logs, deletes staged tools, and overwrites timestamps forces the investigation to rely on secondary sources such as centralized log collectors, endpoint memory, and network telemetry rather than the primary evidence on the compromised host. Log360 maps 45+ pre-built correlation rules to T1070, with a critical advantage: the clearing actions themselves generate detectable events, making the attempt self-evidencing in properly configured environments.

How attackers remove indicators

Adversaries use indicator removal to destroy the investigation trail across multiple artifact categories, each requiring different detection approaches:

1. Windows Event Log clearing: The Security event log is the primary target. Attackers use wevtutil cl Security, Clear-EventLog in PowerShell, or direct API calls to erase all Security log entries. The Windows system generates Event ID 1102 when this occurs, but only if the SIEM is collecting from the host in real time. If logs are only collected periodically, the clearing window may include unforwarded events.
2. EVTX file deletion: Rather than clearing log content through the API, attackers directly delete .evtx files from the C:\Windows\System32\winevt\Logs\ directory. This requires SYSTEM privileges and bypasses Event ID 1102, making it a harder-to-detect variant. File deletion monitoring is required to catch this technique.
3. Web server log deletion: After web-based initial access, attackers delete IIS, Apache, or Tomcat access logs to remove evidence of their exploit activity and the commands they executed through a web shell.
4. PowerShell history removal: The PowerShell command history file (PSReadLine ConsoleHost_history.txt) records every interactive PowerShell command. Attackers delete this file or configure Set-PSReadLineOption -HistorySaveStyle SaveNothing to prevent new entries from being recorded.
5. Secure file deletion: Standard file deletion leaves data recoverable. Attackers use SDelete (Sysinternals) or similar tools to overwrite file data before deletion, preventing forensic recovery of malware binaries, scripts, and staged data.
6. Timestamp manipulation (Timestomping): Modifying file creation, modification, and access timestamps (MACB times) to disrupt forensic timeline reconstruction. This prevents investigators from using file system metadata to sequence attacker activities.

Sub-techniques and variants

MITRE ATT&CK documents multiple sub-techniques under T1070, each targeting different artifact categories:

• T1070.001 — Clear Windows Event Logs: Using wevtutil, Clear-EventLog, or direct API calls to erase Windows Security, System, or Application event log content.
• T1070.003 — Clear command history: Deleting or suppressing shell history files (PowerShell PSReadLine history, bash .bash_history on Linux) to remove records of commands executed interactively.
• T1070.004 — File deletion: Removing malware binaries, staging tools, scripts, and forensic artefacts from disk after use. Secure deletion tools overwrite data before removing file entries.
• T1070.005 — Network share connection removal: Removing mapped network drive connections and net use records to eliminate evidence of lateral movement paths.
• T1070.006 — Timestomping: Modifying file MACB (Modified, Accessed, Created, Birth) timestamps to mislead forensic timeline analysis.

Detection indicators for T1070

T1070 detection is most effective through real-time centralized log collection combined with file integrity monitoring. The key detection principle is that indicator removal activities, unlike the primary attack actions they are designed to hide, consistently generate their own detectable events.

Event log clearing events (Event ID 1102 and 104)

Windows generates Event ID 1102 whenever the Security event log is cleared, and Event ID 104 when the System log is cleared. These events are generated even if the rest of the Security log is empty afterwards. In a well-configured environment, these events are forwarded to Log360 before the local log copy is cleared, making the clearing action visible in the SIEM. A Security log clearing event outside of a scheduled maintenance window is a high-confidence indicator of anti-forensic activity.

Audit policy modification (Event ID 4719)

Event ID 4719 records changes to the system audit policy. Attackers disable auditing before executing their primary attack actions to prevent new events from being generated, then re-enable it afterwards. This is more sophisticated than clearing logs. It creates a gap in the log stream without any evidence in the log itself that events occurred during the gap. Continuous monitoring for 4719 is essential.

EVTX file deletion and forensic tool execution

Direct deletion of .evtx files, execution of SDelete, and wevtutil command-line usage are all detectable through process creation monitoring (Event ID 4688) and Sysmon file deletion events. Log360's File Deleted Via Sysinternals SDelete rule and EventLog EVTX File Deleted rule target these specific patterns with dedicated detection logic.

Log360 detection rules for T1070

Log360 ships with 45+ pre-built correlation rules directly mapped to indicator removal T1070. Rules cover direct clearing actions, deletion of forensic artefact files, tool-based secure deletion, and web server log removal:

Investigation steps

When Log360 fires an indicator removal T1070 alert, follow this sequence to assess the scope of evidence destruction, reconstruct the attack timeline using remaining sources, and identify what the attacker was hiding:

1. Identify the clearing account and method: Event ID 1102 includes the account that performed the clearing action. Verify whether this account is a known administrative account and whether clearing was scheduled. An unexpected account performing log clearing is a high-confidence indicator of attacker activity.
2. Check the centralized log record for the clearing window: Compare Log360's centralized event stream against the local Windows event log on the affected host. Any events present in the SIEM but absent locally confirm the time window of the clearing operation. This gap is your primary evidence of what was hidden.
3. Reconstruct activity from surviving sources: Enumerate all available telemetry sources that survive log clearing: Sysmon process creation logs (if Sysmon was running), endpoint detection telemetry, network firewall and proxy logs, Active Directory authentication logs from the domain controller, and DNS query logs. These sources may preserve evidence of the primary attack action the indicator removal was designed to conceal.
4. Identify what preceded the clearing: Review the 60-minute window before the clearing event in the SIEM for indicators of primary attack activity: lateral movement connections, credential access events, data staging, or privilege escalation. The clearing is a signal that something significant occurred on that host.
5. Check for file deletion artefacts: If the alert involves file deletion, determine whether deleted files can be identified by name from process monitoring (Event ID 4688 showing delete operations) or Sysmon file delete events. Identify whether the deleted files were malware binaries, scripts, or forensic tools.
6. Assess audit policy integrity: Check for Event ID 4719 (audit policy change) in the period before the log clearing event. If audit policy was modified before the primary attack activity, events may never have been generated, creating an unrecoverable evidence gap. Document the gap and note the audit policy state for the investigation record.

Response playbook

• Treat every log clearing event as a confirmed incident: An unauthorized Security log clear (Event ID 1102 from an unexpected account) is an active incident indicator, not a suspicious event requiring more investigation. Immediately initiate incident response procedures for the affected host.
• Preserve the SIEM record: Export and lock the Log360 event record for the affected host before any other response action. This is your primary evidence source if the attacker successfully cleared local logs. Ensure the export covers at least 48 hours before the clearing event.
• Perform memory acquisition if host is live: If the affected host is still running, capture a memory image before any shutdown or reboot. Memory may contain evidence of attacker tools, injected code, or network connections that were not recorded in cleared logs.
• Isolate and image the affected host: After memory acquisition, isolate the host from the network and create a forensic disk image. Even if logs are cleared, file system artefacts, registry hive data, prefetch files, and application-specific logs may survive.
• Strengthen forward-looking log collection: After the incident, verify that all critical endpoints are forwarding logs to Log360 in real time with minimal latency. Log clearing only destroys local evidence — real-time forwarding to a centralized SIEM is the fundamental defense against T1070.
• Audit log retention and access controls: Review who has permissions to clear event logs on monitored endpoints. Standard user accounts and service accounts should not have this permission. Restrict wevtutil and Clear-EventLog access to dedicated administrative accounts with change management oversight. Reviewing log retention policies as part of this audit ensures evidence windows remain adequate for investigation.

Frequently asked questions