Hacked website: what to do immediately in the first few hours

First of all: how to tell if you're really under attack

Some signs are obvious. Others aren't. Here are the most common ones, divided by category.

Signs visible to users The site displays content you never published (drugs, gambling, adult content). The homepage has been replaced with a page claiming the attack. A ransomware message appears demanding payment in cryptocurrency. The site redirects to unknown domains.

Signs in the browser and search engines Google Chrome shows the "This site contains malware" warning. Google Search Console has sent a security notification. Search results for your site show descriptions in Chinese, Russian, or other unrelated content. The site has been removed from Google's index.

Less visible technical signs The admin panel doesn't accept your credentials, but you don't remember changing them. Pages or sections you never created have appeared. The server logs show access from unknown IPs at unusual times. Company emails are being marked as spam by recipients. The server is unusually slow or consuming abnormal resources.

The sneakiest case: some compromises show nothing visible for weeks. The attacker installs a silent backdoor, collects data, or uses the server as a relay for spam, and waits. You discover it months later from a notification by the Data Protection Authority or from a customer reporting suspicious emails received in your name.

The first 4 things to do immediately (within the first 30 minutes)

1. Take the site offline — immediately

It may seem counterintuitive. An offline site loses visibility and potential customers. But a compromised site causes far greater damage: it distributes malware to your visitors, harms your reputation much more deeply than a few hours of downtime, and exposes you to legal liability under the GDPR if user data is breached while the site is still online.

What to do: contact your hosting provider and request a temporary suspension of the site, or replace the homepage with a static maintenance page. If you use a panel like cPanel or Plesk, you can do this yourself.

Don't leave the site online while you investigate.

2. Change all passwords — from a clean device

Change them in this order: the hosting panel password, the FTP/SFTP credentials, the database password, all CMS administrator user credentials, and the password of the company email linked to the site.

Use a device you haven't used to access the site in the last few days — ideally a phone on a data connection different from the company network. If the attacker has compromised your local network, changing passwords from the same device could allow them to be intercepted again.

Use new, randomly generated passwords of at least 20 characters. Don't reuse passwords used previously.

3. Back up the current state — even of the compromised site

It may seem absurd to back up an infected site. Yet it's essential for two reasons.

First reason: forensic analysis. To understand how the attacker got in, you'll need the logs and files in the state they were in at the time of the compromise. If you clean everything before analyzing, you lose this information and risk leaving the same vulnerability open.

Second reason: the GDPR. In the event of a personal data breach, you are required to notify the Data Protection Authority within 72 hours. Having documentation of the system's state at the time of discovery is essential to reconstruct what happened and what may have been exfiltrated.

Make a complete backup — files and database — and store it in a location separate from the compromised server.

4. Document everything with timestamps

Note the exact time you discovered the problem, the signal that alerted you, and the first actions you took. Take screenshots of everything you see: anomalous pages, error messages, notifications in control panels.

This documentation isn't bureaucracy: it's the basis of your report to the Data Protection Authority if needed, and proof that you acted promptly.

In the following hours: analysis and cleanup

Identify the attack vector before cleaning up

The site was compromised in a specific way. If you don't identify it, cleaning is of little use: the attacker will come back through the same door within a few days.

The most common vectors on WordPress sites and open source CMS are these.

Vulnerable plugin or theme. By far the most frequent cause. An outdated plugin with a known vulnerability is exploited by automated scanners that search for that specific version across millions of sites. Check the last update date of every installed plugin and compare it with logs of anomalous access.

Compromised credentials. Administrator account passwords are stolen through phishing, keyloggers on the developer's computer, or reuse of passwords already exposed in other breaches. The site Have I Been Pwned (haveibeenpwned.com) lets you check whether an email appears in databases of stolen credentials.

Unprotected file upload. If the site allows users to upload files — images, documents, attachments — and validation is inadequate, it is possible to upload malicious PHP files that are then executed as code on the server. These webshells give the attacker full access to the filesystem.

Exposed server configuration. Files such as wp-config.php, .env, or .htaccess that are publicly accessible expose database credentials and configuration keys. This often happens after site migrations done in a hurry.

Brute force attack on the admin panel. If the admin panel was not protected by two-factor authentication and the username was the classic admin, attackers were able to automatically try thousands of password combinations until finding the correct one.

Malware scanning and removal

Once you've identified the vector, proceed with the scan. On WordPress there are tools like Wordfence or Sucuri that analyze files in search of malicious code. These tools are useful but not infallible: sophisticated malware can hide in ways that evade known signatures.

Specifically look for PHP files in folders where they shouldn't be (uploads, images, cache folders), dangerous PHP functions in existing files such as eval(), base64_decode(), system(), exec(), lines of obfuscated code that look like random strings, and recently created administrator users that you don't recognize.

The most reliable method — if you have a clean backup from before the compromise — is to restore the original files and reapply only the content (text, images, database) after inspecting it.

Request Your Free Security Audit →

The hidden backdoor: the most underestimated danger

Whenever a site is compromised, the attacker almost invariably installs a backdoor: a file or a piece of code that allows them to get back in even after you've changed all the passwords and removed the obvious malware.

Backdoors are hidden in the least obvious places: in files with names that mimic legitimate system files (.info.php, wp-cache.php), in images that actually contain PHP code, in deactivated but not deleted plugins or themes, in server configuration files.

If you're not sure you've found and removed every backdoor, the safest approach is a complete restoration of the environment from scratch: clean server, CMS reinstalled, plugins reinstalled from official sources, content restored from backup.

The obligation many forget: GDPR notification within 72 hours

If the site collects users' personal data — and almost all business websites do, even just through the contact form — a security breach that may have exposed that data constitutes a data breach under GDPR.

In this case you are required to notify the Data Protection Authority within 72 hours of discovering the incident, through the Authority's portal.

The notification must include: the nature of the breach and the categories of data involved, the approximate number of people affected, the measures taken or underway to remedy the situation, the contact details of the Data Protection Officer (DPO) if appointed.

Penalties for failure to notify can reach up to 10 million euros or 2% of worldwide annual turnover. But beyond the penalties, notifying promptly is also a matter of fairness toward the people whose data you may have exposed.

Don't wait until you're absolutely certain of what happened to notify. The regulation accepts preliminary notifications to be updated later. Waiting to have all the details and exceeding the 72 hours is worse than notifying with incomplete information.

What to do after the cleanup: the 5 steps to avoid starting over

Once the site is back online, the most important job is making sure it doesn't happen again.

Update everything, immediately and always. CMS core, all plugins, all themes — including inactive ones. An inactive theme still present on the server is still accessible and exploitable. Consider deleting everything you don't use.

Enable two-factor authentication on the admin panel. With 2FA active, a stolen password isn't enough to gain access. The attacker would also need your phone. This measure alone eliminates the vast majority of brute force and credential phishing attacks.

Limit access to the admin panel. If you always log in from the same network, you can set up a whitelist of IPs allowed to access the admin panel. Everything else gets a 403 response, even with correct credentials.

Monitor actively. A monitoring system that alerts you when a new PHP file is created in the upload folders, when a new administrator user is registered, or when a core file is modified, lets you catch a compromise within minutes instead of discovering it weeks later.

Review who has access and with what permissions. Every administrator account is a potential entry point. Remove the accounts of developers who no longer work with you, lower the permissions of users who don't need full administrative rights, and keep track of who has access to what.

The question worth asking now

If your site has been attacked, the most important question isn't "how do I fix it?" but "why did it happen?".

The honest answer, in most cases, is that the system running your site was built without considering security as an architectural requirement. Security was added afterwards — with plugins, with external services, with manual updates — on a foundation that wasn't designed to withstand attacks.

A CMS built with security in its core, where protection against SQL injection and XSS doesn't depend on third-party plugins but is integrated into how the system handles every input and every output, has a fundamentally different attack surface. Not because it's magically invulnerable, but because the problem is solved where it needs to be solved: in the architecture, not in the patch.

If you want to concretely understand how exposed your current site is, you can request a free audit from us. We analyze the attack surface of your existing site and provide you with a report of the vulnerabilities found — with no obligation.

Request Your Free Security Audit →