---
updatedAt: 2026-11-10T18:31:52.000Z
agentTools:
  projectIndex: https://docs.censys.com/llms.txt
---

# Platform Host Dataset

Censys provides a comprehensive view of internet-connected assets through its Platform datasets. At the core of this dataset are hosts, which represent individual IP addresses (IPv4 or IPv6) and their associated information. This article delves into the host data model within the Censys Platform, illustrating how hosts and their services are represented and the rich data they encompass.

In the Censys Platform, a host is defined by a unique IP address, represented as the top-level field `host.ip`. Each host record encapsulates various data points describing the host's characteristics and behaviors. These records are accessible via the Censys Platform interface and API, providing users with detailed insights into the attributes of each host.

<Image src="https://files.readme.io/2ef4f3892328f82d9143e92f98af4d8993077029b9a4597b4426c177b0d2bbef-host_example.jpg" align="center" caption="An example host record for 8.8.8.8 in the Censys Platform web interface." border={true} />

<Callout icon="📘" theme="info">
  ### Note

  [Read this article](https://docs.censys.com/docs/internet-scanning#/) to learn about how Censys scans the internet to build its datasets.
</Callout>

## Host data model and enrichment

The host data model is structured to provide a comprehensive overview of each IP address and is enriched with information from Censys and third-party sources. Host data records can consist of multiple objects and nested objects that describe them and the services present on them.

<Image src="https://files.readme.io/7fb884b919f5ed88ee3fc1ecea264a9e25d128b2530fa1b495d4b01a488c21fd-data_diagram.png" align="center" caption="A simplified diagram showing the schema structure and hierarchy for a small selection of host data objects and fields and how they are presented in the Censys Platform." border={true} />

Key components and enrichment aspects of a host record include:

* [Location](https://platform.censys.io/home/definitions#host-host-location): Detailed geographical information associated with the IP address, such as country, region, city, postal code, and estimated latitude and longitude. This allows for understanding the physical distribution of assets.
* [Network routing](https://platform.censys.io/home/definitions#host-host-autonomous-system): Information about the network path to the host, including Autonomous System Numbers (ASNs) and the organizations that own these networks. This is crucial for understanding network infrastructure and identifying potential points of origin or control.
* [DNS information](https://platform.censys.io/home/definitions#host-host-dns): Resolution of IP addresses to associated domain names (forward DNS lookups) and identification of PTR records (reverse DNS lookups), providing valuable context about the purpose and ownership of a host.
* [Operating system](https://platform.censys.io/home/definitions#host-host-operating-system) details: Censys attempts to identify the operating system running on the host based on network behavior and service banners, which is crucial for understanding the host's configuration and potential vulnerabilities.
* [WHOIS](https://platform.censys.io/home/definitions#host-host-whois): Information about registered domain names, IP addresses, and their owners or administrators.
* [Services](https://platform.censys.io/home/definitions#host-host-service-information): A list of services detected on the host, including software information when available.

<Callout icon="📘" theme="info">
  ### Note

  See all available data objects and fields for host records on the [Data Definitions page in the Platform web console](https://platform.censys.io/home/definitions).
</Callout>

## Nested objects and nested fields

On host records, some data objects and fields are nested within other objects.

When writing queries in Censys Query Language, you can use [nested fields](https://docs.censys.com/docs/censys-query-language#nested-fields) to require that multiple search criteria are true of a single object on a data record (like a service), instead of the host, web property, or certificate as a whole. For example, you can use nested fields in a query to only return results that are presenting a specific service on specific port, such as with the query `host.services: (protocol=SSH and port=22)`.

## Host reputation

<Image src="https://files.readme.io/8051051c5db835320a3ae95f3aec374724ce506572202f0d03b440fc474f7539-Screenshot_2026-10-16_at_1.13.01_PM.png" border={true} />

In the Censys Platform, hosts are assigned a reputation label and score that describe their riskiness. This information enables you to prioritize alerts with IP indicators faster and perform triage and analysis more effectively with a transparent and consistent scoring methodology.

<Anchor target="_blank" href="https://docs.censys.com/docs/platform-reputation-scores">Learn more about reputation labels and scores here</Anchor>.

## Service information

Host service objects (`host.services`) contain detailed information about the protocols running on an IP. Each service contains some common information, such as identified software and hardware, TLS and certificate information, labels, and other metadata.

In addition to plain text names, Common Platform Enumeration (CPE) values are also provided for software and hardware and their components.

<Callout icon="📘" theme="info">
  ### Note

  Some data fields are restricted. They are only available to users that are on a paid Censys Platform tier or have access to specific Platform modules or datasets. If you see a 🔒 lock icon by a field or value, it means that you must upgrade to view the data. [Learn more about paid Platform plans](https://docs.censys.com/docs/data-access-tiers-entitlements).
</Callout>

Many services contain highly detailed protocol-specific information. This protocol-specific information is found in a nested object with the same name as the protocol. For example, SSH-specific information can be found within host.services.ssh.

Unidentified protocols are reported with `UNKNOWN` values. This can be because the service is not adhering to a protocol or because the protocol is very uncommon and Censys does not yet have a protocol-specific scanner written for it.

HTTP services use a different representation of protocol-specific data. HTTP service data can be found at `host.services.endpoints`. Each endpoint offers information about a web application or HTTP GET response for a specific URI. To access web application information, use `host.services.endpoints.[application_type]`, such as `host.services.endpoints.prometheus`. To access HTTP GET information, use `host.services.endpoints.http`.

Examples of other useful service data fields and objects include the following.

<Table align={["left","left"]}>
  <thead>
    <tr>
      <th>
        Data field or object
      </th>

      <th>
        Description and notes
      </th>
    </tr>
  </thead>

  <tbody>
    <tr>
      <td>
        `host.services.port`
      </td>

      <td>
        The network port on which the service is running (such as `80` or `443`).
      </td>
    </tr>

    <tr>
      <td>
        `host.services.protocol`
      </td>

      <td>
        The protocol used by the service (for example, `HTTP` or `SSH`).
      </td>
    </tr>

    <tr>
      <td>
        `host.services.banner`
      </td>

      <td>
        A string returned by the service, often containing version information or a welcome message. Hashed versions of this information is provided in `host.services.banner_hash_sha256` and `host.services.banner_hex`.
      </td>
    </tr>

    <tr>
      <td>
        `host.services.cert`
      </td>

      <td>
        Details about the certificate used for a service, including subject, issuer, validity period, and subject information. Service certificate information, such as the certificate SHA-256 hash contained in `host.services.cert.fingerprint_sha256`, is particularly useful for pivoting to related web infrastructure using the same certificate (in the present or <Anchor target="_blank" href="https://docs.censys.com/docs/platform-threat-hunting-use-cert-history-to-build-better-detections#/">historically</Anchor>  ).
      </td>
    </tr>

    <tr>
      <td>
        `host.services.scan_time`
      </td>

      <td>
        When the service was last observed by a Censys scan.
      </td>
    </tr>

    <tr>
      <td>
        Protocol-specific objects and their attendant fields (`host.services.ssh`, `host.services.rdp`, and so on)
      </td>

      <td>
        Detailed, parsed information depending on the protocol (such as TLS/SSL certificate details for HTTPS, HTTP banner and server software for HTTP, SSH banner and algorithms for SSH).
      </td>
    </tr>

    <tr>
      <td>
        `host.services.software`
      </td>

      <td>
        Information about the software identified on the service, including name, version, and vendor, often in the Common Platform Enumeration (CPE) format. Additional contextual data about software including components and life cycle information is available to enterprise customers (see below).
      </td>
    </tr>

    <tr>
      <td>
        Host service HTTP header and body information (`host.services.endpoints.http.headers` and `host.services.endpoints.http.body`, as well as body hash fields like `host.services.endpoints.http.body_hash_sha256`)
      </td>

      <td>
        Header and body information returned by host HTTP services. The first 64 kilobytes of HTTP bodies for host service endpoints are indexed and searchable in the Platform UI and Platform search API.

        The first 64 kilobytes of an HTTP body are used to compose the hashes that are indexed and searchable in the Platform.<br /><br />The first 2 kilobytes of HTTP headers are indexed and searchable in the Platform.&#x20;
      </td>
    </tr>

    <tr>
      <td>
        Host service HTTP favicon information (`host.services.endpoints.http.favicons.size`, `host.services.endpoints.http.favicons.hash_md5`, and so on)
      </td>

      <td>
        Adversaries often use cloned pages for phishing, malware control panels, and other purposes that use the same favicon. Additionally, you can use favicons to identify exposed software on assets.

        Favicon hashes are generated using the first 384 kilobytes of the favicon.
      </td>
    </tr>
  </tbody>
</Table>

These fields help identify the nature of the services on a host and can be used to detect outdated software, misconfigurations, threats, or potential vulnerabilities.

### TLS information

Transport Layer Security (TLS) is a cryptographic protocol for securing communication over a network. TLS information for services detected on hosts by Censys is available in the `host.services.tls` object. TLS data includes the cipher suite selected, post-quantum cryptography (PQC) key exchange groups, and more. You can use PQC data, for example, to determine whether a server or application supports quantum-resistant algorithms like ML-KEM (Kyber) and hybrid key exchanges like X25519MLKEM768.

The TLS object also contains JARM fingerprints. <Anchor target="_blank" href="https://docs.censys.com/docs/platform-jarm-fingerprints">Learn more about JARM in the Platform here</Anchor>.

Selected TLS data for host services is shown in the table below.

| Data field                             | Description                                                                                                              |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `host.services.tls.cipher_selected`    | The cipher suite chosen for the exchange.                                                                                |
| `host.services.tls.key_exchange_group` | Key exchange group selected by the server: the TLS 1.3 key\_share group or the TLS 1.2 ECDHE curve, e.g. X25519MLKEM768. |
| `host.services.tls.pqc_groups`         | Post-quantum TLS 1.3 key exchange groups the server accepts, e.g. X25519MLKEM768.                                        |

### Host service threat context

All users on the [Censys Core tier](https://docs.censys.com/docs/data-access-tiers-entitlements) can view some host service threat data, including the following data fields.

| Data field                     | Description                                                                                              |
| :----------------------------- | :------------------------------------------------------------------------------------------------------- |
| `host.services.threats.id`     | A unique identifier for the threat.                                                                      |
| `host.services.threats.name`   | Name of the threat, such as `Cobalt Strike`.                                                             |
| `host.services.threats.tactic` | How the threat behaves and the purpose of the activity, such as `COMMAND_AND_CONTROL` and `PERSISTENCE`. |
| `host.services.threats.type`   | The role of the service, such as `PHISHING_SERVER` and `WEBSHELL`.                                       |

This information is visible on host records in the Platform web console and is retrievable via API.

<Image src="https://files.readme.io/1a8748c97f59c8c5804060b2397667805cd1333b1c1979bc88908262df0af6ae-Screenshot_2025-10-20_at_12.03.03_PM.png" align="center" caption="An example search result for a host showing that an AsyncRAT threat is present." border={true} />

To see complete threat metadata and search and pivot across threat data, you must have access to the <Anchor target="_blank" href="https://docs.censys.com/docs/platform-threat-hunting#/">Adversary Investigation module</Anchor>.

### Software context

Enterprise customers have access to additional data about service software. This includes information about software components (`host.services.software.components`) as well as life cycle information (`host.services.software.life_cycle` and `host.services.software.components.life_cycle`).

You can use component information to find software that has potentially vulnerable components. For example, you can run the query `host.services: (software.components.product = "nginx" and not software.product = "nginx")` to find service software that is using nginx components but is not itself detected as nginx.

### Software confidence

Software confidence in the Censys Platform measures how reliably Censys identifies service software and versions on assets. Confidence scores range from 0 (low) to 1 (high) and help users assess the likelihood of false positives in detected software fingerprints.

For host service software, the confidence level is provided in the `host.services.software.confidence` field. Exact matches of known, structured fields such as exact favicon hashes, HTTP body hashes, or banner content hashes may yield a high confidence value, whereas HTTP endpoint regex matches, body regex matches, or single-field keyword-based recognition may yield a low to moderate confidence value.

Confidence levels do not currently impact CVE (vulnerability) scoring. Software confidence fields are available exclusively to enterprise tier users.

### Service CVE/vulnerability data

Users on the Censys Core plan have access to Common Vulnerabilities and Exposures (CVE) data for host services in the `host.services.vulns` object. This information includes CVE IDs (`host.services.vulns.id`), CVSS scores (`host.services.vulns.metrics.cvss_v40.score` and others), whether the vulnerability is present in the Known Exploited Vulnerability (KEV) catalog (`host.services.vulns.kev`) and many other vulnerability data fields.

The Data Definitions page contains a [complete list of CVE and vulnerability data for host services](https://platform.censys.io/home/definitions?resource=host#host-host-cves).

#### CVE detections

CVE detections on host services are based on matching fuzzy or exact CPE strings to known vulnerabilities.

<Callout icon="📘" theme="info">
  ### Note

  Services and endpoints in the Censys datasets can have a maximum of 50 CVEs.
</Callout>

#### CVE data in the Platform web UI

Host services that are associated with CVEs have an alert icon next to them in host preview cards and on host record pages.

<Image src="https://files.readme.io/bc5363ebaf7015e259a11cfde74b5bebbd45efa1b2cd1ded2c568886e3cb8cbb-cve_services.png" align="center" caption="Three services with CVEs highlighted on an example host preview card." border={true} />

Additional CVE information is shown on service cards on host record pages.

<Image src="https://files.readme.io/bad1dc351fe97d9b150dd21b9d29a29b0ea101a472812b16727da93a8cc88756-cves_on_service.png" align="center" border={true} />

A detailed list of all the of CVEs present on a host's services is shown on the host's CVEs tab.

<Image src="https://files.readme.io/8117dc80e21218a024ebb5619a7f9e20bee49e5e4751505192a7ee7945acb524-cves_tab.png" align="center" border={true} />

Additionally, all vulnerability data for for a host service is available in the raw data output.

#### CVE search result filters

If you have access to CVE data, CVE-related information like CVE ID and CVSS score are available in the quick filters in the left-side toolbar for search result pages.

<Image src="https://files.readme.io/2b44f0c4ac8406a4c7aa5b5448a70542b476430fe6a0d5c4c21b93515095d416-host_cve_filters.png" align="center" border={true} />

#### Example queries for vulnerability data

Use the following queries to explore vulnerability data in the Platform.

| Query description and link                                                                                                                                                                                                                                                                                           | Query syntax                                                                                                                                                                                                              |
| :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Hosts with services with critical CVEs that are KEVs](https://platform.censys.io/search?q=host.services.vulns%3A+\(severity%3DCRITICAL+and+kev%3A+*\))                                                                                                                                                              | `host.services.vulns: (severity=CRITICAL and kev: *)`                                                                                                                                                                     |
| [Host with services with easily exploitable CVEs](https://platform.censys.io/search?q=host.services.vulns.metrics.cvss_v30.components.attack_complexity%3DLOW+or+host.services.vulns.metrics.cvss_v31.components.attack_complexity%3DLOW+or+host.services.vulns.metrics.cvss_v40.components.attack_complexity%3DLOW) | `host.services.vulns.metrics.cvss_v30.components.attack_complexity=LOW or host.services.vulns.metrics.cvss_v31.components.attack_complexity=LOW or host.services.vulns.metrics.cvss_v40.components.attack_complexity=LOW` |
| [Host with services vulnerable to a specific CVE ID, such as CVE-2019-14540](https://platform.censys.io/search?q=host.services.vulns.id%3A+"CVE-2019-14540")                                                                                                                                                         | `host.services.vulns.id="CVE-2019-14540"`                                                                                                                                                                                 |
| [Host running services with critical CVEs that an unauthenticated attacker can easily exploit](https://platform.censys.io/search?q=host.services.vulns%3A+\(metrics.cvss_v31.score>%3D9+and+metrics.cvss_v31.components.attack_complexity%3DLOW+and+metrics.cvss_v31.components.privileges_required%3DNONE\))        | `host.services.vulns: (metrics.cvss_v31.score>=9 and metrics.cvss_v31.components.attack_complexity=LOW and metrics.cvss_v31.components.privileges_required=NONE)`                                                         |

### Host service HTTP redirect data

Censys scans obtain redirect information from host services. Use this information to map relationships, identify misconfigurations, find parked domains, locate abandoned infrastructure, and more. For example, run `host.services.endpoints.http.redirect_chain.hostname="censys.com"` to find host services that redirect to `censys.com`.

Redirect data is visible to and searchable by users on the [Censys Search and Censys Core plans](https://docs.censys.com/docs/data-access-tiers-entitlements). Redirect data is visible to Censys Starter and Censys Free users, but they cannot search across it.

Host service redirect data is available in the following fields.

| Field                                                            | Description                                                                          |
| :--------------------------------------------------------------- | :----------------------------------------------------------------------------------- |
| `host.services.endpoints.http.redirect_chain`                    | The nested object that contains redirect chain data.                                 |
| `host.services.endpoints.http.redirect_chain.reason`             | The reason for the redirect. Can be `HTTP_3XX`, `REFRESH_HEADER`, or `UNRECOGNIZED`. |
| `host.services.endpoints.http.redirect_chain.transport_protocol` | The transport protocol used for the redirect.                                        |
| `host.services.endpoints.http.redirect_chain.hostname`           | The hostname that the redirect points to.                                            |
| `host.services.endpoints.http.redirect_chain.path`               | The path that the redirect points to, like `/`, `/login`, `/admin`, and so on.       |
| `host.services.endpoints.http.redirect_chain.port`               | The port that the redirect points to.                                                |

### Host HTTP services as web endpoints

Host HTTP services in Censys datasets are also present as [web property](https://docs.censys.com/docs/platform-web-property-dataset#/) endpoints. For example, a host HTTP service operating on port 443 on the host `1.1.1.1` will also have an attendant web property record available at `1.1.1.1:443`.

## Labels

Labels are tags applied to assets and services by Censys to help you quickly identify items and filter search results. Label values are always in [screaming snake case](https://en.wikipedia.org/wiki/Snake_case). Labels can be applied to hosts as a whole as well as specific services.

### Host labels

Labels on hosts (`host.labels.value`) are used to describe the type of host. Examples include:

* `BULLETPROOF`
* `IPV6`

### Host service labels

Labels on services (`host.services.labels.value`) are used to categorically describe the services present on hosts. <Anchor target="_blank" href="https://platform.censys.io/search/report/data/table?q=host.services.labels.value%3A+*&field=host.services.labels.value&num_buckets=500&filter_query=true&count_by=.">You can see a complete list of service labels by running a query for `host.services.labels.value` and then generating a report broken down by that field</Anchor>.

Examples include:

* `DEFAULT_LANDING_PAGE`
* `LOGIN_PAGE`
* `OPEN_DIRECTORY`
* `REMOTE_ACCESS`
* `WAF`

## Historical host data

<Anchor target="_blank" href="https://docs.censys.com/docs/platform-historical-data">Learn about historical host data here</Anchor>.

## "Many" service sampling in Censys data

When Censys identifies a host running the same protocol on a high volume of ports, the Platform transitions from exhaustive scanning to randomized sampling. You will see this labeled in the UI as `Many / [protocol]` (such as `Many / HTTP` or `Many / FTP`) or `[protocol] / [many]`.

To provide the most efficient and least intrusive scanning, Censys implements a threshold for service density. Once a single protocol is detected on a high volume of ports on a single host, that protocol enters "many" mode.

In this state, Censys scanners switch from attempting to verify every individual port to a probabilistic sampling method for that specific protocol.

If you encounter a "many" host, we recommend treating the data as a high-confidence indicator of protocol presence rather than a precise record of every active port at every second.

### Impact on scan data

Because the platform is no longer scanning every port in every scan cycle, the resulting data present on a host and its Service History reflects this sampling logic:

* Timeline gaps: In the <Anchor target="_blank" href="https://docs.censys.com/docs/platform-historical-data#service-history">Service History timeline visual</Anchor>, a port may appear as "down" (a gap in the green bar) simply because it was not selected in the randomized sampling, even if the service remained active.
* Point-in-time sample: On the host page, the service data shown for a "many" protocol represents a sampling of service details, not all service details. Similar behavior is seen in the <Anchor target="_blank" href="https://docs.censys.com/reference/v3-globaldata-asset-host">Platform get host API response</Anchor>. More information on how this data appears is provided in the list below.
  * UI
    * The `host.services.port` number for a "many" protocol will always appear as `0`.
    * The `host.services.representative_info.sampled_port` field will indicate the port for the sampled data.
  * API
    * In the JSON response, `host.services.port` for the "many" protocol will not be present.
    * `host.services.representative_info.sampled_port` will indicate the port for the sampled data.

### Service History timeline impacts

The table below provides guidelines for analyzing and understanding the Service History timeline for a "many" protocol.

| Visual indicator     | Interpretation for most hosts | Interpretation for hosts with "many" protocols                                                     |
| :------------------- | :---------------------------- | :------------------------------------------------------------------------------------------------- |
| Solid green bar      | Consistent uptime confirmed.  | The port was consistently selected and verified during random sampling.                            |
| Gaps in the bar      | Service was confirmed down.   | Potential sampling miss. The service may be up, but was not included in that scan's random sample. |
| New port appearances | A new service was identified. | A previously active port was caught in the random sampling.                                        |

## Example host record

The following is an example of a host record obtained via API to illustrate the data structure. This record indicates that the host at IP address `137.220.232.142` is located in Tokyo, Japan, belongs to ASN `152194`, and has an SSH service running on port 22.

```json
{
  "result": {
    "resource": {
      "ip": "137.220.232.142",
      "location": {
        "continent": "Asia",
        "country": "Japan",
        "country_code": "JP",
        "city": "Tokyo",
        "postal_code": "101-8656",
        "timezone": "Asia/Tokyo",
        "province": "Tokyo",
        "coordinates": {
          "latitude": 35.6895,
          "longitude": 139.69171
        }
      },
      "autonomous_system": {
        "asn": 152194,
        "description": "CTGSERVERLIMITED-AS-AP CTG Server Limited",
        "bgp_prefix": "137.220.232.0/24",
        "name": "CTGSERVERLIMITED-AS-AP CTG Server Limited",
        "country_code": "HK"
      },
      "whois": {
        "network": {
          "handle": "CTG220-192-JP",
          "name": "CTG Server Ltd.",
          "cidrs": [
            "137.220.192.0/18"
          ],
          "updated": "2022-03-30T00:00:00Z"
        }
      },
      "services": [
        {
          "port": 22,
          "protocol": "SSH",
          "transport_protocol": "tcp",
          "software": [
            {
              "source": "censys",
              "confidence": 0.9,
              "evidence": [
                {
                  "data_path": "protocol",
                  "found_value": "SSH",
                  "literal_match": "SSH"
                }
              ],
              "type": [
                "REMOTE_ACCESS"
              ],
              "part": "a"
            },
            {
              "source": "censys",
              "confidence": 0.9,
              "evidence": [
                {
                  "data_path": "protocol",
                  "found_value": "SSH",
                  "literal_match": "SSH"
                }
[truncated for brevity]
}
```