Encryption¶
Introduction / Setup¶
Encryption is a standard and very common way of communication that guarantees security of communication. In recent years, it has become more common, and at the enterprise level the majority of communications are now encrypted. Naturally, this has benefits and disadvantages.
One of the more concerning disadvantages is that encryption is also commonly used by malware actors. This, paired with the fact that encryption diminishes the visibility of network detection and response (NDR) and endpoint detection and response (EDR) systems, creates challenges for many organizations. Encrypted traffic makes it difficult to investigate and highlight malicious activity.
Thankfully, there are plenty of communication artifacts, observations, and log evidence present on the network layer as part of a successful defense strategy that can allow us to observe, highlight, and remediate malicious activity hidden in encrypted communication on the network .
In this document, we will list and explain the various ways that Stamus Security Platform provides visibility into encrypted connections including TLS, SSH, RDP, and others. By using alternative means to identify threats in encrypted communications, your organization can ensure maximum visibility across all areas of your network, thereby minimizing the challenges often posed by the increase in encrypted traffic.
Logs and detection¶
Stamus Security Platform provides several advantages in terms of logging for various encryption protocols. We also provide numerous detection methods and data types for use in threat detection, auditing, and incident response.
Logs¶
The Stamus Security Platform (SSP) includes over 160 different encryption-related log and analytics fields. These encrypted communication protocols are available for use for various analytics, algorithmic detections, and decisions.
TLS¶
Below, you will find the different fields available in SSP from the TLS protocol logs that are related to encryption.
TLS logs, in combination with flow logs, are used for machine learning beacon calculations and detection. Different parts of TLS encrypted communications are constantly being evaluated for repetitiveness, jitter, flow size, and other analytics to learn and determine if a beacon-like behavior is present.
We can use TLS logs to reveal weak, legacy, or no longer recommended cipher security coming into clients or to and from production critical installations. In addition, connections can be hashed to determine whether similar ones occur elsewhere in the organization.
The vast amount of information produced by SSP also allows it to audit all TLS encrypted communications in the organization and easily list the related artifacts to be mapped to the organization’s security requirements and policies. For example, the following communication artifacts can be used for this purpose:
TLS communications breakdown by version
TLS communications breakdown by TLS ciphers used and encryption strength level recommendations and analysis
All or top TLS Server Name Indications domains used
Least TLS SNI domains used - usually revealing interesting communications
TLS Certificate expiration
TLS Expired certificates
TLS Certificate fingerprint
Who are the TLS Issuers that the organization actively uses and from where
TLS encrypted anomalies of the traffic - are there any present from where and why
Example TLS logs can be found under the Download an example log of the TLS protocol event link here: Logs of TLS communication.
The Stamus Security Platform provides numerous TLS fields and descriptions as part of its TLS analytics and logs. These fields and data can be used to analyze and audit encrypted communications, providing extra detections:
Fields¶
tls.cipher_suite
tls.cipher_security
tls.fingerprint
tls.from_proto
tls.issuerdn
tls.ja3
tls.ja3.hash
tls.ja3s
tls.ja3s.hash
tls.ja3s.string
tls.ja3.string
tls.ja4
tls.ja4.hash
tls.notafter
tls.notbefore
tls.serial
tls.session_resumed
tls.sni
tls.subject
tls.version
hostname_info.domain
hostname_info.domain_without_tld
hostname_info.host
hostname_info.url
net_info.dest
net_info.dest_agg
net_info.src
net_info.src_agg
Descriptions¶
“subject”: The subject field from the TLS certificate
“issuer”: The issuer field from the TLS certificate
“session_resumed”: This field has the value of “true” if the TLS session was resumed via a session id. If this field appears, “subject” and “issuer” do not appear, since a TLS certificate is not seen.
“serial”: The serial number of the TLS certificate
“fingerprint”: The (SHA1) fingerprint of the TLS certificate
“sni”: The Server Name Indication (SNI) extension sent by the client
“version”: The SSL/TLS version used
“not_before”: The NotBefore field from the TLS certificate
“not_after”: The NotAfter field from the TLS certificate
“ja3”: The JA3 fingerprint consisting of both a JA3 hash and a JA3 string
“ja3s”: The JA3S fingerprint consisting of both a JA3 hash and a JA3 string
“certificate”: The TLS certificate base64 encoded
“chain”: The entire TLS certificate chain base64 encoded
Flow Logs¶
SSP provides flow logs for each encrypted flow/session and communication for different protocols like TLS, SSH, RDP, and more.
Flow logs based on encrypted communications allow us to pinpoint long sessions, anomalous behaviors, or large amounts of data being transferred in or out of the organization. These sessions and behaviors, despite originating from encrypted traffic, can be observed and tracked.
Flow logs can also reveal the level of encryption used in the organization’s network communication, sequence, volume direction, and other key elements.
As an example, encrypted flows can be uniquely hashed and tracked. Unusual encrypted communications flow can be observed via the specific flow metrics of that encrypted communication. This allows us to observe use cases such as data exfiltration in and out of an organization.
Some other use cases include:
Top TLS talkers in terms of data transferred.
Top data transfers using TLS/SSH (including internal as well as in and out of the organization)
Identification of big SSH sessions , especially on or off business hours.
Identify large or long encrypted transfers in and out of the organization
Identify long admin SSH sessions in and out of the organization.
Identify admin SSH sessions not coming from the expected location (aka IT admins)
Uniquely hash SSH connections to be able to map identical SSH sessions from identical applications in the organization.
Example Flow logs can be found under the Download an example log of the FLOW record event link here: Flow Logs.
SSP includes several flow log-related fields and descriptions as part of its encrypted communication analytics and logs. These fields and data can be used to analyze and audit encrypted communications, providing extra detections:
Fields¶
flow.age
flow.alerted
flow.bytes_toclient
flow.bytes_toserver
flow.end
flow.pkts_toclient
flow.pkts_toserver
flow.reason
flow.start
flow.state
tcp.tcp_flags
tcp.tcp_flags_ts
tcp.tcp_flags_tc
tcp.syn
tcp.fin
tcp.psh
tcp.ack
tcp.state
net_info.dest
net_info.dest_agg
net_info.src
net_info.src_agg
Descriptions¶
“pkts_toserver”: total number of packets to server, include bypassed packets
“pkts_toclient”: total number of packets to client
“bytes_toserver”: total bytes count to server
“bytes_toclient”: total bytes count to client
“bypassed.pkts_toserver”: number of bypassed packets to server
“bypassed.pkts_toclient”: number of bypassed packets to client
“bypassed.bytes_toserver”: bypassed bytes count to server
“bypassed.bytes_toclient”: bypassed bytes count to client
“start”: date of start of the flow
“end”: date of end of flow (last seen packet)
“age”: duration of the flow
“bypass”: if the flow has been bypassed, it is set to “local” (internal bypass) or “capture”
“state”: display state of the flow (include “new”, “established”, “closed”, “bypassed”)
“reason”: mechanism that did trigger the end of the flow (include “timeout”, “forced” and “shutdown”)
“alerted”: “true” or “false” depending if an alert has been seen on flow
SSH¶
SSH encrypted connections are automatically identified regardless of port usage. Each connection is analyzed and corresponding protocol logs are produced. Those protocol logs are used as a basis for the SSH analytics done by the Stamus Security Platform. Further analytics can be developed based on the data and the organization’s needs. Using SSH analytics, we can identify anomalous activity and exfiltration attempts – such as the use of an unusual port or the transfer of data outside of the organization.
The Stamus Security Platform also provides SSH server and client versions, which enables us to identify and audit any SSH server / client software being used for copying and remote administration in the organization via SSH.
SSH identification, analytics, and auditing can be used to do the following:
Audit SSH software used in the organization.
Identify non-interactive SSH sessions.
Identify large SSH transfers in and out of the organization.
Analyze and uniquely hash any SSH connections
Identify and audit all SSH client and server software used in the organization, including versions
Identify SSH connections and location to prod critical infrastructure.
Identify weak encryption offered by communicating points.
Example SSH logs can be found under the Download an example log of the SSH protocol event link here: SSH Logs.
The SSP encrypted communication analytics and logs provide multipleSSH log-related fields and descriptions. These fields and data can be used to analyze and audit encrypted communications, providing extra detections:
Fields¶
ssh.client.hassh
ssh.client.hassh.hash
ssh.client.hassh.string
ssh.client.hassh.string
ssh.client.proto_version
ssh.client.software_version
ssh.client.software_version
ssh.server.hassh
ssh.server.hassh.hash
ssh.server.hassh.string
ssh.server.proto_version
ssh.server.software_version
ssh.server.software_version
Descriptions¶
“proto_version”: The protocol version transported with the ssh protocol (1.x, 2.x)
“software_version”: The software version used by end user
“hassh.hash”: MD5 of hassh algorithms of client or server
“hassh.string”: hassh algorithms of client or server
HASSH¶
The HASSH technique is a unique way of identifying SSH connections. It can be used to trace normal/regular and allowed communication vs unauthorized communication. All SSH protocol logs will have the HASSH filed with a unique value for a specific connection. Based on those unique values, we can do SSH profiling analytics for auditing, threat hunting, or to identify anomaly behaviors of those encrypted communications
HASSH example fields can be found as part of any SSH protocol event log. This is seen in the following example: Log of the SSH protocol event.
RDP¶
Stamus Security platform analises any RDP connection and produces the relevant protocol logs for it regardless if it is encrypted or not. In many cases, encryption-level relevant information can be extracted, reviewed, and analyzed. Encryption relevant RDP fields and data (like tls_handshake, ssl requirements, etc) can reveal details about the encrypted part of the connection that can then be used to do audit and analysis, confirming organizational policies are being enforced.
A few examples below of case usage can reveal potential problems, misconfigurations, or enable idea formation to begin threat hunting:
Identify and audit RDP log in locations
Identify keyboard layouts of the RDP sessions.
List legacy RDP versions and software used.
Identify RDP connections and location to prod critical infrastructure.
Identify and audit misconfigured endpoint communications
The Stamus Security Platform provides extensive protocol analysis and logs of any RDP connection. These fields and data can be used to analyze and audit encrypted communications, providing extra detections:
Fields¶
rdp.channels
rdp.client
rdp.client.build
rdp.client.capabilities
rdp.client.client_name
rdp.client.color_depth
rdp.client.desktop_height
rdp.client.desktop_width
rdp.client.function_keys
rdp.client.keyboard_layout
rdp.client.keyboard_type
rdp.client.product_id
rdp.client.version
rdp.cookie
rdp.error_code
rdp.event_type
rdp.protocol
rdp.reason
rdp.server_supports
rdp.tx_id
rdp.x509_serials
Descriptions¶
Initial negotiations between RDP client and server are stored as transactions and logged. Each RDP record contains a per-flow incrementing “tx_id” field. The “event_type” field indicates an RDP event subtype. Possible values: • “initial_request” • “initial_response” • “connect_request” • “connect_response” • “tls_handshake”
RDP type: Initial Request¶
The optional “cookie” field is a string identifier the RDP client has chosen to provide. The optional “flags” field is a list of client directives. Possible values: • “restricted_admin_mode_required” • “redirected_authentication_mode_required” • “correlation_info_present”
RDP type: Initial Response¶
In the event of a standard initial response: The “protocol” field is the selected protocol. Possible values: • “rdp” • “ssl” • “hybrid” • “rds_tls” • “hybrid_ex” The optional “flags” field is a list of support server modes. Possible values: • “extended_client_data” • “dynvc_gfx” • “restricted_admin” • “redirected_authentication” Alternatively, in the event of an error-indicating initial response: There will be no “protocol” or “flags” fields. The “error_code” field will contain the numeric code provided by the RDP server. The “reason” field will contain a text summary of this code. Possible values: • “ssl required by server” (error code 0x1) • “ssl not allowed by server” (error code 0x2) • “ssl cert not on server” (error code 0x3) • “inconsistent flags” (error code 0x4) • “hybrid required by server” (error code 0x5) • “ssl with user auth required by server” (error code 0x6)
RDP type: Connect Request¶
The optional “channel” field is a list of requested data channel names.
Common channels:
“rdpdr” (device redirection)
“cliprdr” (shared clipboard)
“rdpsnd” (sound)
The optional “client” field is a sub-object that may contain the following:
“version”: RDP protocol version. Possible values are “v4”, “v5”, “v10.0”, “v10.1”, “v10.2”, “v10.3”, “v10.4”, “v10.5”, “v10.6”, “v10.7”, “unknown”.
“desktop_width”: Numeric desktop width value.
“desktop_height”: Numeric desktop height value.
“color_depth”: Numeric color depth. Possible values are 4, 8, 15, 16, 24.
“keyboard_layout”: Locale identifier name, e.g., “en-US”.
“build”: OS and SP level, e.g., “Windows XP”, “Windows 7 SP1”.
“client_name”: Client computer name.
“keyboard_type”: Possible values are “xt”, “ico”, “at”, “enhanced”, “1050”, “9140”, “jp”.
“keyboard_subtype”: Numeric code for keyboard.
“function_keys”: Number of function keys on client keyboard.
“ime”: Input method editor (IME) file name.
“product_id”: Product id string.
“serial_number”: Numeric value.
“capabilities”: List of any of the following: “support_errinfo_pdf”, “want_32bpp_session”, “support_statusinfo_pdu”, “strong_asymmetric_keys”, “valid_connection_type”, “support_monitor_layout_pdu”, “support_netchar_autodetect”, “support_dynvc_gfx_protocol”, “support_dynamic_time_zone”, “support_heartbeat_pdu”.
“id”: Client product id string.
“connection_hint”: Possible values are “modem”, “low_broadband”, “satellite”, “high_broadband”, “wan”, “lan”, “autodetect”.
“physical_width”: Numeric phyical width of display.
“physical_height”: Numeric physical height of display.
“desktop_orientation”: Numeric angle of orientation.
“scale_factor”: Numeric scale factor of desktop.
“device_scale_factor”: Numeric scale factor of display.
RDP type: Connect Response¶
With this event, the initial RDP negotiation is complete in terms of tracking and logging.
RDP type: TLS Handshake¶
With this event, the initial RDP negotiation is complete in terms of tracking and logging. The session will use TLS encryption. The “x509_serials” field is a list of observed certificate serial numbers, e.g., “16ed2aa0495f259d4f5d99edada570d1”.
IKE¶
The Stamus Security Platform provides extensive IKE v1/v2 protocol analysis and coverage. Every connection wherever relevant is automatically identified if it is IKE protocol-based and the respective protocol logs are produced. In turn, those protocol logs provide data that can be used for analytics, hunting, or for auditing organizational policies – assuming all connections adhere to the set configuration, for example. Each connection detected by SSP is analyzed and relevant protocol logs are produced. Those logs include detailed information about the protocol, type of connection, level of encryption, and a wealth of other information. Any field can be queried and checked, aggregated, and have further detection and search logic applied to it to identify misusage, malicious activity, or misconfiguration.
Fields¶
ike.alg_auth
ike.alg_auth_raw
ike.alg_dh
ike.alg_dh_raw
ike.alg_enc
ike.alg_enc_raw
ike.alg_esn
ike.alg_hash
ike.alg_hash_raw
ike.alg_prf
ike.exchange_type
ike.ikev1
ike.ikev1.client
ike.ikev1.client.key_exchange_payload
ike.ikev1.client.key_exchange_payload_length
ike.ikev1.client.nonce_payload
ike.ikev1.client.nonce_payload_length
ike.ikev1.client.proposals
ike.ikev1.client.proposals.alg_auth
ike.ikev1.client.proposals.alg_auth_raw
ike.ikev1.client.proposals.alg_dh
ike.ikev1.client.proposals.alg_dh_raw
ike.ikev1.client.proposals.alg_enc
ike.ikev1.client.proposals.alg_enc_raw
ike.ikev1.client.proposals.alg_hash
ike.ikev1.client.proposals.alg_hash_raw
ike.ikev1.client.proposals.sa_key_length
ike.ikev1.client.proposals.sa_key_length_raw
ike.ikev1.client.proposals.sa_life_duration
ike.ikev1.client.proposals.sa_life_duration_raw
ike.ikev1.client.proposals.sa_life_type
ike.ikev1.client.proposals.sa_life_type_raw
ike.ikev1.doi
ike.ikev1.encrypted_payloads
ike.ikev1.encrypted_payloads
ike.ikev1.server
ike.ikev1.server.key_exchange_payload
ike.ikev1.server.key_exchange_payload_length
ike.ikev1.server.nonce_payload
ike.ikev1.server.nonce_payload_length
ike.ikev1.vendor_ids
ike.ikev2
ike.ikev2.errors
ike.ikev2.notify
ike.init_spi
ike.message_id
ike.payload
ike.resp_spi
ike.role
ike.sa_key_length
ike.sa_key_length_raw
ike.sa_life_duration
ike.sa_life_duration_raw
ike.sa_life_type
ike.sa_life_type_raw
ike.version_major
ike.version_minor
Descriptions¶
“init_spi”, “resp_spi”: The Security Parameter Index (SPI) of the initiator and responder.
“version_major”: Major version of the ISAKMP header.
“version_minor”: Minor version of the ISAKMP header.
“payload”: List of payload types in the current packet.
“exchange_type”: Type of the exchange, as numeric values.
“exchange_type_verbose”: Type of the exchange, in human-readable form. Needs extended: yes set in the ike EVE output option.
“alg_enc”, “alg_hash”, “alg_auth”, “alg_dh”, “alg_esn”: Properties of the chosen security association by the server.
“ikev1.encrypted_payloads”: Set to true if the payloads in the packet are encrypted.
“ikev1.doi”: Value of the domain of interpretation (DOI).
“ikev1.server.key_exchange_payload”, “ikev1.client.key_exchange_payload”: Public key exchange payloads of the server and client.
“ikev1.server.key_exchange_payload_length”, “ikev1.client.key_exchange_payload_length”: Length of the public key exchange payload.
“ikev1.server.nonce_payload”, “ikev1.client.nonce_payload”: Nonce payload of the server and client.
“ikev1.server.nonce_payload_length”, “ikev1.client.nonce_payload_length”: Length of the nonce payload.
“ikev1.client.client_proposals”: List of the security associations proposed to the server.
“ikev1.vendor_ids”: List of the vendor IDs observed in the communication.
“server_proposals”: List of server proposals with parameters, if there are more than one. This is a non-standard case; this field is only present if such a situation was observed in the inspected traffic.
Example IKE logs can be found under the Download an example log of the IKE protocol event link here: IKE Logs.
KRB5¶
Stamus Security Platform analyzes and automatically detects any KRB5-based connection. That process results in a thorough and detailed protocol connection log. The data in the logs contain various aspects of that encrypted connection including fields and values related to the encryption itself. Analysis, auditing, and hunting techniques can then be developed resulting in easy identification of problematic connections with weak encryption, misconfigured communication endpoints, or unexpected and unwanted encryption connections. Additionally, those protocol log details can be used for troubleshooting connections as well. Some examples of use cases are listed below:
Audit Kerberos encryption, identify weak
List and audit all existing domains and realms used in the organization.
Identify log in connections to specific domain.
Troubleshoot KRB5 login issues
Check if an audited account or decommissioned username is still used or trying to be used.
Fields¶
krb5.cname
krb5.encryption
krb5.error_code
krb5.failed_request
krb5.msg_type
krb5.realm
krb5.sname
krb5.ticket_encryption
krb5.ticket_weak_encryption
krb5.weak_encryption
Example KRB5 logs can be found under the Download an example log of the KRB5 protocol event link here: KRB5 Logs.
Descriptions¶
“kerberos.realm” (string): the Kerberos Realm.
“kerberos.snames (array of strings): snames.
Detection¶
Encryption Anomaly events¶
The Stamus Security Platform is threat intel feed vendor agnostic, so it can utilize any threat intel feed provider to match, highlight, and escalate communication on any part of an encrypted connection using protocols like TLS, SSH, IKE, Kerberos and more. Anomaly detection in different protocol communications is available by default. These anomalies could be invalid requests, answers, protocol fields, non-standard RFC communications, or many others. This is very useful, as anomalies detected during encrypted traffic not only help troubleshoot the network or specific applications, but also find and highlight malware, old application communications, very weak or retired encryption, and non-RFC compliant traffic.
The following are examples of the various protocols and events detected by SSP:
TLS¶
Stamus Security Platform auto detects any encrypted TLS communication, regardless of port usage. For TLS specifically, the following list of events can be detected automatically. These are helpful in finding malware, simple unknown misconfigurations, or non-compliant applications/installations in the organization:
TLS invalid SSLv2 header
TLS invalid TLS header
TLS invalid record version
TLS invalid record type
TLS invalid handshake message
TLS invalid certificate
TLS certificate invalid length
TLS error message encountered
TLS invalid record/traffic
TLS heartbeat encountered
TLS overflow heartbeat encountered, possible exploit attempt (heartbleed)
TLS invalid heartbeat encountered, possible exploit attempt (heartbleed)
TLS invalid encrypted heartbeat encountered, possible exploit attempt (heartbleed)
TLS multiple SNI extensions
TLS invalid SNI type
TLS invalid SNI length
TLS handshake invalid length
TLS too many records in packet
TLS certificate invalid version
TLS certificate invalid serial
TLS certificate invalid algorithm identifier
TLS certificate invalid x509 name
TLS certificate invalid date
TLS certificate invalid extensions
TLS certificate invalid der
TLS certificate invalid subject
TLS certificate invalid issuer
TLS certificate invalid validity
App layer¶
For application layer communication on encrypted communication, SSP offers automatic detection of anomalies that can highlight malicious activity or misconfigurations:
Applayer Mismatch protocol both directions
Applayer Wrong direction first Data
Applayer Detect protocol only one direction
Applayer Protocol detection skipped
Applayer No TLS after STARTTLS
Applayer Unexpected protocol
IKE¶
For IKE, the following anomalies detections are available:
IKE malformed request data
IKE malformed response data
IKE weak cryptographic parameters (Encryption)
IKE weak cryptographic parameters (PRF)
IKE weak cryptographic parameters (Auth)
IKE weak cryptographic parameters (Diffie-Hellman)
IKE no Diffie-Hellman exchange parameters
IKE no authentication
IKE no encryption (AH)
IKE invalid proposal
IKE invalid proposal selected
IKE unknown proposal
IKE unknown proposal selected
IKE multiple server proposal
SSH¶
For SSH the following anomalies detections are available:
SSH invalid banner
SSH too long banner
SSH invalid record
Kerberos¶
For Kerberos the following anomalies detections are available:
Kerberos 5 malformed request data
Kerberos 5 weak encryption parameters
QUIC¶
For QUIC the following anomalies detections are available:
QUIC error on data
QUIC failed decrypt
NRD¶
In TLS sessions the Stamus Security Platform has the capability of analyzing, logging, and detecting the TLS Server Name Indication (SNI). In many cases, malicious actors are using Newly Registered Domains (NRD) en masse to be used as C2, CnC, or exfiltration activities.
Naturally, the Stamus Security Platform can highlight sessions – including beaconing – from those types of domains also.
For more information and actual detection mechanism, visit our blog “Threat Hunting for Unknown Actors and Threats Using NRD and Sightings”.
Entropy¶
Entropy of those domains is detected with AI/ML analysis and can be highlighted – offering a generic way to detect those types of malicious communications.
Phishing¶
Phishing domains are also part of the Newly Registered Domains detection capability. Similar to entropy, the Stamus Security Platform offers Phishing domain detection presence in the TLS SNI.
SIGHTINGS¶
Stamus Security platform provides the SIGHTINGS capability to highlight new, previously unseen, and unique communications. As such, any new and unique TLS or SSH encrypted communication connections will be analyzed and highlighted. This helps to identify and audit any new TLS/SSH connection to and from critical and user infrastructure alike based on different encryption protocol metrics – regardless of encryption level. In combination with Network Definitions, the capability gives an edge to the defenders as it allows detection and escalation of any such communication based on organizational context.
For example:
very weak new unique TLS encryption coming in and out of production systems
new and never seen before ssh agent from the Marketing department VPN
The list below gives an example of new , previously unseen TLS based unique communication identifiers:
SN SIGHTINGS Newly discovered TLS SNI servers not seen
SN SIGHTINGS Newly discovered TLS Serial servers not seen
SN SIGHTINGS Newly discovered TLS Subject servers not seen
SN SIGHTINGS Newly discovered TLS Issuer servers not seen
SN SIGHTINGS Newly discovered TLS JA4 clients not seen
SN SIGHTINGS Newly discovered TLS JA3S servers not seen
SN SIGHTINGS Newly discovered TLS Fingerprint not seen
Example SIGHTINGS logs for TLS (Click on Download an example log of the TLS protocol event to download)
Example SIGHTINGS logs for SSH (Click on Download an example log of the SSH protocol event to download)
DNS over HTTPS (DoH)¶
Oftentimes, malware will use any DNS services it can that will provide resolution and connectivity to its needed C2/CnC communication servers, including DoH.
As an example: typically, in the majority of cases, an organization’s browsers can make use of DoH. That usage from browsers is usually disabled in an organization via a GPO/Policy to allow DNS usage from organization-defined DNS servers.
Stamus Security Platform provides multiple ways to detect DNS Over HTTPS. The detection methods are updated daily. As such, DoH-provided detection allows for the auditing of organizational policies and detection of policy violations.
A few examples are listed below:
Identify and auditing DoH used providers in an organization
Identify and audit traffic volume to and from DoH
Identify applications or production installations using DoH
In general, there are over 1000 different methods (a few examples are provided below):
INFO Observed DNS over HTTPS Domain (doh .securedns .eu in TLS SNI)
INFO SecureDNS .eu DNS Over HTTPS Certificate Inbound
INFO TRR DNS over HTTPS detected
INFO Observed Google DNS over HTTPS Domain (dns .google .com in TLS SNI)
INFO Cloudflare DNS Over HTTPS Certificate Inbound
INFO Observed DNS over HTTPS Domain in TLS SNI (dns .hostux .net)
INFO Observed DNS over HTTPS Domain in TLS SNI (dns .dns-over-https .com)
INFO Observed DNS over HTTPS Domain in TLS SNI (uncensored .lux1 .dns .nixn.xyz)
INFO Observed DNS over HTTPS Domain in TLS SNI (dns .rubyfish .cn)
INFO Observed DNS over HTTPS Domain in TLS SNI (dns .twnic .tw)
INFO Observed DNS over HTTPS Domain in TLS SNI (doh .centraleu .pi-dns .com)
INFO Observed DNS over HTTPS Domain in TLS SNI (fi .doh .dns .snopyta .org)
INFO Observed DNS over HTTPS Domain in TLS SNI (dns .flatuslifir .is)
INFO Observed DNS over HTTPS Domain in TLS SNI (doh .li)
INFO Observed DNS over HTTPS Domain in TLS SNI (dns .digitale-gesellschaft .ch)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .cleanbrowsing .org)
INFO Observed DNS Over HTTPS Domain in TLS SNI (dns .dnsoverhttps .net)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .crypto .sx)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .powerdns .org)
INFO Observed DNS Over HTTPS Domain in TLS SNI (dns9 .quad9 .net)
INFO Observed DNS Over HTTPS Domain in TLS SNI (dns10 .quad9 .net)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .dnswarden .com)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .captnemo .in)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .tiar .app)
INFO Observed DNS Over HTTPS Domain in TLS SNI (doh .xfinity .com)
INFO Observed DNS Over HTTPS Domain (dns .alidns .com in TLS SNI)
INFO Google DNS Over HTTPS Certificate Inbound
INFO Applied Privacy DNS over HTTPS Certificate Inbound
INFO UncensoredDNS DNS Over HTTPS Certificate Inbound
INFO Observed DNS over HTTPS Domain in TLS SNI (free .bravedns .com)
INFO Observed DNS over HTTPS Domain in TLS SNI (zero .bravedns .com)
INFO Observed DNS over HTTPS Domain in TLS SNI (basic .rethinkdns .com)
INFO UncensoredDNS DNS Over HTTPS Certificate Inbound
INFO UncensoredDNS DNS Over HTTPS Certificate Inbound
INFO UncensoredDNS DNS Over HTTPS Certificate Inbound
INFO UncensoredDNS DNS Over HTTPS Certificate Inbound
INFO UncensoredDNS DNS Over HTTPS Certificate Inbound
INFO Keweon Center DNS Over HTTPS Certificate Inbound
INFO Keweon Center DNS Over HTTPS Certificate Inbound
INFO BlahDNS DNS Over HTTPS Certificate Inbound
INFO Observed DNS over HTTPS Domain in TLS SNI (.blahdns .com)
INFO Observed DNS Over HTTPS Domain (doh .zln .wtf in TLS SNI)
TOR detection¶
TOR usage by itself is not necessarily malicious; however, it is usually very rare and unexpected in organizations. It can be an indicator of a compromise as malware loves using it. At the same time, it can also indicate a security policy violation.
Stamus Security platform provides daily method-updated detection for TOR communication. This includes different groups of TOR exit nodes, known malware usage, different user agents, cookies, TLS SNI, and other detections. This is also an easy way to highlight TOR usage in an organization and uncover potential security policy violations.
Here are a few examples:
TOR Known Tor Exit Node Traffic group
TOR Known Tor Relay/Router (Not Exit) Node Traffic group
EXPLOIT Firefox 0-day used against TOR browser
HUNTING SUSPICIOUS Non-SSL Tor Executable Download as (Observed in TorLocker)
MALWARE Possible Ursnif TOR Module DL 32-bit
MALWARE Possible Ursnif TOR Module DL 64-bit
MALWARE Possible TOX Ransomware Downloading TOR Client
MALWARE W32/Unknown Downloading Tor EXE
MALWARE W32.Dreambot Downloading TOR Module
MALWARE KEYHolder ransomware Tor DNS Proxy .onion lookup (mwyigd4n52mkbyhe)
MALWARE Critroni Likely Malicious Tor Proxy Cookie
MALWARE Maktub Locker TOR Status Check
MALWARE Possible Ursnif Tor Module Download M2
MALWARE Possible Ursnif Tor Module Download M2
MALWARE Automated Tor EXE Download Possibly Raum Trojan
P2P TOR 1.0 Server Key Retrieval
P2P TOR 1.0 Status Update
P2P TOR 1.0 Inbound Circuit Traffic
P2P TOR 1.0 Outbound Circuit Traffic
P2P Tor GServer Request
P2P Tor GStatus Request
POLICY TOR Consensus Data Requested
POLICY Observed Tor Browser Bundle Download
POLICY External IP Lookup / Tor Checker Domain (bridges.torproject .org in DNS lookup)
POLICY Middle Earth Illegal Marketplace Tor Hidden Service DNS Query
POLICY External IP Lookup / Tor Checker Domain (check.torproject .org in DNS lookup)
POLICY DNS Query for TOR Hidden Domain .onion Accessible Via TOR
POLICY TOR .exit Pseudo TLD DNS Query
POLICY Onion2Web Tor Proxy Cookie
POLICY TLS possible TOR SSL traffic
HTTPS/TLS File Sharing Services¶
Public file sharing services are often used by malware but also include regular user utilization – for example, it could be a policy violation in the form of Shadow IT. Stamus Security Platform helps audit and uncover such communication and data transfers.
SSP provides detection of encrypted communications for file and online sharing services. The usage of those by itself is not necessarily malicious; however, organizations typically provide established and authorized ways of sharing information between employees and different systems/applications via approved sharing services. Deviation from approved methods can highlight security policy violations or other potentially malicious activity. This is especially true coming in and out of production networks.
Stamus Security Platform currently monitors over 300 global file and data sharing services, and that list is updated daily. Here are a few examples:
INFO Commonly Abused File Sharing Site Domain Observed (transfer .sh in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (sendspace .com in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (anonfiles .com in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (send .exploit .in in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (fex .nin TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (privatlab .nin TLS SNI)
INFO Commonly Abused File Sharing Domain (filetransfer .io in TLS SNI)
INFO Observed File Sharing Domain (drive .protonmail .com in TLS SNI)
INFO Observed File Sharing Domain (www .cloudme .com in TLS SNI)
INFO External File Sharing Service Domain (api .anonfile .com in TLS SNI)
INFO Observed Anonymous File Sharing Service (fromsmash .com in TLS SNI)
INFO Observed Abused File Sharing Domain in TLS SNI
INFO Observed File Sharing Service Domain (link .storjshare .io in TLS SNI)
INFO Observed Collaboration/File Sharing Platform Domain (www .notion .so in TLS SNI)
INFO Observed File Sharing Service Download Domain (files .catbox .moe in TLS SNI)
INFO Observed Temporary File Sharing Service Domain (litter .catbox .moe in TLS SNI)
INFO Observed File Sharing Service Domain (web .opendrive .com in TLS SNI)
INFO Abused File Sharing Site Domain Observed (qaz .su) in TLS SNI
INFO Abused File Sharing Site Domain Observed (qaz .im) in TLS SNI
INFO Observed Anonymous File Sharing Service Domain (send .vis .ee in TLS SNI)
INFO Observed File Sharing Service Domain (www .uplooder .net) in TLS SNI
INFO File Sharing Service Domain (docdroid .net) in TLS SNI
INFO Observed File Sharing Domain (roamresearch .com in TLS SNI)
INFO Observed File Sharing Domain (zippyshare .com in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (a .pomf .cat in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (a .pomfe .co in TLS SNI)
INFO Commonly Abused File Sharing Site Domain Observed (mixtape .moe in TLS SNI)
INFO Observered File Sharing Service in TLS SNI (frocdn .ch)
INFO Abused File Sharing Domain (put .io) in TLS SNI
INFO Abused File Sharing Domain (wasabi .com) in TLS SNI
INFO Commonly Abused File Sharing Domain (wasabisys .com) in TLS SNI
INFO Observed Peer-to-Peer File Sharing Service Domain (ipfs .io in TLS SNI)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (ipfs .eternum .io)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (ipfs .infura .io)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (cloudflare-ipfs .com)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (infura-ipfs .io)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (2read .net)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (cf-ipfs .com)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (hardbin .com)
INFO Peer to Peer File Sharing Service Domain in TLS SNI (ipfs .2read .net)
INFO Observed File Sharing Service Domain (dropmefiles .com in TLS SNI)
INFO File Sharing Domain (pan .tencent .com in TLS SNI)
INFO Observed File Sharing Domain (drive .internxt .com in TLS SNI)
INFO Observed Anonymous File Sharing Service Domain (qu .ax) in TLS SNI
INFO Observed File Sharing Domain (dracoon .team in TLS SNI)
Red-Listed Malicious TLS Communication¶
While the Stamus Security Platform is Threat Intel agnostic, it also comes with redefined red-listed, known malicious TLS connections. Those lists are updated daily and provide matching based on encryption metadata such as - TLS certificates / fingerprints / SNI / fingerprinting / Issuers and more:
Thousands of methods are updated daily. Here are a few examples:
ET MALWARE ABUSE.CH SSL Blacklist Malicious SSL certificate detected (Dyre CnC)
ET MALWARE ABUSE.CH SSL Blacklist Malicious SSL certificate detected (TorrentLocker CnC)
ET MALWARE ABUSE.CH SSL Blacklist Malicious SSL certificate detected (Gozi MITM)
ET MALWARE ABUSE.CH SSL Blacklist Malicious SSL certificate detected (Vawtrak CnC)
Malicious TLS Communication Categories¶
Stamus Security Platform also comes with detections for known malicious TLS-based encryption communication tools. In total, there are over 16,000 TLS Malware detection methods, updated daily.
Stamus Security Platform threat coverage (also known as Declarations of Compromise™) include about 9,442 TLS detection methods – updated daily and constantly growing.
There are also different groups of TLS detection methods for other applications and potentially unwanted applications. For example:
3843 MALWARE
1148 INFO
654 MOBILE_MALWARE
488 ATTACK_RESPONSE
324 PHISHING
122 POLICY
117 JA3
78 EXPLOIT_KIT
49 HUNTING
38 ADWARE_PUP
33 WEB_CLIENT
20 SCADA
19 EXPLOIT
5 COINMINER
1 GAMES
1 CURRENT_EVENTS
Cipher analytics¶
By default, the Stamus Security Platform provides TLS Cipher analytics out of the box. This is done on any and all TLS communication, regardless of the level of encryption. This allows users to identify weak, insecure, unsupported, and not recommended encrypted communications and the endpoints involved with any and all session / flow specifics.
JA4¶
By default, the Stamus Security Platform provides JA4 fingerprinting and identification of any encrypted communication. JA4 is a way of robustly and uniquely fingerprinting an encrypted connection.
Any TLS-based alert or TLS protocol event (even TLS 1.3 with full encryption) will have a JA4 subsection as part of the standard JSON log. The fields ja4.hash and ja4.agent would be added indicating the type of protocol that is being encrypted. This allows for auditing, identification, analysis, and investigation of any TLS-based encrypted connection and the end points involved.
ALPN¶
Application-Layer Protocol Negotiation (ALPN) provides information on what is being encrypted as part of the TLS communication. It can reveal the type of data that is being communicated and provides for security policy violations detection, auditing, and malicious activity like exfiltration.
Any TLS-based alert or TLS protocol event (even TLS 1.3 with full encryption) will have an ALPN subsection as part of the standard JSON log. The fields tls.alpn_tc and tls.alpn_ts would be added indicating the type of protocol that is being encrypted.
Available Dashboards and Visualizations¶
Elasticsearch / Kibana¶
The Stamus Security Platform comes with over 150 different predefined, ready to use visualizations in more than 23 dashboards (in Elasticsearch and Kibana) for different TLS, Flow, Network, and Anomaly analytics. This allows for comprehensive encrypted traffic overview, analysis, audit and reporting.
A few examples of such dashboards follow below:
SN-ALERTS: Alerts dashboard.
SN-ALERTS-CVE: CVE specific alerts dashboard.
SN-ALERTS-PHISHING: Phishing specific alerts dashboard.
SN-ANOMALY: Protocol anomaly events dashboard.
SN-BEACONING-TLS: TLS beacons dashboard.
SN-FLOW: Generic FLOW records dashboard.
SN-FLOW-SIZE: Generic FLOW size based search dashboard.
SN-FLOW-SSH: SSH flow records dashboard.
SN-FLOW-TCP: TCP flow records dashboard.
SN-FLOW-TLS: TLS flow records dashboard.
SN-IDS: Generic IDS alerts timelion dashboard.
SN-IKEv2: IKE protocol events dashboard.
SN-IoC-Search: Search for specific dns-like IoCs/names in DNS Requests, TLS SNIs, and HTTP Hosts records.
SN-KRB5: KRB5 protocol events dashboard.
SN-Network-Overview: Network flow data overview dashboard.
SN-POLICY-OLD-TLS: Older or vulnerable TLS protocol encryption.
SN-POLICY-Violations: TOR, old TLS, External DNS Resolvers, Clear text passwords, Abused file sharing.
SN-RDP: RDP protocol events dashboard.
SN-SIGHTINGS: Newly discovered communication never seen before.
SN-SSH: SSH protocol events dashboard.
SN-STAMUS: Declarations of compromise dashboard.
SN-TLS: TLS protocol events dashboard.
SN-TrafficID: Social media dashboard.
Splunk¶
The Stamus Security Platform also comes with ready-to-use TLS/SSH, Flow, Network, and Anomaly analytics-based visualizations and dashboards for Splunk. This includes over 50 visualizations in 9 different dashboards or reports, allowing for broad detection and in-depth detailed analytics of encrypted communications.
A few examples below from the free to use Stamus Networks App for Splunk:
Stamus Networks Hosts Anomaly
Stamus Networks IDS Dashboard
Stamus Networks IP investigation
Stamus Networks NDR Dashboard
Stamus Networks NSM Anomaly
Stamus Networks NTA Dashboard
Stamus Networks Policy Violations
Stamus Policy Violations
Stamus TLS Analysis
Encryption Services Running on Hosts¶
Host Insights is one of many unique, differentiating features of the Stamus Security Platform allowing users to achieve continuous passive fingerprinting and tracking of hosts and their behavior on the network. One benefit of this is the platform’s ability to identify encrypted services that are available or being used by the hosts and their specifics. This allows for easy identification of unintended, malicious activity or misconfigurations, as well as unauthorized encrypted network services running inside or being served to the organization.
Here are a few examples:
SSH server services running on an end user/ client pc or servers.
Unauthorized FTPS or SSH software running on end points.
Non standard SSH/TLS services port usage
HTTPS Proxy¶
As part of Host Insights, the Stamus Security Platform also automatically detects and highlights HTTPS proxies functioning in the organization. This allows for fast and easy identification of any unauthorized HTTPS proxies in the infrastructure as well as the endpoints and specifics of those using unauthorized services. It can also highlight Policy violations and/or Shadow IT.
Encrypted Transfers¶
Any part of encrypted communication session flow analytics are automatically analyzed and made available as detailed logs by the Stamus Security platform. This allows for detection and review/audit using flow analytics of direction, volume,size, repetitiveness, and other flow metadata pieces of those sessions.
Suspicious Transfers¶
Using flow analytics, SSP can detect or view if there are large or suspicious transfers during off business hours, in an unexpected infrastructure location, and more. Some examples include:
Unusual (time wise) encrypted transfers
SSH/RDP/TLS fromm unexpected locations at 3 am
Very long, big data volume transfers
Exfiltration¶
There can be many forms of exfiltration, including encrypted and/or obfuscated. The Stamus Security Platform automatically analyzes and detects (large) encrypted transfers (such as SSH, TLS, or RDP-based) in and out of the organization or production sites to and from unusual or unexpected locations.
Machine Learning-Enabled TLS Beaconing Detection¶
AI-enabled TLS encrypted beaconing detection is included by default and available on any Stamus Security Platform deployment.
See also
If you want to know more about Beaconing Detection, read this page.
Decryption¶
Existing Deployments¶
Stamus has successful deployments with customers actively using decryption as part of their security monitoring operations infrastructure. In many cases that includes large financial institutions that deploy decryption hardware to different aggregation points of their infrastructure using different vendors like Cisco, Mcafee and others. From those points the decrypted traffic is mirrored back to the Stamus Security Platform where analysis, inspection and detection takes place.
Decrypting HW/Software¶
The Stamus Security Platform can work with most decryption solutions that can deliver the decrypted network traffic in standard PCAP formats. Stamus Networks partners with Mira Security for decryption capabilities. We chose Mira because of their rich history in the field and flexibility to deliver solutions from hardware, virtual machines and in the cloud.