Pentesting de infraestructura interna y externa: guía técnica para empresas

Un pentesting de infraestructura es una auditoría ofensiva sobre la red, los sistemas, las identidades y los servicios de tu organización. La parte externa simula a un atacante que sólo conoce el dominio público y empieza enumerando lo que hay expuesto a Internet. La parte interna parte de un escenario distinto: un atacante ya está dentro (un endpoint comprometido por phishing, un visitante en la wifi corporativa, un empleado descontento) y mide hasta dónde llega antes de ser detectado. Las dos miden cosas diferentes y, en organizaciones medianas, las dos hacen falta al menos una vez al año.

Esta guía cubre qué se audita exactamente en un pentesting de infraestructura externa y en uno interno, por qué Active Directory es la columna vertebral del trabajo interno, los hallazgos típicos que aparecen en el 80% de los proyectos, la metodología que aplica un equipo serio y cómo encaja en NIS2, DORA, ENS, ISO 27001 y PCI DSS.

Qué es un pentesting de infraestructura

Un pentesting de infraestructura es un ejercicio ofensivo autorizado y acotado sobre los sistemas, redes e identidades de la organización: servidores físicos y virtuales, dispositivos de red (firewalls, switches, routers), Active Directory o Entra ID, VPNs, segmentaciones, servicios expuestos y los flujos legítimos entre todo eso.

A diferencia del pentesting web, que se centra en una aplicación HTTP y su lógica, el pentesting de infraestructura mira el sistema operativo y la identidad. Lo que se audita:

• Servicios expuestos y sus configuraciones (SSH, RDP, SMB, LDAP, Kerberos, bases de datos, paneles administrativos).
• Identidades: cuentas de usuario, cuentas de servicio, permisos, grupos, GPOs, ACLs, delegaciones.
• Segmentación de red entre VLANs, entre entornos (producción, preproducción, oficina), entre DMZ y backend.
• Parches y endurecimiento de sistemas operativos, hipervisores y dispositivos de red.
• Telemetría defensiva: si EDR, SIEM y honeypots detectan los movimientos del equipo ofensivo.

El pentesting de infraestructura es el escenario más cercano a un incidente real, porque la mayoría de ransomware y APT atacan precisamente identidad y red, no aplicaciones web aisladas.

Por qué hacer pentesting de infraestructura

Tres razones operativas que cualquier equipo de seguridad ya tiene asumidas:

1. La mayoría de incidentes se mueven por infraestructura, no por web. El acceso inicial puede venir de un correo o de un servicio expuesto, pero a partir de ahí el atacante hace movimiento lateral en Active Directory, escala privilegios y llega a controlador de dominio. La auditoría web no toca nada de eso.
2. Active Directory acumula deuda silenciosa. GPOs creadas hace 10 años, cuentas de servicio con privilegios excesivos, delegaciones Kerberos olvidadas, ACLs heredadas mal pensadas. Sin auditoría externa periódica, esa deuda no se ve hasta que un atacante la explota.
3. NIS2, DORA, ENS, PCI DSS e ISO 27001 cubren explícitamente infraestructura. NIS2 artículo 21 exige pruebas de eficacia de medidas técnicas. PCI DSS req. 11.4 obliga a pentest interno y externo anual. El ENS (Real Decreto 311/2022) lo pide en el Marco Operacional para sistemas de categoría media y alta.

Bien hecho, un pentesting de infraestructura entrega:

• Inventario real de servicios expuestos y de la red interna desde la perspectiva del atacante (a menudo con más detalle que el inventario CMDB del cliente).
• Cadenas de ataque reproducibles: del primer acceso al controlador de dominio, paso a paso.
• Evaluación de la segmentación real, no la del diagrama Visio.
• Recomendaciones priorizadas por blast radius y esfuerzo, no por severidad CVSS aislada.
• Evidencia auditable para auditores NIS2, DORA, ENS, ISO 27001 o QSA PCI DSS.

Pentesting externo: la auditoría del perímetro

El pentesting externo simula a un atacante que sólo dispone del nombre de dominio o del rango público. Lo que cubre:

• Reconocimiento OSINT. Subdominios olvidados (Certificate Transparency, archive.org, GitHub leaks), IPs expuestas, entradas DNS huérfanas, servicios accesibles que el equipo ya no recuerda haber dejado online.
• Enumeración de servicios. Nmap completo, identificación de versiones, fingerprinting. Mapeo del banner, las cabeceras y las respuestas.
• Auditoría de configuraciones expuestas. VPN sin MFA o con CVE conocido (Fortinet, Citrix, SonicWall, Ivanti han sido titulares varias veces), Exchange on-prem sin parches, paneles administrativos públicos, FTP anónimo, SMB en Internet, RDP abierto, Kibana/Elasticsearch sin auth.
• Auditoría de TLS y certificados. Versiones obsoletas, certificados próximos a caducar, ciphers débiles, dominios con certificate transparency sin protección.
• Detección de leaks externos. Credenciales en pastebin, repositorios públicos con secretos, buckets S3 abiertos, Trello/Notion públicos, repositorios GitHub corporativos con tokens.
• Phishing técnico (cuando el alcance lo incluye). Validación de SPF, DKIM, DMARC, capacidad de spoofing del dominio corporativo.

El equipo no entra a nada que no esté autorizado, pero llega hasta el punto de demostrar el acceso (capturas, request crudos, evidencia de versión vulnerable). El cliente decide si autoriza la explotación de cada hallazgo o se conforma con la evidencia.

Pentesting interno: la auditoría desde dentro

El pentesting interno parte del supuesto de que el atacante ya está en la red. El escenario inicial varía:

• Assumed breach: un endpoint corporativo entregado al equipo ofensivo, simulando phishing exitoso.
• Empleado malicioso: con sus credenciales legítimas y su perfil de permisos.
• Visitante en la wifi corporativa: red con acceso restringido a internet pero con cierto alcance interno.
• Conexión VPN de partner: simulando proveedor con acceso limitado.

A partir de ese punto, el equipo intenta hacer lo que un atacante real haría:

• Reconocimiento de la red interna. Escaneo, identificación de servidores críticos, controladores de dominio, jump hosts, NAS, servidores de backup, hipervisores.
• Enumeración de Active Directory. BloodHound, ldapdomaindump, PowerView. Permite ver la red de relaciones, identificar usuarios privilegiados, cuentas de servicio con SPN, máquinas con delegación inseguras, GPOs editables.
• Captura de credenciales. LLMNR/NBT-NS poisoning con Responder, mitm6 contra IPv6, NTLM relay, kerberoasting, ASREProasting. Producen hashes que se intentan crackear offline.
• Movimiento lateral. Pass-the-hash, pass-the-ticket, abuso de SeImpersonate, abuso de PrintNightmare en sistemas sin parche, RCE vía SMB en sistemas legacy.
• Escalada a Domain Admin o equivalente. DCSync, Golden Ticket, abuso de delegación Kerberos, ACL hijacking en grupos privilegiados, PetitPotam contra ADCS mal configurada.
• Persistencia. Backdoors silenciosas: skeleton key, modificación de ACLs, AdminSDHolder, Kerberos delegation.
• Test de detección. Cada acción se documenta para que el cliente verifique después qué detectaron EDR, SIEM y SOC.

External vs internal: cuándo conviene cada uno

Las dos auditorías miden cosas distintas. Decisión razonable:

• Externo: anualmente y tras cualquier cambio significativo del perímetro (nuevo balanceador, despliegue de VPN, exposición de un nuevo servicio). Es la prueba que detecta lo que un atacante ve antes de tener un punto de apoyo.
• Interno: anualmente para empresas con Active Directory grande o con compliance (NIS2, DORA, ENS medio o alto, PCI DSS). Tras incidentes o cambios estructurales (consolidación de dominios, migración a Entra ID, fusión).
• Combinado: cuando el presupuesto lo permite, lo más útil es ejecutar ambos en el mismo proyecto con un equipo que comparta hallazgos cruzados. Lo expuesto en el perímetro a veces explica cómo se entró en una intrusión real.

Para empresas pequeñas o con superficie acotada, un externo anual + interno bienal es una cadencia razonable. Las que están bajo NIS2 esencial, DORA o PCI DSS necesitan ambos cada año.

Active Directory: el corazón del pentesting interno

Más del 80% de los hallazgos críticos en pentesting interno aparecen en Active Directory. Las categorías:

• Kerberoasting. Cuentas de servicio con SPN registrado y password débil. Cualquier usuario del dominio puede pedir el ticket, extraer el hash y crackearlo offline. Defensa: passwords largas (25+ caracteres) y rotadas, gMSA donde se pueda.
• ASREProasting. Cuentas con preautenticación Kerberos deshabilitada (DONT_REQ_PREAUTH). Permite extraer hash sin estar autenticado en el dominio. Defensa: revisar y eliminar el flag salvo casos justificados.
• Delegaciones Kerberos inseguras. Unconstrained delegation (la más peligrosa, permite suplantar cualquier usuario que se conecte) y constrained delegation mal configurada. Defensa: minimizar unconstrained, auditar resource-based constrained delegation y usar Protected Users group para cuentas críticas.
• DCSync abusable. Cuentas o grupos no privilegiados con permisos Replicating Directory Changes que permiten replicar la base completa de credenciales. Defensa: revisar ACLs en el objeto del dominio, sólo Domain Controllers y cuentas justificadas.
• AdminSDHolder y SDProp. Modificaciones en AdminSDHolder se propagan cada hora a las cuentas privilegiadas. Backdoor silenciosa de manual. Defensa: monitorización SACL y revisión periódica.
• GPOs editables por usuarios no privilegiados. ACLs heredadas que permiten editar una GPO aplicada a equipos críticos. Defensa: revisar permisos sobre GPOs y centralizar la administración.
• PetitPotam y NTLM relay a ADCS. Forzar autenticación de un controlador de dominio y relayarla contra el rol de Active Directory Certificate Services para emitir certificados de admin. Defensa: deshabilitar NTLM contra ADCS, EPA habilitado, parchear MS-EFSRPC.
• LAPS ausente o mal aplicado. Misma password local de admin en todos los equipos, robable de uno y reutilizable en todos. Defensa: LAPS desplegado y rotación efectiva.
• Cuentas privilegiadas con sesión activa en estaciones. Domain admin con sesión iniciada en una estación de trabajo (o el portátil del IT). Cualquier compromiso de la estación entrega la cuenta. Defensa: tiering estricto de cuentas, máquinas administrativas dedicadas (PAW).

BloodHound sigue siendo la herramienta de cabecera para visualizar la mayoría de estas relaciones en horas.

Hallazgos típicos en infraestructura externa

Cinco patrones que se repiten:

• VPN o appliance de red sin parchear. CVE crítico publicado y aún sin aplicar. Las campañas masivas suelen explotarlo en horas tras la publicación.
• Servicios olvidados expuestos. Subdominio antiguo apuntando a una IP con un panel administrativo que el equipo ya no recuerda.
• Credenciales en repositorios públicos. GitHub, GitLab, Docker Hub. Tokens de servicio, claves AWS, secretos de API.
• Spoofing del dominio corporativo. SPF laxo, DMARC en p=none, falta de DKIM. Permite enviar correos como @empresa.com a empleados.
• Buckets S3 o equivalentes públicos con datos sensibles. Aparece en la auditoría con OSINT más que con pentest activo, pero es de los hallazgos más frecuentes.

Metodología de un pentesting de infraestructura serio

Lo que aplicamos en Secra y lo que cualquier equipo profesional sigue (alineado a PTES y NIST 800-115):

1. Onboarding técnico. Acuerdo de alcance, IPs, VPN si aplica, ventana de pruebas, contacto técnico para emergencias, autorización por escrito de las pruebas.
2. Reconocimiento pasivo y activo. OSINT, enumeración de servicios, mapeo de la superficie. Sin tocar nada.
3. Identificación de vulnerabilidades. Análisis de configuraciones, comparación de versiones contra bases de datos de CVE, análisis de respuestas anómalas.
4. Explotación controlada. Cada explotación con autorización explícita en el alcance. Documentación de cada paso, captura de evidencia, sin causar denegación de servicio.
5. Post-explotación. Movimiento lateral, escalada, captura de evidencia. En entorno autorizado.
6. Limpieza. Toda persistencia, herramienta y archivo creado por el equipo se elimina al final. Inventario detallado para validación.
7. Reporting. Informe ejecutivo separado del técnico. Cada hallazgo con descripción, prueba de concepto, severidad CVSS justificada y recomendación.
8. Debrief y retest. Reunión técnica con el equipo del cliente, retest de cada hallazgo cuando los fixes están listos.

Pentesting de infraestructura y compliance

• NIS2 (artículo 21). Eficacia probada de medidas técnicas. El pentest de infraestructura cubre la mayoría de controles del Anexo I (gestión de incidentes, seguridad de redes, criptografía, control de acceso).
• DORA (artículos 24-26). Pruebas de resiliencia operativa anual. Para entidades significativas, TLPT bajo TIBER-EU cada tres años, que combina inteligencia, externo e interno bajo escenarios realistas.
• ENS (Real Decreto 311/2022, Marco Operacional MP-OP). Auditoría técnica regular para sistemas de categoría media y alta. Frecuencia mínima bienal en alto, anual en algunos casos.
• PCI DSS v4.0 (req. 11.4). Pentest interno y externo anual + tras cualquier cambio significativo en el entorno CDE. Metodología "industry-accepted" exigida (PTES, OWASP, NIST 800-115).
• ISO 27001:2022 (control 8.29). Pruebas de seguridad documentadas en el SGSI. La auditoría con metodología, hallazgos, fixes y retest cubre el control directamente.

Cómo elegir el alcance correcto

Tres preguntas que ayudan a dimensionar:

• ¿Cuántas IPs externas activas tenemos? El externo escala con superficie expuesta. Una empresa con 5 IPs y un dominio se cubre en 3-5 días; una con 50 IPs y subdominios extensos puede pedir 10-15.
• ¿Cuántos usuarios y máquinas tiene el dominio interno? Un dominio con 200 máquinas y 50 servidores se audita en 5-7 días; uno con varios miles de máquinas y arquitectura forest pide 15-25 días.
• ¿Hay compliance específico? PCI DSS exige enfoque, evidencia y firma de la metodología que algunos proveedores no aplican por defecto.

Más detalle sobre criterios de elección de proveedor en la guía para elegir empresa de pentesting.

Preguntas frecuentes

¿En qué se diferencia el pentesting interno del externo?

El externo simula un atacante que sólo conoce el dominio público; audita lo que hay expuesto a Internet (servicios, configuraciones, fugas, certificados, parches, spoofing). El interno parte de un atacante ya dentro de la red y mide hasta dónde llega: Active Directory, segmentación, escalada, movimiento lateral. Son auditorías complementarias: una empresa madura ejecuta ambas.

¿Cuánto se tarda en un pentesting de infraestructura?

Varía con el tamaño. Un externo sobre una superficie pequeña (10-20 IPs, un dominio): 3-5 días. Un externo grande con varios subdominios y appliances: 7-12 días. Un interno contra Active Directory mediano: 5-10 días. Contra un dominio con miles de máquinas y forest complejo: 15-25 días. Un proyecto combinado externo más interno con AD mediano se suele cerrar en 3 semanas.

¿Hay riesgo de que el pentesting cause denegación de servicio?

Bien planificado, casi nunca. Las pruebas que pueden afectar disponibilidad (fuzzing pesado, ataques contra balanceadores, exploit con probabilidad de tirar el servicio) se acuerdan en alcance previo y se ejecutan en ventana fuera de horas críticas. El equipo profesional documenta cada acción y aborta si detecta inestabilidad. La incidencia real estadísticamente es muy baja en proyectos bien onboardados.

¿Vale con escáner automatizado o hace falta pentest manual?

El escáner (Nessus, OpenVAS, Qualys) es complementario, no sustituto. Detecta CVEs y misconfiguraciones conocidas pero no encuentra encadenamientos ni problemas de Active Directory ni lógica de delegación. El pentest manual es el que descubre la cadena de Kerberoasting + LAPS ausente + delegación insegura que termina en Domain Admin. Auditar con escáner sólo deja fuera el 70% del riesgo real.

¿Necesito pentesting interno si ya tengo EDR y SIEM bien desplegados?

Sí, son cosas distintas. EDR y SIEM detectan al atacante mientras actúa; el pentest revela cómo de fácil es para el atacante moverse y, secundariamente, qué detectan o no esas plataformas. Muchos proyectos descubren que el EDR no cubre todos los servidores o que las reglas SIEM no incluyen kerberoasting. La auditoría es lo que valida la cobertura real.

¿Y si nunca he hecho pentesting interno y tengo miedo de lo que vamos a encontrar?

Es lo habitual la primera vez: aparecen hallazgos críticos en Active Directory que llevaban años. La forma profesional de gestionarlo es acordar de antemano que el primer pentest se trata como diagnóstico baseline, planificar 2-3 ciclos consecutivos para cerrar la deuda y aprovechar el informe para conseguir presupuesto interno. El primer informe siempre es el más cargado; los siguientes muestran progreso medible.

Recursos relacionados

• Qué es un pentesting: el pillar del cluster, con tipos, metodologías y frecuencia recomendada.
• Cómo elegir una empresa de pentesting: preguntas para RFP, comparativa de tipos de proveedor y señales de alerta.
• Pentesting de aplicaciones web: la auditoría hermana en frontend HTTP, complementaria al perímetro de infraestructura.
• Pentesting de APIs REST y GraphQL: la auditoría del backend que se expone vía web y móvil.
• Pentesting cloud AWS, Azure, GCP: la disciplina equivalente cuando la infraestructura está en cloud y el perímetro lo definen IAM y políticas, no IPs.

El pentesting de infraestructura en Secra

En Secra cubrimos pentesting externo e interno con metodología PTES y NIST 800-115, perfiles especializados en Active Directory y enumeración Kerberos, evidencia reproducible, mapeo a NIS2, DORA, ENS, ISO 27001 y PCI DSS según aplique, y retest incluido. Si tu organización tiene Active Directory grande, está bajo compliance o nunca ha hecho un interno, escríbenos a través de contacto o consulta nuestro servicio de auditoría de infraestructura.