Someone hacked my website — what should I do?
A website breach calls for a quick response, but random, ill-considered actions can make the situation worse. Deleting a few suspicious files, restoring an old backup, or installing another security plugin will not necessarily solve the problem.
Below is an order of operations that can help limit the impact of an attack and improve the chances of cleaning the website thoroughly and permanently.
Step 1 — Do not immediately delete suspicious files
The first impulse is often to delete everything that looks unusual. However, doing so can damage the website, destroy information needed for analysis, remove only part of the infection, leave an active backdoor, or make it harder to determine when and how the breach occurred.
Record the names, locations, and modification dates of suspicious files. If possible, make a copy of them in an isolated directory. Do not run suspicious files on your computer.
Step 2 — Make a backup of the current state
Before starting repairs, make a complete backup of the website files, database, messages from your hosting provider, server logs, DNS configuration, user list, and information about recent changes.
The backup may contain malware, so it should not later be restored without first being checked. It is nevertheless needed for analysis and as protection against data loss.
Step 3 — Restrict access to the infected website
If the website redirects visitors, steals data, distributes malicious files, displays fake forms, or attacks other servers, temporarily restrict its operation.
You can put up a technical notice, block access, or limit traffic to selected IP addresses. A standard maintenance-mode plugin may not stop malicious code running directly on the server outside WordPress.
Step 4 — Contact your hosting provider
Ask your hosting provider for information: which files were detected, when the activity was detected, whether the account sent spam, whether there were unusual logins, whether any specific processes were blocked, and whether logs from the time of the breach are available.
Do not ask your hosting provider only to unblock the website. If the source of the problem remains active, the infection may quickly return.
Step 5 — Change passwords from a secure device
Change passwords from a computer that is up to date, has been scanned, and shows no signs of infection. Change the passwords for:
- the hosting control panel
- FTP and SFTP
- SSH
- the CMS administrator panel
- the database
- email accounts
- DNS services and the domain registrar
- accounts associated with backups
- external services connected to the website
Do not reuse the same password in multiple places. Enable two-factor authentication wherever it is available. Changing passwords alone is not enough if a backdoor remains on the server.
Step 6 — Log out active sessions and remove unknown access
Check active administrator sessions, unknown user accounts, API keys, access tokens, SSH keys, FTP accounts, integrations with external services, and applications that have access to the hosting account or domain.
Remove or revoke anything you do not recognize. Also check whether the attacker changed the email addresses used for account recovery.
Step 7 — Check every installation on the hosting account
If the same hosting account contains other WordPress or Joomla websites, test versions, old site backups, unused subdomains, or directories left over from previous migrations, each one should be checked.
An attacker may break in through an old, forgotten installation and then modify files belonging to the other websites. Cleaning only one domain often leads to reinfection.
Step 8 — Preserve logs and determine when the breach may have occurred
Useful sources may include HTTP, FTP, SSH, hosting-panel, and application logs; update history; a list of recently changed files; and security notifications.
Logs may help identify the vulnerability that was exploited, the attacker's IP address, the compromised account, the vulnerable extension, and when the backdoor was created. This is not always possible, especially if the hosting provider retains logs for only a short time.
Step 9 — Do not restore a random backup
A backup is helpful only if you know that it was made before the breach. Restoring a backup may not solve the problem because it may already contain malware, a vulnerable plugin may remain, other websites on the hosting account may be infected, or a cron job may recreate malicious files.
After restoring a backup, you still need to investigate, update, and secure the environment.
Step 10 — Remove the infection and its cause
A proper cleanup should cover CMS core files, plugins, components and themes, the database, administrator accounts, configuration files, .htaccess, .user.ini and php.ini, cron jobs, directories containing user files, other websites on the hosting account, and mechanisms that recreate malware.
Deleting a file detected by a scanner is not enough. You need to determine how it got onto the server and whether other access mechanisms exist.
Step 11 — Update the CMS and extensions
After cleaning the website: update the CMS, update legitimate extensions, remove unused plugins and themes, replace components that are no longer maintained, remove pirated themes and extensions, and check PHP-version compatibility.
Do not update everything without first making a backup and checking compatibility. An abrupt update to an old website may cause additional errors.
Step 12 — Check whether data may have been compromised
If the website stores customer or employee data, user accounts, orders, contact forms, payment data, or documents, assess whether the attacker could have accessed them.
Depending on the type of data and the scope of the incident, additional legal obligations may arise. In that situation, consult the person responsible for data protection. Do not inform users based on assumptions, but do not ignore the possibility of a data breach.
Step 13 — Request a review of the website
If Google or a browser has marked the website as unsafe, request a review only after the website has been fully cleaned, the exploited vulnerability has been closed, the software has been updated, passwords have been changed, other installations have been checked, and you have confirmed that malicious content is no longer accessible. A review request submitted too early may be rejected.
What should you not do after a breach?
- Do not delete files without making a backup
- Do not send passwords by ordinary email
- Do not install several scanners at the same time
- Do not restore the first backup you find
- Do not leave old websites on the same hosting account
- Do not delete only the files identified by your hosting provider
- Do not assume that changing a password has solved the problem
- Do not bring the website back online without testing it
When should you request a professional investigation?
Get specialist help if the infection keeps returning, the website contains customer data, the hosting provider has blocked the entire account, you do not have a reliable backup, several websites run on the hosting account, you do not have access to logs, the online store has stopped working, or thousands of spam URLs have appeared in Google.