Finding malicious code on your site: a step-by-step check in cPanel
PrintTo find malicious code on a hosted website, start with the Imunify360 scan results in cPanel, then look for recently changed or out-of-place files, injected code in the database, extra users and scheduled tasks, and finally the access logs to see how the attacker got in. This article walks through each check. Removing code is only half the job: unless you also find the entry point, the infection comes back.
Before you start, download a copy of the site as it is now (files and database), even infected. Keep it apart from your clean backups; it may be needed to trace the cause.
1. Read what Imunify360 found
In cPanel, open Security, then Imunify360. You will see the files the server scan flagged, with their full paths and the date they were detected. The paths already tell you a lot:
- files inside a single plugin or theme folder point to that plugin or theme;
- PHP files in wp-content/uploads, images or cache folders are almost always planted;
- a long list of changed core files suggests the attacker had full write access (a stolen password, for example).
The scanner does not catch everything, so continue with the checks below even if the list is short. If you received a notice from us, see also what to do after an Imunify notice.
2. Look for files that changed recently
In File Manager you can sort a folder by the Last Modified column, but only one folder at a time. If SSH access or Terminal is available in your account (see connecting via SSH), one command lists all PHP files changed in the last 7 days:
find ~/public_html -type f -name "*.php" -mtime -7
Change 7 to the number of days since the problem appeared. Remember that an attacker can fake the modification date, so a file with an old date is not automatically clean.
3. Look for files that should not be there
- PHP files in folders meant only for images and uploads:
find ~/public_html/wp-content/uploads -type f -name "*.php"
- Files with random names (such as x7f3k.php), names that imitate system files (such as wp-tmp.php), or files with an image extension, such as .ico, that actually contain PHP code.
- Unexpected .htaccess files in subfolders, or rules in the main .htaccess that redirect visitors arriving from search engines or from phones. Such rules often check HTTP_REFERER or HTTP_USER_AGENT.
4. Look for hidden code in the files
Malicious code is usually obfuscated: long unreadable strings decoded and executed on the fly. This command lists the PHP files containing the most common patterns:
grep -rlE 'eval\(base64_decode|eval\(gzinflate|str_rot13\(|assert\(\$_(POST|GET|REQUEST)' ~/public_html --include='*.php'
Open each file from the list and look at the context. Some legitimate plugins use base64_decode for normal tasks; a line of several thousand characters at the very top of a file, before the original code, is a much stronger sign. Also look for script tags loading JavaScript from unknown domains in theme files such as header.php and footer.php.
5. Check the database
Code can also be stored in the database, not only in files. In cPanel, open phpMyAdmin, choose the site's database and use the Search tab to look for <script or for an unknown domain name in all tables. For WordPress, check in particular the tables ending in _posts and _options.
Then look at the users: in WordPress, open Users and filter by the Administrator role. Remove any administrator you did not create, after you have changed your own password.
6. Check the back doors in cPanel
- Cron Jobs (Advanced section): a task you do not recognise can download the malicious files again every few minutes.
- FTP Accounts (Files section): an extra FTP account gives the attacker a way back in.
- Forwarders (Email section): a hidden forwarder can copy your mail to an outside address.
7. Find the entry point in the logs
In cPanel, open Metrics, then Raw Access, and download the access log of the domain. Errors (also in Metrics) shows the latest server errors. In the access log, look for:
- POST requests to files that are not part of the normal site, or to the planted files you found;
- requests around the exact time a malicious file was created or modified. The IP address and the URL in those lines usually reveal the vulnerable plugin or form;
- many requests to wp-login.php or xmlrpc.php from the same addresses, a sign of password guessing.
If you work with a developer, send them these log lines: they show precisely which script was used.
8. For WordPress: compare the core with the original
WP Toolkit can check whether the WordPress core files match the official ones and reinstall them without touching your content. See checking and reinstalling the WordPress core.
After the check
- Remove the planted files and code, or restore a clean copy from before the infection with JetBackup 5.
- Close the entry point: update or remove the vulnerable plugin (vulnerability in a plugin or theme), change every password from a scanned computer.
- Follow the full recovery order in your website has been hacked: the first steps.
If you are not sure whether a file is safe to delete, send us its full path in a support ticket before removing it.
