Covering Tracks After an Intrusion
1. Introduction and Objectives
This phase, not covered in the cycle of “professional ethical hacking” but indeed in “Red Team Operations,” is necessary to gain a deeper understanding of the MITRE methodology used by many black/grey hats. Furthermore, it’s also valuable for those tasked with performing forensic analysis on the victim system.
After the attacker has completed their intrusion into the victim system, they should erase their tracks by deleting system event log files, as well as other specific programs and services that were used for exploitation. This action makes detection and forensic analysis more challenging.
During a “Red Team Operation,” the deletion and elimination of traces are of paramount importance. This way, the “Blue Team” responsible for defending the computer systems will face greater difficulty in their tasks of detection and investigation.
Undoubtedly, the primary goal of erasing intrusion traces is to ensure that nobody ever becomes aware of the existence of that intrusion.
2. Entering the subject
If we talk about system logs, we are referring to those system files where every action performed by the user within the machine is recorded.
Regarding the tracks or traces that might exist, it’s important to note that there are as many types of these as there are types of attacks carried out. Each attack is different from the previous one, and therefore each scheme of actions for erasing traces will also be different. However, let’s try to define a general framework that can be used as a “check-list” to maintain a more systematic and organized approach.
The first thing we must consider is the intrusion methodology we have employed, which ports and services we have compromised. Essentially, we need to understand what we have done and think deeply about how “Blue Teamers” might uncover our actions during a forensic analysis.
To better understand this proposition, let’s draw a parallel to the physical world. When it comes to breaking into a house, intrusions can be executed in various ways:
- Forcibly breaking down the door.
- Using a lever for brute-force entry.
- Employing more sophisticated methods like lock bumping or lock picking.
To eliminate traces after an intrusion into a residence, in the first case, the entire door might need to be reconstructed. In the second case, minor repairs may be sufficient. And in the third case, only the “master keys” or lock-picking tools need to be disposed of.
During an intrusion, a variety of tools are used: trojans, backdoors, sniffers for capturing network traffic, services from the victim’s system, etc.
Many “Red Teamers” merely erase access logs for the services they’ve used and delete the tools they employed to carry out the intrusion (webshells, backdoors, rootkits, exploits, etc.). As we will see throughout this article, merely performing these actions isn’t sufficient to go unnoticed.
To carry out these elimination tasks, it’s worth mentioning that there are many “zapper” type tools available today that automate these removal processes. However, it’s advisable to develop our own tools, using others as a reference, since generally, open-source “zappers” might not be completely efficient.
Naturally, the proper elimination of files in the victim’s system will depend on the privileges of the user with whom we are conducting our operations.
3. Erasing Traces in Windows
In Windows operating systems, you can find the various system event logs in the following directory:
- “%SystemRoot%\System32\Winevt\Logs”
To carry out the deletion of specific security log files on a Windows system, we will use various commands which we will see below.
a) Using “Wevtutil”
We will use the following tools to copy the list of various events that have occurred in the system to a file, and then search for the word “security” to locate those events related to system security that need to be deleted.
- C:\>wevtutil el > logs.txt
- C:\> type logs.txt | find /i “security”
The “gl” option displays the configuration information of the specified log, which includes whether the log is enabled or not, the maximum limit corresponding to the log file size, and the path to the file where the log is stored.
- C:\> wevtutil gl Security
The “gli” option displays information about the status of the specified log.
- C:\> wevtutil gli Security
Once we have identified the name of the log we want to delete, we proceed to delete the entire event log file for “Security.” Of course, any event log file can be deleted. Below is the command to completely delete the selected file.
- C:\> wevtutil cl Security
From this point onward, the security events are deleted. If we proceed to view the content of the “Security” log file using the Windows Event Viewer, we will see that only the existence of a single event is recorded.
This tool (wevtutil) offers various options, including those that allow you to modify the configuration of specific logs, archive them, export them, among other options that you can see in its help context (wevtutil /?).
b) Using “PowerShell”
This task of event log deletion can also be performed using commands in PowerShell. Some of the most useful commands for this purpose are as follows:
- PS C:\>Clear-Eventlog -Log Application, System
- PS C:\>Get-WinEvent -ListLog Application,Setup,Security -Force | % { Wevtutil.exe cl $_.Logname }
We should be aware that through these cleaning actions, a secure deletion of the directory where the file was located is not performed. That’s why after a forensic analysis, it might be possible to recover (either partially or entirely) the log file, and thus the events it contained.
c) Using “Metasploit”
If the intrusion was carried out by obtaining a “Meterpreter shell,” we can also use Metasploit’s own tools to perform the cleanup of traces. To do this, we need to load the “incognito” module and then use the “clearev” command:
- meterpreter> load incognito
- meterpreter> clearev
[*] Wiping 102 records from Application…
[*] Wiping 236 records from System…
[*] Wiping 48 records from Security…
d) Using “Clearlogs”
To conclude, let’s mention another excellent and effective tool for clearing access logs in Windows environments. This tool is called “Clearlogs.” Its usage is straightforward—simply execute the command “clearlogs.exe -sec”. You can download the tool from the following link:
https://sourceforge.net/projects/clearlogs/
4. Covering Tracks in Unix
In these types of systems, each program generally uses the “syslogd” daemon to generate its own event logs.
A good method for carrying out the elimination of these logs is by using the “Shred” tool (command “shred -zu ‘*.log'”). This tool destroys and makes it practically impossible to recover the information stored on the disk.
Another tool to consider for this phase is “secure-delete”. This tool performs multiple deletions of the specified file and also allows for the deletion of entire directories. You can install it using the command “apt-get install secure-delete”, and it can be launched from the command line using “srm -r directory”.
Among the most commonly used methods for covering tracks in these systems are:
a) Disabling the victim’s system
This step is executed when the intrusion has left so much trace that there is no other option. It will obviously depend on the privileges one has on the victim’s system. The most common approach is to disable system entry (login) and cause internal system damage in a way that it cannot be recovered without formatting the system.
Here are some relevant files:
/etc/passwd
/etc/shadow
/bin/login
/etc/inetd.conf
b) Remove Apache event logs
If a web-based attack, such as through the use of a webshell, has been executed, it’s advisable to delete related log files. The most common Apache logs can be found in the following directories:
apache/logs/
etc/httpd/logs/
var/www/logs/
var/log/
usr/local/apache/logs/
var/log/apache/
var/log/apache2/
c) Clearing Command Line History
One of the simplest ways to obtain information about a user is to view their command history on the system. Therefore, it’s necessary to delete or partially modify this history after performing our operations. To do this, you should:
- Edit or Delete the History File: Edit or delete the “.bash_history” or “.sh_history” file in the user’s directory (“/home/user/.bash_history”). This file keeps a record of all the commands executed by the user you’re working with. Each user has their own “bash history” in their home directory.
- Clear Past and Current History: Completely clear both past and current session history using the command: “cat /dev/null > ~/.bash_history && history -c”
Keep in mind that this action should be performed just before finishing your work to ensure that any sensitive command history is removed.
d) Eliminate the tools and utilities used during the attack
We must pay special attention to not leave any tools used for system exploitation. It’s common to upload exploits and compile them on the victim machine for tasks like privilege escalation, capturing network traffic, among others. If we leave any tools of this kind on the victim system, sooner or later they will expose us, and we will be discovered.
e) Not leaving backdoors in the victim system
During a short period of time, it might go unnoticed, but one must be cautious because over time, it could be discovered. If discovered, an investigation may be initiated, leading to further revelations of the intrusion through thorough forensic analysis. That’s why we should be cautious and keep backdoors active for a reasonable and prudent amount of time to avoid detection.
f) Removing created user accounts on the victim machine
When conducting an intrusion that requires privilege escalation, we often exploit security vulnerabilities by launching exploits that automatically create new users with administrative privileges. We must not forget to delete these users before concluding our work.
g) Pay attention to whether someone else is working on the system
We often carry out intrusions on systems where other users are connected. This can be observed using the “who” command. We must pay special attention to this, as there is a possibility that someone is monitoring the system activity and could discover us.
h) Commands of Interest
- “who”: List of active users on the system.
- “last”: Last logged in users.
- “lastb”: Last failed login attempts.
- “ps”: Active processes.
- “lastcomm” / “history”: Commands executed in the system.
- “unset”: We use this command to stop recording the history of commands executed from the terminal. Launch it with: “unset HISTFILE; unset SAVEHIST”.
i) Dangerous files
- “utmp”: It keeps a record of events for users who are using the system while they are connected. Directories: “/var/adm/utmp” and “/etc/utmp”.
- “wtmp”: It logs each time a user logs in or out of the system.
- “lastlog”: It logs the exact moment when a user last logged into the system.
- “acct” o “pacct”: It records all the commands executed by each user, but it doesn’t record the arguments with which those commands were executed.
- “.bash_history” y “.sh_history”: as mentioned earlier.
- “touch”: is used to reset the date and time of the last access to a file, among other functions.
In Linux systems, the main event and system service logs can be found in the following directory:
- “/var/log”
j) Programs and Tools of Interest
- “TCP-Wrapper“
This is a tool similar to “Syslog,” but it is linked to exclusive services such as FTP, telnet, mail, etc. In addition to logging all activity related to the authentication of these services, it is capable of filtering them, restricting access so that only certain users can connect.
To eliminate the traces we generate in this service, we should follow the same process as with “Syslog,” which means finding its configuration file and modifying its associated files.
- “Wzap“
“Zapper” is responsible for erasing a specific user from the “wtmp” log.
- “Zap2“
This is a “Zapper” that deletes the “wtmp,” “utmp,” and “lastlog” files. Keep in mind that when you copy the source code, you should be aware of the victim’s system to change the paths where the logs to be deleted are located.
Example of the line of code to modify:
#define WTMP_NAME “/usr/adm/wtmp”
#define UTMP_NAME “/etc/utmp”
#define LASTLOG_NAME “/usr/adm/lastlog”
- “Metasploit”
Just like in a Windows system, if the intrusion has been carried out using a “Meterpreter Shell,” we can perform the covering of tracks by loading the “incognito” module and then executing the “clearev” command.
k) Android system
Regarding Android systems, it’s important to note that they generate various system logs and logs from other applications running on the device. These files cannot be deleted unless you have administrator privileges on the system. The logs can be found in the directory “/data/log” on the local device.
Once you have finished removing the traces generated during your intrusion on the victim’s system, you can consider your mission concluded.
