Pruebas de penetración
Lo que haría un atacante, nosotros lo hacemos antes.
Pruebas de penetración manuales alineadas con OWASP, PTES y NIST. Un equipo de pentesters certificados somete su aplicación web, API, aplicación móvil, nube y red externa e interna a la presión de un atacante real. Encontramos a mano los fallos de lógica de negocio, los exploits encadenados y las escaladas de privilegios que un escáner automático nunca detecta, y se los entregamos en un informe con evidencias.
No es un servicio que lanza un escáner y genera un PDF. Es una disciplina que simula a un atacante pasando días dentro de su sistema, con resultados demostrables y una nueva prueba tras las correcciones.
280+
Proyectos de pentest
CVSS3.1
Puntuación de riesgo
OSCP/CEH
Certificaciones
nmap -sV -p- target.partnerfy.co
443/tcp open https nginx 1.18.0 — TLS 1.2
22/tcp open ssh OpenSSH 7.4 (legacy)
gobuster dir -u https://target -w common.txt
/admin (Status: 200) [Size: 4821]
/api/v1/users (Status: 401) [Size: 38]
/.git/config (Status: 200) [Size: 263]
sqlmap -u 'target/login' --data 'u=a&p=b'
[INFO] testing 'AND boolean-based blind'
[INFO] parameter 'u' is vulnerable
[CRITICAL] SQL Injection — CVE-2024-XXXX — CVSS 9.8
Cadena de ataque
MITRE ATT&CK
Informe de pentest: hallazgos
RPT-2026-0541
Inyección SQL en el formulario de acceso
CVSS 9.8
CRIT
Secreto JWT débil: fuerza bruta
CVSS 9.1
CRIT
IDOR en /api/v1/users/{id}
CVSS 8.2
HIGH
XSS almacenado en comentarios
CVSS 7.4
HIGH
CORS mal configurado
CVSS 6.1
MED
Falta la cabecera HSTS
CVSS 3.7
LOW
FIXED
El problema
¿Por qué no basta con un escáner automático?
Escáneres como Nessus, Acunetix y OWASP ZAP son útiles, pero no sustituyen a un atacante. Un atacante encadena exploits, estudia las reglas de su negocio y las convierte en un arma, ignora el ruido y encuentra la verdadera vía de entrada. Un escáner recorre una lista de verificación; un pentester formula hipótesis específicas para su sistema.
Sin exploits encadenados
Un escáner muestra los hallazgos de forma aislada; un atacante combina tres fallos de riesgo bajo en una cadena crítica.
No ve la lógica de negocio
Un escáner jamás detectará un error lógico como “multiplicar el total del pedido por -1”.
Sin creatividad
Un pentester formula hipótesis propias de su aplicación; un escáner solo busca firmas.
Montones de falsos positivos
El 70 % de un informe de escáner de 500 páginas es ruido. Un pentester valida cada hallazgo a mano.
No conoce los límites de autorización
La regla “este usuario no debe ver este registro” solo puede probarla alguien que conozca su negocio.
No elude CAPTCHA ni WAF
Un atacante elude el WAF; un escáner se detiene en el primer 403.
Sin ingeniería social
A veces la verdadera entrada es un correo electrónico. Un escáner no puede ejecutar una simulación de phishing.
No prueba el borrado de rastros
Los atacantes borran sus rastros; si su SOC lo detecta o no, solo puede medirlo un red team.
Visualización del ataque
¿Dónde están las vulnerabilidades y cuál es su gravedad?
En cada proyecto resumimos los hallazgos en tres elementos visuales: un mapa de calor por categorías, una lista de verificación OWASP Top 10 y una línea de tiempo “escaneo → detección → corrección → nueva prueba → limpio”.
Mapa de calor por categoría de vulnerabilidad
Critical
High
Med
Low
XSS
SQLi
Auth
CORS
Crypto
Logic
IDOR
CSRF
SSRF
Upload
Headers
Deps
Cada celda es una categoría; los puntos indican el número de hallazgos y su gravedad. Su responsable ve la zona de riesgo de un vistazo.
OWASP Top 10 (2021)
Lista de verificación
- A01 Broken Access Control
- A02 Cryptographic Failures
- A03 Injection (SQL/XSS/Cmd)
- A04 Insecure Design
- A05 Security Misconfiguration
- A06 Vulnerable Components
- A07 Identification & Auth Failures
- A08 Software & Data Integrity
- A09 Logging & Monitoring Failures
- A10 SSRF
Antes y después
El proceso de pentest: escaneo → detección → corrección → nueva prueba → limpio
Cada etapa queda documentada; cada hallazgo se verifica con una nueva prueba gratuita tras la corrección.
01
Escaneo
Reconocimiento automático + manual
02
Detección
Hallazgos validados
03
Corrección
Propuesta de corrección + código de ejemplo
04
Nueva prueba
Verificación del cierre
05
Limpio
Informe limpio + certificado
¿Para quién es?
¿Quién necesita realmente este pentest?
El pentest no es obligatorio para todas las empresas, pero si encaja en alguno de estos perfiles, debería empezar hoy, no algún día. Estos son los 8 perfiles típicos.
E-commerce con pagos
Datos de tarjetas, flujos 3DSecure, abuso de cupones, manipulación de precios.
SaaS con datos de clientes
Aislamiento multitenant, límites de autorización de usuarios, alto riesgo de IDOR.
Fintech regulada
PCI-DSS, supervisores financieros y RGPD: al menos un pentest independiente al año.
Salud con datos PHI
Datos de pacientes, sistemas de citas, protección de nivel HIPAA.
Contratistas públicos
Antes de las auditorías públicas se exige una certificación independiente de pentest.
B2B con integraciones de API
API de partners, flujos OAuth, cadenas de identidad.
Apps móviles auditadas por App Store
Almacenamiento de tokens, detección de jailbreak/root, SSL pinning, cumplimiento de MASVS.
Clientes tras un incidente
Tras una brecha: una respuesta con evidencias a la pregunta “¿hay alguna otra puerta abierta?”.
Alcance del servicio
10 especialidades de pentest en un solo equipo.
De la web a la nube, del móvil a lo físico: un único equipo de ingeniería que cubre toda la superficie de ataque. Si necesita probar una sola aplicación, lo hacemos; si necesita un red team completo, también.
Pentest de red externa
Todas las IP expuestas a internet, puertos abiertos, servicios heredados.
Pentest de red interna
Desde dentro, como un empleado: el camino hasta administrador de dominio.
Pentest de aplicaciones web
OWASP Top 10, lógica de negocio y escenarios de autenticación y autorización.
Pentest de API
REST, GraphQL y gRPC; OWASP API Top 10, límites de frecuencia (rate limit), BOLA.
Pentest de aplicaciones móviles
iOS y Android, MASVS, Frida, ingeniería inversa.
Pentest de nube (AWS/Azure/GCP)
Errores de configuración de IAM, buckets públicos, IAM de Lambda, RBAC de K8s.
Ingeniería social
Campañas de phishing, vishing y USB drop: miden la concienciación del personal.
Pentest físico
Entrada a oficinas, clonación de tarjetas, tailgating, acceso a la sala de servidores.
Ejercicio de red team
Escenario completo, del correo electrónico al administrador de dominio: ¿lo detectará su SOC?
Nueva prueba tras la corrección
Verificación gratuita de que las correcciones cerraron realmente las vulnerabilidades.
Proceso
Nuestro método de pentest en 6 pasos.
Todos los proyectos siguen la misma disciplina: documento de alcance (RoE), reconocimiento, evaluación de vulnerabilidades, explotación real, informes con evidencias y, por último, una nueva prueba gratuita.
01
Alcance y reglas de intervención (RoE)
Los sistemas, los escenarios, los horarios permitidos y los límites de frecuencia se firman en un documento RoE formal. Producción o preproducción, ingeniería social dentro o fuera del alcance: todo queda aclarado desde el inicio.
02
Recopilación de información (recon)
OSINT, enumeración de subdominios, mapeo de puertos, identificación de tecnologías, búsqueda de credenciales filtradas. Retratamos la superficie con los ojos de un atacante.
03
Evaluación de vulnerabilidades
Los resultados del escáner se filtran manualmente y se diseñan escenarios de lógica de negocio. Cada hallazgo se convierte en una hipótesis.
04
Explotación (exploitation)
Las hipótesis se demuestran como lo haría un atacante real: exploits encadenados, escaladas de privilegios y exfiltración de datos, dentro de los límites éticos y con todo registrado.
05
Informes
Resumen ejecutivo, evidencias de cada hallazgo, puntuación CVSS y hoja de ruta de corrección priorizada. El equipo de desarrollo puede llegar hasta el ejemplo de código.
06
Corrección y nueva prueba
Una vez aplicadas las correcciones (normalmente en 4-8 semanas), todos los hallazgos Critical/High se vuelven a probar sin costo y se verifica su cierre.
Herramientas
Las herramientas que usamos en nuestros proyectos.
Las herramientas importan, pero importa más la mente que las usa. Las pruebas manuales siempre van por delante del escáner.
Burp Suite Pro
OWASP ZAP
Metasploit
Nmap
Nessus
Acunetix
Nuclei
Wireshark
John the Ripper
Hashcat
Cobalt Strike
Postman
ffuf
BloodHound
SQLmap
Frida
MobSF
Kali Linux
Responder
CrackMapExec
Casos reales
Algunas vulnerabilidades reales que detectamos.
Mantenemos la confidencialidad de los nombres de los clientes y compartimos los detalles técnicos. Cada caso se cerró antes de llegar a producción o de sufrir algún abuso.
Comercio electrónico
CRIT
Inyección SQL antes del lanzamiento
SQLi ciega en la búsqueda de productos: se podía extraer toda la tabla de pedidos. Se detectó 4 días antes del lanzamiento y se migró a un ORM.
SaaS
CRIT
Omisión de autenticación
El JWT aceptaba “alg:none”: un atacante podía entrar en cualquier inquilino (tenant) como administrador.
Banca móvil
CRIT
Almacenamiento inseguro de tokens
El token de sesión se escribía en texto plano en NSUserDefaults y podía leerse en un dispositivo con root. Se migró a Keychain + biometría.
API B2B
HIGH
IDOR: datos de otra empresa
/api/invoices/{id} no comprobaba la propiedad; los ID secuenciales dejaban expuestas las facturas de empresas competidoras.
Portal de salud
HIGH
Enlace de restablecimiento no aleatorio
El token de restablecimiento de contraseña se generaba a partir de epoch + user_id; por fuerza bruta se podía tomar el control de cualquier cuenta.
AWS corporativo
MED
Bucket S3 público
Los logs de CI/CD se escribían en un bucket público y contenían credenciales temporales de base de datos.
Preguntas frecuentes
Las preguntas más habituales sobre pentest.
Un escáner automático (Nessus, ZAP, Acunetix, etc.) se basa en firmas: busca patrones conocidos, la mayoría de sus resultados son falsos positivos y nunca detecta los fallos de lógica de negocio. Un pentester, en cambio, formula hipótesis específicas para su aplicación, encadena tres puntos débiles hasta convertirlos en un ataque crítico, intenta la escalada de privilegios a mano y demuestra cada hallazgo con pasos reproducibles. En la práctica, la mitad de los “10 críticos” de un escáner son falsas alarmas; cada hallazgo de un informe de pentest se ha explotado y demostrado, de modo que el equipo de desarrollo puede saltarse el debate y pasar directamente a la corrección.
Los tres son válidos y miden cosas distintas. La caja negra (black-box) parte de un atacante que no sabe nada de usted: es lo más parecido a un atacante real, pero resulta costosa en tiempo y alcance. La caja blanca (white-box) da al evaluador el código fuente, los diagramas de arquitectura y las cuentas de administrador: es la prueba más profunda por hora y la más adecuada antes de producción. La caja gris (gray-box) queda en medio: una cuenta de usuario normal y una visión general de la arquitectura; para la mayoría de los pentests empresariales es el compromiso más práctico, porque cubre los modelos de atacante externo e interno en un mismo proyecto. La elección correcta depende del objetivo y la decidimos con usted en la primera reunión.
Bien gestionado, no. El documento de reglas de intervención (RoE) detalla los horarios permitidos, los límites de concurrencia, las cuentas de prueba aisladas y las acciones prohibidas (DoS, eliminaciones permanentes, etc.). En la mayoría de los proyectos, las comprobaciones destructivas (por ejemplo, fuerza bruta que activa el bloqueo de cuentas o la subida de payloads) solo se ejecutan en preproducción (staging); en producción recopilamos evidencias de solo lectura. Siempre hay un plan de reversión: instantáneas antes de la prueba y un ingeniero de guardia localizable ante cualquier anomalía. Más de 280 proyectos sin una sola interrupción en producción, porque el oficio exige esa disciplina.
Depende del alcance. Una sola aplicación web suele requerir de 5 a 10 días hábiles; un proyecto de API de tamaño medio, de 7 a 12 días hábiles; una aplicación móvil, de 8 a 14 días hábiles; y un escenario completo de red team, de 4 a 8 semanas. Además, una vez aplicadas las correcciones (normalmente en un plazo de 4 a 8 semanas), la nueva prueba gratuita lleva unos 2 o 3 días hábiles. Tres factores determinan la duración: la amplitud del alcance, el número de roles y permisos que hay que revisar y la accesibilidad del entorno de pruebas. En la primera reunión fijamos el alcance y le indicamos días y precio cerrados; no cambian después.
El informe tiene tres niveles. El primero es un resumen ejecutivo: de 1 a 2 páginas con una tabla de riesgos no técnica, el número de hallazgos y la situación general de seguridad. El segundo son los hallazgos técnicos: descripción de cada uno, componente afectado, pasos de explotación con capturas de pantalla, puntuación CVSS 3.1 y corrección recomendada (con código de ejemplo). El tercero es un plan de acción priorizado: qué corregir primero y qué después, adaptado al ritmo de sus sprints. El informe completo se entrega en Markdown + PDF; tras la nueva prueba se vuelve a emitir con la anotación “remediated”. Nuestros clientes lo presentan directamente en auditorías ISO 27001, SOC 2 y PCI-DSS.
No. La nueva prueba de todos los hallazgos Critical y High del proyecto principal está incluida en el precio del contrato. La única condición es que las correcciones se desplieguen en un plazo de 4 a 8 semanas (ampliable a 12 de común acuerdo) y que haya un entorno disponible para las pruebas. Los hallazgos cerrados se marcan como “remediated”; los que siguen abiertos se notifican de nuevo. Esta es nuestra garantía de calidad: no entregamos un informe y desaparecemos, nos quedamos hasta el cierre. La nueva prueba de los hallazgos Medium y Low es opcional y cuesta una pequeña parte del proyecto principal.
Usamos los tres en un mismo proyecto. Para aplicaciones web, OWASP Top 10 (2021) y OWASP ASVS Level 2; para API, OWASP API Top 10; para móvil, OWASP MASVS. La metodología sigue las fases de PTES (Penetration Testing Execution Standard): preparación previa, recopilación de información, modelado de amenazas, análisis de vulnerabilidades, explotación, postexplotación e informe. Para la puntuación de riesgo usamos CVSS 3.1, y el formato del informe se apoya en NIST SP 800-115. Está alineado con ISO 27001, SOC 2 y PCI-DSS, es decir, el informe tiene la estructura que espera su auditor. Aplicar los tres juntos garantiza tanto la profundidad técnica como la preparación para auditorías.
Sí, en cada proyecto el ingeniero líder cuenta con al menos una certificación reconocida en el sector: OSCP (Offensive Security Certified Professional), OSWE (Offensive Security Web Expert), CEH (Certified Ethical Hacker), CRTP (Certified Red Team Professional) o GPEN (GIAC Penetration Tester). Para móvil preferimos además eMAPT, y para nube, AWS Security Specialty o AZ-500. Las certificaciones no son obligatorias, pero cuando el cliente las solicita (especialmente en licitaciones financieras y del sector público) podemos adjuntarlas a la documentación de compra. Más importante es que el equipo obtenga hallazgos reproducibles; las certificaciones son un indicio de ello, no una garantía, y nosotros ofrecemos ambas cosas.
Encontremos sus vulnerabilidades
antes que los atacantes.
En una reunión gratuita de 30 min definimos juntos el plan del pentest: sistemas objetivo, RoE, calendario y precio cerrado.