El malware de macOS que no explota nada: lo pegas tú en la Terminal

El 6 de agosto, Huntress publicó el desmontaje de un ladrón de credenciales para macOS escrito en Go. Lo encontraron en junio, en una búsqueda retrospectiva, dentro de un Mac que ya estaban monitorizando: llevaba alrededor de tres meses ahí. Lo que hace interesante el caso no es el binario, que es el de siempre. Es que en toda la cadena no hay ninguna vulnerabilidad. No hay CVE que buscar, ni versión mínima a la que llegar, ni parche que aplicar el martes. Hay una web que le dicta un comando a una persona y una persona que lo pega en la Terminal.

La técnica tiene nombre desde hace un par de años —ClickFix— y nació en Windows: el falso CAPTCHA, el «pulsa Win+R y pega esto para verificar que eres humano». Contra macOS no es nueva: el propio Microsoft documentó en mayo una campaña con señuelos de falsas utilidades para Mac. Lo que cambió en agosto es que la infraestructura aprendió a esconderse. Un día antes del informe de Huntress, el 5 de agosto, Microsoft Threat Intelligence publicó el análisis de más de 250 dominios montados para servir estos señuelos, con un filtro delante que decide a quién se los enseña.

Lo primero que hace el comando no es robar

Huntress publica el comando entero, y está escrito por alguien que ha pensado en qué va a pasar después. Todo va dentro de un subshell en segundo plano con la salida redirigida a /dev/null: descarga un script con curl desde una dirección IP, lo ejecuta con bash y borra el fichero temporal. Luego vienen cuatro instrucciones que no roban nada: clear, un printf con la secuencia de escape que vacía el búfer de desplazamiento de la ventana, un history -d que elimina del historial la propia línea recién ejecutada y un fc -p /dev/null que desengancha el fichero de historial.

Traducido: cuando la persona levante la vista de la pantalla, la ventana estará limpia y no habrá nada que enseñar. Si mañana esa persona sospecha y llama a su informático, lo primero que hará el informático es pedirle que abra la Terminal y mire qué pegó. No lo va a encontrar. Ese borrado apunta a tu proceso de respuesta: a la conversación del día siguiente.

Gatekeeper no falla: es que no está invitado

Aquí es donde se cae el argumento con el que llevamos años conviviendo, el de «en Mac eso no pasa porque Apple lo firma todo». El script que se descarga perfila la máquina con ioreg y system_profiler, mira uname -m para saber si es Apple Silicon o Intel, se baja el binario Mach-O que toque y lo deja en una carpeta creada al efecto dentro de ~/Library/Caches/ con un nombre que imita a un servicio del sistema. Después le da permisos de ejecución y ejecuta xattr -d com.apple.quarantine sobre él.

Ese atributo extendido, com.apple.quarantine, es la marca que el navegador y el Finder ponen a lo que baja de internet, y la que dispara la comprobación de notarización y el diálogo de «¿seguro que quieres abrirlo?». Aquí hay un detalle que redondea el asunto: curl no pone esa marca. Lo que baja por el shell nace ya sin ella, así que ese xattr -d es un cinturón sobre unos tirantes que nadie llevaba puestos. Gatekeeper no ha sido burlado ni ha fallado: nunca llegó a intervenir, porque la ruta de entrada no fue una descarga abierta con doble clic, fue tu shell obedeciéndote.

La persistencia sigue la misma línea. El binario acaba en otra carpeta de caché con nombre de servicio de Apple y se registra con launchctl bootstrap gui/501 apuntando a un LaunchAgent llamado com.apple.softwareupdated.plist. Es decir: en la lista de elementos en segundo plano de tu Mac aparece algo que se llama casi exactamente igual que el actualizador de software del sistema. Y para escalar, un osascript que pide la contraseña con el aspecto de un diálogo normal de macOS: todas las piezas son herramientas nativas usadas como están documentadas. El binario, además, va firmado —en Apple Silicon el núcleo no ejecuta nada sin firma—, pero una firma ad-hoc la genera el propio compilador y no identifica a nadie. Lo que este binario nunca pasa, porque nadie se la pide, es la notarización de Apple.

DRAIN_PCT: la variable que dice mucho

La parte que se ha llevado los titulares es la función que Huntress encontró dentro del binario, llamada DRAIN: busca direcciones de monedero de Bitcoin, Litecoin, Dogecoin, Monero, Ethereum y XRP, consulta el saldo en la cadena y, si hay fondos, saca una dirección de destino de una lista embebida en el propio binario o de su servidor de control y transfiere el valor allí. Con un detalle que los analistas subrayan como novedad: una variable DRAIN_PCT que permite llevarse un porcentaje en lugar del saldo entero.

Un ladrón que se lleva el 100% se descubre esa misma tarde. Uno que se lleva una parte puede pasar por un error de la aplicación, por una comisión rara, por «mira, qué cosa». La diferencia entre robar y ordeñar es exactamente la diferencia entre un incidente de un día y uno de tres meses. Y conviene decir el matiz honesto, que la propia Huntress apunta: las carteras que aparecen en el binario no tenían transacciones registradas públicamente. No estamos midiendo un botín, estamos midiendo una capacidad.

En una empresa, lo caro no es la cripto

Si el Mac infectado es el de una empresa que no toca criptomonedas, es fácil leer esto y archivarlo. Sería un error. La lista de lo que el mismo binario se lleva antes de llegar al monedero es la de siempre: contraseñas guardadas en el navegador, el Keychain, las cookies en caché y credenciales del sistema. La cookie de sesión es la joya, y la razón es la que ya hemos contado aquí: una sesión ya emitida no vuelve a pedir el segundo factor. Quien la reutiliza no está autenticándose, está siendo tú.

De ahí sale la consecuencia práctica que más se salta la gente cuando limpia un equipo: cambiar la contraseña no cierra nada. Si no se revocan las sesiones y se revisan las aplicaciones conectadas, el atacante sigue dentro con el token que ya tenía mientras el usuario se felicita por la contraseña nueva.

«Yo me habría dado cuenta» no es un control

El informe de Microsoft del 5 de agosto es el que conviene enseñar a quien responde eso. Delante de las páginas señuelo hay un filtro de unos 2,5 KB de JavaScript que examina la plataforma declarada por el navegador, el tamaño de pantalla y de ventana, señales de WebGL, la zona horaria, si la página va dentro de un iframe y si el dispositivo tiene pantalla táctil. Y lleva dos trampas específicas para analistas: un contador que detecta si tienes la consola de desarrollador abierta y una comprobación de soporte de códecs con canPlayType("video/mp4"), pensada para cazar navegadores sin interfaz, los que usan los sistemas de análisis automático.

Si el filtro decide que eres un investigador, no te enseña el ataque: te sirve otra cosa. La víctima ve la página maliciosa; el que la iría a comprobar, no. A eso se suma el envoltorio: páginas que imitan descargas de GitHub con una insignia de «editor verificado» falsificada. La cadena que Microsoft siguió a través de ese filtro terminaba en AMOS, la familia de ladrones de macOS más extendida de los últimos años, y el conjunto de la campaña también distribuía MacSync.

Es el mismo patrón que vimos con las redes wifi de hoteles manipuladas para robar sesiones de Microsoft 365: el objetivo ya no es tu servidor, es el rato en que tu gente está fuera de la oficina con un portátil y con prisa.

Lo que Apple hizo en marzo, y por qué no basta

Conviene reconocerlo: Apple vio venir esto y actuó. En macOS 26.4, en marzo de 2026, apareció un aviso nuevo al pegar ciertos comandos en la Terminal. El texto es directo —«Possible malware, Paste blocked»— y explica que los estafadores suelen pedir que se peguen instrucciones en la Terminal, y que el Mac no ha sufrido ningún daño. Es una defensa bien pensada, en el sitio exacto donde ocurre el problema, y llegó antes que los informes de agosto.

Y aun así no cierra el asunto, y el propio documento de soporte de Apple deja ver por qué. No hay un aviso, hay dos niveles. El blando —el del «Possible malware»— trae un botón para pegar igualmente, y quien lleva veinte minutos peleándose con un «error» que le impide ver un documento va a pulsarlo. El duro bloquea sin salida, pero salta cuando lo pegado coincide con malware ya conocido, que es justo lo que no va a ser el comando de la campaña siguiente. Y hay un tercer matiz, el más interesante: Apple explica que el aviso está pensado para quien no usa la Terminal habitualmente y pega algo que le ha llegado de un correo, de un chat o de otra fuente parecida. Protege bien al que nunca la abre. No al administrador que la tiene abierta todo el día, que es quien más daño puede hacer si se equivoca.

Los tres meses son el titular

Volvamos al principio, porque el dato incómodo del caso de Huntress no es el DRAIN. Es que el Mac estaba monitorizado y el bicho salió en una caza retrospectiva, meses después de entrar. Nadie parecía haberse dado cuenta en su momento. Eso no se arregla comprando un antivirus mejor: un antivirus decide en el instante en que ve el fichero y, si en ese instante no lo conoce, lo deja pasar; que vuelva a mirarlo depende de que alguien lance otro análisis cuando ya exista la firma.

Lo que salvó el caso fue la otra mitad: telemetría guardada —qué proceso lanzó a qué otro, qué se registró en los elementos de arranque, qué salió por la red— y alguien haciendo preguntas sobre ella semanas después. Esa es la diferencia entre detección y caza, y es exactamente lo que montamos cuando hablamos de EDR y MDR: no solo el agente que bloquea, sino el histórico que permite preguntar «¿esto lleva aquí desde marzo?» y obtener una respuesta. Sin ese histórico, la respuesta honesta a esa pregunta es «no lo sé», y con «no lo sé» no se cierra un incidente.

Qué haríamos el lunes

Nada de esto necesita presupuesto nuevo. Necesita que alguien se siente una mañana:

• Cuenta los Macs. No los que están en el inventario: los que hay. El parque Mac suele vivir en dirección, diseño y marketing, comprado fuera del circuito habitual, y acaba fuera de la consola donde está todo lo demás. Nadie lo gestiona, así que nadie lo mira.
• Comprueba que el agente de seguridad está también en ellos. Muchos contratos de EDR se despliegan sobre el parque Windows y el Mac se queda «para más adelante». Más adelante fue marzo.
• Mira los elementos de inicio de sesión y los agentes. launchctl print gui/$(id -u) y el contenido de ~/Library/LaunchAgents. Lo que busques no se llamará «malware»: se llamará como algo de Apple. Fíjate en la ruta antes que en el nombre: un ejecutable dentro de ~/Library/Caches/ no tiene por qué estar ahí.
• Di la frase, una sola, en la próxima reunión. Ninguna web, ningún chat de soporte y ninguna llamada te va a pedir nunca que pegues un comando en la Terminal. Ninguna. Es la única regla que hace falta y cabe en un renglón.
• Si alguien ya lo pegó, el orden importa. Aísla el equipo de la red antes de tocar nada, y luego revoca sesiones y rota lo que hubiera en el Keychain y en el navegador. Reinstalar el Mac sin revocar sesiones deja al atacante dentro de la nube con una máquina limpia delante.

Y una cosa que no diremos porque quedaría bien: que hay que formar a la gente para que no caiga. Formar ayuda. Pero el señuelo que Huntress describe llegó por correo con un enlace, y las páginas que analizó Microsoft imitan descargas legítimas con insignia de verificado. Diseñar la seguridad de una empresa asumiendo que nadie se va a equivocar nunca no es formación, es optimismo. Lo que se planifica es el después: que cuando alguien se equivoque, se sepa el mismo día y no en junio.

Detección y respuesta gestionada sobre todo el parque —Windows, Linux y también los Macs que compró dirección— es lo que operamos en EDR y MDR, dentro del trabajo de ciberseguridad del día a día. Si no sabes cuántos Macs hay en tu empresa ni quién los mira, escríbenos y los contamos contigo.