Tusindvis af lækkede AWS-nøgler virkede stadig efter flere år

Truffle Securitys undersøgelse fra august 2026 peger på et cloud-sikkerhedsproblem, der både er omfattende og bemærkelsesværdigt langvarigt. Forskerne registrerede 431.875 fund af AWS-hemmeligheder i offentlige kodearkiver, Git-historik, datasæt, Docker-images, containerregistre og logfiler fra continuous integration mellem august 2022 og august 2026. Efter deduplikering og kontrol bestod materialet af 64.024 unikke AWS-nøgler. 145

Det mest alvorlige resultat var ikke blot antallet af eksponerede legitimationsoplysninger, men hvor mange der stadig virkede. Ved en gentest den 10. august 2026 kunne 9.308 af 10.616 komplette legitimationspar stadig godkende en bruger – svarende til cirka 88 procent. 145

Flere nøgler kunne give fuld kontrol over virksomheders AWS-konti

Det verificerede materiale omfattede 10.625 root-legitimationsoplysninger, 48.744 nøgler til IAM-brugere og 4.655 nøgler, som ikke kunne klassificeres. Root-legitimationsoplysninger udgjorde 16,6 procent af de unikke nøgler. 1

Truffle Security identificerede 817 aktive nøgler, der kunne knyttes til virksomheder. Blandt dem var:

• 526 root-nøgler, som har det højeste privilegieniveau på en AWS-konto.
• 242 nøgler til IAM-brugere med AdministratorAccess, en politik, der kan give fuld kontrol over kontoen.
• 768 legitimationsoplysninger i alt, som kunne give en angriber fuld kontrol over en virksomheds AWS-konto.
• 130 aktive root-nøgler til AWS Organizations-managementkonti, hvor et kompromitteret login potentielt kan påvirke medlemskonti i hele organisationen. 13

I en mindre gruppe IAM-brugere, hvor forskerne kunne udlæse politikkerne, havde 976 af 1.157 læsbare brugere – 84 procent – AdministratorAccess. Yderligere 144 havde IAMFullAccess. Truffle understreger, at tallet kun skal ses som en indikation, fordi brugere, der tillader udlæsning af politikker, ikke nødvendigvis repræsenterer alle lækkede IAM-brugere. 1

Hvor mange AWS-konti var berørt?

Det leverede materiale indeholder to kontotal, som ser ud til at dække forskellige udsnit. Én opsummering beskriver sættet på 64.024 nøgler som fordelt på 9.945 forskellige AWS-konti, mens kilderapportens opsummering angiver 50.654 forskellige AWS-konti. Materialet forklarer ikke, hvorfor tallene er forskellige, og de bør derfor ikke behandles som udskiftelige. 1

Risikoen på kontoniveau er dog tydelig: Hundredvis af aktive legitimationsoplysninger kunne knyttes til virksomheder, og 768 kunne give fuld kontrol over en virksomheds AWS-konto. 13

Hugging Face var den største enkeltkilde

Hugging Face stod for 8.482 unikke, aktive AWS-nøgler på tværs af 3.394 offentlige datasæt og var dermed den største enkeltkilde i gennemgangen. Root-legitimationsoplysninger udgjorde 17,9 procent af disse nøgler – den højeste andel af root-nøgler blandt de kilder, som blev fulgt. 125

Eksponeringen blev forstærket af den måde, offentligt kodeindhold kan genbruges på. Kodeudsnit med hemmeligheder kan blive kopieret ind i træningsdatasæt og derefter distribueret gennem flere afledte datasæt. At fjerne en legitimationsoplysning fra det oprindelige kodearkiv betyder derfor ikke nødvendigvis, at alle kopier er væk. 1

AWS-resultatet indgår i en bredere scanning af Hugging Face. Truffle Security oplyser, at virksomheden gennemsøgte 7,6 petabyte og 187 millioner filer og fandt 221.303 aktive, unikke legitimationsoplysninger i 6.003 datasæt. Disse tal dækker alle typer legitimationsoplysninger – ikke kun AWS-nøgler. 6

Mange aktive nøgler var flere år gamle

Blandt 2.903 aktive nøgler, hvor oprettelsesdatoen kunne aflæses, var medianalderen 1.831 dage – cirka fem år. Halvdelen var mere end fem år gamle, den ældste var 17,4 år, og kun 25 nøgler, svarende til 0,9 procent, var oprettet inden for de seneste 30 dage. 1

Kun 398 af de 2.903 nøgler – 13,7 procent – havde en nyere erstatningsnøgle. Det tyder på, at de fleste ikke var blevet roteret, erstattet eller ryddet op efter eksponeringen. 1

Den praktiske lære er enkel: En hemmelighed, der først har været offentlig, bør behandles som permanent kompromitteret – også selv om den oprindelige fil eller repository-post senere er blevet redigeret. Git-historik, containerimages, pakke­artefakter og offentlige datasæt kan bevare tidligere kopier. 1

Manglende budgetalarmer øgede risikoen for kryptomining

Budgetstyring var også sjælden. Af 2.754 konti, hvor indstillingerne kunne aflæses, havde kun 262 – 9,5 procent – konfigureret mindst én budgetalarm. Den typiske alarmgrænse, målt som median, var 8 dollar. 12

Det efterlod 90,5 procent af de læsbare konti uden en registrerbar budgetalarm. En angriber med brugbare legitimationsoplysninger kunne dermed udnytte cloud-computerressourcer til kryptomining eller andre arbejdsbelastninger, før organisationen opdagede det usædvanlige forbrug. 12

De konti, hvor forbrugsdata kunne aflæses, brugte tilsammen 420.631 dollar i juli 2026. Halvtreds brugte mere end 1.000 dollar den måned, mens ni brugte mere end 10.000 dollar. Tallene beskriver de observerede konti og dokumenterer ikke, at forbruget skyldtes misbrug af legitimationsoplysninger. 1

AWS-karantæne betød ikke nødvendigvis øjeblikkelig spærring

Truffle oplyste, at AWS blev observeret til at knytte politikken AWSCompromisedKeyQuarantine til eksponerede IAM-nøgler. Politikken begrænser, hvad en registreret nøgle kan gøre, men deaktiverer ikke nødvendigvis godkendelsen med det samme. 1

Blandt de aktive IAM-nøgler, som blev undersøgt, havde 929 af 7.590 – 12 procent – denne politik. Yderligere 112 havde en ældre version, som AWS stoppede med at anvende i 2023. Truffles resultater tyder på, at nogle nøgler fortsat kunne bruges trods langvarige beskeder om eksponering. 1

En karantænepolitik bør derfor ses som et signal om eksponering – ikke som et bevis på, at hemmeligheden er sikkert pensioneret. Organisationen bør undersøge nøglen, finde dens ejer og rettigheder samt tilbagekalde eller rotere den. 1

Sådan testede forskerne nøglerne

Truffle oplyser, at virksomheden kun gentestede legitimationspar, hvor den havde alle nødvendige oplysninger. Til analyse af konti og privilegier brugte forskerne skrivebeskyttede IAM-kald, én nøgle ad gangen. De offentliggjorde ikke selve nøglematerialet og underrettede alle ejere, som de kunne identificere. 15

Metoden er vigtig for fortolkningen af tallet på 88 procent. Det gælder den delmængde af komplette legitimationspar, som blev gentestet – ikke alle offentlige fund eller alle delvise hemmeligheder, der blev fundet under scanningen. 14

Hvad bør organisationer gøre nu?

Undersøgelsen peger på en kort handlingsliste:

1. Slet root-adgangsnøgler. Truffle vurderer, at root-nøgler ikke har nogen legitim driftsmæssig anvendelse. 1
2. Lav en samlet opgørelse over IAM-adgangsnøgler, inklusive nøgler i kodearkiver, Git-historik, CI-logfiler, images, registre og offentliggjorte datasæt. 1
3. Tilbagekald eller rotér eksponerede legitimationsoplysninger med det samme. Det er ikke nok at slette den synlige kopi, hvis hemmeligheden stadig findes i historiske eller afledte artefakter. 1
4. Fastlæg en maksimal levetid for nøgler og håndhæv rotation. Gamle og ubrugte legitimationsoplysninger bør fjernes i stedet for at være aktive på ubestemt tid. 1
5. Opsæt budgetalarmer. Selv en lav grænse, eksempelvis 10 dollar, kan give et tidligt varsel om uautoriseret forbrug. 1
6. Overvåg AWSCompromisedKeyQuarantine og undersøg politikken som et tegn på, at en legitimationsoplysning kan være eksponeret. 1
7. Brug løbende scanning efter hemmeligheder på tværs af kildekode, historik, build-systemer, containerartefakter, registre og offentliggjorte datasæt. 1

Den centrale advarsel er, at offentlig eksponering ikke er et engangslæk. Uden tilbagekaldelse, rotation og overvågning kan en AWS-legitimationsoplysning forblive en fungerende adgangsvej til cloud-infrastruktur i årevis.