I am planning to engage a vendor to do pen test on my external systems. I know that pen test has a set of systematic steps .. just would like to gather some industry experience. Normally, at which stage of the pen test would you most likely stop, to give you enough justification that your system is indeed vulnerable. In my technical requirement specs I could just state, "if manage to breach, touch a file, make it hidden etc" and stop. OR i could jolly well say, "proof to us you can get root and then stop the pentest".

What are some of your own experiences in this? thanks

  • It's game over if they get root access. What is useful to know is in how many ways can they get it? Also, you might want to test some apps for things la xss and other well known vulnerabilities. It's good if they found a big security flaw and stopped. Is bad if there are other big ones they didn't have the time to look for.
    – sir_k
    Dec 17, 2014 at 10:28

4 Answers 4


You are not really going to get good results, such an approach is really appropriate for a pentest but more for a Red Team/Tiger Team test where flags are set (honestly these are not appropriate if you never had a pentest because you'll get very demotivated and spend a large amount of your budget as it's quite time consuming). For a pentest you preferably you define or let them define different scenarios which need to be tested from the perspective of different types of users:

  • authenticated (can be different types of privilege)
  • unauthenticated

You limit the systems in scope and descope DoS testing especially as this is your first set of pentests. You request an overview of all discovered vulnerabilities categorized and sorted based on their impact, likelihood and overall risk rating.

A system is not considered vulnerable just because you can get root, a system is vulnerable to vulnerabilities each with their own risk rating. Also note that one system which has a low vulnerability risk rating may, because of the gathered information, assist in compromising another system.

You normally define a time frame, depending on the size of your network or website, in which they should work. Normally you can discuss the scope and your different parties will tell you what they see fit for the scope. Note that because you perform a network pentest, it does not nescesarily mean that all your websites are in scope as well.

You also preferably provide information about your network, it's a pentest, it means it's limited in budget and time. Real attackers have got more time and are often not financially bound. Therefore to get the best results perform gray or white box testing where you give information to the testers such as network ranges and functions of different servers.

Ensure you also limit the exploitation of production servers. You should ensure no production servers are exploited without your prior permission. This is to ensure that these do not crash during business hours.

My personal preference for the report is as follows:

  • Scope
  • Management Summary
  • Technical Summary
  • Attack Scenarios ( appropriate if different vulnerabilities lead to compromising a host)
  • Findings categorized per vulnerability with a list of vulnerable hosts detailing a description of the vulnerability, the risk, the recommendation and references. Findings should be made in such way that even someone with limited pentest knowledge can reproduce the finding. Ample evidence should be given, such as example screenshots, requests, responses,...
  • So in your description you would say a full pen test is actually a vulnerability assessment followed by a pen test, i.e. both of what is described here? Dec 19, 2014 at 10:54
  • I guess that's semantics. I would say a vulnerability assessment assists when doing a pentest. Scenarios and goals may be defined for a pentest though. Dec 19, 2014 at 10:57
  • Semantics - definitely. Thanks for your opinion. We are currently deciding the language to use for our own services so this helps. Dec 19, 2014 at 11:07

The "scope" generally does not state something like "You can't root the machines", as a client you want to know if this is possible IMHO. Once root access is acquired it's basically game over anyway.

What the scope should say is the amount of servers and its server names / IP's and that it the assessment is restricted to these devices only. This to prevent that once a machine is compromised, the security consultants start to work their way in to the rest of the network.

Let's asume that there is a buffer overflow in a daemon or an application. Would you want them to spend time on exploiting this buffer overflow or find more vulnerabilities?

Generally, as a security consultant, I explain the situation to the client that given enough time the buffer overflow could most likely be exploited. I will ask if they want us to continue on exploiting this or spend time in to looking at other parts of the system.

Also, we report high and critical vulnerabilities immediately and have a daily evaluation on the findings.

Talk to the consultant(s) on a daily basis, communication is key here (something the consultant(s) should do towards their clients anyway IMHO).


As a penetration tester, this wording is put forth in the Statement of Work however, as a tester, I don't recommend that you have the tester just stop the test once access is gained. The purpose of a penetration test is to gain access much similar to how an attacker would gain access. By stopping the test, you could never know what else is exploitable. Let's look at the following:



Let's state the the tester begins at and gains access at, the tester comes across a highly exploitable machine, gains full control, and you stop the test. What have you benefited from if there were 244 machines left untested?

One of the biggest hurdles we (testers) face, is that we are at times limited in what we can test, and how we can test. Generally, I aim to use reliable exploits which don't affect a client's network (crash services, cause denials of service). Many times techniques a bonafide attacker would use are of the table for me. E.g., chaining exploits, where I can find a low level cross site script (XSS) but the only way for me to exploit it, would be to add a social engineering vector (emailing your employee a link).

There are pros and cons with performing pentests, and the standard: "Aim a tool at this network block, if you can't get in, we are safe" never works. This is because the testing is a loaded gun. As a professional tester, I know I can't do something to disrupt your operations, so I will not chance it. A bonafide attacker is never going to state: "well if I run this exploit, I might crash his system... Better not," or "well this is only an XSS attack... I better not use this in a crafted email," or "I found the first exploitable machine... I should stop exploiting the rest of the network." On the contrary, an attacker will run whatever exploit they want, they won't care if they crash anything, and they will chain exploits.

I prefer performing internal blackbox (anything goes) testing from the inside. With and without credentials versus remote testing. This is simple logic: "Let's assume they made it in the front door... What can they do." This enables me to have the client determine his security posture from the inside out, where external testing is performed AFTERWARDS. I found this approach yields much better results than firing off at an external IP.

Further, depending on your structure, I have run across too many third party hosting providers. This is where the client's web facing infrastructure is say on Amazon, or some other hosting provider, to which we cannot test, as cloud provider shun penetration tests. So you're likely going to get a skewed report.

My advice is, if you're going to let someone test, it should be all or nothing. Most competent testers are aware of the pitfalls I mentioned here. Most should already know: "thou shall never use exploits that will crash something" so they will be responsible. However, I would not stop testing, and you would get more bang for your buck performing internal testing first (blind, and with credentials) followed by external testing.


PenTests have a "scope" associated with them that you as the customer define. You define how far you want them to go and what the success criteria are.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .