The Biggest Sale of the year is now LIVE! Get Up-to 80% OFF Across All Certification, Enroll Now!

Investigating Domain Fronting-Based Attacks and Cutting-Edge Detection Strategies

In-recent trends adversaries are increasingly targeting on-premise/cloud infrastructure, including critical servers and systems within an organization’s to gain or maintain long-term persistence via C2 servers. In this blog we will be investigating traditional and modern C2  Attacks and Cutting-Edge Detection Strategies.

An Detailed overview of C2 Communication

Evolution of Domain Fronting-Based Attacks

Advanced investigation and detection

An Detailed overview of C2 Communication

C2 generally termed as Command and Control, is an adversarial technique which is typically used to maintain stable communication with compromised victims.

This technique is commonly used to maintain a stable persistence with the victim, on successfully achieving such stuff the adversarial can successfully create a communication channel which most probably used to transmit instructions/command and data to the infected machine.

Common patterns involved in C2 communication

  • Initial Compromise : The attacker gains initial access to the target system through various means such as phishing emails, software vulnerabilities, or weak passwords.
  • Implant Installation : The attacker installs a malicious implant or malware on the compromised system. This implant establishes a connection back to the attacker’s C2 infrastructure.
  • Beaconing : The implanted malware periodically sends “beacon” signals to the C2 server to signal its presence and readiness to receive commands.
  • Communication Encryption : The C2 communication is often encrypted to evade detection by security controls. Encryption ensures that the communication remains covert and difficult to intercept.
  • Command Transmission : The attacker sends commands and instructions to the compromised systems through the C2 server. These commands can include tasks such as exfiltrating data, executing additional malware, or conducting reconnaissance.
  • Data Exfiltration/Persistence : The compromised system may be instructed to exfiltrate sensitive data to the attacker-controlled C2 server. This data could include personally identifiable information (PII), intellectual property, or financial information.

Detecting and responding to traditional C2 communication:

In-recent trends many organizations have developed proactive strategies to detect, respond, and mitigate an traditional C2 communications and exploits:

In-general Security teams specifically monitor the outbound network traffic to detect signs of C2 communication. This can be achieved by analyzing network traffic patterns and anomalous behaviors.

As we know that the traditional C2 communication has been requested directly from the C2 server itself in such case the C2 ip will be exposed to the security team and many organizations have implemented policy to directly restrict out-bound network communication from the internal network.

Evolution of Domain Fronting-Based Attacks:

AS many traditional C2 communications are easily detectable, the adversaries create a new methodology to evade such detection. This is typically named as Domain Fronting-Based C2 Communication.

Domain fronting is a technique used to conceal the destination of network traffic by leveraging content delivery networks (CDNs) or other intermediary services.

The above architecture diagram gives us a clear working representation of the Domain Fronting-Based C2 Communication where the CDN act as a intermediary between C2 and the targeted victim, the request and response from the victim and C2 are communicating via HTTPS protocol, these process makes the security detection much harder and stealthier.

Common detection issues associated with C2 communication

Detecting Command and Control (C2) communication poses several challenges due to the evolving tactics and techniques used by attackers to evade detection.

One of the most challenging issues associated with C2 communications are the encrypted C2 traffic which uses secure protocols like HTTPS, making it challenging to inspect the content of the communication. Traditional packet inspection may not reveal malicious activities hidden within encrypted connections.

In general, It was practically impossible to decrypt the communication request without the encryption key.

One of the solutions which might work when the host has been implemented with some methodology to inspect TLS and SSL communication, a tool such as PolarProxy will help in connecting to external TLS servers on behalf of clients on a network. This mode is typically used in order to intercept and monitor encrypted HTTPS traffic from clients.

Even if the traffic is encrypted the PolarProxy runs as a local HTTP proxy server, which only supports the CONNECT request method. Every TLS traffic passing through PolarProxy’s HTTP CONNECT proxy will be decrypted and re-encrypted regardless of port.

But in many real time monitoring cases this methodology will fail, it is not possible or recommended solutions, Implementing such stuff will result in more resource consuming and impact the productivity of an organization. This has been generally used in multiple malware analysts and security researchers for identifying their pattern and behavior.

Advanced investigation and detection of Domain Fronting-Based C2 Communication

Analyzing and investigating Network Traffic pattern

It is recommended to examine the network traffic for signs of beaconing, which is a regular and periodic communication pattern often associated with C2 activity. As in case of Domain Fronting it won’t be useful to monitor non-standard ports or unusual protocols, because it will communicate via port 443.

Blocking HTTPS/port 443 hinders employees from accessing essential tools and services and it typically impacts the productivity of the organization.

In such cases it’s been recommended to investigate the network traffic pattern of the “beacon” signals to the C2 server.  Generally The implanted malware periodically sends “beacon” signals to the C2 server to signal its presence and readiness to receive commands.

In case of C2 communication the victim machine will generate a Client Hello message to the C2 to signal its presence and readiness. These client hello will be sent on frequent intervals of 5/10 Sec from the victim machine,

As per the above packet capture we can clearly observe the Client Hello communication on the frequent interval by co-relating such activity will help you to identify an C2 communication.

Implant detection using Endpoint Monitoring.

Implement EDR/XDR solutions which typically help in real-time monitoring, detection, and response capabilities. EDR/XDR tools often use advanced heuristics, machine learning, and threat intelligence to identify malicious activities on endpoints.

It is recommended to Integrate threat intelligence feeds into endpoint monitoring to stay updated on known indicators of compromise and emerging threats. This enables quicker detection of implants based on known malicious signatures.

Fingerprinting with JA3

As in case of C2 the tools and mechanism might get changed frequently but it responds to the malware/C2 client in exactly the same way; it mostly does not deviate.

JA3 correlation methodology will help us in identifying and categorizing different types of software or libraries based on their unique fingerprints generated during the handshake process, JA3 typically get generated based on their cryptographic characteristics of the SSL/TLS handshake. Each unique SSL/TLS handshake will result in unique JA3 fingerprinting.

Common advantages of JA3 Fingerprinting

  • Granular Client Identification

JA3 fingerprints offer a fine-grained level of identification for SSL/TLS clients. Which typically result in precise identification beyond basic categories.

  • Detection of Malicious Activity

It’s been commonly used as a part of threat detection and incident response strategies. Unusual or malicious JA3 fingerprints may indicate the presence of a specific type of malware, a malicious tool.

  • Signature-Based Detection
    JA3 generally provides a unique signature-based approach rather than being detected based on the file hash or an IP reputation,  JA3 uses specific SSL/TLS client behaviors. Security systems can use these signatures to identify known clients or flag anomalies based on deviations from expected JA3 fingerprints.
  • Adaptability to SSL/TLS Changes

Since JA3 is based on cryptographic properties observed during the handshake, it can adapt to changes in SSL/TLS implementations and configurations. This adaptability makes it robust against changes in client behavior over time.

Basic Working of JA3 Fingerprinting

JA3 fingerprinting value is calculated by collecting the decimal values of the bytes for the following fields.

  • Version
  • Accepted Ciphers
  • List of Extensions
  • Elliptic Curves
  • Elliptic Curve Formats

The collected decimal values are then hash to MD5 format and resulted with 32 character fingerprints.

Using JA3+JA3S Fingerprinting technique to identify the C2 communication

As we are aware that these fingerprinting are calculated based on the SSL/TLS, The JA3 would be common in the environment and therefore not as useful for detection. This is where JA3S can assist in identifying the malicious communication.

JA3S allows for the identification and categorization of SSL/TLS servers based on the cryptographic characteristics observed during the server’s handshake process.

Just as JA3 provides fine-grained identification for SSL/TLS clients, JA3S offers a granular level of detail for identifying and differentiating between various SSL/TLS server implementations.

Working Example

Let us consider Metasploit’s Meterpreter and Cobalt Strike’s Beacon use a Windows socket to initiate TLS communication. In such cases we observe the below pattern.

(JA3=72a589da586844d7f0818ce684948eea OR JA3=a0e9f5d64349fb13191bc781f81f42e1)

JA3S=70999de61602be74d4b25185843bd18e 

So if we combine JA3 + JA3S, we are then able to identify this malicious communication regardless of destination IP, Domain, or Certificate Details.


Reference:

TLS Fingerprinting with JA3 and JA3S