The Log4j exploit was discovered in December 2021, and by now, it should have been resolved. However, it persists.
According to IBM, Log4j vulnerabilities are actively tracked and exploited by attackers. A recent Forbes article highlighted that many organizations remain exposed. The reasons range from patching delays to unknown dependencies and, most commonly, a lack of visibility into what is actually running across their environments.
This ongoing risk points to a deeper issue — one that goes beyond a single vulnerability. It underscores the persistent challenge organizations face in identifying, prioritizing and eliminating deeply embedded threats, particularly those hidden within legacy systems or third-party components.
In many environments, teams are still grappling with a fundamental question: Do we have any Log4j instances still running in production? This uncertainty alone poses a significant risk.
The reality is that the Log4Shell breach path was not particularly complex. Exploits were often triggered by outbound lightweight directory access protocol (LDAP) or remote method invocation (RMI) connections from vulnerable internal servers — behaviors that should have raised immediate alarms. Yet, in many cases, no one was tracking these connections, and many teams were unaware they even existed.
Visibility is no longer optional — it is the foundation of effective security. Below are five key steps any organization can take right now to locate and eliminate vulnerable Log4j instances from their environment once and for all.
-
Implement Continuous Software Composition Analysis
Many organizations conducted software composition analysis (SCA) scans only once — immediately after the Log4j vulnerability was disclosed — and then moved on. However, software ecosystems are constantly evolving. New code is deployed, containers are updated and dependencies change frequently.
Modern SCA tools offer continuous insight into both direct and transitive dependencies. They can detect vulnerable versions of Log4j across code repositories, container images, build artifacts and runtime environments — even in areas that teams may have overlooked.
To prevent vulnerabilities like Log4j from resurfacing, implementing continuous SCA is essential.
-
Strengthen Patch Governance and Consider Virtual Patching
In some cases, updating a vulnerable component may not be possible. Legacy software may no longer be supported, or the risk of downtime could outweigh the benefits of a complete upgrade.
In such situations, virtual patching can serve as an effective solution. This approach involves implementing a security control — such as a web application firewall (WAF) or endpoint protection system — in front of the vulnerable system to intercept exploit attempts. While virtual patching is not a substitute for actual updates, it offers temporary protection and helps reduce risk exposure while long-term solutions are underway.
Strong patch governance policies are essential for ensuring that all components are consistently tracked and updated across both development and production environments.
-
Use Application Dependency Mapping
Application dependency mapping (ADM) platforms assist teams in identifying the full range of services operating within their environment, particularly those that are often overlooked.
Agentless ADM solutions, such as the one we have built at Faddom, can monitor East-West traffic, revealing connections between services that typically remain hidden. This functionality is essential for uncovering shadow IT, orphaned virtual machines, outdated applications and forgotten internal tools that may still be using Log4j.
The value of ADM lies in its behavior-focused approach. It does not depend on manual inventories or assumptions. If an application is generating traffic or responding to requests, it will be detected. Furthermore, if that traffic involves protocols such as LDAP or RMI (commonly associated with Log4j exploits), security teams can investigate those connections further.
-
Track Outbound Traffic for Suspicious Behavior
One of the core indicators of Log4Shell exploitation is outbound communication with attacker-controlled infrastructure. In many attacks, internal servers connect to malicious domains through LDAP, RMI or hypertext transfer protocol (HTTP) to retrieve remote payloads.
Monitoring outbound traffic and setting alerts for connections to unexpected external domains or the use of unsupported protocols is an effective way to detect active exploitation. This method can also uncover compromised systems that may have been overlooked during the initial response phase.
To support this, security teams should regularly analyze domain name system (DNS) queries, proxy logs and firewall activity to detect anomalies and trace them back to their source.
-
Enhance Visibility Into the CI/CD Pipeline
Catching a vulnerability early makes it significantly easier to address. Therefore, security should be integrated into the software development life cycle rather than added at the end.
To prevent deployments that include known vulnerable versions of Log4j, incorporate SCA and dependency checks into your continuous integration and continuous deployment (CI/CD) pipeline. Establish rules to block outdated libraries from being included in new builds. Most importantly, make component tracking part of release process so you can accurately monitor which version of each library is in use at any given time.
By ensuring clear visibility and control during the development stage, you can significantly reduce the risk of reintroducing known vulnerabilities.
The Bottom Line
Eliminating Log4j is not a one-time task — it requires continuous commitment to visibility, governance and automation. When implemented together, these five strategies can assist organizations in detecting and eliminating not only Log4j, but also other hidden and persistent vulnerabilities that often evade traditional security measures.
If your team is unsure whether Log4j has been completely removed from your network, the issue lies not in the patching process but in a lack of visibility.