9.1 Specialized Discovery Tools

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.

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.