How to detect Log4Shell exposure and exploitation

The string of vulnerabilities found over the past few weeks in the widely used Log4j open-source Java component continue to keep enterprise security teams busy. While patching the impacted library should be the priority, identifying all affected applications and servers on big networks is not straightforward due to indirect software dependencies and third-party products.

The problem is the more time it takes organizations to find potentially exposed assets, the more time attackers have to find them and exploit them. Different groups of attackers are currently exploiting the remote code execution flaws, ranging from state-sponsored cyberespionage actors to ransomware groups and cryptocurrency mining and DDoS botnets.

It’s therefore vital that organizations not only identify vulnerable assets and put in place a mitigation strategy, which might be different for every case, but also look for indicators of compromise and exploitation attempts in their servers and application logs.

Detecting vulnerable applications and servers

The security community has developed and released multiple open-source tools that can be used to scan directories and file systems for instances of vulnerable Log4j packages, and commercial vulnerability scanners have also added detection for this vulnerability. However, all scanners can have blindspots and that’s particularly true when dealing with Java components like lLog4j.

First, while many Java packages come packaged as JAR (Java ARchive) files, this is not the only format used for Java application deployment. There’s also TAR (uncompressed Tape Archive), WAR (Web Application Archive), EAR (Enterprise Application Archive), SAR (Service Application Archive), PAR (Portlet Archive), RAR (Resource Adapter) and KAR (Apache Karaf Archive).

Furthermore, JARs themselves can be of various types. Packages called Uber JARs or Fat JARs contain Java programs and all their dependencies, but can be shaded, unshaded or nested. A nested JAR contains other JARs and it can go several levels deep.

This means that a vulnerability scanner with support for Log4j flaws needs to have support for all these application formats and nesting. Simply scanning a directory for JARs with Log4j in their names can miss a lot of instances.

Transitive or indirect dependencies further complicate the issue. Scanning just for the primary dependencies of an application is not enough, because Log4j can be a dependency of a dependency. According to an analysis by researchers at Google, as of December 19 there are over 17,000 packages on the Maven Central Repository of Java components that depend on Log4j and only 25% of them have released a fixed version. This means the flaw directly impacted nearly 4% of the ecosystem, but 80% of those packages are impacted as a result of indirect dependencies, which means they don’t have Log4j listed as a direct dependency. Instead they depend on other packages that pull in Log4j and, according to Google, for a majority of them, this goes five or more levels deep.

Researchers from software composition analysis and vulnerability management firm Rezilion tested several open-source Log4j vulnerability scanning tools and three commercial vulnerability scanners that are market leaders and found detection blindspots with all of them. Some scanners did better than others, but none of them were able to detect all instances of Log4j in all scenarios the researchers used. The scanners tested included: Qualys, Tenable, Rapid7, Anchor’s Grype, Palantir’s log4j-sniffer, Aqua Security’s trivy, JFrog’s log4j-tools, MergeBase’s log4j-detector and OWASP’s Dependency Checker.

“Rezilion’s research demonstrates the limitations of static scanning in detecting Log4j instances, and highlights the need for code-level visibility in runtime memory where the code isn’t packaged or nested,” the Rezilion researchers said in a blog post. “It also reminds us that detection abilities are only as good as your detection method. Scanners have blindspots. Security leaders cannot blindly assume that various open source or even commercial-grade tools will be able to detect every edge case – and in the case of Log4j there are a lot of edge instances in many places.”

The conclusion is that organizations should scan with multiple tools, not just their commercial vulnerability scanner, since they might get different results with different scanners. In addition, if they have access to an application’s source code, they should use software composition analysis tools and code vulnerability scanners that account for transitive dependencies. Ultimately, these scanning blindspots highlight why it’s important to continuously look for exploitation attempts and potential compromises.

Detecting exploitation of the Log4j vulnerability

Similar to detecting vulnerable Log4j instances, catching all exploitation attempts in log files is not straightforward because there are various ways for attackers to obfuscate their malicious requests. Even when signs of exploit activity are found in a server log file, it does not mean those exploitation attempts were necessarily successful.

Many automated attacks will indiscriminately try to exploit all Java applications, whether or not they actually use Log4j, and this is another example where attacking is much easier than defending. Defenders will have to follow up exploit detections with deeper forensic investigations into whether the targeted applications actually use Log4j or not. If those apps have previously been cleared, they should be checked again with additional scanners because Log4j might be present as a transient dependency or in a nested JAR.

A search for known indicators of compromise and artifacts associated with currently known Log4j attacks should also be performed before ruling out a compromise and this all falls under the inexact science of threat hunting. Here are some of the free tools and resources that can help defenders:

• Researcher Florian Roth of Nextron Systems created a log analyzer called Log4Shell Detector as well as YARA rules with Log4j IOCs. Nextron’s free multi-platform IOC and YARA scanner called THOR Lite can also be used.
• Researcher back2root created a RegEx (regular expression) called Log4Shell-Rex that can be used from the command line or any SIEM to search logs for indicators of Log4Shell exploitation, including those using various obfuscation techniques. The RegEx attempts to strike “a reasonable tradeoff between detecting as many attack attempts as possible with an acceptable number of false positives,” so it should work well against most attacks, but sophisticated attackers can find a way around it if they want, the researcher warns.
• Mandiant created two open-source tools to detect exploitation attempts of Java deserialization flaws in general. This is an entire category of vulnerabilities that includes Log4Shell.
• Palo Alto Networks has also created various Log4Shell rules that can be used to audit cloud logs as well as processes and outbound connections in network environments.
• Microsoft’s Azure team has created multiple detection rules for Log4Shell IOCs for use with Azure Sentinel.
• Curated Intel, a volunteer community of private researchers from around the world has profiled active exploitation threats related to Log4Shell and has parsed and vetted several IOC feeds from multiple security firms including AlienVault, KPMG and Equinix, as well as lists of known vulnerable products.
• NCC Group released detection rules that can be used with open-source network threat detection engine Suricata as well as a list of IOCs.
• The CISA advisory contains links to additional free resources with detection rules and IOCs curated from trusted vendors and researchers.