Qué es el pentesting: guía completa para empresas

Un pentesting (o test de penetración) es, dicho llano, un ataque controlado contra tus propios sistemas para encontrar fallos de seguridad antes de que los encuentre alguien que no debería. Lo hace un equipo autorizado por escrito, con un alcance claro y un calendario acordado, y termina con un informe que dice qué falla, cómo de grave es y qué hay que tocar para arreglarlo. La diferencia con un escáner automático es importante: un pentesting profesional encadena vulnerabilidades, mide el impacto real y entrega evidencias reproducibles. Y la diferencia con un Red Team también: el pentesting busca fallos en activos concretos, el Red Team mide si tu defensa se entera cuando alguien ya está dentro.

En España es, además, la prueba técnica que evidencia controles obligatorios en NIS2, DORA, ENS, ISO 27001 y PCI DSS. Esta guía explica qué es exactamente, las 5 fases, los tipos según alcance, las metodologías estándar y cómo elegir un proveedor que aporte valor.

Qué es el pentesting

El pentesting (penetration testing, también conocido como test de intrusión o auditoría técnica de seguridad) es un ejercicio autorizado y acotado en el tiempo. Un equipo de profesionales ofensivos intenta comprometer activos concretos de tu organización (una aplicación web, una API, una red interna, un entorno cloud, una app móvil) con técnicas equivalentes a las de un atacante real, y al terminar entrega un informe que describe cada hallazgo, su impacto, una prueba de concepto y la corrección recomendada.

La pregunta que responde un pentesting es directa: ¿qué fallos hay y cómo de graves son si alguien los explota?. No es la misma pregunta que responde un Red Team (¿podríamos comprometer el negocio sin que nos detectaran?) ni un escáner de vulnerabilidades (¿qué vulnerabilidades conocidas detecta una herramienta automática a primera vista?). El pentesting está deliberadamente entre ambos: profundidad técnica de un ataque manual con alcance acotado para que los hallazgos sean accionables.

En la práctica, un proyecto de pentesting profesional:

• Parte de un alcance escrito: lista de URLs, rangos de IP, repositorios, identidades cloud, cuentas de prueba, ventanas horarias permitidas y técnicas excluidas.
• Se ejecuta con autorización por escrito del titular del activo (las rules of engagement o ROE).
• Combina herramientas profesionales (Burp Suite, Nuclei, Nmap, Metasploit, BloodHound, scripts propios) con técnica manual cuando lo automático ya no encuentra nada nuevo.
• Encadena hallazgos cuando es posible: una fuga de información que filtra credenciales, credenciales que dan acceso a una API, una API mal autorizada que permite tomar control de cuentas privilegiadas.
• Termina con un informe ejecutivo legible por dirección y un informe técnico detallado por hallazgo: severidad CVSS, prueba de concepto, request/response capturados, impacto y remediación.
• Suele incluir una fase de retest unas semanas después para validar que las correcciones funcionan.

La duración típica oscila entre 1 y 4 semanas de ejecución activa, según tamaño y complejidad del alcance.

Para qué sirve un pentesting

Bien ejecutado y bien aprovechado, un pentesting produce cinco resultados concretos que un escáner automatizado no produce:

1. Inventario priorizado de riesgos reales, no listas largas sin contexto. Una vulnerabilidad CVSS 9.8 que requiere acceso de administrador previo es menos urgente que una CVSS 6.5 explotable sin autenticación desde Internet, y el informe lo refleja.
2. Evidencias reproducibles para que el equipo de desarrollo arregle sin tener que adivinar qué pasó.
3. Cumplimiento normativo demostrable. NIS2, DORA y ENS exigen pruebas técnicas periódicas; el informe firmado es la evidencia auditable.
4. Lectura honesta del estado de seguridad que puedes presentar al comité de dirección, a la junta o a un cliente B2B durante una due diligence.
5. Reducción medible del riesgo tras aplicar las correcciones y pasar el retest.

Visto desde el otro lado: el incidente medio en una pyme española, según el panel de INCIBE, supone decenas a cientos de miles de euros entre rescate, paralización y recuperación. Un pentesting anual cuesta una fracción y, sobre todo, evita el incidente cuando sus hallazgos se corrigen.

Pentesting vs auditoría vs Red Team vs escaneo de vulnerabilidades

Los cuatro términos se usan a menudo como sinónimos en pliegos y propuestas, y no lo son. Confundirlos lleva a comprar un servicio que no responde a la pregunta que tu organización necesita responder. La diferencia rápida:

Escáner de vulnerabilidades. Una herramienta automática (Nessus, Qualys, OpenVAS) lanza chequeos contra una IP o URL y devuelve un listado de vulnerabilidades conocidas con CVE asignado. Tarda minutos u horas. Es útil como primera capa, pero no encadena fallos ni mide impacto. La pregunta que responde: qué detecta una herramienta sin criterio.

Auditoría de seguridad. Revisión documental y técnica para verificar el cumplimiento de un marco normativo (ENS, ISO 27001, RGPD). Combina entrevistas, revisión de políticas, evidencias y, a veces, un pentesting incrustado. Dura semanas. La pregunta que responde: cumple esta organización un marco.

Pentesting. Ataque manual y autorizado contra activos concretos durante 1 a 4 semanas. Profundidad técnica alta, hallazgos con prueba de concepto reproducible. La pregunta que responde: qué fallos reales tiene este activo y cómo de graves son.

Red Team. Simulación adversarial completa de 6 a 16 semanas, sin avisar al SOC. Objetivos de negocio (control del dominio, exfiltración, llegar al CEO), evasión de detección, OSINT, phishing y movimiento lateral. La pregunta que responde: podría un atacante motivado comprometernos sin que nos enteráramos.

Si quieres profundizar en la diferencia entre pentesting y Red Team, tenemos una pieza dedicada en la guía completa de Red Team para empresas. Y si tu organización es entidad financiera designada bajo DORA, la prueba que necesitas se llama TLPT y la cubrimos en TIBER-EU y TLPT: Red Team intelligence-led en banca.

Tipos de pentesting según el alcance

El "pentesting" es un paraguas. Lo que cambia entre uno y otro es qué se ataca y, por tanto, qué herramientas, qué metodología y qué perfil técnico hace falta.

• Pentesting web. Aplicaciones HTTP/HTTPS, paneles de administración, e-commerce, plataformas SaaS. Cubre OWASP Top 10 (inyección, autenticación rota, XSS, IDOR, SSRF, deserialización), lógica de negocio y errores de autorización. Es el más demandado y la piedra angular de cualquier programa de seguridad en el ciclo de desarrollo (SDLC).
• Pentesting móvil. Aplicaciones iOS y Android revisadas sobre los criterios de OWASP MASVS: análisis del binario, almacenamiento local, comunicación con backend, ofuscación, detección de jailbreak/root y permisos. Hay un caso práctico de preparación de entorno en rootear AVD Android con Burp Suite para pentesting.
• Pentesting de infraestructura interna. Simulación de un atacante con acceso a la LAN corporativa, o asumiendo breach en un endpoint. Active Directory, segmentación, configuraciones de servidores, parches, credenciales reutilizadas, escalada lateral.
• Pentesting de infraestructura externa (perímetro). Lo que un atacante ve desde Internet: servicios expuestos, fugas en certificados, paneles olvidados, VPN sin MFA, subdominios huérfanos.
• Pentesting cloud (AWS, Azure, GCP). IAM, configuración de buckets, secretos en repositorios, redes virtuales, contenedores, funciones serverless. La superficie ha cambiado: ya no se ataca un servidor, se atacan identidades y políticas.
• Pentesting de APIs (REST, GraphQL, gRPC). Foco en autenticación, autorización por objeto y por función, rate limiting, mass assignment, inyección y exposición de datos. La especificación OWASP API Security Top 10 es el estándar.
• Pentesting IoT/OT. Dispositivos, firmware, protocolos industriales (Modbus, S7, OPC UA), redes OT segmentadas. Requiere prudencia operativa: muchas pruebas no se hacen en producción.
• Pentesting de ingeniería social. Phishing dirigido, pretexting telefónico, pruebas físicas in situ. Se contrata cuando el factor humano es el vector más probable.

Una organización mediana suele necesitar pentesting web, perímetro e interno una vez al año, más uno específico (móvil, cloud o API) según su negocio. Las pymes con un único producto digital empiezan por web y API.

Caja blanca, caja negra y caja gris

Independientemente del tipo, el modelo de información que se entrega al equipo ofensivo cambia el resultado. Hay tres modelos:

• Caja negra. Solo URL pública o IP. Sin credenciales, sin código fuente. Útil para medir qué ve un atacante externo sin contexto previo.
• Caja gris. Credenciales de usuario y rol limitado. Es el modelo más habitual porque equilibra realismo y eficiencia.
• Caja blanca. Código fuente, arquitectura, credenciales privilegiadas. Para máxima cobertura técnica en aplicaciones críticas.

Para una explicación más detallada con ejemplos, ver diferencias entre auditoría caja blanca, negra y gris.

Las 5 fases de un pentesting profesional

Casi todas las metodologías formales convergen en cinco fases. Cambian los nombres pero no el orden ni la lógica.

1. Reconocimiento (recon)

Recopilar información del objetivo sin tocarlo todavía. En externo, OSINT: Shodan, Censys, GitHub público, fugas en combolists, certificados TLS, DNS pasivo. En interno, mapeo de red, descubrimiento de hosts vivos, enumeración de servicios. El objetivo es construir un mapa: qué hay, dónde está y qué versión corre.

2. Análisis y enumeración

Identificar tecnologías, versiones, endpoints, parámetros, usuarios y permisos. Aquí se cruzan los datos del recon con bases de vulnerabilidades conocidas (CVE, exploit-db) para anticipar qué podría funcionar antes de tocar nada.

3. Explotación

La fase más visible. Se intentan las técnicas que las dos primeras fases han sugerido: inyección SQL, deserialización, autenticación rota, abuso de tokens JWT, RCE en componente desactualizado, robo de tokens AWS por SSRF. No es lanzar un exploit y ver qué pasa: cada intento se documenta con su request, su response y el impacto.

4. Postexplotación

Tras un acceso inicial, el equipo evalúa qué se puede conseguir desde ahí: pivotar a otra red, escalar privilegios, persistir, exfiltrar datos sensibles, acceder a buzones del comité de dirección. Sin postexplotación, el informe minimiza el riesgo real porque solo cuenta el primer paso.

5. Documentación y informe

El entregable. Un buen informe contiene:

• Resumen ejecutivo legible por no-técnicos, con conclusiones y prioridades.
• Hallazgos detallados: título, severidad CVSS v3.1, descripción técnica, prueba de concepto reproducible, impacto en el negocio y recomendación de mitigación.
• Anexos con logs, capturas y, cuando aplica, cadenas de explotación documentadas paso a paso.

A las semanas, la fase opcional pero muy recomendada de retest verifica que las correcciones aplicadas funcionan y cierra el ciclo.

¿El pentesting es legal? Marco normativo y autorización

El pentesting es legal cuando media autorización expresa del titular del activo y se ejecuta dentro del alcance acordado. Sin esa autorización, las mismas técnicas constituirían un delito tipificado en los artículos 197 a 197 bis y 264 a 264 ter del Código Penal español (acceso no autorizado a sistemas informáticos, daños y descubrimiento o revelación de secretos).

Los cuatro elementos que debe contener cualquier proyecto de pentesting profesional son:

1. Contrato y NDA entre cliente y proveedor.
2. Rules of engagement (ROE) firmadas: alcance, ventanas horarias, técnicas permitidas y excluidas, contactos de emergencia, acuerdos sobre datos sensibles encontrados.
3. Autorización del titular del activo cuando este no es el propio cliente. En SaaS multi-tenant, por ejemplo, hace falta autorización del proveedor además del cliente.
4. Tratamiento de datos personales alineado con el RGPD: si durante la prueba se accede a datos personales, el contrato debe describir su tratamiento, conservación y destrucción.

Ningún proveedor serio empieza sin estos cuatro elementos por escrito. Si alguien te ofrece "empezar mañana" sin ROE firmadas, es señal directa para no contratar.

Metodologías estándar: OWASP, OSSTMM, PTES, NIST 800-115

El sector trabaja sobre cuatro estándares principales. Un proveedor profesional declara cuál sigue y cómo lo adapta.

• OWASP Web Security Testing Guide (WSTG). El estándar de facto para aplicaciones web. Cubre desde recopilación de información hasta criptografía, autorización, gestión de sesiones, lógica de negocio y APIs.
• OWASP MASVS y MASTG. Equivalente para aplicaciones móviles. Define niveles L1 (estándar) y L2 (alto riesgo) más los requisitos de resistencia.
• OSSTMM (Open Source Security Testing Methodology Manual). Enfocado en pruebas operativas medibles. Útil cuando el cliente exige métricas reproducibles.
• PTES (Penetration Testing Execution Standard). Orientado a la ejecución, con énfasis en preengagement, threat modeling y postexplotación.
• NIST SP 800-115. La guía estadounidense que usan muchos pliegos públicos. Ortodoxa pero clara.

En la práctica, la mayoría de proveedores combinan OWASP WSTG + PTES para web y API, MASVS + MASTG para móvil y NIST 800-115 + criterio propio para infraestructura.

Pentesting y compliance: NIS2, DORA, ENS, ISO 27001, PCI DSS

El pentesting es una de las pruebas técnicas que evidencian controles obligatorios en los marcos que aplican a empresas y administraciones en España y la UE.

• NIS2 (artículo 21.2). Exige pruebas técnicas periódicas como parte de las medidas de gestión de riesgos. Frecuencia: anual mínimo y tras cambios significativos en la infraestructura.
• DORA (TIBER-EU). Las entidades financieras designadas necesitan TLPT acreditado cada tres años; el resto, pentesting avanzado anual.
• ENS (Real Decreto 311/2022). Pruebas de penetración y análisis de vulnerabilidades en categorías media y alta, con frecuencia anual.
• ISO 27001 (control A.8.29). Pruebas técnicas en sistemas de información con frecuencia definida por el análisis de riesgos del SGSI; lo razonable es anual.
• PCI DSS v4.0 (requisito 11.4). Pentesting interno y externo anual y tras cambios significativos en la red CDE (entorno de datos del titular).

Un mismo proyecto bien diseñado cubre simultáneamente la evidencia técnica para varios marcos. Eso es exactamente lo que un proveedor profesional debe articular en la propuesta.

Cómo elegir un proveedor de pentesting profesional

Cuatro criterios separan un proveedor que aporta valor de uno que entrega un informe automatizado de Nessus pintado de azul:

1. Equipo técnico verificable. Pide nombres de las personas que ejecutarán el proyecto, sus certificaciones (OSCP, OSWE, OSEP, eWPT, eCPPT, CRTO, GPEN) y referencias de proyectos similares. Un equipo serio responde sin reparos.

2. Investigación propia y CVEs publicados. Los proveedores que descubren vulnerabilidades en software comercial y publican advisories CVE demuestran capacidad técnica real. En la página de investigación de Secra listamos los CVE que hemos descubierto.

3. Metodología explícita. La propuesta debe declarar qué estándar sigue (OWASP WSTG, MASVS, PTES, NIST 800-115) y qué adapta de él. Si el documento no lo dice, probablemente no haya metodología.

4. Calidad del informe muestra. Pide un informe muestra con datos anonimizados. Mira si los hallazgos están priorizados, si hay prueba de concepto reproducible, si la severidad CVSS está justificada y si la sección ejecutiva habla en términos de negocio. Lo demás son palabras.

Algo que no debería ser criterio: el precio más bajo. Un pentesting low-cost suele significar un escáner automatizado con plantilla. La diferencia se nota cuando llega un incidente y descubres que en el informe no aparecía la vía que lo causó.

Cuándo y con qué frecuencia hacer pentesting

Las cuatro situaciones que disparan un proyecto de pentesting son sencillas de identificar:

1. Antes de salir a producción una aplicación nueva o un cambio mayor.
2. Anualmente como mínimo, para mantener la evidencia de cumplimiento.
3. Tras un incidente o un near miss, para validar que la causa raíz se ha cerrado y que el atacante no ha dejado huellas.
4. Bajo exigencia contractual de un cliente B2B durante el proceso de due diligence o renovación.

Como heurística rápida: si tu organización publica software al exterior, una vez al año es el suelo. Si manejas datos sensibles regulados (sanitarios, financieros, infraestructura crítica), dos veces al año es más realista.

Preguntas frecuentes

¿Cuánto dura un pentesting?

Entre 1 y 4 semanas de ejecución activa según el tamaño del alcance. Una aplicación web mediana se cubre en 5 a 10 días laborables. Una infraestructura interna corporativa puede requerir 2 a 3 semanas. El informe final llega típicamente 3 a 7 días después del cierre de la fase técnica.

¿Qué diferencia hay entre pentesting y test de penetración?

Ninguna. Son sinónimos: pentesting es la contracción inglesa de "penetration testing" y "test de penetración" es la traducción literal al español. Lo mismo aplica a "auditoría técnica de seguridad" cuando se refiere a una prueba ofensiva con alcance acotado.

¿El pentesting puede romper sistemas en producción?

Un pentesting profesional minimiza el riesgo operativo: ROE escritas, ventanas horarias acordadas, técnicas potencialmente disruptivas excluidas o ejecutadas en preproducción y contactos de emergencia disponibles. El riesgo no es cero, pero está controlado, y la alternativa (descubrir el fallo cuando lo aprovecha un atacante real) es mucho peor.

¿Qué es mejor, un pentesting o un Red Team?

Responden a preguntas distintas. El pentesting mide qué fallos hay en activos concretos. El Red Team mide si tu defensa detectaría un ataque real y completo sin avisar. El orden lógico es: primero pentesting hasta tener un nivel de higiene aceptable, luego Red Team para evaluar la capacidad de detección bajo presión. Si tu Blue Team es inmaduro, un Red Team probablemente desperdicie presupuesto.

¿Cuánto cuesta un pentesting?

El precio depende del alcance, el tipo (web, móvil, infraestructura, cloud), la metodología exigida y la duración. La industria en España trabaja en horquillas amplias: una aplicación web mediana puede ir desde unos pocos miles de euros a decenas de miles según complejidad. Lo más útil no es comparar precio en abstracto sino comparar propuestas con el mismo alcance entre proveedores y mirar el equipo, la metodología y el informe muestra.

¿Necesito hacer pentesting si ya tengo un EDR y un SOC?

Sí. El EDR y el SOC defienden y detectan; el pentesting encuentra los fallos antes de que el atacante los explote. Son capas complementarias, no alternativas. De hecho, el resultado del pentesting suele alimentar las reglas de detección del SOC con escenarios que tu equipo defensivo no había considerado.

¿Qué certificaciones debe tener el equipo que ejecuta el pentesting?

Las más reconocidas en la industria son OSCP, OSWE y OSEP (Offensive Security), eWPT y eCPPT (eLearnSecurity / INE), CRTO (Zero-Point Security) y GPEN (SANS / GIAC). Una certificación no garantiza calidad por sí sola, pero su ausencia total en el equipo asignado al proyecto es señal de alarma.

¿Qué pasa con los datos sensibles que el pentester encuentra durante la prueba?

Deben tratarse según lo que el contrato y las ROE establezcan. Lo habitual: minimización (no se exfiltra más de lo necesario para demostrar el hallazgo), cifrado en tránsito y en reposo, conservación limitada al período mínimo para elaborar el informe y destrucción verificable al cierre. Si en algún momento aparecen datos personales no previstos, el procedimiento debe estar pactado por escrito.

Cómo trabajamos los pentesting en Secra

En Secra hacemos pentesting web, móvil, de infraestructura interna y externa, cloud y APIs sobre OWASP WSTG, MASVS y PTES, con un equipo que publica investigación propia (CVE-2025-40652 en CoverManager, CVE-2023-3512 en Setelsa ConacWin CB) y entrega informes con prueba de concepto reproducible, severidad CVSS justificada y resumen ejecutivo separado del técnico. El alcance se diseña para que la misma prueba sirva como evidencia ante auditorías NIS2, DORA, ENS, ISO 27001 o PCI DSS según aplique.

Si quieres una propuesta concreta para tu alcance, escríbenos a través de contacto o consulta los servicios de auditoría web y móvil, auditoría de infraestructura, auditoría cloud y auditoría IoT/OT. Si lo que buscas es un ejercicio adversarial de espectro completo, la siguiente lectura es nuestra guía de Red Team para empresas.