The platform
One correlated model of your exposure.
Exploit Hound collects from the outside in and the inside out, stores what it finds as an evidence-backed graph, and reasons over that graph to answer the only question that matters on a Monday morning: what do we fix first?
Architecture
Cloud management. Local visibility.
Exploit Hound is a hosted platform. The collection happens inside your customers’ networks, on the machines and segments where the assets actually live, and reports out to the platform over a connection the customer’s side opens.
Attack surface
Discovery from both directions
External
Domains, subdomains, public addresses, exposed ports and services, TLS posture and certificate state. Everything discovered is recorded with when it was first and last seen, so new exposure is obvious.
Internal
Network Sentry discovers devices on the LAN, tracks them by MAC and address over time, and flags devices that are not authorized. Endpoint agents report operating system, installed software and services.
Vulnerability management
Prioritization you can explain to a customer
Findings carry an Exploit Hound Risk Score from 0 to 100 built from named factors — never a single opaque number.
Exploitability
CVSS, EPSS probability, CISA Known Exploited Vulnerabilities and public exploit availability.
Reachability
Whether the affected service is reachable from the Internet, and whether it sits on a route toward something valuable.
Business context
Asset criticality and role, observed threat activity, finding age, reopen history and any compensating control you have recorded.
Scores are versioned. When the methodology changes, older scores remain interpretable because the factors that produced them are stored alongside the number.
Configuration assessment
Beyond CVEs
A great deal of real exposure is configuration, not a missing patch. Exploit Hound derives configuration findings from evidence it has already collected.
- Plaintext administrative protocols
- Internet-reachable database ports
- Internet-reachable administrative interfaces
- File sharing exposed to the Internet
- SNMP exposure
- Deprecated TLS versions
- Weak TLS cipher suites
- Certificate problems
Findings are mapped to CIS Control, NIST CSF and MITRE ATT&CK identifiers, with remediation guidance written for this product. No proprietary benchmark text is redistributed.
Attack paths
How the pieces connect
Attack path analysis walks the exposure graph from entry points — the Internet, an untrusted network, a workstation assumed to be under attacker control — toward the systems worth protecting.
Evidence per hop
Each hop states why it exists, what evidence supports it, its confidence, the finding behind it and the recommended remediation.
Honest labels
Potential High confidence Safely validated
A path is never described as exploited or as evidence of compromise.
Choke points
The systems that the largest number of distinct routes pass through — usually where a single change buys the most.
Threat detection
Signals, not just inventory
Network telemetry
NetFlow collection with DNS, TLS and ASN enrichment, baselines and service drift alerting.
Deception
Deployable honeypots that record interactions with services nobody legitimate should be touching.
Threat intelligence
Indicator matching against observed traffic and DNS, correlated back to the internal host involved.
These signals feed prioritization directly: an exposure on an asset with recent suspicious activity scores higher than the same exposure on a quiet one.
Identity exposure
Identity is part of your attack surface
Attackers don't stop at software vulnerabilities. Exploit Hound reads Active Directory and Microsoft Entra ID, and puts both in the same exposure graph as your network and assets — so the dangerous combinations become visible, including the ones that cross between on-premises and cloud.
Read-only, and explicitly authorized
The assessment reads attributes any authenticated domain user can already see. It never cracks or sprays passwords, never reads password hashes, never requests Kerberos tickets for offline cracking, and never writes to the directory. It stays disabled until a named person authorizes it with a written reason, and that record is kept.
What it looks for
Unconstrained and dangerous delegation, privileged accounts exposed to Kerberoasting, accounts with pre-authentication disabled, dormant privileged accounts, reversible password storage, nested privilege, weak password policy, stale krbtgt, LDAP and SMB signing posture, LLMNR and NBT-NS exposure, and certificate templates that let a requester choose their own identity.
Identity findings are not a separate report. They join the same exposure graph as everything else, so a server trusted for unconstrained delegation shows up as what it actually is: a route toward a domain controller.
Microsoft Entra ID and Microsoft 365
Cloud identity, in the same graph as everything else
An isolated cloud scanner can tell you a Global Administrator has no MFA. This can tell you that an internet-facing server leads to an on-premises account synchronised to that administrator — a different sentence, and a different priority.
Privileged identities
Accounts holding directory roles, how many Global Administrators the tenant has, privileged accounts that have not signed in, and guest accounts — external identities from another organisation’s directory — holding roles here.
Authentication posture
Which privileged accounts have registered strong authentication and which have not. Usually the single most valuable finding the integration produces, and the one that maps directly to a CMMC and NIST requirement.
Conditional Access
Policies that exist but enforce nothing because they sit in report-only mode, and policies whose exclusion lists have grown one exception at a time until they protect few of the people they name.
Applications and service principals
Enterprise applications holding directory-wide write permission — administrative control without appearing in any role assignment, which is why it is a favoured persistence route — and applications owned by another tenant holding privilege in yours.
Hybrid identity paths
A synchronised account is joined to its on-premises counterpart in the graph, so “compromised server leads to domain account leads to tenant administration” is a path you can see rather than infer. The on-premises node is matched, never invented: an ambiguous match draws no edge at all.
Read-only consent
Every Graph permission requested is a read permission — not one write. The exact list, what each is used for and what goes unassessed without it are shown before you grant anything. Where a permission was not granted or a licence is absent, that area is reported as unassessed rather than clean.
Ticket and remediate
The work lands where your technicians already are
A security console a technician has to visit separately costs the hours an MSP is selling. So a Fix First recommendation becomes a ticket in your PSA, and approved remediation runs through your RMM.
PSA ticketing
HaloPSA, ConnectWise Manage, Datto Autotask, Jira and ServiceNow. One recommendation becomes one ticket; re-running it updates that ticket rather than opening a second. Credentials are encrypted and never returned by any endpoint.
RMM remediation Beta
Approved actions execute through NinjaOne, Datto RMM, Syncro or N-able N-central. Exploit Hound is not an RMM and does not patch anything itself — it submits named actions from a fixed catalogue, never a script of its own, because an RMM runs as SYSTEM on every endpoint it manages.
Devices are matched on serial, MAC or fully qualified name; a weaker match needs a person to confirm it, and two devices matching equally well stops the workflow rather than picking one. You choose how much runs without approval, and the default is nothing.
ConnectWise RMM is not implemented, and is blocked on documentation rather than effort: its public developer portal covers authentication and little else, and we will not write an integration against guessed endpoints when those endpoints are the ones that cause code to run on your machines.
Datto works a little differently and it is worth knowing before you connect it. Datto runs components — reviewed script objects that live in your own Datto instance — rather than exposing “apply patches” as an API call, and Datto’s documentation is explicit that a component’s identifier cannot be read from the API. So you map each approved action to a component you have reviewed, and Exploit Hound sends that identifier and structured parameters. It still never sends script text, and an action you have not mapped is refused rather than quietly run through a near neighbour.
Alerting
One event pipeline, not an integration per feature
Critical exposures, known exploited vulnerabilities, new attack paths to critical systems, reopened findings, verified fixes and overdue remediation all flow through one pipeline to email Beta, Slack and Microsoft Teams Beta, Pushover Beta or a webhook Beta.
The pipeline itself is ours and runs; every destination it can send to is Beta, because none of them has yet delivered a message to a real mailbox, workspace, device or endpoint. The integrations page carries the status of each one.
Repeats of the same condition are folded into one event with a count rather than a hundred alerts, and a destination is not notified again about something it already acknowledged. Events are recorded even when nothing is sent, so “we knew and chose not to page” stays auditable.
AI Security Analyst
Ask questions about a customer’s exposure
What should I fix first? What changed this week? What is the shortest potential route from the Internet to a critical system? Answers are grounded in that customer’s own data.
Every finding, asset and attack path the answer cites is checked against the records it was actually given — anything else is flagged rather than presented as fact. With no data, it says so instead of producing something plausible. You can see the exact evidence it was handed.
Remediation & verification
Fix First, then prove the fix
Fix First
Findings are grouped into the actions a person actually performs, and each action reports the attack paths it removes, the critical systems it protects, the known exploited vulnerabilities it clears and the findings it closes at once. Path counts are exact over the current graph; percentages are labeled as estimates.
Verify Fix
Request a targeted, non-destructive recheck of one finding. Exploit Hound selects the narrowest safe check for that finding type, runs it against the finding's own authorized asset, records the evidence, and only then moves the finding to verified.
Verification checks are read-only by design: a TCP connect test, a TLS handshake inspection, a response-header read or a banner read. Verify Fix cannot be pointed at a target of your choosing — the target is derived from the finding's own authorized asset record.
Business context
Not every asset is worth the same
A critical vulnerability on a spare laptop and the same vulnerability on the domain controller are not the same problem. Criticality feeds risk scoring, which systems attack path analysis treats as worth reaching, Fix First ranking and what the report says.
Exploit Hound can suggest a role and criticality from what it has observed — a machine answering as a domain controller, a database listening on its standard port, a host that many others depend on. Suggestions are proposals, not silent edits: you confirm them, and an explicit setting is never overwritten by inference.
Change detection
What changed since last week
Added, removed, worsened, improved — over whatever window you pick. New exposure is the thing worth a person’s attention; a finding that has been open and unchanged for a month is not news.
There is no separate capture pipeline behind this. It reads the first-seen, last-seen and active bookkeeping the exposure graph, findings and attack paths already maintain, which means it cannot disagree with the rest of the platform about what is true.
Security regressions GA
A fix that came back
A vulnerability this platform verified as fixed, found open again on the same asset. That is a different event from a finding that was never fixed, and it is the one that says a process is leaking rather than a job is outstanding.
Where a cause can be named it is named, and the bar for naming one is deliberately high: a record is a confirmed cause only when it names the finding. A change that happened to land in the same window is a lead, never a cause — timing is not evidence, and a regression report that guesses at causes is worse than one that says it does not know.
Exceptions and risk decisions Beta
Accepted, for a reason, until a date
Some exposure is not going to be fixed this quarter, and pretending otherwise makes a list nobody trusts. An exception records what was accepted, who accepted it, why, and when it lapses.
Expiry is not removal. When an exception lapses there are three answers, not two: the finding is gone, the finding is back, or nobody can currently tell — and the third is the one a two-state design reports wrongly. An exception whose evidence has gone stale returns “verification needed” rather than quietly reopening or quietly staying shut.
Accepted risk is re-scored on a schedule, and a re-score is not a change: the scoring model version is recorded in each snapshot, so a number that moved because the model moved can be told apart from one that moved because the exposure did.
False positives
Does this finding actually apply?
A version banner is not proof. Before a finding consumes anyone’s time, Exploit Hound checks whether the vulnerability genuinely applies to that target — the right product, the affected version range, the configuration that makes it reachable.
This matters more for MSPs than for anyone else. You are reporting to customers who did not choose the tool, and a queue padded with findings that do not apply costs you credibility long before it costs you time.
Start with what's actually exposed.
Point Exploit Hound at the assets you are authorized to assess and see the connected picture, ranked by what removes the most exposure.