I have a WordPress site that features a .htaccess and a file called postfs.php.
But when I try to delete them, they are written again. I tried to delete all the files on the site, change permissions, check the cron … but there isn’t anything to do. These files appear as soon as I delete or edit them.
The contents of the file are as follows:
File .htaccess
<FilesMatch ".(PhP|php5|suspected|phtml|py|exe|php|asp|Php|aspx)$">
Order allow,deny
Deny from all
</FilesMatch>
<FilesMatch "^(postfs.php|votes.php|index.php|wjsindex.php|lock666.php|font-editor.php|ms-functions.php|contents.$
Order allow,deny
Allow from all
</FilesMatch>
AddType application/x-httpd-cgi .sh
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>
And the postfs.php file has this content: PHP Decode
How can I avoid the restoring of these files?
11
Answers
In the first step, you should find the shell file (your host provider can do it with antisheller).
remove unused theme and plugin in the WordPress installation
log in in the SSH area and run this command:
find /home/.../wordpres_directory -type f -name ".htaccess" -delete
open the updated page with this link:
youdomain/tld/wp-admin/update-core.php?action=do-core-reinstall
If you still see the problem, you should do step 2 and 3.
Your server needs a security configuration. Call the host provider to secure the server.
You must search for every .htaccess file. Use an FTP client and delete it (almost 5000 in my case). Upgrade plugins to solve security breaks.
This was how I solved this:
Maybe this wouldn’t help everyone, but this worked fine for me and no traces are left.
Ultimately… none of them work. Follow this option and keep monitoring the .htaccess and index.php files in the respective domain folder where you see this issue.
Don’t uninstall or drop the WordPress installation. All the records stored will be gone.
Take a backup of the DB file from MySQL, by looking for the DB mapped to the domain
Now create a new sub-domain
Install WordPress mapped to the sub-domain
Import the db to the newly created DB (against the new WordPress instance)
Create the respective views… you will have to open the SQL file and change the user / dbname against the views created and manually restore them
Once all the above done, now open the table wpxx_options and update the two records with the new sub-domain name
Now go to WordPress and add the theme which you had installed earlier [don’t use a new one]
Install only the required plugins and not all as you did earlier installation
go to the wp_content folder (from the earlier installation) and get all the media files and copy them to the wp_content folder (1999, 2000, 20xx, …) folders is what I meant and not all
finally go to your wp-config.php file and change the table prefix to the new one
With this I think it should work.
I had tried by removing the files and uninstalling all, including domain and restored… the same junk information gets updated in the two files (.htaccess and index.php)… so I had to follow the above steps. It’s working for now, and I have to keep monitoring the above files.
You might have a cronjob that keeps on adding the .htaccess files. look out for a cronjob with a Wget request to hello.turnedpro.xyz.
If you are using cPanel, you can reset your cPanel account password and run anti-malware scan for any keyloggers/malware, e.g., RedLine Stealer.
If files start reappearing after you deleted them you should look out for lines of code—often in the index.php file—where a time-limit or a TTL (time to live) is specified, along with a (most of the time) very long line of Base64 code. (These are often recognizable by a couple of shorter lines of code with ‘equal-to’ signs in the middle.)
The way this works is the time-limit / TTL makes sure all files are held up against a reference set of files located either on another URL or in the web servers cache, and if one is missing it will sync itself back.
One thing you can do to solve this is deleting the script together with restarting Apache and PHP / nginx. This cleans out the web servers cache.
After that, you can clean out the malicious deny allow rules and stuff that’s in the .htaccess files and probably other stuff that’s lurking between the files and folders of your web application.
Bonus suggestions to really try and solve the actual security issue here:
Always make sure all software, plugins, modules, themes, etc. is up-to-date. Don’t miss out on any security patches!
Make sure to change every password on every account providing access to your web application. (don’t forget the FTP accounts and backend panels and stuff).
Try to run a malware scan (if you have a shared hosting package you might do so through a security plugin, or ask your hosting company to run one)
Make sure there aren’t any users, plugins, or any other possibly malicious components you’ve never heard of and haven’t installed!
At least make sure to check the root folder, all upload folders, and the temporary folders for malicious files.
I had the very same problem. In my case, I had several WordPress sites under one user. It was very convenient for me to maintain the sites, but it made the clean up more tricky, sort of whack a mole situation.
Both malicious .htaccess and index.php were regenerating as soon as they were deleted. What I did was look for all the radio.php and about.php with malicious code (easy to find because they are bigger in size and out of place) and also found some folders called "maint" with files with malicious code. After cleaning this, the .htaccess file and index.php infected did not regenerate anymore, so after copying the fresh WordPress files, everything was fine, and was able to access wp-admin correctly.
In one particular WordPress folder, even deleting all the files, infected .htaccess and index.php files were still regenerating, so I deleted the root folder containing the WordPress install and created a new one with a different name, and after pointing the domain name to the new folder, voila! All was fine!
Today I found a WordPress 5.7.5 installation infected. All .htaccess files had permissions for malicious files in the whole menu panel.
I then backed up everything and found several files with strange names that were infected in the root and other locations. I removed, I changed all the passwords, I downloaded the official installation WordPress 5.7.5, I deleted the WP-admin folder and I sent from the official installation in this Panel normalized.
I could update all the plugins, so I did the same with WP-includes. I already requested the WP-content the hosting that runs the find command to delete all .htaccess files, so I did upgrade to a new version.
I had the same problem and the antivirus was not able to detect it. And also the problem of automatically creating files was not related to cron jobs, as friends mentioned.
In fact, every time a page is opened from the site, those files are rebuilt.
I have carefully examined the issue and offer the solution.
The problem occurs for both
.htaccess
andindex.php
.First we search for a keyword in the text of the file (as root):
Output:
For another file, we search for a keyword in the text:
Output:
If you look at the contents of these found image files, you will see that they are not images and contain malicious code that exactly matched our two original files.
Sample:
We now search for all four files found:
Output:
If you edit these two results files:
At the bottom of the file
load.php
and at the beginning of the filetemplate-loader.php
, you will see the extra code that needs to be removed. (Starting with//ckIIbg
)To find out more exactly which sections are correct and which are malicious, just replace that file from another WordPress that you are sure is safe and the same version, or find and remove the extra sections with the diff command.
Thus:
And as a final step, delete the four malicious image files:
And also check cronjobs (
/var/spool/cron/username
) for be like this infected line and remove it:This code create a
./css/index.php
file and can be deleted.We had the same exact hack a while ago.
The first step is to decode the index.php file, and after decoding we see that there are four infected image files:
First delete the infected four images, and check your cron and delete any cron job you didn’t create.
Run this in a SSH session to delete all .htaccess files within all sub directories:
Use the default WordPress .htaccess, and index.php files.
After finishing, you can install Wordfence, and activate the firewall, also don’t forget to update your WordPress core, plugins, and themes.
I solved the problem.
Create a new FTP account and edit .htaccess and index.php with FileZilla. Then you should delete wp-admin and upload the new file and folder by a new version of WordPress. Also wp-include. And then you can.