by In any case where an exploit will destabilize a live production system, you should be cleaning up directly after. However, for everything else, you can wait until the report has been handed off to begin your cleanup tasks. The purpose of these tasks is to ensure that there are no artifacts left over that an attacker could exploit or that could lead to more risk than the organization is willing to tolerate.
Some common cleanup tasks include, but are not limited to:
- Delete any new files you created from the affected systems.
- Remove any credentials or accounts you created from the affected systems.
- Restore any original configurations you modified.
- Restore any original files that you modified or otherwise compromised.
- Restore any log files you deleted.
- Restore any original log files you modified or otherwise compromised.
- Remove any shells, RATs, or other backdoors from the affected systems.
- Remove any additional tools you may have left on the affected systems.
- Purge any sensitive data exposed in plaintext.
- Restore a clean backup copy of any apps that you compromised.
Note that, while you can perform these tasks manually, you’ll save yourself time and effort by automating cleanup through the use of scripts. These scripts can, in many cases, simply revert malicious configuration changes, uninstall malware, restore deleted logs, etc. Of course, in order to properly automate cleanup tasks, you’ll need to have kept meticulous records on all of the exploits you launched, including what the exploits did and how they did it.
Removal of Credentials
Removing tester-created credentials, shells, and tools that were installed on systems as part of the pen test is not necessarily a simple task. These exploits might be deeply embedded in the target systems, especially if you applied evasive techniques to escape notice. Or, the breadth of these exploits might make it difficult to track and manage them across all affected systems, even if you kept records.
When it comes to removing credentials you created during the test, keep in mind that not all authentication systems are alike. While you can simply log on to a local system and delete any local credentials you created on the system, the same can’t be said for Active Directory (AD) domain accounts. If you created an AD account from a domain controller (DC), then used that account to sign in to a workstation, simply removing the account from the workstation won’t remove it from the domain. You’ll need access to the DC to delete the AD account; otherwise, a real attacker might be able to leverage this account by using it to sign in to a domain computer.
Another concern with removing test credentials is that they might be integrated so tightly into a particular system that deleting the credentials could lead to system corruption or other issues. For example, systems that place a strong emphasis on an audit trail or a change history (e.g., wiki software) might not provide a delete account feature on the standard interface to preserve the integrity of changes and/or versions. In these cases, you may need to remove the test accounts from the user database directly, assuming you actually used them to make changes in a production environment.
Removal of Shells and Other Tools
As for removing shells, you need to remember that you likely tried to hide them on the target systems. In fact, you may have hidden them in multiple ways so that other shells could compensate if one were discovered. Make sure to remove any values added to the HKLM and HKCU Run Registry keys that start a shell on system boot. Also make sure to remove any scheduled tasks in Windows Task Scheduler or the Linux crontab file that call a shell. Just because you can’t see the shell running on the system when you check it doesn’t mean it isn’t lying dormant, waiting to be called by a scheduling service. Likewise, if you added a Netcat binary or other shell software to the target system, then you should also remove it so that an attacker can’t take advantage of it.
Besides shells, you’ll also need to remove other tools that you added to a system to enable its compromise, like Metasploit payloads, keyloggers, and vulnerability scanner agents. Some of these tools might be loaded into memory and are therefore automatically removed on system reboot (e.g., certain Metasploit payloads), whereas others linger on the target system until manually uninstalled. For the latter, a superficial deletion of the tool is not necessarily enough—you may need to, when possible, shred the tool and any associated files so that they cannot be recovered by an attacker or curious user.
Whether you’re removing credentials, shells, tools, or some other component added in the test, you need to watch out for collateral damage. Be sure that you’re only removing test accounts and not legitimate user accounts. Take care not to remove any tools and other software that are crucial to the target system’s operations. Ultimately, you want to leave the target systems in the state you found them.