A new report from Red Canary reveals a clever Linux malware called DripDropper that exploits a flaw and then patches it to prevent other hackers from getting in. Learn how this tactic works.
A new report by cybersecurity firm Red Canary reveals that hackers are exploiting a critical vulnerability and then patching it to lock out other attackers. The research from the Red Canary Threat Intelligence team, provided to Hackread.com, exposes a new piece of Linux malware, which the company named DripDropper, and details how adversaries are using it to gain and maintain hidden access on cloud servers.
The attack starts with exploiting a well-known security flaw, CVE-2023-46604, in a widely used piece of software called Apache ActiveMQ. This program is a “message broker,” which is a fancy term for a tool that helps different computer systems talk to each other. Although a patch has been available for some time, many systems are still vulnerable, and hackers are taking advantage of this weakness to get initial access.
“Even though the critical vulnerability exploited in ActiveMQ here is nearly three years old, adversaries are still exploiting the vulnerability to execute payloads such as Godzilla Webshell, and Ransomhub ransomware, resulting in a 94.44% likelihood of being exploited in the next 30 days, according to its EPSS score,” researchers noted.
Strategy for Persistence
After gaining a foothold, the hackers install two main tools. The first is a malicious software called Sliver, a tool that gives them secret, unrestricted control over the compromised computer.
They then use a downloader (DripDropper) that connects to a Dropbox account controlled by the attacker. This malware is an encrypted file that requires a password to run, making it tough for security analysts to examine.
But the most surprising part of the attack comes next. After establishing their control, the hackers use a common internet command to download a legitimate patch for the very vulnerability they just exploited.
By patching the system, they essentially close the door they used to get in, preventing other criminals from exploiting the same weakness. This clever move ensures their grip remains exclusive and makes it harder for defenders to trace the attack back to the original entry point.
To ensure long-term access, the DripDropper malware modifies system files to allow root logins and keep itself running. The malware also drops a second file with a random, eight-character name, which also contacts the attackers’ Dropbox for further instructions.
Researchers noted that using public platforms like Dropbox is a common tactic also used by other malware families such as CHIMNEYSWEEP, Mustang Panda, and WhisperGate.
These findings highlight that a clean vulnerability scan doesn’t always mean a system is secure. A scan might show a system is patched, but it won’t reveal how or by whom. This means, a multi-layered security approach is needed, including consistent patching and careful monitoring of cloud logs. The report also recommends using resources like CISA’s Known Exploited Vulnerabilities (KEV) catalogue to help prioritize which flaws to fix first.
“I’m not sure I’ve heard of automated malware that patched the vulnerability it used to break in, except maybe once before back in the 1990s, when two computer virus groups were battling it out for global control using the same software vulnerability. I have, however, been involved in a few consulting engagements over the years where human hackers broke in and patched the exploits,“ said Roger Grimes, Data-Driven Defense Evangelist at KnowBe4.
“Once, when I was with Microsoft, I was hired to help consult with a customer who was mad that Microsoft was applying a patch that they had configured NOT to apply. It was a controversial patch at the time (it disabled the otherwise default autorun feature in Microsoft Windows when mobile media was inserted into a computer),” he explained.
“A lot of customers were mad that Microsoft was disabling autoruns, so Microsoft configured the patch to not automatically deploy if a particular related registry entry was enabled. Well, for this particular customer, the patch kept applying. They would then uninstall the patch, make sure the related registry entry was made, and then come back the next day to find the patch re-applied. Boy, they were mad.”
“When I showed up, I quickly discovered that a hacker group had broken in using the vulnerability, and they were trying to apply the patch to disable the autoruns feature to prevent other groups. Boy, was that client feeling mea culpa.”
“I said it then, and I’ll say it now, “If hackers are doing your patching faster than you are, you aren’t doing it right!” This is yet another argument for default auto-patching without admin involvement. We’ve yet again seen serious vulnerabilities that have not been patched years later. It’s all too common,” Roger added.
