Root compromise responsible for hacked sites

Readers will have probably read about the series of sites that have recently been compromised with something a little more sophisticated than the regular attack [1,2]. Over the past week or so, aside from ensuring the appropriate detections are in place, we have been trying to track down more information about the attack.

So what is it about these attacks that makes them sophisticated?

  • a malicious script tag pointing to a randomly named Javascript file is injected into page content. This makes it impossible to reliably detect the compromised page itself.
  • the randomly created Javascript file is created on the fly, upon the request for that file (ie. when the user browses the compromised page containing the malicious script tag).
  • malicious content is served up apparently randomly – requested pages from a compromised web server will only sometimes contain the malicious script tag. In contrast to the bulk of kit-created attack sites, this attack does not appear to monitor the requesting IP address. Malicious content may be delivered multiple times to the same client.

The malicious Javascript itself is fairly ordinary. It uses obfuscation to evade detection/analysis, and attempts to exploit several browser vulnerabilities in order to infect the victim with a Win32 Trojan. Detection for the malicious script as Mal/ExpJS-D was added last week. The Trojan it delivers uses obfuscation as well to evade detection. The payloads from the last batch of sites I checked earlier on today continued to be detected as Mal/Behav-184.

Last week, whilst analysing some of the data we had received for sites serving up Mal/ExpJS-D, it was clear that various servers had been compromised, some of them hosting hundreds of web sites. All of the servers were running Apache on some flavour of Linux. As usual for such incidents, I made some efforts to contact the site hosting/development companies involved in order to address the problem and minimise the number of victims exposed to the threat. (Thanks to those who replied with information – if anyone else has anything to help shed light on this case please do get in touch.)

Perhaps the most intriguing facet of this attack is the mechanism used to compromise the site content. Even at this point details are sketchy, but there appears to be agreement that the web servers have all been root compromised. Several system binaries are replaced such that when the server is restarted, the rootkit is loaded. An infected web server then starts serving up malicious content to random web requests.

It is a kernel level attack and not restricted to Apache (early speculation was that it may have been compromised Apache modules that could have been used to inject the malicious content).

Further details about that attack including instructions to check if your web server is affected can be found on the cPanel web site (here). Kudos to them and all those who helped in establising these details.