En la lección anterior colocaste el mapa: los dominios de la disciplina, los marcos que la organizan y —sobre todo— el ciclo de vida de un ataque. Ahora vamos a llenar ese esqueleto de contenido. Esta lección recorre los ataques técnicos que se ejecutan contra sistemas como el de Nimbus Reservas, ordenados por la fase de la cadena en la que aparecen: cómo el adversario recoge información, cómo ataca la red, cómo consigue credenciales, cómo explota una aplicación web, cómo despliega ransomware o compromete una cadena de suministro y cómo abusa de una API. De cada uno verás qué es, un ejemplo mínimo y conceptual sobre la arquitectura de Nimbus, cómo se detecta y hacia dónde apunta su defensa. El enfoque es defensivo en todo momento: los ejemplos son ilustrativos, mínimos y siempre acompañados de su corrección. Conocer el ataque no es un fin, es el requisito para diseñar la defensa.

1. Cómo se organiza este catálogo y una advertencia previa
2. Fase 1 — Reconocimiento: OSINT y escaneo
3. Ataques a la red: escucha, suplantación e interposición
4. Denegación de servicio: volumétrica y aplicativa
5. Ataques a credenciales y sesiones
6. Ataques a aplicaciones web: el Top 10 de OWASP como marco
7. Malware en acción: ransomware moderno y doble extorsión
8. Ataques a la cadena de suministro
9. Ataques específicos a APIs
10. Un ataque encadenado sobre Nimbus, paso a paso
11. Tabla resumen: ataque, propiedad afectada, detección y defensa

Un catálogo de ataques sin estructura es una lista imposible de recordar. Por eso usamos el eje que ya conoces —las fases de la Kill Chain— y añadimos una segunda clave de lectura: qué propiedad de la tríada CIA rompe cada ataque, la que estableciste en 01-01.

Advertencia necesaria. Todo lo que sigue está escrito para defender. No encontrarás aquí herramientas listas para atacar, código funcional de malware ni instrucciones aplicables a sistemas de terceros. Los ejemplos son fragmentos mínimos sobre el entorno ficticio de Nimbus, siempre con su corrección al lado. Ejecutar cualquiera de estas técnicas contra sistemas que no son tuyos y sin autorización expresa y por escrito es un delito; el marco legal y ético de las pruebas autorizadas se trata en 06-06, y la metodología de las pruebas de penetración en 05-03.

El reconocimiento es la fase que las organizaciones ignoran porque no deja rastro en sus sistemas: buena parte ocurre sin tocarlos.

Qué es. Recopilar información públicamente disponible sobre el objetivo. No se explota nada; se lee lo que la organización ha publicado sin darse cuenta.

Qué encuentra un atacante sobre Nimbus sin tocar un solo servidor:

Cómo se defiende. No se puede impedir que alguien lea lo público, pero sí reducir lo que se publica sin querer:

• Revisar periódicamente los subdominios que aparecen en transparencia de certificados y retirar los que ya no existen (es el hallazgo del ejercicio 3 de la lección anterior).
• Escanear el histórico de los repositorios en busca de secretos —no basta con borrar el fichero: en Git sigue estando en el historial— y rotar cualquier credencial expuesta.
• Limpiar metadatos de los documentos publicados.
• Asumir que la lista de correos del equipo es pública. La defensa no es ocultarla, es MFA y formación (02-03, 02-05).

Qué es. Contactar activamente con los sistemas del objetivo para descubrir qué hay: qué IPs responden, qué puertos están abiertos, qué servicios y versiones corren, qué rutas existen en la aplicación web.

A diferencia del OSINT, el escaneo sí deja rastro. Y aquí está la asimetría importante para una PYME: Nimbus ya está siendo escaneada continuamente por bots que no saben qué es. Distinguir el escaneo dirigido del ruido de fondo es difícil; lo que sí es factible es fijarse en escaneos lentos, ordenados y desde una misma fuente, que sugieren interés real.

Cómo se lee este extracto:

• Seis peticiones en seis segundos desde la misma IP, todas a rutas que no existen en Nimbus. Es un escáner automatizado probando el catálogo habitual.
• /wp-login.php y /phpmyadmin/ delatan que el bot no sabe qué tecnología usa Nimbus: prueba todo. Esto es el ataque oportunista de 01-04 en estado puro.
• La señal defensiva más valiosa no está en los 404, sino en el día que uno de ellos devuelva 200. Por eso la alerta útil no es «tenemos escaneos» (los tienes siempre), sino «una ruta sensible ha devuelto algo distinto de 404».

Las herramientas de descubrimiento y escaneo se ven en 05-01 y 05-03. Aquí interesa el concepto y su contrapartida defensiva: cada servicio que no expones es un servicio que no aparece en ningún escaneo.

Estos ataques atacan el canal, no los extremos. Comparten una premisa: si el atacante consigue estar en medio o escuchar, la seguridad de los extremos deja de bastar.

Es la pregunta correcta. TLS bien implementado hace que la escucha pasiva sea inútil: el atacante ve tráfico cifrado. Pero quedan tres huecos reales en Nimbus:

1. El tráfico interno que no va cifrado. En el DFD de 01-04, el flujo F3 (balanceador → API) era HTTP interno. Alguien que llegue a esa red lo lee en claro. Es el motivo del principio Zero Trust: la red interna no es de confianza.
2. Los metadatos siguen visibles. Aunque el contenido esté cifrado, un observador ve a qué dominios te conectas, cuándo y cuánto volumen. La consulta DNS previa suele ir en claro.
3. La degradación y el error de usuario. Si un portátil de Nimbus acepta un certificado no válido con un clic, TLS deja de proteger. Por eso existe HSTS (que veremos en 02-04) y por eso los clientes deben rechazar, no preguntar.

Ejemplo mínimo del error clásico en el código de Nimbus:

Por qué verify=False es tan grave y tan frecuente: desactiva la comprobación de que el certificado presentado corresponde realmente al dominio y está firmado por una autoridad reconocida. El tráfico sigue cifrado, lo que da una falsa sensación de seguridad, pero cifrado contra el atacante si este se ha interpuesto. Aparece casi siempre como parche temporal en un entorno de pruebas y acaba en producción. Regla práctica: verify=False no debe existir en ningún repositorio; si un certificado interno da problemas, la solución es añadir la autoridad interna al almacén de confianza, no desactivar la verificación. Un análisis estático en el CI (02-04) lo detecta automáticamente.

El objetivo es la disponibilidad: impedir que los clientes de Nimbus usen el servicio. Para un SaaS del que dependen agendas de clínicas en marcha, una hora de caída tiene un coste inmediato y visible.

El más peligroso para Nimbus es el tercero, y es el más subestimado. Recuerda el endpoint de informes sin paginación que rompía la disponibilidad en 01-01: 20 peticiones bien elegidas pueden tumbar la API, mientras que un DDoS volumétrico requiere una botnet. La defensa contra el volumétrico se compra (servicio anti-DDoS del proveedor); la defensa contra el aplicativo se programa.

Las cuatro defensas que aparecen aquí, explicadas:

1. Validación de tipos (desde: date en vez de str): rechaza entradas malformadas antes de llegar a la base de datos.
2. Límite de negocio (92 días): un informe de ocupación de diez años no es un caso de uso legítimo. Los límites de negocio son más efectivos que los técnicos porque son defendibles ante el cliente.
3. Paginación con LIMIT: acota la memoria y el tiempo de cada petición, pase lo que pase.
4. Límite de tasa (5/minute): acota cuántas veces se puede pagar ese coste. Sin él, los otros tres límites solo obligan al atacante a repetir más.

Detección: latencia media de la API disparada con poco tráfico entrante, consultas lentas en PostgreSQL concentradas en un endpoint, y un mismo user_id o token concentrando la mayor parte del consumo. Estas señales, en un DDoS volumétrico, serían distintas: mucho tráfico y saturación de red.

La identidad es hoy la vía de entrada dominante, porque una credencial válida no dispara ninguna alarma: no hay exploit, no hay malware, no hay anomalía de protocolo. Solo alguien entrando.

Merece atención especial porque está diseñado para eludir el bloqueo de cuenta. Si Nimbus bloquea tras 5 intentos fallidos por cuenta, el atacante prueba una sola contraseña muy común contra las 38 cuentas del equipo, espera una hora y prueba la siguiente. Ninguna cuenta llega nunca a 5 fallos.

Cómo se lee: cuatro fallos y un éxito, un intento por cuenta, misma IP, cuatro segundos entre cada uno, a las 2 de la madrugada. Ninguna cuenta ha llegado al umbral de bloqueo, y sin embargo el ataque ha tenido éxito. La detección correcta no cuenta fallos por cuenta, sino fallos distintos por origen y la relación entre cuentas atacadas y cuentas existentes. Esta es exactamente la clase de regla que se construye en 05-02.

La defensa que lo neutraliza casi por completo es MFA resistente al phishing, junto con la comprobación de contraseñas contra listas de filtradas. Ambas se desarrollan en 02-05.

En el inventario descubriste un token de la cuenta nimbus-deploy-bot sin caducidad y con permisos de escritura en todos los repositorios. Un token así tiene tres propiedades que lo convierten en el objetivo perfecto:

• No caduca: robarlo una vez basta para siempre.
• No tiene segundo factor: un token es la credencial completa.
• Está en muchos sitios: en la configuración del CI, en el portátil de quien lo creó, quizá en un fichero .env, quizá en el historial de un chat.

Su corrección —caducidad corta, ámbito mínimo, credenciales efímeras del propio CI y rotación— se detalla en 02-05.

El OWASP Top 10 es la lista de las diez categorías de riesgo más extendidas en aplicaciones web. No es un catálogo exhaustivo de vulnerabilidades: es una lista de categorías por frecuencia e impacto, y por eso funciona bien como guía de revisión. Recorremos las más relevantes para la API de Nimbus.

Es la primera categoría del Top 10 por prevalencia, y ya te la encontraste en 01-01.

Qué es. El sistema autentica correctamente («sé quién eres») pero no autoriza correctamente («no compruebo que esto sea tuyo»).

Variantes de la misma familia que conviene reconocer:

• Escalada horizontal: acceder a datos de otro usuario del mismo nivel (el IDOR clásico).
• Escalada vertical: un usuario de recepción consigue funciones de administrador porque el control está solo en el interfaz y no en el servidor.
• Manipulación de parámetros: enviar {"rol": "admin"} en el cuerpo de una actualización de perfil y que el servidor lo acepte porque hace una asignación masiva de campos.

Detección. Es difícil desde fuera y fácil desde la auditoría: si el log registra usuario, tenant y recurso, una consulta que busque accesos donde el tenant del recurso no coincide con el del usuario encuentra los intentos. Sin ese log, es invisible. He aquí por qué la auditoría de 01-01 y 01-03 no era burocracia.

Qué es. El dato del usuario se concatena en una consulta y el motor lo interpreta como instrucción en lugar de como dato.

Si texto contiene una comilla, la estructura de la consulta cambia. Basta este ejemplo conceptual: un valor como ' OR '1'='1 transforma la condición de búsqueda en una condición siempre cierta, y la consulta devuelve todas las filas a las que el rol de base de datos tenga acceso. Variantes más avanzadas permiten leer otras tablas o inferir datos carácter a carácter por el tiempo de respuesta (inyección ciega).

Por qué la parametrización funciona de verdad y el «escapado manual» no: con parámetros, el motor recibe primero la estructura de la consulta y después los valores, ya como datos. No hay ningún contenido de texto que pueda cambiar la estructura, porque la estructura ya está fijada. El escapado manual, en cambio, depende de acertar con todas las combinaciones de comillas, codificaciones y modos del motor: tarde o temprano falla.

Segunda capa (la que salva cuando la primera falla): el rol nimbus_api de 01-03 no tiene DELETE, no tiene DDL y no puede leer nominas ni claves_pasarela. Una inyección con ese rol es grave, pero acotada. Y la RLS de PostgreSQL impide además que devuelva filas de otro tenant. Defensa en profundidad en estado puro.

Detección: errores de SQL en los logs de aplicación (un syntax error at or near es una señal inequívoca de que alguien está probando), picos de consultas anómalamente lentas, y peticiones con comillas o palabras clave SQL en parámetros que nunca deberían contenerlas. Un WAF detecta muchos intentos, pero no sustituye a la parametrización.

Qué es. El atacante consigue que el navegador de otra víctima ejecute código en el contexto del sitio de Nimbus. La víctima no es el servidor: es el usuario.

Ejemplo conceptual y mínimo. El campo «notas» de una reserva admite texto libre. Si la SPA lo inserta en la página sin escapar, un texto que contenga una etiqueta <script> se ejecutará en el navegador de la recepcionista de la clínica que abra esa cita. El impacto no es «una ventana emergente»: es que ese código actúa con la sesión de la recepcionista, y puede leer la agenda completa o realizar acciones en su nombre.

Las tres capas de defensa contra XSS, en orden de importancia:

1. Codificación en la salida según el contexto. El mismo dato se escapa distinto en HTML, en un atributo, en JavaScript o en una URL. Los motores de plantillas modernos y los frameworks de SPA lo hacen por defecto; el problema aparece cuando alguien lo desactiva a propósito (innerHTML, dangerouslySetInnerHTML, |safe).
2. Content-Security-Policy: cabecera que indica al navegador de qué orígenes puede cargar y ejecutar código. Convierte muchos XSS explotables en intentos fallidos. Se detalla en 02-04.
3. Cookies HttpOnly: impiden que el JavaScript lea la cookie de sesión, limitando el robo directo. No impiden que el código actúe en nombre del usuario. Se detalla en 02-05.

Qué es. Un sitio malicioso hace que el navegador de la víctima, ya autenticado en Nimbus, envíe una petición no deseada. El navegador adjunta la cookie de sesión automáticamente, así que la petición parece legítima.

Ejemplo en Nimbus: la administradora de una clínica está autenticada en el panel y visita otra página que, sin que ella lo note, envía un formulario a POST /api/v1/usuarios/invitar para dar de alta a un usuario nuevo con permisos.

Defensas, y por qué hay que combinarlas:

Qué es. El atacante consigue que el servidor de Nimbus haga una petición a una URL que él elige. Es especialmente peligroso en la nube, porque el servidor está dentro de la red privada y puede alcanzar sitios a los que nadie llega desde fuera.

Ejemplo en Nimbus: una funcionalidad permite a la clínica indicar la URL de su logotipo para las facturas, y el servidor la descarga. Si no se valida, el atacante puede indicar una dirección interna —el servicio de metadatos del proveedor cloud, un panel administrativo interno, localhost— y hacer que el servidor la consulte por él. El caso más grave es el acceso al servicio de metadatos de la instancia, que en configuraciones antiguas puede devolver credenciales temporales de la cuenta cloud (A-05).

Las cuatro decisiones del código corregido: solo HTTPS (evita file://, gopher:// y otros esquemas); resolución previa del nombre y comprobación de que la IP no cae en un rango interno; sin seguir redirecciones, porque una redirección es la forma clásica de saltarse la comprobación; y límite de tamaño para que la descarga no se convierta en una denegación de servicio. Aun así, la defensa definitiva es de arquitectura: que estas peticiones salgan por un proxy de salida con lista blanca, y que el servicio de metadatos exija la versión que requiere token (se ve en 05-07).

Qué es. La aplicación reconstruye objetos a partir de datos que vienen del exterior. Algunos formatos permiten que el proceso de reconstrucción ejecute código.

La regla: pickle, yaml.load sin SafeLoader y equivalentes en otros lenguajes nunca deben aplicarse a datos que vengan de fuera. Usa JSON y valida el esquema. La validación con un modelo explícito aporta además defensa contra la asignación masiva de campos: solo se aceptan las tres claves declaradas.

Menos vistosa y muy frecuente. Formas habituales en una API como la de Nimbus:

• Devolver más de lo necesario: SELECT * que incluye dni, notas_internas o hash_password, y confiar en que el interfaz no los muestre. El dato viaja al cliente y está en el navegador.
• Mensajes de error verbosos: una traza completa con la versión de la librería, la ruta del fichero y hasta la consulta SQL.
• Registrar lo que no se debe: tokens, contraseñas o datos de salud en los logs. Se trata en 02-04.
• Objetos accesibles sin autorización: el bucket de adjuntos (A-02) sin política restrictiva. Ya lo resolviste con URLs firmadas de 120 s en 01-03.

La API de Nimbus arrastra alrededor de 180 dependencias transitivas de Python. Iván ha escrito una fracción mínima del código que se ejecuta en producción.

Cómo se lee y qué se hace: cada línea es una vulnerabilidad conocida con su versión corregida. Lo importante no es la lista, es el proceso: que este comando se ejecute en cada construcción, que rompa la integración cuando aparezca algo de severidad alta y que exista un compromiso explícito de plazo de corrección. Un análisis que nadie lee es peor que ninguno, porque genera la sensación de estar cubierto. El yaml completo del CI está en 02-04.

En 01-02 viste la taxonomía de nueve familias de malware. Aquí interesa cómo opera hoy la que más daño causa a empresas del tamaño de Nimbus.

Lo que cambió respecto al ransomware clásico: ya no es un fichero que cifra un ordenador. Es una operación humana, con varios grupos especializados, que dura semanas y en la que el cifrado es el último paso.

Las tres conclusiones defensivas que se derivan de esta cronología:

1. Hay tres semanas de ventana. El ransomware no es instantáneo: es la conclusión visible de un compromiso largo. Cada día de esa ventana es una oportunidad de detección que Nimbus hoy no aprovecha porque nadie mira los logs.
2. Las copias son el objetivo, no un daño colateral. El atacante busca activamente las copias y las borra. Por eso una copia accesible con las mismas credenciales que producción no es una copia: es un fichero más que se va a cifrar. La respuesta es la inmutabilidad y la separación de cuentas (02-04, 04-06).
3. Pagar no resuelve la fuga. Aunque se pague y se descifre, los datos ya salieron. Para Nimbus, con datos de citas de clínicas, eso significa notificación de brecha con independencia de si se recupera el servicio. Las implicaciones concretas se ven en 06-03, y la decisión de pago se analiza en el caso de Colonial Pipeline en 02-06.

Nota legal: el pago de rescates tiene implicaciones legales, fiscales y de sanciones que varían según la jurisdicción y la identidad del grupo atacante. Cualquier decisión en un caso real debe consultarse con asesoría jurídica y con las autoridades competentes.

Qué es. En lugar de atacar a Nimbus directamente, el adversario compromete algo en lo que Nimbus confía y espera a que Nimbus lo instale o lo ejecute. Es un ataque de eficiencia extrema: se compromete uno y se llega a miles.

Por qué es tan difícil de detectar: todo lo anterior parece legítimo. Una dependencia instalada por pip desde el índice oficial, una acción de CI con nombre conocido, una conexión de la consultora en horario laboral. No hay ninguna anomalía de protocolo que detectar; solo comportamiento posterior.

Defensas aplicables hoy en Nimbus:

• Fijar versiones exactas y un fichero de bloqueo con sumas de verificación, para que la construcción sea reproducible.
• Fijar las acciones de CI por hash del commit, no por etiqueta:

• Mínimo privilegio en el CI: que el flujo de construcción no tenga acceso a los secretos de producción, y que los secretos sean efímeros.
• Generar un inventario de componentes (SBOM) para poder responder en minutos a «¿usamos la librería que acaba de salir en las noticias?». Es el inventario de 01-04 aplicado al software.

El tratamiento del proveedor como riesgo gestionable —evaluación, contrato, revisión— corresponde a 04-04.

La API de Nimbus (A-04) es su superficie principal: ~120 endpoints usados por la SPA y la app móvil. Los ataques a APIs no siempre son «vulnerabilidades» en el sentido clásico; muchas veces son usos legítimos llevados al extremo.

El punto que más se subestima: el abuso de lógica de negocio. No hay ninguna vulnerabilidad técnica en reservar y cancelar 200 citas; el sistema hace exactamente lo que se le pidió. Ningún WAF, ningún análisis estático y ningún escáner lo detectan, porque no hay nada malformado. Solo lo detectan límites de negocio pensados por alguien que conoce el dominio, y alertas sobre métricas de negocio (tasa de cancelación anómala en un tenant). Es la razón por la que la seguridad no puede delegarse por completo en herramientas.

Los ataques reales no son una técnica: son una cadena en la que cada eslabón aprovecha el anterior. Reconstruyamos uno completo, conectando lo visto en la lección.

Dónde se rompe esta cadena, eslabón por eslabón:

La observación decisiva: de los ocho eslabones, cinco se rompen con medidas que cuestan poco o nada —caducidad de tokens, ámbito mínimo, filtro de tenant, límite de tasa y una alerta de volumen—. Ninguna requiere comprar un producto. Y el eslabón 6 ya estaba roto de antemano gracias a una decisión de diseño tomada en 01-03: las URLs firmadas de vida corta. Eso es exactamente lo que significa «defensa en profundidad» cuando funciona.

Errores comunes:

• Estudiar los ataques como una lista de nombres. Lo que hay que retener de cada uno son tres cosas: qué propiedad rompe, qué señal deja y qué control lo neutraliza. El nombre es lo de menos.
• Creer que HTTPS resuelve los ataques de red. Resuelve la escucha del contenido externo. No cubre el tráfico interno en claro, ni los metadatos, ni al usuario que acepta un certificado inválido.
• Confiar el filtrado de entradas a una lista negra. Intentar prohibir ', <script> o UNION siempre se puede eludir con codificaciones. La defensa correcta es estructural: parametrizar consultas y codificar en la salida.
• Pensar que un WAF sustituye al código correcto. Un WAF es una capa útil que da tiempo; no arregla una inyección ni un control de acceso roto.
• Ignorar el DDoS aplicativo. Se invierte en protección volumétrica mientras un solo endpoint sin paginación permite tumbar el servicio desde un portátil.
• Tratar el ransomware como un problema de antivirus. Es una operación de semanas cuyo desenlace lo deciden las copias inmutables, el MFA y la segmentación, no la firma del fichero final.
• Suponer que las dependencias son problema de otros. El 95 % del código que corre en producción no lo ha escrito Iván, y las vulnerabilidades de ese 95 % son igual de explotables.
• Olvidar la lógica de negocio. Ninguna herramienta detecta el abuso de una funcionalidad que funciona exactamente como se diseñó.

Consejos:

• Cuando revises un endpoint, hazte cuatro preguntas en este orden: ¿quién eres? (autenticación), ¿es tuyo? (autorización), ¿es válido lo que envías? (validación) y ¿cuánto cuesta esto? (límites).
• Busca en el repositorio de Nimbus estos cinco patrones: verify=False, SELECT *, concatenación de cadenas en SQL, innerHTML y pickle.loads. Encontrarás la mayor parte del riesgo de aplicación en menos de una hora.
• Para cada ataque nuevo que aprendas, escribe la consulta de log que lo detectaría. Si no puedes escribirla, no lo detectarás.
• Practica el ejercicio de la cadena: coge cualquier incidente y pregúntate en qué eslabón habría sido más barato romperlo. Casi siempre es uno de los primeros.
• Recuerda que la mayoría de los ataques con éxito no usan exploits: usan credenciales válidas y configuraciones olvidadas.

Para cada uno de estos extractos o hechos observados en Nimbus, indica: qué ataque sugiere, qué propiedad CIA está en juego, qué comprobarías a continuación y qué defensa corresponde.

Los siguientes fragmentos están en el código de Nimbus. Para cada uno: identifica la vulnerabilidad, explica cómo se explotaría conceptualmente, reescribe el código corregido y añade una segunda capa de defensa independiente del código.

Nimbus sufre el siguiente incidente:

1. Rubén recibe un correo con un fichero adjunto que dice ser una incidencia de una clínica cliente. Lo abre.
2. Su portátil ejecuta un componente que establece un canal saliente con el atacante.
3. El atacante extrae del navegador de Rubén la cookie de sesión del panel interno de soporte, que no caduca hasta pasados 30 días.
4. Con esa cookie entra en el panel de soporte sin pasar por el inicio de sesión ni por el MFA.
5. Desde el panel de soporte, que permite «ver como cliente», accede a los datos de 40 clínicas.
6. Exporta un CSV con 120.000 registros de citas usando la funcionalidad de exportación del panel.
7. Tres días después, la exportación aparece publicada en un foro.

Se pide: (a) asigna cada paso a su fase de la Kill Chain y a la técnica del catálogo de esta lección; (b) indica dos controles por paso que lo habrían roto; (c) explica por qué el MFA no protegió en el paso 4 y qué medida concreta sí lo habría hecho; (d) di en qué paso la detección habría sido más fácil y qué señal exacta habrías buscado.

Solución 1

Solución 2

(a) Buscador de clientes. Vulnerabilidades: inyección SQL por concatenación y exposición excesiva por SELECT *. Explotación conceptual: un valor de q con una comilla cierra la cadena y permite añadir condiciones, convirtiendo el filtro en una condición siempre cierta y devolviendo el contenido completo de la tabla accesible al rol.

Segunda capa independiente del código: el rol nimbus_api sin DELETE ni DDL (01-03) y la RLS por tenant_id, que impide devolver filas ajenas aunque la consulta se manipule. El LIMIT 50 añade además protección contra la extracción masiva y el mínimo de 3 caracteres evita el buscador vacío que devuelve toda la base.

(b) Descarga de adjuntos. Vulnerabilidad: control de acceso roto — se descarga cualquier clave del bucket sin comprobar que la reserva pertenece al tenant del usuario. Además puede permitir recorrido de rutas si la clave contiene ../. Explotación conceptual: conocida o adivinada una clave, cualquier usuario autenticado descarga el adjunto de otra clínica: un parte médico escaneado.

Cambios clave: el cliente ya no elige la clave del objeto, sino el identificador de su reserva; la clave real se obtiene de la base de datos tras verificar la propiedad; se entrega una URL firmada de 120 s en vez de servir el objeto; y se registra el acceso. Segunda capa: el bucket es privado, la política impide el acceso anónimo y la API no tiene permiso de borrado sobre él (01-03).

(c) Webhook de pago. Vulnerabilidades: suplantación (no se verifica que el mensaje venga de la pasarela) y manipulación de la integridad (cualquiera puede marcar facturas como pagadas). Explotación conceptual: una petición HTTP a ese endpoint con un JSON adecuado convierte una factura impagada en pagada. Es la amenaza S del flujo F8 del DFD de 01-04.

Segunda capa: confirmar el estado contra la API de la pasarela antes de dar por buena una operación económica, y restringir el origen a las IPs publicadas por el proveedor. El HMAC se explica en detalle en 03-04.

Solución 3

(a) y (b) Cadena, técnicas y controles:

(c) Por qué el MFA no protegió. El MFA se verifica en el momento del inicio de sesión y produce una sesión. Si el atacante roba la sesión ya emitida, no vuelve a pasar por la autenticación: entra directamente con un artefacto válido. Esa es la esencia del pass-the-cookie y la razón por la que «tenemos MFA» no es una respuesta completa.

Lo que sí habría funcionado, en orden de eficacia:

1. Vincular la sesión a un contexto (dispositivo, IP o certificado de cliente), de modo que una cookie usada desde otro equipo se invalide.
2. Sesiones cortas con renovación silenciosa: una cookie de 30 días es una credencial permanente disfrazada. Horas, no semanas.
3. Reautenticación para operaciones sensibles: suplantar a un cliente o exportar datos exige volver a presentar el segundo factor, aunque la sesión sea válida.
4. Enlace criptográfico del token al cliente (token binding / claves ligadas al dispositivo), que es la línea a la que apuntan las passkeys (02-05).

(d) Dónde detectar y qué señal buscar. El punto más fácil es el paso 6: una exportación de 120.000 registros que abarca 40 tenants distintos es un evento cuantitativamente único en la operación normal de Nimbus. La consulta de detección es directa sobre la tabla de auditoría append-only de 01-01:

Lo importante de esta consulta no es su SQL, sino su premisa: solo funciona si la auditoría registra sesion_id, tenant_id y num_registros. La detección no se improvisa cuando ocurre el incidente; se diseña cuando se escribe el log. Una segunda señal útil, más temprana, es el paso 4: una sesión activa sin evento de autenticación previo en el log es una anomalía que no tiene explicación legítima.

Ya conoces al adversario en acción. Has recorrido los ataques ordenados por las fases de la cadena: el reconocimiento que ocurre sin tocar tus sistemas —OSINT en certificados, repositorios y ofertas de empleo— y el escaneo que sí deja rastro, con la lección práctica de que la alerta útil no es «nos escanean» sino «una ruta sensible ha dejado de devolver 404». Has visto los ataques a la red —escucha, ARP y DNS spoofing, interposición— y por qué siguen importando en un mundo con HTTPS: por el tráfico interno en claro, por los metadatos y por el verify=False que alguien dejó en producción. Has distinguido la denegación de servicio volumétrica, que se compra defensa, de la aplicativa, que se programa, y has comprobado que veinte peticiones bien elegidas hacen más daño que una botnet cuando falta la paginación.

En credenciales has aprendido a distinguir fuerza bruta, diccionario, password spraying —diseñado precisamente para eludir el bloqueo por cuenta— credential stuffing y robo de sesión, con la idea incómoda de que una credencial válida no dispara ninguna alarma. En aplicaciones web has recorrido el Top 10 de OWASP sobre la API de Nimbus: control de acceso roto e IDOR, inyección SQL y por qué la parametrización funciona donde el escapado manual falla, XSS con sus tres capas de defensa, CSRF, SSRF y su ruta hacia las credenciales de la cuenta cloud, deserialización insegura, exposición de datos y dependencias vulnerables. Has entendido el ransomware moderno como una operación de tres semanas cuyo desenlace lo deciden las copias inmutables, no el antivirus; los ataques a la cadena de suministro, donde todo parece legítimo; y los ataques a APIs, con el abuso de lógica de negocio que ninguna herramienta detecta. Y has reconstruido una cadena completa sobre Nimbus, comprobando que cinco de sus ocho eslabones se rompen con medidas que no cuestan dinero.

Falta el vector que encabeza casi todas las estadísticas y que no aparece en ninguna de las técnicas anteriores: la persona. En la siguiente lección, Ingeniería Social y Phishing (02-03), veremos por qué el factor humano es la vía dominante, qué principios de influencia explotan los atacantes, el catálogo completo de técnicas —del phishing masivo al fraude del CEO dirigido a Sara, el vishing, el quishing y el consent phishing—, cómo desmontar un correo malicioso indicador por indicador leyendo sus cabeceras, y las defensas técnicas y de proceso que lo contrarrestan, empezando por SPF, DKIM y DMARC.