If your website has been hacked, the priority is to stop the damage, remove malicious changes, and bring the service back online safely. In a hosting or managed hosting environment, this usually means checking the site files, database, accounts, and server-side settings, then restoring only trusted content. If you use a control panel such as Plesk, the process is often faster because you can review backups, file permissions, logs, and security tools from one place.
A hacked website can affect more than the visible pages. Attackers often inject phishing forms, redirect visitors to other domains, create hidden admin users, add backdoors, and break SSL trust by changing configuration files or serving mixed content. In the EU hosting context, it is also important to restore the site quickly while keeping user data secure and making sure the public version of the website is clean, stable, and compliant with your internal security procedures.
This article explains how to clean up a hacked website step by step, how to identify the most common infection points, and how to restore service without reintroducing malware from a bad backup.
What to do first after discovering a hack
Before you start deleting files, take a few minutes to contain the incident. A rushed cleanup can make recovery harder if you remove evidence, overwrite good data, or restore an already infected backup.
1. Put the website in maintenance mode if possible
If the site is still online and actively serving malicious content, switch it to maintenance mode or temporarily disable public access. In Plesk, you can use hosting settings or a maintenance page if your application supports it. If maintenance mode is not available, restrict access with password protection or a temporary firewall rule.
2. Change passwords immediately
Reset credentials for:
- Hosting control panel accounts
- FTP / SFTP / SSH users
- CMS administrator accounts
- Database users
- Email accounts linked to the domain
Use strong, unique passwords and, where available, enable two-factor authentication.
3. Check for suspicious redirects and SSL warnings
Open the website in a private browser window and confirm whether users are being redirected to unknown domains, seeing browser warnings, or getting mixed content errors after login. These symptoms can help narrow the infection to .htaccess rules, JavaScript injections, or theme/template files.
4. Preserve logs and evidence
Do not immediately delete logs. Access logs, error logs, and application logs can show the first suspicious request, the infected script, or the account used to upload the malicious file. This is especially useful when the site is hosted on a managed hosting platform and you need to report the incident to support.
How a website is usually hacked
Understanding the attack path helps prevent reinfection. Most compromises do not start with the server itself. They usually begin with weak credentials, outdated software, or a vulnerable plugin, theme, or custom script.
Common infection sources
- Outdated CMS core, plugins, or themes
- Weak FTP, SSH, or admin passwords
- Compromised local workstation used for uploads
- Insecure file permissions
- Exposed admin panels or forgotten test sites
- Malicious cron jobs or scheduled tasks
- Injected code in database content or page builders
Typical signs of a compromise
- Unexpected redirects or pop-ups
- New files in uploads, cache, or tmp directories
- Hidden admin users in the CMS
- SEO spam pages or foreign-language content
- Modified .htaccess, wp-config.php, or index files
- Browser security warnings or SSL trust issues
- High CPU usage or unusual outbound traffic
Step-by-step cleanup process
The safest approach is to clean from the outside in: start with access control, then review files, database content, scheduled jobs, and web server rules.
Step 1: Verify the scope of the infection
Check whether the compromise affects only one site, one account, or multiple sites on the same hosting subscription. In control panel environments, one infected account can sometimes host several domains, subdomains, or application instances. Review:
- All domain roots and subdomains
- Temporary folders and caches
- Mail directories if email was also compromised
- Shared user accounts and additional FTP logins
Step 2: Compare files against a known good version
The fastest way to identify malware is to compare the current site against a clean backup or a fresh copy from the application vendor. Focus on:
- Core application files
- Templates, themes, and plugins
- Configuration files
- Upload directories containing PHP, JS, or unusual file types
- Recently modified files
Be cautious with generic clean-up scripts that delete all unfamiliar files. Some legitimate plugins create dynamic files, cache folders, or minified assets that may look suspicious at first glance.
Step 3: Remove obvious backdoors and malicious injections
Look for code patterns that often indicate a backdoor or obfuscated payload, such as:
- Long strings with base64, gzinflate, str_rot13, or eval
- PHP files inside image upload folders
- Unexpected iframe inserts in templates
- JavaScript redirect code in header or footer files
- Hidden admin usernames or strange cron entries
If you are unsure whether a file is legitimate, replace it with a clean copy from the official source rather than editing it manually.
Step 4: Clean the database
Many infections are stored in the database, especially on CMS-based sites. Check posts, pages, widget areas, menu items, custom HTML blocks, and option tables for:
- Spam links
- Injected scripts
- Malicious iframes
- Hidden redirects
- Fake login forms
If the platform has a built-in database tool or phpMyAdmin access, export a backup before changing records. This gives you a rollback point if you remove legitimate content by mistake.
Step 5: Review scheduled tasks and startup points
Attackers often persist by adding cron jobs or app-level scheduled tasks that recreate the infection after cleanup. Check:
- System cron jobs
- CMS scheduled tasks
- Auto-generated scripts in tmp or cache folders
- Startup hooks in configuration files
Step 6: Replace the application core with clean files
For most CMS platforms, the safest method is to reinstall the core application from a trusted source and keep only the content that you know is clean. Reuse uploads and custom files only after scanning them carefully. This is usually more reliable than trying to patch each file manually.
Step 7: Scan the account from the hosting side
Use the tools available in your hosting platform or Plesk environment to scan for malware, suspicious permissions, and infected archives. If your plan includes server-side security checks, run them on the full hosting subscription, not just the public web root. Also review whether PHP handlers, file permissions, or outdated extensions are exposing the site to further risk.
How to restore service safely
Once the site is clean, restore it in a controlled way. The goal is to bring the website back online without restoring the malware at the same time.
Use a clean backup, not the latest backup by default
The most recent backup may already contain the infection. Choose a backup from before the first sign of compromise. If possible, validate it in a staging environment before publishing it. In managed hosting setups, restoring to staging first is often the safest option.
Test the site before opening it to the public
Check the restored site for:
- Broken links and missing assets
- Login and checkout functionality
- Form submissions
- Mixed content warnings
- SSL certificate validity
- Unexpected redirects on desktop and mobile
Clear caches and CDN layers
Malicious content can persist in application cache, reverse proxy cache, browser cache, or CDN cache even after the server files are cleaned. Purge all available cache layers, including object cache, page cache, and any proxy cache in front of the site. If you use a CDN, confirm that it is not serving an old infected version.
Force HTTPS and verify secure browsing
After restoration, confirm that the website loads consistently over HTTPS. If the site still shows mixed content, check hardcoded resource URLs, theme templates, and database-stored links. Mixed content is not the same as malware, but it can cause browser warnings and make a recovered website look untrustworthy to users.
Fixing SSL and mixed content issues after a hack
Hacked sites often have HTTPS problems because malware changes redirects, certificate paths, or resource URLs. In the HTTPS and Cleanup Problems category, these are common after a cleanup.
Check redirect rules
Review .htaccess, web server directives, and application settings for unexpected rewrite rules. Malicious redirects can send users to phishing pages, while broken HTTPS rules can create redirect loops. Make sure only one canonical redirect path exists, for example from HTTP to HTTPS and from non-www to www, or the reverse, depending on your setup.
Search for insecure resource URLs
Replace old http:// links in content, templates, and configuration files with https:// where appropriate. Pay special attention to:
- Image paths
- CSS and JavaScript includes
- Font files
- Embedded videos and widgets
- Internal links in page builders or database content
Verify certificate status and renewal
If the site displays certificate errors after cleanup, confirm that the correct certificate is installed, the domain resolves to the right host, and the certificate chain is complete. In some cases, a hack or forced redirect may have masked a renewal problem that was already present.
Post-cleanup security hardening
Cleanup is only half the job. Without hardening, the site can be reinfected within hours or days. Focus on the weakest entry point first.
Update everything
- CMS core
- Plugins and extensions
- Themes and templates
- Server packages if managed by your hosting environment
- Any custom code or scripts
Remove unused accounts and files
Delete old admin users, expired FTP accounts, unused staging sites, and abandoned test folders. Attackers often scan for forgotten copies of the site that are still writable.
Restrict file permissions
Use the minimum permissions needed for the application to run. Avoid world-writable files and directories unless they are required by the software. A common cleanup mistake is leaving permissions too open after debugging.
Enable protection features
Depending on your hosting stack, you may be able to enable:
- Web application firewall rules
- Malware scanning
- Login rate limiting
- IP restrictions for admin panels
- Two-factor authentication
- Automatic security updates
Review email deliverability and blacklists
If the hacked site sent spam or hosted phishing pages, your domain or IP may have been flagged. Check mail queues, outgoing scripts, and blacklists. Cleaning the website does not automatically fix reputation issues.
How to prevent reinfection
Prevention should be built into your hosting workflow. A clean site can become compromised again if the original entry point is still open.
- Keep regular backups and store at least one offline or immutable copy
- Use separate credentials for each site and environment
- Limit write access to only the folders that need it
- Review logs after updates or plugin installs
- Use staging for major changes before publishing
- Audit third-party plugins and themes before installing them
- Set up alerting for file changes or admin logins where available
When to restore from backup and when to clean manually
Use a clean backup if the attack affected many files, if the application core is heavily modified, or if you need to restore service quickly and can validate the backup first. Manual cleanup is better when the infection is limited to a few files, one database record set, or a specific redirect rule.
If you restore from backup, verify that the backup predates the compromise and does not contain the same malware. If you clean manually, document every change so you can undo it if necessary and repeat the process on other affected sites in the same account.
FAQ
How do I know if my website is fully clean?
No single check proves a website is 100% clean. Combine file comparison, malware scans, log review, database checks, and a test of the public site over HTTPS. If the site behaves normally and no suspicious changes reappear after several hours or days, that is a strong sign the cleanup was successful.
Should I delete everything and start over?
Not always. Rebuilding from scratch is sometimes the safest choice, especially for heavily infected sites, but many websites can be recovered faster by restoring a clean backup and replacing only the compromised parts. The right choice depends on how far the infection spread.
Why does the site still redirect after I cleaned the files?
The redirect may still exist in browser cache, CDN cache, database content, a hidden .htaccess rule, or a scheduled task. Check all layers, not just the public files.
Can a hacked website break SSL?
Yes. Malware can alter redirects, inject insecure resources, or modify hosting configuration files. Even if the certificate itself is valid, the browser may still show warnings because the page is loading mixed content or sending users to unsafe destinations.
What should I tell visitors or customers?
If the site handled user accounts, orders, or personal data, communicate carefully and factually. Explain that the site was temporarily affected, that access was restored after cleanup, and that passwords may need to be reset. Follow your internal incident response policy and legal requirements for the EU market if personal data may have been exposed.
Do I need to reissue my SSL certificate after a hack?
Usually not, unless the certificate, private key, or account access may have been exposed. If there is any doubt about key compromise, replace the certificate and generate new private keys.
Conclusion
Cleaning up a hacked website is a combination of containment, careful investigation, file and database recovery, and post-incident hardening. In a hosting or Plesk-based environment, the most reliable method is to verify the infection scope, restore only trusted files, remove persistence points, clear caches, and confirm that HTTPS works correctly after cleanup. Once the site is stable again, close the original attack vector so the same problem does not return.
If you are restoring a site on a managed hosting platform, use the control panel tools available to review backups, logs, permissions, and security settings before putting the site fully back online. A clean, tested restoration is safer than a fast restoration that leaves hidden malware behind.