40% of Corporate Networks Targeted by Attackers Seeking to Exploit Log4j

Early concerns about the Log4j vulnerability posing one of the biggest threats to Internet security in recent memory are quickly being confirmed with exploits and exploit activity targeting the flaw exploding over the weekend and the enormity of the remediation work involved for organizations becoming starkly clearer.

On Monday, Check Point said that it had already blocked some 846,000 scans for the flaw on its customer networks since the vulnerability — now being referred to as Log4Shell — was disclosed on Dec. 9. Some 40% of corporate networks globally already have been targeted in activity seeking to exploit the flaw.

The security vendor said that at times it has observed as many as 100 attempts to exploit the vulnerability in a single minute. Known malicious groups were responsible for nearly half — 46% — of the malicious activity that Check Point has observed on customer networks so far.

Ominously for organizations, new variations of the original exploit — first posted on GitHub — are being introduced at a rapid pace. Over the past 24 hours alone, Check Point researchers observed over 60 variations of the exploit becoming available in the wild. Log4Shell now can be exploited in multiple ways — including over HTTP and HTTPS — meaning that one layer of protection alone against the threat is no longer sufficient.

Numerous others reported similar activity. Sophos, for instance, said it had observed "hundreds of thousands" of attempts to attack the flaw. Many of these were scans for the vulnerability, exploit tests, and attempts to install cryptocurrency coin miners on vulnerable systems. Sophos researchers observed attackers attempting to use the flaw to extract encryption keys and other sensitive data from cloud services, including the Amazon Web Services (AWS) platform.

Cisco Talos, meanwhile, said its analysis showed that the earliest attempts to exploit Log4Shell happened on Dec 2. Others have noted that exploited activity may have been going on for several weeks before the flaw was disclosed on Dec. 9. Cisco, like several other security vendors tracking the flaw, said most of the malicious activity around Log4Shell so far has involved coin miners and botnet operators. But it's only a matter of time before other actors, including those motivated by financial gain and espionage, will start using the exploit to gain access to target networks.

"Early adoption from coin miners and botnet operators is not surprising," says Vitor Ventura, senior threat researcher at Cisco Talos. "[It] fits a pattern we have observed over the past few years where the groups behind the operations are very quick to adopt new exploits in an attempt to grab as many new systems as possible."

A Dangerous, Easy-to-Exploit Flaw
Log4j is a logging tool that is almost ubiquitously present in Java applications. A flaw (CVE-2021-44228) is present in it that gives attackers a way to remotely execute arbitrary code on any application that uses Log4j. Experts have described the flaw as relatively trivial to exploit and giving attackers a way to gain a foothold on any network with the vulnerable logging framework.

The vulnerable software is embedded in servers and services that organizations use daily. Affected software and services include those that an enterprise might have developed internally and those they might be relying on from third parties, such as Amazon, Cloudflare, ElasticSearch, Pulse Secure, VMware, Google, Apache Solr, and others.

The vulnerability can be present in the application programming interfaces (APIs) that organizations use. So even if an organization doesn't directly use the logging framework, a vulnerable API could expose it to attack, Noname Security warned. The way in which Java packing works can often make vulnerable applications hard to identify. 

"For example, Java archive (JAR) files contain all the dependencies, including the Log4j library. However, a JAR file can also contain another JAR file (which could also contain another JAR file) — essentially nesting this vulnerability several layers deep," Noname Security posted.

John Hammond, security researcher at Huntress Labs, says that, ultimately, almost every organization is likely affected by the vulnerability in one way or the other. This includes a significant amount of software that managed service providers use, he adds. 

"There is an extremely high chance, almost certain, that every person interacts with some software or technology that has this vulnerability tucked away somewhere," he says.

So far, there is no clear target in attacks or exploitation in the wild, Hammond says. "Because this vulnerability is ubiquitous, and exploitation is so trivial, there is no target — the security industry is seeing attacks all across the Internet."

Mitigation Challenges
Organizations mitigating against the flaw may need to look beyond externally facing servers and applications. Cisco Talos researchers said that in some instances they observed a gap between an attacker's mass scans and callbacks from vulnerable systems on a network. This suggests that exploits are being triggered in an organization's internal systems as well, such as log collection systems and SIEM systems.

The typical response time is near-instantaneous, and anything that isn't indicates that there are probably back-end systems that process data in batches, Ventura says. An example would be a system that analyzes email that takes a few minutes to process its logs. "What this shows is that even back-end systems need to be reviewed for potential exposure to this vulnerability," Ventura adds. "Anything that ends up processing user-supplied input needs to be reviewed. It is simply a reflection of the broad scope of this vulnerability."

Analyst firm Forrester Research recommended that organizations break the task of mitigating the threat into three parallel streams: prevention and detection; vendor risk management; and internal and external communications about the nature of the threat.

This requires a multipronged effort to manage the vulnerability internally, with vendors, and to prevent or be able to quickly respond to attacks, says Forrester analyst Allie Mellen. 

"Security and IT teams need to identify if any internal systems are affected by this vulnerability and patch those systems," she notes. "They also need to track all of the vendors they are currently using across the business — including security tools — to identify which systems need to be patched and get status updates from their vendors on timing."

It's likely that some vendors may take months to address the vulnerability. But organizations must make it a priority to update their software in a timely manner for vendors that do issue patches quickly. 

"[IT teams] can’t patch every system at once, so they will need to develop a patching and testing schedule," Mellen says. The security operations team will need to monitor for attacks and maintain a high-level of situational awareness around the threat. "Bottom line: There’s a ton for security teams to do," she adds, "and it’s all cross-functional."

Ariel Parnes, former head of the cyber department for the Israeli intelligence service and currently co-founder and COO of Mitiga, says organizations also need to make sure they haven't already been breached. 

"This vulnerability has been out there for years," Parnes says. "Attackers could have been using it to attack your environments already, so you need to make sure you are not already compromised." Mitiga has published a blog post describing how organizations can find vulnerable assets on AWS.