Un chat de soporte que parecía rutinario terminó golpeando una capa delicada de confianza: la firma de código. Según la descripción del incidente documentada en Bugzilla de Mozilla, el 2 de abril de 2026 un atacante contactó con el soporte de DigiCert a través de un canal de chat de cliente y envió un archivo ZIP que aparentaba ser una captura de pantalla, pero contenía un ejecutable .scr con carga maliciosa ^[12]. Después, mediante sistemas de soporte comprometidos, se obtuvieron códigos de inicialización para un número limitado de certificados de firma de código; algunos acabaron usándose para firmar malware ^[1].

Para los equipos de seguridad, el punto importante no es solo que hubiera una intrusión. Es que el ataque tocó un mecanismo que muchas organizaciones usan para decidir si un software merece confianza.

Qué ocurrió realmente

El vector inicial fue ingeniería social contra el soporte de DigiCert. Help Net Security describe el núcleo del caso de forma similar: una supuesta captura de pantalla enviada como ZIP contenía un archivo .scr, un formato usado por Windows para salvapantallas, pero con funcionalidad maliciosa ^[2].

SecurityWeek informó de que el malware infectó dos equipos: uno fue identificado el 3 de abril y otro el 14 de abril ^[10]. Desde un sistema comprometido, los atacantes se movieron hacia el portal interno de soporte de DigiCert ^[10]. El punto crítico era una función limitada que permitía a analistas autenticados acceder en modo proxy a cuentas de clientes; esa función daba acceso a tareas específicas, entre ellas códigos de inicialización de certificados pendientes ^[10]. BleepingComputer acotó el alcance a códigos de inicialización de certificados EV de firma de código ya aprobados, pero todavía no entregados ^[5].

Por qué los certificados EV eran un objetivo atractivo

Un certificado de firma de código ayuda a verificar el origen de un programa y a detectar si un binario ha sido alterado. DigiCert, como autoridad de certificación, ocupa un papel relevante en la confianza usada por navegadores, sistemas operativos y distribución de software; sus certificados de firma de código son utilizados por desarrolladores de software ^[11].

Los certificados EV, de Extended Validation o validación extendida, están asociados a un nivel de confianza mayor en muchos flujos de instalación y verificación. Por eso resultan valiosos para un atacante: no necesita romper toda la criptografía del ecosistema si puede abusar de un certificado que ya parece legítimo.

ThreatNoir informó de que algunos de los certificados obtenidos se usaron para firmar malware ^[1]. CyberInsider también describió un incidente en el que sistemas internos de soporte comprometidos y datos de emisión de certificados fueron usados para obtener certificados EV válidos de firma de código; algunos de ellos se utilizaron después para firmar malware ^[11].

El riesgo es práctico: el malware firmado puede parecer menos sospechoso en una primera revisión. Vectra ha descrito este patrón de forma general: actores maliciosos pueden usar certificados EV para firmar archivos dañinos y aprovechar la confianza reforzada que suelen despertar las aplicaciones firmadas con EV; las organizaciones que dependen solo de la confianza basada en firmas quedan expuestas ^[15].

Lo que las fuentes no demuestran

Conviene separar el incidente conocido de una lectura más alarmista. Las fuentes disponibles describen equipos de soporte comprometidos, funciones internas de portal y acceso a códigos de inicialización ^{[1][5][10][12]}. No aportan pruebas de que se comprometieran las claves raíz de DigiCert ni las claves de una autoridad de certificación.

Eso no vuelve menor el caso. Significa que, con la información publicada, el incidente encaja mejor como abuso de un proceso de soporte y emisión alrededor de certificados de firma de código, no como una toma completa de la autoridad de certificación ^[1][5][10].

Cuánto alcance tuvo

Las cifras públicas deben leerse con cuidado porque no todas miden lo mismo:

• ThreatNoir habló de un número limitado de certificados de firma de código, de los cuales algunos se usaron para firmar malware ^[1].
• Risky Business informó de 27 certificados de firma de código robados que posteriormente se utilizaron para firmar malware ^[8].
• ThreatLocker citó 60 certificados de firma de código revocados en total ^[3].

La diferencia clave está en si una fuente habla de certificados obtenidos, certificados efectivamente usados para malware o certificados revocados. Aun así, el volumen no es lo único importante: unos pocos certificados que parezcan válidos pueden bastar para dar apariencia de legitimidad a una campaña maliciosa si las defensas confían demasiado en la firma ^[15].

Revocación y contención

DigiCert revocó los certificados identificados dentro de las 24 horas posteriores al descubrimiento, según BleepingComputer, y fijó la fecha de revocación en la fecha de emisión ^[5]. Como medida preventiva, también se cancelaron pedidos pendientes dentro de la ventana afectada ^[5]. ThreatNoir informó igualmente de la revocación en 24 horas y de la anulación de pedidos pendientes en el periodo afectado ^[1].

La revocación limita nuevos abusos, pero no cierra por sí sola el trabajo de defensa. Los equipos de seguridad deben seguir evaluando archivos firmados con una combinación de datos: certificado, hash, comportamiento, conexiones de red, persistencia y contexto de inteligencia de amenazas. La razón es sencilla: la firma EV puede ser precisamente el señuelo de confianza que el atacante quiere explotar ^[15].

El ruido añadido: Microsoft Defender y los falsos positivos

Alrededor del incidente apareció otra complicación: alertas erróneas de Microsoft Defender. BleepingComputer informó de que Defender marcó por error certificados de DigiCert como Trojan:Win32/Cerdigent.A!dha ^[5]. daily.dev resumió que, tras una actualización de firmas de detección del 30 de abril, Defender identificó indebidamente certificados raíz legítimos de DigiCert; Microsoft publicó después la actualización de inteligencia de seguridad 1.449.430.0, que corregía el problema y restauraba certificados eliminados ^[7].

Para las organizaciones, eso creó un problema operativo clásico de respuesta a incidentes: distinguir entre abuso real de certificados, malware firmado con certificados comprometidos y alertas falsas contra certificados legítimos ^[5][7].

Qué deberían aprender los equipos de seguridad

La conclusión no es que la firma de código sea inútil. La conclusión es que no puede ser el único semáforo de confianza.

• No aceptar una firma como veredicto final. Una firma válida, incluso EV, no debe convertir automáticamente un archivo en confiable; los atacantes pueden usar certificados EV para firmar archivos maliciosos y aprovechar esa confianza ^[15].
• Mirar los detalles del certificado. Emisor, número de serie, cadena de confianza, marca temporal y estado de revocación importan, especialmente cuando el binario se comporta de forma sospechosa. En este caso, la revocación y la fecha de revocación fueron parte central de la contención ^[5].
• Dar peso al comportamiento. Hashes, procesos hijos, conexiones de red, mecanismos de persistencia y resultados de sandbox ayudan a detectar lo que una firma por sí sola puede ocultar ^[15].
• Tratar los portales de soporte como zonas de alto riesgo. Una función limitada puede volverse crítica si permite acceder a cuentas de clientes o a códigos de inicialización para certificados pendientes ^[10].
• Gestionar los falsos positivos con método. Las alertas de certificados no siempre significan infección: en el caso de Defender, certificados raíz legítimos de DigiCert fueron marcados por error y después restaurados mediante una actualización de Microsoft ^[7].

En resumen

El incidente de DigiCert fue relevante porque los atacantes consiguieron aprovechar la confianza asociada a certificados EV de firma de código para hacer más creíble malware firmado. Los informes disponibles apuntan a un caso acotado en torno a soporte, códigos de inicialización y certificados mal usados, no a una exposición de claves raíz o claves de CA ^{[1][5][10][12]}. Aun así, la lección es contundente: en defensa contra malware, una firma digital debe ser una señal más, nunca la última palabra.