Skip to main content
mySites.guru
New features added last monthRelease RadarFile ManagerImpostor FilesUpdate QueueRogue AdminsMCP & APIJoomla VELCVE Index

Rogue and Hidden Administrators

Rogue and Hidden Administrators

A planted WordPress administrator can be filtered out of your own Users screen. Reading the user tables twice, and reporting when the two answers disagree.

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

This check reads your administrator accounts twice, from two different places, and reports both what it found and whether the two answers agree.

Straight from the database

The account list, and the roles attached to it, read with a plain query against wp_users and wp_usermeta. This is the answer to trust and the list you see.

Through WordPress itself

The same question asked the way your own Users screen asks it.

An account is reported as rogue when its username and email follow a pattern a known attack campaign generates: a role word followed by a run of hexadecimal characters, along with the rest of that campaign’s fingerprint. The rule does not fire on an ordinary account with digits in the name, so your own backup_20260913 is safe.

An administrator with no valid registration date is reported separately as worth a look. That means the row was written straight into the database rather than created through WordPress, which a migration or a command-line import does too. mySites.guru never offers to delete one of those, and they never mark a site as hacked.

The disagreement between the two readings is itself a finding

WordPress lets any plugin rewrite the answer to “who are the users on this site”, and on a site that has been broken into the attacker’s code is loaded and running inside the same request. So when the database holds more administrators than WordPress admits to, something is filtering the list, which is how a planted account stays invisible on the screen you would check. We hold the database answer, so we can see what your own Users screen may not.

Only that one direction counts as hidden. WordPress reporting more administrators than the database holds is a real disagreement too, but it is not a concealed account, because a plugin granting admin rights without a database role produces the same mismatch. That case is reported as information.

What the comparison cannot see

An attacker who leaves the account list alone and instead changes how the Users screen draws itself. Both numbers come out the same and the account is still missing from your screen.

That is why the username check matters independently of the disagreement. On the site this family was pulled apart on, the planted administrator was found by its name and not by any count mismatch: the filter it installed rewrites the links above the Users table and does not touch the user query at all. Neither check covers the other, so read both.

What a planted administrator tells you about the break-in

Someone already had enough access to write to your database before that account existed, and they did not stop there. The account exists so that the attacker keeps access after you close the hole they came in through: with a valid login they need neither the original vulnerability nor a webshell, so one cleanup becomes the next one.

On the compromise this check was built from, four such accounts could be accounted for across five months. Two had already been deleted by the time anyone looked, one was in the backup, and one was created after the backup was taken.

Every administrator accounted for

Every account holding administrator rights is one you can name, with a real email address your team controls and a plausible registration history. The number mySites.guru reads from your database matches the number WordPress reports, and it matches what you see on your own Users screen.

How to fix it

  1. Delete the accounts, then keep going. Deleting them closes that particular door and nothing else. Whatever created them can create more.
  2. Change the passwords on every remaining administrator, and force everyone to sign in again by rotating the authentication salts in wp-config.php.
  3. Run a full audit and work through every file it flags, then check your scheduled events and your must-use plugins and drop-ins. This family plants all three.
  4. Compare our list against your own Users screen. If mySites.guru can see an account you cannot, that difference tells you something is still running on the site.
  5. Check the rest of your portfolio. One search finds that user on every site you manage, which is the fastest way to find out how far a campaign reached.

What mySites.guru does about it

On every snapshot, twice a day, mySites.guru reads your user tables directly and compares that answer with WordPress’s own. A rogue account marks the site as hacked and appears in the red card.

Accounts can be deleted from the tool. Their content is reassigned to an administrator who stays, and the delete will not run if removing them would leave the site with no one holding the keys. It also skips the account you are signed in as, re-checks each account against a fresh read before removing it, and caps a batch so a single mistake cannot empty your user table.

On a multisite network administrator rights are held per site and mySites.guru reads the one you registered. The delete will not run on a network at all: removing a user there behaves differently and belongs to a network administrator who can see the whole picture.

Rogue and Hidden Administrators

mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.

Further Reading

Frequently Asked Questions

Can a WordPress administrator account be hidden from the Users screen?
Yes. WordPress lets any plugin rewrite the answer to who the users on a site are, so malware running inside your site can filter its own account out of the list. The account sits perfectly visibly in the database the whole time. That is why this check reads the user tables directly and then compares that answer against the one WordPress gives, because the disagreement between the two is itself a finding.
What makes an account rogue rather than just unfamiliar?
Its username and email follow a shape a known attack campaign generates, such as a role word followed by a run of hexadecimal characters together with the rest of that campaign's fingerprint. The rule does not fire on an ordinary account with digits in the name, so an account you called backup_20260913 yourself is safe.
My administrator has no registration date. Is that a hack?
Not on its own, and it is reported separately for exactly that reason. A missing or invalid registration date means the row was written straight into the database rather than created through WordPress, which a migration or a command-line import does too. Those accounts are listed for review, they never mark a site as hacked, and mySites.guru never offers to delete one.
Should I just change the admin password instead?
It is necessary and nowhere near sufficient. A rogue administrator account is the aftermath rather than the warning: someone already had enough access to create it. Deleting the account closes that one door and nothing else, so you also need to find what created it, rotate every remaining administrator password, and force everyone to sign in again.
EU icon: AI MODIFIEDWritten and edited by a human, with AI assistance. Our approach to AI

What our users say

Michael Sønderup Nielsen
Michael Sønderup NielsenJoomla Consultant, Joomlakonsulenten
★★★★★

I have been a mySites.guru customer since February 2014, and I now look after more than a hundred Joomla sites through it. Twelve years on, it is still the first place I look whenever something feels off. What makes it work is not just the scanning. It is the judgement built into it. The vulnerable extension alerts do not simply say "update this". They explain what the flaw actually does, whether an attacker needs to log in first, and exactly which version closes it. That is what cracked a case for me recently. The platform pointed out that a critical plugin on a client site was a hidden dependency, installed automatically in the background by another extension. The client had never chosen it and had no idea it was there. Nothing else I use would have told me that. The tools show the same care. Separating "100% certain hacked" from "suspect patterns" is exactly the right distinction, and it stops you frightening a client with a number that turns out to be ordinary software. The "executables only" filter on the core folder check took a list of 250 files down to 13 in a single click. And being able to read a file in the built-in editor before deleting it is a small thing that matters enormously. Then there is Phil. Sharp, quick to respond, and still clearly invested in the details after all these years. That combination is rare. Thank you, Phil. Genuinely.

Read more reviews
Mikael A - Webbkompass AB
Mikael A - Webbkompass ABwebbkompass.se
★★★★★

This site / program is just super.

Read more reviews

Read all 282 reviews →

See where your own sites stand

This check, and every other one, run automatically on a free audit. No credit card required.

Get Your Free Site Audit