Detecting and Mitigating Indicator Removal (T1070)

Indicator Removal (MITRE ATT&CK T1070) is a technique in the Stealth tactic. MITRE lists Containers, ESXi, Linux, macOS, Network Devices, Office Suite and Windows as platforms.

The description is worth reading closely because it differs from what many people picture. Adversaries may selectively delete or modify artifacts to reduce signs of their presence and blend in with normal activity. They may not wipe everything. Instead they can target specific artifacts that look anomalous or would draw scrutiny, and leave enough data in place to keep the system looking normal.

How attackers use it

MITRE gives these examples of artifacts: command histories, log entries and file metadata. They can be altered in ways that match expected user or system activity. The location, format and type of artifact, such as a command or login history, is often platform-specific, so an adversary can tailor edits to the platform in front of them.

MITRE is also candid about the limits. These actions may not prevent detection entirely, but they can delay recognition or lower the fidelity of alerts by making events look benign. Removed or modified artifacts may still be recoverable through deeper forensics, though their absence or alteration complicates timeline reconstruction and attribution.

The technique has eight sub-techniques, and each has its own post in this series:

• T1070.003 Clear Command History
• T1070.004 File Deletion
• T1070.005 Network Share Connection Removal
• T1070.006 Timestomp
• T1070.007 Clear Network Connection History and Configurations
• T1070.008 Clear Mailbox Data
• T1070.009 Clear Persistence
• T1070.010 Relocate Malware

How to detect it

MITRE's detection strategy has six analytics, one per environment:

• Windows: sequences of deletion or modification of logs, registry keys, scheduled tasks or prefetch files, following suspicious process activity or elevated access.
• Linux: deletion or overwriting of bash history, syslog, audit logs and .ssh metadata, following privilege elevation or suspicious process spawning.
• macOS: clearing of unified logs, deletion of plist files tied to persistence, and manipulation of Terminal history after initial execution.
• Containers: tampering with audit logs, volumes or mounted storage used for side-channel logging, such as /var/log inside containers.
• ESXi: suspicious use of ESXi shell commands or PowerCLI to delete logs, rotate system files or tamper with hostd and vpxa history.
• Office suite: deletion or hiding of security-related mail rules, audit mailboxes, or calendar and log sync artifacts.

The common thread is sequence. Log deletion on its own can be maintenance. Log deletion shortly after a privilege change, a new remote session or an unusual process is a different story.

Two cheap and strong signals:

• Gaps. A host that stops sending logs, or a log file whose size drops, is a signal in itself. Alert on silence from a source that is normally chatty.
• Clear events. On Windows, the Security log records an audit log clear as Event ID 1102 and the System log as Event ID 104. Alert on both.

How to reduce the risk

MITRE lists three mitigations:

1. Remote data storage. Automatically forward events to a log server or data repository, so an adversary cannot locate and change the data on the local system. Keep the delay between event and forwarding short, so little sits on the local machine.
2. Restrict file and directory permissions. Protect locally stored event files with proper permissions and authentication, and limit chances for privilege escalation, which would let an adversary get past those permissions.
3. Encrypt sensitive information. Obfuscate or encrypt event files locally and in transit to avoid giving the adversary feedback.

The first one does most of the work. If a copy of each event already left the host a second after it happened, deleting the local file only proves that someone tried.

Try it yourself

Click through it at your own pace, or open it full screen.

Check your own environment

# Windows PowerShell: look for log clear events (read only)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=1102} -MaxEvents 10 -ErrorAction SilentlyContinue
Get-WinEvent -FilterHashtable @{LogName='System'; Id=104} -MaxEvents 10 -ErrorAction SilentlyContinue

# Linux: permissions and sizes of key logs (read only)
ls -l /var/log/auth.log /var/log/secure /var/log/syslog 2>/dev/null

Then run through this list:

• Does every server forward its logs to a system the server itself cannot write to?
• How many minutes pass between an event and its arrival in central storage?
• Which accounts can delete or truncate local logs?
• Do you alert when a source goes quiet?
• Are shell histories, mailbox audit logs and network device logs included, or only operating system logs?

Quick check

Sources

• MITRE ATT&CK T1070: Indicator Removal