What to do after a compromise

After a site compromise, take a JetBackup copy or snapshot first so you still have the original files and logs. Put the site on a maintenance page if you can, then rotate every password and key that lived on the account. Restore from a date you know was clean, and only then patch the hole that let the attacker in. Reinstalling WordPress over the damaged files is not a cleanup, because it leaves wp-config, .htaccess, cron jobs, and rogue users in place.

Preserve a copy before you change anything

If JetBackup shows a restore point from before the odd admin user or the first Imunify hit, plan to use that later. Make a fresh copy now anyway, even when you already suspect the site is owned. You may need those files and logs when you review what changed. Tell us in the ticket that this is a site compromise so we can review Imunify and the logs with that in mind. Include the hostname, when you first noticed the problem, and whether you already restored. Do not paste malware samples into the ticket.

A freelancer who connects over FTP and “cleans” production as step one often misses scheduled cron jobs. You can end up paying twice for the same incident. Prefer a known-good restore, or a rebuild from clean theme and plugin files plus a database you have inspected.

Rotate every secret on the account

Treat every credential that lived on the box as burned. Change the cPanel password, FTP accounts, all WordPress admin users, and the database password stored in wp-config.php. Update registrar login details, any mailbox used for password resets, GitHub deploy keys, and CDN tokens. End active WordPress sessions and turn on two-factor authentication while you are in those panels. If the registrar account used email hosted on this same account, that mailbox is burned too and needs a new password elsewhere first.

Restore a known-good date, then close the hole

The usual path is copy, maintenance page, full rotation, restore of a known-good date, then a focused patch. Common entry points include open xmlrpc brute force, an abandoned plugin, or a leftover admin user you no longer need. Watch Imunify for a day after you bring the site back. Buying a larger plan does not remove an attacker who already has credentials or backdoors.

If JetBackup’s calendar has no clean day, export the database and inspect the users table before you load anything back. A slower rebuild from a known-good copy of your themes and a scrubbed dump is more honest than guessing. Notify the registrar if reset mail for that account lived on this box. Leave xmlrpc disabled when you do not need it, and remove unused admin users before you call the work finished. xmlrpc abuse can look like an outage, so rule that out before you spend a week on a full rebuild you may not need.