Un pentest, o prueba de penetración, es una evaluación de seguridad en la que un profesional intenta explotar de forma controlada vulnerabilidades y combinaciones de debilidades para determinar qué podría conseguir un atacante dentro de un alcance autorizado. El resultado no es una lista de fallas posibles: es una demostración, con evidencia, de qué se pudo hacer, hasta dónde se llegó y qué conviene corregir primero. JanusNet, empresa de ciberseguridad en Chile, realiza pentesting como parte de sus servicios de Seguridad Ofensiva.
Un pentest no consiste en ejecutar un escáner y entregar su reporte. El escáner ayuda a cubrir terreno; la prueba de penetración es el trabajo de una persona que interpreta, valida qué es real, combina condiciones y comprueba el impacto. Esta guía explica qué puede probarse, cómo se define el alcance, qué deberías recibir y cómo elegir un proveedor.
¿Necesitas un pentest o un escaneo de vulnerabilidades?
Si necesitas inventario y amplitud, un escaneo puede ser suficiente. Si necesitas saber qué es explotable, hasta dónde permite llegar y qué corregir primero, necesitas un pentest. Son herramientas distintas y complementarias, no una versión buena y una mala de lo mismo.
| Escaneo de vulnerabilidades | Pentest | |
|---|---|---|
| Automatización | Alta: es el núcleo del servicio | De apoyo: cubre terreno, no decide |
| Validación humana | Limitada | Central |
| Explotación controlada | Normalmente no | Sí, dentro del alcance acordado |
| Encadenamiento de hallazgos | Limitado | Sí: combina condiciones para avanzar |
| Contexto del negocio | Limitado | Alto: qué permite cada hallazgo en tu entorno |
| Resultado | Vulnerabilidades potenciales, con un puntaje genérico | Riesgo explotable demostrado, con evidencia y prioridad |
Un escáner encuentra vulnerabilidades conocidas a partir de firmas y no entiende la lógica de negocio ni el contexto. Un pentest lo usa como punto de partida y pone el esfuerzo humano donde la automatización no llega.
¿Qué se puede evaluar en un pentest?
Casi cualquier parte de tu superficie de ataque, siempre que quede definida en el alcance. Lo habitual se agrupa así:
- Perímetro externo: servicios expuestos, infraestructura accesible desde Internet y las rutas de entrada que abren.
- Red interna e identidades: segmentación, privilegios y sistemas de identidad como Active Directory, cuando forman parte del alcance.
- Aplicaciones web: autenticación, autorización, sesiones, lógica de negocio y vulnerabilidades técnicas.
- APIs: autenticación, autorización, exposición de datos, lógica y abuso de funciones.
- Nube: identidades, permisos, configuraciones, exposición y relaciones de confianza.
- Aplicaciones móviles: cuando corresponda, la aplicación, su almacenamiento local y su comunicación con el backend.
No hace falta probar todo a la vez: se parte por lo que responde la pregunta más urgente.
¿Qué tipo de pentest necesito?
Depende de dos decisiones distintas: qué quieres probar y con cuánta información parte el pentester.
Según lo que quieres probar. Externo, interno, web o API, nube, móvil o identidades: cada uno responde una pregunta distinta, y muchas veces conviene combinar dos.
Según la información disponible. Aquí aparecen los términos black box, grey box y white box. Ninguno es universalmente mejor: responden preguntas diferentes.
| Modalidad | Qué sabe el pentester al empezar | Qué pregunta responde |
|---|---|---|
| Black box | Nada o casi nada: solo lo que un atacante externo podría descubrir | ¿Qué puede encontrar y explotar alguien sin conocimiento interno? |
| Grey box | Contexto parcial: credenciales de un usuario común, documentación básica, el mapa de la aplicación | ¿Qué puede hacer alguien con acceso limitado, o cuánto se descubre si no partimos de cero? |
| White box | Visibilidad amplia: arquitectura, configuraciones, cuentas de prueba y, a veces, código | ¿Qué podemos encontrar si maximizamos profundidad y cobertura en el tiempo disponible? |
Black box se parece más a un atacante real; white box encuentra más en menos tiempo; grey box es el punto intermedio más frecuente.
¿Pentest y red team son lo mismo?
No. Un pentest tiene un alcance técnico definido y busca identificar y validar vulnerabilidades y rutas explotables dentro de él; el equipo que defiende suele saber que está ocurriendo. Un red team persigue un objetivo concreto emulando a un adversario, con un alcance más amplio, e intenta alcanzarlo evitando o enfrentando los controles defensivos según las reglas del ejercicio. El primero mide qué tienes abierto; el segundo, si te das cuenta y cómo respondes.
El alcance importa más de lo que parece
«Necesito un pentest» todavía no define el servicio. Dos pentests con el mismo nombre pueden tener alcances muy distintos, y por eso no existe un precio ni una duración universales. Antes de ejecutar hay que fijar:
- Objetivo y activos: qué pregunta quieres responder; dominios, direcciones, aplicaciones, APIs y ambientes que entran; usuarios y roles a probar; credenciales, si la modalidad las contempla.
- Condiciones de ejecución: horarios y ventanas, exclusiones, restricciones, técnicas autorizadas y qué se hace con los datos a los que se llegue.
- Seguridad de la ejecución: contactos de emergencia por ambos lados, criterios de detención y si el retest está contemplado.
Es lo que convierte un nombre de servicio en una prueba que responde tu pregunta sin interrumpir tu operación.
¿No sabes todavía qué alcance necesitas?
Definimos juntos qué conviene probar
Cuéntanos qué te preocupa y qué tienes expuesto. Con eso proponemos el tipo de prueba, la modalidad y los límites, y recién entonces cotizamos.
Un pentest debe estar autorizado
Un pentest solo se ejecuta con un alcance acordado y una autorización expresa de quien puede darla, por escrito y antes de tocar nada. Las reglas de ejecución fijan qué se prueba, qué no, hasta dónde se explota, los contactos de escalamiento y cómo se manejan los incidentes que la prueba detecte o provoque. Sin eso no es una prueba: es un incidente.
¿Cómo se realiza un pentest?
Con una secuencia que va del acuerdo a la corrección. Es la forma en que JanusNet ordena el trabajo, apoyada en dos referencias públicas reconocidas: OWASP para aplicaciones y APIs y MITRE ATT&CK para describir las técnicas de un adversario. Son referencias metodológicas, no certificaciones, y hay otras maneras válidas de agrupar las fases.
- Alcance
- Reconocimiento
- Validación
- Explotación controlada
- Impacto
- Evidencia
- Remediación
- Retest
Se acuerdan alcance y reglas; se recorre el objetivo como lo haría un atacante y lo encontrado se convierte en hipótesis; la validación descarta falsos positivos; la explotación controlada avanza dentro de los límites para medir el impacto real. Todo queda con evidencia, el informe ordena la remediación y, cuando está contemplado en el alcance, un retest comprueba que lo corregido quedó cerrado. Un hallazgo crítico se comunica en cuanto se confirma, no al final.
El valor no está solo en encontrar vulnerabilidades
Una vulnerabilidad aislada puede tener un impacto limitado. Varias condiciones combinadas pueden formar una ruta de ataque: la cadena que permite avanzar desde un punto expuesto hasta un activo crítico. Un servicio publicado, una credencial reutilizada, un usuario con más permisos de los que necesita y una red sin segmentar son cuatro hallazgos «medianos» que, encadenados, terminan en la base de datos de clientes.
Buscar rutas, y no solo fallas sueltas, es lo que distingue un pentest de un listado. El ejemplo completo de una ruta hipotética, con la lectura para gerencia y para TI, está en Seguridad Ofensiva.
Severidad no es prioridad
Una vulnerabilidad técnicamente severa no siempre es lo primero que hay que corregir. La prioridad también depende de si es explotable en tu entorno, de su exposición, del activo y los datos que alcanza, del privilegio que otorga, de si se encadena con otras y del impacto para el negocio. Un informe útil ordena por eso, no solo por un puntaje genérico.
¿Qué debería recibir después de un pentest?
Más que un informe: información para decidir y para corregir, en los dos lenguajes que necesita la organización.
| Para dirección | Para los equipos técnicos |
|---|---|
| Qué riesgo real se demostró y qué activos alcanza | Cada hallazgo con su evidencia y las condiciones que lo hicieron posible |
| Cuál sería el impacto para el negocio | La ruta seguida y hasta dónde se llegó |
| Qué corregir primero y por qué | Impacto técnico, recomendación concreta y prioridad |
| Qué exposición relevante queda abierta | Qué debería revisarse en el resto del entorno |
Cuando el alcance lo contempla, se suman una sesión de resultados y un retest sobre lo corregido. Si lo que recibes es la exportación de un escáner con otro logo, no recibiste un pentest.
¿Un pentest puede afectar sistemas productivos?
Sí, existe riesgo operativo, y por eso un pentest profesional define alcance, técnicas permitidas, ventanas, límites y criterios de detención. El riesgo se controla y se minimiza, pero no se puede prometer cero impacto: algunas técnicas cargan sistemas o provocan comportamientos inesperados. Lo que sí se hace es probar producción con más cuidado, excluir lo que no admite riesgo, acordar horarios y detenerse cuando algo se sale del plan.
¿El pentest también puede probar el EDR o el SOC?
Sí, cuando el alcance contempla la validación de detecciones. La actividad ejecutada se contrasta con lo que observaron el EDR, el SIEM o el SOC, y si una actividad que se esperaba detectar pasa inadvertida, puede convertirse en un hallazgo. No toda ausencia de alerta es una falla: depende del objetivo, de la telemetría disponible y de qué se esperaba detectar. Cuando la pregunta principal es esa, el ejercicio adecuado es un purple team.
¿Cuándo conviene realizar un pentest?
Cuando hay una pregunta concreta que responder. Los casos más frecuentes:
- Antes de sacar a producción un sistema, un portal o una API.
- Después de un cambio relevante: una migración, una integración con un tercero, un cambio de arquitectura o una exposición nueva.
- Cuando un cliente, un contrato o una auditoría lo requieren.
- Después de un incidente, para validar hipótesis concretas sobre cómo podría repetirse.
- Como parte de un programa periódico basado en riesgo.
No existe una frecuencia universal: depende del riesgo, de la velocidad de cambio del entorno, de los requisitos contractuales o regulatorios y del contexto de cada organización.
Cómo elegir una empresa de pentesting
Siete preguntas que separan un pentest de una lista de vulnerabilidades, con cualquier proveedor.
- Pregunta quién realizará la prueba, no solo quién la vende: quién define el alcance, quién ejecuta y quién presenta, y si es la misma persona.
- Pide claridad sobre el alcance: qué entra, qué no, con qué modalidad y con qué límites.
- Comprueba cuánto depende de automatización. Las herramientas son necesarias, pero el servicio no debería reducirse a entregar resultados de escáneres.
- Pregunta cómo validan el impacto: si explotan de forma controlada, si encadenan hallazgos y cómo demuestran hasta dónde se llegó.
- Revisa cómo será el entregable: pide un ejemplo sanitizado y confirma que sirve para decidir y para remediar.
- Pregunta qué ocurre después: sesión de resultados, aclaraciones durante la remediación y retest, si forma parte del alcance.
- Revisa cómo manejan la información y el acceso: credenciales, evidencia y datos generados durante el ejercicio, y qué pasa con ellos al terminar.
Las certificaciones del equipo son una señal útil, no un requisito universal ni una garantía.
Cómo aborda JanusNet una prueba de penetración
Con las mismas respuestas que conviene exigirle a cualquier proveedor. Cada prueba tiene un operador asignado que acuerda el alcance, ejecuta, interpreta y presenta los resultados; las herramientas cubren terreno, pero el criterio y la decisión de hasta dónde llegar son de esa persona. La explotación es controlada, se buscan rutas de ataque y no solo fallas sueltas, y cada hallazgo se entrega con evidencia, impacto y recomendación, priorizado por lo que permite en tu entorno.
Cuando está contemplado en el alcance, se realiza retest sobre lo corregido y se contrasta la actividad ejecutada con lo que observaron tus defensas; JanusNet opera además un SOC, así que esa segunda lectura forma parte del mismo trabajo. Qué se puede comprobar y cómo se convierte en remediación está en Seguridad Ofensiva.
¿Cuánto cuesta y cuánto demora un pentest?
No existe un precio ni una duración únicos, porque los fija el alcance: cantidad y tipo de activos, aplicaciones y APIs, roles a probar, complejidad, modalidad, profundidad, restricciones y si el retest está contemplado. El camino es siempre el mismo: definir el alcance y, con eso, cotizar y planificar.
Preguntas frecuentes
¿Qué es un pentest?
Una prueba de seguridad en la que un profesional, con autorización y dentro de un alcance acordado, intenta explotar de forma controlada vulnerabilidades y combinaciones de debilidades para demostrar qué podría conseguir un atacante.
¿Pentesting y ethical hacking son lo mismo?
En la práctica se usan como sinónimos: ethical hacking es el nombre genérico de la actividad autorizada de atacar sistemas para encontrar fallas, y el pentest es su forma más habitual como servicio, con alcance, reglas y entregables definidos.
¿Qué tipo de pentest necesito?
El que responde tu pregunta: externo si te preocupa lo expuesto a Internet, interno o de identidades si quieres saber qué haría alguien con acceso, web o API si el riesgo está en una aplicación, nube si está en el entorno y sus permisos. Muchas veces conviene combinar dos.
¿Cuánto demora un pentest?
Depende del alcance, la profundidad, la cantidad de activos, las restricciones y la modalidad. No hay una duración universal; se estima después de definir el alcance, no antes.
¿Cuánto cuesta un pentest?
No existe un precio único. El esfuerzo depende de la cantidad y el tipo de activos, las aplicaciones, los roles, la complejidad, la modalidad, la profundidad, las restricciones y el retest. El valor se determina mediante una cotización, después de definir el alcance.
¿ISO 27001 exige hacer pentesting?
No como requisito universal. ISO/IEC 27001 exige gestionar las vulnerabilidades técnicas y evaluar que los controles funcionan, y una prueba de penetración puede ser un mecanismo de validación técnica dentro de ese contexto. Hacer un pentest no equivale a cumplir la norma ni a certificarse.
Fuentes
- NIST SP 800-115, Technical Guide to Information Security Testing and Assessment: la definición de prueba de penetración, la búsqueda de combinaciones de vulnerabilidades, las fases de planificación, descubrimiento, ataque e informe, las reglas de enfrentamiento, la utilidad para medir la capacidad de detección y la advertencia de que el riesgo para los sistemas se mitiga pero no se elimina.
- OWASP Web Security Testing Guide, introducción: la relación entre herramientas automatizadas y prueba manual, y la limitación de los escáneres frente a la lógica de negocio y el contexto.
- ISO/IEC 27001:2022, Information security management systems. Requirements: los requisitos de evaluación del desempeño y de gestión de vulnerabilidades técnicas, que no prescriben una prueba de penetración.
Estas fuentes se usaron para verificar los conceptos de este artículo. OWASP y MITRE ATT&CK son además referencias metodológicas que JanusNet usa en sus pruebas; no son certificaciones ni requisitos de ninguna norma. La secuencia de trabajo, los criterios de prioridad y los ejemplos corresponden a la forma en que JanusNet, empresa de ciberseguridad en Chile, realiza sus pruebas de penetración.