Recently I had a new client approach me with their website recently hacked. The site on first load within the browser was redirecting to another ( frenkulok, oshona ).
First part to solving the problem is to see what it is being redirected to, and each of the stages.
Using Google Chrome Inspector, click into the console tab and ensure ‘Preserve Log’ is checked. This allows the site to run on load and continue to logging whilst the redirect occurs
As you can see below there are a few XHR requests. What we are looking for a certain keywords that we can use to do string search matches in our /wp-content files so that we can find where the script is sitting. In this case, the first one I tried was ‘oshona.in’ an Indian domain that has nothing to do with the website. This domain then has further control on what domains get redirected so that they can then update that at any time they want without having to update the code on the clients website.
Opening the first XHR request toggle, it showed that it was loading on line 1441 on the site, which was in the sites footer, so that was a good clue to being able to find it.
However to make it even easier to myself the next step was to install a temporary plugin called String locator. Which can search for any string of text in the theme directory.
I searched the first suspect keyword that I was sure to be found in the website files somewhere, and very quickly this file popped up. The footer.php file – as suspected in the parent theme.
Loading the file initially it displayed as what would appear as a normal footer.php file, however the code was hidden 80 lines off screen, scrolling down revealed the script hidden just before the </body> tag of the footer.
Select it all, and delete, and the final footer.php looked like the following.
Update the file to the server, and then hit save.
And to ensure this didn’t happen again, security was hardened on the site, and requested that the user update their password, and remove any plugins that were not essential.
Best of luck to anyone that has any of these problems in the future, usually pretty quick to fix, total of 5 mins to do, however can seem overwhelming if you aren’t familiar with some of the tools and methods that you can use to direct you to where the redirect script is triggering.