It’s been a busy month for organizations struggling to understand the impacts of Log4j vulnerability CVE-2021-44228 (also known as Log4Shell). Ever since the original log4j exploits, we have seen a waterfall of information that has kept IT teams and security professionals across the world buzzing the original Log4J exploit. IT teams who worked long hours to update their Log4j versions to 2.15.0 on December 11th were asked again to do it all over again and upgrade to version 2.16.0. 

The Log4Shell Vulnerability in a Nutshell

Cybersecurity experts call this “a tsunami of attacks” or “the worst flaw in the internet history”. They believe that this could impact millions, if not billions, of websites and servers worldwide. We all know that Log4Shell is a critical remote code execution (RCE) vulnerability in Apache’s library, a global Java-based logging tool.

The worst part is that this vulnerability is extremely easy to exploit. Any hacker with access to an exposed server can execute code remotely by adding a line of malformed code to the log file. 

It’s not just you; it’s all of us:

Just about all organizations are running log4j in their environment. As it runs as an integral part of many java applications, an extensive scanning activity was observed around the globe beginning on December 9^th, 2021. What’s threatening over here is that some of this scanning was initiated by security vendors, but most of it was not. Hackers were quick to initiate searching for vulnerable systems.

It’s Still not too late to Patch:

We still believe that there might be fewer compromises than expected. Most hackers might not have started to exploit the flaws yet. If that is the case, the situation may change quite quickly. 

Post-exploitation activity is usually hard to detect. The exploitation is always possible when or where there isn’t visibility. Cyber experts are still observing high volumes of scan traffic detections and are continuously working to generate countermeasures to understand the vulnerability daily.

We already have seen a high volume of activity related to botnets, particularly Mirai and Kinsing (crypto mining). The use of CobaltStrike is also observed as other payloads. At the same time, there have been reports of brand-new ransomware families that have emerged using this exploit.

What Should we do?

The first thing that needs to be done is to update, Patch, and/or take mitigation actions for all vulnerable Log4j servers. Think about proactive security rather than a reactive approach to battle the vulnerability. Think about strengthening your security posture. 

The best way right now to protect our organization and its valuable assets is by deploying the Shift Left approach to your security posture. This eliminates the ability of hackers to exploit back doors and protect your Apps right from the beginning of SDLC. 

Patch the vulnerable applications and systems. If you cannot patch them, apply the mitigations provided by Apache.

Identify systems running with vulnerable versions of Log4j and prioritize internet-facing ones. Authenticated scanners are the most straightforward way to perform this check if you have that capability.

Conclusion:

The impacts of these recent vulnerabilities have taught businesses that having a secure environment for your IT assets is not a choice but a necessity. Having cybersecurity solutions with a proactive approach is the need of the day for your organization. When and where will the following vulnerability be found, it surely will be bigger than the Log4J shell. Prepare in advance for such threats and make your IT infrastructure a secure one.