Log4Shell Attack – Explanation and Recommended Steps for Prevention
The new Apache Log4j 2 vulnerability (CVE-2021-44228) is hopefully the last major issue of 2021 (though there’s still a couple of weeks left). Even if it is the last attack we see this year, the impact has the potential to stick around well beyond the holiday season. Threat actors and adversaries can potentially execute their own code on your systems, which means they can disrupt operations and could potentially access data. This vulnerability can be exploited to enable remote code execution on servers all around the globe, including a variety of major technology brands and services that have been using Log4j as part of critical infrastructure.
While we may not know how long the threat actor community knew about the vulnerability, we do know that large-volume scanning for the flaw by threat actors began nearly instantly after public disclosure of it. In the time it took most organizations to begin patching/upgrading efforts, there were recorded incidents of the vulnerability being used to compromise systems.
Breaking Down the Log4j Exploit
Apache log4j 2 is an open-source java-based logging package. While its primary purpose is to provide logging methodologies for java web apps, it has been utilized to provide functionality in a large variety of platforms. No matter how it's implemented, a specific transmitted payload can cause the log4j library to perform Remote Code Execution (RCE). Such an RCE can allow an un-authenticated threat actor to perform operations on the system running Log4j.
The vulnerability specifically exists in the Java Naming and Directory Interface (JNDI) implementation and can be triggered using an malformed LDAP request, making it easy for an attacker to retrieve a payload from a remote server and execute it locally. Here is a common example of such a command:
Key Lessons
While this particular vulnerability became highly publicized very quickly, it is a good reminder that any flaw in an operating system or critical software platform can become a major threat without much warning. In many cases, the threat isn’t even due to the actions of your organization; but rather programming code and packages provided by a third party, and outside your direct influence. There are a couple of major takeaways from events like this:
Be proactive!
Fact - your security posture is in a state of constant drift. You can keep up with this drift and minimize its impact by running simulated attacks and mapping your attack surface regularly. Continuous security validation technologies provide this capability – make sure you are using the one that gives you the broadest picture and highest visibility.
Be quick!
These kinds of exploits are a magnet for cybercriminals. They monitor vulnerability announcements and have the people and skill to very quickly create methods to use newly-found vulnerabilities to create attacks in hours – not days. Therefore, most organizations – which do not have a large group of experienced cybersecurity testers - need a system that provides the latest threat information so they can test and fine-tune their compensating controls without massively expanding their already overwhelming workload.
What to do?
- Learn: CVE details are available on MITRE website here
- Investigate: Find internal and third-party usage of Log4j vulnerable configurations – don’t forget that many 3rd-party platforms which use Apache may also use Log4j!
- Patch: Since this is a vulnerability of high impact, a patch has already been released by the Apache Software Foundation and must be installed as soon as it becomes available for the platforms and tools you use. In addition, Apache has released an updated version of the impacted library, Log4j 2.15.0, for all those who are managing Apache servers.
- Test – not just for this attack vector, but for others as well: Cymulate customers and prospects can simulate attacks against their Apache servers (and the rest of their infrastructure) to test their cyber defenses and find out if this vulnerability can be exploited in their infrastructure before threat actors do - test now!
For Cymulate Customers
Cymulate takes all vulnerability notifications seriously, and immediately takes action both internally and within the Cymulate Platform:
- We have ensured that this vulnerability doesn’t exist in our cloud, agent, or other infrastructure.
- An attack simulating a real-life attacker utilizing this new exploit has been added to both the Immediate Threats Intelligence Module and the WAF Module to validate that your security controls properly detect attempts to use this vulnerability. This is safe to use in production.
- For those customers licensed for the Advanced Scenarios Module (formerly Purple Team), a new Template has been added that simulates this form of attack.
Learn more about Threat Informed Defense and operationalizing the MITRE ATT&CK framework to validate your security posture is immune to immediate threats.
Featured Resources
View More Resources
Exposure Validation: Continuous Testing Should Drive Continuous Improvement
What’s your end goal? How exactly does this security project make you more secure? Like any technology initiative, those two
2026 Gartner® Market Guide for Adversarial Exposure Validation
The guide covers AEV use cases, key features, and market trends to improve threat exposure visibility and defenses.
Security Spent a Decade Finding More. It Should Have Been Proving More.
Here's an uncomfortable truth most security leaders already suspect but rarely say out loud: Your organization has invested millions in security tools, and