Unit 3: Searching and pipes · Lesson 6 of 6 · 26 min
Case file: hunting Log4Shell
Search three Java apps for a vulnerable library, including a copy hidden inside another jar, and find the probes in their logs.
mission
- You are
- You are the analyst on the December 2021 hunt.
- Situation
- A logging library used by countless Java apps can be made to fetch and run code from a string in a log line. Three of the shop's internal apps are Java.
- Goal
- Find which apps carry a vulnerable log4j-core, and whether anyone probed them.
- Hand in
- Per app: version, vulnerable or not, probes seen and from where.
case file
Log4Shell
Apache Software Foundation (Log4j) · 2021
A critical remote code execution flaw (CVE-2021-44228, CVSS 10.0) in the widely embedded Log4j 2 logging library was disclosed in December 2021 and exploited at scale almost immediately. Because Log4j is buried in countless Java applications and products, many organizations could not quickly tell where they were exposed. The US Cyber Safety Review Board later called it an 'endemic vulnerability' likely to persist for a decade or longer.
What went wrong
A JNDI lookup feature in log4j-core processed attacker-controlled strings written to logs; organizations lacked inventories of where the library was used, slowing patching.
What would have stopped it
- Maintain SBOMs and a software-component inventory so vulnerable transitive dependencies can be located within hours.
- Upgrade to fixed versions (2.15.0+, and later releases) and remove unneeded risky features from dependencies.
- Restrict outbound network connections from application servers (egress filtering) so injected lookups cannot reach external hosts.
- Run a documented vulnerability response program with owners for each application.
What defenders could have seen
- Web/application logs containing JNDI lookup patterns in headers or input fields.
- Unexpected outbound LDAP/RMI/DNS connections from Java application servers.
- Dependency scanner or SBOM alert for log4j-core in the affected version ranges.
Read the note
cat NOTE.txt
Logs and libraries from three Java apps, preserved from December 2021.
The fixed releases are log4j-core 2.17.1 and later (2.12.4 for Java 7).
you should see Fixed versions are 2.17.1 and later.
Find the obvious copies
find apps -name 'log4j-core-*.jar' | sort
apps/billing/lib/log4j-core-2.14.1.jar
apps/search/lib/log4j-core-2.17.1.jar
you should see billing has 2.14.1, which is vulnerable. search has 2.17.1. reports shows nothing.
Look inside every jar
A jar is a zip file. Some vendors copy log4j into their own jar under a new name, so search for the vulnerable class, not the file name.
for j in apps/*/lib/*.jar; do python3 -m zipfile -l "$j" | grep -q JndiLookup && echo "$j"; done
apps/billing/lib/log4j-core-2.14.1.jar
apps/reports/lib/analytics-sdk-1.3.jar
apps/search/lib/log4j-core-2.17.1.jar
you should see A third hit: analytics-sdk-1.3.jar in reports carries its own copy.
defender tip This is why the hunt took weeks: file names lie, class names do not. Scanners that open archives found the hidden copies.
Search the logs for lookups
Probes put a ${...} lookup where the app logs user input, such as the User-Agent.
grep -c jndi logs/billing-2021-12-11.log 3 grep -F -c '${' logs/billing-2021-12-11.log 4
you should see 3 lines contain jndi, but 4 contain a lookup. One probe was disguised so the word jndi never appears whole.
Who probed?
grep -F '${' logs/billing-2021-12-11.log | awk '{print $7}' | sort | uniq -c
1 198.51.100.140
3 203.0.113.77
you should see Two source addresses, one of them three times.
Two searches, two answers
grep -c jndi app.log 3
Misses the disguised probe
grep -F -c '${' app.log
4Catches every lookup, then review each one
What a defender takes away
- 1Keep an inventory of the libraries inside every app.
- 2Search archives for the vulnerable class, not just file names.
- 3Hunt for the mechanism, not one spelling of it.
Questions
0 of 3 solved
Answer each one from what you find on your lab machine.