Aanvaller misbruikt Qubole-rollen om AWS-data te kopiëren

Qubole-gekoppelde AWS-rollen zijn tussen 14 en 26 oktober bij meerdere organisaties misbruikt om klantaccounts te doorzoeken, secrets te testen en S3-data te downloaden, melden Wiz en Sentra.

Een oude Qubole-koppeling blijft een toegangsdeur naar AWS, ook nadat een Nederlands bedrijf het platform niet meer gebruikt. De IAM-rol kan clouddata en inloggegevens bereikbaar maken zolang de trust policy en permissies actief zijn. Daarom moeten alle AWS-accounts met zo’n rol en hun logs vanaf 1 oktober in de incidentcontrole mee.

Een oude trustrelatie gaf opnieuw toegang

Bij een standaardintegratie maakt de klant in AWS een IAM-rol aan. De trust policy bepaalt wie die rol mag aannemen; de permissies bepalen welke data bereikbaar is. Qubole gebruikte daarvoor tijdelijke STS-credentials vanuit zijn eigen AWS-account. AWS adviseert een External ID als extra controle bij toegang door een derde partij, maar die waarde is niet geheim. De aanvaller stuurde de juiste External ID mee en de rollen accepteerden de verzoeken.

Wiz zag op 14 oktober de eerste AssumeRole vanuit AWS-account 805246085872, dat het aan Qubole koppelt, via een Mullvad VPN-adres. Vanaf 15 oktober kwam veel activiteit via OVH; op 18 oktober verscheen een tweede IAM-gebruiker. Sessienamen begonnen met quiam-, waaronder quiam-enum. In de meeste onderzochte omgevingen waren de rollen in oktober niet voor normale Qubole-activiteit gebruikt. De trust bleef bestaan en gaf de verzoeken toegang.

Wiz beschrijft ook aparte activiteit van 8 tot en met 11 oktober. Daarbij gebruikte een aanvaller AWS-sleutels van klanten die volgens de onderzoekers voor Qubole-integraties waren aangemaakt. In enkele gevallen volgde een compromis van de cloudomgeving. Wiz kon deze activiteit niet aan de latere AssumeRole-campagne koppelen.

Van roltoegang naar secrets en S3-bestanden

Na het aannemen van de rollen inventariseerde de aanvaller opslag, databases, virtuele machines en identiteiten. In AWS Secrets Manager volgden ListSecrets en GetSecretValue; in Systems Manager Parameter Store DescribeParameters en GetParameter. Lambda-configuraties werden uitgelezen om omgevingsvariabelen te verzamelen. De aanvaller gebruikte TruffleHog vervolgens om gevonden AWS-sleutels, Entra ID-clientgeheimen en Okta-gegevens op geldigheid te testen.

Voor S3 liep de reeks van ListBuckets en ListObjects naar HeadObject en GetObject. De aanvaller las wat de rol kon bereiken en downloadde in sommige sessies complete buckets. Sentra beschrijft één klantomgeving waarin de aanvaller eerst duizenden profielbestanden stal, daarna in ongeveer drie minuten meer dan twaalf AWS-accounts bereikte, in zeven minuten circa honderd wachtwoorden en sleutels uit drie opslagplaatsen las en uiteindelijk miljoenen bestanden downloadde. In de gedownloade bestanden zaten ook duizenden records met opgeslagen inloggegevens. De aanvaller las daarnaast startinstellingen uit EC2 user data en haalde bij een laatste passage productiedatabaseback-ups op. Sentra zag in die klantomgeving geen schrijfacties. Deze aantallen beschrijven één onderzochte klant, niet de totale campagne.

CloudTrail toont de rol, niet altijd het bestand

Wiz adviseert organisaties die Qubole ooit aan AWS koppelden om in ieder account met een integratierol CloudTrail vanaf 1 oktober te controleren. Zoek naar AssumeRole-verzoeken vanuit account 805246085872 die niet van een AWS-adres komen, naar principal-ID AIDA3W7DIFLYOLTK63SFS en naar sessienamen die met quiam- beginnen. Een tweede principal-ID die de aanvaller vanaf 18 oktober gebruikte, komt volgens Wiz ook voor in legitiem platformverkeer; controleer die daarom samen met het bronadres. Loop daarna alle acties van verdachte sessies langs, vooral in Secrets Manager, Parameter Store, Lambda en S3. Verwijder rollen voor koppelingen die niet meer worden gebruikt. Beperk overige trust tot de specifieke leveranciersidentiteit en, waar mogelijk, bekende netwerkadressen. Roteer secrets, parameters en Lambda-variabelen die de rol kon lezen en trek bestaande sessies in.

Voor het vaststellen van S3-downloads is alleen een geslaagde rolwissel onvoldoende. CloudTrail-managementevents registreren de rolwissel en bucketverkenning, maar niet de objectlezingen die de bestanden ophalen. AWS vermeldt dat S3-data-events standaard niet worden vastgelegd en dat er kosten voor gelden. Zonder vooraf ingeschakelde data-events of S3-servertoegangslogs kan een organisatie achteraf mogelijk wel zien dat een rol toegang kreeg, maar niet welke objecten zijn gelezen.

Oude leveranciersrechten blijven onderdeel van de cloudgrens

Het patroon raakt aan eerdere cloudincidenten via leveranciers. Bij Accenture bood een hacker naar eigen zeggen 35 GB aan interne data met cloudtokens en sleutels te koop aan. Een afzonderlijk onderzoek vond dat 88 procent van 10.616 eerder gelekte AWS-sleutels bij een hertest nog authenticeerde. In april beschreef CERT-EU een andere route: een buitgemaakte AWS-API-sleutel na een Trivy-softwareketencompromis leidde tot 91,7 GB gecomprimeerde data-uitvoer uit een AWS-account van de Europese Commissie. De toegang begon daar in een softwarebouwketen, bij Qubole in een vertrouwde rolrelatie.

De omvang van de Qubole-campagne is nog niet vastgesteld. Wiz noemt meerdere getroffen omgevingen, terwijl Sentra details geeft over één klant en geen totaal voor alle slachtoffers. The Hacker News meldde op 9 november dat Qubole en eigenaar Idera nog geen verklaring hadden gepubliceerd en niet hadden toegelicht waar de buitgemaakte Qubole-inloggegevens vandaan kwamen.

De route via Qubole verschilt van de Trivy-inbraak, maar beide laten zien hoe één geldige cloudidentiteit toegang over organisatiegrenzen kan dragen. Een oude trustrelatie blijft bruikbaar zolang zij in AWS staat, ook wanneer het werk met de leverancier is gestopt. CloudTrail kan tonen wie de rol aannam; alleen passende objectlogs maken zichtbaar welke bestanden daarna zijn gelezen. Daarmee bepalen vergeten rollen en logginginstellingen samen hoeveel van een cloudincident later nog te reconstrueren valt.