DigiCert perdió 27 certificados de firma de código por un archivo de salvapantallas

DigiCert es una de las mayores autoridades de certificación del mundo. Emite los certificados digitales que indican a su equipo «este software es seguro de ejecutar». Cuando instala una aplicación firmada, su sistema operativo comprueba la firma contra una cadena de certificados que conduce hasta una CA como DigiCert.

En abril de 2026, un actor de amenazas abrió un chat de atención al cliente en el portal de DigiCert basado en Salesforce. Envió un archivo ZIP disfrazado de captura de pantalla de un cliente. Dentro había un archivo .scr —un ejecutable de salvapantallas de Windows.

La protección de endpoints CrowdStrike de DigiCert lo bloqueó. El agente de soporte lo volvió a intentar. Bloqueado de nuevo. Tercer intento. Cuarto intento. Bloqueado en todos los intentos.

El quinto intento funcionó.

Una máquina, luego dos

La primera máquina comprometida se detectó y aisló en menos de un día. Buena respuesta.

La segunda máquina comprometida no se detectó durante doce días. ¿Por qué? Un «hueco en el sensor de protección de endpoints» —la máquina carecía de cobertura EDR o su telemetría no se estaba revisando—.

Una autoridad de certificación —la organización cuyo negocio entero es la confianza— tenía una máquina en su entorno de soporte sin detección de endpoints funcional. Durante doce días, un atacante tuvo acceso.

27 certificados

El atacante obtuvo 27 certificados de firma de código EV. DigiCert revocó finalmente 60 certificados en total, incluidos 16 adicionales considerados sospechosos y hallados durante la investigación.

Estos certificados se usaron para firmar la familia de malware Zhong Stealer, vinculada a la cibercriminalidad china y al robo de criptomonedas. El malware llevaba una firma digital válida de una CA de confianza. Los sistemas operativos lo trataban como software legítimo.

Esto es lo que distingue el compromiso de una CA de una brecha de seguridad corriente. Las contraseñas robadas afectan a cuentas. Las claves de API robadas afectan a servicios. Los certificados de firma de código robados afectan a la propia confianza. Todos los sistemas operativos, todas las tiendas de aplicaciones y todos los endpoints empresariales confían en la jerarquía de CA. Cuando una CA se ve comprometida, esa confianza se convierte en un arma.

El fallo real

El antivirus funcionó. Cuatro de cada cinco veces, el sistema automatizado hizo exactamente lo que debía hacer. El fallo fue el ser humano que siguió anulándolo.

Es un patrón que vemos por todas partes. Los equipos de seguridad construyen arquitecturas de defensa en profundidad con EDR, sandboxing, segmentación de red y alertas. Después, alguien de soporte abre un archivo porque un cliente lo ha pedido amablemente. El stack de seguridad más sofisticado del mundo no sobrevive a un usuario que hace clic en «Permitir» cinco veces.

Pero culpar al agente de soporte es no ver el problema. El sistema permitió que un agente de soporte recibiera archivos ejecutables a través de un canal de chat. El sistema permitió cinco intentos consecutivos tras cuatro bloqueos. El sistema no marcó «este usuario está eludiendo el antivirus de forma repetida» como evento de seguridad. El sistema tenía una máquina sin cobertura EDR en un entorno que maneja certificados de firma de código.

El ser humano hizo clic. El sistema se lo permitió.

Lo que valen los certificados de firma de código

Un certificado de firma de código EV válido de una CA de confianza es una de las cosas más valiosas que un atacante puede robar. Más valioso que las contraseñas, más valioso que las claves de API y, en opinión de muchos, más valioso que las claves de cifrado.

Con un certificado de firma de código robado, un atacante puede firmar malware que supera SmartScreen, Gatekeeper y cualquier lista blanca empresarial. Puede publicar actualizaciones de software ya firmado que parecen legítimas. Puede eludir las políticas de listas de aplicaciones permitidas en entornos corporativos. Puede neutralizar todo control de seguridad posterior que dependa de la verificación de firmas.

Toda la cadena de suministro de software confía en la cadena de certificados. Cuando una CA se ve comprometida, la cadena se rompe, pero nadie lo sabe hasta que se descubre el malware firmado.

Once de los certificados comprometidos se detectaron porque miembros de la comunidad informaron de su vínculo con malware. No fue la monitorización interna de DigiCert. Fue la comunidad.

El patrón

Solo en este mes:

• ClickUp incrustó una clave de API en el código fuente JavaScript de la página. Una petición, 959 direcciones de correo electrónico.
• El CLI de Bitwarden se vio comprometido mediante npm, capturando claves SSH y credenciales de nube de máquinas de desarrollo.
• Vercel almacenó variables de entorno en un formato que un atacante pudo descifrar durante dos meses.
• DigiCert perdió certificados de firma de código por un archivo de salvapantallas.

Todos estos casos implican una credencial que existía como artefacto copiable, sin ámbito de uso, sin vinculación a hardware y sin segundo factor en su empleo.

La solución no es un mejor antivirus. No es más formación. No es un nuevo documento de políticas. La solución son credenciales que no se pueden copiar. Claves que no existen como archivos. Operaciones de firma que requieren presencia física del hardware. Anclas de confianza vinculadas matemáticamente a un dispositivo físico, no a una cadena de texto que alguien puede pegar en una ventana de chat.\n\n---\n\nFuentes:\n- Informe de incidente en Mozilla Bugzilla\n- Help Net Security: DigiCert breached via malicious screensaver file\n- Declaración oficial de DigiCert