El Mercado Underground de Malware-Signing-as-a-Service que Hace que el Ransomware Parezca “Verificado” en Windows

El Concepto Técnico Central: La Firma de Código

En el centro de la interrupción por parte de Microsoft de la operación cibercriminal Fox Tempest se encuentra un mecanismo fundamental de confianza del que los sistemas operativos modernos dependen enormemente: la firma de código.

La firma de código es un marco criptográfico de confianza utilizado por sistemas operativos como Windows para verificar tanto la integridad como el origen del software ejecutable. Cuando un desarrollador firma un binario — como un EXE, DLL, instalador MSI, controlador de kernel, módulo de PowerShell o paquete de software — el sistema operativo puede determinar si:

  • el archivo ha sido modificado después de ser firmado,
  • la identidad del editor es confiable,
  • y el software proviene de una fuente reconocida.

El mecanismo está construido sobre Infraestructura de Clave Pública (PKI) y criptografía asimétrica.

Un editor de software genera:

  • una clave privada de firma,
  • y una clave pública de verificación.

La clave privada se utiliza para crear una firma digital sobre el hash criptográfico del ejecutable. La clave pública está incrustada dentro de un certificado emitido por una Autoridad Certificadora (CA) confiable. Windows entonces valida:

  • la cadena de certificados,
  • la ruta de confianza de la autoridad certificadora,
  • la integridad del archivo,
  • los metadatos de marca de tiempo,
  • los periodos de validez del certificado,
  • y el estado de revocación.

Si la validación tiene éxito, el ejecutable se asocia con una identidad de editor verificada.

Para los usuarios, esto normalmente aparece como:

  • avisos de “Editor Verificado”,
  • advertencias reducidas de SmartScreen,
  • menor fricción de instalación,
  • y menos alertas de ejecución.

Para entornos empresariales, la firma de código es aún más importante porque múltiples controles de seguridad tratan los binarios firmados de forma diferente a los archivos no firmados.

Los sistemas de seguridad incluyendo:

  • Microsoft Defender SmartScreen,
  • Windows Defender Application Control (WDAC),
  • AppLocker,
  • motores de reputación en la nube,
  • y plataformas modernas EDR

todos incorporan reputación del firmante y confianza del editor dentro de las decisiones de ejecución.

Los binarios no firmados frecuentemente activan:

  • análisis heurístico,
  • detonación en sandbox,
  • advertencias de ejecución,
  • búsquedas de reputación en la nube,
  • o bloqueo directo.

Los binarios firmados frecuentemente reciben:

  • puntuaciones de sospecha más bajas,
  • inspección conductual retrasada,
  • menor prioridad de sandbox,
  • y confianza temporal de ejecución mientras los sistemas de telemetría recopilan contexto.

Esta distinción es operacionalmente crítica.

Los operadores modernos de malware apuntan cada vez más a los propios sistemas de confianza en lugar de depender exclusivamente de vulnerabilidades de software.

Cómo Funcionan los Sistemas Modernos de Confianza y Reputación

La mayoría de los productos modernos de seguridad endpoint ya no dependen únicamente de firmas estáticas de malware. Los pipelines contemporáneos de detección combinan:

  • aprendizaje automático,
  • telemetría en la nube,
  • análisis conductual,
  • reputación del editor,
  • puntuación de prevalencia,
  • análisis de cadena de confianza,
  • y historial de ejecución.

Windows SmartScreen, por ejemplo, evalúa:

  • si el firmante tiene reputación histórica de confianza,
  • con qué frecuencia aparece globalmente el ejecutable,
  • si el editor tiene asociaciones previas maliciosas,
  • cuánto tiempo ha existido el firmante,
  • y qué tan recientemente apareció el binario por primera vez en la telemetría.

Por lo tanto, un ejecutable firmado se comporta de manera muy diferente dentro de los sistemas de confianza de Windows que un binario no firmado descargado desde una fuente desconocida.

Esto crea una poderosa asimetría operacional.

Si los atacantes pueden obtener firmas legítimas, pueden manipular los cálculos de confianza el tiempo suficiente para que el malware se ejecute antes de que las detecciones impulsadas por telemetría maduren completamente.

Esa corta ventana de ejecución suele ser todo lo que necesitan los operadores de ransomware.

El Abuso Tradicional de la Firma de Código

Históricamente, los actores de amenazas abusaban principalmente de la firma de código mediante el robo de certificados.

Los atacantes apuntaban a:

  • proveedores de software,
  • fabricantes de hardware,
  • servidores empresariales de compilación,
  • estaciones de trabajo de desarrolladores,
  • estudios de videojuegos,
  • e infraestructura CI/CD

para robar certificados legítimos de firma y claves privadas.

Varias campañas importantes de malware aprovecharon exitosamente certificados robados:

  • Stuxnet abusó de certificados robados de Realtek y JMicron,
  • Flame explotó cadenas fraudulentas de certificados de Microsoft,
  • ShadowPad aprovechó entornos comprometidos de firma de software,
  • y múltiples grupos de ransomware utilizaron certificados EV robados para suprimir advertencias de SmartScreen.

Estos incidentes expusieron una debilidad estructural en el modelo tradicional de firma:
la propia clave privada de firma se convirtió en un objetivo de alto valor.

Si los atacantes obtenían la clave, podían firmar malware arbitrario mientras aparentaban legitimidad operacional ante Windows y productos empresariales de seguridad.

Lo que hace persistentemente atractivo el robo de certificados, a pesar de años de conocimiento público, es su perfil forense asimétrico. Un certificado robado frecuentemente produce:

  • ninguna provisión sospechosa de tenant,
  • ninguna incorporación anómala en la nube,
  • y ninguna señal obvia de fraude de identidad.

El primer indicador observable suele ser la propia ejecución del malware — momento en el cual el compromiso de primera etapa ya puede estar completo.

Por Qué Microsoft Introdujo Artifact Signing

Microsoft introdujo una plataforma de firma nativa de nube originalmente llamada Trusted Signing, posteriormente renombrada como:

Microsoft Artifact Signing

La arquitectura fue diseñada específicamente para reducir riesgos asociados con claves de firma robadas.

En lugar de que los desarrolladores almacenen certificados localmente, Artifact Signing centraliza las operaciones de firma dentro de infraestructura en la nube controlada por Microsoft y respaldada por Hardware Security Modules (HSMs).

Bajo este modelo:

  • los desarrolladores se autentican ante servicios en la nube de Microsoft,
  • los binarios se cargan a infraestructura de Microsoft,
  • las operaciones de firma ocurren dentro de límites protegidos por HSM,
  • y las claves privadas de firma nunca salen de sistemas administrados por Microsoft.

El diseño estaba destinado a mitigar:

  • el compromiso de estaciones de trabajo de desarrolladores,
  • el robo de claves de firma,
  • el compromiso de pipelines CI/CD,
  • y el abuso prolongado de certificados.

Artifact Signing también soporta flujos modernos CI/CD nativos de nube que requieren firma automatizada de versiones.

Desde una perspectiva defensiva, la plataforma ofrecía varias ventajas:

  • telemetría centralizada,
  • revocación más rápida,
  • certificados de corta duración,
  • monitoreo de abuso más estricto,
  • y menor exposición de activos de firma de largo plazo.

Fox Tempest demostró, sin embargo, que los atacantes ya no necesitaban robar claves de firma si podían manipular el propio proceso de provisión de confianza.

Cómo Fox Tempest Explotó Microsoft Artifact Signing

Microsoft declaró que Fox Tempest no comprometió directamente el backend de Artifact Signing. En cambio, la operación aparentemente abusó sistemáticamente de los flujos de incorporación Azure, verificación de identidad y provisión de tenants.

Según Microsoft y reportes relacionados, el grupo supuestamente creó cientos de tenants Azure y suscripciones en la nube utilizando combinaciones de:

  • identidades sintéticas,
  • organizaciones fachada,
  • registros empresariales comprometidos,
  • métodos de pago operados por mulas,
  • registros fraudulentos,
  • y credenciales robadas.

Los documentos judiciales supuestamente identificaron operadores referenciados como John Doe 1 y John Doe 2, quienes presuntamente utilizaron identidades falsas y suplantaron organizaciones legítimas para provisionar más de 580 cuentas fraudulentas de Microsoft.

Una vez provisionados dentro del ecosistema en la nube de Microsoft, esos tenants obtuvieron acceso a capacidades de Artifact Signing y generaron certificados de firma de corta duración válidos aproximadamente por 72 horas.

Microsoft finalmente revocó más de 1,000 certificados asociados con la operación.

Esto representó una evolución importante en el abuso de firma de malware.

En lugar de proteger un pequeño número de certificados valiosos de larga duración, Fox Tempest industrializó la generación desechable de confianza a escala.

La operación efectivamente transformó la propia infraestructura de confianza de Microsoft en una plataforma Malware-Signing-as-a-Service (MSaaS).

Por Qué los Certificados de Corta Duración se Volvieron Operacionalmente Valiosos

El uso de certificados de 72 horas no fue accidental. Refleja un cambio estratégico más amplio a través de ecosistemas modernos de cibercrimen hacia infraestructura efímera e identidades operacionales desechables.

Históricamente, los atacantes preferían certificados Extended Validation (EV) de larga duración porque transportaban fuerte reputación SmartScreen y podían permanecer utilizables durante meses o años.

Sin embargo, los certificados de larga duración eventualmente se convirtieron en pasivos operacionales.

Una vez que investigadores asocian un certificado con campañas de malware, los defensores pueden:

  • correlacionar ataques relacionados,
  • identificar familias de malware,
  • agrupar afiliados de ransomware,
  • rastrear reutilización de infraestructura,
  • y construir detecciones alrededor de metadatos del firmante.

Un solo certificado de larga duración puede efectivamente convertirse en una huella permanente de atribución.

Fox Tempest en cambio adoptó un modelo de confianza desechable.

Cada operación podía generar:

  • un tenant Azure nuevo,
  • una identidad de editor nueva,
  • un certificado nuevo,
  • y un historial limpio de reputación.

Esto complicó dramáticamente:

  • la atribución,
  • las detecciones basadas en firmantes,
  • el agrupamiento de malware,
  • y la correlación de campañas.

La estrategia explotó una debilidad fundamental en sistemas de seguridad impulsados por reputación:
la reputación toma tiempo en construirse.

Los pipelines modernos de detección frecuentemente requieren horas o días para:

  • detonar malware,
  • analizar comportamiento,
  • correlacionar telemetría,
  • distribuir detecciones,
  • actualizar sistemas de reputación,
  • e identificar superposición de infraestructura.

Fox Tempest comprimió los tiempos operacionales por debajo de ese umbral de detección.

Para el momento en que:

  • Microsoft actualizaba sistemas de revocación,
  • plataformas EDR correlacionaban abuso,
  • la reputación de SmartScreen colapsaba,
  • y proveedores de seguridad distribuían detecciones,

la infraestructura de certificados frecuentemente ya había expirado o rotado.

Esto refleja tendencias más amplias en ecosistemas modernos de cibercrimen donde los atacantes dependen cada vez más de:

  • infraestructura VPS desechable,
  • dominios rotativos,
  • entrega de malware serverless,
  • nodos transitorios de comando y control,
  • cuentas cloud de corta duración,
  • e infraestructura fast-flux.

Fox Tempest aplicó la misma filosofía operacional directamente a las cadenas de confianza de software.

Qué Sucede Después de la Ventana del Certificado de 72 Horas

Un concepto erróneo técnico importante alrededor de la operación es que el malware de alguna manera deja de funcionar una vez que el certificado expira.

No es así como funciona la firma de código en Windows.

La expiración del certificado afecta la validación de confianza — no la ejecución del malware en sí.

Una vez que la víctima ejecuta el malware firmado:

  • el payload se ejecuta normalmente,
  • se instalan mecanismos de persistencia,
  • comienza el robo de credenciales,
  • se despliega malware secundario,
  • y la actividad post-explotación continúa independientemente de la validez del certificado.

La expiración del certificado no:

  • deshabilita el ejecutable,
  • termina el ransomware,
  • elimina persistencia,
  • ni desinstala el malware.

El propósito operacional principal del certificado es facilitar una ejecución inicial confiable.

Una vez que la ejecución tiene éxito, la infraestructura de firma ya cumplió su propósito.

El timestamping es críticamente importante aquí.

La mayoría de binarios legítimamente firmados incluyen marcas de tiempo confiables que prueban que el ejecutable fue firmado mientras el certificado seguía siendo válido. Windows generalmente valida si:

el certificado era válido al momento de la firma,

en lugar de requerir que el certificado permanezca válido indefinidamente después.

Como resultado, malware firmado durante la ventana operacional de 72 horas puede continuar apareciendo criptográficamente válido incluso después de que el certificado expira.

Una campaña de malvertising de finales de 2025 abusó específicamente de certificados de corta duración combinados con servicios legítimos de firma de código para eludir detecciones basadas en firmas. El análisis forense mostró que firmas válidas con timestamp permitieron que los payloads continuaran apareciendo confiables mucho después de que la infraestructura operacional desapareció.

Con el tiempo:

  • la reputación de SmartScreen se degrada,
  • las detecciones EDR mejoran,
  • las listas de revocación se actualizan,
  • y la confianza del firmante colapsa.

Para esa etapa, la cadena de intrusión ya puede estar madura.

Los operadores de ransomware frecuentemente solo necesitan unas pocas horas entre:

  • la ejecución inicial,
  • el robo de credenciales,
  • el movimiento lateral,
  • la escalación de privilegios,
  • y el despliegue de ransomware.

La infraestructura de Fox Tempest fue optimizada específicamente para maximizar el éxito durante esa ventana crítica temprana de ejecución antes de que los sistemas globales de telemetría se adaptaran.

La Comercialización de la Firma de Malware

Fox Tempest operaba no meramente como un grupo actor de amenazas, sino como un proveedor estructurado de servicios cibercriminales comerciales.

Según reportes alrededor del desmantelamiento, la operación supuestamente ofrecía servicios escalonados de firma con precios entre:

  • $5,000,
  • y $9,000,

con niveles superiores de servicio proporcionando:

  • acceso prioritario de firma,
  • máquinas virtuales dedicadas para firma,
  • y separación operacional mejorada.

La operación supuestamente comercializaba servicios mediante canales de Telegram donde operadores anunciaban:

  • certificados confiables por Microsoft,
  • acceso a firma de malware,
  • reputación SmartScreen,
  • y servicios de confiabilidad de ejecución.

Este detalle es operacionalmente significativo porque demuestra la industrialización del abuso de confianza.

Fox Tempest no simplemente estaba utilizando infraestructura de Microsoft de manera oportunista.

Había construido un modelo de negocio escalable alrededor de monetizar legitimidad artificial.

Familias de Malware y Actores de Amenazas Vinculados a la Infraestructura

Microsoft vinculó el ecosistema de firma con múltiples operaciones de ransomware y malware incluyendo:

  • Akira,
  • INC ransomware,
  • Qilin,
  • BlackByte,
  • Rhysida,
  • Lumma Stealer,
  • Vidar,
  • Oyster malware,
  • y actividad Vanilla Tempest.

Los clusters asociados de amenazas rastreados por Microsoft supuestamente incluyeron:

  • Storm-0501,
  • Storm-0249,
  • Storm-2561,
  • y Vanilla Tempest.

Muchos de los binarios firmados suplantaban aplicaciones empresariales legítimas incluyendo:

  • Microsoft Teams,
  • Cisco Webex,
  • AnyDesk,
  • PuTTY,
  • clientes VPN,
  • y herramientas de administración remota.

Esas aplicaciones son ampliamente confiables en entornos empresariales y frecuentemente están en allowlists, haciéndolas disfraces ideales para loaders de malware de primera etapa.

Operacionalmente, muchos de los binarios firmados funcionaban como:

  • loaders de primera etapa,
  • droppers,
  • downloaders,
  • o instaladores de persistencia

en lugar de payloads completos de ransomware por sí mismos.

El objetivo era:

  • eludir SmartScreen,
  • reducir el escrutinio EDR,
  • obtener ejecución inicial,
  • establecer persistencia,
  • y desplegar herramientas secundarias.

Una vez que la ejecución tenía éxito, los operadores podían desplegar:

  • stealers de credenciales,
  • loaders PowerShell,
  • beacons de Cobalt Strike,
  • troyanos de acceso remoto,
  • encryptores ransomware,
  • o frameworks post-explotación.

El componente de firma existía principalmente para garantizar una ejecución confiable en etapas tempranas durante la fase más frágil del ciclo de vida de intrusión.

Otras Técnicas Malware-Signing-as-a-Service Utilizadas en el Ecosistema Cibercriminal

Fox Tempest refleja solo una rama de un ecosistema underground mucho más grande centrado alrededor del abuso de confianza y generación artificial de legitimidad.

Las operaciones modernas Malware-Signing-as-a-Service combinan cada vez más múltiples técnicas diseñadas para manipular confianza de ejecución, retrasar correlación de telemetría y eludir sistemas de seguridad basados en reputación.

Adquisición de Certificados Mediante Empresas Fachada y Fraude de Identidad

Brokers underground dedicados crean:

  • negocios falsos,
  • corporaciones fachada,
  • identidades corporativas sintéticas,
  • y registros fraudulentos de incorporación

para adquirir certificados legítimos de autoridades certificadoras y revenderlos mediante mercados cibercriminales.

Los certificados Extended Validation siguen siendo especialmente valiosos porque SmartScreen y otros sistemas de reputación ponderan fuertemente cadenas EV durante la ejecución temprana.

Los anuncios underground ahora comercializan abiertamente:

  • “fresh SmartScreen reputation,”
  • “Microsoft-trusted certs,”
  • y “AV bypass signing”

como entregables medibles.

Investigadores que investigaban la campaña de malware EvilAI observaron organizaciones recién creadas poseedoras de certificados registradas entre 2024 y 2025, sugiriendo que los atacantes establecen cada vez más compañías desechables únicamente para adquirir infraestructura de firma antes de abandonarla y rotarla.

Abuso de Provisión de Confianza Nativa de Nube

Fox Tempest representa uno de los ejemplos documentados más claros de abuso de provisión de confianza nativa de nube.

Los mismos sistemas automatizados de onboarding diseñados para reducir fricción para desarrolladores legítimos también reducen fricción para adversarios invirtiendo en identidades sintéticas y provisión fraudulenta de tenants.

El abuso de firma nativa de nube ofrece varias ventajas operacionales:

  • rotación trivial de certificados,
  • confianza heredada base de la plataforma cloud,
  • aislamiento de tenants,
  • menor visibilidad de atribución,
  • y bajo costo operacional.

La implicación más amplia se extiende más allá de Microsoft. Cualquier proveedor cloud que ofrezca infraestructura de firma controlada por identidad potencialmente representa un objetivo futuro para abuso de provisión.

Abuso de Timestamp y Persistencia de Confianza Post-Expiración

El abuso de timestamp se ha convertido en un componente fundamental de ecosistemas modernos MSaaS.

Al adjuntar timestamps confiables compatibles con RFC 3161, los atacantes aseguran que el malware continúe apareciendo criptográficamente válido incluso después de que:

  • el certificado expire,
  • la infraestructura del firmante desaparezca,
  • o la reputación colapse.

Esto crea un desafío operacional significativo porque:

  • la expiración del certificado ya no funciona como un límite significativo de remediación,
  • y el malware con timestamp puede continuar ejecutándose en sistemas ya comprometidos mucho después de que comience la actividad de revocación.

Loaders Firmados y Entrega de Payloads en Memoria

Los proveedores avanzados MSaaS soportan cada vez más arquitecturas de ejecución multi-etapa diseñadas para mantener malware no firmado completamente fuera del disco.

Una cadena operacional común luce así:

  1. Se ejecuta un loader firmado
  2. SmartScreen permite la ejecución
  3. El loader asigna memoria
  4. Se descarga shellcode cifrado
  5. El payload se inyecta en procesos legítimos
  6. El ransomware no firmado se ejecuta completamente en memoria

Esta separación entre:

  • el artefacto firmado confiable,
  • y el payload realmente malicioso

incrementa significativamente la complejidad analítica para los defensores.

Arctic Wolf documentó una campaña de 2025 involucrando instaladores troyanizados de PuTTY y WinSCP que entregaban el backdoor Oyster/Broomstick mediante mecanismos de persistencia basados en DLL ejecutados vía rundll32.exe.

BYOVD y EDR Killers

Las operaciones Bring Your Own Vulnerable Driver (BYOVD) han evolucionado de tradecraft ofensivo de nicho a una fase estandarizada pre-encriptación de ransomware.

Los operadores modernos de ransomware utilizan cada vez más drivers vulnerables pero legítimamente firmados para:

  • deshabilitar productos EDR,
  • terminar servicios antivirus,
  • manipular memoria del kernel,
  • desregistrar callbacks de monitoreo,
  • y cegar telemetría de seguridad antes de que comience el despliegue del ransomware.

Un análisis de marzo de 2026 identificó:

  • 54 herramientas distintas EDR-killer
    abusando de:
  • 35 drivers legítimos firmados.

Los drivers frecuentemente abusados incluyen:

  • RTCore64.sys,
  • gdrv.sys,
  • mhyprot2.sys,
  • y procexp.sys.

Actores de amenazas asociados con:

  • BlackByte,
  • AvosLocker,
  • LockBit,
  • Cuba ransomware,
  • y actividad vinculada con Lazarus

todos han aprovechado extensivamente técnicas BYOVD.

Cisco Talos documentó una campaña DeadLock ransomware a finales de 2025 usando un driver vulnerable de Baidu Antivirus para terminar procesos EDR, deshabilitar Windows Defender, detener servicios y deteriorar mecanismos de recuperación antes de la encriptación.

Los operadores Qilin supuestamente desplegaron cadenas multi-etapa BYOVD diseñadas específicamente para desregistrar callbacks de monitoreo EDR antes de terminar herramientas de seguridad.

Siembra de Reputación y Sazonado de Infraestructura

Algunos proveedores MSaaS distribuyen intencionalmente primero software benigno firmado para:

  • generar telemetría,
  • construir reputación SmartScreen,
  • incrementar puntuación de prevalencia,
  • y establecer confianza histórica

antes de cambiar la misma identidad de firma hacia payloads maliciosos.

Esto refleja:

  • envejecimiento de dominios phishing,
  • calentamiento de cuentas cloud,
  • y técnicas de sazonado de personajes en redes sociales

observadas en otros ecosistemas cibercriminales.

El objetivo operacional es sencillo:
extender el periodo durante el cual los sistemas de confianza tratan al firmante como legítimo antes de que las detecciones se adapten.

Compromiso de Cadena de Suministro

Las operaciones más avanzadas de abuso de confianza comprometen directamente cadenas legítimas de suministro de software.

En incidentes involucrando:

  • SolarWinds,
  • CCleaner,
  • ASUS Live Update,
  • y ShadowPad,

el malware fue insertado dentro de versiones genuinas firmadas de software antes de la distribución.

Estos ataques son particularmente peligrosos porque:

  • la propia cadena de confianza permanece técnicamente válida,
  • el certificado es legítimo,
  • y el software fue genuinamente firmado por el proveedor.

La validación tradicional de confianza se vuelve casi insignificante en estos escenarios.

Distribución Mediante SEO Poisoning y Malvertising

Los ecosistemas modernos MSaaS combinan cada vez más malware firmado con:

  • SEO poisoning,
  • malvertising,
  • portales falsos de software,
  • instaladores troyanizados,
  • e infraestructura phishing generada por IA.

Los actores de amenazas suplantan fuertemente:

  • Zoom,
  • Teams,
  • Outlook,
  • ChatGPT,
  • Claude,
  • NotebookLM,
  • clientes VPN,
  • herramientas de criptomonedas,
  • y utilidades de administración remota.

Los investigadores observaron un incremento de 115% en archivos maliciosos suplantando ChatGPT durante inicios de 2025.

La combinación de:

  • confianza de motores de búsqueda,
  • suplantación realista de software,
  • y avisos Windows de “Verified Publisher”

crea una cadena altamente efectiva de ingeniería social capaz de neutralizar casi completamente la sospecha del usuario.

Fabricación de Identidades Asistida por IA

Un desarrollo emergente involucra el probable uso futuro de IA generativa para automatizar flujos de fabricación de identidades utilizados en abuso de provisión de certificados.

El modelo operacional de Fox Tempest requería:

  • grandes cantidades de organizaciones sintéticas,
  • artefactos consistentes de identidad,
  • documentos falsos de registro,
  • y flujos escalables de provisión.

La IA generativa reduce cada vez más la fricción operacional para:

  • creación de empresas fachada,
  • generación sintética de identidades organizacionales,
  • y producción automatizada de documentos.

Aunque sigue siendo un vector emergente de amenaza, esto representa un camino evolutivo natural para ecosistemas nativos de nube de abuso de confianza.

OpFauxSign y la Interrupción de Infraestructura

El esfuerzo de desmantelamiento de Microsoft fue formalmente nombrado:

OpFauxSign

La operación involucró:

  • incautación del dominio signspace[.]cloud,
  • cierre de cientos de máquinas virtuales,
  • interrupción de infraestructura de firma,
  • y bloqueo de acceso a sistemas de hospedaje de código asociados con la operación.

La Digital Crimes Unit (DCU) de Microsoft supuestamente utilizó personajes encubiertos para interactuar con operadores Fox Tempest, mapear infraestructura e identificar flujos operacionales.

La compañía coordinó esfuerzos de interrupción con:

  • el FBI,
  • Europol EC3,
  • proveedores de hosting,
  • y otros socios externos.

El caso legal de Microsoft fue desclasificado el 19 de mayo de 2026 en la Corte de Distrito de EE.UU. para el Distrito Sur de Nueva York y supuestamente identificó a Vanilla Tempest como co-conspirador.

Microsoft también aclaró que la telemetría geográfica asociada con malware firmado no necesariamente indicaba targeting deliberado de esos países. Más bien, reflejaba ubicaciones donde archivos firmados fueron observados globalmente en sistemas.

La implicación estratégica más amplia de la operación Fox Tempest es cada vez más clara:
los ciberdelincuentes modernos ya no simplemente venden malware.

Están vendiendo:

  • lavado de confianza,
  • confiabilidad de ejecución,
  • retraso de telemetría,
  • manipulación de reputación,
  • y éxito de intrusión en etapas tempranas.

El producto ya no es simplemente el propio certificado.

El producto es una ventana operacional temporal durante la cual:

  • SmartScreen,
  • telemetría EDR,
  • sistemas de reputación,
  • y analítica conductual

aún no han correlacionado completamente la actividad maliciosa con la identidad del firmante.

Cada técnica importante en el ecosistema moderno MSaaS — desde abuso de provisión cloud y manipulación de timestamp hasta BYOVD, siembra de reputación, SEO poisoning y loaders firmados en memoria — está finalmente optimizada alrededor del mismo objetivo.