Een BGP-hijack kan veel meer doen dan internetverkeer omleiden: in het slechtste geval leidt het tot gemanipuleerde software-updates. In het incident rondom Virtualizor werd Softaculous-verkeer omgeleid naar een door de aanvaller beheerde server. Via dat omgeleide pad kon een aangepaste Virtualizor-update terechtkomen op (een deel van) de installaties, met als gevolg dat er root-level compromis werd vastgesteld op enkele hypervisor-nodes.
Wat dit extra urgent maakt voor beheerders is dat de vendor geen eenduidige lijst met getroffen versies of installaties kon geven. Daarom draait het bij supply chain risico blokkeren om: alles controleren, snel vertrouwde signalen herstellen en toegang en persistence aanpakken.
Wat er gebeurde bij de Virtualizor/BGP-hijack
Volgens de beschikbare advisering is de aanval gestart via een omleiding van netwerkroutes op basis van Border Gateway Protocol (BGP). Tijdens een tijdvenster — grofweg van 28 augustus 20:57 UTC tot 30 augustus 06:10 UTC — werd verkeer voor Softaculous-services afgeleid naar een server die door de aanvaller werd bediend.
Door die route-omleiding kon een aanvaller een functioneel ogend updatesysteem aanbieden. Bovendien werd in het omgeleide interval een Let’s Encrypt-certificaat verkregen, waardoor verbindingen die via die server liepen geen certificaatwaarschuwingssignalen vertoonden.
Cruciaal hierbij: het update-clientmechanisme verifieerde de updatepakket-inhoud niet cryptografisch afdoende, waardoor een aangepakt pakket kon worden geaccepteerd.
Waarom dit een supply chain incident is
Een supply chain incident gaat niet alleen over kwetsbare code, maar ook over vertrouwde distributiekanalen. In dit geval werd de distributie van een (Virtualizor-)package verstoord via netwerkroute-manipulatie. Daarmee vervaagt de grens tussen “legitieme update” en “kwaadaardige levering”.
De vendor geeft bovendien aan dat het om een handvol servers ging, niet om de totale gebruikersbasis. Maar omdat er geen vaste getroffen-lijst beschikbaar is, betekent dat voor operators: je kunt niet volstaan met aannames op basis van versie of configuratie.
Tekenen van compromis: wat er op systemen werd gevonden
In een onderzocht scenario zijn kwaadaardige wijzigingen ingebracht in bestanden die als legitiem werkten. Later werd die aangepaste code op een cron/job-moment uitgevoerd, en zo werd root-gedreven kwaadaardige activiteit mogelijk gemaakt.
De aanvaller voegde vervolgens onder andere een sleutel toe aan de root-account, installeerde Java 17 wanneer die runtime ontbrak, en downloadde daarna een payload die opnieuw als root werd uitgevoerd. Daarna werd persistentie ingericht via een systemd-service en werd een ongeautoriseerde gebruiker aangemaakt met de naam proxyuser.
Daarnaast zijn indicatoren gemeld zoals een SSH-login op die ongeautoriseerde account vanuit een specifieke bron-IP, wat erop wijst dat toegang niet alleen theoretisch was, maar ook daadwerkelijk tot stand kwam.
Update-checkers en clientverkeer: wie moest actie nemen
De advisering onderscheidt meerdere doelgroepen. Voor Virtualizor-operators geldt: controleer elke server, omdat er geen afgebakende affected-version range of definitieve installatie-lijst bestaat.
Voor gebruikers die in het betreffende tijdvenster in het client-gedeelte hebben ingelogd of betaalgegevens hebben ingevoerd: reset wachtwoorden, check accountactiviteit en bekijk betaaltransacties waar mogelijk. Voor API-gebruikers geldt dat sleutels opnieuw gegenereerd en op servers geüpdatet moeten worden.
Ook andere Softaculous-productoperators wordt aangeraden om te controleren op systemen die tijdens het interval een updatecheck uitvoerden. De vendor stelt hierbij dat er (nog) geen kwaadwillend pakket is geïdentificeerd voor die andere producten, maar het onderzoek bleef open.
Patch 9 en de Security Analyzer: wat het wel en niet oplost
Virtualizor publiceerde Patch 9 met een Security Analyzer op 1 september. De vendor geeft daarbij aan dat cryptografische pakketondertekening nog als toekomstige verbetering werd beschouwd. Dat is een belangrijk leerpunt: totdat ondertekening echt dwingend wordt toegepast, blijft een omgeleid updatepad een reëel risico.
Voor beheerders is Patch 9 vooral een stap richting detectie en containment, niet een terugwerkende “fix” voor alles wat tijdens het omgeleide interval al is geaccepteerd.
Zo pak je supply chain risico blokkeren aan: praktische stappen
Als je wilt voorkomen dat je organisatie slachtoffer wordt van vergelijkbare update-omleiding, is het verstandig om het incidentplan te benaderen als een checklist. Hieronder staat wat Virtualizor operators wordt aangeraden.
1) Zoek naar persistence en verdachte systemd-units
Controleer specifiek of het bestand /etc/systemd/system/java-jre-update.service aanwezig is. Als dat zo is, bewaar dan de aanwijzingen (evidence) en neem contact op met de vendor/support. Bij een positieve host is het belangrijk om niet meteen “alles weg te poetsen” voordat er bewijs is veiliggesteld.
2) API-toegang blokkeren en sleutels roteren
Rotatie van alle Virtualizor API-keys is noodzakelijk. Beperk daarnaast API-toegang tot vertrouwde IP-adressen en verwijder ongekende sleutels. Dit verkleint de kans dat aanvallerstoegang via API kan blijven bestaan.
3) Audit op SSH, nieuwe accounts en scheduled tasks
Ga na of er onbekende SSH-key-materialen zijn, nieuwe gebruikers zijn toegevoegd, of er onverwachte scheduled tasks/cron jobs bestaan. Beperk SSH vervolgens tot vertrouwde IP’s. Dit helpt om zowel de aanvankelijke toegang als latere herhaling te stoppen.
4) Gebruik de officiële scanner en behoud indicatoren
Voer de officiële scanner uit. De vendor vermeldt daarbij een retrieved-script SHA-256 (gerapporteerd op 2 september). Als de scanner een besmetting bevestigt, adviseert de vendor om containment van bekende indicatoren te behandelen en daarna verder te remediëren om het systeem weer in “vertrouwd” gedrag terug te brengen.
5) Bij root-compromis: kies voor een clean rebuild
Waar root-compromis is vastgesteld, wordt aangegeven dat een schone rebuild de meest betrouwbare lange termijn oplossing is. Dat is logisch: bij root-niveau is het moeilijk te bewijzen dat alle sporen, hooks en persistentiemechanismen echt weg zijn.
Indicatoren om te controleren (IoC’s)
De advisering noemt een reeks indicatoren. Je hoeft niet elk detail blind te kopiëren, maar gebruik de lijst wel als inhoudelijke leidraad voor je audit:
- Systemd unit: /etc/systemd/system/java-jre-update.service
- Payload/marker-bestanden zoals /usr/lib/jvm/.cache/jre-runtime.dat en marker-files onder /usr/lib/jvm/.cache en /tmp
- Concrete payload-signaturen zoals een gerapporteerde payload SHA-256
- Aangepaste kernbestanden (core Virtualizor files), waaronder onder andere /usr/local/virtualizor/globals.php en verwante componenten
- Injected strings en mogelijke download/command-and-control (C2) domeinen, zoals cdn[.]nerat[.]cc en connect[.]ne-rat[.]xyz
- Provider-rapportage over de ongeautoriseerde account proxyuser en een gerapporteerde SSH-bron 193.32.127[.]248
Door deze indicatoren gestructureerd te toetsen, wordt supply chain risico blokkeren concreet: je verifieert niet alleen of “updates” binnenkwamen, maar ook of er echte runtime- en persistence-sporen ontstonden.
Wat je nu kunt leren voor de toekomst
Dit incident toont een paar terugkerende principes in software supply chain security. Ten eerste: als je updatekanaal omgeleid kan worden, is route security en pakketvertrouwen essentieel. Ten tweede: zonder dwingende cryptografische verificatie (bijvoorbeeld ondertekening) loop je het risico dat een wijziging door het distributiepad heen komt.
Daarnaast laat de vendor-advisering zien dat “er is geen affected-version list” niet betekent dat je kunt wachten. Het betekent juist dat je operationele discipline moet gebruiken: inventariseren, scannen, API-toegang beperken en systematisch auditten.
Gerelateerde acties die je kunt combineren
Als je supply chain risico’s breder wil aanpakken (ook in webservers en geautomatiseerde omgevingen), zijn deze praktische richtlijnen mogelijk aanvullend:
- Supply chain risico blokkeren in webservers
- Supply chain risico blokkeren bij AI-agent Git-configs
- AI circuit breaker tegen rogue agents
Ze sluiten inhoudelijk aan op het bredere thema: vertrouwen in distributie en uitvoering afschermen, zodat één afwijking niet meteen door kan werken naar productie.
Conclusie
De Virtualizor-incidenten rond een BGP-hijack laten zien hoe supply chain risico blokkeren niet alleen een kwestie is van “patches draaien”, maar vooral van levering controleren, toegang beperken en persistence opsporen. Omdat de vendor geen volledige affected-lijst kon geven, ligt de nadruk op het controleren van elke installatie, het roteren van API-keys, het auditten van SSH en taken, en het draaien van de officiële scanner.
Wie root-compromis vermoedt of bevestigt ziet zich het meest gebaat bij een clean rebuild: daarmee herstel je het systeemvertrouwen op een manier die lastig te evenaren is met alleen containmentsignalen. Zo maak je je omgeving weer bestand tegen omgeleide updates en vergelijkbare distributierisico’s.
Bron: https://thehackernews.com/2026/09/bgp-hijack-delivers-malicious.html
