CrashStealer: el nuevo malware para macOS que se hace pasar por el reportador de fallos de Apple
Los investigadores de Jamf Threat Labs han identificado un nuevo infostealer para macOS bautizado como CrashStealer, que utiliza un Apple Developer ID válido y un ticket de notarización para superar Gatekeeper y distribuirse como una falsa aplicación llamada Werkbit Setup. El malware, escrito en C++ y detectado por primera vez a principios de julio de 2026, está diseñado para robar credenciales de inicio de sesión, monederos de criptomonedas y cualquier dato sensible que encuentre en el sistema o en los navegadores de la víctima. Su particularidad más inquietante no es lo que recoge, sino cómo se presenta: su dropper está firmado y notarizado por Apple, lo que en teoría debería garantizar que la aplicación es legítima.
La capacidad de los atacantes para obtener un Developer ID válido y pasar el proceso de notarización no es nueva, pero sigue siendo relativamente infrecuente entre los infostealers commodity. La mayoría de las familias de malware para macOS se distribuyen como binarios sin firmar, lo que activa al menos una alerta visible de Gatekeeper. CrashStealer ha cruzado esa barrera, y al hacerlo se coloca en una categoría más difícil de detectar por usuarios no técnicos. La aplicación descargada, una vez instalada, se hace pasar por el componente integrado de reporte de fallos de Apple (Apple Crash Reporter), una elección deliberada que aporta legitimidad visual al engaño.
La cadena de infección paso a paso
La investigación publicada por Jamf el 13 de julio describe una cadena de ataque que se desarrolla en al menos dos etapas, con un nivel de sofisticación superior al malware commodity habitual para macOS.
La primera entrega es una imagen de disco (.dmg) que se distribuye con el nombre Werkbit Setup. La imagen está firmada con un Developer ID válido de Apple y ha pasado por el proceso de notarización de la compañía, lo que significa que cuando el usuario la abre por primera vez, macOS no muestra ninguna advertencia de seguridad y Gatekeeper permite la ejecución. El bundle de la aplicación dentro de la imagen está empaquetado de tal forma que imita visualmente al componente de reporte de fallos integrado en macOS, lo que refuerza la percepción de legitimidad para el usuario.
Una vez que el usuario decide ejecutar la aplicación, esta realiza una llamada a una API de GitHub. La respuesta es un script ofuscado que, tras ser decodificado, se transforma en un downloader-installer que se encarga de obtener el payload real de CrashStealer desde un servidor controlado por los atacantes. El uso de GitHub como intermediario no es accidental: el tráfico hacia GitHub es percibido como legítimo por las herramientas de monitorización de red y por los proxies corporativos, lo que dificulta la detección temprana.
La segunda etapa comienza cuando el payload se descarga y se ejecuta en el sistema. CrashStealer entonces muestra al usuario un cuadro de diálogo nativo que imita fielmente una solicitud de autenticación del sistema. El diálogo pide al usuario la contraseña de su cuenta, presentándose como si fuera una verificación rutinaria del sistema operativo. Si el usuario introduce su contraseña, CrashStealer la captura y la valida. Si la contraseña es correcta, el malware procede con su objetivo principal: robar credenciales, monederos y datos sensibles.
Qué roba exactamente
Una vez que CrashStealer ha confirmado la contraseña de la cuenta del usuario, su verdadero objetivo es capturar todo lo que tenga valor en el sistema. Los investigadores de Jamf detallan varios blancos prioritarios.
En primer lugar, las credenciales almacenadas en los navegadores web. Chrome, Safari, Firefox, Brave y otros navegadores populares guardan contraseñas y tokens de sesión en bases de datos locales protegidas por el llavero del sistema. CrashStealer tiene la capacidad de extraer esas credenciales, lo que le da acceso a todas las cuentas en línea del usuario, desde correo electrónico hasta banca.
En segundo lugar, los monederos de criptomonedas. La familia de malware busca extensiones de navegador asociadas con monederos populares (MetaMask, Phantom, Trust Wallet y similares) y exfiltra las frases semilla y las claves privadas. Esto convierte a CrashStealer en una amenaza especialmente grave para usuarios con tenencias significativas de criptomonedas, o para desarrolladores Web3 que almacenan claves de despliegue en sus estaciones de trabajo.
En tercer lugar, los datos del llavero del sistema, que contienen credenciales de aplicaciones nativas, certificados, tokens de APIs y otros secretos. Si la víctima tiene acceso a bases de datos corporativas, sistemas de producción o infraestructura cloud desde su Mac, todos esos secretos pueden quedar comprometidos.
En cuarto lugar, archivos específicos del sistema. CrashStealer busca patrones de archivos asociados con billeteras de escritorio (Electrum, Exodus, Bitcoin Core), credenciales SSH, archivos .env de proyectos, claves AWS, configuraciones de Kubernetes, y otros ficheros que en entornos de desarrollo contienen los secretos que dan acceso a infraestructura crítica.
Lo que hace diferente a CrashStealer
Jamf Threat Labs señala tres características técnicas que distinguen a CrashStealer del malware commodity típico para macOS.
La primera es la implementación nativa en C++. La mayoría de los infostealers para macOS están escritos en Objective-C o en lenguajes de script (Python, JavaScript). Escribir en C++ ofrece a los atacantes control de bajo nivel sobre la ejecución y dificulta el análisis estático por herramientas de seguridad. El binario resultante es más difícil de revertir y de entender para los analistas.
La segunda es el uso de cifrado AES-GCM en el lado del cliente para los archivos exfiltrados. CrashStealer cifra los datos robados antes de exfiltrarlos, lo que protege el botín incluso si el canal de exfiltración es interceptado o monitorizado. Para los defensores, esto significa que capturar el tráfico de red no entrega los datos en claro; hace falta romper el cifrado o comprometer el endpoint antes de la exfiltración.
La tercera es la resistencia al análisis. El malware incorpora control-flow flattening, cadenas de strings cifradas y múltiples capas anti-debugging. Estas técnicas no son nuevas en el malware de Windows, pero son relativamente raras en macOS, lo que indica que los operadores detrás de CrashStealer vienen del mundo Windows y han portado sus técnicas. Para los analistas de macOS, esto significa adaptar herramientas y mentalidades.
Qué ha hecho Apple y qué queda por hacer
Tras confirmar que un Developer Team ID había sido utilizado para distribuir el malware, Jamf Threat Labs reportó el incidente a Apple. La respuesta de Apple fue revocar el Developer ID de inmediato, lo que invalida el binario firmado en sistemas con la revocación procesada. En la práctica, eso significa que Gatekeeper bloqueará nuevas infecciones con el mismo binario, pero no afecta a máquinas que ya estén comprometidas, ni a variantes del malware con otros Developer IDs.
Esta respuesta es la correcta y esperada, pero revela un problema estructural en el modelo de notarización de Apple. El proceso de notarización es una barrera que eleva el coste de la infección, no la impide. Un atacante con los recursos para comprar un Developer ID (99 dólares al año) y para pasar la revisión de Apple (que es automatizada para la mayoría de aplicaciones) puede distribuir malware firmado durante semanas o meses antes de que la revocación llegue. Para los usuarios, la única señal fiable de legitimidad sigue siendo la fuente de la descarga: si una aplicación llega por un canal no solicitado, no es legítima por muy firmada que esté.
Apple podría endurecer el proceso de varias formas: revisiones manuales más frecuentes para Developer IDs recién emitidos, monitorización post-notarización que detecte comportamiento anómalo en binarios distribuidos, y revocación proactiva de Developer IDs asociada a indicadores de compromiso conocidos. Ninguna de estas medidas es trivial, pero el creciente número de malware notarizado justifica el debate.
Cómo protegerse en la práctica
Para los usuarios individuales, la defensa sigue siendo la misma de siempre, aunque reforzada por la comprensión del nuevo modelo de amenaza.
La primera regla es descargar software solo desde fuentes esperadas. Si una aplicación llega por correo electrónico, por una red social o por un anuncio, no es legítima aunque esté firmada. La cadena de suministro de software empieza por el origen, no por la firma criptográfica.
La segunda regla es desconfiar de los diálogos de contraseña inesperados. macOS pide contraseñas para acciones administrativas (instalar software, cambiar preferencias del sistema, acceder a ciertas funciones). Si un diálogo de contraseña aparece sin que el usuario haya iniciado una acción administrativa, es una bandera roja. La autenticación de macOS muestra el origen del diálogo en la parte superior (el nombre del proceso o aplicación que lo solicita); un diálogo legítimo siempre identifica claramente quién lo pide.
La tercera regla es habilitar FileVault. Si un atacante tiene acceso físico a la máquina, FileVault cifra el contenido del disco y protege los datos del llavero y de las billeteras. CrashStealer roba datos del sistema en ejecución, pero FileVault añade una capa de protección para los datos en reposo.
Para los administradores de sistemas que gestionan flotas de Mac, la defensa se complica. CrashStealer usa Developer IDs válidos y pasa la notarización, lo que significa que las herramientas de control de aplicaciones basadas en listas de binarios firmados no lo detectan. Las herramientas EDR para macOS que monitorizan comportamiento (no solo firma) son la única defensa viable en este nuevo escenario. Productos como Jamf Protect, CrowdStrike Falcon, SentinelOne y Microsoft Defender for Endpoint monitorizan la ejecución de procesos, el acceso al llavero y las llamadas a APIs sensibles, lo que permite detectar CrashStealer aunque esté firmado.
Las reglas de detección concretas que los equipos de seguridad deberían desplegar incluyen: monitorización del acceso al llavero por procesos no firmados por Apple o por desarrolladores desconocidos, alertas sobre llamadas a la API de GitHub desde procesos sospechosos, y análisis del tráfico DNS para detectar dominios asociados con la exfiltración de datos.
Implicaciones para el modelo de confianza de macOS
CrashStealer no es el primer malware notarizado para macOS, ni será el último. La tendencia apunta a que los atacantes están profesionalizando sus operaciones en macOS y aprendiendo a aprovechar las propias defensas de Apple como vectors de confianza. La notarización fue diseñada para elevar la barrera de entrada al malware, y lo ha conseguido, pero los operadores que están dispuestos a invertir los 99 dólares y esperar el ciclo de revisión están encontrando el camino rentable.
Para los profesionales de seguridad que defienden endpoints Mac, el mensaje es claro: la firma del binario ya no es una señal fiable de legitimidad. Las herramientas y políticas deben evolucionar hacia la monitorización de comportamiento, la detección de anomalías en tiempo de ejecución y la aplicación del principio de mínimo privilegio en las operaciones del día a día. El modelo de "instalar y firmar" de macOS, cómodo durante años, se está quedando corto frente a atacantes que saben cómo jugar dentro de él.