Análisis de vulnerabilidades
Perímetro, red interna, aplicaciones web y nube revisados de forma continua frente a CVE — valorados según su contexto …
VerServicios ofensivos
Pruebas de penetración
Un análisis de vulnerabilidades le dice qué puertas están sin cerrar. Una prueba de penetración le dice hasta dónde llega quien las cruza, y qué podría llevarse por el camino. Ese ataque lo ejecutamos nosotros, por encargo suyo y dentro de sus límites, antes de que lo haga alguien sin ninguna de las dos cosas.
01
Qué es
La diferencia con un análisis de vulnerabilidades
Ambos aparecen a menudo uno junto al otro en las ofertas, como si fueran grados de lo mismo. No lo son. Un escáner recorre una lista de debilidades conocidas y comunica cuáles se aplican. Eso es valioso, rápido y barato, y se detiene justo donde empiezan los ataques interesantes.
Porque la mayoría de los incidentes graves no vienen de un solo hueco, sino de una cadena: un sistema de pruebas desactualizado que ya nadie vigila; una cuenta de servicio con más permisos de los que necesita; un segmento de red más abierto de lo previsto. Cada eslabón por separado parecería inofensivo. Solo juntos forman un camino desde fuera hasta la base de datos de clientes.
Ningún procedimiento automatizado encuentra esas cadenas. Surgen de entender su organización, sus procesos y qué merece la pena llevarse. Empleamos las mismas herramientas y las mismas técnicas que un atacante; la única diferencia es que al final escribimos un informe en lugar de desaparecer.
El proceso
Siete fases, como en un ataque real
Trabajamos según metodologías consolidadas: OSSTMM, PTES y, para aplicaciones web, la guía de pruebas de OWASP. La secuencia es deliberadamente la que seguiría un atacante; solo cambia el final.
- 3–5 días
- para una sola aplicación web
- 1–2 semanas
- para una infraestructura de tamaño medio
- 3 días
- para el análisis y el informe
- 1 día
- para el retest tras la corrección
Tras la corrección volvemos a comprobar los hallazgos. Un informe que acaba en una carpeta no ha cambiado nada; solo un retest superado cierra el asunto.
- 01
Reconocimiento
reunimos lo que puede encontrarse públicamente sobre su organización —dominios, rangos de direcciones, nombres en redes profesionales, subdominios huérfanos—. El primer punto de apoyo aparece a menudo ya aquí.
- 02
Enumeración
qué sistemas responden, qué servicios corren y en qué versiones. Comparar eso con lo que usted espera es con frecuencia el primer hallazgo.
- 03
Acceso
el intento de entrar de verdad. Por un hueco, con credenciales válidas procedentes de una filtración o a través de una persona.
- 04
Escalada de privilegios
del primer pie en la puerta hasta administrador. Esta fase decide si un incidente resulta molesto o existencial.
- 05
Tiempo de permanencia
¿cuánto seguiría el atacante sin ser detectado? Esa es la verdadera prueba de su monitorización, no la cuestión de si la intrusión sale bien.
- 06
Rastros
comprobamos qué registró de todo esto su sistema de logs. Con frecuencia menos de lo esperado.
- 07
Informe
hallazgos ordenados por gravedad, cada uno con su evidencia, su impacto y una contramedida concreta. Además, un resumen legible sin formación informática.
Pensar como un atacante, informar como un perito.
02
Las variantes
Qué alcance necesita su prueba
01
Dos preguntas determinan el esfuerzo y el valor: ¿cuánto sabemos de antemano y desde dónde atacamos? La respuesta correcta depende de lo que quiera averiguar, no de lo que suene más exhaustivo.
02
Caja negra
Empezamos con lo que cualquiera puede encontrar en internet. Es la simulación más honesta de un ataque externo y muestra hasta dónde llega un desconocido sin conocimiento previo. El precio: una parte considerable del tiempo se va en el reconocimiento que un atacante también invertiría, salvo que él no tiene un presupuesto que se acabe.
03
Caja blanca
Usted nos entrega documentación de arquitectura, accesos y, donde sea útil, el código fuente. Con el mismo tiempo se encuentra bastante más. Esta variante es la más exhaustiva y la elección cuando se exigen evidencias, pero no responde a lo difícil que sería entrar desde fuera.
04
Caja gris
El compromiso habitual y, en la mayoría de los casos, nuestra recomendación: información previa limitada, por ejemplo una cuenta de usuario sin permisos especiales. Eso comprueba qué puede lograr un atacante que ya tiene un pie dentro, que es el punto de partida real más frecuente.
05
Desde fuera o desde dentro
La prueba externa examina lo que es accesible desde fuera: cortafuegos, servidores web, accesos VPN, servicios en la nube. La interna arranca donde queda un atacante tras el primer paso con éxito, o donde está de todos modos un empleado descontento. Comprobar solo el exterior no le dice nada sobre la segunda mitad del daño.
Los hallazgos
Lo que encontramos casi siempre
Tras muchas pruebas los patrones se repiten. No es una mala noticia: significa que puede lograrse mucho con un esfuerzo asumible antes de que entren en juego los casos difíciles.
01
Sistemas sin parchear, normalmente no los productivos sino los olvidados: el servidor de pruebas de hace dos años que sigue colgado de la red.
02
Credenciales que pueden hacer demasiado. Cuentas de servicio con permisos de administrador, porque así se configuraba más rápido.
03
Configuraciones erróneas en sistemas que en sí mismos están actualizados y son seguros, solo que mal montados.
04
Personas que no reconocen como ataque un mensaje bien hecho. Sin reproche, pero es el motivo de que la formación en concienciación esté justo al lado.
03
La base
Quién prueba, y bajo qué condiciones
Una prueba de penetración es un ataque autorizado contra sistemas ajenos. Sin una base jurídica limpia es un delito, y la mejor de las intenciones no cambia eso. Antes del primer paquete hay, por tanto, siempre un encargo por escrito que fija el alcance, el plazo, las técnicas permitidas y los contactos de emergencia.
Cuando intervienen sistemas que no son suyos —alojados en un proveedor, en la nube de un tercero, operados por un socio de servicios— obtenemos su consentimiento antes de tocarlos. Eso cuesta tiempo de preparación y no es negociable.
Nuestros pentesters tienen las certificaciones pertinentes —OSCP, GPEN, CEH—, pero eso es la entrada, no la cualificación. Lo que cuenta es la experiencia de qué cadena es probable en su sector y la discreción para manejar lo que uno llega a ver por el camino.
04
El ritmo
Una prueba es una foto fija
El resultado vale para el estado del día de la prueba. Cada nueva aplicación, cada migración, cada interfaz que se abre cambia la situación. Una prueba anual es la base razonable; más importante es una adicional después de cada cambio grande, cuando de verdad ha aparecido algo nuevo.
Si quiere vigilar la situación entre una y otra, combine la prueba con una monitorización continua. Lo que la prueba descubre una vez, Strider lo mantiene a la vista en la operación, y el estado de la corrección aterriza en Sightadel.
05
Para terminar
Solo quien conoce sus debilidades puede cerrarlas
El valor de una prueba de penetración no está en el informe. Está en lo que ocurre después: en los hallazgos que se han trabajado y vuelto a comprobar, y en la certeza de que los que quedan se aceptan de forma consciente en lugar de pasar inadvertidos.
Hable con nosotros sobre el alcance y el diseño. La primera conversación no cuesta nada y por sí sola suele dar ya una primera valoración aprovechable.
FAQ
Preguntas frecuentes
¿Puede una prueba de penetración dañar o tumbar nuestros sistemas?
El riesgo no puede reducirse a cero, pero sí acotarse bien. Las técnicas con riesgo para la disponibilidad —pruebas de carga o la explotación de determinados errores de memoria— se aprueban o se excluyen explícitamente de antemano. En los sistemas críticos preferimos probar sobre una copia o dentro de una ventana acordada. Y durante toda la prueba hay un número al que llamar para que paremos de inmediato.
¿Cuánto dura una prueba?
Para una sola aplicación web, normalmente de tres a cinco días; para una infraestructura de tamaño medio, de una a dos semanas. Añada unos tres días para el informe. El retest tras la corrección suele llevar un día.
¿Qué pasa con los datos que ven por el camino?
Accedemos solo hasta donde hace falta para la evidencia: un extracto de una tabla, no todo su contenido. Lo que vemos es confidencial, se guarda cifrado y se borra tras un plazo acordado. Los detalles están en el contrato, no en una declaración de intenciones.
¿Conviene avisar de antemano a nuestro equipo de informática y al SOC?
Depende del objetivo. Si lo saben, está probando la tecnología. Si no lo saben, está probando además la detección y la respuesta, lo cual es más valioso, pero exige que al menos una persona de su lado esté informada y pueda confirmar la prueba en caso de duda.
¿Basta una prueba de penetración para ISO 27001 o NIS2?
Es un bloque, no una evidencia por sí sola. Ambas exigen pruebas técnicas periódicas, y una prueba con corrección documentada cubre ese punto. No cubre el resto de los requisitos: para eso está la implantación de un SGSI.
Servicios ofensivos
Más servicios de esta área
Contacto
La reputación tarda años. Destruirla, segundos.
Hable con nosotros antes de que lo haga otro. La primera conversación es gratuita y respondemos el mismo día laborable.