Sintiéndose Blue(Noroff): dentro de una sofisticada intrusión de Corea del Norte en Web3

Resumen

El 11 de junio de 2025, Huntress recibió contacto de un socio indicando que un usuario final había descargado, potencialmente, una extensión maliciosa de Zoom. La profundidad de la intrusión se hizo evidente de inmediato al instalar el agente Huntress EDR, y tras algo de análisis, se descubrió que el señuelo usado para obtener acceso había sido recibido por la víctima varias semanas antes.

Esta publicación busca ofrecer un análisis detallado de principio a fin de la intrusión, incluyendo un desglose completo de varias piezas nuevas de malware usadas por los actores de amenazas.

Atribuimos con alta confianza que esta intrusión fue realizada por el subgrupo APT norcoreano (RPDC) rastreado como TA444, también conocido como BlueNoroff, Sapphire Sleet, COPERNICIUM, STARDUST CHOLLIMA, o CageyChameleon—un actor de amenazas patrocinado por un estado conocido por atacar criptomonedas desde al menos 2017.

Figura 1: Visualización de la cadena de ataque

Acceso inicial

La configuración:

Un empleado de una fundación de criptomonedas recibió un mensaje de un contacto externo en su Telegram. El mensaje solicitaba tiempo para hablar con el empleado, y el atacante envió un enlace de Calendly para programar una reunión. El enlace de Calendly era para un evento de Google Meet, pero al hacer clic, la URL redirigía al usuario final a un dominio falso de Zoom controlado por el actor de amenazas.

Figura 2: Archivo de invitación de reunión .ics enviado al empleado bajo la apariencia de una reunión de Google

Varias semanas después, cuando el empleado se unió a lo que terminó siendo una reunión grupal de Zoom, esta contenía varios deepfakes de líderes sénior conocidos dentro de su empresa, junto con contactos externos. Durante la reunión, el empleado no pudo usar su micrófono, y los deepfakes le dijeron que había una extensión de Zoom que necesitaba descargar.

El enlace a esta “extensión de Zoom” enviado por Telegram era hxxps[://]support[.]us05web-zoom[.]biz/troubleshoot-issue-727318. El archivo descargado resultó ser un AppleScript (el lenguaje de scripting integrado de Apple) llamado zoom_sdk_support.scpt.

Figura 3: Carga útil inicial enviada a la víctima - zoom_sdk_support.scpt

Este AppleScript primero abre una página web legítima para SDKs de Zoom, pero después de más de 10,500 líneas en blanco, descarga una carga útil desde un sitio web malicioso, https[://]support[.]us05web-zoom[.]biz, y tras completar la descarga, ejecuta un script. Aunque no pudimos recuperar esta segunda etapa de la intrusión, encontramos una versión en VirusTotal que brinda buena información sobre lo que sucede a continuación.

El script comienza deshabilitando el registro del historial de bash y luego verifica si Rosetta 2, que permite a los Mac con Apple Silicon ejecutar binarios x86_64, está instalado. Si no lo está, lo instala silenciosamente para asegurar que las cargas útiles x86_64 puedan ejecutarse. Luego crea un archivo llamado .pwd, que queda oculto a la vista del usuario debido al punto que lo antecede, y descarga la carga útil desde la página falsa y maliciosa de Zoom a /tmp/icloud_helper.

Figura 4: Deshabilitar el registro, instalar Rosetta 2 y descargar binario

A continuación, realiza otra solicitud curl usando el agente de usuario cur1-request. Esto se ha observado en intrusiones previas de BlueNoroff, como la cubierta por Kaspersky en 2022. Lamentablemente, esta carga útil tampoco estaba activa al momento del análisis.

Figura 5: Imprimiendo el “progreso” al extraer la carga útil descargada

Luego intenta obtener la contraseña del usuario y verificarla usando sudo. Continuarán haciendo esto hasta que se proporcione una contraseña válida.

Figura 6: Intentando verificar la contraseña del usuario

Por último, elimina el historial del shell, para que los usuarios no sepan qué se ejecutó. Durante nuestra investigación, notamos que estos archivos de historial habían sido modificados en el momento del ataque.

Figura 7: script bash eliminando el historial del shell

Análisis técnico

Al final de nuestra investigación, recuperamos 8 binarios maliciosos diferentes del endpoint de la víctima. Cubriremos la funcionalidad de algunos de estos binarios en esta sección. Para resumir rápidamente qué es cada uno:

• Telegram 2: el binario persistente, escrito en Nim, responsable de iniciar el backdoor principal.
• Root Troy V4 (remoted): backdoor con todas las funciones, escrito en Go, usado para descargar las otras cargas útiles y ejecutarlas. 
• InjectWithDyld (a): un cargador de binarios escrito en C++ que es descargado por Root Troy V4. Descifrará dos cargas útiles adicionales.
• Base App: Una aplicación benigna de Swift en la que se inyecta código.
• Carga útil: Un implante diferente escrito en Nim, con capacidad de ejecución de comandos.
• XScreen (keyboardd): un keylogger escrito en Objective-C con capacidad de monitorear pulsaciones de teclas, el portapapeles y la pantalla.
• CryptoBot (airmond): un infostealer escrito en Go diseñado para recopilar archivos relacionados con criptomonedas del endpoint.
• NetChk: un binario casi vacío que generará números aleatorios para siempre.

La mayoría de los implantes, con excepción de los escritos en Nim, contenían artefactos de compilación que mostraban los nombres de usuario de quienes compilaron los binarios. Había 4 personas responsables de diferentes herramientas:

Figura 8: Nombres de usuario de las máquinas del atacante responsables de compilar ciertas herramientas

Implante persistente: Telegram 2

El implante central responsable de ejecutar todos los demás componentes se llama Telegram 2 y está escrito en Nim. Persiste desde /Library/LaunchDaemons/com.telegram2.update.agent.plist, ejecutando un binario en /Library/Application Support/Frameworks/Telegram 2. El binario está firmado de manera adhoc con el identificador root_startup_loader_arm64.

Telegram 2 se usó como el mecanismo de persistencia, iniciando cada hora, con el siguiente plist:

Figura 9: com.telegram2.update.agent LaunchDaemon 

Configuración

Al ejecutarse, este binario crea un archivo de configuración en /private/var/tmp/cfg. Lamentablemente, no pudimos recuperar este archivo de la máquina de la víctima.

Funcionalidad

Este binario es muy pequeño y solo tiene unas pocas funcionalidades:

• poEchoCmd: ejecuta un comando echo (prueba)
• poEvalCommand: ejecuta un comando usando /bin/bash
• poInteractive: genera un shell interactivo
• poDaemon: inicializa la persistencia

Backdoor: Root Troy V4 (remoted)

Este binario, que se encontró ejecutándose desde /Library/WebServer/bin/remoted, es un backdoor con todas las funciones escrito en Go. Los artefactos de compilación muestran que en realidad se llama “Root Troy V4” o “RTV”.

El uso principal que observamos para este binario fue ejecutar una carga útil de AppleScript para descargar y ejecutar otro implante (cubierto en la siguiente sección). Este comando se ejecutó 6 veces desde que el cliente se incorporó hasta que el endpoint fue aislado.

Figura 11: remoted descargando con curl implantes adicionales

Configuración

El binario almacena información asociada, como su configuración, versiones de carga útil y comandos de inicio, en un directorio ubicado en /Library/Google/Cache/. El archivo de configuración (.cfg) está cifrado con una clave RC4 (3DD226D0B700F33974F409142DEFB62A8CD172AE5F2EB9BEB7F5750EB1702E2A) encontrada en el binario. Contiene la información de C2 junto con IDs de usuario (editados aquí).

Figura 12: Contenido del archivo de configuración

También hay un archivo de versión (.version) cifrado con otra clave RC4 (C4DB903322D17C8CBF1D1DB55124854C0B070D6ECE54162B6A4D06DF24C572DF). Contiene la información de versión de dos de las cargas útiles usadas más adelante: {"cbot":"1.0.1","rt":"4.0.1"}.

El archivo .startup contiene comandos que deben ejecutarse cada vez que un usuario inicia sesión. Comenzará a ejecutar el binario de keylogging y uno de los binarios contenidos en el archivo .version:

Figura 13: Contenido del archivo de script .startup

Ejecución principal

Cuando se ejecuta la función principal, primero crea el directorio para almacenar los archivos de configuración:

Figura 14: Creando el directorio de configuración

Luego intenta cargar la información de C2 desde dentro del binario, que cubrimos en la última sección. Si por alguna razón esto falla, terminarán el proceso actual, eliminarán los artefactos y saldrán.

Figura 15: Autoeliminación si falla la extracción de la configuración

Después de verificar que la configuración está en orden, y que no hay otras instancias ejecutándose usando el archivo PID, ejecutará dos nuevos hilos: la función execStartup, que ejecuta el script detallado anteriormente, y logoutMonitor, que vigila si el usuario cierra sesión. Si eso sucede, activará execStartup nuevamente.

Figura 16:  Nuevos hilos para ejecutar el script y monitorear el cierre de sesión

Finalmente, entra en un bucle infinito que recopila los /Volumes del sistema, así como la lista de procesos en ejecución. Estos se envían al servidor C2 periódicamente usando la función sendRequest .

Capacidad: Ejecución remota de código

Hay varias formas diferentes en que un operador puede ejecutar comandos en el endpoint usando este malware:

• execScript: ejecuta una carga útil remota de AppleScript usando osascript -e.
• execShell: ejecuta un comando de shell usando /bin/zsh -sc
• execShellDetached: ejecuta un comando de shell usando /bin/zsh -sc en segundo plano

Capacidad: Ejecución durante el reposo

Para evitar cualquier caso en que un usuario pueda observar que se ejecuta código, los comandos están envueltos por una función checkSleep que consulta el estado de la pantalla. Si la pantalla está en reposo, los comandos se ejecutan; de lo contrario, se ingresan en una cola para ejecución posterior. Para lograr esto, usan system_profiler SPDisplaysDataType y buscan el campo Online.

Figura 17: Ejemplo de salida al consultar system_profiler SPDisplaysDataType

Comunicaciones con el C2

Las solicitudes al C2 se envían a http://$DOMAIN/update y contienen la información del endpoint recopilada usando la función host.PlatformInformationWithContext de la biblioteca github.com/shirou/gopsutil/. También proporciona el tiempo de arranque y las versiones de los otros implantes actualmente en ejecución.

Cargador: InjectWithDyld (a)

Como se mencionó antes, el binario llamado a fue descargado por remoted usando la carga útil de AppleScript. La contraseña encontrada en esa secuencia de descarga es necesaria para que este binario funcione correctamente, ya que se usa para derivar las claves AES para el descifrado de la carga útil. Para revisar rápidamente qué hizo el actor de amenazas con este binario:

Figura 18: Script ejecutado por remoted para instalar y ejecutar a

Este binario hace principalmente dos cosas: en la primera, toma otro binario y una contraseña como argumentos y descifra las cargas útiles embebidas. En la segunda, simplemente toma el argumento --d y sobrescribirá todos los archivos en el directorio actual con ceros como medida antiforense. Los actores primero ejecutaron la carga útil con los parámetros ./cloudkit y una contraseña de gift123$%^.

Función de derivación de claves

Para descifrar tanto la carga útil como la aplicación base, la contraseña proporcionada se usa con una Función de Derivación de Claves Basada en Contraseña (PBKDF) para derivar claves AES.

Figura 19: Descompilación de la contraseña proporcionada a la función de derivación de claves

La sal se antepone a la carga útil real; en el caso de baseApp, es la cadena decodificada en base64 GJM0bP36hbomz9Gw.

Figura 20: Sal antepuesta a la carga útil en base64

Descifrado de la carga útil

Después de derivar la clave, la muestra descifra las dos cargas útiles usando una versión modificada de AES-CFB. Pasan el contenido decodificado en base64, omitiendo los bytes de sal, y la clave a la función AesEncrypt.

Figura 21: Descompilación de la decodificación base64 de la carga útil y omisión de los primeros 16 bytes (sal)

Iteran a través del base64 decodificado y llaman a AesTrans en cada bloque, el cual cifra el buffer usando AES; esta salida luego se somete a XOR contra el original, resultando en el contenido descifrado.

Figura 22: Implementación de AES-CFB

Figura 23: Descompilación de la rutina de descifrado

Esto ocurre para ambos blobs en base64, que luego se usan en la parte de inyección de procesos.

Inyección de procesos

Por mucho, la parte más interesante de este malware es cómo despliega la carga útil maliciosa. Cualquiera que haya trabajado con Windows está extremadamente familiarizado con la técnica de inyección de procesos, en la que un proceso escribe código en la memoria de otro proceso. Pero, históricamente, la inyección de procesos no ha sido común en macOS porque hay una gran cantidad de requisitos previos necesarios para eludir las protecciones de memoria de Apple.

¡Esta muestra aprovecha algunos casos límite en el modelo de seguridad de Apple para permitir la inyección! Los binarios que quieren hacer esto necesitan un permiso de herramienta de depuración(s), que les permite adjuntarse a otros procesos y, más importante aún, obtener task ports. Este binario, y varios de los otros usados en esta intrusión, tienen esto:

• com.apple.security.cs.debugger
• com.apple.security.get-task-allow

Después de descifrar la carga útil, el malware verificará los bytes mágicos del archivo macho resultante. Si son 0xbebafeca es un ejecutable FAT (es decir, un binario ARM y uno x86_64 unidos), por lo que debe iterar sobre las entradas del encabezado FAT hasta encontrar el encabezado macho x86_64. De lo contrario, si los bytes mágicos son 0xfeedfacf, es simplemente un macho x86_64 y eso no es necesario, por lo que puede llamar directamente a la rutina de inyección. El mismo proceso ocurre para el ejecutable ARM, pero busca un cputype de CPU_TYPE_ARM64.

Figura 24: Preparación para llamar al código de inyección de procesos

Luego comienza el proceso de inyección, llamando a InjectAMD64, como se ilustra en la siguiente figura:

Figura 25: Descompilación de la función InjectAMD64 con posix_spawnattrs

Para iniciar el proceso de inyección, se genera un nuevo proceso con los atributos configurados previamente. Luego se llama a task_for_pid en el proceso, que devolverá el Mach port del proceso. Tener acceso a este puerto permite al malware utilizar las APIs de mach_vm, permitiendo la manipulación arbitraria de memoria y la gestión de tareas.

Figura 26: Descompilación de la obtención de un Mach port en el proceso sacrificial

A partir de ahí, obtienen una lista de hilos asociados con el proceso usando task_threads. Si eso tiene éxito, comienzan a analizar el encabezado mach-o de la carga útil descifrada. Este es un proceso muy similar a cómo deciden si llamar o no a la rutina de inyección para un binario FAT. Hacen esto para encontrar el número total de segmentos en el binario de la carga útil.

Figura 27: Análisis del mach-o de la carga útil en preparación para la copia

En este punto, el malware comienza a copiar los segmentos del binario de la carga útil al proceso sacrificial y modifica la memoria para permitir la ejecución. El siguiente código descompilado muestra cómo se modificaron los permisos de página para lectura y escritura, como se ve en la función _mac_vm_protect , donde la variable new_protection se establece en 3 (VM_PROT_READ | VM_PROT_WRITE).

Figura 28: Descompilación de las modificaciones de protección de memoria por segmento

Después de realizar las modificaciones de memoria mencionadas, el proceso en reposo se restaura con la carga útil inyectada, como se ve en la siguiente figura:

Figura 29: Descompilación de la restauración del proceso en reposo para ejecutar la carga útil inyectada

Limpieza de carga útil

Después de que se desplegaron las cargas útiles, el actor luego ejecutó el binario usando la bandera --d que llama a la función ZeroWrite. Esto itera sobre todos los archivos en el directorio actual, y escribirá bytes nulos sobre todas las funciones contenidas.

Cargas útiles descifradas: implante Nim (Trojan 1) & Base App 

Como se mencionó, hay dos binarios descifrados por el paso anterior.

Implante Nim (Trojan 1)

El implante Nim se usa principalmente para enviar comandos de forma interactiva hacia y desde el endpoint infectado. El archivo principal se llama trojan1.nim y permite al operador emitir comandos y recibir respuestas de forma asíncrona. Para comunicarse con el C2 usa websockets wss[:]//firstfromsep[.]online/client.

El análisis de este binario sigue en curso y la publicación se actualizará cuando se complete.

Base app

La aplicación base es un binario relativamente escueto, escrito en Swift por el autor dominic.

Figura 30: Artefactos de compilación del ejecutable base

El método principal simplemente ejecuta una tarea simple en bucle (cada 3.37 segundos).

Figura 31: Método principal de la aplicación base

La tarea simplemente imprime la cadena Current: YYYY-MM-DD HH:MM:SS en /dev/null. Esto probablemente solo sirve para mantener el binario activo, de modo que pueda ser inyectado en algún momento futuro si es necesario.

Figura 32: Closure llamado por el método principal

Keylogger: XScreen (keyboardd)

Este binario se usa para keylogging, grabación de pantalla y recuperación del portapapeles. Está escrito en Objective-C y fue compilado por un usuario llamado pooh.

Figura 33: Artefactos de compilación del binario keyboardd

Para iniciar la ejecución, primero verificará si existe el archivo /Users/Shared/._cfg, que contiene la URL del C2. Por defecto usa el servidor https[:]//metamask[.]awaitingfor[.]site/update, pero en este caso era el mismo que la URL encontrada en el archivo ._cfg recuperado.

Figura 34: Descompilación de la resolución del C2

Acepta 3 posibles argumentos de línea de comandos:

• -u: usar un dominio C2 personalizado
• -c: cuánto tiempo dormir entre capturas de pantalla
• -p: si se debe monitorear el portapapeles

En el caso de esta intrusión, fue invocado repetidamente por el binario remoted con el argumento -p.

La forma general en que funciona este binario es iniciando 3 bucles asíncronos, uno para cada tipo de recolección. El primer bucle enviará el contenido del buffer de keylog al servidor C2:

Figura 35: Descompilación del bucle asíncrono 1

El segundo llama a la función MonitorClipboared (sic) en un bucle:

Figura 36: Callback de MonitorClipboared

El último es responsable de la funcionalidad de recolección de pantalla discutida en la siguiente sección.

Funcionalidad de keylogging 

La funcionalidad real de keylogging se implementa usando la biblioteca Core Graphics con la API EventTapCreate. Esta API toma una función de callback que se ejecutará cada vez que se registre un evento de pulsación de tecla.

Figura 37: Bucle de la función de keylogging

Lo primero que hace la función de callback es mantener un registro de qué aplicación se estaba usando en cada pulsación de tecla. Hacen esto consultando frontmostApplication y obteniendo el identificador del paquete de esa aplicación. Si es diferente de la última llamada, registrarán el nombre de la aplicación y la hora en el buffer de keylog:

Figura 38: Función de callback verificando qué ventana activa se está usando

Después de eso, verificarán si el código de tecla es un carácter imprimible. Si es uno especial (control, comando, etc.) lo convertirán a una representación de texto y luego lo añadirán al buffer de keylog:

Figura 39: Conversión de caracteres no imprimibles a una representación de texto

Figura 40: Salidas de conversión

Funcionalidad de captura de pantalla

Para capturar las pantallas, el malware entra en un bucle infinito que verifica el número de pantallas activas usando CGGetActiveDsiplayList. Si hay al menos una pantalla activa, comenzará a capturar datos, y si hay más de una, iterará sobre todas las pantallas disponibles para capturar cada una.

Figura 41: Descompilación de la función controladora de la grabación de pantalla

La función CaptureAndSend es responsable de recopilar realmente los datos. Toma una imagen de la pantalla usando la API CGDisplayCreateImage, y luego guarda ese contenido en un archivo ubicado en /private/tmp/google_cache.db. Si eso tiene éxito, convertirá la imagen a base64 y añadirá la letra “I” para que el C2 pueda distinguir qué datos son una imagen. Finalmente, usa la misma función SendData para enviar todo al servidor C2.

Durante nuestra investigación, no encontramos ningún dato almacenado en la ubicación de guardado de archivos.

Figura 42: Descompilación de la función CaptureAndSend

Funcionalidad de portapapeles

Para monitorear el portapapeles, simplemente toman el pasteboard del sistema y luego extraen el contenido de texto de ese objeto. El bucle infinito monitoreará si ha habido un cambio en el contenido del portapapeles y, de ser así, escribirá el contenido en el buffer de keylog compartido.

Figura 43: Descompilación del código de monitoreo del portapapeles

Envío de datos

Para enviar los datos al servidor C2, crean una cadena que contiene un UUID, el uid de la víctima, los datos, el nombre de usuario, y un token embebido en el binario:

Figura 44: Envío de datos al servidor C2

Infostealer: CryptoBot (airmond)

El binario airmond es un infostealer con todas las funciones, enfocado en el robo de criptomonedas. Está escrito en Go y tiene una gran cantidad de artefactos de compilación que muestran que se trata de un proyecto llamado CryptoBot compilado por un usuario chris.

Figura 45: Artefactos de compilación del binario airmond

Configuración

Al igual que el otro malware en este incidente, CryptoBot hace uso de varios archivos en su directorio actual

• /Library/AirPlay/.pid: Un archivo PID para prevenir múltiples instancias.
• /Library/AirPlay/.cache: Un caché para almacenar datos de criptomonedas recopilados.
• /Library/AirPlay/.CFUserTextEncoding: Usuario y una clave (user|key)
• /Library/Google/Cache/.cfg: Configuración compartida con el binario “Root Troy V4”.
• /Library/Google/Cache/.version: Información de versión compartida con el binario “Root Troy V4”. 

Los archivos de configuración en el directorio AirPlay están cifrados usando AES-CFB con un IV de 0. La clave es estática y está embebida en el binario f6102a492570dee84bbc9ebd8bd7bfab4e442eae3b416b1a. Se usan varias funciones de inicialización para crear los archivos mencionados anteriormente:

• main.initializeCryptoCache
• main.initializeUserInfo
• main.initializeVersion
• main.writePid

Y hay otro conjunto de funciones para cargar esos archivos de configuración mientras se ejecuta:

• main.loadUserInfo
• main.loadVersions
• main.writeCryptoCache
• main.readCryptoCache

Crypto Stealer

El propósito principal de este binario es indexar información relacionada con criptomonedas del endpoint. Como es típico en los stealers para hacer esto, iteran sobre las extensiones de navegador instaladas buscando plugins de billeteras. Si se encuentran, llama a una serie de funciones auxiliares diseñadas para extraer la información sensible de esas extensiones. Todas están contenidas en el módulo crypto-bot:

• crypto-bot/wallet.ExtractAddressInfosFromBinance
• crypto-bot/wallet.ExtractAddressInfosFromBitget
• crypto-bot/wallet.ExtractAddressInfosFromCoin
• crypto-bot/wallet.ExtractAddressInfosFromKeplr
• crypto-bot/wallet.ExtractAddressInfosFromLeather
• crypto-bot/wallet.ExtractAddressInfosFromMetamask
• crypto-bot/wallet.ExtractAddressInfosFromNabox
• crypto-bot/wallet.ExtractAddressInfosFromOKX
• crypto-bot/wallet.ExtractAddressInfosFromPhantom
• crypto-bot/wallet.ExtractAddressInfosFromPhantom.Println.func1
• crypto-bot/wallet.ExtractAddressInfosFromRabby
• crypto-bot/wallet.ExtractAddressInfosFromRainbow
• crypto-bot/wallet.ExtractAddressInfosFromRonin
• crypto-bot/wallet.ExtractAddressInfosFromSafepal
• crypto-bot/wallet.ExtractAddressInfosFromSender
• crypto-bot/wallet.ExtractAddressInfosFromStation
• crypto-bot/wallet.ExtractAddressInfosFromSubwallet
• crypto-bot/wallet.ExtractAddressInfosFromSui
• crypto-bot/wallet.ExtractAddressInfosFromTon
• crypto-bot/wallet.ExtractAddressInfosFromTron
• crypto-bot/wallet.ExtractAddressInfosFromTrust
• crypto-bot/wallet.ExtractAddressInfosFromUnisat
• crypto-bot/wallet.ExtractAddressInfosFromXverse

Interacción con el C2

El binario interactúa con un C2 en productnews[.]online usando HTTP. Las solicitudes se cifran usando la misma clave y algoritmo usados para cifrar los archivos de configuración. También hay una opción para enviar paquetes sin cifrar si es necesario:

• main.postEncryptedData
• main.postToServer

Identificación y mitigación de ingeniería social en aplicaciones de reuniones

Los trabajadores remotos, especialmente en áreas de trabajo de alto riesgo, suelen ser los objetivos ideales para grupos como TA444. Es importante capacitar a los empleados para identificar ataques comunes que comienzan con ingeniería social relacionada con software de reuniones remotas:

• Ten cuidado con las invitaciones de calendario marcadas con urgencia de personas con las que no te has comunicado en algún tiempo, o grupos de personas que normalmente no están en reuniones juntas.
• Los usuarios deben sospechar inmediatamente de cambios repentinos y poco naturales, como cambiar de plataforma de reunión a último minuto, una solicitud para instalar una “extensión” o “plugin”, nombres de TLD poco populares como .biz, .xyz, .site, .online, o .click, y solicitudes para habilitar acceso remoto o controles similares.
• Aconseja a los empleados que, ante cualquiera de estos indicadores, o incluso incertidumbre, desconecten el software de reuniones de inmediato y lo reporten a sus equipos de seguridad, RR.HH. y otros equipos.

Conclusión

Históricamente, macOS ha sido visto como un objetivo más pequeño en comparación con su contraparte Windows. Junto con el dicho de que “las Mac no se infectan con virus” que ha permeado el espacio durante las últimas dos décadas, a menudo se consideran como “que no requieren protección.” Debido a estos sentimientos, esto comprensiblemente se traduce en ataques más dirigidos. En los últimos años, hemos visto que macOS se convierte en un objetivo mayor para los actores de amenazas, especialmente en lo que respecta a atacantes altamente sofisticados y patrocinados por estados.

En este caso, vimos a BlueNoroff utilizando técnicas específicas para Mac en un ataque muy dirigido. Aprovecharon AppleScript, que es exclusivo de macOS, múltiples implantes, keyloggers y capturas de pantalla. Además, capturaban el contenido del portapapeles, limpiaban el historial de su sesión, y también buscaban una amplia variedad de billeteras de criptomonedas, demostrando su enfoque en macOS.

A medida que estos ataques y la frecuencia con la que ocurren continúan en aumento, será cada vez más importante proteger tus Mac. Como vimos aquí, los atacantes no solo usaron técnicas de ataque comunes y multiplataforma, sino que aprovecharon binarios, APIs y funcionalidades específicas de Mac.

IOCs

Archivos

Infraestructura