Hackers hebben tussen 14 oktober en 26 oktober meerdere AWS-accounts van Qubole-klanten gecompromitteerd en daarbij data en opgeslagen secrets buitgemaakt. Dat meldt beveiligingsbedrijf Wiz na onderzoek naar misbruik van de trusted AWS-toegang die Qubole nodig heeft om binnen klantomgevingen te werken.
De kern van het probleem is dat de aanvallers konden doen alsof ze Qubole waren bij het overnemen van IAM-rollen (via AssumeRole). Daardoor kregen ze rechten die in de praktijk nog steeds aan Qubole’s account waren gekoppeld—ook bij rollen die volgens Wiz niet actief gebruikt leken te worden.
In dit artikel lees je wat er precies is gebeurd, welke sporen je in je logs kunt zoeken en welke maatregelen Wiz adviseert om de “route” naar je data zo snel mogelijk af te sluiten.
Hoe misbruik trusted AWS-toegang Qubole-klanten raakte
Qubole is een data lake-platform dat binnen de AWS-accounts van klanten opereert. Om dat mogelijk te maken, kan een klant een IAM role aanmaken die Qubole mag aannemen. Die toestemming wordt vastgelegd met een trust policy waarin staat dat Qubole’s AWS-account die role mag assumen, mits de aanvraag een bijbehorende code bevat: de External ID.
Bij de aanval maakten hackers gebruik van credentials voor het AWS-account dat Qubole gebruikt om toegang te krijgen tot klanten. Hoe zij aan die gegevens kwamen is door Wiz niet toegelicht. Zodra de juiste External ID werd meegestuurd, accepteerde AWS de AssumeRole-aanvragen—en gingen de rechten van die IAM-rollen “open”.
Waarom ook “ongebruikte” rollen toch werkten
Wiz stelt dat het merendeel van de door de aanvaller overgenomen IAM-rollen niet actief in gebruik leek. Toch bleef in die rollen de trustrelatie naar Qubole’s AWS-account bestaan. Daardoor bleven de AssumeRole-aanvragen succesvol, ook als de betreffende rollen niet langer nodig waren.
Wat de aanvaller deed in de klantomgeving
In de geanalyseerde omgevingen focusten de aanvallers op het vinden en testen van opgeslagen credentials. Ze keken onder meer naar waarden die in de cloudomgeving “klaar lagen”, zoals:
- environment variables van AWS Lambda-functies
- secrets uit Secrets Manager
- parameters uit SSM Parameter Store
Vervolgens controleerden ze of de gevonden waarden bruikbaar waren met tooling zoals TruffleHog voor het testen van uitgelezen toegang.
Daarna probeerde de aanvaller data te kopiëren uit S3. In plaats van één specifieke set bestanden te targeten, werd gekeken naar buckets waartoe de overgenomen rol toegang had. Soms werd zelfs een volledige bucket in één sessie gedownload.
Naast de AssumeRole-route: ook gebruik van klantkeys
Wiz beschrijft dat Qubole klanten ook kan laten verbinden via eigen AWS access keys (in plaats van een role). In de periode 8 tot 11 oktober zou een aanvaller klantkeys hebben gebruikt die naar verwachting waren opgezet voor Qubole. Die eerdere activiteit leidde tot een compromis van enkele cloudomgevingen, maar Wiz koppelt dit niet rechtstreeks aan hetzelfde AssumeRole-misbruik.
Controleer je CloudTrail vanaf 1 oktober
Wiz adviseert organisaties die Qubole met AWS hebben verbonden (ook als ze het inmiddels niet meer gebruiken) om hun CloudTrail-logs te checken. Kijk daarbij vanaf 1 oktober in elk AWS-account dat een Qubole-role bevat.
De belangrijkste signalen zijn AssumeRole-requests die afkomstig lijken te zijn van het Qubole-platformaccount, maar niet binnen het AWS-netwerk thuishoren.
Waar je precies op moet letten
Wiz noemt onder andere de volgende aandachtspunten:
- Account: AssumeRole-requests met userIdentity.accountId gelijk aan 805246085872 en een sourceIPAddress die niet overeenkomt met een AWS-adres.
- IAM principal ID’s: onderzoekt activiteit van specifieke IAM-gebruikers die in de zaak naar voren kwamen (Wiz noemt o.a. AIDA3W7DIFLYOLTK63SFS en AIDAJYRRH5Y3A7AAJM2HW), met extra context rond de herkomst van het IP-adres.
- IP-adressen: Wiz vermeldt o.a. OVH-hosted IP’s en Mullvad VPN-adressen die door de aanvaller werden gebruikt. Let op: bij VPN-adressen is alleen een match niet genoeg om zeker te zijn.
- Session name: role sessions die beginnen met quiam- (bijvoorbeeld quiam-enum).
- User agent: signalen waarbij TruffleHog opduikt bij GetCallerIdentity-calls vanaf één van de verdachte IP’s. Je kunt dezelfde user agent ook terugzoeken in sign-in logs van je identity provider.
Voor elke verdachte sessie geldt: bekijk daarna wat er verder is gebeurd. Richt je vooral op acties rondom Secrets Manager, SSM Parameter Store, Lambda en S3.
Let op: niet alles is terug te zien in CloudTrail
CloudTrail logt management events van AssumeRole en bucket listing, maar niet welke specifieke objecten in S3 zijn gelezen. Om dat te reconstrueren heb je S3 data events of S3-server access logs nodig. Wiz geeft aan dat sommige slachtoffers die benodigde logging niet hadden, waardoor het moeilijker werd om precies te bepalen welke bestanden waren geopend.
Maatregelen om de aanvalsvector te stoppen
Als je hebt vastgesteld dat jouw omgeving geraakt kan zijn, is snelheid belangrijk. Wiz noemt een reeks stappen om de “route” naar je data af te sluiten en herhaling te voorkomen.
1) Roteer en intrek de toegang die misbruikt is
Wanneer een aanvaller één van jouw Qubole-roles heeft aangenomen, adviseert Wiz om:
- alle secrets, parameters en Lambda environment variables te rotaten die door die role toegankelijk waren
- de actieve sessies te revoquen
Alleen roteren is niet genoeg voor al uitgegeven sessies. Als een sessie al is gestart, kan die doorlopen zolang je deze niet intrekt.
2) Verwijder rollen die je niet langer nodig hebt
Heb je Qubole-rollen die inmiddels overbodig zijn? Haal ze weg of haal Qubole’s account uit de trust policy. Dit verkleint de kans dat toekomstige misbruikpogingen nog kunnen slagen met “restrechten”.
3) Verscherp de trust policy waar dat kan
Wiz beveelt ook aan om, wanneer mogelijk, de trust policy te beperken tot een specifieke IAM principal in plaats van het brede :root principal. Verder is het verstandig om voorwaarden toe te voegen die AssumeRole beperken tot bekende netwerkbronnen.
Een Source IP-voorwaarde zou in deze casus volgens Wiz alle waargenomen rolassumpties hebben geblokkeerd. Daarom is het toevoegen van een aws:SourceIp of aws:SourceVpce (passend bij jouw inrichting) een praktische verbetering.
4) External ID is géén “geheim”
Wiz benadrukt dat de External ID in veel gevallen zichtbaar kan zijn in logging en ook in infrastructuurcode kan voorkomen. Daarom moet je External ID niet behandelen als de enige beveiligingslaag. Na een incident is het beter om de External ID te vervangen—idealiter met een andere waarde per role waar dat haalbaar is.
5) Controleer wat iedere role mag bereiken
Veel vendor-roles krijgen extra permissies voor gemak. Wiz adviseert om na te gaan welke resources de Qubole-role kan benaderen, inclusief toegang tot S3-buckets, Lambda-instellingen, Secrets Manager en SSM-parameters. Door je rechten te reduceren tot wat écht nodig is, beperk je de mogelijke impact als een rol toch wordt misbruikt.
Versterk je monitoring en incidentrespons
Naast het beperken van toegang helpt goede detectie. Wiz stelt voor om alerts in te richten voor AssumeRole-requests vanuit vendor-accounts die binnenkomen via VPN of hostingproviders die normaal niet voorkomen. Daarmee zie je sneller dat er iets afwijkt van het patroon van “legitieme” Qubole-verkeer.
Verder is het nuttig om organisatiebrede logging aan te zetten zodat je meerdere accounts en regio’s in één overzicht hebt. Zet daarnaast waar mogelijk S3 data events of S3 server access logs aan voor buckets met gevoelige data, zodat je na een incident kunt zien wat precies is uitgelezen.
Relatie met andere cloud- en beveiligingsissues
Dit soort incidenten laat zien hoe belangrijk het is om niet alleen kwetsbaarheden in applicaties te patchen, maar ook misbruik van toegangsketens in je cloudomgeving te voorkomen. Eerder zagen we bijvoorbeeld ook dat aanvallen zich snel kunnen verspreiden via misbruik van toegangs- en auth-mechanismen in SSH-contexten. Als je daarvan meer wilt weten, kun je deze achtergrond lezen: SSHole: OpenSSH kwetsbaarheid en directe acties.
Daarnaast kan patchvertraging in bredere zin zorgen dat verkeerde timing je blootstelling vergroot. Dat zie je terug in signalen rond updates en operationele achterstand. Een relevant overzicht staat hier: Dreiging en patchvertraging in 2026.
Conclusie: pak misbruik trusted AWS-toegang nu aan
De melding rond Qubole laat zien hoe een geaccepteerde trustrelatie in AWS (AssumeRole) een aanval kan versnellen zodra aanvallers toegang krijgen tot het AWS-account of de credentials van de vendor. Door misbruik trusted AWS-toegang konden hackers rollen aannemen en vervolgens secrets en S3-data ophalen.
Door CloudTrail vanaf 1 oktober te analyseren, verdachte AssumeRole-sessies te onderzoeken en daarna direct secrets te roteren én sessies in te trekken, verklein je de kans op verdere schade. Tot slot: beperk permissies, verwijder onnodige rollen en voeg netwerkbeperkingen toe aan je trust policy. Zo maak je het veel lastiger voor aanvallers om opnieuw dezelfde route te gebruiken.
Bron: https://thehackernews.com/2026/11/hackers-exploit-quboles-trusted-aws.html
