Malware, Vulnerability Management, Identity, Exposure management

Attackers patch 10.0 Apache ActiveMQ bug after gaining access to Linux systems

In a somewhat unusual – yet not unheard of – twist, unknown threat actors patched a two-year-old critical 10.0 vulnerability in Apache ActiveMQ after gaining access to cloud Linux systems and deploying malware called DripDropper.

Red Canary researchers said in an Aug. 19 blog that the bad actors patched the exploited bug to prevent further exploitation by other adversaries and evade network detection.

The maximum-severity flaw – CVE-2023-46604 – is a remote code execution (RCE) bug in Apache ActiveMQ, a widely-used open-source message broker written in Java that attackers have already exploited.

Threat actors have exploited the Apache ActiveMQ flaw for the past two years, dropping malware that ultimately spread TellYouThe Pass, RansomHub, and HelloKitty ransomware, along with the Kinsing malware, best known for targeting Linux systems to spread cryptominers.

“As cloud environments and containerization have led to an increase in Linux environments, adversaries have adapted by increased attacks and tradecraft development for Linux,” wrote the Red Canary researchers. “The patching of the vulnerability to prevent competition underscores how prevalent exploitation can be. It highlights the risks of assuming that a clean vulnerability scan means a secure system.”

We've seen this before

Thomas Richards, infrastructure security practice director at Black Duck, said it’s not the first time a threat actor patched a vulnerability after they successfully exploited it. Richards said the malware that exploited an Ivanti vulnerability back in February 2025 also patched the system after exploiting it to prevent competing attackers from compromising the same systems. 

“Given that the vulnerability is at least two-years-old, systems that are exploited are probably not being monitored and maintained proactively by an organization’s patching system,” said Richards. “The compromise and remediation probably goes unnoticed until the attacker tries to reach out to other systems and triggers alarms.”

Jason Soroko, senior fellow at Sectigo, also said that we’ve seen this tactic before. During the Citrix NetScaler/ADC CVE‑2019‑19781 wave, Soroko said researchers documented “adversary patching” and the NOTROBIN backdoor, which removed competitors’ webshells and altered components so only the intruder with a secret key could re‑enter—leaving victims patched, yet still backdoored.

“Similarly, government guidance during Log4Shell noted cases where attackers patched Log4j after compromise to evade detection,” said Soroko. “It’s very possible for a security team to miss detecting someone else performing a patch. Unless teams correlate patch timestamps with authorized change tickets and hunt for side‑effects, they can wrongly assume remediation was internal and complete.”

Mayuresh Dani, security research manager at the Qualys Threat Research Unit, added that we definitely have seen this tactic, most notably with the Welchia/Nachi Worm from the early 2000s. Dani said it would exploit a Microsoft RPC vulnerability and then patch the vulnerability to prevent reinfection and attempt to remove other worms like Blaster from the system.

“Most legacy vulnerability scanners and patch management systems focus on whether a vulnerability is patched, not who patched it,” said Dani. “In such situations, the security teams often wouldn't notice immediately and incorrectly assume they're safe, missing that the patching occurred through compromise.”

Get daily email updates

SC Media's daily must-read of the most current and pressing daily news

By clicking the Subscribe button below, you agree to SC Media Terms of Use and Privacy Policy.

You can skip this ad in 5 seconds