January 07, 2022 Blogs 4 min read

Log4Shell Aftermath

By KYND

Log4shell aftermath

On December 9, 2021, Apache disclosed CVE-2021-44228, a critical remote code execution zero-day in Log4j. Subsequent vulnerability disclosures (CVE-2021-45046, CVE-2021-44832) were made which further increased attack vectors and exposure.

This all occurred during the lead up to the holidays, a period where many organisations are typically more prone to cyber attacks. We wrote an initial blog post detailing these vulnerabilities and possible mitigations here. Understanding the high severity and risk to organisations, we tested and implemented detection capability for Log4Shell on a sample of ~4500 organisations to have their externally-facing services checked for exposure.

How many organisations were vulnerable to Log4Shell?

From our own post-mortem analysis we found that 0.69% of ~4500 organisations had external vulnerabilities to the issue. This correlates with other analyses we have seen published.

While this is a low number, it could be the tip of an iceberg rather than a “nothing-burger” as has been claimed by some. Firstly, the Log4j utility is primarily an internal tool and the majority of vulnerabilities lay "under the surface" and so are only detectable inside the network. This means that attackers could use Log4Shell as one step in a chained attack.

Secondly, the nature of logging means that vulnerabilities and exploitation of them may not surface for a while – for instance if logging is used in an asynchronous manner. Moreover, from our week to week external vulnerability detection and tracking, we have seen that many organisations have not remediated their existing externally-visible vulnerability to Log4Shell. Therefore, it’s likely that similar proportions will not have patched all vulnerable instances inside their network.

The threats are present and have not subsided

Organisations should be aware of the broad availability of exploit code and scanning capabilities to be a real and present danger to their environments. Due to the ubiquitous usage of Log4j there are a vast number of software and services that are impacted. This is further complicated and compounded by the software supply chain and components being affected.

Microsoft is warning of ongoing attempts by nation-state actors and cybercriminals to exploit Log4Shell to deploy malware on vulnerable systems. Particularly concerning is its rising use in botnets and ransomware attacks.

“Exploitation attempts and testing have remained high during the last weeks of December. We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on-keyboard attacks. Organizations may not realize their environments may already be compromised.”

Microsoft Threat Intelligence Center (MSTIC)


Log4Shell is reminiscent to Heartbleed, a severe vulnerability which lay dormant in open-source view for years and was in ubiquitous usage at the time, which went on to cause issues much later down the line - issues which are still reverberating, and persistent to this day.

Given the large number of instances that could be vulnerable – externally visible or not; logging immediately & synchronously or not – there is still much remediation to be done. And with the disclosure of further vulnerabilities (Apache Log4j Security Vulnerabilities), ongoing, sustained vigilance will be required from security and infrastructure teams. The fallout from Log4Shell will only be truly known in the fullness of time – either a tip of the iceberg, or a nothing-burger.

What is KYND doing to help our customers?

We are continuing to monitor the situation closely as it evolves, and will continue to adapt our detection capability and awareness efforts to mitigate associated risks. We have left an open invitation for all KYND customers to request a red-flag check for Log4Shell on their externally-facing services.

We’re also continuing to support our customers to understand where they may be affected by this vulnerability within their network, and how to remediate those instances. To find out more, feel free to get in touch, and we’d be happy to help!

Share this article
Join the newsletter

Accreditation & Features