Rogue Super Admin Accounts

What this check and mySites.guru tool looks at on your site

This check reads the Joomla user tables and looks for accounts a site compromise plants for persistence. An account is flagged when its identity matches one of two patterns. The first is a known attacker email or username: the throwaway addresses and usernames an attacker’s webshell stamps on the accounts it creates, currently the @secure.local domain, sysop@localhost.net and sysbackdoor@proton.me, with usernames such as admin_mori and sysbackdoor. No legitimate account is ever issued one of these. The second is a generated identity from a known campaign: one wave plants Super Users whose username is cms plus five random letters, reusing that same string as the email on a six-letter .net throwaway address, for example cmsargfp@tvmbfe.net. Every part of the pattern has to line up before it is flagged, so an account you genuinely named cmsadmin on your own domain is left alone.

The group an account sits in is not part of the test. These exploits ask Joomla for a Super User, but Joomla ignores the group an unauthenticated request asks for, so the planted account often ends up in the site’s default registration group instead. It is still the attacker’s, so this check resolves Super User by ACL permission (core.admin) rather than by group name, which also means a renamed or translated group is still read correctly.

Separately, a Super Administrator whose registration date is the invalid -0001-11-29 zero-date placeholder, but whose identity otherwise looks normal, is raised as a manual-review warning rather than a confirmed flag. That date is a soft tell of a planted account, but a legitimate admin created by hand or by script can carry it too, so these accounts are listed for a human to check and never marked as a hack on their own.

How attackers keep access after the hole is patched

A planted Super Administrator is how an attacker keeps access to a Joomla site after breaking in through a vulnerable extension. The clearest known example is the June 2026 SP Page Builder zero-day: com_sppagebuilder is one of the most widely installed page builders for Joomla, and its asset.uploadCustomIcon task allowed an unauthenticated arbitrary file upload, so an anonymous visitor could upload a PHP file into the site’s images tree and run it. The webshell that upload delivers creates a Super Administrator so the attacker keeps access even after the upload hole is patched, and drops a PHP File Manager backdoor in several innocuous locations so cleaning one copy leaves the others behind.

A fake Super Administrator carries the same fingerprint regardless of which extension let the attacker in:

Joomla user timestamps are stored in the site’s configured timezone rather than UTC, which is worth remembering when cross-referencing an account’s registration time against server access logs.

Every Super User accounted for

Every account holding Super User permission is one you can name, with a real email address your team controls, and a plausible registration and last-visit history. Nobody in your Super Users list is there through a machine-generated identity.

How to fix it

1. List everyone with Super User permission. In the administrator, go to Users, then Manage, and check the Group column, or run a query filtering on core.admin if you want to be certain a renamed group is not hiding an account.
2. Preserve evidence before deleting anything. Note the suspicious account’s details, since removing it removes the record.
3. Delete the rogue account and its dependent rows, its group mapping, profile fields and remember-me keys, so nothing is left behind for the account to re-authenticate with.
4. Find and remove the webshell. These attacks drop a PHP File Manager backdoor, often under images/<random>/fonts/ or as a lone users.php in media/. Deleting the admin account alone does not remove it.
5. Close the entry point. Update or remove the vulnerable extension. If SP Page Builder is installed, patch it first: see SP Page Builder Rogue Icon-Font Assets for the matching database-side check. Until the hole is closed, the site can be re-breached.
6. Rotate every secret. Change the Joomla administrator password, database credentials and any FTP/SSH access, since a webshell running as the web user could have read all of them. If you are working through this on a site that is already live and public, dealing with a hacked Joomla site covers the wider recovery process end to end.
7. Check the rest of your portfolio. This is automated, sprayed tooling. When one site is hit, others running the same vulnerable extension usually are too.

What mySites.guru does about it

On every snapshot, twice a day, mySites.guru reads the Joomla user tables against the signatures above and flags any account that matches, whichever group it sits in. We show you the account and why it was flagged, so you can verify it before removing anything.