By chance we found a hacked website on the net and offered our help to the operator (in this case an association). The help first consisted of a free damage analysis to see how much effort it would take to clean the website from the malicious code and make it safe to run again.
The website was infected with a hack that has also been known for WordPress for a while. There are posts about this hack in the WordPress support forum that go back several years.
How does the website behave?
If you access the website directly by entering the URL in the browser, it behaves normally, the website loads as expected and no problems are apparent.
The hack basically only takes effect if you want to reach the website via Google search. If you click on the website in Google search results, you will be redirected to a spam page.
The following things are interesting:
- It is not always redirected to the same page
- It redirects only a few times (about 3 times), then the page behaves normally again.
- The hack does not only attack the home page, but also the subpages.
- Google links to the correct domain in the search, then the redirection happens only on the page itself.
- You are redirected to dubious pages that want to activate browser notifications. One click leads to the next redirect and it goes on and on.
- If you come from other search engines like bing.com, ecosia.org or duckduckgo.com, the website behaves normally.
What conclusions can be drawn from this?
The hack seems to affect only traffic that comes directly via the Google search engine. The whole thing suggests that the referrer (origin of the visitor to a website) is being queried somewhere. The only question is where.
Cookies are set by the malicious websites that are redirected to. These cookies apparently prevent the redirects from happening again if they are called from Google several times. However, in addition to the cookies, IP addresses are probably logged and after X calls from the same IP address, the redirects are no longer executed. I.e. it makes it seem as if the problem is only a temporary one and gives the users* the feeling that one might have clicked somewhere wrong.
Based on the behavior, one can theorize the following about how the hack works:
- Redirection via a hacked .htaccess file
- Redirection via JavaScript
- Redirect via PHP redirect via hacked pages in WordPress (is the most obvious in this case)
Step by step on the trail of the hack.
How to find out what happened?
The following procedure will help to uncover the hack:
- Login via WordPress - use a password that you don't use anywhere else. The site is hacked and can log your password and forward it. Possibly reset the password directly before login.
- Connect to the server via FTP or SSH and search for strange filenames and cryptic directories.
- Search the code for the occurrence of base64_decode or eval. Code is often stored encrypted and is decrypted with base64_decode. Download the code for this purpose or perform the search directly on the server.
Attention: Do not start the site from a local web server! Running the site locally can cause significant damage to your computer by deleting files, downloading malware or infecting existing files.
What happened?
In our case, the first thing we did was connect via FTP, because we don't have a WordPress admin. At the 1st glance we have already discovered bad things.
The hacked index.php is already in the root directory.
Based on the last changed date of the index.php we have a first idea when the hack happened. In this case, the file has been modified on 23.1.2023.
After analyzing several files, we can place the attack between 1/18/2023 and 1/23/2023. On this date, or in between, there are a large number of cryptic files that were infiltrated into the WordPress core.
One is a hacked index.php:
If you look closely at the code and try to decrypt it, you will see that a file is included under the following path: /wp-includes/Requests/Transport/.ebfbb52c.ico
This file contains encrypted PHP code that is executed via eval().
In the root directory we discover other files with cryptic names:
If you look at files from the WordPress Core that were edited on this date, you can also see that malicious code was injected here.
In the next step, we take a look at the directories of the WordPress Core and pay special attention to a modification date in January 2023, since this is obviously where the hack happened.
We take a closer look at the files with a modification date in January 2023 and find infiltrated code here as well:
There are many files in the WordPress directories with flashy file names and cryptic contents that definitely don't belong there.
There was also a plugin directory created called "882r8005". This directory contains some cryptic files and content and is probably the source of all the evil.
The date of the last modified files matches the date.
However, in a backup directory we find another file with the date 5.5.2011. This file also contains malicious code, but probably already from an earlier hacker attack.
Furthermore, there are hacked files and directories in the themes directory, which in turn have a different date. So maybe a third hack.
We could already discover several, presumably independent hacks by looking into the directory structure.
But how did the hackers get in?
How did the hackers get in?
What we know:
- The entire WordPress core is contaminated with hacked files.
- There are additional files that were created, but also files that were edited and contaminated with code. The code is camouflaged, so that you can't find anything by searching for base64, because the code is generated at runtime.
- More information about base64_decode at this link.
- In this project there is a plugin that was updated 2 days before the hack started. It is a plugin that is supposed to secure the WordPress login. Interestingly, it is not uncommon for plugins that are supposed to protect WordPress against attackers to contain vulnerabilities themselves, thereby giving hackers access.
- After a file called wp-login.php was also found in a directory called themes-ai1ec-obsolete, with also cryptic contents, it cannot be excluded that happened via a security hole in the "All In One Event Calendar", which has the abbreviation ai1ec. There are known vulnerabilities in older versions of this plugin that made it possible to gain access via XSS (Cross Site Scripting).
One thing is for sure, and that is that the attackers in this case penetrated WordPress or plugins via security vulnerabilities.
Every WordPress plugin represents an additional security risk. That's why the rule is: install as many as necessary, as few as possible. And those that are installed, keep them up to date and best have them monitored for security vulnerabilities with software like SYSSY.
Since this is a site where users can upload files, it is also possible that a malicious file was uploaded via a form. In any case, a file admin.php was found in the uploads directory, which also contains malicious code. Pugins that allow users to upload files should be treated with caution. For example, PNG files can also be hacked and contain malicious code that is eventually executed on the server. With such plugins, it is important to make sure that the files are renamed after uploading so that they cannot be accessed via the browser with their original name.
After also in a directory called themes-ai1ec-obsolete a file called wp-login.php was found, with also cryptic content, it is not excluded that happened via a security hole in the "All In One Event Calendar" that has the abbreviation ai1ec. There are known vulnerabilities in older versions of this plugin that made it possible to gain access via XSS (Cross Site Scripting).
What can be done to fix the problems?
A simple update from the WordPress backend does not help. If you do an update from the WordPress backend, files are overwritten, but additional files are not deleted. I.e. the files continue to exist and contaminate again.
The additionally installed plugins and themes are also not removed by an update. The plugins may not even be visible in the WordPress backend.
In addition, there is still malicious code in the uploads directory, which is not affected by updates.
Our suggestion:
- Create a copy of the project and clean the copy - possibly run it under a subdomain on the server.
- Search in the database or in the WordPress backend for user names that you have not created yourself. If there are user names that you do not know, delete them immediately.
- Delete the complete WordPress core (via FTP) and replace it with a fresh one.
- Replace all plugins step by step with a plugin download from the WordPress repository. A simple plugin update may not be enough. Check before if you need the plugins at all. Big clean out makes sense here. Folders with flashy names in the plugin directory that don't look like official plugins are best deleted.
- Search all directories for cryptic files and delete them.
The cleanup can be very costly and only makes sense if the website is still worth saving. A simple cost-benefit calculation. If the site is already very outdated and it is cheaper to redo the site, then it probably makes sense to redo the site and in the course of this to modernize it and get rid of all the old burdens.
In this specific case, the site is already over 10 years old and, apart from the hack, also has some DSGVO issues. It also uses plugins that have not been updated in over 10 years and are no longer supported.
So my advice in this case would be to redo the page.
Actually, the site should be taken down immediately, as users can be harmed due to the redirection to the dubious pages. Especially if you run an online store and there is a possibility to enter credit card data, the page should be disabled immediately.
How can you protect yourself as a user or website visitor?
- Set the browser settings so that, for example, third-party cookies are not accepted.
- Install browser extensions that recognize and block such things. For Firefox there is uBlock Origin, which blocks such redirects.
- Do not click on links if the page looks dubious. Close the browser or the browser tab immediately and do not visit the website again. Possibly delete cookies and browser data.
- If you as a visitor discover that a website has been hacked, you should inform the owner of the website immediately.
How can you protect yourself as a website operator?
For information on how to better secure your website and how to determine if your website has been hacked, see the article Detecting and Avoiding Hacked Websites.
