Take a Product Tour Request a Demo Cybersecurity Assessment Contact Us

Stories

The latest cybersecurity trends, best practices,
security vulnerabilities, and more

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: Steve Povolny, Douglas McKee, Mark Bereza, Frederick House, Dileep Kumar Jallepalli

There is never a dull moment in the cybersecurity industry and there is no better time than now to embrace this notion as an advantage and catalyst for business empowerment.

Currently, professionals across the globe continue to combat the latest threat facing businesses where no vertical is immune. We’ve seen an increase in the analysis and patching of the Log4Shell vulnerability in the Apache Log4j Java-based logging platform for a good reason - Log4j is one of, if not the most popular logging applications used by developers. But businesses also need to think beyond patching, as we are seeing Log4Shell shift what we think of as an attack surface.

The potential for large-scale damage and this vulnerability to proliferate is high, so this impact must be taken seriously now to better plan and safeguard against the next major flaw.

While patching is critical, it shouldn’t be a static or one-time fix to ensure infrastructure security. Instead, an always-on approach combining extensive monitoring, assessment, scanning, and forensics must be implemented to provide the agility needed against today’s more modern threats.

Specifically, in this post we show how an endpoint solution with performant memory scanning capabilities can effectively detect active exploitation scenarios and complement your company’s network security capabilities to create a new kind of resiliency for your organization.

Background

As those across the security industry are aware, yet another new vulnerability affecting a widely used library was released just in time for the 2021 holiday season. CVE-2021-44228 reported a vulnerability in the Log4j Java library affecting applications and web sites using the library to perform logging.

The vulnerability allowed 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, for example a modified HTTP Header sent as part of a POST request.

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


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

Now, this doesn’t mean that network protection solutions are not useful against this attack! In fact, Log4j is proving just how critical it is for defenders to be as adaptable as attackers and enter a new era of living security – embracing a more dynamic approach and mindset. Network security platforms provide a first layer of defense and should be used as part of an embedded 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, such as in-memory scanning and rapid response orchestration. This combination results in a robust defense against threats like Log4Shell and allows businesses to build back confidence via end-to-end security.

‘I See You’: Memory Scanning #FTW

Memory scanning can provide further value and help network security platforms when a connection arrives to the endpoint after defeating the obfuscation layers. The diagram below shows the execution flow for a common web-based Log4j attack.



Let’s outline what happens:

  • Step #1: An attacker sends a specially-crafted string to the web server hosting the vulnerable application. This string, as we see, can be obfuscated to bypass network-based signatures.
  • 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 file is located.
  • 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.
  • Step #4: The vulnerable application will proceed to initiate a download of the malicious class file.
  • 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. This can include spawning additional processes or touching files and registry keys after an exploitation.

Imagine if we could outsmart the obfuscation tactics? You absolutely can – and should – to get ahead of threats like Log4j. This can be accomplished by triggering a memory scan at some point in this execution flow to detect the presence of the malicious code file. 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.

Endpoint Security Expert Rules meets Memory Scan

Our solution allows organizations to do just that, delivering the ability to trigger a memory scan from an Expert Rule.

Expert Rules are customizable access control rules that end-users employ to detect suspicious activity not commonly seen by other scanners. We also provides community Expert Rules mapped to the MITRE ATT&CK Matrix through our public GitHub.

These capabilities let us target the applications vulnerable to Log4j and identify the moment they are being exploited. Consider the following rule:



Here we see a section defining ACTORS (inside the Process {…} section) and TARGETS (inside the Target {…} section). ACTORS are any process that may be vulnerable to the Log4j exploit. In this case, we see 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.

The TARGET section includes any potential payload from 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 can also include any exclusion of valid behavior as shown in the example above using “Exclude” as the command line parameter. This exclusion is something customers can tailor to their environment to avoid false positives, creating better efficiencies when combating threats.

This Expert Rule will trigger when any ACTOR process spawns any of the TARGET payloads. It is important to note how certain nuances can affect outcomes and false positives. Take a look at this line at the beginning of the rule:



This instruction initiates a memory scan against the ACTOR process which caused the Expert Rule to trigger. Now we have a reliable trigger for a performant memory scan, avoiding any performance issues that could arise from a blind memory scan. A bonus is that this scan is done at a time very close to the initial exploitation attempt, which guarantees the de-obfuscated string will be in memory.

Next, we scan the memory of the process which triggered the Expert Rule, executed by the AV DAT Engine. Once this string is found, detection will occur on the affected process, and the action configured in the Expert Rule REACTION line will be applied. We recommend you use the REPORT action initially until you have sorted out what processes you need to monitor.



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 the Expert Rule detection was solely present and NOT the Java Naming and Directory Interface (JNDI)/Log4j-Exploit event, it would indicate a program has executed suspicious children processes, 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.

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

If you’d like to implement this solution, we encourage you 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 so you’re not only thwarting or responding to active risks, but also dynamically adapting to safeguard against evolving threats.

Conclusion

To protect an environment against attacks like Log4j, a layered, embedded strategy comprised of network security coupled with 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 you with such capabilities so you can apply precise countermeasures against these emerging threats and gain the upper hand and more confidence to maintain and grow your business.

M'informer

La cybersécurité n'a plus aucun secret pour nous. Mais nous sommes une nouvelle entreprise.
Suivez notre actualité et nos nombreux projets.

Indiquez une adresse e-mail valide.
Nous ne vous enverrons jamais de courrier indésirable. Si vous le souhaitez, vous pouvez vous désabonner à tout moment.