There are many ways to inject a malicious payload onto a website. The attacker can modify any of the web files (index.php for example), the .htaccess file or php.ini (if the site is using PHP). There are other ways, but those are the most common methods, specially on shared hosts.

However, for the last year, we started to see a new way to inject malware on compromised servers via a malicious Apache module. We posted about it before and it has been covered on many other mediums. After a few months of tracking them, and working on multiple servers that had this issue, we want to share a bit of what we have learned.

Identifying the injection

First, a good way to identify if an infection is coming via the Apache module compromise is by looking at how the iframe is being inserted. They seem to always follow this pattern:

Early on they were using .net’s and .info’s domains and recently switched to using domains from Change IP (changeip.name, longmusic.com and others). Another interesting point is that since .co.cc was disabled, we have started seeing many attacks using Change IP: http://labs.sucuri.net/?note=2012-12-10.

Apache Module

The attackers are modifying the httpd.conf file (or any configuration file inside /etc/httpd/conf.d) and insert a line to inject their own modules:

LoadModule pool_mem_module /lib64/libwutfa.so.2

or

LoadModule bench_proxy_module /lib64/libhdast.so.1

or

LoadModule string_log_module /usr/lib/libcehf.so.7

The module names and location are pretty random and their md5 checksums also seems to change often:

If you find any module that is not part of any package (not owned by anyone), it is a good red flag that this module was added by the attackers.

SSHD binary

Another part of the compromise that we haven’t seen mentioned anywhere else is how the attackers keep access to the owned servers. We have noticed that they are modifying all SSH binaries and inserted a version that gives them full access back to the server. The modifications not only allow them to remote into the server bypassing existing authentication controls, but also allow them to steal all SSH authentications and push it to their remote servers.

A good way to identify this is to run the rpm -Va command to see all file changes. If SSHD has been modified, you would see this error:

Daniel B. Cid is the Founder & CTO of Sucuri and also the founder of the open source project - OSSEC HIDS. His interests range from intrusion detection, log analysis (log-based intrusion detection), web-based malware research and secure development. You can find more about Daniel on his site dcid.me or on Twitter: @danielcid

It’s very important that when these scenarios happens, you must immediately identify the cause, the source and a possible solution for the infection. We must always be cautious and vigilant because hackers/viruses are just around the corner waiting to strike.