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 http://djlab.com/2010/09/finding-php-shell-scripts-and-php-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.
eg
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”
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 module.audio.mp3.php 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.
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
[…] have made posts before regarding how to find exploits, and what to do about those previously, however it has come to my attention that some people are […]