Finding Exploits and Trojan php hacks on a website

Its always unfortunate when you are exploited, and the best method to fix a site is to wipe and restore from a known backup as well as track down the entry point they gained access and fix it.

Sometimes you need to ‘clean’ a site of these files before migrating things over however , or to keep the site going for a short time until you are able to do this. This is what this HOWTO is for, keeping things going for a short time until you can track down the entry point, or migrate/upgrade the site and get it back online.

I use multiple methods to identify scripts, and even doing so there will probably be things that are missed. Here are the ones i usually use

This is a handy script, however i was unable to get it working as expected, so took the main commands out and ran them seperately

cd /var/www
sploitpattern='r0nin|m0rtix|upl0ad|r57shell|cFaTaLisTiCz_Fx|Tukulesto|99shell|shellbot|phpshell|void\.ru|phpremoteview|directmail|bash_history|\.ru/|brute *force|multiviews|cwings|vandal|bitchx|eggdrop|guardservices|psybnc|dalnet|undernet|vulnscan|spymeta|raslan58|Webshell'

find ./ \( -regex '.*\.php$' -o -regex '.*\.cgi$' -o -regex '.*\.inc$' \) -print0 | xargs -0 egrep -il "$sploitpattern" | sort > potential_exploits.txt

Then checked the file ‘check’ to see what was found.
Another couple of lines that will helpfully identify things are

 find /var/www -type f | grep -v ' ' | grep '.php'   | xargs grep 'php .*eval.*_POST'
## finding the timestamp of those
 ls -l $(find /var/www -type f | grep -v ' ' | grep '.php'   | xargs grep -l  'php .*eval.*_POST')

Sometimes the simple option of clamscam is a great way to find exploits – you may need to install clamav for this

cd /var/www
nice -n 19 clamscan ./ -r -i | grep " FOUND" >> potential_exploits.txt

Even more simple. look for files with single, or double letter names as they are rare in the php world. Particularly if they are owned by apache

find /var/www/ -type f -iname ?.php -uid 33
find /var/www/ -type f -iname ??.php -uid 33

uid 33 is the apache user in this example. May pay to check passwd for others

Occasionally even 3 character file names are common with some hackers, so pays to check them also.

Searching for file suffixes that are just not normal, eg .c for compiled binaries are not normally found in a document root. .pl may be another

find /var/www/ -name "*.c"

Directories starting with a space or a dot, or any files in any tmp folders (including /var/tmp and /tmp on the system).

find /var/www/ -name '.*'  # finding folders starting with ".name" 
find /var/www/ -name '. *' # finding folders with ". name"
find /var/www/ -name ' *' # finding folders with " name"

You can find all newly created or edited files using

find /var/www -mtime 0 -type f

When you find files that should not be there, exploits, shells or whatever, It pays not to delete them right away. You should ideally grep the apache log for the filename of those to see how they uploaded them and who accessed those files.

grep "bms.html" /var/log/apache2/access.log

If nothing shows up, then check the timestamp of the file, when was it created? What happened in the logs at the same time ? You may find other files based on the new file, potentially a security hole, or something that had been hacked some time ago.

If you need any help at all fixing anything, or have exploits, just drop us an email at support.


4 responses to “Finding Exploits and Trojan php hacks on a website”

  1. I used above commands (with $sploitpattern), but it gave failed results I think. It reports 2 files:
    – one is MemcachedStore.php from package OpenID
    – one is from mediamanager plugin of Tinymce

    Not sure which regex then.

    • Unfortunately its not always an exact science, but it ought to narrow things down rahter than having to look in all files. I would advise you to check that file for any of the strings in the $sploitpattern, but if it seems to be legit it potentially is.

  2. More false alarms
    – smartypants
    – wordpress ultimate-security-checker, better-wp-security plugins
    – wordpress vars.php file
    – prestashop
    – IP.Board v3.2.3

    Well… I guess it can find out some potential exploits, but really need to fix how it works