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.
25 checks in this group, 13 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 nobody 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.
That distinction matters more than it sounds like it should 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
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
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
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