Log4J and The Memory That Knew Too Much

By Guilherme Venere, Ismael Valenzuela, Carlos Diaz, Cesar Vargas, Leandro Costantino, Juan Olle, Jose Luis Sanchez Martinez, AC3 Team

Collaborators: ATR Team (Steve Povolny, Douglas McKee, Mark Bereza), Frederick House (FireEye), Dileep Kumar Jallepalli (FireEye)

In this post we want to show how an endpoint solution with performant memory scanning capabilities can effectively detect active exploitation scenarios and complement network security capabilities your company has implemented.

Background

As it is becoming the norm lately, a new vulnerability affecting a widely used library was recently released just in time for the Holidays. As detailed in our ATR blog, CVE-2021-44228 reported a vulnerability in the Log4J Java library affecting applications and web sites using the library to perform logging.

This vulnerability allows an attacker to coerce the vulnerable site or application to load and execute a malicious Java code from an untrusted remote location. Attack vectors are varied but the most common is associated with the attacker sending crafted strings as part of a network protocol to the target machine, like for example a modified HTTP Header sent as part of a POST request.

That is the reason many defenders are focusing their efforts on detecting the malicious strings through the network traffic. However, network signatures can be bypassed and there are reports confirming threat actors are adapting their network attacks with various forms of obfuscation to defeat network scanning.  The following image shows some of the current obfuscation techniques that have been observed or reported related to this attack.

Source: https://github.com/mcb2Eexe/Log4j2-Obfucation

This doesn’t mean that network protection solutions are not useful against this attack. Network security platforms provide a first layer of defense and should be used as part of a defensible security architecture (security risk treatment strategy), augmented by additional layers of protection, detection, visibility, and response. Modern endpoint solutions are uniquely positioned to complement network-based capabilities with in-depth host-based visibility of system processes, like in-memory scanning and rapid response orchestration. This combination results in a robust defense against threats like Log4Shell.

‘I See You’: Memory Scanning #FTW

To understand how memory scanning can help complement the network security platforms after a connection arrives to the endpoint and defeating the obfuscation layers, let’s take a look at the diagram below, describing the flow of execution for a common web based Log4J attack.

Let’s outline what happens:

In Step 1, an attacker sends a specially crafted string to the web server hosting the vulnerable application. This string, as we have seen, can be obfuscated to bypass network-based signatures.

In Step 2, the application proceeds to de-obfuscate this string to load it in memory. Once loaded into memory, the application initiates a LDAP connection to request the address of where the malicious class is located.

In Step 3, the attacker-controlled LDAP server responds with the location of the malicious Class file by indicating the HTTP URL address of where it is hosted.

In Step 4, the vulnerable application will proceed to initiate a download for that malicious class file.

In Step 5, the vulnerable application will load and run the malicious class file from step 4.

At this moment, the attacker achieves code execution on the target, leaving traces that may provide visibility on this activity for the defender. For example, spawning additional processes or touching files and registry keys after an exploitation

With this in mind, let’s imagine we could trigger a memory scan at some point in this execution flow to detect the presence of the malicious code. In general, scanning the memory of an endpoint is expensive from a processing perspective, therefore it’s not something that can be done continuously or even very often, but under specific circumstances it can be achieved with precision.

So, suppose we could trigger a memory scan at any point after step (2). We would have a high probability to find the de-obfuscated string used within the process memory at that time. If the memory is scanned after the malicious class file is downloaded, that content would also be available for scanning in its de-obfuscated form.

Such possibilities make the memory signature performant, and efficient, given the timing of the detection mainly depends on the trigger used to start the memory scan.

These technical capabilities are possible in ENS, let us show you how to do that!

Endpoint Security Expert Rules meets Memory Scan

In ENS (Endpoint Security) 10.7 update 4 and above, there is a powerful security feature available to every defender, and WE absolutely love it, which is the ability to trigger a memory scan from an Expert Rule.

We have talked about Expert Rules before, these are customizable access control rules which the end-user uses to detect suspicious activity not commonly seen by other scanners. McAfee Enterprise also provides community Expert Rules mapped to the MITRE ATT&CK Matrix through our public GitHub.

The feature we are interested in now is the ability to trigger a memory scan when an Expert Rule fires. That would allow us to target the applications vulnerable to Log4J and identify the moment they are being exploited.

Consider the following rule:

In the example rule above, we see a section defining ACTORS (inside the Process {…} section) and TARGETS (inside the Target {…} section). We define as actors any process that may be vulnerable to the Log4J exploit. In this case JAVA.EXE for standalone Java applications and TOMCAT?.EXE for Apache web-based applications. Either of these processes need to load both JAVA.DLL and JVM.DLL to ensure the Java runtime is active.

In the target section we add any potential payload of the attack. As Expert Rules are not focused on network traffic, we need to focus on the last step of the execution flow, which is when the payload is executed. Additional triggers like files or registry keys accessed can be added as more information about exploits become available. We may also have in this section any exclusion of valid behavior as shown in the example above with the “Exclude” on command line parameter. This exclusion is something customers can tailor to their environment to avoid false positives.

This expert rule will trigger when any ACTOR process spawns any of the TARGET payloads. If the rule were just that, one could see it would not be too effective in detecting the exploit and would probably cause many false positives.

But notice this line at the beginning of the rule:

This instruction tells ENS 10.7 to initiate a memory scan against the ACTOR process which caused the expert rule to trigger, and only that process. Now we have a reliable trigger for a performant memory scan, avoiding the performance issues of a blind memory scan, and it is done at a time very close to the initial exploitation attempt, which guarantees the de-obfuscated string will be in memory.

The second part of this solution is executed by the AV DAT Engine when it scans the memory of the process which triggered the Expert Rule. Once this string is found, a detection will occur, and cleaning will be applied to that process to attempt to stop the exploit from continuing. In ePO, customers will see two events below which indicate an exploit attempt happened:

The first event highlighted above is the Expert Rule triggering for a suspicious process spawning from JAVA.EXE, and the second shows the AV DAT detection indicating the memory of that process had signatures of the exploit.

Note:

IF only the Expert Rule detection was present and NOT the JNDI/Log4J-Exploit event, it would indicate a program has executed children processes considered suspicious, and customers are advised to review the event and improve the Expert Rule accordingly.

However, IF, both the Expert Rule and JNDI/Log4j-Exploit events are triggered for the same program, we have confidently detected the presence of the process being exploited.

McAfee Enterprise provides more information about our current coverage for Log4J vulnerability in KB95901 – McAfee Enterprise coverage for Apache Log4j CVE-2021-44228 Remote Code Execution. This article contain links to download the Expert Rule and the associated EXTRA.DAT, as well as details on how to set up ePO to use them in your environment.

Customers who want to implement this solution are invited to review the instructions in the KB and associated documentation. It is highly recommended to review the Expert Rule and customize it to your environment.

Conclusion

To protect an environment against attacks like LOG4J, a layered strategy comprised of network security coupled by targeted endpoint memory scans allows defenders to effectively detect and prevent the attack execution flow against vulnerable systems exposed via network vectors.

Our ENS Expert Rules and Custom Scan reactions are designed to enable defenders with such capabilities so they can apply precise countermeasures against these emerging threats.