3rd Party Risk Management , Application Security , Business Continuity Management / Disaster Recovery

Log4j Exploitations Have Slowed, But Attack Vectors Remain

Russia, Brazil and US are Top Countries Targeted in Attacks Tied to Log4shell
Log4j Exploitations Have Slowed, But Attack Vectors Remain
An artistic interpretation of the Log4j vulnerability aka Log4Shell (Photo: Kevin Beaumont)

Attackers made more than 30,000 attempts to scan and leverage exploits found in the critical Log4Shell vulnerability in January, according to security firm Kaspersky. Log4Shell, a flaw found in the Apache Software Foundation Log4j library logging tool, was first disclosed to the public in December and continues to be a challenge.

See Also: The State of Organizations' Security Posture as of Q1 2018

Although Kaspersky researchers say attackers are still seeking ways to facilitate the remote code execution vulnerability, the 30,562 blocked attempts mark a decline in numbers from when the flaw was originally disclosed. But cybercrime groups, such as Prophet Spider and freshly emerging ransomware gang Night Sky, have attempted to exploit the flaw.

Some researchers and security professionals have also observed downloads of vulnerable Log4j software, and in some cases an unawareness of the vulnerability altogether, despite the far-reaching attention given to the flaw, as well as other issues. And the Computer Emergency Response Team of Ukraine, known as CERT-UA, has not ruled out ties to the Log4j vulnerability in the investigation of recent attacks on government websites deployed through wiper malware (see: Cyberattack Spillover From Ukraine: Be Prepared, UK Warns).

“We certainly see that there have been far fewer scans and attempted attacks using Log4Shell than there were in the first weeks when it was initially discovered," says Evgeny Lopatin, security expert for Kaspersky. "Still, attempts to exploit this vulnerability are here to stay."

Log4Shell, which is tracked as CVE-2021-44228, is one of the most severe vulnerabilities detected in recent years, with a CVSS critical score of 10 out of 10. The dangers of this flaw - aside from the widespread use of Log4j in the development of Java-based apps and software - lie in the potential for an attacker to take complete control over a network system through executing arbitrary code.

To date, Kaspersky has detected and prevented more than 150,000 attempts to strike networks by leveraging the flaw.

Top Targets: Russia, Brazil and US

Chart shows scans/attempts to exploit Log4j flaw from Jan. 1 to Jan. 20 (Source: Kaspersky)

According to research by Kaspersky, nearly 40% of the attacks were detected in the first five days in January and the top three targeted countries were Russia, Brazil and the U.S.

Kaspersky researchers broke down the percentages of the attacks as follows:

  1. Russia - 13%
  2. Brazil - 8.97%
  3. U.S. - 7.36%

Lopatin tells ISMG: "We can assume that the activity of both researchers and cybercriminals in regard to this vulnerability will continue to decline in 2022," but that because of how easy an attack vector is to launch, tools to exploit Log4Shell will "stay in the arsenal of cybercriminals for a long time."

Users who do not update to the latest versions of Apache Log4j will continue to be at risk of attacks, warns Lopatin, who also says that updating software can take security teams weeks and sometimes months.

Kaspersky, as well as federal agencies such as the Cybersecurity and Infrastructure Security Agency, recommend installing the latest version of the Apache Log4j library, 2.17.1 and following guidelines by Apache Logging Services for patching tips. If network defenders cannot meet the demands of remediating Log4j in a timely manner, Lopatin also urges organizations to seek assistance through a trusted service provider.

Still Challenges Ahead

Even though the Log4Shell vulnerability had been a major focus in the security world - and in some cases mainstream media - there are still many who continue to download unsafe versions of Log4j or may not even be aware of the flaw.

Timothy Torres, CIO for Sutter Health, tweeted about these concerns.

Ilkka Turunen, Field CTO for open-source software management firm Sonatype, also says that downloads of vulnerable versions of Log4j persist, due to security burnout.

Zach Jones, senior director of detection research for NTT Application Security, says a minority of organizations in his client base have yet to mitigate the threats posed by the Log4j flaw. But Jones says it is "common" for downstream legacy systems to be affected in ways that could cause an attack to execute nearly a week after it was first attempted.

"This makes it very difficult for security teams and developers alike to hunt down the systems that have been reported as vulnerable by external testing. Therefore, organizations without software composition analysis capability in place across their portfolio will likely play Log4j whack-a-mole for quite some time," he says.

Others are pointing to the complications stemming from open-source software, such as Apache's Log4j.

Daniel Stenberg, a Sweden-based software developer and founder of cURL, discussed his views on bad practices from developers in the wake of Log4j.

"Larger open-source projects like OpenSSL and Log4j only have one or two full-time developers dedicated to the project," says Michael Isbitski, technical evangelist for Salt Security, adding that even when there are multiple participants working on an open-source project, contributors are not always writing or fixing the code. Isbitski cites the commit history, or the log of changes to source code, for Log4j as a "more obvious" example.

He also says organizations will need to actively test coding and reporting issues in projects. "Many organizations will suppress found issues in third-party and open-source code since they have a hard enough time detecting, triaging and remediating issues in their own code," he says.

Nation-States, Malicious Hackers Persist

In recent weeks, threat actors have continued to exploit the vulnerability, which takes advantage of the Apache Java Naming and Directory Interface.

Researchers at BlackBerry warned this week that Prophet Spider, an initial access broker group, was detected striving to exploit the Log4j flaw in VMware Horizon - virtual desktop software that is often times used for external-facing products. Prophet Spider was attempting to harvest credentials, among other nefarious activity.

At the end of last month, a new ransomware group known as Night Sky emerged and began taking advantage of the Log4Shell flaw. The crypto-locking malware can be installed once attackers exploit Log4j in unpatched versions of VMHorizon.

And Check Point Research, earlier this month, detected Iranian nation-backed hackers APT35, aka Charming Kitty and Phosphorous, using a JDNI exploit kit in an attempt to launch an attack.

Log4j in Ukrainian Cyberattacks?

A statement released by CERT-UA on Wednesday stated the "most likely" attack vector was supply chain compromise, after an investigation into the cyberattacks that launched on Jan. 14.

But CERT-UA has not eliminated the possibility of ties to the Log4Shell flaw.

"At the same time, two other possible attack vectors are not ruled out, namely the exploitation of October CMS and Log4j vulnerabilities," a translated version of the report reads.

Updates on the investigation will be provided as they become available.


About the Author

Devon Warren-Kachelein

Devon Warren-Kachelein

Former Staff Writer, ISMG

Warren-Kachelein began her information security journey as a multimedia journalist for SecureWorld, a Portland, Oregon-based cybersecurity events and media group. There she covered topics ranging from government policy to nation-states, as well as topics related to diversity and security awareness. She began her career reporting news for a Southern California-based paper called The Log and also contributed to tech media company Digital Trends.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.eu, you agree to our use of cookies.