Why Exploit Hound?
Your tools find problems. Know which fixes matter next.
Know what to fix first — and verify that the fix reduced exposure. Exploit Hound is an exposure management workflow for MSPs: it takes evidence from discovery, its own checks and the tools you connect, ranks the changes that remove the most exposure for each customer, and rechecks the result.
Where it fits in your stack
Exploit Hound works alongside the tools you run.
| Tool you already run | Evidence it holds | How Exploit Hound uses it |
|---|---|---|
| Vulnerability scanner | Findings on the hosts it scans | Not imported. Exploit Hound runs its own checks; a pilot compares the two exports side by side. |
| RMM | Managed devices and job results | Matches devices to assets and submits named actions from a fixed catalog under an approval mode you set. A job result is recorded, never treated as proof. Beta |
| PSA | Tickets and who owns them | Turns a Fix First action into one ticket, updated rather than duplicated. A closed ticket does not close the finding. Beta |
| EDR | What it sees on protected endpoints | Not connected. A device missing from an EDR console is not reported as unprotected. |
| Active Directory and Entra ID | Accounts, groups and privilege | Read-only connections add identity relationships to the exposure graph. Beta |
| Cloud accounts | Roles, permissions and resources | A read-only role adds cloud privilege and exposure to the same graph. Beta |
Four problems it is built for
Too many findings, no order of work
Approach: Fix First groups findings into the changes a technician can make and ranks them using reachability from the Internet, known exploitation (CISA KEV), asset criticality and modeled attack paths. Each action lists why it ranks where it does.
Benefit: one defensible list per customer. Evidence: Fix First, the demo.
Exposure reduction is shown as an estimate and labelled one.
Each tool sees only its own inventory
Approach: external discovery from a customer’s domains needs nothing installed; the onsite probe covers the internal network; endpoint clients add host detail where you deploy them; directory and cloud connections add identity.
Benefit: assets you did not know about, and stated gaps. Evidence: what we scan.
Discovery sees what it can reach from where it runs, inside the scope you authorize. An area with no collector is reported as unassessed, not clean.
Inference presented as fact
Approach: a route built from the graph is potential; traffic or probing seen on the wire is observed; a non-destructive check that confirmed it is validated. Findings carry detected, high confidence or safely validated.
Benefit: a report a customer can act on without being misinformed. Evidence: terminology.
A modeled route is not evidence that anyone used it.
“Done” that was never checked
Approach: Verify Fix runs a targeted, read-only recheck and records fixed, still present or inconclusive. A finding that simply stops appearing is “potentially remediated” until a recheck confirms it. A regression — a verified fix that came back — is tracked separately from an ordinary reopened finding.
Benefit: fixes you can show a customer. Evidence: remediation verification.
A completed script or a closed ticket is never recorded as proof.
Worked example · demonstration data
One exposure, from discovery to recheck
The customer (Northwind Demo), hosts and addresses are invented; the vulnerability is real. The screenshot is the running console on that data.
- 1Discovery
External discovery finds vpn.example.com (203.0.113.22) answering on HTTPS, and a finding records CVE-2024-21762, a FortiOS SSL VPN flaw, against it. Its evidence level is detected: something indicates the exposure, nothing has confirmed it yet.
- 2Context
The host is reachable from the Internet, marked critical, and the CVE is on CISA’s Known Exploited Vulnerabilities catalog. A modeled route runs from the Internet to the host; it is labelled potential.
- 3Prioritized action
Fix First ranks “Patch CVE-2024-21762 on vpn.example.com” first: one known-exploited finding that is reachable from the Internet, risk score 100 of 100. It also says patching removes none of the modeled routes — they run through the host’s Internet exposure, which is a separate action further down.
- 4Recheck
After the change, Verify Fix re-observes the service. A successful RMM job changes nothing on its own.
- 5Result
If the recheck sees the fixed version, the finding is verified and leaves the open count. If it sees the old one, it stays open as still present. If the appliance cannot be reached, the result is inconclusive and the finding stays open. No outcome is shown here because none was measured on demonstration data.
Across every customer
- Each customer is a separate tenant; a record from one customer is never returned to another, and a cross-tenant request is refused.
- Technicians get actions with their reasons; customers get a report that separates verified fixes from reported ones, white-labelled if you choose.
- One console ranks which customers need attention first.
Discover without growing the bill
Discovered assets are never billed. You pay per customer environment and per asset you deliberately enrol as managed — never per finding.
Plans run from Single environment at $199/month (1 organization, up to 100 managed assets) to MSP Scale at $999/month (up to 30 customer environments, up to 1,500 managed assets). Beyond a plan's allowance, the monthly overage is $0.75 per managed asset and $25 per environment; above 30 environments or 1,500 managed assets it is quoted. Full pricing and the calculator →
A good fit if…
- You manage exposure for several customers and need one order of work.
- You have to justify to a customer why one fix came before another.
- You want fixes rechecked rather than assumed.
- You want discovery to find more without raising the bill.
Understand the boundaries
- It complements your RMM, EDR and scanner; it does not replace them, a SOC or a penetration test, and it exploits nothing.
- Internal visibility needs the onsite probe (outbound HTTPS only); endpoint detail needs a client on the machines you choose.
- Every available PSA, RMM, identity and cloud connection is Beta; the platform is hosted by us, not installed on your servers.
Questions
Why use this with an existing vulnerability scanner?
A scanner lists what is vulnerable. Exploit Hound adds reachability, known exploitation, asset importance and modeled routes, ranks the changes and rechecks them. It runs its own checks rather than importing your scanner’s.
Does it replace my RMM or EDR?
No. It can submit approved actions through your RMM (Beta) and does not read EDR data; protection and patching stay with those tools.
Do I need an onsite probe or endpoint agents?
Not to start: external discovery needs nothing installed. The internal network needs the onsite probe; host detail needs the endpoint client (Beta) where you choose.
Are attack paths modeled or validated?
Modeled. A path is potential unless every hop is backed by stronger evidence, and graph analysis alone never calls anything exploited.
How are fixes verified?
By a targeted, non-destructive recheck that records fixed, still present or inconclusive. Only a recheck marks a finding verified.
Does every discovered asset become billable?
No. Only assets you deliberately enrol as managed are billed, alongside the number of customer environments.
Which integrations are currently in beta?
PSA: HaloPSA, ConnectWise Manage, Datto Autotask, Jira, ServiceNow; RMM: NinjaOne, Datto RMM, N-able N-central, Syncro; identity: Active Directory, Microsoft Entra ID, Microsoft 365, Google Workspace, Single sign-on (OpenID Connect); cloud: Microsoft Azure, Amazon Web Services, Google Cloud; endpoint clients: Linux, Windows, macOS. The integrations page states what each one has and has not been tested against.
Evaluate it on one customer
Pick one customer environment you are authorized to assess. The pilot guide sets out the steps; a guided evaluation runs them with you.