¿Qué es una vulnerabilidad de día cero? Definición, ejemplos y medidas de protección

El término «zero day» aparece constantemente en las noticias sobre ciberseguridad, pero a menudo se malinterpreta este concepto. Una vulnerabilidad de tipo «zero day» 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 de día cero y subestiman el riesgo, mucho más común, de las vulnerabilidades conocidas sin parchear. Las defensas que cierran la ventana de los ataques de día cero 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. Lea el informe «2026 Kaseya State of the MSP Report»: 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 críticos en la seguridad de TI.

¿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 la descubren o la aprovechan.

El término hace referencia al número de días de que ha dispuesto el proveedor para resolver el problema: cero. Cuando un investigador descubre una vulnerabilidad y la comunica de forma responsable al proveedor, este tiene tiempo para desarrollar y publicar un parche antes de que la vulnerabilidad se dé a conocer ampliamente y sea objeto de ataques. En cambio, una vulnerabilidad de «día cero» es aquella que se aprovecha antes de que se produzca cualquier divulgación, o que se da a conocer públicamente sin que se haya notificado previamente al proveedor, lo que deja un intervalo 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 puede resultar 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 desde que un atacante tiene conocimiento de una vulnerabilidad hasta que una organización aplica el parche correspondiente y, para la mayoría de las organizaciones, ese intervalo 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 se suelen utilizar indistintamente, pero describen cosas diferentes.

Una vulnerabilidad de día cero es un fallo subyacente en el software o el firmware, 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 la red», se refiere a que se ha utilizado 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 causa 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 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 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, notificando al proveedor de forma privada y concediéndole un plazo determinado (a menudo de 90 días, 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 considerablemente 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 manera suelen convertirse en armas de inmediato 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 explotan activamente antes de que nadie ajeno al grupo atacante sepa siquiera que existen.

El mercado de vulnerabilidades de día cero es una economía real y considerable. 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 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 proveedor 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 suponen un riesgo operativo mayor que las vulnerabilidades de día cero.

Las vulnerabilidades de «día cero» acaparan gran parte de la atención 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 existen 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 graves que se investigan y se atribuyen públicamente resultan estar relacionadas con vulnerabilidades conocidas que han sido explotadas, más que con auténticos «zero-day». Los atacantes optan por la vía más fácil. Un servidor Exchange sin parches que presente una vulnerabilidad CVE de hace 18 meses es más accesible que un «zero-day» recién descubierto, cuya identificación le haya llevado meses al equipo de investigación de un Estado-nación.

En la práctica, esto significa que la mejor defensa frente al conjunto de vulnerabilidades, tanto las de día cero como las conocidas, es básicamente la misma: una gestión rápida y automatizada de los parches que reduzca al mínimo el tiempo que transcurre entre la publicación de un parche y su aplicación, combinada con una capacidad de detección basada en el comportamiento que permita identificar los intentos 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 depender de 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 de día cero

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 una gestión automatizada de parches y un inventario de activos que mostraba su exposición a Log4j pudieron priorizar y responder. Las que carecían de ambos pasaron días descubriendo 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. Para cuando Microsoft publicó los parches, miles de servidores Exchange en 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 de día cero que se están explotando de forma activa con cierta periodicidad, ya que los navegadores son programas complejos que están directamente expuestos a contenidos no fiables. El patrón es siempre el mismo: se detecta que una vulnerabilidad de día cero 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 en 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 provocar 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 devastadores de la historia desde el punto de vista económico. Aunque ya existía un parche de Microsoft para la vulnerabilidad subyacente cuando se lanzó WannaCry, 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 tónica general en los incidentes de «día cero» es la siguiente: las organizaciones que aplicaron los parches rápidamente tan pronto como estuvieron disponibles, o que contaban con sistemas de detección de comportamiento capaces de identificar los intentos de explotación, lograron contener los daños de forma mucho más eficaz que aquellas que no lo hicieron.

Protección contra 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.

Minimizar 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 es eficaz durante la fase inicial de una vulnerabilidad de día cero, 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 secundarios 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 aprovecha 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 el aprovechamiento de la vulnerabilidad, 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 ofrece 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 activamente. Esto permite aplicar medidas de control compensatorias (modificaciones de 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 proveedores de servicios de gestión (MSP): el problema de la ventana de actualización

Para los MSP, el reto que plantea la defensa frente a vulnerabilidades de día cero no es conceptual, sino operativo. El periodo que transcurre entre el momento en que se publica un parche para una vulnerabilidad de día cero y el momento en que dicho parche se implementa en decenas de entornos de clientes es la verdadera ventana de exposición, y sin automatización, ese periodo se alarga.

Imaginemos cómo es la coordinación manual de parches a gran escala. Un martes se da a conocer una vulnerabilidad crítica de tipo «zero-day» en un navegador. El equipo del proveedor de servicios de gestión (MSP) identifica el riesgo, 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 virtud 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 está 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 proteger la ventana de «día cero». El servicio es el sistema. Descubra la gestión automatizada de parches de Kaseya VSA 10 y conozca el 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 cuando se produce una nueva revelación de gran repercusión. Para entonces, la puerta ya está abierta.