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.

La 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.

De 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.

flowchart TD
    A["Muestra sospechosa"] --> B["Estático
YARA · PE headers · imports · strings"]
    B --> C{"¿Empaquetada?"}
    C -->|no| D["Dinámico
detonación en sandbox"]
    C -->|sí| E["Unpacking
BP en VirtualAlloc · dump de memoria
reconstruir IAT (impscan)"]
    E --> D
    D --> F["Observación
ProcMon · Regshot · Autoruns · FakeNet"]
    F --> G["IOCs
hash · dominio · ruta · clave Run"]
    F --> H["IOAs
comportamiento: cadena de procesos,
persistencia, patrón de red"]
    C -->|"virtualizada /
flujo aplanado"| I["Reversing profundo
módulos de procesador IDA · MIASM
(caro, no escala)"]
    I --> H
    G --> J["Reglas de detección"]
    H --> J
    J --> 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.

La 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.

La 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.

Y 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.

Un 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.

Las 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.

El 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.

Aná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.

La instrumentación mínima cubre cuatro planos y se ejecuta con privilegios administrativos antes de detonar:

  • Actividad 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: aquí está el truco central. Herramientas como FakeNet-NG o INetSim emulan internet entera dentro del laboratorio: responden a las consultas DNS, aceptan las conexiones HTTP y HTTPS, sirven respuestas plausibles. El malware cree que alcanzó su servidor, resuelve su dominio, se registra y hasta intenta exfiltrar, y el analista captura todo en un PCAP sin que un solo paquete salga del entorno.

El caso Kenora.exe recorre la cadena completa y muestra el producto. Tras diez minutos de ejecución, el segundo disparo de Regshot revela una entrada nueva en la clave Run apuntando a un binario secundario depositado en C:\ProgramData\Synaptics\Synaptics.exe —el nombre imita un controlador legítimo de panel táctil, que es precisamente el hiding in plain sight de 5.2—. ProcMon confirma los comandos de descubrimiento del sistema. FakeNet intercepta las consultas DNS hacia un dominio de DNS dinámico y captura los datos que la muestra intenta enviar. Autoruns resalta la entrada de arranque no firmada. Y al terminar, se revierte al snapshot.

El resultado de todo esto son dos productos que conviene no confundir. Los IOC (indicators of compromise) son artefactos concretos: el hash, el dominio, la IP, la ruta del archivo secundario, la clave de registro. Se despliegan de inmediato como búsqueda retrospectiva y como bloqueo —el dominio va a la lista del proxy, y ahí engancha con 5.7—, y caducan rápido, porque el adversario los cambia sin esfuerzo. Los IOA (indicators of attack) son afirmaciones sobre comportamiento: «un proceso que escribe un ejecutable en ProgramData y acto seguido crea una entrada en Run apuntando a él». Cuestan más de construir, sobreviven al recompilado y son los que suben por la pirámide del dolor de 5.1. Un análisis que solo produce IOC hizo la mitad del trabajo.

Anti-VM: la comprobación que el defensor debe romper#

Vale detenerse en cómo el malware decide que está siendo analizado, porque determina cómo se endurece el laboratorio. Las comprobaciones burdas —buscar el proceso vmtoolsd.exe, mirar direcciones MAC del rango del hipervisor, consultar puertos de E/S característicos— son conocidas y se neutralizan con el hardening descrito. Las interesantes usan WMI, la infraestructura nativa de administración de Windows, para preguntarle al sistema por sí mismo.

La consulta directa instancia Win32_BIOS y lee sus propiedades. La divergencia es inmediata: un equipo físico reporta un fabricante como Dell Inc., mientras que la máquina virtual reporta Phoenix Technologies LTD y un número de serie con el prefijo VMware-. Es fácil de detectar y también relativamente fácil de falsear.

La variante elegante no busca una firma sino una ausencia. La clase Win32_TemperatureProbe expone los sensores térmicos del hardware. En un equipo físico, consultar su estado devuelve OK. En una máquina virtual el arreglo vuelve vacío, porque los hipervisores no exponen sensores térmicos al invitado, y cualquier lectura directa lanza una excepción de referencia nula. Envolviendo la consulta en un bloque try/catch, el malware deduce que está en una VM sin comparar ninguna firma: le basta con que la pregunta falle. Es un buen ejemplo de por qué la carrera de firmas no se gana —la comprobación no busca nada que se pueda renombrar, busca una propiedad estructural del entorno—.

La contramedida obliga a intervenir el proveedor WMI (CIMWin32) para que la clase térmica devuelva objetos simulados con sus propiedades obligatorias, Status y CurrentReading. La lección de arquitectura es la que importa: emular un sistema genérico es insuficiente; un laboratorio serio simula propiedades de hardware creíbles, y esa simulación hay que mantenerla porque las comprobaciones evolucionan.

Unpacking: el momento en que la carga se muestra#

Cuando hace falta el binario real —para escribir una regla YARA sólida, para entender el algoritmo, para atribuir— hay que desempaquetar. Y aquí reaparece el principio del capítulo en su forma más nítida: el empaquetado protege el archivo en reposo, pero el código tiene que existir en claro en memoria para ejecutarse.

La técnica clásica se apoya en eso. El binario empaquetado necesita reservar memoria donde escribir su carga descifrada, y para eso llama a la API del sistema: VirtualAlloc, HeapCreate y compañía. Poniendo un punto de interrupción en esas funciones dentro de un depurador, la ejecución se detiene exactamente cuando la memoria fue reservada y —tras dejar correr un poco más— cuando ya contiene el código descifrado, justo antes de que el control se transfiera a él. Ahí se vuelca a disco.

El proceso se automatiza bien. El caso documentado escribe un script para x64dbg que limpia los puntos de interrupción previos, coloca uno sobre VirtualAlloc, valida en el registro eax que la reserva tuvo éxito, escanea el búfer buscando la firma hexadecimal 546869732070726F6772616D —los bytes de la cadena This program, el comienzo del mensaje de modo DOS presente en todo ejecutable de Windows— y, al encontrarla, vuelca la región con savedata. Es un buen ejemplo de que gran parte del unpacking convencional es mecánico: los empaquetadores comerciales conocidos se desarman con rutinas repetibles.

La alternativa cuando el empaquetador es propietario y el depurador se complica es el forense de memoria, que es literalmente el capítulo 5.5 aplicado a esto. Con Volatility se vuelca el proceso completo con procdump —usando el modificador que preserva los espacios vacíos— y se reconstruye la tabla de importaciones con el plugin impscan, corrigiendo el campo ImageAddress para que el binario resultante sea analizable. Es el mismo movimiento que 5.5 describió con malfind para localizar las regiones RWX sin archivo de respaldo: el disco dice lo que el malware dejó; la memoria dice lo que el malware es. Y es el mismo principio que 5.2 señaló con el registro de bloques de script, que captura PowerShell ya desofuscado justo antes de su evaluación. Tres capítulos distintos, un solo argumento: la ofuscación tiene que deshacerse en algún punto, y ese punto es observable.

Antes del binario: el documento como portador#

Todo lo anterior asume que la muestra es un ejecutable, pero el artefacto que el SOC recibe primero casi nunca lo es. Lo que llega adjunto al correo de phishing —el vector que el acceso inicial (3.17) armó y que el triaje de correo (5.3) intercepta— es un documento o un script: un PDF, un .docx con macros, un .js o un .hta. Es la etapa cero, el dropper que descarga o desata el binario que ocupa el resto del capítulo. Y es la ilustración más pura de la tesis de 3.11 y de este capítulo: un script ofuscado tiene que desofuscarse para ejecutar, igual que un binario empaquetado tiene que descomprimirse. El principio del unpacking reaparece un nivel más arriba, sobre texto en vez de código máquina, y las herramientas cambian pero el movimiento es el mismo —dejar que la muestra haga el trabajo de desofuscación y observar el resultado—.

flowchart TD
    A["Adjunto de phishing"] --> B{"¿Qué portador?"}
    B -->|"script"| C["JS/VBScript/HTA
box-js · SpiderMonkey
eval → print"]
    B -->|"PDF"| D["pdfid (triage /JS /OpenAction)
pdf-parser -f (FlateDecode)"]
    B -->|"Office/RTF"| E["OLE2 · macros VBA
oledump · olevba
xor-kpa (clave XOR)"]
    C --> F["Shellcode / URL de 2ª etapa"]
    D --> F
    E --> F
    F --> G["scdbg
emular → API calls → C2/descarga"]
    G --> H["IOC: dominio · hash de 2ª etapa"]
    G --> I["IOA: lector/Office → intérprete
(la arista padre-hijo de 5.2)"]

Scripts (JavaScript, VBScript, HTA). El atacante ofusca el script para esconder dominios, rutas y la rutina de ejecución, casi siempre detrás de eval. El análisis no consiste en leerlo —puede ser ilegible a propósito— sino en hacer que se imprima en lugar de ejecutarse. Intérpretes aislados como SpiderMonkey o el emulador box-js corren el script fuera del navegador entregándole objetos falsificados —un document, un window simulados— y redefiniendo las funciones peligrosas: se reasignan eval y document.write a la función print. El script, convencido de que corre en un navegador, se desenrolla solo y, en vez de detonar, vuelca su código limpio en la consola con el dominio de explotación a la vista. Es el mismo movimiento que el punto de interrupción sobre VirtualAlloc de la sección anterior, trasladado del código máquina al texto.

PDF. Un PDF malicioso encapsula el exploit o la acción de inyección en objetos indirectos y streams de datos comprimidos con filtros como /FlateDecode, y se dispara con acciones de ejecución automática —/OpenAction, /JS, /JavaScript—. El triaje empieza con pdfid, que cuenta esas palabras clave: un número anómalo de referencias /JS en un documento que debería ser texto es la primera señal. Luego pdf-parser —de la suite de Didier Stevens— rastrea el objeto de entrada, vuelca su stream y, con el modificador que revierte el /FlateDecode, recupera el JavaScript incrustado, que a menudo porta un largo arreglo hexadecimal: el shellcode de la siguiente etapa.

Office y RTF (macros VBA). Los documentos de Office son droppers que incrustan código VBA dentro del formato contenedor OLE2 (Object Linking and Embedding, el sistema de archivos-dentro-de-archivo de Microsoft, donde cada stream es como un fichero individual). oledump u olevba enumeran esos streams y marcan con una bandera los que contienen macros funcionales; extraído el código, suele estar ofuscado con un XOR de un solo byte sobre las rutas y comandos —una clave débil que se rompe con un ataque de texto claro conocido (xor-kpa), aprovechando que todo comando de instalación contiene cadenas predecibles—. La macro, ya en claro, casi siempre termina invocando PowerShell o WMI de forma silenciosa: el puente hacia el binario de segunda etapa.

El shellcode embebido. El eslabón final de la cadena documental es un bloque de ensamblador position- independent sin dependencias formales. En vez de desensamblarlo a mano, se vuelca y se alimenta a scdbg, un emulador ligero que simula un entorno Windows y rastrea las llamadas a la API que el shellcode ejecuta —incluida la caminata sobre el PEB (Process Environment Block) con que resuelve kernel32.dll al vuelo—, revelando la conexión saliente y la descarga sin ingeniería inversa tediosa. Es el mismo shellcode que reaparece en la inyección de procesos: cuando el dropper lo escribe en un proceso legítimo, deja la tríada de API VirtualAllocEx → WriteProcessMemory → CreateRemoteThread (o el process hollowing, que lanza un proceso del sistema suspendido y le vacía la memoria antes de rellenarla), cuya detección en memoria es exactamente el forense de 5.5 —malfind sobre la región RWX sin archivo de respaldo—.

Lo que este análisis produce para la defensa cierra el círculo del capítulo. El documento portador tiene un propósito estructural inevitable: lanzar un intérprete. Un lector de PDF o un proceso de Office que engendra powershell.exe, wscript.exe, cscript.exe o mshta.exe es precisamente la arista padre-hijo que 5.2 desarrolló y que la cuarta prueba de sensores de más arriba encontró que nadie estaba correlacionando. El análisis del maldoc no solo produce los IOC de la segunda etapa —el dominio, el hash—, sino que dice qué aristas padre-hijo merecen una alerta de alta fidelidad, y habilita firmas YARA o Snort sobre los streams maliciosos. Es triaje de etapa cero: barato, seguro —estático, sin detonar la cadena completa— y escalable, lo contrario del reversing profundo con que sigue la próxima sección.

El límite honesto: cuando el análisis deja de escalar#

Sería deshonesto terminar la sección anterior sin decir dónde se rompe. Existe una clase de protección contra la cual el unpacking no funciona, porque no hay un momento en que la carga original aparezca en memoria: el código nunca se restaura, se traduce.

El aplanamiento del flujo de control (control flow flattening) destruye la estructura del programa. En lugar de bucles y condicionales anidados, el código se parte en bloques básicos puestos todos al mismo nivel bajo un despachador: una sentencia switch gobernada por una variable de estado que cada bloque recalcula al terminar, indicando cuál sigue. El resultado, generable con un compilador ofuscador mediante una sola opción, es un ensamblado sin ninguna construcción de bucle reconocible —la lógica sigue ahí, pero el grafo que la representaba desapareció—. Se combina con predicados opacos, saltos condicionales cuya evaluación es constante y conocida de antemano (son saltos incondicionales disfrazados de ramificación, que inflan la complejidad del grafo con caminos falsos), y con constant unfolding, que sustituye cada valor literal por una secuencia de operaciones aritméticas que lo produce.

La virtualización de instrucciones va más lejos. El protector define una arquitectura propia y traduce el código nativo a bytecode de esa máquina inventada. Lo que queda en el binario es un intérprete: un bloque de inicialización que hace un cambio de contexto —guarda el estado de los registros y banderas reales en una estructura de registros virtuales— y luego un ciclo cerrado de obtener, decodificar y delegar, que lee el bytecode, lo decodifica con reglas propietarias y busca el manejador correspondiente en una tabla de punteros a función cifrada. Nunca hay código x86 original que volcar, porque el original ya no existe en el binario.

La respuesta es cara y ese es el punto. Se ataca desarrollando módulos de procesador para el desensamblador —código propio que enseña a la herramienta a decodificar ese conjunto de instrucciones virtual y reconstruir el grafo— o con motores de análisis simbólico y ejecución rastreada, combinados. Es trabajo de días o semanas por familia, hecho por especialistas.

Y de ahí sale la conclusión operativa, que es incómoda pero clarificadora: el reversing profundo no es una estrategia de detección, es una capacidad de investigación. No escala a los miles de muestras que ve una organización, y el adversario lo sabe. Lo que sí escala es lo otro —el comportamiento en ejecución—, porque el código virtualizado, cuando finalmente corre, sigue teniendo que crear procesos, escribir su persistencia y abrir su canal de red. La protección más sofisticada del binario no cambia en nada lo que el implante hace una vez activo.

El segundo movimiento: medir el sensor propio#

Todo lo anterior asume que la detección, una vez escrita, funciona. La parte más valiosa de este capítulo cuestiona ese supuesto, y lo hace con evidencia: cuatro evaluaciones documentadas de sensores comerciales de endpoint, ejecutadas con mentalidad ofensiva contra el propio entorno. Los resultados no son un ataque a ningún producto —cualquier sensor daría resultados análogos— sino un argumento sobre la necesidad del método.

Primera prueba: el formato contenedor como punto ciego. Se descargan 586 muestras conocidas de un repositorio público a un Windows 10 con un sensor de nueva generación en política agresiva. Descargar, descomprimir y mover los archivos no genera ninguna alerta: el producto no hace análisis estático en disco, opera solo por aprendizaje automático y comportamiento en tiempo de ejecución. Al ejecutar, sí bloquea los ejecutables portátiles. Pero un instalador MSI disfrazado de conversor a PDF pasa: msiexec.exe es un binario legítimo del sistema, la instalación parece una instalación, y el troyano bancario que trae se despliega sin alerta.

Segunda prueba: la latencia como ventana operativa. Con otro sensor, un script en Python descarga y extrae el lote diario completo de muestras. La primera detección llega a las 09:58 y la última a las 15:53: casi cuatro horas de brecha durante las cuales 47 binarios maliciosos permanecen en disco sin bloquear. En una repetición posterior la demora es de veinte a treinta minutos, y cinco muestras conocidas evaden permanentemente todos los motores. Una detección que llega cuatro horas tarde no es una detección tardía: es una no-detección para cualquier ataque que se ejecute en el ínterin.

Tercera prueba: los falsos negativos sobreviven al escaneo bajo demanda. Con un tercer producto y 42 muestras de un repositorio de investigación, la descarga de los archivos comprimidos no se bloquea; al extraer, la mayoría sí se detecta pero cuatro se salvan; y cuando se fuerza un escaneo completo del sistema desde la consola —donde el motor tiene todo el tiempo y todo el archivo—, las mismas cuatro siguen sin detectarse. Los formatos son reveladores: un script de VBScript, un binario de macOS, un inyector y un exploit en Java. La diversidad de formatos expone los sesgos del motor.

Cuarta prueba: la cadena de LOLBins no se correlaciona. Un script en Python abre una conexión inversa por un puerto no estándar hacia una IP externa, ejecutando cmd.exe con su entrada y salida enlazadas al socket; el sensor no intercepta ni la conexión ni la ejecución. Desde esa consola remota, Invoke-WebRequest descarga un archivo desde un túnel efímero, sin alerta. El archivo es un VBScript que wscript.exe interpreta, y que a su vez lanza powershell.exe con la carga procesada en memoria mediante Invoke-Expression. Ninguna pieza es maliciosa por sí misma —Python, wscript, PowerShell son todos legítimos— y el motor de comportamiento clasifica cada eslabón como tarea administrativa válida. Lo que falta es la correlación entre padre e hijo: la relación wscript.exe → powershell.exe, con argumentos -nop, -w hidden y -enc, es la firma de comportamiento que 5.2 desarrolló y que aquí nadie está evaluando.

La conclusión transversal de las cuatro pruebas es que existe una brecha sistemática entre el disco y el runtime. Los sensores modernos apuestan casi todo a la ejecución, lo que los vuelve eficaces contra la detonación directa de un ejecutable y ciegos ante todo lo que ocurre antes: archivos en reposo, formatos contenedor (ZIP, MSI, ISO), binarios de otras plataformas. El adversario que entrega su carga dentro de un contenedor y la ejecuta a través de un binario legítimo del sistema atraviesa las dos brechas a la vez. Ninguna hoja de producto menciona esto; solo aparece midiendo.

El método que se desprende es sencillo y debería ser rutina: probar el sensor propio por fases —entrega, escritura en disco, manipulación, escaneo bajo demanda, ejecución— con muestras catalogadas de repositorios de investigación, en un entorno controlado y con autorización explícita. El producto no es un veredicto sobre el proveedor sino un número accionable: la tasa real de falsos negativos y la latencia real de bloqueo del entorno propio, que definen exactamente la ventana de exposición y, sobre todo, dicen qué hay que compensar con reglas de correlación en el SIEM. Es ingeniería de detección en el sentido de 5.1: la regla no está terminada cuando se escribe, sino cuando se verificó que dispara. La misma lógica sostiene los ejercicios de simulación de incidentes —con inyecciones que fuerzan al equipo a operar sin la telemetría que daba por sentada—, que son la versión organizativa de esta misma validación.

La otra cara: el falso positivo heredado#

Medir el sensor tiene un reverso necesario, porque el error de detección va en dos direcciones y la segunda hace tanto daño como la primera.

El caso documentado empieza como un incidente de manual: la plataforma de endpoint agrupa alertas de conexiones desde 49 máquinas y 27 usuarios hacia un mismo dominio externo, clasificado por el proveedor como infraestructura de comando y control. El volumen es precisamente lo que 5.1 llamaría un buen indicador de ataque: muchos hosts distintos hablando con un único destino. El equipo azul inicia la cacería, aísla el caso y somete la URL a análisis en entornos controlados y en servicios de sandboxing, que la clasifican como inocua. Al escalar, el proveedor admite que su motor heredó una mala clasificación de un servicio público de reputación y que el tráfico corresponde a una plataforma de telemetría publicitaria. El dominio se excluye.

Hay dos lecciones y ambas importan. La primera es sobre la cadena de confianza de la inteligencia: la reputación de terceros se propaga entre productos, y un error en el origen se convierte en un incidente crítico en decenas de organizaciones sin que ningún analista haya evaluado nada. Es el matiz que faltaba en la sección de reputación de dominios de 5.7 —la reputación es una señal útil, no un veredicto—. La segunda es que el hunting sirve tanto para confirmar como para refutar: el trabajo que descartó esta alerta es idéntico en método al que confirma una real, y hacerlo bien evita que 49 equipos entren en un flujo de respuesta injustificado. La fatiga de alertas contra la que advirtió 5.1 no se combate solo bajando el volumen de reglas propias; también hay que auditar las que llegan de afuera.

Postura: del artefacto al comportamiento#

Lo accionable, ordenado:

  • Un laboratorio propio, aislado y endurecido, con snapshots y red simulada, para lo que no puede subirse a un servicio público. Verificarlo periódicamente contra una muestra anti-VM de control.
  • Analizar para producir IOA, no solo IOC. El hash y el dominio se despliegan hoy y caducan mañana; la regla de comportamiento —cadena de procesos, punto de persistencia, patrón de red— sobrevive al recompilado.
  • Cerrar la brecha disco-runtime con correlación: inspección de formatos contenedor, y reglas en el SIEM para lo que el EDR no correlaciona —msiexec ejecutando desde rutas de descarga, wscript/cscript lanzando PowerShell, intérpretes que escriben ejecutables o abren conexiones salientes—. Son exactamente las señales que 5.2 y 5.6 dejaron disponibles.
  • Medir el sensor propio por fases, con periodicidad, y traducir el resultado en reglas compensatorias. Sin esta medición, la cobertura declarada es una hipótesis.
  • Auditar la inteligencia recibida con la misma severidad que la propia: una alerta de reputación de terceros es el comienzo de una investigación, no su conclusión.
  • Reservar el reversing profundo para lo que lo justifica —una familia recurrente, una campaña dirigida— y apoyarse en el resto del tiempo en el comportamiento, que es lo que la evasión no puede eliminar.

Con esto quedan cerrados la evasión de AV y EDR de 3.11 —cuya conclusión, vista desde acá, es que gana la batalla de la firma y pierde la del comportamiento— y el análisis de los infostealers de 2.6, cuyas muestras se desarman con exactamente esta cadena. Quedan dos capítulos para cerrar P5: la detección de exfiltración y el estegoanálisis (5.9) y las dos superficies pendientes, Linux y contenedores.

Referencias#

  • blue-dfir/effective-threat-investigation/cap-15 — construcción de un sandbox local: aislamiento host-only, hardening anti-VM del invitado, análisis estático (YARA, inspectores de PE), análisis dinámico (ProcMon, Regshot, Autoruns, FakeNet), extracción de IOCs y reversión a snapshot.
  • blue-dfir/for610/cap-03 — análisis de documentos y scripts maliciosos como artefacto de acceso inicial: desofuscación de JavaScript/VBScript con SpiderMonkey y box-js (eval→print), triaje de PDF con pdfid y volcado de streams con pdf-parser (/OpenAction, /JS, /FlateDecode), extracción de macros VBA de contenedores OLE2 con oledump/olevba y ruptura del XOR de un byte con xor-kpa, emulación de shellcode embebido con scdbg.
  • blue-dfir/for610/cap-04 — shellcode e inyección: la tríada VirtualAllocEx/WriteProcessMemory/ CreateRemoteThread, process hollowing, y la caminata sobre el PEB con que el shellcode resuelve kernel32.dll.
  • blue-dfir/modern-malware-obfuscation/cap-01 — unpacking convencional: puntos de interrupción sobre VirtualAlloc, volcado desde memoria, automatización en x64dbg, procdump e impscan en Volatility para reconstruir la tabla de importaciones.
  • blue-dfir/modern-malware-obfuscation/cap-02 — anti-reversing: control flow flattening, despachador y variable de estado, virtualización de instrucciones (ciclo obtener-decodificar-delegar), predicados opacos, constant unfolding, módulos de procesador para IDA.
  • blue-dfir/modern-malware-obfuscation/cap-08 — anti-VM por WMI: Win32_BIOS y Win32_TemperatureProbe, la ausencia de sensores térmicos como detector de hipervisor, parcheo del proveedor CIMWin32; herramientas de desofuscación simbólica.
  • blue-dfir/pt0721-threat-hunting/cap-02 — evasión por paquete MSI y despliegue de un troyano bancario sin alerta.
  • blue-dfir/pt0721-threat-hunting/cap-03 — descarga masiva por intérprete de scripting y brecha de casi cuatro horas hasta la detección.
  • blue-dfir/pt0721-threat-hunting/cap-04 — metodología de prueba de eficacia por fases y falsos negativos que sobreviven al escaneo bajo demanda.
  • blue-dfir/pt0721-threat-hunting/cap-05 — reverse shell, cadena wscript.exe → powershell.exe en memoria y ausencia de correlación padre-hijo.
  • blue-dfir/pt0721-threat-hunting/cap-08 — latencia y omisiones del sensor; falso positivo heredado de una clasificación de reputación de terceros, refutado por hunting.
  • blue-dfir/greenbook/cap-01 — laboratorio de experimentación, análisis estático y dinámico, y validación de la respuesta mediante ejercicios de simulación.
  • MITRE ATT&CK — T1027 (Obfuscated Files or Information) y .002 (Software Packing); T1497 (Virtualization/ Sandbox Evasion) y .001 (System Checks); T1218 (System Binary Proxy Execution) y .007 (Msiexec); T1059 (Command and Scripting Interpreter) .001 (PowerShell) y .005 (Visual Basic); T1562.001 (Disable or Modify Tools); T1620 (Reflective Code Loading). Mitigaciones M1040 (Behavior Prevention on Endpoint), M1038 (Execution Prevention), M1049 (Antivirus/Antimalware), M1042 (Disable or Remove Feature).