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 ?

10
  • 2
    It's a choice between "They are too good, I give up" and "I need to learn more and retry."
    – ThoriumBR
    Commented Jul 12, 2020 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
    Commented Jul 12, 2020 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. Commented Jul 12, 2020 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. Commented Jul 12, 2020 at 22:43
  • 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. Commented Jul 13, 2020 at 3:13

1 Answer 1

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.

0

You must log in to answer this question.

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