Administrator accounts created (Vulnerability)

Hi! I experienced what appears to be the same issue on two separate WordPress installations.

In my case, I removed Prime Slider and Ultimate Post Kit, deleted the unauthorized users and the malicious/fake plugins and files that had been created, and cleaned the related database entries. Wordfence detected some of the malicious files at one point, although not consistently in every scan.

I also noticed that the malicious activity on one of the sites occurred immediately after I logged into wp-admin. Since removing the affected plugins and cleaning the sites, I haven’t seen any further signs of the infection so far.

Of course, I can’t be sure yet that the problem has been completely resolved, so I will continue monitoring both sites.

I’m sharing this in case it helps others experiencing the same issue.

OK, here you go, I am too exhausted to write it up all myself. So the second part comes from AI.

I am very sure that this plugin was the source of the infection. It was just absolutely not clear at the beginning, as it seemed to go back to a login into the website backend via MainWP (open wp-admin directly from MainWP). At that time I opened within a few minutes in total 10 sites via MainWP, very soon after I got NinjaSecurity warning emails about new administrators. I had suspicion that the MainWP connection was somehow compromised, I thought it’s affecting all sites I opened during that session from MainWP, however other sites at least did not give a hint that they were compromised as well.

After long investigation and first restore and cleanup, I logged in directly again to the freshly restored site on a fresh Chrome Profile even, and it happened again pretty much the second I logged in.

The plugin obviously got temporary shut down from WP Repository Team because of this all. It also seems that this all goes back to backend promotion code of the plugin itself.

I am not fully back yet and still have a lot of tasks to take care of, I of course deleted the plugin before I restored back into /public_html folder.

It’s a shame because once compromised you never know if something else happened during that time, therefore a restore from a backup (without restoring this plugin) is mandatory.

Summary from AI

I have now completed a detailed investigation and recovery of both the live and development installations.

The evidence strongly points to Prime Slider as the entry point. The affected sites were the only installations using this plugin. The reinfection occurred after an administrator logged into wp-admin, even while the entire site was protected by HTTP Basic Authentication. Prime Slider versions up to 4.4.5 loaded data from an external promotions API and inserted parts of that response into the WordPress admin interface without sufficient validation.

Indicators of compromise found in my case included:

• Fake plugins such as wp-smart-thumbnails and wp-cache-cleanup
• Files such as emer-run.php
• Malicious MU plugins named class-wp-query-[random].php and class-wp-token-validate.php
• Unauthorized administrator accounts with changing names and WordPress-looking email addresses
• Hidden administrators that were visible directly in wp_users/wp_usermeta, but not always in the WordPress Users screen
• Database options named fz_emer_done_v1 and fz_emer_login_tokens

Simply deleting the users and files was not sufficient. I restored files and databases from clean backups, removed Prime Slider before the restored site was executed, replaced WordPress core and affected plugins with trusted copies, rotated credentials and salts, invalidated sessions, and monitored the database and filesystem afterward.

Since removing Prime Slider, both installations have remained clean. This does not constitute definitive proof without the malicious promotions API response itself, but the timing, shared plugin, reinfection behavior, plugin withdrawal, and 4.4.6 security changelog all strongly correlate.

I repeat: I would not just remove the plugin and cleanup the site accordingly, as this still gives you a site where a foreign admin user had potentially full access. I would always combine it with a full restore (without restoring the plugin during that process). Never log into wp-admin with the plugin enabled at the current moment.