Cyberhelden 73 - Linux Exploits, Five-Eyes AI Advisory en de breach op Trellix
Vandaag nemen Jelle en Marco je mee in de wereld van Linux Kernel Exploits, de advisory van de Five Eyes over het verantwoord gebruik van AI modellen, en de breach van Trellix - een groot cybersecurity bedrijf. Een aflevering zonder Ronald, want die zit of zat in het vliegtuig.
Vragen, opmerkingen, of suggesties? Mail het naar [email protected].
Bronnen
- CopyFail: https://xint.io/blog/copy-fail-linux-distributions
- DirtyFrag: https://github.com/V4bel/dirtyfrag
- Auditd rules voor detectie: https://www.elastic.co/security-labs/copy-fail-dirtyfrag-linux-page-bugs-in-the-wild
- Five-Eyes AI Advisory: https://media.defense.gov/2026/Apr/30/2003922823/-1/-1/0/CAREFUL%20ADOPTION%20OF%20AGENTIC%20AI%20SERVICES_FINAL.PDF
- Trellix data breach: https://www.bleepingcomputer.com/news/security/trellix-discloses-data-breach-after-source-code-repository-hack/

TRANSCRIPTIE
whisperWelkom bij alweer een nieuwe aflevering van Cyberhelden. De podcast waarin we in gesprek gaan met mensen die zich bezighouden met de digitale dreiging. Mijn naam is Ronald Print.
Fuck. Ik lees hier gewoon de tekst voor. Dat klopt niet helemaal. Opnieuw. Ja, oké. Opnieuw. Oké. Welkom bij alweer een nieuwe aflevering van Cyberhelden. De podcast waarin we gesprek gaan met mensen die zich bezighouden met de digitale dreiging. Of eigenlijk gewoon lekker samen kletsen. Mijn naam is Jelle van Haaster en ik zit samen met Marco Kuipers. Vandaag nemen we op zonder Ronald. Ja, klopt. Want Ronald, die zit in het vliegtuig. Ja, eigenlijk zijn vliegtuig die keerde weer om vanwege cabinedrukproblemen. Dus ik denk dat het licht te tukken of zo.
Ja, vorige week dan, want toen zat ik in het vliegtuig en jullie zouden gaan opnemen. Ja, dat is echt balen, want vorige week werd ook gewoon ingehaald door de realiteit. Jij zit in het vliegtuig en terwijl bij Ronald de zonnepanelen door de glasvezelkabels heen vlogen. Dus ja, wat logische issues zou ik maar zeggen. Oké, maar we zijn er weer. Dus wat gaan we vandaag eens doen, Marco? Zonder die Ronald? Ja, we hebben wat nieuwtjes gevonden, zoals Copperfilm Dirty Frack. Zometeen meer? Ja, en ik heb er niet helemaal bij, maar gelukkig jij wel. Maar ik had het zagen dat een agentic AI richtlijn langskomt van de Firevives wel. Dat vond ik ook even interessant, dus daar ben ik wel even ingedoken.
Ja, nice. Ja, en dan gaan we nog even boven Trellix, want daar is ook wat mee gebeurd. Maar eerst, hoe gaat het met ons, Jelle? Ja, er is achter elkaar een Helsinki geweest bij het Hybrid Center of Excellence van de EU. Volgens een weekendje weg geweest met KAMA, KAMA, de Communitaire Academie Clubje en de families. En daarna gelijk een weekje na Monterey, California. Dat was wel vet, maar mijn hersenen zijn wel een beetje musch. En in de stad was gewoon wel fackenvet. Dus Monterey, groot oefenterrein in de buurt daar, Camp Roberts.
14.000 hectare waar je gewoon shit mag doen, die je normaal niet mag doen in Nederland of in de Vrije Staten ook niet in, ze viel dus drones. Maximale range vliegen, zeg maar. Dus kijken hoe hoog je drone kan vliegen, totdat hij naar beneden laazert. Dus dat was echt wel vet. Ik en een collega die waren dus daar aan het kijken. Dus je had zo'n hok met zo'n dakje erop voor alle operators en dat je als je daar stond, dat je gewoon af en toe gewoon inslagen van drones bovenop het golfmetalen dak hoorde en zo. Dat was wel alles wat ik. En dus dat ze live GPS-proving en jamming deden op verzoek.
Dus dat was een Amerikaanse eenheid. En als een clubje of een bedrijfje zei van, ja, kun je eens proberen wat mijn drone doet als ik aan het spoeven of als jullie spoeven of jammen. Ja, dat was vet. Dus je had landingen die totaal fout gingen en dat de drones echt bijna near collisions waren en zo met mensen omdat die drone gewoon niet meer geen command inputs meer kreeg. Ja, dat was vet om te zien. Gewoon keihard nerden, heel veel toffe bedrijfjes. Vet hoor. Ontzettend cool. En was die GPS-proving, was dat dan commerciële of militaire GPS? Geen idee. Ze konden alles. Dus dat was heel vet.
Ze hadden een hele set aan apparaten bij zich. Dus ze konden gewoon breedband jamming doen, zeg maar. Maar ook specifieke kanalen jammen, specifieke frequenties, specifieke alles bijna. Ze hadden gewoon een huge fucking pick up met alleen maar antennes en shit en vermogenen. En weet ik van wat ze allemaal bij elkaar. Hey, maar en jij? Ja, gaat ook lekker hoor. Ik heb twee weken terug met het gezin dat je in Denemarken gezeten, in de landen in Billund. Dus een beetje naar Kordoom van de glijbaan af. En ja, dan komt het toch gewoon weer naar boven dat ik eigenlijk ook gewoon een klein kind in een groot lichaam ben.
Dus weinig techniek die week. Geen lora of pokéball zoals jullie zo mooi zeiden. Maar het was wel even lekker ertussenuit. En verder weinig slaap de afgelopen nacht, omdat ik weer vuist diep in een resource project zit. Het wordt helemaal lijp van mijn nerds night brain, zeg maar. Van hyperfocus. Maar goed. En dan mag je waarschijnlijk niks over zeggen? Nee, nog work in progress. Dus ik ga nog even niks over zeggen. Maar wie weet ooit. Hey, maar jij wel een beetje ingelezen weer naar vorige week in Cyber Security News? Ja, een beetje wel.
En wat mij zo het meeste opviel eigenlijk de afgelopen dagen is dat een researcher die had wat gepubliceerd onder de naam Yellow Key ongeveer vier dagen geleden. Dat is een zero de exploit voor Windows. Als je fysieke toegang hebt tot een Windows apparaat met Bitlocker, dat device encryption, de disk encryption moet ik zeggen. Dan nou, bij deze heeft dat geen zin meer. Met die exploit kun je gewoon die crypto onvoldaan maken. Maar even zo te zeggen, echt insane, echt insane. Bitlocker is dat gebruikt iedereen die een beetje veilig wil omgaan met zijn laptop.
Dus heel veel bedrijfs laptops hebben Bitlocker omdat het idee is, toch? Dat als je het laat flikkeren ergens je laptop, dat je dan precies ja. En dat is nu ja, je mee. Ja, is het alsof het niet bestaat, zeg maar. En de research heeft dus wel een coördineerde fundability disclosure gedaan met Microsoft, met andere woorden gewoon verantwoordelijk gemeld en dat soort zaken. Maar hij heeft uiteindelijk toch dit gedropt, nadat Microsoft volgens hem het embargo had geschonden. En hij lijkt een beetje in de klintjes te liggen bij Microsoft als je een blogpost leest. En ja, wel, oké, dus hij publiekt dit dan best wel heftig.
Gelukkig heeft hij wel het meest gevoelige deel nog geheim gehouden. Dus dat is een stukje waarmee je nog meer features kan omzeilen. Maar ja, de vraag is hoe lang dat natuurlijk standt houden met alle slimme mensen in de wereld die hier waarschijnlijk opgedoken zijn. En nou ja, langzaam maar zeker komen meer technische details naar buiten. Maar volgens die researcher is nog niemand gelukt om de daadwerkelijke technische bug naar boven te halen. Wel echt meer in de volgende aflevering. Dat zullen we zien. Dus voor nu, I guess, houd je laptop onder de arm of zo. En ja, van het afgelopen vrijdag dacht hij van ja, weet je wat?
Ik drop gewoon nog even een exploit voor Windows. Dus hij heeft een local privilege escalation. Oftewel, hoe kan ik op het apparaat in één keer de hoogste rechten krijgen? Het is gewoon een herziener versie van een oude bug die hij al gevonden, die gepatcht zou moeten zijn. Patch blijkt niet goed te werken. Dus ja, weer een cadeautje. En het is wel onduidelijk of hij hier dan wel weer netjes responsible disclosure heeft gedaan. Dat klinkt wel alsof het een bijzondere gast is die een punt wil maken ergens mee of zo. Want het is toch niet echt net proces wat hij dan nu doet. Nee, je kunt ook een discussie beginnen over ja, stel je komt er niet uit met responsible disclosure.
Ga je dan dingen publishen of niet? Juist om ook wat te forceren of het ervoor te horen dat er een patch komt. Ik hoop dat hij in één keer wat meer vertelt over wat nou de exacte reden is, waarom hij dit op deze manier doet en waarom die dus met Microsoft in de klintje lijkt te liggen. Het is een beetje dus. Er zijn allerlei mensen die testen de exploit en het werkt best uit. Maar goed, we blijven nog even in het technische landschap, want we hebben ook nog even wat dingen voor Linux gepost. Die waren gelukkig wel in ieder geval aangeboden voor patches. Maar straks meer details over hoe dat zit met responsible disclosure. Maar het zijn CopyFill en DirtyFrag. Er zijn twee bugs.
Even kijken, 29 april is CopyFill er buiten gekomen en 7 mei DirtyFrag. Ja, dat is dus in acht dagen tijd twee Linux kernel kwetsbaarheden. Dus het diepste deel eigenlijk van het systeem, zeg maar, met de hoogste rechten. Ja, als je dus een van die dingen gebruikt, dan ben je roeit op ongeveer elk modern Linux systeem. Beide hebben een mooi naam. Dus CopyFill en DirtyFrag, een beetje in de traditie van als je een leuke Linux bug hebt of iets ergens die impact heeft, dan verzin je een koel naam. Het lijkt me toch wel leuk om even een keer hier in te duiken zonder al te veel jargon. Maar ik vind gewoon zo vette bugs dat ik dacht van, ga ik gewoon proberen.
Nou, kijken we dan even beginnen bij CopyFill. Als je dus Linux gebruikt en je wil gebruikmaken van een applicatie zoals SU, dus iets aan van gebruikers te wisselen, dat is een programma met speciale rechten. Dus die speciale rechten zorgen ervoor dat als je het juiste wachtwoord kent, dat jij dan eigenlijk onder de rechten van die andere gebruiker iets mag uitvoeren. Ja, en dat noemen we ook wel een SetUID-binary. De eerste keer dat je dat uitvoert, leest de kernel dat hele programma vanaf disk in memory en houdt vast in dat werkgeu. Dat noemen ze dan de PageCache. Dat is superhandig. Want de tweede keer dat je dan dat bestandje aanroet, SU,
dan hoeft de kernel niet naar disk, maar pak je hem uit geheugen. Dat is gewoon een soort performance-optimalisatie. Super snel, super logisch. Want disk is traag en geheugen is snel. Disk IO is gewoon trager en we hebben ook een hele debat op, op starten over hoeveel trager, maar toch voor performance de hele tijd, als je dat van alles uitvoert, is best wel goede performance gain. Maar dan de tricky part, want stel nou, jij kunt op de een of andere manier in die PageCache schrijven en dus de in-memory versie van zo'n SU of andere applicatie aanpassen
zonder dat het bestand disk verandert. De computer denkt gewoon chill, die binary staat hier in mijn cache, mooi, hoef ik niet naar disk. En dan voert hij gewoon ook jou aangepaste versie uit met de speciale rechten van het origineel. Oftewel, als jij dus op die manier dan iets kan wegschrijven in zo'n PageCache, dat jij zonder een wachthoort in te voeren bijvoorbeeld roet kan worden, of de hoogste rechten halen. En voila. En CopyFill en DirtyFact doen dus allebei dat. Ze hebben een manier gevonden om dus wat bytes te schrijven in de PageCache van een SUID binary. En vier bytes is genoeg om een
springtje naar shellcode te installeren. Dan ben jij goed. Dus dan passen ze, switch user SU, passen ze aan. En in dat programmetje wat in memory zit, kunnen ze dan bijvoorbeeld andere logica toevoegen of meer dingen toevoegen die daar eigenlijk niet in thuis worden. Ja, dus eigenlijk zeg je van, en stel, daar staat op, ik moet op adresje 10 beginnen, met code uitvoeren. Dat staat dan zo in de binary op disk, het bestandje. In memory staat dus die copy. Maar die copy hebben ze dus aangepast en dan zeggen ze van,
ja, oké, maar op 10 staat nu niet begin met printen, hallo, maar begin met springen naar code die ik wil dat je uitvoert. Ja, vet. Je past de code flow aan van de applicatie zonder dat dat ding op disk veranderd is. Als je op disk integriteit checks continu doet, zoals bijvoorbeeld onderdeel van je audit scans, heeft dat allemaal geen zin. Hoe kun je dan dit operationaliseren, zeg maar? Want dan moet je wel eerst al toegang hebben tot iemand's machine, toch? Voordat je hier überhaupt iets kunt, want je moet het bij memory kunnen. Dus je hebt iets nodig wat in memory op die switch user edits kan doen.
Ja, ja, ja. Nou, dan gaan we nu even lekker wat meer de diepte nog in, want dan gaan we nu kijken hoe ze dat ooit bedacht hebben. Zoals we beginnen bij CopyTale, gevonden door het Koreaanse onderzoekbedrijf Theori door het team Xynthcode. Ik kan nog mijn naam, Juno Inmas, hoofdauteur. Ze hebben een eigen AI tool, Xynthcode. Die hebben ze losgelaten op de source code van het Linux Crypto subsysteem. Dus eigenlijk alles wat de cryptografie regelt in Linux kernel. En ze hebben hem een hint gegeven. Dus ze hebben hem niet zoals Cloud Mythos, maar losgelaten.
Maar ze hebben gezegd, ga eens kijken, want Splice, dat is een functie, die kan page cache verwijzingen van read-only bestanden in Crypto ScatterList krijgen. Nou, echt, toen ik dat moest researchen, dacht ik, wat is een vrede na mijn ScatterList? Dan moet dat zo doen. Laten we het er even op houden. Ergens waar je met cryptografie dingen kan al dan niet tijdelijk wegschrijven. Even kijken, volgens mij was het een uur scantijd en toen rolde die bug eruit. Dus het is een AI assisted vulnerability research, superleuk. En wat is dan de bug? In een bepaalde cryptotemplate Authentic ESN,
een onderdeeltje van IPsec voor versleuteld VPN verkeer. Daar moet, zeg maar, de functie 2 bytes in de juiste volgorde zetten. En daarvoor gebruikt het een stukje geheugen als klatpapier. Dus die schrijft er even wat neer, leest het weer en gaat terug. En dan hebben ze later, hebben ze dan daar optimalisatie op uitgevoerd. Dan kun je dus eigenlijk, zeg maar, dat stukje wat als klatpapier werd gebruikt, een directe geheugen verwijzig geven. Dus je kunt zeggen, oh, ik heb hier een stukje geheugen voor jou. Daar moet jij straks de output neerschrijven.
Nou, dat gebruikt even als klatpapier en daarna gaat hij dat werkelijk de output schrijven. Ja, dus als jij dan dat weet aan te passen naar bijvoorbeeld die page cache van zo'n ZUID binary, dan gaat dus IPsec zijn bytes wegschrijven in die page cache. Ze hebben dus een punt gevonden waar zij dus invloed hadden over waar die bytes werden weggeschreven. Oké, dus je hebt dat klatpapiertje. Je past die cijfers op het klatpapiertje aan om ergens iets weg te schrijven. Dus je klatpapiertje staat niet die twee cijfers, maar er staat doe iets anders. Ja, dus die 2 bytes hebben ze invloed op.
Maar ze hebben dus ook invloed op wat het klatpapiertje is. Dus ze maken eigenlijk van het klatpapiertje, maken zij die page cache van. Dus zij zeggen, nu zit jij in de page cache, dus die kopie van ZUID bijvoorbeeld, en op deze offset, oftewel op deze positie in dat bestandje, kun je nu jouw klatpapiertje wegschrijven. Dat is best wel creatief. En dus dat betekent dat ze uiteindelijk met 732 bytes aan Python code, dus dat is voor het gemak even 732 karakters, dat ze daarmee kunnen exploiteren.
En het werkt op ongeveer elke distro. Nee, het is wel cryptisch man. Ik kom er gewoon niet even dicht bij in mijn hoofd. Maar het is dat klatpapier, dat schrijf je weg zeg maar naar die input. Dus je zegt positie 10, dit is het klatpapiertje, zit daar. Daar zit een verwijzing, een reference naar het klatpapier. Dat je gewoon arbitrair kunt genereren, zeg maar, bijna. Dat is het klatpapiertje. Ze hebben uitgevonden hoe zij inderdaad een arbitrair adres eigenlijk, zeg maar, daar kunnen krijgen.
Uiteindelijk dus ervoor kunnen zorgen dat die crypto functie, die dus die bytes, die dus tijdelijk even een klatpapiertje heeft, dat die daar zijn bytes neer schrijft. Maar ze hebben invloed op welke bytes dat zij, want dat is voor die cryptotunnel. Ze hebben daar eigenlijk volledig die flow gebruikt om ervoor te zorgen dat allemaal legitieme functies gewoon data wegschrijven naar een Curl-on-memory-object. En daarmee dus eigenlijk ervoor zorgen dat er zo u erop eens, wat zei, er is die codeflow van. En wat kun je hier dan mee? Local route. Dus je doet . slash exploit.py. En dan ben je route.
Wat ze hebben gedaan, ze hebben 23 maart het gereport aan de Linux Kernel team, zeg maar, in die message boards. En een dag later was die, zeg maar, acknowledged. En weer een dag later hebben ze alweer gelijk patches voorgesteld. En eigenlijk vrij snel ernaast een allerlei patches ook uitgekomen. Was wel even wat gedoe met de hele disclosure-tijdlijn, want ze moesten versneld naar buiten brengen omdat er een third party niet goed had nagedacht over
het geheimhouding en zo. Dus toen leek er van alles uit te gaan lekken. Dus hebben ze besloten om het maar te gaan publishen in de hoop dat mensen zeggen, met tips van hoe kun je dat mitigeren. Dat was wel nice, I guess. Dus dat was copy-fill. En dus wel cool dat je dat op disk eigenlijk echt hebt, want ik zei, dat past me wel alleen in memory. En nou zegt dat team dat ze ook nog voor Kubernetes wat cool zou gevonden om dan uit de containers te kunnen escape. En wie weet gaan we daar in de toekomst nog eens het over hebben als ze het blogpost hebben gepubliceerd. Ik vind het wel erg dik dat ze dit allemaal in memory doen. Dus dat hele disk ding wat je zei, dat je elke audit hier overheen kijkt.
Zijn er manieren dat je dit wel zou kunnen detecteren, anders dan gewoon... Ja, dus er wordt een bepaald type socket opengezet. Ik weet niet zo goed hoe die er moet gaan, maar er wordt een bepaald type socket opengezet. En je kunt bijvoorbeeld in je auditlogging die operaties monitoren en dan ook alerts laten genereren in je monitoringssoftware. Dat is een van de mitigaties dat ze hier aanhalen dat dat moet je doen. Om ervoor te zorgen dat je niet volledig gaat.
Daarnaast zijn er natuurlijk allemaal patches uitgebracht. Dat heet ook gewoon zillend de patchen. En je kunt eigenlijk ook zonder problemen de kernel module niet laten laden. Dus je krijgt zeg maar weggooien van het systeem, want dan gebruik je gewoon allerlei userland cryptografie. Dan zou je kunnen zeggen dat is een performance hit. Dan maak je daar echt geen rol van. Dus dat zijn manieren om het te voorzorgen dat je het mitigate en ook een beetje in de gaten hebt. Cool, en die staan ook allemaal op het blog wat ze hadden gerapporteerd. Even denken, in ieder geval die dingen over de kernel module, dat je natuurlijk kan patchen. De andere regels staan volgens mij ook ergens op het internet.
Kunnen we nog even vinden en dan in de show notes publiceren. Oké, maar je had er ook nog eentje. Ja, klopt. Dirtyfract doet eigenlijk hetzelfde. Die schrijft vier bytes in een page cache van een ZUID-binering, maar dan op een hele andere manier. Je gebruikt twee bytes. Dus ze hebben... Ik ben weer kwijt. Wat was ook weer de ZUID-binery? Dus de ZUID-binery is een applicatie met bijzondere rechten op Linux. Dat je dus als je het juiste wachtwoord hebt, of de juiste omstandigheden, of je ruikt juiste rechten, dat je code mag uitvoeren onder de privéleestjes van een andere gebruiker.
Ja, ik ben weer daar. Dus ook als root, maar ook bijvoorbeeld als een andere gebruiker op het systeem. Dirtyfract heeft dus ook weer wat gevonden in die PSEC. Trouwens ook wel grappig dat de bugs er al negen jaar in zitten, ook die vorige die we noemden. Maar er zit in die PSEC een bug waardoor ze een arbitrary 4-by-write kunnen realiseren. Dat is gewoon een schijfoperatie, exploit misbruik van schijfoperatie. En de tweede bug zit in een netwerkprotocol onder AFS. Dat is een van de oude distributie, distributie des faals systeem. En daar hebben ze ook een bug gevonden waarmee ze dus een page cache write voor elkaar kunnen krijgen.
En ze hebben dus twee bugs. Deze keer ga ik even technisch iets minder diep erop in, want we hebben die voorgaaf vanuitvoeren gedaan. Maar het grappige is dat de eerste bug vaak op Ubuntu werkt wel. Maar weer niet op bijvoorbeeld in Red Hat Linux of Debian Base Servers. Maar die andere werkt dan wel weer op Red Hat Linux en Debian Base Servers of op Ubuntu systemen met bepaalde omstandigheden. Dus eigenlijk door ze allebei te gebruiken of allebei naast elkaar te zetten. Ja, kom je op een Linux systeem, doe je .slash exploit en dan flops. En dan heb je een root op ongeveer elk Linux systeem. Oh, en wat ik net zei over CopyFill, over die voortijdige release.
Dat heb ik even verkeerd onthouden. Dat gaat over DirtyFrag. Dus de researcher Hyun Woo Kim heeft netjes gemeld aan de Kernel Metaners. Alleen de Proof of Concept was via een third party op de distributie lijst uitgelekt. Ja, dus toen was het embargo geschonden en toen heeft die gauw zijn report post door je publiek gezet. Want dat had hij gezegd, als het embargo geschonden wordt, dan doe ik dat. Ja. Nou, dus voor de meeste dingen zijn dat patchjes. DirtyFrag waren dus, zijn de patchjes een beetje vertraagd uitgebracht. Ik heb even niet gecheckt wat de allerlaatste status is. Er waren er een paar uit op het moment dat ik het voorbereid had.
Dus zorg er voor dat je alles patcht. En ook overal zijn allerlei audit detection rules voor mogelijk. Dus dan kun je in ieder geval je systemen monitoren of allemaal van dit soort operaties plaatsvinden op je systeem. Oké, dus eigenlijk is heel Linux met meer fails en DirtyHacks dingen is eigenlijk... Elke Linux distro op dit moment die niet gepatcht is, is kwetsbaar voor de capabilities die je net noemde. Die CWs. Ja, eigenlijk wel. Ja, de internet stond eventjes weer een klein beetje in de fik.
Ja, en het is ook best wel reliable. Het is niet alsof het allemaal systemen laat crashen met allemaal moeilijke race conditions. Nee, het is gewoon een scrapje uitvoeren. Dat is wel lijp. Ja, maar goed. Jelle, jij appte iets over een nieuwe richtlijn over AI? Ja, even wat minder technisch. Technisch vind ik ook leuk. Maar het was wel even graven in mijn hoofd met hoe we alles ook weten. Marco, dat was wel lekker. Ja, een trigger. Dus oké, ik ga proberen nog te focussen op die AI richtlijn. Ja, want de Fireflies hebben dus zes nationale cybersecurity agentschappen.
Die hebben een 30 pagina tellen document gepubliceerd namelijk de Careful Adoption of Agentic AI Services. Dus agentic AI is AI die handelingen mag verrichten. Daar is ook een nette definitie van gegeven. Het is dus een LLM, Large Language Model, gebaseerde software die dus zelfstandig kan plannen, beslissen of handelen. En met verbinding ook met externe tools, databases, geheugenopslag, geautomatiseerde workflows, de Albert Heine app. Dat soort. Dat is wel een heel mooi definitie toch? Ik bedoel, ik weet niet of we ergens allemaal formele definitie voor hebben.
Dat ze dit zo formel hadden vastgelegd. Nee, en het is ook wel goed denk ik dat deze agencies zeggen van oké, dit zijn de meest bedreigende applicaties die je kunt hebben namelijk agentic. Weet je dat je gewoon een LLM doet om tegen te babbelen en te vragen over van alles en nog wat. Een beetje als Google gebruiker. Dat is misschien niet zo spannend, maar inderdaad als je dat ding met allerlei andere capabilities integreert, dingen wil laten uitvoeren op je machine, een beetje de clod en de clodbot die we een tijdje hebben gezien, openclaw en zo.
Dat is waar het spannend werkt natuurlijk, dat we al die dingen, daadwerkelijke handelingen laten uitvoeren op systemen. Was ook een zaak, of een productiedatabase removed of zo geloof ik, of het was het ook weer. Dat zeker, ja. En dan volgens Cree shot over van no what did you do? Ja, dat is slink aan het worden. Ja. Nee, dus het was ook wel trouwens vet vorige week, die bedrijven die er waren bij die oefening, die kregen ook allemaal als ze wilden een security audit, een quick scan van 4 uur van een soort pen testing club van de Amerikaanse overheid.
En die het eerste wat zij er bij elke doen, doen bij elke engagement tegenwoordig waar AI in zit, is gewoon het makkelijker is kijken of je die LLM die erin zit, zijn boundaries kunt laten overschrijden, allerlei dingen kunt laten uitvoeren. Want gewoon voor ons ook het meest makkelijk ever, dat je gewoon kunt praten tegen zo'n bot en die kunt vragen om, kun je me even admin geven om al om de database heeft te bekijken, zeg maar. Ja, precies. Dus die definitie is echt wel goed. Ja, en ze zien dus, nou ja, wat net wel een klein beetje aan ze refereren, vijf risicocategorieën, namelijk Privilege Risk.
Die agents, die Agents de KI, die geven natuurlijk vaak heel veel toegangsrechten, zodat ze lekker veel dingen kunnen doen op je systeem. De meerwaarde van die dingen zit namelijk in dat ze een deel van je werk kunnen vervangen. Maar om jouw werk kunnen vervangen, moet ze ook jouw rechten hebben, natuurlijk om dingen te doen op systemen, waardoor je eigenlijk één gecomprimeerde agent, dus iemand heeft toegang tot één van jouw agents, kan al best grote impact hebben als hij ongeveer dezelfde rechten heeft als jou. Of als je dat ding met allerlei API calls, tokens, allemaal verbonden hebt aan alle systemen in een bedrijf of je privé netwerk.
Dat is eigenlijk ook gelijk het tweede risico waar ze dan op ingaan, is eigenlijk design en configuration risk. Als je dit dus verkeerd instelt, dus je geeft die agent geen boundaries mee, of je geeft het systeem waarin de agent opereert geen boundaries mee. Dus de scoping van je systeem doe je verkeerd. Dan kun je dus allerlei grote issues veroorzaken omdat dat ding nou eenmaal zo veel toegang heeft. En wat Marco, waar jij eerder aan gerefereerd in de uitzending, zijn cooperatief. Ze willen heel graag met de user samenwerken.
Het zijn collaborative systems die eigenlijk alles aan willen doen om ervoor te zorgen dat ze de gebruiker zo blij mogelijk maken. Dus als je die scoping verkeerd doet, heb je gewoon een groot issue. Dan moet je ook wel weer een beetje denken aan de least privilege principes die je in alle trainingen en dingen, en wat voor business is gewoon belangrijk is voor met mensen omgaan. Zorg ervoor dat één admin niet alles kan en dan zeg je tegen agent, jij mag daar wel. Ja, zeker. Ja, precies ook omdat we een soort antropomorphisme hebben ermee,
dat we het zien als een mens of zo in plaats van als een systeem of zo. Dat we denken van, oké, ik moet ook AI helpen om zo snel mogelijk of zo goed mogelijk mij te ondersteunen of zo. Waardoor al dat dit soort shit die in software en security management eigenlijk constant terugkomen, een soort van overboord flikkeren als het over AI gaat. Dus dat is wel en ik doe het zelf ook af en toe omdat je een beetje aan het experimenteren bent, dat je denkt, oké, hoe zo? Ja, nee, het is wel leuk om toegang te hebben tot een health data, tot mijn API app, tot alles in je hele systeem, zeg maar.
En als je serieus aan het overwegen bent, oh, misschien is het leuk om dit te connecten met je internetbankvieren. Zoals ik bij OpenClaw zag. Dat zijn wel allemaal linken beslissingen, zeg maar, en heel veel macht in één arme agent. Ja. Een andere risico wat we zien is eigenlijk het behavioral risk, dus het gedragsrisico dat AI en agentic AI natuurlijk nieuwe dingen kan gaan doen. Dus dat een AI denkt van, oké, weet je, het is nu heel optimaal. Ik zie nu al een aantal keer dat je iets doet. Ik denk dat dit een nieuwe regel is die je toe wil passen.
Bijvoorbeeld dat je zegt, ik zie dat je elke keer dat je start dat je, weet ik veel, een bepaald stukje van de database en ergens add of zo. Dat lijkt me heel goed en heel efficiënt. Dat kan ook automatiseren voor je. Dus dat er eigenlijk zaken oppoppen in het gedrag van een LLM, want LLM is natuurlijk deterministisch stochastisch. Dus we hebben bepaald dat dat ding niet altijd dezelfde output moet genereren. Dat vinden we als mensen heel lekker. Dus dat ding, dat kan gewoon natuurlijk nieuwe gedrag vertonen, waardoor jij in een keer grote risico's in je hele prodsysteem hebt.
Dus laat ze alsjeblieft niet los op prod. En dan zeggen ze ook nog een keer, dus je hebt het gedragsrisico, maar... Met productie bedoel je productie, toch? Productievergeving. Ja, zeker. En dan de structural risk. Zie ze dus de afhankelijkheid ketens tussen agents, subagents en de modellen waarop die lopen. Dat zie je natuurlijk ook wel deels in de hele discussie met het ministerie van Defensie in de Verenigde Staten. Het gebruik van antropics modellen, van OpenAI, de modellen.
Dus al die modellen waar dit op opereert, dat is allemaal een soort... Wij vertrouwen dat die modellen goed zijn en we gaan ervan uit dat die modellen constant gebruikt kunnen worden. En dat zie je ook dus heel veel van die startups die vorige week bijvoorbeeld zag. Die maken heel veel gebruik van de OpenAI API-con. Dat is een lekker Amerikaanse bedrijf. Het waren Amerikaanse bedrijfs allemaal. Maar als je dan vanuit Europees perspectief zegt van hey, kun je ook tegen Mistral praten of tegen LocalLM's en zo. Dus je heel veel van die bedrijven nadenkt van fuck, nee, maar waarom zouden we dat willen? Nou ja, dan komen wij met hele faalsoevereiniteit.
Wat nu als je geen internet hebt. Dus er zit een best wel structureel risico in dat we maar vertrouwen op dat er altijd internet is en dat die modellen altijd beschikbaar zijn. En dat je toegang hebt tot een heel dik fronteer model. Terwijl... Maar zit daar ook een stuk betrouwbaarheid van het model zelf in? Dus als je bijvoorbeeld kijkt hoe de... Je ziet toch een klein beetje verschil tussen hoe bijvoorbeeld Chinese modellen en Amerikaanse modellen omgaan met bepaalde stukken informatie. Gaat het daar ook over die structural risk? Ja, zeker. Dus dat structureel is denk ik inderdaad het hele...
Het systeem als geheel wat aan elkaar hangt van allerlei availabilities en weet ik veel. En ook inderdaad weights. Dus hoe zijn de modellen getraind? En dus de constraints, het harnas, wat zo'n model meegeven is ook. Bijvoorbeeld dat weet ik veel. De Chinese modellen zeggen je mag niks zeggen over Shiji, over de grote partijleider. Of dat een OpenAI instructies, de instructies die je niet als gebruiker ziet. Zit een heel stuk in over dat hij niet over goblins mag praten. Omdat OpenAI en GPT dus een hele tijd te veel over goblins begon te praten.
Omdat het namelijk in de beginfase van het model er heel veel interacties daarover zijn geweest. Dus je hebt zo'n tijdje... Dus er staat letterlijk in van never never talk about goblins unless the user explicitly asks for it. Ja, dus dit soort constraints zitten ook allemaal onder de opslag zijn natuurlijk in die modellen. Ja, en dat is eigenlijk ook gelijk het vijfde risico dan. Dus dat zijn alle vijf risico's die ze dan benoemen. De grote risico's is gewoon de hele supply chain risk. Dus de third party tools, alles wat je installeert aan scale of in cloud, een capability of een connector.
De APIs waarmee je het laat praten, de websites waar je tegen laat praten. Je ziet er gewoon heel zelf eigenlijk voelt het misschien als een soort magie op de achtergrond. Maar ja, op de achtergrond, als je dat werk naar de code kijkt, is natuurlijk heel veel third party applications. Waar je in principe geen toegang toe hebt. Net zoals bij alle andere software development, al die plugins die je installeert, alle MCPs die je van GitHub trekt. Ja, je weet niet wie de eigenaar is vaak. Je weet niet of de versie die je nu gebruikt nog veilig is in de toekomst. Als er een of andere maintainer komt.
Ja, dat zien ze als vijf flinke dingen aan het gebruik van agent API. Die laatste was ook bij Open Cloud toch gelijk ter sprake. Dat zodra Open Cloud een beetje het werd, toen werden er gelijk een moment met scales gepublished. Die allerlei geheimen ontfutselden aan stuurdaarners, de 2 servers en dat soort dingen. Inderdaad, een API of een MCP met 80 tool calls en dat je eigenlijk niet meer weet welke tool wat doet en wat er op de achtergrond gebeurt. Uit het documenten hebben we ook een concreet voorbeeld zitten. Dus een agent met rewrite-rechten en edit-rechten, denk ik, breed verwijderd firewall logs naar dat die een prompt was gegeven.
Ja, dat voorbeeld. Dus je hebt die firewall. Een aanvaller wil dat die regels verdwijnen zodat hij lekker door je firewall heen en weer kan communiceren. En dan gevolgst tegen je agent, AI zegt van verwijder de logs, want dat vind ik noodzakelijk. Dat is natuurlijk een risico en die heeft dat niet één van die vijf risicocategorieën, maar meer. Dus bijvoorbeeld dat privilege-risk, risico 1 en dat gedragsrisico, risico 3. Namelijk dat je zo tool dingen kunt laten doen die je als ooit ontwerper misschien niet zo bedoeld had. Tricky hoor. Ik ben echt heel benieuwd hoe dat in de toekomst eruit gaat zien, want je wil steeds meer AI gaan hebben in de managementlaag van apparatuur.
En als je dan zo'n aanvaller komt en je zegt, ah mijn disk space loopt vol, je moet echt alle logs weggooien. En dan kijken wat er gebeurt. Ja precies en hoe constrain je dat dan? Dus hoe ga je, zelfs OpenAI moet tegen zijn GPT zeggen, praat niet over goblins. Als zelfs de FrontierLab het lab problemen heeft om modellen te harnassen, constrainen, zeg maar. Hoe ga je dat als gebruiker doen? Dus dat zit wel iets in, ja, dus uiteindelijk kom je denk ik bij heel veel basics uit. Ja en dat zit eigenlijk ook wel een beetje in het document.
Dus ze zeggen echt een hele reeks aan bekende controls en maar een paar die echt specifieke AI zijn. Het meest open deur. Zorg dat je weet wat je agents doet en zorg dat je op de juiste punten controle houdt. En zo'n facking open deur vind je wel zo natuurlijk. En nice. Heb jij dan de gelijk idee dat je denkt, dit zou ik zo inrichten Marco? Voor wat betreft inzicht houden bedoel je? Ja. Nou kijk, de controle houden is natuurlijk wel, ik werk zelf graag met shortlift tokens en authentication tokens. Dus dat bijvoorbeeld Claude, als ik die toegang geef, dat hij maar een bepaalde tijd iets kan doen.
En daarna is dat token niet meer geldig. Dus dat is al om ervoor te zorgen dat hij niet te lang toegang heeft. Daarnaast doe ik dan ook in mijn software role-based access control inbouwen. Dat ik gewoon zeg, ja mijn agent mag niet alles. Dus stel ik zou toegang geven tot mijn bankieren, dan ga ik proberen zo... Heb ik nog niet, maar stel ik wil dat ooit, dan ga ik er wel zo inrichten dat hij... Niet eens schrijfoperaties, maar wel read operations komt. Want vaak gaat het over inzicht en niet zozeer over dat hij ook transacties kan doen voor mij. Dus dat is in ieder geval een stukje controle houden. En zorgen dat je weet wat je doet, ja genoeg logging. Er is altijd vragen om de AI agent om zijn geheugen vast te leggen, de bevindingen vast te leggen.
Zijn reasoning volgen. Maar ja als je een agent hebt, dan kan dat niet de hele tijd. Want dan heb je een dagdagen aan dat monitoren. Dus ik denk dat dat ook een beetje experimenterend is. Ik weet er al wat voor. Nee, niet. Ik vind die die jij noemt over van oké, short-lived tokens en zo. Want afvoer is geit irritant dat je constant die tokens moet updaten en zo. Maar dat is natuurlijk gebruiksmak versus veiligheid. En inderdaad de liefde voor letjes. Zoals als we op een apart account zitten wat beperkte rechten heeft en zo. Dat is misschien ook wel een hele goede. Maar als basis gebruiker is het gewoon heel veel gelul.
Want je wilt natuurlijk zo snel mogelijk, zoveel mogelijk rendement halen uit een... Ja, 100%. Agent. Maar voor het bedrijf? Ja, als gebruiker denk ik dat je dan gewoon moet nadenken over... Ik ga hem nu volledig toe gaan geven tot mijn WhatsApp of mijn mail. Dat je in ieder geval bij stil staat. Dat je weet wat je hem laat doen, weet je wel. Dat het ook mis kan gaan. Ja, precies. Ja, er staan nog een paar van die open deuren in wel. Dus introduceer meerdere lagen. Dus defense in depth.
Wat we natuurlijk kennen uit cyber security, informatie security. Dit is gewoon een van de dingen die al heel current... Of wel heel current. We weten allemaal dat het in principe zo zou moeten. Dus dat is eigenlijk wat Marko denk ik net al zegt. Over gewoon meerdere lagen inbouwen, monitoring hebben. Zorgen dat je niet alleen vertrouwt op de logging van je agent. Want die heeft dezelfde risico's. Als die wat net benoemd is. Je kunt er niet op vertrouwen dat je agent voldoende logging produceert. Omdat die namelijk gewoon gestuurd kan worden. Om geen logging te genereren.
Of om de firewall logs en al je logging logica te verwijderen. Dus ja, en dan denk ik... De laatste die ik wel wel mooi vind is van... Probeer het eerst in een sandbox omgeving. Doe gewoon die hele development pipeline goed. Ga testen wat dat ding kan. En laat het daarna los. En zorg dat je daar gewoon een goed onderzoek naar doet. Over hoe je je agentic AI wilt toepassen in een bedrijfsnetwerk. En dat vind ik denk ik wel de beste aanbeveling die erin zit. Doe het niet zomaar los later. Want ik weet dat er heel veel incentives zijn voor bedrijven om het te doen.
Omdat je dienstverlenen goedkoper moet worden. Dat je minder mensen hebt. Dat je helemaal omkomt in je seamlogging. En de alerts van je detectie logica. Maar uiteindelijk is het natuurlijk wel een spannende handeling. En we zien het nu al af en toe misschien te veel als een no-brainer. Later de AI tegenaan gooien. Ik bouw een product. Er moet wel AI in zitten. Want het moet AI enabled zijn. Want anders verkook ik het niet. Maar doe het wel bewust. En dat is een hele mooie aanbeveling. Oké. Ja, het voelt nog steeds als heel veel open deuren.
En tegelijkertijd, ik denk dat het wel heel belangrijk is dat die grote agencies dit nu uitbrengen. Ja, maar wij doen toch ook eens met de MCP-server bij CYBERELDE. Ja, klopt. We hebben er ook eentje draaien. Die heeft toch gewoon toegekoet tot alles. Nou, ik vind me koor niet te veel. Maar uiteindelijk hebben we daar natuurlijk wel authenticate en dat soort dingen op. Maar ja, die kan ons helpen in onze aflevering voorbereiding. En ik zit wel gelijk te denken van, heb ik daar alles wel goed in gegeven? Dat voelt mij wel redelijk.
Ik ken de maintainer wel vrij goed. Dus dat is... Oké. Gelukkig kennen we die. En dat is Marco natuurlijk. Oké, dus dat is misbruik van generatieve AI en wat je daar eventueel tegen kunt doen. Was het ook... Je had nog iets gevonden over Trellix. Had daar een AI-angle aan of niet? Dat is een goede vraag. We weten eigenlijk niet. Want inderdaad Trellix, dat is een cybersecurity bedrijf, de voorloper van McAfee, zeg maar. Zij hebben op hun website bekend gemaakt dat op 2 mei dat een ongeautoriseerde partij toegang had tot... ...A portion of our source code repository.
Dus een deel van hun broncode... Dus de plaats waar hun broncode staat is opgeslagen eigenlijk voor hun cybersecurity tools. Ze komen voor het uit McAfee. Dus kun je je voorstellen dat ze die AV-software nog hebben. Ze hebben allerlei threat intel dingen en andere cooler security applicaties en software. Hoe vaak ben je dan als je dit hoort? Dus als iemand toegang heeft dat je broncode, wat kan er aanvallen ermee? Als je broncode hebt van bijvoorbeeld een AV-boer of een IDR-product, dan... Als je maar genoeg broncode hebt, dan leer je natuurlijk heel goed hoe een detectielogica werkt.
Ja, als aanvaller kun je dan natuurlijk jouw C2 malware, whatever you're going to use... ...kun je dus aanpassen en zo maken dat het door die producten niet meer wordt opgepikt. Nou, forensische experts hebben ze ingehuurd. Law enforcement is geïnformeerd. En ze claimen dat er geen bewijs is dat broncode ook daadwerkelijk buitgemaakt is. Op 7 mei, vijf dagen later, publiceert Ransom House, een ransomwerkgroep, op hun leaked site, op de dark web. Daar publiceren ze zeven screenshots.
En die screenshots zijn best wel interessant, want wat zie je dan in die screenshots? Je ziet dan broncode-repoor stories, maar ook de backend systemen. Dus al de VMware v-centre, dus dat is, ik noem het maar even het beheer van de backbone-frame-netwerk. Dan kun je server virtualisation, management doen. En ook de VMware v-centre consoles en Dell EMC management consoles. Dat zijn allemaal plekken waar virtualisatie, storage en alles allemaal te beheren is. En als daar een acteur binnen zit, dan zit ze toch wel een beetje in de kern van je netwerk, zal ik maar zeggen.
Een beetje, een heel klein beetje. Een heel klein beetje, ja. En nou zou je nog kunnen zeggen, is dat maar een deel van het netwerk die minder relevant is. Maar toch, het wijst er wel, ze zitten diep in het netwerk. In principe, als je op zo'n plek zit en het is maar diep genoeg in het netwerk, dan kun je eigenlijk overal bij. Want vanuit zo'n virtualisatie omgeving kun je gewoon bijna alles gaan uitlezen en kun je gewoon feest vieren. Ja, dus als dan Trellix zegt, er is geen broncode buitgemaakt en dat soort dingen. Nou, dat blijkt dan eigenlijk uit de screenshots dat dat zeer waarschijnlijk toch wel anders ligt.
Oké, dus het blijkt dus dat die acteur er wel gewoon binnen zit en dan niet een klein beetje toegang heeft tot het netwerk. Maar gewoon het vuist diep in het netwerk zit. Wat denk jij dat ze daar proberen te halen? Wat heb je hier aan? Wat ze precies proberen te halen, dat weet ik niet. Ik denk dat ze de data voor heel veel geld zouden kunnen verkopen. Want broncode van een IDR product is voor de malicious kant, de aanvallende kant natuurlijk super interessant. Want als jij de broncode van IDR producten in de hele levens zou hebben en dan kun je natuurlijk gaan uitzoeken hoe die detectielogica werkt.
Dus waar gaat die software op af? Misschien zit er soms ook wel een bypass in. Dat als je een trucje uithaalt dat je dan daar dus voorbij kan komen. Ja, dat is natuurlijk vanavond wel eens interessant. Want dan kunnen ze hun malware en hun tools zo schrijven dat ze zeer waarschijnlijk minder goed opgemerkt worden door die producten. En als je dan 50.000 klanten hebt, dan is dat best wel een probleem. Dus het gelijk is 50.000 klanten ongeveer. Zo. Het is best wel... Dus ja, wat ze precies willen doen, ik denk die broncode is een interessant target. En daarnaast is er een renselberggroep. Die wil ik nog geld verdienen.
Wat het wel bijzonder maakt is dat het natuurlijk een cybersecurity bedrijf is. Het doet toch altijd een beetje pijn als een cybersecurity bedrijf zelf wordt gepot. Het kan, everybody makes mistakes, maar het voelt gewoon een beetje heftig. 50.000 klanten, ongeveer 200 miljoen endpoints beschermd met software van Trellix. Het is best grote omvang. Tering, zeker. Ja, en FireEye, die dus, dus McAfee en FireEye zijn samen gegaan tot Trellix. En FireEye werd in 2020 al te grazen genomen door SolarWinds. Maar bij de... Even kijken, ze hadden toen die tools gestolen van Duin.
Ja, en dan nu zes jaar later eigenlijk ook weer een issue. Dat doet toch zeer. Niemand is onvelbaar. Er is een mogelijke link met een supply chainaanval die gaande is. Want security week, dat de timing goed past bij een bredere campagne van team PCB en lapses. Verschillende actoren. Ja, dat raakt ook andere security bedrijven, of andere vendors. Bijvoorbeeld ook Bitwardens, de password manager. Geen zorgen er niet de hele Bitwarden, maar een deel van de applicatie die alleen door power users gebruikt wordt. Maar die verbinding is onbevestigd. Maar het is in hetzelfde patroon dat het toch wel lijkt dat aanvallers ook echt steeds meer
verschuiven naar securitypartijen. Ook wel een beetje wat wij. Wij zeiden toch ook over van, oké, niet al je vertrouwen op één zo'n partij, zeg maar. Dus als je zo'n AV, antivirus of IDR boer, die heeft natuurlijk heel veel toegang tot je systemen. En daarmee is het natuurlijk een soort supernode en een supergoed target voor aanvallers. Om te pakken. Want dat ding heeft nou eenmaal zoveel access tot je systemen en het wordt gebruikt om heel kritieke delen van netwerken veilig te houden. En ook minder kritieke delen. Maar het is dus gewoon een heel aantrekkelijk target.
En dit laat dat zien volgens mij. Ik denk dat daar zeker een kern van waarheid in zit. Dat je, ik herf dat je dan remote overal zo maar allemaal bij kan. Dat valt te betwijfelen, maar het is in ieder geval wel pijnlijk dat eigenlijk nu zeg maar een beetje de integriteit van die software toch een beetje aangetast is. Denk jij dat Trellex toch nog klanten heeft over een paar maanden? Nee, zo'n grote partij met zoveel grote klanten ook, die gaan echt niet zomaar overstappen. Ik denk, weet je, er is nog heel weinig naar buiten gebracht over dat werkelijk wat er gebeurd is, dat werkelijk wat er buiten gemaakt is. Er is nog heel veel vaag. Net voordat we gingen opnemen ook nog even snel zitten zoeken van, hoor, kan ik ergens
nog wat nieuws vinden erover? Het is nog, ik denk dat het nog opvolger, ik hoop dat het nog opvolger krijgt dat het niet wel helder wordt. Ja, waar zijn we aan toe? Ja, maar vaagheid voor een groot bedrijf en cybersecurity vendor is natuurlijk wel, link, wat je wil geen vaagheid in je security product hebben. Je verwacht ook van zo'n grote partij dat die zijn hele incident respons en recovery process op orde heeft en dat die ook misschien het goede voorbeeld zou laten zien over communiceren over een incident. Ja, tot nu toe krijg ik er een beetje audio vibes van. Oké, maar dus zonder Ronald best wel een zippe aflevering gemaakt.
De staat van het internet. Dat is ook gewoon cybersecurity, denk ik. Af en toe heb je van die weken dat je denkt van, wat komt er in vredesnamen allemaal uit? Ik zat er niet zo in, maar ik ben er weer. Ik ben me lekker positief over de hele cyberheden en onze maatregelen. Ja, het was wel inderdaad afgelopen week turbulent op het internet. Ja, maar we gaan even de outro proberen te pakken. Je kunt natuurlijk vragen opsturen naar vragen. At cyberhelden.nl.
Ja, nee, mocht je onderwerpen hebben, gasten of feedback, het is allemaal van harte. Welkom. Elke week kan je weer een nieuwe aflevering van Cyberhelden luisteren. Onze gesprekken met cyberhelden kan je terug luisteren via Spotify en je favoriete podcast app. Vergeet ook niet te subscriben, want dan krijg je vanzelf een notificatie als er weer een nieuwe aflevering klaarstaat. Veel dank voor het luisteren en graag tot de volgende keer. Lekker Marco, tot de volgende keer. Later.


