The Log4j Wildfire (CVE-2021-44228) : Are you exposed?


Priya R

~ 6 mins read | December 16, 2021


CVE-2021-44228 in the Apache Log4j Logging library is a heavily exploited, critical vulnerability with a Securin VRS* score of 10. It now has APT groups targeting it, and ransomware associations as well. Also, more vulnerabilities have been identified in the Log4j package. If you haven't already scanned your assets for a Log4j exposure, start now before it is too late.

Updates Added:

  • Another Log4j in the offing? Watch out for CVE-2021-42392.
  • New Malware Associations - Conti, TellYouThePass, Dridex, Night Sky
  • New Threat Actor Associations - Aquatic Panda, DEV-0401
  • Release of new Log4j 2.17.0, 2.17.1
  • New related attack vectors : CVE-2021-45046, CVE-2021-45105, CVE-2021-4104, CVE-2021-44832
  • Details of publicly disclosed Log4j attacks

Amidst approaching holiday season celebrations, teams were pulled away from their parties on the weekend starting December 10, 2021. The reason: a high impact, severe vulnerability in a widely used Apache Log4j logging framework was turning into a full-blown security nightmare! The CVE in question is the Log4j or the Log4Shell vulnerability.

On January 7, 2022, researchers discovered a Log4j-like RCE flaw, CVE-2021-42392, in H2 database consoles used by 6807 artefacts. The vulnerability stems from the same root cause as the Log4j, the JNDI remote class loading. It remains to see if this vulnerability becomes another Log4Shell!

What is the Log4Shell issue?

Log4j is an open source, Java-based Apache logging utility used by a multitude of Apache products like Struts, Solr, Flink, among others. Services like Elasticsearch, Logstash, Kafka, Steam, Apple iCloud, and even Minecraft servers are known to use the framework. On December 9, 2021, a critical zero-day vulnerability, CVE-2021-44228, was identified as existing in the library, causing alarm bells ringing. The vulnerability is capable of unauthenticated remote code exploitation that could allow hackers to enter any application using the package, using a simple string. Once compromised, an attacker gains complete access to the entire server and all users on it.

What's more, it is not enough if you fix the Log4j implementation in your hardware alone. From cloud integrations to SaaS applications, any service that uses Java, be it an internal or external asset, and applications that depend on services using the Apache framework, could pose a risk to organizational networks. The difficulty is not simply in remediating the issue at hand, but in discovering all possible penetration points that an organization's attack surface exposes.

"The impact of Log4j is huge - we are just starting to get a glimpse of what is being tried out there in the wild, and will be dealing with the long-tail consequences for years to come. The exploit is not only publicly known but has a low barrier to entry, and newly impacted apps are being discovered every minute. Organizations should expect that all kinds of attackers will exploit the vulnerability, from crypto miners to ransomware groups and beyond. Work with your teams to understand the attack surface and exposures to Log4j - put the mitigation controls quickly, then focus on patching as that takes time."

- Kiran Chinnagangannagari, Co-Founder and CTO of Securin

Why should you discover and patch CVE-2021-44228 on priority?

Reason 1: VRS* Score of 10

Securin assigns the vulnerability a risk score of 10, categorizing it as a highly critical CVE that must be addressed on priority.

Reason 2 : Ransomware Association

The Log4j vulnerability has now been associated with a newly identified ransomware group, Khonsari and a revived older group, TellYouThePass. The Khonsari group is believed to encrypt files using the AES encryption algorithm. The vulnerability-hungry Conti ransomware, which already is linked to 16 CVEs based on our research, has added CVE-2021-44228 to its kitty as well.

Reason 3 : Soon becoming a Threat Actor favorite

With progressing time, we are observing the vulnerability being exploited by multiple Advanced Persistent Threat (APT) Groups including Iranian-based Nemesis Kitten, Charming Kitten (aka Phosphorus, APT35) , and China-based groups Hafnium and Aquatic Panda, so far. Threat actors have also been observed infecting devices with the dridex malware, a banking trojan known to be favoured by many ransomware and APT groups till date. China-based DEV-0401 has joined the bandwagon, deploying the Night Sky ransomware.

Reason 4 : Unauthenticated RCE Exploit Category

The vulnerability is classified under the highest exploit category, remote code execution, which allows attackers to execute code remotely and override all current processes. Furthermore, the vulnerability does not require any user interaction for exploitation. The mere presence of an unpatched instance is sufficient to launch an attack.

Reason 5 : Easily exploitable

A crafted request using Java Naming Directory Interface (JNDI) injection, combined with Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS) or Remote Method Invocation (RMI) could lead to attackers deploying malicious payloads and corrupting the system. Such simple exploits could result in breaking the software supply chain even, akin to the SolarWinds attack that took the world by storm.

Reason 6 : Can exploit three different weaknesses in code

Three possible weaknesses in code can be exploited via this vulnerability. CWE-502, which deserializes untrusted data without sufficient verification; CWE-400 which can manipulate resource consumption, leading to the exhaustion of available resources; and CWE-20 which does not properly validate received input.

Reason 7 : Heavily Exposed on the Internet

The exposure of CVE-2021-44228 is gigantic. Shodan scans show that the vulnerability is present in 1600+ products belonging to 290+ different vendors so far, including enterprise software, web applications and consumer products; this excludes indirect exposures from dependent services.

Reason 8 : Trending in the Deep Web and the Dark Web

The Log4j CVE has seen many instances of exploitation in the wild, and the vulnerability is trending in hacker channels and Dark Web forums. Google Trends show an average of at least 50 users searching for the vulnerability at any point of time, over the last 4 days. The vulnerability has also repeatedly been looked up in the Americas, Asia and Europe continents.


Reason 9 : The attack rampage has begun

The Log4j vulnerability has started being compromised to take down organizations. The first reported attack was on the Belgian Ministry of Defense on Dec 21, 2021. The Aquatic Panda group claimed responsibility for infiltrating the network of a prominent academic institution via a public GitHub project since Dec 13, which only came into light a fortnight later. The Vietnamese fintech firm, ONUS , soon joined the list having been at the receiving end of a cyberattack between Dec11 and Dec 13, 2021 via a Cyclos server, and was demanded a ransom of $5 Million. The UK National Health Service detected the Log4j vulnerability being used to hack VMWare Horizon servers to plant web shells, although the platform had received a patch.

Detailed list of products affected


Timeline analysis of the Log4j vulnerability


A timeline analysis of the Log4j vulnerability brings about three interesting factors :

  1. The vulnerability has been exploited in the wild in less than 2 weeks since it was discovered. This is a clear indication of the speed at which threat actors are developing today, calling for increased cyber vigilance from our end.
  2. This also brings out the need for vendors to proactively address vulnerabilities in their offerings in an agile manner as end users are reliant on the vendor community.
  3. We also see how a vulnerability can even be exploited before it gets disclosed on the NVD. This highlights the need for a vulnerability intelligence backing that goes beyond the traditional approach and analyses the true risk a vulnerability poses based on capability and exploitation trends as well.

How can you avoid a Log4j attack?

Apache Log4j 2.17.1 is now available, and Securin recommends users to upgrade to this version ASAP.

The Apache Logging Advisory suggests other mitigations for users who are unable to migrate to the latest version. However these are found to be largely insufficient for an exploit of this magnitude as they still leave some attack vectors open. All users are urged to remove the JndiLookup class from the Log4j-core jar, which is believed to have been one of the primary reasons for this exposure.

  1. Users of Log 4j 2.17.0 must fix CVE-2021-44832 as well.
  2. Users of Log 4j 2.16.0 must patch CVE-2021-45105 as well.
  3. Users of Log 4j 2.15.0 are urged to patch CVE-2021-45046 and CVE-2021-45105 as well.
  4. CVE-2021-44832 is addressed in versions Log4j 2.17.1 (Java 8 ), 2.12.4 (Java 7) and 2.3.2 (Java 6).
  5. For releases >=2.7 and <=2.14.1, users can modify logging configuration to disable message lookups.
  6. Users of versions >=2.10 can set system property
    'log4j2.formatMsgNoLookups' or environment variable
  7. Log4j 1.x versions have reached their end-of-life and will not be supported by their vendor. Users are urged to upgrade to version 2 immediately.

A look into the other Log4j vulnerabilities

1. A previous fix for CVE-2021-44228 in Log4j version 2.15.0 was found to be incomplete and gave rise to another vulnerability which is now tagged as CVE-2021-45046. The vulnerability introduces a threat context attack vector and was initially tagged under the DoS category. It has now been elevated to have associated RCE exploits arising from the lookups in code. Securin gives the CVE a VRS* score of 8.64.

2. The fix for CVE-2021-45046, Version 2.16, is now found to be impacted by CVE-2021-45105 which could expose unaddressed CVEs to a Denial-of-Service (DoS) attack due to self-referential lookups in code. Securin gives the CVE a VRS* score of 7.98.

3. The fix for CVE-2021-45105, Version 2.17.0, and all versions preceding this are found to be susceptible to an RCE vulnerability, CVE-2021-44832, which takes advantage of the lack of additional access controls on JDNI.

4. CVE-2021-4104 is found to affect the no-longer supported Log 4j v1.2

Most importantly, with attack vectors aplenty, organizations are encouraged to enumerate all external facing devices with a Log4j installation, and stay on top of updates. Additionally, a detection script provided by Cyber Security Works, a cybersecurity services company, can help identify if the vulnerability is present in your code.

Log4j in a nutshell

Securin VRS* Score 10
Exposure 1600+ products across 290+ vendors and counting
Weakness CWE-502, CWE-400, CWE-20
Exploit Type Remote Code Execution
Ransomware Associations Khonsari, Conti, TellYouThePass, Night Sky
Threat Actors Nemesis Kitten, Charming Kitten, Hafnium, Aquatic Panda, DEV-0401

Scan all assets for CVE-2021-44228 immediately!

Highlighting the importance of the Log4j vulnerability, CISA added the CVE to their recently released Known Exploited Vulnerabilities list in a day's time. This was followed by an emergency directive that directs federal agencies to patch the Apache Log4j vulnerability by Dec 23, 2021. Recognizing the criticality of the Apache Log4j vulnerabilities that have actively been under attack, FBI, NSA, and cyber security authorities of Australia, Canada, New Zealand, and the United Kingdom joined hands with CISA to release a joint Cybersecurity advisory on Dec 22, 2021. The US Federal Trade Commission has published an advisory warning companies of the vulnerability, while Microsoft has notified all Windows and Azure customers.

A quick scan of threat forums shows how important it is to identify the presence of this vulnerability in your assets. However, it is not just the one CVE you need to be wary about. All exposures, from ports to services, which could give way to cascading access vectors and allow attackers to penetrate further into the network are at risk. Scan your assets and manage your attack surface. Action is needed, and needed now.

*Securin Vulnerability Risk Score (VRS) is Securin's proprietary scoring system for vulnerabilities and weaknesses, bringing out the real-world risk each vulnerability poses.VRS attributes an automated risk score between 0 and 10 to every vulnerability, comprehending their maturity, exploit impact, trends, and associated threats.

Securin can help you scan for the exposures in your assets!