5 Signs Your Website Was Hacked — And What to Do in the Next 24 Hours

A compromised website is not always obvious. Attackers who want to maintain long-term access — to send spam, host phishing pages, or mine cryptocurrency using your server — have every incentive to stay invisible. You may be serving malware to your visitors right now with no visible indication on the surface. These five signs cut through the noise.

Sign 1: Unknown Admin Accounts Appeared

Log into your CMS (WordPress, Drupal, Joomla) and audit the user list. If you see administrator accounts you did not create — with generic names like "admin2", "support_user", or random strings — your site is almost certainly compromised. Attackers create backdoor admin accounts to maintain access even after you change your own password.

The same applies to your hosting control panel. Check cPanel, Plesk, or your server's SSH authorized_keys file for entries you do not recognise. Attackers with server access often add their own SSH keys to ensure re-entry regardless of what passwords you reset.

What to do now: do not delete the rogue accounts immediately — first document them (screenshot usernames, email addresses, registration timestamps). This forensic evidence helps trace the attack vector. Then disable the accounts, change all legitimate admin passwords to 20+ character random strings, and enable multi-factor authentication on every privileged account.

Sign 2: Google Is Warning Visitors About Your Site

Google Safe Browsing scans billions of web pages for malware and phishing content. When it detects a threat on your domain, it displays a full-screen red warning to anyone trying to visit your site in Chrome, Firefox, or Safari. If your organic traffic has collapsed overnight, check Google Search Console immediately — the Security Issues section will show exactly what Google found and when.

A blacklisting like this is not just a traffic problem: it signals that your site was actively distributing malware or hosting phishing pages targeting your visitors' credentials. Recovery after a Google blacklisting requires removing all malicious content, submitting a reconsideration request, and typically waiting 1–3 days for Google to re-scan and lift the warning.

Quick check: search Google for site:yourdomain.com. If your pages appear with descriptions you did not write — pharmaceutical spam, adult content, or foreign language text — attackers have injected SEO spam into your pages to hijack your domain's authority for their own schemes.

Sign 3: Visitors Are Being Redirected Without Your Doing

This is one of the most common and damaging hacks: a piece of malicious JavaScript or a server-side redirect rule sends your visitors to a third-party site — typically a phishing page, a fake pharmacy, or a malware download. The insidious detail is that the redirect often targets only mobile users or first-time visitors, so the site owner checking on a desktop browser sees nothing wrong.

Test your site from an incognito window on a mobile device, or use a tool like Google's Mobile-Friendly Test or Redirect Detective to trace the full redirect chain. Also check your .htaccess file and your theme's functions.php (for WordPress) for injected redirect rules — these are common hiding spots.

Also check: your DNS records. Attackers who gain access to your domain registrar account can modify DNS settings to redirect your entire domain at the infrastructure level. Log into your registrar (Namecheap, GoDaddy, OVH) and verify that your A records, CNAME records, and MX records match what you configured.

Sign 4: Your Server Resources Are Spiking Unexpectedly

Unexplained spikes in CPU usage, memory consumption, or outbound bandwidth are classic indicators of a compromised server being used for purposes beyond your website. The most common culprits in 2026: cryptocurrency mining scripts (cryptojacking), bulk email spam delivery, and participation in a DDoS botnet as a command node.

Check your hosting control panel's resource usage graphs for the past 30 days. Look for sustained CPU spikes that do not correlate with traffic increases. On a Linux server you have SSH access to, run top or ps aux --sort=-%cpu to identify processes consuming abnormal resources. A process with a random name running as your web server user is a red flag.

Also check outbound connections: run netstat -tulpn to see which processes are establishing outbound connections and to which IP addresses. Connections to mining pool addresses or known command-and-control servers confirm the compromise.

Sign 5: Strange Files or Code Appeared in Your Codebase

Web shells are the attacker's remote control: a PHP, ASP, or Python file placed in your web root that allows the attacker to execute commands on your server through a browser. They are often disguised as legitimate files — names like wp-config-backup.php, xmlrpc2.php, or files with random alphanumeric names inside your uploads directory.

Run a file modification audit: compare your current file tree against a known-good baseline using a tool like AIDE or Tripwire, or simply check which files were modified in the last 7–30 days with find /var/www -name "*.php" -newer /var/www/index.php -ls. Any PHP file in your uploads directory is almost certainly malicious — legitimate file upload configurations should never allow executable scripts.

Injected code in legitimate files: attackers also insert obfuscated malicious code into your existing theme files, plugin files, and core CMS files. Look for base64-encoded strings, eval() calls, or gzinflate(base64_decode(...)) patterns — these are the fingerprints of injected PHP malware.

Your 24-Hour Response Plan

1. 01

   Hours 0–2: Contain the damage

   Put the site in maintenance mode or take it offline entirely. Change all credentials immediately: hosting panel, CMS admin, FTP, database, domain registrar. Revoke all active sessions. Every minute the attacker retains access is another minute they can deepen the compromise or exfiltrate data.

2. 02

   Hours 2–6: Forensic analysis

   Review server access logs to identify the attack vector — when did the attacker first appear? Which URL did they access? What file did they upload or modify? Preserve logs before they rotate. Identify all malicious files and injected code. Do not clean yet — document first.

3. 03

   Hours 6–16: Clean and restore

   Restore from a clean backup predating the compromise — if one exists. If not, manually remove all malicious files and sanitise injected code. Reinstall core CMS files from official sources. Update every plugin, theme, and dependency to the latest version.

4. 04

   Hours 16–24: Harden and monitor

   Implement a web application firewall (WAF), set up file integrity monitoring, enable two-factor authentication across all accounts, and configure automated daily backups to an offsite location. Submit a Google reconsideration request if your domain was blacklisted. Notify affected users if personal data may have been exposed — this is a legal requirement under GDPR.

FAQ