News is spreading fast about the recent CVE-2021-44228 Log4Shell vulnerability. SANS noted that the first exploit seen by Cloudflare was 4:36 GMT on December 1st. This was eight days prior to the Proof of Concept (PoC) exploit published on GitHub on December 9th. SANS saw first attempts at 12:32 PM on December 9th.
In this blog, we will show you how to detect the vulnerability using the LogRhythm NextGen SIEM Platform (you can use the advice and detections outside of LogRhythm, too). The primary method of detection discussed in this blog is around exploit attempts using the User Agent string in web requests. The RegEx sample given by LogRhythm below should help you detect potential attacks in your environment. We will also demonstrate how MistNet by LogRhythm is able to detect a PoC exploit.
The known Indicators of Compromise (IOCs) relevant to this attack are comprised of IP addresses that have been observed attempting to exploit the vulnerability and contents of the requests being sent. The log sources with the best visibility into these IOCs will be firewalls, intrusion detection systems, web application firewalls, and proxies. While these log sources can potentially provide detection for the initial exploit, keep in mind that IOCs change over time and there are many possible variations of this attack that can evade rules-based detection.
Your detection stance should also look for abnormal behavior on the servers using log4j in your environment. Abnormal behavior includes unusual process behavior and unusual outbound network connections from the server. Endpoint logging, such as operating system logs and endpoint detection and response (EDR) observations will help greatly in rounding out the behavioral detections.
LogRhythm SOC Detections with SIEM
LogRhythm’s Security Operation Center (SOC) has created a detection rule based on observed attempted attacks. Zack Rowland and Eric Brown’s approach focuses on exploit attempts present in the “User Agent” field within LogRhythm. The following RegEx is being used to detect the attack:
According to our SOC team, you should exclude your known vulnerability scanners from this rule’s detection.
We have included the AIE rule that you may use in your LogRhythm deployment here. Note that this rule has not been fully tested, and using RegEx in detection can cause a degradation in AIE if utilization is high. Please tune the rule to only consider logs sources that would contain the possible attack in User Agent.
On December 13, 2021, SANS presented a webcast called “What do you need to know about the log4j (Log4Shell) vulnerability.” Based on the information shared, there are some novel detections you could take in detecting possible attacks. The two novel detections are:
- Servers talking to new hosts
- Host connected to DNS host by IP address
According to SANS, “New related attacks will likely come based on the focus of this vulnerability.” Therefore, detecting these behaviors is critical.
LogRhythm has a Community post on a few behavioral detections that would be applicable here.
Detecting Log4Shell Exploit with MistNet by LogRhythm
MistNet detects network traffic associated with the Log4Shell exploit. Figure 2 demonstrates a Log4Shell exploit attempt detected by MistNet’s Rules Engine. As seen in Figure 3, MistNet provides a rich set of metadata along with the detection, including the payload which triggered it. In this instance, the exploit was delivered via the X-Api-Version header.
There are many ways for attackers to obfuscate the exploit to evade detection, which is why a layered detection approach is crucial. MistNet addresses this in several ways:
- MistNet signature-based rules are updated daily, automatically providing more detection opportunities as they become known.
- It continually builds behavioral activity baselines both for discrete hosts and for peer groups, providing opportunity to surface a change in the network activity from normal.
- MistNet incorporates threat intel which is updated daily providing IOC based detections.
- The platform provides enrichment and contextualization for all traffic, providing a solid basis for threat hunting and traffic analysis.
It is also worth considering not only the network activity related to the initial exploit attempt but also unusual process activity and network connections from servers running log4j. For example, search for external traffic to ports associated with the exploit (eg 389, 1389, 1099).
An example evasion technique for this exploit can be found here.
Additional Resources to Defend Against CVE-2021-44228 Log4Shell
The following resources will be helpful in detecting, mitigating, preventing, and responding to CVE-2021-44228 Log4Shell:
- Log4Shell: RCE 0-day exploit found in log4j, a popular Java logging package
- CVE-2021-44228 – Log4j 2 Vulnerability Analysis
- Exploiting JNDI Injections in Java
- CVE-2021-44228 – Log4j RCE 0-day mitigation
- log4j RCE Exploitation Detection
- mubix /CVE-2021-44228-Log4Shell-Hashes
There are a number of IOCs being published by various security researchers and corporations like Microsoft. You can use LogRhythm’s Threat Intelligence Service (TIS) with lists of IOCs. You can learn more about TIS here.
LogRhythm’s SOC has compiled an IOC list of IPs that have been observed using attack patterns. The list can also be downloaded here and used in your LogRhythm environment.
You may also want to reference LogRhythm’s previous blog post, “How to Detect and Search for SolarWinds IOCs in LogRhythm,” covering how to import lists from 3rd parties.
- Fenrir: Fenrir is a simple IOC scanner bash script. It allows scanning Linux/Unix/OSX systems for vulnerable log4j instances and Indicators of Compromise (IOCs)
*** This is a Security Bloggers Network syndicated blog from LogRhythm authored by Kelsey Gast. Read the original post at: https://logrhythm.com/blog/cve-2021-44228-log4shell-detection/