What it looks at, and how.

Where collection runs

The onsite probe and the OS client are the same program

Exploit Hound ships one agent that does whichever job you give it, so the distinction below is about configuration rather than about software you have to choose between.

Both roles talk outbound to the hosted platform over TLS; nothing is opened inbound to the customer network. Enrolment is a one-time token that becomes a per-agent credential, and an agent can be issued a client certificate so the platform can recognise it by more than a bearer token. See the architecture for how the two halves fit.

Methods that reach out

These send traffic to your systems, so all of them are limited to assets you have confirmed you own or are authorized to test.

• 1
  Internet-facing discovery

  How: subdomain enumeration and DNS resolution across the domains you confirm, then TLS certificate inspection and port and service identification on what resolves.
  Needs: your domains and address ranges, confirmed as yours.
  Finds: assets nobody remembered were exposed, expired or mismatched certificates, deprecated TLS versions, administrative interfaces reachable from the Internet, and services whose version is known-vulnerable.

• 2
  Web application assessment Beta

  How: safe HTTP requests to sites on assets you have confirmed. It reads TLS certificates and which protocol versions actually negotiate, response headers, cookie flags, advertised HTTP methods, and a fixed list of paths that expose things by accident. Nothing attempts execution and nothing writes.
  Needs: the site’s domain confirmed on an authorized asset. A URL that does not match is refused before any request is made.
  Finds: expired and mismatched certificates, deprecated TLS, plain HTTP without a redirect, missing security headers, session cookies without Secure or HttpOnly, exposed .git directories and environment files, readable backups, administrative interfaces and debug endpoints reachable from the Internet, directory listings and open redirects.
  Cannot determine: anything requiring authentication, business logic flaws, or whether a fingerprinted version is genuinely the version running — a banner is what a server chose to say, and findings from one are marked at lower confidence.
  Into the graph: the site becomes a node reachable from the Internet, and exposures that are genuinely a way in — readable source, exposed configuration, an administrative interface — become edges an attack path can traverse. A missing Permissions-Policy is a finding, not a path.

• 3
  Authorized active web assessment Beta

  How: crafted requests — strings resembling SQL injection, cross-site scripting and path traversal — sent to see how the application responds. It gains no execution, extracts no data, changes nothing and keeps no access. It is still traffic somebody has to have agreed to receive.
  Needs: an authorisation record naming the exact hosts, with the acknowledgement text a person accepted stored alongside it, an expiry date, a request budget, a rate limit, and optionally a maintenance window. No wildcards. It is off by default and a scan profile does not enable it: “deep” is an operator’s judgement about thoroughness, and this is the customer’s decision about what may be sent at their site.
  Refuses: hosts outside the authorisation, redirects that leave it, paths where a crafted request performs an action rather than reveals one — logout, delete, checkout, billing, backup — which no authorisation unlocks. Withdrawing permission stops a scan that is already running, not just the next one.
  Finds: indicators. A response that suggests injection is an indicator and is recorded as one; this platform does not confirm exploitability, because confirming it would mean exploiting it.
  Never run against a customer. The controls above are implemented and tested; no live site has been actively assessed.
  Severity is contextual: a missing Content-Security-Policy is moderate on a site handling credentials and informational on a brochure page.

• 4
  Internal network discovery

  How: a probe on the network sweeps it with ARP and nmap, identifying hosts, open ports and service versions.
  Needs: a probe inside the network and the ranges you want swept.
  Finds: devices nobody inventoried, unexpected listening services, unsupported operating systems, and the internal reachability that decides whether an external foothold goes anywhere.

• 5
  Endpoint assessment

  How: an agent on the endpoint reports installed software and patch state; findings come from comparing versions against the vulnerability corpus, not from probing the machine.
  Needs: the agent installed.
  Finds: missing patches and vulnerable package versions, per machine, including on endpoints that never appear in a network scan because they were asleep or off-site.

• 6
  Fix verification

  How: after a fix, the specific service is re-checked — a TCP connect, a TLS negotiation, an HTTP header read, or a service banner. Only the check needed to answer the question, and only against authorized targets.
  Needs: nothing extra.
  Finds: whether the exposure is actually gone. A ticket being closed is not evidence; this is.

Methods that read configuration

These query a directory with credentials you supply. They read; they never write.

• 7
  Active Directory

  How: read-only LDAP queries against a domain controller.
  Needs: a read-only account, and your written authorization.
  Finds: unconstrained delegation, privileged accounts with service principal names, stale privileged accounts, weak domain password policy, privileged group nesting, and the paths those create toward domain control.

• 8
  Entra ID and Microsoft 365

  How: read-only Microsoft Graph queries. Every permission requested is a read permission — the platform cannot modify your directory, by design.
  Needs: an app registration and administrator consent. The exact permissions are shown before you grant them.
  Finds: privileged accounts without strong authentication, more Global Administrators than a tenant needs, guests holding directory roles, applications holding directory-wide write permission, and Conditional Access that is configured but not enforced.

• 9
  Microsoft Azure Beta

  How: read-only Azure Resource Manager queries using the Reader role.
  Needs: an app registration with Reader assigned on the subscriptions you want assessed — nothing more. Reader cannot read the contents of a Key Vault secret; that needs a data-plane role this platform does not request and would refuse to hold.
  Reads: virtual machines, public IP addresses, network security group rules, storage accounts, Key Vault configuration and role assignments.
  Finds: management ports open to any source, internet-facing machines, storage permitting anonymous access, storage and vaults reachable from any network, vaults without purge protection, privileged roles assigned across a whole subscription, and an internet-facing workload carrying a managed identity that holds privileged access.
  Cannot determine: what is inside your storage or vaults, whether a public workload is meant to be public, or anything about resources in subscriptions where the Reader role was not assigned — those are reported as unassessed rather than clean.
  Into the graph: subscriptions, machines, storage, vaults and identities become nodes, and the escalation route becomes edges. That last one is the point: Internet → a machine with a management port open → the managed identity it carries → Contributor across the subscription is a path, and neither half of it is visible on its own.

• 10
  Amazon Web Services Beta

  How: read-only AWS API queries, using a role in your account that this platform assumes. There is no AWS credential of yours to store: the session the role yields expires in an hour.
  Needs: a role carrying AWS’s own SecurityAudit managed policy, whose trust policy names this platform and requires an external ID. The external ID is generated per connection and is not optional — without it, a role that trusts us could be assumed on behalf of anyone who learns its ARN.
  Reads: EC2 instances and their security groups, S3 bucket access settings, IAM roles, users and policy attachments, RDS instance settings, and the existence of secrets.
  Finds: management ports open to any address, instances with public addresses, instance metadata service v1 still permitted where a role is attached, publicly accessible buckets and databases, users holding account-wide policies, console users without MFA, long-lived access keys, roles assumable from outside the account, and an internet-facing instance carrying a role that holds account-wide privilege.
  Cannot determine: what is inside a bucket, a secret or a key — the policy requested grants no permission to read the contents of anything, which is deliberate. Nor anything in a region you did not select for collection: those are reported as unassessed rather than clean, because a region nobody read is invisible, not empty.
  Into the graph: accounts, instances, buckets, databases and roles become nodes, and the escalation route becomes edges. That last one is the point: Internet → an instance with SSH open → the role its instance profile carries → AdministratorAccess across the account is a path, and neither half of it is visible on its own. Where IMDSv1 is still permitted the first step gets cheaper still, because a server-side request forgery reaches the credentials without code execution at all.

• 11
  Google Cloud Beta

  How: read-only Google Cloud API queries. Access is a role binding you add for this platform’s service account on your project. Nothing is exchanged in either direction, and you revoke it by removing the bindings.
  Needs: five narrow predefined roles — compute.viewer, iam.securityReviewer, storage.bucketViewer, cloudsql.viewer and optionally secretmanager.viewer. That is a longer list than the single role Azure and AWS need, and it is deliberately less access: the obvious one-role answer is Google’s basic roles/viewer, and granting it also confers storage.objects.get — the ability to read the contents of every file in every bucket. Exploit Hound refuses it and asks for the narrow roles instead.
  Reads: Compute Engine instances and their service accounts, firewall rules, Cloud Storage bucket settings and IAM policies, Cloud SQL instance settings, project IAM bindings, service account keys, and secret names with their rotation settings.
  Finds: management ports open to any address, permissive firewall rules that name no target and therefore apply to every instance on the network, instances running as the default compute service account, instances with full API access scope, publicly accessible buckets and databases, databases that do not require TLS, basic Owner and Editor role bindings, user-managed service account keys, and an internet-facing instance whose service account holds privileged access to the project.
  Cannot determine: what is inside a bucket or a secret — the roles requested grant no permission to read the contents of anything. Nor anything served by an API you have not enabled: a disabled API and a missing role both return the same error, so the two are reported separately rather than merged into one confusing message.
  Into the graph: projects, instances, buckets, databases and service accounts become nodes, and the escalation route becomes edges. The Google-specific version of that route is worse than its AWS equivalent because of what is default: Internet → an instance with SSH open → the default compute service account Google attached to it automatically → Editor across the project. In AWS somebody has to attach an over-privileged role; here the over-privileged identity is what you get unless somebody intervened.

Methods that only listen

These send nothing. They are how the platform learns what is really happening rather than what should theoretically be reachable.

• 12
  Honeypots

  How: decoy services you deploy deliberately, recording what connects, from where, and which credentials are tried.
  Needs: a honeypot deployed where you want the visibility.
  Finds: which services are being probed and by whom, and which credentials attackers are currently trying against you. Because a honeypot has no legitimate users, every connection to it is worth reading.

• 13
  NetFlow

  How: flow records exported by routers and firewalls you already run.
  Needs: flow export pointed at the collector.
  Finds: what actually talks to what. This is the difference between assuming a segment is isolated and having evidence, and it is what stops a finding on an unreachable host outranking one on a reachable one.

• 14
  Vulnerability and threat intelligence

  How: continuously synchronised CVE data, EPSS exploitation probability, the CISA Known Exploited Vulnerabilities catalog, and public exploit availability.
  Needs: nothing from you.
  Finds: which of your vulnerabilities are being exploited in the world right now, as opposed to which ones score highly in the abstract.

What it does with all of it

Collection is the cheap part. The reason for gathering these particular things is that together they answer a question no single one of them can.

What it does not do

A page that lists only capabilities is an advertisement. These are deliberate limits, and they are as much a part of the design as the checks above.

• —
  It does not exploit anything

  Nothing tries to gain execution, extract data, change content or keep access. Attack path validation is limited to safe checks — negotiate a protocol version, read a header, complete a handshake. Web assessment additionally has an active mode that sends crafted input and reads the response; it is off by default, needs a per-host authorisation somebody at the customer signed, and is described in full on what we scan.

• —
  It does not scan what you have not authorized

  Targets are limited to domains and ranges confirmed as yours. Discovering an asset is not the same as being permitted to test it, and the platform keeps those separate.

• —
  It does not modify your directory

  Active Directory and Entra access are read-only. Remediation is described for a human to action, or executed through your own RMM under an approval mode you choose.

• —
  It does not run its own patches

  Exploit Hound is not an RMM. It submits named actions from a fixed catalog to the endpoint tool you already run; it cannot send a script of its own.

• —
  It does not claim what it could not check

  Where a permission was not granted or a licence is absent, the affected area is reported as unassessed rather than clean. An empty result and an unchecked area are different facts.