Blog
Tre minutter til kompromittering: Hvad et virkeligt Kubernetes-angreb lærte os om AI-drevne trusler
Et virkeligt Kubernetes-angreb viser, hvor hurtigt moderne trusler kan udfolde sig. På under tre minutter bevægede angriberen sig gennem miljøet, overtog privilegerede adgange og fjernede spor efter sig. Læs, hvilke erfaringer hændelsen gav om AI-drevne angreb, Zero Trust og moderne cloud-sikkerhed.
Can I help you?
Nicolaj Wichmann
Sales Director, Conscia Danmark
Da Cloud Security Architect Fadi Dasus blev involveret i en kundes sikkerhedshændelse, viste det sig, at angriberen allerede havde gennemført hele angrebskæden. På under tre minutter havde vedkommende bevæget sig gennem miljøet, overtaget privilegerede adgange og fjernet en stor del af sporene efter sig.
Casen handler ikke kun om et kompromitteret Kubernetes-miljø. Den peger på en bredere udvikling i trusselslandskabet, hvor automatisering og AI reducerer tiden fra kompromittering til kontrol fra timer til minutter. Når angreb kan gennemføres så hurtigt, bliver sikkerhed i stigende grad et spørgsmål om at opdage, begrænse og genoprette hurtigere, end angriberen kan bevæge sig gennem miljøet.
Angrebet var overstået, før sikkerhedsteamet nåede at reagere
En tirsdag morgen, modtog Fadi Dasus et opkald fra sin chef. En kunde med et Kubernetes-miljø var blevet kompromitteret. Ingen vidste præcist hvordan. Ingen vidste, hvad angriberne havde opnået. Og ingen vidste, om de stadig befandt sig i miljøet.
Da incident response-teamet begyndte at undersøge hændelsen, gik det hurtigt op for dem, at de allerede var bagefter. Angrebet var overstået.
Det hele skete på under tre minutter
Den første overraskelse var hastigheden.
Fra den første kompromitterede container til fuld kontrol over privilegerede ressourcer i clusteren gik der mindre end tre minutter.
Angriberne startede med at kompromittere en enkelt pod og opnåede dermed et første fodfæste i Kubernetes-miljøet. Herfra bevægede de sig systematisk gennem clusteren ved hjælp af lateral movement mellem pods og containere, mens de ledte efter identiteter og service accounts med højere privilegier.
Målet var kontrol
På et tidspunkt fandt angriberne en service account, som allerede havde omfattende rettigheder i miljøet. Dermed behøvede de ikke længere udnytte sårbarheder eller forsøge yderligere kompromitteringer. De kunne ganske enkelt anvende de eksisterende privilegier til at kortlægge miljøet, identificere kritiske workloads, undersøge netværksforbindelser og få indsigt i, hvor de kunne udvide deres adgang yderligere.
Efterfølgende forsøgte de at eskalere deres adgang endnu mere ved at undersøge mulighederne for container escapes og adgang til underliggende hosts.
Hele angrebet fulgte et velkendt mønster:
- Få adgang til en pod
- Bevæg dig lateralt mellem workloads
- Find privilegerede identiteter
- Eskalér rettigheder
- Fjern sporene
Jeg har aldrig set noget lignende før,” fortæller Fadi. “Det virkede som et angreb, der var programmeret specifikt til miljøet. Angriberne vidste præcis, hvad de ledte efter, gennemførte deres handlinger og forsvandt igen.
Da loggene forsvandt, blev central logmanagement afgørende
En af de første udfordringer for incident response-teamet var manglen på spor.
Angriberne havde fjernet en stor del af den lokale evidens. Logfiler var slettet eller manipuleret, hvilket gjorde det ekstremt vanskeligt at rekonstruere hændelsesforløbet direkte fra clusteren.
Heldigvis var kunden ikke afhængig af lokale logs alene.
Virksomheden benyttede et centraliseret logmanagement-system, som løbende indsamlede og opbevarede logs uden for Kubernetes-miljøet. Det gjorde det muligt at genskabe dele af angrebet og forstå, hvad der var sket.
Ifølge Fadi er central logmanagement ikke længere et “nice to have”. Det er en grundforudsætning for moderne incident response, hvis en sikkerhedshændelse skal håndteres effektivt.
Når angribere aktivt forsøger at slette deres spor, bliver eksternt lagrede logs ofte den eneste kilde til sandheden.
GitOps som sikkerhedsværktøj
Da de tekniske teams begyndte at analysere miljøet, stødte de på endnu en udfordring:
Hvordan så clusteren egentlig ud, før angrebet fandt sted?
Uden et klart referencepunkt kan det være svært at afgøre, hvilke ændringer der er legitime, og hvilke der er introduceret af en angriber.
Her fremhæver Fadi GitOps som en af de mest undervurderede sikkerhedsmekanismer i Kubernetes.
Med GitOps beskrives infrastrukturen deklarativt i Git og fungerer som den autoritative kilde til den ønskede tilstand af miljøet. Hvis nogen ændrer netværkspolitikker, deployer nye workloads eller fjerner sikkerhedskontroller direkte i clusteren, opstår der en afvigelse mellem den ønskede og den faktiske tilstand.
Dermed bliver kompromitteringer synlige hurtigere. Samtidig bliver gendannelse markant enklere.
I stedet for manuelt at rekonstruere miljøet kan platformen automatisk sammenligne den aktuelle tilstand med Git-repositoriet og bringe clusteren tilbage til den ønskede konfiguration.
Mere end logs: Behovet for reel synlighed
Logs fortæller en del af historien. Men i komplekse Kubernetes-miljøer er det ikke altid nok.
For Fadi handler moderne observability om at kunne se, hvordan miljøet opfører sig i realtid:
- Hvilke pods kommunikerer med hinanden?
- Hvilke forbindelser bliver afvist?
- Hvor kommer den mistænkelige trafik fra?
- Hvilke workloads er påvirket?
Hvis man hurtigt kan visualisere trafikken mellem workloads, bliver det lettere at forstå angrebets blast radius og identificere kompromitterede komponenter.
Her peger Fadi blandt andet på moderne eBPF-baserede værktøjer som Cilium og Hubble, der kan give detaljeret indsigt i netværkskommunikation og identitetsbaseret trafik på tværs af Kubernetes-miljøet.
For incident responders kan denne synlighed være forskellen mellem timer og dage, når et angreb skal analyseres og begrænses.
Kubernetes er ikke sikkert som standard
Mange organisationer antager fejlagtigt, at Kubernetes automatisk leverer de nødvendige sikkerhedsbarrierer.
Det gør platformen ikke. Kubernetes er først og fremmest en orkestreringsplatform.
Som standard opererer mange Kubernetes-miljøer i praksis på et relativt fladt netværk, hvor workloads kan kommunikere bredt med hinanden. Hvis en angriber først opnår adgang, kan det derfor skabe gode muligheder for lateral movement.
Derfor anbefaler Fadi en langt mere segmenteret tilgang.
Network Policies bør anvendes aktivt til at begrænse kommunikation mellem workloads. Kritiske systemer bør isoleres. Testmiljøer bør adskilles fra produktionsmiljøer. I nogle tilfælde giver det mening at placere særligt følsomme workloads i dedikerede clusters.
Det vigtigste princip er enkelt:
Start med “deny all”.
Tillad derefter kun den trafik, som rent faktisk er nødvendig.
Runtime security bliver afgørende i en AI-tid
Selv med stærk segmentering og gode logs kan angribere stadig finde vej ind. Derfor var den sidste læring fra hændelsen behovet for stærkere runtime security.
I den konkrete sag kunne kunden se hændelserne, men havde begrænsede muligheder for automatisk at stoppe dem.
Hvis runtime security-løsninger havde været konfigureret til aktiv blokering, kunne forsøg på privilege escalation, container escapes eller uautoriserede shells potentielt være blevet stoppet, allerede mens angrebet var i gang.
Og netop automatisering bliver stadig vigtigere.
Når angreb gennemføres på få minutter, er manuel respons sjældent hurtig nok.
Forsvarsmekanismer skal kunne reagere automatisk.
Zero Trust i Kubernetes handler om arkitektur, ikke produkter
For Fadi peger hele oplevelsen mod én overordnet konklusion:
Zero Trust er ikke et produkt, men en måde at designe platforme på.
I et Kubernetes-miljø betyder det blandt andet:
- En verificerbar source of truth gennem GitOps.
- Fuldt overblik over trafik, identiteter og workloads.
- Segmentering og isolation som standard.
- “Deny by default” frem for implicit tillid.
- Runtime security, der kan håndhæve sikkerheden automatisk.
- En antagelse om, at angriberen allerede kan være inde i miljøet.
Hvis man designer platformen ud fra denne antagelse, bliver målet ikke blot at forhindre kompromittering.
Målet bliver at begrænse konsekvenserne, opdage angreb hurtigere og gendanne miljøet mere effektivt.
Fire ting at tage med
1. Identitet som tillidsanker
- Kryptografisk workload-identitet frem for netværksplacering.
- Kortlivede, audience-bundne credentials ikke langtidsholdbare secrets.
- Ingen stående privilegier: just-in-time adgang gælder også for mennesker, ikke kun workloads.
2. Politik som standard, ikke som undtagelse
- “Deny by default” på netværket og disciplin nok til ikke at åbne RBAC igen med wildcards og cluster-admin.
- Segmentering og isolation som udgangspunkt, ikke som efterfølgende oprydning.
- Namespaces er ikke en sikkerhedsgrænse: delt host kernel betyder delt tillidsdomæne.
- NetworkPolicies lukker netværket, sandboxing lukker kernen, de er to forskellige problemer.
3. Håndhævelse i runtime
- Runtime-sikkerhed, der kan håndhæve politikker automatisk, ikke kun alarmere.
- Verificeret proveniens ved admission: signaturer og attestations skal håndhæves, ikke blot produceres.
- AI kan bruges defensivt til at opdage og reagere på afvigelser hurtigere end mennesker kan. Men den skal være underlagt de samme regler som alt andet: egen identitet, egne privilegier, egen revisionsspor.
4. Verificerbarhed
- En sandhedskilde gennem GitOps: alt er defineret som kode.
- Fuldt overblik over trafik, identiteter og workloads.
- En sandhedskilde gennem GitOps: alt er defineret som kode.
- Fuldt overblik over trafik, identiteter og workloads.
For én ting står tilbage efter hændelsen: Angriberen skulle kun bruge tre minutter.
Det afgørende spørgsmål er ikke, om et angreb sker, men om organisationen kan opdage det, begrænse konsekvenserne og genoprette driften hurtigere, end angriberen kan bevæge sig gennem miljøet.
KONTAKT
Skal vi tale sammen om jeres virksomheds sikkerhed?
Nicolaj Wichmann
Sales Director, Conscia Danmark
Relateret
