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:
- Attacks target testbed applications. Two out of three attempts to exploit the vulnerability targeted decoys that mimicked testbed applications commonly hosted on subdomains such as dev, test, uat, etc. These Internet-facing assets are further down on the patch priority list, which makes them a likely target for adversaries exploiting a zero-day vulnerability.
- Threat intel feeds don’t help. We correlated targeted threat activity against our customers with 3rd-party threat intel feeds. Only 12% of that threat activity was captured and categorized as malicious or unknown by the 3rd-party feeds. This is common with targeted recon activity where the attackers know which subdomains to go after.
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:
- Makes apps invisible to the Internet to minimize the attack surface
- Tightens access using SASE
- Prevents lateral movement with micro-segmentation
- Improves visibility with inspection
- Detects targeted threats with deception
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:
- Agility: Makes it possible to proactively respond with agility without waiting on the vendor ecosystem to respond
- Future-proofing: Makes defending against zero-days future-proof. Decoys spun up today will continue collecting telemetry and trigger when newer zero-days are disclosed.
- Threat Intel: Generate private threat intelligence not found in 3rd party threat intel feeds.
- Orchestration: Deception alerts are high fidelity, low false positive compared to traditional threat detection telemetry. This can be fed into your response workflow to automate containment.
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:
- DMZ: Detects targeted pre-breach recon. Invaluable source of private threat intelligence
- Datacenter: Disrupts lateral movement in segments hosting business-critical applications
- Active Directory: Detects and disrupts privilege escalation
- Privileged endpoints: Stops data encryption/theft during ransomware attacks
Run a complimentary internet attack surface analysis to see if you have any external attack surface using Apache.