Motor Autónomo de Detección y Contención Heurística de Ransomware

Prototipo de cifrado progresivo + detección y contención autónoma.

Importante: el cifrado es real (AES-256-GCM), pero el simulador está deliberadamente confinado a demo_data y únicamente procesa los archivos sintéticos creados por setup_demo.py. No acepta una ruta de destino, no busca carpetas personales, no tiene persistencia, no usa red y no bloquea Windows. La pantalla a pantalla completa es una simulación visual con salida segura.

1. Diagrama de flujo de la detección

flowchart TD
    A["Cada 350 ms:<br/>foto del filesystem + muestra I/O por proceso"] --> B["Delta vs. foto anterior:<br/>creados / borrados / modificados"]
    B --> C["Entropía de Shannon de archivos<br/>nuevos o modificados (≥ 7,35 bits/byte)"]
    C --> D["Ventana móvil de 2,5 s:<br/>puntuación combinada de señales (máx 9)"]
    D --> E{"Score ≥ 5?"}
    E -- "No" --> A
    E -- "Sí" --> F["Correlación: proceso con mayor<br/>escritura reciente (≥ 64 KiB),<br/>nacido durante el monitoreo"]
    F -- "Sin candidato" --> G["Registrar patrón sospechoso<br/>y seguir escaneando"]
    G --> A
    F -- "Con candidato" --> H["Contención: terminate()<br/>→ kill() si no cede en 1,5 s"]
    H --> I["Reporte de contención JSON<br/>(quarantine/) + detector.jsonl"]

Loading

La clasificación es puramente conductual: ninguna firma identifica al simulador; la decisión surge solo de la combinación de señales débiles dentro de la ventana móvil (detalle en la sección 7).

2. Qué incluye

Archivo	Función
src/setup_demo.py	Crea 30 archivos sintéticos en cinco carpetas y guarda sus hashes SHA-256 originales.
src/ransomware_sim.py	Cifra una carpeta nueva cada 5 segundos con AES-256-GCM y una clave derivada de contraseña; luego muestra la pantalla de recuperación.
src/detector.py	Escanea cada 0,35 s, puntúa comportamiento anómalo y termina automáticamente el proceso de escritura correlacionado.
src/verify_lab.py	Compara los SHA-256 actuales contra el manifiesto y demuestra que la restauración quedó byte por byte intacta.
src/self_test.py	Ejecuta una prueba integrada de detección, contención, recuperación e integridad antes de la exposición.
src/lab_common.py	Límites de seguridad, rutas y utilidades compartidas.

3. Estructura del repositorio

proyecto_ransomware_lab/
├── .gitignore            # Excluye .venv, demo_data, logs, quarantine y el manifiesto
├── README.md
├── requirements.txt
└── src/
    ├── __init__.py
    ├── lab_common.py     # Seguridad, rutas y utilidades compartidas
    ├── setup_demo.py     # Genera el entorno sintético + manifiesto SHA-256
    ├── ransomware_sim.py # Cifrado progresivo + pantalla de recuperación
    ├── detector.py       # Detección y contención autónoma
    ├── verify_lab.py     # Verificación de integridad post-recuperación
    └── self_test.py      # Prueba integrada de todo el flujo

En tiempo de ejecución se generan demo_data/, logs/, quarantine/ y lab_manifest.json en la raíz del repositorio. Ninguno se sube a GitHub (ver .gitignore).

4. Preparación en la VM (Windows)

Recomendado: Python 3.11 o superior (probado con 3.13) en una máquina virtual con snapshot.

py -m venv .venv
.venv\Scripts\Activate.ps1
python -m pip install -r requirements.txt
python src\setup_demo.py
python src\verify_lab.py

Resultado esperado de la última orden:

Integridad SHA-256: 30/30 archivos idénticos al estado inicial.
OK: el entorno volvió intacto a su estado original.

Antes de la clase conviene ejecutar también la prueba integrada:

python src\self_test.py

Debe finalizar con SELF-TEST OK: detección, contención y recuperación verificadas.

Contraseña sugerida para la exposición: Seguridad2026.

5. Demostración A: cifrado + pantalla + recuperación

Con el detector apagado:

python src\setup_demo.py
python src\ransomware_sim.py encrypt --password Seguridad2026

Qué observar:

1. El primer grupo de archivos cambia inmediatamente.
2. Se selecciona una carpeta nueva cada 5 segundos.
3. Los originales desaparecen de demo_data y aparecen representaciones cifradas de alta entropía.
4. Al terminar se abre una pantalla completa de advertencia académica.
5. Escriba Seguridad2026 y pulse DESCIFRAR Y DESBLOQUEAR.
6. Compruebe la integridad:

python src\verify_lab.py

Ese 30/30 es evidencia objetiva de que no solo se recuperaron nombres: el contenido volvió exactamente igual, porque se compara SHA-256 de cada archivo contra el estado previo al cifrado.

Si cerró la pantalla de forma segura, también puede recuperar desde terminal:

python src\ransomware_sim.py decrypt --password Seguridad2026
python src\verify_lab.py

Con una contraseña errónea, AES-GCM falla la autenticación antes de escribir el texto recuperado y conserva el archivo cifrado.

6. Demostración B: detección y contención autónoma

Restablezca primero el entorno:

python src\setup_demo.py

Abra dos PowerShell en esta misma carpeta (la raíz del repositorio).

Terminal 1:

.venv\Scripts\Activate.ps1
python src\detector.py

Terminal 2:

.venv\Scripts\Activate.ps1
python src\ransomware_sim.py encrypt --password Seguridad2026

El detector debería alertar y finalizar el proceso antes de que transcurran los 5 segundos necesarios para que el simulador avance a la siguiente carpeta. Muestra la latencia real de detección y deja evidencia en quarantine/containment-*.json y logs/detector.jsonl.

Después de la contención, recupere cualquier archivo alcanzado antes de que el proceso fuera detenido:

python src\ransomware_sim.py decrypt --password Seguridad2026
python src\verify_lab.py

7. Cómo detecta sin "saber" cuál es el ransomware

src/detector.py no contiene el nombre ransomware_sim.py, no busca .locked, no lee la cabecera del formato cifrado y no compara un hash del programa.

En una ventana móvil de 2,5 s observa:

• Ráfaga de cambios: muchos archivos creados, borrados o modificados en muy poco tiempo.
• Patrón destructivo: varios archivos desaparecen mientras aparecen varios nuevos.
• Entropía: si varios archivos nuevos/modificados pasan a tener bytes casi aleatorios, suma evidencia compatible con cifrado o compresión.
• Concentración de extensiones nuevas: detecta que muchas salidas recientes comparten una terminación, cualquiera que esta sea.
• I/O por proceso: correlaciona el evento del disco con el proceso que más bytes acaba de escribir.

Cada señal aislada puede ser legítima. Por eso se usa una puntuación combinada. Al superar el umbral, el proceso con la actividad de escritura correlacionada se finaliza automáticamente.

Límite de contención de la práctica

Para que un falso positivo nunca mate procesos ajenos a la práctica, el detector solo puede contener procesos cuyo directorio de trabajo esté dentro de esta carpeta del proyecto y que hayan nacido después de que el detector arrancó. La segunda condición es el modelo de amenaza real (el ataque se lanza durante la observación) e impide que la contención alcance procesos preexistentes del laboratorio (terminales, shells, runners). Estas dos fronteras no identifican el ransomware: únicamente definen el perímetro seguro de la VM/laboratorio. La clasificación sigue dependiendo exclusivamente del comportamiento observado.

8. Relación directa con la rúbrica

Rúbrica	Evidencia en la demo
Cifrado progresivo	ransomware_sim.py agrupa por carpeta y programa cada inicio con intervalo exacto de 5 s.
Cifrado real y funcional	AES-256-GCM mediante cryptography; los bytes almacenados no son una simple renombrada/codificación.
Contraseña y recuperación	PBKDF2-SHA256 deriva la clave desde la contraseña; AES-GCM autentica cada archivo antes de restaurarlo.
Recuperación intacta	verify_lab.py exige 30/30 hashes SHA-256 iguales al manifiesto original.
Mensaje/pantalla de bloqueo	Ventana tkinter a pantalla completa y topmost, explícitamente etiquetada como simulación académica.
Escaneo más rápido	0,35 s por escaneo frente a 5 s por cambio de carpeta.
Detección por rastros	Ráfaga de archivos + borrado/creación + entropía + I/O; ninguna firma del simulador.
Contención automática	psutil termina el PID correlacionado sin pedir confirmación.
Operación autónoma	Una vez iniciadas ambas herramientas, ninguna intervención es necesaria para detectar y contener.

La única diferencia deliberada frente a un ransomware real es el alcance: en vez de recorrer contenido personal de la computadora, cifra datos sintéticos. Para la exposición conviene decirlo expresamente como control de seguridad de la práctica.

9. Mapeo MITRE ATT&CK

El laboratorio reproduce, de forma confinada, dos técnicas del framework:

Técnica ATT&CK	ID	Componente del laboratorio	Cómo se emula
Data Encrypted for Impact	T1486	ransomware_sim.py	El actor cifra archivos de la víctima con AES-256-GCM (clave derivada con PBKDF2-SHA256, salt y nonce por archivo), dejando los datos inutilizables hasta pagar/descifrar.
Command and Scripting Interpreter: Python	T1059.006	ransomware_sim.py	El payload se distribuye y ejecuta como un script Python de línea de comandos (encrypt --password ...), sin binario compilado ni persistencia.

Del lado defensivo, detector.py representa el control de comportamiento equivalente al que implementa un EDR moderno: detecta T1486 en curso (ráfaga destructiva + alta entropía + concentración de extensiones) sin firmas ni hashes, y contiene al intérprete T1059 que la ejecuta (correlación por I/O y terminación del proceso). La correspondencia exacta entre cada señal del detector y la evidencia que aporta se detalla en la sección 7.

10. Explicación técnica corta para defender el código

1. setup_demo.py crea la evidencia inicial y calcula SHA-256.
2. Para cada archivo, el simulador genera salt y nonce aleatorios.
3. PBKDF2-SHA256 transforma la contraseña en una clave de 256 bits.
4. AES-GCM cifra y agrega autenticación: una clave incorrecta o datos alterados no producen una restauración silenciosamente corrupta.
5. Se escribe primero un temporal, se sincroniza y luego se reemplaza; así se reduce el riesgo de dejar una salida incompleta.
6. El detector toma una línea base, vuelve a escanear cada 350 ms y mantiene una ventana móvil de 2,5 s.
7. Cuando varias señales coinciden, correlaciona el cambio con el proceso de mayor escritura reciente nacido durante el monitoreo dentro del límite del laboratorio y lo termina.
8. El reporte JSON deja visibles las métricas que provocaron la decisión, por lo que la detección es explicable.

11. Mejoras técnicas que puede proponer en la presentación

• En Windows real: consumir ETW/Sysmon o un minifiltro para atribuir cada operación de archivo directamente al PID, en vez de correlacionar por tiempo e I/O.
• Mantener una copia transaccional/rollback de archivos afectados antes de la contención.
• Aprender una línea base por usuario y tipo de archivo para reducir falsos positivos de compresores, copias de seguridad y compilaciones.
• Combinar entropía con tasas de rename, delete, apertura masiva y fallos de acceso.
• Ejecutar el detector como servicio protegido y enviar telemetría a un SIEM.
• Agregar pruebas automatizadas de falsos positivos con cargas legítimas (ZIP, copia masiva, compilación) y medir precisión/recall.

12. Notas de seguridad para la exposición

• Use exclusivamente la VM y tome un snapshot antes de la clase.
• No quite el marcador ni cambie LAB_ROOT para apuntar a datos reales.
• No ejecute la demostración con privilegios de administrador; no los necesita.
• No copie archivos personales a demo_data; use setup_demo.py para regenerar el entorno.
• La pantalla completa tiene una salida segura y no modifica políticas, sesión, teclado ni shell de Windows.

13. Despliegue en una VM local (Ubuntu 22.04 LTS)

Paso a paso de referencia para recrear la máquina virtual de la exposición en cualquier computadora, sin servicios en la nube. La presentación original se hizo en una instancia EC2 de AWS; este procedimiento la reemplaza por una máquina virtual local de VirtualBox con Ubuntu 22.04 LTS (mismo sistema operativo, en local).

Requisitos del anfitrión: Oracle VirtualBox 7.x instalado y virtualización activada (VT-x/AMD-V en el firmware). En Windows: Administrador de tareas → Rendimiento → CPU → "Virtualización: Habilitada".

13.1 Crear e instalar la máquina virtual

1. Descargar la ISO Ubuntu 22.04 LTS (ubuntu-22.04.x-desktop-amd64.iso) desde ubuntu.com/download.
2. VirtualBox → Nueva:
   • Nombre: ransomware-lab | Tipo: Linux | Versión: Ubuntu (64-bit)
   • Memoria: 4096 MB (mínimo 2048 MB)
   • Disco virtual: 30 GB, tipo VDI, expansión dinámica
3. Configuración de la VM → Sistema → Procesador: 2 CPUs y casilla VT-x/AMD-V habilitada.
4. Configuración → Almacenamiento: montar la ISO en la unidad óptica.
5. Arrancar la VM e instalar Ubuntu (instalación mínima, usuario normal con contraseña). Al terminar, desmontar la ISO y reiniciar.

13.2 Preparar el sistema

Dentro de la VM:

sudo apt update && sudo apt upgrade -y
sudo apt install -y python3-venv python3-pip git python3-tk

• python3-tk: pantalla de bloqueo del simulador (tkinter)
• Ubuntu 22.04 trae Python 3.10; el código es compatible pese a la recomendación 3.11+ de la sección 4.
• No hace falta xrdp ni SSH: la VM tiene su propia pantalla en la ventana de VirtualBox.

(Opcional) Guest Additions para pantalla completa y portapapeles compartido: menú Dispositivos → Insert Guest Additions CD image y ejecutar VBoxLinuxAdditions.run dentro de la VM. No es imprescindible: la pantalla de bloqueo se ve igual en la ventana de la consola.

13.3 Clonar y preparar el proyecto

cd ~
git clone https://github.com/LoesssLR/Cibersecurity_Ramsomware.git
cd Cibersecurity_Ramsomware
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/python src/setup_demo.py
.venv/bin/python src/verify_lab.py        # 30/30 + OK
.venv/bin/python src/self_test.py         # SELF-TEST OK

13.4 Demostraciones (flujo final de la exposición)

Demo A — cifrado + pantalla de bloqueo + recuperación. Abrir el administrador de archivos (GNOME Files) en demo_data y una terminal:

.venv/bin/python src/setup_demo.py
.venv/bin/python src/ransomware_sim.py encrypt --password Seguridad2026

Aparece la pantalla roja de bloqueo a pantalla completa; se escribe la contraseña y se pulsa DESCIFRAR Y DESBLOQUEAR:

.venv/bin/python src/verify_lab.py

Luego restablecer el entorno:

.venv/bin/python src/setup_demo.py

Demo B — detección y contención (dos terminales en el escritorio de la VM; así la demo es solo texto e instantánea, y Files queda abierto para ver los archivos pasar a .locked en vivo):

# Terminal 1: el detector
.venv/bin/python src/detector.py
# Terminal 2: el ataque sin interfaz (1-2 s después del detector)
.venv/bin/python src/ransomware_sim.py encrypt --password Seguridad2026 --no-ui

El detector alerta en ~0,4 s (Score=8), correlaciona el PID del simulador por I/O real y lo termina; mientras tanto, en Files se ven los archivos pasar a .locked. La evidencia:

cat quarantine/containment-*.json

Y la recuperación de lo alcanzado antes de la contención:

.venv/bin/python src/ransomware_sim.py decrypt --password Seguridad2026
.venv/bin/python src/verify_lab.py

Resumen del flujo de la exposición: Demo A en la VM (el ataque con pantalla) → reset → Demo B en dos terminales (el defensor, con Files de testigo) → evidencia (reporte de contención) → verify_lab 30/30.

13.5 Snapshot (red de seguridad)

Una vez verificado todo (self_test OK), crear un snapshot de la VM:

VirtualBox → menú Máquina → Tomar snapshot (nombre: funcional).

Un snapshot es una foto completa del disco: si algo falla el día de la exposición, Máquina → Restaurar snapshot devuelve la VM al estado funcional en minutos. Para un respaldo fuera del equipo: Archivo → Exportar appliance (OVA) y conservar el archivo.

13.6 Particularidades del detector en Linux

El detector fue ajustado para correr de forma confiable en Linux nativo:

• Solo procesos nacidos durante el monitoreo son candidatos a contención (modelo de amenaza real): nunca se toca un proceso preexistente (terminal, shell, runner de pruebas).
• La actividad se mide por deltas reales entre muestras, no por contadores I/O acumulados, que pueden arrastrar I/O histórico de corridas previas y desviar la correlación.
• La contención sondea estado (status()/zombie) en vez de waitpid(): en Linux no se puede esperar (waitpid) a un proceso que no es hijo del detector, y el simulador es hijo del runner de self_test.
• psutil.io_counters() funciona con procesos vivos; un AccessDenied al muestrear procesos recién terminados es un artefacto de zombie, no un problema de permisos.

13.7 Apagar y encender la VM

• Apagar la VM desde el escritorio de Ubuntu (o al cerrar la ventana elegir "Save the machine state": guarda sesión y programas corriendo).
• Al encenderla de nuevo todo queda como estaba: sistema, proyecto, venv y configuración. Los snapshots solo son para restaurar el disco si algo se rompe.
• Para actualizar el código en la VM: git pull y re-ejecutar src/verify_lab.py y src/self_test.py.
• Si se cambia de computadora anfitriona: Archivo → Exportar appliance (OVA) y Importar appliance en la nueva, conservando el snapshot.