Desenmascarando a VEILDrive: los actores de amenazas explotan los servicios de Microsoft para comando y control

Por el equipo de cazadores Axon

Resumen

• El equipo de cazadores AXON ha identificado y actualmente está monitoreando una campaña de amenazas en curso, denominada " VEILDrive ".
• La campaña se identificó originalmente como parte de un compromiso de AXON para abordar una actividad maliciosa identificada en la infraestructura de uno de nuestros clientes.
• Como parte de la investigación, identificamos diferentes componentes de infraestructura de Microsoft de organizaciones víctimas adicionales que fueron comprometidas y utilizadas por el atacante.
• El atacante aprovechó diferentes servicios y aplicaciones SaaS de Microsoft como parte de la campaña, incluidos Microsoft Teams, SharePoint, Quick Assist y OneDrive.
• El atacante utilizó un método de comando y control (C&C) único basado en OneDrive como parte del malware encontrado en la infraestructura de la víctima.
• Según las conclusiones de nuestra investigación, existe una probabilidad significativa de que esta campaña se origine en Rusia.
• El equipo AXON informó sus hallazgos a Microsoft para ayudar a cerrar la infraestructura del actor.
• El equipo también se puso en contacto con varias víctimas afectadas identificadas durante nuestra investigación.

Resumen ejecutivo

El equipo de Hunters, AXON, ha descubierto y está monitoreando activamente una campaña de amenazas en curso denominada "VEILDrive". VEILDrive, que se descubrió inicialmente durante una investigación de actividad maliciosa en la infraestructura de un cliente, aprovecha la suite SaaS de Microsoft (en particular Teams, SharePoint, Quick Assist y OneDrive) para ejecutar sus tácticas. De manera única, el actor de amenazas utiliza un método de comando y control (C&C) basado en OneDrive integrado en un malware personalizado que se implementa en entornos comprometidos. Nuestro análisis indica un probable origen ruso para esta campaña, y desde entonces el equipo AXON ha alertado tanto a Microsoft como a las organizaciones afectadas para mitigar una mayor explotación.

Nuestra investigación comenzó en septiembre de 2024, tras una respuesta a un ataque a una entidad de infraestructura crítica en los Estados Unidos. Las técnicas de ataque de VEILDrive difieren claramente del comportamiento típico de las amenazas. Dependen en gran medida de la infraestructura SaaS de Microsoft para distribuir campañas de phishing selectivo y almacenar software malicioso. Esta estrategia dependiente de SaaS complica la detección en tiempo real y elude las defensas convencionales.

El malware asociado con VEILDrive es un archivo .jar basado en Java que carece notablemente de ofuscación, lo que lo hace inusualmente legible y bien estructurado. A pesar de su simplicidad, el malware evadió la detección de una herramienta de detección y respuesta de endpoints (EDR) de primer nivel y de todos los motores de seguridad de VirusTotal. Esto pone de relieve un riesgo crítico: incluso un código sencillo y no ofuscado puede evadir los mecanismos de detección modernos, lo que sugiere una necesidad más amplia de revisar las estrategias de detección en entornos de alto riesgo.

Este informe proporciona información sobre las metodologías de VEILDrive y las limitaciones de los enfoques de detección actuales para equipar mejor a la comunidad de ciberseguridad contra las amenazas cambiantes.

Fondo

En septiembre de 2024, el equipo AXON respondió a un incidente que tenía como objetivo a una empresa de infraestructura crítica en los Estados Unidos. Esta investigación reveló una campaña de amenazas única, "VEILDrive", que mostró tácticas, técnicas y procedimientos (TTP) inusuales que se desviaban significativamente de los que se observan habitualmente en incidentes similares.

Según nuestros hallazgos, estimamos que la campaña VEILDrive comenzó a principios de agosto de 2024 y sigue activa al momento de este informe. Aprovechando los servicios SaaS de Microsoft (incluidos Teams, SharePoint, Quick Assist y OneDrive), el atacante explotó las infraestructuras confiables de organizaciones previamente comprometidas para distribuir ataques de phishing selectivo y almacenar malware. Esta estrategia centrada en la nube le permitió al actor de la amenaza evitar ser detectado por los sistemas de monitoreo convencionales.

Cabe destacar que VEILDrive introdujo un nuevo método de comando y control (C&C) basado en OneDrive integrado en un malware basado en Java implementado en los dispositivos afectados. El malware en sí, un archivo .jar, presenta dos características sorprendentes:

• Transparencia del código: con cero ofuscación y un código bien estructurado, este malware desafía la tendencia típica del diseño centrado en la evasión, lo que lo hace inusualmente legible y sencillo.
• Eficacia de sigilo: a pesar de su simplicidad, este malware no fue detectado ni por la solución de detección y respuesta de endpoints (EDR) de primer nivel implementada en el entorno de la víctima ni por todos los motores de seguridad de VirusTotal (consulte la Figura 1 a continuación):

Estas características ponen de relieve que, incluso sin técnicas de evasión sofisticadas, el malware cuidadosamente diseñado y no ofuscado puede evadir las defensas modernas. Esta investigación subraya una brecha en las estrategias de detección actuales y enfatiza la necesidad de estar alerta ante enfoques de ataque menos convencionales.

El equipo AXON ha compartido sus hallazgos con Microsoft y las organizaciones afectadas, ofreciendo inteligencia práctica para mitigar esta amenaza constante.

La ruta de ataque de VEILDrive

A principios de septiembre de 2024, uno de los clientes de Hunters, al que se hace referencia a continuación como "Org C", contactó al equipo AXON para obtener ayuda en la gestión de un incidente activo. El caso se centraba en un dispositivo específico dentro de Org C que había sido comprometido mediante ingeniería social.

Una tarea programada creada de forma sospechosa en el dispositivo de un empleado de la organización C activó una alerta, lo que dio lugar a una investigación más exhaustiva. Al correlacionar los registros y comunicarse con el usuario afectado, el equipo aclaró el método de acceso inicial.

A continuación se muestra un diagrama de ataque que proporciona una descripción general de alto nivel del flujo de ataque:

La secuencia de acontecimientos se desarrolló de la siguiente manera:

Paso 1

El actor malicioso aprovechó Microsoft Teams para enviar mensajes a cuatro empleados seleccionados de la organización C, quienes, además de no tener conocimientos técnicos debido a sus funciones, no tenían ninguna otra conexión aparente. El atacante se hizo pasar por un miembro del equipo de TI y solicitó acceso al dispositivo de cada empleado a través de la herramienta de utilidad remota Quick Assist .

En lugar de utilizar una cuenta recién creada para la suplantación de identidad, el atacante utilizó una cuenta de usuario comprometida de una posible víctima anterior, a la que aquí se hace referencia como "Org A".

Los registros de auditoría de M365 se utilizaron para identificar el phishing dirigido de Microsoft Teams.

• Se identificaron varios eventos “ MessageSent ” y “ ChatCreated ”, todos originados por el usuario previamente comprometido de Org A , propiedad del actor de amenazas.

• Si bien 4 empleados fueron atacados, solo se identificó un evento “ MemberAdded ” dirigido al usuario comprometido de Org A.

  
  

• Este evento “ MemberAdded ” fue realizado por la única cuenta de usuario de los 4 usuarios afectados que aceptaron la solicitud de acceso del actor de amenazas, lo que creó un chat individual. Esto significa que este usuario fue el único que interactuó activamente con el mensaje entrante.
• Esta información se alineó con los datos de telemetría EDR de la organización, lo que confirmó que el usuario no solo aceptó la solicitud y recibió el mensaje, sino que también permitió al atacante obtener acceso inicial gracias a una ingeniería social exitosa.

La información anterior fue interesante y valiosa, y puso de relieve la creciente prevalencia del phishing a través de Microsoft Teams y herramientas de comunicación similares. Distinguir entre intentos de phishing exitosos y fallidos mediante registros de auditoría de M365, junto con la correlación con registros de EDR, puede ser muy importante para las investigaciones.

Los mensajes de Microsoft Teams recibidos por los usuarios objetivo de Org C fueron posibles gracias a la funcionalidad " Acceso externo " de Microsoft Teams, que permite la comunicación uno a uno con cualquier organización externa de forma predeterminada.

Paso 2

El atacante logró engañar a la víctima de Org C para que ejecutara la herramienta Quick Assist de Microsoft y le proporcionó el código de acceso a través de Microsoft Teams. Esto permitió que el actor de amenazas accediera de forma interactiva a la computadora de la víctima.

Paso 3

El actor de amenazas luego compartió un enlace de descarga al SharePoint de una organización separada (la víctima pertenecía a un inquilino diferente al utilizado para el phishing a través del chat de Microsoft Teams, al que nos referiremos como "Org B"). Este enlace contenía un archivo .zip protegido con contraseña llamado Client_v8.16L.zip, que incluía varios archivos, entre ellos una herramienta RMM adicional.

El archivo fue descargado, probablemente a través de medios interactivos, por el atacante (que ya contaba con acceso remoto) operando bajo el contexto de explorer.exe, lo que le permitía hacer clic en el enlace y descargar las herramientas necesarias.

Vale la pena mencionar que durante la investigación, correlacionamos los registros de auditoría de M365, que proporcionaron información precisa sobre las URL entrantes en los mensajes de Microsoft Teams, con la telemetría EDR del host de la víctima para comprender completamente los TTP del atacante.

Paso 4

Se realizaron múltiples intentos de realizar operaciones maliciosas manuales a través del acceso remoto. Estas actividades implicaban principalmente esfuerzos de persistencia, como la creación de tareas programadas para ejecutar repetidamente uno de los archivos descargados por el atacante, una herramienta RMM llamada LiteManager ("ROMServer.exe").

schtasks /Create /TN "Perfomance monitoring" /SC MINUTE /TR C:\ProgramData\500000003\ROMServer.exe

Paso 5

Después de las actividades anteriores, el actor descarga manualmente otro archivo .zip llamado Cliento.zip.

Como antes, el enlace se compartió en el chat entre el usuario víctima y el actor de la amenaza. Este archivo .zip incluía el malware .JAR principal, así como todo el kit de desarrollo de Java para ejecutar el malware .JAR.

Paso 6

El actor de amenazas ejecutó el malware .JAR utilizando lo siguiente: C:\\ProgramData\\Cliento\\jdk-22_windows-x64_bin\\jdk-22.0.2\\bin\\javaw.exe -jar C:\\ProgramData\\Cliento\\Cliento.jar

Paso 7

Se identificaron múltiples actividades de red y ejecuciones de comandos en el contexto del archivo .JAR malicioso, entre ellas:

• Varias solicitudes DNS salientes/actividad de red a → safeshift390-my.sharepoint.com

• Varias solicitudes DNS salientes/actividad de red a → graph.microsoft.com

• Varias solicitudes DNS salientes/actividad de red a → login.microsoftonline.com

• Ejecución de comandos de enumeración local:

  • Obtener las especificaciones del sistema - Systeminfo
  • Obtener información del tiempo de la máquina - net time
  • Obtener el UUID de la máquina ( recuerde esto; lo discutiremos más adelante ) - Get-WmiObject -Class Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID
  • Enumeración de dispositivos USB - {$_.interfacetype -eq \"USB\"}"

  
  

La siguiente captura de pantalla muestra las partes principales del árbol de procesos relacionados con actividades maliciosas:

Paso 8

El atacante también agregó un binario JAR malicioso como clave de ejecución en el registro para la ejecución persistente del malware Java.

Línea de comando:

Set-ItemProperty -Path \"HKCU:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\" -Name \"current\" -Value \"C:\\ProgramData\\Cliento\\jdk-22_windows-x64_bin\\jdk-22.0.2\\bin\\javaw.exe -jar C:\\ProgramData\\Cliento\\Cliento.jar\" -ErrorAction Stop"

La contención y erradicación de este incidente fue muy rápida y efectiva, y de acuerdo con la evidencia forense que teníamos, no hubo indicios de que el atacante lograra causar algún daño significativo al host y la organización víctima.

Una idea clave del flujo de ataque detallado anteriormente es que el atacante utilizó diferentes servicios de Microsoft conocidos y comúnmente utilizados como parte de su ataque, tanto para ocultarse a simple vista como potencialmente también para su conveniencia.

Resumamos rápidamente los servicios de Microsoft utilizados por el actor de amenazas mediante la siguiente tabla:

En esta etapa, habíamos identificado los cuatro servicios/aplicaciones de Microsoft mencionados anteriormente. Si bien comprendíamos el propósito de los primeros tres, la actividad dirigida a Graph API seguía sin estar clara. Teníamos varias suposiciones sobre su propósito potencial, pero en la respuesta a incidentes, las suposiciones por sí solas no son suficientes, ¿no es así?

Para recopilar más información y comprender mejor el malware .JAR 'Cliento.jar' en OneDrive/SharePoint, tanto para evaluar las posibles acciones tomadas por el atacante como para obtener información sobre sus intenciones, procedimos a un análisis detallado del malware.

Malware de Java “ODC2”: OneDrive como comando y control

Utilizamos un descompilador de Java llamado “JDGUI” para descompilar el malware Client.jar (al que llamamos “ODC2”).

Con solo observar el malware a primera vista, pudimos correlacionarlo inmediatamente con la ejecución de PowerShell que vimos en la investigación del incidente. Esto se debe a la inclusión del paquete Java “ jPowerShell ”, un contenedor de PowerShell para Java.

Además, pudimos ver paquetes adicionales como “comandos”, “conexión”, “lanzador”, “o conectar”, etc. Esto nos proporcionó una comprensión de alto nivel de la estructura del malware.

1. Comenzamos con la clase Main.class del paquete “launcher” y encontramos un conjunto de credenciales codificadas que utiliza el malware. Esto nos sorprendió un poco, pero fue muy interesante.

   
   

Al analizar más a fondo el malware (como se describe en el análisis detallado a continuación), descubrimos que el malware utilizó estas credenciales para realizar una autenticación "en nombre" de Entra ID. Para realizar esta autenticación, se utilizó el token de actualización codificado de forma rígida con el ID y el secreto del cliente para solicitar un token de acceso.

La autenticación permitió que el malware accediera al OneDrive de usuarios específicos de Entra ID, en inquilinos supuestamente propiedad del actor, abusando de este acceso para fines C2.

2. En la función principal de Main.class podemos ver el punto de entrada propiamente dicho, que incluye múltiples hilos. Incluye la ejecución de las funciones “odThread1” y “mainThread1”.

   
   

“odThread1” incluye la ejecución de la función del controlador “odRun” que obtiene el primer conjunto de credenciales codificadas (token de actualización, etc.) para la autenticación.

• Utiliza la dirección IP “40.90.196.221” para la configuración de la conexión “odRun”

• La dirección IP “40.90.196.228” para “Run” inicializa el socket HTTPS al C2 del atacante. Esta IP también es la IP de Azure y es muy probable que sea una máquina virtual. Este canal C2, como se detalla a continuación, es más “clásico” y conduce a la ejecución de comandos de PowerShell.

• Para obtener más información sobre estas direcciones IP, consultamos recursos conocidos como ipinfo.io y las etiquetas de servicio de direcciones IP de Azure publicadas por Microsoft, como se muestra en la siguiente captura de pantalla:

  
  

  
  

• También vale la pena mencionar que la dirección IP codificada adicional que se encuentra en este malware (38.180.136.85) parece pertenecer a otro proveedor de servicios y está asociada con servicios de alojamiento. Según nuestros conocimientos, esta dirección IP no fue utilizada activamente por el malware. Suponemos que estaba allí por razones heredadas (infraestructura C2 anterior).

  
  

Zócalo HTTPS C2

3. Si analizamos un poco más en profundidad el “mainThread1()”, que ejecuta la función “ctrl.run()”, podemos ver que la función run() intenta crear una conexión y comprueba de forma rutinaria si la conexión está activa. Luego intenta ejecutar “parseCommand”, eliminando las partes irrelevantes.

   
   

4. Esta función "run" utiliza "connect()" para configurar o restablecer una conexión. Crea un socket a la dirección IP remota que vimos anteriormente: 40.90.196.228.

5. Esta función de “ejecución” utiliza “CommandManager”, que incluye diferentes manejos para los diferentes tipos de comandos/capacidades que proporciona este malware, incluida la transferencia de archivos del cliente al servidor y del servidor al cliente, compresión de archivos, capturas de pantalla, cierre de conexiones de red y, por supuesto, ejecución de comandos.

   
   

Comprueba si el comando recibido está vacío o si se recibió un comando real del servidor C2.

6. Si se encuentra un comando, lo analiza y lo ejecuta. La ejecución se realiza básicamente en el contexto de PowerShell.

   
   

   La ejecución del comando entrante como un comando de PowerShell se lleva a cabo utilizando el contenedor jPowerShell que mencionamos anteriormente.

Comando y control de OneDrive

Antes de profundizar en la funcionalidad básica de OneDrive C2, es importante señalar que partes críticas del código del malware dependen en gran medida de tres "tipos" específicos de archivos de OneDrive: UUID, cf_UUID y rf_UUID. Como se observó en nuestra investigación, se ejecutó el comando Get-WmiObject -Class Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID , lo que reveló el UUID del hardware del dispositivo. Este identificador único sirve para distinguir a cada víctima en la campaña VEILDrive.

Cada tipo de archivo desempeña una función distinta en las operaciones del malware. La siguiente captura de pantalla ofrece ejemplos de estos archivos y sus funciones principales en la ejecución del malware.

Profundicemos en el flujo de la funcionalidad de OneDrive C2 y cómo se utilizan esos archivos UUID en la práctica:

7. Además de las clásicas capacidades de ejecución remota a través de PowerShell, la función “odRun” es responsable de otro hilo basado en “OneDrive” como canal de comunicación. Esta es la parte única de este malware.

   
   

   El “odRun” tal como lo vemos, probablemente lleva el nombre de “OneDrive” (OneDriveRun), e incluye la creación de una conexión OneDrive utilizando la función “Odconnect” como primer paso:

   
   

8. Como puede ver, primero se establece la cadena “machineUUID” como una cadena vacía. A continuación, se ejecuta la función “getMachineUUID()”, que, como su nombre indica, obtiene el UUID de la máquina del dispositivo víctima:

   
   

9. Luego podemos ver que la conexión de OneDrive se está realizando mediante la función “OdConnect”: la conexión se está realizando a “login[.]microsoftonline[.]com” para la creación/actualización de un conjunto de nuevos tokens de acceso y tokens de actualización.

   
   

10. La función “WriteFileToOneDrive” es la siguiente que se llama, siempre y cuando no haya ningún archivo con el UUID de la máquina víctima actual en la computadora de destino, según una verificación realizada por la función “checkFile”.

• "checkFile": esta función verifica si hay un archivo llamado == machineUUID en la carpeta de inicio del usuario actual OneDrive

  
  

11. Si no existe dicho archivo, “writeFileToOneDrive()” entra en el juego y crea un archivo con el UUID de la computadora de la víctima actual sin ningún prefijo.

12. La siguiente parte de “odRun” es la función “getFiles()” que obtiene el contenido del UUID.

Archivo de OneDrive cuyo nombre es el UUID de la máquina del dispositivo (sin prefijos).

• Si el contenido del archivo no está vacío, verifica si comienza con la palabra “enviar”:
  • Realiza cierta normalización del contenido, preparándolo para las próximas comprobaciones, eliminando la cadena “send” y reemplazando “\”“ con “” (nada) y guardándolo en una variable llamada “ filenameForDownload ”
  • Se pasa filenameForDownload a la función getFileDownloadUrl . Esta obtiene el archivo elegido por el atacante. El atacante especificaría el nombre del archivo después de la palabra "send" en el archivo UUID y lo guardaría en la ruta de destino especificada en la máquina víctima, que es "user.home"\downloads (la carpeta de descargas).
  • A continuación, se llama a la función “ downloadFile ”, que descarga el archivo remoto al dispositivo víctima local, según la salida de la función getFileDownloadUrl .
  • El atacante obtiene una indicación sobre la ejecución del archivo usando " writeFileToOneDrive ", que se ejecuta justo después como parte de "odRun" para escribir lo siguiente "rf_" + "send file" + filenameForDownload + "done" → para que el atacante sepa que se realizó la ejecución. Después de eso, hay otra ejecución de "writeFileToOneDrive", en la que se escribe otro archivo, llamado "cf_" + machineUUID en OneDrive, sin ningún contenido en él.
• Si el contenido del archivo no está vacío pero no comienza con “enviar”:

  • Se ejecutará el contenido del archivo cf_MachineUUID.

  • Seguido nuevamente escribiendo un archivo en OneDrive, usando “ writeFileToOneDrive ”, primero “rf_“ + machineUUID, con el contenido de la respuesta de ejecución.

  • Y otro uso de “ writeFileToOneDrive ”, para escribir y vaciar el archivo “cf_”, básicamente evitando otra ejecución del mismo comando (ya que el malware se ejecuta en un bucle).

    
    

Para resumir brevemente, este malware parece tener dos canales C2 diferentes con los que puede trabajar:

• HTTPS Socket C2 : un enfoque más clásico, que recibe comandos desde una máquina virtual remota de Azure y los ejecuta en el contexto de PowerShell.

• C2 basado en OneDrive : es más exclusivo y su funcionamiento es un poco más complejo y creativo. Incluye tres archivos diferentes, todos ellos con el UUID del dispositivo víctima, algunos con prefijos (rf_ y cf_), para facilitar al actor de amenazas el envío y recepción de comandos mediante Microsoft Graph.

  
  

  Nota : Es importante mencionar que este malware tiene capacidades adicionales además de la ejecución de comandos estándar, incluida la transferencia de archivos. Sin embargo, la información detallada anterior se centra únicamente en el aspecto de ejecución de comandos.

  
  

Servicios y aplicaciones de Microsoft como infraestructura del atacante

En este punto, está claro que este ataque combinó hábilmente técnicas simples con tácticas sofisticadas y únicas. Una característica destacada de nuestra investigación inicial fue el uso extensivo de la infraestructura y los servicios de Microsoft integrados en toda la campaña.

Después de analizar el malware y correlacionar la nueva información con los resultados de nuestra investigación, obtuvimos una comprensión más clara del uso que el atacante hacía de los distintos servicios y sus propósitos. Descubrimos que el uso de los servicios y la infraestructura de Microsoft era incluso más amplio de lo que pensábamos inicialmente.

Vea la siguiente tabla para ver un breve resumen:

Indicadores de compromiso (IOCS)

• Inquilinos de Entra ID conocidos que son propiedad del atacante:
  • C5f077f6-5f7e-41a3-8354-8e31d50ee4d
  • 893e5862-3e08-434b-9067-3289bec85f7d
• Aplicaciones conocidas registradas por los ID de cliente del atacante:
  • B686e964-b479-4ff5-bef6-e360321a9b65
  • 2c73cab1-a8ee-4073-96fd-38245d976882
• Inquilinos de ID de entrada utilizados por el atacante (busque solicitudes DNS salientes hacia esos dominios):
  • SafeShift390[.]onmicrosoft[.]com
  • GreenGuard036[.]onmicrosoft[.]com
• Archivo IOCs (SHA256) encontrado como parte de la investigación:
  • ROMServer.exe a515634efa79685970e0930332233aee74ec95aed94271e674445712549dd254
  • HookDrv.dll 1040aede16d944be8831518c68edb14ccbf255feae3ea200c9401186f62d2cc4
  • ROMFUSClient.exe 7f61ff9dc6bea9dee11edfbc641550015270b2e8230b6196e3e9e354ff39da0e
  • AledensoftIpcServer.dll d6af24a340fe1a0c6265399bfb2823ac01782e17fc0f966554e01b6a1110473f
  • ROMwln.dll 7f33398b98e225f56cd287060beff6773abb92404afc21436b0a20124919fe05
• Direcciones IP:
  • 40.90.196[.]221
  • 40.90.196[.]228
  • 38.180.136[.]85
  • 213.87.86[.]192

Consultas de búsqueda de amenazas

Además de los IOC específicos mencionados anteriormente, creamos múltiples consultas de búsqueda de amenazas que se pueden usar para detectar ataques originados por el mismo actor, realizados bajo la misma campaña o que comparten características similares (TTP).

Nota: El período de caza recomendado para VEILDrive es a partir de julio de 2024.

CONSULTA DE CAZA 1 : Javaw genera Powershell con indicadores específicos: comportamiento inusual

• Lógica de consulta: durante nuestro análisis, identificamos que la herramienta de acceso remoto (RAT) del atacante utilizó PowerShell para obtener el UUID de la máquina como parte de su proceso de ejecución. Esta consulta detecta instancias inusuales de PowerShell generadas por javaw.exe con los indicadores de línea de comandos específicos utilizados por el actor de la amenaza.

• Consulta:

   SELECT EVENT_TIME, AGENT_ID, PARENT_PROCESS_NAME, PARENT_PROCESS_COMMANDLINE, INITIATING_PROCESS_NAME, INITIATING_PROCESS_COMMANDLINE, TARGET_PROCESS_NAME, TARGET_PROCESS_COMMANDLINE, TARGET_PROCESS_OS_PID FROM INVESTIGATION.EDR_PROCESS_CREATION_EVENTS WHERE 1=1 AND PARENT_PROCESS_NAME ILIKE '%javaw%' AND INITIATING_PROCESS_NAME ILIKE '%cmd%' AND TARGET_PROCESS_NAME ILIKE '%powershell%' AND TARGET_PROCESS_COMMANDLINE ILIKE 'powershell.exe -ExecutionPolicy Bypass -NoExit -NoProfile %' AND EVENT_TIME > current_timestamp - interval '60d'

  
  

CONSULTA DE CAZA 2: Persistencia de la herramienta ROM a través de tareas programadas

• Lógica de consulta: esta consulta detecta instancias de una tarea programada que se registra con la ejecución de una herramienta ROM utilizada por el actor de amenazas para la persistencia.

• Consulta:

   SELECT EVENT_TIME AS EVENT_TIME, AID AS AGENT_ID, CID AS COMPUTER_ID, EVENT_SIMPLE_NAME AS EVENT_NAME, RAW:TaskName AS TASK_NAME, RAW:TaskExecCommand AS TASK_EXEC_COMMAND, RAW:TaskAuthor AS TASK_AUTHOR, RAW:UserName AS USER_NAME --- Adjust according to your EDR of choice FROM RAW.CROWDSTRIKE_RAW_EVENTS WHERE EVENT_SIMPLE_NAME = 'ScheduledTaskRegistered' AND TASK_EXEC_COMMAND ILIKE '%romserver%' AND EVENT_TIME > CURRENT_TIMESTAMP - interval '60d'

CONSULTA DE BÚSQUEDA 3 : Usuarios no pertenecientes a la organización que comparten vínculos a dominios de SharePoint de terceros a través de Microsoft Teams

• Lógica de consulta: esta consulta detecta casos en los que se comparte un vínculo de SharePoint en un chat de Teams, pero el dominio del vínculo de SharePoint no pertenece a ninguno de los participantes del chat. Esto podría indicar un posible intento de phishing o exfiltración de datos, donde se utiliza un dominio externo para compartir archivos o información con usuarios desprevenidos dentro de la organización.
• Consulta:

 SET YOUR_ORGANIZATION_NAME = 'hunters'; SELECT EVENT_TIME, ORGANIZATION_ID AS ORG_ID, OPERATION AS EVENT_TYPE, SPLIT_PART(LOWER(SPLIT_PART(USER_ID, '@', 2)), '.', 1) AS SENDER_ORG_DOMAIN, RECORD_SPECIFIC_DETAILS:message_ur_ls AS MESSAGE_URLS, WORKLOAD AS WORKLOAD, USER_ID AS USER_ID, RECORD_SPECIFIC_DETAILS:chat_thread_id AS CHAT_THREAD_ID, RECORD_SPECIFIC_DETAILS:communication_type AS COMMUNICATION_TYPE, RECORD_SPECIFIC_DETAILS:members[0].DisplayName AS MEMBER_DISPLAY_NAME, RECORD_SPECIFIC_DETAILS:members[0].UPN AS MEMBER_UPN, RECORD_SPECIFIC_DETAILS:members[0] AS MEMBERS, RECORD_SPECIFIC_DETAILS:resource_tenant_id AS RESOURCE_TENANT_ID, RECORD_SPECIFIC_DETAILS FROM RAW.O365_AUDIT_LOGS WHERE NOT USER_ID ILIKE '%' || $YOUR_ORGANIZATION_NAME || '%' AND (NOT (MESSAGE_URLS ILIKE '%' || SENDER_ORG_DOMAIN || '%') AND MESSAGE_URLS ILIKE '%sharepoint%') AND NOT MESSAGE_URLS ILIKE '%' || $YOUR_ORGANIZATION_NAME || '%' AND EVENT_TIME > CURRENT_TIMESTAMP - interval '60d'

CONSULTA DE BÚSQUEDA 4 : Microsoft Teams - Detección de phishing - Múltiples mensajes directos de dominios no comunes

• Lógica de consulta: la siguiente consulta detecta mensajes enviados en un chat individual por usuarios externos desde dominios no comunes. La consulta filtra los dominios de uso generalizado en función de la actividad histórica e identifica a los miembros externos agregados a los chats que pueden estar realizando ataques de phishing.

• Consulta:

   SET YOUR_DOMAIN_NAME = 'hunters'; --- GET EXTERNAL TEAMS AND ONEDRIVE USERS OF THE LAST 3 MONTHS - TO CLEAN EXTENSIVELY USED DOMAINS WITH COMMONLY_USED_DOMAINS AS ( SELECT LOWER(SPLIT_PART(USER_ID , '@', 2)) AS DOMAIN_COMMONLY_USED, MIN(EVENT_TIME) AS MIN_EVENT_TIME, MAX(EVENT_TIME) AS MAX_EVENT_TIME, ARRAY_AGG(DISTINCT OPERATION) AS OPERATIONS, COUNT(*) AS COUNTER FROM RAW.O365_AUDIT_LOGS WHERE WORKLOAD IN ('MicrosoftTeams', 'OneDrive') AND EVENT_TIME > CURRENT_TIMESTAMP - interval '90d' AND USER_ID ILIKE '%@%' GROUP BY DOMAIN_COMMONLY_USED HAVING COUNTER > 20 ), ---- Get List of External Domains that recently communicated with our organization using Microsoft Teams LATEST_EXTERNAL_DOMAINS AS ( SELECT USER_ID AS LATEST_EXT_USERS, LOWER(SPLIT_PART(USER_ID , '@', 2)) AS USER_DOMAIN, MIN(EVENT_TIME) AS MIN_EVENT_TIME, MAX(EVENT_TIME) AS MAX_EVENT_TIME, ARRAY_AGG(DISTINCT OPERATION) AS OPERATIONS, ARRAY_AGG(DISTINCT RECORD_SPECIFIC_DETAILS:communication_type) AS COMMUNICATION_TYPE, COUNT(*) AS COUNTER FROM RAW.O365_AUDIT_LOGS WHERE EVENT_TIME > CURRENT_TIMESTAMP - interval '50d' AND NOT USER_ID ILIKE '%' || $YOUR_DOMAIN_NAME || '%' AND NOT USER_ID IN ('app@sharepoint') AND USER_ID ILIKE '%@%' -- CLEAN-UP OF EXTENSIVELY USED DOMAINS AND USER_DOMAIN NOT IN (SELECT DISTINCT DOMAIN_COMMONLY_USED FROM COMMONLY_USED_DOMAINS) AND OPERATION IN ('MemberAdded', 'ChatCreated') AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne' GROUP BY USER_ID HAVING COUNT(*) > 5 ) SELECT EVENT_TIME, ORGANIZATION_ID AS ORG_ID, WORKLOAD AS WORKLOAD, OPERATION AS OPERATION, USER_ID AS USER_ID, LOWER(SPLIT_PART(USER_ID , '@', 2)) AS USER_DOMAIN, RECORD_SPECIFIC_DETAILS:chat_thread_id AS CHAT_THREAD_ID, RECORD_SPECIFIC_DETAILS:communication_type AS COMMUNICATION_TYPE, RECORD_SPECIFIC_DETAILS:members[0].DisplayName AS MEMBER_DISPLAY_NAME_0, RECORD_SPECIFIC_DETAILS:members[0].UPN AS MEMBER_UPN_0, RECORD_SPECIFIC_DETAILS:members[0] AS MEMBERS_0, RECORD_SPECIFIC_DETAILS:members[1].DisplayName AS MEMBER_DISPLAY_NAME_2, RECORD_SPECIFIC_DETAILS:members[1].UPN AS MEMBER_UPN_2, RECORD_SPECIFIC_DETAILS:members[1] AS MEMBERS_2, RECORD_SPECIFIC_DETAILS:resource_tenant_id AS RESOURCE_TENANT_ID, RECORD_SPECIFIC_DETAILS, RAW:ClientIP AS CLIENT_IP FROM RAW.O365_AUDIT_LOGS WHERE 1=1 AND RECORD_SPECIFIC_DETAILS:communication_type = 'OneOnOne' AND ( RECORD_SPECIFIC_DETAILS:members[0].UPN IN (SELECT LATEST_EXT_USERS FROM LATEST_EXTERNAL_DOMAINS) OR RECORD_SPECIFIC_DETAILS:members[1].UPN IN (SELECT LATEST_EXT_USERS FROM LATEST_EXTERNAL_DOMAINS) ) AND USER_ID ILIKE '%' || $YOUR_DOMAIN_NAME || '%' AND OPERATION = 'MemberAdded' AND EVENT_TIME > CURRENT_TIMESTAMP - interval '50d';

• Lógica de consulta detallada: dado que esta consulta es un poco compleja, a continuación se ofrece una explicación de la lógica. Primero, utilizamos la función “CTE” de Snowflake para construir dos vistas:

  1. DOMINIOS DE USO COMÚN:
     • Extraemos los nombres de dominio del ID de usuario dividiendo la cadena después del '@'.
     • Cuente todos los eventos generados por cada dominio durante los últimos 90 días
     • Mantén los dominios que tengan más de 20 eventos y considéralos comunes. Puedes ajustar esto según tus necesidades.
  2. ÚLTIMOS DOMINIOS EXTERNOS:
     • Filtrar los dominios internos y los dominios de uso común identificados en la vista anterior de todos los eventos de los últimos 50 días
     • Consulta todos los dominios que tengan más de 5 eventos que involucren envío de mensajes directos y adiciones de miembros a Teams.

  Finalmente, recuperamos información detallada sobre el usuario y su dominio asociado consultando los resultados filtrados de LATEST_EXTERNAL_DOMAINS.

  
  

Consejos de higiene

Abordamos aspectos de búsqueda e investigación relacionados con las múltiples técnicas de ataque utilizadas por el actor. También se sabe que algunos de esos métodos y técnicas maliciosos se utilizan en diferentes campañas.

Proteger a su organización de esas amenazas puede reducir significativamente el riesgo de que se produzcan ataques exitosos dirigidos a diferentes partes de su infraestructura organizacional.

A continuación se presentan algunos consejos de higiene que se pueden utilizar para mejorar su postura de seguridad:

1. Para reducir las posibilidades de que se produzcan ataques de phishing exitosos a través de Microsoft Teams, puede seguir estos pasos:
   • De forma predeterminada, Microsoft Teams permite el “Acceso externo”, que permite chats individuales con contactos externos. Si esto no es esencial para su organización, considere deshabilitar esta opción.
   • Si es necesaria la comunicación externa, limítela únicamente a dominios confiables.
   • Otra forma de comunicarse con terceros en Microsoft Teams es agregarlos como invitados o miembros. Recomendamos enfáticamente restringir esta función y permitir que solo usuarios selectos y con privilegios elevados puedan administrarla.
2. El aumento de los ciberataques que utilizan herramientas de administración remota exige una distinción clara entre las herramientas que se utilizan de forma legítima y las que explotan los actores de amenazas. A continuación, se ofrecen algunas recomendaciones:
   • Limite las herramientas de administración remota a aplicaciones específicas aprobadas que sean necesarias para fines comerciales. Quick Assist se puede descargar fácilmente desde Microsoft Store; considere bloquear su uso si no está en la lista blanca de su organización. Puede restringir el acceso aplicando medidas como AppLocker, reglas de Firewall de Windows o administración de MDM.
   • Realice un seguimiento de las herramientas de administración remota que se utilizan con frecuencia y controle si hay herramientas de terceros inusuales o no autorizadas. Por ejemplo, si se utiliza Quick Assist y su equipo de TI no depende de él para recibir asistencia remota, debería activar una alarma.
3. Capacitación en concienciación sobre seguridad: puede parecer un cliché, pero los errores humanos son siempre una de las principales razones del éxito de los ciberataques. La capacitación en concienciación sobre seguridad puede marcar la diferencia en este sentido, protegiéndolo de la próxima vulneración.
   • Recomendamos que se centre en las amenazas que se observan en la red y que sean relevantes para ellas. Por ejemplo, los casos de suplantación de identidad de personal de TI a través de plataformas de comunicación como Microsoft Teams, Slack o incluso llamadas telefónicas tradicionales están aumentando. Asegúrese de que sus empleados sepan cómo abordar esta situación.

Conclusión

• VEILDrive combina simplicidad y sofisticación. Fue interesante observar el uso de las características clásicas de C2 en paralelo con C2 sobre OneDrive, así como el uso de la persistencia clásica basada en tareas programadas combinada con la ejecución de malware que un EDR de primera categoría no detecta.

• Las características identificadas como parte de la investigación y el estudio de amenazas fueron interesantes y nos permitieron comprender mejor cómo funciona este actor de amenazas, qué servicios conocidos está abusando, cómo los está abusando y con qué propósito.

• La forma en que se abusó de OneDrive para la comunicación C2 en VEILDrive tenía características únicas. Sin embargo, el concepto general de abuso de OneDrive para fines C2 ha aumentado en los últimos meses y es algo que se debe tener en cuenta.

• El acceso inicial a través de spear-phishing en plataformas de comunicación como Microsoft Teams, Slack y servicios similares es cada vez más común.

• Prevemos que se volverá aún más común a medida que pase el tiempo. Por lo tanto, las medidas de higiene y postura relacionadas con este aspecto (como se menciona en los consejos de higiene anteriores) son cruciales.

• Las herramientas de administración remota ya son muy populares entre los actores de amenazas. Se pueden adoptar diferentes enfoques para minimizar la posibilidad de acceso no autorizado mediante dichas herramientas. Desde nuestro punto de vista, el enfoque recomendado en esta área es la inclusión en listas blancas (listas de permitidos) combinada con una supervisión sólida.

• Prevemos que surgirán más campañas de esta naturaleza, que empleen métodos y características similares, por lo que se recomienda encarecidamente realizar un seguimiento continuo y una búsqueda proactiva de amenazas de este tipo.

  
  

Para mantenerse actualizado sobre las investigaciones, actividades y consultas sobre búsqueda de amenazas, siga la cuenta X/Twitter del Equipo Axon ( @team__axon ).