The Log4j vulnerability in Apache’s popular logging library—known as Log4Shell—was disclosed on Dec 9, 2021. Security teams around the world spent the next five days either patching, fending off exploitation attempts, or dealing with the fallout from threats that did pass through.
On Dec 14, 2021, an additional attack vector was identified and reported in CVE-2021-45046. Open source patch management service, LunaSec, reported that the new CVE invalidates some previous mitigations used to protect Apache Log4j versions from 2.7.0 to 2.14.1 from Log4Shell.
At Zscaler, one way in which we’ve tracked attacker attempts to exploit the vulnerability is by observing our global decoy network spread across customers.
Here’s what we’ve seen so far:
As the situation continues to evolve, here’s one takeaway – Defending against zero-day exploits is a race against time. You can’t patch everything. So what do you do?
Forward-thinking security teams are transitioning to or planning to transition to a zero-trust architecture that:
However, zero trust is a journey and evolving threats like zero-days require an active defense approach in the meantime.
Deception is a simpler and more effective approach to threat detection that uses decoy/honeypots to intercept attacks and divert them away from whatever asset they were originally targeting. Deception is particularly effective against zero days as it doesn’t require any prior knowledge of the threats to detect an attack: ANY interaction with a decoy sends a clear signal to security teams that malicious activity is underway.
As we’ve seen with Log4Shell and other zero-day exploits in the past, Internet-facing testbed applications lower on the patch priority list are the first to be targeted.
Planting decoys that mimic these applications is a pragmatic strategy to detect these targeted attacks while the security team patches away.
This has a couple of advantages:
Check out the below video for a brief demo of how Zscaler Deception detects exploits of the Log4j vulnerability:
Zero-days are often used to execute more severe attack campaigns like ransomware. The starting point of the Kaseya ransomware incident was an unpatched application vulnerability.
We recommend organizations consider adopting a comprehensive deception defense strategy that covers:
Run a complimentary internet attack surface analysis to see if you have any external attack surface using Apache.