Does this mean everyone can sit back and relax? Not a chance, according to one cybersecurity researcher citing telemetric scenarios.

As the world prepares for a long-drawn crisis around the Log4Shell vulnerability found in the widely used Apache Log4J software in early December 2021, an unexpected lull is currently being felt.

As soon as details of the bug were announced globally, makers of the world’s biggest and most important cloud services, software packages and IT products had taken action to steer away from the iceberg, supported by shared threat intelligence and practical guidance from the security community.

The immediate threat of attackers mass exploiting Log4Shell has been averted thus far because, according to one cybersecurity firm, the severity of the bug had united the digital and security communities and galvanized people into preemptive action.

Such a trend was seen back in the period before the Y2K bug was to have wreaked havoc in year 2000, and now it seems to have made a significant difference here, according to principal research scientist Chester Wisniewski, Sophos.

Limited mass exploitation for now

To date, the firm has recorded a lower-than-expected overall number of successful attacks linked to Log4j. While its Managed Threat Response Team (MTR) has detected many scans and attempts to trigger the Log4Shell exploit, by early January 2022 only a handful of MTR customers had faced attempted intrusions triggered with the bug. The majority of these were cryptominers.

“Another possible reason for the limited mass exploitation could be the need to customize the attack to each application that includes the vulnerable Apache Log4J code. At one end of the scale are the incredibly widely-used applications that are exposed to the internet that need to be manually updated one-by-one. These are being exploited at scale in an automated fashion. At the other end of the scale are many other, more obscure applications involving Apache Log4J that will take time to be discovered and exploited by attackers,” Wisniewski explained.

These attacks will proceed at a human pace and will not result in giant spikes of activity, although they will still present a significant risk to organizations that remain vulnerable.

The looming threat remains

As other industry observers have pointed out, some initial threat incidents may have resulted in attackers securing access to a vulnerable target, but not actually abusing that access to deliver malware—so the successful breach has remained undetected. 

Wisniewski said this has happened in the past, where countries such as Iran and North Korea had pounced on VPN vulnerabilities to gain access to targets’ networks and installed backdoors before the targets could deploy patches—and then delayed attacking for months. In another example, attackers targeted vulnerable Exchange servers in the immediate aftermath of the first ProxyLogon patches, leaving behind web shells as backdoors for later attacks. Patching an Exchange server was not enough—as any remaining backdoors would have been compromised much later on.

“There’s more. Over time, internet facing applications vulnerable to a Log4Shell exploit are likely to be identified patched or removed. However, unknown internally vulnerable systems may never be known or discovered, and these will remain a security risk. Sophos telemetry shows that the number of vulnerable Java Archive files (JAR) on Sophos-protected endpoints has not changed. These could become a favorite tool for malicious lateral movement down the road,” said the researcher.

So let everyone buckle up for years of bumpy cyber activities ahead involving attempted exploitation of the Log4Shell vulnerability by penetration testers and state-sponsored threat actors alike. The urgency of identifying where it is used in applications and updating the software with the patch remains as critical as ever.