Er is een nieuwe supply chain-incident gemeld met een AOMEI Backupper backdoor. In het kort: aanvallers hebben gedurende korte tijdvensters bestanden op AOMEI’s eigen update-servers aangepast. Wie in zo’n venster controleerde op updates, kon daardoor een pakket downloaden dat niet alleen installaties uitvoerde, maar ook een achterdeur activeerde.
Het opvallende: er is geen klassieke software-exploit gemeld. De besmetting kwam tot stand door server-side manipulatie van updatecontent, terwijl de Backupper-app de aangepaste bestanden via het normale updateproces ophaalde.
Wat er precies gebeurde met de AOMEI Backupper backdoor
Volgens Google Threat Intelligence Group (GTIG), Mandiant en ManageEngine’s Threat Analysis Lab zijn de aanvallers tussen mei en juli 2026 meerdere keren ingegrepen in wat Backupper van de vendorserver ophaalt. Die aanpassingen duurden steeds vijf tot tien minuten. In dat tijdslot downloadde het programma dan de “updatebestanden” zoals de software ze verwachtte—alleen waren ze gemanipuleerd.
Cruciaal daarbij is hoe Backupper de update controleert. De software haalt twee bestanden op die samen bepalen wat gedownload wordt en wat er in meldingen/popuplogica moet gebeuren. Maar: de betreffende bestanden worden niet cryptografisch gevalideerd. Bovendien zit de controle-informatie over de download (de checksum die “genuine” moet bewijzen) in hetzelfde onbeveiligde bestand dat ook de bestandsnaam bevat. Daardoor kon de aanvaller met slechts tekstbestandswijzigingen het gedrag sturen.
Twee korte wijzigingen op de server
De onderzoekers beschrijven dat de aanvaller twee tekstbestanden op AOMEI’s servers veranderde:
- down_html.ini: bepaalt de updatebestandsnaam en de checksum die Backupper gebruikt.
- Notifycfg.ini: stuurt welke melding/popup er wordt getoond en welk onderdeel er moet worden uitgevoerd.
Omdat de software geen sterke cryptografische verificatie toepast voor deze onderdelen, volstond het om tijdens de korte vensters “de juiste” tekst te serveren.
Waarom dit lastig te detecteren is
De campagne is lastig omdat alleen systemen die in het exacte venster een updatecheck deden, het gemanipuleerde pakket kregen. Een machine die net ervoor of erna checkte, downloadde gewoon de echte bestanden. Met andere woorden: je ziet het niet op basis van “het lijkt alsof alles nu weer schoon is”.
GTIG beschrijft dat de targeting “opportunistisch” was: wat er pollde tijdens de minuten waarin de server was aangepast, werd geraakt. Dat maakt zowel triage als geautomatiseerde bestands-scanlogica kwetsbaar als je niet kijkt naar wat er toen precies is geserveerd.
De gemelde tijdvensters
GTIG en Mandiant bevestigden drie manipulatievensters. Mogelijk zijn er meer geweest:
- 28 mei 2026: 10 minuten (05:40–05:50 UTC)
- 16 juli 2026: 6 minuten (08:33–08:39 UTC)
- 20 juli 2026: 5 minuten (10:35–10:40 UTC)
ManageEngine’s lab onderzocht daarnaast minimaal een versie in de context van de bevindingen (het gaf aan een versie 8.3.0 te hebben bestudeerd). De meldingen sommen geen lijst op met alle getroffen Backupper-versies.
Wat er “landde” op een getroffen Windows-systeem
Wanneer Backupper in een venster een pakket ophaalde, startte een keten die onderzoekers beschrijven met o.a. de naam CROSSROAD. Die component pakte de inhoud uit in een lokale map (met Radmin-verwijzingen) en zette vervolgens een geplande taak op die periodiek zou draaien. Daarna verwijderde de downloader zichzelf weer van de schijf.
In de bundel zat ook een legitiem, ondertekend component: een commerciële remote-administration tool (Radmin). Volgens ManageEngine werd die staged, maar niet daadwerkelijk geactiveerd (er was geen listener, geen configuratie en geen nieuw account). De remote control kwam uiteindelijk via een aparte kwaadaardige component.
De keten werkte grofweg zo:
- Een geplande taak startte het ondertekende Radmin-programma.
- Naast dat programma werd een aanvaller-DLL geplaatst.
- Die DLL laadde vervolgens een implant (SHINYROAD) die commando’s kon uitvoeren.
De onderzoekers wijzen ook op een praktische mitigatie: de implant communiceerde met een hard-coded adres voor controle. Als je die communicatie afsnijdt (zoals in rapporten beschreven), kan de aanvaller de controle verliezen.
Extra truc: tokenlekkage via onzichtbare popup
Voor het venster op 20 juli vonden de onderzoekers bovendien een tweede aanvalsmethode die geen programmatische payload vereiste op het moment dat het gebeurde. De notification file werd aangepast om een onzichtbaar pop-upje (slechts één pixel) te openen met een verwijzing naar een bestand op een aanvallersserver via WebDAV.
Wanneer Windows dat probeert te renderen, kan de machine een authenticatieantwoord (NetNTLMv2) sturen van de ingelogde gebruiker naar de aanvaller. Zelfs als later een backdoor niet kan worden geblokkeerd, kan dit soort gedrag toch credentie-informatie blootleggen—met mogelijkheden voor offline cracking of hergebruik.
Welke organisaties zijn geraakt
Op basis van eigen telemetry zegt GTIG getroffen omgevingen te hebben gezien binnen onder meer IT-services, telecommunicatie en hoger onderwijs in 11 landen. Er wordt geen totaal aantal genoemd; GTIG verwacht dat het daadwerkelijke aantal hoger ligt.
GTIG noemt AnyViewer (een remote-desktop tool van AOMEI) als onderdeel van hetzelfde update-mechanisme in de rapportage, maar de beschreven detecties/compromissen richten zich op Backupper. De onderliggende groep achter de campagne wordt door GTIG gevolgd als UNC7017 (zonder vaste land- of actorlink).
Belangrijk: een “fix” op serverniveau maakt besmette machines niet automatisch schoon
Volgens de onderzoekers heeft AOMEI servers gecorrigeerd. Maar dat neemt niet weg dat een machine die eerder in een venster een gemanipuleerd pakket binnenhaalde, daarmee al een backdoor kan hebben geïnstalleerd.
Daarbij komt dat het lokale herstel ook misleidend kan zijn: een downloader kan na uitvoering lokale bestanden terugzetten naar “echte” inhoud, zodat een systeem op het moment van onderzoek weer normaal kan lijken terwijl de echte vector in het verleden al heeft gedraaid.
Daarom waarschuwen GTIG en Mandiant expliciet om niet alleen te vertrouwen op “de vendorpagina ziet er nu schoon uit”. Die pagina kan het merendeel van de tijd inderdaad overeenkomen met de echte bestanden, omdat de manipulatie slechts kort was.
Wat je nu moet controleren (endpoint en netwerk)
De onderzoekers geven concrete aanknopingspunten om te jagen. Hieronder staan de hoofdpunten die in hun meldingen naar voren komen.
Endpoint hunting: geplande taken en staged bestanden
Zoek op systemen waar Backupper draait naar:
- Geplande taak: RadminComponentRuntime of NitroRuntime (voor het vervolgtooling)
- Bestanden: een unsigned upgrade-now.exe met uitgeversdetails van AOMEI, of executables die draaien vanuit de Backupper “html popup”-folder
- Mapstructuren: aanvaller-stage onder de lokale “Radmin application-data” map
De precieze combinatie van bestandsnamen kan per uitvoering verschillen, maar de logica (scheduled task + staged tooling + uitvoering uit Backupper-gedreven popupcontext) is volgens de rapporten een bruikbaar patroon.
Netwerk hunting: blokkeer command-and-control en relevante protocollen
Daarnaast adviseren de onderzoekers om infrastructuur te blokkeren die in hun rapporten wordt genoemd, én outbound verkeer te beperken voor protocollen die betrokken waren bij de credential-truc (zoals SMB en WebDAV naar externe adressen).
In de meldingen worden o.a. de volgende domeinen genoemd:
- storage-data[.]com
- promotion.storage-data[.]com
- aomei.storage-data[.]com
Ook worden de volgende IP-adressen genoemd:
- 8.210.84[.]56
- 8.218.65[.]184
- 47.239.60[.]117
Door SMB (TCP 445) en WebDAV outbound naar externe locaties te blokkeren, verklein je de kans dat een machine alsnog authenticatie-responses uitlekt via die route.
Praktische aanpak: kijk niet alleen naar “wat downloadt het nu”
Een goede incidentaanpak begint met tijdgebonden informatie. Omdat de wijziging slechts minutenlang gold, wil je terug naar de logs op de momenten dat jouw alert afging of jouw EDR netwerkverkeer zag. Controleer dus:
- Welke bestanden in de Backupper-lokale mappen zijn gecached rond een verdacht moment.
- Welke content exact is geserveerd tijdens de pollingperiode (en door welke URL’s/domeinen).
- Of er gelijktijdig geplande taken zijn aangemaakt door Backupper-onderdelen.
Zo voorkom je dat je de detectie afdoet als “false positive” omdat de vendorpagina nu weer klopt. Dat patroon hebben onderzoekers vaker gezien bij dit type kortstondige server-side manipulatie.
Vergelijkbare supply chain risico’s in bredere zin
Dit incident past in een bredere trend: aanvallen die niet starten met een bug in de software, maar met het misbruiken van de manier waarop software updates of bijbehorende content binnenhaalt. Eerder zagen we ook meldingen waarin aanvallers via veranderde componenten of implementatiestappen controle konden krijgen.
Als je wilt vergelijken hoe andere supply chain- of update-gerelateerde campagnes worden benaderd, kun je ook lezen:
- AI confidence is geen validatie: zoborg je bewijs
- (optionele) supply chain context
- Contextuele cyberdefensie: van losse meldingen naar actie
Let op: bekijk vooral de principes rond bewijsvoering en context—niet de specifieke indicators—want die verschillen per campagne.
Conclusie
De AOMEI Backupper backdoor-campagne laat zien hoe krachtig korte supply chain-manipulatie kan zijn: geen exploit, geen gebruikersactie, maar wel controle via updatebestanden die in minuten worden omgezet. Omdat aanvallen afhangen van exacte updatechecks, is het risico niet “weg” zodra de vendor servers corrigeert.
Pak daarom nu de hunting-aanpak op: controleer scheduled tasks en staged tooling op endpoints, en beperk tegelijk netwerkroutes (SMB/WebDAV) naar externe adressen. Alleen zo kom je achter wat er in jouw omgeving in de vensters is gedownload en uitgevoerd.
Bron: https://thehackernews.com/2026/10/attackers-tampered-with-aomei.html
