Amenaza persistente avanzada dirigida a defensores de los derechos humanos en Vietnam

Resumen ejecutivo

No importa si eres una organización pequeña, una organización sin fines de lucro o una empresa Fortune 500: siempre habrá alguien que quiera acceder a tu información. En muchos casos, este acceso busca principalmente un beneficio financiero; sin embargo, para muchas organizaciones sin fines de lucro y organizaciones pequeñas, la dura realidad es que la naturaleza de su trabajo, o de sus clientes, también las convierte en un objetivo ideal para actores de amenazas motivados por la recopilación de inteligencia y el espionaje.

Los analistas del SOC de Huntress descubrieron recientemente una intrusión en el equipo de un defensor de derechos humanos vietnamita, que se sospecha estuvo activa durante al menos cuatro años. Esta intrusión presenta varias coincidencias con técnicas conocidas usadas por el actor de amenazas APT32/OceanLotus, y un perfil de objetivo conocido que coincide con los objetivos de APT32/OceanLotus. Esta publicación destaca hasta dónde llegan las amenazas avanzadas con fines de recopilación de información cuando esto se alinea con sus intereses estratégicos.

Contexto

Huntress realiza regularmente operaciones de caza de amenazas para encontrar intrusiones que puedan haber pasado desapercibidas por las defensas de seguridad habituales. En un caso reciente, los analistas de Huntress identificaron una intrusión contra una organización sin fines de lucro que apoya los derechos humanos en Vietnam, la cual probablemente se extendió durante al menos cuatro años. Si bien las detecciones en la plataforma de Huntress encontraron cierta actividad anómala que fue reportada al socio de Huntress, el equipo del SOC pudo encontrar persistencia bien oculta y acciones tomadas por el actor de amenazas. Esta información se usó luego para reconstruir la intrusión y rastrearla hasta mucho antes de que se implementara el Huntress Agent.

Metodología de caza

Huntress está en una posición única para buscar actores de amenazas en millones de sistemas. Esto se logra combinando información sobre el comportamiento de los procesos con puntos de persistencia recopilados mediante el Huntress EDR. Aprovechando la información sobre el comportamiento de los procesos, los analistas del SOC usan inteligencia, o una hipótesis, y su conocimiento de lo que es normal en un sistema para crear reglas de caza de amenazas. Estas reglas difieren de las detecciones de producto, ya que generalmente tienen mayor frecuencia y menor eficacia, dado que apuntan a técnicas usadas por actores de amenazas que intentan mezclarse con el entorno. Usando las reglas de caza creadas, el equipo del SOC suele adoptar tres enfoques distintos para la caza de amenazas: buscar señales de caza poco comunes, conjuntos de múltiples señales y anomalías estadísticas.

El Managed EDR de Huntress identifica de forma constante puntos de persistencia en un sistema. Esto permite al equipo del SOC localizar anomalías donde puede encontrarse un punto de persistencia en un pequeño subconjunto de los sistemas protegidos por Huntress. Estas anomalías podrían ser una diferencia en el mecanismo de persistencia, el nombre, el binario u otro atributo respecto a lo que normalmente se observa en otros entornos de socios de Huntress. Mientras se investigaba una nueva señal de caza, se descubrió que un sistema ejecutaba de forma infrecuente e inconsistente una pequeña cantidad de comandos administrativos desde un proceso inusual.

Los comandos administrativos ejecutados fueron deliberados y rara vez superaron los tres comandos en un período de diez minutos, con un máximo de doce ejecutados en un sistema durante un día determinado. A pesar de esto, la actividad inusual fue suficiente para llamar la atención de los analistas del SOC de Huntress, quienes procedieron a revisar los puntos de persistencia en el entorno del socio y reconstruir la magnitud real de esta intrusión.

Investigación y análisis

Host 1

Mecanismos de persistencia

Durante la incorporación a Huntress, el endpoint 1 presentó una tarea programada titulada Adobe Flash Updater:

Tarea programada 1

El archivo referenciado scheduler.ps1:log.txt es un flujo de datos alternativo llamado log.txt dentro de un archivo llamado scheduler.ps1. Este archivo ya había sido eliminado antes de que se implementara el agente de Huntress; sin embargo, la convención de nombres y el uso de un flujo de datos alternativo tienen cierta similitud con un informe público de Cybereason que detalla un cargador basado en VBS y PowerShell usado para cargar payloads de Metasploit y Cobalt Strike.

En las semanas siguientes, se crearon nuevas tareas programadas en el endpoint, identificadas por el agente de Huntress con una diferencia de aproximadamente 10 días entre sí:

Tarea programada 2

Tarea programada 3

Esta tarea programada contenía un SID de usuario diferente al que se encontró en la tarea programada AdobeUpdateTaskUser . El script MSSharePoint.vbs estaba diseñado para usar una clave privada ya colocada en el disco, autenticarse en un servidor SFTP remoto, y descargar / ejecutar un script llamado cloud.bat.

El archivo por lotes cloud.bat utilizó la misma clave privada para autenticarse en el mismo servidor SFTP remoto, y descargó un archivo llamado cloudlog.txt.

Al momento de la investigación no había ningún archivo cloudlog.txt en el disco. Las marcas de tiempo de modificación en la clave privada, los binarios de SFTP y SSH indican que posiblemente estuvieron presentes desde noviembre de 2023.

Menos de un día después, se usó schtasks.exe para crear persistencia que ejecutaría cloud.bat una vez cada 5 horas.

Tarea programada 4

Se descubrió que la creación de la tarea programada Handler se originó más tarde a partir de un proceso sustituto de DllHost que ejecutaba una DLL de un objeto COM almacenado en el registro con el identificador {1F7CFAF8-B558-4EBD-9526-203135A79B1D}.

Se descubrió que este proceso se lanzaba desde otra tarea programada que ya existía antes de la implementación de Huntress.

Tarea programada 5

Esta tarea intentó hacerse pasar por la tarea legítima UpdateLibrary del sistema y tenía una descripción idéntica a la de la tarea programada legítima UpdateLibrary que también existía en el sistema. Las marcas de tiempo de creación y modificación de la tarea indican que se configuró por primera vez en junio de 2020. El StartBoundary dentro del archivo XML usado para esta tarea programada también tenía un valor de marca de tiempo de 2020-01-01T00:00:00 que indica que se esperaba que la tarea se ejecutara desde el inicio de 2020 en adelante.

Aunque la tarea programada no tenía un ejecutable configurado para ejecutarse, sí tenía un controlador COM que debía invocarse. El análisis del endpoint encontró un objeto COM configurado mediante claves de registro.

Objeto COM

Esta DLL del objeto COM configurada para ejecutarse era una iisutil.dll legítima y firmada, usada por IIS Express, que coincidía con una regla creada por Florian Roth de Nextron Systems hace 5 años llamada APT_OceanLotus_ISSUTIL_Sep18. Aunque esta coincidencia fue un falso positivo, se encontró una muestra maliciosa en VirusTotal que coincidía con esta regla, la cual fue enviada con los nombres iisutil.dll e iisutil2.dll.

Algunos motores antivirus han marcado esta muestra como vinculada a APT32/OceanLotus, y tiene un notable solapamiento con otra DLL encontrada en el disco llamada iisutil2.dll. El análisis adicional de la DLL y otros 2 archivos, que juntos actúan como una puerta trasera, se presenta en la sección: "Análisis de malware".

Unas semanas después de la creación de estas tareas programadas, se observó un comando de enumeración en el endpoint que buscaba los privilegios del usuario actual. 

whoami /priv

Al día siguiente, se realizó un reinicio forzado en un endpoint remoto. Esta misma acción se realizó en otro sistema aproximadamente dos semanas después de la ejecución en el primero.

No sabemos la intención de esta acción, pero especulamos que pudo haber sido para asegurar la ejecución de malware en un sistema remoto o para asegurar que se aplicaran cambios de configuración del sistema.

Durante los meses siguientes, se ejecutaron varios comandos de descubrimiento para garantizar el acceso a estaciones de trabajo remotas desde el endpoint 1. Se tomaron acciones para asegurar que la conectividad de red siguiera activa en el endpoint y en los endpoints remotos.

Se encontró una clave de ejecución en el equipo 1 que hacía referencia a un binario del módulo OEM de McAfee (mcoemcpy.exe) que se hacía pasar por WdiServiceHost. No se encontró en el momento de la investigación la DLL usada para la carga lateral; sin embargo, existe un informe público de ESET que indica que este ejecutable es vulnerable a la carga de una DLL maliciosa llamada McUtil.dll.

Clave de ejecución 1

Se encontró una segunda clave de ejecución en el equipo 1 que hacía referencia a un binario de software de Apple (SoftwareUpdate.exe) con una firma de código revocada. Este mecanismo de persistencia era único entre los clientes de Huntress y se cree que se usó para cargar lateralmente una DLL maliciosa. No se encontró en el momento de la investigación la DLL usada para la carga lateral; sin embargo, existe un informe público de Recorded Future que indica que este ejecutable es vulnerable a la carga de una DLL maliciosa llamada SoftwareUpdateFilesLocalized.dll.

Clave de ejecución 2

Se encontró otra clave de ejecución más en el equipo 1 que hacía referencia a un script por lotes llamado connection.bat. Este tenía una funcionalidad idéntica a MSSharePoint.vbs, excepto que ejecutaba PowerShell para correr SFTP en lugar de un script VBS.

Clave de ejecución 3

Justo antes de que ocurriera el aislamiento en este sistema, se observó que el actor de amenazas intentaba robar las cookies de Google Chrome de todos los perfiles de usuario del sistema desde la puerta trasera del objeto COM DllHost.

cmd /c for /f "tokens=*" %G in ('dir /b "%localappdata%\Google\Chrome\User
 Data\Profile *"') do copy "%localappdata%\Google\Chrome\User
 Data\%G\Network\Cookies.bak" "%localappdata%\Google\Chrome\User 
Data\%G\Cookies" /y

Equipo 2

Mecanismo de persistencia

En un equipo distinto, el equipo 2, se ejecutaron comandos remotos mediante Windows Management Instrumentation para ejecutar un script por lotes aproximadamente 1,5 meses después de la primera acción observada en el equipo 1. Este script por lotes se usó para consultar los procesos en ejecución en el equipo.

cmd.exe /c C:\Users\Public\Downloads\1.bat

El contenido del script por lotes se muestra a continuación:

Poco después también se observaron comandos de descubrimiento de dominio en este sistema.

net group "Domain Admins" /domain
nltest /dclist:<REDACTED>.local

El proceso que inició esto fue una versión legítima del ejecutable de gestión de libros electrónicos calibre calibre.exe que había sido configurado para ejecutarse como una tarea. A través de la telemetría de Huntress, se observó que se intentó crear una tarea programada para ejecutar este ejecutable calibre.exe desde una ubicación inusual.

schtasks /create /sc MINUTE /mo 300 /tn
 "Microsoft\Windows\WindowsColorSystem\Calibration_Update" /tr
 "C:\Users\<REDACTED>\AppData\Roaming\Microsoft\SPMigration\Bin\Calibre.exe
" /f

Tarea programada 1

Cabe notar que esto es un intento de pasar desapercibido imitando la tarea legítima “Calibration Loader”, que generalmente se encuentra en C:\Windows\System32\Tasks\Microsoft\Windows\WindowsColorSystem\Calibration Loader. Especulamos que se eligió la tarea “Calibration Loader” por su nombre similar al archivo calibre.exe.

Poco después de esta ejecución, se intentó una escalada de privilegios mediante tuberías con nombre (named pipes), realizada a través del proceso calibre. Esto probablemente implicó una inyección en el proceso legítimo de Windows gpupdate.exe, un proceso conocido que suele recibir inyecciones mediante perfiles maleables de Cobalt Strike y que se observa con frecuencia al ejecutar el comando “getsystem” de Cobalt Strike.

El análisis de este equipo reveló que el ejecutable calibre estaba ejecutando una DLL maliciosa llamada calibre-launcher.dll en el disco; sin embargo, en cuestión de minutos, antes de que se pudieran obtener la DLL y el ejecutable, el actor de amenazas parece haber terminado el proceso en ejecución y haber eliminado todo el directorio SPMigration incluyendo el implante. Al momento de la investigación, todavía había una entrada sospechosa en la caché DNS del sistema:

Aunque no pudimos confirmar que esta búsqueda estuviera relacionada con la intrusión en cuestión, el dominio era similar a uno visto anteriormente (msteamsapi[.]com) y el subdominio también coincidía parcialmente con un subdominio visto en el endpoint 4.

Endpoint 3

Mecanismo de persistencia

Poco después de realizar la suplantación de named pipe en el endpoint 2, se ejecutó un comando usando el mismo beacon de Cobalt Strike en un intento de crear una tarea programada en un tercer sistema. Esta tarea programada se configuró para ejecutarse cada 15 minutos como la cuenta de usuario SYSTEM (Nota: el nombre de la tarea se asemeja a una clave de licencia y, por lo tanto, se ha redactado como precaución).

schtasks.exe /u "<REDACTED>\<REDACTED>" /p "<REDACTED>" /S
 <REDACTED> /create /SC MINUTE /MO 15 /TN "<REDACTED>" /TR
 "C:\Users\<REDACTED>\AppData\Roaming\Microsoft\SPMigration\Bin\calibre.exe" 
/RU "NT AUTHORITY\SYSTEM" /K /f

Tarea programada 1

Poco después de esto, se ejecutó un comando para invocar el ejecutable calibre.

wmic /node:<REDACTED> /user:<REDACTED> /password:<REDACTED> 
process call create "cmd.exe /c start
c:\Users\<REDACTED>\AppData\Roaming\Microsoft\SPMigration\Bin\calibre.exe"

En el momento de la investigación, el ejecutable y la DLL no se encontraron en el disco.

Endpoint 4

Mecanismos de persistencia

Usando la telemetría disponible de Huntress, se realizó una búsqueda para encontrar cualquier otra instancia donde el ejecutable calibre estuviera configurado para ejecutarse al inicio. Se encontraron tres tareas programadas en el sistema, dos de las cuales se hacían pasar por ejecutables legítimos de Adobe, y la otra se hacía pasar por una tarea de actualización de Microsoft.

Tarea programada 1

Tarea programada 2

Tarea programada 3

El análisis de las conexiones de red en el sistema mostró que uno de los ejecutables calibre que se hacía pasar por Adobe (AdobeARM.exe) tuvo previamente una conexión de red a una dirección IP remota.

Según el análisis de esta infraestructura y de los archivos maliciosos calibre-loader.dll enviados a VirusTotal, esta dirección IP y el implante calibre.exe probablemente estaban vinculados a un Cobalt Strike Team Server.

Meses después de nuestra detección inicial en el endpoint 1, se observó un descubrimiento de privilegios de usuario mediante un proceso calibre.exe diferente.

whoami /priv

Semanas después de este comando, observamos la creación de un nuevo servicio para ejecutar un ejecutable node legítimo. Este ejecutable estaba configurado para lanzar un binario de Node addon malicioso para evadir la detección en el sistema.

Servicio 1

El Node addon fue creado específicamente para apuntar al sistema y a la cuenta de usuario, e incluía una ruta codificada a un archivo en disco en C:\Programdata\Adobe\ms-adobe.bin. Esto también incluía un nombre de servicio codificado que se crearía llamado SrvAdobeUpd; sin embargo, en el momento de la investigación, este no se encontró en el sistema. El análisis de las conexiones de red en el sistema mostró que este ejecutable node se conectó previamente a una dirección IP remota.

Según el análisis de esta infraestructura y del archivo node malicioso, se cree que esto probablemente estaba vinculado a un Cobalt Strike Team Server.

Aproximadamente un mes después del lanzamiento del Node addon, observamos la creación de una tarea programada que se originaba desde el proceso node.exe.

Esta tarea programada estaba configurada para ejecutar un archivo jar que cargaría una DLL incrustada en memoria.

Tarea programada 4

Se menciona un análisis más detallado sobre msadobe.jar en la siguiente sección.

Análisis de respaldo

Lo más probable es que esto sea solo la punta del iceberg y que el verdadero alcance de esta intrusión se extienda mucho más allá de los sistemas con el agente de Huntress. Se realizó un análisis preliminar del malware encontrado en estos sistemas y de la infraestructura usada en la intrusión. Esto se hizo para determinar si existía alguna coincidencia conocida con técnicas de actores de amenazas que se alinearan con la industria objetivo o el perfil de la organización víctima.

Análisis del malware

Esta intrusión involucró varios binarios y archivos. A continuación se incluye un resumen de estos archivos.

Durante el análisis del sistema 1, se descubrió que el cachuri.dll legítimo, configurado para ejecutarse como un objeto COM, importaba y ejecutaba código explícitamente desde iisutil2.dll. Aunque iisutil2.dll tenía información casi idéntica a una copia firmada y válida de iisutil.dll, este había sido parchado para ejecutar código diferente, y se modificó para aumentar el tamaño del archivo por encima de 50 MB. Se cree que esto se hizo para evadir varias reglas YARA que a menudo tienen restricciones de tamaño de archivo, y para evitar enviar el archivo a herramientas de análisis en un entorno aislado en línea, muchas de las cuales tienen un límite de tamaño de archivo de 50 MB. Esta modificación causó diferencias notables en el NT Header, el Optional Header y, más significativamente, en la sección .text .

El punto de entrada de esta DLL también había sido modificado al desplazamiento 0x00025FB0 (155568), que difería del punto de entrada original de 0x00027FB0 (163760). Un breve análisis de este binario mostró que colocaba la dirección de retorno en la pila y luego ejecutaba una función en 0x1002711e.

Esto es significativo porque estas operaciones, el punto de entrada y la dirección de la función que se va a ejecutar son todos idénticos al malware mencionado anteriormente, enviado a VirusTotal y vinculado a APT32/OceanLotus. Una inspección más detallada mostró que este archivo era en realidad idéntico a la muestra en VirusTotal vinculada a OceanLotus mencionada anteriormente, con la única diferencia de que se le añadieron datos para que su tamaño de archivo creciera por encima de 50 MB.

En contraste, la DLL legítima comenzaba configurando los registros necesarios antes de tener una condición de bifurcación dependiendo de los argumentos pasados al ejecutable que ejecuta la DLL.

El DLL malicioso buscaría en el Process Environment Block (PEB) una estructura PEB_LDR_DATA para poder identificar el InLoadOrderModuleList. Esta estructura contiene una lista de DLL en el orden en que se cargaron.

El código incluye múltiples operaciones de salto, como la que se muestra en la figura 10, que nunca se ejecutarían, o que solo se usarían para correr una pequeña cantidad de instrucciones, antes de volver al flujo original de ejecución.

Curiosamente, este malware contiene varios códigos de operación basura y ofuscación del flujo de control para confundir el análisis estático y dificultar el desensamblado. Esto coincide con técnicas que se sabe que usa APT32/OceanLotus, como se informó previamente en un reporte de ESET.

Este malware examina los DLL cargados y sus exportaciones para poder resolver dinámicamente las API que se usan para facilitar el descifrado y la inyección de un payload en memoria. Esto coincide de forma significativa con el malware reportado por BlackBerry/Cylance, llamado Steganography Loader #2 (cargador de esteganografía n.º 2).

El análisis reveló que esta DLL finalmente leía iisexpressshim.sdb, lo descifraba usando una clave XOR de 0xFF, y luego descomprimía los datos usando el algoritmo de compresión LZNT1. El archivo descifrado iisexpressshim.sdb mostró más instancias de códigos de operación basura que nunca se evaluarían.

La DLL descifrada en memoria luego cargaba logo.png, usaba una rutina personalizada de esteganografía, y luego hacía una llamada a la API CryptDecrypt de Windows para descifrar y cargar la DLL final en memoria. El uso de una rutina personalizada de esteganografía para ocultar código malicioso en un archivo PNG aparentemente inofensivo, además del uso de una clave XOR y compresión, coincide con el Steganography Loader mencionado anteriormente, usado por APT32/OceanLotus. Se observa que hubo varias diferencias entre esta versión del Steganography Loader y la reportada anteriormente, entre ellas el uso de LZNT1 en lugar de LZMA, y una clave XOR fija de 0xFF en lugar de obtenerla de un archivo en disco.

El malware también mostró un alto grado de coincidencia con una muestra analizada por un investigador de seguridad en marzo de 2019, y es muy probable que ambas muestras de malware pertenezcan a la misma familia de malware. Al momento de la investigación, el equipo tenía conexiones activas a 185.198.57[.]184 y 185.43.220[.]188 en el puerto 8888 desde el proceso DllHost que ejecutaba la puerta trasera del objeto COM.

La información de DNS pasivo para la dirección IP 185.198.57[.]184 mostró que los dominios mencionados en el blog del investigador de seguridad de 2019 resolvían a esta dirección IP. Esto ayuda a validar que el malware descrito en su blog es el mismo malware encontrado en este sistema 5 años después. También vale la pena mencionar que ninguno de los dominios parece haber caducado ni haber sido registrado de nuevo, y todos los dominios se registraron originalmente a finales de 2017. Esto indica que los dominios a continuación probablemente han estado bajo el control del mismo actor de amenazas durante casi 7 años.

• cdn.arlialter[.]com - Dominio registrado originalmente: 2017-10-27
• fbcn.enantor[.]com - Dominio registrado originalmente: 2017-10-27
• ww1.erabend[.]com - Dominio registrado originalmente: 2017-10-27
• var.alieras[.]com - Dominio registrado originalmente: 2017-10-27

Los dominios también parecen hacerse pasar por dominios legítimos, lo cual es notable dado que APT32/OceanLotus ha usado anteriormente esta técnica en sus intrusiones.

También se descubrió que el equipo tenía otras cuatro tareas programadas que se hacían pasar por varios servicios con descripciones idénticas. Estas tareas tenían una convención de nombres similar a las tareas programadas vistas anteriormente. Además, una clave de ejecución de usuario también tenía una convención de nombres similar:

Tarea programada 1

Tarea programada 2

Tarea programada 3

Tarea programada 4

Clave de ejecución 1

El análisis de las tareas programadas del equipo 1 encontró otras dos instancias de la puerta trasera COM maliciosa registrada. Estas ya no ejecutarían el código malicioso oculto dentro de logo.png ya que el archivo malicioso necesario iisutil2.dll había sido eliminado del sistema. Se sospecha que se establecieron múltiples variantes de la puerta trasera en el sistema a lo largo del tiempo para ayudar a garantizar que el acceso se mantuviera incluso si los productos antivirus detectaban algunas de las puertas traseras existentes.

Entre las tareas programadas había una tarea DropboxUpdate que apuntaba a un ejecutable legítimo. Aunque DropboxUpdate no importa ni usa directamente goopdate.dll, este es llamado y cargado indirectamente por DropboxUpdate, que luego se usa para cargar un archivo malicioso DropboxUpdate.bin en el mismo directorio, como se muestra a continuación en la Figura 15.

El análisis de la memoria del proceso encontró múltiples dominios y detalles de configuración de C2 para este malware:

Estos dominios, una vez más, se hacían pasar por dominios legítimos.

La DLL maliciosa goopdate.dll tiene un tamaño de más de 20 MB y verifica si existe una variable de entorno GUID codificada en el sistema. Si no está presente, se establecerá. Esto se hace antes de configurar los permisos de memoria como RWX para permitir inyectar el payload .bin en memoria.

Cabe destacar que esta DLL tiene una función en el desplazamiento 0x0001010 que usa una lista codificada de nombres en esta rutina de inyección. Específicamente, toma el último nombre del arreglo y lo concatena con todos los demás nombres, lo cual luego se evalúa antes de la inyección.

No se observaron coincidencias específicas con archivos maliciosos goopdate.dll reportados previamente y utilizados por APT32/OceanLotus. A pesar de esto, Facebook, Cybereason, y Volexity han reportado previamente el uso de APT32/OceanLotus con una goopdate.dll maliciosa que se cargaba en un ejecutable benigno. Vale la pena señalar que esta técnica y el nombre de la DLL también se usan entre otros actores de amenazas.

Al examinar los archivos JAR adobe.jar y msadobe.jar se encontró que eran simples cargadores que ejecutarían DLL integradas específicas en la memoria desde una clase principal llamada UpdateData.

Al observar la DLL mi54giwp.dll se encontró que crearía un Mutex con el valor okSSjZzAlnNOlQaGoDWx antes de apuntar a un archivo .bin ubicado dentro de un directorio codificado en la DLL. Esto resalta que el malware se había creado específicamente para apuntar al sistema en el que se ejecutó.

Se encontró un comportamiento similar en la DLL zfhqq01v.dll, que crea un Mutex con el valor sbvjJpGLbbmnHNfWEetm antes de apuntar a un archivo .bin ubicado en el directorio de otra cuenta de usuario codificado de forma fija dentro de la DLL.

Al examinar el equipo 1 se descubrió que previamente se había configurado persistencia para ejecutar un ejecutable sospechoso desde una clave de ejecución de usuario. Windows Defender puso este ejecutable en cuarentena.

Clave de ejecución 2

Cabe destacar que el directorio “TPM Console” tenía tres archivos con marcas de tiempo de modificación distintas, que son de interés al momento de establecer la cronología de este incidente.

El análisis del archivo en cuarentena TpmInit.exe reveló que se trataba de una versión modificada de un ejecutable legítimo de TpmInit . Al ejecutarse por primera vez, este ejecutable crea dos archivos, TpmInit.mdb y TpmInit.mdf en el disco si no están presentes, antes de finalizar, momento en el cual estos archivos ya no se modifican.

Aunque se desconoce si este ejecutable estuvo relacionado con la misma intrusión, las marcas de tiempo de modificación indican que este malware pudo haber estado presente y en ejecución en el sistema afectado desde 2017. Si tanto TPMInit.mdb como TPMInit.mdf están presentes cuando se ejecuta el ejecutable, TpmInit.db (una DLL) se extrae de TpmInit.exe y se ejecuta usando rundll32.exe después de inyectarse primero en otro proceso rundll32 . Este archivo cambiará su marca de tiempo de modificación cada vez que se ejecute el ejecutable, lo que indica una posible primera y última vez que este malware se ejecutó en el sistema.

Para ejecutar TpmInit.db, el malware aprovecha la aplicación legítima rundll32 para ejecutar una función exportada llamada 'TpmVCardCreate'. Vale la pena señalar que las exportaciones de esta DLL llevan el nombre de un subconjunto de exportaciones que se encuentran en un tpmvsc.dll legítimo que normalmente se encuentra en Windows.

Después de la ejecución, esto obtendría un identificador de kernel32.dll para obtener la dirección de los módulos que se usarán y verificar si Kaspersky AV se estaba ejecutando en el sistema (avp.exe) y avg (avghookx.dll) como se ve en la figura 28.

Análisis de la infraestructura

Al examinar las dos direcciones IP sospechosas del Cobalt Strike Team Server, se encontró que ambas estaban firmadas con certificados de Let's Encrypt y se ubicaban detrás de un Cloudflare Load Balancer. Resulta interesante que los servidores presentaban un mensaje de 404 Not Found con un Content-Length de 0 cada vez que se enviaba una solicitud GET con un URI que contenía un '/'. Los servidores también presentaban una respuesta 200 con un Content-Length de 0, y los métodos permitidos OPTIONS, GET, HEAD, POST cada vez que se enviaba una solicitud OPTIONS . Esto es importante porque se espera el mismo comportamiento al interactuar con un Cobalt Strike Team Server, como lo reportó anteriormente Palo Alto Networks.

La combinación de encabezados de respuesta específicos y el Cloudflare Load Balancer dio lugar a un banner de servicio único que se observó en ambas direcciones IP sospechosas del C2 de Cobalt Strike mediante una búsqueda en Censys, como se ve en la Figura 30.

Una búsqueda de este banner encontró solo siete hosts, lo que lo convierte en una huella digital bastante única. Al buscar únicamente los hosts identificados tanto por un nombre como por una dirección IP, se encontraron tres direcciones IP y dominios únicos, de los cuales solo uno no se había visto en esta intrusión.

Resulta interesante que todas estas direcciones IP tenían nombres de dominio que parecían hacerse pasar por sitios web o software legítimos, y ninguno de los ASN ni de los proveedores de servicio coincidía entre sí.

Objetivos y atribución

Desde hace tiempo se ha informado que periodistas, bloggers, disidentes y defensores de los derechos humanos vietnamitas han sido blanco de malware y tácticas consistentes con las operaciones de APT32/OceanLotus, que se remontan al menos a 2013. Esto ha sido reportado por empresas como Google, la Electronic Frontier Foundation, Amnistía Internacional, y muchos otros proveedores de seguridad. Durante nuestra investigación se encontraron varias coincidencias entre las técnicas conocidas que usa APT32/OceanLotus, los sectores e intereses objetivo de este actor de amenazas, y lo que se encontró en esta intrusión:

• El objetivo fue una organización sin fines de lucro que apoya los derechos humanos en Vietnam
• El malware en cuestión usaba una DLL maliciosa que era cargada por una DLL de IIS Express llamada iisutil.dll. Esto coincide con una regla YARA creada por Nextron Systems que apunta al actor de amenazas APT32/OceanLotus.
• La DLL maliciosa usada en esta intrusión usaba una versión modificada de iisutil con el punto de entrada 0x00025FB0 (155568) y una función en 0x1002711e. Todo el código del malware es idéntico al malware subido a VirusTotal que se sabe está asociado con APT32/OceanLotus, salvo por un relleno adicional agregado al final.
• Los puertos 8888 y 8531 se usaron en la configuración de C2 del malware. El backdoor de objeto COM coincide con un informe público de un investigador de seguridad de 2019, donde el payload final contenía ocho posibles direcciones de servidor C2 con números de puerto idénticos. 
• El uso de direcciones C2 codificadas en un recurso DLL tiene una coincidencia conocida con el malware usado por APT32/OceanLotus, según lo reportado por BlackBerry/Cylance.
• El uso de objetos COM y esteganografía con archivos PNG es una técnica conocida que se reporta como usada por APT32/OceanLotus, según lo reportado por BlackBerry/Cylance.
• Se agregaron flujos de datos alternativos (Alternate Data Streams) con el nombre log.txt a un script de PowerShell y fueron cargados por wscript mediante una tarea programada. Esto tiene una convención de nombres similar a una campaña reportada públicamente y atribuida a APT32/OceanLotus, 'Operation Cobalt Kitty', por Cybereason.
• Se sospecha que el actor de amenazas usó Cobalt Strike al cargar una DLL maliciosa en un ejecutable legítimo, una técnica conocida usada por APT32/OceanLotus.
• Facebook, Cybereason y Volexity han reportado que APT32/OceanLotus usa una goopdate.dll maliciosa que se carga en un ejecutable benigno.
• Se sabe que APT32/OceanLotus usa CLSID únicos, relleno binario, compresión y tareas programadas en sus intrusiones, según lo reportado por ESET. Las convenciones de nombres usadas en su malware también son similares.
• Se sabe que APT32/OceanLotus usa muchos dominios e infraestructura únicos con una coincidencia mínima para ayudar a permanecer en los entornos por periodos prolongados, lo cual coincide con lo que hemos visto aquí.
• Se sabe que APT32/OceanLotus incorpora malware basado en Java en sus operaciones.
• APT32/OceanLotus ha usado anteriormente códigos de operación basura en su malware para desviar el análisis, además de ofuscación del flujo de control, según lo reportado por ESET.
• APT32/OceanLotus ha usado anteriormente el módulo OEM de McAfee para cargar lateralmente DLL maliciosas, según lo reportado por ESET.
• APT32/OceanLotus ha usado anteriormente servidores de Cobalt Strike detrás de Cloudflare, según lo reportado por Cybereason y Volexity
• APT32/OceanLotus ha usado anteriormente el binario de Apple Software Update para cargar lateralmente DLL maliciosas, según lo reportado por Recorded Future.
• APT32/OceanLotus ha usado anteriormente, de manera intensiva, certificados TLS de Let's Encrypt en su infraestructura, según lo reportado por Volexity.

Indicadores de compromiso

Mapeo de MITRE ATT&CK