File permissions keep reverting after a hack

You set the permissions on index.php, or another file, to 644 in FileZilla. Within seconds they're back to 444, and the file content has been overwritten too. Replacing the file with a clean copy has the same outcome: it's overwritten again.

This article explains why this happens and how to stop it.

The symptom

You set index.php to 644 in FileZilla. Within seconds it's back to 444, and the file content has been overwritten too. Uploading a clean copy has the same outcome.

The cause

This is not an FTP problem and not a permissions problem on your account.

Malicious code is running inside a PHP-FPM worker. The worker stays alive in memory and rewrites your files the moment you change them, setting the mode back to 444. FileZilla looks broken, but the file is being overwritten and chmod'ed by a PHP process on the server, just after your upload.

Killing that worker stops it. The worker belongs to the FPM pool that serves the site, so you restart that pool.

After a restore from backup

The same loop can appear right after restoring from a backup, because the backup often includes the infected files. Same fix.

Steps

1. Restart the FPM pool

A restart kills every PHP-FPM worker for the pool and starts fresh ones, so the malicious process is gone. See Restart and reload for both routes to the 'Restart' button.

'Reload' is not enough. It lets the current request finish first, which gives the malware time to rewrite the file and reset its mode before the worker is replaced.

2. Replace the file and set the permissions

Your upload of a clean index.php and the change to 644 now succeed, and are not reverted.

Do the same for every other file you know is compromised.

3. Check the malware scan results

The cluster runs a daily malware scan (maldet) across UNIX user home directories. Hits appear under 'Malware' on the UNIX user page and on the project page, with the file path and a 'Last Seen' timestamp. See Malware scanning.

Clean up every file in the list. If you miss one, the next request to it starts a new worker that rewrites your fixed files, and the permissions start reverting again.

4. Close the entry point

The two most common ways in:

An outdated CMS, plugin, or theme.
A leaked FTP, SSH, or admin password.

Update the software and change any credentials that may have leaked. If you skip this, the site is hacked again — usually within days — and the permissions start reverting again.