Vimexx server web0167 geïnfecteerd met malware

Vanavond merkte ik dat op 2 WordPress sites van klanten bij Vimexx de plugin UpdraftPlus gedeactiveerd was door WP-CLI. Dat is niet door de klant, de bouwer of door mij gebeurd, dus ik dacht eerst door iemand van Vimexx, maar bij nadere inspectie blijkt er malware te staan in de mu-plugins map met root als eigenaar en 0444 rechten, dus alleen door de serverbeheerder te verwijderen. Wel heb ik een kopie van de malware kunnen maken en uitlezen en die heb ik door Claude AI laten analyseren.

Analyse malware via Claude AI

Het gaat om het bestand cms-options-plus.php in de map mu-plugins en het is duidelijk onleesbaar gemaakt door verschillende coderingen, dus heb ik de analyse uitbesteed en aangegeven dat ik vermoed dat het malware is en niet door de server beheerder is geplaatst. Dat bleek wel te kloppen.

Output Claude AI

Wat het is

Een zwaar geobfusceerde WordPress MU-plugin (Must-Use), vermomd als “Central Compiler Rig”. Alle strings zijn XOR-gecodeerd met sleutel 22 en in omgekeerde volgorde opgeslagen, zodat de code onleesbaar is voor mensen en eenvoudige scanners.

Na decodering blijkt het een volledig uitgerust backdoor/dropper te zijn met de volgende onderdelen:

Functionaliteit (per module)

1. Command-and-control via Ethereum blockchain De malware bevat 21 publieke Ethereum RPC-endpoints (van eth.llamarpc.com t/m eth.api.pocket.network). Het gebruikt deze om instructies op te halen via een blockchain-transactie, inclusief een hardcoded API-key. Dit is een geavanceerde C2-techniek die moeilijk te blokkeren is, want er is geen vast aanvallers-domein.

2. Persistentie en zelfbescherming

Controleert zijn eigen bestandsinhoud (checksum via eerste 12 bytes).
Als het bestand wordt aangepast of verwijderd, schrijft het zichzelf terug.
Zet bestandsrechten op 0444 (read-only) om verwijdering te bemoeilijken.
Kopieert zichzelf naar alle gevonden wp-content/mu-plugins-mappen op de server, ook buiten de eigen site.
Zoekt actief naar andere WordPress-installaties op het systeem (/home, /var/www, /var/www/vhosts, /srv/www etc.) om zich te verspreiden.

3. Backdoor admin-account aanmaken

Zoekt naar bestaande administrator-accounts.
Als die er zijn, reset het hun wachtwoord (naar een nieuw willekeurig wachtwoord, opgeslagen in WordPress-opties).
Als er geen administrator is, maakt het er zelf een aan (wp_insert_user), met willekeurige gebruikersnaam en wachtwoord.
Onderdrukt alle notificatie-e-mails (nieuwe gebruiker, wachtwoordwijziging) zodat de eigenaar niets merkt.
Verbergt de backdoor-gebruiker in het WordPress-adminpanel via pre_user_query en rest_user_query hooks.

4. Plugin-manipulatie

Ontvangt van de C2 een lijst met regex-patronen.
Scant alle actieve plugins op overeenkomsten in hun broncode.
Verwijdert plugins die matchen (delete_plugins, inclusief bestandsverwijdering).
Kan ook code injecteren in plugin-bestanden (preg_replace op de broncode).
Verbergt zichzelf in het plugin-overzicht (show_advanced_plugins filter).

5. elFinder-integratie Detecteert populaire file manager-plugins (WP File Manager, File Manager Advanced) en injecteert een eigen class elFinderConnector waarmee de aanvaller toegang heeft tot de bestandsbeheerder.

6. Cron en activeringstriggers Hooks op vrijwel elke WordPress-actie (plugins_loaded, admin_init, cron_schedules) om periodiek contact te maken met de C2, updates te ontvangen en persistentie te handhaven.

Is dit van de host geplaatst?

Nee, dit is geen legitieme hostingcode. Kenmerken die dat uitsluiten:

Actieve verduistering/obfuscatie van alle strings.
Zelfkopieer-mechanisme naar andere sites.
Heimelijk backdoor-account aanmaken en verbergen.
Command-and-control via Ethereum blockchain.
Onderdrukt e-mailnotificaties zodat de beheerder niets merkt.
Eigendom van root en rechten 0444 wijzen erop dat het via een servercompromis of gecompromitteerde uploadmethode is geplaatst, niet door de webhoster zelf.

Aanbevolen aanpak

Site offline halen totdat de infectie volledig is opgeruimd.
Alle WordPress-installaties op de server controleren — het malware verspreidt zich actief.
Het bestand verwijderen (eerst chmod 644 want het staat op read-only).
De WordPress-database controleren op onbekende administrator-accounts en verdachte opties/transients met prefix uwzib_.
Alle wachtwoorden resetten (WordPress admin, hosting, database).
Uitzoeken hoe het bestand als root-eigenaar in de mu-plugins-map is beland — dat duidt mogelijk op een serverbrede compromittering.
Logbestanden (SSH, webserver, control panel) analyseren op het tijdstip van plaatsing.

Wat nu?

Aangezien support van Vimexx op zaterdagavond niet bereikbaar is en het vrij kleine sites zijn, waar ik (schone) offline backups van heb, ga ik die zo op mijn server plaatsen en de DNS wijzigen, zodat de sites weer bereikbaar worden. Dan zien we later wel hoe het met Vimexx wordt opgelost.

Als er nog bijzonderheden volgen, dan zal ik die hier vermelden.

Controleren of je zelf geraakt bent

Host je bij Vimexx, controleer dan even op welke server je zit. Als je dat niet zeker weet, dan kun je bijvoorbeeld je domeinnaam invullen op https://www.abuseipdb.com/ en dan zie je op welke IP adres en server je zit. Staat daar web0167.zxcs.nl dan is je site hoogstwaarschijnlijk ook gehackt en kun je het beste contact opnemen met support van Vimexx.

Let op: Vimexx vraagt mogelijk ca. € 200,- per website om deze voor je op te schonen. Ga daar niet mee akkoord, want zo proberen ze geld te verdienen aan hun slachtoffers.

Tijdlijn

11-4-2026 14:47 uur
Plugin UpdraftPlus wordt uitgeschakeld door WP-CLI op 2 sites

11-4-2026 19:15 uur
Deactivatie UpdraftPlus kwam aan het licht bij inspecteren monitoring. Contactpersoon voor beide sites op de hoogte gebracht en onderzoek gestart naar oorzaak.

11-4-2026 19:40 uur
Met Claude AI de code van de aangetroffen malware geanalyseerd en verwerkt tot dit artikel.

11-4-2026 20:30 uur
Gestart met het herstellen van beide sites via schone backups om die op mijn server te plaatsen.

11-4-2026 22.45 uur
DNS is omgezet en beide sites zijn weer bereikbaar en veilig.

12-4-2026 11:00 uur
Er is nog steeds niets vermeld op de Status pagina van Vimexx en de malware is nog steeds aanwezig, dus er lijkt daar nog geen actie te zijn ondernomen.

13-4-2026 10:00 uur
Nog steeds geen teken dat Vimexx al bezig is met herstel.

13-4-2026 13:19 uur
Vimexx heeft gereageerd op een support ticket van een klant en zegt niets te zien, dus dat de klant zich geen zorgen hoeft te maken. Dit artikel is duidelijk niet gelezen en de malware staat nog altijd op de site, dus er is gewoon niet goed gekeken.

14-4-2026 10:20 uur
Vimexx Support gaat in overleg met systeembeheer.

15-4-2026 16:45 uur
Er is nog steeds geen inhoudelijke reactie van support. Wel zie ik dat op de sites het malware bestand uit mu-plugins verwijderd is. Dat wil echter nog niet zeggen dat de sites schoon zijn, want de hacker heeft o.a. gebruikersaccounts aangemaakt op alle sites en wie weet wat voor infecties er verder nog zijn.

16-4-2026 10:30 uur
Nog altijd geen informatie van Vimexx gehad. Wel werd ik gebeld door een ander slachtoffer met tientallen sites op een reseller pakket op deze server. Vimexx blijft volhouden, dat je niet alles moet geloven wat je op internet leest en dat er niks mis is met de server (ondanks hard bewijs in dit artikel). Dus ik heb nu zelf gereageerd op een support ticket met extra uitleg. Ook blijkt Vimexx geld te vragen voor het opschonen van de sites, terwijl dat geen zin heeft zolang de server gehackt is en het hun eigen verantwoordelijkheid is. Daarvoor heb ik nu een waarschuwing geplaatst in dit artikel.

17-4-2026 16:22 uur
Vimexx heeft inhoudelijk gereageerd en blijft volhouden dat dit niet door de server komt, maar dat er meerdere sites mogelijk al sinds 2025 geïnfecteerd zouden zijn, met een technische verklaring, die grotendeels uit mijn analyse is overgenomen, maar zo verdraaid, dat het toch de schuld van alle klanten is en niet van Vimexx.
Uiteraard heb ik daar op gereageerd, dat dit geëscaleerd moet worden, om de schade voor de klanten niet nog groter te maken, omdat de schade voor Vimexx zelf ook alleen maar groter zal worden.

21-4-2026 09:27 uur
Vimexx reageert en blijft volhouden, dat de infectie echt niet op de server zit en vraagt mij om bewijs, terwijl het door mij aangeleverde bewijs wordt genegeerd en zeker niet tegengesproken. Het zou ook niet om alle klanten op deze server gaan, want dat heeft uitgebreid onderzoek uitgewezen. Bevindingen worden niet gedeeld en informatie van andere klanten wijst juist uit, dat ze wel getroffen zijn. Ik heb nog van niemand gehoord, dat een site niet geïnfecteerd zou zijn. Mogelijk hebben sommige klanten zelf eerder al een backup terug gezet, waardoor de malware daarop niet meer werd gezien, maar dat wil niet zeggen, dat ze niet gehackt waren.

21-4-2026 14:18 uur
Ik heb weer gereageerd en aangegeven, dat ik al bewijs had aangeleverd, omdat het malware bestand root:root als eigenaar had en dat kan nooit door een normale gebruiker zijn toegekend, want daar heb je root rechten voor nodig. Dus nogmaals gevraagd om bewijs dat het wel mogelijk zou zijn om dit via een gehackte website voor elkaar te krijgen. En ik heb ook gevraagd om welke “lekke” plugin het dan zou gaan, waarmee deze sites allemaal gehackt zouden zijn. Dat zou namelijk het geval zijn, maar ze noemen niet welke plugin dat zou zijn geweest. Statistisch gezien is het ook zeer onwaarschijnlijk, omdat alleen 2 sites van mijn klanten op deze server zijn gehackt en 330 sites op andere servers niet, net als 200 sites van een collega. En tientallen sites van andere klanten zijn op deze server ook gehackt, terwijl ik nergens signalen heb opgevangen dat die allemaal een overeenkomst hebben, die buiten deze server niet voorkomt.

21-4-2026 14:38 uur
Vanwege de aanhoudende ontkenning van Vimexx, heb ik dit nu ook op LinkedIn gedeeld.

22-4-2026 18:00 uur
Inmiddels trekt het bericht op LinkedIn de nodige aandacht, waaronder meer meldingen van slachtoffers. En dat terwijl Vimexx blijft volhouden, dat het slechts om enkele sites gaat. Ook heeft de directeur van Vimexx gereageerd, dat hij een PM gaat sturen om dit te bespreken. Die PM heb ik echter een uur later nog niet ontvangen. Hij geeft echter ook meteen aan dat het geen server hack betreft en hij graag meer informatie wil delen. Daar vraag ik echter al 12 dagen om. Dus ik ben benieuwd!

23-4-2026 10.15 uur
Nu toch een mailtje ontvangen voor een afspraak voor morgenochtend 11.00 uur. Helaas is dit blijkbaar niet ernstig genoeg om vandaag al in te plannen, maar het duurt nu toch al bijna 2 weken, dus wat is dan een extra dag toch? Zucht…

24-4-2026 11.00 uur
In gesprek met de directeur en de teamleider van support is er eindelijk iets meer informatie op tafel gekomen, die al veel eerder gedeeld had kunnen worden, zodat dit minder geëscaleerd had hoeven worden. Men schijnt al voor 11 april op de hoogte te zijn geweest van deze hack, waarbij de analyse al is gestart, maar dit was niet bekend bij support, er is niet over gecommuniceerd en men heeft dit als “standaard procedure” naar afzonderlijke klanten proberen te temperen als individuele gevallen.

Het verhaal van Vimexx blijft dat het technisch gezien onmogelijk is dat dit via server/root niveau heeft kunnen verspreiden, maar omdat men ook geen andere verklaring heeft blijft de conclusie dat alles sites afzonderlijk van elkaar zijn geïnfecteerd. Het zou ook niet alleen om server web0167 gaan, maar om veel meer servers en men heeft ook andere hostingpartijen gesproken, waar dit speelt. Daar heb ik geen concrete informatie over, dus kan het ook niet controleren.

De infectie zou op de getroffen sites al veel eerder hebben plaatsgevonden en pas op 11 april of de dagen ervoor zijn geactiveerd met het doel om alle sites in te zetten voor crypto mining. Dit zou door Vimexx al onschadelijk zijn gemaakt en geblokkeerd, zodat men daar geen kans meer toe heeft. Dat neemt niet weg dat al die sites nog wel in meer of mindere mate zijn geïnfecteerd, maar dat moet elke klant dus zelf zien op te lossen.

Dat het aangetroffen malware bestand root eigenaar was en 444 rechten had, was het gevolg van de analyse en poging tot opschoning van Vimexx. Daar was support echter ook weer niet van op de hoogte en er was geen bericht op de status pagina geplaatst.

Er zijn wel veel punten besproken, waarmee de signalering en communicatie in de toekomst verbeterd zouden kunnen worden en er is ook toegezegd, dat men daar mee aan de slag gaat. Met name op de eerste lijn moet beter herkend worden of men met een “gewone gebruiker met weinig kennis” te maken heeft of met iemand, die al een uitgebreide technische analyse heeft gedaan. Met moet in het laatste geval sneller escaleren, zodat er sneller verbanden kunnen worden gelegd. Maar van bovenaf moet men ook duidelijker communiceren als er informatie bekend is, die kan zorgen, dat er begrip komt voor een situatie. Daarmee kan een klant ook rust vinden, dus dat werkt juist de-escalerend.

Ik ga nog technische details gemaild krijgen over de infectie, zodat ik verder onderzoek kan doen bij mijn 2 getroffen sites in de hoop toch iets te kunnen ontdekken dat de belangrijkste vraag beantwoordt: “Hoe zijn al die sites nu gehackt geraakt, terwijl ze goed onderhouden werden?“, want dat kan niemand nog vertellen. En statistisch kan ik ook nog steeds niet verklaren, waarom alle incidenten zich beperkt leken te hebben tot web0167, terwijl ik het nergens anders heb aangetroffen, niemand heb gehoord die wel op die server zit, maar niet getroffen was en ik het bij verschillende andere hosts ook nergens ben tegen gekomen.

Conclusie van het gesprek: Ik waardeer de tijd (1,5 uur) die er is genomen om dit te bespreken. Mijn inzet en doorzettingsvermogen werd gewaardeerd, maar toch voelde ik me ook regelmatig niet serieus genomen en ging het “downplayen” door, verschool men zich achter het enorme aantal sites dat ze hosten en dat dit dus maar een kleine impact zou hebben. Ook kreeg ik meermaals het verwijt dat ik geen uitspraken moest doen, wanneer ik niet het complete verhaal ken. Maar als daar herhaaldelijk om gevraagd wordt en het niet wordt gegeven, dan kan ik mijn verhaal dus ook niet bijstellen.

30-4-2026 17.00 uur
We zijn inmiddels bijna een week verder en ik heb nog altijd geen aanvullende informatie ontvangen, die mij was toegezegd. Wel komen er nog reacties binnen van andere klanten op andere servers, waar ook UpdraftPlus was uitgeschakeld via WP-CLI, maar op andere momenten. Zowel die klanten als de betreffende beheerder gebruiken dat niet, dus ook dat is door Vimexx of een hacker gedaan. De sites hebben we echter wel gecontroleerd en er zijn geen andere sporen aangetroffen van deze malware.

Zo blijven we vooral met veel vraagtekens zitten en wijst alles nog steeds in de richting van de server(s) of Vimexx in het algemeen en wordt er geen informatie verstrekt, die een ander scenario plausibel zou maken. En het blijft ook allemaal nog eens beperkt tot alleen Vimexx en heb ik over sites bij andere (grote of kleine) hostingproviders geen enkel signaal gehoord, dat daar iets vergelijkbaars aan de hand zou zijn.

1-5-2026 10.10 uur
Mail ontvangen met meer technische details, maar het grootste gedeelte was al bekend. Wel stonden er wat concrete patronen in voor gebruikers en opties, die in de database worden geplaatst. Daar ga ik nog een controle voor bouwen, die ik op alle sites in onderhoud kan loslaten, maar daar ben ik vandaag niet meer aan toegekomen.

Wat me blijft verbazen is de tegenstrijdigheid, dat het niet mogelijk zou zijn om vanaf de server malware te plaatsen in een grote hoeveelheid sites, terwijl het wel mogelijk blijkt om diezelfde malware collectief op te ruimen.

Vanmiddag nog met 2 partijen contact gehad, die het recente Linux lek Copy Fail (CVE-2026-31431) noemden als mogelijke oorzaak. Dat is pas 2 dagen gepubliceerd, maar de patch is al op 1 april gemaakt, dus iemand zou dat kunnen hebben gezien en uit kunnen vogelen hoe dat te misbruiken was.

Als je dat combineert met het zeer grote aantal sites dat tegen een laag tarief gehost wordt bij Vimexx en laag budget impliceert vaak ook minder aandacht voor onderhoud van die sites. En het feit dat de software op de servers van Vimexx vaak verouderd is (ongepatchte phpMyAdmin en MariaDB, waardoor een aanval op de database waarschijnlijker wordt), dan zie ik nog altijd geen aanwijzingen die wijzen op een lek op alle individueel getroffen sites.

1-5-2026 22.30 uur
Inmiddels een script geschreven dat ik via MainWP Code Snippets extensie heb uitgevoerd op alle sites in mijn onderhoud en er zijn nergens gebruikers of opties aangetroffen, die door deze malware worden aangemaakt.