Six Months Later: Assessing the OT and ICS Risks of the Log4j Vulnerability

It has been six months since Log4j lit up security headlines. When the Alibaba Cloud Security team disclosed the Log4j vulnerability, it surprised many who never expected Apache’s Java logging library to be the source of a critical zero-day vulnerability.¹ The flaw (CVE-2021-44228) enables attackers to execute code remotely to gain access to systems that use Log4j. When the Log4j discovery was announced, Director of the U.S. Cybersecurity and Infrastructure Agency (CISA), Jen Easterly, characterized the vulnerability as “one of the most serious that I’ve seen in my entire career, if not the most serious.”²

Since the December 2021 Headlines, How Has the Log4j Threat Changed?

Are industrial control systems (ICS) and operational technology (OT) still at risk? Unfortunately, the answer is yes. Despite the warnings, many Java-based software and hardware solutions in the wild are still running code that is vulnerable to the Log4j exploit.

Will Log4j Be a Persistent Vulnerability in OT and ICS Environments for Years?

Since December 2021, major operational technology (OT) vendors have been disclosing the vulnerability’s impact on their software and equipment, thus reducing the Log4j attack surface. Yet, the nature of the Log4j vulnerability can make it hard to identify. Why? Log4j is often an embedded component of Java-based ICS hardware and software (both proprietary and open-source), leaving OT operators dependent on vendors to identify the Log4j risks and develop and deploy patches to mitigate the risks. Because of this, Dragos assesses with moderate confidence that Log4j will be a persistent vulnerability in ICS environments for years to come.

Researchers in Search of the Log4j Vulnerability in the Wild

Open-Source Insights³ —a Google service that scans millions of open-source packages—researched the components affected by the Log4Shell vulnerability and found a total of 17.84K affected packages, with only 7.14K patched for Log4Shell — for a 60 percent total of vulnerable packages that are not yet patched.⁴

In a widespread search, Rezilion researchers used Shodan to determine how many Log4j-vulnerable applications are exposed to the internet. The results? In April 2022, Rezilion found that over 90,000 vulnerable internet-facing applications and more than 68,000 servers are still publicly exposed,⁵ — describing the vulnerable attack surface as the “tip of the iceberg”⁶ and illustrating the scale of the vulnerability.

Nation State-Sponsored Adversaries Targeting Log4j: Stonefly, APT35, APT41

Stonefly

Nation state-sponsored adversaries have not missed the opportunities presented by the Log4j vulnerability. According to Symantec,⁷ in February 2022 adversaries were able to attack an undisclosed engineering firm in the energy and military sectors due to its Log4j vulnerability. Symantec is attributing the attack to Stonefly (also known as DarkSeoul, BlackMine, Operation Troy, and Silent Chollima).⁸

The adversaries exploited a gap on a public-facing VMware View server,⁹ dropping the malware onto the network hours after the initial compromise,¹⁰ and then moved laterally through the network —compromising at least 18 computers.¹¹ Other cybersecurity researchers have suggested that Stonefly has links with Lazarus Group, a well-known grouping of North Korean threat activity.¹² While Lazarus Group has focused on financial crimes targeting banking and cryptocurrency, Stonefly is an espionage operation targeting energy, aerospace, and military organizations that “could yield intelligence to assist strategically important sectors.”¹³

APT35 and APT41

In January 2022, only four days after Log4j was disclosed, Check Point Software uncovered the APT35 adversaries (also known as Phosphorous and Charming Kitten) exploiting Log4j and using the vulnerability to distribute a new modular PowerShell toolkit.¹⁴ Another nation-state-sponsored adversary, APT41, breached at least six U.S. state government networks between May 2021 and February 2022. APT41 retooled its attack vectors to take advantage of vulnerable internet-facing web applications, which included Log4j.¹⁵

While initial exploitation efforts focused on internet-facing web applications, as these opportunistic targets are patched, adversaries may start to use the vulnerability in attempts at lateral movement within networks. This shift in focus could be particularly relevant for adversaries attempting to pivot into ICS/OT networks from existing access in the enterprise network.

Dragos Has Observed Both the Attempted and Successful Exploitation of Log4j

Dragos has observed both the attempted and successful exploitation of the Log4j vulnerability in the wild. On December 8, 2021, Dragos coordinated a takedown of malicious domains that were part of an effort at wide-scale automated exploitation. Dragos also reported on the compromise of PingFederate Single Sign On (SSO) devices by adversaries utilizing the Log4j vulnerability at numerous industrial organizations within the energy, manufacturing, and pharmaceutical sectors.