An Apache ActiveMQ flaw is being actively exploited, according to findings from Red Canary. However, there is an unconventional element to this exploitation: the threat actors targeting this flaw are also patching the exploited vulnerability after gaining initial access, preventing other adversaries from leveraging it and avoiding detection. 

Security Leaders Weigh In

Neil Pathare, Associate Principal Consultant at Black Duck:

This relatively rare technique is utilized by persistent threat actors seeking to maintain exclusive access to compromised systems while avoiding detection. Unfortunately, Security engineers may mistakenly believe their environments are "secure" simply because they appear to have been patched — traditional patch management systems typically do not record who applied the patch. Adversary patching represents a sophisticated threat, especially in fast-moving, cloud-native environment and organizations should adopt a proactive approach of structured log reviews, forensic analysis, or anomaly detection.

Jason Soroko, Senior Fellow at Sectigo:

Red Canary’s finding is a classic case of patching for persistence.  An adversary exploited the 2023 ActiveMQ RCE (CVE 2023 46604), established footholds with tools like Sliver and Cloudflare Tunnels, then quietly replaced the vulnerable ActiveMQ JARs with fixed versions from the Apache Maven repo — closing the very hole they used so scanners and opportunistic rivals wouldn’t trip the alarm. On top of that, they hardened access by enabling root logins over SSH and deploying a password gated PyInstaller ELF (“DripDropper”) that talks to Dropbox, with cron based persistence via the `0anacron` scripts — tradecraft designed to blend in and stick around even after the vulnerability disappears from reports.

We’ve seen this tactic before. During the Citrix NetScaler/ADC CVE 2019 19781 wave, 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. 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 Qualys Threat Research Unit:

Most legacy vulnerability scanners and patch management systems focus on whether a vulnerability is patched, not who patched it. In such situations, the security teams often wouldn't notice immediately and incorrectly assume they're safe, missing that the patching occurred through compromise. However, modern vulnerability management solutions now also include patch management workflows and ticketing systems inbuilt. There definitely will be pointers in these systems as a vulnerability was discovered and assigned to someone in the security team for managing the risk and before the person got to mitigating it, the vulnerability now says patched. This missing patch attribution can help identify affected systems.

Ms. Nivedita Murthy, Senior Staff Consultant at Black Duck:

Patching a vulnerable software after taking advantage of its vulnerability is definitely a new tactic to avoid detection. However, this points to a much greater problem of attackers being able to install software without any additional permission. This vulnerability should have been detected by the IT Team especially on the server. The attackers gained root access and that should have been flagged by any server monitoring tool. This incident highlights the need for stricter controls on operating environments and deeper detection mechanisms to identify changes that were not approved.