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

Support the originator by clicking the read the rest link below.