https://fennek.org/speculum/Recent content on Speculum VulpisHugoenhttps://fennek.org/speculum/p0-fundamentos/0-1-principios-seguridad/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p0-fundamentos/0-1-principios-seguridad/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.https://fennek.org/speculum/p0-fundamentos/0-2-redes/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p0-fundamentos/0-2-redes/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.https://fennek.org/speculum/p0-fundamentos/0-3-sistemas-operativos/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p0-fundamentos/0-3-sistemas-operativos/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.https://fennek.org/speculum/p0-fundamentos/0-4-criptografia/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p0-fundamentos/0-4-criptografia/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.https://fennek.org/speculum/p0-fundamentos/0-5-arquitectura-confianza/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p0-fundamentos/0-5-arquitectura-confianza/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.https://fennek.org/speculum/p0-fundamentos/0-6-sintesis/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p0-fundamentos/0-6-sintesis/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.https://fennek.org/speculum/p1-threat-intel/1-1-programa-inteligencia/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p1-threat-intel/1-1-programa-inteligencia/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.https://fennek.org/speculum/p1-threat-intel/1-2-coleccion-fuentes/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p1-threat-intel/1-2-coleccion-fuentes/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.https://fennek.org/speculum/p1-threat-intel/1-3-modelos-analisis/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p1-threat-intel/1-3-modelos-analisis/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&CK 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.https://fennek.org/speculum/p1-threat-intel/1-4-indicadores-diseminacion/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p1-threat-intel/1-4-indicadores-diseminacion/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.https://fennek.org/speculum/p1-threat-intel/1-5-cti-en-el-soc/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p1-threat-intel/1-5-cti-en-el-soc/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.https://fennek.org/speculum/p1-threat-intel/1-6-panorama-amenazas/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p1-threat-intel/1-6-panorama-amenazas/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.https://fennek.org/speculum/p2-recon-osint/2-1-metodologia-osint/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p2-recon-osint/2-1-metodologia-osint/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.https://fennek.org/speculum/p2-recon-osint/2-2-osint-identidad/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p2-recon-osint/2-2-osint-identidad/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.https://fennek.org/speculum/p2-recon-osint/2-3-osint-contenido/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p2-recon-osint/2-3-osint-contenido/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—.https://fennek.org/speculum/p2-recon-osint/2-4-osint-infraestructura/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p2-recon-osint/2-4-osint-infraestructura/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.https://fennek.org/speculum/p2-recon-osint/2-5-recon-ofensivo/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p2-recon-osint/2-5-recon-ofensivo/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).https://fennek.org/speculum/p2-recon-osint/2-6-leaks-breaches/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p2-recon-osint/2-6-leaks-breaches/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.https://fennek.org/speculum/p3-red-team/3-1-metodologia-pentest/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-1-metodologia-pentest/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.https://fennek.org/speculum/p3-red-team/3-2-web-inyeccion/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-2-web-inyeccion/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.https://fennek.org/speculum/p3-red-team/3-3-web-cliente/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-3-web-cliente/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.https://fennek.org/speculum/p3-red-team/3-4-web-auth-acceso/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-4-web-auth-acceso/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.https://fennek.org/speculum/p3-red-team/3-5-web-moderno/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-5-web-moderno/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.https://fennek.org/speculum/p3-red-team/3-6-stack-shellcode/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-6-stack-shellcode/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.https://fennek.org/speculum/p3-red-team/3-7-format-ret2libc-rop/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-7-format-ret2libc-rop/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.https://fennek.org/speculum/p3-red-team/3-8-exploit-dev-windows/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-8-exploit-dev-windows/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.https://fennek.org/speculum/p3-red-team/3-9-escalada-privilegios/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-9-escalada-privilegios/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.https://fennek.org/speculum/p3-red-team/3-10-c2-infraestructura/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-10-c2-infraestructura/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.https://fennek.org/speculum/p3-red-team/3-11-evasion-av-edr/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-11-evasion-av-edr/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.https://fennek.org/speculum/p3-red-team/3-12-estego-canales/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-12-estego-canales/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.https://fennek.org/speculum/p3-red-team/3-13-pivoting-tunneling/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-13-pivoting-tunneling/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.https://fennek.org/speculum/p3-red-team/3-14-persistencia-linux/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-14-persistencia-linux/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.https://fennek.org/speculum/p3-red-team/3-15-exploit-dev-linux-avanzado/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-15-exploit-dev-linux-avanzado/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.https://fennek.org/speculum/p3-red-team/3-16-contenedores-kubernetes/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-16-contenedores-kubernetes/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.https://fennek.org/speculum/p3-red-team/3-17-acceso-inicial-weaponizacion/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-17-acceso-inicial-weaponizacion/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).https://fennek.org/speculum/p3-red-team/3-18-post-explotacion-persistencia-windows/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-18-post-explotacion-persistencia-windows/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—.https://fennek.org/speculum/p3-red-team/3-19-cloud-red-team/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-19-cloud-red-team/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.https://fennek.org/speculum/p3-red-team/3-20-exploit-dev-heap/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-20-exploit-dev-heap/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.https://fennek.org/speculum/p3-red-team/3-21-exploit-dev-kernel/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p3-red-team/3-21-exploit-dev-kernel/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.https://fennek.org/speculum/p4-active-directory/4-1-recon-ad/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-1-recon-ad/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.https://fennek.org/speculum/p4-active-directory/4-2-kerberos/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-2-kerberos/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).https://fennek.org/speculum/p4-active-directory/4-3-ntlm-relay/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-3-ntlm-relay/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.https://fennek.org/speculum/p4-active-directory/4-4-adcs/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-4-adcs/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.https://fennek.org/speculum/p4-active-directory/4-5-credential-dumping/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-5-credential-dumping/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.https://fennek.org/speculum/p4-active-directory/4-6-delegacion-trusts/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-6-delegacion-trusts/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.https://fennek.org/speculum/p4-active-directory/4-7-acls-persistencia/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-7-acls-persistencia/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.https://fennek.org/speculum/p4-active-directory/4-8-movimiento-lateral/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-8-movimiento-lateral/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.https://fennek.org/speculum/p4-active-directory/4-9-defensa-ad/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p4-active-directory/4-9-defensa-ad/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—.https://fennek.org/speculum/p5-blue-dfir/5-1-deteccion-hunting/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-1-deteccion-hunting/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).https://fennek.org/speculum/p5-blue-dfir/5-2-telemetria-siem/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-2-telemetria-siem/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.https://fennek.org/speculum/p5-blue-dfir/5-3-identidad-correo/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-3-identidad-correo/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).https://fennek.org/speculum/p5-blue-dfir/5-4-respuesta-incidentes/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-4-respuesta-incidentes/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.https://fennek.org/speculum/p5-blue-dfir/5-5-forense-memoria/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-5-forense-memoria/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.https://fennek.org/speculum/p5-blue-dfir/5-6-siem-lateral/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-6-siem-lateral/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.https://fennek.org/speculum/p5-blue-dfir/5-7-caza-c2/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-7-caza-c2/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.https://fennek.org/speculum/p5-blue-dfir/5-8-deteccion-evasion/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-8-deteccion-evasion/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.https://fennek.org/speculum/p5-blue-dfir/5-9-deteccion-exfil-estego/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-9-deteccion-exfil-estego/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.https://fennek.org/speculum/p5-blue-dfir/5-10-deteccion-persistencia-linux/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-10-deteccion-persistencia-linux/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.https://fennek.org/speculum/p5-blue-dfir/5-11-deteccion-runtime-contenedores/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-11-deteccion-runtime-contenedores/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.https://fennek.org/speculum/p5-blue-dfir/5-12-deteccion-rootkits/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p5-blue-dfir/5-12-deteccion-rootkits/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.https://fennek.org/speculum/p6-purple/6-1-funcion-validacion/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p6-purple/6-1-funcion-validacion/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.https://fennek.org/speculum/p6-purple/6-2-emulacion-adversario/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p6-purple/6-2-emulacion-adversario/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.https://fennek.org/speculum/p6-purple/6-3-ejercicio-purple/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p6-purple/6-3-ejercicio-purple/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.https://fennek.org/speculum/p6-purple/6-4-tabletop-crisis/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p6-purple/6-4-tabletop-crisis/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.https://fennek.org/speculum/p6-purple/6-5-gestion-exposicion/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p6-purple/6-5-gestion-exposicion/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.https://fennek.org/speculum/p7-gobernanza/7-1-marco-gobernanza/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p7-gobernanza/7-1-marco-gobernanza/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.https://fennek.org/speculum/p7-gobernanza/7-2-riesgo-politica-cscrm/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p7-gobernanza/7-2-riesgo-politica-cscrm/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.https://fennek.org/speculum/p7-gobernanza/7-3-programa-insider/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p7-gobernanza/7-3-programa-insider/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.https://fennek.org/speculum/p7-gobernanza/7-4-controles-insider/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p7-gobernanza/7-4-controles-insider/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.https://fennek.org/speculum/p8-factor-humano/8-1-factor-humano/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p8-factor-humano/8-1-factor-humano/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.https://fennek.org/speculum/p8-factor-humano/8-2-armas-influencia/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p8-factor-humano/8-2-armas-influencia/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.https://fennek.org/speculum/p8-factor-humano/8-3-ingenieria-social/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p8-factor-humano/8-3-ingenieria-social/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.https://fennek.org/speculum/p8-factor-humano/8-4-control-coercitivo/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p8-factor-humano/8-4-control-coercitivo/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.https://fennek.org/speculum/p8-factor-humano/8-5-desinformacion-psyop/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p8-factor-humano/8-5-desinformacion-psyop/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.https://fennek.org/speculum/p8-factor-humano/8-6-defensa-cognitiva/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p8-factor-humano/8-6-defensa-cognitiva/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.https://fennek.org/speculum/p9-ia-seguridad/9-1-ia-cambio-superficie/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p9-ia-seguridad/9-1-ia-cambio-superficie/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).https://fennek.org/speculum/p9-ia-seguridad/9-2-ia-defensiva-soc/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p9-ia-seguridad/9-2-ia-defensiva-soc/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.https://fennek.org/speculum/p9-ia-seguridad/9-3-ia-ofensiva/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p9-ia-seguridad/9-3-ia-ofensiva/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.https://fennek.org/speculum/p9-ia-seguridad/9-4-seguridad-de-la-ia/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/p9-ia-seguridad/9-4-seguridad-de-la-ia/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.https://fennek.org/speculum/buscar/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/buscar/https://fennek.org/speculum/synapsis/Mon, 01 Jan 0001 00:00:00 +0000https://fennek.org/speculum/synapsis/