Cuando hablamos de Pentesting Web, es común pensar inmediatamente en herramientas, payloads y vulnerabilidades: SQL Injection, XSS, SSRF, XXE, LFI, RCE y muchas otras técnicas forman parte del lenguaje cotidiano de una evaluación de seguridad.

Y, por supuesto, conocer estas técnicas es importante.

Pero existe una pregunta mucho más interesante:

¿CÓMO DECIDE UN PENTESTER QUÉ HACER DESPUÉS?

Cuando un investigador se enfrenta por primera vez a una aplicación web desconocida, no existe una lista capaz de indicarle exactamente cuál será su siguiente movimiento. No sabe dónde está la vulnerabilidad. Ni siquiera sabe si existe.

Cada decisión debe tomarse bajo incertidumbre.

Hoy contamos con metodologías, frameworks y plataformas que permiten automatizar buena parte de la enumeración inicial. Sin embargo, estas herramientas no reemplazan el proceso cognitivo mediante el cual un investigador transforma una observación en conocimiento.

Por eso, propongo mirar el Pentesting Web desde una perspectiva diferente: como un proceso de investigación científica.

No porque un pentest sea un laboratorio académico, sino porque comparte una dinámica fundamental:

observar → formular hipótesis → experimentar → obtener evidencia → actualizar el conocimiento.

EL PROBLEMA DEL PESTESTING BASADO EN CHECKLISTS

Una metodología lineal puede verse más o menos así:

Fingerprint → Directory Bruteforce → SQLi → XSS → CSRF → SSRF → XXE → SSTI → LFI → RCE

El problema no es utilizar estas pruebas.

El problema aparece cuando el checklist termina reemplazando al razonamiento.

Un checklist indica qué probar, pero no necesariamente por qué probarlo.

Esto puede generar un comportamiento mecánico:

Encontramos un parámetro → probamos SQLi → no funciona → probamos XSS → no funciona → probamos SSTI → tampoco funciona → volvemos a empezar.

El investigador está probando vulnerabilidades porque las recuerda, no porque la evidencia del sistema indique que esas pruebas tienen sentido.

Un checklist puede aportar cobertura, pero no necesariamente explica qué hipótesis debería investigarse.

PROBAR MÁS NO NECESARIAMENTE SIGNIFICA APRENDER MÁS

El enfoque mecánico puede parecer productivo porque genera muchas solicitudes y pruebas.

Pero una gran cantidad de pruebas no significa necesariamente una gran cantidad de conocimiento.

Este tipo de comportamiento puede terminar provocando:

• miles de solicitudes innecesarias;
• mayor probabilidad de detección;
• pérdida de tiempo;
• agotamiento cognitivo;
• dificultad para descubrir vulnerabilidades relacionadas con la lógica de negocio.

La diferencia entre un investigador junior y uno experimentado, entonces, no necesariamente está en quién conoce más payloads.

Muchas veces está en quién sabe qué experimento puede aportar más conocimiento sobre el sistema.

DEL DATO A LA EVIDENCIA: CÓMO CONSTRUYE CONOCIMIENTO UN PENTESTER

Para entender esta diferencia tenemos que detenernos en algo fundamental: ¿qué significa realmente conocer una aplicación?

No es lo mismo tener datos que tener información o conocimiento.

El proceso puede entenderse como una serie de niveles:

Datos → Información → Conocimiento → Hipótesis → Experimentos → Evidencia

Cada etapa se construye sobre la anterior.

El razonamiento ofensivo evoluciona desde la observación de datos hasta la obtención de evidencia mediante experimentación.

1. Datos: observar sin interpretar

Los datos son simplemente observaciones.

Por ejemplo, durante una evaluación podemos encontrar:

GET /api/orders/1043

HTTP/2 200 OK

{

  "id": 1043,

  "user": "apolo",

  "total": 79.90

}

En este punto sabemos que recibimos una respuesta.

Pero todavía no sabemos qué significa.

Tenemos un dato.

2. Información: comenzar a relacionar

Cuando comenzamos a conectar diferentes observaciones, aparece la información.

Por ejemplo:

• La aplicación expone una API REST.
• Los pedidos utilizan identificadores numéricos.
• Los identificadores parecen ser correlativos.
• El acceso requiere autenticación.

Ya no estamos simplemente observando respuestas aisladas.

Estamos empezando a encontrar relaciones dentro del sistema.

3. Conocimiento: incorporar experiencia

El conocimiento aparece cuando esas relaciones se combinan con lo que el investigador ya sabe.

Por experiencia previa, sabemos que algunas APIs que utilizan identificadores numéricos pueden presentar problemas cuando confían únicamente en ese identificador y no verifican correctamente que el objeto solicitado pertenezca al usuario autenticado.

Pero aquí hay algo importante: todavía no tenemos una vulnerabilidad.

Tenemos comprensión del comportamiento y una posibilidad que merece ser investigada.

4. Hipótesis: convertir la observación en una pregunta comprobable

Ahora podemos formular una hipótesis:

Si el endpoint utiliza únicamente el número del pedido para recuperar la información, probablemente no está verificando que ese pedido pertenezca al usuario autenticado.

Esto cambia completamente nuestra forma de trabajar.

Ya no estamos preguntándonos:

"¿Qué vulnerabilidad puedo probar?"

Estamos preguntándonos:

"¿Qué explicación podría existir para lo que estoy observando y cómo puedo comprobarla?"

La vulnerabilidad todavía no está confirmada.

Existe una hipótesis.

5. El experimento: intentar demostrar que estamos equivocados

Una buena hipótesis debe generar una predicción observable.

Si nuestra hipótesis es correcta, entonces modificar el identificador del pedido podría provocar que la aplicación devuelva información perteneciente a otro usuario.

Ahí aparece un experimento concreto.

En un entorno autorizado de evaluación, podemos comprobar qué ocurre al solicitar otro identificador manteniendo la misma sesión.

Si la aplicación devuelve información que no debería estar disponible para ese usuario, entonces aparece evidencia que permite confirmar la existencia de un IDOR (Insecure Direct Object Reference).

El documento de Eduardo utiliza precisamente este ejemplo para mostrar cómo una observación puede transformarse progresivamente en una hipótesis y finalmente en un experimento comprobable.

EL PENTESTER NO BUSCA CONFIRMAR SUS IDEAS. BUSCA INTENTAR REFUTARLAS.

Esta es, quizás, una de las ideas más interesantes del enfoque.

Cada petición HTTP puede convertirse en un experimento diseñado para falsar una hipótesis.

El ciclo sería:

Hipótesis → Predicción → Experimento → Resultado → Actualización del modelo

¿Por qué es importante intentar refutar una hipótesis?

Porque evita uno de los errores cognitivos más comunes durante una evaluación de seguridad:

El sesgo de confirmación.

Es fácil enamorarse de una hipótesis.

Si creemos que existe una vulnerabilidad, podemos comenzar a buscar únicamente comportamientos que parezcan demostrar que tenemos razón.

El enfoque experimental obliga a hacer lo contrario:

buscar evidencia que pueda demostrar que nuestra hipótesis es incorrecta.

Esto reduce la posibilidad de interpretar un comportamiento ambiguo como una vulnerabilidad.

EL MODELO MENTAL: CADA INTERACCIÓN CAMBIA LO QUE SABEMOS

Mientras investiga, el pentester construye un modelo mental de la aplicación.

Al comenzar una evaluación, ese modelo está prácticamente vacío respecto del sistema objetivo.

Pero cada interacción agrega información.

Una primera petición HTTP puede revelar determinadas relaciones.

El descubrimiento de un panel administrativo agrega otras.

Un flujo de recuperación de contraseña puede revelar nuevas conexiones.

Cada interacción incorpora nuevos nodos y relaciones al modelo mental.

Cada interacción con la aplicación agrega nuevos nodos y relaciones al modelo mental del investigador.

EL OBJETIVO INMEDIATO NO ES ENCONTRAR UNA VULNERABILIDAD

Esta perspectiva cambia una idea fundamental.

Podríamos pensar que el objetivo de un pentest es simplemente:

"Encontrar vulnerabilidades".

Pero el enfoque propuesto por Eduardo plantea algo más profundo:

El objetivo inmediato es mejorar y afinar el modelo mental del sistema.

Las vulnerabilidades aparecen como consecuencia de comprender correctamente cómo funciona la aplicación.

Esto es especialmente relevante cuando hablamos de vulnerabilidades de lógica de negocio, donde un scanner automatizado puede tener muchas dificultades para entender que un determinado flujo de la aplicación no debería comportarse de cierta manera.

El espacio de hipótesis

Mientras el modelo mental crece, el investigador también mantiene una lista de posibilidades.

Por ejemplo:

• ¿Existe SQL Injection?
• ¿Existe XSS?
• ¿Existe IDOR?
• ¿Existe SSRF?
• ¿Existe Session Fixation?
• ¿Existe una Race Condition?

Pero hay una distinción fundamental:

ninguna de ellas es todavía una vulnerabilidad confirmada.

Son simplemente hipótesis compatibles con la información disponible hasta ese momento.

A medida que aparecen nuevas evidencias, algunas hipótesis desaparecen, otras adquieren mayor plausibilidad y también pueden aparecer nuevas.

El trabajo del pentester consiste en refinar continuamente ese espacio de hipótesis.

ABDUCCIÓN: EL RAZONAMIENTO DETRÁS DEL PENTESTING WEB

Aquí aparece un concepto especialmente interesante: el razonamiento abductivo.

La deducción parte de una regla conocida y obtiene una conclusión necesaria.

La inducción observa diferentes casos y construye una generalización.

La abducción, en cambio, busca la explicación más plausible para una observación incompleta.

Y eso se parece mucho a lo que hace un pentester.

• Observa un comportamiento.
• Encuentra una relación.
• Formula una explicación posible.
• Después diseña un experimento para comprobarla.
• No se trata simplemente de lanzar payloads hasta encontrar algo.
• Se trata de reducir incertidumbre de manera disciplinada.

Probar múltiples técnicas sin una hipótesis puede convertir el pentesting en un ciclo repetitivo que no aporta conocimiento.

EL CICLO COMPLETO DEL PENTESTING BASADO EN HIPÓTESIS

Podemos resumir este enfoque en un ciclo continuo:

Sistema

↓

Observaciones

↓

Datos → Información → Conocimiento

↓

Modelo mental del sistema

↓

Lista de sospechas / hipótesis

↓

Priorización

↓

Predicciones

↓

Experimentos

↓

Evidencia

↓

Actualización del modelo mental

↓

Nueva lista de hipótesis

↓

Repetir

El proceso no tiene necesariamente un punto final predefinido. Continúa mientras existan hipótesis suficientemente plausibles y con valor investigativo.

CONCLUSIÓN: PENSAR ANTES DE PROBAR

El Pentesting Web suele describirse desde su superficie: herramientas, payloads, scanners y vulnerabilidades.

Pero detrás de todo eso existe algo mucho más importante: el razonamiento del investigador.

Un buen pentester no es necesariamente quien conoce más técnicas de explotación.

Es quien puede observar un sistema desconocido, construir rápidamente un modelo mental, identificar posibilidades, formular hipótesis relevantes y diseñar experimentos que permitan obtener evidencia.

En otras palabras, el trabajo ofensivo moderno no consiste en explorar aplicaciones al azar.

Consiste en explorar disciplinadamente el espacio de hipótesis que explica cómo podría comportarse una aplicación.

Y quizás ahí está una de las mayores diferencias entre ejecutar un pentest y realmente investigar una aplicación.