Hacked site detection
Signatures and behaviours that only appear on a compromised site: rogue admin accounts, planted editor profiles, malicious cron jobs and injected template code.
34 checks in this group, 22 with a full write-up.
Evidence, not opinion
Everything else in this reference argues about risk: a setting is wrong, a header is missing, a version is behind. This group is different. Every check here exists because we have seen it on an actual compromise: a cron job an attacker planted to reinstall a backdoor after it gets cleaned up, a super admin account no one on the team created, template code that renders spam links only to Googlebot, a folder full of files with names chosen to look like core files but weighing in at a fraction of the size. These are not “this could go wrong” checks. They are “this already went wrong, and here is what it left behind” checks.
The newest checks in this group cover the half of a compromise that never touches a file at all: a WordPress scheduled event that rewrites deleted malware from the database, the settings rows a payload is kept in, the two folders WordPress loads PHP from without showing you, an administrator account filtered out of your own Users screen, a plugin whose declared author was invented alongside its vendor domain, and the Joomla scheduler that no crontab lists. None of those is a file, so no file scanner reaches any of them.
The difference shows most when you are running this across a portfolio rather than one site. A misconfiguration sits still until someone reads the audit. Evidence of compromise does not: an account with login access is being used, a cron job is running on schedule, and every day it goes unnoticed is a day an attacker keeps their foothold or widens it to a second and third site sharing the same hosting account. That urgency is why the account and cron checks in this group sit on the twice-daily snapshot rather than waiting for a scheduled audit: a rogue admin account or a planted cron job is live right now, and the fast checks that need no file scanning are the ones built to catch it quickly.
Across a large enough set of sites, hacks cluster rather than spreading evenly. A single vulnerable Joomla extension or WordPress plugin that happens to be popular with your client base can put several unrelated sites through the same compromise in the same week, planted by the same toolkit, leaving the same injected string in different clients’ files. Recognising that pattern once makes the next nineteen instances of it fast to confirm rather than another cold investigation.
A few of these checks are stated as certainties: a file matching a known-bad signature exactly, with no room for a false positive. Most are not. A suspicious pattern in a file, a cron entry that looks unfamiliar, a file that is technically core-adjacent but was never shipped: these need a human look before you act on them, and that is by design. Certainty checks tell you to act now. Everything else tells you where to look next. Both kinds involve scanning file contents rather than a quick lookup, which is why they run on the site’s audit schedule (weekly by default) rather than the twice-daily snapshot. Security audit tools for WordPress and Joomla covers how this fits alongside everything else mySites.guru checks.
Generic
Check Suspect Patterns Matched Content In Files
Matches file contents against our pattern library, deliberately casting a wide net, so entries here need a human to read them and judge.
Hacked Files (100% Certain)
Files confirmed compromised rather than merely suspicious: a hash match against a known hack, an attacker-only filename, or a live compromise found during the scan.
Check Files That Can Send An Email (or Mass Emails!)
Attackers commonly plant PHP mail relays and spam scripts after a hack; this lists every file containing the word mail so you can confirm each one is legitimate.
Check Files That Can Attempt To Upload Files
Flags files capable of accepting an uploaded file, worth investigating since that capability is how a hacker reinfects a site once the first backdoor is found.
Check For Malicious Cron Jobs
Find compromised sites: a scheduled cron job that re-drops a webshell or malware after files are cleaned
Processes Running Deleted Code
Find sites where a PHP process is still running code that has been deleted from disk, rewriting files after a clean
Joomla
Check for JCE Rogue Profiles & Backdoors
Find sites compromised through the JCE editor: rogue editor profiles, malicious profile imports and dropped webshells
Check Suspect Patterns Matched Content In Files
Matches file contents against our pattern library, deliberately casting a wide net, so entries here need a human to read them and judge.
Files confirmed compromised rather than merely suspicious: a hash match against a known hack, an attacker-only filename, or a live compromise found during the scan.
Find compromised sites: rogue accounts planted with a known attacker signature or a generated identity
Check Files That Can Send An Email (or Mass Emails!)
Flags files capable of sending email beyond the CMS's own core mailer, worth investigating since a compromised site spams using exactly this capability.
Check Files That Can Attempt To Upload Files
Flags files capable of accepting an uploaded file, worth investigating since that capability is how a hacker reinfects a site once the first backdoor is found.
Find compromised sites: template styles whose custom-code params carry a defacement or stealth-loader payload written via the Helix3 onAjaxHelix3 exploit
Check Files That Are Not Core Files
Lists every file that does not match the CMS's official core file set, which is normal for installed extensions but is also where an unnoticed upload would show up.
SP Page Builder Rogue Icon-Font Assets
Find compromised sites: rogue icon-font asset rows planted anonymously through the SP Page Builder asset.uploadCustomIcon exploit
Check Core Folders For Impostor Files
Flags files sitting inside folders Joomla's core owns outright, such as the root of /administrator/, where no genuine extension has any reason to add anything.
Find compromised sites: menu items whose Helix mega-menu params carry a stored-XSS / super-user-creation payload written via the unauthenticated saveMegaMenuSettings exploit
Unpatched JoomShaper Security Holes
Deploy JoomShaper's official Joomla 3 security patches to sites still running vulnerable, now-unsupported extensions (Helix Ultimate, SP Page Builder, Helix3)
Fixable in one click
Find compromised sites: a scheduled cron job that re-drops a webshell or malware after files are cleaned
Check For Malicious Scheduled Tasks
Find compromised sites: a task in Joomla's own scheduler that re-drops a webshell after files are cleaned
Processes Running Deleted Code
Find sites where a PHP process is still running code that has been deleted from disk, rewriting files after a clean
WordPress
Check Suspect Patterns Matched Content In Files
Scans file contents against our library of malware patterns, catching backdoors and injected code that a plain file listing would not reveal.
Hacked Files (100% Certain)
Files confirmed compromised rather than merely suspicious: a hash match against a known hack, an attacker-only filename, or a live compromise found during the scan.
Check Files That Can Send An Email (or Mass Emails!)
Flags files capable of sending email beyond the CMS's own core mailer, worth investigating since a compromised site spams using exactly this capability.
Check Files That Can Attempt To Upload Files
Flags files capable of accepting an uploaded file, worth investigating since that capability is how a hacker reinfects a site once the first backdoor is found.
Check Files That Are Not Core Files
Lists every file that does not match the CMS's official core file set, which is normal for installed extensions but is also where an unnoticed upload would show up.
Check Core WordPress Folders For Impostor Files
Recursively checks wp-admin and wp-includes for any file WordPress core never shipped, exactly where a shell dropped after a hack tries to hide.
Check For Malicious Cron Jobs
Find compromised sites: a scheduled cron job that re-drops a webshell or malware after files are cleaned
Check For Malicious WP-Cron Events
Find hacked sites: a WordPress scheduled event that rewrites malware from the database after the files are cleaned
Find the database rows a payload hides in: machine-named options and known malware families in wp_options
See the PHP WordPress loads on every request that cannot be deactivated from the Plugins screen
Rogue and Hidden Administrators
Find hacked sites: planted administrator accounts, and accounts the site's own Users screen does not show
Find plugins with an invented vendor identity, or with nothing in the folder but the payload
Processes Running Deleted Code
Find sites where a PHP process is still running code that has been deleted from disk, rewriting files after a clean
Find out which of these your sites fail
Connect a site and every check in this group runs against it automatically, with the result and the fix in one place. The quick checks here run twice a day; the deeper file scans run with the full audit, which most sites schedule weekly.
Run a free audit