Pentesting de infraestructura interna y externa

Test de intrusión externo: lo que ve Internet

El test de intrusión externo se coloca donde está el atacante oportunista: en Internet, sin cuenta, sin acceso y sin un plano de tu red. Su objetivo es levantar el mapa de lo que expones —incluido lo que ya no recordabas que exponías— y comprobar después cuáles de esas puertas se abren de verdad.

Partimos de tus nombres de dominio y de tus rangos de direcciones IP para reconstruir la superficie de exposición: subdominios, certificados, registros DNS, activos alojados en terceros. Esta fase casi siempre saca a la luz cosas que no están en ningún inventario: una interfaz de administración publicada «un momento, para una incidencia», un entorno de preproducción que se quedó en línea, un servidor de correo antiguo que nunca se dio de baja.

Lo que revisamos a continuación:

• Superficie expuesta y servicios publicados: servidores web, API, portales de cliente, recursos compartidos, interfaces de administración accesibles y protocolos de acceso remoto.
• Accesos remotos y VPN: concentradores VPN, pasarelas de acceso, escritorio remoto, solidez del segundo factor y existencia de caminos que lo esquivan.
• Correo corporativo: configuración de SPF, DKIM y DMARC, relés abiertos, portales de webmail y cuentas expuestas a pulverización de contraseñas (password spraying).
• Credenciales filtradas: búsqueda en fuentes abiertas de credenciales de tu plantilla aparecidas en brechas anteriores, claves de API en repositorios públicos y documentos internos indexados. Trabajamos sobre la superficie de exposición de la organización, dentro del alcance contratado y sin investigar a personas concretas.
• Perímetro y filtrado: cortafuegos, balanceadores, reglas demasiado permisivas y servicios de administración alcanzables desde cualquier dirección.

Un externo sobre un perímetro acotado suele caber en 3 a 5 jornadas. Es el punto de partida que recomendamos cuando tu mapa de exposición no está al día, porque por ahí entran los ataques no dirigidos. Si tus aplicaciones web son la mayor parte de esa superficie, el pentesting de aplicaciones web profundiza en lo que el test de infraestructura solo sobrevuela.

Test de intrusión interno: partimos de un compromiso ya ocurrido

El test de intrusión interno responde a otra pregunta: ¿y después qué? Damos por hecho que alguien ya tiene un pie dentro —un puesto comprometido por un correo fraudulento, un proveedor cuyos accesos se han desviado, un portátil robado—. Es el escenario que el mercado nombra en inglés, assumed breach: en vez de gastar medio presupuesto en demostrar que se puede entrar, lo damos por supuesto y medimos lo que cuesta.

En la práctica, nos facilitas un punto de entrada —un puesto de trabajo estándar, una máquina virtual en la VLAN de usuarios o una cuenta de dominio sin privilegios— y medimos el camino que va de ahí a tus activos más sensibles.

Active Directory

El directorio suele ser el centro de gravedad del trabajo, porque es el centro de gravedad de tu sistema de información. Buscamos las cadenas de compromiso clásicas y las que ha ido creando tu propia historia: cuentas de servicio con SPN y contraseña débil (Kerberoasting), cuentas con la preautenticación de Kerberos desactivada (AS-REP roasting), delegación restringida o no restringida mal controlada, ACL que permiten a un usuario corriente restablecer la contraseña de una cuenta privilegiada, secretos en claro en scripts de inicio de sesión y en objetos de directiva de grupo, retransmisión NTLM, y cuentas de administrador local con la misma contraseña en todo el parque.

Segmentación de red

Después comprobamos si tu compartimentación aguanta: ¿llega un puesto de ofimática a los servidores de copias de seguridad, al hipervisor, a los autómatas de planta, a la red de cámaras? Cada salto que se consigue se documenta con el flujo que lo permitió, para que la corrección sea una regla de filtrado concreta y no una reforma vaga.

Escalada de privilegios y movimiento lateral

Sobre los equipos y servidores alcanzados probamos los caminos de escalada local: servicios con permisos incorrectos, tareas programadas modificables, parches ausentes, secretos residentes en memoria y credenciales reutilizables. Luego encadenamos saltos de una máquina a otra. El objetivo no cambia: determinar si se llega a la administración del dominio, en cuántos pasos, y cuál de esos pasos es el más barato de eliminar.

Un interno que cubra el directorio y la segmentación suele ocupar entre 5 y 10 jornadas. En un entorno alojado en un proveedor de nube las mismas preguntas se plantean con otros mecanismos: lo tratamos en pentesting de cloud. Y si lo que quieres medir no son los caminos técnicos sino tu capacidad de detección y respuesta, eso es un ejercicio de Red Team.

Enfoques: caja negra, caja gris y caja blanca

Antes de hablar de herramientas hay que decidir cuánta información recibimos de tu parte. Esa decisión cambia el desarrollo, la duración y lo que acabas aprendiendo. Ninguno de los tres enfoques es mejor que los otros: responden a preguntas distintas.

Caja negra (black box)

Solo disponemos de lo que puede conseguir alguien desde fuera: un nombre de empresa, unos dominios y, como mucho, un rango de direcciones IP. Reproduce con fidelidad un ataque no dirigido y pone a prueba tu exposición tal y como está, incluidos los activos que habías perdido de vista. Su límite es presupuestario: parte del tiempo se va en reconocimiento, y un activo que no lleguemos a descubrir no se prueba.

Caja gris (grey box)

Nos das un nivel de acceso intermedio: una cuenta de dominio sin privilegios, acceso a la VLAN de usuarios, la lista de rangos afectados. Es el enfoque que recomendamos para la gran mayoría de los test de intrusión internos y es el del escenario assumed breach. El presupuesto se va en explotación y no en descubrimiento, y la cobertura del alcance queda garantizada.

Caja blanca (white box)

Trabajamos con todo el material: esquemas de arquitectura, reglas de filtrado, configuraciones y acceso de lectura a las consolas de administración. Es el enfoque que cubre más terreno por jornada gastada; encaja antes de una puesta en producción, después de rehacer el directorio, o cuando quien audita espera una cobertura exhaustiva y trazable.

En la práctica, casi todos los encargos son mixtos: caja negra fuera, caja gris dentro. La decisión se toma al cerrar el alcance, según tu presupuesto y según la pregunta que quieras responder.

Qué obliga realmente en España

Conviene separar lo que está en vigor de lo que se anuncia. En materia de pentesting de infraestructura, el mapa español a fecha de hoy es este.

NIS2 todavía no es ley española

La Directiva (UE) 2022/2555, conocida como NIS2, debía estar transpuesta el 17 de octubre de 2024. España no lo ha hecho. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad recibió una primera lectura en el Consejo de Ministros el 14 de enero de 2025 y no ha llegado a las Cortes Generales. El 9 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea precisamente por esa falta de transposición, en el procedimiento de infracción INFR(2024)0270.

Lo que sí obliga hoy a operadores de servicios esenciales y a proveedores de servicios digitales es el Real Decreto-ley 12/2018 y su reglamento de desarrollo, el Real Decreto 43/2021, que siguen exigiendo análisis de riesgos, medidas técnicas y auditorías periódicas. Las advertencias sobre sanciones de NIS2 en España se refieren, por tanto, a una norma que todavía no está aprobada. Lo desarrollamos en NIS2 en España: qué obliga hoy y qué no.

El Reglamento de Ejecución (UE) 2024/2690 sí se aplica, sin transposición

Hay una pieza de NIS2 que no depende de que España legisle. El Reglamento de Ejecución (UE) 2024/2690 de la Comisión, de 17 de octubre de 2024, es directamente aplicable y fija las medidas técnicas y metodológicas para proveedores de servicios DNS, registros de nombres de dominio de primer nivel, servicios de computación en nube, centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados y de servicios de seguridad gestionados, mercados en línea, motores de búsqueda y plataformas de redes sociales.

Su anexo dedica el punto 6.5, «Pruebas de seguridad», a lo que aquí nos ocupa. Exige una política de pruebas documentada, un alcance y una frecuencia decididos en función del riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. Si tu entidad está en esa lista, el informe de un test de intrusión de infraestructura es exactamente la evidencia que ese punto pide, y el documento de alcance es la política de pruebas que lo acompaña.

ENS: Real Decreto 311/2022

El Esquema Nacional de Seguridad obliga al sector público y a quien le presta servicios. El art. 31 exige una auditoría regular ordinaria al menos cada dos años, y el art. 38 separa la autoevaluación propia de la categoría BÁSICA de la certificación que necesitan las categorías MEDIA y ALTA.

En el Anexo II, el refuerzo R6 de la medida [op.mon.3] incluye el subrequisito [op.mon.3.r6.3] «Pruebas de penetración» para la categoría ALTA. Y desde la categoría BÁSICA, la medida op.nub.1.2 a) pide una «Auditoría de pruebas de penetración (pentesting)» cuando el servicio en la nube que utilizas lo presta un tercero que no es conforme con el ENS. Conviene no confundirlo con [op.mon.1] Detección de intrusión, que es otra medida y se refiere a sistemas IDS e IPS, no a este trabajo.

Nosotros aportamos la prueba técnica y el informe. La conformidad con el ENS la declara o la certifica quien puede hacerlo: Haxoris no es una entidad de certificación acreditada por ENAC, no expide certificados del ENS ni el Distintivo de Conformidad, y nuestro informe se usa como evidencia ante la entidad que sí los expide. Quién puede firmar cada cosa lo explicamos en quién puede auditar el ENS y en qué exige realmente el ENS sobre pentesting.

RGPD y DORA

El art. 32.1.d) del RGPD exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas» aplicadas para garantizar la seguridad del tratamiento. Un test de intrusión periódico sobre la infraestructura que aloja datos personales es una de las formas habituales de acreditar ese proceso, y el informe fechado es lo que queda como prueba.

En el sector financiero, DORA (Reglamento (UE) 2022/2554) se aplica desde el 17 de enero de 2025 y exige un programa de pruebas de resiliencia operativa digital. Su art. 26 añade, para las entidades que designe la autoridad competente, pruebas guiadas por amenazas (TLPT) al menos cada tres años. Ese es un ejercicio distinto, con requisitos propios de proveedor en el art. 27, y no lo prestamos.

Si lo que necesitas es encajar el trabajo en un programa de cumplimiento concreto, la página de pentesting para NIS2 y la de pentesting para ISO 27001 explican cómo se documenta cada una.

Última verificación de este apartado: 12 de septiembre de 2026.

Tratamiento de datos y soberanía

Un pentest de infraestructura produce material sensible: mapas de red, volcados de configuración, credenciales obtenidas durante el ejercicio, capturas que pueden contener datos personales. Dónde vive ese material y bajo qué ley se responde antes de firmar, no después de la primera incidencia.

Haxoris es una empresa establecida en la Unión Europea. Eso tiene consecuencias concretas y comprobables en el contrato:

• El RGPD se aplica directamente. No hay que construir una base jurídica alternativa ni negociar salvaguardas añadidas: la relación se rige por el Reglamento (UE) 2016/679 y por la LOPDGDD, y la autoridad de control competente es europea.
• No hay transferencia internacional. El tratamiento se mantiene dentro del Espacio Económico Europeo, así que no entra en juego el capítulo V del RGPD: no necesitas cláusulas contractuales tipo, ni una decisión de adecuación, ni una evaluación de impacto de la transferencia para justificar el encargo ante tu delegado de protección de datos.
• No hay jurisdicción estadounidense sobre el material. Ninguna de las entidades que interviene está sujeta a la CLOUD Act ni a requerimientos de acceso de autoridades de terceros países.
• El encargo de tratamiento está por escrito. Firmamos el contrato del art. 28 del RGPD con los subencargados nombrados, las medidas de seguridad descritas y el plazo de conservación y destrucción de las evidencias fijado de antemano.
• Las evidencias se destruyen. Lo recogido durante el ejercicio se guarda cifrado durante el plazo pactado y se elimina después, dejando constancia escrita de la eliminación.

Nuestras oficinas están en Bratislava y en Praga. Los trabajos para organizaciones en España se ejecutan, se documentan y se presentan en español, y el contrato se firma con una empresa de la Unión Europea. Si tu criterio de compra exige que el proveedor esté establecido en España, dilo en la primera llamada: no lo estamos, y es mejor saberlo el primer día que el de la firma. El tema completo, con las excepciones reales donde esto sí importa, está en contratar una empresa de pentesting no española.

Qué no hacemos

Casi todo lo que se lee en este mercado son listas de lo que sí se hace. Estas son las cuatro cosas que nos van a pedir y que no vamos a aceptar, porque decirlo aquí es lo que hace creíble el resto de la página.

• No certificamos. No expedimos certificados del ENS, ni el Distintivo de Conformidad, ni certificados de ISO/IEC 27001. Esa función corresponde a entidades de certificación acreditadas, y Haxoris no lo es. Lo que entregamos es un informe técnico que sirve de evidencia ante quien sí certifica.
• No hacemos TLPT. Las pruebas guiadas por amenazas del art. 26 del Reglamento (UE) 2022/2554 exigen proveedores que cumplan los requisitos de su art. 27. Un ejercicio de Red Team nuestro puede servir de preparación previa, pero no lo sustituye ni lo realizamos.
• No trabajamos con información clasificada. El acceso a materia clasificada exige una habilitación de seguridad tramitada por la Oficina Nacional de Seguridad. No la tenemos y no nos presentamos a las licitaciones que la piden.
• No somos una empresa de seguridad privada. Prestamos servicios de seguridad informática. Esta actividad no figura entre las reservadas del art. 5.1 de la Ley 5/2014 y no requiere autorización del Ministerio del Interior; tampoco prestamos ninguno de los servicios que esa ley reserva ni investigamos a personas concretas.

Hay además dos cosas que sí hacemos, pero no dentro de este encargo. Medir la reacción de tu plantilla ante un correo fraudulento o una llamada es un test de ingeniería social, y medir tu capacidad de detección y respuesta frente a un adversario con objetivos es un ejercicio de Red Team. Cada uno tiene su alcance y su autorización, y mezclarlos con un pentest de infraestructura empeora los dos resultados.

Las pruebas destructivas tampoco entran por defecto: denegación de servicio, fuerza bruta masiva y cualquier acción capaz de tumbar un sistema quedan fuera salvo petición escrita y ventana acordada.