BlogExtraHop threat researchers have observed attackers in the wild using encrypted traffic to avoid detection of Log4Shell attacks. This is consistent with the general trend of cyberattackers using encryption as an evasion mechanism to avoid detection during both the initial intrusion and lateral movement stages of an attack, among others.
The use of encrypted traffic will completely hide post-compromise Log4Shell activity from many security detection and investigation tools. Security practitioners should examine their security tooling to determine whether they have sufficient decryption and traffic inspection capabilities to catch encrypted Log4Shell-related exploits and the subsequent post-compromise threat behavior, which can include installation of coin miners, ransomware delivery, and data exfiltration, among others.
How Encrypted Log4Shell Attacks Work
Log4j exploits work by prompting the Log4j library to reach out to an external, attacker-controlled source and retrieve a Java class, which is then executed. Here's a nifty graphic showing the sequence of events:
Learn More from DarkReading: Close the Visibility Gap with Strategic Decryption
Multiple encrypted protocols can be used in Log4Shell attacks. For this example, we will focus on the most common: HTTPS. Attack steps at both the initial intrusion and post-compromise stages of a successful attack can be executed using unencrypted HTTP or encrypted HTTPS. In these steps malicious JNDI requests may be included in one or more of the fields included in all HTTPS requests.
These malicious JNDI requests can be detected in plaintext HTTP traffic. But if the traffic is encrypted, the malicious requests are hidden from the view of security analysts and their tools unless they have some way of decrypting the traffic. Reveal(x) is able to securely decrypt HTTPS traffic, completely out of band, to detect and investigate these attacks with full access to the malicious JNDI strings. Security tools without decryption capabilities will not catch encrypted versions of this attack.
The annotated screenshot below shows a set of HTTP and HTTPS transaction records observed by ExtraHop Reveal(x). You can see various characteristics of the requests, including:
- Which port the request came over: We can see port 80, which is default for unencrypted HTTP, and port 443, the default for encrypted HTTPS
- User Agent field containing malicious JNDI payloads, indicating a Log4j exploit
- Origin field, also containing malicious JNDI payloads
It is critical to note that the important information about which devices had been attacked with a Log4Shell exploit—and how they had responded—would be completely hidden in the encrypted traffic on port 443. The reason we can see it in this screenshot is that Reveal(x) 360 is able to decrypt HTTPS traffic for inspection in a secure way that does not violate any security or privacy requirements. Without this capability, threat detection tools that rely on pattern or string matching, or even behavior to some extent, would see nothing of interest here. Security analysts and investigators would be unable to access these details, and the attacker would be free to continue exploiting.
Identifying information in this screenshot has been redacted.
Post-Compromise Activity from Log4Shell Attacks
As a remote code execution (RCE) vulnerability, the Log4Shell vulnerabilities can be the starting point of nearly any type of attack campaign. A few post-compromise activities that have been observed in the wake of Log4Shell exploits include:
- Coin miner activity: specifically the installation of XMrig. Reveal(x) is able to detect this post-compromise activity by identifying usage of the Stratum coin mining protocol.
- Ransomware delivery: As one of the most profitable attacker strategies, it was inevitable that ransomware would start to be delivered via Log4Shell. Reveal(x) has several mechanisms for detecting and responding to ransomware attacks. Reveal(x) ransomware detections are driven by behavioral monitoring, and can work regardless of the delivery mechanism.
- Lateral Movement: Attackers don't stop when they compromise a machine in a target environment. They move laterally, using encrypted protocols to affect other devices on the network, to establish persistence, and to expand their reach to ultimately achieve more impact, whether by exfiltrating data or distributing ransomware more widely. Reveal(x) is able to detect lateral movement and living off the land tactics, including abuse of Active Directory systems and remote access protocols such as MSRPC, PSExec, and more.
A Note on Log4j and Supply Chain Attacks
It became increasingly clear in 2021 that software supply chain attacks represent a source of risk that can affect anyone. The SolarWinds SUNBURST attack, and the Kaseya/REvil attacks used the software supply chain to gain unauthorized access and inflict massive damage on thousands of organizations. Log4Shell exploits are different in that they exploit a zero-day vulnerability that was not maliciously introduced by attackers. But Log4j is so ubiquitous that many vendors are susceptible to it, especially in their development environments and continuous integration and continuous delivery (CI/CD) pipelines. This widespread availability of a zero-day vulnerability makes it likely to be exploited. Anyone using software must assume their providers are vulnerable and take measures to secure their supply chain, in addition to their own network.
Log4j is a widely used component that is present in many, many systems and pieces of software worldwide. It is likely that many people and companies vulnerable to this attack are not yet even aware that they are vulnerable. For security practitioners and vendors alike, it is important to investigate internally and to check with any vendors and service providers you work with to assure that they are taking steps to protect themselves and you!
How to Detect Log4Shell Attacks in Encrypted Traffic
To detect encrypted Log4Shell attacks, you have to be decrypting the right traffic. The ability to decrypt traffic for inspection is a standard feature of Reveal(x). Customers have complete control over whether it is enabled and granular control over which traffic streams to decrypt for inspection. ExtraHop customers with decryption enabled for HTTPS traffic streams where Log4Shell attacks are likely to occur will be able to detect and investigate attacks with the details shown in the above screenshot.
If you're a current customer and want to enable decryption capabilities in Reveal(x), visit the SSL/TLS decryption page of the ExtraHop documentation website.
For help identifying which traffic to decrypt to make it easier to detect and respond to Log4Shell, please reach out to your ExtraHop account contact.
If you're not an ExtraHop customer and want to learn more about strategic decryption and how it can help detect today's advanced attacks, check out our white paper Encryption vs. Visibility: Why SecOps Must Decrypt Traffic for Analysis.
