Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

We have published an initial blog on the Log4j exploit and a followup blog with a second detection method for detecting the first stage of exploits occurring over LDAP. Today, we will discuss a third detection method, this one focused on the second-stage download that happens after the first stage completes. In this case, the JVM will download additional Java code payloads over HTTP.

There's little question that you've already heard about the recently discovered security flaw related to Log4j, a widely used Java library for logging error messages in applications. The vulnerability enables a threat actor to remotely execute commands via remote code execution (RCE) on nearly any machine using Log4j. But it's also important to cut through all of the noise to truly understand the implications of the Log4j and what organizations can do to combat it.

After successful deployment to Arctic Wolf’s customer community of more than 2,300 organizations worldwide, today we are making “Log4Shell Deep Scan” publicly available on GitHub. Log4Shell Deep Scan enables detection of both CVE-2021-45046 and CVE-2021-44228 within nested JAR files, as well as WAR and EAR files.

A critical vulnerability has been recently discovered in the Apache Log4j Java logging library (CVE-2021-44228), a library used in many client and server applications. The Log4j library is commonly included in Java based software including multiple Apache frameworks such as Struts2, Solr, Druid and Fink. The library provides enhanced logging functionality for Java applications and is commonly used in business system development.

Dec. 29: Updated to cover three additional CVEs: CVE-2021-4104, CVE-2021-44832, and CVE-2021-42550 (in logback as opposed to log4j). Dec. 22: A joint Cybersecurity Advisory was issued by multiple national cybersecurity agencies providing mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105. Dec. 17: Please note the emergency directive from CISA on Log4j.

Dec. 29: Updated to cover three additional CVEs: CVE-2021-4104, CVE-2021-44832, and CVE-2021-42550 (in logback as opposed to log4j). Dec. 22: A joint Cybersecurity Advisory was issued by multiple national cybersecurity agencies providing mitigation guidance on addressing vulnerabilities in Apache’s Log4j software library: CVE-2021-44228 (known as “Log4Shell”), CVE-2021-45046, and CVE-2021-45105. Dec. 17: Please note the emergency directive from CISA on Log4j.

New day. New threat. New technology to combat said threat. Sound familiar? The threat landscape is continually evolving and getting more sophisticated, and, in an attempt to keep up, many organizations are quick to adopt the latest buzz-worthy product. This is a recipe for disaster.

While many organizations are patching the two recent Apache Log4j vulnerabilities (CVE-2021-44228 and CVE-2021-45046), attackers have been racing to exploit them to deliver malware, such as botnets, backdoors, and cryptominers. Among the threats delivered using Log4Shell exploits, a new ransomware family was found by Bitdefender: Khonsari.

The Apache Log4j vulnerability has been assigned the most critical cyber threat rating of CVSS 10. For a concise overview of the zero-day, and to learn how to secure your systems against its exploitation, all of the popular FAQs concerning this vulnerability have been conveniently compiled in this post.