After a Busy December, Attacks on Log4j Vulnerability Dropped

In a recent poll by certification group (ISC)², 52% of security professionals said their teams collectively spent weeks or more than a month remediating the remote code execution vulnerability in the Apache Log4j logging library (CVE-2021-44228). Nearly half, or 48%, of cybersecurity teams represented in the poll gave up holiday time and weekends to assist with remediating applications and seuring systems, (ISC)² found. 

It appears the efforts have paid off, as attack volume has plunged, according to the SANS Technology Institute’s InfoSec Handlers Diary Blog. “Our sensors detected exploit attempts almost immediately,” wrote Johannes Ullrich, the dean of research for SANS Technology Institute. 

December saw a lot of exploitation activity, but since a massive spike on Dec. 28, attack activity has been almost flat for January and February. “Over time, attackers and researchers lost interest in log4j,” Ullrich wrote.

Just 10 days after the vulnerability was disclosed, the number of denial-of-service attacks targeting the Log4j vulnerability was double the cumulative volume of attacks targeting the Apache Struts flaw in the first year after it was disclosed, according to a recent report by Fortinet. In less than a month, attacks targeting the flaw were the most prevalent detected by intrusion prevention systems in the second half of 2021. 

The main challenge for security teams lay in the fact that the logging library was ubiquitous and affected nearly every enterprise application and service. 

There haven’t been any major breaches attributed to Log4j to date, largely because security teams moved quickly to address the flaw. However, the (ISC)² was cautious, noting that 27% of respondents believe the reallocation of resources and the sudden shift in focus made the organizations less secure because other priorities and tasks had to be placed on hold. Security teams say they fell behind on their 2022 security priorities. 

And security teams still have to address any of the systems still left unpatched. Just because the heavy bombardment has eased doesn’t mean attackers aren’t looking at the flaw. The costly lesson Experian learned in 2018 applies: The massive 2018 data breach was the result of a system running an unpatched version of Apache Struts even after the patch was available.