One of the ways to fix timely security gaps related to zero-day vulnerabilities is to get into the mind of the adversary to understand the Tactics, Techniques, and Procedures (TTPs) and objectives they’re seeking. In the case of Log4j, threat hunting for Log4j TTPs in AWS Cloud is a mission-critical way to manage risks associated with Log4j, due to the prevalence of AWS being in most multi-cloud environments. By understanding the adversary, defenders can better address security controls and gaps that may allow an attacker to gain a foothold.

Now, let’s dive into how an attacker can use the Log4j shell TTPs to exploit Log4j in an AWS cloud environment.

About the Log4Shell Security Vulnerability

Log4j supports a logging feature called Message Lookup Substitution by default. This capability enables certain special strings to be replaced by other dynamically generated strings during logging. For example, sending the string ${hostName} via one of the vulnerable headers to a vulnerable host will yield an output similar to:


It has been discovered that one of the lookup methods, the JNDI lookup paired with the LDAP protocol, will fetch a specified Java class from a remote source and deserialize it, executing some of the code of the class in the process.

This means that if a remote attacker can control any part of a logged string, the attacker can gain remote code execution on the application that logged the string.

The most common substitution string that exploits this flaw will look something like this:


The Log4j security vulnerability is triggered by this payload and the server makes a request to via “Java Naming and Directory Interface” (JNDI). This response contains a path to a remote Java class file (ex. which is injected into the server process. This injected payload triggers the second stage and allows an attacker to execute arbitrary code.

Because of how common Java vulnerabilities are, security researchers have created tools to easily exploit them. The marshalsec project is just one of many that show how to create an exploit payload for this vulnerability. This malicious LDAP server can be used as an example of exploitation.

Log4j Attack Scenario

While searching the internet for the infamous Log4j security vulnerability, a bad actor discovers, which appears to be vulnerable to Log4j. We could start with an open source Log4j detection tool like

An attacker scans the vulnerable host with the Log4j scanner and assigns it a custom dns callback host –, as shown in the following screenshot.

The DNS callback was indeed received on our Burp collaborator host, as shown in the bottom half of the screenshot, which is a strong indication that the host is vulnerable.

After we confirm that the host is potentially vulnerable to the Log4j vulnerability, the next steps will be preparing our environment.

To do, so we will need to set up to following:

  • Malicious JNDI Toolkit – The JNDI Exploit Kit Injection toolkit is a tool for creating functional JNDI links and providing background services by starting the RMI, LDAP, and HTTP servers.
  • Local python server on port 1337
  • Netcat listener on port 8080

When we run the Malicious JNDI toolkit, we’ll be able to listen to two ports at the same time: LDAP and HTTP. The JNDI toolkit will receive a crafted request sent to the vulnerable host.

We will choose the following JNDI payload convention from the various payloads which we can send to the vulnerable host:


We will use msfvenom to generate our reverse shell payload elf file:

Basically what our base64 payload will do is download the reverse shell payload to the /tmp/ folder by using wget, make it executable by setting it with an “x” flag using chmod, and finally execute it. If all goes as expected, we should get our reverse shell.

Before sending our crafted payload we will ensure that our local python server is listening to Port 1337.

And finally, setting our netcat on the designated reverse shell port (8080):

The following screenshot shows our listeners and our prepared GET request via curl:

We will send our crafted request:

The screenshot above shows that we got our reverse shell.

We can see if we can escape and/or pivot using the constraints of the current environment once we’re inside our vulnerable app container. Let’s look at where we can go from here, even though we get our reverse shell as the root user:

The screenshot above shows that there are no environmental variables, python, curl, nor wget, and there is no user under /home/ directory.

By listing the current folders and files we can understand that we are probably running our shell in a container since the /app/ folder contains the current running app which is our vulnerable Log4j app:

To perform the attack, we have two main options:

  1. We can try to perform a Docker escape; or,
  2. Since our vulnerable host is running on Amazon Linux AMI, we can try to retrieve sensitive data by abusing the IMDSv2 (Instance Metadata Service).

Since Docker escape could not be performed in our case, I’ll use the second option.

I’ll use BusyBox which is a multicall binary that combines many common Unix utilities into a single executable. These are the executables which we can use:

I’ll use wget to send our request. I’ll send the following request to see whether IMDSv2 can be accessed  by sending a GET request to the following endpoint:

So our final request will be:

busybox wget

Great. It seems that we retrieved the various paths for the IMDSv2. One of the more interesting paths by which I would like to access the Security Credentials for the EC2 instance is: (URL no longer functional as of April 2022)

This endpoint returns a set of odd IAM credentials described by the AWS Documentation as: 

The screenshot above shows that we retrieved three main variables:

AccessKeyId, SecretAccessKey, and the Temporary Session Token.

Once retrieved, I’ll set all three of them in my attacker ~/.aws/credentials file as follows:

I’ll add the “Session Token” Value that was also retrieved to the ~/.aws/credentials file:

So now that all is in place, let’s review the details of the IAM user or role whose credentials are used to call the operation by executing the “get-caller-identity” command.

Summary of Log4Shell Exploit

We retrieved the IMDSv2 information by exploiting the vulnerable Log4j version on the victim host. By adding the AccessKeyId, SecretAccessKey, and the Temporary Session Token to the attacker’s credential file, we were able to query the AWS account and retrieve information about the account and the EC2 instance.

What Can We Learn From This Log4Shell POC?

There’s a reason the Log4j vulnerability was marked as Critical Severity – It is pretty scary how easily it can be exploited. Following the massive headache Log4j caused for Blue Teams and thousands of organizations, we can cautionally say that in order to prevent such attacks we would recommend to: 

      1. Build and Manage your Asset Inventory.
      2. Be aware that both IMDSv1 and IMDSv2 are enabled by default, as well as the following information related with regards to the SSRF vector –  
        • Requiring the secret session token (AWS_SESSION_TOKEN) is always strictly more effective than requiring only a static header.
        • The X-Forwarded-For header should not be allowed in IMDSv2, ensuring that no proxy based traffic can communicate with the metadata service.
      3. If you haven’t already – Patch and Upgrade.

    Could You Have Undiscovered Log4j Vulnerabilities?

    Since the Orca Security platform scans workloads and configurations without requiring agents, Orca  covers 100% of your cloud assets without the blind spots of agent-based workload protection solutions. So, even if you already have a cloud security solution, wouldn’t you like a second opinion? 

    Sign up for a complimentary, no obligation Log4j Vulnerability Cloud Risk Assessment to make 100% sure that you have not missed any Log4Shell vulnerabilities.