CloudSyncD, un malware descubierto por Jamf Threat Labs, oculta credenciales robadas en un archivo JSON usando 48 caracteres de ancho cero que indican dónde empieza la contraseña y cuánto mide.
Jamf Threat Labs identificó el 15 de septiembre un instalador falso de Zoom para macOS que combina ingeniería social clásica con una técnica de ocultamiento poco común: usa caracteres Unicode invisibles para marcar la ubicación de contraseñas robadas dentro de un archivo de configuración aparentemente inocuo. El malware, bautizado CloudSyncD por el nombre del daemon que simula, pasó de una dirección de prueba privada a infraestructura de comando y control activa en dominios reales en menos de 48 horas desde su primera aparición en VirusTotal, lo que sugiere un ciclo de desarrollo acelerado y una operación que ya estaba lista para salir de fase de prueba.
Un instalador que enseña a desactivar las protecciones del sistema
El vector de entrega es un volumen de disco llamado Zoom que se presenta como un instalador legítimo, con un icono de aplicación y un acceso directo a la carpeta Aplicaciones. La imagen de fondo del instalador incluye instrucciones paso a paso para que el usuario desactive Gatekeeper manualmente, porque la aplicación está firmada solo ad-hoc y macOS la bloquearía por defecto. Una vez que el usuario ejecuta la aplicación, aparece un diálogo falso que solicita la contraseña del sistema bajo el pretexto de continuar con la instalación. El prompt se repite hasta que la contraseña ingresada es correcta: el dropper valida cada intento contra la cuenta local usando dscl antes de avanzar.
Este enfoque de ingeniería social no es nuevo en macOS, pero sigue siendo efectivo porque el sistema operativo solicita credenciales con frecuencia durante instalaciones legítimas. La diferencia está en que este instalador nunca instala Zoom: solo muestra una ventana de progreso falsa que dice «Downloading Zoom…» mientras procesa la contraseña capturada.
Cómo 48 caracteres invisibles marcan la ubicación de la contraseña
La contraseña robada no se envía de inmediato al servidor de comando y control. En su lugar, se codifica en base64, se rellena con una cantidad aleatoria de texto basura, y se inserta en un campo que simula ser un valor de caché dentro de un archivo llamado data.json. El archivo está formateado para parecer un archivo de preferencias de aplicación común, con campos de tema y configuración de idioma que no levantan sospechas en una inspección superficial.
La técnica de ocultamiento que da nombre al malware aparece después del número de versión visible 1.0.0: ahí se insertan 48 caracteres Unicode invisibles, específicamente espacios de ancho cero y no-unidores de ancho cero. Estos caracteres no se ven en editores de texto normales, pero cuando se decodifican indican dónde comienza la contraseña real dentro del texto relleno y cuántos caracteres ocupa. Como la cantidad de relleno cambia en cada ejecución, la contraseña queda oculta en una posición diferente cada vez, aunque la técnica de marcado permanece constante. Este método de esteganografía basado en caracteres invisibles es poco frecuente en malware para macOS y complica la detección automatizada basada en patrones de contenido.
Ejecución desde memoria bloqueada por System Integrity Protection
El payload completo ya está incluido dentro del dropper como un archivo Mach-O universal de aproximadamente 756 kilobytes. El malware intenta primero ejecutar el payload directamente desde memoria a través de un descriptor de archivo anónimo usando /dev/fd, una técnica diseñada para evitar escribir el ejecutable en disco y reducir la superficie de detección. En las pruebas de Jamf, este método falló con el error /dev/fd spawn failed rc=13, porque System Integrity Protection bloquea este tipo de ejecución en la mayoría de los sistemas macOS actuales.
Cuando el método sin archivo falla, el malware recurre a un plan B: escribe el payload en un archivo temporal usando mktemp y lo ejecuta con sudo, usando la contraseña robada para obtener los privilegios necesarios. Este respaldo muestra que el malware está diseñado para adaptarse a las protecciones del sistema, aunque su técnica preferida ya no funciona en configuraciones estándar. Un script de limpieza ensamblado en tiempo de ejecución a partir de fragmentos ofuscados está diseñado para intercambiar el bundle de la aplicación por un reemplazo antes de eliminarse, pero en las muestras recuperadas por Jamf el bundle de reemplazo no existe, lo que sugiere que esta funcionalidad estaba preparada para un payload que aún no había sido distribuido.
Un backdoor discreto que espera órdenes del servidor cada ocho segundos
La segunda etapa del malware, que Jamf llama cloudsyncd por el nombre del daemon que simula, es un implante relativamente contenido una vez que está en ejecución. No establece persistencia, no instala un LaunchAgent, no se renombra para mezclarse con procesos legítimos como su propia configuración sugiere que debería hacer. Construye un directorio de trabajo, registra su actividad con logs cifrados, y se comunica con su servidor cada 8 a 16 segundos enviando únicamente un identificador de hardware.
La capacidad real del backdoor aparece cuando el servidor responde: puede enviar un archivo comprimido para desempaquetar o un ejecutable completo para ejecutar. Esto significa que el malware no está limitado a comandos de shell individuales, sino que puede recibir y ejecutar programas enteros, lo que cambia el perfil de detección: en lugar de buscar comandos sospechosos en terminal, los defensores deben buscar archivos nuevos siendo creados o ejecutados sin origen claro. Al momento de la publicación del análisis de Jamf, el malware se comunicaba con dos dominios activos, ambos registrados en 2011 a través del mismo registrador y protegidos por Cloudflare. Ninguno de los dos dominios estaba marcado como malicioso en ese momento.
Todas las muestras analizadas usaban la misma clave de cifrado y el mismo vector de inicialización, lo que significa que una sola muestra recuperada por Jamf podría usarse para descifrar el tráfico de red de otras versiones del malware. Esta reutilización de credenciales criptográficas es un error operacional que facilita el análisis forense y la detección de variantes relacionadas.
Impacto en organizaciones que dependen de instalaciones manuales
Aunque CloudSyncD no incluye funcionalidad específica dirigida a América Latina, su vector de ataque es particularmente efectivo en entornos donde los usuarios instalan software manualmente fuera de repositorios corporativos gestionados, una práctica común en pequeñas y medianas empresas de la región que no tienen políticas de gestión de dispositivos móviles implementadas. México, Brasil y Argentina tienen tasas altas de adopción de macOS en sectores creativos y de tecnología, donde los usuarios suelen tener privilegios administrativos y están acostumbrados a desactivar Gatekeeper para instalar software no firmado o firmado por desarrolladores no verificados. La combinación de ingeniería social efectiva y la dependencia de credenciales de usuario en lugar de exploits técnicos hace que este tipo de malware funcione igual de bien en cualquier geografía donde los usuarios tengan autonomía para instalar aplicaciones.
Nuestro análisis
CloudSyncD representa un patrón que se repite en malware para macOS: la explotación de la confianza del usuario es más efectiva que la explotación de vulnerabilidades técnicas. El malware no usa ningún zero-day, no explota ninguna falla de seguridad no parcheada, no requiere privilegios elevados previos. Simplemente le pide al usuario su contraseña y el usuario se la da, porque el contexto de instalación de software hace que la solicitud parezca legítima. La técnica de ocultamiento con caracteres Unicode invisibles es ingeniosa pero secundaria: lo que hace funcionar el ataque es la ingeniería social, no la esteganografía.
Lo que distingue este caso es la velocidad con la que el malware pasó de desarrollo a operación activa: 48 horas desde su primera aparición en VirusTotal hasta tener infraestructura de comando y control en dominios reales. Esto sugiere que el actor detrás de CloudSyncD tiene capacidad operacional para iterar rápido y que el malware detectado el 15 de septiembre probablemente no era la primera versión, sino una iteración en un ciclo de desarrollo ya maduro. El hecho de que el script de limpieza esté diseñado para intercambiar bundles que no existen en las muestras recuperadas indica que hay funcionalidad planeada que aún no se ha desplegado. ¿Qué pasaría si esa funcionalidad incluye persistencia real, comunicación cifrada más robusta, o capacidad de movimiento lateral dentro de redes corporativas?