Pentesting

Un escáner puede informar de una versión vulnerable. Un pentest empieza cuando esa observación se convierte en una pregunta que todavía no está resuelta: ¿la condición existe en la configuración efectiva, puede alcanzarse desde la posición evaluada y permite obtener una capacidad con impacto real?

La diferencia parece pequeña hasta que el entorno contradice la etiqueta. Un proxy puede ocultar el backend. Un parche puede haberse aplicado sin modificar el banner. Una credencial válida puede carecer de permisos sobre el recurso que interesa. Un hallazgo aislado puede ser inofensivo y, al mismo tiempo, proporcionar el dato que completa una cadena con otras dos debilidades. El pentesting existe para reducir esa distancia entre la posibilidad y la evidencia.

Las guías de evaluación técnica llevan décadas combinando revisión, identificación, análisis y pruebas activas. NIST SP 800-115, publicada en 2008, ya separaba planificación, descubrimiento, ataque e informe y advertía que ninguna técnica ofrece por sí sola una imagen completa. El entorno actual ha ampliado el problema. Una aplicación web depende de identidades federadas, APIs, proveedores cloud, pipelines, endpoints y servicios internos. La frontera que interesa rara vez coincide con un único host.

Por eso un pentest moderno conserva dos movimientos a la vez. El primero busca cobertura: qué activos, interfaces, funciones, identidades y relaciones del alcance se han examinado. El segundo busca profundidad: qué observaciones justifican seguir una rama hasta demostrar una capacidad, un encadenamiento o un impacto. Perseguir el primer foothold y abandonar el resto del alcance produce una historia interesante, pero una evaluación incompleta. Ejecutar cientos de checks sin validar ninguno produce volumen, pero poca certeza.

El equilibrio cambia según el encargo. Una evaluación web puede profundizar en la lógica de una sola aplicación. Una evaluación interna debe repartir tiempo entre segmentos, servicios, Active Directory y rutas de confianza. La disciplina consiste en hacer visible esa elección para que el informe distinga lo probado, lo parcialmente probado y lo que quedó fuera.

Los objetivos, el alcance, las exclusiones, los contactos, el tratamiento de datos y los límites operativos se fijan antes de empezar. Estas condiciones no son un prólogo administrativo. Cambian la técnica.

Una prueba que puede bloquear cuentas necesita conocer umbrales y ventanas. Una carga que escribe en disco necesita un procedimiento de retirada. Una validación sobre producción puede detenerse al demostrar lectura de un registro sintético, mientras un laboratorio permite explorar la cadena completa. Alcance y reglas de enfrentamiento desarrolla cómo se formalizan estas decisiones.

El operador traduce después el encargo a cuatro vistas que deben mantenerse sincronizadas:

Vista	Pregunta que debe poder responderse
Activos	¿Qué sistemas, nombres, interfaces, aplicaciones e identidades existen?
Superficie	¿Qué servicios, rutas, funciones y fronteras de confianza son alcanzables?
Hipótesis	¿Qué condición concreta podría convertirse en una capacidad?
Cobertura	¿Qué se probó, desde qué posición, con qué profundidad y qué sigue pendiente?

El inventario de activos evita que una señal desaparezca entre outputs. El mapa de superficie sitúa esa señal en un sistema. Las hipótesis convierten observaciones en preguntas contrastables. La cobertura impide que la atención sobre una rama oculte todo lo que no se ha examinado.

Cada rama técnica recorre un bucle. Primero formula una hipótesis a partir de una señal. Después elige la interacción mínima capaz de refutarla o sostenerla. Antes de ejecutarla define qué aspecto tendría un resultado positivo, uno negativo y uno ambiguo. Finalmente observa la respuesta, los cambios de estado y los artefactos disponibles, actualiza el modelo y decide si debe profundizar, pivotar o cerrar.

Supongamos que una petición a un recurso administrativo devuelve 403. Esa respuesta confirma que algún componente procesó la ruta, pero todavía no identifica qué componente ni qué política decidió el rechazo. El siguiente paso puede comparar roles, observar la cadena de proxies, variar el método o reproducir la petición directamente contra un backend conocido. Ejecutar inmediatamente un fuzzer más grande añade tráfico sin resolver la ambigüedad.

Esta separación entre observación e interpretación es una de las diferencias más importantes entre operar y coleccionar resultados:

• un timeout conserva causas de red, filtrado, saturación y aplicación
• una versión afectada conserva dudas sobre backports y configuración
• una credencial válida no demuestra autorización sobre todos los recursos
• una shell no explica todavía identidad, integridad, proceso padre ni alcance
• un check negativo bajo una identidad no descarta exposición bajo otra

El trabajo senior conserva esas diferencias porque cada una selecciona una prueba distinta. Cuando una herramienta infiere una conclusión, se identifica la señal que utilizó y se valida manualmente si esa conclusión sostiene un hallazgo.

La explotación controlada convierte una condición en una capacidad verificable. La prueba mínima depende del hallazgo. Puede consistir en leer un recurso sintético, ejecutar en un contexto identificado, asumir una identidad, cruzar una frontera de confianza o demostrar una operación de negocio previamente acordada.

La profundidad útil no termina en shell obtained. Una sesión solo adquiere significado cuando se conocen el host, la identidad, el nivel de integridad, el transporte, la estabilidad, el proceso y las restricciones observables. La prueba debe explicar además prerrequisitos, fiabilidad, controles encontrados, artefactos creados y procedimiento de limpieza.

Los encadenamientos se documentan como dependencias, no como una narración retrospectiva que parece inevitable. Una exposición de nombres puede permitir enumerar usuarios. Una credencial puede abrir un servicio. Ese servicio puede revelar una ruta privilegiada. Cada enlace conserva su evidencia y sus condiciones iniciales. Si una credencial solo funciona desde una nueva posición de red, esa posición forma parte del encadenamiento.

También existe un criterio de parada. Si una nueva acción aporta poco a la demostración y aumenta de forma material el riesgo de inestabilidad, exposición de datos o cambio de estado, se conserva la evidencia disponible y se escala la decisión. Detenerse con criterio es una conclusión técnica, no una prueba incompleta ocultada.

Durante la evaluación aparecen activos, hipótesis, credenciales, sesiones, pivots, evidencias y tareas de limpieza. Cada elemento tiene ciclo de vida. Una nueva posición de red abre una vista de cobertura separada. Una cuenta se registra con origen, formato, ámbito, servicios probados y condiciones de bloqueo. Una sesión conserva host, identidad, integridad, transporte, PID y proceso padre cuando sean observables.

Este control permite reconstruir qué se sabía antes de una acción, qué se probó, qué cambió y por qué se tomó la siguiente decisión. También evita repetir intentos, mezclar datos de clientes o perder una rama porque el terminal dejó de mostrar su output. Los templates de control operacional convierten ese modelo en registros utilizables.

El proceso completo suele recorrer preparación, descubrimiento, validación, explotación, análisis posterior, informe, limpieza y retest. Esas fases orientan, pero no sustituyen el bucle de hipótesis. Una observación obtenida durante explotación puede devolver el trabajo a enumeración. Un hallazgo redactado puede revelar que falta una evidencia y reabrir una prueba. El ciclo de una evaluación desarrolla estas transiciones.

Actividad	Resultado
Vulnerability assessment	Inventario y priorización de debilidades potenciales
Pentest	Validación manual de explotabilidad e impacto en un alcance
Red team	Evaluación orientada a objetivos frente a un adversario emulado
Bug bounty	Investigación bajo una política y un modelo de recompensa definidos

Las fronteras no son absolutas. Un vulnerability assessment puede incluir validaciones y un pentest puede utilizar automatización a gran escala. La diferencia operativa está en la pregunta dominante. El assessment prioriza condiciones potenciales. El pentest demuestra explotabilidad e impacto dentro de un alcance. El Red Team intenta alcanzar objetivos bajo un modelo de adversario y evalúa también la respuesta organizativa. Un bug bounty investiga activos permitidos por una política y recompensa hallazgos elegibles.

Confundirlas cambia las expectativas. Un cliente que espera cobertura no recibe el mismo producto que uno que quiere medir detección frente a una operación sigilosa. Las herramientas compartidas no vuelven equivalentes sus objetivos, restricciones ni deliverables.

Cada hallazgo debe permitir reproducir la condición sin exponer datos innecesarios. Identifica activo, condiciones iniciales, pasos mínimos, evidencia, causa, impacto, controles existentes y una recomendación cuya aplicación pueda verificarse. El output original se conserva como evidencia, pero no reemplaza la explicación.

El informe también describe cobertura y límites. Un área sin hallazgos no se presenta como segura si apenas pudo probarse. Los caminos explotados se distinguen de los técnicamente posibles. Las acciones omitidas por estabilidad o tratamiento de datos conservan la evidencia que motivó la decisión.

Un retest cierra el ciclo cuando reproduce primero la condición original, verifica el cambio y comprueba si la remediación alteró rutas relacionadas. Marcar un hallazgo como cerrado porque desapareció un banner repetiría el error que el pentest trataba de evitar. La conclusión debe apoyarse en el comportamiento efectivo.

• ¿Qué diferencia la evidencia de un pentest del output de un escáner?
• ¿Cómo se equilibran cobertura y profundidad durante una evaluación?
• ¿Por qué una capacidad debe documentarse con sus condiciones iniciales?
• ¿Qué diferencia el resultado de un pentest del de un vulnerability assessment?

• NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
• CISA: Cyber Hygiene Services
• PTES: Penetration Testing Execution Standard