Een supply chain aanval rond Qubole laat zien hoe dreiging en patchvertraging samen kunnen vallen in de praktijk. Onderzoekers melden dat een aanvaller gecompromitteerde IAM-credentials gebruikte om via cross-account rollen toegang te krijgen tot AWS-omgevingen van meer dan een dozijn organisaties. In veel gevallen ging het niet om een nieuw of zeldzaam pad, maar om toegang die al bestond—en die te lang bleef staan.
Het incident draait om een mechanisme dat op zichzelf normaal is voor SaaS-platformen: klanten richten tijdens onboarding een rol in AWS in, zodat het SaaS-platform (op aanvraag) kan inloggen en taken kan uitvoeren. Zodra organisaties stoppen met het gebruik van het platform, zouden die rollen echter moeten worden verwijderd of ingeperkt. In deze campagne bleken ze nog aanwezig.
Wat er misging in het Qubole-ecosysteem
Volgens beveiligingsonderzoekers werden gestolen IAM-gegevens gekoppeld aan een AWS-account dat hoort bij Qubole. Met die gegevens kon de aanvaller in AWS roles aannemen die klanten hadden ingesteld voor het gebruik van Qubole. Daardoor kon de aanvaller toegang krijgen tot het AWS-landschap van meerdere organisaties.
Cross-account IAM-rollen zijn dus geen afwijking, maar juist onderdeel van de standaard inzet van SaaS in klantomgevingen. De aandacht gaat daardoor naar het tweede deel van het probleem: rollen bleven nog in place nadat organisaties stopten met het gebruik van Qubole. De onderzoekers beschrijven dit als “oude deuren” die nog openstonden.
Old roles blijven open: waar dreiging en patchvertraging samenkomen
De aanval bleek pas later te worden geactiveerd. Onderzoekers geven aan dat de misbruikte rollen langere tijd sliepen en pas werden ingezet rond 14 oktober. Vervolgens werd er gewerkt tot 26 oktober. In die periode werd de omgeving systematisch onderzocht en werden secrets en configuraties verzameld.
Dit is precies waar dreiging en patchvertraging raakvlakken heeft. Niet alleen het patchen van kwetsbaarheden is belangrijk; ook het tijdig intrekken van autorisaties bepaalt of een aanvaller een ingang vindt. Als een organisatie stopt met een dienst, maar de bijbehorende rollen blijven bestaan, dan is “herstel” in de vorm van toegang verwijderen net zo relevant als een software-update.
Van enumeratie naar data-exfiltratie
De aanpak bestond uit meerdere stappen. Eerst werden resources geïnventariseerd. Daarna verzamelde de aanvaller informatie uit veelgebruikte AWS-locaties die voor opslag van secrets en configuraties dienen.
Om te valideren welke credentials werkten, werd tooling gebruikt om de gevonden gegevens te testen. Vervolgens vond de datadiefstal plaats: de aanvaller exfiltreerde data uit de S3-buckets van de slachtoffers.
Opvallend is de beschrijving van de handelwijze als opportunistisch. In plaats van specifiek één soort data te zoeken, werd gelezen uit de buckets waar de rollen bij konden. In sommige gevallen werd zelfs een hele bucket gedownload tijdens één sessie.
Vast patroon in rol-sessienamen
Uit analyse kwam ook een terugkerend patroon naar voren in hoe sessies werden aangemaakt. De rol session names volgden een consistente opbouw: een prefix met een specifieke aanduiding, gevolgd door een suffix die te maken had met de acties. Voorbeelden die onderzoekers noemen zijn sessienamen zoals quiam-enum en quiam-scope-full.
Dit type patroon kan helpen bij detectie, omdat het een herkenbaar signaal geeft van hoe aanvallers hun handelingen structureren.
Exfiltratie via AWS, niet via het Qubole-netwerk
Volgens de onderzoekers kwam de waargenomen activiteit niet voort uit het netwerk van Qubole. De aanvallen werden uitgevoerd vanaf een gehuurde server en via een VPN-dienst die ook door de aanvaller werd gebruikt. Met andere woorden: het was geen “Qubole-doet-het-zelf” verhaal, maar misbruik van rechten nadat credentials waren gelekt.
Daarmee wordt het risico op het niveau van klantconfiguratie duidelijk: wie IAM-rollen heeft ingericht voor een derde partij, moet periodiek controleren of die rollen nog nodig zijn en of ze nog steeds de juiste beperkingen hebben.
Een ISO-image als mogelijke extra stap
Naast AWS-activiteiten identificeerden onderzoekers een ISO-bestand dat bedoeld leek om op doelcomputers te worden geboot voor het verzamelen van data. Er werd echter geen bewijs gevonden dat dit bestand daadwerkelijk was ingezet in de campagne.
Het bestaan van zo’n component illustreert wel dat aanvallers vaak meerdere sporen voorbereiden, terwijl de kern van deze campagne aantoonbaar uit IAM- en AWS-toegang bestond.
Waarom dit relevant is voor patch- en autorisatiebeleid
Veel organisaties focussen bij beveiligingsbeheer vooral op het patchen van software. Maar incidenten als deze tonen dat de beveiliging van “gebruikersrechten” minstens zo dynamisch moet zijn. Denk aan:
- Het verwijderen of beperken van cross-account rollen zodra een SaaS-dienst niet meer wordt gebruikt.
- Het regelmatig herzien van machtigingen die via External ID’s en role trusts zijn ingericht.
- Het controleren van S3-toegang en het monitoren van ongebruikelijke downloads of scope-brede sessies.
Als IAM-toegang blijft bestaan nadat de organisatorische context is veranderd, dan is de kans groot dat een aanvaller later—met gestolen gegevens—toch kan binnenkomen.
Gerelateerd: patchvertraging en platform-incidenten
Als je wilt zien hoe vergelijkbare patronen rond toegang en vertraging terugkomen in andere contexten, zijn deze artikelen mogelijk interessant:
- Dreiging en patchvertraging: waarom rijke data wint
- Dreiging en patchvertraging: misbruik van Trusted AWS-toegang
- Dreiging en patchvertraging in 2026: default admin
Wat je nu kunt doen: praktische maatregelen
Ook zonder precies dezelfde tooling of TTP’s kun je wel lering trekken uit dit incident. Neem de volgende stappen mee in je eigen beveiligingsroutine:
- Voer periodieke IAM-audits uit op cross-account role trusts, zeker voor rollen die ooit nodig waren voor SaaS-platformen.
- Beperk rechten tot minimale toegang en voorkom “read nearly all data” situaties door scoping en voorwaarden te verbeteren.
- Monitor AWS-sessies: let op ongebruikelijke enumeratie, brede scope-sessies en herhaalde toegang tot secrets/configuraties.
- Veranker een decommission-proces voor geabonneerde diensten: rollen intrekken, policies herzien en waar nodig ook gegevensstromen stopzetten.
Zo voorkom je dat dreiging en patchvertraging zich vertaalt naar een langdurig openstaande toegangspoort, ook al draait er technisch geen “nieuwe exploit” op dat moment.
Conclusie
De Qubole supply chain aanval laat zien dat het echte risico vaak niet in één specifieke kwetsbaarheid zit, maar in wat er na een overstap of stopzetting overblijft. Gelekte IAM-credentials gaven de aanvaller toegang via cross-account rollen, terwijl die rollen bij veel organisaties nog actief waren. Door tijdig rollen te verwijderen of te beperken, verklein je de kans dat gestolen informatie later alsnog leidt tot grootschalige data-exfiltratie.
Bron: https://www.securityweek.com/over-a-dozen-organizations-hit-in-qubole-supply-chain-attack/
