El pentesting manual es una evaluación de seguridad en la que expertos humanos, y no herramientas automatizadas, atacan un sistema con la autorización de su propietario para encontrar y demostrar vulnerabilidades explotables. El pentester encadena fallos, abusa de la lógica de negocio y razona sobre para qué sirve la aplicación, que es justamente la parte que un escáner no puede hacer.
En el benchmark de diciembre de 2023 de Fluid Attacks, que enfrentó a 36 herramientas AppSec de terceros contra un conjunto de 1.201 vulnerabilidades distribuidas en 105 categorías CWE, un solo pentester encontró 1.076: 89,6 % de recall con 100 % de precisión. De esas, 743 vulnerabilidades, el 61,9 % del conjunto, las halló únicamente el pentester y ninguna herramienta automatizada.
Esta página cubre qué es y qué no es el pentesting manual, por qué importa, en qué se diferencia del escaneo automatizado, los enfoques black box, white box y gray box, las cinco fases de un proyecto, y cómo Fluid Attacks lo ejecuta de forma continua en lugar de una vez al año.
¿Qué es el pentesting manual?
El pentesting manual es un ataque simulado y autorizado que ejecutan expertos en seguridad con las mismas herramientas y técnicas que usaría un adversario real, para identificar, explotar y reportar vulnerabilidades en un sistema. La palabra "manual" es una aclaración, no una categoría: el pentesting es trabajo humano por definición, y el término existe porque algunos proveedores empezaron a vender el escaneo automatizado como "pentesting automatizado".
Un pentester sí usa herramientas. La distinción no está en si hay software de por medio, sino en quién decide qué atacar a continuación. En un escaneo, esa decisión es un conjunto fijo de reglas. En un pentest, es una persona que acaba de aprender algo del objetivo y cambia de plan.
Qué no es el pentesting manual: no es un escaneo de vulnerabilidades, no es una casilla de cumplimiento y no es un evento único. Un informe que enumera hallazgos que nadie intentó explotar es un escaneo con portada.
¿Por qué es importante el pentesting manual?
Las herramientas automatizadas te dicen dónde puede haber una debilidad. Un pentester te dice qué puede hacer realmente un atacante con ella, y en esa brecha vive la mayor parte del riesgo real.
Demuestra la explotabilidad, no la supone
La NIST Technical Guide to Information Security Testing and Assessment (SP 800-115, 2008) traza la misma línea: las técnicas automatizadas identifican debilidades candidatas, y la validación manual es la que confirma si esas candidatas son reales y alcanzables. Sin ese paso, un equipo gasta su presupuesto de remediación en hallazgos que ningún atacante habría podido usar.
La diferencia de severidad es medible. En el informe State of Attacks 2026 de Fluid Attacks, que cubre todos los sistemas evaluados entre el 1 de enero y el 31 de diciembre de 2025, los hallazgos reportados por pentesters promediaron 93,2 unidades CVSSF cada uno, frente a 15,5 unidades CVSSF de los reportados por herramientas automatizadas: alrededor de seis veces más riesgo por hallazgo.
Encuentra lo que no tiene firma
Los fallos de lógica de negocio, el control de acceso roto y el abuso de funcionalidades legítimas no tienen un patrón que emparejar. La OWASP Web Security Testing Guide trata las pruebas de lógica de negocio como una disciplina manual justamente por eso: un escáner puede confirmar que un endpoint exige un token, pero no sabe que un usuario con rol A nunca debería poder aprobar su propia transacción.
Aquí también pesa más el objetivo del atacante que el fallo individual. Como lo expresó Daniel Yepes, Security Analyst de Fluid Attacks, sobre el trabajo de red team:
"También ayuda a reforzar la idea de que obtener Domain Admin no es el objetivo principal, sino parte del camino para alcanzar una meta final".
Un escáner no tiene meta final. Un pentester sí, y el adversario también.
El pentesting manual y el automatizado no son alternativas
La pregunta útil no es cuál comprar. Es en qué es bueno cada uno, y qué pasa cuando te saltas el otro.
Las herramientas automatizadas cubren amplitud y velocidad: corren en cada commit, sobre todo el código, a un costo por escaneo cercano a cero. Las pruebas manuales cubren profundidad: menos hallazgos, mucho más graves, y alcanzables solo por alguien que entiende la aplicación.
Medida | Herramientas automatizadas | Pentesters |
Porcentaje de la exposición al riesgo total detectada | 55,8 % | 44,2 % |
Porcentaje de todas las vulnerabilidades reportadas | 88,4 % | 11,6 % |
Severidad promedio por hallazgo (CVSSF) | 15,5 | 93,2 |
Porcentaje de vulnerabilidades de severidad crítica | 13 % | 87 % |
Lee las dos últimas filas juntas. Los pentesters reportaron aproximadamente una de cada nueve vulnerabilidades, y esas pocas concentraron el 87 % de las vulnerabilidades de severidad crítica reportadas ese año. Amplitud sin profundidad deja los peores problemas en producción.
La comparación de Fluid Attacks entre simulación de brechas y ataques, pentesting y red teaming llega a la misma conclusión desde el lado del costo: apoyarse solo en la automatización puede salir más caro con el tiempo que sostener evaluaciones manuales continuas, porque el intervalo entre el momento en que una nueva técnica de ataque se hace pública y el momento en que una herramienta aprende a detectarla es una ventana de falsos negativos que nadie está cubriendo. El mismo análisis señala que las organizaciones deberían solicitar pruebas para cada sistema de forma continua, y no en un ciclo anual.
Profundiza: BAS vs. pentesting vs. red teaming y Tipos de pruebas de penetración.
El pentesting manual en Fluid Attacks
Ejecutamos el pentesting manual como un servicio continuo junto a nuestros propios escáneres y a la IA, no como un proyecto anual aparte. Hace parte del plan Advanced, y lo que sigue es cómo funciona, incluido dónde se queda corto.
Qué evaluamos y bajo qué reglas
Cada proyecto parte de una autorización escrita y un alcance definido: qué aplicaciones, qué entornos, qué técnicas entran y cuáles no. No se evalúa nada que el propietario no haya aceptado.
Nuestro pentesting se entrega como Pentesting as a Service (PTaaS), y la práctica está acreditada externamente: Fluid Attacks es proveedor acreditado por CREST en Penetration Testing y firmante del CREST AI Charter. Nuestros pentesters tienen OSCP, OSEP, OSEE, OSCE3, OSWE y OSED entre más de 60 certificaciones de seguridad ofensiva en el equipo.
Los hallazgos no se describen en texto libre. Cada uno se mapea a una entrada de nuestra base de datos abierta de vulnerabilidades, donde cada criterio de evaluación está documentado y cruzado con CWE y con los estándares ante los que reporta el cliente. Dos pentesters que reportan el mismo problema en sistemas distintos lo reportan igual.
Cuando ese mismo trabajo destapa un fallo en software de terceros y no en el código del cliente, pasa por divulgación coordinada y termina en nuestros avisos de seguridad públicos.
Cómo se ve en la práctica
El proyecto no termina con un PDF. Un hallazgo recorre una secuencia fija, y cada paso deja evidencia en la plataforma.
Paso | Qué produce el pentester | Qué recibe el equipo de desarrollo |
Reportar | Prueba de explotación, ubicación afectada, severidad en CVSSF | Un hallazgo reproducible, no una advertencia |
Clasificar | Mapeo a la entrada de la base de datos de vulnerabilidades y a CWE | Ejemplos de código conforme para esa debilidad exacta |
Consultar | Una llamada de 30 minutos sobre los problemas más complejos | Acceso directo a quien lo rompió, vía Talk to a Pentester |
Reatacar | Intento de reexplotación después del arreglo | Confirmación de que el arreglo aguanta, o un hallazgo reabierto |
Hallazgo reportado manualmente en la plataforma de Fluid Attacks. La columna Technique muestra que vino de un pentester y no de un escáner, y esa misma vista ofrece el reataque y una llamada con el pentester que lo reportó.
El reataque es la parte que los equipos subestiman. Un arreglo que nunca se volvió a explotar es una suposición.
Evidencia de explotación que el pentester adjunta al mismo hallazgo: la grabación del ataque y el código que lo permite. Esto es lo que separa una vulnerabilidad demostrada de una apenas señalada.
Qué encuentra el pentester que el escáner no
En el benchmark de diciembre de 2023, el pentester detectó el 99,8 % de la exposición al riesgo del conjunto de datos medida en CVSSF, frente al 8,8 % de la mejor herramienta de terceros. En el puntaje F1 ponderado por CVSSF, el pentester llegó a 99,5 % y la mejor herramienta automatizada de terceros, a 16,2 %.
Las 743 vulnerabilidades que solo encontró el pentester no eran exóticas. Eran los problemas que exigen entender qué se supone que hace la aplicación antes de poder notar que está haciendo otra cosa.
Profundiza: Aumentar la precisión de AST mediante pentesting.
Lo que estas cifras no dicen
Dos cosas sobre esas cifras que una página de proveedor se guardaría.
Primero, el benchmark corrió contra un conjunto controlado de 1.201 vulnerabilidades conocidas, no contra una aplicación en producción con incógnitas desconocidas. Una cifra de recall significa "de las vulnerabilidades que sembramos, se encontró esta proporción". No promete la misma proporción de todo lo que existe en tu sistema.
Segundo, el escáner automatizado con mejor recall en ese benchmark es el nuestro, no el de un tercero. La comparación justa para quien compra es la de arriba: el pentester contra la mejor herramienta de terceros disponible.
Y el límite estructural: un pentest no escala a cada commit. Una persona no puede volver a evaluar una aplicación cuarenta veces al día, que es exactamente para lo que sirve la automatización. Quien te venda las pruebas manuales como reemplazo del escaneo te está vendiendo un hueco de cobertura.
La práctica que decide todo lo demás
Encontrar vulnerabilidades es la mitad fácil. La cifra que mueve el riesgo es la proporción que se arregla, y la práctica que más la cambia es romper la compilación cuando el código es inseguro.
En los datos del State of Attacks 2026, los sistemas que usan nuestro CI Gate alcanzaron una tasa de remediación del 72,2 % al cierre del año, con una mediana de 22 días para remediar. Los sistemas sin él llegaron al 58 %, con una mediana de 30 días.
Pentesting black box, white box y gray box
Estos tres términos describen cuánto sabe el pentester del objetivo antes de empezar. No son niveles de calidad; simulan atacantes distintos.
Enfoque | Qué recibe el pentester | Atacante que simula | Limitación principal |
Black box | Nada más allá de lo que es alcanzable públicamente | Alguien de afuera sin acceso previo | El tiempo se va en reconocimiento en vez de profundidad; las rutas internas pueden quedar sin evaluar |
White box | Código fuente, arquitectura, credenciales, documentación | Un adversario con conocimiento interno completo | Es el escenario externo menos realista, pero el de mayor cobertura por hora |
Gray box | Conocimiento parcial: una cuenta de usuario, algo de documentación | Un usuario malicioso, o un atacante que ya obtuvo una credencial por phishing | La cobertura depende de qué porción de conocimiento se compartió |
Pentesting black box
El pentester no recibe información interna y trabaja solo con lo que está expuesto. Refleja la posición de un atacante externo, y es el enfoque que mejor responde "¿a qué puede llegar alguien desde internet?". El costo es el tiempo: las horas que se van en mapear el objetivo son horas que no se gastan en explotarlo.
Pentesting white box
El pentester recibe código fuente, diagramas de arquitectura, credenciales y documentación. La cobertura por hora es la más alta de las tres porque no hay que inferir nada, y es el enfoque que se empareja de forma natural con la revisión de código seguro. Responde "¿qué está mal aquí dentro?" en vez de "¿qué puede hacer alguien de afuera?".
Pentesting gray box
El pentester arranca con conocimiento parcial, típicamente una cuenta de bajos privilegios. Este es el escenario real más común: la mayoría de las brechas empiezan con algún nivel de acceso legítimo, sea robado, comprado u otorgado. Pone a prueba la escalada de privilegios y el movimiento lateral, que el black box muchas veces nunca alcanza.
Las cinco fases de un pentest manual
La secuencia de abajo es la forma real de un proyecto. Se corresponde con las siete fases del Penetration Testing Execution Standard (PTES), la referencia de la industria que formalizó esta estructura, con el modelado de amenazas integrado en la planeación y la posexplotación dentro de la fase de explotación.
Fase aquí | Fase correspondiente en PTES |
Planeación | Pre-engagement Interactions · Threat Modeling |
Reconocimiento | Intelligence Gathering |
Evaluación de vulnerabilidades | Vulnerability Analysis |
Explotación | Exploitation · Post-Exploitation |
Reporte | Reporting |
Planeación
Se acuerdan por escrito el alcance, las reglas de enfrentamiento, los objetivos y la autorización. Aquí también el equipo define cómo se vería un ataque exitoso para este negocio en concreto, que es lo que convierte una lista de fallos en una narrativa de riesgo.
Reconocimiento
El pentester reúne todo lo disponible sobre el objetivo: servicios expuestos, tecnologías, subdominios, información de empleados, repositorios de código públicos. Primero va la recolección pasiva y después el sondeo activo. La calidad de esta fase pone el techo de todo lo que viene después.
Evaluación de vulnerabilidades
Se identifican las debilidades candidatas, con herramientas automatizadas como acelerador y análisis manual para interpretarlas. Aquí es donde se descartan los falsos positivos y donde empiezan a aparecer problemas que ninguna herramienta señaló, porque el pentester ya está razonando sobre cómo volver las propias funcionalidades de la aplicación en su contra.
Explotación
El pentester intenta explotar las candidatas, encadenándolas cuando se puede, y luego explora a qué da acceso ese punto de apoyo: otros sistemas, otros datos, más privilegios. Una vulnerabilidad calificada como media de forma aislada muchas veces se vuelve crítica aquí, cuando se demuestra que es el primer paso de una cadena.
Reporte
Cada hallazgo queda documentado con evidencia, pasos de reproducción, severidad y guía de remediación, escrito para las personas que lo van a arreglar. En un modelo continuo, el informe no es el final del proyecto; el reataque sí.
Conclusiones
El pentesting manual es la parte de las pruebas de seguridad que ninguna herramienta ha reemplazado: una persona que entiende el negocio ataca el sistema como lo haría un adversario, demuestra qué es explotable y encadena los fallos que por separado parecen inofensivos.
Los datos dicen que los dos enfoques son complementarios, no competidores. Las herramientas automatizadas reportaron el 88,4 % de las vulnerabilidades en 2025, pero los pentesters reportaron el 87 % de las de severidad crítica. Los equipos que solo corren escáneres obtienen volumen sin profundidad; los que solo hacen un pentest anual obtienen profundidad sobre una foto que queda obsoleta en semanas. La combinación, ejecutada de forma continua y respaldada por una compuerta que bloquea compilaciones inseguras, es lo que movió la remediación del 58 % al 72,2 %.
Preguntas frecuentes
¿En qué se diferencia el pentesting manual de un escaneo de vulnerabilidades?
Un escaneo señala patrones de vulnerabilidad conocidos de forma automática; en un pentest manual un experto humano explota activamente el sistema y encadena fallos que un escáner no puede reconocer. En los datos de 2025 de Fluid Attacks, los pentesters reportaron el 11,6 % de todas las vulnerabilidades pero el 44,2 % de la exposición al riesgo total, porque los problemas que encuentran son mucho más graves: 93,2 CVSSF por hallazgo frente a 15,5 de los hallazgos automatizados.
¿Cuál es la diferencia entre las pruebas black box, white box y gray box?
El black box no le da al pentester ningún conocimiento interno, el white box le da acceso completo al código fuente y a la arquitectura, y el gray box le da conocimiento parcial, como una cuenta de usuario. Simulan atacantes distintos: alguien de afuera, alguien de adentro con visibilidad total, y un usuario malicioso o comprometido, respectivamente.
¿Cuánto dura un pentest manual?
Depende del alcance, pero la pregunta más útil es la frecuencia y no la duración. Un proyecto único sobre un alcance definido suele ir de días a unas pocas semanas; las pruebas integradas de forma continua en el desarrollo atrapan los problemas mientras arreglarlos es barato, en vez de sacar a la luz el acumulado de un año de una sola vez.
¿Las herramientas de IA pueden reemplazar el pentesting manual?
Hoy no. La revisión de Fluid Attacks sobre investigación empírica de IA generativa en pentesting encontró ganancias reales en velocidad y en cobertura de pasos rutinarios, pero concluyó que la supervisión humana sigue siendo indispensable para validar lo que produce el modelo y para decidir qué perseguir después. Ver nuestro análisis de GenAI en pentesting.
¿Fluid Attacks hace pentesting manual?
Sí, de forma continua, como parte de un enfoque combinado con IA y nuestros propios escáneres. Fluid Attacks es proveedor acreditado por CREST en Penetration Testing, y cada hallazgo manual se reporta en la plataforma con su evidencia, mapeado a nuestra base de datos abierta de vulnerabilidades, abierto a una llamada de 30 minutos con el pentester que lo encontró, y verificado por reataque una vez arreglado.
Un pentester en tu código, no una vez al año
Los escáneres te dicen dónde mirar; nuestros pentesters te muestran qué haría un atacante una vez que llega ahí, y luego lo intentan. Prueba gratis · Contáctanos.
