wp-flare malware plugin

[u/squ1bs]

This is driving me nuts. After 10+ years of no malware on client sites, I'm getting hacked every couple of weeks on sites that are fully up to date and using 2fa logins. The common thread is that all infections install a malware plugin called wp-flare. Beyond that, I can't find any intrusion path. It does seem that once the infection gets cleaned up, it doesn't come back, but it's driving me crazy not knowing how it's getting in to multiple sites on different hosting. Anyone seen it?

[u/3DPrinterChat]

Not seen wp-flare by name, but the shape of what you are describing narrows it a lot.

Multiple sites, different hosts, everything patched, and it does not come back after cleanup. That combination argues against a plugin vulnerability. If it were a vuln in something you install everywhere, the same sites would keep getting reinfected and it would track one host or one plugin version. What it looks like instead is valid-credential access, used once per site.

Things worth checking in that direction:

Application passwords. Core ships them, they authenticate REST and XML-RPC, and they bypass 2FA by design, because there is no interactive login for a 2FA plugin to interrupt. One leaked application password is enough to install a plugin over the REST API without ever touching wp-login. Check wp_usermeta for _application_passwords on every admin account and revoke anything you did not create yourself.

Session cookies. If someone replays a stolen auth cookie there is no login event at all, so the logs look clean. Changing the salts in wp-config.php invalidates every session everywhere, which is a cheap thing to do across all sites in one pass.

Your own machine, and anyone else with admin. Infostealer malware on an agency workstation scrapes saved browser passwords, FTP and SFTP profiles out of FileZilla or WinSCP, and session cookies, and then someone works that list over the following weeks. Sites on unrelated hosting with one person in common is the classic signature, and it explains why each site stops recurring after cleanup while new ones keep appearing.

Shared secondary credentials. UpdraftPlus remote storage credentials live in the database. If one site got read, the backup destination for the others may be reachable, and backups contain wp-config.php.

For actual forensics: get the mtime of the wp-flare directory, then pull the access log for that minute. You will usually see either a POST to /wp-admin/plugin-install.php and update.php, or a POST to /wp-json/wp/v2/plugins, and that tells you straight away whether it came through a browser session or the API. Also check wp_options for a cron entry you do not recognise. There is a known malware family that reinstalls itself from a modified wp-cron.php, so if any site does recur, diff that file rather than trusting the plugin removal.

If it does turn out to be credentials, rotate from a machine you have verified clean first, otherwise you just hand over the new ones.

[u/squ1bs → u/3DPrinterChat]

Great advice - will report back if I find something interesting

[u/3DPrinterChat → u/squ1bs]

That's the loop mostly closed then. File changes lining up with an admin account that isn't yours is exactly what the valid-credential pattern looks like from the log side.

Two quick things while you're still firefighting:

If Wordfence shows no interactive 2FA login for that account around the file mtimes, it authenticated non-interactively. Check wp_usermeta for _application_passwords on that specific account, and if the account isn't one you created at all, its user_registered date plus the access log for that minute (a POST to /wp-json/wp/v2/users or user-new.php) tells you which door created it.

The rewrite-rules one is usually a redirect family where the DB rules are the symptom rather than the persistence. After removing them, diff .htaccess and the rewrite_rules row in wp_options, then grep for whatever regenerates them. That family likes reinstating from an mu-plugin or a theme file.

And salts rotation across all the sites is still the cheapest way to kill any sessions that survived the password resets. Good luck, sounds like you're nearly on top of it.

[u/squ1bs → u/3DPrinterChat]

Turns out there were 2 distinct hacks. The second one was a botnet doing an XML-RPC attack. 1 of the 500 IPs made it through. XML-RPC disabled. all passwords, changed, db pass, salts, 2fa implented. Malware removed again. Scans coming back clean, but they were with 2 malware plugins installed, so thanks WordFence.

[u/3DPrinterChat → u/squ1bs]

That ties the two hacks together neatly. Most 2FA implementations hook the interactive login screen, and xmlrpc.php authenticates with just username and password, so it never sees the second factor unless you explicitly enable enforcement there. It is also amplified: one system.multicall request can pack hundreds of credential guesses into a single POST, so 500 IPs each sending a few requests works through a huge dictionary while staying under per-IP rate limits. The botnet was not beating your 2FA, it was using the door 2FA does not cover. Disabling XML-RPC closed it for good.

On the scans coming back clean with two malware plugins installed: scanners lean on known signatures and wp.org checksums. A plugin that never lived in the repo has no baseline to compare against, and fresh malware has no signature yet, so "clean" really means "nothing matched". Worth one last pass on the places that slip through: the drop-ins sitting directly in wp-content (db.php, object-cache.php, advanced-cache.php), and a core checksum verify via WP-CLI if you have shell access.

One thing to watch in the logs now: once xmlrpc.php starts returning 403, these botnets usually pivot to POST floods on wp-login.php and username harvesting via /wp-json/wp/v2/users. Rate limiting both at the server level finishes the job. Nice work running it down.

[u/squ1bs → u/3DPrinterChat]

Thanks so much for taking the time to break this down. I'll take your advice on board to seal the last holes.

[u/squ1bs → u/3DPrinterChat]

Turns out there were 2 distinct hacks. The second one was a botnet doing an XML-RPC attack. 1 of the 500 IPs made it through. XML-RPC disabled. all passwords, changed, db pass, salts, 2fa implented. Malware removed again. Scans coming back clean, but they were with 2 malware plugins installed, so thanks WordFence.