The National Institute of Standards and Technology (NIST) is a renowned body in the cybersecurity space. A physical sciences laboratory and non-regulatory agency of the United States Department of Commerce, it plays a leading role in promoting cyber resilience globally.
Part of NIST’s work includes the provision of the Common Vulnerability Scoring System (CVSS). An open framework for communicating the characteristics and severity of software vulnerabilities, it is used to rank the seriousness of threats on a scale of 1 to 10.
Given the organization’s reputation, it was hard to ignore the 10/10 rating of a new weak point in the Log4j Java logging library on December 8, 2021.
Better known as the Log4Shell exploit, or Log4j vulnerability, it quickly captured industry-wide headlines worldwide, deemed by some to be one of the most threatening security issues of all time. However, being publicized so widely as a highly concerning weak point also attracted unwanted attention.
Attackers quickly worked to take advantage of the vulnerability, the first exploit attempt occurring just nine minutes after publication. In the three days prior to a patch being released, the total figure of exploit attempts then rose to 830,000.
What’s equally concerning is that a proof of concept of an attack using the Log4J vulnerability was detected eight days earlier. Such a discovery suggests that the vulnerability was actually known and exploited well before it was made public.
This extremely high volume of attempts is largely why NIST points to Log4j being so challenging from a security perspective. It received the rating that it did because of a unique combination of being both easy to exploit and demonstrating the potential of being extremely damaging for organizations.
Threat Actors Will Wait for the Prime Opportunity
Given the evidence, it’s highly likely that malicious actors have already compromised enterprise servers by tapping into the Log4J vulnerability.
While many companies have audited and remediated any exposure, there will still be many instances that have not yet been identified and resolved, given the wide scope of impact. For context, over 1.5 million WordPress sites alone were impacted.
In cases where no remediation has been taken, threat actors will be laying low, probing the network, and waiting for an opportunity to spread to more high-value targets.
We therefore anticipate a rise in breaches over the coming months that use Lo4j as an attack vector – and history tells us that this could include some high-profile companies. Looking at SolarWinds as a case in point, it was discovered that the attackers involved had gained access to the company network as much as nine months before it was first realized.
At the same time, Highly Evasive Adaptive Threats (HEAT) are exacerbating the situation.
Threat actors are increasingly adopting HEAT to evade detection from traditional security tools and successfully launch ransomware and phishing attacks. Already latent in many web servers because of the Log4J vulnerability, payloads can be delivered to the endpoint using data obfuscation, HTML smuggling, and Javascript obfuscation to bypass traditional security controls like Secure Web Gateways (SWGs), sandboxes and firewalls.
This is what makes Log4J so dangerous – the fact that attackers can use it to gain easy access to a corporate network and then combine it with HEAT to hide, gather information and strike at any time.
How Isolation Can Achieve Zero Trust in the Truest Sense
So, what is the solution in combatting the threat of Log4j, particularly in combination with HEAT?
The Log4j vulnerability and the likelihood that malicious actors are currently lurking on the enterprise network has eroded users’ trust.
Organizations simply cannot assume that their web servers are safe. We believe that prevention is key versus a detect and mitigation strategy. As a result, organizations must transition from a post-breach detection mindset to a zero trust approach – ideally one powered by web isolation – to stop threats in their tracks before they ever reach the endpoint.
Isolation ensures all active code from the internet is executed in isolated cloud containers, removing any risk that malicious payloads will reach the endpoint. It doesn’t matter if there’s a known or unknown vulnerability on the endpoint because no content – regardless of whether it is malicious or not – has the opportunity to execute.