Recursos incrustados y carga en memoria vistos en el informe

Los recursos incrustados de un ensamblado se guardan dentro del propio archivo y se leen por nombre desde el código. Es lo normal en cualquier programa: iconos de la ventana, traducciones, plantillas. La ficha estática los lista con su nombre, su tamaño y, si la herramienta lo calcula, su entropía.

Una entropía alta no acusa a nadie, porque una imagen comprimida también la tiene. Lo que llama la atención es el desajuste: un recurso que dice ser una imagen, que no empieza como empiezan las imágenes de ese tipo y que ningún visor abre.

En .NET un programa puede pedir al entorno que cargue un ensamblado a partir de un conjunto de bytes, en lugar de a partir de un archivo. En el decompilado se reconoce porque aparece la carga con un arreglo de bytes como argumento, normalmente cerca de la lectura de un recurso o de una descarga. Después, el programa busca dentro de lo cargado una clase y un método por su nombre escrito como texto, y lo invoca.

MITRE ATT&CK describe este comportamiento como Reflective Code Loading (T1620): cargar código directamente en la memoria del proceso en vez de ejecutarlo desde un archivo en disco. Aquí solo se reconoce en la salida; el detalle de cómo se transforman los bytes está omitido en el material y no hace falta para el informe.

El decompilado dice qué puede pasar; la corrida del entorno aislado dice qué pasó una vez. Cuando las dos coinciden en el orden de los hechos, la conclusión gana mucha fuerza. En el informe hay un evento de carga de ensamblado sin ruta en disco y, justo antes, una respuesta del servidor que encaja con el método que atiende órdenes en Sincronizador.

Si la segunda etapa nunca toca el disco, su huella SHA-256 no está en ningún equipo para buscarla, y un barrido de archivos no la encontrará. Lo que sí queda a la vista es el primer archivo con su recurso, la conexión al servidor y el comportamiento del proceso: un programa de turnos que carga un ensamblado sin ruta justo después de hablar con un dominio externo.

El informe que lee el SOC usa ATT&CK para describir conductas. Elegir la técnica correcta importa porque cada una arrastra sus propias detecciones: no es lo mismo describir una descarga que una carga en memoria o una ocultación de datos.