Manifiesto
CyberShellGame.net es un simulador de aprendizaje. No es un “campo libre”: es un laboratorio con límites técnicos y éticos. El objetivo no es “hacer daño”; el objetivo es entender.
01 · Propósito
Aprender técnicas reales de seguridad (web, red, sistemas) con una metodología clara: reconocer → analizar → explotar en control → documentar → corregir → endurecer.
- Aprendizaje práctico, no teoría vacía.
- Documentación como disciplina central.
- Mejora continua: cada fallo enseña una defensa.
02 · Ley del Sandbox
Todo lo que ocurre en el laboratorio está diseñado para existir solo aquí. Los datos son simulados y los accesos son para entrenamiento.
- Se prohíbe cualquier intento de salir del entorno controlado.
- Se prohíbe atacar infraestructuras externas o de terceros.
- La ética es el cortafuegos: sin ética no hay acceso.
03 · Espíritu
“Romper” aquí significa medir, entender y reconstruir. Cada misión completada debe dejar un rastro de conocimiento.
2) No hay poder sin responsabilidad.
3) No hay hacking sin método.
4) No hay método sin documentación.
5) No hay documentación sin verdad técnica.
04 · Declaración
CyberShellGame.net no promueve actividades ilegales. Es un espacio de formación donde se simulan escenarios, vulnerabilidades y defensas para mejorar la seguridad.
- Sin datos reales · Sin víctimas · Sin daño
- Solo aprendizaje dentro del laboratorio
- Zero trust fuera del sandbox
Normas extendidas
Estas reglas protegen el proyecto, a los participantes y al objetivo educativo. Se aplican a cada reto, misión, herramienta y publicación.
1 · Alcance y autorización
El alcance permitido es exclusivamente el conjunto de dominios y servicios del laboratorio CyberShellGame. Cualquier uso fuera de este alcance queda prohibido.
- Permitido: pruebas en servicios del lab (p.ej. WordPress lab, login lab, player lab) dentro de CyberShellGame.
- Prohibido: atacar objetivos de terceros, redes externas, APIs ajenas o infraestructura no incluida.
- Regla de oro: si no hay autorización explícita y por escrito, no se toca.
2 · Datos simulados y privacidad
Los datos del laboratorio son simulados. Aun así, se debe respetar una disciplina de privacidad: no publicar identificadores técnicos innecesarios y no doxxear a nadie.
- Evita publicar listados completos de logs/IPs si no aportan al aprendizaje.
- No se permite intentar recolectar datos personales reales (aunque “parezca posible”).
- El objetivo es el conocimiento, no el “coleccionismo de info”.
3 · Seguridad operativa del laboratorio
Mantener el lab usable es parte de la misión. Se prohíbe cualquier acción que destruya el entorno o lo deje inservible.
- No DoS real: no saturar servicios con tráfico masivo.
- No destrucción: no borrar sistemas, no cifrar, no sabotear.
- Progreso: si encuentras una debilidad crítica, documéntala y repórtala al admin del lab.
4 · Publicación de writeups
Se fomentan los writeups educativos, pero con una política clara: no publicar soluciones completas de misiones activas.
- Describe metodología, conceptos, defensa y lecciones aprendidas.
- Deja “pistas” técnicas, no “contraseñas finales”.
- Cuando una misión se cierre, se puede publicar el “full writeup” si el admin lo marca como
ARCHIVED.
5 · Herramientas y uso responsable
Las herramientas (escáneres, fuerza bruta, inyección, etc.) se usan con objetivos didácticos. El foco es aprender límites, parámetros y defensas.
- Usa límites de velocidad (rate limit) cuando sea razonable.
- Evita repetir ataques sin sentido: documenta y avanza.
- No se aceptan “scripts destructivos” como contribuciones.
6 · Incumplimientos y sanciones
Si se detecta abuso, se aplican medidas para proteger el lab:
- Advertencia (cuando el caso sea leve o por desconocimiento).
- Bloqueo temporal del acceso a misiones.
- Expulsión del proyecto si hay intención clara de daño o salida del sandbox.
Misiones
Las misiones están diseñadas para construir habilidad real por capas: Recon → Enumeración → Explotación controlada → Post-explotación segura → Defensa y hardening. Cada misión tiene “evidencias” (proof) y “lecciones”.
| ID | Nombre | Objetivo educativo | Proof (Evidencia) | Estado |
|---|---|---|---|---|
| M00 | Handshake del Sandbox | Entender alcance, reglas, y cómo documentar. | Captura de pantalla de la página de normas + resumen en 5 líneas. | OPEN |
| M01 | Recon & Fingerprint | Enumeración básica: cabeceras, rutas, versiones, superficie de ataque (solo lab). | Lista de hallazgos (sin credenciales) + medidas defensivas propuestas. | OPEN |
| M02 | WPScan Vulnerabilities | Interpretar resultados, CVEs, riesgo real vs teórico, mitigaciones. | Informe tipo post: vulnerabilidad → impacto → fix (sin exploit completo). | OPEN |
| M03 | Auth Gate (Login Lab) | Entender autenticación web, límites, y defensa (rate-limit, lockouts). | Writeup con metodología + recomendación de protección. | ROTATING |
| M04 | Session & Tokens | Cookies, sesiones, y fallos típicos (solo entorno lab, sin abuso). | Listado de checks + propuesta de hardening. | OPEN |
| M05 | Input Validation | Entender validación/sanitización y por qué fallan. | PoC mínima no destructiva + fix recomendado. | OPEN |
| M06 | Blue Team Patch | Convertir un hallazgo en defensa: WAF, headers, permisos, actualizaciones, hardening. | Checklist aplicable + diff de configuración (si procede). | OPEN |
| M07 | Incident Drill | Simular incidente: detectar → contener → erradicar → recuperar → lecciones. | Timeline + 5 controles preventivos. | SCHEDULED |
| M08 | Mentor Mode | Ayudar a otros: revisar writeups, mejorar metodología, proponer defensas. | Feedback técnico estructurado en 10 puntos. | OPEN |
Rangos & niveles
Los rangos miden disciplina y método (no solo “exploits”). Subir de rango requiere pruebas y documentación. Cada nivel desbloquea tipos de misiones y responsabilidades.
Escalera de rangos
- Nivel 0 · Visitor — Lee normas, observa, aprende el alcance.
- Nivel 1 · Scout — Recon / enumeración, reportes básicos.
- Nivel 2 · Operator — PoCs controladas, análisis de impacto, mitigaciones.
- Nivel 3 · Specialist — Misiones avanzadas, writeups estructurados, defensas sugeridas.
- Nivel 4 · Architect — Diseña misiones, revisa hardening, propone mejoras del lab.
- Nivel 5 · Guardian — Custodia ética: revisión final, control de estabilidad, respuesta a incidentes del lab.
Requisitos de ascenso
- Scout → Operator: 2 misiones OPEN + 1 propuesta de hardening.
- Operator → Specialist: 3 writeups + 1 “defense patch plan”.
- Specialist → Architect: diseñar 1 misión + rubric de evaluación.
- Architect → Guardian: mantener estabilidad del lab + protocolo de respuesta.
Todos los ascensos requieren: respeto total del sandbox, sin intentos de salida.
Niveles de acceso (política)
Access A · Read-Only (Visitor)
Qué puede hacer: leer documentación, ver misiones, practicar localmente con ejemplos genéricos.
Qué no: lanzar scans, fuerza bruta o acciones que generen carga.
Access B · Recon (Scout)
Qué puede hacer: enumeración básica, comprobaciones de superficie, informes sin credenciales.
Qué no: pruebas repetitivas agresivas, ni acciones destructivas.
Access C · Controlled Exploit (Operator+)
Qué puede hacer: PoCs mínimas, verificación controlada, análisis de impacto.
Obligatorio: incluir mitigación y hardening en cada entrega.
Access D · Lab Builder (Architect/Guardian)
Qué puede hacer: diseñar misiones, ajustar dificultad, validar defensas sin romper el lab.
Responsabilidad: estabilidad, ética, y continuidad educativa.
1) Alcance respetado · 2) Metodología clara · 3) Evidencias mínimas · 4) Impacto explicado · 5) Mitigación propuesta · 6) No destructivo · 7) Reproducible · 8) Lenguaje técnico · 9) Defensa priorizada · 10) Lecciones aprendidas.