ADEX rastreó una infección activa de macOS desde un proceso extraño hasta una amenaza mayor en la cadena de suministro que se propagaba a través de las herramientas de desarrollo de Apple. El caso se centró en XCSSET, una familia de malware que se oculta dentro de los archivos de proyecto de Xcode en lugar de en las aplicaciones terminadas, esperando a que un desarrollador compile un proyecto y active el payload.
La Pista Que Inició el Caso
La primera señal era pequeña pero extraña: actividad repetida de osascript ejecutándose desde /tmp/jl. AppleScript en sí es una herramienta normal de macOS, pero la ubicación importaba. El directorio /tmp es un espacio temporal, no un lugar donde un software limpio deba relanzar continuamente scripts de corta duración con argumentos codificados de gran tamaño.
ADEX copió el archivo antes de que desapareciera. Una vez capturado, /tmp/jl resultó ser un AppleScript compilado. Su contenido estaba empaquetado bajo capas de codificación base64, un método habitual que usa el malware para ocultar su próximo movimiento a una inspección rápida.
Tras la desencriptación, la muestra reveló un script de shell que recopilaba detalles del sistema. Recogía el nombre de usuario, la configuración regional, la versión de macOS, el tipo de CPU, el estado de System Integrity Protection, el número de serie del Mac y datos relacionados con Chrome. La información se enviaba a riggletoy.ru, un dominio de comando y control que ADEX indicó que no aparecía en los feeds públicos de amenazas en ese momento. Un segundo dominio, netcdndev.in —encontrado más tarde en la parte de GitHub de la investigación— también estaba ausente de cualquier lista pública de indicadores de compromiso.
Un Archivo de Compilación Se Convirtió en la Puerta de Entrada
El peligro de XCSSET proviene de su lugar de ocultamiento. Los proyectos de Xcode contienen archivos project.pbxproj, que indican al software de desarrollo de Apple qué ejecutar durante una compilación. Un script malicioso colocado allí puede ejecutarse bajo la propia cuenta del desarrollador cuando se compila el proyecto.
Eso hace que el ataque sea silencioso. No se necesita ningún instalador extraño. No aparece ningún ícono de aplicación obvio. Un desarrollador puede clonar un proyecto de GitHub, abrirlo en Xcode, presionar Build y darle al malware el momento que necesita.
La infección entonces busca otros proyectos de Xcode en la máquina. ADEX encontró más de 20 proyectos alterados en la estación de trabajo afectada, todos modificados en el mismo minuto. Ese timing apuntaba a un barrido automatizado, no a una edición humana. Una estación de trabajo infectada ya se había convertido en un punto de partida para una mayor propagación.
La Persistencia Era el Verdadero Problema
Limpiar un solo proyecto no resolvería el caso. ADEX encontró un Launchpad.app falso enterrado en una carpeta de caché de usuario, mientras que el Launchpad real reside en /System/Applications/Launchpad.app. Ese detalle coincidía con un conocido "método del dock", donde el malware redirige un ícono del Dock para que el usuario abra tanto la aplicación real como el payload oculto sin darse cuenta.
El informe describía rutas de persistencia adicionales, incluyendo agentes de inicio, cambios en el perfil del shell y git hooks. La lección era clara: los proyectos infectados eran síntomas. El mecanismo que mantenía viva la infección debía eliminarse primero.
El orden de limpieza de ADEX era estricto. Eliminar los puntos de inicio automático, reiniciar y luego restaurar los proyectos de Xcode desde un estado git limpio. Invertir ese orden arriesga que el malware reescriba los archivos ya limpiados.
GitHub Mostró el Rastro Más Amplio
La investigación pasó de una sola máquina a repositorios públicos. ADEX reportó 24 repositorios de GitHub que contenían cadenas de payload de XCSSET. Entre los ejemplos se encontraban PrinceMittal1/DemoForAuthFlow, zzzznick/dummy-ios y dvillegastech/ReaxBD.
Un repositorio, usamajaved357/Breezy, usaba riggletoy.ru, el mismo dominio visto en la muestra activa. Otro, xiaoyouPrince/XYDevTool, usaba netcdndev.En un dominio que ADEX describió como ausente de la lista pública de indicadores de compromiso en el momento de la inspección, lo que indica que los operadores están rotando la infraestructura más rápido de lo que los feeds públicos de amenazas pueden rastrearlo. Doce de los 24 repositorios recibieron commits en 2026, con el más reciente apenas un día antes de la inspección; varios repositorios tuvieron actividad en 2026, lo que sugiere que la campaña seguía propagándose a través del código compartido.
Los números importan porque la confianza del desarrollador es parte del vector de ataque. Los archivos de proyecto de Xcode suelen tratarse como infraestructura rutinaria, menos visibles que el código fuente o las dependencias. XCSSET explota ese hábito.
El Riesgo para los Desarrolladores de Apple
El objetivo directo no es el usuario de la App Store. El objetivo es la persona que desarrolla software, junto con las credenciales, sesiones del navegador, repositorios y tokens almacenados en esa máquina.
XCSSET puede extraer datos de navegadores, Keychain y archivos de configuración —incluyendo claves en la nube, tokens de AWS, claves SSH y credenciales de Git—, reemplazar direcciones de monederos de BTC o ETH copiadas, y alterar el comportamiento del navegador mediante código JavaScript inyectado. Para un equipo de software, eso significa que un solo Mac comprometido puede poner en riesgo el código fuente, las cuentas y los proyectos posteriores.
La defensa práctica comienza antes del botón de compilación. Los desarrolladores deben inspeccionar las fases de compilación de Xcode desconocidas y mantener los archivos project.pbxproj bajo control de versiones, vigilar los git hooks globales, mantener activado System Integrity Protection y monitorear el tráfico saliente inesperado. Los equipos de seguridad deben tratar los portátiles de los desarrolladores como parte de la cadena de suministro, no como endpoints ordinarios.
