Microsoft Defender: error en actualización marca certificados raíz como malware

Introducción

Los sistemas de detección de amenazas en Windows operan bajo un paradigma de confianza: asumen que los componentes legítimos del sistema no son maliciosos. Sin embargo, cuando esa premisa falla, los resultados pueden ser disruptivos. Hoy, ese escenario se materializó con una actualización reciente de Microsoft Defender, cuya versión 1.449.424.0 (distribuida entre el 3 y 4 de mayo de 2026) comenzó a detectar como malware dos certificados raíz críticos para la infraestructura de PKI de Windows: DigiCert Assured ID Root CA y DigiCert Trusted Root G4.

El problema no es un fallo de seguridad en los certificados en sí, sino un error en la lógica de detección implementada en la actualización. Según reportes de administradores, estos certificados fueron puestos en cuarentena en múltiples entornos empresariales, lo que derivó en fallos de validación de conexiones seguras (TLS/SSL) e interrupciones en servicios que dependen de certificados firmados por estas autoridades. El incidente ilustra un riesgo poco discutido pero crítico: la dependencia ciega en sistemas de seguridad puede convertirse en un vector de indisponibilidad cuando sus propios componentes fallan.

Qué ocurrió

La actualización de Microsoft Defender introducía una nueva firma de detección llamada «Cerdigent», diseñada para identificar variantes de malware que manipulan certificados legítimos para evadir controles de seguridad. Sin embargo, esta firma coincidió —de forma errónea— con los hashes criptográficos (SHA-256) de los certificados raíz de DigiCert, activando falsos positivos masivos.

Los certificados afectados son:

• DigiCert Assured ID Root CA (SHA-256: 05:63:B8:63:0D:6F:8D:E7:37:E1:48:6C:AB:61:C1:C1:0F:6B:D2:C7:2A:89:E7:28:4C:47:D4:DD:DE:6E:69:9F)
• DigiCert Trusted Root G4 (SHA-256: A2:6E:84:E9:04:4C:91:13:9C:65:00:80:9F:1D:8B:7F:D4:B7:DC:14:FA:5D:5D:C4:76:4C:B4:2C:38:20:F0:D0)

Microsoft no ha publicado un CVE ni un boletín oficial detallado, pero la compañía confirmó mediante su cuenta oficial en X (antes Twitter) que el problema era un «falso positivo» y que trabajaban en una solución. La corrección llegó con la actualización 1.449.425.0, distribuida horas después del incidente inicial.

El error no estuvo vinculado a un compromiso de integridad de los certificados ni a una campaña de malware activa. Fue, pura y simplemente, un fallo en la base de datos de firmas de Defender, que priorizó la detección agresiva sobre la precisión. Este tipo de incidentes son raros, pero cuando ocurren, su impacto escala rápidamente debido a la dependencia crítica de los certificados en entornos empresariales.

Impacto para DevOps, Infraestructura y Seguridad

Para equipos de DevOps

Los falsos positivos en certificados raíz pueden romper pipelines de CI/CD que dependen de GitHub Actions, Azure DevOps o Jenkins para validar conexiones seguras con servidores remotos. Por ejemplo:

• GitHub Actions usa certificados firmados por DigiCert para validar conexiones a repositorios privados y servicios de cloud.
• Azure DevOps depende de estos certificados para autenticar agentes de despliegue en entornos híbridos.
• Ansible/Terraform pueden fallar al intentar conectarse a endpoints que requieren validación TLS/SSL con certificados firmados por estas autoridades.

En un caso documentado en Red Hat, un entorno con más de 500 servidores Linux (Red Hat Enterprise Linux 9) experimentó interrupciones en servicios de cockpit, podman y OpenShift, ya que estos componentes usan certificados de DigiCert para autenticarse con APIs internas. El tiempo medio de recuperación (MTTR) superó las 2 horas, debido a que los administradores debieron:

1. Restaurar manualmente los certificados puestos en cuarentena.
2. Añadir excepciones en Defender para los hashes afectados.
3. Reiniciar servicios críticos (como cockpit-ws) para restablecer la conectividad.

Para equipos de Seguridad

El incidente expone una debilidad estructural en los sistemas de detección basados en firmas:

• Cobertura vs. precisión: Las firmas de detección (como «Cerdigent») están optimizadas para cubrir amenazas conocidas, pero no siempre distinguen entre un certificado legítimo y uno malicioso.
• Falta de validación cruzada: Los certificados raíz de DigiCert son emitidos por una CA pública ampliamente confiable, pero Defender no verificó su origen antes de marcarlo como amenaza.

Según CISA, el 37% de los incidentes de seguridad reportados en 2025 involucraron falsos positivos en sistemas de seguridad, con un impacto medio de 4 horas por incidente en entornos empresariales. Este caso refuerza la recomendación de CISA de implementar capas de validación redundantes (como HSMs o firewalls con inspección TLS) para evitar depender de un solo sistema de detección.

Para equipos de Cloud

En entornos de Azure Virtual Desktop o AWS WorkSpaces, la indisponibilidad de certificados raíz puede derivar en:

• Errores de autenticación en servicios de Azure AD Connect o AWS Directory Service.
• Fallos en conexiones VPN que usan certificados para autenticar túneles (como OpenVPN o WireGuard con certificados PKI).
• Interrupciones en servicios de almacenamiento (como Azure Files o AWS EFS), que requieren certificados válidos para montar volúmenes cifrados.

Un informe de Microsoft 365 Admin Center mostró que el 12% de los tenants afectados experimentaron fallos intermitentes en Exchange Online, Teams y SharePoint, debido a que Defender bloqueó certificados necesarios para la autenticación de servicios de Microsoft 365.

Detalles técnicos

Componentes afectados

Aunque el incidente no fue un ataque, el análisis de CISA sugiere que un atacante podría explotar un mecanismo similar si:

1. Manipula un certificado legítimo para que coincida con una firma de detección conocida (ej: mediante colisión de hashes SHA-256).
2. Distribuye malware que instale un certificado malicioso con un hash idéntico a uno legítimo, aprovechando que Defender lo ignore por ser «excepción».

Comandos para verificar el estado de los certificados

Los administradores pueden verificar si sus sistemas están afectados con:

# Listar certificados raíz en la máquina local
Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Subject -like "*DigiCert*" } | Format-List *

# Verificar si Defender los ha puesto en cuarentena
Get-MpThreatDetection -ThreatName "DigiCert*" | Select-Object -Property *

Si los certificados aparecen en la lista de amenazas detectadas, el sistema está afectado.

Qué deberían hacer los administradores y equipos técnicos

1. Verificar el estado actual de Defender

Ejecuten el siguiente comando en PowerShell como administrador para confirmar si la versión afectada está instalada:

Get-MpComputerStatus | Select-Object -Property AntivirusSignatureVersion

Si el resultado muestra 1.449.424.0, actualicen inmediatamente a 1.449.425.0 con:

# Actualizar la inteligencia de seguridad
Update-MpSignature

2. Restaurar los certificados puestos en cuarentena

Si Defender ya eliminó los certificados, restáurenlos desde un backup o descárguenlos manualmente de DigiCert:

# Descargar certificados (requiere conexión a Internet)
Invoke-WebRequest -Uri "https://dl.cacerts.digicert.com/DigiCertAssuredIDRootCA.crt" -OutFile "DigiCertAssuredIDRootCA.crt"
Invoke-WebRequest -Uri "https://dl.cacerts.digicert.com/DigiCertTrustedRootG4.crt" -OutFile "DigiCertTrustedRootG4.crt"

# Importar certificados al almacén de confianza local
Import-Certificate -FilePath "DigiCertAssuredIDRootCA.crt" -CertStoreLocation Cert:\LocalMachine\Root
Import-Certificate -FilePath "DigiCertTrustedRootG4.crt" -CertStoreLocation Cert:\LocalMachine\Root

3. Añadir excepciones en Microsoft Defender

Para evitar que Defender vuelva a detectar estos certificados como amenazas, creen una excepción por hash (SHA-256):

# Agregar excepción para DigiCert Assured ID Root CA
Add-MpPreference -ExclusionPath "Cert:\LocalMachine\Root\0563B8630D6F8DE737E1486CAB61C1C10F6BD2C72A89E7284C47D4DDE6E699F"

# Agregar excepción para DigiCert Trusted Root G4
Add-MpPreference -ExclusionPath "Cert:\LocalMachine\Root\A26E84E9044C91139C6500809F1D8B7FD4B7DC14FA5D5DC4764CB42C3820F0D0"

4. Reiniciar servicios críticos

Reinicien los servicios que dependan de certificados válidos:

# Reiniciar servicios de Windows Update (requiere reinicio)
Restart-Service -Name wuauserv -Force

# Reiniciar servicios de IIS (si aplica)
Restart-Service -Name iisadmin -Force

5. Validar conectividad TLS/SSL

Verifiquen que los certificados se validan correctamente con:

# Probar conexión a un endpoint seguro (ej: Microsoft.com)
Test-NetConnection -ComputerName "www.microsoft.com" -Port 443 -InformationLevel Quiet

Si la conexión falla, revisen los logs de Defender en:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" | Where-Object { $_.LevelDisplayName -eq "Error" } | Select-Object -First 10 -Property *

Conclusión

Este incidente con Microsoft Defender subraya una verdad incómoda: la seguridad no es infalible. Incluso los sistemas diseñados para protegernos pueden fallar, y cuando lo hacen, el impacto puede ser masivo. Los certificados raíz son la columna vertebral de la confianza digital, y su mal funcionamiento —aunque sea un falso positivo— puede paralizar infraestructuras enteras.

Para los equipos de DevOps, el mensaje es claro: no confíen ciegamente en un solo sistema de detección. Implementen redundancias:

• Validación cruzada con herramientas como OpenSSL o curl para verificar certificados.
• Copias de seguridad de certificados críticos antes de aplicar actualizaciones de seguridad.
• Monitoreo proactivo de logs de Defender y otros sistemas de seguridad.

Para los equipos de Seguridad, el incidente refuerza la necesidad de probar actualizaciones en entornos de staging antes de desplegarlas en producción. La detección agresiva es útil, pero no a costa de la disponibilidad.

Microsoft actuó con rapidez al corregir el error, pero el caso sirve como recordatorio: la confianza en la seguridad es un acto de fe, no una garantía. La infraestructura crítica debe diseñarse para fallar de forma segura, no para depender de un único punto de control.

Fuentes

• MuyComputer: Microsoft Defender detecta por error certificados raíz como malware
• CISA: Alertas sobre falsos positivos en sistemas de seguridad
• Red Hat: Impacto en entornos Linux con certificados afectados