This tool provides you with the ability to scan internal (only) subnets for vulnerable log4j web services. It will attempt to send a JNDI payload to each discovered web service (via the methods outlined below) to a list of common HTTP/S ports. For every response it receives, it will log the responding host IP so we can get a list of the vulnerable servers.

If there is a "SUCCESS", this means that some web service has received the request, was vulnerable to the log4j exploit and sent a request to our TCP server.

The tool does not send any exploits to the vulnerable hosts, and is designed to be as passive as possible.

• added an option to scan a custom list of ports --ports=1555,3030,8000,8080,9003
• added a --connect-timeout flag to control the time to wait for a response from each port while scanning
• various bug fixes

In this example we run the tool against the 192.168.1.59/29 subnet (which contains a vulnerable server).

The tools does the following:

1. Open a server on the default address (the local IP at port 5555)
2. POssibly, add the flag --ports=top100 to adjust the scan to include the top 100 ports
3. The tool then tries all ports on each of the IP addresses in the subnet. If a remote server responds at one of the ports, the request is sent to it.
4. If the server is vulnerable, a callback is made to our server (created on step 1) and the IP address of the remote is logged
5. After all IP addresses in the subnet are scanned, the server waits for a default duration of 10s for any lingering connections and closes down
6. The tools displays the summary of the connections made:
   1. Requests sent to responding remote servers (and the status code they responded with)
   2. Any callback address made to our server

• If a callback happened, this means that a vulnerable server exists, the exploit worked and it initiated a callback. However.
• A good rule of thumb, if the callback IP address is not in the subnet scanned, the vulnerable server is behind a NAT (e.g. a docker container responds with its own IP address, not the host running the docker)
• The network traffic created by the tool might be classified as malicious by security products, or cause a lot of noise for monitoring services
• The server created by the tool assumes that it is open to receive inbound traffic. That means that opening a FW inbound rule on the host running the scan is needed.

Download the tool for your specific platform (Windows, Linux or Mac), to run the tool, make sure port 5555 on the host is available (or change it via configuration), and specify the subnet to scan (it is possible to configure a separate server:port combination using the --server flag):

log4jScanner.exe scan --cidr 192.168.7.0/24

This will test the top 10 HTTP\S ports on the hosts in the subnet, print any vulnerable hosts to the screen, and generate a log + summary CSV in the same location as the binary including all the attempts (both vulnerable and non-vulnerable).

In order to identify which hosts are vulnerable just look up the word SUCCESS in the log, you can grep the log for the keywork SUCCESS to get just the results. Also, the tool generates a CSV file containing all the results, filter on vulnerable to get the vulnerable hosts.

You can use the tool to test for the top 100 HTTP\S ports, insert a single custom port, a range of ports, or a list of custom ports (limited up to 1024 ports).

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=top100

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=9000

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=9000:9005

log4jscanner.exe scan --cidr 192.168.7.0/24 --ports=1555,3030,8000,8080,9003

it is possible to use a non-default configuration for the callback server

log4jscanner.exe scan --cidr 192.168.7.0/24 --server=192.168.1.100:5000

if you wish to disable the callback server, use --noserver

• --nocolor provide output without color
• --ports either top10 (default), top100 (list of the 100 most common web ports), a custom single port, a range of ports, or a list of custom ports
• --noserver only scan, do not use a local callback server
• --timeout=10 set the server shutdown timeout to 10 seconds
• --connect-timeout=2000 set the response timeout for each scanned port to 2000 milliseconds

Currently, the tool uses the following areas to try and send an exploit:

• Various X-* headers (we plan to enlarge these in the future)
• URL parameter encoding
• User-Agent

In order to test your environment, you can use the included docker images to launch vulnerable applications.

Run the docker compose in here:

docker-compose up -d

This will provide you with a container vulnerable on port 8080 for HTTP and port 8443 for HTTPS.

Alternatively, you can also run this:

1. Vuln. target:
   1. docker run --rm --name vulnerable-app -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app
2. spin a server for incoming requests
   1. log4jScanner scanip --cidr DOCKER-SUBNET
3. send a request to the target, with the server details
   1. sends a request to the vuln. target, with the callback details of the sever
   2. once gets a callback, logs the ip of the calling request

We welcome contributions, please submit a PR or contact us via contact@profero.io