Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1070.009: Clear Persistence

Adversaries may clear artifacts associated with previously established persistence on a host system to remove evidence of their activity. This may involve various actions, such as removing services, deleting executables, Modify Registry, Plist File Modification, or other methods of cleanup to prevent defenders from collecting evidence of their persistent presence.[1] Adversaries may also delete accounts previously created to maintain persistence (i.e. Create Account).[2]

In some instances, artifacts of persistence may also be removed once an adversary’s persistence is executed in order to prevent errors with the new instance of the malware.[3]

EnterpriseT1070.009Sub-techniqueObject v2.0 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

Clear Persistence is a stealth behavior where an adversary removes traces of persistence they previously established, such as services, executables, registry changes, plist changes, or accounts. For leaders, the risk is not just cleanup—it can erase the evidence needed to understand scope, prove containment, and make confident incident decisions across Windows, Linux, macOS, and ESXi environments.

Executive priority

Treat this as an incident-readiness and evidence-preservation priority. If persistence artifacts can be deleted without reliable off-host logging or privileged change visibility, responders may lose the timeline needed for containment, audit evidence, and recovery confidence. Executives should ask whether critical hosts forward security telemetry centrally, whether privileged users and processes can modify persistence locations, and whether SOC playbooks explicitly investigate removed persistence—not only newly created persistence.

Technical view

ATT&CK provides no official detection text, but the related DET0040 strategy indicates defenders should monitor persistence artifact removal across host platforms. SOC and IR teams should validate visibility into deletion or modification of services, executables, registry keys, plist files, local accounts, and other host persistence mechanisms. Detection should focus on suspicious removal patterns, especially when performed by unusual users, unexpected processes, remote sessions, or shortly after evidence of persistence creation. Relationship context shows multiple Windows software entries using this behavior, while the technique platforms also include ESXi, Linux, and macOS, so coverage should not be Windows-only.

Likely telemetry

  • Endpoint file creation, modification, and deletion events for persistence-relevant paths
  • Windows service creation, modification, and deletion audit data
  • Windows registry modification and deletion telemetry
  • macOS plist modification and deletion telemetry
  • Linux and ESXi file and service configuration change logs where available

Detection direction

  • Validate that detections cover removal as well as creation of persistence artifacts.
  • Correlate artifact deletion with prior persistence indicators, suspicious process execution, or account lifecycle changes.
  • Tune for administrative false positives such as software uninstallers, patching, configuration management, and legitimate account deprovisioning.
  • Prioritize alerts where deletion is performed by non-standard processes, unusual principals, or outside approved maintenance windows.
  • Check blind spots on ESXi, Linux, and macOS, especially where endpoint telemetry is less mature than Windows telemetry.

Mitigation priorities

  • Apply M1022 by restricting file and directory permissions so only authorized users, groups, or processes can modify persistence-relevant locations.
  • Apply least-privilege access to reduce who can delete services, executables, configuration files, plist files, registry keys, or accounts associated with persistence.
  • Apply M1029 by forwarding critical security logs and forensic evidence to secure remote storage so local artifact cleanup does not eliminate the incident record.
  • Review privileged administration workflows to ensure legitimate cleanup is auditable and distinguishable from adversary-driven removal.
  • Use incident response procedures that preserve volatile and host evidence before remediation removes remaining artifacts.
Analyst notes and limits

This technique sits under Indicator Removal and is associated with the stealth tactic. The relationship set includes DET0040 plus mitigations M1022 and M1029, and multiple software examples, many of which are Windows-focused. That relationship context supports prioritizing Windows coverage, but the official platform list also requires validation for ESXi, Linux, and macOS where present in the environment.

MITRE provides no official detection guidance for this object, so detection recommendations are derived from the official description, platforms, tactics, and supplied relationships. Local asset inventory, logging configuration, administrative workflows, and EDR/audit capabilities are required to determine actual coverage. This summary does not assert active exploitation or guaranteed detection.

Official MITRE ATT&CK definition

Clear Persistence

Adversaries may clear artifacts associated with previously established persistence on a host system to remove evidence of their activity. This may involve various actions, such as removing services, deleting executables, Modify Registry, Plist File Modification, or other methods of cleanup to prevent defenders from collecting evidence of their persistent presence.[1] Adversaries may also delete accounts previously created to maintain persistence (i.e. Create Account).[2]

In some instances, artifacts of persistence may also be removed once an adversary’s persistence is executed in order to prevent errors with the new instance of the malware.[3]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Related techniques

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1070 Indicator Removal This object subtechnique of Indicator Removal.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0534: Bazar

Bazar is a downloader and backdoor that has been used since at least April 2020, with infections primarily against professional services, healthcare, manufacturing, IT, logistics and travel companies across the US and Europe. Bazar reportedly has ties to TrickBot campaigns and can be used to deploy additional malware, including ransomware, and to steal sensitive data.[1]

Windows
Malware Enterprise

S1132: IPsec Helper

IPsec Helper is a post-exploitation remote access tool linked to Agrius operations. This malware shares significant programming and functional overlaps with Apostle ransomware, also linked to Agrius. IPsec Helper provides basic remote access tool functionality such as uploading files from victim systems, running commands, and deploying additional payloads.[1]

Windows
Malware Enterprise

S0385: njRAT

njRAT is a remote access tool (RAT) that was first observed in 2012. It has been used by threat actors in the Middle East.[1]

Windows
Relationship explorer

All related ATT&CK context

uses · Malware S0559: SUNBURST Enterprise uses · Tool S0500: MCMD Enterprise uses · Malware S0534: Bazar Enterprise uses · Malware S1132: IPsec Helper Enterprise uses · Malware S0013: PlugX Enterprise uses · Malware S0517: Pillowmint Enterprise mitigates · Mitigation M1022: Restrict File and Directory Permissions Enterprise uses · Malware S0083: Misdat Enterprise subtechnique of · Technique T1070: Indicator Removal Enterprise uses · Malware S1190: Kapeka Enterprise uses · Malware S0085: S-Type Enterprise uses · Malware S0385: njRAT Enterprise uses · Malware S0669: KOCTOPUS Enterprise detects · Detection Strategy DET0040: Detection of Persistence Artifact Removal Across Host Platforms Enterprise uses · Malware S1232: SplatDropper Enterprise uses · Malware S0632: GrimAgent Enterprise mitigates · Mitigation M1029: Remote Data Storage Enterprise uses · Malware S1130: Raspberry Robin Enterprise uses · Malware S0148: RTM Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1022: Restrict File and Directory Permissions

Restricting file and directory permissions involves setting access controls at the file system level to limit which users, groups, or processes can read, write, or execute files. By configuring permissions appropriately, organizations can reduce the attack surface for adversaries seeking to access sensitive data, plant malicious code, or tamper with system files.

Enforce Least Privilege Permissions:

- Remove unnecessary write permissions on sensitive files and directories. - Use file ownership and groups to control access for specific roles.

Example (Windows): Right-click the shared folder → Properties → Security tab → Adjust permissions for NTFS ACLs.

Harden File Shares:

- Disable anonymous access to shared folders. - Enforce NTFS permissions for shared folders on Windows.

Example: Set permissions to restrict write access to critical files, such as system executables (e.g., `/bin` or `/sbin` on Linux). Use tools like `chown` and `chmod` to assign file ownership and limit access.

On Linux, apply: `chmod 750 /etc/sensitive.conf` `chown root:admin /etc/sensitive.conf`

File Integrity Monitoring (FIM):

- Use tools like Tripwire, Wazuh, or OSSEC to monitor changes to critical file permissions.

Audit File System Access:

- Enable auditing to track permission changes or unauthorized access attempts. - Use auditd (Linux) or Event Viewer (Windows) to log activities.

Restrict Startup Directories:

- Configure permissions to prevent unauthorized writes to directories like `C:\ProgramData\Microsoft\Windows\Start Menu`.

Example: Restrict write access to critical directories like `/etc/`, `/usr/local/`, and Windows directories such as `C:\Windows\System32`.

- On Windows, use icacls to modify permissions: `icacls "C:\Windows\System32" /inheritance:r /grant:r SYSTEM:(OI)(CI)F` - On Linux, monitor permissions using tools like `lsattr` or `auditd`.

Mitigation Enterprise

M1029: Remote Data Storage

Remote Data Storage focuses on moving critical data, such as security logs and sensitive files, to secure, off-host locations to minimize unauthorized access, tampering, or destruction by adversaries. By leveraging remote storage solutions, organizations enhance the protection of forensic evidence, sensitive information, and monitoring data. This mitigation can be implemented through the following measures:

Centralized Log Management:

- Configure endpoints to forward security logs to a centralized log collector or SIEM. - Use tools like Splunk Graylog, or Security Onion to aggregate and store logs. - Example command (Linux): `sudo auditd | tee /var/log/audit/audit.log | nc 514`

Remote File Storage Solutions:

- Utilize cloud storage solutions like AWS S3, Google Cloud Storage, or Azure Blob Storage for sensitive data. - Ensure proper encryption at rest and access control policies (IAM roles, ACLs).

Intrusion Detection Log Forwarding:

- Forward logs from IDS/IPS systems (e.g., Zeek/Suricata) to a remote security information system. - Example for Suricata log forwarding: `outputs: - type: syslog protocol: tls address: `

Immutable Backup Configurations:

- Enable immutable storage settings for backups to prevent adversaries from modifying or deleting data. - Example: AWS S3 Object Lock.

Data Encryption:

- Ensure encryption for sensitive data using AES-256 at rest and TLS 1.2+ for data in transit. Tools: OpenSSL, BitLocker, LUKS for Linux.

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
2.0
Created
Modified
Raw hash
4bdef41d6ab41d9b...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 2.0 Current bundle 4bdef41d6ab4…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Cylance Dust Storm

    Gross, J. (2016, February 23). Operation Dust Storm. Retrieved December 22, 2021.

    Open source URL
  2. [2]
    Talos - Cisco Attack 2022

    Nick Biasini. (2022, August 10). Cisco Talos shares insights related to recent cyber attack on Cisco. Retrieved March 9, 2023.

    Open source URL
  3. [3]
    NCC Group Team9 June 2020

    Pantazopoulos, N. (2020, June 2). In-depth analysis of the new Team9 malware family. Retrieved December 1, 2020.

    Open source URL
  4. [4]
    mitre-attack T1070.009
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use