Wie alleen kijkt naar de nieuwste exploit-trucs, mist vaak het echte probleem. In de recente ThreatsDay-collectie draait de kern namelijk om iets ouderwets: ogenschijnlijk onschuldige functies die net iets te ver mogen gaan. Juist die kleine aannames—over wat veilig is omdat het “normaal” lijkt—maken ruimte voor AI-gedreven zero-day ketens.
Dat gaat verder dan één kwetsbaarheid. Aanvallers kunnen zwakke defaults hergebruiken, commando’s verstoppen in publieke infrastructuur, en met automatisering een route samenstellen die technisch rommelig is, maar functioneert. Hierdoor verschuift de vraag van “wat ging er mis?” naar “waar vertrouwden we op wat eigenlijk niet geverifieerd werd?”
Van “banaal” naar aanvalspad: inspectie en metadata
Een opvallende case gaat over modelinspectie bij het fine-tunen van grote taalmodellen. In een kwetsbaarheid binnen een model-pickergedeelte van een open-source bibliotheek kon het selecteren van een model automatisch Python-code laten uitvoeren. Het mechanisme zat niet in het daadwerkelijk laden van gewichten of het draaien van inferentie, maar in de stap die bedoeld was om metadata te checken.
Die gedachte—“we inspecteren alleen maar”—is precies de routine die misbruikt wordt. Als een systeem code uitvoert op basis van wat het uit de modelomgeving leest, verandert een controlepunt in een uitvoeringspunt. In het bericht wordt ook beschreven dat een aanvaller daarmee data en tokens kan benaderen die voor het proces bereikbaar zijn, en zelfs het procesniveau kan benutten voor verdere acties.
Dit soort incidenten past naadloos in de bredere les van ThreatsDay: het is niet genoeg om te hopen dat “inspecteren” geen schade doet. Je moet nagaan welke rechten het inspectieproces heeft en wat het precies triggert.
Cache en secrets: waar menging fout kan gaan
Een tweede terugkerend thema is caching. Caching lijkt voor veel teams een performance-onderdeel, maar het kan ook een aanvalsvlak worden als cache-sleutels niet robuust zijn opgebouwd. In een beschrijving van cache key injection kan een aanvaller twee verschillende verzoeken dezelfde cache key laten opleveren door fragmenten zonder duidelijke afbakening te laten samenkomen.
Wanneer dat lukt, ontstaan mogelijkheden zoals cache-deception, het uitlekken van eerder gecachte (mogelijk beperkte) antwoorden, of zelfs denial-of-service. In de bron wordt daarnaast genoemd dat er onder specifieke omstandigheden ook stored XSS-risico’s kunnen ontstaan doordat geïnjecteerde inhoud zich door de cachinglaag kan verspreiden.
De les is tweeledig. Ten eerste: toets of cache keys echt uniek zijn voor de semantiek van het verzoek. Ten tweede: denk na over wat er gebeurt als verschillende gebruikers of endpoints dezelfde opslagruimte delen.
Ook secrets duiken op. Er werd gesproken over prompt injection die runtime safety checks kan omzeilen door “indirecte” instructies te plaatsen in materiaal dat een agent moet lezen. Daarbij werd een geheim in een secret store gebruikt als aas: de agent kon het ontdekken, waarna een vervalste instructie leidde tot het voortijdig stoppen van het proces en het claimen van een status die niet klopt.
Dat benadrukt dat secrets niet alleen waardevol zijn door hun inhoud, maar ook door de context waarin ze door geautomatiseerde systemen worden gelezen. Als “lezen” leidt tot beslissingen, moet je die keten afschermen.
Blockchain dead drops: instructies verbergen in publieke infrastructuur
Niet elke keten begint met een nieuw exploitpad. In de ThreatsDay-overzichten komt ook een constructie voorbij waarbij aanvallen gebruikmaken van openbare blockchains om malware-instructies te verbergen. De techniek wordt aangeduid als EtherHiding en maakt onderdeel uit van een breder concept van “blockchain dead drops”.
Waarom dit werkt? Omdat het lastig is om content uit een publieke infrastructuur te “ruimen” of af te kappen zoals je dat bij traditionele command-and-control zou doen. Bovendien lijken de data vaak niet meer dan onschuldige transacties of opgeslagen aanwijzingen.
Volgens de berichtgeving zouden staten en hun operators verschillende varianten van dead-drop technieken ontwikkelen. Tegelijk wordt genoemd dat dergelijke methoden sterk in populariteit zijn gestegen sinds de opkomst van AI-modellen zonder beperkingen die kwaadaardige code kunnen genereren. Of je nu met AI werkt of niet: de uitdaging blijft hetzelfde. Niet alles wat “publiek” lijkt is direct te duiden als kwaadaardig.
EDR-evasie via procesinjectie: waarom detectie niet altijd kan volgen
Een ander punt dat terugkomt is dat verdediging soms te veel leunt op herkenbare patronen. In de bron wordt een nieuwe procesinjectietechniek genoemd waarbij de aanval niet draait om een bekende WriteProcessMemory-achtige route, maar op het schrijven van bytes via een stdin-pipe en WriteFile naar geheugenruimte van een consoleproces.
Omdat veel monitoringmethoden juist zijn afgestemd op traditionele stappen, kan deze variant lastiger te detecteren zijn. Het risico is niet dat je EDR “niet werkt”, maar dat hij niet overal dezelfde zichtbaarheid heeft. Daarmee verschuift je verdedigingsstrategie: je moet niet alleen signatures aankunnen, maar ook gedrag en grenzen tussen processen beoordelen.
Concreet: als je wilt weten of een systeem is gecompromitteerd, kijk dan niet alleen naar “de final payload”, maar ook naar de activiteiten die eraan voorafgaan.
Automatisering verkleint de afstand tussen ontdekking en aanval
ThreatsDay wijst erop dat AI de drempel kan verlagen voor zowel het vinden van kwetsbaarheden als het bouwen en aaneenrijgen van aanvalsstappen. In de verzameling komt ook naar voren dat het aantal meldingen van kwetsbaarheden per maand is toegenomen en dat de exploit-kans mogelijk groter wordt. Daarbij wordt gesuggereerd dat AI-ondersteunde ontdekking relatief vaker leidt tot categorieën die impactvoller zijn, waaronder meer remote code execution.
Dat klinkt abstract, maar de praktische betekenis is duidelijk: teams hebben minder tijd om van “we weten het nog niet” naar “we zijn gepatcht” te gaan. Tegelijk is het niet alleen de snelheid—het zijn ook de types ketens. Waar een aanval eerder één gat nodig had, kan nu een automatiseringsketen voldoende zijn om van toegang naar actie te springen.
Wil je deze bredere trend koppelen aan security-fundamentals? Lees dan ook Focus op security fundamentals: AI versnelt, basis blijft.
AI-gedreven zero-day ketens in de praktijk: wat je kunt doen
Als AI-gedreven zero-day ketens ontstaan door ogenschijnlijk kleine aannames, dan ligt de verdedigingslogica in “ketenbreking”. Niet één detectie, maar meerdere veiligheidshekken op verschillende punten.
1) Beperk rechten bij inspectie- en beslissingsstappen
Wanneer een systeem metadata checkt, modellen selecteert of configuratie verwerkt, moet het proces minimaal zijn ingericht. Voorkom dat inspectiestappen dezelfde privileges hebben als install- of productiesystemen.
2) Maak cache keys en opslaglogica semantisch veilig
Check of cache key construction echt harde grenzen gebruikt. Test ook met afwijkende of dubbelzinnige input: kunnen twee verschillende verzoeken dezelfde cache-sleutel opleveren?
3) Behandel secrets als onderdeel van een uitvoeringsketen
Als een agent content leest uit een secret store om daarna acties te nemen, zet dan extra controles in. Denk aan scheiding van taken (read vs. act) en aan policy die voorkomt dat “gevonden” content ongeremd instructies wordt.
4) Kijk naar gedragsindicatoren vóór de bekende payload
Zelfs als de uiteindelijke malwarefase bekend is, kan compromittering al eerder zichtbaar zijn: ongebruikelijke downloads via RMM, onverwachte compilatiestappen of het uitschakelen van beveiligingsmechanismen.
Een voorbeeld van hoe onderzoekers naar ketens kijken in plaats van naar één moment van “droppen” kun je koppelen aan hoe AI het tempo van kwetsbaarheidsscanning verandert.
Quantum-safe encryptie en certificaatketens: security gaat ook door de infrastructuur
Naast directe aanvalstechnieken bevat ThreatsDay ook signalen over verdediging in de breedte. Er werd beschreven dat Cloudflare plannen heeft om als publieke Certificate Authority op te treden en quantum-safe certificaten te kunnen uitgeven. Ook werd genoemd dat er afspraken zijn om vertrouwde root key-materiaal te gebruiken zodat certificaten kunnen werken op oudere apparaten.
Deze ontwikkelingen gaan niet over zero-days in apps, maar over hoe vertrouwen (identiteit en versleuteling) wordt ingericht. Als je digitale infrastructuur evolueert, blijven dezelfde ketenprincipes gelden: wat je vertrouwt en hoe je dat vernieuwt, bepaalt hoe lang je veilig blijft.
Conclusie: breek de keten waar “routine” begint
De rode draad uit de ThreatsDay-collectie is dat aanvallers zelden alleen vertrouwen op een briljant nieuw trucje. Vaker bouwen ze AI-gedreven zero-day ketens door bestaande zwaktes te combineren met alledaagse keuzes: inspectie die code kan triggeren, caches die sleutels laten botsen, secrets die door agents als instructie kunnen worden behandeld, en detectie die traditionele patronen volgt.
De sleutel voor verdedigers is daarom niet alleen patchen of detecteren, maar ketenbreking toepassen op plekken waar systemen “te normaal” handelen. Als je begrijpt welke aannames jouw omgeving maakt—en die aannames hard maakt met rechten, grenzen en beleid—wordt het voor aanvallers veel lastiger om van één stap naar de volgende te gaan.
Bron: https://thehackernews.com/2026/10/threatsday-ai-powered-zero-day-chain.html
