Datenblatt

Network security metadata fields in Vectra AI

Verschaffen Sie sich mit den umfangreichen Metadaten der Vectra AI einen umfassenden Einblick in die Netzwerkaktivitäten und ermöglichen Sie so eine schnellere und genauere Erkennung von Bedrohungen.
Die wichtigsten Erkenntnisse:

  • Erkunden Sie den vollständigen Katalog der Metadatenfelder für Protokolle wie HTTP, DNS, SSL, SMB und andere.
  • Verstehen Sie, wie die einzigartigen Metadaten von Vectra AIAI die Erkennungs-, Untersuchungs- und Reaktionsabläufe bereichern.
  • Nutzen Sie standardisierte und benutzerdefinierte Attribute, um einen tieferen Netzwerkkontext aufzubauen und die Triage zu beschleunigen.

Network security metadata fields in Vectra AI
Sprache zum Herunterladen auswählen
Zugang
Datenblatt

This page provides a structured reference of network security metadata fields used across the Vectra AI Platform. It defines common schema attributes, session-layer connectivity fields, protocol-specific telemetry (DNS, HTTP, SMB, LDAP, etc.), authentication metadata (Kerberos, NTLM, RADIUS), detection-layer match attributes, and encrypted communication fingerprints (SSL/TLS, SSH, X.509). These normalized metadata streams enable behavioral analysis, cross-domain correlation, and encrypted traffic visibility without requiring full packet capture. Together, they form the foundation for scalable network observability and security investigation across hybrid enterprise environments.

These normalized metadata streams support threat hunting, metadata enrichment, and metadata forensics by enabling behavioral analysis, cross-domain correlation, and encrypted traffic visibility, without requiring full packet capture. Together, they form the foundation for scalable network observability and investigation across hybrid enterprise environments.

Common network metadata fields across all telemetry streams (except DHCP)

These fields appear in nearly every metadata stream and define the shared connection schema used across metadata types. They capture origin and responder identifiers, ports, hostnames, locality flags, sensor attribution, timestamps, and a stable connection UID.

Common fields in all metadata streams (except DHCP)
Field Beschreibung
id.ip_ver*IP Version
id.orig_hOriginating endpoint IP address
id.orig_pOriginating endpoint TCP/UDP port
id.resp_hResponding endpoint IP address
id.resp_pResponding endpoint TCP/UDP port
local_origBoolean indicating if connection was locally originated
local_respBoolean indicating if connection was locally responded
orig_hostname*Originating endpoint hostname
orig_huid*Unique identifier for the originating host if it is local
orig_sluid*Unique identifier for the originating host session
resp_hostname*Responding endpoint hostname
resp_huid*Unique identifier for the responding host if it is local
resp_sluid*Unique identifier for the responding host session if it is local
sensor_uidUnique identifier for Vectra sensor that observed the underlying traffic generating the metadata record
tsTimestamp when the metadata record is generated. It is in date format (e.g. May 9, 2018, 10:09:25.366)
uidUnique id of connection


Treat these fields as baseline join keys. They anchor metadata enrichment workflows by allowing protocol, authentication, and detection records to be tied back to the same session and entity. In threat hunting and metadata forensics, this consistency enables reliable pivoting across telemetry layers.

Most protocol tables that follow extend this schema while inheriting this shared context. This preserves attribution integrity and session continuity across network metadata streams.

Beacon metadata fields and behavioral communication patterns

Beacon metadata describes repeated communication between an origin and a destination across multiple sessions. The fields below capture the beacon identifier, timing boundaries, session count, byte volume by direction, protocol/service context, and client fingerprinting used to summarize the pattern.

Beacon analysis is frequently used in threat hunting to identify command-and-control callbacks, automation loops, and persistent outbound communication. Rather than inspecting packets, analysts rely on metadata types that describe periodicity and consistency.

Beacon**
FieldBeschreibung
beacon_typeThe type of beacon. 'single_resp_multiple_sessions' type indicates a beacon to one destination comprising of multiple sessions
beacon_uidThe unique uid of the beacon
durationTotal duration of the BeaconUid
first_event_timeTimestamp of the first observed session for this beacon_uid
ja3Ja3 hash of client based on client SSL parameters
last_event_timeTimestamp of the last observed session for this beacon_uid
orig_ip_bytesTotal bytes sent from originator to responder for this beacon_uid
protoL4 protocol value. 6 is TCP, 17 is UDP
proto_nameL4 protocol name (TCP or UDP)
resp_domainsThe responder domains in this event
Antwort-IP-BytesTotal bytes send from responder to originator for this beacon_uid
serviceService (e.g. "http" or "tls")
session_countThe number of sessions that comprise the beacon_uid
uidThe unique uid of the first connection for the reported beacon event
tsTimestamp when the metadata record is generated. It is in date format (e.g. May 9, 2018, 10:09:25.366)
uidUnique id of connection


Use these fields to evaluate duration, frequency, and directional volume. Then pivot to DNS, HTTP, or SSL/TLS metadata for deeper behavioral context during metadata forensics.

Stop hunting for the “what” behind network detections

Beaconing is only one behavioral signal. When suspicious network metadata triggers, analysts still need to understand which endpoint process or identity initiated it. Without that linkage, investigations stall.

See endpoint process correlation

Stop hunting for the “what” behind network detections

Beaconing is only one behavioral signal. When suspicious network metadata triggers, analysts still need to understand which endpoint process or identity initiated it. Without that linkage, investigations stall.

See endpoint process correlation

DCE-RPC metadata fields and remote procedure call attributes

DCE-RPC metadata captures remote procedure call behavior commonly associated with Windows administration and service interaction. These fields encode domain context, endpoint resolution, invoked operations, username attribution, and request/response timing.

In threat hunting, DCE-RPC metadata helps surface anomalous remote execution sequences and privilege use patterns without requiring endpoint logs.

DCE-RPC
FieldBeschreibung
domain*Domain of the host
endpointEndpoint name looked up from the uuid (e.g. IXnRemote, IWbemLoginClientID)
hostname*Hostname on which the user logged in
operationOperation seen in the call (e.g. "RemoteCreateInstance")
rttRound trip time of request – response
username*Username or account name that logged in. Names ending in '$' are machine names (not user account names)


Use operation names and username/host context to distinguish routine administrative workflows from lateral movement activity during metadata forensics.

DHCP metadata fields and network configuration attributes

DHCP metadata records dynamic addressing and configuration assignments that place devices onto the network. These metadata types link assigned IPs to MAC addresses and hostnames while recording lease duration and DHCP/DNS server attribution.

Because IP churn complicates investigation, DHCP records provide essential metadata enrichment for maintaining attribution continuity.

DHCP
FieldBeschreibung
assigned_ipAssigned IP in response
dhcp_server_ip*DHCP server IP address
dns_server_ips*DNS server ips from DHCP options. DHCP Option 6
lease_timeDHCP lease time. DHCP Option 51
macMAC address in request
orig_hostname*Hostname from DHCP options. DHCP Option 12
trans_idTransaction id
tsTimestamp when the metadata record is generated. It is in date format (e.g. May 9, 2018, 10:09:25.366)
uidUnique id of connection


Use DHCP fields to stabilize investigations when IP addresses change, anchoring identity to device-level attributes rather than ephemeral addressing.

DNS metadata fields and query response attributes

DNS metadata represents domain resolution behavior, including query intent, recursion handling, response codes, truncation flags, TTL values, and record counts.

DNS network metadata is central to threat hunting because it exposes staging infrastructure, domain fluxing, reconnaissance, and failed callback attempts without payload inspection.

DNS metadata enables visibility into:

  • Which domains were queried and by whom
  • Whether recursion was requested or available
  • How authoritative responses were returned
  • What response codes and TTL values were observed
DNS
FieldBeschreibung
AAAuthoritative answer. True if server is authoritative for the query
answers†List of answers to the query
authList of Authoritative responses for the query
protoProtocol of DNS transaction—6 (for TCP) or 17 (for UDP)
qclass / qclass_nameValue specifying the query class (e.g. 1 / Internet [IN])
qtype / qtype_namequery type value / descriptive name (e.g. A, AAAA, PTR, TXT)
query†Domain name subject of the query
RARecursion available. True if server supports recursive queries
RDRecursion desired. True if recursive lookup of query requested
rcode / rcode_nameResponse code value in the DNS response (e.g. NXDOMAIN, NODATA)
rejectedThe DNS query was rejected by the server
saw_queryWhether the full DNS query has been seen
saw_replyWhether the full DNS reply has been seen
TCTruncation flag. True if the message was truncated
TTLsList of TTLs from the answers
total_answersThe total number of resource records in a reply message's answer section
total_repliesThe total number of resource records in a reply message's answer, authority, and additional sections
trans_id16-bit identifier assigned by DNS client


Use DNS metadata forensics to interpret intent and outcome, what was queried, what was returned, and whether resolution failed, then pivot into TLS or HTTP metadata to extend analysis.

HTTP metadata fields and web session attributes

HTTP metadata summarizes web-layer behavior without storing full payloads. These fields capture header-derived context, methods, URIs, proxy forwarding indicators, fingerprinting attributes, and directional byte/packet metrics.

In network metadata investigations, HTTP fields provide application-layer context for threat hunting, including suspicious file transfers, scripted callbacks, and anomalous header structures.

HTTP
FieldBeschreibung
acceptValue of the Accept header in the request, if present, truncated to 256 bytes
accept_encodingValue of the Accept-Encoding header in the request, if present, truncated to 256 bytes
cookie*Value of the Cookie header, truncated to 256 bytes
cookie_vars*The variables in the cookie field, without the values
hostValue of the Host header, truncated to 256 bytes
host_multihomed*Boolean attribute that indicates whether the address in the host header is observed to be associated with one or more IPs
is_proxied*Boolean value indicative of a proxied request
ja4hThe JA4H fingerprint of the HTTP client
methodHTTP Request Method
orig_ip_bytes*Bytes sent by originator to responder
orig_mime_typesContent type header in originator request
orig_pkts*Number of packets sent from originator to responder
proxiedValue of x-forwarded-for header (e.g. X-FORWARDED-FOR -> 10.10.15.192)
referrerValue of the Referrer header, truncated to 256 bytes
request_body_lenHTTP payload bytes in request
request_cache_control*Value of the Cache-Control header in the request, if present, truncated to 256 bytes
request_header_count*Count of headers in request
resp_filenameThe name of the file returned by the server (if any)
resp_ip_bytes*Bytes send by responder to originator
resp_mime_typesValue of the Content-Type header in response, truncated to 256 bytes
resp_pkts*Number of packets sent from responder to originator
response_body_lenHTTP payload bytes in response
response_cache_control*Value of the Cache-Control header in the response, if present, truncated to 256 bytes
response_content_dispositionThe value of the Content-Disposition header (specifies names of the files to be downloaded as attachment, e.g. 'attachment; filename="filename.jpg"')
response_expires*Expires header in response, if present
response_header_count*Count of headers in response
status_codeThe status code in the HTTP response
status_msgThe status message corresponding to the status code
uriURI used in the request, truncated to 512 bytes
user_agentValue of the User-Agent header from the client


Use HTTP metadata to reconstruct web behavior, then correlate with DNS and TLS metadata types to confirm destination identity and encryption characteristics.

iSession connectivity metadata and session-level network attributes

iSession metadata defines the normalized session model used across protocols. It captures connection state, directional confidence, timing markers, fingerprinting variants, VLAN context, and directional byte/packet counts.

This session-layer abstraction enables scalable metadata enrichment by standardizing how network metadata is represented, regardless of protocol.

iSession Connectivity
FieldBeschreibung
applicationApplications associated with this session
conn_stateConnection state. Takes values: S0, S1, SF, REJ, S2, S3, RSTO, RSTR, RSTOS0, RSTRH, SH, SHR, or OTH
dir_confidenceClient/server assignment confidence from 0 to 100
durationDuration of connection in ms
first_orig_resp_data_pkt*Base64 encoding of the first 16 bytes of the packet from originator to responder, represented as a string
first_orig_resp_data_pkt_time*Timestamp of first data packet from originator to responder
first_orig_resp_pkt_time*Timestamp of first packet from originator to responder
first_resp_orig_data_pkt*Base64 encoding of the first 16 bytes of the packet from responder to originator, represented as a string
first_resp_orig_pkt_time*Timestamp of first packet from responder to originator
first_resp_orig_data_pkt_time*Timestamp of first data packet from responder to originator
ja4lcThe JA4LC fingerprint of the client's light distance
ja4lsThe JA4LS fingerprint of the server's light distance
ja4tThe JA4T fingerprint of the client's TCP SYN packet
ja4tsThe JA4TS fingerprint of the server's TCP SYN ACK packet(s)
orig_ip_bytesBytes sent from originator to responder
orig_pktsNumber of packets sent from originator to responder
orig_vlan_id*VLAN_id of originator, if any
protoL4 protocol value. 6 is TCP, 17 is UDP
proto_nameL4 protocol name (TCP, UDP or ICMP)
resp_domain*Calculated from TLS SNI, HTTP Host, or the destination IP name (in this exact order)
Antwort-IP-BytesBytes send from responder to originator
resp_multihomed*Boolean attribute that indicates whether the domain is observed to be associated with one or multiple IPs
resp_pktsNumber of packets sent from responder to originator
resp_vlan_id*VLAN id of responder, if any
serviceService (e.g. "smb")
session_start_timeTimestamp when session started


Treat iSession as the pivot spine during threat hunting. It provides stable session continuity across protocol, authentication, and detection metadata types.

Connection state values and TCP session lifecycle indicators

Connection state values encode how a session progressed, established, rejected, reset, half-open, or incomplete. These indicators are behavioral metadata types that reveal scanning, probing, unstable communication, or aborted sessions.

Connection State Values
StateBeschreibung
S0Connection attempt seen, no reply.
S1Connection established, not terminated.
SFNormal establishment and termination. Note that this is the same symbol as for state S1. You can tell the two apart because for S1 there will not be any byte counts in the summary, while for SF there will be.
REJConnection attempt rejected
S2Connection established and close attempt by originator seen (but no reply from responder)
S3Connection established and close attempt by responder seen (but no reply from originator)
RST0Connection established, originator aborted (sent a RST)
RSTRResponder sent a RST
RSTOS0Originator sent a SYN followed by a RST, we never saw a SYN-ACK from the responder.
RSTRHResponder sent a SYN ACK followed by a RST, we never saw a SYN from the (purported) originator.
SHOriginator sent a SYN followed by a FIN, we never saw a SYN ACK from the responder (hence the connection was "half" open).
SHRResponder sent a SYN ACK followed by a FIN, we never saw a SYN from the originator.
OTHNo SYN seen, just midstream traffic (one example of this is a "partial connection" that was not later closed).


Use lifecycle states alongside timing and volume fields to prioritize reconnaissance patterns during metadata forensics.

Kerberos metadata fields and authentication ticket attributes

Kerberos metadata captures ticket issuance, authentication type, privilege scoring, cipher negotiation, and success/error states. These identity-layer metadata types are essential for detecting credential abuse and privilege escalation.

Kerberos metadata enables visibility into:

  • Account and service privilege levels (low, medium, high)
  • Ticket request and response types (AS, TGT)
  • Encryption cipher usage and negotiation
  • Authentication success and error conditions
Kerberos
FieldBeschreibung
account_privilegePrivilege level of the account. The scores can fall in three categories – Low (1,2) Medium (3,4,5,6,7) and High (8,9)
account_uidAccount unique identifier (principal@REALM format)
clientClient name, including realm
data_sourceThe source of the record, either "network" or "log"
error_codeError code if not a success
error_msgError message if not a success
orig_host_observed_privilege*The privilege represents the observed privilege based on the activity of an account seen to operate from the host. The scores can fall in three categories – Low (1, 2), Medium (3, 4, 5, 6, 7) and High (8, 9)
protocol*L4 protocol. 6 (TCP) or 17 (UDP)
rep_cipherThe Response ticket encryption type
reply_timestamp*Timestamp of reply
req_ciphersThe request ticket encryption type(s)
request_typeType of request (AS or TGT)
serviceService being requested, including realm
service_privilegePrivilege level of the service. The scores can fall in three categories – Low (1,2) Medium (3,4,5,6,7) and High (8,9)
service_uidService unique identifier (principal@REALM format)
successWhether request was success or not


Use privilege categories and request types to focus threat hunting on high-impact accounts and services, then pivot to LDAP or session telemetry for validation.

LDAP metadata fields and directory query attributes

LDAP metadata summarizes directory search and bind behavior, including query scope, attribute selection, result counts, and error conditions.

Directory metadata forensics is particularly useful for identifying enumeration preceding authentication abuse.

LDAP*
FieldBeschreibung
attributesA set of attributes to request for inclusion in entries that match the search criteria and are returned
base_objectBase of the subtree in which the search is to be constrained
bind_error_countIf there are bind errors, count of the errors
durationDuration of the session
encrypted_sasl_payload_countIf sasl encryption is used, the number of encrypted sasl payloads encountered
errorThe error message in case of error (e.g. "0000208D: NameErr ...")
logon_failure_error_countThe count of logon errors
is_closeBoolean flag indicating whether the close was observed
is_queryBoolean flag indicating whether the query was observed in the request
matched_dnThe matched distinguished name
message_idMessage id
queryCriteria to use to identify which entries within the scope should be returned
query_scopeThe portion of the target subtree that should be considered (e.g. wholeSubtree)
response_bytesNumber of bytes in the response
resultThe result of the query in this request
request_bytesNumber of bytes in the request
result_codeThe result code (success or failure) in the response
result_countThe count of the entries in the result


Use result volume and error patterns to distinguish routine lookups from large-scale discovery during threat hunting workflows.

Match metadata fields and alert signature attributes

Match metadata represents evaluated detection output rather than raw telemetry. These metadata types describe signature identity, severity, revision state, deployment scope, and packet context.

This layer reflects how network metadata was interpreted by detection logic.

Match
FieldBeschreibung
eve_json.alert.categoryCategory of the Alert Message
eve_json.alert.gidUnique identifier for group of signatures. Defaults to 1 for most signatures.
eve_json.alert.metadata.affected_productSpecifies details on the affected product
eve_json.alert.metadata.attack_targetSpecifies if the attack target is the Client, Server, Both, or Other
eve_json.alert.metadata.created_atSpecifies the date the signature was created
eve_json.alert.metadata.deploymentSpecifies where the signature should be deployed
eve_json.alert.metadata.malware_familySpecifies the Malware Family that is associated with the signature
eve_json.alert.metadata.policySpecifies details on the alert policy
eve_json.alert.metadata.signature_severityDescribes the severity associated with the signature
eve_json.alert.metadata.tagSpecifies any tag information assigned to the signature by the author
eve_json.alert.metadata.updated_atSpecifies the data of the last update to the signature
eve_json.alert.revAlert signature revision number indicating if the signature has been updated
eve_json.alert.ruleSpecifie the rule that fired the alert
eve_json.alert.severityNumber representing the severity of the alert
eve_json.alert.signatureThe rule name. Based on the 'msg' text in the signature
eve_json.alert.signature_idAlert signature Identifier
eve_json.alert.xffValue of x-forwarded-for
eve_json.directionSpecifies the traffic direction of the alert
eve_json.packetSpecifies the packet that triggered the signature
eve_json.payloadProvides the Base64 Encoded packet payload information
eve_json.payload_printableProvides the payload presented in ASCII
eve_json.protoL4 protocol name


Use match metadata to understand why a detection triggered, then pivot back into underlying protocol and session metadata for full reconstruction.

NTLM metadata fields and authentication response attributes

NTLM metadata captures authentication attempts and outcomes, including host, domain, username, status code, and success state.

In environments where NTLM remains active, these metadata types are important for identifying fallback authentication abuse.

NTLM
FieldBeschreibung
domainDomain of the host
hostnameHostname on which the user logged in
statusStatus code in response
successWhether the request was successful or not
usernameUsername or account name that logged in


Use repeated failures or anomalous success patterns as threat hunting signals, then correlate forward into SMB or RDP metadata.

RDP metadata fields and remote desktop session attributes

RDP metadata captures interactive remote session attributes including client identity, versioning, display characteristics, and encryption indicators.

These metadata types support investigation of administrative access patterns without decrypting content.

RDP
FieldBeschreibung
client_buildRDP client version used by client machine. Will be "unknown" if encrypted
client_dig_product_idProduct ID of the client machine
client_nameName of the client machine
cookieCookie value used by client machine (username)
desktop_heightDesktop height of client machine. 0 if encrypted
desktop_widthDesktop width of client machine. 0 if encrypted
keyboard_layoutKeyboard layout (language) of client machine (e.g. "US" "Encrypted Keyboard Layout")
resultIf encrypted, result value is "encrypted" otherwise it will be empty


Baseline expected remote access patterns and flag deviations during metadata forensics.

RADIUS metadata fields and authentication accounting attributes

RADIUS metadata records access control authentication and accounting behavior, including session identifiers, duration, packet/byte counters, addressing, and policy markers.

These network metadata types help trace remote access paths through VPN, NAC, or wireless systems.

Radius
Field Beschreibung
account_authentic Identifies how the user was authenticated
account_delay_time Identifies how long the sender has been trying to send the message for
account_input_gigawords Identifies how many times the Acct-Input counter has rolled over for input
account_input_octets How many bytes have been received
account_input_packets How many packets the system has received
account_output_gigawords Identifies how many times the Acct-Input counter has rolled over for output
account_output_octets How many bytes have been set
account_output_packets How many packets the system has sent
account_session_id This is a unique ID that identifies the RADIUS Accounting Session which is sent in a separate packet.
account_session_time Duration of service received by user
calling_station_id This is the identifier of the calling station
connect_info Identify the speed of the connection or other connection related information
delegated_ipv6_prefix IPv6 Pool from which the IPv6 address was assigned
dst_display_name DNS Name of the Destination
dst_host_luid This is the ID of the destination host with host ID
dst_luid The LUID of the RADIUS Server
dst_luid_external Value is True if the destination is external
event_timestamp Similar to ts but is the timestamp from the device, not from Vectra
filter_id This identifies any ACL that is in use
framed_address This field is available in the request that identifies the endpoint requesting authentication
framed_interface Identifies the interface used when the user connects to the system
framed_ip_address IP address of the endpoint device connecting to the system
framed_ipv6_prefix Indicates the framed IPv6 prefix for the user
framed_protocol Identifies the Framed Protocol used when the user connects to the system


Use accounting and NAS context fields to validate access scope and duration before pivoting into SMB or RDP activity.

Extended RADIUS metadata fields and network access control attributes

Extended RADIUS metadata adds device and enforcement context: NAS identifiers and ports, session and idle timeouts, tunnel endpoints, external source indicators, reply timing, and whether sensitive fields (like password) were observed. These fields help interpret how access decisions were implemented.

Radius
Field Beschreibung
idle_timeout Amount of time a session can be idle before it is disconnected
logged The boolean attribute indicates if the request was previously logged
mac MAC Address if observed as a field in the Radius message
nas_identifier Identifies the role the authenticating client is requesting
nas_ip_address This is an IP Address format, it can be the IP of the Device, the Endpoint, or Intermediate system, depending on implementation
nas_port Physical Port Number of the Device Authenticating the User
nas_port_id Text string identifying the port provided by the client
nas_port_type This is the type of medium of the port (e.g. Ethernet, Wifi &c.)
password_seen Boolean attribute indicating password was seen
radius_type The value indicates if it is an access or accounting request
reply_msg Reply message from the server challenge. This is frequently shown to the user authenticating.
reply_timestamp Timestamp when the reply message was received
result Success or Failed Authentication
service_type Type of service the user has requested
session_timeout This is the maximum session length
src_display_name DNS Name of the Source
src_host_luid This is the ID of the Src with Host ID
src_luid The LUID of the RADIUS Client
src_luid_external Value is True if the source is external
ttl The duration between the first request and either the "Access-Accept" message or an error. If the field is empty, it means that either the request or response was not seen.
tunnel_client Address (IPv4, IPv6, or FQDN) of the initiator end of the tunnel, if present. This is collected from the Tunnel-Client-Endpoint attribute.
username This is the username if observed in the Radius message

Use NAS and tunnel context to pinpoint where access was granted, what service was requested, and how long it persisted, especially useful when tracing remote access paths into internal SMB/RDP activity.

SMB file metadata fields and file operation attributes

SMB file metadata captures file-level operations including creation, rename, delete-on-close behavior, path context, SMB version, and user attribution.

These metadata types are critical for ransomware and lateral staging investigations.

SMB Files
FieldBeschreibung
actionAction taken on file
delete_on_close*Flag indicating if the delete_on_close attribute is enabled. If enabled, a file close action may delete the file if it is the last close on the file
domain*Domain of the SMB server
hostname*Hostname of the SMB client
pathPath pulled from the tree file was transferred to or from
prev_nameIf the rename action was seen, this will be the file's previous name
nameFilename if one was seen
username*Username or account name that logged in. Names ending in '$' are machine names (not user account names)
versionSMB version (SMBv1 or SMBv2)


Use file action and rename patterns to identify destructive behavior during threat hunting.

SMB mapping metadata fields and share connection attributes

SMB mapping metadata captures tree connections and share access prior to file interaction.

This layer provides metadata enrichment by linking user identity to share access context.

SMB Mapping
FieldBeschreibung
domain*Domain of the SMB server
hostname*Hostname of the SMB client
pathName of the tree path
serviceType of re-originator of the tree
username*Username or account name that logged in. Names ending in '$' are machine names (not user account names)
versionSMB version (SMBv1 or SMBv2)

Use mapping events to establish access lineage before analyzing file-level operations.

SMTP metadata fields and email header attributes

SMTP metadata captures mail header attributes and authentication results including SPF, DKIM, DMARC, TLS usage, and originating IP. Email-related network metadata supports threat hunting for phishing infrastructure and spoofed sender behavior.

SMTP
FieldBeschreibung
ccContents of the CC header, formatted as a comma separated list
dateContents of the Date header
dkim_statuspass/fail/none. Based on the 'Authentication-results' header
dmarc_statuspass/fail/none. Based on the 'Authentication-results' header
first_receivedContents of the first Received header, which signifies the first SMTP server to receive this message, (i.e. sending server)
fromContents of the From header
heloContents of the Helo header
in_reply_toContents of the In-Reply-To header
mail_fromEmail addresses found in the From header
msgidContents of the MsgID header
rcpt_toEmail addresses found in the Rcpt header, formatted as a comma separated list
reply_toContents of the ReplyTo header
second_receivedContents of the second Received header, which signifies the second SMTP server to receive this message
subjectContents of the Subject header
spf_helo_statusBased on the 'Received-SPF' header in smtp. This header specifies the SPF status (Sender Policy Framework). One of pass/fail/neutral/softfail/none/temperror/permerror. See: https://tools.ietf.org/html/rfc7208#section-9.1
spf_mailfrom_statusOne of pass/fail/neutral/softfail/none/temperror/permerror
tlsIndicates that the connection has switched to using TLS
toContents of the To header, formatted as a comma separated list
user_agentValue of the User-Agent header from the client
x_originating_ipContents of the X-Originating-IP header


Use authentication results and relay chain metadata for forensic validation of sender legitimacy.

SSH metadata fields and encrypted session negotiation attributes

SSH metadata captures negotiation details including client/server versions, key exchange, cipher selection, MAC algorithm, and fingerprinting hashes. These metadata types support identification of anomalous administrative tooling and unauthorized remote shell behavior.

SSH
FieldBeschreibung
clientThe client's version string
cipher_algThe encryption algorithm in use
compression_algThe compression algorithm in use
hasshhassh hash of client based on client SSH parameters
hassh_serverhaashServer hash of server based on client SSH parameters
host_keyThe server's key fingerprint
host_key_algThe server host key's algorithm
kex_algThe key exchange algorithm in use
mac_algThe signing (MAC) algorithm in use
serverThe server's version string
versionSSH major version (1 or 2)


Use algorithm and fingerprint fields to baseline expected administrative tooling and identify unusual clients or negotiation patterns, then pivot to session connectivity to understand duration, direction, and volume for the same SSH session.

SSL/TLS metadata fields and encrypted session attributes

SSL/TLS metadata captures handshake negotiation and certificate exchange characteristics for encrypted sessions. The fields below include protocol versions, chosen cipher suite, curve parameters, client/server extensions, issuer/subject identifiers, SNI, and JA3/JA4 fingerprints, plus establishment status.

SSL
FieldBeschreibung
applicationApplications associated with this session
cipherSSL/TLS cipher suite chosen from server
client_curve_num*Elliptical curve number sent by the client
client_ec_point_format*Elliptical curve point format offered by the client
client_extension*Client extensions
client_issuerClient cert issuer
client_subjectClient cert subject
client_version*SSL version string sent by the client
client_version_num*SSL version number sent by the client
curveElliptical curve number for ECDHE
establishedFlag to indicate if this ssl session has been established successfully, or if it was aborted during the handshake
issuerServer cert issuer
ja3JA3 hash of client based on client SSL parameters
ja3sJA3S hash of server based on server SSL parameters
ja4The JA4 fingerprint of the TLS client
ja4sThe JA4S fingerprint of the TLS server response
next_protocolNext protocol the server chose using the application layer next protocol extension, if present
server_extensionsServer extensions
server_nameSNI value
subjectServer cert subject
versionSSL/TLS version that the server chose
version_numNumeric SSL/TLS version that the server chose
version/version_numSSL version number


Use TLS fingerprints and SNI/certificate context to identify client/server implementations and destination identity, then pivot to X.509 to inspect certificate properties and SAN coverage for deeper trust analysis.

X.509 certificate metadata fields and digital certificate attributes

X.509 metadata records certificate identity and trust characteristics including subject/issuer composition, validity windows, SAN values, key length, signature algorithm, and JA4X fingerprinting. These metadata types support certificate-based metadata forensics and detection of suspicious infrastructure.

X509
FieldBeschreibung
applicationApplications associated with this session
basic_constraints.caFlag indicating whether the subject of the certificate is a CA
basic_constraints.path_lenMaximum depth of valid certification paths that include this certificate
certificate.cnCommon name that identifies the host name of the certificate
certificate.curveCurve, if EC-certificate
certificate.exponentKey exponent
certificate.issuerCombination of country, organizations, common name, issuer, URI
certificate.key_algName of the public key algorithm that is used in data transmission, e.g. RSA encryption
certificate.key_lengthNumber of bits used in the encryption, e.g. 2,048-bit encryption
certificate.key_typeThree key types, depending upon the key algorithm
certificate.not_valid_afterTime after the certificate is invalid
certificate.not_valid_beforeTime before the certificate is invalid
certificate.self_issuedBoolean flag indicating whether the certificate is self-issued or backed by a CA
certificate.serialUnique serial number given by certificate authority or certificate signed authority. Usually 40 hexadecimal characters
certificate.sig_algName of the signature algorithm
certificate.subjectOwner of the certificate (distinguished name)
certificate.versionVersion of the server certificate (SSL V3, TLS V1, TLS V2, etc.)
ja4xThe JA4X fingerprint of the X.509 TLS certificate
san.dnsSpecifying a list of additional host names for a single certificate along with DNS names that are associated with SAN (Subject Alternative Name)
san.emailEmail address associated with the SAN
san.ipIP address of the SAN in the digital certificate
san.other_fieldsOther fields in the SAN
san.uriURL name associated with SAN
version/version_numSSL version number


Use X.509 attributes to evaluate trust posture and reuse patterns, then correlate back to TLS and DNS metadata to complete the investigative chain.

Weltweites Vertrauen bei Experten und Unternehmen

Häufig gestellte Fragen