1. Knowledge Base
  2. Analytics
  3. Analytic Technical Guides

IronNet Analytics for Encrypted Communications

This technical guide delves into the Encrypted Communications IronDefense analytics and organizes them based on Cyber Kill Chain.


001_pkb_download_button

Introduction

Attackers who do not want to be quickly detected know they must hide in encrypted traffic. To avoid detection, they attempt to obfuscate and camouflage communications over the TLS (Top Layer Security) protocol, which facilitates encryption and enhances data security. Although the content of TLS messages are encrypted, the handshake is unencrypted. IronDefense uses data from the handshake to evaluate the host for Indicators of Compromise (IoC) and create alerts. This enhances IronNet's suite of analytics that are designed to detect suspicious behavior across all phases of the Cyber Kill Chain. IronNet’s analytics for encrypted communications work together to identify anomalies in network traffic and target behaviors that pose threats to the integrity, availability, and confidentiality of the system. The analytics are:

Phishing HTTPS Unusual Day
Domain Analysis TLS TLS Invalid Certificate Chain
Encrypted Communications TLS TOR TRaffic
Consistent Beaconing TLS Novel JA3
Extreme Rates TLS  

Some of IronNet’s analytics (Phishing, Domain Analysis, Consistent Beaconing, Extreme Rates, and Unusual Day) and the behaviors they detect are agnostic to specific protocols. Regardless of TLS, an attacker will often attempt to gain credentials through a phishing scam, shift domains to obfuscate C2 servers, deliver beacons to and from a C2 server to send and receive instructions, and exfiltrate large amounts of data from the network. IronNet's analytics for these behaviors analyze generic properties of network traffic such as payload size, session timing, and destination domain and, therefore, do not require decrypting what is inside of the payload. Through this agnostic approach, IronNet is able to analyze many types of traffic (DNS, HTTP) while also utilizing unencrypted features from the TLS handshake when available.

Other analytics (Encrypted Communications TLS, TLS Invalid Certificate Chain, TOR Traffic, and Novel JA3) are designed exclusively for the TLS protocol. These analytics identify cases where an attacker utilizes TLS to create a command and control channel, create invalid certificates to attempt to bypass authentication, or hide behind anonymous proxy servers to protect their identities. By parsing the TLS protocol, IronNet can pull Indicators of Compromise (IoC) and other unencrypted features out of the TLS handshake. These features are then used in machine learning and other model-based approaches to classify the traffic by extracting a JA3 hash and validating if the traffic is new to the network, examining the SNI (Server Name Indication), and identifying misconfigurations in the handshake where attackers sometimes leave a footprint.

In addition to analytics, IronNet’s sensor employs signature-based detection with threat intelligence derived from JA3 hashes. Network traffic is checked against a list of known malicious hashes. In addition to analytics, IronNet’s sensor employs signature-based detection with threat intelligence derived from JA3 hashes. Network traffic is checked against a list of known malicious hashes.

Encrypted sessions can represent a blind spot for network detection. IronNet is addressing this by continuously improving our behavioral analytics for encrypted communications, focusing on TLS headers, developing new analytics for anomaly detection of novel JA3 hashes, and implementing signature-based detections for JA3 hashes.


Reconnaissance

Phishing HTTPS

Phishing HTTPS detects when a user visits a domain that may be associated with phishing activity over HTTPS. The analytic examines all SSL (Secure Sockets Layer)/TLS (Transport Layer Security) encrypted communications from internal devices to external domains. The analytic reviews both the SNI (Server Name Indication) and the certificate of the destination. The SNI indicates the hostname of the server being contacted by the web browser at the beginning of the TLS handshake process. An IronDefense alert is created when an internal entity initiates a communication with an external server with a suspicious SNI or certificate.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP

Detection Capabilities

All SSL/TLS communications from enterprise entities are analyzed, and alerts are generated when entities reach out to suspicious SNIs possibly associated with untrustworthy certificates.

Baseline Learning Requirements

Phishing HTTPS uses two different classifiers that are trained with historical data. One is used to quantify SNI suspiciousness and another is used to quantify certificate suspiciousness. It also ingests up to one week of historical TLS data each time it runs, and it uses this history to determine which SNIs are new to the environment.

Minimum Data Requirements
  • Minimum Data Ingest Period: 1 hour, though results are best when a full week of historical data is present.
  • Processing Period: Hourly
MITRE ATT&CK Matrix
  • Tactic: Initial Access
  • Techniques: Spearphishing via Service, Spearphishing Link
Targeted Malware and Behavior

Phishing HTTPS identifies when malicious/phishing domains are visited via the HTTPS protocol. The analytic detects HTTPS SNIs that may be associated with malicious links and fake web content to deceive users into disclosing their credentials. Phishing via HTTPS is on the rise due to the availability of free TLS certificates and users' perceived trust of HTTPS. Examples of malware associated with phishing attacks using HTTPS include GhostPhisher, SpeedPhish (SPF), Gophish, Social Engineer Toolkit (SET), and SP Toolkit.


Command and Control

Domain Analysis TLS

The Domain Analysis analytics alert on suspicious domains that have yet to be seen in the network's environment in the last 30 days. The analytic assesses outgoing communications from an internal host to a new or unusual domain. The communication may be the result of a malware calling back to a domain for instructions or an employee who inadvertently visited a malicious web site. If the domain has not been detected in the past 30 days of traffic, the analytic examines fields within the header, such as the path, referer, and user agent, for unusual activity.

When the analytics flag the activity, IronDefense applies Expert System rules that automate the process of determining if the domain is on an IronDefense or open source block list. IronDefense validates domains against the Majestic Top Million and Cisco Umbrella to ensure customer networks are not communicating with bad domains. IronDefense is also able to determine if the communication is an isolated event, originating from a single user, which would be suspicious, or from many users, indicating a possible scheduled service. After Expert System validates the analytic’s findings, an alert is created and shared with analysts.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP

Detection Capabilities

Identifies new effective top-level domains (ETLDs) within the last 30 days of TLS traffic and extracts interesting features. These new domains are then assessed and prioritized based on characteristics of the domain involved, along with other TLS-specific fields and features.

Baseline Learning Requirements

A minimum of seven days of historical TLS data is required. This data will be stored for up to 30 days.

Minimum Data Requirements
  • Minimum Data Ingest Period: 7 days
  • Processing Period: Daily
MITRE ATT&CK Matrix
  • Tactic: Command and Control
  • Technique: Application Layer Protocol
  • Sub-technique: Web Protocols
Targeted Malware and Behavior

Domain Analysis TLS identifies suspicious new domains by evaluating domains under ETLDs (e.g., co.uk, blogspot.com) that have appeared for the first time in the last 30 days of TLS traffic. These new domains, represented in the TLS SNI, are then assessed and prioritized based on characteristics of the domain involved, along with other TLS-specific fields and features. Examples of malware and tools that abuse TLS include TOR, Ursnif, Gozi, Dridex, and Etumbot.

Encrypted Communications TLS

The Encrypted Communications analytic is designed to detect suspicious activity by evaluating features consistent with malware communications passed through encrypted channels, without the privacy and security costs of traffic decryption. The adoption of encrypted communication methods presents new challenges for network security. As the amount of overall encrypted traffic increases globally, threat actors are using encryption to hide malware in covert communications.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP
Detection Capabilities

Detects incorrect, outdated, or uncommon TLS configurations in encrypted traffic. The analytic examines traffic communicating over the TLS protocol. Although the content of the message is encrypted, the TLS handshake is unencrypted. IronDefense uses data from the handshake to evaluate the host for suspiciousness and create Encrypted Communications alerts.

Baseline Learning Requirements

This analytic does not require historical data for analysis. Alerts can be generated as soon as the analytic starts running.

Minimum Data Requirements
  • Minimum Data Ingest Period: 1 hour

  • Processing Period: Hourly

MITRE ATT&CK Matrix
  • Tactic: Command and Control
  • Technique: Application Layer Protocol 
  • Sub-technique: Web Protocols
Targeted Malware and Behavior

Malware typically uses outdated or incorrect TLS configurations in the handshake to communicate over encrypted channels. By using encrypted forms of communication, the attacker hopes to conceal his or her presence on the network. Examples of malware that leverage TLS for C2 communication channels include Ursnif, Dridex, and Zeus/Panda Banker.

Consistent Beaconing TLS

Malware uses beaconing to communicate back to the attacker in order to receive instructions or report successful implantation. While beaconing activity often executes over regular and fixed intervals, attackers may randomize the behavior by adding jitter to the beacon timing to obfuscate the activity and avoid detection. The Consistent Beaconing analytic detects ongoing patterns of both fixed-interval and randomized-timing beacon activity and places a high emphasis on the most persistent and continuous beaconing signals.

Beaconing is not a technique that is exclusive to malware. Many enterprise software applications use beaconing for operations such as software updates or data retrieval. To increase the efficacy of the alerts, analysts can safe list benign traffic.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP

Additional Data Requirements
  • Requires thorough understanding of telemetry collection allowed on organization assets, the organization’s web proxy structure, and the organization’s internal DNS structure.
  • Logs such as DHCP logs are optional but critical for highly dynamic IP environments to provide host resolution.
  • Sensors must be placed at a location to capture traffic flows from the internal network and the network egress point associated with data centers and branch offices.
Detection Capabilities
  • Analyzes communications from an internal entity to an external destination.
  • Detects periodic and randomized beaconing over a variety of frequencies ranging from seconds to multiple hours.
  • Automatically identifies the source-destination pairs, beaconing frequency, amount of jitter, duration of beaconing, and other behavioral attributes.
Baseline Learning Requirements

The system does not require historical data for analysis. Alerts can be generated as soon as the analytic starts running.

Minimum Data Requirements

Periodic Detection:

  • Minimum Beaconing Duration: 30 minutes
  • Minimum Beacon Frequency: 5 seconds
  • Minimum Number of Beacons: 3
  • Maximum Jitter: 3 seconds
  • Processing Period: Daily

Randomized Detection:

  • Minimum Beaconing Duration: 30 minutes
  • Minimum Beacon Frequency: 5 seconds
  • Minimum Number of Beacons: 25
  • Maximum Jitter: 60%
  • Processing Period: Daily
MITRE ATT&CK Matrix
  • Tactic: Command and Control
  • Technique: Application Layer Protocol
  • Sub-technique: Web Protocols
Targeted Malware and Behavior

Consistent Beaconing identifies when entities generate activity consistent with repetitive attempts by malware to establish communications with a command and control server. The targeted beaconing behavior may either be periodic or obfuscated with randomization. Beaconing activity may indicate the presence of malware attempting to call home. Beaconing is used by a wide variety of malware, with examples including the Havex RAT, the Backoff PoS implant, the Keybase keylogger, the PittyTiger RAT, and the Zeus bot family.


Action 

Extreme Rates TLS

The Extreme Rates TLS analytic detects high-volume TLS data transfers over TCP port 443. The analytic compares entities within a peer group and baselines the average amount of outbound traffic across the group. The analytic monitors the peer groups for significant increases in the number of bytes. When the analytic detects such an increase, an alert is created. While the kill-chain attack methodology remains the same as unencrypted attacks, the true underlying activities are more difficult to identify because the content of the data is encrypted.

Capability Description 
Protocols Monitored

TCP over port 443

Supported Data Sources
  • Network TAP
  • AWS VPC Logs or Azure NSG Logs
  • Zeek IPS Conn Logs
Detection Capabilities
  • Detection of high rates of data exfiltration that occur in bursts over TLS.
  • Designed to report underlining activities that are hard to detect due to obfuscation through encryption.
Baseline Learning Requirements

While the analytic can run immediately, it is more accurate when it has ingested at least five hours of data (one hour of regular ingest, plus four hours of historical data).

Minimum Data Requirements
  • Minimum Data Ingest Period: 1 hour
  • Processing Period: Hourly
MITRE ATT&CK Matrix
  • Tactic: Exfiltration
  • Techniques: Exfiltration Over Command and Control Channel, Exfiltration Over Other Network Medium, Exfiltration Over Alternative Protocol
Targeted Malware and Behavior

Extreme Rates TLS detects when a device is exhibiting anomalously high rates of network data transfer to external destinations via TLS, consistent with hasty exfiltration of data from the enterprise. An Extreme Rates TLS event could indicate that an intruder or malware implant is conducting a “smash-and-grab” attack, racing to move large quantities of data outside the enterprise network before defenders can respond. Data exfiltration can be accomplished using a variety of standard applications and tools, and is also a capability of many RATs and other malware implants.

Unusual Day

The Unusual Day analytic detects when an entity is sending out more traffic than established baseline behavior patterns. IronDefense accumulates patterns of typical network behavior for each host. When the host’s network activity deviates from baseline activity by uploading unusual amounts of data, contacting new resources, or communicating with new devices outside the host’s expected role, IronDefense creates an event and fires an alert for Unusual Day. The analyst must determine if the activity is legitimate, normal browsing or suspicious behavior such as transferring unauthorized data outside of the network.

Capability Description
Protocols Monitored HTTP, TLS, and DNS
Supported Data Sources
  • Network TAP
  • AWS VPC Logs or Azure NSG Logs
  • Zeek IPS Conn Logs
Additional Data Requirements
  • Logs such as DHCP logs are optional but critical for highly dynamic IP environments to provide host resolution.
  • Sensors must be placed at a location to capture traffic flows from the internal network and the network egress point associated with data centers and branch offices.
Detection Capabilities
  • Potential data exfiltration from an internal entity to an external destination over HTTP, HTTPS, or DNS.
  • Identifies unusually large data transfers as compared to the historical rate for an entity.
  • Detects large volumes of data transferred whether it is transferred as a single session or many smaller sessions over a period of time as in the case of “low-and-slow” data exfiltration.
  • Analyzes DNS subdomain characteristics for potential DNS tunneling activity.
Baseline Learning Requirements

This analytic does not require historical data for analysis. Alerts can be generated as soon as the analytic starts running.

Minimum Data Requirements
  • Minimum Data Ingest Period: 7 days
  • Processing Period: Daily
MITRE ATT&CK Matrix
  • Tactic: Exfiltration
  • Techniques: Exfiltration Over Command and Control Channel, Exfiltration Over Other Network Medium, Exfiltration Over Alternative Protocol, Automated Exfiltration, Data Transfer Size Limits, Scheduled Transfer
Targeted Malware and Behavior

Unusual Day identifies when an outbound network data transfer is significantly higher than historical norms for a specific user or device. This activity may indicate a data breach by an active intruder, malware, or an insider threat. For example, an Unusual Day event could indicate that an intruder or malicious insider is attempting to take advantage of off-hours time to transmit sensitive data outside the enterprise network. Data exfiltration can be accomplished using a variety of standard applications and tools, and is also a capability of many RATs and other malware implants.


Other

TLS Invalid Certificate Chain

The TLS Invalid Certificate Chain analytic identifies instances where a destination server’s SSL/TLS certificate could not be validated against a root certificate authority. The analytic is used to quickly identify self-signed or otherwise fraudulent certificates. When these certificates are presented by the server, they are then validated using the certificate issuer, which is generally an intermediate or root issuing authority. If for whatever reason a server certificate or certificate chain cannot be validated with the root authority, an alert is produced.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP

Detection Capabilities
  • Validates all available server certificate chains in a flow and generates events for chains that fail the validation process.
  • Identifies self-signed or falsified TLS certificates.
  • Events include the reason for validation failure, the root certificate issuer, and the root certificate source entity community of interest (COI).
Baseline Learning Requirements

This analytic does not require historical data for analysis. Alerts can be generated as soon as the analytic starts running.

Minimum Data Requirements
  • Minimum Data Ingest Period: Single IronFlow
  • Processing Period: Instant (less than a second)
MITRE ATT&CK Matrix

N/A

Targeted Malware and Behavior

TLS Invalid Certificate Chain validates all available server certificate chains in a flow and generates events for chains that fail the validation process. The analytic is used to quickly identify falsified, invalid, or self-signed TLS certificates. The events include the reason for validation failure, the root certificate issuer, and the root certificate source entity community of interest. Examples of malware that may use invalid certificates include Dridex, Gozi, Chanitor, and Trickbot.

TOR Traffic

TOR (The Onion Router) is an anonymity network frequently exploited by attackers. To disguise the source of malicious traffic, adversaries will leverage TOR to appear to come from any of a number of public or private exit nodes. The TOR Traffic analytic identifies the traffic based on behavioral characteristics of the TLS connection even when the attacker is using a private exit node.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP

Detection Capabilities

Events include the reason for validation failure, the root certificate issuer, and the root certificate source entity community of interest (COI).

Baseline Learning Requirements

This analytic does not require historical data for analysis. Alerts can be generated as soon as the analytic starts running.

Minimum Data Requirements
  • Minimum Data Ingest Period: Single IronFlow
  • Processing Period: Instant (less than a second)
MITRE ATT&CK Matrix
  • Tactic: Command and Control
  • Technique: Proxy
  • Sub-technique: Multi-hop Proxy
Targeted Malware and Behavior

The TOR Traffic analytic targets activity associated with TOR, an open-source anonymous network frequently exploited by threat actors to obfuscate their actual location or source. Examples of malware and threat actors that exploit TOR for malicious purposes include the ZBot/Zeus bot family, APT29/Cozy Bear, and CRASHOVERRIDE.

Novel JA3

The Novel JA3 analytic searches TLS traffic for first-time appearances of JA3 fingerprints. Each novel fingerprint represents a new configuration of the client side of a TLS handshake, which can be associated with applications that are new to the network and in some cases are malicious exploits. Network owners typically enforce policies constraining the set of applications admissible on the network. This means first-time application usage is either associated with a newly approved application or is indicative of a user violating security policies.

Novel JA3 constructs a historical baseline of JA3 fingerprints appearing on the network by recording the complete set of distinct fingerprints that appear each day. In addition, the analytic searches for the appearance of any fingerprints that have never appeared prior in the historical data and publishes events for each of these.

After this initial detection, the analytic further monitors novel fingerprints for a period of 5 days to measure their popularity in terms of the distinct count of source entities, destination entities, and server name indications (SNI) associated with the use of the fingerprint. Fingerprints that are rarely used, as indicated by low values for the aforementioned counts, receive an additional event.

Capability Description
Protocols Monitored TLS
Supported Data Sources Network TAP
Detection Capabilities

A novel JA3 is a JA3 fingerprint that does not appear in the available historical baseline of distinct JA3 fingerprints that have been previously seen on the network. The historical baseline must be at least 14 days long, but can grow as long as 150 days.

Baseline Learning Requirements

This analytic requires a 14-day burn-in period of historical data for analysis.

Minimum Data Requirements
  • Minimum Data Ingest Period: 15 days
  • Processing Period: Daily
MITRE ATT&CK Matrix
  • Tactics: Command and Control, Exfiltration
  • Techniques: Web Service, Encrypted Channel, Exfiltration Over C2 Channel
  • Sub-technique: Asymmetric Cryptography

Targeted Malware and Behavior

Broadly, this analytic monitors for misuse of the TLS protocol. The analytic looks for emerging threats with unique, anomalous TLS implementations, as defined by the network's historical data. One common TLS exploit frequently abused by attackers is the Cobalt Strike Beacon, which uses vulnerabilities in the legitimate tool Cobalt Strike to act as a C2 beaconing point. The Novel

JA3 analytic works best in concert with other analytics, such as Consistent Beaconing and Extreme Rates, so a fuller understanding of the activity is gleaned.


Analytics Applied to Logs

Most analytics for encrypted communications run over raw data collected by the network TAP and converted into IronFlows. The Extreme Rates and Unusual Day analytics are applied to log data as well, as shown in the chart below.

Analytic AWS CloudTrail AWS VPC Logs AZure NSG Logs Azure AD STS Logon Events from Office 365 Audit Logs Microsoft Windows Server AD Logs DNS Logs HTTP Proxy Logs Zeek DNS Logs Zeek HTTP Proxy Logs Zeek IPS Conn Logs
Action - Extreme Rates TLS  

✔️

✔️

            ✔️
Action - Unusual Day   ✔️ ✔️             ✔️