How to Recover a Website After Malware or Hacking

If you suspect a website infection, treat the issue as urgent but controlled. The fastest safe recovery is not to “clean everything immediately”, but to isolate the site, preserve evidence, remove the cause, and restore a known-good version. In a managed hosting or control panel environment such as Plesk, this usually means working through backups, file integrity checks, password resets, and a careful re-deployment of clean content rather than trying random fixes on the live site.

How to tell if a website has been hacked or infected with malware

Malware incidents do not always look dramatic. Some websites show obvious warnings, while others continue to load normally but quietly redirect visitors, send spam, or inject hidden scripts. In hosting environments, the first signs are often found in logs, security scans, or customer complaints rather than on the homepage itself.

Common signs of compromise

  • Unexpected redirects to unfamiliar domains or landing pages.
  • New administrator accounts, especially in WordPress, Joomla, or other CMS platforms.
  • Defaced pages, missing content, or strange text inserted into templates.
  • Unusual CPU or disk usage in the hosting control panel.
  • Spam emails being sent from the account or website contact forms.
  • Files modified at unusual times, especially in uploads, tmp, or theme directories.
  • Security tools, browser warnings, or search engine alerts about harmful content.

Confirm whether the issue is malware, a failed update, or deletion

Not every broken website is hacked. A site may be down because of a bad plugin update, missing database tables, deleted files, expired PHP compatibility, or a corrupted cache. Before restoring, check whether the problem is:

  • Malware infection — malicious code was injected into files, database content, or scheduled tasks.
  • Unauthorised access — someone gained access to the control panel, FTP, SSH, or CMS admin area.
  • Failed update — an application, plugin, or theme update broke the site.
  • Accidental deletion — files, database records, or an entire site were removed.

This distinction matters because the recovery steps are similar, but the cleanup depth is not. If you restore an infected backup without removing the source of compromise, the website can be reinfected within minutes.

Immediate actions to protect the website

Before making any changes, contain the incident. A controlled response reduces the chance of spreading malware to visitors, email accounts, and other hosted sites in the same account.

1. Put the site into maintenance mode or take it offline

If possible, enable maintenance mode from the CMS or temporarily restrict public access using the hosting control panel. In Plesk, you can also use web hosting settings, password protection, or a temporary rule in the site configuration. If the infection is active, removing public access helps stop further damage while you investigate.

2. Preserve evidence

Do not immediately delete suspicious files if you may need support or a forensic review. Save copies of:

  • recent error logs and access logs;
  • a list of modified files and their timestamps;
  • screenshots of warnings, redirects, or defacement;
  • any suspicious usernames, IP addresses, or login events.

This information can help identify the entry point, such as a weak password, vulnerable plugin, or exposed upload endpoint.

3. Change passwords and revoke access

Reset credentials as soon as the site is contained. This should include:

  • hosting control panel password;
  • FTP/SFTP accounts;
  • SSH access, if enabled;
  • database user passwords;
  • CMS administrator accounts;
  • email accounts linked to the domain;
  • API keys, tokens, and application secrets.

If your platform supports session invalidation, log out all active sessions so any stolen cookies stop working.

Restore from a clean backup the safe way

The most reliable recovery method is to restore a backup from before the compromise, then apply security cleanup before the site is reopened. In a backup-driven hosting environment, this often provides the fastest return to service.

Choose the right restore point

Select a backup from a time when the website was known to be healthy. Ideally choose one created before the first suspicious activity. If you restore a backup that already contains malicious code, you will simply reintroduce the problem.

When reviewing restore points, consider:

  • the approximate date of first compromise;
  • the last known safe site behavior;
  • whether the backup includes both files and database;
  • whether the backup was created before a risky plugin or theme update.

Restore files and database carefully

For full-site recovery, both the file system and the database usually need to be restored together. Restoring only files may leave malicious database content behind, such as injected JavaScript in posts, widgets, or product descriptions. Restoring only the database may leave infected PHP files in place.

If your control panel supports granular recovery, you can restore the website to a staging location first. This is often safer than replacing the live site directly.

Check whether the backup is clean

Before pointing the domain back to the restored site, scan the backup contents for suspicious indicators:

  • obfuscated PHP code such as base64_decode, eval, gzinflate, or long encoded strings;
  • unknown files in image or upload directories;
  • unexpected cron jobs or scheduled tasks;
  • recently changed theme or plugin files that do not match the original version;
  • strange admin users or hidden content in the CMS database.

Clean the infection before bringing the site back online

Restoration should be followed by security cleanup. Even if the backup looks clean, the original attack path may still be open. A successful recovery closes that path so the issue does not return.

Scan files and compare against known-good versions

Use available malware scanning tools in your hosting environment, or compare the current files against a trusted source repository or original package. Focus on:

  • core application files;
  • theme and template files;
  • plugin or extension directories;
  • upload folders that should normally contain only media files;
  • hidden files such as .htaccess, .user.ini, and scheduled task definitions.

If you have a managed hosting platform with file manager access, look for unusual file names that imitate legitimate components, such as single-letter PHP files, random hashes, or recently added files in writable directories.

Remove malicious code and unknown accounts

Delete files that are clearly malicious and restore legitimate files from a trusted source. Remove CMS users, control panel users, and database accounts that you do not recognise. Review file ownership and permissions as well. A compromised account with excessive permissions can re-create the infection after cleanup if it remains active.

Review scheduled tasks and startup points

Attackers often use cron jobs, task schedulers, or auto-prepend configuration to survive file cleanup. Check for:

  • unexpected cron entries in the hosting account;
  • PHP auto-prepend or auto-append directives;
  • compromised .htaccess redirects;
  • server-level rewrite rules that send visitors elsewhere.

In Plesk and similar control panels, review both the subscription-level scheduled tasks and application-level automation settings.

Harden the website after recovery

A recovered site should be treated as a fresh security baseline. Hardening reduces the chance of reinfection and protects the rest of the hosting account.

Update the application, plugins, and themes

Apply the latest stable updates for the CMS, extensions, and themes after the site is clean. Many compromises happen through vulnerable plugins, outdated themes, or unsupported application versions. Update only after you have restored the site and verified compatibility, especially if a previous update triggered the incident.

Enable least-privilege access

Review who can access the site and how. Good recovery practice is to limit access to what is truly necessary:

  • use separate FTP/SFTP accounts per user or project;
  • avoid shared administrator credentials;
  • restrict SSH access to trusted users only;
  • remove unused accounts and keys;
  • disable write access where it is not required.

Strengthen file permissions and configuration

Incorrect permissions can make reinfection easier. Check that directories and files use sensible permissions for your platform. In many hosting setups, writable directories should be limited to upload locations, while application code should not be broadly writable. Also verify that dangerous functions, if relevant, are not exposed unnecessarily.

Use security headers and anti-abuse protections

Where appropriate, add protective measures such as:

  • content security policy for sites that support it;
  • web application firewall rules;
  • rate limiting or login protection;
  • two-factor authentication for admin and control panel access;
  • CAPTCHA or anti-spam controls on forms.

These measures do not replace cleanup, but they reduce the likelihood of repeat compromise.

Special recovery cases in managed hosting and Plesk

In hosting platforms with a control panel, recovery is often faster because backups, file management, logs, and security tools are accessible from one place. The best approach is to use those tools in a structured order rather than making isolated fixes.

Recovering a site from Plesk backups

If the platform includes backup management, confirm the backup date and scope before restoring. Look for whether the backup contains:

  • website files;
  • databases;
  • mail data, if needed;
  • configuration files;
  • scheduled tasks or other account settings.

If you only need to recover the website, you may not need to restore mail or unrelated service data. Restoring less can reduce the chance of reintroducing old problems.

Using a staging copy first

When available, restore the website to a staging environment before replacing the live site. This lets you verify:

  • that the backup loads correctly;
  • that pages do not contain hidden malicious scripts;
  • that forms, checkout flows, and logins work;
  • that the restored site is compatible with the current PHP or application version.

Reviewing web server logs and access patterns

Apache logs and related access logs can show how the attacker entered the site. Look for:

  • repeated login attempts;
  • requests to vulnerable plugin endpoints;
  • uploads of executable files;
  • suspicious POST requests to admin paths;
  • unusual traffic from the same IP ranges around the time of compromise.

This review is useful not only for cleanup, but also for preventing future incidents.

What not to do after a hack or malware incident

Some well-intentioned actions can make recovery slower or less reliable.

  • Do not restore an unknown backup without checking its date and integrity.
  • Do not keep the site public while cleaning if the infection is active.
  • Do not delete logs before you have reviewed them or shared them with support.
  • Do not reuse passwords that may have been exposed.
  • Do not assume that a visual cleanup means the site is fully safe.
  • Do not ignore the database, which may contain injected code or hidden redirects.

How to verify that the website is clean

After cleanup and restoration, validate the site before removing maintenance mode. A proper verification step helps avoid putting a partially cleaned website back into production.

Basic verification checklist

  • Browse the homepage and main sections in an incognito session.
  • Check that no unexpected redirects occur.
  • Inspect the page source for unknown scripts or frames.
  • Test login, contact forms, search, and checkout if applicable.
  • Re-scan the site using available malware tools.
  • Review recent file changes to confirm no new suspicious edits appear.

Check external reputation

Search engine warnings, email deliverability issues, and browser blocklists may persist for a short time after cleanup. If your website was flagged externally, you may need to submit a review request after verifying that the infection is removed. Make sure the issue is actually resolved before requesting re-evaluation.

When to contact hosting support

Contact support if you cannot access the control panel, cannot identify the entry point, or suspect the compromise affects more than one website in the account. Hosting support can often help with log access, backup restoration guidance, server-side scanning, or isolation of the affected subscription.

Provide support with:

  • domain name and affected account details;
  • approximate time the issue started;
  • what symptoms you observed;
  • steps already taken;
  • log excerpts or screenshots if available.

If your hosting plan includes managed assistance, it may be appropriate to request help with restoring a clean backup, reviewing security logs, or verifying the site after recovery.

Prevention tips to reduce the risk of future recovery incidents

The best recovery process is one you do not need to repeat often. Prevention is especially important for websites running popular CMS platforms, extensions, and custom themes, because those are common attack targets.

  • Keep the CMS, plugins, and themes updated.
  • Use unique passwords and two-factor authentication.
  • Remove unused plugins, themes, and user accounts.
  • Schedule regular backups and test restores.
  • Limit admin access by role and IP where possible.
  • Monitor file changes and login activity.
  • Use SFTP or SSH instead of plain FTP.
  • Review contact form and upload abuse settings.

For EU-based hosting environments, it is also good practice to keep recovery records and incident notes in a way that supports internal security processes and data protection obligations.

FAQ

Can I just restore a backup and be done?

Sometimes, but only if the backup is known to be clean and the original cause has been fixed. If the vulnerability or stolen password remains active, the site can be infected again after restoration.

Should I restore files or the database first?

For most full-site incidents, restore both from the same clean point in time. If the issue is limited to deleted files, a file restore may be enough. If the database contains injected content, that part must be cleaned as well.

What if I do not have a backup from before the attack?

Use the most recent backup available, then scan and clean it carefully. You may also need to rebuild parts of the site from trusted source files, cached pages, or exported content. In some cases, manual reconstruction is safer than restoring a heavily infected snapshot.

How do I know if the attacker is still inside the account?

Review passwords, active sessions, admin users, SSH keys, FTP accounts, and scheduled tasks. If new suspicious files keep appearing after cleanup, assume there is still an active access path.

Is a malware scanner enough to confirm recovery?

No. Scanners help, but they do not guarantee that every backdoor or injected rule has been removed. Always combine scanning with log review, password resets, and file integrity checks.

Should I notify customers or users?

If the compromise exposed user data, email content, forms, or account credentials, you should follow your incident response and legal obligations. For EU-focused services, consider data protection requirements and internal reporting procedures.

Conclusion

Recovering a website after malware or hacking is most successful when you combine containment, clean restoration, and security hardening. Start by taking the site offline or limiting access, preserve evidence, reset credentials, and determine whether the problem is malware, a failed update, or accidental deletion. Then restore from a known-good backup, clean the attack vector, verify the site, and only bring it back online when you are confident it is safe.

In a hosting platform or Plesk-based environment, the right tools can make this process more efficient, but the logic stays the same: restore carefully, verify thoroughly, and close the vulnerability that allowed the incident in the first place.

  • 0 Users Found This Useful
Was this answer helpful?