What to Do If Your Website Gets Hacked

Experiencing a corporate security breach is a highly critical operational incident that requires an immediate, structured response to limit financial, reputational, and legal exposure. Understanding exactly what to do if your website gets hacked allows security administrators and business owners to limit the blast radius of an intrusion. This authoritative blueprint outlines the systematic protocols necessary to safely isolate compromised assets, revoke unauthorized administrative credentials, perform deep forensics on access logs, and restore operational integrity without risking reinfection. By executing these defensive measures, enterprises can maintain compliance with data privacy regulations and safeguard search engine visibility.

Immediate Damage Control: Containment and Isolation

Take the Website Offline Immediately

The primary phase of any incident response framework is containment. When a web asset is compromised, maintaining its public availability risks exposing users to malware injection, drive-by downloads, or phishing schemes. Leaving a hacked site online also provides malicious actors with continued access to execute additional remote code payloads.

To prevent this, you must display a static maintenance page that returns an HTTP 503 "Service Unavailable" status code. Returning a 503 code is critical for search engine preservation; it instructs web crawlers like Googlebot that the downtime is temporary and that they should return later to re-index the content. Returning a 500 internal server error or a 404 page can severely damage your search visibility and organic rankings if sustained.

You can configure your web server to redirect all inbound traffic to a static file using server configuration modifications. If you are operating on an Apache web server, append the following directive rules to your .htaccess configuration file:

RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.100$
RewriteCond %{REQUEST_URI} !^/maintenance\.html$ [NC]
RewriteRule ^(.*)$ /maintenance.html [R=503,L]

Replace 192.168.1.100 with your static administrative IP address. This specific configuration redirects all public traffic to your static maintenance file while permitting your internal security team to access the site for analysis.

For Nginx environments, define a similar routing rule in your server configuration block:

error_page 503 @maintenance;
location / {
    return 503;
}
location @maintenance {
    rewrite ^(.*)$ /maintenance.html break;
}

If your web application is behind a reverse proxy or a Content Delivery Network (CDN) such as Cloudflare or AWS CloudFront, you can implement an Edge Page Rule or use Cloudflare's "Under Attack Mode." This serves a challenge page or a custom static maintenance template directly from edge servers, stopping traffic before it even communicates with your origin server.

Isolate the Compromised Server

If your website operates on a shared hosting environment, virtual private server (VPS), or a dedicated cloud instance, you must isolate the environment from the broader corporate network. Malware can spread horizontally (lateral movement) through connected systems, database servers, local area networks, or API connections.

In cloud environments such as Amazon Web Services (AWS), Microsoft Azure, or Google Cloud Platform (GCP), immediately modify the instance's Security Groups or Virtual Private Cloud (VPC) firewalls. Remove all inbound (ingress) rules allowing public HTTP (80) and HTTPS (443) traffic. Restrict egress rules to block the server from initiating outbound connections, which prevents installed malware from communicating with Command and Control (C2) servers to download further payloads or upload stolen database records.

If your setup utilizes SSH access or FTP/SFTP, disable these services temporarily or configure your firewall rules to accept connection requests strictly from virtual private network (VPN) tunnels or designated static administrative IP addresses.

Communicate with Your Hosting Provider and IT Team

During an active security breach, standard internal communication channels (such as corporate email systems hosted on the same infrastructure or linked to compromised active directory instances) may be monitored by the attacker. Implement an out-of-band communication channel (such as encrypted messaging applications or a separate, isolated corporate communication platform) to coordinate your response team.

Notify your hosting provider's technical support or security operations center (SOC) immediately. Managed hosting providers often maintain backup environments, baseline virtual machine snapshots, and hypervisor-level network monitoring logs. They can provide valuable details regarding anomalous bandwidth consumption, outbound spam mail flows, or unauthorized server management portal access. Furthermore, hosting companies can assist in taking disk snapshots of the infected machine for forensic analysis before you begin any manual cleanup attempts.

Revoke Access and Secure Infrastructure

Reset All Administrative Credentials

Once the server has been network-isolated, your next priority is terminating any current or future access vectors the attacker might use. This requires a comprehensive reset of all credentials associated with the website’s management, database layers, and hosting infrastructure.

Begin by changing passwords for every user database, administrative portal, and backend service. Your database credentials (typically stored in files like @@CODE0@@, @@CODE1@@, or database configuration scripts) must be regenerated with high-entropy, randomized 32-character strings. Attackers often target the database directly to extract customer information or plant rogue administrator profiles.

You must reset the credentials for:

• All Content Management System (CMS) Administrator Accounts: WordPress, Drupal, Joomla, Magento, or custom admin panel users.

• Control Panels: cPanel, Plesk, WHM, AWS Console, GCP Console, or Azure Portal.

• File Transfer Protocols: All FTP, SFTP, and SSH user accounts.

• Database Users: The primary database user, replication users, and administrative tools like phpMyAdmin.

• Domain Registrars: Your DNS manager (e.g., GoDaddy, Namecheap, Cloudflare), as DNS hijacking allows attackers to permanently redirect your domain.

Avoid reusing old passwords. Implement a password management system to enforce unique, complex credentials across all operational roles.

Terminate Active Sessions and API Keys

Simply updating a password does not automatically invalidate active session cookies or Jason Web Tokens (JWT) stored in a user's browser. If an attacker has hijacked a valid session, they can continue executing administrative actions even after a password change.

To force a global logout across all active accounts, you must clear your application's session caches. For standard PHP applications, this may involve deleting files in the designated session directory (e.g., /var/lib/php/sessions). For databases or caching layers like Redis and Memcached, execute commands to flush session keys.

If you are running WordPress, update the unique security salts in your wp-config.php file. You can retrieve a new set of randomized keys from the official WordPress salt generator API. Replacing these keys invalidates all logged-in cookies immediately, forcing every user (including the attacker) to re-authenticate:

define('AUTH_KEY',         'g-`{+S~z]uM.9Y=;SgR+;pE?_b}*mF#V_K4|L}XGgC|3&_T,B1pg_Y2_N_L_');
define('SECURE_AUTH_KEY',  'uB;g_F/1+V_Z=m_K8~P|Q_L_#]v+Gg_F*Y_L;z_K_M_P_Y_K_#_K_Y_L_V_');
define('LOGGED_IN_KEY',    'f_K_`{_M~v_J_Z_=_W_W_Y_L_Z_Y_Y_F_R_X_L_V_X_G_N_F_U_Z_K_P_');
define('NONCE_KEY',        'h_Z_M_Y_Y_P_N_W_X_X_R_F_Z_P_X_L_Z_Y_W_K_X_G_W_R_R_X_F_X_');

In addition to session keys, rotate all API keys, webhook secrets, and application tokens. If your website integrates with external services (such as ERP software, Stripe payment systems, Mailchimp, or Salesforce), a compromised API key can permit attackers to bypass the website entirely and query your connected cloud databases.

Quarantine Connected Third-Party Applications

In modern web development, websites rely on dozens of third-party plugins, themes, external SaaS integrations, and social login buttons. Security compromises frequently occur through these channels due to supply-chain vulnerabilities or compromised developer accounts.

Audit all connected apps, OAuth integrations, and external plugins. Temporarily revoke access permissions for all non-essential integrations. If a plugin has not been updated by its developer within the past six months, quarantine or uninstall it completely. Ensure that any remaining integrations run on the principle of least privilege, allowing them access only to the precise database tables or files required for their basic functions.

Investigate the Breach: Vulnerability Analysis

Analyze Server Access Logs and Error Logs

To prevent a recurring breach, you must identify how the attacker gained access. Without locating the entry point, any restore or cleanup attempt will be vulnerable to reinfection. Your primary tools for this investigation are the server's access logs and error logs.

Access logs record every HTTP request sent to your server. Error logs record server-level issues, such as database query failures, missing files, or PHP script crashes. Analyzing these logs helps establish a chronological timeline of the security incident.

For Linux-based Apache or Nginx servers, these logs are typically found in @@CODE0@@ or @@CODE1@@. You can use command-line utilities like @@CODE2@@, @@CODE3@@, and find to isolate suspicious traffic patterns.

For instance, search your access logs for requests containing common SQL injection signatures (such as @@CODE0@@, @@CODE1@@, CONCAT, or database schema names) or attempts to execute unauthorized commands:

grep -i "UNION" /var/log/nginx/access.log
grep -i "select" /var/log/nginx/access.log

Additionally, look for anomalous @@CODE0@@ requests sent to directories where only static content or uploads should reside. If a user uploads a @@CODE1@@ file to an /images/ directory and subsequently executes it via a direct browser request, the access log will record a line similar to:

192.168.1.50 - - [17/Aug/2026:14:22:10 +0000] "POST /uploads/2026/08/backdoor.php HTTP/1.1" 200 4501

A 200 success response code on a PHP file execution within an uploads directory indicates a highly probable malware injection vector.

Identify the Point of Entry (Malware, Brute Force, or Vulnerability)

Websites are generally compromised through one of four primary vectors:

1. Vulnerability Exploitation: Outdated software packages, themes, plugins, or core application components.

2. Brute Force Attacks: Repeated automated login attempts on administrator panels (e.g., @@CODE0@@, @@CODE1@@, /user/login).

3. Credential Stuffing/Phishing: Using leaked passwords from other breaches or stealing administrator credentials via social engineering.

4. Insecure Hosting Environment: Cross-site contamination on shared servers where one compromised tenant infects neighboring environments.

The table below outlines how to distinguish between these exploit vectors:

Audit Recent Core, Theme, and Plugin Modifications

If your website is built on a standard Content Management System, you can detect modified or added files by comparing your production file system against clean, official repositories.

For WordPress environments, the WP-CLI command-line tool is highly effective. If you have shell access to your server, run the following command to verify the integrity of the core WordPress installation:

wp core verify-checksums

This utility compares the SHA-1 hashes of your local files with the official hashes maintained by WordPress.org. Any modified, missing, or added core files will be flagged immediately.

If you maintain your website files inside a Git repository (which is highly recommended for corporate applications), run:

git status
git diff

This immediately displays every line of code modified, added, or deleted since your last verified deployment. Any unexpected PHP scripts or obfuscated javascript lines (such as blocks starting with eval(base64_decode(...))) are clear indicators of malicious payload placement.

Eradication and System Recovery

Avoid Blindly Restoring Infected Backups

A frequent and highly destructive mistake is immediately restoring the most recent backup file without verifying its integrity. Modern attackers often perform "sleeper" attacks, where they compromise a system and maintain access quietly for weeks or months before deploying active payloads (like ransomware or spam redirects).

If you restore a backup taken two days ago, and the site was actually compromised three weeks ago, you will restore the attacker's backdoors. The site will be hacked again almost instantly.

Analyze your log timelines and file modification dates to identify the exact date of intrusion. You must locate a secure backup archive created before the initial intrusion vector occurred.

Restore from a Verified, Secure Backup

Once you have identified a clean, uncompromised backup, prepare a completely fresh, isolated hosting environment. Do not simply extract the backup over your existing files. Overwriting files leaves any newly created malicious folders or backdoor files untouched in the directory structure.

The correct process for a secure file restoration involves:

1. Exporting current data: Back up your current, infected site state to an offline sandbox folder for forensic reference.

2. Complete Directory Eradication: Delete the entire directory structure of the compromised website (e.g., everything inside @@CODE0@@ or @@CODE1@@).

3. Database Drop: Drop all tables in the existing database.

4. Clean Installation: Provision a clean operating system or a clean CMS installation using the exact version number of your safe backup.

5. Backup Extraction: Extract your verified, clean backup files into the empty directory.

6. Database Import: Import your clean database backup file.

Verify that your file permissions are configured securely. On standard Linux web servers, directories should be set to @@CODE0@@ permissions, and files should be set to @@CODE1@@ permissions. Avoid granting write permissions (777) to any folder unless absolutely necessary for specific, isolated upload directories, which should be configured to block the execution of PHP scripts.

Patch the Identified Vulnerability Post-Restoration

Once your clean files are restored and online in an isolated testing environment, immediately patch the security gaps that allowed the initial entry.

Update your core software, active plugins, and themes to their latest secure releases. If the vulnerability was linked to an outdated server-level package (such as an old version of PHP, OpenSSL, or Apache/Nginx), coordinate with your system administrator or hosting provider to upgrade the server's operating system packages.

Review your php.ini configuration file and disable risky functions that allow system command execution. Add the following line to restrict what PHP scripts can do:

disable_functions = exec, passthru, shell_exec, system, proc_open, popen, curl_multi_exec, parse_ini_file, show_source, eval

This configuration prevents any undetected backdoors from executing shell commands or downloading payloads directly onto your server infrastructure.

Post-Incident Hardening: Preventing Future Attacks

Implement a Web Application Firewall (WAF)

With your website restored and patched, you must establish defensive controls to prevent future security compromises. A Web Application Firewall (WAF) acts as a gateway proxy, evaluating all incoming web requests and comparing them against a regularly updated database of known cyber threat patterns.

A cloud-based WAF (such as Cloudflare, AWS WAF, or Sucuri) sits between your users and your origin server. It filters out malicious traffic—including SQL injection, cross-site scripting (XSS), and automated bot scans—before it reaches your server.

[Incoming Public Traffic] ──> [Cloud WAF / CDN Edge] ──> [Filtered Clean Traffic] ──> [Your Origin Server]

Implementing a WAF reduces server load, shields administrative directories from brute force login attempts, and provides virtual patching capabilities. If a zero-day vulnerability is discovered in your CMS, a WAF can block exploits at the edge while your IT team prepares and tests a formal patch.

Enforce Strict Password Policies and MFA (Multi-Factor Authentication)

Insecure password practices remain a common entry point for enterprise intrusions. Implement a strict password policy across your entire organization, requiring a minimum of 16 characters, including alphanumeric characters and symbols.

Enforce Multi-Factor Authentication (MFA) on all administrative interfaces. MFA requires users to supply two or more verification factors to gain access, neutralizing standard credential-stuffing and brute-force attacks.

For corporate security, avoid SMS-based MFA. SMS messages are vulnerable to interception via SIM-swapping attacks. Instead, utilize Time-based One-Time Password (TOTP) applications (such as Google Authenticator, Microsoft Authenticator, or Duo Security) or physical hardware keys (such as YubiKeys) that utilize the FIDO2 standard.

Establish Continuous Malware Scanning and File Integrity Monitoring

Maintaining visibility over your file system is critical for prompt threat detection. File Integrity Monitoring (FIM) systems calculate cryptographic hashes of your server files and compare them continuously against a known baseline. If any core file or script is altered without authorization, the FIM raises an immediate security alert.

On Linux servers, open-source host-based intrusion detection systems (such as OSSEC or Samhain) can monitor directory changes in real time. For CMS environments, install trusted security suites (such as Wordfence or iThemes Security) configured to perform daily integrity scans of core files, themes, and plugins.

Additionally, configure automatic notifications for:

• The creation of new administrative users.

• Failed login attempt spikes exceeding established thresholds.

• Modified system configuration files (such as @@CODE0@@ or @@CODE1@@).

• Database schema changes or table creation.

Managing Search Engine and User Trust

Request a Review in Google Search Console

If your compromised website was detected distributing malware or executing redirects, Google may have flagged your site with a warning page reading "This site ahead contains harmful programs" or "The site ahead contains malware." This security warning discourages user visits, resulting in a sudden drop in your organic search traffic.

Once you have completely removed the malicious files, patched the underlying vulnerabilities, and verified that your site is clean, you must request a review from Google to remove the warning banner.

To do this, log in to your Google Search Console account:

1. Navigate to the Security & Manual Actions tab on the left-hand navigation panel.

2. Click on Security Issues.

3. Review the specific issues flagged by Google.

4. Click Request Review.

5. In the submission form, provide a detailed, technical explanation of the actions you took to resolve the security breach. Outline how you identified the entry point, how you sanitized the file system, and what defensive protocols you have implemented (such as activating a WAF and updating administrator passwords).

A typical request looks like this:

"Our security team identified a vulnerability in an outdated third-party plugin (version 1.4.2) that permitted unauthorized file uploads. We have taken the server offline, deleted all compromised files, restored the directory from a verified clean backup dating from August 10th, and updated all core systems. We have also updated database passwords, enforced MFA on all admin accounts, and implemented an active cloud-based WAF. A clean file signature check has been completed."

Google typically processes these security reviews within 24 to 72 hours. Once approved, the warning screen is removed, and your search indexation standing will begin to normalize.

Transparent Communication with Stakeholders and Users (If Data Was Compromised)

If your investigation reveals that customer data (such as personally identifiable information, credit card numbers, passwords, or email addresses) was compromised or exfiltrated, you have legal and regulatory responsibilities to report the breach.

Under regulations like the General Data Protection Regulation (GDPR) in the European Union or the Law on the Protection of Personal Data (KVKK) in Turkey, you are required to report data breaches to the relevant supervisory authorities within 72 hours of discovery. Failing to meet this window can result in significant regulatory fines.

Draft a transparent, honest communication to your users. Avoid downplaying the incident. Your notification should clearly state:

• What occurred: Explain the nature of the breach in clear, non-technical language.

• What information was affected: Specify the exact categories of data that were compromised (and clarify what was not compromised, such as encrypted payment cards).

• What actions you have taken: Detail the security upgrades you have implemented to secure the environment.

• What users should do: Advise users to change their account passwords and update any matching credentials on other platforms.

Honest, prompt communication is key to rebuilding brand equity, minimizing legal liability, and protecting user trust after an incident.