What a Real Pentest Is (and Why an Automated Scanner Isn't Enough) — NyxqLab

We hear this sentence too often in first meetings with clients: "we already had a pentest done last year, they gave us a 40-page report with 180 findings." When we ask to see that report, in most cases we find the raw output of an automated scanner (Nessus, OpenVAS, or similar) with the consultancy's logo pasted on top of the PDF.

That's not a pentest. It's a vulnerability scan. And the difference matters far more than it seems.

The difference between scanning and exploiting

A vulnerability scanner compares the software versions it detects against public CVE databases and tells you: "this Apache version has 14 known vulnerabilities." That's useful information, but it's only the first step — and it's automatable in minutes.

What a scanner doesn't do:

• Verify whether that vulnerability is actually exploitable in your specific configuration (often it isn't, due to mitigations the scanner can't see).
• Chain several "medium" severity vulnerabilities together to achieve critical impact (which is, in fact, how most real breaches happen).
• Find business logic flaws — for example, that you can view another customer's order by changing a number in the URL, something no signature-based scanner detects because it isn't a "known vulnerability," it's a design flaw specific to your application.
• Prioritize based on real impact to your business, rather than a generic CVSS score that has no idea what data your system handles.

A real pentest does all of this. A consultant — or a team — actively tries to get in, move laterally, and demonstrate the real impact of each finding with a reproducible proof of concept.

What a real pentest looks like, step by step

Phase 1 — Reconnaissance. Mapping the real attack surface: subdomains, exposed services, technologies in use, employees and their public footprint if social engineering is in scope. This isn't "run nmap" — it's understanding how the target actually works.

Phase 2 — Vulnerability analysis. This is where automated tools do come in, but as a starting point, not the final deliverable. What the tools report gets cross-checked against the pentester's knowledge of the specific technology.

Phase 3 — Exploitation. The step that makes the real difference. Each candidate vulnerability is actively exploited in a controlled manner, documenting the exact steps, so the finding has a reproducible proof of concept — not "we believe this could be exploitable," but "this is exactly what we did and this is what we got."

Phase 4 — Post-exploitation and lateral movement. If initial access is achieved, what can be reached from there? This phase reveals the real impact: "low-risk" access to a log server can be the door to credentials that grant access to the customer database.

Phase 5 — Report. Not a list of findings sorted alphabetically. A report that clearly separates critical from cosmetic, prioritizes by real business impact (not automated scoring), and gives concrete technical recommendations, not generic ones ("keep your software updated" isn't useful advice without more context).

Why this matters for your security budget

If your only starting data point is "we have 180 vulnerabilities," rational prioritization is impossible. Which of those 180 are actually exploitable in your context? Which ones, if exploited, grant access to something valuable? Which are noise — technically real vulnerabilities with no practical path to exploitation?

A real pentest gives you that prioritization. In most of our reports, out of dozens of initial automated findings, the number of truly critical vulnerabilities — the ones that genuinely deserve urgent budget — is usually a handful, not hundreds. That doesn't mean the rest never matters; it means you now know in what order to tackle it.

Legal framework: why authorization isn't a formality

In most jurisdictions, unauthorized access to computer systems is a criminal offense, even without intent to cause harm. This means that, technically, attempting to exploit a vulnerability in a system — even "to help," even against your own company if you don't have proper internal authorization — can constitute a crime.

That's why at NyxqLab we always work under:

• A written, defined scope: which systems, which techniques are allowed and which aren't (for example, whether denial-of-service testing is permitted), and what time window.
• Signed authorization from someone with the legal capacity to grant it.
• An emergency contact during the test, in case something unexpected happens (a production system goes down, for example, even though avoiding that is the goal).
• Clear rules of engagement: what to do if, during the test, evidence of a real prior compromise is found, not a simulated one — this happens more often than people think, and requires a different protocol than a normal finding.

How to tell if what you're being offered is a real pentest

A few questions you can ask any provider before hiring, which quickly separate the serious from the not-so-serious:

• Does the price depend on the number of IPs to scan, or on estimated human work time? (If it's the former, be suspicious: that's scan pricing, not pentest pricing.)
• Can you see an example of a previous report (anonymized) before hiring?
• Will you get reproducible proofs of concept, or just descriptions of "possible" vulnerabilities?
• Who signs the report, and what demonstrable experience does that person or team have?
• Does it include a re-test phase after you fix the findings, to verify the fix actually worked?

A real pentest isn't cheap or fast, because it involves qualified human work, not just machine time. But it's the only way to know, with real evidence rather than a generic list, where your actual exposure lies.