Detecting Exploitation of CVE-2021-44228 (Log4j2) with Elastic Security

To understand how Elastic is currently assessing internal risk of this vulnerability in our products please see the advisoryhere.

This blog has been updated (Dec. 17, 2021) with further detection and hunting improvements since its initial publish.

Overview

This blog post provides a summary of CVE-2021-44228 and provides Elastic Security users with detections to find active exploitation of the vulnerability in their environment.

Further updates will be provided to this post as we learn more. This version is accurate as of Tuesday, December 14, 2021. Updates from Apache may be investigated directly via the security page for Log4j2.

Summary of CVE-2021-44228 (Log4Shell)

Log4j2 is an open source logging framework incorporated into many Java based applications on both end-user systems and servers. In late November 2021, Chen Zhaojun of Alibaba identified a remote code execution vulnerability, ultimately being reported under the CVE ID : CVE-2021-44228, released to the public on December 10, 2021. The vulnerability is exploited through improper deserialization of user-input passed into the framework. It permits remote code execution and it can allow an attacker to leak sensitive data, such as environment variables, or execute malicious software on the target system.

The identified vulnerability impacts all versions of Log4j2 from version 2.0-beta9 to version 2.14.1. Early methods to patch the issue resulted in a number of release candidates, culminating in recommendations to upgrade the framework to Log4j2 2.15.0-rc2 at the time of this post.

Given the trivial complexity and the nature of observed widespread exploitation, mitigation should be considered critical in any environment that has identified software leveraging vulnerable versions of Log4j2.

Detecting Exploitation of Log4Shell in Elastic Security

Elastic Security users can use the following Event Correlation detection rule to identify active exploitation of the Log4j2 vulnerability. Depending on the format of the host based event data you may need to modify this detection to match your data fields.

Detection Rule when using Endpoint data

sequence by host.id with maxspan=1m
 [network where event.action == "connection_attempted" and
  process.name : "java" and
  /*
     outbound connection attempt to
     LDAP, RMI or DNS standard ports
     by JAVA process
   */
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh",
                   "bash",
                   "dash",
                   "ksh",
                   "tcsh",
                   "zsh",
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*",
                   "wget")] by process.parent.pid

Detection Rule when using Auditbeat data

sequence by agent.id with maxspan=1m
 [network where event.action == "connected-to" and
  process.name : "java" and
  /*
     outbound connection attempt to
     LDAP, RMI or DNS standard ports
     by JAVA process
   */
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh",
                   "bash",
                   "dash",
                   "ksh",
                   "tcsh",
                   "zsh",
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*",
                   "wget")] by process.parent.pid

Detection rule when using Endgame streamed events

sequence by agent.id with maxspan=1m
 [network where event.category == "network" and
  process.name : "java" and
  /*
     outbound connection attempt to
     LDAP, RMI or DNS standard ports
     by JAVA process
   */
  destination.port in (1389, 389, 1099, 53, 5353)] by process.pid
 [process where event.type == "start" and

  /* Suspicious JAVA child process */
  process.parent.name : "java" and
   process.name : ("sh",
                   "bash",
                   "dash",
                   "ksh",
                   "tcsh",
                   "zsh",
                   "curl",
                   "perl*",
                   "python*",
                   "ruby*",
                   "php*",
                   "wget")] by process.parent.pid

This detection rule looks for a sequence of an outbound connection attempt to standard ports for LDAP, RMI and DNS (often abused via recently observed JAVA/JNDI injection attacks) followed by a child process of the same Java process instance.

Now, let’s demonstrate how this rule detects exploitation of the log42j vulnerability:

The screenshot above shows an attacker exploiting the vulnerability with a base-64 encoded payload targeting an example vulnerable application created by Christophe Tafani-Dereeper.

This screenshot shows the detection of the active exploitation of CVE-2021-44228 within Elastic Security detailing both the alert and timeline view of the exploit.

The screenshot above shows in the investigation of the detection alert that Java executed a shell script to download and run a bash script.

Update: Detection & hunting improvements

Suspicious Shell Commands Execution via Java

Based on observed publicly known malicious Java classes served via log4j exploit, you can hunt for suspicious shell scripts and ingress tool transfer commands:

process where event.type == "start" and
  process.parent.name : "java*" and

  /* Ingress tools transfer via common shell command interpreters */

  /* linux or macos */
  (
   (process.name : ("sh", "bash", "python*") and
    process.command_line : ("*curl*|*sh*", "*wget*|*bash", "*curl*|*bash*", "*curl*|*bash*", "*http*|*sh*", "*python*http*")) or

  /* windows */
  (process.name : ("powershell.exe", "pwsh.exe", "cmd.exe") and
   process.command_line : ("*.downloadstring*", "*.downloadfile*", "*.downloaddata*", "*BitsTransfer*", "* -enc*", "* IEX*", "*wp-content*", "*wp-admin*", "*wp-includes*", "*$*$*$*$*$*", "*^*^*^*^*^*^*^*^*^*", "*.replace*", "*start-process*", "*http*", "*cmd*powershell*")))

Untrusted File Execution via JAVA

Identifies when a JAVA interpreter creates an executable file (PE/ELF) and the file is subsequently executed.

Detection Rule when using Endpoint data

sequence by host.id with maxspan=5m
 [ file where event.type != "deletion" and
  process.name : ("java", "java.exe", "javaw.exe") and

  (file.extension : ("exe", "com", "pif", "scr") or
      /* Match Windows PE files by header data (MZ) */
  file.Ext.header_bytes : ("4d5a*", "7f454c46*")) and

  not file.path :  ("?:\\Program Files\\*",
                    "?:\\Program Files (x86)\\*") ] by file.path
 [ process where event.type == "start" and
  not process.code_signature.trusted == true ] by process.executable

Detection rule when using Endgame streamed events

sequence by agent.id with maxspan=5m
  [ file where event.type != "deletion"
    process.name : ("java", "java.exe", "javaw.exe")] by file_path
  [ process where event.type == "start" and
  not process.code_signature.trusted == true] by process_path

Potential CoinMiner activity

Process with command line common to cryptocurrency miner (most observed campaigns leveraging log4j exploit are coinminers):

process where event.type == "start" and
 process.command_line :
       ("* pool.*", "*-u*--coin*", "*.xmr.*", "*.xmr1.*",
        "*stratum*", "*elitter.net*", "*cryptonight*",
        "*-a scrypt*", "*stratum1*", "*-userpass*", "*-max-cpu-usage*",
	  "*qhor.net*", "*-wallet*pool*", "*--donate-level*", "*supportxmr.com*")

Other relevant post exploitation detections :

Attempt to Disable IPTables or Firewall

Tampering of Bash Command-Line History

System Log File Deletion

Potential Reverse Shell Activity via Terminal

Suspicious JAVA Child Process

Attempt to Disable Syslog Service

Elastic Endgame EQL Queries

Suspicious Java Netcon followed by Unusual Child Process

sequence with maxspan=5s
 [network where process_name == "java*" and destination_port in (1389, 389, 1099, 53, 5353) and
  destination_address != "127.0.0.1" and not destination_address == "::1"] by pid
 [process where opcode in (1,5) and
  /* Suspicious JAVA child process */
  parent_process_name == "java*" and
   process_name in ("sh", "bash", "dash", "ksh", "tcsh", "zsh", "curl", "perl*", "python*", "ruby*", "php*", "wget", "powershell.exe", "cmd.exe")] by ppid

Suspicious Shell Commands Execution via Java

process where opcode in (1,5) and
  parent_process_name == "java*" and
  /* Ingress tools transfer via common shell command interpreters */

  /* linux or macos */
 (
  (process_name in ("sh", "bash", "python") and
   wildcard(command_line, "*curl*|*sh*", "*wget*|*bash", "*curl*|*bash*", "*curl*|*bash*", "*http*|*sh*", "*python*http*")) or
  /* windows */
  (process_name in ("powershell.exe", "pwsh.exe", "cmd.exe") and
   wildcard(command_line,"*.downloadstring*", "*.downloadfile*", "*.downloaddata*", "*BitsTransfer*", "* -enc*", "* IEX*", "*wp-content*", "*wp-admin*", "*wp-includes*", "*$*$*$*$*$*", "*^*^*^*^*^*^*^*^*^*","*.replace*", "*start-process*", "*http*", "*cmd*powershell*")))

Common Coin Miners as a descendant of JAVA

process where opcode in (1, 3, 4, 5) and
 descendant of [process where opcode in (1, 3, 4, 5) and process_name == "java*"] and
 wildcard(command_line, "* pool.*", "*-u*--coin*", "*.xmr.*", "*.xmr1.*", "*stratum*", "*elitter.net*", "*cryptonight*", "*-a scrypt*", "*stratum1*",
"*-userpass*", "*-max-cpu-usage*", "*qhor.net*", "*-wallet*pool*",  "*--donate-level*", "*supportxmr.com*",
/* evasion commands */
"*base64*", "*history -c*", "*ld.so.preload*", "*nmi_watchdog*", "*ufw*disable*", "*.bash_history*", "*chmod*+x*",
"*tor2web*", "*kill*-9*", "*python*-c*http*")

Untrusted File Execution via JAVA

sequence with maxspan=2m
  [ file where opcode != 2 and file_name == "*.exe" and process_name == "java*"] by file_path
  [ process where opcode in (1,5)] by process_path

Community Detections

A number of community members discussing widespread exploitation of the vulnerability have provided insights into a number of early detection methods that analysts may leverage to identify if systems they are using have been exploited or are under active exploitation:

A series of payloads have been shared by the GreyNoise team, including payloads containing both encoded and decoded variants for analysts looking to explore logs stored within their systems. This has been complemented with a list of initial tagged IPs attempting exploitation of the vulnerability.
Florian Roth of Nextron Systems has provided a series of checks for local exploitation using grep / zgrep, alongside some initial YARA signatures in a Gist listed on his Github account. Florian also shared a method for generating Thinkst CanaryTokens to test systems you may manage for exploitability.
Rob Fuller (Mubix) has shared a list of known file hashes for vulnerable versions of the framework, here.

Additional Mitigation Strategies

Outside of the recommended guidance from the Apache team regarding the deployment of the latest, patched versions of the Log4j2 framework to update, a number of mitigations have been widely suggested to prevent exploitation:

Fastly have suggested checking if your version of Log4j supports executing the JVM with JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true to disable the lookup functionality to the remote server. This should apply to versions 2.10.0 through 2.15.0.
To prevent lateral movement from a vulnerable host, or exploitation over the network, limiting connectivity from potentially vulnerable systems to external resources to trusted applications and / or services is recommended.

Thank you, from Elastic Security.

We want to thank all of the security teams across the globe for your tireless work today and through the weekend, especially those of you listed in this post. Openness and collaboration in the security community to safeguard all users is paramount when facing such a serious and pervasive vulnerability. We want you to know we are here with you every step of the way.

Existing Elastic Security can access these capabilities within the product. If you’re new to Elastic Security, take a look at our Quick Start guides (bite-sized training videos to get you started quickly) or our free fundamentals training courses. You can always get started with a free 14-day trial of Elastic Cloud. Or download the self-managed version of the Elastic Stack for free.