From Banner Grab to Shell: The Exploit-DB + CVE Attack Pipeline

Most scanners stop at the banner. They see Server: nginx/1.24.0 (Ubuntu) in a response header, look up the version in their CVE database, and emit a finding that says "nginx 1.24.0 has 47 known CVEs". The CVSS score is averaged. The KEV flag is present or absent. There is no proof. There is no exploitation. The customer reads it, asks "are any of these actually exploitable on us?", and the scanner has no answer.

Pentestas turns the same detection into the start of a chain. Detect the version, match it against the local NVD database with version-range awareness, join the Exploit-DB index for public PoC code, look up whether we ship a hand-crafted exploit module for any of the matched CVEs, fire it if we do, and — if the exploit lands — pull canonical evidence (/etc/passwd, id, uname -a, /proc/1/cgroup on Linux, whoami + type win.ini on Windows) and bake it into the finding.

The result: where another tool emits 200 LOW-severity "version disclosed" findings, Pentestas emits 4 CRITICAL EXPLOIT_CONFIRMED findings each with a copy-and-paste shell prompt baked into the evidence pane.

Version detection is the foundation. Pentestas combines five signals before it commits to a version string:

• Server / X-Powered-By headers — the obvious signal, parsed into (name, version) pairs (nginx, apache, IIS, lighttpd, openresty, caddy, traefik, varnish, plus the 30+ frameworks that announce themselves in X-Powered-By).
• YAML fingerprint matchers — the WhatWeb-pattern declarative engine matches against URL shape, body regex, header regex, cookie names, and known asset MD5s.
• Asset MD5 oracle — static assets on a target (jQuery 3.6.4's jquery.min.js hashes to a known value, WordPress 6.5's wp-emoji-release.min.js hashes to another) confirm versions even when the operator has stripped the version-disclosing header.
• Login-page + admin-page fingerprints — the WordPress login page, Tomcat manager, Spring Boot Actuator base, JIRA dashboard markup all change between major versions; we match against those when present.
• Generator meta tags + RSS feeds — CMS engines often leak the exact build into the HTML <meta name="generator"> tag or the /feed.xml generator field.

A version is committed only when at least one of these signals returns a 3-component (major.minor.patch) string. A two-component "Apache 2.4" or a brand-only "nginx" is treated as too coarse for CVE matching and produces an INFO disclosure rather than a vulnerability claim.

Pentestas ships its own CVE database built from three feeds and joined daily:

• NVD — every published CVE with affected-product CPE strings, versionStartIncluding / versionEndExcluding ranges, CVSS 3.1 vector + score.
• CISA KEV — the Known Exploited Vulnerabilities catalogue. KEV-flagged CVEs get a severity floor of HIGH regardless of CVSS, because actively-exploited vulns aren't theoretical.
• Exploit-DB — the public PoC index, joined to NVD by CVE id. When an EDB entry exists for a matched CVE we surface the EDB id in the finding evidence.

The matching itself is range-aware. A naive scanner does SELECT * FROM cves WHERE product = ? AND version = ? and misses every CVE whose CPE expresses an open-ended range. Pentestas walks the per-cpeMatch range fields and a candidate CVE matches only when the detected version is at or above versionStartIncluding (or above Excluding) and below the corresponding upper bound. We also fan out to legacy CPE variants (nginx CVEs use both f5:nginx after the F5 acquisition and nginx:nginx for older entries) and merge by CVE id.

When the lookup returns hits, the version-disclosure finding is automatically promoted from INFO to VULNERABLE_SOFTWARE at the worst CVE's severity. KEV-flagged CVEs are called out inline. Exploit-DB ids are listed in the evidence pane.

Pentestas's exploit framework is called Cannon. Each Cannon module is a small Python class that targets exactly one CVE id. It declares a list of affected product strings, exposes a fast non-destructive detect() method (returns true if the target shows the bug's fingerprint) and a controlled exploit() method (attempts to actually pop the box and returns proof on success).

Cannon ships modules for the high-impact CVEs you would expect on an authorised pentest:

• CVE-2021-41773 / 42013 — Apache 2.4.49 / 2.4.50 path traversal + mod_cgi RCE.
• CVE-2021-44228 — Log4Shell, with header-injection-vector fan-out.
• CVE-2022-22965 — Spring4Shell.
• CVE-2023-22515 — Confluence broken-access-control.
• CVE-2023-34362 — MOVEit Transfer SQL injection.
• CVE-2023-3519 — Citrix NetScaler RCE.
• CVE-2023-44487 — HTTP/2 Rapid Reset DoS detector.
• CVE-2023-46805 — Ivanti Connect Secure auth bypass.
• CVE-2024-3400 — PAN-OS GlobalProtect command injection.
• CVE-2024-4577 — PHP-CGI argument-injection RCE on Windows.
• CVE-2024-27198 — JetBrains TeamCity auth bypass.
• Symfony / WordPress — specialist exploit packs.

The dispatcher is targeted: when a matched CVE has a Cannon module, it fires immediately during the version-disclosure path with the matching CVE_ID as the trigger. We do not auto-execute arbitrary Exploit-DB PoCs — those are third-party shell scripts of variable safety, and running them blindly against a customer's environment is the wrong move. EDB ids are surfaced as evidence; only Cannon-shipped modules ever auto-fire.

A Cannon module that lands an RCE primitive doesn't stop at the proof-of-execution. It pulls a small, deterministic set of canonical evidence files and bakes the contents into the finding:

On Linux:

$ id
$ whoami
$ uname -a
$ hostname
$ head -5 /etc/os-release
$ head -10 /etc/passwd
$ ip -4 a 2>/dev/null || ifconfig -a 2>/dev/null

Plus, when a file-read primitive is available:

--- /etc/passwd ---
--- /etc/hostname ---
--- /etc/os-release ---
--- /proc/1/cgroup ---       (container-runtime detection)
--- /proc/self/environ ---   (env vars + secrets)

On Windows:

$ whoami
$ hostname
$ ver
$ ipconfig /all
$ type C:\Windows\win.ini
$ type C:\Windows\System32\drivers\etc\hosts

The evidence panel of the finding shows these as a structured block, with each command output capped at 800 bytes so the report stays readable. Customers reading the PDF on a Monday morning don't have to argue with their IT team about whether the bug is real — the proof is right there.

When Cannon doesn't land a primitive (the version is in the affected range but the customer's configuration mitigates the bug), the finding stays at the CVE-graded severity but is marked as verified: false and the evidence pane explains exactly which step of the exploit chain failed. No false claims of a popped shell.

Active exploitation is dangerous when done blindly. The Cannon design has three safety rails that distinguish it from "run every Metasploit module against the target":

• Targeted dispatch. Cannon modules only fire against CVEs we already matched via version detection. We don't fire Spring4Shell against an Apache+PHP target.
• Hand-crafted only. Every Cannon module is reviewed code that we ship. Exploit-DB PoCs are surfaced as references but never auto-executed — arbitrary third-party shell scripts have arbitrary side-effects, and we don't want them running inside a customer's environment.
• Tier gating. The active-exploitation toggle is a per-scan opt-in. RED-tier modules (the ones that actually demonstrate impact rather than just observe symptoms) are gated behind the Enterprise / Business plan and require explicit ticking of a separate "allow RED-tier" checkbox.

Customers who need the certainty of a popped-shell finding for compliance or for board-level risk reporting turn it on. Customers who need a non-disruptive scan for production-monitoring duty leave it off and get the version-graded finding without the active step. Both flows work; the operator chooses.

Run a scan with active-exploitation enabled and the allow-RED checkbox ticked. When Pentestas detects a vulnerable version that maps to a Cannon module, you'll see a CRITICAL EXPLOIT_CONFIRMED finding with canonical evidence in the same scan. The PDF and SARIF exports both carry the proof block, so the finding survives every downstream tool you push it into.

• The NVD + KEV + Exploit-DB Ingestor: Three Feeds, One CVE Truth
• Exploit-DB Ranking: Every Pentestas Finding Links to the Best Public Exploit
• Attack Chain Synthesis: Why Two Combined Mediums Can Be Your Biggest Risk
• Pentestas for Medtech: HIPAA-Aligned AI Pentesting for HealthTech SaaS