5 de octubre

  1. Principales Vulnerabilidades y Filtraciones de la semana

  2. "Instala Claude" y entrega tus credenciales: la campaña que convierte la confianza en IA en el vector de ataque más activo de 2026

  3. 1.313 CVEs en una sola actualización: lo que el kernel de Linux nos dice sobre el futuro de la gestión de vulnerabilidades

  4. Antino: el implante chino que convierte tu buzón de Outlook en un panel de mando de espionaje

💥 MikroTik RouterOS sigue sumando CVEs esta semana: subdesbordamiento de enteros (integer underflow) en RouterOS que añade otro vector de ataque a los dispositivos ya afectados por MikroTrick, mientras CISA confirma que CVE-2023-30799 (privilege escalation a SuperAdmin) sigue siendo activamente explotado en ataques contra routers sin parchear (INCIBE / The Hacker News)

💥 FortiMail 0-day CVE-2026-104286 (CVSS 9.8): explotado activamente, sin parche disponible aún. Path traversal combinado con manejo incorrecto de NULL bytes en la interfaz web de FortiMail permite a un atacante no autenticado escribir ficheros arbitrarios en el sistema y ejecutar código. (BleepingComputer / INCIBE / SecurityWeek)

💥 TeamViewer corrige cinco vulnerabilidades de alta severidad en boletín TV-2026-1010. La más grave, CVE-2026-92370 (CVSS 8.8), permite a un atacante remoto autenticado saltarse los controles de acceso configurados durante el establecimiento de la sesión y realizar acciones que el usuario objetivo había denegado explícitamente, con potencial de llegar a RCE. (CybersecurityNews / BleepingComputer)

💥 Múltiples vulnerabilidades críticas en Apache HTTP Server. El servidor web más usado del mundo recibe su boletín de seguridad con varios fallos de severidad alta entre los que destaca un path traversal con potencial de exposición de ficheros fuera del DocumentRoot en configuraciones específicas (INCIBE)

💥 BTR (Branch Target Reuse): nueva variante de Spectre-v2 que extrae el hash de root de Linux en 3-5 minutos en CPUs Intel, AMD y Arm. VUsec (VU Amsterdam) publicó el PoC completo aceptado en ACM CCS 2026: explota la reutilización de memoria de compiladores JIT (incluyendo el kernel de Linux cBPF) para provocar que la CPU ejecute especulativamente código antiguo con datos del estado actual, filtrando bytes de memoria privilegiada a 8 bytes por segundo. (The Hacker News / VUsec paper)

💥 Citrix NetScaler: los dos zero-days que hicieron apagar appliances en todo el mundo ya tienen parche. CVE-2026-88771 (CVSS 9.5, RCE no autenticado por validación incorrecta de entrada, afecta a todas las configuraciones incluyendo la por defecto) y CVE-2026-88772 (CVSS 9.5, memory overflow con RCE, afecta cuando DTLS está activo, que es la configuración por defecto en servidores VPN) fueron explotados como zero-days antes de que existiera ningún parche ni CVE asignado. (BleepingComputer / SecurityWeek)

"Instala Claude" y entrega tus credenciales: la campaña que convierte la confianza en IA en el vector de ataque más activo de 2026

La captura que ves arriba, donde alguien te pide que abras PowerShell, copies un comando y lo ejecutes para "instalar Claude", no es nueva. Es la versión más reciente de una campaña que lleva meses evolucionando, se ha extendido a casi todas las herramientas de IA populares y ha comprometido organizaciones en todos los continentes. Lo que la hace especialmente peligrosa no es su sofisticación técnica, que existe y es notable, sino algo mucho más difícil de defender: explota la disposición del usuario a seguir instrucciones de instalación sin cuestionarlas, especialmente cuando vienen de una herramienta en la que confía.

El dominio que aparece en la captura, cladesktop-apps.com, ya está documentado. Intellibron lo identificó en septiembre como parte de una infraestructura activa de entrega de infostealers en memoria, junto con otros dominios como freshbase11.com, wiseview58.com, fairpoint29.com y primemetricsa.com. El comando que propone ejecutar, mshta https://last-version.install-2026.com/app, sigue exactamente la misma lógica de las cadenas documentadas desde abril: usar mshta.exe, un binario legítimo de Windows que ejecuta aplicaciones HTML (HTA), para descargar y correr código malicioso sin que el usuario vea nada sospechoso.

La historia completa empieza antes. El 9 de abril de 2026, Rapid7 detectó en uno de sus clientes una ejecución de mshta.exe lanzada desde el diálogo Ejecutar de Windows, con una URL que apuntaba a download-version.1-5-8.com/claude.msixbundle. El fichero parecía un paquete MSIX legítimo de Microsoft, con cabecera ZIP válida y firma del Marketplace de Microsoft. Dentro había un payload HTA que ejecutaba un script VBScript con la ventana reducida a cero píxeles para que la víctima no viera nada mientras la cadena corría.

Pocos meses después, Cyderes documentó una variante más sofisticada: el payload llegaba como un fichero MP3 de 6,7 MB. VLC lo leía como audio reproducible y lo consideraba legítimo. mshta.exe, sin embargo, al procesarlo encontraba el bloque de script HTA embebido al final del fichero y lo ejecutaba. Es un polígoto MP3/HTA: un solo fichero que es dos cosas distintas según quién lo abre. La técnica sirve para pasar inspecciones de tipo de fichero sin activar alertas.

La cadena técnica completa que han documentado Rapid7 y Trend Micro sobre variantes de esta campaña funciona así:

La víctima busca "instalar Claude" o "Claude Code install" en Google. Un anuncio de pago aparece en las primeras posiciones, con un dominio que tiene el nombre de Claude o Anthropic en algún lugar. La página de destino imita con precisión la documentación oficial: colores, tipografía, logotipo. Muestra una ventana modal de "instalación" con pasos numerados, exactamente como una guía legítima. El paso 2 copia un comando al portapapeles automáticamente (sin que el usuario lo solicite), y los pasos 3 y 4 explican cómo pegarlo en PowerShell o en el diálogo Ejecutar y presionar Enter.

Cuando el usuario ejecuta el comando, mshta.exe descarga el payload. Este construye un PowerShell ofuscado de segunda etapa que parchea AMSI (el sistema de análisis de scripts de Windows, que normalmente detectaría malware en PowerShell) directamente en memoria antes de ejecutar nada más. Luego inyecta shellcode cifrado en un proceso legítimo del sistema. Todo ocurre en memoria: no hay fichero malicioso escrito en disco que un antivirus pueda escanear. El infostealer resultante extrae contraseñas de todos los navegadores Chromium y Firefox, tokens de sesión, cookies, wallets de criptomonedas, claves SSH, credenciales almacenadas en el gestor de Windows, y en algunas variantes hace capturas de pantalla. Los datos salen cifrados hacia infraestructura del atacante.

La evolución de la campaña a lo largo de 2026 es la parte más reveladora. No se quedó en Claude. Pillar Security ha mapeado 16 campañas distintas entre 2025 y 2026 que usan la misma técnica contra ChatGPT, Cursor IDE, Perplexity, JetBrains, Claude Code, Grok, DeepSeek, InVideo AI y otros. En macOS el payload cambia (Terminal en vez de PowerShell, el infostealer MacSync en vez de variantes .NET), pero la estructura es idéntica.

Lo más interesante desde el punto de vista táctico es cómo los atacantes han ido escalando el uso de infraestructura confiable para eludir los filtros. Primero usaron dominios propios. Luego pivotaron a Google Sites, porque sites.google.com pasa la mayoría de los filtros de reputación de dominio corporativos. Más tarde, TrendMicro documentó que abusaron directamente de las conversaciones compartidas de claude.ai: creaban una conversación en Claude que contenía las instrucciones de ClickFix, la compartían como URL pública de claude.ai, y la usaban como destino de los anuncios. La URL de destino del anuncio era un dominio de Anthropic legítimo. Más recientemente, Huntress documentó la variante más elaborada: un Custom GPT de OpenAI llamado "Plus 5.6" (diseñado para parecer un modelo oficial de ChatGPT) con aproximadamente 850 anuncios de pago en Google, 26 destinos de Custom GPT y 71 IDs de campaña distintos a lo largo de tres meses. El flujo era: el usuario busca ChatGPT, hace clic en el anuncio, llega a un Custom GPT de apariencia oficial, introduce un prompt, el GPT responde con un mensaje de "dominio de backup por alto tráfico", sigue el enlace, llega a una página de verificación Cloudflare falsa con instrucciones ClickFix, ejecuta el comando y descarga un RAT.

Por qué funciona tan bien es una pregunta con una respuesta que no gusta oír: porque los usuarios que buscan instalar herramientas de desarrollo confían en las instrucciones de instalación, especialmente si la página parece oficial. El comando mshta o mshta.exe puede sonar técnico, pero si la interfaz dice que es un paso necesario de verificación o instalación, la mayoría lo ejecuta. Además, los desarrolladores y usuarios técnicos que son el objetivo de estas campañas están acostumbrados a ejecutar comandos en terminal como parte del flujo normal de instalación de software. Un brew install o un pip install no levantan sospechas. Este ataque aprovecha exactamente ese hábito.

IOCs documentados:

  • Dominios de lure: cladesktop-apps.com, download-version.1-5-8.com, download.version-516.com, last-version.install-2026.com, freshbase11.com, wiseview58.com, fairpoint29.com, primemetricsa.com, swiftmatrix15.com

  • Dominio de entrega ChatGPT: openai-backup.one

  • Proceso clave de detección: mshta.exe lanzado desde explorer.exe o el diálogo Ejecutar, especialmente con URLs remotas

  • Artefacto de registro: clave RunMRU con entradas de mshta (registra los últimos 26 comandos ejecutados vía Win+R)

  • Payload: UltraFreeISOCreateWizardSolution.msi en variantes más recientes

Qué monitorizar: mshta.exe con URL remota como argumento, lanzado desde el diálogo Ejecutar o desde un navegador; carga de .NET reflectiva; procesos leyendo ficheros de credenciales de perfiles de navegador; conexiones salientes desde procesos que no deberían hacerlas. Un EDR configurado para alertar sobre mshta.exe originado en explorer.exe habría bloqueado la mayoría de estas cadenas.

La regla práctica para usuarios es simple y vale la pena repetirla: ningún software legítimo te pedirá nunca abrir PowerShell o el diálogo Ejecutar y pegar un comando copiado de una web como paso de instalación. Nunca. Si una página de instalación incluye ese paso, es un ataque. La instalación de Claude Desktop se hace desde claude.ai/download directamente, sin ningún comando manual.

1.313 CVEs en una sola actualización: lo que el kernel de Linux nos dice sobre el futuro de la gestión de vulnerabilidades

El 29 de septiembre, el equipo de seguridad de Debian publicó el advisory DSA-6528-1 para su distribución estable Trixie (Debian 13). La firma habitual: "se han descubierto varias vulnerabilidades en el kernel de Linux que pueden llevar a escalada de privilegios, denegación de servicio o fugas de información". La versión corregida: 6.12.111-1. Lo inusual: la lista de CVEs que corregía esa actualización tenía 1.313 entradas. Cuatro cifras. No es un error tipográfico, como ya ha aclarado todo el que lo ha cubierto esta semana.

Antes de entrar en lo que significa realmente, contexto inmediato: llega tres semanas después de que Microsoft publicara un Patch Tuesday de 966 CVEs que ya rompía todos sus récords históricos. En la misma semana que el advisory del kernel de Debian, la distribución publicó también DSA-6534-1 para webkit2gtk con 232 CVEs, DSA-6535-1 para Chromium con 32 CVEs y un advisory para Thunderbird con 44. El 2 de octubre, el sitio Linux Compatible hizo el recuento del día: ocho distribuciones distintas, más de 600 CVEs en boletines de seguridad en un solo día, con Debian liderando gracias a los 232 de webkit2gtk en una sola entrada.

¿Qué ha pasado realmente?

El número 1.313 no refleja que el kernel de Linux haya tenido de repente 1.313 vulnerabilidades nuevas y críticas que antes nadie conocía. Refleja un cambio de política en la forma en que el proyecto del kernel de Linux asigna CVEs, que lleva en marcha desde 2024 pero cuyos efectos se están acumulando de forma cada vez más visible.

El cambio es este: el kernel de Linux ha pasado a asignar un CVE a prácticamente cualquier commit identificado como corrección de un problema de seguridad potencial, incluso si ese problema es menor, no tiene un exploit conocido, afecta a un subsistema que la mayoría de sistemas no utilizan, o cuyo impacto real es tan condicionado que en la práctica es imposible de explotar. La lógica detrás es razonable en abstracto: la transparencia máxima permite que cada organización evalúe su exposición específica en lugar de fiarse del criterio del equipo del kernel sobre qué merece atención y qué no. En la práctica, el resultado es una avalancha de entradas que convierte el número de CVEs en una señal de ruido más que de riesgo.

9to5Linux lo resume bien: "ver más de 1.300 vulnerabilidades en una sola actualización del kernel de Debian es abrumador, pero la gran mayoría de estos CVEs son de baja severidad, muy condicionados, o afectan a subsistemas irrelevantes para cualquier máquina concreta. La actualización sigue mereciendo aplicarse, pero no son 1.313 problemas críticos independientes".

El advisory de Debian lo confirma con su propio lenguaje: el equipo evalúa cada problema en el contexto específico de Debian, y las correcciones de menor impacto se incluyen junto con las más graves. En otras palabras, la lista de 1.313 agrupa desde fallos que podrían permitir a un usuario local escalar a root bajo condiciones muy específicas de hardware y configuración, hasta correcciones preventivas en controladores de dispositivos que quizás ningún sistema en producción tenga activo. No hay ninguna de esas 1.313 entradas con explotación confirmada en el momento de publicarse el advisory.

Pero el problema real no es este advisory concreto.

Lo que DSA-6528-1 ilustra es una tendencia más amplia y más preocupante para los equipos de seguridad: la inflación de CVEs está rompiendo los modelos de gestión de vulnerabilidades basados en contar y parchear.

El sistema CVE nació como un diccionario común que permitiera a distintas herramientas y organizaciones hablar del mismo fallo con el mismo identificador. Cumplía bien ese propósito cuando los CVEs eran escasos y cada uno representaba un problema concreto, bien delimitado y razonablemente explotable. Hoy, la combinación de tres factores ha hecho que eso ya no sea así: primero, la política del kernel de Linux de asignar CVEs a correcciones preventivas de baja severidad; segundo, el uso creciente de herramientas de análisis asistidas por IA que descubren vulnerabilidades potenciales a un ritmo que los humanos no pueden seguir (los propios ingenieros de Microsoft lo reconocieron implícitamente como explicación parcial de su Patch Tuesday récord de septiembre); y tercero, la proliferación de CNAs (autoridades numeradoras de CVE) que aplican criterios distintos de severidad y alcance.

El resultado práctico para un equipo de seguridad con recursos limitados, que es la mayoría, es un problema de priorización irresoluble si se usa el número de CVEs como métrica principal. Una organización que recibe 1.313 CVEs en una sola actualización no puede triagear cada uno de forma independiente. Necesita filtros: ¿tiene exploit conocido? ¿está en el KEV de CISA? ¿es explotable desde red sin autenticación? ¿afecta a subsistemas activos en mi entorno? Esos filtros ya existían, pero se vuelven más necesarios que nunca cuando el volumen bruto de CVEs deja de ser una señal útil.

Lo que hay que hacer con la actualización concreta, independientemente de la lectura macro: aplicarla. La versión corregida para Debian Trixie es 6.12.111-1, disponible desde el repositorio de seguridad de Debian. Que la mayoría de los 1.313 fallos sean de baja severidad no significa que todos lo sean, y la separación señal/ruido en el advisory no está documentada entrada por entrada. La actualización existe, está disponible y no tiene efectos adversos conocidos. Los entornos con unattended-upgrades configurado ya la habrán aplicado automáticamente.

La lección más duradera no es "aplicad este parche" sino una más incómoda: el CVE como unidad de medida de riesgo está perdiendo fiabilidad. En un mundo donde un solo advisory puede listar 1.313 entradas y otro (el Patch Tuesday de Microsoft de septiembre) puede listar 966, el número de CVEs pendientes ha dejado de ser un indicador útil de la postura de seguridad de una organización. Lo que importa es cuántos de esos CVEs son explotables en tu entorno específico, cuántos tienen exploit público o están en el KEV, y cuántos afectan a sistemas expuestos. Eso requiere contexto, no conteo.

Antino: el implante chino que convierte tu buzón de Outlook en un panel de mando de espionaje

El 30 de septiembre, Cisco Talos publicó el análisis de una campaña de espionaje con nexo China que lleva activa desde septiembre de 2025 y que han rastreado durante diez meses sin que apareciera en ningún informe público previo. El actor, que Talos designa UAT-11587, ha comprometido aproximadamente 350 endpoints en 16 entornos institucionales de ocho países asiáticos (Taiwán, India, Filipinas, Camboya, Pakistán, Tailandia, Myanmar y Siria), atacando exclusivamente organismos gubernamentales, de defensa, diplomáticos, parlamentarios y de política exterior, junto con think tanks, universidades y organizaciones de derechos humanos. El payload final de la campaña es Antino, un backdoor compilado en Rust con una característica que lo distingue de prácticamente todo lo documentado hasta ahora: su canal de mando y control no utiliza ningún servidor propio. Toda la comunicación pasa por Microsoft 365.

La entrada: un email que parece Gmail

Los correos de spear-phishing de UAT-11587 son notablemente precisos en su contenido. Los señuelos recuperados incluyen un documento sobre un taller de "guerra informativa en Taiwán" que reproduce terminología y contexto que solo conocería alguien familiarizado con la comunidad objetivo, una resolución real del Ministerio de Finanzas taiwanés sobre el tratamiento fiscal de los gastos de legisladores (diseñada para funcionarios concretos del sector público), un documento titulado "CSIS Indo-Pacific Forecast 2026" con agenda y ponentes verosímiles, y un artículo de noticias titulado "El ex asesor de Trump sobre Rusia afirma que Moscú ofreció libertad en Venezuela a cambio de Ucrania", parafraseando una noticia real de AP y subiendo a VirusTotal dos días después.

El vector técnico de entrega tiene un detalle refinado: el cuerpo del email contiene código HTML que reconstruye con precisión visual el widget de adjuntos de Gmail, usando cuatro imágenes PNG en Base64 como partes MIME. Un usuario que abra el email en un navegador ve lo que parece exactamente un adjunto real de Gmail. Al hacer clic, no se descarga nada: la URL apunta a Cloudflare Pages, donde empieza la cadena de infección.

El actor también abusa de la distinción entre el remitente SMTP (envelope) y el campo From visible. Envía los mensajes a través de Migadu usando el dominio controlado osc-cdn.com como remitente técnico, mientras el campo From visible muestra la organización que está suplantando. SPF pasa porque Migadu está autorizado para ese dominio. DMARC falla, pero el dominio visible tenía política p=none, que solo pide monitorización y no bloqueo. El mensaje llega al buzón del destinatario con apariencia totalmente legítima.

La cadena de infección: cinco fases para llegar al implante

Clic en el falso adjunto de Gmail → URL en Cloudflare Pages → descarga de un archivo HTA (o WSF en variantes alternativas), ejecutado por mshta.exe. El HTA emite una petición de seguimiento al dominio de tracking de Cloudflare Pages (oisadjfoinsiduhfnoisdnfosdnoifnsoid.pages.dev) incluyendo el título del señuelo en la URL, lo que permite al operador saber qué víctima ha abierto qué versión del email. Luego descarga el siguiente stage desde Cloudflare R2 o Amazon CloudFront.

El segundo stage es JScript alojado en el HTA, cifrado con RC4 y descifrado en memoria. Su función es descargar tres recursos cifrados: un orquestador JScript y dos recursos de gadgets .NET serializados. Estos tres elementos forman la cadena de deserialización de BinaryFormatter (Etapa 3): el orquestador JScript instancia clases .NET visibles desde COM y pasa los datos serializados a BinaryFormatter, que al deserializarlos ejecuta la cadena de gadgets ActivitySurrogateSelector. El resultado es que TestAssembly.dll se carga directamente en memoria dentro del proceso mshta.exe, sin tocar disco como DLL reconocible. El actor incluye un paso previo que intenta deshabilitar la comprobación de seguridad de .NET que bloquea este tipo de gadget, con un bloque try/catch que lo rodea para funcionar en distintas versiones del framework.

TestAssembly.dll (Etapa 4) descarga desde Cloudflare R2 el documento señuelo, lo abre para distraer a la víctima, y junto a él descarga tres archivos con extensiones aleatorias inusuales (.luy, .pzs, .syk): GatherOsState.exe, una herramienta legítima y firmada por Microsoft del Kit de Evaluación y Despliegue (ADK) de Windows; slc.dll, el backdoor Antino; y un PE señuelo adicional. Los lanza desde un directorio de staging y ejecuta GatherOsState.exe, que por DLL sideloading carga slc.dll desde su propio directorio, activando Antino.

Toda la cadena de entrega pasa por Cloudflare Pages, Cloudflare R2 y Amazon CloudFront. Desde la perspectiva de la red, son peticiones HTTPS a CDNs masivamente usados. No hay ningún dominio propio del actor en el trayecto hasta que el implante está corriendo.

Antino: cómo se convierte Outlook en un panel de mando

Antino es un backdoor compilado en Rust (disponible en versiones de 32 y 64 bits), nombrado así por los artefactos de desarrollo que Talos recuperó: rutas PDB del tipo D:\a\antino\antino\..., estructura de GitHub Actions en Windows, y el identificador AntinoApp en el manifiesto de la aplicación Windows. Talos identificó dos generaciones del implante, con diferencias en la generación del session ID y en el modelo de registro y heartbeat.

Lo que diferencia a Antino de prácticamente cualquier otro backdoor documentado es su arquitectura de C2. No hay ningún servidor propio del atacante al que conectarse. El implante se autentica con Microsoft Graph API usando el flujo OAuth 2.0 de credenciales de cliente (client-credentials), lo que le da acceso a los recursos de Microsoft 365 de una cuenta controlada por el atacante sin ningún login interactivo. A partir de ahí, usa dos canales paralelos:

El primero, a través de Outlook, es el canal de comandos. Cada 10 segundos, Antino consulta la bandeja del buzón del atacante buscando mensajes cuyo asunto empiece por command_req_[session_id]. El cuerpo del mensaje contiene un objeto JSON con tres campos: command_type (el comando a ejecutar), command_data (parámetros específicos) y request_id (para correlacionar respuesta con petición). Cuando el implante completa la ejecución, envía un email de respuesta con asunto command_res_[session_id] y el resultado en el mismo formato JSON. El operador envía comandos y lee resultados vía el buzón de Outlook de su cuenta M365. El implante y el operador nunca se conectan entre sí directamente.

El segundo, a través de OneDrive, es el canal de heartbeat y transferencia de ficheros. Cada 60 segundos, Antino sube un JSON a /antino/heartbeats/{session_id}.json con el estado del host: session ID, timestamp, nombre de máquina, usuario, plataforma y código de campaña. Para recibir herramientas del atacante, comprueba /antino_uploads/; para exfiltrar ficheros de la víctima, los sube a /antino_downloads/. La nomenclatura es desde la perspectiva del operador: "uploads" son cosas que el operador empuja hacia la víctima, "downloads" son datos que el operador extrae de ella.

Todo el tráfico de red resultante termina en graph.microsoft.com y login.microsoftonline.com, dominios universalmente confiables y habitualmente en lista blanca en entornos corporativos. No hay ninguna conexión a IPs o dominios desconocidos en ningún momento del ciclo de vida del implante.

Capacidades y evasión de memoria

El backdoor soporta reconocimiento del host (system_info, list_files), ejecución de comandos (cmd, powershell), ejecución de programas (execute_program), carga de shellcode en memoria (load_shellcode), transferencia de ficheros (upload_file, download_file) y persistencia (add_to_run).

Para la ejecución de shellcode, Antino incluye una técnica de enmascaramiento de memoria: cuando el parámetro use_sleep_mask está activo, el implante hookea Sleep y VirtualAlloc y registra un manejador de excepciones vectoriales (VEH). Cuando el thread del payload llama a Sleep, el hook cambia la región de memoria a no ejecutable, la cifra en su sitio con XOR, y llama al Sleep real. Cuando el thread intenta ejecutar desde esa región cifrada, se genera una infracción de acceso; el VEH la captura, descifra la región, restaura los permisos de ejecución y reanuda. El objetivo es reducir la ventana de tiempo en que los escáneres de memoria pueden observar bytes ejecutables reconocibles del payload.

Para la persistencia, Antino abusa del framework Windows Scripted Diagnostics: crea una instancia COM de CScriptedDiag, la inicializa con el paquete PCW legítimo de Windows, escribe un script PowerShell controlado por el atacante en el directorio temporal de trabajo del diagnóstico, y el workflow de diagnóstico lo ejecuta vía sdiagnhost.exe. El resultado es que la creación de la clave Run y la ejecución de PowerShell aparecen originadas por un proceso de diagnóstico firmado por Microsoft, no por el propio implante.

IOCs y detección

La detección en red es estructuralmente difícil precisamente por el diseño. Lo que Talos recomienda monitorizar en el endpoint:

  • mshta.exe con URLs de Cloudflare Pages o CloudFront como argumento, especialmente con el parámetro ?track

  • GatherOsState.exe ejecutándose desde rutas distintas a su ubicación estándar (el ADK no se usa en producción habitual)

  • Actividad anómala de Microsoft Graph API asociada a aplicaciones Entra ID no reconocidas

  • Paths de OneDrive con los patrones /antino/heartbeats/, /antino_uploads/, /antino_downloads/

  • Subjects de email con prefijos command_req_ o command_res_ en buzones corporativos

  • sdiagnhost.exe ejecutando scripts PowerShell en paths temporales C:\Windows\Temp\SDIAG_<GUID>

IOCs seleccionados (lista completa en el GitHub de Talos):

  • Dominio de tracking: oisadjfoinsiduhfnoisdnfosdnoifnsoid.pages.dev

  • CloudFront de staging: d2nq35tel3ucuo.cloudfront.net

  • R2 de staging: pub-abfa7742e315485a98a5fafd6dbfb68e.r2.dev, pub-0173d1566dcd4fd49fa25f11f14bfe4c.r2.dev

  • Fake installers: microsoft-flash.com, wps-cn.com

  • Dominio SMTP del actor: osc-cdn.com

  • AssemblyAttribute GUID de TestAssembly.dll: b2b3adb0-1669-4b94-86cb-6dd682ddbea3

  • Hashes de backdoor Antino Gen2: 09ef7c736bccfafefc44d9910d499173b88063b73b221fc0dc9e9105107e5cff, e2eb7703047b37b28dc34e6990205d758a2454b39bc655b460606745fadcb530

El contexto más amplio: el año de los implantes en infraestructura cloud legítima

Antino no es el primer implante en usar Microsoft 365 como C2. HollowGraph, que cubrimos en julio, usaba eventos de calendario de Microsoft 365 con el mismo concepto de dead-drop. Lo que diferencia a Antino es la sofisticación del conjunto completo: la ingeniería social de los señuelos, la cadena de cinco etapas que solo usa infraestructura cloud ampliamente confiable hasta la instalación del implante, y la robustez del mecanismo de C2 con dos canales independientes y redundantes. El hecho de que Talos lo haya rastreado durante diez meses antes de publicarlo, con 350 endpoints comprometidos y 16 entornos afectados sin que apareciera en ningún otro informe, dice mucho sobre su capacidad de evasión.

NuestiberSOC monitoriza la seguridad sobre su infraestructura, detectando de manera temprana cualquier incidente crítico para su organión.

Nuestro equipo de RedTeam hace una evaluación de la seguridad, simulando un ciberataque externo, poniendo así a prueba a toda la organización.

Disponemos de una plataforma de formación y concienciación con material para que su organización sepa enfrentarse a las principales amenazas.