Enrichment Data

In addition to the fingerprint and CVE fields (see Response Schema), each target-intel record carries enrichment derived from the host itself: where it sits on the network, what kind of infrastructure it is, and the full protocol-level detail captured when its service was grabbed.

Enrichment fields follow the standard omitempty contract: a field is only present on a record if it was populated for that observation.

Network and Geolocation Fields

asn, country, and country_code are all queryable. as_name and as_domain are returned for context but are not searchable — to find every host on a network operator's infrastructure, query by asn or cidr.

Classifications

classifications is a flat array of type:value strings describing what kind of infrastructure the host is, independent of what software it runs. A single host can carry several. Classifications come from the same scanning rules that identify products, plus one label computed from VulnCheck's canary network.

The values above are examples, not the full set — each type carries many more, and the library grows as new frameworks and malware families are fingerprinted. Coverage per value also moves with the internet: a framework whose operators rotate infrastructure may have many matching hosts one week and none the next, so a value returning no results is normal rather than a sign the value is wrong.

canary-attacker is the join between Target Intelligence and Canary Intelligence: a host that both exposes a vulnerable service and actively attacks canaries is usually compromised infrastructure being used to attack others.

cdn and proxy are by far the most common classifications, and both are worth filtering out as much as in — a CDN-fronted host's fingerprint often describes the CDN edge rather than the origin.

See Query Parameters for how to filter on these, including why the combined type:value form should not be passed to the classifications parameter.

Protocol-Specific Service Metadata

The metadata object holds everything captured from the service during the banner grab. Its shape depends on the record's protocol field — there are around 48 distinct shapes, one per supported protocol. Consumers must branch on protocol before reading metadata.

A handful of examples, all real response shapes:

protocol: "ssh"

{
  "raw": "SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u10",
  "hassh": "425d29fe50d8e4f5e37efb6e24bcf660",
  "host_key_algorithm": "ssh-rsa",
  "ja4ts": "42340_2-1-1-4-1-3_1460_9"
}

protocol: "modbus"

{
  "function_code": 43,
  "length": 8,
  "unit_id": 0,
  "response": "DgGDAAAA",
  "mei_response": {
    "conformity_level": 131,
    "mei_objects": [],
    "next_object_id": 0,
    "object_count": 0
  },
  "ja4ts": "64240_2-1-1-4-1-3_1460_10"
}

protocol: "http" — the richest shape, and the one most records carry:

Every TLS-capable protocol — HTTP, FTP, SMTP, IMAP, POP3, RDP and others — also carries a shared block of TLS handshake and certificate fields:

Certificate and TLS fingerprint fields are where a lot of the analytic value sits. jarm, ja4s, and ja4x_fingerprints identify server implementations independently of banners, which is how much of the c2 classification coverage is built — several C2 frameworks are identifiable only by their TLS certificate or handshake, never by an HTTP response.

ja4ts — a TCP-level fingerprint — is present on essentially every protocol shape, including those with no TLS at all.

Note on certificate identities: cert_common_name, cert_subject_dn, cert_issuer_dn, and subject_alternative_names are returned but not searchable. The hostname and domain parameters search reverse DNS only, so a host whose certificate names your organization cannot be found by certificate identity through this API.

Note on empty-by-design fields: a few fields exist in the metadata schema but are not populated in this export — body_shodan_hash, favicon_shodan_hash, favicon_md5, and redirects on HTTP, and host_key / host_key_fingerprint_sha256 on SSH. Treat them as reserved rather than as "no data observed".