Cuando el software de seguridad se torna el camino más corto para comprometer un sistema, algo fundamental se quebró. En 2026, vimos eso ocurrir dos veces en el ecosistema Microsoft: zero-days en el Defender que entregan privilegios SYSTEM, y malware firmado por la propia infraestructura de code signing de Microsoft. La lección es clara, confiar ciegamente en el protector es la verdadera vulnerabilidad.
El antivirus que entrega las llaves del sistema
El Microsoft Defender corre como NT AUTHORITY\SYSTEM. Eso no es un detalle técnico menor, es el motivo por el cual él es el blanco más valioso de Windows. Quien compromete el Defender no necesita exploit de kernel. El Defender ya tiene los privilegios máximos. Basta hacer que él trabaje para ti.
La CVE-2026-41091, bautizada RedSun, explora exactamente eso. El Malware Protection Engine (mpengine.dll) resuelve symlinks antes de validar el camino. Un atacante con cualquier cuenta local, aun la más restringida, crea un symlink apuntando a un archivo privilegiado. El Defender sigue el link con sus privilegios de SYSTEM y accede al blanco. Resultado: cualquier usuario mínimo se vuelve NT AUTHORITY\SYSTEM. CVSS 7.8, CWE-59, sin interacción del usuario.
El investigador Nightmare Eclipse publicó los PoCs en GitHub en abril de 2026. El MSRC ya había patchado el BlueHammer (CVE-2026-33825) en el Patch Tuesday de abril. Pero RedSun y UnDefend quedaron 6 semanas sin patch, con exploración activa documentada. Seis semanas de zero-day público, activo en el wild, sin corrección. Ninguna organización debería aceptar esa ventana.
La alarma que desarma sin hacer ruido
La segunda vulnerabilidad es más sutil y, en ciertos escenarios, más peligrosa. La CVE-2026-45498, llamada UnDefend, causa crash del servicio MsMpEng.exe cuando procesa un archivo craftado en cualquier directorio grabable. El Defender para. Sin alerta. Sin notificación. Sin ícono de warning en la bandeja del sistema.
El panel muestra "actualizando" o "última verificación: hace X horas". Parece normal. No lo es. El CVSS 4.0 engaña, clasificar como DoS un ataque que desarma el antivirus es como llamar de "allanamiento menor" al corte de la línea telefónica antes del asalto. DoS en el antivirus es desarmar la alarma antes del ataque real.
Huntress documentó la intrusión en abril: atacante entró vía FortiGate VPN comprometida, ejecutó reconocimiento básico (whoami /priv, cmdkey /list, net group), y entonces encadenó UnDefend y RedSun. Primero, el Defender crashea silenciosamente. Después, escala para SYSTEM. Endpoint ciego y comprometido. Cero detección. De la carpeta Downloads al SYSTEM en segundos, sin que el admin sepa.
Cuando la firma se vuelve vector de ataque
Si las zero-days muestran que el Defender puede ser quebrado, el Fox Tempest muestra que él puede ser bypaseado por diseño. Microsoft mantiene un servicio llamado Artifact Signing que emite certificados de code signing para que Windows confíe en el software. Un grupo criminal creó un servicio de firma de malware usando esa misma infraestructura.
El site signspace[.]cloud era el escaparate. Clientes criminales hacían upload de binarios. El sistema firmaba con certificados emitidos por el Microsoft Artifact Signing. Certificados de 72 horas, vida corta para limitar detección, larga lo suficiente para bypasear SmartScreen, Defender y allow-lists que confían en binarios firmados. Windows veía el sello de Microsoft y trataba el malware como software legítimo.
La infraestructura detrás de eso: 580+ cuentas fraudulentas usando identidades robadas de EUA y Canadá, cientos de Azure tenants emitiendo certificados independientes. En febrero de 2026, VMs pre-configuradas en Cloudzy automatizaban el proceso: upload del malware, recibe binario firmado. Precio: 7.500 dólares en bitcoin. Alias: SamCodeSign en Telegram. Más de 1.000 certificados fraudulentos emitidos entre mayo de 2025 y mayo de 2026.
Ransomware con sello de confianza
El cliente principal de Fox Tempest fue el Vanilla Tempest (Rhysida). El flujo de ataque es revelador: un anuncio en Google redirige búsquedas por "Microsoft Teams", la víctima descarga MSTeamsSetup.exe firmado con certificado Microsoft, el SmartScreen no alerta, Windows confía, y el Oyster backdoor instala el Rhysida ransomware. Mismo camino con AnyDesk, PuTTY y Webex falsos.
Otros clientes incluyeron Storm-0501, Storm-0561, Storm-2561 y Storm-0249. Malware distribuido: Lumma, Vidar, INC, Qilin, Akira, BlackByte. Sectores alcanzados: healthcare, educación, gobierno y financial services. La cadena de confianza de Windows fue transformada en arma, el sello que debería proteger se volvió el mecanismo que permite la ejecución.
La Microsoft DCU actuó en mayo de 2026: seizure del signspace[.]cloud, cientos de VMs derribadas, más de 1.000 certificados revocados, proceso en el Distrito Sur de Nueva York. El DCU hizo test purchases de 7.500 dólares en bitcoin para documentar la operación. Pero los certificados de 72h ya habían hecho su trabajo. Miles de máquinas infectadas, incluyendo 12+ de la propia Microsoft.
El modelo de amenaza que nadie revisó
El patrón de esos incidentes es el mismo: la infraestructura de seguridad de Windows fue proyectada con un modelo de amenaza que asume que el propio ecosistema Microsoft es confiable por definición. El Defender corre como SYSTEM porque necesita acceso total. El SmartScreen aprueba binarios firmados por Microsoft. Las allow-lists tratan firmas como proof of safety.
Pero code signing atesta identidad, no seguridad. Cuando la verificación de identidad puede ser fraudada en escala, como Fox Tempest probó, la firma se vuelve vector de ataque. Y cuando el software que debería detectar amenazas es él mismo el camino para escalada de privilegios, como RedSun probó, la arquitectura de seguridad necesita capas independientes.
En Tech86, nuestra posición es directa: seguridad por capas no es lujo, es requisito. Un EDR independiente con telemetría propia no depende del mismo engine del Defender. Cuando el Defender es ciego, por crash, por zero-day, o por firma fraudada, el EDR continúa detectando. Monitorea Event IDs 2001/2002/2003 para fallas de actualización y 4672 para escalada de privilegio. Verifica si Engine está en 1.1.26040.8+ y Platform en 4.18.26040.7+. Y nunca trates un binario firmado como seguro por default.
La seguridad no puede depender de un único proveedor, especialmente cuando ese proveedor es, simultáneamente, el blanco más atacado y la fuente de confianza que los atacantes aprenden a explorar.