DigiCert cambia las normas para compartir archivos en chats tras un ciberataque

Un archivo habitual en el chat de soporte se convirtió para DigiCert en un problema serio. Un atacante presentó un archivo ZIP malicioso como «captura de pantalla del cliente» y logró acceder a sistemas que se usan para emitir certificados digitales.
El incidente se describe en el informe de DigiCert. El ataque comenzó el 2 de abril de 2026. Un desconocido contactó a un agente de soporte mediante el chat y envió varias veces un archivo ZIP. Dentro había un ejecutable con carga maliciosa. Los mecanismos de protección detuvieron cuatro intentos, pero el quinto tuvo éxito y uno de los equipos de trabajo quedó infectado.
Al día siguiente detectaron y aislaron el sistema infectado. En ese momento creyeron que habían eliminado la amenaza. Más tarde se descubrió que el atacante se había afianzado también en otro equipo, donde la protección funcionaba de manera incorrecta y no registró la intrusión.
Al obtener acceso al portal interno de soporte, el atacante usó una función administrativa. Con ella, los empleados pueden iniciar sesión en las cuentas de los clientes para ayudar con la configuración. No es posible gestionar cuentas ni tramitar pedidos mediante esta función, pero resultó que allí estaban disponibles códigos especiales de inicialización para certificados de firma de código.
Esos códigos, junto con un pedido ya aprobado, permiten obtener un certificado listo. El atacante aprovechó esta posibilidad y emitió varios certificados en nombre de clientes. Parte de ellos luego se usó para firmar programas maliciosos de la familia Zhong Stealer.
En total DigiCert revocó 60 certificados. De ellos, 27 se vincularon directamente con las acciones del atacante; los restantes se anularon por precaución. Todos los certificados se declararon inválidos en el plazo de un día desde su detección, y como fecha de revocación se indicó el momento de la emisión.
El problema no residió en el sistema de emisión de certificados en sí, sino en la combinación de varios factores. En uno de los equipos no funcionaba la protección a nivel de endpoint, el portal de soporte mostraba datos sensibles a los empleados sin restricciones y los códigos de inicialización no se consideraban credenciales completas y no se ocultaban.
Además se comprobó que el canal de soporte permitía enviar archivos sin restricciones estrictas. Ese mecanismo se convirtió de hecho en un punto de entrada conveniente para el ataque.
La empresa ya ha realizado cambios. Se cerró el acceso a los códigos de inicialización, se endurecieron los requisitos para la autenticación multifactor y se restringió la transferencia de archivos en los chats. También están revisando la configuración de los sistemas de protección para evitar «zonas ciegas», como en el caso del segundo equipo infectado.
DigiCert afirma que el atacante no obtuvo acceso a otros sistemas ni intervino en los procesos de verificación de clientes. Sin embargo, la historia muestra que incluso las herramientas auxiliares dentro de una empresa pueden convertirse en un punto crítico si a través de ellas pasa el camino para la emisión de certificados digitales.