In recent days, the cybersecurity industry has been rapidly assessing the full impact of the Log4Shell (CVE-2021-44228 and CVE-2021-45046) vulnerability. Many organizations are quickly trying to figure out whether this vulnerability is within their environment, and where. The next question a security operations team will ask is if its presence has been exploited. This is critical to answer quickly given Log4Shell’s high severity, the pervasiveness of Java, and its ease of exploitation.

In a previous blog we discussed how to mitigate the threat of this vulnerability via a patch or configuration change. Now let’s take a deep dive into how this exploit unfolds, and how you can quickly assess if Log4Shell has been exploited in your environment.

How the Exploit Works

Similar to many other remote code execution vulnerabilities, Log4Shell can be exploited due to input not being validated by the code. When using the log4j2 functionality, the text being logged can use what are known as lookups. For example, if you wanted to log the version of Java or perhaps the operating system running the application, you can denote that within the logged string such as ${java:version} or ${java:os} , respectively. Since the input is not being validated, whoever controlled the test of the log could leverage these lookups.

What this specific exploit is doing is leveraging the Jndi Lookup feature. JNDI is the Java Naming and Directory Interface which provides an interface to LDAP, CORBA, RMI, and DNS functionality. When used as directed, this provides a valuable way for developers to quickly lookup information from those services. However, since there was no input validation in the vulnerable instances of Log4J2, this gives attackers the opportunity to run arbitrary code remotely from anywhere in the world.

Armed with this information, attackers are running scans on the internet looking for vulnerable hosts directly connected to the internet. A simple non-malicious test to conduct is to force the vulnerable machine to make a DNS lookup. Without running suspicious commands or injecting malicious code onto a machine, this is a quick way to validate that the vulnerability exists.

To do this, attackers have been seen placing the malicious Jndi Lookup string anywhere they suspect a field could be logged. This could be anything – such as forms on websites intended for user interaction to hidden fields used by machines (e.g. the user agent of the web browser). There have even been instances of vulnerable machines being detected using an wrongly placed SSID being read and logged by other machines locally. With the prevalence of Java running on 15 billion devices worldwide, the attack surface of the Log4Shell vulnerability is enormous.

Let’s review 6 key detection opportunities to help you locate the Log4Shell vulnerability within your environment.

Detection Opportunity 1: Scan Logs for Malicious Strings

Since this is an attack on the logging server, you may be actively collecting those logs into a centralized location such as a log manager, SIEM, or XDR solution. First, you should look for sample strings known for this exploit, such as “JNDI”. This will not be an exhaustive search, as the commands can be heavily obfuscated, such as adding printing out JNDI as ${::-j}${::-d}${::-d}${::-i} or ${lower:j}${lower:n}${lower:d}${lower:i} . The combinations of obfuscation can be nearly endless, so it’s important to rely on detection in depth and to look for post exploitation events as well.

Another important aspect to remember is that only failed exploit attempts will be visible in the logs. If the exploit is successful and the payload is correctly interpreted by the JNDI handler, the payload will execute without making any entry in the logs. As such, a successful exploit will most probably be blind to log inspection.

Detection Opportunity 2: Look for Java Making Network Connections

The core component of this exploit is that Log4J2 is leveraging the lookup functionality to make a network lookup to these remote services (LDAP, RMI, etc.). While Java making network connections itself is not anomalous in itself, making connections to these services suddenly this week is highly suspect.

The following QQL queries in Qualys EDR can isolate hosts which have these types of connections:

• process.name:”java” and network.remote.address.port:53 and type:NETWORK and action:ESTABLISHED
• process.name:”java” and network.remote.address.port:389 and type:NETWORK and action:ESTABLISHED
• process.name:”java” and network.remote.address.port:1389 and type:NETWORK and action:ESTABLISHED
• process.name:”java” and network.remote.address.port:636 and type:NETWORK and action:ESTABLISHED
• process.name:”java” and network.remote.address.port:1098 and type:NETWORK and action:ESTABLISHED
• process.name:”java” and type:NETWORK and action:ESTABLISHED

The first four commands will hunt for Java processes making connections to remote DNS, LDAP, LDAPS, or RMI services. The final command is more generic and will find all instances of Java making a network connection. This will be useful to broaden the search to validate network connections for potential exploits still unknown at the time of this writing.

Detection Opportunity 3: Look for Java Calling Suspicious Processes

Once an attacker validates that a system is exploitable, they will try to execute code on the victim’s machine. This could come in the form of downloading malicious files or executing trusted binaries in malicious ways using Living off the Land – Binaries and Scripts (LOLBAS) techniques. Commonly you will see something such as scripting languages or data transfer utilities.

The following QQL queries can find evidence of such activity:

• process.parentname: “java” and process.name: “cmd.exe”
• process.parentname: “java” and process.name: “powershell.exe”
• process.parentname: “java” and process.name: “pwsh.exe”
• process.parentname: “java” and process.name: “wscript.exe”
• process.parentname: “java” and process.name: “cscript.exe”
• process.parentname: “java” and process.name: “python.exe”
• process.parentname: “java” and process.name: “perl.exe”
• process.parentname: “java” and process.name: “ruby.exe”
• process.parentname: “java” and process.name: “curl.exe”
• process.parentname: “java” and process.name: “wget.exe”

Running these “as is” will likely return results of benign and known applications. These can then be used to filter out known-good (what?) and narrow down suspicious invocations of the exploit taking place.

Detection Opportunity 4: Hunt for Java Processes Using Log4J2

Simply looking for applications that are known to load Log4J2 will be useful in understanding your attack surface. This will provide insight on machines which may be actively vulnerable to exploit. Use the following QQL in Qualys EDR to find instances of log4j2 being loaded:

• process.arguments:” log4j-core-2″

Alternatively, as a broader search you can find all assets that are running Java in your environment by using the following QQL search:

• process.name:”java”

Detection Opportunity 5: Search for Known Payloads

Post exploitation activities (after an adversary gains access) often include dropping various malware families on the box. The malware that gets deployed will be entirely dependent on the adversary taking the action. The following malware families have been observed exploiting Log4Shell already:

• Bazarloader
• Mirai
• Various Cryptocurrency Mining Software

The presence of Bazarloader leads Qualys to believe that this vulnerability will be actively used by some of the more well-known adversarial groups. Searching for the presence of malware and performing a comprehensive incident response into where it originated is especially important given the prevalence of the Log4Shell vulnerability.

Detection Opportunity 6: Find Evidence of Exploitation Attempts

For Qualys EDR customers who are leveraging the AntiMalware engine, there are specific detections that can be searched within the environment to find evidence of someone attempting to exploit this vulnerability. These detections are specifically looking at the network traffic which the java process will make when performing the Jndi lookups mentioned above.

To find these exploit attempts, you can leverage the following queries:

• event.networkDetectionName:”Exploit.HTTP.CVE-2021-44228.Log4Shell”
• event.networkDetectionName:”Exploit.CVE-2021-4228.Log4Shell”

Key Points

While the Log4Shell vulnerability is grabbing headlines around the world, it is important to remember that there remain other active threats. Proactively preventing, detecting, and responding to adversarial behavior will ensure that you are protected against all of them.

Each of these 6 detection opportunities and how Qualys prevents Log4Shell attacks are described in this recent blog. Additionally, leveraging the MITRE ATT&CK framework to hunt for post exploitation activity can yield valuable insights while hunting for adversarial activity. Looking at an adversarial playbook, we know that some of the initial steps an attacker will take are performing reconnaissance to get situational awareness, lateral movement to find your “crown jewels”, and credential access to make their attacks successful.

Searching for such activity is made easy with the Qualys EDR. For example, high level searches such as these can find high level behaviors:

• mitre.attack.tactic.name: “Reconnaissance”
• mitre.attack.tactic.name:”Lateral Movement”
• mitre.attack.tactic.name:”Credential Access”

Prevent Future Attacks

Patching with a software vendor’s security update is the best bet to plug known vulnerabilities. Qualys Patch Management can also remove the JndiLookup.class to neuter the exploitation of Log4Shell altogether.

Multi-Vector EDR is continually updated with the latest threat intelligence and detection techniques to constantly monitor endpoints and to protect against existing and future exploits of the Log4Shell vulnerability.

The Qualys Malware Threat Research Team anticipates that what we know today is just the tip of the iceberg. We predict that there will be an avalanche of malware and attacks exploiting Log4Shell throughout the remainder of 2021 and 2022. You can be assured that we will continue monitoring the situation 24/7 to ensure coverage of any new exploit techniques.

Free 30 Days of Qualys Multi-Vector EDR

To help security teams protect, detect, and respond to Log4Shell Exploits, Qualys is offering Multi-Vector EDR free for 30 days. Sign up today to take advantage of this limited time offer.