Practicar pentesting legalmente: laboratorios y normas

La línea entre un pentester y un atacante es el permiso. Las habilidades son las mismas; lo que convierte una cosa en una profesión y la otra en un delito es una autorización por escrito que dice exactamente qué puedes probar, cuándo y cómo. Esta guía cubre dónde practicar legalmente, cómo funcionan las normas de los proveedores de nube a octubre de 2026, qué necesita un documento de reglas de enfrentamiento y cómo simular phishing y movimiento lateral sin hacer daño a nadie.

Esto es información general, no asesoramiento legal. Las leyes varían según el país; si no tienes claro si algo está autorizado, da por hecho que no lo está y consulta a un abogado.

¿Qué hace que una prueba de penetración sea legal?

La autorización de alguien que tiene derecho a darla. En Estados Unidos, la Computer Fraud and Abuse Act (18 U.S.C. 1030) tipifica como delito acceder a un ordenador sin autorización o excediendo el acceso autorizado; en el Reino Unido, la Computer Misuse Act 1990 hace lo mismo; la mayoría de los países tienen un equivalente. En mayo de 2022, el Departamento de Justicia de EE. UU. indicó a los fiscales que no acusaran según la CFAA la investigación de seguridad de buena fe, pero esa política no vincula a los fiscales estatales ni a las demandas civiles, y «solo estaba probando» no es por sí solo una defensa. Regla práctica: si no lo tienes por escrito, no lo tienes.

Los programas de bug bounty son una forma de permiso por escrito, pero solo para lo que su política declara dentro del alcance y con los métodos que permite. Cualquier cosa fuera del alcance publicado no está autorizada. Lo mismo se aplica cuando un agente de IA maneja las herramientas: PentAGI y otros agentes autónomos de pentesting necesitan exactamente el mismo alcance por escrito que un pentester humano.

¿Dónde puedes practicar pruebas de penetración legalmente?

¿Cuáles son las normas de los proveedores de nube para el pentesting?

Los tres grandes proveedores te permiten probar tus propios recursos sin pedir permiso antes, con límites. A octubre de 2026:

• AWS (política de pruebas de penetración): sin aprobación previa para una lista de servicios que incluye EC2, RDS, Aurora, CloudFront, API Gateway, Lambda, Lightsail, Elastic Beanstalk, ECS y Fargate. Cualquier prueba que incluya comando y control (C2) necesita aprobación previa. Los ejercicios de red, blue o purple team, el phishing simulado, las pruebas de malware y otros eventos simulados necesitan un formulario de Simulated Events enviado al menos dos semanas antes. Están prohibidos la denegación de servicio (incluida la DoS simulada), la inundación, el recorrido de zonas DNS mediante Route 53 y la toma de control de buckets S3 o de subdominios.
• Microsoft Azure (Microsoft Cloud Unified Penetration Testing Rules of Engagement): no se exige notificación para Azure, pero debes seguir las Rules of Engagement: probar solo los recursos de tu propio tenant, sin denegación de servicio, sin ataques a otros clientes. El proceso sin notificación se aplica solo a Azure, no a todos los servicios en la nube de Microsoft.
• Google Cloud (Cloud Security FAQ): no tienes que ponerte en contacto con Google para probar tu propia infraestructura de Google Cloud, siempre que sigas la Acceptable Use Policy y los Terms of Service y que tus pruebas solo afecten a tus propios proyectos.

Vuelve a leer la política antes de cada encargo; estas páginas cambian.

¿Qué incluye un documento de reglas de enfrentamiento?

1. Autorización: quién aprobó la prueba, con su autoridad para aprobarla (y el consentimiento de terceros si intervienen proveedores de alojamiento o SaaS).
2. Alcance: rangos de IP, dominios, aplicaciones, cuentas y entornos exactos dentro del alcance.
3. Fuera del alcance: sistemas, técnicas (por ejemplo, denegación de servicio o ingeniería social a personas concretas) y datos que no debes tocar.
4. Metodología: caja negra, gris o blanca; métodos de referencia como NIST SP 800-115 o PTES.
5. Calendario: ventanas de prueba y periodos de bloqueo.
6. Tratamiento de datos: qué hacer si encuentras datos personales o sensibles; cómo se guardan y se destruyen las evidencias.
7. Comunicación: contactos de emergencia en ambos lados, un procedimiento para detener la prueba y cuándo informar de inmediato de un hallazgo crítico.
8. Informe: formato, calificación de gravedad y condiciones de la nueva prueba.

El Penetration Test Scoping Generator lo construye como un alcance y una RFP descargables a partir de un breve cuestionario.

¿Cómo se simulan el phishing y el movimiento lateral de forma segura?

1. Ponlo por escrito. Unas reglas de enfrentamiento firmadas que nombren explícitamente el phishing y el movimiento lateral, los grupos objetivo y a cualquiera que quede excluido.
2. Avisa a las personas adecuadas. Acuerda con el SOC o con TI si la prueba se anuncia, y establece una vía de escalado para que un incidente real nunca se confunda con el ejercicio.
3. Mantén inofensivas las cargas. Una página de destino que explique lo que la persona no vio, sin captura real de credenciales, y archivos de prueba como EICAR en lugar de malware real.
4. Aísla el movimiento lateral. Practica en un dominio de laboratorio como GOAD, o usa pruebas asociadas a ATT&CK (Atomic Red Team, Caldera) en un entorno de pruebas. En una red de producción, solo dentro del alcance firmado.
5. Mide lo que importa. La tasa de notificación y el tiempo hasta la notificación importan más que la tasa de clics; el tiempo de detección y respuesta importa más que si conseguiste ser administrador del dominio.
6. Limpia. Elimina cuentas, herramientas, tareas programadas y archivos de prueba, y documenta que lo hiciste.

PlayCISO no envía correos de phishing; para el lado defensivo, el juego Pick the Phish y el Kerberos Attack Lab (señales de detección de Kerberoasting, golden tickets y pass-the-ticket) son buenos complementos.

Lista de comprobación: antes de cualquier práctica o prueba

• ¿Es mío este sistema, o tengo permiso por escrito de quien lo es?
• ¿Está el alcance exacto por escrito, incluido lo que queda fuera?
• ¿He leído este mes la política de pruebas del proveedor de alojamiento o de nube?
• ¿Está mi laboratorio aislado de producción y de internet?
• ¿Son inofensivas mis cargas y está acordado el tratamiento de datos?
• ¿Sé a quién llamar, y cómo parar, si algo se rompe?

Preguntas frecuentes

¿Es legal practicar pruebas de penetración?

Sí, en sistemas de tu propiedad o para los que tengas permiso explícito por escrito. Practicar en laboratorios deliberadamente vulnerables (Hack The Box, TryHackMe, PortSwigger Web Security Academy, OffSec Proving Grounds) o en máquinas virtuales que ejecutas tú mismo es legal. Probar cualquier otra cosa sin autorización puede ser delito, por ejemplo según la Computer Fraud and Abuse Act de EE. UU. o la Computer Misuse Act 1990 del Reino Unido.

¿Cómo simulo phishing y movimiento lateral de forma segura?

Consigue unas reglas de enfrentamiento por escrito firmadas por alguien con autoridad, avisa al SOC o acuerda un proceso de lista blanca y escalado, y usa cargas inofensivas y una página de destino que enseñe en lugar de capturar credenciales reales. Haz el movimiento lateral en un dominio de laboratorio aislado (por ejemplo, GOAD) o con herramientas asociadas a ATT&CK como Atomic Red Team en un entorno de pruebas. Mide la tasa de notificación y el tiempo hasta la notificación, no solo la tasa de clics.

¿Cómo ejecuto cargas de forma segura en un laboratorio aislado?

Usa una red aislada sin ruta hacia producción ni hacia internet, haz instantáneas de las máquinas virtuales antes de empezar, usa archivos de prueba inofensivos como la cadena de prueba EICAR para comprobar que la detección salta, y no saques nunca muestras ni herramientas del laboratorio. Los laboratorios en la nube van en una cuenta o suscripción separada con una alerta de presupuesto.

¿Necesito permiso para hacer un pentest de mi propia cuenta de AWS, Azure o Google Cloud?

A octubre de 2026, ninguno de los tres exige aprobación previa para probar tus propios recursos, dentro de sus normas. AWS permite probar los servicios de una lista sin aprobación, pero exige aprobación para la actividad de comando y control y un formulario de Simulated Events con al menos dos semanas de antelación para pruebas de red team, phishing o malware; las pruebas de denegación de servicio están prohibidas. Microsoft no exige notificación para Azure, pero debes seguir sus Rules of Engagement. Google no exige que te pongas en contacto con él, siempre que las pruebas se queden dentro de tus propios proyectos y sigan su Acceptable Use Policy.

¿Qué es un documento de reglas de enfrentamiento?

El acuerdo escrito que hace que una prueba sea legal y segura: quién la autorizó, el alcance exacto (rangos de IP, dominios, aplicaciones, cuentas), qué queda fuera del alcance, las técnicas permitidas, las ventanas de prueba, cómo tratar los datos sensibles, los contactos de emergencia y un procedimiento de parada, y cómo se informa de los hallazgos. No empieces nunca sin uno, ni siquiera en una prueba interna.