Skip to main content
Use the services dataset when each endpoint matters. One result represents one observed network service, so a host with several exposed ports can produce several results.

​
Build the hypothesis

Start with the strongest stable signal you have, then add constraints that reduce noise.
Tag results respect the API key’s organisation visibility. Category paths use canonical slash notation, and /* includes descendants.
This example finds observed SSH services on port 22:
Search results are ordered by recent matching observations. Review:
  • ip_address or domain, port, and transport for endpoint identity.
  • protocol, status, and scanned_at for the observation.
  • banner, http, and tls for promoted protocol evidence.
  • fingerprints for allowlisted stable fingerprints.
  • tags for visible reviewed classifications.
  • matched_fields only as bounded match context; check matched_fields_complete before treating it as exhaustive.

​
Validate generated queries

Validate queries produced by a user, agent, or saved hunt before execution:
Validation checks syntax, public fields, and field-specific operators without running a search.

​
Turn one service into a broader hunt

1

Choose stable evidence

Prefer a protocol fact, certificate identity, reviewed tag, or fingerprint over a volatile banner fragment.
2

Add environmental constraints

Narrow by ASN, country, port, or observation date when the hypothesis calls for it.
3

Inspect a result page

Confirm the matches represent the intended service before requesting an exact count or distribution.
4

Measure the population

Run count and aggregate independently so analytics do not block the first page of evidence.

Measure the result set

Count the hunt and group it by fields such as country, ASN, or port.

Browse searchable fields

Find protocol-specific fields and supported operators.