Detecting and responding to Apache “Log4j 2” using Google Chronicle
Editor’s note: This post was updated on 12/14/21 at 1:15PM PST.
By Rick Correa, Security Engineering, GCP & Sharat Ganesh, Product Marketing, Chronicle
In this post, we will share how customers can detect and respond to Log4j 2, and discuss solutions available to Chronicle customers to manage the risk of the Apache “Log4j 2” vulnerability (CVE-2021–44228 and CVE-2021–45046).
Please visit Google Cloud’s advisory page for the latest updates on our assessment of CVE-2021–44228, and the potential impact of the vulnerability for Google Cloud products and services. Also review the related Google Cloud blog on broader mitigation recommendations.
Background
The Apache Log4j 2 utility is an open source Apache framework that is a commonly used component for logging requests. On December 9, 2021, a vulnerability was reported that could allow a system running Apache Log4j version 2.14.1 or below to be compromised and allow an attacker to execute arbitrary code on the vulnerable server. We strongly encourage customers who manage environments containing Log4j to update to the latest version or take the mitigation actions outlined in this post. The Cybersecurity and Infrastructure Security Agency (CISA) released additional recommendations for immediate steps regarding this vulnerability.
On December 10th, 2021, NIST published a critical CVE in the National Vulnerability Database identifying this as CVE-2021–44228. The official CVSS severity score has been determined as a 10. Log4j 2 is used in millions of applications to handle logging while the application is running and the vulnerability can allow attackers to remotely execute arbitrary Java code on a system and gain control over a vulnerable server.
Detecting Log4j 2 Exploitation
Threat Hunting and investigation tools can be used to look at historical data and determine if exploitation was attempted — or can be used as vehicles for monitoring active exploitation.
This vulnerability has been exploited actively in the wild. Chronicle can help search historical data and determine if exploitation was attempted — or can be used to monitor and detect an active exploit.
In this blog we’ll show you how to search for indicators of exploitation targeting Log4j 2 vulnerabilities across your enterprise environment.
Raw Log Search
We recommend customers use Chronicle to search for historical exploit attempts. We can use the platform to search for relevant attack substrings “jndi” across your enterprise using both UDM Structured Query and Raw Log Scan + Regular Expressions (RegEx). You can also try different regex variations of jndi..
Detecting matching log entries does not indicate that there has been a successful compromise. It may indicate that someone is probing to exploit the vulnerability within your enterprise, and will be an indicator to your risk level.
Detection Rules
Chronicle uses its UDM to normalize log data, making it possible to search for indicators and TTPs in fewer steps. The following two rules are powerful examples of this. Many sources have flagged attackers using the user agents, urls, and referral urls to encode malicious JNDI urls. One of the most critical indicators to search for is to check for process execution using JNDI strings in your search. This process launch data is consumed from a majority of EDRs today, and Chronicle can look for process execution with the relevant strings (even cross platform operating systems, if it can be captured in a regular expression).
rule cve_2021_44228_execution {meta:tactic = “TA0002”description = “Identifies process execution using JNDI strings.”events:$event.metadata.event_type = “PROCESS_LAUNCH”$event.target.process.command_line = /.*\$\{jndi\:(ldap|rmi|ldaps|dns)\:.*\}.*/ nocase$event.principal.hostname = $hostnamecondition:$event}
Detecting process execution using JNDI strings
Additionally, continuously searching for JNDI strings in HTTP requests will provide security teams the ability to identify malicious JNDI urls encoded in user-agents, urls and referral urls. Chronicle allows various sources (including network and proxy logs) to be combined in a single rule.
rule cve_2021_44228_http {meta:tactic = "TA0002"technique = "T1059"description = "Identifies JNDI strings in network user agents or URIs."reference = "https://www.lunasec.io/docs/blog/log4j-zero-day/"events:$event.metadata.event_type = "NETWORK_HTTP"($event.network.http.user_agent = "({jndi:.*}|{env:.*}|:j}.*{)" or
$event.network.http.referral_url = "({jndi:.*}|{env:.*}|:j}.*{)" or$event.target.url = "({jndi:.*}|{env:.*}|:j}.*{)")condition:$event}
Identify Low Prevalence Events
An attacker could exploit this vulnerability by sending a specially crafted request to a server running a vulnerable version of log4j 2. This can lead to further compromise by having assets in your environment beacon out to malicious servers.
Prevalence measures the number of assets within your enterprise connected to a specific domain over the past seven days. More assets connecting to a domain means that the domain has greater prevalence within your enterprise. High prevalence domains, such as google.com, are unlikely to require investigation.
You can use the Prevalence slider to filter out the high prevalence domains and focus on the domains which fewer assets across your enterprise have accessed. Chronicle customers can also look at external communication events for low-prevalence destinations that could be an indication of impacted systems reaching out for remote code execution.
We will continue to actively monitor this event and will provide updates to this blog post on relevant responses and detections in Chronicle.
