How T1070 Indicator removal hides intrusions from your SOC
When alerts stop mid-incident and the logs for an affected host go quiet, the SOC may be looking at indicator removal. In MITRE ATT&CK, T1070 describes adversaries deleting or altering the artifacts their actions leave behind, such as logs, files, registry values and file metadata, so defenders lose the trail of what happened. Under the Stealth tactic (TA0005), the goal is to make intrusion activity look like normal behavior. Removal usually appears after execution, credential use or persistence, when the attacker wants to erase traces before leaving or continuing. It is also a signal in its own right: legitimate administration rarely needs to wipe security-relevant evidence, so a deletion, truncation or unexplained gap can be suspicious even when no other alert has fired.
The ATT&CK version you map to matters. This page targets Enterprise ATT&CK 20.0, which MITRE released on 2026-10-13 according to the attack-stix-data repository index. ATT&CK v19 release notes record that v19, released April 28, 2026, split the Enterprise Defense Evasion tactic. Stealth keeps the ID TA0005, and a new tactic, Defense Impairment, carries ID TA0112. Detection content, dashboards and coverage reports that still label T1070 under Defense Evasion need a mapping review. Confirm with your detection engineering owner which tactic labels your rules and reports use, and confirm in the release notes whether the technique and sub-technique IDs you rely on are unchanged in your target version.
Start with three checks. First, confirm which log sources would record deletion or truncation on your Linux, container and hypervisor hosts, and whether those logs are forwarded off-host so a local wipe does not erase the record. Second, alert on gaps: a host that stops reporting, a log file whose size drops or whose metadata changes, or an audit service that stops. Third, decide who owns the response when a gap appears during active hours, because the first hour often determines whether you can rebuild the timeline. Off-host storage of logs is the main control against this technique, and the mitigation section of this page explains how to implement it.
Which telemetry reveals indicator removal and which open-source tool collects it
This table maps the telemetry ATT&CK links to indicator removal onto the platforms in scope, the signal each one produces and the open-source collector that gathers it. Check each data component ID against the enterprise-attack 20.0 bundle before writing rules, because the supplied facts do not list IDs for these three telemetry types. The main takeaway is that log integrity needs evidence from outside the host, since a host-only record can be altered along with the logs it holds.
| Telemetry | Platforms in scope | Signal to look for | Collector and data component |
|---|---|---|---|
| File Modification | Linux, macOS, ESXi, containers | Truncation, deletion or replacement of log files and shell history files outside rotation windows | Wazuh file integrity monitoring and Auditd watch rules. Confirm the File Modification data component ID in the 20.0 bundle. |
| Windows Registry Key Modification | Windows hosts in mixed estates | Changes to event log service settings, audit policy keys or logging configuration values | Wazuh Windows agent with registry monitoring enabled. Confirm the data component ID in the 20.0 bundle. |
| File Metadata | Linux, macOS, ESXi, containers | Timestamps that break log sequence, unexpected ownership or permission changes on log paths | Auditd attribute change events and Velociraptor file collection artifacts. Confirm the data component ID in the 20.0 bundle. |
| Log continuity | Linux, ESXi, containers, network devices | Gaps in forwarded logs, stopped log shipping or agents that disconnect from the manager | Wazuh manager alerts on agent status. Zeek and Security Onion show stopped syslog sessions where the transport is visible to sensors. |
| Container log paths | Containers and container hosts | Writes to log directories inside running containers, or log loss after container restarts | Wazuh agent on container hosts and Velociraptor hunts across nodes. Confirm container coverage and data component mapping. |
| ESXi host logging | ESXi | Changes to syslog forwarding settings, unexpected log size drops or missing hypervisor events at the central store | Wazuh syslog ingestion and Security Onion for forwarded syslog. Confirm which ESXi log sources your version exposes. |
Detection logic for log clearing, file deletion and metadata tampering
T1070 Indicator removal covers attempts to erase the traces an intruder leaves behind. The detection ideas below look at the evidence trail itself: whether logs go quiet, whether files vanish in bulk, whether timestamps and registry values change in ways normal work does not explain. Each card lists the logic, the local baseline to tune against, and the benign activity that will trigger it.
Log source gaps and truncation
Alert when a host, container or network device stops sending events for longer than its normal quiet period, or when event counts drop sharply while the host still answers health checks. Compare each source against its own history by hour and day of week, because a silent database server at 3 a.m. is normal and a silent domain controller is not. Also watch for log files that shrink to near zero size without a rotation event. Tune thresholds per source class, not globally. Expected false positives include maintenance windows, agent upgrades, network segmentation changes and decommissioned hosts that remain in the inventory. Confirm the log retention settings with each platform owner before tuning.
Bulk deletion of log and history files
Flag processes or interactive sessions that delete many log, shell history or audit files within a short window, especially under system log directories. The logic should look at the deleting process, its parent, the account and whether the target set matches a known log path list. A single deleted file is weak evidence; a burst across several log paths on one host is stronger. Tune the count and window against a baseline gathered from routine cleanup jobs. Expected false positives include log rotation utilities, package managers that replace files, backup agents that prune local copies and configuration management runs that reset state. Keep an allowlist of named jobs with owners.
Timestomping-style metadata changes
Detect file creation, modification or access times that move backward in time or that disagree with the time of the file system journal entry for the same change. Compare timestamps on sensitive binaries, scripts and recently written logs against their expected change history. Keep the threshold strict for system directories and looser for user project folders. Expected false positives include file copies that preserve original timestamps, archive extraction, restores from backup, container image layers and clock corrections after a host syncs with a time source. Check that the file integrity tooling records both the content hash and metadata, so that the two can be compared.
Registry value removal on Windows
Alert on deletion of registry values under event log configuration, audit policy and security provider keys, and on changes that disable event channels. Pair the deletion with the process that made it and with any change to the service that writes those keys. Tune by key path, because some values are removed during normal software installs and uninstalls. Expected false positives include software uninstallers, group policy refresh cycles, endpoint agent updates and vendor installers that reset their own configuration. Confirm the audit policy for registry changes is enabled on the endpoints in scope before relying on this logic.
Log forwarding stops
Watch for the forwarder service stopping, its configuration file changing, or the destination connection failing while local logs keep growing. A host whose local log volume continues but whose central index receives nothing is a strong signal, because it suggests forwarding was cut rather than the host going quiet. Compare forwarder heartbeats against the expected interval. Expected false positives include forwarder upgrades, certificate renewals, destination outages, network changes and planned restarts. Require the health check to run from a second source, such as the collector, so that a stopped agent cannot hide its own silence.
How to validate that the detection fires before you trust it
This sequence proves that the T1070 Indicator Removal detections fire on the behaviors they claim to cover, that the alerts reach the SIEM with usable fields, and that the team knows where coverage is thin before an attacker finds those gaps. It produces a documented record that the detection logic is tested, not assumed.
Agree scope and rules of engagement
The detection owner, the SOC lead and the cyber range team agree in writing which sub-techniques are in scope, which hosts and platforms the exercise touches (for example Linux, macOS, containers or ESXi, depending on what your estate runs), who may stop the exercise, and how the range is isolated from production. Done means a signed scope note exists and every participant knows the stop conditions.
Map planned behaviors to sub-techniques
Build a table that links each planned behavior to a specific T1070 sub-technique and to the ATT&CK version your detection targets, so the mapping names the version it was written against. Record the expected data source for each behavior, such as File Modification, Windows Registry Key Modification or File Metadata. Done means every sub-technique in scope has at least one planned behavior and one expected telemetry source, and gaps are noted rather than silently skipped.
Run the behaviors in a non-production range
The red or purple team executes the mapped behaviors inside a private cyber range that mirrors the production logging configuration as closely as possible. A second person observes and timestamps each action in a shared log. Done means the exercise log lists every behavior with a start time, an end time and the host it ran on, so later alert timing can be matched to a known action.
Confirm alerts reach the SIEM with expected fields
The detection engineer checks the SIEM, for example a Wazuh or Security Onion deployment, for each expected alert and inspects the fields it carries: host, user, process or file path, event time and rule identifier. Missing or malformed fields count as a failure even when an alert exists. Done means each planned behavior maps to either a correctly populated alert or a logged defect with an owner.
Measure time to alert
Using the timestamps from the exercise log and the SIEM event times, the detection engineer calculates how long each alert took after the behavior ran. Compare the result with the response time the SOC has agreed to, and note whether the delay comes from log shipping, rule scheduling or analyst queueing. Done means each detected behavior has a recorded delay and a stated cause for any delay that exceeds expectations.
Record coverage gaps and false positives
Mark behaviors that produced no alert as coverage gaps, and mark alerts raised by legitimate administrative activity during the exercise as false positives. Assign each item to the detection owner with a target for tuning or new telemetry. Done means the gap register and false positive list are reviewed by the SOC lead and stored with the detection record.
Retest after every rule change
Each time a detection is tuned, the engineer reruns the affected behaviors in the range and confirms that the alert still fires with the expected fields and that the false positive has not returned. Retests are tied to the ATT&CK version recorded in the mapping, so changes made after a version update are checked against the updated technique definitions. Done means the retest result is attached to the change record before the rule is promoted to production.
Why log integrity and forwarding matter more than single alerts
Indicator removal often succeeds on the host and fails in the SIEM. An adversary who clears a local log, truncates a file or alters timestamps is changing the copy that sits on the machine they control. If the same events were already forwarded to a central platform, the record of the original activity and of the removal itself may still exist elsewhere. For T1070 Indicator Removal, the practical question for a defender is not whether a deletion event fired on the endpoint, but whether a copy of the relevant telemetry left the host in time and was kept under controls the attacker cannot reach with the same credentials.
Remote Data Storage (M1029) is the ATT&CK mitigation that addresses this directly: it moves log and evidence storage off the system being monitored so that a local change does not erase the only record. Centralized forwarding changes what a defender can prove, because it lets the team show what was logged, when it arrived and whether the central copy was altered. Confirm with your platform team which sources forward in real time, which batch, and which hosts are excluded. Check whether the central store enforces write-once or retention rules, and whether administrators of the endpoint can also administer the SIEM. If they can, the separation is weaker than it looks.
Detections should also watch for silence. When a host stops sending events, or a source's volume drops to zero while its heartbeat or agent status still reports healthy, that gap can be the indicator. Build alerts on expected-source checks, last-seen timestamps and sudden drops in event counts per host, and test them in the cyber range by stopping a forwarder on purpose. Note that a silence alert is a lead, not proof: outages, maintenance and misconfiguration produce the same pattern, so record the response steps that separate them. Any tooling you choose should be checked against your own environment and documented before you rely on it.
Mitigations that make indicator removal harder to do quietly
Indicator removal succeeds most often when the evidence sits on the same host the adversary already controls. The cards below cover three ways to take that advantage away: restricting who can write to log and history paths, shipping logs off the host, and tightly managing the administrative accounts that can change logging settings.
Restrict log and history file permissions
ATT&CK maps mitigation Restrict File and Directory Permissions (M1022) to T1070 so that only the logging service and designated administrators can modify or truncate log files, shell history and audit configuration. Review ownership and write permissions on /var/log, audit rule files and shell history locations, including container log paths on hosts that run them. Confirm that log directories are not writable by general service or user accounts, and that changes to permissions themselves are logged. This control reduces the ease of tampering but does not stop an attacker who already holds root or equivalent rights.
Ship logs off the host
The ATT&CK mitigation Remote Data Storage addresses T1070 by keeping a copy of audit and system events outside the system where they were generated. Forward authentication, process, and file integrity events to a collector such as Wazuh or Security Onion in a separate trust zone, and confirm that the forwarder cannot be silently disabled from the monitored host. Check how long the remote store retains events and whether gaps in forwarded data trigger an alert. Remote copies only help if the detection team reviews them, so define who watches for host-side log gaps.
Limit administrative access to logging
Mitigation Privileged Account Management (M1026) applies to T1070 because clearing logs, disabling auditd, or editing journal settings usually requires administrative rights. Restrict those rights to named administrators, require elevation through a logged mechanism, and remove standing privileges where the platform allows it. Confirm which service accounts can write to the logging daemon, and review whether any of them are used interactively. Account separation limits blast radius but will not prevent misuse by a legitimate administrator, so pair it with alerting on privileged logging changes.
Alert on tampering with logging controls
Even with the controls above, indicator removal leaves a trace when the logging configuration itself changes. Monitor file modification events on audit rules, syslog and journal configuration, and log directories, and alert when logging services stop or restart outside a change window. Confirm that these alerts reach an on-call queue rather than a dashboard nobody checks. Illustrative example: a sudden drop in events from one host followed by a configuration edit is a stronger signal than either event alone. Tune thresholds against your own baseline before relying on them.
What the SOC does in the first hour after a log removal alert
The first decision is whether the alert describes a real loss of evidence or a logging artifact. Confirm the gap before anyone treats it as an attack. Log rotation, a log forwarder restart, an agent upgrade, a full disk on the source host or a collector that stopped accepting events can all produce a silent window that looks like T1070 Indicator Removal. Check the agent health and forwarding status for the affected hosts, compare the gap against the rotation schedule and the time of any restart, and confirm whether other sources from the same host show the same window. If the gap is unique to one host and lines up with no operational event, treat it as suspicious until proven otherwise.
Next, preserve what survived. Export the remaining endpoint telemetry, the SIEM search history and the raw events around the gap before any cleanup or reimaging, and record hashes and collection times so the evidence holds up later. Then look for correlated activity on either side of the window: authentication events for the account that owned the host, new process creation, shell history where it exists, and changes to file or registry state such as edits to the paths that hold log files or audit configuration. Scope the activity by identity and host, not only by the alerted machine. Decide on containment based on the findings, for example isolating the host while keeping its network evidence, or disabling a single account, rather than wiping systems that still hold volatile data.
Document, early and in writing, what can and cannot be reconstructed. Record which log sources still cover the window, which were lost, and why, so the incident record separates confirmed gaps from unknown ones. The scope of response depends on what logging survived, so ask the team that owns each source to confirm its retention, forwarding and integrity controls before concluding anything about intent. Where a timeline cannot be rebuilt from logs, say so explicitly and name the compensating evidence you used, such as network flow records, cloud control plane events or endpoint memory captures. Review the detection's own coverage afterwards to confirm the alert would fire again if the same activity recurred.
How to rehearse T1070 detection in a private cyber range
A private range for this environment should mirror the production estate closely enough that log paths, container runtimes and file ownership match what the blue team sees daily. A typical topology includes a few Linux hosts running representative services, one container host with orchestration, a central log collector, and a Wazuh or comparable manager receiving File Modification telemetry. The red team scripted scenario (illustrative) clears or truncates log files and shell history on a host, then alters container log output. The blue team receives an inject showing a gap in log sequence numbers on one host.
- Range topology: Include at least one host with a remote log forwarder and one without, so the team can compare what survives local tampering.
- Injects: Provide a timeline of benign administrative activity plus a single removal event, so analysts must separate noise from the action.
- Good detection: Alerts fire on modification or truncation of monitored log paths and on gaps between forwarded and locally stored records.
- Good response: The team preserves the remote copy first, confirms the scope on other hosts, and documents which records cannot be recovered.
- Validation: Confirm which file paths and container log drivers your production systems actually use before building the range.
Before the exercise, confirm with your platform team which log locations and retention settings are live in production.
Virtualization hosts hold logs and configuration that attackers may try to clear, so the range should include a small ESXi cluster or a lab equivalent, a vCenter-style management plane if your estate uses one, and a syslog destination outside the hypervisor. The exercise focuses on whether removal of host-side logs or configuration files is visible from outside the host. The red team scenario (illustrative) removes local log content on one host after a benign change window. The blue team must notice the mismatch between expected and received events.
- Range topology: Place a remote syslog receiver and a management console on separate network segments so the blue team tests cross-platform correlation.
- Injects: Schedule a planned maintenance window, then introduce an unplanned removal of host logs during that window.
- Good detection: Analysts identify missing time ranges in centrally collected records and tie them to a specific host and account.
- Good response: The team isolates the management path, checks configuration integrity, and restores evidence from the remote collector.
- Validation: Ask your virtualization team which logs are forwarded by default and which require explicit configuration.
Confirm vendor-specific log locations and forwarding options with the hypervisor vendor documentation for your version.
Indicator removal on Windows often involves registry values, event log clearing or changes to file metadata such as timestamps. The range should include a domain-joined Windows workstation and server, a Sysmon-style or equivalent endpoint sensor feeding Wazuh or Security Onion, and a file share with monitored directories. Scenario injects test whether the team can correlate a Windows Registry Key Modification alert with a File Metadata change on the same asset. The red team scenario (illustrative) alters a timestamp on a staged file and removes a registry value tied to a prior event.
- Range topology: Use one workstation and one server in the same domain, with a shared folder that the blue team knows to monitor.
- Injects: Combine a registry change with a file metadata change within a short window, and add a benign software update as a decoy.
- Good detection: Analysts link the two events, separate the decoy, and identify the account and process responsible.
- Good response: The team collects the affected registry hive and file copy, compares them with backups, and records the chain of custody.
- Validation: Check that the sensor records the fields your analysts will need, including process and user context.
Confirm which event IDs and sensor fields your Windows build produces before finalizing the detection criteria.
macOS fleets often sit outside the server-focused monitoring that many teams build first, so the range should add a small set of managed Mac endpoints with a unified log collection agent and a file integrity monitor for user and system directories. The exercise tests whether file modification events in user library paths and shell configuration files reach the SIEM in a usable form. The red team scenario (illustrative) edits a shell profile to remove a trace of prior activity and deletes a temporary file from a user directory.
- Range topology: Include at least two endpoints under different user profiles and one shared administrative account to reflect typical fleet use.
- Injects: Present a developer workflow that legitimately modifies profile files, then a removal event that looks similar.
- Good detection: Analysts distinguish expected developer changes from removal by comparing against baseline file states and process ancestry.
- Good response: The team pulls the endpoint for triage, snapshots user directories, and reviews other endpoints for the same pattern.
- Validation: Confirm with your endpoint management team which macOS log streams and file monitoring policies are deployed.
Verify with the current macOS management and logging documentation that your fleet uses before relying on any log path in the exercise.
Questions SOC leads and detection engineers ask about T1070
How do I tell normal log rotation from indicator removal on Linux hosts?
Log rotation renames, compresses or replaces log files on a known schedule and keeps the events, while removal deletes, truncates or empties them outside any planned job. Start by inventorying the rotation configuration on each host, including the logrotate settings under /etc/logrotate.d, and record the expected schedule, file naming pattern and owning process. Then alert on deletion, truncation or unexpected size drops for log paths, and correlate each event with the process, account and time that made the change. Suppress expected rotations by matching the specific job, owner and time window, so the rule keeps watching the rest of the path. Confirm with your platform team that every rotation tool and logging agent is documented, because an undocumented job will look like an attack until someone explains it.
Do Sigma rules cover registry and file metadata events for indicator removal?
Public Sigma rules include some rules for registry and file events, but coverage for indicator removal is uneven, so check each rule against your own telemetry. Sigma is a generic rule format that converts to the query language of backends such as Wazuh or Splunk, which means a rule only fires if the underlying events are collected. Registry key modification events on Windows depend on the audit policy or an endpoint sensor such as Sysmon or an EDR. File metadata changes, such as timestamp edits, need file creation and modification auditing on the hosts that matter. ATT&CK v18 replaced data sources with data components, so map each rule to the data components it needs and verify those are collected. Review the rules in the Sigma repository for the specific T1070 sub-technique you target, then record which telemetry each rule actually depends on.
How do I pin T1070 detections to ATT&CK 20.0 and handle later releases?
Record the ATT&CK version in every detection's metadata and build your mapping from the matching STIX bundle, such as the enterprise-attack-20.0.json file in the attack-stix-data repository. Pinning keeps your coverage report reproducible, because the technique IDs and relationships you tested are the ones you can show an auditor. Later releases can rename, deprecate or revoke techniques. ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic into Stealth, which keeps ID TA0005, and Defense Impairment, which has ID TA0112, so confirm where T1070 sits in the version you target. When a new release arrives, diff the bundles, review changed mappings, and update your coverage matrix in a controlled change. Keep the old mapping until the new one has been tested in your cyber range.
Which ATT&CK data components should a SOC prioritize for T1070?
Prioritize the data components that show the removal action itself, then the components that show who performed it. Across Stealth techniques, the most referenced data components in ATT&CK 20.0 include Process Creation (DC0032), Command Execution (DC0064), File Creation (DC0039), Module Load (DC0016), Network Connection Creation (DC0082) and Process Access (DC0035). For T1070, file and registry modification telemetry matters most, because deletion, truncation and metadata edits are the observable actions. Process Creation and Command Execution show the tool or script that made the change, and Network Connection Creation helps show whether logs were forwarded before they were altered. Confirm in the STIX bundle which of these components are linked to T1070 and each sub-technique, since the relationships are the authoritative source for your mapping.
How can we test indicator removal detections without disrupting production logging?
Test in a private cyber range that mirrors your collection pipeline, not in production. Build the range with the same agents, audit policies, log forwarders and rule versions as production, and use dedicated test hosts and test log paths that carry no business data. Define each exercise in advance with the expected telemetry, the expected alert and the owner who will confirm the result. Run the scripted scenarios in an approved change window, and watch ingestion rates and storage on the range so that a noisy test does not fill the pipeline. Record the results, including misses and false positives, and feed them back into rule tuning. Once the rules pass in the range, promote them to production in stages, starting with monitoring-only mode, and keep a rollback path for each rule.
Does restricting file permissions stop indicator removal on Linux and Windows hosts?
Restricting file and directory permissions reduces the number of accounts that can delete or truncate log files, which is the purpose of mitigation M1022, Restrict File and Directory Permissions. It does not stop a privileged account from acting, because administrators and root can usually change permissions as well. For that reason, pair permission controls with Remote Data Storage, which keeps a copy of security events on a system the host cannot alter, and with auditing (M1047), which records the act of removal. Confirm the exact guidance for T1070 on the ATT&CK mitigation pages, and validate each control in your environment. DeployOpen can plan and implement self-hosted log forwarding and hardening inside your own infrastructure, and it can test whether the copies survive local deletion in a cyber range.
How DeployOpen builds T1070 detections and range exercises
DeployOpen plans T1070 detection work as a fixed-scope engagement, agreed in writing before any work starts. The scope names the platforms in play for indicator removal, such as Linux hosts, container nodes, ESXi hosts, macOS endpoints and whichever SaaS audit sources the client uses, and it names the telemetry that will be collected for each. Before writing any rule, we ask the client to confirm which log paths are retained, for how long, and whether they are forwarded off the host. Many T1070 gaps are not missing rules but logs that were rotated, truncated or never shipped, so that inventory is the first deliverable, not an afterthought.
Detection logic is built on the open-source stack the client already runs or chooses, typically Wazuh for host telemetry, Security Onion with Zeek and Suricata for network context, and Velociraptor for targeted collection during response. Rules are written against a named ATT&CK version, so the mapping stays traceable when MITRE changes technique content. Each rule is tuned against the client's own administrative baseline, including log maintenance jobs, backup agents and configuration management tools, because those routinely resemble log clearing or timestamp changes. Every rule is documented with its data source, its known false positives and the response step it triggers.
Validation happens in a private cyber range that mirrors the client's platforms. DeployOpen runs purple team exercises in which the client's defenders and our testers agree in advance on which indicator removal behaviors are in scope, then record what fired, what was missed and why. Handover includes the tuned rules, a validation record for each exercise, and a runbook covering triage, evidence preservation and log recovery. Where the client needs compliance evidence, DeployOpen prepares the control mapping, configuration records and test results for independent assessors. Those assessors, not DeployOpen, decide whether any attestation or certification is issued.
