Impostor Plugin Identities

How impostor plugin detection works

This is the one check in this group that never contacts your site. Everything it uses was collected on an ordinary snapshot: the name, version, author and vendor address every plugin declares about itself in its own file header.

It asks one question. Is the declared author a plain two-word human name whose surname is also the vendor domain, someone called “Jack Walker” publishing at walker.dev? One malware family generates a fake plugin per site it breaks into, and it invents the author and the domain from the same pool, so the two agree in a way a real vendor identity rarely does.

The shape of the rule matters as much as the idea. The author has to be two capitalised words, which is why “Team Yoast” and company names never reach the test at all, and the host has to be exactly the surname followed by .dev rather than merely containing it, because a case-insensitive match on .dev would also catch perfectly real vendors whose domains happen to end that way.

Why a planted plugin looks exactly like a real one

Everything WordPress knows about a plugin is self-declared. The name, the version, the author and the vendor URL all come from a comment block at the top of the plugin’s main file, and nothing anywhere verifies any of it. A planted plugin writes whatever header it likes and then appears in your Plugins screen looking like software you chose.

On the compromise this came from, the declared names were things like Lunar Analyzer Lab and Keen Librarian Go, with invented authors at invented .dev domains. Several of them installed into a folder whose name did not match the plugin name they declared, which is a tell in itself and not something a legitimate plugin does.

The reason this check exists is that the evidence was already held and no one was looking at it. Going back through the extension records for this identity pattern turned up the matches immediately, and every one of the affected sites was reading as clean at the time, because the malware behind them lives in the database rather than in files a scanner can compare.

What a clean result does not prove

The first is that it reads what the plugin claims. This is a check on a self-declared identity, so a plugin that invents a more convincing one passes it.

The second is that it catches something newly planted rather than a takeover. A plugin’s details are recorded the first time it is seen, and the record is keyed on a hash of its description, path, version and name. A plugin already installed that later changes only its author address keeps the record already held, so the new address is never stored and never tested. For that shape of problem, a plugin you trusted being sold to an attacker is the fuller story.

This check is WordPress only, and that follows from where it came from. The rule was shaped against real infections on WordPress sites, and the field it reads is a plugin’s Plugin URI header, which on Joomla holds the author URL instead. Running it across both would be comparing two different things.

Every plugin identity accounted for

Every plugin on the site has an author you can find, a vendor address that resolves to something real, and a listing somewhere with a changelog and other users. The folder each one installs into matches the name it declares.

Verifying a flagged plugin in a minute

Checking one of these takes about a minute.

1. Search for the plugin by name. A real plugin has a listing, a support forum, a changelog, other people complaining about it. A planted one has none of that anywhere.
2. Search for the author. Same test. A developer publishing under their own name has a history you can find.
3. Ask whether anyone installed it. If no one with access to the site recognises it, that is the answer, and the plugin is not the whole problem. Find out how it got there.
4. Do not just delete it and move on. A planted plugin normally comes with a scheduled event or a must-use plugin that puts it back. Check both before you decide the site is clean.
5. Tell us if it is real. If it turns out to be a real plugin by a real person, nothing needs doing and we will note it.

Re-reading plugin identities on every snapshot

On every snapshot mySites.guru re-reads the identity every plugin on your site declares, and flags any that match the pattern above. It colours a warning, never a danger, and it does not contribute to the hacked flag.

Each flagged plugin links into the web file manager at its own directory, so you can read the header for yourself and see what else is in there.

Separately, every WordPress site mySites.guru monitors is swept for newly appearing identities of this shape, and only new ones are reported, so the same planted plugin is not announced again every time its version number changes.