Exploit Testing

At this phase you are testing potential exploits that may bear fruit. You may have an overall goal of what you want the exploit to accomplish but that is not always the first thing you should try to see if the service is in fact vulnerable. Most of the time you will want to develop a proof of concept (POC) to prove that there is a vulnerability before spending time developing a payload that gets you to your goal.

There is no way that I can detail exploit testing on all types of exploits. For one, I'm new to this. For two, there are way too many out there. When developing an POC test, think of what is the least complicated payload that you can develop that gives you the most amount of information.

For example, let's look at abusing Apache James 2.3.2. There is a potential vulnerability that would allow an attacker to have code ran after boot and after every time someone logs in. To test this, it may be tempting to simply create a reverse shell and fire that off. However, consider the complexity and how many moving parts are in even the simplest reverse shell. Could you build a payload that would let you know that you can execute arbitrary code easier? One thing you may want to do is create a payload that runs whoami or id or any other simple application that prints some small amount of information on the screen.

Remember Keep It Simple Silly! The more complex you make the testing, the more likely there are mistakes which lead to the exploit failing. If you made a mistake and could not get the exploit to work, you may incorrectly assume that the service is not vulnerable.

If the exploit does not seem to be working and it is code pulled from somewhere, see if you can manually complete each step to see where it is failing and why.