Is het ook al duidelijk wat ze doen? Ik had een Wordpress installatie met een nieuw admin account 'wpsvc_229a63eb90ec' in wp_users, maar ik kon verder geen spoor vinden van hacks. Gelukkig zijn de php files niet van www-data bij deze installatie (in tegenstelling tot wat vaak wel het geval is), dus het kan zijn dat ze geen bestanden konden bewerken, maar in theorie zou er nog van alles kunnen zijn gedaan.

Ik zie verder ook geen rare processen of bestanden op de server. Ik heb vaker dit soort hacks meegemaakt, en de vroege vogels zijn vaak spammers en crypto miners, dus dat valt erg op.

Check de plugin map. Daar vond ik een mooie nieuwe filebrowser.

Niets daar. De dir 'wp-content/plugins' is niet schrijfbaar voor www-data, dus dat scheelt. Ik snap sowieso niet dat Wordpress stimuleert dat de code schrijfbaar is voor dezelfde user als die het uitvoert. Ik snap dat het makkelijk is voor auto-upgrades, maar het is gewoon niet slim.

Ik doe updates met wp-cli trouwens. Tenminste, voor mijn eigen Wordpress installaties (wat dit niet was; deze was van iemand anders).

1 van mijn 4 WP-sites geraakt met deze Wp shell

Kan bevestigen dat dit lek inderdaad razendsnel werd misbruikt. Eén van mijn klantensites (WordPress 7.0.1, dus nog niet gepatcht) is via deze keten gecompromitteerd geraakt. Gevonden:

Rogue admin-account aangemaakt (wpsvc_[random]-achtig patroon)
Kwaadaardige plugin geïnstalleerd, vermomd als cache-plugin
Kwaadaardige MU-plugin (wp-content/mu-plugins/), deze laden altijd, ook zonder activatie, dus check die map sowieso even
Webshell met ROT13/XOR-obfuscatie en een WPCACHE_OK-marker in de output, om tussen normale cache-plugin-responses te verdwijnen

Herkenningspunt in de access-logs: User-Agent wp2shell-rce/1.0 en POST-requests naar /?rest_route=/batch/v1 met HTTP 207-responses. Wie dat patroon in de logs ziet met een 207 (niet 400/404), is de kwetsbaarheid daadwerkelijk getriggerd.

Bij mijn andere 3 sites (al eerder gepatcht, sommige uren tot dagen eerder) zag ik in de logs ook aanvalspogingen vanaf meerdere IP's, maar geen enkele succesvolle payload, dus het lijkt breed geautomatiseerd gescand te worden, niet gericht.

Wat hielp bij het opschonen: wp core verify-checksums en wp plugin verify-checksums --all via WP-CLI, plus handmatig zoeken naar chr()-opgebouwde strings en str_rot13/eval+base64-combinaties in de bestanden. Losse admin-tools (Wordfence, NinjaScanner) gaven achteraf ook een schone uitslag ter bevestiging.

Wachtwoorden + salts ververst, rogue admin verwijderd, 2FA aan, en bij mijn host tijdelijk IP-restrictie aangevraagd tijdens het onderzoek..

Leuk geprobeerd, maar dat gaat dit niet werken op een WordPress site die ik beheer. "/" is niet de locatie van WordPress. De aloude methode van een andere locatie gebruiken dan default werkt nog steeds tegen domme aanvallen die domweg domme hard coded locaties gebruiken.