Responses Field Reference

May 23, 2025

The Responses Collection captures live data from internet-wide scanning of services and hosts. Each document represents a real-world service response, including banners, certificates, HTTP metadata, and network context. This dataset is essential for attack surface discovery, vulnerability assessment, infrastructure monitoring, and threat hunting.

Property	Description
Document	Each document represents a single service response collected during scanning.
Unique Identifier	The combination of the `uri` and `ip` fields serves as the unique identifier for each document.
Default Fields	- `host` - `domain` - `http.title` - `geo.country` - `isp` - `protocol` - `tag.name` - `uri` - `whois.asn.name` - `whois.net.name` - `whois.net.organization` - `whois.net.description` - `certificate.issuer_dn` - `certificate.issuer.common_name` - `certificate.issuer.organization` - `certificate.extensions.subject_alt_name.dns_names` - `certificate.names`

Addressing

A group of fields that are used to describe the addressing information, such as IP addresses, ports, and protocols.

`domain`

A list of domain names associated with the IP address.

This field is depricated due to unclear semantics. It is recommended to use the host field instead.

Field type: WILDCARD

Examples: example.com, www.example.com, example.org

`host`

The IP address or domain name used in the actual request.

Use this field to filter by the domain name or IP address of the scanned service. This may differ from target in cases where the response was captured after a redirect.

Field type: WKEYWORD

Examples: example.com, 23.215.0.136

Usage in queries:

Responses from a host with IP 23.215.0.136 (all services):
```
host:23.215.0.136
```
The same host, requested by domain name (HTTP services only):
```
host:example.com
```
The same domain and its subdomains (HTTP services only):
```
host:(example.com OR *.example.com)
```
Previous example as a regular expression:
```
host:/(.*\.)?example\.com/
```

Difference between IP and domain-based searches in the host field

When scanning by IP address, Netlas scans all available services on the target machine. In contrast, when scanning by domain name, only HTTP/HTTPS services on ports 80 and 443 are scanned.

So if you query host:example.com, you will only get HTTP(S) responses. To retrieve all services hosted on the machine behind example.com, use its IP address instead.

`host_type`

Type of the host field. Can be either ip or domain.

Field type: TTEXT

Examples: ip, domain

Usage in queries:

Find responses fetched after requests made by IP address on port 80:
```
host_type:ip port:80
```

`ip`

The IP address from which the response was received.

This field is always present, regardless of whether the request was made using an IP address or a domain name.

Field type: IPIP

Examples: 8.8.8.8, 23.215.0.136

Usage in queries:

Responses from an IP address:
```
ip:23.215.0.136
```
Responses from a specific IP address range using CIDR notation:
```
ip:"64.4.250.0/24"
```
Responses from a specific IP address range using a range query:
```
ip:[64.4.250.0 TO 64.4.250.255]
```
Combined query to get responses from domain-based requests only:
```
ip:23.215.0.136 port:443 host_type:domain
```
Combined query to get responses from IP-based requests only (no virtual sites):
```
ip:"64.4.250.0/24" host_type:ip
```

`path`

Path component of the URI.

Netlas requests only the index (main) page of the service.

Netlas does not scan the entire resource — only the index (main) page is requested.

If the path differs from /, it means the response was received after a redirect.

Field type: WKEYWORD

Examples: /, /login, /admin/

Usage in queries:

Filter out responses received after a redirect:
```
path:"/"
```
Services redirecting to a login page:
```
path:/.*\/login\/?/
```

`port`

Port number used to connect to the remote service.

Field type: #INTEGER

Examples: 80, 443, 22

Usage in queries:

port:8080

port:<1000

`prot4`

Transport-layer protocol used in the connection: tcp or udp.

Field type: WKEYWORD

Examples: tcp, udp

Usage in queries:

prot4:udp

`prot7`

Application-layer protocol.

This field does not include secure variants such as https or ftps. Use this field to search by general protocol type. For example, a query like prot7:http will match both http and https services.

To filter specifically by secure variants, use the protocol field instead.

Field type: WKEYWORD

Examples: http, ftp, smtp

Usage in queries:

prot7:http

`protocol`

Application-layer protocol used in the request, including secure variants.

Field type: WKEYWORD

Examples: http, https, ftp, ftps

Usage in queries:

protocol:(http OR https)

`ptr`

A list of reverse DNS pointer (PTR) records associated with the IP address, if available.

Reverse DNS domains such as in-addr.arpa and ip6.arpa are not indexed.

Field type: TTEXT

Examples: dns.google, mail.example.com

Usage in queries:

ptr:dns.google

`referer`

Referrer URL that led to this request. Present in cases of redirects (e.g., after a 301/302).

Referrer URL contains port information to identify the service that redirected the request.

Field type: TTEXT

Examples: https://redirector.example.com:443, http://23.215.0.136:8080

Usage in queries:

referer:"http://redirector.example.com:80"

`target.domain`

The initial scan target, which may differ from host after redirects.

This field is present only if the scan was initiated using a domain name.

Field type: WILDCARD

Examples: original.example.com

Usage in queries:

target.domain:www.example.com

`target.ip`

The initial scan target, which may differ from host after redirects.

This field is present only if the scan was initiated using an IP address.

Field type: IPIP

Examples: 23.215.0.136

Usage in queries:

target.ip:23.215.0.136

`target.type`

Type of the scan target. Values: ip, domain.

Field type: TTEXT

Examples: domain, ip

Usage in queries:

target.type:domain

`uri`

Full URI scanned, including scheme, host, port, and path.

Field type: WKEYWORD

Examples: https://example.com/login, http://23.215.0.136:8080/

Usage in queries:

Search for a specific URI:
```
uri:"https://google.com:443/"
```
Search for a specific URI and path:
```
uri:"http://1.1.1.1:80/redirect.php"
```

Search for a specific URI with a regular expression:

uri:/https:\/\/login.microsoftonline.com:443\/common\/oauth2\/.*/

Information

Fields containing additional meta information about response. Such as IP WHOIS data, X.509 certificate information, tags, and vulnerability information.

`certificate`

These are fetched during the scan X.509 certificate fields.

Certificates Field Reference →

Field type: OBJECT

`cve`

Common Vulnerabilities and Exposures (CVE) fields.

Read more about vulnerability detection technology in the dedicated article →

Field type: OBJECT

`cve.base_score`

The CVSS base score of the vulnerability, typically ranging from 0.0 to 10.0.

Field type: #SCALED_FLOAT

Examples: 9.8, 6.8, 5.5

Usage in queries:

CVEs with high risk score:
```
cve.base_score:>=9
```

`cve.description`

A textual summary describing the vulnerability.

Field type: TTEXT

Examples:

Microsoft SharePoint Server Remote Code Execution Vulnerability
A security regression in OpenSSH's sshd allows a race condition, potentially leading to signal mishandling.

Usage in queries:

Find CVEs mentioning a Microsoft SharePoint vulnerability:

cve.description:(Microsoft SharePoint Remote Code Execution)

Find CVEs mentioning OpenSSH:
```
cve.description:OpenSSH
```

`cve.exploit_links`

A list of URLs linking to public exploit code or proof-of-concept demonstrations for the vulnerability.

Field type: TTEXT

Examples:

https://github.com/samplerepo/CVE-2023-38408

`cve.has_exploit`

Indicates whether a known public exploit exists for this CVE.

This field is set to true if a public exploit exists for the vulnerability. If no exploit is known, the field is omitted from the response.

Field type: BOOLEAN

Examples: True

Usage in queries:

cve.has_exploit:true

`cve.name`

The CVE identifier of the vulnerability.

Field type: TTEXT

Examples: CVE-2025-21400, CVE-2024-6387

Usage in queries:

cve.name:"CVE-2024-6387"

`cve.severity`

Severity level assigned to the vulnerability, usually based on CVSS rating.

Field type: TTEXT

Examples:

CRITICAL
HIGH
MEDIUM
LOW

Usage in queries:

Filter responses with critical vulnerabilities:
```
cve.severity:CRITICAL
```

`geo`

Geolocation fields.

Represent the approximate physical location of the IP address associated with the response. The values are based on public IP geolocation databases and may not reflect the exact location.

Field type: OBJECT

`geo.accuracy`

Estimated radius of accuracy (in meters) for the geolocation.

A lower number means higher accuracy.

Field type: #LONG

Examples: 1000, 5000

`geo.city`

Name of the city where the IP address is geographically located.

Field type: WKEYWORD

Examples:

Sydney
Frankfurt

Usage in queries:

Find hosts located in Sydney:
```
geo.city:Sydney
```

`geo.continent`

Full name of the continent where the IP address is geographically located.

This value is based on GeoIP databases and may occasionally be missing (-) for ambiguous or unknown locations.

Field type: WKEYWORD

Examples:

North America
South America
Europe
Asia
Africa
Oceania
Antarctica

Usage in queries:

Find hosts located in Europe:
```
geo.continent:Europe
```
Filter responses from Oceania:
```
geo.continent:Oceania
```

`geo.country`

Two-letter country code of the IP's geolocation.

Always represented as a 2-digit code, following the ISO 3166-1 alpha-2 standard.

Field type: WKEYWORD

Examples: AU, DE, US

Usage in queries:

Hosts located in Australia:
```
geo.country:AU
```

`geo.is_satellite_provider`

Indicates whether the IP address belongs to a satellite internet provider.

This field is set to true when the IP is attributed to a known satellite-based network operator. If not present, the provider is assumed to be terrestrial (non-satellite).

Field type: BOOLEAN

Examples: True

Usage in queries:

geo.is_satellite_provider:true

`geo.location.lat`

Latitude of the IP geolocation.

Field type: #FLOAT

Examples: -33.494, 48.8566

`geo.location.lon`

Longitude of the IP geolocation.

Field type: #FLOAT

Examples: 143.2104, 2.3522

`geo.postal`

Postal code, if available, associated with the IP location.

Field type: TTEXT

Examples: 2000, 10115

`geo.registered_country`

Country where the organization owning the IP block is registered (may differ from geo.country).

Field type: TTEXT

Examples: US, CA

`geo.represented_country`

Country on behalf of which the IP is used (e.g., for military or diplomatic networks).

Field type: OBJECT

`geo.represented_country.name`

Full name of the country on behalf of which the IP is used.

Field type: TTEXT

Examples: US

`geo.represented_country.type`

Type of representation.

Field type: TTEXT

Examples: military

`geo.subdivisions`

Name of the first-level administrative region (such as state, province, or district) where the IP is located.

This typically refers to subdivisions like states in the US, provinces in Canada, or regions in other countries.

Field type: TTEXT

Examples:

California
Ontario
North Holland
Tokyo
Île-de-France

Usage in queries:

Filter hosts located in California:
```
geo.subdivisions:California
```

Match German regions like Bavaria or Berlin:

geo.subdivisions:(Bavaria OR "Land Berlin")

`geo.tz`

Time zone of the IP address, in the format of IANA Time Zone Database.

Field type: WKEYWORD

Examples:

America/Chicago
Europe/Kyiv
Asia/Bangkok

Usage in queries:

Hosts in Jerusalem time zone:
```
geo.tz:Asia/Jerusalem
```

`geo.zipcode`

Zip or postal code associated with the IP.

Field type: WKEYWORD

Examples: 2000, 10115

`isp`

The name of the Internet Service Provider (ISP) that owns or operates the IP address from which the response was received.

This field reflects the organization responsible for routing and infrastructure, not necessarily the hosting company.

Field type: TTEXT

Examples:

Cloudflare
Hetzner Online
OVH SAS

Usage in queries:

Search for responses from a specific provider:
```
isp:"Hetzner Online"
```
Match major hosting companies or CDNs:
```
isp:(OVH OR "Digital Ocean" OR Amazon)
```

`jarm`

Contains JARM fingerprint data for identifying TLS servers.

See the Ports & Protocols article for details on JARM fingerprints

Field type: TTEXT

Usage in queries:

jarm:2ad2ad0002ad2ad00042d42d00042d01a05e5e7e28522d5dc83e0500c983cf

`tag`

Responses are tagged when the software type can be identified from the host's response.

If a version is detected, it is stored in the tag.<tag_name>.version field.

Field type: OBJECT

Usage in queries:

Searching for specific software:
```
tag.nginx:*
```
Tag search using version:
```
tag.nginx.version:<1.18
```
Tag search using version range:
```
tag.nginx.version:[1.15 TO 1.18]
```

`tag.category`

The category of the software.

Tags are grouped into categories. Use this facet search query to view all available categories.

Field type: TTEXT

Examples:

Web servers
CDN
Reverse proxies
Operating systems
Mail server

Usage in queries:

tag.category:"Mail server"

`tag.name`

The name of the detected software.

You can construct search queries in two equivalent ways:

tag.some_tag:*
tag.name:some_tag

Both approaches return the same results.

Field type: TTEXT

Usage in queries:

Search for Nginx servers by tag.name field:
```
tag.name:nginx
```
Hosts that are highly likely honeypots:
```
tag.name:honeypot
```

`whois`

Data mapped from the IP WHOIS collection, reflecting ownership and registration details relevant at the time of the scan.

IP WHOIS Field Reference →

Field type: OBJECT

Protocols

A group of fields to store protocol-specific information, such as HTTP headers, FTP banner, and other application-level protocol-related data.

`amqp`

Advanced Message Queuing Protocol (AMQP) is an open standard application layer protocol used for message-oriented middleware.

AMQP enables systems to communicate using message queues with features such as reliability, routing, and security. It is widely used in enterprise systems, cloud-native applications, and IoT solutions where message delivery must be guaranteed even under failure conditions.

Field type: OBJECT

`amqp.banner`

The raw uparsed banner string returned by the AMQP server.

Field type: TTEXT

Examples:

Product: RabbitMQ\nVersion: 3.8.14\nPlatform: Erlang/OTP 26.2.5.9\nCapabilities:\nauthentication_failure_close: true\n...

`amqp.banner_sha256`

SHA-256 cryptographic hash of the banner string.

Field type: TTEXT

Examples:

fb6ae269a9e68f4dbfac7024504cb07a7b28440a170f10832f70d24d6a94705e

`amqp.capabilities`

Set of protocol features and extensions advertised by the AMQP broker during the handshake.

These capabilities determine how clients and servers can interact—for example, whether advanced message routing or acknowledgment features are available.

Field type: OBJECT

`amqp.platform`

The platform on which the AMQP broker is running.

This usually refers to the runtime environment and can be useful for identifying specific technology stacks or debugging compatibility issues.

Field type: TTEXT

Examples:

Erlang/OTP 23.2.6
Crystal 1.15.1

`amqp.product`

Name of the AMQP message broker software.

Common examples include RabbitMQ, which is widely used in microservices architectures. This field helps identify the specific implementation and is useful for fingerprinting.

Field type: TTEXT

Examples:

RabbitMQ
LavinMQ
Apache Qpid Broker-J Core
AMQProxy
amqpprox

`amqp.version`

The version number of the AMQP broker software.

Useful for assessing compatibility and identifying known vulnerabilities in specific versions.

Field type: TTEXT

Examples: 3.8.9

`dns`

Domain Name System (DNS) protocol metadata, extracted from services using UDP and TCP.

This object provides insight into DNS server identity, authority data, and capabilities.

Field type: OBJECT

`dns.authority.ns`

Primary authoritative name server for the DNS zone.

Field type: TTEXT

Examples:

ns1.example.com.
id.server.

`dns.authority.serial`

Serial number used by secondary DNS servers to detect changes to the zone.

Field type: #LONG

Examples: 2024010101, 0

`dns.authority.ttl`

Default Time-To-Live (in seconds) for records in the zone.

Field type: #LONG

Examples: 86400

`dns.banner`

Raw unparsed text banner returned by the DNS service.

Field type: TTEXT

Examples:

Software: 9.18.33-1~deb12u2-Debian\nAuthority:\nexpire: 604800\nmailbox: hostmaster.id.server.\nns: id.server.\nrefresh: 28800\n...

`dns.banner_sha256`

SHA-256 hash of the banner string.

Field type: TTEXT

Examples:

4d53f346abecb2945b16e6ef16f851f6462405a56aad470950c0cd1358bde9c3

`dns.contacts.email`

Administrator contact email extracted from DNS records in standard email format.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for servers exposing contact addresses:
```
dns.contacts.email:*
```

`dns.id_server`

Response from a CHAOS class TXT query to id.server, if available.

Field type: TTEXT

Examples:

id.server.example.com
localhost.localdomain

`dns.software`

Name and version of the DNS server software, when identified from the banner or other metadata.

Field type: TTEXT

Examples:

PowerDNS Authoritative Server 4.9.2 (built Feb 24 2025 16:51:00 by [email protected])
9.16.50-Debian
9.11.3-1ubuntu1.18-Ubuntu
dnsmasq-2.87
BIND

Usage in queries:

Find DNS servers running BIND software:
```
dns.software:BIND
```
Locate RedHat DNS servers:
```
dns.software:RedHat
```
Search for servers with a specific version string:
```
dns.software.keyword:*9.11.36*
```

`elasticsearch`

Elasticsearch is a RESTful distributed search and analytics engine.

This object includes metadata from publicly accessible Elasticsearch instances.

Field type: OBJECT

`elasticsearch.elastic_cluster`

Metadata extracted from the Elasticsearch Cluster State API (typically accessed via /_cluster/state).

This data reflects the state and configuration of the entire Elasticsearch cluster. The field structure is very similar to that of elastic_search_main.

Field type: OBJECT

`elasticsearch.elastic_search_main`

Metadata extracted from the root endpoint of the Elasticsearch service (accessed via /).

This endpoint reflects the default HTTP response of the Elasticsearch instance.

Field type: OBJECT

`elasticsearch.elastic_search_main.response_json.error.header.WWW-Authenticate`

Raw list of authentication challenges returned by the Elasticsearch instance. Useful for identifying which authentication mechanisms are enabled (e.g., Basic, Bearer, ApiKey).

Note that values can vary in format and may include realms or other metadata.

Field type: TTEXT

Examples:

Basic realm="security", charset="UTF-8"
Bearer realm="security"
ApiKey
Negotiate

`elasticsearch.elastic_search_main.response_json.version.build_flavor`

Build flavor, indicating the distribution type.

Field type: TTEXT

Examples: default, oss, unknown

`elasticsearch.elastic_search_main.response_json.version.build_snapshot`

Indicates if the build is a development snapshot.

Field type: BOOLEAN

Examples: True, False

`elasticsearch.elastic_search_main.response_json.version.build_type`

Type of packaging or distribution used.

Field type: TTEXT

Examples: docker, tar, deb, rpm, zip, unknown

`elasticsearch.elastic_search_main.response_json.version.lucene_version`

Version of Lucene used in the build.

Field type: TTEXT

Examples: 9.4.2, 8.10.1

`elasticsearch.elastic_search_main.response_json.version.number`

Reported Elasticsearch version number.

Field type: TTEXT

Examples: 7.17.9, 8.2.0

`elasticsearch.elastic_search_main.url`

URL used for scanning the root endpoint of the Elasticsearch service.

Field type: TTEXT

Examples:

https://195.60.239.19:9200/

`ftp`

File Transfer Protocol (FTP).

Metadata extracted from FTP services, including support for encrypted authentication and service identification.

Field type: OBJECT

`ftp.auth_ssl`

Indicates support for the AUTH SSL command, which allows the FTP session to switch to an encrypted channel using SSL. Presence of this field typically means the server advertises or accepts SSL-based authentication.

Field type: TTEXT

Examples:

431 Necessary security resource unavailable
500 AUTH not understood
502 SSL/TLS authentication not allowed

Usage in queries:

Find FTP servers that explicitly do not support AUTH SSL:
```
ftp.auth_ssl.keyword:/5[0-9]{2}.*/
```

`ftp.auth_tls`

Indicates support for the AUTH TLS command, enabling encrypted control and/or data channels using TLS. This is considered a more secure alternative to AUTH SSL.

Field type: TTEXT

Examples:

234 AUTH TLS successful
431 Necessary security resource unavailable
502 Explicit TLS authentication not allowed

Usage in queries:

Find FTP servers that explicitly do not support AUTH TLS:
```
ftp.auth_tls.keyword:/5[0-9]{2}.*/
```

`ftp.banner`

Raw FTP banner returned upon connection. Typically includes server software name and version.

Field type: TTEXT

Examples:

220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------\r\n220-You are user number 1 of 50 allowed.\r\n220-Local time is now 17:10....

`ftp.banner_sha256`

SHA-256 hash of the FTP banner text.

Field type: TTEXT

Examples:

12a239bc15df3c7f20ecfcb9e71e6ed7ed9d1b9ddadcf21efc897ba0b9e5ff5e

`ftp.contacts.email`

Email address extracted from FTP service messages, typically indicating the administrator or maintainer.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Find FTP serivces disclosing contact emails:
```
ftp.contacts.email:*
```

`http`

Hypertext Transfer Protocol.

Field type: OBJECT

`http.body`

The body content of the HTTP response as plain text.

Field type: TTEXT

Usage in queries:

Web pages with the word “atlassian” in the body section:
```
http.body:atlassian
```
Web pages with words “camera” and “online”:
```
http.body:(camera AND online)
```
Search for a phrase:
```
http.body:"admin panel"
```

Only full-text search is supported

Search for HTML tags or other special characters not available due to tokenization.

`http.body_sha256`

SHA-256 hash of the HTTP body.

Useful for searching exact the same static content across different hosts or services.

Field type: WKEYWORD

Examples:

3a7bd3e2360a3d4d9c65a857d1d7a8dd7a9e743dd73a7a5e

`http.contacts.address`

Physical address mentioned on the page or in meta tags.

Field type: TTEXT

Examples: CA, Mountain View, 1600 Amphitheatre Parkway

`http.contacts.email`

Contact email addresses found on the page or in meta tags.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for pages that contain email addresses:
```
http.contacts.email:*
```
Search for pages that contain specific email domain:
```
http.contacts.email:*@example.com
```

`http.contacts.geo`

Geographical coordinates found on the page or in meta tags.

Field type: OBJECT

`http.contacts.tel`

Phone numbers found on the page or in meta tags.

Field type: TTEXT

Examples: +1-800-123-4567

`http.content_length`

Length of HTTP body in bytes.

Field type: #DOUBLE

Examples: 548, -1

`http.description`

Page description from meta tags.

Field type: TTEXT

Examples:

Joomla!
This is a default index page for a new domain.
Web site created using create-react-app

Usage in queries:

http.description:3CX

http.description:"safe home for all your data"

http.description:"Login to your CyberPanel Account"

http.description:"Synology Router"

http.description:"Zimbra provides open source server and client software for messaging and collaboration"

`http.favicon.cert_md5`

MD5 hash of the favicon certificate.

Field type: TTEXT

Examples: d41d8cd98f00b204e9800998ecf8427e

`http.favicon.hash_sha256`

SHA-256 of favicon for exact searching.

Field type: TTEXT

Examples:

92c09ca740b0e18bfe82382f0adcb7a9d4b037fe7cc42f17b9cb2d84a5325124

Usage in queries:

Search for Synology DiskStation instances using favicon:

http.favicon.hash_sha256:92c09ca740b0e18bfe82382f0adcb7a9d4b037fe7cc42f17b9cb2d84a5325124

Search for Zimbra MX Server instances using favicon:

http.favicon.hash_sha256:1afd891aacc433e75265e3ddc9cb4fc63b88259977811384426c535037711637

Search for 3CX Webclient instances using favicon:

http.favicon.hash_sha256:b27e55c218d49ccc9399ae6b3302c339a445568411cadaf5d1cadd7e4c99bf74

`http.favicon.image`

Binary image content of favicon.

Field type: BINARY

`http.favicon.last_modified`

Favicon Last-Modified date.

Rarely used, but can be useful for identifying when the favicon was last updated, e.g. to identify product versions.

Field type: DATE

Examples: 2023-01-01T12:00:00Z

`http.favicon.last_updated`

Deprecated field. Use last_modified instead.

Field type: DATE

`http.favicon.perceptual_hash`

A hash representing the visual appearance of the favicon, used to identify similar icons by color and shape.

Learn more about Netlas perceptual hashes.

Field type: TTEXT

Examples: 187e76c7c3667e18

Usage in queries:

Search for pages with the exact same visual favicon:
```
http.favicon.perceptual_hash:187e76c7c3667e18
```
Use fuzzy matching to find visually similar favicons:
```
http.favicon.perceptual_hash:187e76c7c3667e18~1
```
Match favicons within a 6-byte similarity range:
```
http.favicon.perceptual_hash:187e76c7c3*
```

`http.favicon.uri`

Full URI of the favicon.

Field type: TTEXT

Examples:

https://example.com/favicon.ico

Usage in queries:

Hosts without "google" in uri that used Google's favicon:

http.favicon.uri:"https://www.google.com:443/favicon.ico" !uri:/.*google\..*/

`http.headers`

HTTP headers returned by the server.

This includes both standard and custom headers, which may reveal server software, caching behavior, content security policies, and other metadata.

Only the top 1,000 most commonly observed headers are indexed here. All others are stored in the http.unknown_headers field as key/value pairs.

Header name formatting

All dashes (-) in header names are replaced with underscores (_). For example, use http.headers.content_security_policy instead of http.headers.content-security-policy.

Field type: OBJECT

Usage in queries:

Find JSON API responses:

http.headers.content_type:"application/json"

Find responses served by NGINX:
```
http.headers.server:nginx
```
Find websites powered by PHP:
```
http.headers.x_powered_by:PHP*
```

`http.http_version.major`

Major version number of the HTTP protocol.

Field type: #LONG

Examples: 1, 2

`http.http_version.minor`

Minor version number of the HTTP protocol.

Field type: #LONG

Examples: 0, 1

`http.http_version.name`

Full HTTP protocol version string (e.g., 'HTTP/1.1').

Field type: TTEXT

Examples: HTTP/1.1, HTTP/2

`http.meta`

HTML <meta> tag content extracted from the response page.

Meta tags can include information about the page such as character encoding, viewport settings, description, keywords, and directives for search engines.

Field type: TTEXT

`http.status_code`

HTTP response status code returned by the server.

Field type: #SHORT

Examples: 200, 301, 404, 500

Usage in queries:

Find responses with a specific status code:
```
http.status_code:404
```
Find positive responses (2xx):
```
http.status_code:<300
```
Find responses with redirection status codes (3xx):
```
http.status_code:[301 TO 399]
```

`http.status_line`

HTTP status line returned by the server.

Field type: WKEYWORD

Examples:

200 OK
301 Moved Permanently
429 Too Many Requests
500 Internal Server Error
503 Service Temporarily Unavailable

`http.title`

Title of the HTML document, extracted from the <title> tag.

Field type: TTEXT

Examples:

Web Server's Default Page
Welcome to nginx!
Webmail Login

Usage in queries:

Find responses with a specific title:
```
http.title:"index of"
```
Find responses with a title containing a specific combination of words:
```
http.title:(Database Error)
```
Search for exact title matches:
```
http.title.keyword:"cPanel Login"
```

`http.tracker.facebook_pixel`

Facebook Pixel ID extracted from the page content.

Field type: TTEXT

Examples: 744013972422032

`http.tracker.google_analytics`

Google Analytics ID / Google Tag Manager ID extracted from the page content.

Field type: TTEXT

Examples: GTM-TFBK4FF, GT-CPM2DAP

`http.tracker.yandex_metrica`

Yandex Metrica ID extracted from the page content.

Field type: TTEXT

Examples: 51023681

`http.trailers`

HTTP trailers are headers sent after the message body, allowing for additional metadata to be included in the response.

These headers are not part of the standard HTTP/1.1 specification but are used by some servers and proxies.

Field type: OBJECT

`http.transfer_encoding`

Indicates the form of encoding used to safely transfer the response body.

Field type: WKEYWORD

Examples: chunked, gzip

`http.unknown_headers`

Non-standard or rarely used HTTP headers returned by the server.

These headers are not among the top 1,000 most frequent headers and are not stored in http.headers.

Field type: OBJECT

`http.unknown_headers.key`

The name of a non-standard or rarely used HTTP header returned by the server.

Header names are normalized by replacing dashes (-) with underscores (_).

Field type: TTEXT

Examples:

x_content_options
x_domain
x_sqsp_edge

Usage in queries:

Find responses where a specific unknown header was present:
```
http.unknown_headers.key:x_domain
```

`http.unknown_headers.value`

The value associated with a header listed in http.unknown_headers.key.

Used in combination with key to filter responses by specific unknown header values.

Field type: TTEXT

Usage in queries:

Find responses that returned a specific unknown header with a known value:

http.unknown_headers.key:cross_origin_opener_policy http.unknown_headers.value:same-origin

Find responses where an unknown header has any value:

http.unknown_headers.key:x_domain http.unknown_headers.value:*

`imap`

Internet Message Access Protocol (IMAP) allows email clients to retrieve messages from a mail server and manage mailboxes.

Metadata extracted from IMAP services, including their greeting banner and encryption capabilities.

Field type: OBJECT

`imap.banner`

The initial banner message returned by the IMAP server upon connection. It usually includes the server name, software type, and version.

Field type: TTEXT

Examples:

* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS ID ENABLE IDLE LITERAL+ STARTTLS AUTH=PLAIN] Dovecot DA ready.\r\n

`imap.banner_sha256`

SHA-256 hash of the banner text, used for fingerprinting the service.

Field type: TTEXT

Examples:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

`imap.contacts.email`

Email address extracted from IMAP banner, typically indicating the administrator or maintainer.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Find IMAP servers disclosing contact emails:
```
imap.contacts.email:*
```

`imap.starttls`

Server response to the STARTTLS command, indicating whether the server supports upgrading the connection to TLS encryption.

Field type: TTEXT

Examples:

a001 OK Begin TLS negotiation now.
a001 OK go ahead with TLS handshake STARTTLS completed

`memcached`

Memcached protocol for high-performance distributed memory caching.

Field type: OBJECT

`memcached.auth_cmds`

Total number of authentication commands received by the Memcached server.

Field type: TTEXT

Examples: 123

Usage in queries:

Filter servers that have handled authentication:
```
memcached.auth_cmds:>0
```

`memcached.banner`

Unparsed plain-text banner returned by the Memcached service.

Field type: TTEXT

Examples:

STAT pid 1\r\nSTAT uptime 5214850\r\nSTAT time 1742480385\r\nSTAT version 1.6.34\r\nSTAT libevent 2.1.12-stable\r\n...

`memcached.banner_sha256`

SHA-256 hash of the Memcached banner text.

Field type: TTEXT

Examples:

3e6a17f620184c87fbc345cba0a482eae3235290f83bbc25eb190cc1ba4ec1e8

`memcached.curr_connections`

Current number of open client connections.

Field type: TTEXT

Examples: 5

Usage in queries:

Find heavily used instances:

memcached.curr_connections.keyword:/[0-9]{3}.*/

`memcached.curr_items`

Number of items currently stored in the cache.

Field type: TTEXT

Examples: 857

Usage in queries:

Search for servers with active cache:
```
memcached.curr_items:>0
```

`memcached.log_watchers`

Number of active log watchers.

Field type: TTEXT

Examples: 0, 1, 3

Usage in queries:

Find servers currently monitored:
```
memcached.log_watchers:>0
```

`memcached.rejected_connections`

Connections rejected due to max client connection limit.

Field type: TTEXT

Examples: 0, 5

Usage in queries:

Detect overloaded servers:
```
memcached.rejected_connections:>0
```

`memcached.time`

Current server timestamp in seconds since epoch.

Field type: TTEXT

Examples:

1679990000

`memcached.total_connections`

Total number of client connections since startup.

Field type: TTEXT

Examples: 3, 7, 458196

Usage in queries:

Find high-traffic nodes:

memcached.total_connections.keyword:/[0-9]{4}.*/

`memcached.total_items`

Total number of items stored since the server started.

Field type: TTEXT

Examples: 320000

`memcached.uptime`

Time in seconds since the server was started.

Field type: TTEXT

Examples: 36000

`memcached.version`

Reported Memcached version.

Field type: TTEXT

Examples: 1.6.5, 1.5.22

Usage in queries:

Find servers running a specific version:
```
memcached.version:1.6.5
```

`modbus`

Modbus industrial protocol widely used in SCADA and automation systems.

This group of fields includes metadata extracted from Modbus TCP services.

Modbus Parser Notice

Some Modbus fields may be parsed incorrectly due to known issues. We're aware of them and will release fixes in future versions. Sorry for the inconvenience.

Field type: OBJECT

`modbus.banner`

Human-readable, decoded summary of the raw_response field.

Field type: TTEXT

Examples:

Length: 56\nFunction: 43\nMEIResponse:\nConformityLevel: 129\nMoreFollows: false\nObjectCount: 3\n

`modbus.banner_sha256`

SHA-256 hash of the Modbus banner.

Field type: TTEXT

Examples:

9c09ae1ff3e92259e9efb95a81b19a3e3e9d0e60b505c3b29b768b66020d0d6f

`modbus.exception_response`

A Modbus Exception Response indicates that the server (slave device) encountered an error while processing the request.

Exception responses are part of normal Modbus behavior and help identify unsupported operations or configuration issues on devices. See the Modbus Application Protocol Specification (Section 7) for the full list of exception codes and their meanings.

Field type: OBJECT

`modbus.function_code`

Function code used in the request.

Netlas is always requesting 43 (0x2B): Standard request for Device Identification using the MEI mechanism.

Field type: #LONG

Examples: 43

`modbus.mei_response`

The Modbus Encapsulated Interface (MEI) response returned by the device when queried using function code 43 (0x2B) with MEI type 0x0E.

This response provides Device Identification information such as vendor name, product code, firmware version, and other metadata.

Field type: OBJECT

`modbus.mei_response.conformity_level`

Indicates the device's support level for the Modbus Device Identification (MEI type 0x0E) standard.

Higher levels support more detailed device metadata:

1: Basic (vendor, product, version)
2: Regular (adds more standard fields)
3: Extended (adds vendor-specific fields)

This helps determine how much identifying information the device is willing to expose.

Field type: #LONG

Examples: 1, 2, 3

Usage in queries:

Find devices that support extended device identification:
```
modbus.mei_response.conformity_level:3
```

`modbus.mei_response.objects`

A collection of identification objects returned by the device in response to a Modbus Device Identification request (Function Code 43, MEI Type 0x0E).

Each key represents a specific Object ID (OID) as defined in the Modbus Application Protocol Specification V1.1b3, Section 6.4. These fields contain device metadata such as vendor name, product code, version, and optionally serial numbers or other extended identifiers.

Field type: OBJECT

`modbus.mei_response.objects.product_code`

Product code returned by the device (Object ID 01) as defined in the Modbus Device Identification specification.

Field type: TTEXT

Examples:

BMX P34 2020
TWDLCAE40DRF
Smart Logger

Usage in queries:

Search for specific product lines:

modbus.mei_response.objects.product_code:XPort

`modbus.mei_response.objects.revision`

Device revision or firmware version string (Object ID 02) according to the Modbus Device Identification standard.

Field type: TTEXT

Examples: V1.0, V3.3.0.2GC, V2.8.1,2018-12-13

Usage in queries:

Filter by revision:

modbus.mei_response.objects.revision:"9.4.200210"

`modbus.mei_response.objects.vendor`

Vendor or manufacturer name (Object ID 00) as specified in the Modbus Device Identification specification.

Field type: TTEXT

Examples:

Schneider Electric
AB Regin
Delta Electronics, Inc.
ABB
HUAWEI

Usage in queries:

All devices from Schneider:

modbus.mei_response.objects.vendor:(Schneider Electric)

`modbus.raw`

Base64-encoded full Modbus TCP response received from the device.

This includes both the MBAP (Modbus Application Protocol) header and the Protocol Data Unit (PDU). It reflects the complete TCP payload sent by the device in reply to the scan request.

Field type: TTEXT

Examples:

WkcAAAApACsOAYEAAAMACUlOVkVOU1lTIAEJMDE1MF8wNDA3AgkwMjlDXzAwMDk=

`modbus.raw_response`

Base64-encoded Protocol Data Unit (PDU) extracted from the Modbus TCP response.

Unlike raw, this field excludes the MBAP header and contains only the function code and its associated payload (e.g., device identification objects or exception codes).

Field type: TTEXT

Examples:

DgGBAAADAAlJTlZFTlNZUyABCTAxNTBfMDQwNwIJMDI5Q18wMDA5

`mongodb`

MongoDB Protocol for document-based NoSQL databases.

Netlas captures metadata from exposed MongoDB instances, including build info, databases, and replication status, to aid in security assessments.

Field type: OBJECT

`mongodb.banner`

Raw banner data returned from the MongoDB server during probing.

Field type: TTEXT

Examples:

IsMaster:\nIsMaster: true\nReadOnly: false\nBuildInfo:\nVersion: 8.0.3\nGitVersion: 89d97f2744a2b9851ddfb51bdf22f6...

`mongodb.banner_sha256`

SHA-256 hash of the MongoDB banner.

Field type: TTEXT

Examples:

9f04b3c1c8f9ffea7e4e8eae418fe77e2d15c357df6fa18efc8a10deef07b234

`mongodb.build_info.build_environment.dist_arch`

Target distribution architecture.

Field type: TTEXT

Examples: aarch64, i386, x86_64, arm64, i686

`mongodb.build_info.build_environment.dist_mod`

Distribution module or variant.

Field type: TTEXT

Examples: ubuntu1204, debian10, rhel93

`mongodb.build_info.build_environment.target_os`

Target operating system.

Field type: TTEXT

Examples: linux, windows, macOS, freebsd

`mongodb.build_info.debug`

Whether the MongoDB binary was built in debug mode.

Field type: BOOLEAN

Examples: True

Usage in queries:

Debug builds may indicate testing environments:

mongodb.build_info.debug:true

`mongodb.build_info.sys_info`

System-level build info (hostname, CPU).

Field type: TTEXT

Examples:

Linux orlo 3.2.0-58-generic #88-Ubuntu SMP Tue Dec 3 17:37:58 UTC 2013 x86_64 BOOST_LIB_VERSION=1_54
FreeBSD 110amd64-quarterly-job-18 11.0-RELEASE-p7 FreeBSD 11.0-RELEASE-p7 amd64 BOOST_LIB_VERSION=1_49
windows sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1') BOOST_LIB_VERSION=1_49

Usage in queries:

Identify FreeBSD builds:
```
mongodb.build_info.sys_info:FreeBSD
```
Search by Boost library version to spot old toolchains:
```
mongodb.build_info.sys_info:"BOOST_LIB_VERSION=1_49"
```
Detect MongoDB instances built on ancient Linux kernels:
```
mongodb.build_info.sys_info:"2.6.18"
```

`mongodb.build_info.version`

MongoDB version.

Field type: TTEXT

Examples: 7.0.4-2, 7.0.6, 3.2.11, 4.4.25, 3.0.0-rc11

`mongodb.contacts.email`

Contact email address exposed by MongoDB server.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Detect exposed admin emails:
```
mongodb.contacts.email:*
```

`mongodb.databases.databases.empty`

Whether the database is empty.

Field type: BOOLEAN

Examples: False, True

`mongodb.databases.databases.name`

Name of a database exposed by the instance.

Field type: TTEXT

Examples: admin, rocketchat, CMSInstall

Usage in queries:

Detect ransomware-encrypted databases:

mongodb.databases.databases.name:*RECOVER_YOUR_DATA*

`mongodb.databases.total_size`

Total disk space used by all databases.

Field type: #LONG

Examples: 536870912

`mqtt`

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe protocol often used in IoT environments. It allows devices to communicate efficiently over low-bandwidth networks.

Field type: OBJECT

`mqtt.banner`

Raw banner message retrieved during MQTT handshake.

Field type: TTEXT

Examples:

�\u0003\u0000\u0001\u00001-\u0000\u0013$SYS/broker/versionmosquitto version 2.0.111\"\u0000\u0012$SYS/broker/uptime195895 seconds

`mqtt.banner_sha256`

SHA-256 hash of the banner.

Field type: TTEXT

Examples:

7d0e5d1d9dfe12015bb765d5f0e8fcd13c239fe70564bc182c2a19aa143bcbd9

`mqtt.contacts.email`

Email address advertised by the broker for contact.

Field type: WKEYWORD

Examples:

[email protected]

Usage in queries:

Detect brokers with exposed emails:
```
mqtt.contacts.email:*
```

`mqtt.topics.sys_broker_clients_connected`

Number of currently connected clients.

Field type: TTEXT

Examples: 12, 1778

Usage in queries:

Find brokers with active clients:

mqtt.topics.sys_broker_clients_connected:>0

`mqtt.topics.sys_broker_clients_disconnected`

Number of clients disconnected since start.

Field type: TTEXT

Examples: 449, 45984

`mqtt.topics.sys_broker_clients_maximum`

The maximum number of clients that have been connected to the broker at the same time.

Field type: TTEXT

Examples: 150, 25124

`mqtt.topics.sys_broker_clients_total`

The total number of active and inactive clients currently connected and registered on the broker.

Field type: TTEXT

Examples: 200, 2133287

`mqtt.topics.sys_broker_messages_received`

Total MQTT messages received.

Field type: TTEXT

Examples: 1353392

`mqtt.topics.sys_broker_messages_sent`

Total MQTT messages sent by broker.

Field type: TTEXT

Examples: 1291503

`mqtt.topics.sys_broker_subscriptions_count`

Active topic subscriptions on the broker.

Field type: TTEXT

Examples: 396, 47045

`mqtt.topics.sys_broker_time`

UNIX timestamp reported by the broker.

Field type: TTEXT

Examples: 1744247530

`mqtt.topics.sys_broker_timestamp`

Broker’s internal system time (human-readable).

Field type: TTEXT

Examples:

Tue, 18 Jun 2019 11:42:22 -0300
2023-03-07 23:05:03+0800
11/07/2017 0:03:18.53

`mqtt.topics.sys_broker_uptime`

Time since the broker was last restarted.

Field type: TTEXT

Examples: 1684745 seconds, 2014771 seconds

`mqtt.topics.sys_broker_version`

Version string of the MQTT broker software.

Field type: TTEXT

Examples:

mosquitto version 2.0.11
HBMQTT version 0.10.0
1.1.1

`mqtt.unknown_topics.key`

Name of a topic not covered by the known MQTT topic fields.

These are usually broker-specific or dynamically generated system topics.

Field type: TTEXT

Examples:

sys_broker_load_bytes_sent_15min
sys_broker_publish_messages_sent
sys_broker_heap_maximum

Usage in queries:

mqtt.unknown_topics.key:"sys_broker_load_bytes_sent_15min"

`mqtt.unknown_topics.value`

Reported value for the unknown topic.

Field type: TTEXT

Usage in queries:

mqtt.unknown_topics.key:"sys_notice_status_online" AND mqtt.unknown_topics.value:"online"

`mssql`

Microsoft SQL Server Protocol metadata observed from exposed MSSQL services during internet-wide scanning.

Field type: OBJECT

`mssql.banner`

Raw banner string received from the server. It often contains version information, protocol features, and system details.

Field type: TTEXT

Examples:

Version: 13.0.5865\nEncryptMode: 1\nTLSLog:\nHandshakeLog:\nClientHello:\nVersion: 771\nOcspStapling: true\nTicketSupported: false\n...

`mssql.banner_sha256`

SHA-256 hash of the banner field content.

Field type: TTEXT

Examples:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

`mssql.contacts.email`

Email address advertised by the server as a point of contact for administration or abuse reporting.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Discover servers disclosing contact emails:
```
mssql.contacts.email:*
```

`mssql.encrypt_mode`

Encryption mode advertised by the Microsoft SQL Server during the connection handshake.

ENCRYPT_OFF – encryption is disabled
ENCRYPT_ON – encryption is enabled but not required
ENCRYPT_REQ – encryption is required for all clients
ENCRYPT_NOT_SUP – server does not support encryption

Misconfigurations or outdated server setups may result in unencrypted communication, which poses a security risk.

Field type: TTEXT

Examples: ENCRYPT_OFF, ENCRYPT_ON, ENCRYPT_REQ, ENCRYPT_NOT_SUP

Usage in queries:

Filter servers based on encryption mode:
```
mssql.encrypt_mode:"ENCRYPT_OFF"
```

`mssql.version`

Parsed version string of the Microsoft SQL Server.

Field type: TTEXT

Examples:

15.0.2000
10.50.1600

`mysql`

MySQL Protocol is used by MySQL and MariaDB servers to handle database connections, queries, and responses.

Field type: OBJECT

`mysql.banner`

Raw banner string received from the server during initial handshake.

Field type: TTEXT

Examples:

ProtocolVersion: 10\nServerVersion: 8.0.19\nConnectionID: 104\nCharacterSet: 255\nStatusFlags:\nSERVER_STATUS_AUTOCOMMIT: true\n\n

`mysql.banner_sha256`

SHA-256 hash of the banner string.

Field type: TTEXT

Examples:

9d7cbbd0f196a14ab123d8cbd9c33b6f5f1dc7873ed07ef7d209f0e7be30d535

`mysql.capability_flags`

Set of capability flags reported by the MySQL server, indicating supported protocol features.

A flag is included only if the corresponding feature is supported. The value is always true.

Only security-related flags are documented. For the full list, see the MySQL Documentation.

Field type: OBJECT

`mysql.capability_flags.CLIENT_LOCAL_FILES`

Indicates that the server allows clients to use the LOAD DATA LOCAL INFILE command.

This command enables a client to upload a file from its local filesystem and insert its contents into a database table. In case of a successful SQL injection, an attacker may exploit this feature to read sensitive files from the client’s machine — for example, from a developer’s or administrator’s system.

Field type: BOOLEAN

Usage in queries:

Find servers that allow local file uploads:

mysql.capability_flags.CLIENT_LOCAL_FILES:true

`mysql.capability_flags.CLIENT_LONG_PASSWORD`

Server support the improved password authentication mechanism introduced in MySQL version 4.1.

Field type: BOOLEAN

Usage in queries:

Find servers that do not support the improved password authentication:

mysql:* !mysql.error_id:* !mysql.capability_flags.CLIENT_LONG_PASSWORD:true

`mysql.capability_flags.CLIENT_MULTI_STATEMENTS`

Server supports multiple statements in a single query.

With this flag enabled, successful SQL injection can lead to more severe impact (e.g., table deletion, data exfiltration, privilege escalation), because the attacker might be able to inject multiple statements, not just modify one.

Field type: BOOLEAN

Usage in queries:

Find servers that support multiple statements:

mysql.capability_flags.CLIENT_MULTI_STATEMENTS:true

`mysql.capability_flags.CLIENT_PLUGIN_AUTH`

Server supports plugin-based authentication, which is standard in modern MySQL.

If missing, the server likely supports only the old native password method or no authentication plugins at all.

Field type: BOOLEAN

Usage in queries:

Find servers that do not support plugin-based authentication:

mysql:* !mysql.error_id:* !mysql.capability_flags.CLIENT_PLUGIN_AUTH:*

`mysql.capability_flags.CLIENT_PLUGIN_AUTH_LEN_ENC_CLIENT_DATA`

Server supports length-encoded authentication data for plugins — a more flexible and secure method to pass authentication payloads.

Field type: BOOLEAN

`mysql.capability_flags.CLIENT_SECURE_CONNECTION`

Server requires secure challenge/response authentication, typically based on hashed passwords with a salt sent by the server.

If missing, passwords might be sent in plaintext or via weaker challenge schemes.

Field type: BOOLEAN

Usage in queries:

Find servers that do not require secure authentication:

mysql:* !mysql.error_id:* !mysql.capability_flags.CLIENT_SECURE_CONNECTION:*

`mysql.capability_flags.CLIENT_SSL`

Server supports SSL/TLS encryption for the entire session (not just authentication). Clients can use --ssl to encrypt traffic.

Field type: BOOLEAN

Usage in queries:

Find servers that do not support SSL/TLS encryption:

mysql:* !mysql.error_id:* !mysql.capability_flags.CLIENT_SSL:*

`mysql.error_code`

Numeric error code returned by the MySQL server during connection or handshake.

Field type: #LONG

Examples: 1130, 1129, 1040

`mysql.error_id`

Textual identifier of the MySQL error.

Only a small subset of errors typically occurs in scans, each with unique implications.

Field type: TTEXT

Examples:

ER_HOST_NOT_PRIVILEGED
ER_HOST_IS_BLOCKED
ER_CON_COUNT_ERROR
ER_CANT_CREATE_THREAD
ER_BAD_HOST_ERROR

Usage in queries:

Filter servers that actively block unauthorized IPs:
```
mysql.error_id:ER_HOST_NOT_PRIVILEGED
```

`mysql.server_version`

Version string advertised by the MySQL server.

Field type: TTEXT

Examples:

8.0.36
5.7.23-23
8.0.41-0ubuntu0.22.04.1
5.5.5-10.11.10-MariaDB
5.5.5-10.6.21-MariaDB-cll-lve

`mysql.status_flags`

Status flags returned by the MySQL server during handshake.

Full list available in the MySQL Internals Documentation.

Field type: OBJECT

`netbios`

NetBIOS is a legacy name resolution and service advertisement protocol in Windows-based LANs.

Although designed for local networks, misconfigured or legacy systems often expose NetBIOS to the internet. Netlas scans these services to extract metadata useful for asset identification, network mapping, and OSINT investigations.

Field type: OBJECT

`netbios.banner`

Raw NetBIOS banner data returned by the service. It may include system type, domain name, or role info.

Field type: TTEXT

Examples:

Mac: 00:00:00:00:00:00\nNames: [\"WDMYCLOUD\", \"WDMYCLOUD\", \"WDMYCLOUD\", \"__MSBROWSE__\", \"WORKGROUP\", \"WORKGROUP\"...

`netbios.banner_sha256`

SHA-256 hash of the banner field.

Field type: TTEXT

Examples:

9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

`netbios.mac`

MAC address of the device as reported via the NetBIOS protocol.

The first 3 bytes of the MAC address, known as the Organizationally Unique Identifier (OUI), indicate the vendor of the network interface. OUIs can be used to identify device type and purpose.

You can look up OUIs using the official IEEE registry or popular tools:

Field type: TTEXT

Examples: 00-14-22-01-23-45, B8-27-EB-12-34-56

Usage in queries:

Find VMWare devices, probably ESXi hosts or other VMs:
```
netbios.mac:"00:50:56"
```
Find Intel NICs, embedded boards, or other Intel devices:
```
netbios.mac:"F0:DE:F1"
```
Find Dell devices:
```
netbios.mac:"00-14-22"
```

`netbios.names`

A list of registered NetBIOS names for the host. These names may include machine name, domain, and service roles.

Field type: TTEXT

Examples: WORKGROUP, WDMYCLOUD, __MSBROWSE__

`ntp`

Network Time Protocol (NTP) is used to synchronize the clocks of systems over packet-switched, variable-latency data networks.

Netlas detects NTP servers by querying standard ports and parsing responses that include timestamps and metadata about the server's synchronization status.

Field type: OBJECT

`ntp.banner`

Raw NTP banner string.

Field type: TTEXT

Examples:

Version: 3\nTime:\nwall: 804701375\next: 63880744839\nTimeResponse:\nVersion: 3\nMode: 4\nStratum: 3\nPrecision: -23\nRootDelay:\nFraction: 4998\n

`ntp.banner_sha256`

SHA-256 hash of the banner string.

Field type: TTEXT

Examples:

5c6f2aee7c4b4f3bd8191d81fbb5a2641a6f4bcd5de6c26ebd1c191a6ec76c03

`ntp.time`

Human-readable server time as returned during the scan.

Field type: TTEXT

Examples: 2025-04-20 11:20:39.804701+00:00

`ntp.time_response.mode`

NTP mode. Helps infer the role of the host.

Value	Mode Name	Notes
1	Symmetric active	Used to initiate synchronization between two peers. Rare in scans.
2	Symmetric passive	Responds to mode 1; appears in peer configurations.
3	Client	Sent by clients requesting time.
4	Server	Most common in scans; response to mode 3 client requests.
5	Broadcast	Server periodically sends time to clients on LAN; rarely seen publicly.
6	Control (ntpq)	Used by monitoring tools to query stats; reveals detailed server info.

Field type: #LONG

`ntp.time_response.reference_id`

A 32-bit identifier representing the source of the NTP server’s time.

Its meaning depends on the ntp.time_response.stratum level:

Stratum 1: A 4-character ASCII string identifying the reference clock (e.g., GPS, LOCL, INIT).
Stratum ≥ 2: The IPv4 address of the upstream NTP server.
Some modern implementations may use non-standard formats (e.g., hashed values or vendor-specific encodings).

In Netlas, this field is base64-encoded to preserve its original 4-byte binary form.

Field type: TTEXT

Examples: SU5JVA==, f38BAA==, AAAAAA==

Usage in queries:

Find NTP servers using GPS as their reference clock:
```
ntp.time_response.reference_id:"R1BTAA=="
```
Find NTP servers using the ACTS (Automated Computer Time Service) service from NIST:
```
ntp.time_response.reference_id:"QUNUUw=="
```
Detect systems relying on LOCL (local unsynchronized clocks):
```
ntp.time_response.reference_id:"TE9DTA=="
```

`ntp.time_response.stratum`

Stratum level of the clock.

In the Network Time Protocol (NTP), the term "stratum" refers to the distance (in hops) from the reference clock — the original source of accurate time. It is a measure of how many layers or levels separate a device from the most accurate time source.

0 - unspecified
1 - primary source like GPS
2+ - secondary or downstream sources.
16 - unsynchronized/unknown

Field type: #LONG

`ntp.time_response.version`

NTP protocol version in use.

Field type: #LONG

Examples: 2, 3, 4

`ntp.version`

Depricated field. Use time_response.version instead.

Field type: #LONG

`oracle`

Oracle Database Protocol.

Handshake metadata and error responses captured from Oracle database servers using the TNS (Transparent Network Substrate) protocol.

Field type: OBJECT

`oracle.banner`

Banner text returned by the Oracle server during handshake.

Field type: TTEXT

Examples:

Handshake:\nAcceptVersion: 312\nGlobalServiceOptions:\nFULL_DUPLEX: true\nHEADER_CHECKSUM: true\n...

`oracle.banner_sha256`

SHA-256 hash of the Oracle server banner.

Field type: TTEXT

Examples:

2e682cd17779408d6b0f485aff797361531ce27c765b4397bb1863a576bc08c6

`oracle.handshake.accept_version`

Protocol version accepted by the Oracle server.

Field type: #LONG

Examples: 312, 0, 310

`oracle.handshake.connect_flags0`

Flags to indicate which features or services are required or desired by the client.

These boolean flags control aspects of session negotiation, such as required services, optional enhancements, or experimental capabilities. Some flags are well-documented, while others may be vendor-specific or reserved for internal use.

Field type: OBJECT

`oracle.handshake.global_service_options`

Set of service capability flags advertised by the Oracle server.

These options indicate support for features such as full-duplex communication and header integrity verification. Presence of these flags helps clients adjust their behavior based on the server's capabilities.

Field type: OBJECT

`oracle.handshake.nsn_service_versions.Authentication`

Negotiated versions of Oracle Authentication service.

Field type: TTEXT

Examples: 8.1.0.116.0, 11.2.0.3.0, 21.0.0.16.0

`oracle.handshake.nsn_service_versions.DataIntegrity`

Negotiated versions of Oracle DataIntegrity service.

Field type: TTEXT

Examples: 8.1.0.116.0, 11.2.0.3.0, 21.0.0.16.0

`oracle.handshake.nsn_service_versions.Encryption`

Negotiated versions of Oracle Encryption service.

Field type: TTEXT

Examples: 8.1.0.116.0, 11.2.0.3.0, 21.0.0.16.0

`oracle.handshake.nsn_service_versions.Supervisor`

Negotiated versions of Oracle Supervisor service.

Field type: TTEXT

Examples: 8.1.0.116.0, 11.2.0.3.0, 21.0.0.16.0

`oracle.handshake.refuse_error.key`

Parsed key-value refusal reason from Oracle server.

Field type: TTEXT

Examples:

DESCRIPTION.TMP
DESCRIPTION.ERRARGS
DESCRIPTION.ERROR_STACK.ERROR.ARGS
DESCRIPTION.ERROR_STACK.ERROR.BUF
DESCRIPTION.VSNNUM

`oracle.handshake.refuse_error.value`

Parsed key-value refusal reason from Oracle server.

Field type: TTEXT

Examples:

36716544
169870080
169870592
169870336
153092352

`oracle.handshake.refuse_error_raw`

Raw refusal error message returned by the server.

Field type: TTEXT

Examples:

(DESCRIPTION=(TMP=)(VSNNUM=169869568)(ERR=12514)(ERROR_STACK=(ERROR=(CODE=12514)(EMFI=4))))

`oracle.handshake.refuse_version`

Protocol version mentioned in the refusal packet.

Field type: TTEXT

Examples: 8.1.0.116.0, 10.1.0.4.2, 11.1.0.7.0

`pop3`

Post Office Protocol version 3 (POP3) is a standard email protocol used to retrieve emails from a remote server over a TCP/IP connection.

Field type: OBJECT

`pop3.banner`

Raw banner string returned by the POP3 service when a connection is initiated.

Field type: TTEXT

Examples:

+OK Dovecot ready.\r\n
+OK Hello there.\r\n
+OK POP3 server ready <1ec031.49e16.68042e61.e76O0ftzZtI/[email protected]\r\n

Usage in queries:

Search for specific mail server software:
```
pop3.banner:"Dovecot"
```

`pop3.banner_sha256`

SHA-256 hash of the banner, used for fingerprinting server implementations.

Field type: TTEXT

Examples:

f1d2d2f924e986ac86fdf7b36c94bcdf32beec15c19f6c7c2b5ef3e6d91a1c6b

`pop3.contacts.email`

Contact email address advertised by the POP3 server, if available.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for servers exposing contact addresses:
```
pop3.contacts.email:*
```

`pop3.starttls`

Indicates whether the server supports the STARTTLS extension for upgrading to a secure connection.

Field type: TTEXT

Examples:

+OK Begin TLS negotiation now.
+OK Begin SSL/TLS negotiation now.
+OK

Usage in queries:

Find servers that do not support STARTTLS:
```
!pop3.starttls:*
```

`postgres`

PostgreSQL Protocol — an open-source relational database system.

Field type: OBJECT

`postgres.banner`

Raw banner output from the PostgreSQL server, often including TLS handshake logs.

Field type: TTEXT

Examples:

TLSLog:\nHandshakeLog:\nClientHello:\nVersion: 771\nOcspStapling: true\nTicketSupported: false\nSecureRenegotiation: true\nHeartbeatSupported: false\n

`postgres.banner_sha256`

SHA-256 hash of the banner field.

Field type: TTEXT

Examples:

ee184c08385cecc945298e9bb95f3c9beeb1e2566ced92f3d17494dca9be9796

`postgres.contacts.email`

Email address advertised by the server, typically belonging to the administrator or a designated contact.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Find PostgreSQL servers exposing contact emails:
```
postgres.contacts.email:*
```

`postgres.is_ssl`

Indicates whether the PostgreSQL server supports SSL encryption.

Field type: BOOLEAN

Examples: True, False

Usage in queries:

Find PostgreSQL servers that accept unencrypted connections:
```
postgres.is_ssl:false
```

`postgres.protocol_error`

Error messages generated during regular PostgreSQL protocol communication after the startup phase.

Presented in most responses due to the probing method used. These typically indicate issues like authentication failure, access restrictions, or connection termination. Includes structured fields such as SQLSTATE error code, severity, message text, and internal routine name.

Field type: OBJECT

`postgres.startup_error`

Error messages returned during the initial startup phase of the PostgreSQL connection.

Presented in most responses due to the probing method used. The error structure may include fields such as hints, severity level, source file and line number, and other diagnostic metadata.

Field type: OBJECT

`postgres.supported_versions`

List of PostgreSQL protocol versions supported by the server.

When probed with an invalid protocol version (0), the server responds by advertising the versions it supports. The message may include messages in non-English (national) languages.

Field type: TTEXT

Examples:

FATAL: unsupported frontend protocol 0.0: server supports 1.0 to 3.0
FATAL: フロントエンドプロトコル0.0をサポートしていません: サーバは1.0から 3.0までをサポートします
ВАЖНО: неподдерживаемый протокол клиентского приложения 0.0; сервер поддерживает 2.0 - 3.0

`raw_tcp`

Fallback protocol used when the application-layer protocol cannot be identified during scanning.

This includes cases where:

The response does not match any known protocol patterns.
The protocol parser fails to interpret the data for various reasons.
The server responds in a non-standard or malformed way.

Field type: OBJECT

`raw_tcp.banner`

Textual content extracted from the raw TCP response.

Field type: TTEXT

Examples:

HTTP/1.1 400 Bad Request\r\nSec-WebSocket-Version: 13\r\n\r\n0
220 mail.example.com ESMTP \\Postfix (mail)\r\n
ERROR\nERROR\n

`raw_tcp.banner_sha256`

SHA-256 hash of the banner field.

Field type: TTEXT

Examples:

a3c1e1a0b3f2396fd0248db515cb95c0d20638b182dd21919d0b234d1cda3dfb

`raw_tcp.contacts.email`

Email address extracted from the response content.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Find servers exposing contact emails:
```
raw_tcp.contacts.email:*
```

`raw_tcp.length`

Length of the raw TCP response in bytes.

Field type: #LONG

Examples: 42

Usage in queries:

Find servers with responses longer than 1000 bytes:
```
raw_tcp.length:[40 TO 60]
```

`rdp`

Remote Desktop Protocol used for remote access to Windows desktops and servers.

Netlas extracts metadata from the RDP handshake, including NTLM security negotiation details and a screenshot of the remote desktop login screen, where available.

Field type: OBJECT

`rdp.image`

Screenshot (as a Base64-encoded or hosted image link) of the captured RDP login interface. May show system banners, usernames, or background images.

This field is not directly searchable, but textual content is extracted from the image using OCR (Optical Character Recognition) and stored in the text field.

The image is stored as a Base64-encoded string.

Field type: TTEXT

`rdp.ntlm_info`

Metadata extracted during NTLM authentication negotiation as part of the RDP handshake.

Field type: OBJECT

`rdp.ntlm_info.dns_computer_name`

Name of the target computer as reported during NTLM negotiation.

Field type: TTEXT

Examples: WIN-BUNS25TD77J, DESKTOP-A99NG6G, Windows

`rdp.ntlm_info.dns_domain_name`

Active Directory domain name (DNS format) to which the RDP host belongs.

Field type: TTEXT

Examples: WIN-BUNS25TD77J, DESKTOP-A99NG6G, Windows

`rdp.ntlm_info.dns_tree_name`

Root of the DNS namespace (domain tree) of the Active Directory forest.

Field type: TTEXT

Examples: example.com, example.local

`rdp.ntlm_info.netbios_computer_name`

Legacy NetBIOS name of the computer. Often used in older internal Windows environments and can aid in lateral movement mapping.

Field type: TTEXT

Examples: WIN-BUNS25TD77J, DESKTOP-A99NG6G, WINDOWS

`rdp.ntlm_info.netbios_domain_name`

NetBIOS name of the domain. Legacy domain identifier often still present in mixed or older Windows environments.

Field type: TTEXT

Examples: WIN-BUNS25TD77J, DESKTOP-A99NG6G, WINDOWS

`rdp.ntlm_info.product_version`

Windows OS version reported during NTLM authentication as part of the RDP handshake.

Version Range	OS Family / Codename	Type
10.0.25346–27823	Windows 11 / Server Insider	Desktop/Server
10.0.23475–26392	Windows 11 Insider Preview	Desktop
10.0.22631	Windows 11 Version 23H2	Desktop
10.0.22621	Windows 11 Version 22H2	Desktop
10.0.22000	Windows 11 Version 21H2	Desktop
10.0.20317–20348	Windows Server 2022	Server
10.0.19033–19041	Windows 10 Version 2004 / 20H1	Desktop
10.0.18342–18363	Windows 10 Version 1903–1909	Desktop
10.0.17763	Windows Server 2019	Server
10.0.17133–17134	Windows 10 Version 1803	Desktop
10.0.15063–16299	Windows 10 Version 1703–1709	Desktop
10.0.14393	Windows Server 2016	Server
6.3.9600	Windows 8.1 / Server 2012 R2	Server
6.2.9200	Windows 8 / Server 2012	Desktop/Server
6.2.3790	Windows Server 2003	Server
6.1.7601	Windows 7 SP1 / Server 2008 R2 SP1	Desktop/Server

Field type: TTEXT

Examples: 10.0.20348, 10.0.14393, 6.3.9600

Usage in queries:

Find outdated Windows Server 2012 R2 systems:
```
rdp.ntlm_info.product_version:"6.3.9600"
```

Find RDP hosts running Windows Server 2022:

rdp.ntlm_info.product_version:"10.0.20348"

`rdp.ntlm_info.target_name`

Identifier of the target system in the NTLM challenge, typically matching the domain or host name.

Field type: TTEXT

`rdp.text`

Raw or parsed text extracted from the RDP screen using OCR (Optical Character Recognition). Includes visible usernames, system banners, and any readable text shown on the captured RDP interface.

Field type: TTEXT

Examples:

= =/ Windows Server2008 Standard er = 已登录 administrator 下 = हब

`redis`

Redis Protocol for in-memory data structure storage and caching.

Metadata extracted from Redis servers during PING/INFO/CONFIG command probing.

Field type: OBJECT

`redis.banner`

Raw banner string returned by the Redis server upon connection.

Field type: TTEXT

Examples:

Commands: [\"PING\", \"INFO\", \"CONFIG GET *\", \"QUIT\"]\nPingResponse: (Error: NOAUTH Authentication required.)\n

`redis.banner_sha256`

SHA-256 hash of the Redis banner string.

Field type: TTEXT

Examples:

2c6ee24b09816a6f14f95d1698b24ead8e0e40b4c1a3d5f7e9c3f4a2b5c1e0a7

`redis.clients_info.blocked_clients`

Number of Redis clients blocked at the moment of the scan.

This includes clients blocked by the BLPOP, BRPOP, and BRPOPLPUSH commands. A high value may indicate performance issues, DoS attempts, or application misuse.

Field type: #LONG

Examples: 0, 4, 1136

`redis.clients_info.connected_clients`

Total number of client connections to the Redis server.

This includes normal clients and replicas. High values may suggest abuse, public exposure, or bot activity.

Field type: #LONG

Examples: 0, 7, 2802

Usage in queries:

Find Redis servers with a large number of connected clients:
```
redis.clients_info.connected_clients:>=1000
```

`redis.config_response`

Raw response to the Redis CONFIG GET * command.

May include sensitive server configuration such as bind, requirepass, and other security-critical settings.

Field type: TTEXT

Examples:

oom-score-adj-values\r\n0 200 800\r\nbind\r\n* -::*\r\nlatency-tracking\r\nyes\r\nmasterauth\r\n\r\n...
dbfilename\r\ndump.rdb\r\nrequirepass\r\n\r\nmasterauth\r\nwindows\r\nunixsocket\r\n\r\n...

`redis.persistence_info.aof_enabled`

Indicates whether Append Only File (AOF) persistence is enabled.

When AOF is enabled, every write operation the server receives is logged to disk, allowing a full replay of commands to restore the dataset after a crash. AOF disabled on publicly accessible Redis instances could be a misconfiguration signal — possibly a development/test setup unintentionally exposed to the internet.

A flag is included only if the corresponding feature is supported. The value is always true.

Field type: #LONG

Examples: True

Usage in queries:

Find Redis servers with AOF persistence disabled:
```
redis.persistence_info.aof_enabled:0
```

`redis.replication_info.role`

The replication role of the Redis server.

Master nodes are typically writable and present a larger attack surface if exposed.

Field type: TTEXT

Examples: master, slave, active-replica

Usage in queries:

Find Redis servers acting as master nodes:
```
redis.replication_info.role:master
```

`redis.server_info.arch_bits`

System architecture of the Redis process (32 or 64 bits).

Field type: TTEXT

Examples: 64, 32

`redis.server_info.os`

Operating system reported by the Redis server.

Field type: TTEXT

Examples:

Linux 5.15.0-1073-kvm x86_64
Linux 5.15.0-126-generic x86_64
Linux 6.6.72+ x86_64
Windows
Darwin 20.3.0 x86_64

Usage in queries:

Find Redis servers running on Windows operating systems:
```
redis.server_info.os:"Windows"
```

`redis.server_info.redis_mode`

Redis operational mode.

Field type: TTEXT

Examples: standalone, sentinel, cluster

`redis.server_info.tcp_port`

TCP port used by the Redis server to accept incoming connections.

Useful for identifying services on non-default ports (6379 is default).

Field type: #LONG

Examples: 6379, 16379, 26379

`redis.server_info.version`

Full Redis server version string.

Field type: TTEXT

Examples: 7.4.0, 6.0.16, 3.0.504

`s7`

S7 Protocol is used by Siemens PLCs (Programmable Logic Controllers) for industrial automation.

It enables structured communication between control systems and engineering software over industrial networks.

Responses include metadata extracted from the Siemens System Status List (SSL), obtained through a READ SZL (System-Zustands-Liste) request sent by Netlas scanners. This standard mechanism allows Netlas to collect internal identification and diagnostic information — such as hardware type, firmware version, module names, and serial numbers — from accessible devices for analysis and attribution.

Field type: OBJECT

`s7.banner`

Full unparsed banner from the S7 response. Often includes metadata structured as key-value pairs in plaintext.

Field type: TTEXT

Examples:

IsS7: true\nSystem: S7-1500 station_1\nModule: PLC1\nPlantId: \nCopyright: Original Siemens Equipment\n

`s7.banner_sha256`

SHA-256 hash of the banner field.

Field type: TTEXT

Examples:

c78bdc87219c77da7f29fe62bd1c280d9a8d93ca76a2df0a7fdd355f6d42e6aa

`s7.copyright`

Free-text or numeric copyright marker for the module or firmware.

Often contains the string "Original Siemens Equipment" or OEM-specific names. On some systems, numeric codes are returned instead of human-readable strings.

Field type: TTEXT

Examples:

Original Siemens Equipment
Original INSEVIS equipment
IBHsoftec GmbH
100194
22316

Usage in queries:

Search for Original Siemens Devices:

s7.copyright:"Original Siemens Equipment"

`s7.firmware`

Basic firmware identification – the firmware version of the module’s operating system.

Field type: TTEXT

Examples: 4.5.1, 4.1.3, 3.0.2

`s7.hardware`

Basic hardware identification – the hardware revision or version string of the CPU module.

Field type: TTEXT

Examples: 14.32.32, 10.32.32, 4.0.1

`s7.module`

Name of the PLC module as assigned in engineering software.

Often a descriptive label like "PLC_1" or the default module name. This is a user-defined field. May be blank or equivalent to the module_type field.

Field type: TTEXT

Examples:

CPU 315-2 PN/DP
IM151-8 PN/DP CPU
Energy, Water, Climate C
Pump Control Unit
PLC

`s7.module_id`

Identification of the module – Siemens catalog/order number (MLFB) of the device. Uniquely identifies the hardware type and variant.

Field type: TTEXT

Examples:

6ES7 214-1HG40-0XB0
6ES7 215-1AG40-0XB0
6ES7 315-2AH14-0AB0
6FC5 317-2FK14-0AB0
6NH7 800-4BA00

Usage in queries:

Find SIMATIC S7-1200 Devices:
```
s7.module_id:"6ES7215-1AG40-0XB0"
```

`s7.module_type`

Module type name – the human-readable type designation of the module.

This field provides the official name of the CPU model.

Field type: TTEXT

Examples:

CPU 315-2 PN/DP
CPU 313C
CPU 1510SP-1 PN
IM151-8 PN/DP CPU
IM151-8F PN/DP CPU

`s7.plant_id`

Plant designation of the module – user-assigned identifier for the plant, system, or project associated with the module.

Field type: TTEXT

Examples: Example Factory, Water Service, ACME Inc.

`s7.reserved_for_os`

Not standardized operating system reserved metadata field.

May carry Siemens internal codes or memory card identifiers. Siemens documentation indicates this slot is set aside for system use and typically has no user-readable information.

Field type: TTEXT

Examples: MMC 267FF11F, SMC_b5db2dd80c, SD 34657213

`s7.system`

Name of the automation system or PLC station as configured by the user.

Field type: TTEXT

Examples: S7_Turbine, Central Pump, PRODUCTION S7-1200

`smb`

Server Message Block (SMB) is a protocol for network file, printer, and resource sharing primarily used in Windows environments.

The data is extracted during SMB protocol negotiation and NTLM authentication phases.

SMB Parser Notice

Some SMB fields may be parsed incorrectly due to known issues. We're aware of them and will release fixes in future versions. Sorry for the inconvenience.

Field type: OBJECT

`smb.banner`

Raw banner text returned by the SMB service during initial connection.

Field type: TTEXT

Examples:

SupportV1: false\nVersion:\nMajor: 2\nMinor: 1\nVerString: SMB 2.1\nCapabilities:\nDFSSupport: true\nLeasing: true\nLargeMTU: true\n

`smb.banner_sha256`

SHA-256 hash of the banner field.

Field type: TTEXT

Examples:

2c6ee24b09816a6f14f95d1698b24ead8e0e40b4c1a3d5f7e9c3f4a2b5c1e0a7

`smb.has_ntlm`

Indicates whether the server supports or advertises NTLM (NT LAN Manager) authentication.

NTLM is considered less secure than Kerberos; its presence may indicate legacy configuration.

Field type: BOOLEAN

Examples: True, False

`smb.negotiation_log.authentication_types`

Authentication types supported by the server.

This field includes Object Identifiers (OIDs) representing the authentication mechanisms.

OID	Name
1.3.6.1.4.1.311.2.2.10	Microsoft NTLM
1.3.6.1.4.1.311.2.2.30	Microsoft NEGOEX
1.2.840.48018.1.2.2	Microsoft Kerberos V5
1.2.840.113554.1.2.2	Kerberos V5 GSS-API Mechanism
1.2.840.113554.1.2.2.3	Kerberos V5 User-to-User
1.2.752.43.14.3	Stockholm University Mechanism
1.3.6.1.5.2.5	Kerberos V5 User-to-User
1.3.6.1.5.5.14	SASL EXTERNAL
1.3.5.1.5.2	Kerberos V5 (Alternate OID)

Field type: TTEXT

Examples:

1.3.6.1.4.1.311.2.2.10
1.3.6.1.4.1.311.2.2.30
1.2.840.48018.1.2.2

Usage in queries:

Find servers supporting NTLM authentication:

smb.negotiation_log.authentication_types:"1.3.6.1.4.1.311.2.2.10"

`smb.negotiation_log.command`

SMB2 command identifier included in the server's response header.

This field echoes the original request's command code. Since Netlas only processes negotiation responses, this field will always be 0 — representing the SMB2_NEGOTIATE command.

Field type: #LONG

Examples: 0

`smb.negotiation_log.dialect_revision`

The dialect revision selected by the server during SMB negotiation.

Dialect revisions correspond to SMB protocol versions. Values include:

514 (0x0202): SMB 2.0.2, first Windows Vista version
528 (0x0210): SMB 2.1, introduced in Windows 7 / Server 2008 R2
65535 (0xFFFF): No dialect accepted — the server refused all versions offered.

Field type: #LONG

Examples: 514, 528, 65535

Usage in queries:

Find servers supporting older SMB dialects:

smb.negotiation_log.dialect_revision:{0 TO 528}

`smb.negotiation_log.protocol_id`

Protocol identifier included in the server's response header.

The ProtocolId field is a 4-byte magic constant at the start of every SMB2 packet. This field is always 0x424D53FE (or 0xFE534D42 in little-endian format) for SMB protocol. This means "\xFE" + "SMB" in ASCII.

Field type: TTEXT

Examples: AAAAAP5TTUI=

`smb.negotiation_log.status`

NTSTATUS code returned by the server in the SMB NEGOTIATE response.

0 means STATUS_SUCCESS, indicating the request was accepted and processed.
Non-zero values (not typically seen in Netlas) would represent various failure states (e.g., unsupported dialects or security mismatches).

Field type: #LONG

Examples: 0

`smb.smb_version.version_string`

Human-readable SMB version string extracted from server response. Typically used for display or simple filtering.

Field type: TTEXT

Examples: SMB 1.0, SMB 2.0.2, SMB 2.1

`smb.smbv1_support`

Indicates whether the server supports the deprecated SMBv1 protocol.

SMBv1 is insecure and vulnerable to numerous well-known exploits, including EternalBlue (used in WannaCry). Public-facing SMBv1 support is a strong misconfiguration signal and should be considered a security risk.

Field type: BOOLEAN

Examples: True, False

Usage in queries:

Find servers supporting SMBv1:
```
smb.smbv1_support:true
```

`smtp`

Simple Mail Transfer Protocol (SMTP) is a protocol used for sending emails across IP networks.

Netlas extracts metadata from the SMTP banner and responses to EHLO, HELO, and STARTTLS commands.

Field type: OBJECT

`smtp.banner`

Raw banner string returned by the SMTP service when a connection is initiated.

Field type: TTEXT

Examples:

220 undefined ESMTP Sendinblue SMTP 2.0
220 localhost ESMTP Postfix
421 Too many concurrent SMTP connections; please try again later.

Usage in queries:

Search for specific SMTP server software:
```
smtp.banner:"Sendinblue"
```

`smtp.banner_sha256`

SHA-256 hash of the SMTP banner.

Field type: TTEXT

Examples:

3f786850e387550fdab836ed7e6dc881de23001b70f7a1a1f87f1f0a2ddc9394

`smtp.contacts.email`

Contact email address advertised by the SMTP server, if included in the service banner or message.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for SMTP servers exposing contact addresses:
```
smtp.contacts.email:*
```

`smtp.implicit_tls`

Indicates whether the SMTP server is using implicit TLS from the start of the connection.

A flag is included only if the corresponding feature is supported. The value is always true.

Field type: BOOLEAN

Examples: True

Usage in queries:

Find servers using implicit TLS:
```
smtp:* !smtp.implicit_tls:true
```

`smtp.starttls`

Response string indicating support for the STARTTLS command, which upgrades a plaintext connection to TLS.

Field type: TTEXT

Examples:

220 2.0.0 Ready to start TLS
503 STARTTLS command used when not advertised
502 5.5.1 command not supported in "STARTTLS"

Usage in queries:

Find servers that do not support STARTTLS:
```
smtp.starttls:502*
```

`snmp`

Simple Network Management Protocol used for monitoring and managing network devices.

Netlas scanners use unauthenticated SNMP requests (typically with the public community string) to collect basic metadata exposed by misconfigured or publicly accessible devices. This includes system name, contact info, description, uptime, and location.

Field type: OBJECT

`snmp.banner`

Raw SNMP banner assembled from the device’s response.

Field type: TTEXT

Examples:

Name: Maxio\nUptime: 363074\nContact: Router\nDescription: Linux compu...
Name: mkr01.mochatest.lab\nUptime: 2238687500\nLocation: lab rack 12\nContact: Admin

`snmp.banner_sha256`

SHA-256 hash of the SNMP banner.

Field type: TTEXT

Examples:

2c6ee24b09816a6f14f95d1698b24ead8e0e40b4c1a3d5f7e9c3f4a2b5c1e0a7

`snmp.contact`

Raw value of the sysContact field.

Can include names, email addresses, timestamps, or mixed content. Sometimes unstructured.

Field type: TTEXT

Examples:

1691454203.6651886
Azure Cloud Switch vteam <[email protected]>
ACME Communication Technology Co., Ltd.

`snmp.contacts.email`

Parsed email address extracted from sysContact when present.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for a specific domain used in SNMP contacts:
```
snmp.contacts.email.keyword:*@example.com
```
Search for devices exposing contact addresses:
```
snmp.contacts.email:*
```

`snmp.description`

Device or system description (sysDescr), typically includes OS name, version, and hardware or software details.

Field type: TTEXT

Examples:

RouterOS RB450G
Linux compu-2.30 3.18.29 mips
DGS-3000-10L Gigabit Ethernet Switch
HP ETHERNET MULTI-ENVIRONMENT,SN:CNBRQCT53Q,FN:0891W4J,SVCID:10127,PID:HP Color LaserJet MFP M283fdn
Cisco IOS Software, ASR1000 Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.5(3)S1a, RELEASE SOFTWARE (fc1)\r\nTechnical Support: http://www.cisco.com/techsupport\r\nCopyright (c) 1986-2015 by Cisco Systems, Inc.\r\nCompiled Wed 04-Nov-15 13:58 by mcpre

Usage in queries:

Search for RouterOS devices (probably MikroTik):
```
snmp.description:"RouterOS"
```
Search for Brother printers and MFPs:
```
snmp.description:"Brother NC"
```
Search for IP Cameras:
```
snmp.description:"IP Camera"
```

`snmp.error`

Error string if SNMP failed to retrieve data from the device.

Field type: TTEXT

Examples:

unknown username
unknown security level
unknown engine id

`snmp.is_public`

If true, the device responded with readable information without requiring authentication.
If false, the response may contain an error field instead, indicating access was denied or restricted.

Field type: BOOLEAN

Examples: True, False

Usage in queries:

Find devices with public SNMP access:
```
snmp.is_public:true
```
Find devices with restricted SNMP access:
```
snmp.is_public:false
```

`snmp.location`

Device location field from sysLocation.

Often describes the physical rack, room, or site. Sometimes includes GPS or city names.

Field type: TTEXT

Examples:

Hangzhou, China
Jakarta [-6.25393,106.82967]
Server Room

`snmp.name`

Hostname of the device from sysName.

Commonly used for internal network identification. This field may be blank or equivalent to the description field.

Field type: TTEXT

Examples:

MikroTik
Innbox G2400 Series Gateway
Cellular Router
Gateway2
Corporate-Router

`socks`

SOCKS5 is a proxy protocol that routes network packets between a client and server through a proxy server.

Netlas scanners detect SOCKS proxy services and enumerate supported authentication methods to identify open, potentially misconfigured or abused proxy endpoints.

Field type: OBJECT

`socks.auth_type`

List of authentication methods supported by the SOCKS5 proxy.

Netlas performs multiple SOCKS5 handshake probes to the proxy server, each time offering a different set of authentication methods. Through repeated probing, it infers the full set of authentication mechanisms supported by the server.

Authentication methods are represented by an 8-bit identifier, with each value corresponding to a specific authentication mechanism.

Value in `auth_type`	Hex	Reference	Characteristic
No authentication	`0x00`	RFC 1928	No credentials required; insecure; often abused for anonymous proxying.
GSSAPI	`0x01`	RFC 1961	Strong authentication; supports Kerberos; used in enterprise environments.
Username/password	`0x02`	RFC 1929	Simple credential-based authentication. Credentials are sent in plaintext and are vulnerable to interception.
Challenge-Handshake Authentication Protocol	`0x03`	IANA	Legacy challenge-response method; more secure than plaintext, but outdated.
Unassigned	`0x04`	IANA	Reserved/undefined; may indicate misconfiguration or unsupported method.
Challenge-Response Authentication Method	`0x05`	IANA	Generic challenge-response; implementation-specific; unclear security guarantees.
Secure Sockets Layer	`0x06`	IANA	SSL/TLS-based authentication; provides encryption and identity verification.
NDS Authentication	`0x07`	IANA	Novell Directory Services; legacy enterprise authentication method.
Multi-Authentication Framework	`0x08`	IANA	Flexible negotiation between multiple authentication types.
JSON Parameter Block	`0x09`	IANA	Modern method using structured JSON; allows extensible authentication parameters.

Field type: TTEXT

Examples: No authentication, Username/password, GSSAPI

Usage in queries:

Find open SOCKS proxies with no authentication:
```
socks.auth_type:"No authentication"
```

Detect proxies supporting weak or legacy authentication:

socks.auth_type.keyword:/(Username|Challenge|Unassigned).*/

`socks.banner`

Raw list of advertised SOCKS5 authentication methods returned during handshake.

Field type: TTEXT

Examples:

AuthType: ["Challenge-Response Authentication Method", "No authentication"]
AuthType: ["", "", "", "Username/password", "", "", "No authentication"]

`socks.banner_sha256`

SHA-256 hash of the banner field. Used to group servers with identical authentication method responses for fingerprinting purposes.

Field type: TTEXT

Examples:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

`ssh`

Secure Shell (SSH) is a cryptographic network protocol used for secure remote login, command execution, and other secure network services over an unsecured network.

Netlas scanners initiate an SSH handshake and extract metadata about the server’s identity, supported cryptographic algorithms, authentication methods, and key exchange parameters. This information helps assess security posture and identify server software or misconfigurations.

Field type: OBJECT

`ssh.algorithm_selection.client_to_server_alg_group`

Algorithms used for traffic sent from the client to the server.

Field type: OBJECT

`ssh.algorithm_selection.client_to_server_alg_group.cipher`

Symmetric encryption algorithm used for traffic from client to server.

Field type: TTEXT

Examples: aes128-ctr, 3des-cbc, arcfour256

`ssh.algorithm_selection.client_to_server_alg_group.mac`

Message authentication code (MAC) algorithm ensuring data integrity from client to server.

Field type: TTEXT

Examples: [email protected], hmac-sha2-256, hmac-sha1

`ssh.algorithm_selection.dh_kex_algorithm`

Key exchange algorithm used during the SSH handshake.

Field type: TTEXT

Examples: curve25519-sha256, diffie-hellman-group14-sha1, ecdh-sha2-nistp256

`ssh.algorithm_selection.host_key_algorithm`

Algorithm used to sign the server's host key.

Field type: TTEXT

Examples: ecdsa-sha2-nistp256, ssh-rsa, rsa-sha2-512

`ssh.algorithm_selection.server_to_client_alg_group`

Cryptographic algorithms negotiated for traffic sent from the SSH server to the client.

Identical in structure and semantics to client_to_server_alg_group.

Field type: OBJECT

`ssh.banner`

The raw SSH banner string sent by the server upon initial connection.

Field type: TTEXT

Examples:

C\r\n############################\r\n# THIS SYSTEM IS PROVIDED FOR USE BY AUTHORIZED USERS ONLY. #\r\n...
Unauthorized access prohibited
Debian GNU/Linux 11

`ssh.contacts.email`

Self-reported contact information, if exposed during the SSH handshake or via banners.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for SSH servers exposing contact addresses:
```
ssh.contacts.email:*
```

`ssh.extensions`

Optional extensions advertised by the server, which signal support for non-standard or vendor-specific SSH features like ping@openssh or no-flow-control.

Field type: OBJECT

`ssh.key_exchange`

Detailed parameters observed during the SSH key exchange process, including public keys, Diffie-Hellman or elliptic curve parameters, server signatures, and host key data.

Field type: OBJECT

`ssh.server_id`

Parsed metadata from the SSH server banner, including software name, version number, and additional comment string if present.

Field type: OBJECT

`ssh.server_id.comment`

Optional comment string appended to the server's identification banner, often used to indicate the OS distribution or package version.

Field type: TTEXT

Examples:

Debian-2+deb12u5
Ubuntu-3ubuntu0.11
FreeBSD-20200214

`ssh.server_id.raw`

The full unprocessed SSH identification banner as sent by the server.

Field type: TTEXT

Examples:

SSH-2.0-OpenSSH_7.4
SSH-2.0-OpenSSH_8.9p1 Ubuntu-3ubuntu0.11
SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u5

`ssh.server_id.software`

The name and version of the SSH server software extracted from the banner.

Field type: TTEXT

Examples: OpenSSH_8.9p1, Cisco-1.25, AWS_SFTP_1.1

`ssh.server_id.version`

The SSH protocol version advertised by the server, typically 2.0.

Field type: TTEXT

Examples: 2.0, 1.99

`ssh.server_key_exchange`

Lists of algorithms proposed by the server during the SSH key exchange initiation, including supported key exchange methods, ciphers, compression algorithms, MACs, and languages.

Field type: OBJECT

`ssh.server_key_exchange.client_to_server_ciphers`

List of symmetric encryption algorithms proposed for data flowing from the client to the server.

Field type: TTEXT

Examples: aes128-ctr, aes256-ctr, [email protected]

`ssh.server_key_exchange.client_to_server_macs`

List of MAC (Message Authentication Code) algorithms proposed for verifying the integrity of client-to-server traffic.

Field type: TTEXT

Examples: hmac-sha2-256, hmac-sha1, [email protected]

`ssh.server_key_exchange.cookie`

A 16-byte random value included in the KEXINIT packet to guard against spoofing and replay attacks.

Field type: TTEXT

Examples: /zn8n78dSTAc3/pu+QXhnQ==

`ssh.server_key_exchange.host_key_algorithms`

List of server host key algorithms the server supports for authentication.

Field type: TTEXT

Examples: rsa-sha2-512, ecdsa-sha2-nistp256, ssh-ed25519

`ssh.server_key_exchange.kex_algorithms`

List of key exchange algorithms the server is willing to use to establish a secure session key.

Field type: TTEXT

Examples: curve25519-sha256, diffie-hellman-group14-sha256, ecdh-sha2-nistp384

`ssh.server_key_exchange.serverHaSSH`

HaSSH fingerprint generated from the server’s algorithm proposal list. Helps identify server configurations independently of keys.

Field type: TTEXT

Examples: 425d29fe50d8e4f5e37efb6e24bcf660

`ssh.server_key_exchange.server_to_client_ciphers`

List of symmetric encryption algorithms proposed for traffic from the server to the client.

Field type: TTEXT

Examples: aes128-ctr, aes256-ctr, [email protected]

`ssh.server_key_exchange.server_to_client_macs`

List of MAC algorithms proposed for verifying integrity of server-to-client data.

Field type: TTEXT

Examples: hmac-sha2-256, hmac-sha1, [email protected]

`ssh.userauth`

Authentication methods supported by the server, as advertised during the SSH handshake.

Method	Description	Reference
`publickey`	Authenticate using an asymmetric key pair	RFC 4252 §7
`password`	Authenticate using plain-text password	RFC 4252 §8
`keyboard-interactive`	Challenge-response, often used for OTP or 2FA	RFC 4256
`hostbased`	Trust based on the client machine’s SSH host key	RFC 4252 §9
`none`	Dummy method to query supported authentication methods	RFC 4252 §5.2
`gssapi-with-mic`	GSSAPI (e.g., Kerberos) authentication with MIC	RFC 4462 §3
`gssapi-keyex`	GSSAPI authentication during key exchange	RFC 4462 §2
`external-keyx`	External key exchange used in SSH Tectia (e.g., for smartcards, tokens)	SSH Tectia External Keys
`[email protected]`	Kerberos-based auth method from SSH Tectia	SSH Tectia Kerberos
`passticket`	IBM z/OS-specific method using one-time PassTickets	IBM PassTicket

Other nonstandard or vendor-specific userauth methods may occasionally appear, often reflecting proprietary extensions, experimental features, or server misconfigurations.

Field type: TTEXT

Examples: publickey, password, keyboard-interactive

Usage in queries:

Find SSH servers supporting password authentication:
```
ssh.userauth:"password"
```

`t3`

T3 Protocol, a proprietary protocol used by Oracle WebLogic Server for Java EE remote communication.

T3 facilitates client-server interactions for remote method invocation (RMI), JNDI, EJB, and object serialization. It's used internally for administration, deployment, and EJB invocation.

Exposure of T3 on the internet may signal misconfigured WebLogic servers, which have historically been targets of remote code execution (RCE) vulnerabilities.

Netlas extracts the T3 handshake banner returned by the WebLogic server when a T3 connection is established.

Field type: OBJECT

`t3.banner`

The banner field contains the full T3 handshake response returned by an Oracle WebLogic server.

Although Oracle does not publish the full T3 protocol specification, the structure and meaning of fields in the banner have been deduced through empirical analysis, penetration testing, and reverse engineering of WebLogic's behavior.

The T3 banner string contains space-separated key-value pairs:

Field	Description	Reference
HELO	Greeting and Version Identifier Format: `HELO:<version>.<patchFlag>`. The numeric part is the WebLogic version and the boolean part is a flag indicating whether a temporary patch is present on the server (`true` = patched, `false` = not patched). Example: `HELO:10.3.6.0.false`	Nmap Dev
AS	Abbreviation Size This is a numeric value (often 2048 in server responses) that defines the size of the abbreviation table used by the T3 protocol. T3 can compress or abbreviate repeated data (like class descriptors) in the RMI stream; the AS value indicates how many entries the abbreviation table can hold. Example: `AS:2048`	Nmap Dev
HL	Header Length This is a fixed numeric value indicating the length of the T3 protocol header in bytes. It is almost always `19` for WebLogic T3, meaning the protocol’s header is 19 bytes long. Example: `HL:19`	Nmap Dev
MS	Message Size This appears in newer WebLogic versions’ T3 handshake and denotes the maximum message size (in bytes) that the server is willing to accept for T3 requests. For example, `MS:10000000` indicates a 10,000,000-byte (~10 MB) message size limit. Other values like `5242880` (5 MB) or `300000000` have been observed, likely reflecting server configuration or version defaults. Example: `MS:10000000`	NeonPrimetime
PN	Partition Name Introduced in WebLogic 12c when multi-tenancy was added, this field indicates the name of the domain partition that the server is responding from. In most cases, if no specific partition is used, it defaults to `DOMAIN`. In a multi-tenant environment, this would carry the actual partition name. Example: `PN:DOMAIN`	SecurePulse, RSSing
LGIN	Login or Error Response Returned instead of `HELO` when the handshake is malformed or missing required fields. Signals that the server rejected the initial connection request. For instance, `LGIN:Invalid parameter` is returned by WebLogic when the initial handshake message from the client is malformed or missing required fields Example: `LGIN:Invalid parameter`	Nmap Dev

Field type: TTEXT

Examples:

HELO:14.1.1.0.false AS:2048 HL:19 MS:5242880 PN:DOMAIN
HELO:12.2.1.4.false AS:2048 HL:19 MS:10000000 PN:DOMAIN
HELO:10.3.6.0.false AS:2048 HL:19

Usage in queries:

Find exposed WebLogic instances running version 10.3.6.0:
```
t3.banner:"HELO:10.3.6.0"
```

`t3.banner_sha256`

SHA-256 hash of the banner value.

Field type: TTEXT

Examples:

2c6ee24b09816a6f14f95d1698b24ead8e0e40b4c1a3d5f7e9c3f4a2b5c1e0a7

`t3.length`

Length in bytes of the banner field.

Field type: #LONG

Examples: 57

`telnet`

Telnet is an application-layer protocol used to provide a bidirectional interactive text-based communication facility.

Telnet is considered deprecated and insecure due to its lack of encryption and susceptibility to interception and credential theft.

A full list of Telnet commands and option codes can be found in RFC 854 – Telnet Protocol Specification.

Field type: OBJECT

`telnet.banner`

The raw banner string returned by the Telnet server upon connection. Typically includes welcome messages, login prompts, or device information.

Field type: TTEXT

Examples:

Welcome Visiting Huawei Home Gateway\nCopyright by Huawei Technologies Co., Ltd.\n\nLogin:
Ubee Interactive Corporation Telnet Server\n\nWARNING: Access allowed by authorized users only.\n\nLogin:
\n\nUser Access Verification\n\nUsername:

`telnet.contacts.email`

Email address found in Telnet banner or connection metadata, often for administrative or support contact.

Field type: WKEYWORD

Examples: [email protected]

Usage in queries:

Search for Telnet servers exposing contact addresses:
```
telnet.contacts.email:*
```

`telnet.do`

Telnet options the server requested the client (Netlas scanner) to enable.

During handshake, the server sends DO <option> to ask Netlas to activate a specific Telnet feature. This reveals which capabilities the server expects the client to support.

Field type: OBJECT

`telnet.do.name`

Human-readable name of the Telnet option requested by the server.

Field type: TTEXT

Examples: Negotiate About Window Size, Echo, Remote Flow Control

`telnet.do.value`

Numeric code of the Telnet option requested by the server.

Field type: #LONG

Examples: 31, 1, 24

`telnet.dont`

Telnet options the server instructed the client (Netlas scanner) not to enable.

The server sends DONT <option> to explicitly refuse or deactivate specific Telnet features on the client side.

Field type: OBJECT

`telnet.dont.name`

Human-readable name of the Telnet option the server rejected.

Field type: TTEXT

Examples: Linemode, Echo, Remote Flow Control

`telnet.dont.value`

Numeric code of the Telnet option the server rejected.

Field type: #LONG

Examples: 34, 1, 24

`telnet.will`

Telnet options the server offered to enable itself.

A WILL <option> means the server announces it is capable of supporting and activating the specified option.

Field type: OBJECT

`telnet.will.name`

Human-readable name of the Telnet option the server offers to enable.

Field type: TTEXT

Examples: Suppress Go Ahead, Status, Terminal Type

`telnet.will.value`

Numeric code of the Telnet option the server offers to enable.

Field type: #LONG

Examples: 3, 5, 24

`telnet.wont`

Telnet options the server refused to enable.

The WONT <option> message tells the client that the server declines to activate the given feature.

Field type: OBJECT

`telnet.wont.name`

Human-readable name of the Telnet option the server declines to support.

Field type: TTEXT

Examples: Binary Transmission, Timing Mark, Authentication Option

`telnet.wont.value`

Numeric code of the Telnet option the server refuses to enable.

Field type: #LONG

Examples: 0, 6, 16

`vnc`

Virtual Network Computing (VNC) is a graphical desktop sharing protocol based on the Remote Framebuffer (RFB) protocol.

The VNC handshake process involves version negotiation followed by security type negotiation, where the server offers supported authentication methods. Netlas scanners extract the VNC handshake response, including the server's version and supported security types.

Field type: OBJECT

`vnc.banner`

Protocol version banner sent by the VNC server immediately after a TCP connection is established.

It follows the format RFB xxx.yyy\n, where xxx and yyy are version numbers indicating the highest supported RFB protocol version.

Field type: TTEXT

Examples: RFB 003.003\n, RFB 003.008\n

`vnc.banner_sha256`

SHA-256 hash of the raw banner string.

Field type: TTEXT

Examples:

2c6ee24b09816a6f14f95d1698b24ead8e0e40b4c1a3d5f7e9c3f4a2b5c1e0a7

`vnc.security_types`

A dictionary of supported VNC security types offered by the server during handshake.

The keys are numeric codes (as strings), and the values are textual identifiers where available. These codes represent authentication and encryption methods such as None, VNC Authentication, VeNCrypt, or vendor-specific mechanisms.

For RFB 3.7+ the server sends a list of supported types. In RFB 3.3, only a single security type is returned.

For a list of known VNC security types, refer to:

Field type: OBJECT

`vnc.version`

Parsed version number extracted from the banner field.

Typically represented as major.minor, e.g., 3.8 for RFB 003.008.

Field type: TTEXT

Examples: 3.3, 3.8

Usage in queries:

Find VNC servers running version 3.3:
```
vnc.version:3.3
```
Find VNC servers running version 3.8:
```
vnc.version:3.8
```

Service Fields

Various service fields that provide additional information about the document.

`@timestamp`

The timestamp when the document was indexed. This time is usually very close to the scan time, with only a few hours difference.

Field type: DATE

Examples:

2023-01-01T12:00:00Z
2024-10-15T08:30:00Z

Usage in queries:

@timestamp:>=now-30d

@timestamp:[now-7d TO now]

@timestamp:[2024-01-01 TO 2024-12-31]

`last_updated`

The timestamp indicating when the document was last updated. This field is no longer in use as a new index is created for each scan cycle.

Field type: DATE

`scan_date`

The timestamp indicating when the document was scanned. This field is deprecated and replaced by the @timestamp field.

Field type: DATE