Recientemente, los especialistas de PT ESC descubrieron un documento en formato Publisher llamado "Invitación 29-30 de noviembre de 2018.pub" (1edd5b6a02ec82cec381c1a1ec74a67e). En este artículo, le diremos cómo un documento de aspecto ordinario se convierte en un troyano, lo que permite a un atacante capturar imágenes de cámaras web, grabar sonido por comando o cuando se detecta una ventana de Skype, ejecutar scripts de PowerShell, tomar capturas de pantalla, copiar archivos de dispositivos multimedia.
Entonces, cuando abre el documento, aparece una ventana con un borrón de documento borroso y una solicitud para incluir el script de Microsoft Publisher.
Después de que el usuario lo enciende, el script integrado en el documento se ejecuta en JavaScript. Se ve así:
El resultado del script será la decodificación de dos archivos, PDF y EXE, de Base64. Ambos archivos se escribirán en C: \ Users \ {Nombre de usuario} \ AppData \ Roaming \ DBFUpdate. En consecuencia, ambos archivos se ejecutarán y el usuario verá dicho trozo en la pantalla del documento:
RAT del cazador de tesoros
Los atacantes usan una RAT de múltiples módulos con un gran conjunto de funciones que proporciona acceso completo a la máquina infectada.
Características del código:
- Completamente escrito en C ++ con una gran cantidad de construcciones STL que se usan internamente.
- Aplicación de la biblioteca boost, en particular JSON y Archive.
- Funciones de depuración (más en la sección sobre stager).
Troyano principal
El troyano principal se fija en la máquina de la víctima y es una plataforma en la que se cargan módulos maliciosos desde C2.
Primero, stager inicializa el directorio de trabajo, que posteriormente almacenará la información recopilada por los módulos, las utilidades necesarias para que los módulos funcionen, etc.
A continuación se muestra la inicialización de las rutas para crear el directorio de trabajo:
Una vez que se han creado los directorios necesarios, el troyano principal recopila información sobre la máquina infectada y la envía al servidor de control.
Troyan está interesado en tales datos:
- identificador de la versión del sistema operativo en el que se ejecuta el troyano principal;
- El idioma predeterminado de la interfaz
- El número de versión principal del Service Pack OS;
- nombre de la computadora e identificador de la máquina (para obtener detalles sobre cómo obtener un identificador de la máquina, consulte la sección sobre el protocolo de red).
Así es como se recopila la información sobre la máquina infectada:
A continuación, el troyano principal se repara en la máquina infectada mediante la modificación del valor en el registro en HKCU \ Environment \ UserInitMprLogonScript. Aquí se escribe el nombre del archivo ejecutable que se asignó durante la inicialización del directorio de trabajo, en este caso es igual a "DCTHOST.exe". Este método se
describe en el blog Hexacorn , y también fue utilizado por APT28 y el grupo Cobalt en su ComDLLDroper.
Y el último paso para inicializar el troyano principal es copiar el archivo ejecutable desde su ubicación actual al directorio de trabajo con el mismo nombre que se seleccionó cuando se inicializó el directorio de trabajo.
Después de inicializar el troyano principal, se lleva a cabo la preparación para recibir comandos. El módulo Core se agrega a la lista de módulos en ejecución, que es el troyano principal. A continuación, se inicia un comando desde el módulo Core con el identificador 0. No hay implementación de este comando en el módulo principal; en cambio, es solo un código auxiliar. El constructor del objeto del módulo Core se presenta a continuación.
Al final, comienzan dos hilos. Uno de los subprocesos inicia un temporizador, que se activa por defecto cada segundo e intenta solicitar un comando de C2.
La segunda secuencia carga bibliotecas adicionales y módulos estándar. Las bibliotecas, como los módulos, tienen un identificador, pero a diferencia de los módulos, los identificadores de la biblioteca son negativos, comienzan en -1, crecen hacia números más bajos. A continuación se muestra una lista de bibliotecas descargadas de C2.
Funciones de depuración del troyano principal
Al comienzo de su trabajo, inmediatamente después de la inicialización, el troyano principal establece un controlador de excepciones a través de SetUnhandledExceptionFilter, que contiene funcionalidades interesantes. Cuando se producen excepciones, caen en el controlador, que escribe el minivolcado de la aplicación, al tiempo que guarda información sobre la excepción. Luego se reinicia solo. En la pantalla, creando un minivolcado:
Protocolo de red
El intercambio entre el software y C2 se lleva a cabo utilizando un protocolo binario auto-escrito. Cada mensaje se describe usando BinPackage (nombre tomado de RTTI). Cada BinPackage es esencialmente un contenedor sobre std :: vector, que almacena el conjunto PackageRecord (se inventa el nombre). PackageRecord es la unidad mínima para almacenar datos.
struct PackageRecord { _DWORD dataId; _DWORD datatype; _DWORD szData; char[] data; };
Más sobre los campos de esta estructura:
- dataId : indica el tipo de registro. O la entrada es un identificador de módulo, o un identificador de comando, o una carga útil.
- szData : el tamaño de los datos almacenados en el registro.
- tipo de datos es un tipo de datos.
En total, se registró el uso de tres tipos de datos:
- Un valor de "0" significa que los datos almacenados en el registro deben interpretarse como DWORD.
- El valor "1": los datos almacenados en el registro deben interpretarse como una cadena ASCIIZ.
- El valor "2": los datos almacenados en el registro deben interpretarse como datos cifrados / almacenamiento intermedio sin procesar.
Al enviar BinPackage al servidor de control, se le agrega el identificador de la máquina. El identificador es el GUID de la sección de la que se cortan todos los caracteres especiales. En la figura, obteniendo el identificador de la máquina:
Antes de enviar, todos los registros almacenados en BinPackage se recopilan secuencialmente en un único búfer y se cifran. Para el cifrado, se
utiliza la biblioteca
WinAES , específicamente AES-128-CBC.
Usando Windows CryptoAPI, se generan dos matrices pseudoaleatorias de 16 bytes. Uno para IV, el otro para la llave. Se realiza el cifrado y los datos cifrados se vuelven a agregar a BinPackage, que contiene el paquete cifrado y consta de tres entradas:
- registro con ID 0x777: contiene la clave utilizada para el cifrado;
- registro con ID 0x555: contiene el IV utilizado para el cifrado;
- registro con ID 0x999: contiene datos cifrados (en general, un registro con este ID indica una carga útil y se usa no solo para almacenar datos cifrados).
Después del final del proceso de encriptación, el BinPackage generado nuevamente se recopila en un único búfer y se envía a través de una solicitud HTTP POST al servidor de gestión 151.80.237.222.
A continuación se muestra un ejemplo de un paquete que contiene información de la máquina:
Y este es un ejemplo de un paquete cifrado con información del sistema:
Módulos
Cada módulo, con la excepción de Core, se carga desde el servidor de control. Todos los módulos se pueden dividir en dos categorías: módulos que se cargan automáticamente y módulos que se cargan a pedido del servidor de control.
Un ejemplo de un paquete que solicita un módulo:
Respuesta a la solicitud del módulo:
Cada módulo tiene una interfaz simple que consta de tres funciones: llamada al cargar el módulo Init, llamada al completar fini, y una función que cambia la configuración del módulo. Cada módulo también tiene una exportación llamada GetModule, que crea un objeto que representa este módulo y lo devuelve al troyano principal. Todos los módulos que descubrimos se lanzan en la memoria mediante carga reflexiva.
Además, los nombres de los módulos se dan en la forma en que están presentes en RTTI como nombres de clase.
Módulo CCore
Este módulo representa la funcionalidad básica y está integrado directamente en el troyano principal. Su constructor se puede ver en la tabla a continuación:
| ID del módulo | ID del equipo | Descripción |
|---|
| 0 0 | 0 0 | Básicamente, un troyano en lugar de un comando es un trozo, y su propósito exacto no se pudo establecer |
| 1 | Modificar la configuración del módulo |
| 2 | Solicitar información de la computadora |
| 3 | Descargue la utilidad desde el servidor de control |
| 4 4 | Solicitar listado de un directorio que contiene utilidades |
| 5 5 | Descargue el módulo y ejecútelo |
Módulo CShell
Este módulo proporciona un shell remoto a una máquina infectada. Cuando se inicializa el módulo, se crea el proceso cmd.exe, al que se conectan dos canalizaciones: una para entrada estándar y otra para salida estándar, a través de la cual se reciben y transmiten comandos desde el servidor de control y viceversa. También en este momento, se inicia un subproceso, que toma automáticamente toda la salida y la envía al servidor de control. La figura muestra la inicialización del módulo CShell.
| ID del módulo | ID del equipo | Descripción |
|---|
| 2 | 0 0 | Enviar comando a shell |
| 1 | Imprime el archivo. Se lee un archivo, la ruta a la cual se transmite desde el servidor de control, y el contenido de este archivo se carga en el servidor de control |
| 2 | Obtenga una lista de todos los discos existentes en el sistema. Los datos se envían al servidor de control en formato JSON |
| 3 | Descargue el archivo del servidor de control. La ruta donde guardar el archivo y los datos se reciben del servidor de control |
Módulo CFileSystemBrowser
Este es un módulo pasivo, que a pedido le permite recibir información sobre la estructura del sistema de archivos. Así es como ocurre la inicialización del módulo CFileSystemBrowser:
| ID del módulo | ID del equipo | Descripción |
|---|
| 3 | 0 0 | Obtenga una lista de todos los discos existentes en el sistema. Los datos se envían a C2 en formato JSON |
| 1 | Obtener listado de directorio. El listado se genera en formato JSON |
| 2 | Imprime el archivo. Se lee un archivo, la ruta a la cual se transfiere desde C2 y el contenido de este archivo se carga en C2 |
| 3 | Eliminar archivo La ruta al archivo se transfiere desde C2 |
Módulo CScreenShot
Este módulo le permite tomar capturas de pantalla o capturar imágenes desde una cámara web. Puede hacerlo tanto a pedido como con un período específico en el temporizador.
| ID del módulo | ID del equipo | Descripción |
|---|
| 4 4 | 0 0 | Tome una captura de pantalla y envíela al servidor de control |
| 1 | Ejecute un temporizador, después del cual se toma una captura de pantalla de la pantalla de la máquina. Las capturas de pantalla resultantes se empaquetan en BinPackage y se guardan en la carpeta de registros. Los nombres de los archivos se generan utilizando la API GetTempFileName con el prefijo "MS_". |
| 2 | Obtenga videos de dispositivos disponibles en una máquina infectada |
| 3 | Capture un marco de la cámara web y envíelo al servidor de control |
Módulo CSender
Este módulo no está activado inicialmente. Sube el contenido de la carpeta de registros al servidor de control. Se activa cuando llega una solicitud para cambiar la configuración, que contiene el período de verificación.
Módulo CKeylogger
Este módulo tampoco está activado inicialmente. Se activa cuando llega una solicitud de cambio de configuración que contiene el tamaño del búfer en el que se almacena el registro. La interceptación de entrada se lleva a cabo a través de
rawinput . Además, el keylogger monitorea la ventana en la cual el usuario ingresa y registra su título.
Módulo CDictaphone
Este módulo graba el sonido por comando o al detectar una ventana de Skype. Cuando se inicia, inicia un subproceso que enumera todas las ventanas y sus ventanas secundarias en el sistema y busca la ventana entre las clases cuyo nombre de clase es TLiveConversation o TCallMonitorControl. Si se encuentra dicha ventana, comienza la grabación. A continuación se muestra la inicialización del módulo CDictaphone:
Y la ventana de búsqueda de Skype
La grabación se realiza a través del MCI enviando comandos especiales. Así es como se ve el ciclo de escritura del módulo CDictaphone:
Después de cerrar la ventana o de recibir un comando para completar la grabación, los datos recibidos se guardan en una carpeta temporal, después de lo cual se codifica mediante el codificador de MP3 cojo (se considera una utilidad y ya debería estar cargado, no fue posible obtenerlo del servidor de control). El archivo codificado se guarda en la carpeta de registros. Generar un nombre de carpeta es similar a generar nombres para capturas de pantalla.
| ID del módulo | ID del equipo | Descripción |
|---|
| 7 7 | 0 0 | Comience a grabar y complételo después de 15 minutos. |
| 1 | Dejar de grabar |
| 2 | Verificar estado: está grabando en progreso |
Módulo CProcessesManager
Este es un módulo pasivo, capaz de devolver una lista de procesos a pedido o finalizar por el PID que se le pasa.
| ID del módulo | ID del equipo | Descripción |
|---|
| 8 | 0 0 | Devuelve una lista de procesos: sus nombres, PID y el nombre del usuario propietario del proceso. |
| 1 | Finalización del proceso PID |
Módulo de CDownloader
El módulo está diseñado para cargar archivos grandes al servidor de control. Realiza la transmisión de datos por fragmentos, cuyo tamaño se establece por su configuración. El módulo lee datos de un archivo, la ruta a la que recibe del servidor de control, y empaqueta trozos en BinPackage. Para cada BinPackage que contiene el fragmento, se agrega una entrada con el identificador 0x888, que incluye la ruta al archivo. Después de pasar cada trozo, el sueño se realiza durante 5 segundos.
| ID del módulo | ID del equipo | Descripción |
|---|
| 9 9 | 0 0 | Trozo, no se pudo establecer el valor exacto |
| 1 | Realiza la transferencia de una gran cantidad de datos (0x500000 bytes), después de lo cual mide el tiempo dedicado a la transferencia y envía este valor a C2 |
| 2 | Descargar un archivo de una máquina |
Módulo CPS
Este módulo le permite ejecutar scripts de PowerShell.
| ID del módulo | ID del equipo | Descripción |
|---|
| 10 | 0 0 | Recibe un script de PowerShell de C2 y lo ejecuta |
Módulo CDeviceMonitor
Un módulo pasivo que monitorea los dispositivos multimedia conectados y copia archivos de ellos. Utiliza mensajes de difusión WM_DEVICECHANGE para detectar la conectividad del dispositivo. Después de conectar el dispositivo al servidor de control, se envía información sobre cuándo se conectó el dispositivo, su etiqueta de volumen y la ruta al dispositivo. El código utilizado para obtener la ruta al dispositivo es muy similar a este. Todos los archivos se copian en la carpeta de registros. Los nombres se generan de la misma manera que para las capturas de pantalla. El archivo fsIndex.dat se crea por separado, en el que se encuentra el diccionario serializado con boost :: archive. Este diccionario almacena las rutas originales a los archivos que se copiaron y sus hash MD5. A continuación se muestra el recibo de DevicePath:
Como epílogo, varias recomendaciones:
- No es necesario abrir archivos adjuntos en cartas de destinatarios desconocidos, y mucho menos incluir un script de Microsoft Publisher.
- No es menos peligroso hacer clic en los enlaces de las cartas de remitentes desconocidos. El sitio donde va puede alojar malware que se descargará automáticamente a su PC.
- Debe actualizar regularmente el software, especialmente Microsoft Windows y Microsoft Office, que cerrará el acceso a una amplia gama de malware.