MacSync bajo el microscopio: nuevos métodos de distribución y carga útil

MacSync es una familia de stealers de criptomonedas e información relativamente joven y en desarrollo activo. La publicidad de las primeras versiones, bajo el nombre Mac.c, apareció en la darknet en 2025; más tarde, los atacantes la renombraron como MacSync. Las primeras versiones se implementaron como scripts de AppleScript y se parecen, en gran medida, a la familia de stealers AMOS; sin embargo, con el tiempo, MacSync desarrolló características propias, entre ellas un módulo de puerta trasera. En este informe, describimos la nueva cadena de infección, que presenta cambios significativos respecto a las modificaciones anteriores y a las que identificamos en entornos reales por primera vez en septiembre de 2026.

Puntos clave:

• Los autores de la familia revisaron su enfoque de distribución de la carga maliciosa y sustituyeron los droppers basados en scripts por droppers binarios.
• La carga maliciosa principal ahora está compuesta por módulos en Objective-C y Swift.
• En una de las etapas de la infección, los atacantes usan la infraestructura de iCloud para entregar la siguiente etapa.

Las soluciones de Kaspersky detectan las amenazas descritas a continuación con los siguientes veredictos:

• HEUR:Trojan.OSX.MacSync.*
• HEUR:Trojan-PSW.OSX.MacSync.*
• HEUR:Trojan-Dropper.OSX.MacSync.*
• HEUR:Trojan-Downloader.OSX.MacSync.*

Detalles técnicos

Cadena de infección

MacSync es un infostealer distribuido bajo el modelo MaaS (Malware as a Service), por lo que el método específico de entrega de la primera etapa de la cadena de infección queda a cargo de los operadores. Los informes públicos más recientes sobre MacSync se han centrado en módulos distribuidos mediante ingeniería social y ataques tipo ClickFix; sin embargo, tanto en ese momento como en la actualidad, el malware también se distribuye disfrazado de versiones gratuitas o crackeadas de aplicaciones conocidas, así como de software que dice ser nuevo. Por ejemplo, identificamos a MacSync distribuyéndose bajo la apariencia de la billetera de criptomonedas inexistente Toria: los atacantes no solo crearon una página web dedicada a ella, sino que también la promovieron en la red social X y en el mensajero Telegram:

La versión más reciente del infostealer que se ha identificado inicia la cadena de infección a partir de imágenes de disco maliciosas en formato DMG. Además, incluso dentro de una campaña que usa una sola aplicación falsa, identificamos dos variantes de entrega de los módulos de infostealer y puerta trasera en el dispositivo de la víctima. En una de ellas, dentro del DMG, el papel de la carga maliciosa lo desempeñaba un script JXA compilado que, tras ejecutarse, decodificaba un script de shell y lo pasaba directo al intérprete, sin escribirlo en disco. En la otra versión de la aplicación, el mismo script aparecía en una etapa más avanzada de la infección, después de ejecutarse la cadena de droppers y cargadores. Analizaremos la segunda cadena de infección, por ser más compleja e interesante desde el punto de vista técnico. El esquema general de infección se muestra a continuación.

Vale la pena señalar desde ya que, en casi todas las etapas, MacSync presenta características comunes:

• Todos los archivos temporales se colocan en el directorio /tmp. En él también se crean archivos *.lock, destinados a impedir la ejecución repetida de la carga maliciosa.
• Después de completar su tarea, el módulo elimina los rastros: archivos temporales, sus propios registros, etc.
• Todos los binarios están en formato Fat Mach-O y están dirigidos a dispositivos con procesadores tanto de Apple como de Intel.

Cargador, calendario y dos droppers

En esta cadena de infección, la carga maliciosa presente en la imagen de disco es una aplicación .APP. Al ejecutarse, primero verifica si todo el paquete tiene el atributo extendido de cuarentena com.apple.quarantine y, si lo encuentra, ejecuta el comando xattr -cr <app_name> para eliminar todos los atributos. A continuación, extrae de su propia superposición una URL cifrada con el algoritmo XOR y la descifra usando la clave 73 6f 6e 6f 6d 61 62 6c 64 07. Después de los datos cifrados hay 8 bytes que indican la longitud del texto cifrado, seguidos de la palabra mágica SONOMAC1. Cabe destacar que el malware lee la superposición al revés: primero localiza la palabra mágica, luego lee el tamaño de los datos y, con base en ese tamaño, determina los límites del bloque de datos que contiene el texto cifrado.

La URL obtenida es el enlace al siguiente script cargador. En algunos casos, apuntaba a un archivo alojado en un servidor controlado por los atacantes; sin embargo, en al menos una muestra, el enlace dirigía a un calendario público de iCloud:

Contenido del calendario descargado

Después de obtener el archivo de calendario del servidor, el cargador crea un canal anónimo, inicia el intérprete en modo de lectura de comandos desde la entrada estándar (zsh -s), define ese canal creado como entrada estándar y redirige hacia él, línea por línea, el contenido del calendario. Como el calendario no suele ser un comando, el intérprete tratará las líneas como comandos inválidos hasta llegar a la carga maliciosa, ubicada después de la línea DESCRIPTION:. Se trata de comandos que, en última instancia, provocan la descarga desde iCloud de un archivo tar.gz que contiene un paquete .APP. El cargador le elimina el atributo de cuarentena, lo firma con una firma ad hoc y lo ejecuta.

No conocemos el contenido de los scripts distribuidos desde el servidor del atacante, pero es muy probable que se trate del mismo script presente en la descripción del evento del calendario.

La aplicación que se descarga es un dropper. La carga maliciosa que extrae es un ejecutable comprimido con el algoritmo ZLIB y cifrado con AES en modo CBC (Cipher Block Chaining), con la siguiente clave y vector de inicialización:

El dropper lo descifra, lo descomprime y lo coloca en la ruta /tmp/.sys-<16-digit random value>.

Dentro hay otro dropper, pero, a diferencia de las etapas anteriores, este cuenta con protección antidepuración. En particular, verifica si se está ejecutando en una máquina virtual mediante llamadas sysctl con los parámetros kern.hv_vmm_present y machdep.cpu.brand_string, además de establecer la bandera PT_DENY_ATTACH mediante ptrace, lo que impide la conexión de un depurador al proceso. La carga útil es un script de shell cifrado con AES en modo CBC, con la siguiente clave y vector de inicialización:

Carga útil maliciosa del segundo dropper

Como se observa en la captura de pantalla anterior, el segundo dropper entrega un script cargador que obtiene del servidor de C2 la carga maliciosa de la siguiente etapa, la descifra con AES en modo CBC usando la siguiente clave y vector de inicialización, y luego la ejecuta en memoria:

Un par de scripts más

Dentro del script que se obtiene, podemos identificar de inmediato varios indicadores conocidos, característicos del malware de la familia MacSync:

• La función principal del script se llama daemon_function.
• La carga de los datos robados al servidor de C2 se realiza mediante solicitudes PUT. Los datos se envían en las solicitudes en bloques de 90 megabytes. En versiones anteriores, los tamaños de los bloques eran diferentes.
• Uno de los métodos de persistencia en el sistema es la inyección de un comando malicioso en .zshrc, el archivo de configuración del intérprete ZSH que contiene los comandos que deben ejecutarse cada vez que se inicia el intérprete.
• La ruta de URL donde se aloja el ejecutable de la puerta trasera en el servidor de C2 comienza con el directorio /loader/.

El script realiza las siguientes tareas:

• Descarga y descifrado de módulos maliciosos adicionales: el infostealer, la puerta trasera y una utilidad especial para generar claves de cifrado y descifrar los ejecutables descargados.
• Persistencia de la puerta trasera en el sistema.
• Carga al servidor de C2 de los datos obtenidos por el módulo infostealer.

Cabe destacar un detalle interesante: en lugar de los algoritmos de cifrado habituales (XOR, AES, etc.), los atacantes recurrieron a un enfoque diferente para la entrega de los módulos maliciosos en esta etapa, en el que participa la utilidad pkgunpack creada por ellos, que implementa dos comandos: genkey y decrypt. El descifrado de la carga maliciosa se realiza de la siguiente manera:

1. El malware genera las claves de cifrado pública y privada mediante el comando genkey de pkgunpack; la función de generación utiliza una implementación de código abierto del protocolo Diffie-Hellman sobre la curva elíptica Curve25519, curve25519_donna.
2. La clave pública se codifica en base64 y se envía al servidor de C2 junto con un código de un solo uso generado por el comando $(date +%s)-${RANDOM}-$$.
3. Como respuesta, el servidor devuelve el siguiente JSON:
   
   { "ok": true, "dek_wrap_b64": <base64_encoded_encrypted_key> , "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=", "crypto": "v2.5" }

   1 2 3 4 5 6

   {     "ok": true,     "dek_wrap_b64":  <base64_encoded_encrypted_key> ,     "build_pub_b64": "pFSxn/Uwg9bS45aVKCzA+8exSMfDHXpbpHC/f7G472w=",     "crypto": "v2.5" }

   
   Aquí, build_pub_b64 es la clave pública del servidor, también predefinida en el propio script, y dek_wrap_b64 es una cadena codificada en base64 que contiene la clave de cifrado de la carga útil. Esta clave se cifra en el servidor con un secreto compartido, calculado a partir de la clave pública generada por pkgunpack en el dispositivo de la víctima.
   A continuación, mediante la llamada al comando decrypt de pkgunpack se realiza el descifrado de la clave.
   1. A partir de la clave pública conocida del servidor y de la clave privada de la sesión actual, se calcula el secreto compartido mediante la misma implementación del esquema de intercambio de claves ECDH Curve25519 usada para generar las claves.
   2. El secreto compartido obtenido se concatena con la cadena sn-dek-wrap-v1, y se calcula el hash SHA-256 del resultado.
   3. A continuación, se decodifica el bloque dek_wrap_b64 recibido del servidor. Tiene la siguiente estructura:
      1. Los primeros 5 bytes son los datos adicionales autenticados (AAD)
      2. Los siguientes 12 bytes son el vector de inicialización (IV)
      3. A continuación, el texto cifrado.
   4. El texto cifrado se descifra mediante AES en modo GCM usando la clave, el IV y el AAD que se habían obtenido antes.
      

      Bloque dek_wrap_b64 decodificado

4. El resultado obtenido es la clave para descifrar la carga maliciosa descargada. Esta, a su vez, también contiene AAD e IV en su encabezado, y está cifrada con AES GCM. La utilidad la descifra y finaliza su ejecución.

Cabe señalar que, en cada etapa, la utilidad rellena los búferes con ceros después de usar las claves de cifrado y los datos, al parecer con el fin de dificultar la recolección de evidencia forense y el análisis dinámico de las muestras.

Como se mencionó antes, en esta etapa el script descarga solo dos módulos: el infostealer y la puerta trasera. Ambos, una vez descifrados, son archivos en formato .tar.gz cuyo contenido se extrae, se limpia de todos los atributos extendidos (como com.apple.quarantine) y se firma con una firma ad hoc. Primero se ejecuta el módulo infostealer: recopila los datos de su interés, los coloca en una carpeta temporal y los comprime en un archivo .tar.gz, que el script luego envía al servidor de los atacantes. Después, antes de iniciar la puerta trasera, el script le asegura la persistencia y también crea una copia de seguridad de ella. La copia de seguridad, junto con los demás archivos necesarios para su funcionamiento, se almacena en $HOME/Library/Application Support/System. Ese directorio no existe en macOS por defecto: lo crea el script. La puerta trasera se disfraza de aplicación Finder y se mantiene persistente en el sistema de las siguientes maneras:

• Mediante el uso de un agente de inicio automático (LaunchAgent) con el nombre com.apple.finder.agent
• La inyección de un comando que ejecuta el script .repair-run al iniciar el intérprete ZSH desde .zshrc
• La inyección de un comando similar, que también ejecuta el script .repair-run, en los hooks globales de GIT pre-commit y post-checkout

El script .repair-run verifica la existencia de los archivos de la puerta trasera, los restaura desde la copia de seguridad si están ausentes, y vuelve a crear y reiniciar el agente de inicio automático, mientras finaliza los procesos del sistema BTMNotificationAgent, NotificationCenter y BackgroundTaskManagementAgent para impedir que el sistema notifique la adición de un nuevo agente de inicio automático.

Lo último que vale la pena destacar sobre el funcionamiento del script en esta etapa es el uso de un encabezado HTTP personalizado, X-Upload-Token, sin el cual el servidor de C2 responderá a las solicitudes con errores. Durante la investigación, observamos el uso de los siguientes tokens: b8b4b88205a8f594b95a841bc37342898f34cad8a5a9e4a22ce69a31a1208650 y ff3ab9ef841630364818396f62e696b72aed162cf0b895b6643ef25dad79b51d. Estos mismos tokens son utilizados también por la puerta trasera para comunicarse con el servidor de C2.

Infostealer

El módulo infostealer se distribuye como una aplicación .APP, cuyo ejecutable principal está escrito en Swift. Igual que en las versiones anteriores en AppleScript, el malware primero solicita al usuario la contraseña de administrador. Para ello, adapta la ventana que se muestra para que se parezca a la de la aplicación que está imitando. Después de introducir la contraseña, el usuario ve una ventana que imita una notificación del sistema sobre una aplicación dañada, con la sugerencia de moverla a la papelera.

Ventanas emergentes falsas del stealer

Es interesante que, en lugar del método característico de la mayoría de las familias de malware para macOS para verificar la contraseña introducida (mediante la utilidad dscl), los atacantes utilizaron la API de los módulos de autenticación conectables (PAM). Se trata de una técnica bastante nueva para el malware de macOS, utilizada por primera vez en entornos reales en julio de 2026 en la familia Pam Stealer. Al parecer, esta técnica despertó el interés de los autores de malware, y es posible que la veamos con mayor frecuencia en el futuro.

Verificación de la contraseña mediante PAM

Muchas cadenas (nombres de archivos, directorios, teamid, etc.) en el stealer están cifradas con el algoritmo XOR y se almacenan en arreglos estáticos. Las claves de cifrado varían entre las muestras y se generan en función de la longitud del texto cifrado.

Descifrado de cadenas

El conjunto de datos que recopila el stealer se amplió un poco respecto a las versiones anteriores. La lista general es la siguiente:

• Información de los navegadores: historial, archivos de cookies, datos de extensiones de billeteras de criptomonedas, inicios de sesión y contraseñas guardados, archivos Local State
• Datos de aplicaciones de billeteras de criptomonedas
• Datos de Telegram
• Nombre de usuario y contraseña del dispositivo
• Archivo del llavero
• Información del sistema: lista de aplicaciones instaladas y procesos en ejecución, modelo del dispositivo, hardware, UUID, etc.
• Archivos de configuración de SSH, ZSH, AWS, Kubernetes, GIT y otros servicios/programas
• Historial de comandos de los intérpretes ZSH y Bash
• Avatar del usuario actual

Los datos recopilados se guardan en un directorio oculto dentro de /tmp/.

El módulo stealer también incluye una función interesante que, en todas las muestras identificadas hasta el momento, está desactivada y, al parecer, aún se encuentra en desarrollo. Su tarea es verificar si el archivo KcHelper está presente en los recursos de la aplicación maliciosa, en la ruta <app_path>/Contents/Resources/Helpers, y, si lo está, ejecutarlo con parámetros específicos. En caso de que este archivo no exista, se ejecuta la función alternativa _kc_grab_storage_item. Dado que, al momento de la investigación, KcHelper no estaba presente en los recursos de la aplicación, solo podemos suponer su propósito a partir del análisis de esta función. En ella, primero se ejecuta un comando que modifica el partition_id de una entrada del llavero para un servicio determinado, de modo que el acceso a esta pueda otorgarse sin confirmación del usuario y sin la contraseña del llavero a tres categorías de aplicaciones:

• teamid: la aplicación está firmada con un certificado con un teamID específico (en este caso, el del desarrollador de la aplicación objetivo)
• apple: la aplicación es un servicio de Apple
• apple-tool: la aplicación es una utilidad de línea de comandos de Apple

Luego, el stealer intenta obtener el contenido del secreto por sí mismo mediante la API de Security.framework, lo cual, al final, de todos modos genera una solicitud de confirmación de la operación. Al parecer, los atacantes planean, en el futuro, mejorar esta función para obtener acceso sin restricciones a los secretos incluso si se cambia la contraseña del llavero, pero no lo logran por ahora, y por eso la función está desactivada. En las cadenas cifradas del stealer, vimos ejemplos de argumentos para el comando que modifica el partition_id, los cuales indican que los atacantes están interesados en los secretos de los navegadores, por ejemplo:

Fragmento de código responsable de modificar el acceso a los servicios en el llavero

Puerta trasera

La puerta trasera es un ejecutable Fat Mach-O escrito en Objective-C. Tiene dos modos de ejecución: el normal y el que usa la bandera --persist-status. En el segundo caso, solo verifica de qué manera se agregó a los elementos de inicio automático: mediante un elemento de inicio de sesión (Login Item) o un agente de inicio automático (LaunchAgent). En el modo estándar, antes de pasar a ejecutar su funcionalidad principal, la puerta trasera también verifica si ya está persistente de alguna manera. Si no lo está, se ejecuta el mismo mecanismo de persistencia que en el script principal; sin embargo, para versiones de macOS anteriores a 13.0, más allá de la presencia de elementos de inicio automático, se usa un ejecutable auxiliar independiente, almacenado en el propio cuerpo de la puerta trasera. Este auxiliar tiene una única tarea: mediante la API de CoreServices.framework, agrega el ejecutable que se le pasa como argumento a los elementos de inicio de sesión.

De manera similar a los droppers de las primeras etapas de la cadena de infección, la configuración de comunicación con el C2 se almacena en la superposición del ejecutable y se cifra con XOR usando la misma clave. Consiste en varias cadenas separadas por bytes nulos:

• AGNT1: constante mágica que confirma que la configuración se descifró con éxito
• URL del servidor de C2
• Token de acceso: el mismo que en el script principal
• BLD-150: número de compilación de la puerta trasera

El malware también escribe registros en la ruta $HOME/Library/Logs/.sysnotif-agent.log y admite registros detallados al ejecutarse con la variable de entorno LAUNCHER_DEBUG. La comunicación con el C2 se realiza mediante el protocolo HTTP. Como respuesta, el servidor debe devolver un JSON. A continuación se muestra una tabla con las solicitudes al servidor de C2 y su descripción:

Aunque la puerta trasera ofrece varios comandos distintos, todos se reducen, en esencia, a una sola acción: extraer del campo script_b64, en la respuesta del servidor, un script de AppleScript codificado en base64 y ejecutarlo. En este caso, los controladores de cada comando actúan como wrappers sobre los scripts, que completan con éxito la telemetría y realizan las solicitudes al servidor de C2. A partir de los nombres de los comandos y de los mensajes enviados al servidor durante su ejecución, podemos reconstruir su significado sin tener acceso directo a los scripts. La puerta trasera admite los siguientes comandos:

• deploy_ext: inyecta en el navegador del usuario una extensión descargada del servidor.
• deploy_ledger: sustituye la billetera Ledger instalada por una versión obtenida del servidor.
• regrab: vuelve a recopilar información del sistema o archivos específicos. En este caso, los datos recopilados se almacenan en el archivo característico de la familia MacSync, en la ruta /tmp/osalogging.zip, a menos que se indique otra ruta en el campo archive_path enviado junto con el comando.
• live_browser es el único comando que se ejecuta sin la intervención de scripts de AppleScript. La puerta trasera verifica la presencia del archivo sn_relay en sus recursos y, si no lo encuentra, lo descarga y lo ejecuta. Su contenido y propósito siguen siendo un misterio para nosotros; sin embargo, a juzgar por el nombre del comando y los mensajes enviados al servidor, podemos suponer que, de alguna manera, los atacantes implementan un ataque MitM sobre el tráfico proveniente del navegador de la víctima.

Fragmento del comando regrab en el que, antes de enviar el archivo, se verifica su integridad y se calcula la suma de hash

Conclusión

La nueva versión del infostealer MacSync difiere bastante de sus modificaciones anteriores. Los atacantes revisaron su enfoque para la ejecución de la carga maliciosa principal del stealer y de la puerta trasera, y pasaron de scripts de AppleScript a ejecutables completos, escritos en Swift y Objective-C. También vale la pena destacar la cadena de infección, que se volvió más compleja: en lugar de scripts de shell ofuscados que se entregan mediante ataques tipo ClickFix, en esta versión se usaron droppers y cargadores binarios, incluido el uso de la infraestructura de Apple como una de las etapas intermedias de entrega de la carga maliciosa.

La naturaleza de los datos que interesan a los atacantes, recopilados del dispositivo de la víctima, así como las categorías de aplicaciones bajo las que se disfraza el stealer, indican que la familia está dirigida a desarrolladores, entusiastas de las criptomonedas y otros usuarios relacionados de alguna manera con TI y el ámbito cripto. El compromiso de los dispositivos de los desarrolladores de software por parte de la familia MacSync representa riesgos de seguridad particulares tanto para los usuarios finales como para los sistemas corporativos, lo que abre a los atacantes posibilidades ampliadas de avance adicional.

Indicadores de compromiso

Cargador de la primera etapa
26a0f7cdb9f7dc5ace9a40af825b1538
2d69812584269699fade26622e6490c5
7df1049cbd56c0bfa4a3364a379b4c2c
9f15fe9c4415cd668334339f705b94d8
fb90887592655a8c989e443c640167aa
6791dad263cac6d63ebba6a4b57e7d71

Calendario malicioso (segunda etapa)
3ded1d71a822b53b12c3b67bcaf633f5

Dropper de la tercera etapa
781ce50001d4b449600afa347c9b0208
8e84b01d5ac9624f0b181ade0e737193
980e2134679bc0c609f7659882883d77
4203ec932bfcc0907f91732440d6d997
eb760d5c88f13f7ee0f8f86ba3407123
f9f70096aabb4d22a6657014f4853a53

Dropper de la cuarta etapa
3deeed48fd38f22e369f5c3092bd68a1

Script de la quinta etapa
f97d24212fa6a21be0c4d211e10f044c

Script de la sexta etapa
00d12d842596bf5ee1805effb4571d30
9a0043d900a9ac78c886c59c9a328fd0

Script auxiliar .repair-run
7212229c85852c3bffaf9740002b2f39

Infostealer
c53d0ea45dbc622afb7f16ea3eec78bc

Puerta trasera
fc3ba5ed282d77127efd0b0f2403531b

Herramienta auxiliar de inicio automático
8dc8561349d144d4661bc66f2ec49f9f

URL
hxxps://toria[.]app/
hxxps://warpcast[.]asia/Toria.dmg
hxxps://streamyard.appstore.com[.]mx/installer.sh
hxxps://slack.apple03cloudstore[.]com/installer.sh
hxxps://toria.apple03cloudstore[.]com/
hxxps://waaako.appstore.com[.]mx/installer.sh
hxxps://toria.apple03cloudstore[.]com/e3c1a6b00bc31e14/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/stage2.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/CoreUpdate.pkg.enc
hxxps://docsend.appstore.com[.]mx/dcc737d157ef4271/Helper.pkg.enc
hxxps://caldav.icloud[.]com/published/2/MTk1NDMwMDMzNTUxOTU0M1aHCZ-nMxiyGzBTzPiodOf44DtKJ6PpjftAG28_ui2NCYMpL_vu4pF4ddsJ8ysg0QI7pR0VEIEbZYdilVZRw08
hxxps://gateway.icloud[.]com/caldav/1_MTk1NDMwMDMzNTUxOTU0M0pybtJB186GzhogprwCQUjY3oZNiDFHH8WVo6bmgUtI/attach/4GE4TKNBTGAYDGMZVGUYTSNJUGOAALDAFMDOJBGWNUCYJLZRNDCLCO2YMQ3I64RLGMNXVG3KYBPWQOGYIEI7MPBDDYHECFDYVENTXIYFNDCPOVRMCTYI236RCYZAE63V5U3RTUYGUMO2CO7PKCLWMCXE73M7OPTHSGRWH5DXQ4PCUQU4ELZTLW54JSTK2H7VQ6PD26WOA2R7PPIQ6RTJWDEWP34U3HB4YWMXXC6EJ6PKWILSPYRSDEVY6QGMWSIUN6PR5W35KO3D4QZE7CFPUVBAEKI/Loader.app.tar.gz/YXR0YWNoYXR0YWNoYXR0YRhrE8mQ0E-b_dTUSGStQgTQ0ULFxCanei3Ke-EuEyQL

C2
hxxps://docsend.appstore[.]com[.]mx
hxxps://toria.apple03cloudstore[.]com