Post-exploitation is an often overlooked aspect of penetration testing. In the past, many even considered the job to be complete the moment that shell access is gained on a remote target machine. Goal-oriented pentesting will require more than this. There must be a specific goal, such as accessing a critical database or obtaining key credentials that will allow an attacker to read private corporate e-mails, for the penetration test to be of value. Business owners and managers are concerned with protecting the confidentiality, integrity, and availability of their assets and data. Reporting that a random system was easily compromised means very little compared to providing tangible proof that an attacker could effortlessly cost the company millions of dollars in missed sales due to a vulnerability affecting a critical system that is externally facing.
In this chapter, we will be covering many areas of interest, including:
- Rules of Engagement with regards to post-exploitation
- Data gathering techniques
- Gaining stored credentials
- Elevation of privilege
Tip
As much as we would like to, we cannot provide a direct step-by-step instructional guide for every situation you will face as a penetration tester. We do hope that we are providing the guidance necessary to develop the skill set and mindset necessary to properly inspect and verify the security of secured environments. Penetration testing requires dedication and the ability to find and act upon clues. There are many recipes for specific exploitation and post-exploitation, but without the proper technical understanding and background, these recipes will only lead to confusion. Taking the time to fully understand the operating systems and technologies being tested is critical and of utmost importance to any penetration test.
During a goal-oriented penetration test, the environment will be evaluated using similar techniques to those used by attackers in the wild. With this in mind, the Rules of Engagement are absolutely critical and must be followed carefully. During the post-exploitation phase of a penetration test, there is a good chance that sensitive data could be disclosed; systems that must follow government regulations may be targeted, or passwords that are hardcoded may be found. Be sure to make clients aware of this fact, and prepare the necessary documentation that specifically details what is and what is not acceptable. In some cases, you may be able to test development environments in tandem with the production environment; if this is the case, be sure to look out for password reuse from development to production.
Tip
WARNING
The Rules of Engagement are very important for all phases of the penetration test, but this is particularly the case when it comes to post-exploitation. If you have any questions about the Rules of Engagement in regards to post-exploitation or any other phase, please seek legal counsel prior to performing a penetration test for anyone to ensure that all bases are covered.
Assess the goal of the penetration test and determine what will need to be accomplished to prove the existence of one or more exploitable vulnerabilities that allow the goal to be achieved. For example, if a denial-of-service (DoS) attack that diverts local resources to resolving the issue is required, are you allowed to perform it? Will the business understand that attacking one seemingly unimportant system may give you the opening you need to take on something more important while they are busy trying to resolve the "problem"? How many people on your team are allowed to perform the agreed upon tasks? Think of all possibilities, and then ensure that they are all necessary and approved before you proceed with the test. Simply gaining a VNC session on a system could break your Rules of Engagement unless this has been discussed with your client prior to testing.
Does the environment you are targeting allow you to add or remove accounts, change log files, or launch internal attacks via pivoting? If so, does your client approve of this and all associated risks involved? As simple as it seems, everything needs to be addressed in the Rules of Engagement. No assumptions should be made. Testing an actual secured environment will take a lot of planning and forethought to ensure that you have the permissions necessary to truly test the environment and mimic the attacks that an actual attacker is likely to use.
When performing a test on a large network, it may be necessary to add persistence to key systems. This will allow you to bypass any restrictions or changes made during the test. It also mimics the typical action an attacker would take. After all, how frustrating would it be to gain a rootshell on a system only to have the corporate patch cycle kick in and stop you in your tracks? But, if this does happen, be sure to compliment the security team!
There are different types of persistence that should be considered: are you allowed to root kit a machine, or just install a process that waits on a port? What about back doors to existing services, or even setting up tasks that kick off when you knock on certain ports? There are different levels of persistence and depending on the size and configuration, persistence can make a tester's life much easier. Make a determination of what is necessary to reach your goal, and ensure that you have all of the permissions covered before you test.
The data collected from client-owned assets should be guarded carefully. Set up ground rules before testing in regards to password management, reporting, third-party involvement (what are you using to crack those password hashes?), and everything else that involves client data.
Agree in advance upon how this data will be transferred, stored, and cleaned, so that there are no questions or doubts after the fact. Another item of note includes how you will handle any incident or information that indicates there is an unknown and possibly hostile attacker already in the network. Third-party security incident response teams have very specific methods of handling these situations to ensure the incident is handled properly.
Find out what the laws and regulations, as well as the policies regarding employee information are in regards to each specific job. If the information contained on a system does not belong to the client, are they even able to grant you permission to view, possibly copy, and store any of this data? A good contract that has been properly reviewed by legal counsel that is familiar with this type of work is advised.