What Is The Log4j Vulnerability And How Does It Affect Your Organization?

As the Log4j threat evolves day by day, we are learning more about the exploit and how it is being leveraged for further compromise and attack on IT networks. As with any new vulnerability, upon discovery, threat actors began scouring the internet for vulnerable machines, adapting their scanning tools, and attempting to automatically exploit the vulnerability. 

In the early days of the attack, this was evident as we observed scanning activity against networks, in attempts to determine if vulnerable devices or services existed. Since threat actors have evolved their understanding of the vulnerability through their efforts to infiltrate and exploit target networks, we are now beginning to see successful exploit attempts. Ransomware strains such as Conti are already utilizing the vulnerability to access internal VMware vCenter server instances and encrypt virtual machines, while we have also observed a change in how the Mirai botnet is spread throughout the internet, taking advantage of the vulnerability. 

The vulnerability not only affects organizations but individuals as well. The logging library that the vulnerability resides in is used in a multitude of devices and services used by consumers.

The following impacts of exploitation of the vulnerability have been observed:

  • Installation of remote access Trojans for initial access to networks, which could proceed to ransomware attacks or personal data breaches. 
  • Distribution of the Dridex banking Trojan. 
  • Spread of the Mirai botnet malware.
  • Further exploitation of services once inside a network. For example, the Conti ransomware group using the vulnerability to encrypt virtual machines hosted in VMWare. 
  • Installation of cryptocurrency mining malware, such as MoneroMiner and XMRig.

Overview of CVE-2021-44228 (Log4Shell)

Log4j 2 is an open-source Java logging library developed by the Apache Foundation. It is very popular and used in many applications, devices, and services. Disclosed publicly on December 9, 2021, CVE-2021-44228, also known as Log4Shell, impacts Apache Log4j 2 versions 2.0 to 2.14.1. The 1.x series of Log4j is also vulnerable when using the JMS Appender class. Log4j is incorporated into a host of popular frameworks, including Apache Struts2, Apache Solr, Apache Druid, and Apache Flink. That means that several third-party applications may also be vulnerable to exploits of the same high severity.

What does this vulnerability do?

The vulnerability allows for unauthenticated remote code execution. An attacker can send specially-crafted network traffic to a vulnerable internet-facing device or service, which in turn will execute code that the attacker specifies. In addition, if an attacker breaches a network, they may be able to circumvent security controls by utilizing the vulnerability to negatively impact vulnerable network services. Log4j 2 is widely used in many applications and is present, as a dependency, in many services. These include enterprise applications as well as numerous cloud services.

What is the impact?

  • The CVE impacts all unpatched versions of Log4j from 2.0-beta9 to 2.14. The Log4j library is often included or bundled with third-party software packages and is very commonly used in conjunction with Apache Struts.
  • Cloud services like Steam, Apple iCloud, and apps like Minecraft have already been found to be vulnerable.
  • The Log4j 2 library is very frequently used in enterprise Java software. Due to this deployment methodology, the impact is difficult to quantify. Similar to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come.

Apache has released version 2.17.0 for Log4j to solve the denial of service vulnerability and remove the Log4Shell vulnerability. 

The general recommendations are to:

  • Check the versions of Apache you have in your IT network and patch and update to the most recent versions. Immediately patch vulnerable infrastructure by upgrading to Log4j 2.15-rc2 or higher.
  • Audit services and applications in use to determine if they use the Log4j library. Ensure all those identified are patched to the latest version available. 
  • Reach out to any third-party application providers to check if they utilize Apache and ensure they have patched/upgraded to the latest release.
  • Ensure all client devices have an Endpoint Detection and Response (EDR) agent or sensor installed.
  • Check for external network scanning activity; threat actors will typically attempt to perform reconnaissance activities on a network before attempting exploitation.
  • Set web application firewall rules to filter out malicious connections and packets.
  • If you’re an individual, ensure all your devices’ software is up to date with the latest versions.   

Temporary mitigation until patching can occur

  • The formatMsgNoLookups property was added in version 2.10.0, per the JIRA Issue LOG4J2-2109 [1] that proposed it. Therefore the formatMsgNoLookups=true mitigation strategy is available in version 2.10.0 and higher, but is no longer necessary with version 2.15.0 as it is then the default implementation [2][3].
  • If you are using a version older than 2.10.0 and cannot upgrade, your mitigation choices are one of:
    • Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files, see details at https://issues.apache.org/jira/browse/LOG4J2-2109 
    • Substitute a non-vulnerable or empty implementation of the class org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your classloader uses your replacement instead of the vulnerable version of the class. Refer to the classloading documentation for your application or stack to understand this behavior.

Further recommendations:

  • Carry out a Compromise Assessment, scan, and/or investigations to identify any evidence of the vulnerability being exploited and any further malicious actions as a consequence
  • Penetration Testing and Vulnerability Assessments
  • Implement Network Monitoring via a dedicated internal or external Security Operations Centre (SOC) team
    • SOC requirements: 24x7x365 Monitoring Detection, Threat Hunting, Reaction, Containment, Incident Response services
    • Collect, correlate, and analyze network traffic, via Security Information and Event Monitoring (SIEM), User and Entity Behaviour Analytics (UEBA) and EDR tools, for anomalous activity.

CyberClan’s Incident Response Team is well equipped to respond to any incidents involving the exploitation of this vulnerability. In addition, our SOC team and EDR monitoring software actively protect against the Log4Shell vulnerability. 

If you have any other concerns or would like to contact us regarding the recommendations above, please fill out the form below and we will be in touch with you as soon as possible.

Knowledge Base

Incidentally Informed – 2021 in Review Discussing the changing Cybersecurity landscape and what may be on the horizon for 2022

This month we looked at 2021 in review, discussing the changing Cybersecurity landscape and what may be on the horizon for 2022. We explored this topic with our fantastic panel of speakers

Read More +

What Is The Log4j Vulnerability And How Does It Affect Your Organization?

As the Log4j threat evolves day by day, we are learning more about the exploit and how it is being leveraged for further compromise and attack on IT networks. As

Read More +

The Danger of Outsourcing Cybersecurity Offshore

Written by Charlie Stubbs Cyberattacks, data breaches and malware infections are common occurrences for organizations of any size all across the globe. As such, it has become a daily priority

Read More +
icon-dark icon-light icon logo-light