It sounds counterintuitive. An adversary exploits a system, gains access, and then patches the very hole they used to break in. Yet that is exactly what Red Canary researchers observed in a recent campaign targeting cloud-based Linux servers.
The logic is simple. By fixing the exploited vulnerability, a malefactor can lock out rivals and mask their method of entry. What looks like remediation is, in reality, persistence.
The Red Canary Threat Intelligence team tracked a cluster of activity exploiting CVE-2023-46604 in Apache ActiveMQ, a widely deployed open-source message broker.
Once inside, the adversary moved quickly. “It’s a great way to potentially lock out other adversaries, ensuring their foothold remains exclusive. It can also obscure the adversary’s initial access technique,” the researchers said.
Covert Cloud Persistence
Dozens of cloud Linux endpoints were scanned and prodded. Some were compromised. On those, the threat actor deployed command-and-control tools, including Sliver and Cloudflare Tunnels, to maintain quiet, long-term access.
In one case, after planting the Sliver implant, the attacker altered the SSH daemon’s configuration to allow root logins. Modern Linux distributions disable this by default. Reversing the setting opened the door for unfettered remote control. From there, a new tool appeared: DripDropper.
What is DripDropper?
DripDropper is no ordinary dropper. It is an encrypted PyInstaller ELF file that requires a password to run, blocking most automated analysis. It communicates with a Dropbox account under adversary control. What is sent or received remains uncertain. What is clear is the result: two malicious files are left behind.
The first file’s function varies. Sometimes, it monitors processes, and other times, it calls back to Dropbox. Always, it persists, embedding itself into cron jobs. The second has a random eight-character name and frequently altered SSH configuration files.
One tactic is changing the default login shell for the “games” account to /bin/sh, preparing the way for hidden access.
DripDropper’s reliance on Dropbox is not unusual. Public platforms like Discord, Telegram, and Dropbox have become common command-and-control channels. They blend into legitimate traffic and frustrate detection.
A Patch With Purpose
The campaign revealed one more striking move. After achieving persistence, the attacker pulled down two JAR files from Apache Maven repositories. These were not backdoors. They were legitimate patches for CVE-2023-46604. By installing them, the adversary effectively closed the exploited vulnerability.
Red Canary’s assessment is blunt: “We assess the adversary likely did this to reduce detection via common methods, such as vulnerability scanners, and to effectively reduce the likelihood of being spotted by defenders due to another adversary being detected when attempting to exploit the vulnerability.”
It is not the first time attackers have patched their own compromises. The tactic leaves defenders with a dangerous illusion of safety. A clean vulnerability scan does not always mean a secure system.
Why This Matters
Linux has become the backbone of modern cloud infrastructure. Adversaries know it. They have invested in tools and tradecraft to exploit it. DripDropper shows how far they are willing to go to maintain persistence by fixing what they broke to keep the door locked from the inside.
The lesson for defenders is: do not assume patching alone is enough. Document every update. Verify who applied it and why. Build incident response playbooks designed for Linux and cloud environments.
Effective defense requires multiple layers. Harden host-level configurations. Enforce secure SSH policies through automation tools like Ansible or Puppet. Run services with non-root accounts. Restrict exposure with ingress rules tied to trusted IPs or VPNs. And above all, monitor logs. They provide the trail that adversaries prefer you never see.
The Bigger Picture
ActiveMQ’s CVE-2023-46604 is nearly three years old. Yet it remains a favorite exploit path for ransomware operators and cryptominers. According to its EPSS score, it carries a 94.44 percent likelihood of being exploited in the next 30 days. That figure underscores the reality: even old flaws remain dangerous.
Not the First Time
Thomas Richards, Infrastructure Security Practice Director at Black Duck says this isn’t the first threat actor to patch a vulnerability after they successfully exploited it. “The malware that exploited the Ivanti vulnerability back in February 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. The compromise and remediation probably goes unnoticed until the attacker tries to reach out to other systems and triggers alarms.”
A Classic Case of Patching for Persistence
Red Canary’s finding is a classic case of patching for persistence, adds Jason Soroko, Senior Fellow at Sectigo. “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, Soroko says. “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, he says 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.”
A False Sense of Security
Mayuresh Dani, Security Research Manager, at Qualys comments: “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, Dani adds that 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.”
A Much Greater Problem
Nivedita Murthy, Senior Staff Consultant at Black Duck says patching a vulnerable software after taking advantage of its vulnerability is definitely a new tactic to avoid detection.
However, she says 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.”
Information Security Buzz News Editor
Kirsten Doyle has been in the technology journalism and editing space for nearly 24 years, during which time she has developed a great love for all aspects of technology, as well as words themselves. Her experience spans B2B tech, with a lot of focus on cybersecurity, cloud, enterprise, digital transformation, and data centre. Her specialties are in news, thought leadership, features, white papers, and PR writing, and she is an experienced editor for both print and online publications.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.