Sooner or later every site owner, hosting support engineer and incident responder has the same moment: you open Users → All Users — or query wp_users directly — and there is an administrator you cannot place. adminbackup. sys_maint. editor_1fb66a. Someone called kevin_vauls who has never worked for the company. The first question is always the same: is this bad?
This article is the reference I wish existed every time that question lands on my desk. It is built from two sources: aggregate data from hundreds of real malware-removal investigations I have worked on (every name below was found as an attacker-created account in at least one confirmed compromise, with all client-identifying details removed), and public incident research that independently documents many of the same names. Over 100 usernames, grouped by the pattern they follow, each marked with how much evidence sits behind it.
One thing before the lists, because it matters more than the lists: a username is a lead, not a verdict. None of these names is malicious by itself, and a legitimate colleague can own an account with an unlucky name. The goal is to tell you which accounts deserve the fifteen minutes of verification described at the end — registration date, email, capabilities, creator code — before anyone deletes anything.
🎯 Two different lists: names attackers try vs. names attackers create
Most "worst WordPress usernames" posts mix up two unrelated things, so let's separate them first.
- Names brute-force bots try to log in with. Login floods overwhelmingly target names that might already exist:
admin,Admin,administrator,test,root, single letters, and the site's own domain name without the TLD. Security vendors have published this list for years, and a 2013 botnet campaign targeted the usernameadminacross tens of thousands of sites. If your admin account uses one of these names, you are simply absorbing more password-guessing traffic than you need to. - Names attackers create once they are in. This is the subject of this article. An attacker with code execution, a plugin exploit or stolen credentials does not guess accounts — they insert one. Those names follow completely different patterns, because they are chosen to survive a casual glance at the user list: they imitate maintenance tooling, misspell "admin", borrow a human name, or come out of a random generator.
Finding a name from the first list in your user table is a hygiene issue. Finding one from the second list — an account nobody claims — is an incident until proven otherwise.
🚪 Where rogue admins come from
Every account in this article appeared in one of a handful of ways, all well documented in public research and all things I see weekly in cleanups:
- Plugin vulnerabilities that create users directly. The WP‑Automatic SQL injection (CVE‑2024‑27956) was used to insert admins with usernames starting with
xtw; the LiteSpeed Cache flaw CVE‑2023‑40000 planted admins namedwpsupp-userandwp-configuser; the OttoKit/SureTriggers authorization bypass (CVE‑2025‑3102) allowed unauthenticated admin creation within hours of disclosure. - Backdoor code that recreates the account on every page load — a snippet appended to a theme's
functions.php, a must-use plugin, or a fake plugin such as the "WP Compatibility Patch" (wp-compat) that createdadminbackup, or "DebugMaster Pro", which created an admin namedhelp. I analysed one of these recreation loops in detail in Phantom Admin: the backdoor that hides users and rebuilds itself from the database. - Direct database inserts via SQL injection, a planted database client, or stolen DB credentials — no WordPress API involved, so nothing is logged and
user_registeredis whatever the attacker chose to write. - Stored-XSS payloads that run in a real admin's browser and silently add an administrator, as in the October 2026 campaign against two popular plugins where the new account was also hidden from the Users screen.
- Site-builder and SFTP-level access — attacker-created file transfer or panel users that are then used to plant the WordPress-level account.
🔬 How to read the lists
Each name carries an evidence grade:
| Grade | Meaning |
|---|---|
| A — corroborated | Attacker-created in my own casework and independently documented in public incident research |
| B — repeated | Attacker-created in two or more unrelated incidents in my casework |
| C — observed | Attacker-created in one confirmed incident in my casework |
| P — public | Documented in public incident research; not (yet) seen in my own cases |
Names derived from the victim site itself (the site's brand or domain as a username) are a real and common pattern — publicly documented for one large campaign that generated admins from the hostname — but the literal examples from my cases would identify clients, so that pattern is described rather than listed.
💾 Family 1: the "backup" pretext
The single most successful disguise in my data. "Backup" sounds like something an agency or a plugin would legitimately leave behind, so these survive user-list reviews for months. The star of the family, adminbackup, was created by the fake wp-compat plugin together with the email adminbackup@wordpress.org — I took one of these infections apart in the wp-compat analysis, and public research documents the same account name, fake plugin and email verbatim.
| Username | Grade | Notes from the field |
|---|---|---|
| adminbackup | A | 8 unrelated incidents; email adminbackup@wordpress.org; recreated by fake plugin on every load |
| adminbackup<hex6> | B | Same family with a random suffix: adminbackup5525ef, adminbackup9fdc1c, adminbackupd43b5f, adminbackup79c2f2, adminbackupc094ad, adminbackupf03d1e, adminbackup9b7b8d, adminbackupf47df6 all observed |
| seobackup | B | 7 unrelated incidents, usually alongside SEO-spam injections |
| admin_backup · admin2backup · adminbockup | B | Variants, including the misspelling adminbockup seen in two incidents |
| backupadmin · backupsystem · wp-backup · wpbackupbb | B/C | backupsystem and wp-backup each in two unrelated incidents |
| backup_manager · backup_auth · bk_service<digits> · backup_<hex> · backup-<unixtime> | C | Generated variants; the Unix-timestamp suffix (e.g. backup-1740742128) is a giveaway — no human names an account that way |
⚙️ Family 2: the "system service" pretext
These pretend to be something the platform itself needs: a maintenance daemon, a cache manager, an API integration. sys_maint is the flagship — in my incidents it was recreated by code appended to every theme's functions.php, and public case studies document the identical name and mechanism, plus the variant sys_maint_service.
| Username | Grade | Notes from the field |
|---|---|---|
| sys_maint | A | 7 unrelated incidents; often paired with email sys@localhost.local; recreates on page load |
| sys_maintenance · sys_users · sys_<hex8> · system<hex8> | B/C | Generated siblings: sys_5187da24, sys_cd4e8cdb, system8e175df8 and more |
| system_manager · sysmgr · wp-system · wp_management | C | Plausible-sounding "platform" accounts that no stack actually creates |
| cache_manager_wp · wp_cache_mgr · cache_sync | C | The "caching" disguise extends to usernames, not just fake plugins |
| sync_agent<n> · mail_daemon<n> · log_agent<n> · form_agent<n> · toolkit-service | C | Unix-daemon cosplay; WordPress has no such accounts, ever |
| uapi · woocommerceapi · wc-analytics · developer_api1 · webuser · analytics | B/C | Fake "integration" users; webuser and analytics each in two unrelated incidents |
| sec_audit · sec_monitor<n> · wpsecurity | C | The boldest disguise: the intruder pretending to be the security team |
| wpsvc_<digits> · wpcron<hex> · wp_update-<unixtime> · seo_<unixtime> | B/C | wp_update-1711373523 appeared in two incidents — the "name" is literally the moment the exploit ran |
🎭 Family 3: admin lookalikes and typos
Designed to be skimmed past in a user list. The leetspeak variant admln (lowercase L for i) and its sibling admlnlx appeared in five and six unrelated incidents respectively, and admlnlx is independently documented by a European cleanup provider alongside adminbackup and one_images_user.
| Username | Grade | Notes from the field |
|---|---|---|
| admlnlx · admln | A / B | 6 and 5 unrelated incidents; an l standing in for the i survives a surprising number of reviews |
| wadminw · abmin · adminJCeN · admin-wp | B | Each in 2–3 unrelated incidents; adminJCeN keeps its random suffix across victims |
| adminn · admini · adm1n · admin-su · adminML · administratoir · admidbsnn | C | One confirmed incident each; the half-typed-looking admidbsnn class also shows up as admkxtwnr-style consonant mash |
| wp-adminn · wp-admnin · wp-admnn · wp_administrator | C | The wp- prefix plus a typo — imitating a platform account that does not exist |
| zadmin · lyadmin · huadmin · wphadm | C | Short prefix + admin; sorts next to the real account in an alphabetical list |
| admin_<hex> | B | Observed as admin_600af85c, admin_cfa211459c, admin_11a63458fa; one variant was generated by a large multi-site malware framework |
🎲 Family 4: generated role names — role_<hex> and timestamps
When a kit creates accounts in bulk it concatenates a role word with a random suffix. The role word buys plausibility, the suffix buys uniqueness. If you ever see two of these on one site, you are almost certainly looking at a kit, not a person:
editor_1fb66a editor_e7ab26 editor_f69b84
support_51720f support_633eb9
dev_3b781b dev_5892ab
content_<hex6> manager_<hex> usr_<hex8>
asset_mgr<n> data_worker<n>The same generator logic produces the timestamp names from Family 2 (wp_update-1711373523, seo_1772504570) and the adminbackup<hex6> swarm from Family 1. Treat the pattern as the indicator: a role word, an underscore, and 4–10 hex characters or digits that mean nothing to anyone in the company.
🧑💼 Family 5: fake human personas
The opposite strategy: instead of imitating machinery, imitate a colleague. These are the hardest to spot by name alone and the clearest proof that verification — not the username — must carry the verdict. Every one of these was an attacker-created administrator in a confirmed incident:
kevin_vauls john_doe john_walker kelly.moon
lusie.carry chris.merloy nilley.looby MarkJSmith
bennett bob Kenny steven44
trumpweiss kralkenan eretik stender
dantel_admin devsupm KeenNomad201188lusie.carry, bennett, trumpweiss, kralkenan, dantel_admin and devsupm each appeared in two or more unrelated incidents — the same "person" joining completely different companies days apart. That cross-site reuse is the tell: attackers recycle persona names across victims, so a name that means nothing to your HR department but appears in this list deserves the full check. The publicly documented backdoor account etomidetka belongs here too (grade A — I have seen it twice, and both a popular support forum thread and an independent analysis describe it as a hidden admin backdoor).
🔀 Family 6: random strings
No disguise at all — these come from generators and rely on the user list never being read. Pronounceable eight-letter randoms are a recognisable sub-pattern (two consonant-vowel alternations glued together):
ivenyyqszj66 evqoztog idyevalr ufutnivf yupxeaxw
edzexegh kodsukli subadmin zet cg1
xdx hxh c85fa957 a7f3e9b2c4d1e5f6ivenyyqszj66 turned up in three unrelated incidents and evqoztog / idyevalr in two each — again the cross-victim reuse. The pure-hex names (c85fa957) overlap with Family 4's suffix logic minus the role word. In one memorable case five of these names (admln, bot, ufutnivf, dantel_admin, yupxeaxw) were created on two unrelated sites days apart — same toolkit, same operator, different victims.
📢 Family 7: names documented in public campaigns
These come from published incident research and are worth checking on any site, whether or not I have personally met them:
| Username | Campaign / vector |
|---|---|
| wpsupp-user · wp-configuser | LiteSpeed Cache exploitation, CVE‑2023‑40000 |
| xtw<hex>… | WP‑Automatic SQL injection, CVE‑2024‑27956 ("usernames beginning with xtw"); I met xtw18387bd89 and xtw18387d371 in the field — grade A |
| wpsupport · wpsupport_<suffix> | Fake "support" accounts; documented with emails wpsupport@wordpress.com and @wp-mail.net |
| help | "DebugMaster Pro" fake plugin + a root-level wp-user.php that deletes and recreates the account |
| superadmin | Backdoor posing as a caching plugin; hard-coded password, deletes the account after use to hide traces |
| etomidetka | Hidden-admin backdoor; widely reported by site owners who first saw it in a login alert |
| anonymousfox_<suffix> | AnonymousFox account-takeover tooling; also creates smtpfox-style mail accounts in the hosting panel |
| one_images_user | Hidden-admin malware documented by a European cleanup provider alongside admlnlx and adminbackup |
| greeceman · <site-derived> | The Balada Injector campaign first used a fixed name, then switched to generating the username from the victim's own hostname (e.g. "exammann" for example.com) — a pattern I also see in the field |
⚖️ Family 8: generic words — context decides
admin, administrator, admins, test, bot, install, support, webmaster, customer, security, developer, devops. Every one of these has appeared as an attacker-created account in my casework (bot in five unrelated incidents, admins and install in two each) — and every one of them also exists legitimately on millions of sites. For this family the name carries almost no signal; the verification below carries all of it. The question is never "is there a user called admin?" but "who created this admin, when, and does anybody claim it?"
📧 Beyond the username: the tells that actually convict
Across all eight families, the strongest indicators were never the names — they were the fields next to the names:
- Impossible email addresses.
adminbackup@wordpress.org,wpsupport@wordpress.com,sys@localhost.local,admin@wordpress.local,admin@local.invalid,test@test.test,admin@gmail.com,admin2@google.com. Nobody at wordpress.org registers accounts on your site, and.local/.invaliddomains cannot receive mail at all — which is the point: no password-reset email will ever reach a real inbox. - Forged registration dates. Direct-DB inserts write whatever they like into
user_registered. I have seen1970-10-10 10:10:10(older than the internet), dates earlier than the site itself, and several admins sharing one identical timestamp to the second — a batch insert. - Hidden from the dashboard. The account exists in
wp_usersbut not in Users → All Users: apre_user_queryfilter, a_pre_user_idmarker option, and tampered role counts are the standard kit. This is exactly the mechanism I dissected in Phantom Admin. - Resurrection after deletion. functions.php appenders, mu-plugins, fake plugins — and in the most persistent case I have handled, a MySQL trigger that recreated the rogue admin whenever a new comment was inserted. The trigger lives in the database, so no file scanner can see it.
- The same name on unrelated sites. When
lusie.carryorivenyyqszj66joins two different companies in the same week, it is a toolkit, not a coincidence.
🔍 The 15-minute verification, in SQL and WP-CLI
Run these read-only checks before deleting anything. Replace the wp_ prefix with your own.
1. List every administrator straight from the database
This bypasses any pre_user_query hiding, because it never asks WordPress:
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID AND m.meta_key = 'wp_capabilities'
WHERE m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered;Then compare the count with what the dashboard shows. A mismatch is the finding:
# What WordPress is willing to admit to:
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# What is actually in the table:
wp db query "SELECT COUNT(*) FROM wp_users u JOIN wp_usermeta m \
ON m.user_id=u.ID AND m.meta_key='wp_capabilities' \
WHERE m.meta_value LIKE '%administrator%'"2. Vet each unexplained account
-- Registration date vs. the site's real history: anything older than the
-- site, equal to another admin's to the second, or from 1970 is forged
SELECT ID, user_login, user_registered, user_email FROM wp_users ORDER BY user_registered;
-- Active sessions: a "dormant" account with live session tokens is in use
SELECT user_id, meta_value FROM wp_usermeta WHERE meta_key = 'session_tokens';
-- The hidden-user marker several backdoors leave behind
SELECT * FROM wp_options WHERE option_name LIKE '%pre_user%';3. Find the code that will recreate it
# User-creation calls outside core — mu-plugins, themes and plugins
grep -rnE "wp_create_user|wp_insert_user|add_role|set_role\('.{0,30}administrator" \
wp-content/mu-plugins/ wp-content/themes/ wp-content/plugins/ --include='*.php' | head -50
# The standard hiding hook
grep -rn "pre_user_query" wp-content/ --include='*.php' | head -204. Check the database itself for triggers
SHOW TRIGGERS;A WordPress database should normally have none. Any trigger that writes into wp_users or wp_usermeta is your resurrection mechanism.
🧹 What not to do
- Don't delete on name alone. I have seen cleanups delete a real employee's account because the name "looked generated". The name selects candidates; the evidence convicts.
- Don't delete the user first. If creator code exists, the account returns and you have told the attacker you noticed. Remove the creator (file or trigger), then the account.
- Don't stop at one. Kits create spares. After removing
adminbackup, re-run the SQL audit — in several of my incidents a second, quieter account (editor_<hex>grade) was waiting. - Don't trust the dashboard count. If the table says five admins and the screen says four, the missing one is the incident.
✅ Takeaways
- Attackers name accounts to survive a glance. Maintenance words, admin typos, role+hex suffixes, fake colleagues, or pure noise — eight families cover practically everything I have met in the field.
- The username shortlists; the metadata convicts. Email domain, registration timestamp, session tokens and creator code are where the verdict comes from.
- Reuse across victims is the strongest name-level signal. Names like
adminbackup,sys_maint,admlnlxandseobackuprecur across unrelated sites and, for several, across independent public reports. - Audit the table, not the screen. Hidden-user hooks only fool the dashboard. SQL does not lie.
- Remove the creator before the creature, or the account will be back before your coffee is cold.
❓ Frequently asked questions
I found a WordPress admin user I didn't create. Is my site hacked?
Treat it as a serious lead, not yet a verdict. First rule out legitimate origins: other staff, your agency or developer, hosting-panel installers and some migration plugins create accounts. Then check the account's registration date, email address, last login and whether any code recreates it. An account nobody claims, with a generic or fake email and a registration date that does not match any onboarding, almost always turns out to be attacker-created.
Is a username from this list proof of compromise?
No. A username is never proof by itself — a real person can legitimately be called bennett, and admins named admin exist on millions of sites. The names here are investigation leads ranked by how often they appeared as attacker-created accounts in real incidents. Always verify with the registration timestamp, the email address, usermeta capabilities and the code audit before deleting anything.
Why does the rogue admin account come back after I delete it?
Because code somewhere on the site recreates it — typically a snippet appended to a theme's functions.php, a must-use plugin, a fake plugin, or in some cases a MySQL trigger inside the database itself. Deleting the user row only removes the symptom. Find and remove the creator code first, then delete the account.
Which usernames do attackers try to log in with, and which do they create?
Brute-force bots mostly try existing-sounding names: admin, administrator, test, root, single letters and the site's own domain name. Attackers who already have code execution create new accounts instead, and those names follow different patterns: maintenance lookalikes such as adminbackup or sys_maint, typo-lookalikes such as admln, generated names like editor_1fb66a, fake personas, or random strings. The two lists serve different purposes and should not be confused.
📚 Public sources referenced
Independent documentation for the grade-A and grade-P names above: the LiteSpeed Cache campaign and its usernames (The Hacker News), the WP‑Automatic SQLi and the xtw accounts (The Hacker News), the OttoKit admin-creation flaw (The Hacker News), the superadmin fake caching plugin (Dark Reading), the adminbackup / wp-compat and help / DebugMaster write-ups (Sucuri, July 2025; Sucuri, September 2025), the Balada Injector's hostname-derived admins (Sucuri, October 2023), the AnonymousFox indicators (Sucuri, June 2022), the admlnlx / one_images_user report (website-bereinigung.de), the etomidetka analysis (InCyberera), the October 2026 hidden-admin XSS campaign (Patchstack) and the brute-force username lists (Wordfence; Dark Reading). Everything else is first-hand, anonymised casework.
