0

A typicall pentesting activity has the following step :

   1 - information gathering + enumeration
   2 - vulnerability assessment (vulnerability scanning)
   3 - exploitation
   4 - post exploitation (persistence, clearing tracks, etc...)
   5 - report writing

Step 1 to 4 can be a cycle after getting a foothold.

But what do you do if you don't get that foothold. That is, on the iteration, Step 2 (Vulnerability scanning) does not return any vulnerable service nor configuration. If social engineering is not part of the deal, does it mean it's pretty much game over ?

steve312
  • 1
  • 2
    It's a choice between "They are too good, I give up" and "I need to learn more and retry." – ThoriumBR Jul 12 '20 at 22:01
  • @ThoriumBR Haha I know right !!?? You definitely got my point. The thing is I have topnotch scanners (Nexpose and Qualys) enterprise edition. But the still don't pick up anything. What is left to learn when these guys don't find a loophole ? lol – steve312 Jul 12 '20 at 22:12
  • 2
    While it's nice to have good scanners, it's better to have knowledgeable pen testers. Instead of, "Pushed the button and found nothing," you should get a report delineating what was tested and what was encountered both good and bad. Magic Box testing should only be a small part. – user10216038 Jul 12 '20 at 22:30
  • 6
    I fear that too many "security assessments" consist of someone running an expensive scanner and nothing more. Scanners can be helpful for enumeration and finding the low hanging fruit, but will miss anything past that. – multithr3at3d Jul 12 '20 at 22:43
  • @multithr3at3d Ok. I'm at that point in my pentesting evolution where I'm asking myself how to find anythings beside low hanging fruits. If it requires researching, then I guess it's out of my league since I'm only a pentester. Hence my question to you : what vulnerabilites would you categorize as not being low hanging fruits ? – steve312 Jul 13 '20 at 00:27
  • @user10216038 Thank you. Don't forget that sometimes, client don't understand why what was tested was exploited to full compromise. So if the vulnerability scanner did not find something juicy, just telling the client SMBv1 is activated is not always appreciated on the client side – steve312 Jul 13 '20 at 00:41
  • 1
    @steve312 not sure what you mean by "only a pentester". I don't think that the title implies limited skills at all. Well, what are the low hanging fruits? Known vulnerable software versions, known vulnerable configurations, very obvious software bugs, etc. So that leaves out almost all vulnerabilities in custom applications, business logic flaws, improper access controls/user privileges, broken crypto implementations, etc. Or perhaps the scanner can't even get to applications that require authentication. – multithr3at3d Jul 13 '20 at 03:13
  • Now that you've used **automated tools** for a cursory check, it's time to perform **manual** testing for a more in-depth probe of the target. I would probably use nmap for example. Scapy perhaps, to interpret the results myself. False positive or negatives are common with automated tools. And they [do not work the same](https://security.stackexchange.com/a/226580/125626) and can return different results for the same target. A good pentest is not a box-ticking exercise. Someone who only uses automated tools is not a pentester but more like an auditor imho. Or a script kiddie but I hope not. – Kate Jul 13 '20 at 19:25
  • you need to analyse source code manually / analyse banaries for vulnerabilities (if you don't have sources but allowed to decompile / attack them) – Awaaaaarghhh Jul 14 '20 at 03:25
  • @Anonymous Good. Thank you stating the nuance pentester vs auditor. When you say manual testing, does it mean for instance going through all items of OWASP OTGv4 one by one when applicable ? – steve312 Jul 14 '20 at 06:24

1 Answers1

4

I think your list of steps is flawed. It looks more like this (source):

  • Planning & Preparation
  • Reconnaissance
  • Discovery
  • Analyzing information and risks
  • Active intrusion attempts
  • Final analysis
  • Report preparation

Performing a scan on an application is not a penetration test. It is just that, a vulnerability scan. It's very unlikely that you don't see any vulnerabilities. Usually you make a pentest for a reason. There are endless potential attack vectors that a scanner cannot detect. The first thing that comes to my mind are business logic flaws. Also scanners (without complicated manual setup) are not very good at detecting authentication flaws like IDOR. Something a good human pentester will find after the first few minutes of their assessment.

A simple example is the integration of payment providers. I've often seen flaws in the implementation where you could just re-send a specific request in the payment-process, to order the same item over and over again without paying for it. Or you could modify the payment amount. I've even seen webshops where you could recharge gift cards by manually setting the item price to a negative amount. How should a scanner test for that, when it involves third-party components?

Nothing can replace a human pentester.

So the concrete answer to your question is: you analyze all requests and business logic manually, if you couldn't find anything during your automated vulnerability assessment.

Martin Fürholz
  • 795
  • 9
  • 21