One of computer security’s special frustrations is the phenomenon of malware that keeps re-infecting a system no matter how many times defenders think they’ve cleaned it.
This was the puzzle that recently confronted Sophos Support when it was called in to investigate the mystery of an internet-facing Apache Tomcat web server that couldn’t seem to shake a Monero cryptominer called XMrig.
Thanks to its open-source status, XMrig has recently become more popular – and, fortunately, it’s not that hard to spot, in this case by way of intrusion detection and command and control detection alerts.
Nevertheless, while the automated reinstatement of this kind of malware had turned up in SophosLabs honeypots before, it had never been detected in the wild.
The server’s OS and applications were fully up to date which means that the attackers were either exploiting an unknown software flaw or had found another, more parochial weakness.
Analysis of the network packets allowed Support to peel back the layers of the attack, and identify the root cause as a successful brute-force attack on the Tomcat’s internet-facing admin panel.
Armed with admin-level access, the attacker was aided by the fact that the server was configured to allow the upload of executables using the Web Application Resource (.war) format, which was used to transfer a malicious admin.jsp file.
This enabled the execution of three commands using HTTP POST requests: SI (which returns system information), UF (file creation on the server) and SH (command execution).
The SH command was used to execute code that contacted a remote server, which responded by offering up the XMrig cryptominer as well as some PowerShell that attempted to kill three server processes that weren’t in fact running.
Sitting duck
Ostensibly, the glaring vulnerability was that the compromised server’s admin panel used a weak, easily guessed or default password, the foothold the attackers needed for the compromise. Specifically:
The initial phase of the attack was marked with a brute-force credential stuffing attempt at the Tomcat admin panel, and once the attackers successfully logged in as an admin, all bets were off.
Certainly, where an attack is reinstating quickly, the security of the server’s credentials should come under immediate suspicion. Changing these as a precaution costs nothing.
But there was a second big problem, namely that the admin panel was reachable from the internet at all. This gives criminal hackers all the time in the world to conduct a brute force attack against its passwords, and an opportunity to shrug off those passwords completely if a vulnerability is discovered in Tomcat’s admin code.
The combination of these two issues on a server where admins can upload executables and files offered the sort of target that invites trouble. This attack could have been so much worse than a bout of nuisance cryptomining.
Simple risk assessment tells us this. If the front door is visible enough to be a target, what sort of power lies beyond? In the case of this server, too much.
Ideally, admin access should be restricted to internal IP addresses. Where that’s not possible, the use of multi-factor authentication – such as client digital certificates – should be a minimum rather than a luxury.
You can read more about this attack and delve into the technical details in the SophosLabs Uncut article Worms deliver cryptomining malware to web servers.