Cybersecurity Student · Future Red Team / Penetration Tester
Cybersecurity Student · Toekomstig Red Team / Penetration Tester
The first time I truly understood what a hacker was, I wasn't reading a book. I was watching someone on YouTube methodically disassemble a login system — layer by layer, explaining exactly where it broke and why. I remember thinking: that's not destruction. That's the deepest possible understanding of something.
From there it snowballed. I followed hackers online, watched every film I could find about it, and started testing things myself. Minecraft was my first playground — finding server exploits, experimenting with what was possible, learning how systems behaved when you pushed them past their limits. I didn't know it at the time, but I was already doing the thing I'd end up studying for years.
In secondary school I chose Electronics & ICT — not by accident, but because I wanted a technical foundation, not just theory. By the time Thomas More offered a Cybersecurity programme, the decision had already been made long before I ever visited an open day. I knew exactly where I was going.
De eerste keer dat ik echt begreep wat een hacker was, las ik geen boek. Ik keek naar iemand op YouTube die methodisch een loginsysteem uitelkaar haalde — laag voor laag, precies uitlegde waar het brak en waarom. Ik dacht: dat is geen vernietiging. Dat is de diepste manier om iets te begrijpen.
Daarna ging het snel. Ik volgde hackers online, keek elke film die ik kon vinden, en begon dingen zelf te testen. Minecraft was mijn eerste speeltuin — server-exploits ontdekken, experimenteren met wat mogelijk was, leren hoe systemen zich gedragen als je ze tot hun limiet duwt.
Op school koos ik voor Elektronica & ICT — niet toevallig, maar omdat ik een technisch fundament wilde. Toen Thomas More een Cybersecurity-programma aanbood, was de beslissing al lang voor de open dag gemaakt. Ik wist precies waar ik naartoe ging.
I'm not going to pretend I'm the most disciplined student in the room. I'm not the one who attends every lecture, keeps perfect notes, and starts assignments two weeks early. That person exists — I've met them — and I'm not them. That's fine. We're different machines.
What I am is someone who comes alive under impossible conditions. There's a version of me that had three days before an exam, a stack of material I'd barely seen, and a choice: give up or go all in. I stayed up until 4am two nights running. I built a map of everything I didn't understand and filled every gap, one by one. I passed. Not barely — I passed. Not because I'm particularly gifted, but because when there's no option left except fight, something in me shifts gear.
The real challenge — the one I'm still working on — is bringing that same intensity to the quiet moments. The weeks without a deadline. The periods where no one is watching. That's the work I'm doing on myself right now. Not making excuses for it. Not hiding it. Just being honest about where I'm growing.
Ik ga niet doen alsof ik de meest gedisciplineerde student in de kamer ben. Ik ben niet degene die elke les bijwoont, perfecte notities bijhoudt en taken twee weken vroeg begint. Dat type bestaat — ik heb het ontmoet — en ik ben het niet. Dat is oké. We zijn verschillende machines.
Wat ik wél ben, is iemand die tot leven komt onder onmogelijke omstandigheden. Er is een versie van mij die drie dagen voor een examen stond, een berg stof die ik nauwelijks had gezien, en een keuze: opgeven of alles geven. Ik bleef op tot 4 uur's nachts, twee nachten op rij. Ik maakte een kaart van alles wat ik niet begreep en vulde elk gat in. Ik slaagde. Niet ternauwernood — ik slaagde. Niet omdat ik bijzonder getalenteerd ben, maar omdat als er geen andere optie is, iets in mij een andere versnelling inschakelt.
De echte uitdaging — die ik nog steeds aanpak — is die intensiteit ook brengen in de rustige momenten. De weken zonder deadline. De perioden waar niemand meekijkt. Dat is het werk dat ik nu op mezelf doe.
"Pressure doesn't break me. "Druk breekt me niet. It shows exactly how far I'm willing to go." Het laat zien hoe ver ik bereid ben te gaan."
Doesn't just survive high-stakes situations — performs best in them. Deadline pressure is a feature, not a bug.
Overleeft niet alleen hoge-druk situaties — presteert er het beste in. Deadline-druk is een feature, geen bug.
Naturally breaks everything into components. Can't look at a system without asking: where does this break?
Breekt alles van nature op in componenten. Kan een systeem niet bekijken zonder te vragen: waar breekt dit?
Knows his weaknesses as clearly as his strengths. Not performing growth — actually doing it.
Kent zijn zwaktes even helder als zijn sterkte. Niet groeien als show — het echt doen.
When fully on, the output is undeniable. Working on making that consistency, not just the peaks.
Wanneer volledig aan staat, is de output onmiskenbaar. Werkt aan de consistentie, niet alleen de pieken.
The hardest stretch of the past few years didn't happen in a classroom. It happened in life. There were weeks I couldn't find a reason to open my laptop. Periods where everything I was supposed to be building felt pointless — where showing up felt impossible and not showing up felt even worse.
I fell behind. I skipped classes. I made decisions that cost me. And then — slowly, messily, without a single clean turning point — I came back. Not because it suddenly got easier. Because I decided that no matter what was going on around me, I could still control what I built in spite of it.
Those periods also forced me to grow in ways school never would have. I've become more honest with myself, more willing to sit in discomfort, more capable of communicating what I actually think — especially with people I trust. The next step is doing that in every room, not just the comfortable ones. That's the part I'm actively working on.
De zwaarste periode van de afgelopen jaren speelde zich niet af in een klaslokaal. Het speelde zich af in het leven. Er waren weken dat ik geen reden kon vinden om mijn laptop te openen. Perioden waar alles wat ik moest bouwen zinloos voelde — waar opdagen onmogelijk voelde en niet opdagen nog erger.
Ik raakte achterop. Sloeg lessen over. Nam beslissingen die me iets kostten. En toen — langzaam, rommelig, zonder een enkel clean kantelpunt — came ik terug. Niet omdat het plotseling makkelijker werd. Omdat ik besloot dat wat er ook om me heen speelde, ik kon nog steeds controleren wat ik desondanks bouwde.
Die perioden dwongen me ook te groeien op manieren die school nooit zou hebben gedaan. Ik ben eerlijker geworden met mezelf, meer bereid om in ongemak te zitten, meer in staat te communiceren wat ik echt denk. De volgende stap is dat in elke kamer doen, niet alleen de comfortabele. Dáár werk ik actief aan.
Stronger communicator. More self-aware. Actively pushing into unfamiliar group situations instead of avoiding them. Still imperfect — but moving forward on purpose.
Sterkere communicator. Meer zelfbewust. Actief in onbekende groepssituaties stappen in plaats van ze te vermijden. Nog steeds imperfect — maar bewust vooruit.
Not a past-tense resume. A present-tense snapshot of where things stand right now.
Geen cv in de verleden tijd. Een snapshot in de tegenwoordige tijd van waar dingen nu staan.
Six real projects. Not demos — things that actually run, with real constraints, real teammates, and real lessons earned the hard way.
Zes echte projecten. Geen demo's — dingen die echt draaien, met echte beperkingen, echte teamgenoten en echte lessen op de harde manier geleerd.
A live parcel tracking platform with hardware and software built from scratch. We built a physical GPS tracker using an ESP32 that read coordinates and pushed them to our database via an API key — and built the full web platform on top: ~1 second live updates over WebSockets, JWT authentication with role-based access, and a real-time dashboard showing parcel movement on a map. The hardware feeds the software. Both sides had to work together.
Een live pakkettracking platform met hardware en software volledig zelf gebouwd. We bouwden een fysieke GPS-tracker met een ESP32 die coördinaten uitleest en via een API-sleutel naar onze database stuurt — en daar bovenop het volledige webplatform: ~1 seconde live updates via WebSockets, JWT-authenticatie met rolgebaseerde toegang, en een real-time dashboard dat pakketbeweging op een kaart toont. De hardware voedt de software. Beide kanten moesten samenwerken.
How real-time architecture actually behaves under pressure — WebSocket lifecycle management, graceful reconnections, and keeping client/server state in sync when events arrive out of order. I implemented JWT auth flows properly for the first time: separate access and refresh tokens, silent refresh without breaking the session, role-based route protection. The biggest shift was moving from "does this work?" to "is this reliable when real users push it?" — they're completely different questions.
Hoe real-time architectuur zich echt gedraagt onder druk — WebSocket lifecycle management, graceful reconnecties, en client/server state synchroon houden als events buiten volgorde aankomen. Ik implementeerde JWT auth-flows correct voor het eerst: aparte access- en refresh-tokens, silent refresh zonder sessie te breken, rolgebaseerde routebeveiliging. De grootste shift was van "werkt dit?" naar "is dit betrouwbaar als echte gebruikers het pushen?"
Keeping the tracking map accurate when GPS packets arrived out of sequence. The server was fast, but network jitter meant the client sometimes received position updates in the wrong order — making the marker jump backwards on the map. Fixed it by attaching timestamps server-side and sorting on the client before rendering. A small bug that taught me a lot about distributed timing.
De trackingkaart accuraat houden wanneer GPS-pakketten buiten volgorde aankwamen. Het netwerk veroorzaakte jitter waardoor de client soms positie-updates in de verkeerde volgorde ontving — de marker sprong terug op de kaart. Opgelost door server-side timestamps toe te voegen en op de client te sorteren voor rendering.
A real server environment for a client — not a sandbox, not a mock. The first version of the website is live, the CI pipeline builds it into a container image on every push, VMs are running with NFS-backed shared storage, and the firewall is configured to keep the environment controlled. Argo CD is being wired in to make deployments automatic and traceable. My role: backend feature development and the webhooks pipeline that triggers builds when code gets pushed.
Een echte serveromgeving voor een klant — geen sandbox, geen mock. De eerste versie van de website is live, de CI-pipeline bouwt die bij elke push naar een containerimage, VM's draaien met NFS-gedeelde opslag en de firewall houdt de omgeving onder controle. Argo CD wordt gekoppeld voor automatische en traceerbare deployments. Mijn rol: backend features en de webhooks-pipeline die builds triggert bij elke code-push.
This is the first project where my code has to be deployable by someone else, on a server I don't fully control, in a pipeline I didn't build alone. That changes how you write. Features need to be clean enough for the team to extend. Webhooks need to be reliable enough that a silent HTTP failure doesn't break a deployment. I'm learning how a frontend, a CI pipeline, container images, firewall rules, and shared storage all have to work together before a single page loads — and the client meeting that went well confirmed we're building the right thing.
Dit is het eerste project waarbij mijn code door iemand anders deployed moet worden, op een server die ik niet volledig beheer, in een pipeline die ik niet alleen bouwde. Dat verandert hoe je schrijft. Features moeten uitbreidbaar zijn voor het team. Webhooks moeten betrouwbaar genoeg zijn dat een stille HTTP-fout geen deployment breekt. Ik leer hoe frontend, CI-pipeline, containerimages, firewallregels en gedeelde opslag allemaal moeten samenwerken voor één pagina laadt.
Understanding where my work ends and the infrastructure begins. When something breaks — is it the webhook payload, the container build, or a firewall rule blocking the port? In a team project with multiple moving pieces, debugging means tracing a problem through layers you didn't all write yourself. It's a different skill from solo debugging, and I'm actively building it.
Begrijpen waar mijn werk eindigt en de infrastructuur begint. Als iets breekt — is het de webhook payload, de containerbuild of een firewallregel die de poort blokkeert? In een teamproject met meerdere bewegende delen betekent debuggen een probleem traceren door lagen die je niet allemaal zelf hebt geschreven. Dat is een andere vaardigheid dan solo debuggen, en ik bouw die actief op.
Two devices, both built from scratch: a pick-up truck running on a 7.4V LiPo with a 390 brushed motor, two servo motors, a laser transmitter and LED strip — and a custom handheld controller with dual joysticks, rotary encoder, four buttons and a TFT display. Both had their own custom PCB designed in EasyEDA and soldered by hand. They communicate wirelessly via NRF24L01 RF modules over SPI. The vehicle could drive, shoot a laser at a target, and carry Duplo blocks for a team challenge involving a crane.
Twee apparaten, beide van nul gebouwd: een pick-up truck op een 7.4V LiPo met een 390 brushed motor, twee servomotoren, een lasertransmitter en LED-strip — en een zelfgemaakte handcontroller met dubbele joysticks, rotary encoder, vier knoppen en een TFT-display. Beide hadden een eigen PCB ontworpen in EasyEDA en handmatig gesoldeerd. Ze communiceren draadloos via NRF24L01 RF-modules over SPI. Het wagentje kon rijden, op een doel schieten met een laser en Duplo-blokjes vervoeren voor een teamuitdaging.
PCB design end-to-end: schematic in EasyEDA, layout, ordering, soldering. SPI communication and how RF protocols actually behave in the real world. ESC and servo control via PWM. Power budgeting — the 2700mAh LiPo gives about 20 minutes of runtime at nominal draw. And the most important lesson: a bug in firmware isn't wrong output — it's a motor that doesn't stop, or a PCB that explodes.
PCB-design van begin tot eind: schema in EasyEDA, layout, bestellen, solderen. SPI-communicatie en hoe RF-protocollen zich in de echte wereld gedragen. ESC en servo-aansturing via PWM. Vermogensbudget berekenen — de 2700mAh LiPo geeft ongeveer 20 minuten bij nominaal verbruik. En de belangrijkste les: een bug in firmware is geen verkeerde output — het is een motor die niet stopt, of een PCB die ontploft.
Three real problems, three real fixes. First: the NRF24L01 modules refused to communicate reliably when paired with a Raspberry Pi — random connections that disappeared overnight. Switched both sides to ESP32 and it worked perfectly. Second: ordered the ESC and LiPo separately and only realised on delivery that the connectors didn't match. Sent the wrong ESC back, bought the right one cheaper. Third — and best: a wiring mistake on the PCB pulled 7.4V directly to ground through the switch with no resistor. The PCB literally exploded. Redesigned, reordered, resoldered. It worked.
Drie echte problemen, drie echte oplossingen. Eerst: de NRF24L01-modules wilden niet betrouwbaar communiceren met een Raspberry Pi — willekeurige verbindingen die 's nachts verdwenen. Beide kanten naar ESP32 geswitcht en het werkte perfect. Dan: ESC en LiPo apart besteld, bij levering pas gezien dat de stekkers niet pasten. Foute ESC teruggestuurd, juiste goedkoper gekocht. Derde — en beste: een bedradingsfout op de PCB trok 7.4V rechtstreeks naar de grond via de schakelaar zonder weerstand. De PCB ontplofte letterlijk. Herontworpen, herbesteld, hersoldeerd. Het werkte.
An old PC running Proxmox VE with two VMs: one hosting Minecraft servers for me and my friends to play on, and one running Home Assistant for smart home control. On the Home Assistant side I've connected my bedroom lights and built a custom ESP32 LED strip controller for configurable room lighting. More IoT integrations are on the list — just haven't gotten to them yet. Built and maintained entirely on my own time, because some projects you do for yourself.
Een oude pc met Proxmox VE en twee VM's: één voor Minecraft-servers voor mij en vrienden, één voor Home Assistant. In Home Assistant heb ik mijn slaapkamerlichten gekoppeld en een eigen ESP32 LED-strip controller gebouwd voor instelbare sfeerverlichting. Meer IoT-integraties staan op de lijst — moet er nog aan toe komen. Volledig in mijn eigen tijd gebouwd.
How virtualisation actually works once you're responsible for it yourself — spinning up VMs, allocating resources, keeping services running when you want to play. Proxmox makes you think in terms of machines as isolated, manageable units rather than "the computer". Home Assistant taught me how automation config works in practice: YAML-based device control, triggers, and why getting hardware to talk to software is never as simple as it looks on paper.
Hoe virtualisatie echt werkt als je er zelf verantwoordelijk voor bent — VM's opzetten, resources verdelen, services draaiende houden. Proxmox dwingt je te denken in geïsoleerde, beheersbare eenheden. Home Assistant leerde me hoe automatiseringsconfiguratie in de praktijk werkt: YAML-gebaseerde apparaatbesturing, triggers, en waarom hardware en software koppelen nooit zo simpel is als het eruitziet.
Getting the Minecraft server to run reliably inside a VM on Proxmox — it took some digging to understand how to allocate the right CPU and memory so the server didn't lag. A separate issue: friends in the Netherlands couldn't connect because of a DNS misconfiguration on their end. Took a bit of back-and-forth to diagnose remotely, but once we understood what was wrong it was a quick fix. Small problems, but the kind you only run into when something real is running for real users.
De Minecraft-server betrouwbaar laten draaien in een VM op Proxmox — het vroeg wat uitzoekwerk om de juiste CPU- en geheugenallocatie te vinden zodat de server niet lagde. Een apart probleem: vrienden in Nederland konden niet verbinden door een DNS-misconfiguratie aan hun kant. Wat heen-en-weer om het op afstand te diagnosticeren, maar eenmaal begrepen wat er mis was, snel opgelost. Kleine problemen — maar het soort dat je alleen tegenkomt als iets echt draait voor echte gebruikers.
Performed a structured black-box penetration test on the ShopMore web application as part of the Application Security course. Tested authentication, the admin interface, contact form, and product filtering against the OWASP Top 10. Produced a professional report with CVSS scores, reproduction steps, screenshots, and remediation recommendations for every finding.
Uitgevoerd een gestructureerde black-box penetratietest op de ShopMore webapplicatie als onderdeel van het vak Application Security. Getest op authenticatie, admininterface, contactformulier en productfiltering tegen de OWASP Top 10. Professioneel rapport opgesteld met CVSS-scores, reproductiestappen, screenshots en hersteladvies.
SM-01 Critical (CVSS 9.1) — Broken Access Control: the /admin interface had zero authentication. Navigate to it, get full control — create, edit, delete any user. SM-02 Medium (CVSS 6.1) — Reflected XSS: user input echoed back to the contact form without encoding. <script>alert(1)</script> executed in the browser. SM-03 Medium (CVSS 5.3) — Information Disclosure: unhandled exceptions exposed full stack traces and internal framework details. SQL injection, stored XSS, directory traversal, and command injection were all tested — not present.
SM-01 Critical (CVSS 9.1) — Broken Access Control: de /admin-interface had nul authenticatie. Navigeer ernaar, volledige controle — gebruikers aanmaken, bewerken, verwijderen. SM-02 Medium (CVSS 6.1) — Reflected XSS: userinput werd zonder encoding teruggestuurd naar het contactformulier. <script>alert(1)</script> werd uitgevoerd in de browser. SM-03 Medium (CVSS 5.3) — Information Disclosure: onafgehandelde uitzonderingen legden volledige stack traces bloot. SQL-injectie, stored XSS, directory traversal en command injection allemaal getest — niet aanwezig.
How to approach a web application systematically — OWASP as a real testing framework, not a checklist to memorise. What CVSS scores actually mean in practice: a 9.1 means any unauthenticated person on the network can take full control. And the most important lesson: a pentest is only as useful as the report it produces. Knowing how to document findings so a developer can actually fix them — precise impact, clear steps, actionable recommendations — is half the job.
Hoe je een webapplicatie systematisch benadert — OWASP als echt testframework, niet een lijst om te onthouden. Wat CVSS-scores in de praktijk betekenen: een 9.1 betekent dat elke niet-geauthenticeerde persoon op het netwerk volledige controle kan krijgen. En de belangrijkste les: een pentest is alleen nuttig als het rapport dat erbij hoort ook nuttig is. Bevindingen documenteren zodat een developer ze kan oplossen — precieze impact, duidelijke stappen, uitvoerbaar advies — is de helft van het werk.
The critical finding was almost embarrassingly simple — just navigate to /admin. The harder work was writing the report professionally: quantifying the risk accurately with CVSS, explaining the attack chain clearly enough for a non-technical reader, and making sure every recommendation was specific enough to act on. Finding the vulnerability is one skill. Communicating it properly is another.
De kritieke bevinding was bijna gênant simpel — gewoon naar /admin navigeren. Het moeilijkere werk was het rapport professioneel schrijven: het risico nauwkeurig kwantificeren met CVSS, de aanvalsketen duidelijk genoeg uitleggen voor een niet-technische lezer, en zorgen dat elk hersteladvies concreet genoeg was. De kwetsbaarheid vinden is één vaardigheid. Die correct communiceren is een andere.
MASSWAVE is a communication platform built to solve a real problem: smallholder farmers in Tanzania can't easily reach crop buyers without physically travelling to market. The solution uses what they already have — a basic Nokia feature phone. Farmers navigate a USSD menu (no internet, no app, just the GSM network) to register available crops, quantities, prices, and location. That data hits a REST API as JSON, gets stored in a database, and is pushed as a notification to middlemen (aggregators) on their smartphone app. The middleman confirms the offer, picks a route, and the farmer gets a confirmation back on their Nokia. The whole loop — no internet required on the farmer's end.
MASSWAVE is een communicatieplatform gebouwd voor een echt probleem: kleinschalige boeren in Tanzania kunnen niet makkelijk cropkopers bereiken zonder fysiek naar de markt te gaan. De oplossing gebruikt wat ze al hebben — een Nokia-featurephone. Boeren navigeren een USSD-menu (geen internet, geen app, enkel het GSM-netwerk) om beschikbare gewassen, hoeveelheden, prijzen en locatie te registreren. Die data komt als JSON bij een REST API terecht, wordt opgeslagen in een database en als notificatie naar tussenpersonen (aggregators) verstuurd via hun smartphone-app. De tussenpersoon bevestigt het aanbod, kiest een route, en de boer krijgt bevestiging terug op zijn Nokia. De volledige loop — geen internet nodig aan de kant van de boer.
That the most interesting engineering constraints come from the user, not the tech. USSD is a 160-character, menu-only, stateless protocol — there's no fancy UI, no validation popups, no retry buttons. Designing a flow that's actually usable within those limits forces you to think about the experience in a completely different way. Also got exposed to how REST APIs serve very different clients at once: a bare-bones USSD gateway on one end, a full smartphone app on the other — same backend, totally different interaction models.
Dat de interessantste engineeringbeperkingen van de gebruiker komen, niet van de technologie. USSD is een 160-karakter, menu-only, stateless protocol — geen fancy UI, geen validatiepopups, geen retry-knoppen. Een flow ontwerpen die echt bruikbaar is binnen die limieten dwingt je om de ervaring op een compleet andere manier te benaderen. Ik leerde ook hoe REST API's tegelijk zeer verschillende clients bedienen: een kaalbere USSD-gateway aan de ene kant, een volledig smartphone-app aan de andere — dezelfde backend, totaal verschillende interactiemodellen.
Building under international-week time pressure with a mixed team from different programs at Thomas More — developers, network engineers, and cybersecurity students all working on the same codebase. Everyone had a different way of thinking about the problem and a different part of the stack to own. Coordinating without stepping on each other's work, keeping the API contract stable while both sides were still changing, and shipping something demo-ready in five days. The security issues we found along the way couldn't be patched before the demo — so the presentation included both what the system does and what would need fixing before it went to production.
Bouwen onder internationale-week tijdsdruk met een gemengd team van verschillende richtingen binnen Thomas More — developers, netwerkingenieurs en cybersecurity-studenten die allemaal op dezelfde codebase werkten. Iedereen dacht anders over het probleem en had een ander deel van de stack in handen. Coördineren zonder elkaars werk te verstoren, het API-contract stabiel houden terwijl beide kanten nog veranderden, en iets demo-klaar opleveren in vijf dagen. De securityproblemen die we onderweg vonden konden niet worden gepatcht voor de demo — dus de presentatie omvatte zowel wat het systeem doet als wat gefixed zou moeten worden voor productie.
Most people in security want to defend. I want to attack — because the best defenders are the ones who've already been on the other side. I want to sit in front of a system built by someone smart, find the thing they missed, and hand it back to them documented, explained, and fixed. That's what Red Team work is. That's what I'm building toward.
De meeste mensen in security willen verdedigen. Ik wil aanvallen — want de beste verdedigers zijn degenen die al aan de andere kant zijn geweest. Ik wil voor een systeem zitten dat door iemand slims is gebouwd, het ding vinden dat ze misten, en het teruggeven gedocumenteerd, uitgelegd en opgelost. Dat is Red Team werk. Dat is waar ik naartoe bouw.
Simulate real attacks before the real attackers show up. Find the gaps first.
Echte aanvallen simuleren voor de echte aanvallers komen. De gaten als eerste vinden.
Systematic, documented probing of systems. Understand every layer before calling it secure.
Systematisch, gedocumenteerd onderzoeken van systemen. Elke laag begrijpen voor het veilig te noemen.
The end goal: help build environments that can withstand what I know how to throw at them.
Het einddoel: helpen omgevingen bouwen die kunnen weerstaan wat ik weet hoe te gooien.
It started with a YouTube video — a hacker, a broken login, and the realisation that truly understanding something means knowing exactly where it breaks. That curiosity is still here. If you want someone who thinks that way, let's write the next chapter.
Het begon met een YouTube-video — een hacker, een kapot loginsysteem, en het besef dat iets echt begrijpen betekent weten precies waar het breekt. Die nieuwsgierigheid is er nog steeds. Als je iemand wil die zo denkt, laten we het volgende hoofdstuk schrijven.
© 2026 Sem Vanderlinden · Cybersecurity Student · Thomas More · Belgium
