Een BGP-hijack Virtualizor-incident laat zien hoe kwetsbaar software-updates kunnen zijn wanneer netwerkverkeer wordt omgeleid. In de melding wordt beschreven dat aanvallers het Border Gateway Protocol gebruikten om updateverkeer voor Softaculous om te leiden naar een server die zij beheersten. Vervolgens konden zij een gemanipuleerde Virtualizor-update afgeven aan bepaalde installaties.
Volgens Virtualizor ging het om een beperkte set systemen, maar voor operators geldt juist dat je niet kunt vertrouwen op “waarschijnlijk niet”. De vendor benadrukt dat er geen eenduidige lijst is van getroffen servers en dat iedere operator moet controleren of er iets is binnengekomen.
Wat gebeurde er precies bij de BGP-hijack Virtualizor?
De kern van de aanval is het omleiden van verkeer. Virtualizor stelt dat hackers BGP gebruikten om verkeer bestemd voor Softaculous-services om te leiden. Daardoor konden updateverzoeken terechtkomen bij een aanvaller-gestuurde infrastructuur.
Als een installatie tijdens dat omleidingsvenster de update controleerde, kon de gebruiker een aangepast Virtualizor-pakket ontvangen. Cruciaal detail in de beschrijving: het updateclientproces zou geen cryptografische verificatie van het pakket uitvoeren. Daardoor wees de client de gemanipuleerde inhoud niet af op basis van handtekeningen.
Wanneer speelde het incident?
Het tijdvak waarin de routeafkondiging zichtbaar was, liep volgens de informatie grofweg van 28 augustus rond 20:57 UTC tot 30 augustus om 06:10 UTC. Virtualizor gaf aan dat operators hun servers moeten nalopen, omdat niet openbaar is welke installaties precies het gewijzigde pakket hebben gekregen.
Een route-aankondiging met het door de vendor geïdentificeerde pad verscheen op 28 augustus om 20:57:30 UTC, bevestigd op basis van RIPE Stat-gegevens. Virtualizor noemt de route ongeautoriseerd en stelt dat de Softaculous-verkeerstromen via een aanvalleroperated server werden omgeleid.
Hoe kwam aanvallers worteltoegang binnen?
Naast de omleiding beschrijft de melding wat er in de aangepaste update zat. Een hosting-provider-account meldde dat er in drie legitieme Virtualizor-bestanden kwaadaardige commando’s waren ingevoegd. Daarna zou een root cron-taak de aangepaste code hebben uitgevoerd.
In de aangeleverde beschrijving wordt verder uitgelegd dat de geïnjecteerde code een aanvaller-gestuurde sleutel toevoegde aan de root-accountomgeving. Ook werd een Java-component toegevoegd wanneer die niet aanwezig was: Java 17 werd geïnstalleerd, vervolgens werd een payload gedownload en uitgevoerd. Vanuit die positie werd persistentie opgezet en werd de aanvaller in staat gesteld om opnieuw toegang te behouden.
Persistentie en extra toegang
De payload zou persistentie realiseren via een systemd-service. Daarnaast werd een niet-geautoriseerde gebruiker aangemaakt, genaamd proxyuser. In de logs van de provider zou vervolgens een SSH-login met wachtwoordauthenticatie zichtbaar zijn vanaf een specifieke bron-IP.
Volgens de provider werd bij 5 van de 34 gecontroleerde Virtualizor hypervisor-nodes dezelfde gemanipuleerde wijzigingen aangetroffen. Het is dus niet “massaal bij iedereen”, maar wel genoeg om een serieus incident te noemen voor wie de software draait in kwetsbare updateketens.
Impact voor klanten en gebruikers
Virtualizor geeft aan dat het onderzochte scenario in eerste instantie leek op een beperkte set getroffen servers in plaats van de volledige gebruikersgroep. Tegelijkertijd is het voor gebruikers en providers belangrijk om niet uitsluitend naar CVE’s of versievelden te kijken: als de updatecheck tijdens het omleidingsvenster plaatsvond, kan er toch iets mis zijn gegaan.
Over mogelijke datadiefstal meldt de vendor dat er op dat moment nog geen bevestigde meldingen waren van misbruik van clientaccounts of betalinggegevens. Wel wordt genoemd dat sessies in het klantenportaal en betalingsgerelateerde verkeer tijdens het omleidingsvenster mogelijk naar de aanvallerserver konden worden geleid.
Patch 9 en de Security Analyzer
Virtualizor bracht Patch 9 uit met een Security Analyzer. In de advisering geeft de vendor aan dat cryptografisch pakketondertekenen een vervolgstap is (“future work”). Met andere woorden: het pakket werd geanalyseerd en indicatoren konden worden gecontroleerd, maar een fundamentele verbetering in pakketverificatie was nog niet volledig afgedwongen in de toenmalige build.
De vendor benadrukt dat iedere operator de officiële scanner moet uitvoeren, waarna verdere containment en herstel kan plaatsvinden. Ook is er een duidelijke instructie om de juiste volgorde te volgen: eerst evidence veiligstellen en pas daarna gericht remediëren.
Wat Virtualizor operators moeten doen
De guidance richt zich op het controleren van elk systeem, omdat er geen exacte getroffen-versierange of volledige lijst met ontvangende installaties beschikbaar is. Concreet adviseert Virtualizor operators om meerdere stappen te doorlopen.
1) Voorkom dat je bewijs verliest
Virtualizor adviseert te controleren op een systemd unit met het pad /etc/systemd/system/java-jre-update.service. Als die aanwezig is, moet je de situatie als incident behandelen, evidence bewaren en contact opnemen met support.
2) Rotatie en restricties van API-toegang
Verder moeten alle Virtualizor API-keys worden geroteerd. Beperk daarnaast API-toegang tot vertrouwde IP-adressen en verwijder ongekende sleutels.
3) Controleer SSH, geplande taken en uitgaande verbindingen
Audit onbekende SSH-sleutels, nieuwe gebruikers, geplande taken (zoals cron) en onverwachte outbound verbindingen. Ook hier geldt: beperk SSH tot vertrouwde IP-adressen.
4) Draai de officiële scanner
De vendor verwijst naar een officiële scanner en noemt de SHA-256-waarde van het opgehaalde script zoals die op 2 september 2026 is gecontroleerd. De scanner onderzoekt op bekende indicatoren van compromis (IoC’s) en probeert de bekende sporen te containen.
Virtualizor adviseert expliciet om containment niet als “klaar” te zien: als je host positief blijkt, behandel containment als het beperken van bekende indicatoren. Voor herstel naar een vertrouwd systeem is aanvullende remediatie nodig.
Welke IoC’s horen bij deze aanval?
De melding bevat een lijst met indicatoren die de scanner controleert. Denk daarbij aan een combinatie van bestanden, markers, geïnjecteerde strings en domeinen, maar ook aan SSH-sleutelmaterial en provider-gerapporteerde accounts.
Voorbeelden uit de guidance (niet uitputtend) zijn onder andere:
- Marker bestanden: /usr/lib/jvm/.cache/.installed en /tmp/widdow.jar
- Payload-pad: /usr/lib/jvm/.cache/jre-runtime.dat
- Gemonipuleerde core bestanden: o.a. /usr/local/virtualizor/globals.php en /usr/local/virtualizor/_universal.php
- Geïnjecteerde strings: o.a. cdn.nerat.cc/installer/widdow.jar en connect.ne-rat.xyz
- C2-domeinen: cdn.nerat.cc en connect.ne-rat.xyz
- Provider-reported account: proxyuser
- SSH-bron: een specifieke bron-IP uit de providerlogs
Als core Virtualizor-bestanden zijn aangepast, adviseert de vendor om te herstellen met een “known-good” bron of herinstallatie. Voor een host met bevestigd root-compromis wordt een schone rebuild genoemd als de meest betrouwbare langetermijnremediatie.
Wat moeten Client Center API-gebruikers en clients doen?
Virtualizor splitst de guidance op naar doelgroepen. Voor klanten die tijdens het incidentvenster inlogden of betaalgegevens invoerden, komt de nadruk te liggen op het heractiveren van accountveiligheid.
De aanbevelingen omvatten in de beschrijving: reset wachtwoorden in het klantenportaal, pas wachtwoorden aan waar ze hergebruikt worden, bekijk accountactiviteit en controleer bank- of creditcardoverzichten wanneer betaling tijdens het venster mogelijk was. Voor Client Center API-gebruikers geldt bovendien: regenereer API-sleutels en werk die bij op de servers.
En als je ook andere Softaculous-producten beheert?
De guidance richt zich niet alleen op Virtualizor. Ook andere Softaculous-productoperators wordt geadviseerd om hun servers te controleren, met name op systemen die in dezelfde periode een updatecheck hebben uitgevoerd. In de melding worden Webuzo, Softaculous, Backuply, SitePad en andere productservers genoemd.
Virtualizor stelt dat er voor die producten nog geen specifieke gemanipuleerde pakketdefinitie is geïdentificeerd, maar het onderzoek was op het moment van de advisering nog open.
Waarom dit incident extra aandacht verdient
De BGP-hijack Virtualizor-case draait niet om één klassieke kwetsbaarheid in een productcode. Het gaat om een breuk in de keten tussen “updatecheck” en “vertrouwde distributie”. Door netwerkverkeer om te leiden konden aanvallers een update aanbieden die niet werd verworpen op basis van cryptografische verificatie door de updateclient.
Dat maakt de boodschap voor organisaties helder: beveiliging moet niet alleen op applicatieniveau plaatsvinden, maar ook op de route, het distributiemechanisme en de validatie van pakketten.
Als je dit soort keten- en updatevraagstukken breder bekijkt, kan ook interessant zijn hoe andere aanvallen in de software supply chain werken. Lees bijvoorbeeld Fake software-installers schakelen updates uit om te zien hoe aanvallers updates en betrouwbaarheid van distributie kunnen verstoren.
Conclusie
De gemelde BGP-hijack Virtualizor-aanval toont hoe ver aanvallers kunnen gaan wanneer updateverkeer omgeleid wordt naar een server onder hun controle. Virtualizor beschrijft dat bepaalde installaties een gemanipuleerd pakket konden ontvangen en dat daarbij root-level compromittering en persistentie mogelijk was.
De belangrijkste les: behandel “mogelijk getroffen” als “moet je controleren”. Draai de officiële Security Analyzer, roteer API- en accounttoegang, audit SSH en geplande taken, en herstel systematisch naar een vertrouwde staat. Met die aanpak verklein je de kans dat een tijdelijke omleiding verandert in langdurige toegang.
Bron: https://thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
