During a technical audit of one of the sites, it was discovered that the sitemap showed thousands of strange links disguised as internal links to the site, but when the user clicked on them they were redirected to a site selling Viagra and other generics
Because of that the site started lose traffic and positions on SERP, although there were no any penalties in Search Console
Where was it hidden?
First of all I cheked the site with various anti-viruses, but found nothing. I thought, if sitemap.xml is being replaced with hacked, first what I should to do is disable the sitemap module. But problem left.
Checking the .htaccess and php files of current theme and core nothing came up either.
Finally, in the file system in sites/default/files folder I found some strange image file a.jpg which I opened with notepad++ and saw the following code:
How to fix?
If we just delete this file, we get an error, that shot down the entire website
Failed to open stream: No such file or directory in drupal_bootstrap() (line 2588 of \includes\bootstrap.inc).
In the bootstrap.inc file at 2588 row we see::
case DRUPAL_BOOTSTRAP_SESSION: require_once DRUPAL_ROOT . '/' . variable_get('session_inc', 'includes/session.inc'); drupal_session_initialize(); break;
We can see that the string uses the variable_get function to get the path to the include file. This function checks if there is a variable (in our case session_inc) and if the variable is not set, it will return the default value set as the other argument (in our case includes/session.inc).
Checked all files
Having checked all the main files for extraneous code, I am satisfied that they are clean, but where is the session_inc variable stored?
This means that leaves only the database
Go to our database in phpmyadmin and look through the tables for all records with session_inc
In my case three matches were found in the tables: cache_bootstrap, variable, and registry_file
After deleting the a.jpg file, delete the found rows from the variable and cache_bootstrap tables. That's it, the site is cured, but how can we prevent this from happening again?
Drupal 7 is already an unstable version that will not be supported at all soon, so ideally You should migrate to version 9 or 10. But if a migration is not possible, then at least make this steps:
- Update all core files to the latest version of Drupal 7
- Update all modules if they need to
- Check all users roles rights
- Check the rights to folders and files
- Check that the tmp file have not public access and it located outside the root directory
- Install MimeDetect module that prevent uploading images with code inside
- Change passwords for FTP and Server
I'm not a hacker, I don't know what other vulnerabilities may be exploited, so I would be grateful for additional points on how to close possible holes. By the way, this method of hacking has the practice to meet not only with CMS Drupal, but also on all other popular CMS, I just work more with Drupal.
If you need a technical SEO site audit please, checked out this page
- 106 views