Pentests and Log4J: How to Exploit a Vulnerable System

In this article, we pentest a vulnerable system and demonstrate how a remote shell can be obtained using a Log4j open-source exploit that is available to anyone. Introduction This critical vulnerability, labeled CVE-2021-44228, affects a large number of customers, as the Apache Log4j component is widely used in both commercial and open-source software. In addition, ransomware attackers are weaponizing the Log4j exploit to increase their reach to more victims across the globe. Our demonstration is provided for educational purposes to a more technical audience with the goal of providing more awareness around how this exploit works. Raxis believes that a better understanding of the composition of exploits is the best way for users to learn how to combat the growing threats on the internet. Log4j Exploit Storyboard The Apache Log4j vulnerability, CVE-2021-44228 ( ), affects a large number of systems, and attackers are currently exploiting this vulnerability for internet-connected systems across the world. https://nvd.nist.gov/vuln/detail/CVE-2021-44228 To demonstrate the anatomy of such an attack, Raxis provides a step-by-step demonstration of the exploit in action. Within our demonstration, we make assumptions about the network environment used for the victim server that would allow this attack to take place. There are certainly many ways to prevent this attack from succeeding, such as using more secure firewall configurations or other advanced network security devices, however, we selected a common “default” security configuration for purposes of demonstrating this attack. Victim Server First, our victim server is a Tomcat 8 web server that uses a vulnerable version of Apache Log4j and is configured and installed within a docker container. The docker container allows us to demonstrate a separate environment for the victim server that is isolated from our test environment. Our Tomcat server is hosting a sample website obtainable from and is configured to expose port 8080 for the vulnerable web server. https://github.com/cyberxml/log4j-poc No other inbound ports for this docker container are exposed other than 8080. The docker container does permit outbound traffic, similar to the default configuration of many server networks. Note, this particular GitHub repository also featured a built-in version of the Log4j attack code and payload, however, we disabled it for our example in order to provide a view into the screens as seen by an attacker. We are only using the Tomcat 8 web server portions, as shown in the screenshot below. Figure 1: Victim Tomcat 8 Demo Web Server Running Code Vulnerable to the Log4j Exploit Next, we need to setup the attacker’s workstation. Using exploit code from Raxis configures three terminal sessions, called Netcat Listener, Python Web Server, and Exploit, as shown below. https://github.com/kozmer/log4j-shell-poc, Netcat Listener, Port 9001 The Netcat Listener session, indicated in Figure 2, is a Netcat listener running on port 9001. This session is to catch the shell that will be passed to us from the victim server via the exploit. Figure 2: Attacker’s Netcat Listener on Port 9001 Python Web Server, Port 80 The Python Web Server session in Figure 3 is a Python web server running on port 80 to distribute the payload to the victim server. Figure 3: Attacker’s Python Web Server to Distribute Payload Exploit Code, Port 1389 The Exploit session, shown in Figure 4, is the proof-of-concept Log4j exploit code operating on port 1389, creating a weaponized LDAP server. This code will redirect the victim server to download and execute a Java class that is obtained from our Python Web Server running on port 80 above. The Java class is configured to spawn a shell to port 9001, which is our Netcat listener in Figure 2. Figure 4: Attacker’s Log4J Exploit Code Execute the Attack Now that the code is staged, it’s time to execute our attack. We’ll connect to the victim webserver using a Chrome web browser. Our attack string, shown in Figure 5, exploits JNDI to make an LDAP query to the Attacker’s Exploit session running on port 1389. Figure 5: Victim’s Website and Attack String The attack string exploits a vulnerability in Log4j and requests that a lookup be performed against the attacker’s weaponized LDAP server. To do this, an outbound request is made from the victim server to the attacker’s system on port 1389. The Exploit session in Figure 6 indicates the receipt of the inbound LDAP connection and redirection made to our Attacker’s Python Web Server. Figure 6: Attacker’s Exploit Session Indicating Inbound Connection and Redirect The Exploit session has sent a redirect to our Python Web Server, which is serving up a weaponized Java class that contains code to open up a shell. This Java class was actually configured from our Exploit session and is only being served on port 80 by the Python Web Server. The connection log is shown in Figure 7 below. Figure 7: Attacker’s Python Web Server Sending the Java Shell The last step in our attack is where Raxis obtains the shell with control of the victim’s server. The Java class sent to our victim contained code that opened a remote shell to our attacker’s netcat session, as shown in Figure 8. The attacker now has full control of the Tomcat 8 server, although limited to the docker session that we had configured in this test scenario. Figure 8: Attacker’s Access to Shell Controlling Victim’s Server Conclusion As we’ve demonstrated, the Log4j vulnerability is a multi-step process that can be executed once you have the right pieces in place. Raxis is seeing this code implemented into ransomware attack bots that are searching the internet for systems to exploit. This is certainly a critical issue that needs to be addressed as soon as possible, as it is a matter of time before an attacker reaches an exposed system. Also Published here