¿Qué es una vulnerabilidad de día cero? Definición, ejemplos y medidas de protección
El término «día cero» aparece constantemente en las noticias sobre ciberseguridad, pero a menudo se malinterpreta este concepto. Una vulnerabilidad de día cero no es necesariamente la más peligrosa de tu entorno. Se trata de una categoría específica de vulnerabilidad que genera un tipo concreto de riesgo, y comprender en qué se diferencia de otras vulnerabilidades es fundamental para gestionarla adecuadamente.
La mayoría de los equipos de seguridad sobrevaloran el riesgo de los ataques «zero-day» y subestiman el riesgo, mucho más común, de las vulnerabilidades conocidas sin parchear. Las defensas que cierran la ventana de los ataques «zero-day» son, en gran medida, las mismas que reducen la exposición al panorama general de vulnerabilidades. Comprender esta distinción es lo que permite a los equipos de TI y a los MSP distribuir sus esfuerzos de seguridad de forma precisa, en lugar de hacerlo de manera reactiva. Lee el informe «Estado de los MSP 2026» de Kaseya: el 69 % de los MSP ofrecen la gestión de parches y actualizaciones como servicio, ya que el intervalo entre la divulgación de una vulnerabilidad y la aplicación del parche es uno de los más trascendentales en materia de seguridad informática.
Soluciona las vulnerabilidades más rápidamente gracias a la gestión automatizada de parches.
Kaseya VSA 10 automatiza la aplicación de parches en el sistema operativo, el navegador y las aplicaciones de terceros en todos los terminales, lo que reduce el tiempo que transcurre entre la publicación de una vulnerabilidad de día cero y la protección de su entorno.
¿Qué es una vulnerabilidad de día cero?
Una vulnerabilidad de día cero es un fallo de seguridad en el software, el hardware o el firmware que desconoce el proveedor encargado de solucionarlo y, por lo tanto, no existe ningún parche disponible en el momento en que los atacantes tienen conocimiento de ella o la aprovechan.
El término hace referencia al número de días de que ha dispuesto el proveedor para solucionar el problema: cero. Cuando un investigador descubre una vulnerabilidad y la comunica de forma responsable al proveedor, este dispone de tiempo para desarrollar y publicar un parche antes de que la vulnerabilidad se dé a conocer ampliamente y sea objeto de explotación. Un «día cero», por el contrario, es aquel en el que la vulnerabilidad se explota antes de que se produzca cualquier comunicación, o bien se da a conocer públicamente sin que se haya notificado previamente al proveedor, lo que deja un margen de tiempo en el que los sistemas son vulnerables y no existe ninguna solución.
El término también se escribe como «0-day», y «zero-day» puede referirse a la propia vulnerabilidad, al exploit que la aprovecha o al ataque que utiliza dicho exploit. Cada uno tiene un significado distinto, por lo que la terminología resulta confusa.
Una vez que se publica un parche, la vulnerabilidad deja de ser técnicamente una vulnerabilidad de día cero. Se convierte en una vulnerabilidad conocida. Sin embargo, esa transición no elimina el riesgo. El periodo de exposición real es el intervalo de tiempo que transcurre entre el momento en que un atacante tiene conocimiento de una vulnerabilidad y el momento en que una organización aplica el parche correspondiente; y, para la mayoría de las organizaciones, ese periodo puede prolongarse durante semanas o meses, incluso después de que el parche esté disponible.
Vulnerabilidad de día cero, exploit y ataque: definición de estos tres términos
Estos tres términos suelen utilizarse indistintamente, pero describen conceptos diferentes.
Una vulnerabilidad de día cero es un fallo subyacente en el software o el firmware, es decir, una brecha de seguridad que existe pero para la que aún no hay ningún parche. Se trata de una situación, no de una acción.
Un exploit de día cero es el código, la herramienta o la técnica que aprovecha esa vulnerabilidad. Los investigadores de seguridad utilizan los exploits para demostrar que una vulnerabilidad es real y puede ser explotada. Los atacantes los utilizan como armas. Cuando la comunidad de seguridad en general habla de que un exploit de día cero «se está explotando en el mundo real», se refiere a que se ha desplegado un exploit dirigido a esa vulnerabilidad contra objetivos reales.
Un ataque de día cero es la operación en la que se utiliza el exploit contra un objetivo. Una vulnerabilidad puede existir sin que se aproveche. Se puede crear un exploit sin que se utilice en un ataque. El ataque es el momento en el que una vulnerabilidad provoca un daño cuantificable.
Esta distinción es importante para la respuesta ante incidentes. Una organización que detecte un comportamiento de explotación en un sistema puede estar sufriendo un ataque de día cero, pero ese mismo comportamiento también podría indicar la explotación de una vulnerabilidad conocida que aún no se ha corregido. Distinguir entre ambos casos requiere una capacidad de detección que vaya más allá de la simple comparación de firmas.
Cómo se descubren las vulnerabilidades de día cero
Las vulnerabilidades de «día cero» se detectan a través de varias vías distintas, y la vía por la que se detectan es importante porque determina la rapidez con la que se publica un parche.
Los investigadores de seguridad que detectan vulnerabilidades suelen seguir procesos de divulgación responsable, notificándolo al proveedor de forma privada y concediéndole un plazo definido (a menudo de 90 días, tal y como establece la norma de Google Project Zero) para desarrollar un parche antes de hacer pública la información. En estos casos, es posible que ya exista un parche el mismo día en que la vulnerabilidad se hace pública, lo que acorta significativamente el verdadero periodo de «día cero».
Los grupos estatales y las organizaciones criminales sofisticadas invierten recursos considerables en la investigación de vulnerabilidades con el objetivo específico de detectar fallos explotables antes que los propios proveedores. Las vulnerabilidades de «día cero» descubiertas de esta forma suelen convertirse inmediatamente en armas y mantenerse en secreto durante meses o años para preservar su valor como herramientas de ataque. Se trata de la categoría más peligrosa, ya que estas vulnerabilidades existen y se están explotando activamente antes de que nadie ajeno al grupo atacante sepa que existen.
El mercado de vulnerabilidades de día cero es una economía real y de gran envergadura. Los intermediarios compran y venden exploits de día cero, y tanto los servicios de inteligencia gubernamentales como las organizaciones criminales actúan como compradores. Una vulnerabilidad de día cero en un software ampliamente utilizado puede alcanzar precios muy elevados en este mercado, lo que genera un incentivo económico para encontrar y acaparar vulnerabilidades en lugar de revelarlas de forma responsable.
La consecuencia práctica para los defensores es que, a menudo, no es posible saber si existe una vulnerabilidad de día cero en el software que utilizan y si está siendo objeto de comercio o explotación activa, ya que la característica definitoria de una verdadera vulnerabilidad de día cero es que ni el fabricante ni el público tienen conocimiento de ella. La defensa debe basarse en reducir el impacto de una explotación exitosa, más que en impedir la existencia de la vulnerabilidad.
Vulnerabilidades de «día cero» frente a vulnerabilidades conocidas: ¿cuál es más peligrosa?
Para la mayoría de las organizaciones, las vulnerabilidades conocidas sin parchear representan un riesgo operativo mayor que las de «día cero».
Las vulnerabilidades de «día cero» suscitan un gran interés porque son novedosas y porque aún no existen parches para ellas. Sin embargo, también son relativamente poco frecuentes en el panorama general de las vulnerabilidades. El volumen de vulnerabilidades documentadas públicamente y para las que existen parches en el software de uso común en un momento dado es enorme. La gran mayoría de los ataques exitosos que se producen en la red aprovechan vulnerabilidades conocidas, a menudo vulnerabilidades para las que ya hay parches disponibles desde hace meses o años.
Los datos que respaldan esta afirmación no dejan lugar a dudas. La mayoría de las filtraciones importantes que se investigan y se atribuyen públicamente resultan estar relacionadas con vulnerabilidades conocidas que han sido explotadas, más que con auténticas vulnerabilidades de «día cero». Los atacantes buscan el camino que les ofrece menos resistencia. Un servidor Exchange sin parches que presente un CVE de hace 18 meses es más accesible que una vulnerabilidad de «día cero» recién descubierta, cuya identificación le haya llevado meses al equipo de investigación de un Estado-nación.
La implicación práctica es que la mejor defensa frente al panorama completo de vulnerabilidades, tanto de día cero como conocidas, es en gran medida la misma: una gestión rápida y automatizada de los parches que minimice el intervalo de tiempo entre la disponibilidad de un parche y su aplicación, combinada con una capacidad de detección basada en el comportamiento que permita identificar actividades de explotación, independientemente de si la vulnerabilidad concreta es conocida o no.
Las vulnerabilidades de «día cero» requieren dos capacidades adicionales que las vulnerabilidades conocidas no exigen: la detección basada en el comportamiento, que identifica patrones de explotación sin basarse en firmas conocidas; y controles compensatorios que limitan el daño cuando no es posible aplicar un parche a una vulnerabilidad porque aún no existe.
Ejemplos destacados de vulnerabilidades «zero-day»
Log4Shell (2021)
La vulnerabilidad crítica de Apache Log4j, una biblioteca de registro de Java muy utilizada, se hizo pública en diciembre de 2021. A las pocas horas de su divulgación, comenzaron a producirse ataques a gran escala. La combinación de la presencia casi universal de Log4j en las aplicaciones Java empresariales y la gravedad de la vulnerabilidad (ejecución remota de código con requisitos mínimos de autenticación) convirtió este incidente en uno de los eventos de «día cero» más importantes de la última década. Las organizaciones que contaban con sistemas automatizados de gestión de parches y de inventario de activos, y que detectaron su exposición a Log4j, pudieron establecer prioridades y reaccionar. Las que carecían de ambos sistemas tardaron días en descubrir su exposición real, mientras la explotación ya estaba en marcha.
ProxyLogon (Microsoft Exchange, 2021)
Un grupo respaldado por el Estado chino aprovechó «ProxyLogon», un conjunto de vulnerabilidades en Microsoft Exchange Server, antes de que estuviera disponible el parche de Microsoft. Estas vulnerabilidades permitían la ejecución remota de código en servidores Exchange sin parchear. Cuando Microsoft publicó los parches, miles de servidores Exchange de todo el mundo ya habían sido comprometidos a través de «web shells» que persistían tras la explotación inicial.
Vulnerabilidades de día cero en Chrome (en curso)
Google Chrome recibe parches de emergencia para vulnerabilidades «zero-day» que están siendo explotadas de forma activa con cierta periodicidad, ya que los navegadores son programas complejos expuestos directamente a contenidos no fiables. El patrón es siempre el mismo: se identifica una vulnerabilidad «zero-day» que está siendo explotada en la red, Google lanza un parche de emergencia y las organizaciones que no han automatizado la aplicación de parches en los navegadores siguen expuestas hasta que el parche se instala manualmente.
Stuxnet (2010) y EternalBlue (2017)
Stuxnet sigue siendo el ejemplo más emblemático de un arma de «día cero» utilizada por un Estado-nación. Descubierto en 2010, aprovechaba simultáneamente cuatro vulnerabilidades de «día cero» distintas de Windows para introducir una carga útil que causó daños físicos a las centrifugadoras industriales del programa nuclear iraní. Sigue siendo notable por demostrar que la explotación de vulnerabilidades de «día cero» puede tener consecuencias físicas en el mundo real, y no solo la pérdida de datos.
EternalBlue, un exploit de día cero desarrollado originalmente por la NSA y filtrado en 2017, tenía como objetivo el protocolo SMBv1 de Windows. Se convirtió en el mecanismo de propagación de WannaCry y NotPetya, dos de los ciberataques más destructivos de la historia desde el punto de vista económico. La vulnerabilidad subyacente ya contaba con un parche de Microsoft disponible en el momento en que se lanzó WannaCry, pero millones de sistemas sin parchear seguían expuestos, razón por la cual un exploit para una vulnerabilidad ya conocida siguió siendo eficaz a una escala catastrófica.
La tendencia constante en los incidentes de «día cero» es la siguiente: las organizaciones que aplicaron los parches rápidamente tras su publicación, o que contaban con sistemas de detección de comportamiento capaces de identificar los intentos de explotación, lograron limitar los daños de forma significativamente más eficaz que aquellas que no lo hicieron.
Protección frente a las amenazas de «día cero»
La estrategia de defensa frente a las vulnerabilidades de día cero es la misma que la aplicada al panorama general de vulnerabilidades, con dos añadidos.
Reducir al mínimo la superficie de ataque
Cuanto menos software se ejecute en el entorno, menos objetivos potenciales de vulnerabilidades de día cero habrá. Eliminar el software que no se utilice de forma activa, limitar las extensiones del navegador al mínimo necesario y reducir los servicios expuestos a Internet limita las oportunidades de explotación. Una vulnerabilidad de día cero en un software que no se ejecuta no puede causarte ningún daño.
Gestión rápida y automatizada de parches
La aplicación de parches no sirve de nada durante el periodo de «día cero» propiamente dicho, pero reduce drásticamente la exposición una vez que se publica el parche. La transición de una vulnerabilidad de «día cero» a una vulnerabilidad conocida y, posteriormente, a una vulnerabilidad parcheada debe producirse lo antes posible, en cuestión de días, no de semanas. Kaseya VSA 10 y Datto RMM automatizan la implementación de parches en todos los terminales gestionados el mismo día de su publicación, con flujos de trabajo de aprobación configurables basados en anillos para los cambios que requieran pruebas antes de su implementación en producción.
Detección de EDR basada en el comportamiento
Las plataformas EDR que detectan comportamientos de explotación, inyección de procesos, escalada de privilegios, procesos hijos inesperados y conexiones de red inusuales procedentes de procesos de confianza pueden identificar explotaciones de «día cero» incluso sin una firma conocida para la vulnerabilidad específica. Datto EDR ofrece una detección basada en el comportamiento que detecta patrones de ataque en lugar de limitarse únicamente al malware conocido, lo que lo hace especialmente relevante durante el periodo de «día cero» previo al parche, cuando aún no existe ninguna firma.
Segmentación de la red
Limitar el alcance de un sistema comprometido en la red reduce el alcance del impacto cuando se explota con éxito una vulnerabilidad de día cero. Un atacante que aproveche una vulnerabilidad de día cero en una estación de trabajo no debería tener automáticamente acceso a un controlador de dominio, un servidor de archivos o un sistema de copias de seguridad. La segmentación no impide la explotación, pero convierte un compromiso catastrófico en uno contenido.
Gestión de vulnerabilidades
El análisis continuo que identifica el software sin parches en todo el entorno y prioriza las medidas correctivas en función de la disponibilidad de exploits y la importancia de los activos proporciona visibilidad sobre los puntos de exposición más urgentes. Cuando se anuncia una nueva vulnerabilidad de día cero, los datos de gestión de vulnerabilidades muestran de inmediato qué activos se ven afectados y con qué rapidez es necesario actuar.
Información sobre amenazas
Las fuentes de información que realizan un seguimiento de las campañas activas de explotación de vulnerabilidades de «día cero» ofrecen una alerta temprana —a menudo días antes de que exista un parche— de que una vulnerabilidad concreta está siendo explotada de forma activa. Esto permite aplicar controles compensatorios (cambios en las reglas, desactivación temporal de funciones, restricciones de acceso a la red) mientras se desarrolla el parche.
Defensa contra vulnerabilidades de día cero para MSP: el problema de la ventana de parches
Para los MSP, el reto que plantea la defensa frente a las vulnerabilidades de día cero no es conceptual, sino operativo. El periodo que transcurre entre el momento en que un parche para una vulnerabilidad de día cero está disponible y el momento en que dicho parche se implementa en docenas de entornos de clientes es la verdadera ventana de exposición, y sin automatización, ese periodo se alarga.
Pensemos en cómo es la coordinación manual de parches a gran escala. Un martes se da a conocer una vulnerabilidad crítica de «día cero» en un navegador. El equipo del MSP identifica la exposición, evalúa qué clientes se ven afectados, coordina las ventanas de mantenimiento con cada cliente, programa la implementación y verifica el éxito cliente por cliente. En el mejor de los casos, ese proceso se completa en tres o cuatro días para 30 clientes. En entornos en los que los atacantes comienzan a aprovechar las vulnerabilidades de alta gravedad recién reveladas en un plazo de 24 a 48 horas tras su divulgación, ese margen de tiempo es crucial.
Con Kaseya VSA 10 o Datto RMM, la misma implementación se lleva a cabo el mismo día en el marco de una política de parches automatizada, con una fase de prueba por anillos en la que se realizan pruebas con un grupo de validación antes de la implementación completa en producción. La coordinación de la ventana de mantenimiento viene preconfigurada. La verificación se realiza automáticamente. La ventana de exposición del MSP se reduce de días a horas para los clientes que operan bajo esa política.
Por eso, para el 69 % de los MSP que ofrecen la gestión de parches como servicio, no se trata solo de una línea de negocio, sino de la capacidad operativa que permite defender la ventana de «día cero». El servicio es el sistema. Descubre la gestión automatizada de parches de Kaseya VSA 10, un modelo operativo que permite escalar la respuesta rápida a las vulnerabilidades de «día cero» en un entorno multicliente.
Las vulnerabilidades de «día cero» acaparan los titulares. Sin embargo, son las vulnerabilidades conocidas y sin parchear las que causan la mayor parte del daño real. La estrategia de defensa que aborda ambas es la misma: reducir la superficie de ataque, automatizar la aplicación de parches, implementar la detección basada en el comportamiento y segmentar la red. Las organizaciones y los proveedores de servicios gestionados (MSP) que sacan el máximo partido a estas prácticas son aquellos que las aplican de forma continua, en lugar de recurrir a ellas solo como respuesta a la próxima revelación de gran repercusión mediática. Para entonces, la puerta ya está abierta.
Puntos clave
- Una vulnerabilidad de día cero es una falla de seguridad para la que no existe ningún parche disponible. Un exploit de día cero es el código que se aprovecha de dicha falla. Un ataque de día cero es la operación en la que se utiliza ese exploit. Estos tres términos describen conceptos distintos.
- La mayoría de los ataques exitosos que se producen en el mundo real aprovechan vulnerabilidades conocidas y que pueden corregirse mediante parches, en lugar de auténticas vulnerabilidades de día cero. Para la mayoría de las organizaciones, una gestión rápida de los parches reduce el riesgo de forma mucho más significativa que los controles específicos para vulnerabilidades de día cero por sí solos.
- La detección de EDR basada en el comportamiento, la segmentación de la red y la gestión de vulnerabilidades proporcionan los controles compensatorios necesarios durante el periodo previo a la aplicación del parche, cuando aún no existe ninguna solución.
- Para los MSP, el reto operativo es el plazo de aplicación de parches en los entornos de los clientes. La gestión automatizada de parches basada en políticas a través de Kaseya VSA 10 o Datto RMM reduce ese plazo de días a horas.
