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

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:

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:

In simpler terms:

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:

• CVE-2020-1206 (SMBleed) and CVE-2020-1301 (SMBLost)
• CVE-2020-5902: F5 BIG-IP Remote Code Execution Vulnerability
• CVE-2020-17051: Windows Network File System Remote Code Execution Vulnerability
• CVE-2020-17083 and CVE-2020-17084: Microsoft Exchange Server Remote Code Execution Vulnerability
• CVE-2020-17061: Microsoft SharePoint Remote Code Execution Vulnerability

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.