An unfamiliar plugin appears in the dashboard with a generic name, no settings link and no recognised update source. Some legitimate utility plugins have no interface, so absence of settings is not proof. The critical questions are who installed it, what code it runs and whether it returns after removal.
Preserve the plugin before deactivation or deletion when visitor safety allows.
Record dashboard and filesystem evidence
Capture plugin name, description, version, author URL, status and activation time if logs exist. Record the directory, files, owner, permissions and modification times.
Hash the directory contents in a quarantined copy. Do not download it through a public URL or email it.
Check whether it is a normal plugin, must-use plugin or drop-in. Must-use plugins do not use the ordinary activation screen.
Establish legitimate ownership
Search internal change records, hosting/developer documentation and deployment repositories. Ask current maintainers whether the plugin implements a small custom function.
Verify author/vendor domains independently. Do not click links embedded in a suspicious plugin header from an administrator session.
An absent WordPress.org listing is normal for custom or commercial code; it increases the need for an accountable source.
Inspect static behaviour
Review the main plugin header and included files offline. Identify hooks, external connections, filesystem writes, user creation, scheduled events and hidden administration behaviour.
Search for code that removes itself from the plugin list or changes output only for visitors. Check obfuscated or dynamically loaded content without executing it.
Do not judge solely by a harmless-looking header. A plugin directory can contain an innocent main file that includes a concealed payload.
Check how and when it arrived
Compare modification timestamps with WordPress logins, plugin installations, SFTP/panel access and vulnerability events. Check recent administrator creation and application passwords.
Review whether another compromised plugin can write into wp-content/plugins. Inspect hosting account isolation and sibling sites.
The fake plugin may be persistence, not the original entry point.
Disable safely
If the plugin is executing malicious code, contain the public site and deactivate it through a controlled method. Some payloads register shutdown hooks or scheduled tasks, so preserve evidence first.
Take a database backup and record active-plugin state. Remove the confirmed malicious directory after deactivation and inspect options, cron and created users it may have left behind.
Do not install a “clean” plugin with the same generic name unless a verified source exists.
Watch for reappearance
Monitor the plugin directory, active plugin list and must-use folder. If it returns, correlate the creation time with requests, cron and account logins.
Rotate affected WordPress, hosting and deployment credentials after securing administrator devices. Patch the vulnerable component or account route.
Changing the directory permissions to read-only may break legitimate updates and does not remove a writer with higher privileges.
Review the plugin list again after a normal core/plugin update and after any deployment automation runs. A compromised package repository or deployment artefact can restore the directory without a web request, which would otherwise look like unexplained reinfection.
Verify site behaviour
Retest the symptom that led to discovery, public HTML, redirects, forms and authorised checkout. Search files and database for the plugin’s distinctive strings and external domains.
Review PHP errors after removal. A legitimate dependency failure should be repaired without restoring untrusted code.
Request a malware assessment
Request help when no owner can identify the plugin, it hides from the dashboard or returns after deletion. Provide the displayed name, directory and timestamps, not the plugin ZIP or passwords.
A complete response attributes the code, removes its persistence and explains how installation access was regained.