Antino: el backdoor Rust de UAT-11587 que usa Microsoft 365 como C2

octubre 5, 2026 Alfonso Moreno | Sysadmin Senior 38 Visitas 14 min de lectura

TL;DR — Lo que vas a tener al final

Tiempo de setup: 30 minutos a 2 horas dependiendo de la complejidad del entorno.
Requisitos: Acceso root, Linux moderno, conexión a internet para descargar dependencias.
Resultado: Servicio funcional y estable, documentado paso a paso.
Troubleshooting: Logs estándar en /var/log/, comandos de verificación al final de cada sección.

Qué es Antino y por qué importa en 2026

Cisco Talos publicó el 30 de septiembre de 2026 un informe técnico detallado sobre UAT-11587, un actor de amenazas con atribución China-nexus que opera desde finales de 2025 utilizando un implante previamente no documentado llamado Antino. El nombre aparece en el manifiesto de aplicación de Windows (AntinoApp) y en rutas PDB de Rust que Talos recuperó de múltiples builds. Antino es un backdoor compilado en Rust, observado en versiones de 32 y 64 bits, con soporte para reconocimiento del sistema, ejecución de PowerShell y shellcode, persistencia y, sobre todo, un canal de comando y control que se camufla dentro del tráfico legítimo de Microsoft 365.

Lo que distingue a Antino de casi cualquier backdoor que se analiza hoy no es su capacidad técnica aislada sino el protocolo de C2: en lugar de hablar con un servidor dedicado y exótico, el backdoor consulta cada diez segundos la carpeta de un buzón Outlook controlado por el atacante y escribe latidos en JSON sobre OneDrive. Las conexiones de salida apuntan a graph.microsoft.com y login.microsoftonline.com, dos endpoints que están en la lista de permitidos de cualquier empresa mediana o grande. Para un defensor que mira su egress firewall, Antino es invisible.

Hasta julio de 2026 Talos confirmó diez organizaciones afectadas y cinco probablemente comprometidas, con aproximadamente 350 endpoints distribuidos en ocho países asiáticos: Taiwán, India, Filipinas, Camboya, Pakistán, Tailandia, Myanmar y Siria. Los sectores objetivo incluyen defensa, diplomacia, justicia, legislativo, gobierno electrónico y think tanks. En América Latina no se han publicado víctimas hasta ahora, pero el patrón de infraestructura compartida (Cloudflare Pages, Cloudflare R2, dominios que se hacen pasar por Microsoft) es perfectamente replicable y hay lures en español e inglés ya identificados.

Por qué el C2 vía Microsoft 365 cambia las reglas del juego

Durante mucho tiempo el playbook de detección se basó en reputación de IP y dominios. Si veías conexiones a una IP en Moldavia o a un dominio que llevaba activo dos días, era tráfico sospechoso. Antino revierte esa lógica: las IPs son de Microsoft, los dominios son de Microsoft, y los endpoints son graph.microsoft.com, exactamente los que Outlook y OneDrive legítimos tocan cada minuto en cada endpoint Windows del planeta.

El backdoor usa dos canales paralelos. En OneDrive crea tres rutas de carpetas:

/antino/heartbeats/{session_id}.json: el implante sube un JSON con sesión, timestamp, estado, hostname, username. Es el latido que el operador usa para saber qué endpoints están vivos.
/antino_uploads/: el operador sube herramientas y payloads adicionales desde su lado de OneDrive.
/antino_downloads/: el backdoor sube la data exfiltrada de la víctima hacia OneDrive para que el operador la baje después.

En paralelo, el canal de comandos usa Outlook. Cada diez segundos el backdoor hace un GET a la bandeja del atacante buscando correos cuyo asunto empiece por command_req_[session_id]. Cuando el operador envía un comando, el backdoor ejecuta y postea la respuesta como otro correo con prefijo command_res_[session_id]. Es el patrón dead-drop resucitado en una plataforma SaaS, y funciona exactamente por la misma razón que los dead drops de los años 90: desacopla al operador del implante, de forma que la víctima nunca ve una conexión C2 sostenida y el operador puede actuar desde cualquier lugar sin levantar alertas de geolocalización.

La consecuencia operativa es incómoda: bloquear dominios no sirve, bloquear IPs no resuelve nada, y la señal tiene que venir del comportamiento del endpoint (PowerShell sospechoso, librerías DLL que no deberían cargarse, escrituras en carpetas OneDrive que ningún usuario legítimo hace). Volvemos a los 90 en cuanto a detección, pero ahora el host es Windows y los logs están en Defender for Endpoint y Sysmon.

La cadena de infección: cinco etapas

Talos reconstruyó la cadena con detalle forense. Lo que viene a continuación es la versión simplificada, porque la versión completa tiene tres o cuatro capas de ofuscación y carga lateral por cada etapa.

Etapa 1: Spear-phishing y clonación del widget de Gmail

El correo inicial no adjunta un binario malicioso: el HTML del propio correo contiene una tarjeta que imita perfectamente la UI de adjuntos de Gmail. Cuatro imágenes PNG embebidas en Base64 forman la tarjeta, y toda la tarjeta está envuelta en un <a href="//my-<project>.pages.dev/File_download?m=<target-identifier>">. La URL usa // protocol-relative, lo que engaña a extractores de URLs que solo buscan http:// o https:// explícitos. El parámetro ?m= lleva un identificador por destinatario, así el atacante sabe exactamente quién hizo clic.

El engaño de identidad es interesante por su simpleza. UAT-11587 envió los correos a través de Migadu usando osc-cdn[.]com como remitente envelope (RFC 5321), pero puso en el header visible (RFC 5322) el dominio real de la organización objetivo. SPF pasa porque Migadu está autorizado para osc-cdn[.]com. DMARC falla porque los dominios no están alineados, pero la organización objetivo usa política p=none que solo pide monitoreo y no rechazo. La mayoría de las empresas con p=none recibe ese tipo de correos sin pestañear.

Etapa 2: Stager HTA/WSF y beaconing

El clic lleva a un archivo .hta o .wsf hosteado en Cloudflare Pages. El stager se minimiza, emite un beacon HTTP al mismo dominio con el título del cebo en la URL, y luego importa la siguiente etapa JavaScript desde Cloudflare R2 (pub-<hash>.[.]r2[.]dev) o desde CloudFront (d2nq35tel3ucuo[.]cloudfront[.]net).

Cloudflare Pages se usa dos veces: una como CDN de payloads y otra como endpoint de tracking. El dominio fijo oisadjfoinsiduhfnoisdnfosdnoifnsoid[.]pages[.]dev aparece en múltiples campañas, lo que lo convierte en un IoC de muy alta calidad para los defensores. Lo que hay que detectar aquí es mshta.exe hablando con .pages.dev; en un endpoint Windows legítimo esa combinación no existe.

Etapa 3: JScript ofuscado y deserialización .NET

El stager descarga tres recursos cifrados con RC4 (clave embebida), los descifra, y monta una cadena de deserialización BinaryFormatter directamente desde JScript. La técnica es vieja y conocida, pero el actor la combina con un ActivitySurrogateSelector que evade mitigaciones parciales en distintas versiones de .NET. El resultado final es que un mshta.exe ejecuta código .NET 4.x arbitrario sin escribir nada a disco todavía.

Etapa 4: TestAssembly.dll y DLL sideloading firmado

La cadena carga un TestAssembly.dll que descarga tres cosas: el documento señuelo (un PDF con el tema del cebo), un binario firmado de ADK (GatherOsState.exe) y una DLL maliciosa (slc.dll) que es el Antino propiamente dicho. Las extensiones de archivo son aleatorias (.luy, .pzs, .syk) para evadir reglas simples que filtran por extensión. Un AssemblyAttribute GUID común (b2b3adb0-1669-4b94-86cb-6dd682ddbea3) sirve como marcador de detección para este descargador.

Etapa 5: Antino se conecta a Microsoft Graph

El binario firmado carga la DLL por sideloading, la DLL ejecuta su SLOpen, y a partir de ahí Antino se conecta a Microsoft Graph con OAuth 2.0 client-credentials y empieza a sincronizar con Outlook y OneDrive. Toda la cadena pasa por procesos firmados por Microsoft y por endpoints que la mayoría de las organizaciones no pueden bloquear sin romper productividad.

Anatomía técnica del backdoor

Antino está escrito en Rust, lo que ya es un cambio de tendencia: hasta 2024 los implantes APT solían ser C++ o Go. Rust da memoria segura sin garbage collection, perfil más bajo en memoria, y tooling moderno que entorpece el reversing. Talos identificó dos generaciones:

Característica	Antino Gen 1	Antino Gen 2
Periodo de build observado	Octubre 2025	Diciembre 2025 a enero 2026
Identidad de aplicación	Sin manifiesto AntinoApp en builds revisados	Usa el manifiesto AntinoApp
Identificador de sesión	XOR + Base64 sobre PID, hostname, username, plataforma	UUID v4 aleatorio sin info del host
Heartbeat / registro	Emails draft para sesión y heartbeat; DLL temprana ya con OneDrive	JSON en `/antino/heartbeats/{id}.json` en OneDrive; el heartbeat también registra el implante

El set de comandos es amplio: cmd ejecuta cmd.exe /C, powershell lanza powershell.exe -Command, system_info recoge contexto, execute_program ejecuta binarios arbitrarios, list_files enumera directorios, upload_file baja archivos desde OneDrive del atacante al endpoint, download_file sube archivos del endpoint al OneDrive del atacante, load_shellcode corre shellcode en memoria, add_to_run crea persistencia por registro Run en HKCU, y exit apaga el runtime. El comando load_shellcode acepta un parámetro use_sleep_mask que activa una técnica de evasión avanzada: hookea Sleep y VirtualAlloc, registra un vectored exception handler (VEH), y cuando el payload dormido intenta ejecutarse, el VEH descifra la región on-the-fly y la restaura a ejecutable, después la vuelve a cifrar y a no-ejecutable. Es la misma idea que usan familias como EnvInject y módulos de Cobalt Strike: reducir la ventana en la que un scanner de memoria puede ver bytes reconocidamente ejecutables.

Lo más interesante es add_to_run, que abusa del Windows Scripted Diagnostics framework. En lugar de crear directamente la clave Run, Antino inicializa COM, instancia el CLSID {1F3D8AA5-9EBF-4EE4-85C2-EA40379AEDE8} implementado por sdiageng.dll, monta el paquete legítimo PCW (Program Compatibility Wizard), escribe un PowerShell atacante en C:WindowsTempSDIAG_<GUID>result.ps1, y luego reanuda el flujo de diagnóstico para que sdiagnhost.exe -Embedding ejecute ese script en un proceso separado. La modificación al registro Run aparece firmada por un binario de Microsoft, lo que vuelve locas a las herramientas de atribución comportamental.

Indicadores de compromiso verificables

Talos publicó los IoCs en su repositorio oficial y ClamAV y Microsoft publicaron firmas. Lo que viene a continuación es el subconjunto accionable para un sysadmin que tiene que poner firmas hoy, no mañana.

Dominios y URLs de entrega

# Cloudflare Pages — entrega de HTA/WSF stagers
my-3lyt6wcp[.]pages.dev
my-qc39r814[.]pages.dev
my-662ylt3w[.]pages.dev
my-6g16qsfe[.]pages.dev
my-goq6xmbm[.]pages.dev
my-h3qli6kq[.]pages.dev
my-sv7c1fzs[.]pages.dev
my-u0up9qri[.]pages.dev
my-vtsdod2n[.]pages.dev
my-wgoxp32b[.]pages.dev
# Dominios de installers maliciosos standalone
soff[.]com (microsoft-flash[.]com)
wps-cn[.]com
# Cloudflare Pages — tracking/ beaconing fijo
oisadjfoinsiduhfnoisdnfosdnoifnsoid[.]pages.dev
# CloudFront — staging de scripts
d2nq35tel3ucuo[.]cloudfront[.]net
# Cloudflare R2 — staging de payloads
r2[.]dev (pub-abfa7742e315485a98a5fafd6dbfb68e)
r2[.]dev (pub-0173d1566dcd4fd49fa25f11f14bfe4c)
# Dominio de phishing envelope sender
osc-cdn[.]com

Hashes SHA256 clave

# Slc.dll (Antino backdoor)
09ef7c736bccfafefc44d9910d499173b88063b73b221fc0dc9e9105107e5cff  Antino Gen 2 slc.dll
e2eb7703047b37b28dc34e6990205d758a2454b39bc655b460606745fadcb530  Antino Gen 2 slc.dll
fdbd047031c13a17c9f491c9355f44d587584ebe2b8927be8482e6c236c8e1c1  Antino Gen 2 slc.dll
# Standalone fake-installer backdoors
0c39264337a1186b2e765e24073399cbdcba118306614eb411e315887af578bd  Antino Gen 2 fake-installer
971cb2448b5d67dcc1f5eaa10d12e77f213035ad31230dc2ac7a510610a2059d  Antino Gen 2 fake-installer
# TestAssembly.dll (Stage 4 downloader) — todas comparten GUID
d753a615aedf8e58ffc75b2b7ebd320c0cbe6bcb5cbb885db749a2a85c55d3bf  TestAssembly.dll
133a46ba41136ca21c93fb08c28446826d8c0d9b7923a16f2d152d595a710098  TestAssembly.dll
# AssemblyAttribute GUID para detección de TestAssembly.dll
b2b3adb0-1669-4b94-86cb-6dd682ddbea3

Firmas ClamAV publicadas

Html.Trojan.UAT-11587-10060367-2
Txt.Trojan.UAT-11587-10060385-5
Txt.Trojan.UAT-11587-10060386-1
Win.Trojan.UAT-11587-10060365-1
Win.Trojan.UAT-11587-10060369-1
Win.Trojan.UAT-11587-10060370-1
Win.Trojan.UAT-11587-10060371-1
Win.Trojan.UAT-11587-10060372-1
Win.Trojan.UAT-11587-10060373-1
Win.Trojan.UAT-11587-10060374-1
Win.Trojan.UAT-11587-10060375-1
Win.Trojan.UAT-11587-10060376-1
Win.Trojan.UAT-11587-10060377-1
Win.Trojan.UAT-11587-10060378-1
Win.Trojan.UAT-11587-10060379-1
Win.Trojan.UAT-11587-10060380-1
Win.Trojan.UAT-11587-10060381-1
Win.Trojan.UAT-11587-10060382-1
Win.Trojan.UAT-11587-10060383-1
Win.Trojan.UAT-11587-10060384-1
# Reglas Snort
Snort 2 / Snort 3: 1:66880, 1:66881, 1:66882

Cómo montar detección práctica en Linux y en endpoints Windows

La mayoría de los sysadmins Linux no gestionan endpoints Windows, pero muchos sí lo hacen a través de EDR, syslog, o pipelines de ingest a SIEM. Lo que viene aplica a ambos mundos.

Detección en el endpoint Linux

# 1. Buscar binarios firmados por Microsoft cargando DLLs no firmadas desde el mismo directorio
# Sysmon-style query: ProcessCreate + ImageLoad
sysmon_query -q "EventID=7 ImageSigned=true Image='C:WindowsSystem32gatherosstate.exe' Signed=false"
# 2. Monitorizar escrituras a %LOCALAPPDATA%Windows GatherOSStateKit
find /mnt/endpoint-data -path '*Windows GatherOSStateKit*' 2>/dev/null
# 3. Buscar escrituras a OneDrive desde procesos no-Office (no es trivial en Linux pero se puede ingestar desde MDE)
# Regla MDE equivalente:
# DeviceFileEvents | where FolderPath has 'OneDrive' and InitiatingProcessFileName !in~ ('outlook.exe','onedrive.exe','excel.exe')

Troubleshooting común en Linux: el endpoint agent reporta el binario legítimo de ADK como firmado correctamente porque lo está. La señal viene del DLL cargado por sideloading, no del ejecutable. Si tu EDR solo mira hash de ejecutables, no detecta nada. Necesitas correlación de eventos de carga de DLL.

Detección en el correo / DMARC

# 4. Forzar DMARC p=quarantine o p=reject en tu dominio
# Sin esto, Antino (y cualquier actor con SPF-aligned + p=none objetivo) sigue entregando
dig TXT _dmarc.tudominio.com +short
# 5. Bloquear dominios de entrega conocidos a nivel de proxy/firewall
# /etc/hosts entries para endpoints sin proxy — usar proxy corporativo en su lugar
echo "0.0.0.0 my-3lyt6wcp.pages.dev" >> /etc/hosts-blocklist-antino
echo "0.0.0.0 my-wgoxp32b.pages.dev" >> /etc/hosts-blocklist-antino
echo "0.0.0.0 oisadjfoinsiduhfnoisdnfosdnoifnsoid.pages.dev" >> /etc/hosts-blocklist-antino
# 6. Monitorizar conexiones mshta.exe / wscript.exe hacia .pages.dev / .r2.dev / cloudfront.net
# En Splunk/ELK:
index=edr (process_name="mshta.exe" OR process_name="wscript.exe") 
  (dest_domain="*.pages.dev" OR dest_domain="*.r2.dev" OR dest_domain="*.cloudfront.net")
  | stats count by dest_domain, user, host

Troubleshooting: la regla de DMARC necesita la firma de todos los terceros que envíen en tu nombre. Si tienes un SaaS de marketing que envía con tu dominio y no firma, pasar a p=quarantine rompe ese envío. Audita primero con p=ct (solo reporting) durante 30 días antes de endurecer.

Detección en el Microsoft 365 tenant

# 7. Buscar aplicaciones Entra ID registradas con client-credentials flow sospechoso
# Graph PowerShell:
Get-MgServicePrincipal -All | Where-Object {
  $_.PreferredSingleSignOnMode -eq 'null' -and
  $_.AppRoles.Count -eq 0 -and
  $_.KeyCredentials.Count -gt 0
} | Select-Object DisplayName, AppId, KeyCredentials
# 8. Buscar actividad Mail.Read / Mail.ReadWrite desde aplicaciones sin usuario asignado
Get-MgAuditLogSignIn -Filter "appId ne null" | Where-Object {
  $_.AppDisplayName -match 'Antino|UAT-11587|unknown'
}
# 9. Activar Microsoft Defender for Cloud Apps session policies para OneDrive
# Bloquear uploads a /antino/ / /antinousings / /antinousers/ desde orígenes desconocidos
New-DlpComplianceRule -Name "Antino-OneDrive-Block" `
  -Policy "DLP-Policy-General" `
  -ContentContainsSensitiveInformation $false `
  -Condition "ContentPattern: /antino/" `
  -Action Block

Troubleshooting: el token client-credentials de Antino probablemente use una aplicación Entra ID registrada en otro tenant, no en el tuyo. Por eso, una buena detección es auditar sign-ins sin usuario hacia tu tenant desde IPs sospechosas o patrones atípicos. Si el atacante usó una app maliciosa registrada en su propio tenant, el log de Graph no te lo muestra — necesitas correlacionar con el sign-in log del endpoint.

Qué cambia para un administrador de una organización que no es objetivo

Antino no es un problema solo para Taiwán o Filipinas. La técnica es portable: spear-phishing + DLL sideloading firmado + C2 en SaaS confiable es una combinación que cualquier actor con acceso a recursos puede replicar. Lo que tienes que llevarte de este caso no es la atribución a China-nexus sino tres lecciones tácticas.

La primera es que p=none en DMARC es una invitación abierta a que cualquiera suplante tu marca. Si todavía estás en p=none, mueve a p=quarantine o p=reject tan pronto como confirmes que todos tus remitentes legítimos están alineados. Los próximos Antino van a usar la misma técnica con tu dominio.

La segunda es que necesitas detectar DLL sideloading firmado en tus endpoints Windows. Un binario firmado por Microsoft cargando una DLL del mismo directorio no es comportamiento legítimo de Windows Update ni de Office ni de Edge — es comportamiento de atacante. Si tu EDR no correlaciona ProcessCreate con ImageLoad para DLLs del mismo path, está perdiendo esto.

La tercera es que C2 sobre SaaS confiable exige revisar la cola de auditoría de tu proveedor de identidad y de tu tenant. Si ves una app Entra ID que no reconoces haciendo sign-ins sin usuario, o haciendo llamadas Mail.Read desde una IP nunca vista, eso es señal de Antino o de algo igual de serio. La detección ya no es solo reputación: es comportamiento bajo entropía.

Resumen

Antino es un recordatorio incómodo de que el modelo “bloquear lo malo” ya no escala. Cuando el C2 vive dentro de Microsoft 365, el firewall no puede hacer nada. La defensa vuelve al endpoint y al tenant: PowerShell que no debería correr, DLLs que no deberían estar ahí, aplicaciones Entra ID que nadie autorizó, y JSON de heartbeat subidos a OneDrive que ningún usuario legítimo está generando. Para sysadmins, la prioridad no es firmar dominios nuevos sino auditar la cadena de eventos del endpoint y la cola del tenant. Para equipos rojos y azules, la lección es que la creatividad del atacante ya no está en payloads exóticos sino en mover el canal a donde todos miran.

Preguntas frecuentes

¿Por qué Antino: el backdoor Rust de UAT-11587 que usa Microsoft 365 como C2 es relevante para sysadmins Linux?

Forma parte del flujo diario de administración. Los conceptos explicados se aplican directamente a servidores en producción y resuelven problemas reales que enfrentan sysadmins hispanohablantes.

¿Qué necesito para empezar con Antino: el backdoor Rust de?

Distribución Linux actualizada (Debian, Ubuntu, RHEL, Fedora o Arch), acceso root, y conexión a internet. Para producción: entorno de staging separado antes de aplicar cambios.

¿Cuáles son los errores más comunes con Antino: el backdoor Rust de?

Los tres más frecuentes: (1) saltar la lectura de logs, (2) aplicar cambios directos en producción sin probar, (3) olvidar permisos y ownership. La documentación y un plan de rollback siempre.

¿Cuándo usar Antino: el backdoor Rust de y cuándo una alternativa?

Esta solución es ideal para el caso descrito. Alternativas como Docker, Ansible o configuración manual pueden ser mejores según contexto: portabilidad, escala y reproducibilidad son los factores clave.

¿Cómo migro desde una configuración previa a Antino: el backdoor Rust de?

Documentar el estado actual, probar la nueva configuración en staging, validar funcionalmente, y aplicar en producción con rollback plan listo. Los posts de SoyLinux incluyen troubleshooting para los problemas más comunes.