Ethical Hacking
Covering Tracks
After exploitation comes cleanup. Real attackers invest heavily in removing evidence of their presence. Pen testers need to understand every technique — both to assess whether a client would detect an attacker doing it, and because careful cleanup of engagement artefacts is a professional obligation.
Why covering tracks matters — from both sides
An attacker who leaves detailed logs of their activity is an attacker who gets caught quickly. Real threat actors — particularly APT groups operating inside a network for months — devote significant effort to erasing or manipulating evidence of their presence. Log entries deleted. Timestamps altered. Temporary files removed. Installed tools cleared. The goal is not perfect invisibility — it is extending the dwell time before detection by reducing the signal-to-noise ratio in the defender's monitoring tools.
For a pen tester, the topic has two distinct angles. The first is assessment — testing whether the client's log monitoring and integrity controls would detect an attacker attempting to cover their tracks. If an attacker can delete event logs without triggering an alert, that is a finding. The second is operational — pen testers are expected to remove their own artefacts when an engagement concludes. Backdoors removed, created files deleted, modified configurations restored. The cleanup obligation is not optional.
Understanding what real attackers do during this phase also informs incident response. When a SOC analyst sees log gaps — periods where event generation stopped and then resumed — they know what happened. Knowing what to look for is the defender's advantage when the attacker tries to clean up.
Log clearing on Linux
Linux systems maintain several log files that record authentication events, system activity, and command history. An attacker who has achieved root access can modify or clear any of these. The critical point is that clearing logs is itself detectable — a log file that jumps from entries on day one to entries on day three, with nothing in between, is a forensic artefact of its own. Sophisticated attackers do not simply delete log files. They surgically remove specific entries while leaving the surrounding content intact.
Assessment context: The commands below demonstrate what an attacker with root access could do to obscure their presence. In a pen test, these are run only if the scope explicitly includes post-exploitation cleanup testing — and every action taken is documented before execution so the client can verify restoration afterwards.
# Linux log files that record attacker activity — and what each contains
# Requires root to modify — which is why privilege escalation comes first
# /var/log/auth.log — authentication events: logins, sudo usage, SSH attempts
# /var/log/syslog — general system events: service starts, kernel messages
# /var/log/wtmp — binary record of all logins and logouts (read with last)
# /var/log/btmp — binary record of failed login attempts (read with lastb)
# /var/log/lastlog — binary record of each user's most recent login
# ~/.bash_history — every command typed in the current user's shell
# View current SSH login history — shows who logged in, from where, and when
last -n 20
# View failed login attempts — useful for checking what has been recorded
lastb -n 20
# Remove specific lines from auth.log matching the attacker's IP
# sed -i deletes lines in-place — the original file is modified
# /i deletes lines matching the pattern d at the end means delete
# Replace 192.168.56.102 with the attacker's actual source IP
sed -i '/192.168.56.102/d' /var/log/auth.log
# Overwrite bash_history with nothing — suppresses command history entirely
# This is more detectable than surgical removal but faster
cat /dev/null > ~/.bash_history
# Prevent bash from saving any new commands to history for this session
# HISTSIZE=0 sets the in-memory history to zero entries
# export pushes the variable to child processes
export HISTSIZE=0
export HISTFILE=/dev/null
# Remove wtmp entries — last command will no longer show the attacker's session
# utmpdump reads and writes the binary wtmp format as text
# grep -v removes lines containing the source IP
# Then convert back to binary and overwrite the original
utmpdump /var/log/wtmp | grep -v "192.168.56.102" | utmpdump -r > /tmp/wtmp_clean
mv /tmp/wtmp_clean /var/log/wtmpBreaking it down:
The sed command is the standard Unix text manipulation tool. The pattern /192.168.56.102/d finds every line containing the attacker's IP address and deletes it from the file. The surrounding log entries from before and after the attacker's session remain intact — making the log look like a normal period of activity with no gaps. This is significantly harder to detect than simply deleting the entire log file.
Unlike auth.log which is plain text, wtmp is a binary file. Direct text editing corrupts it. The utmpdump tool converts it to readable text, grep removes the attacker's entries, and utmpdump -r converts it back to binary. This workflow preserves the binary format while selectively removing evidence — the last command will show no record of the attacker's session.
Setting HISTFILE to /dev/null redirects all new command history writes to the null device — which discards them silently. Combined with HISTSIZE=0, no history from the current session is retained. This only affects the current session's future commands. Previous history already written to disk requires the cat /dev/null approach to clear.
Log clearing on Windows
Windows records security events in the Windows Event Log — the Security, System, and Application logs visible in Event Viewer. These logs are the primary source of forensic evidence in Windows incident response. Authentication events, privilege use, service installation, and process creation all generate specific event IDs that SOC analysts and forensic investigators rely on.
The critical Windows event IDs for covering tracks are 4624 (successful logon), 4625 (failed logon), 4648 (logon with explicit credentials), 4672 (special privilege logon — indicates admin-level access), and 4698 (scheduled task created). An attacker who clears the Security log removes all of these. A well-configured SIEM that receives events in real time will notice the log cleared event itself — Event ID 1102 — which is a high-confidence indicator of post-compromise cleanup activity.
# Windows event log management — run in an elevated Command Prompt
# These commands require Administrator privileges
# View the most recent Security log entries before clearing
# wevtutil qe queries events /c:20 limits to 20 results /f:text = text format
wevtutil qe Security /c:20 /f:text /rd:true
# Clear specific Windows event logs
# wevtutil cl clears the specified log entirely
# Security log contains authentication, privilege use, and access events
wevtutil cl Security
# Clear the System log — contains service installation and system events
wevtutil cl System
# Clear the Application log
wevtutil cl Application
# PowerShell equivalent — clear all event logs in one command
# Get-EventLog retrieves the list of all logs
# Clear-EventLog empties each one
Get-EventLog -List | ForEach-Object { Clear-EventLog -LogName $_.Log }
# Remove prefetch files — Windows caches recently run executables in prefetch
# Prefetch files can reveal what tools were run on the system even after deletion
# C:\Windows\Prefetch\ contains .pf files named after each executed program
del /f /q C:\Windows\Prefetch\*.pf 2>nulBreaking it down:
When the Security log is cleared on Windows, the system generates Event ID 1102 — which records the account that performed the clearing, the workstation, and the exact time. This event is generated before the log is cleared, so it cannot be removed by the same action that creates it. If the SIEM is receiving events in real time rather than polling the log file, Event ID 1102 arrives at the SIEM before the attacker clears the local log — making it unremovable. This is the primary reason that log forwarding to an external SIEM matters more than local log retention.
Windows prefetch is a performance feature — it pre-loads frequently executed programs to make them start faster. As a side effect, it creates forensic records of every executable run on the system, including the execution count and the last run time. Deleting a malicious tool from disk does not remove its prefetch entry. Forensic investigators routinely find prefetch evidence of tools that were run and deleted weeks before the investigation began. Clearing prefetch is a standard attacker cleanup step — but its absence from the filesystem is itself a finding for a forensic analyst.
Timestamp manipulation — making files look older
File timestamps — created, modified, and accessed times — are a primary source of evidence in digital forensics. When an attacker uploads a tool or creates a script, the creation timestamp reflects when it arrived. An investigator correlating timestamps across a file system can reconstruct exactly when an attacker moved through a system and what they did. Timestamp manipulation — timestomping — overwrites these values to make a newly created file appear to have existed for years.
The critical counter is the MFT — the Master File Table on NTFS filesystems. The MFT stores a second set of timestamps that is significantly harder to modify than the standard file timestamps. Forensic tools read both sets. A file whose $STANDARD_INFORMATION timestamps differ from its $FILE_NAME timestamps is an immediate red flag — it means the visible timestamps were manipulated after the file was created. Timestomping defeats simple timestamp review but fails against MFT-aware forensic analysis.
# Timestamp manipulation — Linux
# The touch command sets file access and modification timestamps
# -t specifies the timestamp in [[CC]YY]MMDDhhmm[.ss] format
# Setting a backdated timestamp makes a new file appear old
# Set the timestamps of a file to match a legitimate system file
# This makes the attacker's tool appear to have existed since the OS was installed
touch -t 202001150930 /tmp/malicious_tool
# More precise — copy the exact timestamps from a legitimate file
# -r uses a reference file's timestamps instead of specifying manually
# /bin/bash is always present with an old creation date
touch -r /bin/bash /tmp/malicious_tool
# Verify the timestamps were changed successfully
stat /tmp/malicious_tool
# Windows timestomping using PowerShell
# CreationTime, LastWriteTime, LastAccessTime can all be set to arbitrary values
$file = Get-Item "C:\Temp\malicious.exe"
$file.CreationTime = "2020-01-15 09:30:00"
$file.LastWriteTime = "2020-01-15 09:30:00"
$file.LastAccessTime = "2020-01-15 09:30:00"Breaking it down:
Linux maintains three timestamps per file: atime (last access), mtime (last modification), and ctime (last status change — including permission or ownership changes). The touch command can set atime and mtime to any value. It cannot set ctime — ctime is always updated to the current time when the file is touched. A forensic analyst seeing atime and mtime from 2015 but a ctime from today knows immediately the timestamps were manipulated. This discrepancy is a forensic red flag that survives even careful timestomping.
Rather than specifying timestamps manually, using a reference file with -r copies its exact access and modification times. Choosing /bin/bash or another core OS binary as the reference produces timestamps that match the system installation date — making the attacker's tool appear to have existed since the OS was set up. This technique is more convincing than an arbitrary date because the timestamp matches a file that investigators would expect to have been present for a long time.
What defenders see — the forensic signals that survive cleanup
Every covering-tracks technique leaves its own forensic residue. Clearing logs is detectable. Timestomping is detectable. Even deleting files is not as final as it appears. Understanding what survives cleanup is what separates an investigation that goes cold from one that successfully reconstructs the attacker's timeline.
Log gaps — the most obvious signal
A log file that stops generating entries for a period and then resumes is immediately suspicious. Normal system activity produces a continuous stream of log events. A gap of several hours in auth.log — or a Security log that was cleared and shows Event ID 1102 — tells a forensic analyst exactly when the attacker was active and what they tried to hide. Log forwarding to an external SIEM that the attacker cannot access makes this evidence irremovable regardless of what happens to the local log files.
MFT entries on NTFS — the second set of timestamps
Every file on an NTFS filesystem has two timestamp entries in the Master File Table — $STANDARD_INFORMATION (which can be modified with standard tools) and $FILE_NAME (which can only be updated by the filesystem driver itself). PowerShell timestomping updates $STANDARD_INFORMATION but cannot touch $FILE_NAME. When these two entries differ, forensic analysts know the visible timestamps were manipulated — and the $FILE_NAME timestamp reflects the real creation time.
Filesystem journal and shadow copies
NTFS maintains a change journal — $UsnJrnl — that records every file operation: creation, modification, deletion, renaming. It is circular and eventually overwrites itself, but it often retains several days of evidence. Volume Shadow Copies — Windows automatic backups — preserve point-in-time snapshots of the filesystem. A file deleted at 10am may still exist in a shadow copy taken at 8am. Attackers frequently delete shadow copies specifically to prevent this recovery path, which is itself a significant forensic event.
Memory forensics — what survives on disk
Fileless malware — code that executes entirely in memory without writing to disk — defeats file-based forensic analysis but leaves traces in RAM. Memory forensics tools can extract running processes, injected code, network connections, and decrypted strings from a memory dump. Even after a system reboot clears RAM, registry hive files, page files, and hibernation files often preserve memory artefacts that reveal what was running. Volatility is the standard memory forensics framework used by incident responders.
Pen tester cleanup obligations — what must happen before closing an engagement
Every artefact created during an engagement must be removed before it closes. This is not optional and is not negotiable. A pen tester who leaves backdoors, uploaded tools, modified configuration files, or created user accounts on a client's system after an engagement ends is a liability — both to the client and to the firm.
The irony in this lesson is that the techniques attackers use to erase their presence are also the techniques pen testers use to clean up after themselves — the motivation is different but the commands are the same. The difference is that a pen tester documents every action before taking it and confirms restoration afterwards. An attacker has no such obligation. That documentation habit is what distinguishes professional engagement work from amateur exploitation.
Teacher's Note: The most important forensic lesson in this topic is not about the attacker — it is about the defender. Log forwarding to an external SIEM is the single control that makes most covering-tracks techniques futile. If events arrive at the SIEM in real time, clearing the local log removes nothing from the investigation. Clients who have a SIEM but are not forwarding all authentication and privilege use events are getting almost none of the benefit from their investment.
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 35
Attack Mitigation
Hardening frameworks, defence maps, and how everything covered in Section III translates into specific controls that reduce real-world attack surface.