Así es un pentesting real
Sin magia, sin cromatismos verdes de película, sin hoodies y sin tipos escribiendo a 300 pulsaciones por minuto. Esto es lo que ocurre de verdad durante una auditoría de seguridad.
Kick-off y definición de reglas de juego
Antes de tocar un solo puerto, definimos contigo las reglas de juego. Esto no es Hollywood — no empezamos a 'hackear' sin permiso y sin saber exactamente qué podemos y qué no podemos hacer.
Firmamos un acuerdo de confidencialidad (NDA). Establecemos el alcance: ¿qué IPs, qué dominios, qué aplicaciones entran en la auditoría? Definimos el horario de pruebas, los contactos de emergencia y los sistemas que no se pueden tocar bajo ningún concepto (bases de datos de producción críticas, sistemas médicos, etc.).
También acordamos el tipo de prueba: caja negra (sin información previa, como un atacante externo real), caja gris (con credenciales de usuario estándar) o caja blanca (acceso completo a código y documentación). La mayoría de nuestros clientes eligen caja gris por ser el equilibrio óptimo entre realismo y eficiencia.
Reconocimiento: mapeando el terreno
Los primeros dos días son de reconocimiento. No lanzamos exploits, no intentamos acceder a nada. Simplemente observamos y mapeamos. ¿Qué servicios hay expuestos a internet? ¿Qué versiones de software? ¿Qué subdominios existen que ni siquiera la empresa sabía que estaban ahí?
Utilizamos herramientas de descubrimiento como Nmap para identificar puertos abiertos y servicios, Amass y Subfinder para enumerar subdominios, Shodan y Censys para buscar información ya pública sobre la infraestructura, y técnicas OSINT para recopilar información sobre empleados, tecnologías utilizadas y posibles fugas de información en GitHub, Pastebin o foros.
Al final del día 2, tenemos un mapa detallado de la superficie de ataque. En muchos casos, este mapa ya revela problemas graves: paneles de administración expuestos a internet sin autenticación, servicios con versiones vulnerable conocidas pero sin parchear, y cuentas de empleados con credenciales filtradas en brechas de datos anteriores.
Explotación: esto es lo que vería un atacante real
Aquí empieza la fase más técnica. Con el mapa de los días 1-2, priorizamos los vectores de ataque más prometedores. Cada hallazgo se explota de forma controlada para confirmar el impacto real. No basta con decir 'tienes un SQL Injection': demostramos qué datos podríamos extraer con él, sin llegar a extraerlos todos.
Las pruebas son manuales. Un escáner automático encuentra la vulnerabilidad obvia; un pentester encuentra la cadena de vulnerabilidades que convierte un fallo menor en acceso completo al sistema. Ejemplo real de una auditoría reciente: un endpoint de API que devolvía demasiada información en los mensajes de error → descubrimos IDs de usuario válidos → uno de ellos tenía MFA desactivado → su contraseña aparecía en una brecha de 2023 → acceso completo al panel de administración. Ningún escáner automático habría trazado esa cadena.
Durante estos días mantenemos comunicación mínima con el cliente. Solo avisamos si encontramos algo que requiera acción inmediata (un sistema crítico completamente expuesto, evidencia de que alguien ya ha entrado antes que nosotros). Estos 'hallazgos críticos' se reportan en caliente, sin esperar al informe final.
Documentación: el informe que realmente sirve
El día 6 se dedica íntegramente a documentar. No hacemos informes de 200 páginas que nadie va a leer. Hacemos dos documentos: uno ejecutivo de 3-4 páginas para dirección, y uno técnico detallado para el equipo de sistemas y desarrollo.
El informe ejecutivo responde a las preguntas que importan al negocio: ¿qué riesgo real tengo? ¿qué probabilidades hay de que esto ocurra? ¿cuánto costaría arreglarlo y en qué orden? El informe técnico incluye cada vulnerabilidad con su CVSS, evidencia en capturas de pantalla, pasos exactos de reproducción, y recomendaciones de remediación específicas — con comandos, snippets de código y referencias.
Cada hallazgo se clasifica en crítico, alto, medio o bajo según su impacto real, no según lo que diga una herramienta. Un XSS en un campo de búsqueda interno puede ser bajo; una inyección SQL en el login que permite bypass de autenticación es crítico. Priorizamos por riesgo de negocio, no por puntuación numérica.
Presentación y siguientes pasos
Entregamos el informe en una reunión de una hora con tu equipo técnico y, si quieres, con dirección. No enviamos el PDF por email y desaparecemos. Explicamos cada hallazgo, resolvemos dudas técnicas, y ayudamos a priorizar el plan de remediación.
Si el hallazgo más crítico cuesta 2 horas de desarrollo arreglarlo y el segundo más crítico cuesta 2 semanas, no los ponemos en orden numérico. Te decimos: 'Empieza por esto hoy mismo. Esto otro puedes planificarlo para el sprint que viene'.
Tres meses después, si quieres, hacemos un retest: volvemos a probar los hallazgos corregidos para verificar que las soluciones funcionan. No cobramos por volver a encontrar lo mismo que ya estaba arreglado. El retest confirma que las correcciones son efectivas y que no se han introducido nuevos problemas.
Durante todo el proceso, la comunicación es directa. No hay gestor de cuenta intermediando. Hablas con el pentester que ha hecho las pruebas. Si algo no se entiende en el informe, te lo explica quien lo escribió. Esto no es una consultora tradicional: somos técnicos hablando con técnicos.
¿Quieres vivir esto en tu empresa?
Todo esto, aplicado a tus sistemas, por personas que han hecho esto cientos de veces. Sin magia, sin sorpresas, sin letra pequeña.