Meer dan 9.300 gelekte AWS-sleutels werkten jaren later nog — 768 gaven volledige controle over bedrijfsaccounts

Publiek gelekte AWS-inloggegevens waren lang niet altijd kortstondige vergissingen. Uit een onderzoek van Truffle Security over de periode augustus 2022 tot en met augustus 2026 blijkt dat veel sleutels jaren geldig bleven. Sommige hadden bovendien genoeg rechten om een volledig bedrijfsaccount bij Amazon Web Services over te nemen.

De belangrijkste uitkomst: blootstelling werd vaak langdurige toegang

Truffle Security verzamelde 431.875 AWS-geheimen uit openbare codeopslagplaatsen, Git-geschiedenis, datasets, Docker-images, containerregisters en logs van continue-integratiepijplijnen. Na het verwijderen van duplicaten vertegenwoordigde de dataset 64.024 unieke AWS-toegangssleutels, gekoppeld aan 50.654 AWS-accounts.

De onderzoekers konden 10.616 volledige sleutelparen verifiëren. Toen zij deze gegevens op 10 augustus opnieuw testten, kon 88% nog steeds authenticeren. Daarmee bleven meer dan 9.300 publiek blootgestelde sleutels bruikbaar.

Een sleutel die ergens openbaar verschijnt, is niet automatisch nog een actief gevaar. Het risico wordt concreet wanneer de sleutel niet is ingetrokken, nog kan inloggen en betekenisvolle rechten heeft. In dit onderzoek kwamen die drie omstandigheden echter vaak samen.

Honderden bedrijfssleutels boden volledige beheerderscontrole

Van de actieve sleutels die aan bedrijfsaccounts konden worden gekoppeld, waren er 817 afkomstig van bedrijven. Daaronder vielen:

• 526 sleutels van AWS-rootaccounts;
• 242 sleutels van IAM-gebruikers met het AWS-beleid AdministratorAccess;
• 768 sleutels in totaal die volledige administratieve controle over een bedrijfsaccount boden.

Rootgegevens geven een AWS-klant het hoogste beschikbare controleniveau. Een IAM-identiteit met AdministratorAccess kan met zeer ruime rechten opereren binnen AWS-diensten. Een geldige sleutel op een van deze niveaus kan de deur openen naar accountovername, ongeoorloofde toegang tot gegevens, het aanmaken van infrastructuur en misbruik van de cloudfactuur.

De bevindingen wijzen daarom niet alleen op slordigheid in broncode, maar ook op problemen met rechtenbeheer en de levenscyclus van inloggegevens. Een sleutel uit een zichtbaar bestand verwijderen beschermt een account niet wanneer iemand al een kopie heeft. De sleutel moet worden ingetrokken of vervangen.

Hugging Face was de grootste afzonderlijke bron

Hugging Face was goed voor 8.482 blootstellingen van AWS-inloggegevens en was daarmee de grootste afzonderlijke bron in de rapportage. Truffle Security meldde dat 17,9% van deze AWS-inloggegevens rootgegevens waren.

Dat resultaat past binnen een bredere scan van openbare Hugging Face-data. Truffle Security zegt 7,6 petabyte aan openbare datasets te hebben onderzocht en actieve inloggegevens in duizenden datasets te hebben gevonden. Dat laat zien hoe geheimen buiten traditionele softwareopslagplaatsen kunnen blijven bestaan en vervolgens in openbaar verspreide data terechtkomen.

Voor beveiligingsteams is de conclusie duidelijk: alleen de huidige broncode scannen is onvoldoende. Git-geschiedenis, buildartefacten, containerimages, gepubliceerde datasets, registers en CI-uitvoer kunnen inloggegevens blijven bevatten nadat ontwikkelaars denken dat ze zijn verwijderd.

De sleutels waren vaak jaren oud en werden zelden vervangen

De gerapporteerde mediane leeftijd van de inloggegevens was ongeveer 1.831 dagen, oftewel circa vijf jaar. De oudste sleutel was 17,4 jaar oud. Slechts 13,7% van de vermeldingen had een nieuwere sleutel die aan dezelfde gebruiker was gekoppeld. Dat wijst erop dat de meeste sleutels niet volgens een regulier rotatieproces waren vervangen.

Langdurig geldige toegangssleutels vergroten de periode waarin onbevoegden ze kunnen gebruiken en maken het moeilijker om vast te stellen wie verantwoordelijk is. Ze kunnen bovendien personeelswisselingen, migraties van applicaties, opschoning van repositories en veranderingen in operationeel beheer overleven.

Leeftijd moet daarom als een risicosignaal worden gezien. Een blootgestelde sleutel van enkele jaren oud is niet automatisch verouderd of onbruikbaar. Controleer de sleutel, trek hem in en onderzoek het gebruik ervan, tenzij de eigenaar kan aantonen dat hij niet meer geldig is.

Weinig accounts hadden budgetbewaking

Truffle Security kon accountinformatie van 2.754 accounts uitlezen. Daarvan hadden slechts 262 AWS-budgetwaarschuwingen ingeschakeld.

Budgetmeldingen vervangen geen sleutelintrekking of detectie van aanvallen, maar kunnen wel vroeg waarschuwen wanneer gestolen gegevens worden gebruikt om dure resources te starten, bijvoorbeeld voor cryptomining of ander cloudmisbruik. Zonder een melding die bij iemand terechtkomt die snel kan handelen, kunnen ongebruikelijke uitgaven doorgaan nadat een account is gecompromitteerd.

Wat AWS-meldingen wel en niet oplossen

Volgens de rapportage beschikt AWS over beveiligingen die openbaar gemaakte toegangssleutels kunnen detecteren, getroffen klanten kunnen waarschuwen en beperkingen of quarantaine­maatregelen kunnen toepassen. Dat zoveel geteste sleutels nog geldig waren, suggereert echter dat detectie of een melding niet consequent leidde tot snelle intrekking en vervanging aan klantzijde.

Detectie is slechts de eerste stap van een reactie op gelekte inloggegevens. Een volledige aanpak moet de eigenaar identificeren, vaststellen waartoe de sleutel toegang heeft, controleren of er misbruik is geweest en de sleutel ongeldig maken. Truffle Security beschrijft de eigen validatie als alleen-lezen: de onderzoekers controleerden authenticatie en metadata over rechten of accounts, zonder klantresources aan te passen. Die werkwijze is hier gebaseerd op de beschrijving van Truffle Security en wordt niet door iedere aangeleverde bron onafhankelijk bevestigd.

Wat organisaties moeten doen na een AWS-lek

1. Trek de sleutel direct in of vervang hem

Verwijder of blokkeer elke publiek blootgestelde inlogmogelijkheid en maak alleen een vervangende sleutel aan als toegang nog noodzakelijk is. Een geheim uit een repository verwijderen, een bestand wissen of de Git-geschiedenis herschrijven maakt kopieën die al zijn buitgemaakt niet ongeldig.

2. Schakel root-toegangssleutels uit

AWS-roottoegangssleutels horen niet bij routinematige programmatische toegang. Verwijder root-sleutels en laat workloads gebruikmaken van beheerde identiteiten met zo beperkt mogelijke rechten.

3. Controleer rechten en eigenaarschap

Breng in kaart bij welk account, welke gebruiker, dienst en resources de sleutel hoorde. Geef prioriteit aan sleutels met rootrechten, AdministratorAccess, brede toegang tot gegevens of de mogelijkheid om infrastructuur aan te maken.

4. Onderzoek vóór en na de intrekking

Controleer authenticatieactiviteiten, CloudTrail-registraties, wijzigingen in IAM, nieuw aangemaakte resources en factuurgegevens op verdachte activiteiten. Het intrekken van een sleutel stopt verder gebruik, maar bewijst niet dat de sleutel eerder niet is misbruikt.

5. Vervang langdurige sleutels door tijdelijke identiteiten

Gebruik waar mogelijk tijdelijke IAM-rollen en identiteiten voor workloads in plaats van permanente toegangssleutels. Rechten volgens het principe van minimale toegang beperken de schade wanneer een inloggegeven uitlekt.

6. Stel budgetmeldingen en een responsprocedure in

Configureer waarschuwingen in AWS Budgets en monitoring voor kostenafwijkingen. Stuur meldingen naar contactpersonen die snel maatregelen kunnen nemen. Financiële monitoring is een vangnet, geen vervanging voor secret scanning, sleutelrotatie en periodieke toegangscontroles.

De bredere beveiligingsles

De belangrijkste uitkomst van het onderzoek is niet alleen het ruwe aantal gevonden geheimen. Het is de combinatie van openbare blootstelling, blijvende geldigheid, hoge rechten, extreme ouderdom en beperkte monitoring. Openbare gegevensopslagplaatsen kunnen inloggegevens bewaren lang nadat een organisatie is vergeten waar ze werden gebruikt. Een gekopieerde sleutel kan bruikbaar blijven totdat iemand hem expliciet intrekt.

Voor cloudteams is de veiligste aanname daarom eenvoudig: behandel elke blootgestelde AWS-inloggegevens als gecompromitteerd, controleer waartoe die toegang geeft, trek hem onmiddellijk in of roteer hem en vervang langdurige toegang door tijdelijke identiteiten met minimale rechten.