Een productieserver hapert om 3 uur ’s nachts. Je SSH’t naar binnen. En nu? De engineers die hier rustig blijven zijn degenen die de volgende tien commando’s al uit hun hoofd kennen, omdat ze precies deze loop al honderd keer hebben gedraaid, alleen met het woord “flag” in plaats van “incident”.

Ik spendeer mijn avonden aan Hack The Box challenges en CTF competities. Ik heb geen plannen om pentester te worden. Ik zit prima in platform engineering. De reden dat ik ermee doorga is dat de skills rechtstreeks doorwerken in mijn dagelijkse werk, en die overdracht is groter dan het klinkt.

Wat heeft het pwnen van een kwetsbare web app te maken met het runnen van Kubernetes clusters? Aan de oppervlakte niks. Eronder is het dezelfde kernvaardigheid: in een systeem belanden dat je niet volledig snapt en snel reconstrueren wat er echt gebeurt. Dat is begrijpen boven vertrouwen, het ding dat ik het hoogst waardeer wanneer er iets stuk gaat. Met CTF oefen je dat juist wanneer de stakes laag zijn en het enige dat in brand staat je vrije tijd is.

Hier is wat er doorwerkt, laag voor laag, beginnend bij één host en opbouwend naar een Kubernetes cluster.

De mindset shift

Beland in een CTF box en de eerste vragen zijn altijd dezelfde:

  • Wat draait er?
  • Wat is kwetsbaar?
  • Waar heb ik toegang toe?
  • Hoe hangen dingen met elkaar samen?

Vervang “kwetsbaar” door “kapot” en dat is incident response. Dezelfde vragen wanneer je SSH’t naar een server die zich misdraagt, wanneer een pod blijft crashen, wanneer je reconstrueert wat een aanvaller heeft aangeraakt.

Het verschil zit in de herhaling. CTF spelers draaien deze loop constant, dus de enumeratie wordt spiergeheugen. Als je het wekelijks voor je plezier doet, stop je met gokken onder druk en begin je met verzamelen. De rest van deze post is de toolkit die die gewoonte bouwt, van bestandssysteem naar syscall naar netwerk naar container.

Bestandssysteem onderzoek

Recent gewijzigde bestanden vinden

CTF gebruik: Geplaatste backdoors vinden, gewijzigde configs, of aanvaller-artefacten.

DevOps gebruik: Vinden wat veranderde voordat een systeem kapot ging, config drift tracken.

# Bestanden gewijzigd in de laatste 24 uur
find / -type f -mtime -1 2>/dev/null

# Bestanden gewijzigd in de laatste 10 minuten
find / -type f -mmin -10 2>/dev/null

# Bestanden veranderd na een specifieke datum
find / -type f -newermt "2026-02-01" 2>/dev/null

# Bestanden op grootte vinden (handig voor log bombs of grote dumps)
find / -type f -size +100M 2>/dev/null

Echt scenario: Deployment faalde, app start niet. Welke config bestanden zijn veranderd? find /etc -type f -mmin -30 laat zien dat iemand 15 minuten geleden het verkeerde config bestand heeft bewerkt.

Bestanden vinden op inhoud

CTF gebruik: Zoeken naar wachtwoorden, sleutels, flags verborgen in bestanden.

DevOps gebruik: Vinden waar een config waarde is ingesteld, hardcoded credentials lokaliseren die er niet zouden moeten zijn.

# Bestanden vinden die een string bevatten
grep -r "password" /etc 2>/dev/null
grep -r "API_KEY" /app 2>/dev/null

# Bestanden vinden met een patroon (zoals IP adressen)
grep -rE "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" /etc 2>/dev/null

# Bestanden met specifieke permissies (world-writable)
find / -perm -002 -type f 2>/dev/null

# SUID binaries vinden (privilege escalation, maar ook config issues)
find / -perm -4000 -type f 2>/dev/null

Echt scenario: “Waar wordt die environment variable gezet?” grep -r "DATABASE_URL" /etc /app ~/.* 2>/dev/null vindt het op drie verschillende plekken met drie verschillende waardes.

Bestand metadata en attributen

CTF gebruik: Verborgen bestanden vinden, bestandsintegriteit checken, tampering spotten.

DevOps gebruik: Permissie-issues debuggen, bestandstoestanden begrijpen.

# Extended attributen
lsattr /etc/passwd
getfacl /var/log/secure

# Bestandstype en magic bytes
file /usr/bin/mystery-binary
file /var/log/weird.log

# Gedetailleerde stat info
stat /etc/shadow

# Immutable bestanden (kunnen niet gewijzigd worden, zelfs niet door root)
lsattr -a /etc/ | grep "\-i\-"

Echt scenario: “Waarom kan ik dit bestand niet verwijderen, zelfs als root?” lsattr laat zien dat de immutable flag is gezet.

Proces onderzoek

Wat draait er en waarom

CTF gebruik: Malicious processen vinden, begrijpen wat resources consumeert, reverse shells vinden.

DevOps gebruik: Resource-issues debuggen, applicatiegedrag begrijpen, runaway processen vinden.

# Gedetailleerde proces tree
ps auxf
pstree -p

# Wat gebruikt nu de meeste CPU/memory
top -bn1 | head -20
ps aux --sort=-%mem | head -10
ps aux --sort=-%cpu | head -10

# Proces op naam met volledige command line
ps aux | grep -E "[n]ginx|[a]pache"

# Welk proces gebruikt een specifieke poort
lsof -i :8080
ss -tlnp | grep 8080
netstat -tlnp | grep 8080

# Welke bestanden heeft een proces open
lsof -p <pid>
ls -la /proc/<pid>/fd/

# Proces environment variables
cat /proc/<pid>/environ | tr '\0' '\n'

# Proces working directory
ls -la /proc/<pid>/cwd

Echt scenario: Java app eet 100% CPU. ps aux --sort=-%cpu laat zien welke PID. /proc/<pid>/fd/ toont dat het 50.000 open file handles heeft, oftewel een connection leak.

Proces activiteit traceren

CTF gebruik: Begrijpen wat een binary doet, verborgen functionaliteit vinden.

DevOps gebruik: Debuggen waarom een app niet kan connecten, syscall gedrag begrijpen.

# System calls gemaakt door een proces
strace -p <pid>
strace -f -e trace=network <command>  # alleen netwerk calls
strace -f -e trace=file <command>     # alleen file operaties

# Library calls
ltrace -p <pid>

# Trace een specifiek commando
strace -o output.txt -f ./mystery-app

# Bekijk wat een proces doet in real-time
watch -n 1 "cat /proc/<pid>/io"

Echt scenario: App zegt “connection refused” maar de service draait. strace -e connect laat zien dat het naar het verkeerde IP connect, omdat een environment variable verkeerd geconfigureerd is.

Netwerk onderzoek

Connectie analyse

CTF gebruik: C2 connecties vinden, exfiltratie kanalen, pivot mogelijkheden.

DevOps gebruik: Connectiviteitsproblemen debuggen, traffic patronen begrijpen, ongeautoriseerde connecties vinden.

# Alle netwerk connecties
ss -tunapl
netstat -tunapl

# Alleen established connecties
ss -tnp state established

# Connecties per proces
ss -tnp | grep <pid>

# Luisterende services
ss -tlnp
netstat -tlnp

# Connecties naar een specifieke host
ss -tn dst 10.0.0.50

# DNS resolution trace
dig +trace example.com
host -v example.com
nslookup -debug example.com

Echt scenario: Applicatie krijgt timeout bij database connectie. ss -tn laat zien dat connectie vastzit in SYN_SENT, wat wijst op een firewall issue of een verkeerde route.

Packet capture en analyse

CTF gebruik: Credentials capturen, protocollen analyseren, verborgen data vinden.

DevOps gebruik: Protocol issues debuggen, begrijpen wat er op de wire staat, TLS verificeren.

# Capture traffic op een interface
tcpdump -i eth0 -w capture.pcap

# Specifiek traffic capturen
tcpdump -i eth0 port 443
tcpdump -i eth0 host 10.0.0.50
tcpdump -i eth0 'port 80 and host 10.0.0.50'

# Capture lezen met volledige packet content
tcpdump -r capture.pcap -A
tcpdump -r capture.pcap -X

# Snelle HTTP debugging
tcpdump -i eth0 -A port 80 | grep -E "GET|POST|Host:"

# TLS handshake checken
openssl s_client -connect example.com:443 -servername example.com

Echt scenario: HTTPS werkt vanaf één server, niet vanaf een andere. openssl s_client laat zien dat de kapotte server de CA niet vertrouwt, omdat een root cert ontbreekt.

Log analyse

Patronen vinden in chaos

CTF gebruik: Aanvalssporen vinden, events correleren, anomalieën identificeren.

DevOps gebruik: Issues debuggen, error patronen begrijpen, incident onderzoek.

# Logs volgen in real-time
tail -f /var/log/syslog
journalctl -f -u myservice

# Logs sinds specifieke tijd
journalctl --since "2026-02-01 10:00:00"
journalctl --since "1 hour ago"

# Logs voor specifieke service
journalctl -u nginx -n 100

# Filter op priority
journalctl -p err  # alleen errors
journalctl -p warning..err  # warnings en errors

# Tel voorkomens van patronen
grep -c "error" /var/log/app.log
awk '/error/ {count++} END {print count}' /var/log/app.log

# Timestamps extracten en groeperen per minuut
awk '{print $1, $2, $3}' /var/log/app.log | cut -d: -f1,2 | uniq -c | sort -rn

# Errors vinden met context
grep -B5 -A5 "FATAL" /var/log/app.log

Echt scenario: Intermitterende 500 errors. grep -c "500" access.log per uur toont een patroon: een spike elk uur om :00, wat een cron job blijkt te zijn die problemen veroorzaakt.

Log correlatie

CTF gebruik: Aanvaltijdlijn reconstrueren, laterale beweging begrijpen.

DevOps gebruik: Oorzaak en gevolg over services heen begrijpen, incident timelines.

# Auth failures
grep "Failed password" /var/log/auth.log | awk '{print $1,$2,$3,$9,$11}' | sort | uniq -c

# Commands uitgevoerd door gebruikers (als auditd is ingeschakeld)
ausearch -k commands -i

# Correleer op timestamp over bestanden heen
grep "2026-02-27T10:15" /var/log/*.log

# Gestructureerde logs parsen (JSON)
cat app.log | jq 'select(.level == "ERROR")'
cat app.log | jq -r '[.timestamp, .message] | @tsv'

Gebruiker en authenticatie

Gebruiker onderzoek

CTF gebruik: Gecompromitteerde accounts vinden, privilege levels begrijpen, laterale beweging.

DevOps gebruik: Toegang auditen, permissie-issues debuggen, security reviews.

# Gebruikers met login shells
cat /etc/passwd | grep -v nologin | grep -v /bin/false

# Gebruikers met UID 0 (root equivalent)
awk -F: '$3 == 0 {print $1}' /etc/passwd

# Laatste logins
last -n 20
lastlog

# Gefaalde login pogingen
lastb -n 20
faillog -a

# Wie is nu ingelogd
w
who

# Gebruiker's groepen en sudo rechten
id username
sudo -l -U username

# SSH authorized keys
cat ~/.ssh/authorized_keys
find / -name "authorized_keys" 2>/dev/null

Echt scenario: Ongeautoriseerde toegang vermoed. last toont login vanaf ongebruikelijk IP. grep "Accepted" /var/log/auth.log laat zien dat ze SSH key gebruikten, geen wachtwoord.

Disk en storage

Disk analyse

CTF gebruik: Verwijderde bestanden vinden, disk layout begrijpen, data recoveren.

DevOps gebruik: Disk vol issues debuggen, ruimtegebruik begrijpen.

# Disk gebruik per directory
du -sh /* 2>/dev/null | sort -h
du -sh /var/* 2>/dev/null | sort -h

# Vind wat ruimte gebruikt
ncdu /  # interactief

# Grote bestanden vinden
find / -type f -size +1G 2>/dev/null

# Verwijderde bestanden nog steeds open (houden disk space vast)
lsof +L1

# Inode gebruik
df -i

# Wat is gemount
mount | column -t
cat /proc/mounts
findmnt

Echt scenario: Disk 100% vol maar du zegt slechts 50% gebruikt. lsof +L1 toont verwijderde log bestanden nog steeds vastgehouden door processen, dus een herstart geeft de ruimte vrij.

Container-specifieke skills

Container onderzoek

CTF gebruik: Container escapes, isolatie begrijpen, misconfiguraties vinden.

DevOps gebruik: Container issues debuggen, container state begrijpen.

# Wat zit er in een draaiende container
docker exec -it <container> /bin/sh
kubectl exec -it <pod> -- /bin/sh

# Container processen vanaf host
docker top <container>
ps aux | grep containerd

# Container resource gebruik
docker stats
kubectl top pods

# Container logs
docker logs -f <container>
kubectl logs -f <pod>

# Container config inspecteren
docker inspect <container>
docker inspect <container> | jq '.[0].Config.Env'
kubectl describe pod <pod>

# Container bestandssysteem
docker diff <container>  # wat is veranderd
docker export <container> | tar -tf -  # bestanden listen

# Capabilities checken
docker inspect <container> | jq '.[0].HostConfig.CapAdd'
kubectl auth can-i --list

Echt scenario: Container crasht bij opstarten. docker logs toont niks. docker inspect onthult de verkeerde entrypoint gezet in een image override.

De skills die overdragen

We begonnen bij één host, liepen omhoog langs processen, het netwerk, logs, auth, disk, en eindigden binnen een Kubernetes pod. Die klim is het hele punt. Na maanden CTF oefenen duiken de gewoontes vanzelf op in mijn werk:

  1. Systematische enumeratie: Ik verzamel informatie voordat ik iets aanraak. Gokken onder druk is hoe je van één outage er twee maakt.
  2. Logs goed lezen: Ik lees de foutmelding in plaats van opnieuw te proberen en te hopen. Het antwoord staat er meestal gewoon.
  3. De hele stack begrijpen: Ik trace een probleem van applicatie naar syscall naar netwerk, op dezelfde manier als ik het pad van web app naar root op een box traceerde.
  4. Gezonde paranoia: Ik merk op wat mis kan gaan en wat verkeerd geconfigureerd is, omdat een CTF je traint om precies daarnaar te kijken.
  5. Snelheid met core tools: grep, find, awk en sed zijn geen dingen meer die ik opzoek, maar reflexen.

Niks daarvan vereist een security baan. Het vereist herhaling, en CTF is een goedkope manier om die te krijgen.

Beginnen

Als je dezelfde toolkit wilt bouwen, begin in het ondiepe:

  1. OverTheWire Bandit: Pure Linux command line oefening, geen setup nodig. Doe dit eerst.
  2. TryHackMe: Begeleide rooms met hints, een zachtere instap.
  3. Hack The Box: Begin met makkelijke boxes en focus op de Linux machines.
  4. PicoCTF: Goede forensics challenges als je dieper wilt gaan.

Je hoeft geen hacker te worden. Je hebt de onderzoekende gewoonte nodig, en een avond per week is genoeg om die te bouwen. De volgende keer dat productie om 3 uur ’s nachts kapot gaat, zit de loop al in je vingers.