I am currently enrolled in Offensive Security's "Penetration Testing with Kali" course, which is aimed at newcomers to penetration testing. The course is great, with many examples/exercises, and a great virtual lab environment which allows me to connect via VPN and practice everything we've been learning.

One thing which I have noticed is that many of the vulnerabities we've been studying/practicing have been on older e.g. Windows XP/2003 systems, older Linux versions, or have been relying on misconfigured systems (which, if configured correctly, would be much more secure) or protocols which are known to have serious flaws in them.

I'm well aware that newer versions of these systems have vulnerabilities of their own. I am also guessing that many of the older systems still persist in usage within organizations anyway. However the weight of the study material which is placed on older systems makes me wonder if in the future, penetration testing will necessarily either become less useful or need to shift in its methods as developers become more security conscious in authoring their protocols/apps/OSs, and as their tools become more advanced. E.g., many higher-level languages manage memory for developers, making buffer-overflows much less likely, even for careless developers. Also, it is my perception (though I could very much be wrong, I'm no expert) that modern operating systems are significantly more secure than their predecessors.

I know that ANY system will have SOME flaws somewhere, however it seems that penetration testing as a professional level involves by definition some degree of standardized scanning/exploitation of known vulnerabilities. My question then is, is the surface area which professional penetration testers shrinking, as security-awareness increases among developers of apps/protocols/OSs, and as the built-in security of their tools improve?

I'm not implying that I think penetration testing would ever "go away", but e.g. it might start to rely more on social engineering than actualy technical vulnerabilities in the networks or software.

  • Built-in security is not always the case even with the latest versions, look into LLMNR poising on a Windows domain. I am not sure if OSCP covers internal penetration testing though. May 1, 2017 at 19:57
  • @whatever489: I'm not meaning to imply "everything is secure in latest versions", just suggesting a general trend towards improved security. Is that trend not actually a thing? (honest question)
    – loneboat
    May 1, 2017 at 19:59
  • Since when did security awareness increase among developers ? Do you have any source for that statement ?
    – niilzon
    May 5, 2017 at 7:06

3 Answers 3


The objective of penetration testing is not to find vulnerabilities, and so it hasn't failed if it doesn't find any. It's to check whether or not vulnerabilities are present. It doesn't get harder if systems get more secure, it just comes up with fewer vulnerabilities. In fact, it will get easier if the list of known vulnerabilities to check gets smaller.

  • I'm not sure I follow the distinction - how is "finding vulnerabilities" different from "checking whether or not vulnerabilities are present"? (not arguing, I just think it went over my head)
    – loneboat
    May 1, 2017 at 20:12
  • No, penetration testing is all about displaying impact of vulnerabilities, saying "you have an SQL injection" or "you are running windows XP" is not a penetration test. You need to show the client what you can do with these vulnerabilities. May 1, 2017 at 20:13
  • 4
    @loneboat If the objective of the test is to find vulnerabilities, then a test that doesn't find any is a failure, and it gets harder to do a successful test as systems get more secure. But if it's to check whether or not there are vulnerabilities, then a test that doesn't find any is still a success (assuming that there are in fact no vulnerabilities).
    – Mike Scott
    May 1, 2017 at 20:15
  • @MikeScott is exactly correct. No one would tell a pentester that they failed their job if they came up with a clean report (unless, of course, they were just a bad pentester and missed obvious issues).
    – forest
    May 20, 2018 at 0:08

The vulnerability and IT landscape are constantly changing and I'd say that while some types of issues are getting less prevalant, others take their place as more common, whilst some issues are forever (it seems)

Things like the classic network exploitable issues in widely deployed Operating Systems (e.g. MS08-067) are less common (although the Shadowbrokers dumps showed that they're still a possibility), and where they exist they tend to be harder to exploit as OS makers add more defences to their systesm (e.g. ASLR/DEP etc)

However I don't think that this necessarily means that there won't be issues for testers to find. Some things, like authorisation issues in web applications, are very hard to fix generically across all platforms and rely on individual developers, so they're a possiblity in any application you test.

Also things that rely on large numbers of people getting security right, like good password choices, seem to persist pretty much forever.

Alongside those, new avenues open up for testers to look at. For example, compared to 15 years ago, far more of companies systems are hosted "in the cloud" which can expose them to attack more easily than if they were in an internal enterprise network behind several layers of defensive systems, so there's new ways that testers can look to exploit that.

Testers definitely need to adapt to new systems coming along and old systems going out of fashion, but I don't see that they'll run out of things to find anytime soon.


In my opinion no... I regularly find SQL injections because developers are building their custom applications in PHP instead of using frameworks. The same is true for APIs (especially those for mobile applications in my experience). As for external infrastructure, I would say finding known vulnerabilities (with metasploit modules) is rare, the reason being they would already have been compromised. Probing normally leads to results however, for example I have found printers exposed on the internet with default credentials which allowed for pivoting into the internal network. As for internal infrastructure there are always weaknesses, but using tools like Responder (for LLMNR poisoning) will get you DA like 80% of the time depending on password policies, so you are basically probing other places while Responder is running just in case it doesn't get you a NTLM hash which you can use to escalate to DA.

You must log in to answer this question.

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