Product tour

See the platform, not a brochure.

Twelve screens from the running console, walked through point by point. These are real captures of the application against a demonstration environment — the interface is genuine, the estate inside it is invented.

Every hostname shown uses example.com and every address is documentation or private space. No customer data appears on this page.

Watch it end to end

Just under four minutes through the running console, captioned as it goes: the multi-customer view, discovery, findings and their evidence, the exposure graph, attack paths, assessment coverage, Fix First, Entra identity, RMM remediation, change detection, CMMC readiness, the monthly customer review and executive reporting.

Screen recording of the running application against the demonstration environment, captioned on screen. Background music only, no narration — nothing in this recording is conveyed by sound, so muting it loses you nothing. Every screen is also covered as a still below, so nothing here is available only as video.

Step 1

Start with the exposure picture

Not a feed of findings. Where the risk sits, which way it is moving, and what needs a person today.

1
Overall risk score
A single number with a band, derived from the same named factors used on every finding.
2
Findings by severity
Counts split by severity so the shape of the estate is visible at a glance.
3
Trend over the period
Whether exposure is falling or rising, not just today's total.

Next: open the inventory behind these numbers, because a score is only as good as the estate it was computed over. the inventory →

sniff.exploithound.com/executiveDemonstration data · v2.80.1

Start with the exposure picture shown in the Exploit Hound console

Step 2

Everything you own, in one inventory

External surface, internal networks and endpoints land in the same inventory, each carrying the context prioritization depends on.

1
Authorization state
Assessment only happens against assets explicitly marked authorized.
2
Scope
Domains and addresses that define what is in bounds for this asset.
3
Environment
Production and development are treated differently by scoring.

Next: what those domains say about themselves to the rest of the internet. domain mail authentication →

sniff.exploithound.com/assetsDemonstration data · v2.80.1

Everything you own, in one inventory shown in the Exploit Hound console

Step 3

What your domains say about themselves

Missing or weak SPF, DKIM and DMARC records raise the risk that someone can impersonate a domain in mail, and can affect whether the domain’s own mail is delivered. Exploit Hound checks what each domain actually publishes, and where it hosts the DNS, publishes what is missing.

1
The record type, not just the name
A wildcard DNS record makes every name under a domain resolve, so anything asking “does this exist” gets a yes while the record itself is absent. This asks for the record.
2
It will not invent a DKIM key
The key belongs to the mail server that signs the mail. One that does not match makes signatures fail rather than be missing, which is worse than publishing nothing.
3
Publishing needs the DNS to be ours
Where it is not, the records are still shown, marked as something the domain’s own operator has to add.

Next: the findings on those assets, each carrying the evidence it was raised from. findings and evidence →

sniff.exploithound.com/domainsDemonstration data · v2.80.1

Domain mail authentication, showing what is published and what is missing, in the Exploit Hound console

Step 4

Findings with the evidence attached

Every finding carries what was observed, how confident the platform is, and the remediation that closes it.

1
Severity and risk
Severity is the raw signal; the Exploit Hound risk score is the prioritized one.
2
Affected asset
Which system, so the finding is actionable rather than abstract.

Next: how those findings connect, which is where a list stops being a list. attack paths →

sniff.exploithound.com/findingsDemonstration data · v2.80.1

Findings with the evidence attached shown in the Exploit Hound console

Step 5

See how exposures connect

Individual findings become routes. A path is labeled potential unless evidence supports something stronger — we do not call a path exploited because it exists.

1
Active paths
Routes currently present in the graph, and how many reach critical systems.
2
Confidence label
Potential, high confidence, observed — never conflated.
3
Choke points
Where one fix removes the most routes.

Next: the ranking that comes out of those paths — which single change removes the most of them. Fix First →

sniff.exploithound.com/attack-pathsDemonstration data · v2.80.1

See how exposures connect shown in the Exploit Hound console

Step 6

One ranked list of what to do

Findings grouped into the actions a person actually performs, ranked by what each removes.

1
Recommended actions
The work, not the finding count.
2
Modeled attack paths
How many routes the graph holds right now, which is what a prediction is counted against.
3
Est. share of modeled path risk
A share of the modeled path risk, with the count and its denominator underneath. Not a reduction in total exposure.

Next: doing one, and finding out whether it worked. verification →

sniff.exploithound.com/fix-firstDemonstration data · v2.80.1

One ranked list of what to do shown in the Exploit Hound console

Fix First prioritization in full →

Step 7

Prove the fix, then watch for drift

Remediation is not the end of the loop. Targeted rechecks confirm the exposure is gone, and change detection surfaces what moved since.

1
Window
Added, removed, worsened and improved over a period you choose.
2
What changed
New exposure is what deserves attention; a month-old unchanged finding is not news.

Next: the identity side, where a cloud account can undo a network fix. Entra identity →

sniff.exploithound.com/changesDemonstration data · v2.80.1

Prove the fix, then watch for drift shown in the Exploit Hound console

Step 8

Cloud identity, read-only

Microsoft Entra ID assessed through read-only Graph permissions, shown with what each permission is for before anything is granted.

1
Consent is informed
The exact permissions, what each reads, and what goes unassessed without it — above the form, before anything is created.
2
Gaps are shown as gaps
Conditional Access and risk detections here were not assessed: one permission was never granted, the other needs a licence this tenant does not have. An unchecked area is not a clean result.
3
Read-only by design
Not one write permission is requested, so a compromise of this platform cannot modify a customer’s directory.

Next: sending an approved action to the RMM the technician already uses. RMM remediation →

sniff.exploithound.com/admin/integrations/entraDemonstration data · v2.80.1

Entra ID exposure, with its coverage gaps stated

Step 9

Approved remediation, through your RMM

Named actions from a fixed catalogue, executed on devices matched confidently enough to act on.

1
A catalogue, not a script
Exploit Hound submits named actions. It cannot send a script of its own to a tool that runs as SYSTEM on every endpoint.
2
Device matching shows its evidence
“Matched on serial 5CG9284XYZ” is checkable. A weaker match needs a person to confirm it before anything runs.
3
Approval is opted into
The default is that nothing runs unattended. Saving credentials is not the act that authorises changing machines.

Next: the part that matters — the RMM says it ran, and this checks whether the exposure is gone. proof of fix →

sniff.exploithound.com/admin/integrations/rmmDemonstration data · v2.80.1

RMM remediation with device mappings and their evidence

Step 10

Then prove the exposure is gone

The RMM reporting success is not evidence. After an action completes the findings are re-probed and the exposure graph recalculated.

1
Measured, not estimated
14 attack paths no longer appear in the recomputed graph, measured against a baseline captured when the work was submitted.
2
Partial stays partial
Two findings confirmed resolved, one still present, one endpoint failed. The ticket stays open and the failed endpoint keeps its finding.
3
Unverifiable is not fixed
Anything that could not be re-checked is reported as unverified rather than counted as resolved.

Next: what all of this adds up to against a framework, including what it cannot see. CMMC readiness →

sniff.exploithound.com/admin/integrations/rmmDemonstration data · v2.80.1

A verified remediation result, including what failed

Step 11

Readiness, including what it cannot see

CMMC technical readiness across the requirements this platform can evidence — and, at least as prominently, the ones it cannot.

1
The largest number first
89 of 110 requirements are not assessable by a vulnerability platform, and that is the largest figure on the page.
2
Four states, not three
A requirement with no findings only passes if we actually assess it. Where our evidence cannot complete one, it says what a human must supply.
3
Never a certification
The disclaimer sits directly above any status.

Next: the same picture across every customer at once. the MSP console →

sniff.exploithound.com/compliance/cmmcDemonstration data · v2.80.1

CMMC technical readiness, with its coverage stated

Step 12

Every customer in one console

Built for running security across many environments, with tenant isolation enforced at the query layer rather than by convention.

1
Per-customer posture
Each environment scored on the same methodology, so they are comparable.
2
Where to spend today
Cross-customer view of what is most urgent.

That is the tour. The demonstration environment is invented; the interface is the running application. ask for a walkthrough →

sniff.exploithound.com/mspDemonstration data · v2.80.1

Every customer in one console shown in the Exploit Hound console

What happens to a finding

Nothing quietly disappears

Four of these are the answers people expect a security tool to hide, so it is worth being specific about what each one does to the record.

Accepted risk

Somebody decided to live with it, and that decision is recorded with who made it. The finding stays open in the data and stops appearing in the work queue. A later scan that sees it again does not reopen it or count it as new — it counts it as seen and suppressed, so a scan that met it does not look identical to one that did not.

False positive

Marked by a person, not inferred. The finding is excluded from scoring and from Fix First, and the signature is remembered so the same detection on the same asset does not come back as new next week. It remains readable: a false-positive decision that turns out to be wrong needs to be findable.

Partial verification

The re-check ran and could not reach everything it needed to. That is reported as unverified rather than as fixed, and the ticket stays open on the part that could not be checked. A remediation that worked on nine endpoints and failed on the tenth is not a remediation that worked.

Reopened

A verified fix that a later scan finds again. The finding reopens with its history attached rather than starting over, so the record shows it was fixed, when, and that it came back — which is the sequence somebody needs when a change keeps getting undone.

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.

Start Finding Exposure See How It Works