Log4j by Another Name. It's Coming; How Can You Keep Pace? - Exabeam

Log4j by Another Name. It’s Coming; How Can You Keep Pace?

Published
May 11, 2022

Author

Reading time
5 mins

For the last couple of months, the cybersecurity field has experienced multiple challenges as a result of the discovery of the Log4j CVE-2021-44228 vulnerability. This vulnerability still remains a serious danger and continues to put hundreds of millions of devices at risk of being remotely attacked.

Log4j is part of the threat family of Remote Code Execution (RCE) where the vulnerability is allowed to execute code in multiple ways, either by a basic Web Request:

Log4j by Another Name

or by a modification of the agent string to be used with a browser, and allows a deployment of the payload to execute arbitrary code.

While Log4j was new to us, we are very familiar with RCEs and their devastating impact. 

Other historical RCEs of note

Another famous and longstanding RCE was EternalBlue MS17-010, which allowed attackers to manipulate memory allocations to give them the ability to control the execution of malicious code. Like Log4j, this also allowed remote code and command execution on target machines.

And who could forget about Shellshock CVE-2014-6271? This was another RCE that was just as impactful as Log4j where the request could get modified with a simple payload that allowed attackers to execute commands with a simple:

Log4j by Another Name

In simpler terms:

Log4j by Another Name. It's Coming; How Can You Keep Pace?
  1. The attacker modifies the payload.
  2. The payload gets into the site that is prone to the vulnerability.
  3. The website gets the request and sends the execution to the back-end server.
  4. The back-end server presents the executed code to the attacker.

These aren’t new or particularly complicated attacks, so why are we missing them? If the tactics, techniques, and procedures (TTPs) remain the same, why do new RCEs in the wild become such major threats?

Organizations seem to be overcompensating on detection versus behavior analysis. Buying more endpoints increases detection telemetry, but misses the nuance to detect anomalous behavior. Detection approaches that focus primarily on rules and signatures are great for known knowns (IOCs) but fall short of detecting behavior (TTPs). 

Detecting RCEs with signatures is no easy task, since every single one requires its own signature and unique behavior depending on what service it tries to impact. Detecting it involves extensive code review and, if it’s an updated version of an existing threat, waiting for the signature or the update of that same code.

How can you be prepared?

Most likely, you are going to find a malicious automated tool testing the vulnerability from a script remotely, so the first thing you have to be on the lookout for is some sort of scan or network abnormality. This means checking your network logs and security alerts; focusing on understanding its behavior by answering the following questions:

  1. Is this alert source the first time I am detecting it reaching out to my exposed service?
  2. Is this the first time my service is executing an abnormal request?
  3. Is this the first time the server from my DMZ is executing this abnormal command?
  4. Is this server connecting to this abnormal location on the internet?

Understanding how this type of threat behaves will not only enable you to detect the most recent RCE, but it will prepare you for the future — we know it will appear again because it has already happened. If it worked one time, new strains of these attack techniques will reappear, as with the following vulnerabilities:

Signatures work. They are useful today and will continue to be down the road. It will always be a good practice to search through your logs and your signature-based alerts. But the best path for success with these types of attacks is developing an understanding of the behavior of users and entities in your environment. Not only will you be able to detect and respond to Log4j, but this will provide you zero-day protection against whatever it is called next time.

Exabeam Security Research Team (ESRT) Mission Statement:

The ESRT strives to provide unique insight into how we look at the world of cyberthreats and risk by highlighting the common patterns that different threats and threat actors use, and why we need to reorient our detections and priorities to tactics, techniques, and procedures (TTPs) vs. indicators of compromise (IOCs).

We aim to share a newer ideology of investigating threats by answering the following questions: “who, what, and how”.

Similar Posts

The 4 Steps to a Phishing Investigation

What Can We Learn From the Lapsus$ Attacks?

Incident Response: 6 Steps, Technologies, and Tips




Recent Posts

Exabeam News Wrap-up – Week of September 19, 2022

Exabeam News Wrap-up – Week of September 12, 2022

The 4 Steps to a Phishing Investigation

See a world-class SIEM solution in action

Most reported breaches involved lost or stolen credentials. How can you keep pace?

Exabeam delivers SOC teams industry-leading analytics, patented anomaly detection, and Smart Timelines to help teams pinpoint the actions that lead to exploits.

Whether you need a SIEM replacement, a legacy SIEM modernization with XDR, Exabeam offers advanced, modular, and cloud-delivered TDIR.

Get a demo today!