192. Post-report Activities (OBJ 4.2)
In this section of the course, we’re going to discuss the different actions that you need to perform after your report has been completed and delivered to your client. As we move through this section, we’re going to continue looking at the fourth phase of our engagement, reporting and communication. This section of the course is going to be focused on objective 4.4, which states that you must explain post-report delivery activities. The purpose of the post-report delivery activities is to ensure that there are no artifacts or evidence left on the target organization system, now that the penetration test has been concluded.
Now, there are many different tasks that you’re going to conduct as part of this cleanup. This includes the deletion of any new files that you may have created on their systems, the removal of any new accounts or credentials that you create on their systems, and the removal of any shells, Trojans, back doors or other tools that you may have installed. In addition to this, you should also restore any original configurations back to their state from before the penetration test began, and you should replace any files you modified or compromised with known good backups.
If you’ve modified any of the log files, you also need to restore those, and you should restore a clean copy of any apps that you may have compromised during your exploits. You’re also going to need to purge any sensitive details that you may have exposed in plain text. For example, you may have some credentials that you compromised and cracked into, and put those back into plain text. At this point, you want to make sure those are deleted or encrypted. In general, you’re going to want to wait until the end of the penetration test to perform all these cleanup actions. But if you destabilized a production system when you launched an exploit during your attack phase, you can also stop at that point and clean up and restore those systems immediately during that attack phase, using the same techniques that we’re discussing here in this section.
That way you can restore it to full operations by restoring its applications or original files back to their pre-exploited states. So as we jump into this section, we’re going to first discuss how we remove shells and tools from the targeted systems. Then we’re going to discuss the importance of deleting any test credentials that you may have created on those systems. After that, we’ll discuss how to properly destroy test data from the systems at the end of your engagement. And then we’ll discuss the client acceptance process and the importance of completing the attestation of findings as part of your post-delivery activities. Next, we’re going to talk about the lessons learned process and how it’s used to continually improve your penetration testing processes. Finally, we’re going to discuss any considerations that you need to think about when you plan a retest of that target organization. All right, it’s time to finish up our coverage of domain four, reporting and communication with the post-report activities in this section of the course.
193. Removing Shells and Tools (OBJ 4.2)
In this lesson, we’re going to talk about removing shells and tools. At the conclusion of your penetration test, you need to remove all of the shells and tools you’ve installed on those victimized systems. For this reason, it is very important that you keep detailed notes of everything you’ve installed and every system that you’ve exploited during your engagement. Now, when it comes removing those shells from those systems, you’re going to have to remember exactly where you put them and how you have them set to launch. If you’re on a Linux system, did you have them set up to be called by a Crontab process? Or did you put ’em inside the startup scripts, like the slash etc slash in it D or slash etc slash system D files?
Now, if you’re on a Windows system, you need to remember where you put those as well. Maybe you put them as a startup item. Maybe you put them as part of the registry key inside the HKLM or HKCU hives underneath the run registry keys. Or maybe you’re doing an advanced technique, like installing your shell as part of a DLL injection process that you’ve now taken over an actual DLL inside the library of the Windows system.
Or maybe inside the Windows system, you used the Windows task scheduler to call some kind of a program that you hit on there that looks very benign like a regular game or something like that. Whatever it is, you need to go back and find all of those things that you installed and take out all of those scheduled tasks, all of those Cron jobs, all those registry keys, and all of those scripts from those systems to make sure your shells will no longer load, and then you need to also remove those shells.
Remember, you put all these things to exploit those systems and it would be a really bad thing if some attacker was able to get in there and use those shells to their own advantage against your target organization. So make sure you’re always going back and checking for any scheduled services or daemons, and removing all of the binaries and shells that you put on those systems, whether they were customized or whether there’s something off the shelf, like the Meterpreter payload or Netcat.
Now another thing you need to think about is any other tools you may have installed on that system beyond those shells. For example, maybe you put some kind of a payload on there, a keylogger, a packet sniffer, or a vulnerability scanning agent on one of these systems. Anything you’ve installed, now needs to be removed and taken off those systems. Some tools may have been loaded into memory because you’re using fileless malware as well. If that’s the case, those will actually be taken out the next time you reboot the system. So if you work with the system administrators of the target organization, they can schedule reboot and remove those things from memory. Essentially, our goal here is to put the system back the way it was before we started our penetration test, so we want to make sure all the persistence we’ve added and all the shells and tools we’ve put on are now removed and the system is back into a known good state.
194. Deleting Test Credentials (OBJ 4.2)
In this lesson, we’re going to talk about the importance of deleting your test credentials. Now, during your engagement, you may have created additional user accounts for you to be able to maintain persistence on those given systems. These could have been local accounts, or they may have been domain accounts; and in some cases, you may have created accounts on a web application as well.
As you’re going through your engagement, it is important that you keep notes of every single user account and every group you’ve affected when you created these accounts; that way, at the end of the engagement, you can go back and remove these different accounts. Now, if you’ve used these accounts on different systems, you’re going to need to go back into each of those systems and delete those accounts from there.
If you’ve created a domain account, you’re going to need to go back into active directory and delete your account there as well. Now, in the case of some web applications, there may be times when the accounts cannot be deleted. For example, if you’re using a system that uses version control, these systems may not allow you to actually delete an account, but you can only archive an account.
In these cases, you’re going to want to work with the organization to have them go manually into the user account database and delete your account. If you can’t do that, you’re going to want to make sure they implement a very long, strong, and complicated password and disable that account from an interactive login; that way, that account can’t be used for further attacks by other people if it’s being left on the system.
In general, our rule of thumb is always to delete every account that we’ve ever created as part of the engagement; that way, there is no trace that we’ve been on those systems once we leave the network at the conclusion of the engagement. Again, though, if there are some cases where that is not possible, you will need to work with the organization directly to make sure they know about those accounts and they can account for them. So they realize they’re put there by the penetration tester and not by some other attacker who’s coming in later.
