The latest sequel no one asked for has been announced, with the only good news being that it doesn’t involve any of the Avengers. The bad news, however, is that it is another attack campaign by malicious actors targeting Apache Tomcat servers, coming just weeks after we reported on the RCE vulnerability, which was also exploited within 30 hours of disclosure.
Nautilus, Aqua Security’s research team, has detailed in a recent blog their findings when they discovered a new and sophisticated attack campaign targeting Apache Tomcat servers. The campaign uses brute-force attacks, encrypted payloads, and persistence mechanisms to hijack resources for crypto-mining. A notable technique used in this attack is the method the attackers use to hide the secondary payload.
Multiple Scripts
The drama begins with a brute-force attempt from a remote server using the flexible and extendable Python script to test out frequently used usernames and weak, predictable passwords on the Tomcat management console. After successfully guessing the Apache credentials, two JavaServer Pages (JSP) files are uploaded and executed onto the Tomcat server.
- The first script serves as a backdoor loader, enabling the attacker to run any Java code. It imports Java libraries for executing commands, decodes encrypted requests, and uses AES encryption to load new Java classes.
- The second script functions as a persistence and privilege escalation mechanism. It tries to download and run a .exe file called os.s without checking if the system is Windows or Linux. It saves the file in C:\Users\Public\os.s and executes it, ascertaining the current user’s privileges and copying itself onto different locations in order to maintain access.
If the .exe fails, it drops a shell script called “w,” hosted on the recently registered domain dbliker.top. The payload then goes through four decoding layers, modifies permissions, and deletes its trace. A second version of the test.jsp script downloads another script, ldr.sh, which gathers local SSH keys and searches for other machines to infect. Both scripts initiate the main payload, a packed ELF binary called app. The script checks for root privileges and, if found, runs functions to optimize the CPU for cryptomining. Initially, the payload is a 2.6 MB ELF file that expands to 8.6 MB when unpacked.
Attack of the Clones
Once inside, attacks deploy multi-layered malware disguised as kernel processes, steal SSH keys to spread laterally and execute cross-platform payloads on Windows and Linux. In tests conducted by Nautilus, the malware showed anti-debugging behavior and cloned itself into new threads while establishing socket communication. The main binary continuously runs without termination, and it disguises itself as a kernel process and drops a modified version to evade detection. This new binary operates as a kernel process while running a cryptominer connected to various mining pools.
Notably, attackers used a tactic to conceal the secondary payload. Visiting the download page displays a misleading 404 error message, but closer inspection reveals hidden payload content.
Available with Subtitles
Interestingly, Nautilus found inside the script features comments in Chinese about its execution process, raising questions about the attackers’ origin. The Chinese comments were found embedded within the file and translated to “Get the real path of the current JSP file” and “The file has been marked for deletion and will take effect after the server is restarted.” No other code or binaries were found to contain any notes in the Chinese language.
Gone in 30 Hours
Like the RCE Vulnerability we previously covered and mentioned earlier, attackers weaponized their botnets and initiated their assault on Tomcat servers within just 30 hours. For any significant organization, the urgency of patching time-sensitive vulnerabilities often exceeds this brief timeframe, so implementing additional layers of security becomes essential for safeguarding against such sophisticated and evolving threats.
Nautilus identifies six practical steps that organizations can take to protect their Tomcat servers.
- Ensure all vulnerabilities, such as Tomcat servers, are patched.
- Disable any services, such as HTTP services, that are no longer required.
- Disable unused management Interfaces, such as Tomcat Manager.
- Implement strict privilege management.
- Isolate critical servers from the internet or use firewalls to restrict outbound communication.
- Deploy runtime protection such as anti-malware tools.
While unrelated to the RCE vulnerability, this new attack poses some serious questions about how quickly attackers could adapt to exploit weak credentials and gain access to Tomcat environments.
Adam Parlett is a cybersecurity marketing professional who has been working as a project manager at Bora for over two years. A Sociology graduate from the University of York, Adam enjoys the challenge of finding new and interesting ways to engage audiences with complex Cybersecurity ideas and products.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.