En el primer artículo de este serial de varias partes, los investigadores de malware del equipo de Elastic Security Labs brindan una breve introducción sobre la amenaza REMCOS y se sumergen en la primera mitad de su flujo de ejecución, desde la carga de su configuración hasta la limpieza de los navegadores sitio web de las máquinas infectadas.
Introducción
Elastic Security Labs continúa su examen de las amenazas de alto impacto, centrar en las complejidades internas de la versión 4.9.3 de REMCOS Pro ( 26de noviembre de 2023).
Desarrollado por Breaking-Security, REMCOS es un software que comenzó su vida como una herramienta de equipo rojo, pero que desde entonces fue adoptado por amenazas de todo tipo dirigidas a prácticamente todos los sectores.
Cuando realizamos nuestro análisis a mediados de enero, era la familia de malware más frecuente reportada por ANY. CORRE. Además, sigue en desarrollo activo, como lo demuestra el reciente anuncio del lanzamiento de la versión 4.9.4 por parte de la compañía el 9de marzo de 2024.
Todas las muestras que analizamos se derivaron del mismo REMCOS 4.9.3 Construcción Pro x86. El software está codificado en C++ con un uso intensivo de la clase std::string para sus operaciones relacionadas con cadenas y bytes.
REMCOS está repleto de una amplia gama de funcionalidades, que incluyen técnicas de evasión, escalada de privilegios, inyección de procesos, capacidades de grabación, etc.
Este serial de artículos proporciona un análisis extenso de lo siguiente:
- Ejecución y capacidades
- Estrategias de detección y búsqueda con ES|Consultas de QL
- Recuperación de aproximadamente el 80% de sus campos de configuración
- Recuperación de aproximadamente el 90% de sus comandos C2
- Direcciones virtuales de muestra en cada captura de pantalla de IDA Pro
- ¡Y más!
Si tienes alguna pregunta o comentario, no dudes en ponerte en contacto con nosotros en las redes sociales @elasticseclabs o en el Slack de la comunidad de Elastic.
Cargando la configuración
La configuración de REMCOS se almacena en un blob cifrado dentro de un recurso denominado SETTINGS. Este nombre parece consistente en las diferentes versiones de REMCOS.
El malware comienza cargando el blob de configuración cifrado desde su sección de recursos.
Para cargar la configuración cifrada, usamos el siguiente script de Python y el módulo Lief .
import lief
def read_encrypted_configuration(path: pathlib.Path) -> bytes | None:
if not (pe := lief.parse(path)):
return None
for first_level_child in pe.resources.childs:
if first_level_child.id != 10:
continue
for second_level_child in first_level_child.childs:
if second_level_child.name == "SETTINGS":
return bytes(second_level_child.childs[0].content)
Podemos confirmar que la versión 4.9.3 mantiene la misma estructura y esquema de descifrado que los descritos anteriormente por los investigadores de Fortinet:
Nos referimos a la "configuración cifrada" como la estructura que contiene la clave de descifrado y el blob de datos cifrados, que aparece de la siguiente manera:
struct ctf::EncryptedConfiguration
{
uint8_t key_size;
uint8_t key[key_size];
uint8_t data
};
La configuración aún se descifra mediante el algoritmo RC4, como se ve en la siguiente captura de pantalla.
Para descifrar la configuración, empleamos el siguiente algoritmo.
def decrypt_encrypted_configuration(
encrypted_configuration: bytes,
) -> tuple[bytes, bytes]:
key_size = int.from_bytes(encrypted_configuration[:1], "little")
key = encrypted_configuration[1 : 1 + key_size]
return key, ARC4.ARC4Cipher(key).decrypt(encrypted_configuration[key_size + 1 :])
La configuración se usa para inicializar un vector global que llamamos g_configuration_vector dividiéndolo con la cadena \x7c\x1f\x1e\x1e\x7c como delimitador.
Proporcionamos una explicación detallada de la configuración más adelante en este serial.
UAC Bypass
Cuando el enable_uac_bypass_flag (índice 0x2e) está habilitado en la configuración, REMCOS intenta una omisión de UAC mediante una técnica conocida basada en COM.
De antemano, el REMCOS enmascara su proceso en un esfuerzo por evitar la detección.
REMCOS modifica la estructura PEB del proceso actual reemplazando la ruta de la imagen y la línea de comandos con la cadena explorer.exe mientras almacena la información original en variables globales para su uso posterior.
La técnica conocida aprovecha la API de CoGetObject para pasar el moniker Elevation:Administrator!new: , junto con el CLSID CMSTPLUA y ICMLuaUtil IID, para crear una instancia de una interfaz COM con privilegios elevados. A continuación, REMCOS emplea el método ShellExec() de la interfaz para iniciar un nuevo proceso con privilegios de administrador y salir.
Esta técnica se documentó previamente en un artículo de Elastic Security Labs de 2023: Exploración de omisiones de UAC de Windows: técnicas y estrategias de detección.
A continuación se muestra una captura de pantalla reciente de la detección de este exploit mediante el agente de Elastic Defend.
Desactivación de UAC
Cuando el disable_uac_flag está habilitado en la configuración (índice 0x27), REMCOS deshabilita UAC en el Registro estableciendo el valor HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\SystemEnableLUA en 0 mediante el reg.exe binario de Windows".
Instalación y persistencia
Cuando enable_install_flag (índice 0x3) se activa en la configuración, REMCOS se instalará en el equipo host.
La ruta de instalación se construye empleando los siguientes valores de configuración:
install_parent_directory(índice0x9)install_directory(0x30)install_filename(0xA)
El binario de malware se copia en {install_parent_directory}/{install_directory}/{install_filename}. En este ejemplo, es %ProgramData%\Remcos\remcos.exe.
Si el enable_persistence_directory_and_binary_hiding_flag (índice 0xC) está habilitado en la configuración, la carpeta de instalación y el binario de malware se establecen en superocultos (incluso si el usuario habilita la visualización de archivos o carpetas ocultos, Windows mantiene oculto el archivo para proteger los archivos con atributos del sistema) y de solo lectura aplicándoles atributos de solo lectura, ocultos y del sistema.
Luego de la instalación, REMCOS establece la persistencia en el registro en función de cuál de las siguientes marcas esté habilitada en la configuración:
enable_hkcu_run_persistence_flag(índice0x4)HKCU\Software\Microsoft\Windows\CurrentVersion\Run\enable_hklm_run_persistence_flag(índice0x5)HKLM\Software\Microsoft\Windows\CurrentVersion\Run\enable_hklm_policies_explorer_run_flag(índice0x8)HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\
Luego, el malware se resetear desde la carpeta de instalación usando ShellExecuteW, seguido de la finalización del proceso inicial.
Inyección de proceso
Cuando el enable_process_injection_flag (índice 0xD) está habilitado en la configuración, REMCOS se inyecta en un proceso especificado o de Windows elegido de una lista codificada de forma rígida para evadir la detección.
El enable_process_injection_flag puede ser un booleano o el nombre de un proceso de destino. Cuando se establece en true (1), el proceso inyectado se elige de la manera de "mejor esfuerzo" entre las siguientes opciones:
iexplorer.exeieinstal.exeielowutil.exe
Nota: solo hay un método de inyección disponible en REMCOS, cuando hablamos de inyección de proceso nos referimos específicamente al método descrito aquí
REMCOS emplea una técnica tradicional de ZwMapViewOfSection + SetThreadContext + ResumeThread para la inyección de procesos. Esto implica copiar a sí mismo en el binario inyectado a través de la memoria compartida, mapeado mediante ZwMapViewOfSection y luego secuestrar su flujo de ejecución al punto de entrada de REMCOS empleando métodos SetThreadContext y ResumeThread .
Comienza creando el proceso de destino en modo suspendido mediante la API de CreateProcessW y recuperando su contexto de subproceso mediante la API de GetThreadContext .
A continuación, crea una memoria compartida mediante la API de ZwCreateSection y la asigna al proceso de destino mediante la API de ZwMapViewOfSection , junto con el identificador del proceso remoto.
A continuación, el binario se carga en el proceso remoto copiando su encabezado y secciones en la memoria compartida.
Las reubicaciones se aplican si es necesario. A continuación, el ImageBaseAddress PEB se fija mediante la API de WriteProcessMemory . Posteriormente, el contexto del subproceso se establece con un nuevo punto de entrada que apunta al punto de entrada REMCOS y se reanuda la ejecución del proceso.
A continuación se muestra la detección de esta técnica de inyección de proceso por parte de nuestro agente:
Configuración del modo de registro
REMCOS tiene tres valores de modo de registro que se pueden seleccionar con el campo logging_mode (índice 0x28) de la configuración:
- 0: Sin registro
- 1: Iniciar minimizado en el icono de la bandeja
- 2: Registro de la consola
Al establecer este campo en 2 , se habilita la consola, incluso cuando la inyección de procesos está habilitada, y se expone información adicional.
Limpieza de navegadores
Cuando el enable_browser_cleaning_on_startup_flag (índice 0x2B) está habilitado, REMCOS eliminará las cookies y la información de inicio de sesión de los navegadores sitio web instalados en el host.
Según la documentación oficial , el objetivo de esta capacidad es aumentar la seguridad del sistema contra el robo de contraseñas:
Actualmente, los navegadores compatibles son Internet Explorer, Firefox y Chrome.
El proceso de limpieza implica eliminar cookies y archivos de inicio de sesión de las rutas de directorio conocidas de los navegadores mediante las API FindFirstFileA, FindNextFileAy DeleteFileA :
Cuando se completa el trabajo, REMCOS imprime un mensaje en la consola.
Vale la pena mencionar dos campos relacionados en la configuración:
enable_browser_cleaning_only_for_the_first_run_flag(índice0x2C)browser_cleaning_sleep_time_in_minutes(índice0x2D)
El valor de configuración browser_cleaning_sleep_time_in_minutes determina cuánto tiempo REMCOS suspenderá antes de realizar el trabajo.
Cuando enable_browser_cleaning_only_for_the_first_run_flag está habilitado, la limpieza se producirá solo en la primera ejecución de REMCOS. Después, se establece el valor del Registro HKCU/SOFTWARE/{mutex}/FR .
En ejecuciones posteriores, la función devuelve directamente si el valor existe y se establece en el Registro.
Ese es el final del primer artículo. La segunda parte cubrirá la segunda mitad del flujo de ejecución de REMCOS, desde su perro guardián hasta la primera comunicación con su C2.
