Tanquem el Mòdul 5 amb una idea que ara es converteix en l'eix de tot el Mòdul 6: la feina tècnica ha acabat; comença la feina de convertir-la en valor per a TechNova. Durant les fases de reconeixement, escaneig, explotació i post-explotació vam capturar una muntanya de matèria primera —comandes, sortides, marques de temps, artefactes, la cadena de compromís i el mapa de la xarxa interna 10.10.10.0/24—. Res d'això val per al client mentre continuï a la teva carpeta de notes. L'informe és el lliurable que dona valor al pentest: és el que TechNova va pagar, el que llegirà la seva direcció i el que faran servir els seus tècnics per remeiar i reduir risc.

Aquesta primera lliçó tracta de com documentar cada troballa de manera que sigui reproduïble, traçable i accionable, i de com s'estructura un informe de pentest. Encara no entrem en com puntuar la severitat amb CVSS (això és 06-02), ni en com redactar remediacions a fons (06-03), ni en com presentar els resultats a la reunió de tancament (06-04). Aquí construïm el maó amb què s'aixeca l'informe: la troballa ben documentada. I un advertiment que recorre tota la lliçó: l'informe conté vulnerabilitats reals i explotables de TechNova; és un document altament confidencial i es tracta com a tal des de la primera nota de camp.

1. Documentar durant el test, no després
2. Anatomia d'una troballa
3. Evidència reproduïble i prova de concepte (PoC)
4. Traçabilitat: de la troballa a l'evidència crua
5. Notes de camp i bitàcola
6. Gestió d'evidència sensible i confidencialitat
7. Estructura d'un informe de pentest
8. Plantilla de troballa: la SQLi de TechNova de principi a fi
9. Errors Comuns i Consells
10. Exercicis
11. Conclusió

L'error més car d'un pentester novell és deixar la documentació per al final. Quan portes dues setmanes de test, has compromès cinc màquines i has pivotat per mitja xarxa, és impossible reconstruir de memòria quin payload exacte va funcionar a producto.php?id= un dimarts a la tarda. La documentació es fa en calent, mentre l'evidència és fresca i el terminal encara mostra la sortida.

La regla pràctica: cada vegada que aconsegueixes alguna cosa rellevant —un servei enumerat, una vulnerabilitat confirmada, un accés obtingut— captures l'evidència en aquell mateix moment i anotes el mínim per reconstruir-ho després (actiu, hora, comanda, resultat). L'informe final es redacta en acabar, però s'alimenta durant tot l'engagement.

Una troballa (finding) és la unitat bàsica de l'informe: descriu una debilitat concreta en un actiu concret. Una bona troballa respon, sense que el lector hagi de preguntar, a: què és, on és, com ho vas demostrar, quin dany causa i què cal fer-hi. Aquests són els seus camps:

Cadascun d'aquests camps té una funció. Si en falta qualsevol, la troballa perd utilitat: sense actiu, no se sap on arreglar; sense passos de reproducció, el client no pot validar; sense impacte de negoci, la direcció no entén per què prioritzar-la.

L'evidència és el que converteix una afirmació en un fet. "El lloc és vulnerable a SQLi" és una opinió; una captura de la resposta del servidor retornant la versió de MySQL davant del teu payload és una prova. Bones pràctiques per capturar evidència:

• Reproduïble: inclou la comanda/petició completa i la sortida literal. Qui llegeixi l'informe ha de poder repetir el pas i obtenir el mateix resultat.
• Mínima però suficient: mostra el just per provar el punt. No aboquis 4.000 files d'una taula; una fila que demostri accés a dades sensibles n'hi ha prou.
• Amb context: anota data, hora, host d'origen i actiu destí a cada peça. Una captura sense context no val com a prova.
• Sense causar dany real: la PoC demostra el problema, no l'explota destructivament. Extreus un registre de mostra per provar l'accés, no aboques ni exfiltres la base de dades sencera del client.
• Dades sensibles emmascarades: si l'evidència conté dades personals reals de clients de TechNova, redacta-les (anonimitza) a l'informe: joan.****@***.com. Demostres l'accés sense propagar la dada.

La prova de concepte (PoC) és la seqüència concreta i controlada que demostra l'explotabilitat. En un informe professional la PoC és suficient per convèncer, insuficient per causar dany: ensenya la ruta, no lliura una arma llesta per abusar-ne.

Traçabilitat significa que cada afirmació de l'informe es pot seguir fins a l'evidència crua que la sustenta. És el que fa la teva feina auditable i defensable: si TechNova (o un tercer) qüestiona una troballa, tu pots ensenyar la captura original, el log de l'eina i l'hora exacta.

Un esquema de traçabilitat simple però eficaç:

A la pràctica es materialitza anomenant els fitxers d'evidència de manera consistent (TN-001_sqli_producto_respuesta.png), guardant-los en una carpeta per troballa i referenciant-los des de l'informe. Així, l'ID de la troballa és el fil que uneix la nota de camp, l'evidència i la recomanació.

Les notes de camp són el teu registre en brut durant el test. Ja vam insistir en la bitàcola al Mòdul 5 des de l'ètica (deixar rastre auditable); aquí la veiem des de la utilitat per a l'informe. Una entrada de bitàcola útil recull, per cada acció rellevant:

Amb marques de temps, origen, destí, acció i referència a l'evidència, qualsevol entrada es converteix després en part d'una troballa o de la cronologia de l'atac. La bitàcola també protegeix el pentester: demostra que es va mantenir dins de l'abast autoritzat.

L'informe i la seva evidència són material sensible: documenten com comprometre sistemes reals de TechNova i poden contenir dades dels seus clients. Tractar això amb lleugeresa és una falta professional greu. Principis:

• Confidencialitat per defecte: l'informe es classifica com a confidencial i només es comparteix amb els interlocutors autoritzats al contracte.
• Xifratge en repòs i en trànsit: les notes, captures i l'informe es guarden xifrats i es lliuren per un canal segur (mai per correu sense xifrar). El lliurament segur es detalla a 06-04.
• Minimització: no capturis més dades sensibles de les necessàries per provar la troballa; emmascara les que sí que captures.
• Retenció i destrucció: acorda amb el client quant de temps conserves l'evidència i destrueix-la de manera segura en vèncer aquest termini.
• Control d'accés: només l'equip de l'engagement accedeix a l'evidència; res de còpies en dispositius personals sense xifrar ni en serveis al núvol no autoritzats.

Recorda: filtrar un informe de pentest és lliurar a un atacant un mapa exacte de per on entrar. La confidencialitat no és burocràcia, és part del servei.

Un informe professional serveix a dos públics alhora i per això s'organitza en dos grans blocs (la comunicació a cada públic es treballa a 06-04). Estructura típica:

La regla d'or: el resum executiu es llegeix sense coneixements tècnics; el detall tècnic es llegeix amb ells. Un director ha d'entendre el risc sense saber què és una injecció SQL; un administrador ha de poder reproduir i corregir el problema amb el detall tècnic.

Reunim tot l'anterior en una plantilla reutilitzable, documentant la troballa estrella de l'engagement: la injecció SQL a producto.php?id= que vam explotar al Mòdul 4.

Aquesta plantilla és autoexplicativa: qui la llegeixi sap què passa, on, com provar-ho, què s'hi juga TechNova i per on començar a arreglar-ho. Fixa't que la PoC demostra l'accés (una fila de mostra) sense abocar dades massives ni causar dany: evidència suficient, impacte controlat.

• Documentar de memòria al final. Es perden detalls crítics i l'evidència deixa de ser reproduïble. Captura en calent, sempre.
• Evidència sense context. Una captura sense data, host i actiu no prova res. Anota el context a cada peça.
• Abocar dades reals del client a l'informe. Emmascara les dades sensibles: demostra l'accés, no propaguis la dada. Un informe filtrat no ha de ser una fuita de dades afegida.
• Una troballa que barreja dos problemes. Una troballa = una debilitat = un actiu. Si hi ha SQLi i XSS, són dues troballes amb dos IDs.
• Títols vagues. "Problema de seguretat al web" no ajuda ningú. Sigues específic: "Injecció SQL a producto.php".
• [Ètic] Tractar l'informe com un document qualsevol. Conté vulnerabilitats reals i explotables; xifra'l, controla'l i lliura'l per canal segur.
• Consell: escriu l'impacte pensant en qui decideix el pressupost. "Extreu la base de dades" és tècnic; "exposa les dades de tots els clients" és negoci. Tots dos importen, a la seva secció.

Exercici 1. Durant el test descobreixes que el panell d'administració de la botiga (https://tienda.technova.lab/admin/) és accessible sense autenticació i mostra comandes de clients. Redacta una troballa completa seguint l'anatomia de la secció 2 (títol, actiu, descripció, impacte, passos de reproducció, evidència i recomanació resumida). Assigna-li un ID.

Exercici 2. Un company et passa aquesta nota: "el web té errors, cal arreglar-lo". Explica per què aquesta nota és inservible com a troballa i enumera quins camps li falten per ser-ho.

Exercici 3. Estàs a punt d'incloure a l'informe una captura que mostra la taula usuarios completa amb 12.000 correus i hashos reals de clients de TechNova. Explica què fas abans d'incloure-la i per què, relacionant-ho amb la gestió d'evidència sensible.

Solució 1. Exemple de troballa:

• ID: TN-2026-014
• Títol: Panell d'administració accessible sense autenticació
• Actiu afectat: https://tienda.technova.lab/admin/
• Descripció: El directori /admin/ no exigeix autenticació; qualsevol usuari que conegui o endevini la ruta accedeix al panell i visualitza comandes de clients. És un error de control d'accés (autorització trencada).
• Impacte: Un atacant no autenticat accedeix a dades personals i de comandes dels clients. Per al negoci: bretxa de dades, incompliment normatiu i dany reputacional.
• Passos de reproducció: (1) navegar a https://tienda.technova.lab/admin/; (2) observar que el panell carrega sense demanar credencials i llista comandes.
• Evidència: captura del panell amb les dades de client redactades (TN-014_admin_sin_auth.png).
• Recomanació (resum): exigir autenticació i autorització per rol a tot /admin/; denegar per defecte. Referència: OWASP A01:2021 (Broken Access Control), CWE-284.

Solució 2. La nota és inservible perquè no és reproduïble, ni traçable, ni accionable: no diu què falla, on, ni com demostrar-ho. Li falten tots els camps d'una troballa: ID, títol específic, actiu afectat, descripció del problema, severitat, impacte de negoci, passos de reproducció, evidència/PoC i recomanació. Tal com està, TechNova no pot verificar res ni corregir res.

Solució 3. Abans d'incloure-la, emmascaro les dades sensibles (anonimitzo correus i no incloc hashos reals) i redueixo l'evidència a una fila de mostra que basti per provar l'accés, no la taula sencera. Motiu: l'evidència ha de ser mínima però suficient i no ha de convertir l'informe en una fuita de dades. Extreure i abocar 12.000 registres reals excedeix la PoC necessària, augmenta el risc si l'informe es filtra i pot vulnerar la protecció de dades. Demostro l'accés sense propagar la dada, i guardo l'evidència xifrada i amb accés restringit.

Hem convertit la matèria primera del Mòdul 5 en la unitat fonamental de l'informe: la troballa ben documentada. Vam veure la seva anatomia completa —títol, actiu, descripció, impacte, passos de reproducció, evidència/PoC, severitat i recomanació—, la importància de capturar evidència reproduïble en calent, la traçabilitat que uneix cada afirmació amb la seva evidència crua, el paper de les notes de camp i, molt en primer pla, la gestió de l'evidència sensible: l'informe conté vulnerabilitats reals de TechNova i es tracta com a material confidencial de principi a fi. També vam encaixar la troballa dins de l'estructura de l'informe, amb el seu resum executiu per a negoci i el seu detall tècnic, i vam deixar una plantilla reutilitzable aplicada a la SQLi de TechNova.

Ja sabem documentar cada troballa; el pas següent és prioritzar-les. A la plantilla vam escriure "Severitat: Crítica | CVSS 9.8" i vam prometre justificar-ho. Això és exactament el que fa la propera lliçó, 06-02: Classificació de Riscos i CVSS, on aprendrem a calcular i llegir un vector CVSS, a traduir el score a un rating i, sobretot, a distingir la severitat tècnica del risc de negoci per a TechNova. Documentar és tenir les peces; classificar és saber quines atacar primer.