Study guide

9.1 Specialized Discovery Tools

CompTIA PenTest+ PT0-003

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current PT0-003 Exam Facts 1.2 Format, PBQs, Scoring, and Retake Policy 1.3 Recertification, CEUs, and Career Fit

2 Pre-Engagement Planning

2.1 Scope, Rules of Engagement, and Agreements 2.2 Target Selection and Assessment Types 2.3 Shared Responsibility, Legal Authorization, and Ethics

3 Collaboration, Frameworks, and Threat Modeling

3.1 Collaboration, Escalation, and Stakeholder Communication 3.2 Testing Frameworks and Methodologies 3.3 Threat Modeling: STRIDE, DREAD, and OCTAVE

4 Reporting and Remediation

4.1 Penetration Test Report Components 4.2 Findings Analysis and Remediation Recommendations

5 Information Gathering

5.1 Active vs Passive Reconnaissance 5.2 OSINT Sources and Techniques 5.3 DNS, Certificate Transparency, and Search Engine Enumeration 5.4 Network Recon, Protocol Scanning, Sniffing, and Banner Grabbing

6 Enumeration Techniques

6.1 OS Fingerprinting, Service Discovery, and Host Discovery 6.2 DNS, Directory, Share, and Account Enumeration 6.3 Secrets, Permissions, and Wireless Enumeration 6.4 WAF Enumeration, Web Crawling, and Attack Path Mapping

7 Recon Scripting and Tools

7.1 Modifying Bash, Python, and PowerShell for Recon 7.2 Recon and Enumeration Tools

8 Vulnerability Scan Types

8.1 Network, Host, Authenticated, and Wireless Scans 8.2 SAST, DAST, IAST, SCA, IaC, and Mobile Scans 8.3 Container, Secrets, and ICS Vulnerability Assessment 8.4 Core Vulnerability Scanners (Nessus, OpenVAS, Nikto)

9 Scan Analysis and Physical Security

9.1 Specialized Discovery Tools 9.2 Validating Scan, Recon, and Enumeration Results 9.3 Public Exploit Selection and Scripted Validation 9.4 Physical Security Concepts for PenTests

10 Attack Prioritization and Preparation

10.1 Target Prioritization: CVSS, CVE, CWE, and EPSS 10.2 Exploit Selection, Customization, and Attack Documentation

11 Network Attacks

11.1 On-Path, VLAN Hopping, Relay, and Multihomed Hosts 11.2 Default Credentials, Misconfigured Services, Packet Crafting, and Certificate Services

12 Authentication Attacks

12.1 Pass-the-Hash, Pass-the-Ticket, Pass-the-Token, and Kerberos Attacks 12.2 Password Attacks, MFA Fatigue, LDAP Injection, OIDC, and SAML

13 Host-Based Attacks

13.1 Privilege Escalation and Credential Dumping 13.2 Process Injection, Security Bypass, and Host Attack Tools

14 Web Application Attacks

14.1 SQL, Command, XSS, and SSTI Injection 14.2 CSRF, SSRF, Deserialization, IDOR, and Directory Traversal 14.3 LFI/RFI, Web Shells, API Abuse, JWT, and Session Hijacking

15 Cloud Attacks

15.1 IAM Misconfiguration, Metadata Service, and Exposed Storage 15.2 Container Escape, Supply Chain, and Cloud Attack Tools

16 Wireless and Social Engineering

16.1 Wireless Attacks and Tools 16.2 Phishing, Spearphishing, Whaling, Vishing, and Smishing 16.3 Physical Social Engineering and SE Tools

17 Specialized Systems

17.1 Mobile Attacks and AI Prompt/Model Attacks 17.2 OT/ICS, NFC, RFID, and Bluetooth Attacks

18 Attack Scripting and BAS

18.1 PowerShell, Python, and Bash Attack Automation 18.2 Breach and Attack Simulation (Caldera, Infection Monkey, Atomic Red Team)

19 Persistence

19.1 Scheduled Tasks, Services, Accounts, and Shells 19.2 C2, Backdoors, Rootkits, and Security-Control Tampering

20 Lateral Movement

20.1 Pivoting, Relays, and Additional Credential Capture 20.2 Remote Services: SMB, RDP, WinRM, WMI, SSH, and Others 20.3 Lateral Movement Tools and LOLbins

21 Exfiltration and Cleanup

21.1 Staging and Exfiltration 21.2 Cleanup, Restoration, and Artifact Preservation

9.1 Specialized Discovery Tools

Key Takeaways Explain This Topic AI

PT0-003 objective 3.1 names nine discovery tools; after Nessus, OpenVAS, and Nikto, the remaining matching set is TruffleHog, BloodHound, PowerSploit, Grype, Trivy, and Kube-hunter.

BloodHound graphs Active Directory attack paths from users, groups, sessions, and ACLs; it is not a container CVE scanner.

TruffleHog finds secrets in Git history and files, including keys that were deleted from HEAD but still live in old commits.

Grype and Trivy scan container images for package vulnerabilities; Trivy also covers IaC misconfigurations and secrets inside images.

Kube-hunter hunts Kubernetes cluster exposures such as an open dashboard; PowerSploit is listed under 3.1 as PowerShell post-recon, AD, and vulnerability-helper modules, not as a public-exploit launcher.

Last updated: August 2026

On CompTIA PenTest+ PT0-003, objective 3.1 Given a scenario, conduct vulnerability discovery using various techniques lists nine tools. Core scanners — Tenable Nessus, Greenbone/OpenVAS, and Nikto — belong with network and web scan types. This section is the matching drill for the remaining six: TruffleHog , BloodHound , PowerSploit , Grype , Trivy , and Kube-hunter . Exam items rarely ask you to recite a command flag. They show a screenshot, an asset class, or a one-line goal and ask which tool belongs. Pick BloodHound for a container CVE and you missed 3.1 even if you know Active Directory well.

Domain 3 is Vulnerability Discovery and Analysis (17 percent of the exam) . Discovery here means finding weakness evidence, not firing an exploit. These six tools sit next to scan types you already studied — container scans, secrets scanning, authenticated host work, and Kubernetes-adjacent cloud estates. The job on test day is: given the asset class, name the tool.

TruffleHog: secrets in Git and files

TruffleHog is a secrets scanner . It walks Git history, working trees, and other file stores looking for high-entropy strings and known secret patterns: cloud access keys, API tokens, private keys, database passwords, and webhook URLs. CompTIA already named secrets scanning as a 3.1 scan type; TruffleHog is the named tool that implements that idea against source control and files.

Two exam facts matter. First, Git history is in scope even when the current commit looks clean. Developers delete a key from HEAD, but the blob that held it last year is still in the object database unless the repository was rebuilt. Second, modern TruffleHog can verify a candidate with a harmless check against the vendor — does this key still authenticate? — versus leaving it unverified . A verified live key is a finding. An unverified high-entropy string might be a test fixture or a revoked token. Do not treat every entropy hit as a confirmed credential, and do not use a discovered key against production just because discovery succeeded. Using the secret is an attack that must stay inside the rules of engagement (RoE).

Exam trap: answering TruffleHog for “which container image has this CVE.” That is Grype or Trivy. Trap two: treating a Git secrets hit as authorization to pivot into the cloud account the key opens. Inventory the secret. Do not assume the SoW included the cloud account behind it.

BloodHound: Active Directory attack-path graphs

BloodHound is the Active Directory attack-path graph tool. A collector inventories users, groups, computers, logon sessions, access-control lists (ACLs), and group policy objects. BloodHound stores those objects as graph nodes and edges so you can query paths such as “shortest path to Domain Admin from this help-desk user,” not a CVE list.

Typical edges include group membership, local administrator rights, who is logged on where, GenericAll , ForceChangePassword , and constrained delegation. A path that reads “helpdesk → GenericAll on Jump-Admins → AdminTo on DC01” is a discovery result: the directory already grants that chain. BloodHound did not exploit Kerberos and did not dump hashes. On 3.1, that graph is the answer when the stem shows a Windows domain and asks how testers mapped privilege relationships.

Collection itself is an active directory query against in-scope domain controllers and workstations. If the SoW named only a DMZ web farm, do not run a forest-wide collector because BloodHound is on the tool list. Exam trap: BloodHound is not a container scanner, not a Kubernetes hunter, and not “the exploit for Kerberos.” Ticket attacks live in Domain 4. Here you only need: AD relationships → BloodHound.

PowerSploit: PowerShell post-recon helper on a discovery objective

PowerSploit is a PowerShell module collection that testers load for post-recon, Active Directory, and vulnerability-helper tasks: enumerating domain objects, checking local privilege-escalation conditions, and gathering host facts after you already have a PowerShell foothold. CompTIA listed it under 3.1 discovery tools , not under Domain 4 attack tools. That placement is deliberate and is an exam trap if you only remember PowerSploit from offensive blog posts.

On this objective, PowerSploit is the answer when the stem is “which PowerShell framework helps inventory AD or host weaknesses after recon.” It is not the answer when the stem is “which public exploit or Metasploit module matches this CVE.” Some PowerSploit folders historically included execution and persistence helpers. For PT0-003 3.1, stay on the discovery side: recon modules, privilege-check scripts, and inventory. Do not paste exploit payloads into a report, and do not run destructive helper functions because a third-party write-up mentioned them. If the RoE forbids post-exploitation tooling on a host, PowerSploit stays on the shelf even though 3.1 named it.

Grype and Trivy: container and image vulnerabilities

Grype (Anchore) scans container images, filesystems, and software bills of materials (SBOMs) and matches installed packages to known CVEs. Trivy (Aqua Security) also scans images and filesystems for vulnerabilities, and it additionally covers misconfigurations , Infrastructure as Code (IaC) files, and embedded secrets . On the exam, both are correct for “which tool finds CVEs in this image.” Prefer Trivy when the stem adds Kubernetes YAML, Terraform, or a secret baked into the image. Prefer Grype when the stem is a straight package-to-CVE match or an SBOM file.

These tools are not BloodHound, not TruffleHog-for-git-history (Trivy can find secrets in an image, but git-history secrets are TruffleHog’s home turf), and not a substitute for hunting a live cluster. Scanning the tar of payments-api:1.4 does not prove the Kubernetes API server is locked down.

Kube-hunter: Kubernetes cluster attack surface

Kube-hunter hunts Kubernetes exposures: anonymous API access, an open dashboard, kubelet read-only ports, etcd without authentication, and similar control-plane mistakes. You can run it remotely from the tester’s network, internally from a pod, or against a network range. An “open dashboard” finding is still only a scanner hypothesis until you validate it — the next section’s true-positive example starts here.

Do not point Kube-hunter at a cluster that is out of scope. Kubernetes control planes often sit on a different CIDR than the web front ends named in the statement of work (SoW). Exam trap: kube-bench is a CIS benchmark configuration auditor and is not on the 3.1 tool list. If the stem wants the 3.1 Kubernetes hunter, the name is Kube-hunter.

  • Tool What it matches Typical evidence Not the answer for
  • TruffleHog Secrets in Git history and files Verified cloud key in an old commit Image CVE lists
  • BloodHound AD attack-path graphs Help-desk user → GenericAll → DC local admin Container package CVEs

PowerSploit PowerShell post-recon / AD / vuln helper modules Domain inventory from a PowerShell session Picking a public CVE exploit

Grype Container, image, and SBOM package vulnerabilities CVE on a library in app:1.4 AD session graphs

Trivy Image and filesystem vulns plus IaC misconfig and secrets CVE plus Terraform open security group BloodHound pathing

  • Kube-hunter Kubernetes cluster attack surface Open dashboard or anonymous API Git history tokens
  • Worked matching

A client hands you three artifacts: a Git remote for payments-api , a Windows domain, and a registry image payments-api:1.4 that also runs in Kubernetes. TruffleHog on the repository history is secrets discovery. BloodHound, with authorized collection, is AD path discovery. Grype or Trivy on payments-api:1.4 is image CVE discovery; Trivy also reads the deployment YAML. Kube-hunter is for the live cluster, not the image tar. PowerSploit is what you reach for after a Windows foothold when 3.1 wants PowerShell-assisted inventory. Six tools, six asset classes — that is the 3.1 remainder.

Loading diagram... Match the 3.1 specialized tool to the asset class