Proudly Canadian 
One of the most unsettling aspects of a website compromise is how long it can go undetected. Attackers frequently design their malware to be invisible to the site owner while actively exploiting the site for purposes that damage your business, your visitors, and your reputation. Your site may look completely normal when you browse it. Meanwhile, visitors arriving from search engines are being redirected to spam sites, your server is sending thousands of phishing emails, or your site is being used to distribute malware to your visitors.
Knowing what to look for and where to look changes this situation. Most compromises leave identifiable traces across multiple places: your file system, your server logs, your database, your search engine presence, and your hosting account behaviour. This guide covers all of them.
Quick Summary
- Many hacks are designed to be invisible to the owner while actively harming visitors and your server reputation
- Check your site from outside your own network, in incognito mode, and on mobile to see what visitors actually experience
- Google Search Console and external scanning tools often detect compromises before the owner does
- Look for signs across your file system, database, server logs, and email activity simultaneously
- Identifying the entry point before cleaning is essential to prevent immediate reinfection
Why Hacks Often Go Unnoticed
A site owner browsing their own website sees a fundamentally different experience than many of their visitors do, and attackers exploit this gap deliberately. The most sophisticated malicious redirects are conditional: they trigger only when a visitor arrives from a search engine, or only on mobile devices, or only for visitors who have not previously visited the site. When you type your URL directly into your browser on your desktop, you bypass all of these conditions and see your normal site. Your visitors searching for your business on Google are redirected to a pharmacy spam site or a phishing page.
Server-side exploits like spam sending scripts and cryptocurrency mining run entirely in the background. They do not affect the visible content of your site at all. The only signs are elevated server resource usage and your server IP appearing on email blacklists, both of which you would not notice without actively monitoring.
This invisibility by design means that waiting to notice something wrong is not a reliable detection strategy. Regular proactive scanning and monitoring is the only way to catch a compromise early.
Visible Signs Visitors or Google Will Notice
Browser security warnings
Chrome, Firefox, and Safari all display full-page warning screens when Google's Safe Browsing database has flagged your site as distributing malware or hosting phishing content. If visitors are reporting that they cannot access your site or are seeing a red warning screen, this is a high-confidence indicator of a confirmed compromise. Google does not flag sites based on suspicious activity alone. A warning from Safe Browsing means Google has already identified and verified malicious content on your site.
Redirects to unrelated websites
If any visitors report being redirected to a different site when they click on your link from a search result, or if you test your site from a mobile device and are taken to a spam site, you have a redirect injection. The redirect may be in your .htaccess file, in a PHP file in your theme or plugins directory, in your database, or injected as JavaScript into your page HTML. Test your site by searching for it on Google and clicking the result rather than typing the URL directly. Also test from a mobile browser and from a fresh incognito window on a network you have not visited the site from before.
Spam content in Google search results
Search for your domain in Google using the query site:yourdomain.com. If the results show pages you did not create, pages with pharmaceutical spam, gambling content, or foreign language text you do not recognize, your site has been used for SEO spam injection. Attackers create hidden pages indexed by Google to hijack your site's domain authority for their own spam content. These pages are usually hidden from regular visitors but visible in search results.
Google Search Console security alerts
Google Search Console sends notifications when it detects security issues on your site. If you have Search Console set up for your domain, check the Security Issues section in the left menu. If you do not have Search Console set up, this is the moment to do it. Verification takes a few minutes and it is one of the most reliable early warning systems available.
Signs in Your Hosting Account and File System
Unexplained resource usage spikes
A sudden sustained increase in CPU or memory usage with no corresponding increase in traffic is one of the most reliable indicators of a background script running on your server. Log into cPanel and check the Resource Usage section. If CPU usage is consistently elevated and your site traffic has not changed, something is consuming processing power that is not your site code. Common causes are spam-sending PHP scripts, cryptocurrency miners, and scripts participating in distributed attacks.
Unfamiliar files in your file system
Access your file manager through cPanel or connect via FTP and look through your public_html directory. Attackers typically drop PHP scripts with random or innocuous-looking filenames into your web root, your WordPress uploads folder, and inside plugin directories. Files named things like wp-feed.php, cache.php, log.php, or files with long random strings of characters are common malware script names. A file modification date that is recent and does not correspond to any update you performed is worth examining.
To find recently modified files from cPanel's file manager, sort by date modified. You can also use SSH to find recently changed files:
find /home/username/public_html -name "*.php" -mtime -14 -ls
This lists all PHP files modified in the last 14 days. Any files you do not recognize should be examined. Open them and look for obfuscated code patterns: base64-encoded strings, the eval() function, or heavily compressed single-line code blocks are common indicators of malicious scripts.
Modifications to core files
WordPress core files like wp-login.php, wp-includes files, and wp-config.php should not be modified under normal operation. If these files show a recent modification date that does not correspond to a WordPress update you performed, they may contain injected code. Compare the checksum of your WordPress core files against the official WordPress version using a plugin like Wordfence or by downloading a fresh copy of the same WordPress version and comparing files.
Changes to .htaccess
The .htaccess file in your web root is a common target for redirect injections. Open it and review the content. A clean WordPress .htaccess contains only a small block of rewrite rules for WordPress permalinks. Any additional rules, particularly ones involving RewriteCond rules that check for user agents, referrers, or mobile devices, are likely malicious. Also check for .htaccess files that may have been created inside subdirectories, since attackers sometimes place them there to control specific parts of your site.
Unknown administrator accounts
In WordPress, go to Users and check the list of accounts with Administrator role. Any account you did not create should be treated as a sign of compromise. Attackers create backdoor admin accounts to maintain access even after a malware scan removes the injected files. Similarly, check your cPanel account for any additional FTP accounts, email accounts, or subdomains you did not create.
Database changes
In WordPress, malware is frequently injected into the database rather than, or in addition to, files. Access phpMyAdmin from cPanel and examine your WordPress database. Look at the wp_options table and search for any entries containing base64 strings, JavaScript code, or URLs to external domains in values where you would not expect them. Check the wp_users table for unfamiliar accounts. The wp_posts table may contain hidden pages or posts with spam content that are not visible in your WordPress admin but are indexed by search engines.
Signs in Your Server and Email Activity
Exim mail queue building up
A mail queue with hundreds or thousands of messages is a strong indicator that a script is using your server to send spam. In cPanel, navigate to Email and open the Mail Queue Manager. If the queue is large, look at the From addresses and message content to confirm whether the traffic is legitimate or spam. Our article on fixing a stuck Exim mail queue covers this investigation in detail, but the presence of a large queue is itself a diagnostic signal worth noting here.
Your server IP on blacklists
If your server's IP address has been listed on email blacklists, it is often because spam has been sent from the server. Check your IP using MXToolbox Blacklist Check. Being listed on blacklists does not itself prove your site is compromised, since you may be on shared hosting where another account caused the listing, but it is a trigger for investigation.
Access logs showing unusual patterns
Access logs in cPanel under Metrics show every request made to your server. Look for POST requests to PHP files in directories where you would not expect them, repeated requests to wp-login.php from a single IP or a range of IPs indicating a brute force attack, requests to non-existent files that may indicate an attacker probing for vulnerabilities, and requests at unusual times or from unusual geographic sources. Raw access logs can be overwhelming for busy sites, but filtering for POST requests and for 200-status responses to files in the uploads directory are two filters that reveal suspicious patterns quickly.
Using Scanning Tools
Manual investigation is thorough but time-consuming. Scanning tools can cover the most common malware signatures quickly and flag areas that need closer inspection.
Wordfence is the most widely used WordPress security plugin and includes a file scanner that compares your WordPress core files, themes, and plugins against known clean versions. It flags files that have been modified, files that do not belong to any installed plugin or theme, and files that match known malware signatures. Run a full scan and review every flagged item. Wordfence will indicate whether each flagged file is a core file modification, an unknown file, or a known malware match.
Sucuri SiteCheck at sitecheck.sucuri.net provides an external scan of your publicly accessible pages, checking for malicious code in your HTML output, checking against known blacklists, and flagging suspicious redirect behaviour. Because it scans from outside your server rather than from within, it catches things that file-level scanners miss, particularly injected content that only appears to certain visitors.
Google Safe Browsing's transparency report at transparencyreport.google.com/safe-browsing/search shows whether Google currently has your domain flagged. If you have not already received a Search Console notification, checking here confirms whether Google considers your site safe.
From cPanel, the Virus Scanner tool under Security performs a server-level file scan. For WordPress sites specifically, it is less thorough than Wordfence but is the appropriate tool if you are not running WordPress or if you want a second opinion at the server level.
What to Do Immediately After Confirming a Compromise
Once you have confirmed your site has been compromised, the sequence of your response matters. Acting in the wrong order can destroy evidence, allow the attacker continued access, or result in rapid reinfection.
First, take the site offline if possible to prevent your site from continuing to harm visitors or distribute malware. In cPanel this can be done by creating a password-protected directory or by temporarily redirecting all traffic to a maintenance page. Continuing to serve a compromised site while you clean it allows more visitors to be exposed and may extend your time on blacklists.
Second, change all passwords before doing anything else. This includes your cPanel password, your FTP password, your WordPress admin password, and your database password. If the attacker still has valid credentials, any cleaning work you do can be immediately undone. Do not reuse any previous passwords.
Third, preserve the current file system state before making changes. Download a copy of your current public_html directory and database before cleaning. This preserves evidence for investigating how the attacker got in and allows you to compare the compromised state against a clean state to identify every changed or added file.
Fourth, identify the entry point before restoring or cleaning. The most common entry points are outdated WordPress core, plugins, or themes with known vulnerabilities, compromised credentials obtained through brute force or credential stuffing, and server-level vulnerabilities. If you restore from a backup without fixing the entry point, the attacker will return, often within hours. Check the access logs for the IP addresses that were active around the time of the initial compromise.
Contact your hosting provider. Our support team can review server logs, check for malicious processes running at the system level, and assist with investigation that goes beyond what is accessible from within cPanel alone. Open a ticket from your WHMCS client area with your domain name and a description of what you have found.
Preventing Reinfection After Cleaning
Cleaning a compromised site is only effective if the conditions that allowed the compromise are also addressed. The most important steps after cleaning are updating everything, including WordPress core, all plugins, and all themes to their current versions, since the exploit that allowed entry was most likely a known vulnerability in an outdated component. Remove any plugins or themes that are no longer maintained and have no current update available.
Change all passwords again after cleaning, not just after the initial discovery. Regenerate your WordPress secret keys and salts by replacing the constants in wp-config.php with new values from the WordPress secret key generator at api.wordpress.org/secret-key/1.1/salt. This invalidates any existing sessions including those that may belong to the attacker.
Review and harden file permissions. Web-writable directories that do not need to be writable should be set to 755. PHP files should be 644. The wp-config.php file should be 440 or 400. Restrict PHP execution in the uploads directory by adding a .htaccess file there containing:
deny from all
<Files ~ "\.(jpg|jpeg|png|gif|webp|svg|ico|css|js)$">
allow from all
</Files>
This prevents PHP files in the uploads directory from being executed by the web server, which is one of the most common paths for re-uploading malware shells after a site has been cleaned.
Install a security plugin like Wordfence if you are not already using one, and enable its firewall and login protection features. Set up Google Search Console if you have not already to receive early warnings of future issues. Consider enabling two-factor authentication on your WordPress admin account and cPanel account.
Gotekky
Need help deciding what to do next?
Tell us what you are seeing and what outcome you need. We will identify whether a managed service, scoped project or paid technical assessment is the right next step.