Loading story…
Attackers continued to exploit Log4Shell (CVE-2021-44228) well after its disclosure, using crafted JNDI payloads over LDAP, RMI, and DNS to gain remote code execution, leak data, and establish initial access on vulnerable Java applications. Security reporting and vendor guidance showed sustained abuse against internet-facing and internal systems, including VMware Horizon and other VMware products, while mass scanning also targeted broadly deployed services such as Elasticsearch 5 and OpenNMS. Sophos and Google observed exploit traffic at very high volume, ranging from reconnaissance and proof-of-concept probes to cryptominer deployment, botnet activity tied to Kinsing, Mirai, and Tsunami, credential theft attempts, and follow-on post-compromise tooling.
Research and incident guidance indicated the risk persisted because vulnerable Log4j components remained embedded in legacy and third-party software, and because JNDI injection could still be weaponized quickly even where newer Java protections reduced some remote class-loading paths. Horizon3 reported successful exploitation in 23.5% of assessed internal environments in early 2022 and demonstrated unauthenticated attack paths in products including VMware Site Recovery Manager 8.3.0, while CISA warned that malicious actors were actively exploiting Log4Shell in VMware Horizon systems. Defenders were urged to prioritize upgrades to safe Log4j releases, apply VMware advisories, inventory indirect dependencies, and monitor for outbound lookup traffic, remote execution, persistence, and lateral movement after initial compromise.
See which actors are running it and whether you're in range.
26 events from the most recent confirmed update back to the earliest known activity.
Veracode published research showing that even after Oracle's Java 8u191 restrictions, JNDI injection can still lead to code execution when Apache Tomcat's org.apache.naming.factory.BeanFactory is present on the target classpath. The proof of concept used a crafted ResourceRef to instantiate javax.el.ELProcessor and execute a command via a malicious RMI server.
CISA published an alert warning that malicious cyber actors continued to exploit Log4Shell in VMware Horizon systems. The alert underscored that the vulnerability was still being actively abused months after disclosure.
Horizon3 said NodeZero detected and exploited Log4Shell in 23.5% of internal environments assessed from January through June 2022. The report highlighted persistent enterprise risk more than six months after disclosure.
Horizon3 reported that NodeZero detected and exploited Log4Shell in 22.1% of assessed internal networks during June 2022, continuing the pattern of persistent exposure.
Horizon3 reported that NodeZero detected and exploited Log4Shell in 18.5% of assessed internal networks during May 2022. Even at this lower monthly rate, the flaw remained broadly exploitable.
Horizon3 reported that NodeZero detected and exploited Log4Shell in 23.3% of assessed internal networks during April 2022, showing exploitation remained common months after disclosure.
Barracuda reported that ongoing Log4Shell exploitation remained relatively steady and was primarily being used to deploy Mirai-based DDoS botnets and cryptomining malware such as BillGates, Kinsing, XMRig, and Muhstik. The company said many systems were still running outdated Log4j versions, sustaining these campaigns.
Horizon3 reported that NodeZero detected and exploited Log4Shell in 32.1% of assessed internal networks during March 2022, the highest monthly rate cited for the first half of the year.
Horizon3 reported that NodeZero detected and exploited Log4Shell in 25.9% of assessed internal networks during February 2022, indicating continued widespread exposure.
Google Cloud published its revised February 2022 Threat Horizons report summarizing continued Log4j scanning, customer mitigation efforts, and post-compromise tradecraft such as Sliver use and Cloud Shell reverse SSH tunneling. The report also included defensive recommendations for patching, credential protection, and log review.
Horizon3 reported that NodeZero detected and exploited Log4Shell in 22.0% of assessed internal networks during January 2022, showing the vulnerability remained prevalent well after disclosure.
IronNet reported that after failed attempts on December 15, a threat actor successfully exploited Log4Shell against a Defense Industrial Base customer on December 16, 2021, using JNDI/LDAP to launch a reverse TCP shell. The attacker then performed host and network enumeration and downloaded a second-stage scanner before the organization quarantined the server.
Sophos reported that exploit attempts peaked on December 15, 2021, and then remained at very high volume. The company observed millions of exploit attempts in customer telemetry during the first week after disclosure.
Microsoft reported state-directed exploitation of Log4j, marking an escalation beyond opportunistic scanning and cryptominer activity. Gigamon noted the disclosure date did not necessarily reflect the earliest state-backed activity.
Security firms identified possible attempts to use CVE-2021-44228 in ransomware distribution starting on December 13, 2021. Later observations linked Log4j exploitation to entities working for or with ransomware distribution networks such as Conti.
Google Cloud Threat Intelligence and Google Trust and Safety observed scanning for vulnerable Log4j instances on the same day the vulnerability was publicly disclosed. The report later said scanning continued at roughly 400,000 times per day.
Apache Log4j remote code execution vulnerability CVE-2021-44228, widely known as Log4Shell, was publicly disclosed. The flaw enabled attacker-controlled JNDI lookups that could lead to remote code execution in many Java applications.
VMware published security advisory VMSA-2021-0028 covering its response to Apache Log4j remote code execution vulnerabilities, including affected VMware products and remediation guidance.
Symantec said its IPS blocked more than 93 million Log4Shell-related exploitation attempts on over 270,000 unique machines between December 9 and December 21, 2021, including more than 18 million attempts against over 60,000 server machines. The company also said most targeted machines were in the United States and United Kingdom, while apparent source devices were mainly in the United States and Germany.
Subsequent investigation indicated exploitation of Log4j began as early as December 1, 2021, before public disclosure. This showed attackers were already abusing the flaw prior to the public announcement.
Horizon3 confirmed that malformed JSON in an Elasticsearch search request could trigger a logged JNDI lookup and demonstrated exploitation of Elasticsearch 5 using remote class loading. The researchers found versions 6 and later allowed attacker-controlled DNS lookups but did not permit the tested remote code execution path.
Horizon3 researchers found an unauthenticated Log4Shell injection point in VMware Site Recovery Manager 8.3.0's OAuth2LoginServlet and achieved remote code execution as the tomcat user. They noted VMware's advisory identified Site Recovery Manager as affected and estimated about 20 instances were publicly exposed.
By the time of Sophos's later December reporting, three sets of fixes had been released for Log4j because additional vulnerability paths were uncovered and earlier patches and workarounds proved insufficient. Sophos identified 2.17.0 for Java 8 and 2.12.3 for Java 7 as safe versions.
Researchers reported that threat actors were exploiting Log4Shell via the RMI variant to deliver Dridex malware to Windows systems and Meterpreter to Linux systems. The campaign used a malicious Java class fetched from attacker-controlled infrastructure, with the Windows chain leading to a Dridex DLL and the Linux chain installing a remote shell payload.
Sophos detected hundreds of thousands of Log4Shell exploitation attempts shortly after disclosure, with activity including scanning, exploit testing, cryptominer deployment, and attempts to steal AWS credentials and other data. The company observed LDAP, DNS, and RMI being used in exploit traffic.
Apache released Log4j 2.15.0 as the recommended patched version after Log4Shell disclosure. Defenders were urged to upgrade or apply mitigations because the vulnerable message lookup feature was enabled by default in earlier versions.
Vulnerabilities, threat actors, malware, products, organizations, breaches, and observables Mallory has linked to this story. Indicator values are masked here and available in full in the app.
Indicator values are masked on this page. View all 15 in Mallory Domains, IPs, hashes, and URLs are exportable to your SIEM.
Correlate live exploitation activity against the software you actually run, and see where you're exposed.
16 references tracked. Mallory keeps watching after this page renders.
news.sophos.com
Open sourcenews.sophos.com
Open sourcenews.sophos.com
Open sourcenews.sophos.com
Open sourceironnet.com
Open sourcevmware.com
Open sourcesensepost.com
Open sourceservices.google.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Threat actors, including suspected state-sponsored groups, continued exploiting **Log4Shell** (`CVE-2021-44228`) in unpatched public-facing **VMware Horizon** and **Unified Access Gateway** systems, according to a joint CISA and U.S. Coast Guard Cyber Command advisory. In confirmed incidents, attackers used the flaw for initial access, deployed malware disguised as SysInternals tools, established command-and-control, moved laterally over RDP, and in at least one case reached a disaster recovery network and exfiltrated sensitive data. The advisory highlighted artifacts including `hmsvc.exe`, `SvcEdge.exe`, `odbccads.exe`, `praiser.exe`, `fontdrvhosts.exe`, `winds.exe`, `error_401.jsp`, and `newdev.dll`, and urged organizations that delayed patching to assume compromise, isolate affected hosts, hunt for indicators, and upgrade to fixed VMware builds. The vulnerability’s broad reach and difficult-to-observe execution paths also drove a wave of defensive tooling and monitoring guidance across the security community. Researchers released a Burp Suite **Log4Shell Scanner** that uses out-of-band DNS and LDAP-based callbacks to uncover hidden or asynchronous vulnerable services, while others published **Suricata** detection coverage, regex-based IOC matching for log review, and updated enterprise advisories from vendors including Red Hat, Sophos, Mandiant, and SANS. Reports also indicated exploitation activity had begun early, with botnets attempting to weaponize the flaw soon after disclosure, reinforcing that Log4Shell remained both a mass-scanning target and a high-impact intrusion vector long after patches became available.
Aug 28, 2026
A critical remote code execution flaw in Apache Log4j, tracked as **`CVE-2021-44228`** and widely known as **Log4Shell**, exposed a vast range of Java applications and services to unauthenticated compromise through the library’s JNDI lookup feature. Security reporting said the bug affected Log4j versions **`2.0-beta9` through `2.14.1`**, with early warnings surfacing through attacks against Minecraft servers before researchers and vendors confirmed broader exposure across enterprise software, cloud services, and Apache frameworks including Struts2, Solr, Druid, Flink, and Kafka. Researchers also warned that exploitation could lead not only to remote code execution but also to leakage of sensitive environment data such as cloud credentials and developer secrets. Exploit code was released publicly and was quickly followed by heavy Internet-wide scanning and attack activity, including targeting of **VMware vCenter Server**, where VMware confirmed exploitation attempts in the wild and urged immediate mitigation. **CISA** described the flaw as one of the most serious vulnerabilities in recent memory and warned that **hundreds of millions of devices** could be affected, with likely follow-on abuse by cryptominers, ransomware operators, and other threat actors. Apache responded with a series of Log4j updates, including releases such as **`2.12.2`**, **`2.12.3`**, **`2.12.4`**, and **`2.3.1`**, while defenders published detection content and scanning tools as organizations raced to identify vulnerable systems and reduce exposure.
Aug 28, 2026
Apache Log4j remained at the center of a major software supply chain security crisis after **Log4Shell** (`CVE-2021-44228`) exposed Java applications to remote code execution through crafted requests that could force vulnerable systems to retrieve and run attacker-controlled payloads. The flaw affected Log4j `2.0-beta9` through `2.14.1`, was reported as easy to exploit, and was observed in widespread attacks across enterprise networks, prompting urgent calls to identify exposed assets and apply vendor fixes or mitigations. Remediation proved more complex as Apache issued updates and additional Log4j vulnerabilities emerged, including `CVE-2021-45046`, `CVE-2021-45105`, and `CVE-2021-44832`, raising concerns that patching alone would not address prior compromise or attacker persistence. Organizations were pushed to combine software updates with threat hunting and incident response, while defenders also relied on community tracking of affected products through resources such as CISA's `log4j-affected-db`, which has since been archived as read-only.
Aug 26, 2026