El pentesting es una técnica de evaluación en la que profesionales de seguridad simulan ciberataques reales contra un sistema, con permiso de su propietario, para determinar qué tan expuesto está. A diferencia de un escaneo, las pruebas de penetración no se detienen en listar hallazgos sospechosos: intentan explotarlos dentro de un alcance acordado y miden hasta dónde podría llegar un atacante.
En el benchmark de Fluid Attacks, una aplicación con 1.201 vulnerabilidades sembradas en 105 categorías CWE fue evaluada por un pentester, por el escáner propio de Fluid Attacks y por 36 herramientas AppSec de terceros. Los pentesters reportaron 1.076 de esas vulnerabilidades: 89,6 % de recall, sin falsos positivos. La herramienta automatizada con mejor desempeño fue el escáner propio de Fluid Attacks, con 22,7 % de recall; la mejor herramienta de terceros llegó a 21,6 %, y las otras 34 promediaron 1,7 %.
Esta página cubre qué es y qué no es el pentesting, por qué sigue encontrando lo que las herramientas pasan por alto, cómo lo ejecuta Fluid Attacks, las fases de una prueba, los tipos y las herramientas involucradas, y con qué frecuencia deberían realizarse las pruebas de penetración.
¿Qué es el pentesting?
El pentesting manual es una evaluación de seguridad en la que un pentester ataca un objetivo de evaluación bajo reglas acordadas, explota las debilidades encontradas y documenta el impacto. Su resultado no es una lista de alertas, sino evidencia: una ruta reproducible desde un punto de entrada hasta una consecuencia de negocio.
Dos límites importan. No es escaneo de vulnerabilidades, que automatiza la detección pero se detiene antes de la explotación. Y no es red teaming, que evalúa la capacidad de detección y respuesta de una organización, no la seguridad de un sistema específico.
La técnica también se llama pentesting manual, y ese calificativo no sobra. Las herramientas apoyan el trabajo en cada fase, pero las decisiones que producen un hallazgo —qué hipótesis probar, qué debilidades encadenar, cuándo un resultado demuestra impacto— las toma una persona. El "pentesting automatizado" describe escaneo con un nombre más ambicioso.
Como el pentesting es legal y autorizado, al profesional que lo realiza se le llama pentester, hacker ético o analista de seguridad. Certificaciones como OSCP u OSEE señalan formación, pero la condición para el rol es demostrar habilidad para evadir defensas dentro de un presupuesto de tiempo y un alcance definido.
¿Por qué es importante el pentesting?
El pentesting importa porque sigue siendo de donde provienen los hallazgos de mayor riesgo. La detección automatizada mejoró y cubre una amplitud que ningún humano iguala, pero la profundidad y la prueba del impacto siguen siendo trabajo manual.
Los pentesters reportan la mayoría de los hallazgos críticos
En su informe State of Attacks 2026, Fluid Attacks analizó datos de pruebas de seguridad recolectados en sistemas de clientes entre el 1 de enero y el 31 de diciembre de 2025. Los pentesters reportaron el 87 % de los hallazgos de severidad crítica en esos sistemas.
El mismo informe muestra por qué contar hallazgos induce al error. Las herramientas automatizadas identificaron el 88,4 % del conteo total de vulnerabilidades, pero solo el 55,8 % de la exposición al riesgo total. Medido en unidades CVSSF, un hallazgo de herramienta promedió 15,5 y uno manual 93,2: seis veces más riesgo por incidencia.
Las herramientas solas dejan sin detectar la mayor parte del riesgo
El benchmark citado arriba midió ambos enfoques contra la misma aplicación. El recall del pentester fue de 89,6 % por conteo de vulnerabilidades y de 98,9 % por CVSSF, es decir, encontró casi toda la exposición al riesgo de la aplicación. Combinadas, todas las herramientas automatizadas evaluadas seguirían sin alcanzar un 60 % de recall por CVSSF.
Esa brecha no es una falla de los escáneres: reconocer patrones conocidos a gran velocidad es para lo que están construidos. Lo que no pueden hacer es razonar sobre las reglas de una aplicación, y ahí es donde el pentesting justifica su costo.
El cumplimiento fija un piso, no una meta
Varios estándares establecen una cadencia fija. PCI DSS v4.0.1 exige pruebas de penetración internas y externas al menos cada 12 meses, y pruebas sobre los controles de segmentación cada 12 meses, o cada seis meses en el caso de los proveedores de servicios. Ese ciclo de seis meses cubre los controles de segmentación, no la prueba de penetración completa, una distinción que la mayoría de los resúmenes confunde. Bajo la FTC Safeguards Rule que implementa la Gramm-Leach-Bliley Act, una institución financiera sin monitoreo continuo efectivo realiza pruebas de penetración anuales y evaluaciones de vulnerabilidades cada seis meses. Esos intervalos definen un mínimo, no una postura de seguridad. Un sistema que cambia cada semana no queda descrito por una prueba ejecutada una vez al año.
Pentesting, evaluación de vulnerabilidades y escaneo de vulnerabilidades no son alternativas
Estos tres términos suelen compararse como si una organización tuviera que elegir uno. Responden a preguntas distintas: la evaluación de vulnerabilidades es el "qué" —la evaluación sistemática de la seguridad de un sistema—, mientras que el pentesting y el escaneo son dos "cómo" que la alimentan.
Atributo | Pentesting | Escaneo de vulnerabilidades |
Ejecutado por | Un pentester, con apoyo de herramientas | Una herramienta, por calendario o disparador |
Hallazgos típicos | Fallas de lógica de negocio, evasión de control de acceso, debilidades encadenadas | Patrones vulnerables conocidos, componentes desactualizados, secretos expuestos |
Explotación | Sí, dentro del alcance acordado | No |
Falsos positivos | Casi nulos; los hallazgos se verifican antes de reportarse | Frecuentes; los resultados requieren triaje |
Cobertura | Profundidad sobre amplitud | Amplitud sobre profundidad |
Tiempo hasta el primer resultado | Días | De minutos a horas |
Ambos métodos alimentan la misma evaluación de vulnerabilidades; la comparación es entre técnicas, no entre una técnica y un objetivo.
Plantearlos como rivales lleva a la compra equivocada. Una organización que solo ejecuta escaneos automatizados obtiene amplitud sin prueba, y una que contrata pentesting una vez al año obtiene prueba sin cobertura. La combinación es lo que produce una evaluación de vulnerabilidades útil.
Pentesting en Fluid Attacks
Fluid Attacks ejecuta Pentesting as a Service (PTaaS) de forma continua, no como un compromiso puntual, junto con Secure Code Review y Reverse Engineering, y los combina con IA y escáneres propios en una sola plataforma. La compañía es CVE Numbering Authority desde 2021 —CVE-2026-6093, una inyección SQL en Corteza, es uno de los registros que asignó nuestro equipo— y proveedor de servicios de pruebas de penetración acreditado por CREST desde 2025.
Qué evaluamos y bajo qué reglas
El alcance se define por objetivo de evaluación. Los clientes registran repositorios, aplicaciones e infraestructura en la nube como objetivos, y el pentesting sigue lo que está registrado, no una lista de activos fijada meses antes. Los entornos de preproducción y de producción pueden estar ambos dentro del alcance.
Las reglas de enfrentamiento fijan los límites. Nuestros pentesters operan en safe mode por defecto, de modo que los ataques demuestran impacto sin detener las operaciones del cliente, y eso cambia solo si el cliente lo pide. Esas reglas también definen qué cuenta como prueba: un hallazgo se reporta con los pasos para reproducirlo, no con una etiqueta de severidad sola.
Cómo se ve en la práctica
Técnica | Qué inspecciona | Evidencia entregada |
PTaaS | Aplicaciones en ejecución, APIs, redes, infraestructura en la nube | Ruta de explotación, prueba de concepto en video, impacto medido en CVSSF |
Secure Code Review | Código fuente, incluida la lógica de negocio que un escáner no puede interpretar | Ubicación del código vulnerable, ejemplo de código conforme |
Reverse Engineering | Binarios compilados y paquetes móviles | Comportamiento deconstruido, secretos embebidos, controles débiles |
Reattack | La corrección que envió un desarrollador | Estado abierto o cerrado verificado para el hallazgo original |
Cada técnica manual reporta en la misma plataforma que los hallazgos automatizados, así que la remediación se rastrea en un solo lugar.
▶️ Video: explicamos cómo Fluid Attacks combina IA, escáneres y pentesters para probar software de forma continua.
Resultados manuales y automatizados, medidos sobre el mismo objetivo
Nuestro benchmark es la comparación más clara que podemos publicar, porque ambos enfoques se ejecutaron contra una aplicación idéntica.
Métrica | Pentester | Escáner de Fluid Attacks | Mejor herramienta de terceros |
Verdaderos positivos (de 1.201) | 1.076 | 273 | 260 |
Recall por conteo | 89,6 % | 22,7 % | 21,6 % |
Recall por CVSSF | 98,9 % | 8,8 % | No reportado |
Precisión | 100 % | 99 % | 72 % |
Puntaje F1 | 94,5 % | 37,0 % | Menor que 37,0 % |
Cifras del benchmark de Fluid Attacks sobre 36 herramientas AppSec de terceros contra una aplicación con 1.201 vulnerabilidades.
Sobre la misma aplicación con 1.201 vulnerabilidades, el pentester alcanzó un 89,6 % de recall sin falsos positivos.
El límite de esa cifra: 89,6 % no es 100 %
El resultado del pentester sobre ese objetivo fue 1.076 de 1.201. El benchmark cuenta 73 del resto como falsos negativos, porque el pentester omitió deliberadamente secciones que el escáner ya había cubierto; la brecha completa de 125 es lo que separa el resultado de la cobertura total. Cualquiera de las dos cifras es el argumento contra vender el pentesting como cobertura completa.
También es el argumento contra la afirmación opuesta. En 2025, las herramientas automatizadas encontraron el 88,4 % de todas las vulnerabilidades por conteo y cargaron con el 55,8 % de la exposición al riesgo total; los pentesters encontraron el 11,6 % restante de las vulnerabilidades y cargaron con el 44,2 % del riesgo. Ningún método basta por sí solo, y cualquier proveedor que presente uno como reemplazo del otro está describiendo un producto, no un resultado.
Cada corrección se vuelve a probar
Encontrar una vulnerabilidad es la mitad del trabajo. La documentación de Fluid Attacks es explícita: "you should reassess the code after a fix attempt", porque un cambio puede no cerrar el problema original o introducir uno nuevo. Los clientes solicitan reattacks desde la plataforma, automatizados o manuales, y cuando el hallazgo lo reportó el equipo de pentesting, es un pentester quien confirma si quedó realmente cerrado. Sin ese paso, un programa de pentesting mide cuántos hallazgos se marcaron como resueltos, no cuántos lo están.
¿Cuánto acceso y conocimiento reciben los pentesters?
Antes de iniciar las pruebas de penetración se acuerdan dos variables independientes: cuánta información recibe quien prueba sobre el objetivo, y cuánto sabe el propio personal de la organización sobre el ejercicio. Ninguna es un tipo de pentesting, aunque a ambas se las describa a menudo como tal.
Las pruebas opacas o de black box no entregan al pentester código fuente ni documentación interna, así que el enfoque imita al de un atacante externo. El black box testing toma más tiempo y suele revelar menos problemas, porque el tiempo se va en descubrir qué es el sistema antes de sondear cómo falla.
Las pruebas semiopacas o de gray box comparten algún detalle interno con el equipo de pentesting —notas de arquitectura, credenciales de prueba, una especificación de API— y retienen el código fuente. Es el punto intermedio práctico para una superficie autenticada.
Las pruebas transparentes o de white box comparten el código fuente y el contexto de apoyo. El white box testing produce los mejores resultados, porque el analista puede revisar código y atacar el sistema en ejecución al mismo tiempo, y puede confirmar desde la fuente si una debilidad es realmente alcanzable.
Del lado del conocimiento, en las pruebas dirigidas ambas partes comparten cada movimiento, así que las defensas se pueden ajustar y volver a verificar durante el ejercicio.
Las pruebas a ciegas entregan a quien prueba solo el nombre de la empresa.
Las pruebas a doble ciego mantienen a parte del equipo de seguridad sin saber que se contrató un ejercicio: es la configuración que recomendamos para operaciones de red teaming, porque mide tanto la detección como la exposición.
Fases del pentesting
No existe una secuencia universal única, pero las metodologías reconocidas convergen. NIST SP 800-115 (2008) agrupa las pruebas de penetración en cuatro fases: planeación, descubrimiento, ataque y reporte, con un ciclo de retroalimentación que va del ataque de vuelta al descubrimiento, porque una explotación exitosa revela superficie nueva por examinar. El Penetration Testing Execution Standard expande el mismo trabajo a siete fases y suma el modelado de amenazas y la posexplotación como pasos explícitos. Elegir una de ellas no es opcional bajo PCI DSS: el requisito 11.4.1 obliga a la entidad a documentar una metodología construida sobre enfoques aceptados por la industria.
NIST SP 800-115 modela las pruebas de penetración como cuatro fases, con la fase de ataque retroalimentando el descubrimiento. Fuente: NIST SP 800-115 (2008).
Planeación y reconocimiento
La organización y quien prueba acuerdan el alcance, los estándares aplicables y qué información se compartirá. Esos términos conforman las reglas de enfrentamiento. El modelado de amenazas va aquí: decidir qué activos querría un atacante y qué rutas valen el tiempo disponible.
Sigue el reconocimiento. El reconocimiento pasivo reúne inteligencia de fuentes públicas sin tocar el objetivo; el reconocimiento activo interactúa con él para identificar tecnologías y puntos de entrada.
Descubrimiento: escaneo y evaluación de vulnerabilidades
El pentester mapea la superficie de ataque con herramientas —escáneres de puertos para servicios expuestos, Static Application Security Testing cuando el código fuente está en el alcance, Dynamic Application Security Testing (DAST) contra el sistema en ejecución— y después trabaja lo que la automatización no puede interpretar: lógica de negocio, límites de autorización y combinaciones de debilidades inofensivas por separado.
Esta es la fase donde el trabajo manual y el escaneo automatizado más se superponen, y donde sus resultados divergen. El escaneo produce candidatos; el analista decide cuáles vale la pena atacar.
Obtención de acceso mediante explotación
Aquí es donde el pentesting se separa del escaneo. Quien prueba construye o adapta un exploit, confirma que la vulnerabilidad es alcanzable y mide qué entrega: exposición de datos, escalamiento de privilegios, movimiento lateral a sistemas adyacentes.
La inyección SQL ciega ilustra por qué esto exige criterio. El catálogo de Fluid Attacks la describe como un ataque en el que "an attacker sends queries to the server that ask the database true or false questions": la aplicación no devuelve nada útil, así que el hallazgo se confirma por comportamiento y no por salida.
Jonathan Armas, analista de seguridad en Fluid Attacks, describe esa decisión cuando un filtro bloquea la ruta habitual:
Un escáner reporta un parámetro sospechoso; elegir qué variante demuestra la explotabilidad es decisión de quien prueba.
Cada debilidad enlaza el hallazgo con su impacto, su remediación y los requisitos de seguridad que incumple.
Posexplotación y mantenimiento del acceso
Ya adentro, el analista establece cuánto tiempo podría permanecer un atacante real y hasta dónde podría moverse. Eso puede implicar un backdoor, extracción lenta de datos o manipulación de registros, todo simulado dentro del alcance acordado, para documentar la persistencia y no para lograrla. La posexplotación convierte una vulnerabilidad confirmada en una afirmación sobre el radio de impacto.
Análisis y reporte
El informe es el entregable. La Web Security Testing Guide de OWASP lo dice sin rodeos: "a good report helps your client understand your findings". Recomienda una introducción que cubra alcance, limitaciones y cronograma; un resumen ejecutivo no técnico; hallazgos detallados con calificaciones de riesgo, y artefactos de prueba reproducibles.
Un informe de pruebas de penetración debe decirle al propietario qué se evaluó, qué se encontró y cómo, qué expone cada hallazgo y qué hacer al respecto. Las pruebas de concepto en video hacen difícil disputar el impacto, y un documento claro le permite al equipo de desarrollo empezar a corregir el mismo día en que llega.
¿Cuáles son los tipos de pentesting?
Los tipos de pentesting suelen clasificarse por lo que se ataca. Las categorías que siguen van por objetivo de evaluación, que es la clasificación que usamos porque corresponde a cómo las organizaciones definen el alcance de un compromiso en la práctica.
Pruebas de penetración en aplicaciones
Las aplicaciones web y móviles son los objetivos más comunes. Más allá del OWASP Top 10, el pentesting verifica requisitos de seguridad que los escáneres no pueden evaluar; por ejemplo, restringir el acceso a los procesos críticos, que exige que las funciones que ejecutan procesos críticos de negocio estén disponibles solo para usuarios autenticados con los privilegios correspondientes.
Eso es una comprobación de lógica, no una coincidencia de patrones. Quien prueba, con una cuenta de bajo privilegio, intenta invocar directamente una función administrativa, y el resultado es o una falla de autorización verificada o un control que resiste.
Pruebas de penetración en redes
El pentesting de red externo sondea si el perímetro puede vulnerarse, con técnicas como el password spraying y el credential stuffing. Las pruebas internas establecen qué daño es posible desde adentro —ataques man-in-the-middle, fallas de segmentación, controles de acceso débiles— y suelen ser las más reveladoras de las dos.
Pruebas de penetración en IoT y hardware
Los dispositivos inteligentes se evalúan por sus restricciones de acceso lógico, la protección de los datos almacenados y transmitidos, la configuración por defecto, el manejo de credenciales y los mecanismos de actualización. Un dispositivo que sale de fábrica con una contraseña compartida por defecto y sin ruta de actualización firmada falla antes de que empiece cualquier análisis de protocolos.
Pruebas de penetración al personal
La ingeniería social apunta a las personas, no a los sistemas. El phishing es el vector más común: quien prueba suplanta a una parte de confianza para que un empleado divulgue información o ejecute algo que no debería. Los resultados se reportan como brechas de proceso, nunca como fallas individuales.
Tipos de herramientas de pentesting
Las herramientas no reemplazan al analista, pero ningún compromiso de pentesting se ejecuta sin ellas. La documentación de Fluid Attacks plantea la relación directamente: "Expert security analysts leverage automation enabled by tools to maximize their security testing speed".
Sniffers de red: monitorean el tráfico para mapear qué dispositivos se comunican, sobre qué protocolos y puertos. Ejemplo: Wireshark.
Escáneres de puertos: identifican puertos abiertos e infieren los servicios y sistemas operativos detrás de ellos. Ejemplo: Nmap.
Descifradores de contraseñas: recuperan credenciales por fuerza bruta, descifrado o material en caché. El pentesting los usa para medir la política de contraseñas en la práctica.
Escáneres de vulnerabilidades: ejecutan SAST, SCA, DAST y revisiones de postura en la nube para marcar problemas conocidos con rapidez.
Proxies web: interceptan y modifican el tráfico entre el navegador y el servidor para sondear el manejo de peticiones.
Frameworks de ataque: ensamblan y entregan payloads una vez confirmada una debilidad.
La lista es un inventario de recursos, no una metodología. El alcance, el análisis y la validación siguen en manos de quien ejecuta el compromiso de pentesting.
¿Con qué frecuencia deben hacerse las pruebas de penetración?
Tan seguido como cambie el sistema. El pentesting puntual describe un sistema el día en que se ejecutó, y cada despliegue posterior es superficie sin probar.
El pentesting continuo aborda esa brecha de tres formas: el alcance se ajusta a medida que aparecen activos nuevos en vez de quedar congelado en las reglas de enfrentamiento, el trabajo de definir alcance y conseguir personal que un compromiso puntual repite cada vez se reduce a ajustes ocasionales, y el soporte de remediación sigue disponible más allá de la ventana corta que ofrece un compromiso aislado. El análisis de Fluid Attacks sobre pruebas continuas frente a puntuales desarrolla las ventajas y desventajas en detalle.
Un matiz: el pentesting continuo no es una obligación universal. La cadencia correcta depende de qué tan rápido cambia el sistema, qué datos maneja y qué estándares aplican. Una herramienta interna estática y una plataforma de pagos que despliega a diario no necesitan la misma respuesta, y una prueba anual que satisface a un auditor todavía puede dejar once meses de cambios sin examinar.
Conclusiones
El pentesting se gana su lugar porque produce evidencia en vez de alertas. Los datos lo respaldan: el 87 % de los hallazgos de severidad crítica en los sistemas de clientes de Fluid Attacks en 2025 vino de pentesters, y sobre un objetivo controlado un solo analista encontró el 98,9 % de la exposición al riesgo frente al 8,8 % del mejor escáner. Ese es el argumento a favor del pentesting, enunciado con su base.
Lo contrario también es cierto. Ese mismo pentester dejó 125 de 1.201 vulnerabilidades sin reportar en ese objetivo, y las herramientas automatizadas cubrieron una amplitud que ningún humano podría. El pentesting es un instrumento de profundidad, y tratarlo como cobertura total es leer mal lo que dicen las cifras.
La pregunta útil no es qué método gana, sino cómo un programa de pentesting los combina, y si da un hallazgo por cerrado solo después de que alguien verificó la corrección.
Preguntas frecuentes
¿Cuál es la diferencia entre pentesting y escaneo de vulnerabilidades?
Un escáner detecta; un pentester explota. El escaneo reporta patrones potencialmente vulnerables sin confirmar que sean alcanzables, mientras que el pentesting demuestra la explotabilidad dentro de un alcance acordado y mide el impacto. El escaneo cubre más superficie, más rápido, con falsos positivos por triar.
¿Se puede automatizar el pentesting?
No. Las herramientas automatizan el reconocimiento, el escaneo y parte de la fase de ataque, pero el criterio que define un pentest —elegir qué hipótesis probar, encadenar debilidades, decidir cuándo el impacto está demostrado— es humano. Los productos que se comercializan como pentesting automatizado están haciendo escaneo automatizado.
¿Con qué frecuencia exigen las pruebas de penetración los estándares de seguridad?
El piso habitual es una vez cada 12 meses, más una nueva prueba después de cualquier cambio significativo. Eso es lo que exige PCI DSS v4.0.1 para las pruebas internas y externas; su regla de seis meses aplica a los controles de segmentación en proveedores de servicios, no a la prueba completa. La FTC Safeguards Rule bajo GLBA exige una prueba anual a las instituciones que carecen de monitoreo continuo efectivo.
¿Qué debe contener un informe de pruebas de penetración?
Alcance y limitaciones, un resumen ejecutivo no técnico, hallazgos detallados con calificaciones de riesgo y artefactos reproducibles. La Web Security Testing Guide de OWASP plantea esta estructura y añade que el informe debe servir tanto a la dirección como a los ingenieros que corregirán los problemas.
¿Fluid Attacks hace pruebas de penetración?
Sí. Fluid Attacks las entrega de forma continua a través de PTaaS, combinadas con IA, escáneres propios, revisión segura de código e ingeniería inversa. En su benchmark contra 36 herramientas AppSec de terceros, un pentester de Fluid Attacks reportó 1.076 de 1.201 vulnerabilidades sembradas, sin falsos positivos.
Prueba tus sistemas como lo haría un atacante
Nuestros pentesters atacan tus aplicaciones, redes e infraestructura en la nube de forma continua, y verifican cada corrección antes de dar un hallazgo por cerrado. Prueba gratuita · Contáctanos
