My mail and post.php infected

Maybe you have a highly customized wordpress blog, but I can tell you that, by default, there simply is NO (blog root)/wp-mail/ folder in wordpress.

Best would be a clean and complete reinstall, preceded by a renewal of all your passwords, first email, then hosting account, database access, FTP, deleting all that is not personalized or yours (such as .htaccess, wp-content’s uploads folder, possible child themes but be super wary your child theme’s files only convey your modifications and yours only, also make yourself a list of your current plugins it will be easier to re-download them like that), and reuploading over it a clean copy gotten from www.ads-software.com

I’ll copy-paste this list about hacks, good luck ??

*

I’m sorry but you have been hacked. You need to start working your way through these resources:
https://codex.www.ads-software.com/FAQ_My_site_was_hacked
https://www.ads-software.com/support/topic/268083#post-1065779
https://smackdown.blogsblogsblogs.com/2008/06/24/how-to-completely-clean-your-hacked-wordpress-installation/
https://ottopress.com/2009/hacked-wordpress-backdoors/
Anything less will probably result in the hacker walking straight back into your site again.
Additional Resources:
Hardening WordPress
https://sitecheck.sucuri.net/scanner/
https://www.unmaskparasites.com/
https://blog.sucuri.net/2012/03/wordpress-understanding-its-true-vulnerability.html

@sabinooo Here is what I noticed. every time I login to my server the injections returns, however when I’m not logged in to WordPress Dashboard the injection are not their. They are returning every time I access dashboard. I just scanned the website and the results displayed clean. Now i will login to dashboard and scan again. Since the wp-mail isn’t suppose to be their I have remove the entire folder. Suggestions?

Suggestions ?

Well, did you read thoroughly the entirety of the links I copy-pasted first ?

Nobody does that I know ??
And yet, it really helps. Really.

But, well, basically, from experience, in case of a hack, you’re in for a TOTAL reinstallation. Preceded by an as complete as possible reinitialization.

I’m copy-pasting here a wall of text I wrote for a friend in the past and shared here and there. It’s made of sweat and tears and sleepless nights parsing logs while screaming internally, I’ve had my fair share of hacks in the past. It’s a long list, it’s not the first time I paste it, although I update it from times to times ^^

*

Typically, in this order, what I’ve gotten used to doing is:

1 – You change your email passwords, and/or your email account’s security questions and/or pin codes and/or whatever last resort recovery option there may be

2 – Then your web hosting account password

3 – Then your FTP password

4 – Then your database password (a change to port in wp-config.php shortly afterwards)

5 – Then the passwords for all your wordpress users

6 – Just in case, ask your web host if your MySQL user has “File” permissions. It should be a “no way in hell” in all circumstances, but it doesn’t harm to ask, if the reply is “yes”, ask them to turn it off.

(Intermission) – Thinking you’re safe passwords-wise ? Nope. The database password is stealable again. Thinking you’re safe as far as changing files remotely comes ? Nope again, it’s easy to change files once one is already inside the machine.

7 – Tollowing this, you’ll have to run a complete backup of all your files (by FTP, download to your disk everything starting from the root of your blog’s directory), and of your database (from your hosting panel, however they offer you to do it, or from one of the many wordpress plugins allowing to export a backup of the database). This way, you can delete everything and restart from scratch.

(Intermission) – Reinstalling everything, restarting from scratch, just importing a copy of your database, is that cool and safe ? Nope, there’s a theorical possibility your database now contains an exploitable trace to allow a hacker to come back in full control. This is *extremely* unlikely even in a totally shitty luck situation, but the possibility exists, the only solution against that is to already have a database backup dated from *way* before your being hacked begun (but nobody is ready to sacrifice months of web activity, something I fully understand.)

8 – You have done your backup, right ? Good. Do another backup of your database, with another method. One can never be careful enough. Never.

9 – On your hard disk, where you downloaded a copy of your blog’s folders. Time to check your wp-content/uploads directory. The uploads directory should only contain images in gif/jpg/png formats (some subfolders are legit, but one cannot tell “just like that”). Hardened trick after lots of painful experiences, search for *.jpg *.gif *.png and copy-paste all your images in a temporary work folder, and try to run them through a recompression utility like Xnview’s, for instance to recompress all of them as jpeg with a random compression ratio. Why should you do that ? Well, I’ve had in the past a hacker who had already gained control, and who hid as flags.png a file that was actually php in the inside, and that allowed to regain control of the blog if I removed the other traces of infection. If an image file is fake and doesn’t contain image contents, the recompression procedure will break upon loading that image, and you’ll know you must delete that image and not reupload it with the rest when you restore your blog’s contents.

(Intermission) – Hackers almost always do that, most of the time it’s not even manually done, this is botted: leaving “control towers”. Small files that look innocent, but actually allow again to steal whatever info we want from the blog, update files, gain administrative rights. Once you’re hacked, you can be certain you’re having some of them and unless you get rid of them all, the hacker will always find a way back in. Mind you, if you still have a gaping security hole (for instance because of a faulty theme or plugin) the hacker will come back whatever you try.
Also, if this is SHARED hosting, you’re fried, it’s possible other people are hacked and, from their account, the hacker manages to edit your files to have you hacked too. Only your web host can tell you if each hosted account is reachable or not by other evildoers (hopefully not, but, hey, who knows.)
Even if your hosting account is virtually alone on the hosted space, if you have several websites, do all of them share the same owner ? If yes, once again, you’re fried, each hacked website has read and write access to the entirety of your hosting space, so any hacked website is able go to and spread its infection to all your other websites. What fun lies ahead, having to reinstall everything without even knowing which is the culprit! Sigh, that’s where binary folder comparisons with programs like Beyond Compare and logs parsing come into play, but that’s another topic. You’ll have to ask your hosting company about it, ideally each website is independant, but who knows for you.

10 – Killzone time! By FTP, delete EVERYTHING in your blog’s root directory. I mean it, everything. Now, move a folder above it. Go to the /tmp directory. You can safely delete EVERYTHING in there too (this is a /tmp dir, if your hosting server reboots, its contents are deleted anyway, nothing important goes there.) Now, still one directory above the blog’s root folder, do you see php files perhaps ? They ought not to be there. Only exception would be wp-config.php, it can be allowed in there… but delete it anyway, we’re in for a clean reinstallation with as little left from the past as possible.

11 – Almost the last steps before reinstalling. Download wordpress.zip from www.ads-software.com, upload the contents of the zip to your hosting folder.
Edit the wp-config.php file with this text:
define( 'DISALLOW_FILE_EDIT', true);
Create on your disk an htaccess.txt file, write THIS in it:

# Hardening wordpress.
# Disabling PHP in Uploads.
	<IfModule mod_rewrite.c>
		RewriteEngine On
		RewriteRule ^blog/wp\-content/uploads/.*\.(?:php[1-6]?|pht|phtml?)$ - [NC,F]
	</IfModule>
# END
# Block too long queries from having a chance to work properly. Will make impossible to bulk edit groups of more than 10-to-20 posts in the post editor, mind you.
RewriteEngine on
RewriteCond %{REQUEST_URI} .{490}
RewriteRule (.*) - [F]
RewriteCond %{QUERY_STRING}  .{490}
RewriteRule (.*) - [F]
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Upload this htaccess.txt file to your blog’s root folder, rename it as .htaccess

12 – Last step before reinstalling. Please create a new empty database in your hosting account. It will be a temporary database, just to make things easier.

13 – Install the blog as if it were a brand new blog. Open its URL, accept the quick installation routine, provide the mysql credentials to the new database, create yourself an admin account BUT do NOT give it neither the same username nor the same password as in the past, please.
Yep, we won’t import your database at once.
On your hard disk’s backups, look at /wp-content/plugins, that’s the list of your plugins.
Now in your new blog admin, go to Plugins > Add new. One by one, searching their name, reinstall the plugins. Safety first: if one of your plugins had only a few dozens installations elsewhere and has last been updated in 2010, consider finding a more up to date and popular replacement. Try to give these plugins the same options as before.
Now, check your wp-content/themes local backup folder, and use it to find the name of your theme. Go to your web wordpress administration, go to Themes > Add New, search for your theme, reinstall it, give it from memory the same options as before. Same remark, if MUST be a theme that is popular enough and has been updated not too long ago.

(intermission) – Why this fixation on popular and updated less than a year ago fixation ? Because even with the best intentions, pieces of software can contain exploitable flaws that are discovered later on, and if wordpress deletes a theme or a plugin from their repository because it was hackable, you, with it already installed on your blog, you can’t know it.

14 – Now, if you can, let that blog work on the internet for 24 hours. Maybe post a note telling the visitors not to panic, this is temporary, server works, things like that. Does the contagion come back ? And you’re not on a dedicated server for you alone ? If yes: congratulations, it’s another of your websites or another of the hosted users that manages to cross-shitnuke you! Worst case scenario. You can’t do anything about it, except begging your web host to localize you on another cluster entirely, or create virtual separations between each of your websites, making them unable to update each other.

15 – Let’s assume you didn’t get contaminated again. Congratulations, either because you gave up on a too obsolete plugin or theme, or a plugin or theme that was removed by wordpress because it was exploitable but you, poor user, you couldn’t know. Or because it came from an external cross attack. Or you had one of your passwords guessed or stolen, from the blog or another place where, lazy human twat, you were using the same password. Whatever it is, now you’re clean! Yay!

16 – Backup again your new clean blog to your disk, label it as “healthy”, with the date. Download all the files starting from your root folder and below, and download the database too.

17 – The last step, the last thrill. In your hosting account, change once again the password for your former database. Done ? Good. Next: in place of the current database that is 100% virginally pure, you’re going to update your wp-config.php file to use your previous database (change the database name and password in wp-config.php, remember you just changed the password to the old database).
… Immediately after this, I mean it, IMMEDIATELY, you’re going to change all your passwords again. First the blog users. Wait here, are you sure all the blog users are legit, by the way ? Except in rare cases, only you should have rights superior to simple user. And then all the other passwords mentioned in step 1. (Yep, even email, stolen or discovered email passwords are a far too underestimated contagion source.)

… And there, done. No hidden control towers, no way to come back to infect stuff.
With luck ??