Revoke API Keys After a Hack

What this mySites.guru tool looks at on your site

Once a hacked site is clean, this tool shuts the doors a password reset leaves open. There is one per platform, and both find every credential that lets a program act as one of your users without a password, then remove them all in one pass.

It is an action rather than a check, so it never appears as a pass or fail row on the Snapshot or Audit pages. You find it in the tool finder, or from the link on a site flagged as hacked.

On Joomla 4 and later

When you open the tool, your site reports live:

• which accounts hold a Joomla API token, blocked accounts included
• on Joomla 5.4 and later, whether the site is registered with joomla.org for automated updates and whether it holds an automated updates key
• how many Joomla API plugins are switched on
• how many people are logged in, and how many remember-me keys exist

A token left behind by an account that has since been deleted still counts. The list can only show accounts that exist, so the page says how many more tokens belong to accounts that no longer do, and those are revoked too.

On WordPress 5.6 and later

Your site lists every Application Password on every account: who holds it, the name it was given, when it was last used and the IP address that last used it. The list comes straight out of the database rather than from WordPress, because on a hacked site a plugin can answer that question for WordPress.

WooCommerce REST API keys are not touched here; the Users With Application Or API Passwords check revokes those one at a time.

How attackers keep access after a password reset

Changing a password does not revoke an API credential, on either platform. That spares you re-authorising every app when you change your own password, and it leaves an attacker’s API access intact after a reset.

Joomla API tokens

A Joomla API token lets a program act as the user who created it, with that user’s permissions, through the Joomla API (Web Services). An attacker who made themselves a token, or read one out of the database, keeps using the site through the API after you have reset every password, and nothing in the administrator looks wrong.

Rotating the configuration secret string also kills every API token, because a token is an HMAC keyed on it. That is the heavier option: it logs everyone out and can break old two factor records. This tool deletes the tokens directly and leaves the secret alone.

The Joomla automated updates key

Joomla 5.4 added automated core updates. A site that signs up gets a 40 character key, stored in the Joomla Update component’s settings and registered with joomla.org, and anyone holding that key can tell your site to start a core update. Anyone who read your database has read the key too.

WordPress Application Passwords

Application Passwords arrived in WordPress 5.6, so apps and integrations could reach the REST API without a real password. The same properties make them a tidy way to keep hold of a site. An attacker with administrator access for thirty seconds can create one, it looks like any other entry, and it keeps working after the password reset and after sessions are cleared. Using it is a successful login every time, so nothing that counts failed logins ever sees it.

After a hack, the safe assumption is that any of these credentials could be the attacker’s, which is also why a planted administrator account is only half the story: delete the account and a token or Application Password it created can still be in use.

Every key accounted for

A clean result is a site where every API credential that exists is one you issued after the clean-up, for an integration you can name.

The result page is your site’s own count after the change, read again once the work is done, so what you see is what is left rather than what was asked for. On Joomla that means no API tokens remain, and on 5.4 and later a new automated updates key is in place with the old one dead. On WordPress it means no Application Passwords remain. If your site could not be read, the page says the count is unreadable, never “0 remain”.

On WordPress the revoke uses WordPress’s own delete first, so any security plugin you run logs each removal. It then reads the database again. If a filter on the site stopped the delete, which malware on a hacked site can do, it clears those rows directly, reads again, and the result page tells you that happened.

How to use it

1. Finish the clean-up first. Remove the hacked files and change every administrator’s password. This tool does not change passwords, and after a hack you need both.
2. Open the tool finder at manage.mysites.guru/en/tools/tools/selector, or press Cmd+K anywhere in mySites.guru, search for “revoke” and pick the site. A site flagged as hacked also links to it directly.
3. Read the live list and note the integrations you rely on, such as a phone app or a backup service. Each needs a fresh credential afterwards.
4. Tick what to revoke. On Joomla, revoking every API token and rotating the automated updates key start ticked. Re-register for automated updates starts ticked only if the site was registered before. Disable the Joomla API is offered only while an API plugin is on. On WordPress, revoking every Application Password starts ticked. Log everyone out starts unticked on both.
5. Click Revoke selected and confirm. The confirmation lists exactly what your site is about to do. None of it can be undone.
6. Read the verified result. It is your site’s own count after the change. If a step failed or is pending, the page says which.
7. Reissue what you need. On Joomla each integration’s owner makes a new token from their user profile. On WordPress each user issues a new Application Password from their profile screen in wp-admin.

Every option stops something. Revoking tokens or Application Passwords stops every integration that uses one until it is given a new credential. Rotating the Joomla key without re-registering switches automated updates off, and re-registering resets the update channel to Default and stable. Disabling the Joomla API stops every integration that uses it, not only the attacker’s.

What mySites.guru does about it

Your own server does the work: mySites.guru sends the instruction, your site does each step and counts again, and that count comes back.

The automated updates key never leaves your site. Your site reports only whether it holds one, and the reply to a rotation says what happened to the key without including it. Rotating means telling joomla.org to forget the old key, writing a new one, and, if you ticked it, registering the new one. The old key stops working on your site the moment the new one is stored, whatever joomla.org does, so a failed call to remove it at joomla.org does no harm. If joomla.org does not answer the registration, Joomla completes it the next time a Super Admin opens the administrator. The call to joomla.org always verifies its certificate, and there is no fallback that sends the key over an unverified connection. Joomla 4 and 5.0 to 5.3 have no automated updates, so the rotation is not offered there.

Run it on every site you have cleaned, not just the one that was reported. The same attacker often reaches more than one site on a hosting account, and a credential planted on a site you thought was fine keeps working until someone revokes it. One cleanup is rarely the end, and API credentials are one of the reasons why.