🔮Zero-day: qué son, por qué importan, y cómo prepararte antes de que te peguen

Imaginá este escenario. Lunes a las 8am, abrís las noticias. Un investigador de seguridad acaba de publicar una vulnerabilidad crítica en un plugin que vos tenés instalado en tu sitio. CVSS 9.8. Exploit público en GitHub. El vendor del plugin responde: "parche oficial en 48-72 horas". Durante esas 72 horas, tu sitio es target legítimo de cualquier bot que escanee internet. ¿Qué hacés?

Eso es un zero-day. Más precisamente, una vulnerabilidad que era zero-day hasta esta mañana — cuando fue descubierta antes del parche oficial. El reloj empezó a correr y todos los administradores de sistemas con ese plugin instalado entraron en el mismo loop mental: "¿cuándo lo van a patchear? ¿cómo me protejo mientras tanto?".

Este artículo explica qué son los zero-days, cómo funciona su ciclo de vida, por qué no podés prevenirlos todos, y — críticamente — cómo construir defensa resiliente que te proteja aun contra lo desconocido. Pensado para admins de WordPress y directores técnicos de empresas medianas LATAM.

Zero-day, N-day, y vulnerabilidad regular

Tres términos que suenan similares pero son distintos:

Vulnerabilidad zero-day

Vulnerabilidad que existe en software pero NO es públicamente conocida. Cero días han pasado desde su descubrimiento público. El vendor no sabe que existe. No hay parche. Si un atacante la conoce, la puede explotar sin resistencia.

Los zero-days más valiosos (en dark markets, brokers, nation-states) son los que nadie más conoce. Zerodium históricamente ofrecía $2.5M por zero-day de iOS. Google Project Zero invierte fuerte en encontrarlos antes que atacantes.

Vulnerabilidad n-day

Vulnerabilidad ya conocida públicamente PERO no parcheada en sistemas específicos. "N-day" porque N días han pasado desde el anuncio público. Si una CVE se publicó hace 30 días y tu sitio no la parcheó, para vos es n-day con n=30.

La mayoría de hackeos exitosos son n-days, no zero-days. Los sistemas no se parchean; los atacantes aprovechan.

Vulnerabilidad regular (pre-pública)

Vulnerabilidad descubierta por investigadores, reportada al vendor, en proceso de fix, pero NO pública aún. Durante este período (semanas a meses), la vulnerabilidad existe pero el riesgo es bajo — solo el vendor y el investigador la conocen.

Este período se llama "responsible disclosure window" — típicamente 90 días entre reporte y publicación pública.

Ciclo de vida: desde descubrimiento hasta amplio abuso

El paseo típico de una vulnerabilidad desde secreto hasta ampliamente explotada:

Fase 1: Descubrimiento privado (días a años)

Alguien — investigador, empleado del vendor, o atacante — encuentra la vulnerabilidad. Puede quedarse oculto durante meses o años antes de ser reportado o explotado.

Fase 2: Disclosure responsable (90 días típico)

El investigador reporta al vendor. El vendor confirma, desarrolla fix, prueba, prepara release. El investigador coordina el timing del anuncio público con el release del parche.

Durante esta fase, si la vulnerabilidad es secreta, el riesgo es bajo. Si el atacante es el que la encontró (no un investigador ético), la explota silenciosamente.

Fase 3: Anuncio público + parche simultáneo (t=0)

El vendor publica la CVE y el parche. Idealmente al mismo momento. "Zero-day" deja de ser zero-day en este momento — ahora todos saben que existe.

Fase 4: PoC público en GitHub (t + 6-24 horas)

Alguien — investigador, atacante, curioso — publica una prueba de concepto en GitHub. Proof of concept: código que demuestra la explotación. A veces los investigadores publican su PoC junto con el report; a veces atacantes reverse-engineer del parche y publican en GitHub/pastebin.

Fase 5: Bots automatizados (t + 12-48 horas)

Los atacantes de masa incorporan el exploit en sus scanners. Los bots empiezan a escanear millones de sitios buscando la versión vulnerable. Si tu sitio tiene esa versión y no parcheó, te están escaneando ahora mismo.

Fase 6: Amplio abuso (t + 72 horas - semanas)

Las campañas a escala empiezan. Newsworthy incidents. Vendors de seguridad publican reportes. Empresas afectadas aparecen en prensa.

Fase 7: Maduración de defensas (t + días a semanas)

WAFs agregan reglas. Threat intel marca IPs de atacantes activos. La mayoría de sitios aplican el parche. El incendio se apaga para la mayoría, queda humeando para sitios sin parchear.

Fase 8: Long tail (t + meses a años)

Una cola larga de sitios nunca parcheados sigue siendo vulnerable. Atacantes de menor capacidad aprovechan. Reporte post-mortem: "X% de sitios tenía la versión vulnerable un año después".

Por qué las empresas medianas son cada vez más target

Históricamente, las campañas de zero-day targeteaban Fortune 500 (más valor por cliente comprometido). Patrón cambió:

• Automatización de explotación: los bots pueden atacar miles de sitios simultáneamente. El costo marginal de un target adicional es casi cero.
• Ransomware como business model: el ransomware no requiere que el target sea rico — requiere que el target pueda pagar. Empresa mediana puede pagar $10K-$100K por descifrar.
• LATAM menos defendida: atacantes saben que defensas típicas en LATAM son menores que USA/EU. Target menos protegido por igual esfuerzo.
• Ecosistema de "Ransomware-as-a-Service": operadores de ransomware (LockBit, Conti, BlackCat) alquilan sus herramientas a affiliates. Los affiliates targetean whoever pueden, no grandes solamente.

Resultado: los zero-days que aparecen en plugins WordPress, WooCommerce, frameworks populares — afectan a miles de empresas medianas LATAM en cuestión de días.

5 capas de defensa contra lo desconocido

No podés prevenir zero-days. Lo que sí podés es construir defensa que reduzca el impacto aun contra amenazas desconocidas.

Capa 1: Superficie de ataque mínima

La mejor protección contra zero-days es no tenerlos. Cada plugin, theme, service que agregás a tu stack es superficie adicional. Principio: mínimo viable.

Auditoría periódica:

• ¿Todos los plugins que tengo son necesarios?
• ¿Uso todas las features del theme o podría usar uno más simple?
• ¿Los servicios third-party agregan valor real o son decoración?

Cada componente removido = una fuente menos de zero-days potenciales.

Capa 2: Actualización sistemática

La mayoría de zero-days que realmente afectan a tu sitio: o están en plugins/themes no actualizados (son n-days, no zero-days puros), o en componentes reales donde el parche llega rápido y lo aplicás rápido.

Disciplina de patcheo: automático para parches menores de seguridad, semanal para mayores con testing previo, mensual para upgrades compatibles-breaking.

Capa 3: Monitoreo de integridad

Aun si un zero-day es explotado contra tu sitio, el atacante típicamente deja artefactos: archivos nuevos, archivos modificados, usuarios creados, tareas cron. Monitoreo de integridad detecta el artefacto aun sin conocer el vector original.

Con Drako (hardening + monitoreo SHA-256 + análisis IA del código modificado), un exploit de zero-day que modifica archivos dispara alerta incluso aunque no conozcas la CVE original.

Capa 4: Virtual patching con IA

Cuando la CVE se publica públicamente (fase 3-4 del ciclo de vida), vos querés proteger ANTES de que el parche oficial llegue. Virtual patching con IA (Conan) genera reglas en minutos, protege durante las 24-72 horas de ventana de vulnerabilidad.

No previene el zero-day cuando aún es secreto. Pero reduce dramáticamente la ventana de exposición post-anuncio público.

Capa 5: Capacidad de respuesta rápida

Si un zero-day te golpea antes de que defensas preventivas actúen, lo que te salva es velocidad de respuesta:

• Detección rápida (alertas que llegan en minutos, no días).
• Plan de contención documentado (sabés qué hacer sin improvisar).
• Backups verificados (restaurar es opción real).
• Capacidad de comunicación a clientes (reducís daño reputacional).

Estas capas son las que separan "un susto recuperable" de "crisis existencial" cuando un zero-day pega.

Oráculo: predicción de riesgo (no de vulnerabilidad)

Un malentendido común: "¿Oráculo puede predecir zero-days antes de que existan?". No, y nadie puede — si pudieras predecir código no escrito, serías rico en otros campos.

Lo que Oráculo hace es predecir riesgo, no vulnerabilidad específica:

Predicción por industria y región

"Basado en telemetría anónima de clientes Drokio, las tiendas WooCommerce LATAM tienen alta probabilidad (estimada >30%) de ser target de campaña de skimmer en próximas 2-4 semanas."

Esto no te dice qué exploit específico usarán. Te dice que la probabilidad de ser target para tu tipo de sitio es alta ahora mismo. Acción: reforzá defensas de checkout específicamente, aumentá monitoreo de ese vector.

Predicción por combinación de stack

"Sitios con combinación de Plugin A + Plugin B + PHP 7.x tienen 3x más probabilidad de ser comprometidos en próximos 90 días que sitios con stack moderno."

Basado en histórico de incidentes entre clientes Drokio con configuraciones similares. Acción: actualizar stack, específicamente las combinaciones que históricamente correlacionan con compromiso.

Predicción de CVEs próximas

"Plugin X tiene tasa histórica de 3-5 CVEs críticos por año, con promedio de 45 días entre CVE y siguiente. Última CVE hace 38 días. Alta probabilidad de próxima CVE en próximas 2-4 semanas."

Predice ritmo de publicación de vulnerabilidades, no contenido específico. Acción: preparate para aplicar parche rápido cuando aparezca, tener virtual patching listo.

Escalamiento de respuesta por severidad

Cuando un zero-day aparece que afecta a tu stack, escalá respuesta según severidad:

Severidad crítica (CVSS 9-10)

• Aplicar virtual patching inmediatamente (Conan).
• Monitorear logs en tiempo real por intentos de explotación.
• Preparar parche oficial para deploy tan pronto salga.
• Comunicación a clientes si downtime es probable.

Severidad alta (CVSS 7-8.9)

• Virtual patching si es posible.
• Priorizar parcheo en próximas 24-48 horas.
• Monitorear activamente.

Severidad media (CVSS 4-6.9)

• Parchear en próximos 7 días.
• Monitorear casualmente.

Severidad baja (CVSS 0-3.9)

• Parchear en próximo ciclo de mantenimiento.
• No requiere acción urgente.

El error frecuente: tratar toda CVE con el mismo nivel de pánico. Genera fatigue del equipo, las críticas reales se atienden como si fueran rutina.

Seguro cibernético contra zero-days

Las pólizas de seguro cibernético modernas sí cubren zero-days, con caveats:

• Requieren diligencia razonable: patcheo regular, logs, plan de respuesta documentado. Sin esto, rechazan reclamos alegando negligencia.
• Exclusiones por nation-state: muchas pólizas excluyen ataques atribuibles a nation-states (argumentando "acto de guerra"). En la práctica es difícil probar atribución.
• Retención específica: requieren que contrates servicios de respuesta que el asegurador aprueba.

Para empresa mediana LATAM 2026: primas típicas 1-5% del revenue anual. Cobertura típica: $500K-$5M. Para empresas con revenue significativo y exposición digital alta, vale la pena.

Cierre

Zero-days son inevitables. Lo que controlás es tu posición cuando aparecen: superficie de ataque, disciplina de patcheo, capacidad de detección, virtual patching, capacidad de respuesta. Ninguna capa individual alcanza; la combinación de todas reduce el impacto dramáticamente.

Oráculo no predice el futuro — reduce incertidumbre al darte estimaciones basadas en data. Eso no es magia, es estadística aplicada con IA. Pero operacionalmente, tener estimación de riesgo para las próximas 4 semanas vale más que operar a ciegas.

La pregunta que importa no es "¿cómo prevenir todo zero-day?" (imposible) sino "¿cómo minimizar el daño cuando alguno te golpea?" (alcanzable).