4 Lessons Learned from Log4Shell

By SOCRadar Research

Log4Shell vulnerability shook the cyber world to its core when it first became public in December 2021. It is a zero-day vulnerability discovered on the log4j logging library, which is widely used by Java applications. Apache maintains the library. It is disclosed as CVE-2021-44228 and has a CVSS score of 10.0 critical. The vulnerability allows an attacker to execute arbitrary code on the victim’s system, potentially leading to the compromise of the victim’s system and the theft of sensitive information.

The ubiquity of the Apache Log4j library made it harder to identify and more dangerous than most vulnerabilities. In research conducted after the vulnerability disclosure, Apache Log4j 2.x was one of the top downloads out of 7.1 million samples. Millions use Apache Log4j. Even tech giants such as Apple, Google, Amazon, and Tesla benefit from this library in their environment. 

Download SOCRadar’s End-of-Year Report and get insights into major vulnerabilities in 2022.

Researchers identified hundreds of projects as vulnerable, with over 100 million instances of software and technology. In an observation pool of 105,497 services running a target for the log4j vulnerability, 102,060 were vulnerable to attack. This showcased the severity of the vulnerability. 

For a detailed explanation of the Log4Shell vulnerability, you can refer to this blog post by SOCRadar. 

What’s Happened Since Log4Shell First Appeared?

With the disclosure of the Log4Shell vulnerability, the attention of the cybersecurity community turned toward it. It was to put out the fire caused by Log4Shell. However, some with malicious intent wanted to spread the fire. SOCRadar Dark Web Team found multiple posts on the dark web forums, sharing or selling Log4Shell vulnerabilities.

When Log4Shell was first disclosed, it was expected that there would be catastrophic results with the prevalence of the log4j logging library and its ease of exploitation. All an attacker has to do is locate an input field that gets logged and write a simple string for exploiting the vulnerability. However, throughout the year, the public results of Log4Shell were not that disastrous. It is still actively exploited by threat actors, but the impact level can be considered low compared to the expectations. 

On July 2022, CSRB (Cyber Safety Review Board) released a report covering the Log4Shell vulnerability. In the report, the vulnerability was assessed as “endemic vulnerability.” The reasoning behind the assessment was that the Log4Shell vulnerability was not over and will remain in systems for many years. Security researchers foresaw that the vulnerability might remain on the systems as a significant risk for a decade or longer. 

As of January, the vulnerability still persists in the systems. Data from Sonatype shows that in the last 24 hours, 26% of log4j library downloads, more than 50.000, are vulnerable versions of the library. Since December 10, 2021, 33% of all downloads have been vulnerable versions of the library.

Though there have been fewer than expected publicly reported attacks involving the vulnerability, according to SOCRadar Research, Log4Shell vulnerability was one of the top 5 vulnerabilities routinely exploited in 2022. Unlike CVE scoring, SOCRadar scores vulnerabilities dynamically with the SVRS (SOCRadar Vulnerability Risk Score). This system considers elements such as social media, news, code repositories, dark web, attribution with threat actors, and malware to score a vulnerability actively. Throughout the year, the Log4Shell vulnerability scored over 90 out of 100.

Major Log4Shell-related Activities

Throughout the year, there have been several attacks leveraging the Log4Shell vulnerability. Researchers found that the first activity for the vulnerability was as early as December 1, 2021. 

According to SOCRadar Vulnerability Intelligence, twelve APT groups leveraged Log4Shell vulnerability in their attacks. These are CHRYSENE, TA505, Lazarus Group, DarkHotel, Axiom, TA413, BRONZE STARLIGHT, ELECTRUM, MuddyWater, EMISSARY PANDA, TeamTNT, and Kinsing.

Ransomware groups are another major party leveraging Log4Shell vulnerability. According to research, the average incident response cost of a Log4Shell compromise was more than $90,000. This research found that two-thirds of Log4Shell incident response cases were attributed to three ransomware groups: LockBit (27%), Conti (19%), and Alphv/BlackCat (12%). These are all notorious ransomware groups targeting various industries around the globe. They are still active, apart from Conti, who ceased operation in mid-2022. 

Belgian Ministry of Defense Attack 

On December 20, 2021, the Belgian Ministry of Defense confirmed an attack on its network. In the attack, they discovered that the threat actors leveraged Log4Shell. Authorities stated that they took the required actions swiftly. 

AQUATIC PANDA Leverages Log4Shell 

Within a few weeks of the vulnerability’s disclosure, researchers observed that AQUATIC PANDA, a China-based group, was conducting malicious activities, such as credential harvesting, leveraging Log4Shell vulnerability. 

This would also become a continuous trend throughout 2022. According to a CISA alert, Log4Shell was among the top CVEs exploited by the China state-sponsored threat actors. 

Log4Shell exploitations in VMware Horizon Systems 

In an alert by CISA, two instances of Log4Shell exploitation were examined. The attacks took place around early to mid 2022. The victims weren’t disclosed, but the malware was deployed on the victim machines in the malicious activities. 

FCEB Attack by Iranian APT Actors 

In another alert by CISA, it was observed that Iranian government-sponsored threat actors were conducting malicious activities toward Federal Civilian Executive Branch (FCEB) organization. The threat actors leveraged the Log4Shell vulnerability for initial access. They deployed crypto miners and credential harvesters on the victim machines. 

What are the Lessons to Learn? 

Lesson 1: Be mindful when using open-source software! 

Apache log4j is an open-source library, meaning that programmers can copy, modify, and use it in their projects. Log4j is seen as a dependency in almost 7,000 other open-source projects. Because of its freedom and usefulness, some software, such as the log4j logging library, became prevalent. This prevalence might lead the developers to think that if there were any problems, they would be disclosed by now. However, it is not the case. In the example of log4j, the library was managed by three people. So, there needed to be more workforce to address every problem in the library.

To get ahead of problematic situations such as this, developers can leverage from Software Bill of Materials (SBOM). SBOM enables organizations to identify and track all third-party components, particularly open-source components, and comply with licensing requirements. It also helps ensure that the organization does not run vulnerable open-source components and keeps track of critical updates and patches. 

Lesson 2: Pay attention to third-party risks! 

Despite the widespread awareness of the Log4Shell vulnerability within the cybersecurity community, vulnerable versions of Log4j remain hard to detect in some instances. Some applications might use the open-source logging library as a direct dependency in their applications. In other cases, an application might use Log4j as a transitive dependency — or a dependency of another dependency. Since transitive dependencies are introduced from the direct dependency choices, they may not always be known or directly visible to your developers. 

SOCRadar provides Supply Chain Intelligence. With its help, you can proactively configure security measures using the intelligence provided by SOCRadar.

You can also check this research by SOCRadar Research Team to get a grip on the supply chain attacks. 

Lesson 3: Security visibility is the key! 

Visibility equates to speed in time of a potential crisis. Complete visibility into your environment when vulnerabilities such as Log4j are discovered is paramount when time is of the essence. Being able to immediately access your network and know exactly where to look for certain tools, technologies, attributes, and software can be the difference between a breach and a successful defense.

With the help of SOCRadar’s External Attack Surface Management, organizations can have the necessary visibility into their system. In a case such as Log4j, organizations could have had a high level of visibility into their environment and would be able to understand how to handle a Log4j attack.

Lesson 4: Patching should not be optional! 

A strong patching strategy should not be optional. As vulnerabilities become known in software, organizations must provide the necessary resources to their cybersecurity teams to remediate the vulnerabilities before threat actors can exploit them.

In reflection of Log4j, patches for the applications with the logging library were released even before the vulnerability disclosure. However, the swiftness of the patches means nothing if the organization cannot allocate the time or resources to apply the patch. 

Despite all the efforts, according to Tenable telemetry research, 72% of the organizations remain vulnerable to Log4Shell. In an even more drastic observation, 29% of the vulnerable assets saw the resurgence of Log4Shell after complete remediation. 

What the Future Holds for Log4Shell? 

The Log4Shell vulnerability will not be going away shortly. We may need a decade to purge the remains of it. However, if the required actions are taken according to lessons learned, Log4Shell vulnerability should not present a considerable threat to the organizations.

Other vulnerabilities are exploited in the wild, similar to the Log4Shell, and many more may emerge in the future. SOCRadar External Attack Surface Management provides visibility into external-facing digital assets. At its core, SOCRadar has a predictive, preventive, and proactive approach toward security. With SOCRadar’s EASM, security teams can track vulnerabilities such as Log4Shell or any other vulnerabilities and detect if they are present in the environment. Knowing which CVEs are present in the organization can boost the security team’s ability to defend against vulnerabilities.