Saltar al contenido
>_ITDITDPlataforma de seguridad web

Incidentes y vulnerabilidades

Filtración masiva de MOVEit (2023) — cómo un zero-day de inyección SQL alcanzó a más de 2.700 organizaciones, y cómo defenderse

Un zero-day de SQLi (CVE-2023-34362) en MOVEit, explotado en masa por Cl0p antes de un parche — más de 2.700 organizaciones, ~93,3M de personas, la mayoría golpeadas a través de un proveedor. La cadena de ataque como mapa de defensa, y las soluciones que importan.

Publicado 2026-06-12 Actualizado 2026-06-12 10 min de lectura

Leemos incidentes públicos reales no como repeticiones de noticias, sino a través de «cómo te defenderías de esto». Este artículo se basa en registros públicos (agencias, avisos de proveedores, inteligencia de amenazas, prensa), citados al final. Sin pasos de ataque ni payloads.

2.700+
organizaciones afectadas
93,3M
personas afectadas (est.)
9.8
CVSS de CVE-2023-34362
zero-day
explotado en masa antes de un parche
Expediente del caso
Objetivo
MOVEit Transfer (producto de transferencia de archivos de Progress Software) y las organizaciones y clientes que lo usaban
Explotación iniciada
en torno al 27 de mayo de 2023 (fin de semana del Memorial Day en EE. UU.)
Clase
un zero-day de inyección SQL en una app web pública → web shell → robo de datos de la BD de respaldo, más extorsión
Escala
más de 2.700 organizaciones, ~93,3M de personas (estimaciones posteriores más altas)
Causa raíz
fallo de SQLi desconocido + explotación masiva antes de un parche + una capa web que podía leer toda la BD de respaldo + difusión vía proveedores
Soluciones reales
parcheo rápido de KEV, minimizar la exposición, mínimo privilegio y segmentación web↔BD, inventario de proveedores y minimización de datos

Qué ocurrió (en términos llanos)

MOVEit Transfer es un producto para entregar archivos de forma segura entre organizaciones, y muchos lo ejecutaban expuesto a internet. Su interfaz web pública tenía un zero-day de inyección SQL: un fallo donde la entrada reescribe el significado de una consulta a la base de datos.

El grupo Cl0p lo explotó antes de que existiera una corrección para plantar un web shell (un programa malicioso de control remoto, llamado "LEMURLOOT" en los registros públicos) en las instancias de MOVEit expuestas. Con eso, leyeron en masa los archivos y la información de usuarios almacenados en la base de datos detrás del producto y los exfiltraron. Cl0p luego reivindicó la autoría en un sitio de filtraciones y exigió un rescate, amenazando con publicar los datos.

Un «appliance de transferencia de archivos» es un mapa del tesoro para un atacante

Los productos de transferencia de archivos, por su naturaleza, concentran datos sensibles de muchas organizaciones y tienden a estar expuestos a internet por necesidades del negocio. Para un atacante eso es un objetivo de alto valor: «rompe uno, alcanza muchos datos». Por eso este tipo de appliance público debe defenderse asumiendo que estará entre las primeras cosas golpeadas en cuanto aparezca un zero-day.

La cadena de ataque también es un mapa de defensa

Lo que importa es que esto fue una cadena de cuatro saltos, y cada salto tenía un punto donde detenerlo. Léela no como una receta de ataque, sino como dónde se pudo haber cortado.

1. Entrada: zero-day de SQLi en la app web pública

un fallo desconocido de inyección SQL en una interfaz expuesta a internet.

⊘ parada: minimizar la exposición (tras VPN/lista de IP permitidas)

2. Web shell plantado

el fallo se usa para instalar un programa de control remoto.

⊘ parada: parcheo rápido de KEV (cerrar el agujero activo en horas-días)

3. Datos robados de la BD de respaldo

la capa web lee en masa los datos almacenados de la base de datos.

⊘ parada: mínimo privilegio web↔BD, segmentación, detección de lecturas masivas

4. Difusión a miles vía proveedores

desde proveedores que usaban MOVEit, hacia los datos de sus clientes.

⊘ parada: inventario de proveedores + minimizar los datos que entregas

Cada etapa «pudo detenerse». La defensa en profundidad significa muchas de estas paradas, no un único muro.

La cronología divulgada

  1. 2023-05-27

    Cl0p comienza a explotar en masa el zero-day de MOVEit Transfer (fin de semana del Memorial Day en EE. UU.).
  2. 2023-05-31

    Progress Software divulga CVE-2023-34362 y lanza un parche de emergencia.
  3. 2023-06-02

    CISA añade CVE-2023-34362 al catálogo KEV (Known Exploited Vulnerabilities).
  4. 2023-06-06

    Cl0p reivindica la autoría en su sitio de filtraciones y comienza la extorsión.
  5. 2023-06-07

    CISA/FBI publican el aviso conjunto #StopRansomware (AA23-158A).
  6. 2023→

    Los recuentos de organizaciones y personas afectadas siguen subiendo a medida que aflora el impacto por la vía de los proveedores.

La causa raíz no fue «un solo error», sino capas fallando

Archivar esto como «MOVEit tenía un fallo» garantiza una repetición. En realidad fallaron varias capas en secuencia.

La configuración que falló (en su momento)

  • un appliance que concentra datos sensibles, ampliamente expuesto a internet
  • explotado en masa en la ventana zero-day, pre-parche
  • una capa web que podía leer toda la BD de respaldo (segmentación/privilegio débiles)
  • sin visibilidad de las prácticas de los proveedores, así que la difusión no se pudo detener

La configuración defendida (prevención)

  • minimizar la exposición (tras VPN/lista de IP permitidas; cerrar funciones no usadas)
  • parcheo rápido de KEV (aplicar primero las correcciones en explotación activa)
  • segmentar y mínimo privilegio web↔BD + detección de lecturas masivas
  • inventario de proveedores + minimización de datos para reducir el radio de impacto

Cadena de suministro: tu seguridad depende de «aquel a quien se los entregaste»

El rasgo definitorio de esta filtración es que la mayoría de las víctimas no usaban MOVEit ellas mismas. Como un proveedor o prestador al que habían confiado datos (nóminas, pensiones, seguros) usaba MOVEit, sus clientes fueron arrastrados por la cadena (la misma forma aparece en el incidente de cadena de suministro de Codecov). Así que cuando entregas datos a un tercero, pregunta tanto «¿cuál es su práctica frente a vulnerabilidades?» como «¿hace falta siquiera entregar estos datos?»

Cómo prevenir una repetición en tu entorno

Soluciones ordenadas por prioridad que funcionan a cualquier escala. Si tienes aunque sea una «función de administración/transferencia de archivos expuesta a internet» o una «relación donde entregas datos a un tercero», esto va contigo.

1

Minimiza la exposición (reduce el objetivo)

No expongas las funciones de administración y transferencia de archivos directamente a internet donde sea evitable. Ponlas tras una VPN o una lista de IP permitidas, y cierra/aísla las funciones no usadas y los appliances antiguos. Reducir lo que un atacante puede tocar es el primer movimiento.

2

Parchea primero los fallos listados en KEV (parcheo rápido)

Cuando un producto que ejecutas aparece en la lista de explotación activa (KEV), aplica la corrección en horas o días. No puedes evitar el zero-day, pero cerrar de golpe la ventana posterior al parche evita el grueso del daño (→ la práctica de la respuesta ante vulnerabilidades, el feed de alertas de amenazas).

3

Segmenta la app web de la BD de respaldo, mínimo privilegio

Para que una app web pública vulnerada quede contenida, restringe los privilegios de modo que la capa web no pueda leer toda la BD de respaldo, y segmenta la red. La verdadera solución de la SQLi son los marcadores de posición, pero la segmentación y el mínimo privilegio reducen el radio de impacto si algo se cuela.

4

Inventaría a los proveedores y minimiza los datos que entregas

Lista quién tiene tus datos (proveedores, SaaS, prestadores) y mantén una vía de contacto para incidentes graves. Y minimiza los datos que entregas en primer lugar: los datos que nunca enviaste no pueden filtrarse cuando los vulneren.

Dónde coincide esto con el diseño de este sitio

Este sitio también se construye sobre minimizar la exposición y monitorizar de forma automática los fallos en explotación activa (KEV) para parchearlos rápido (mediante su propia auditoría de dependencias y su feed de amenazas). Este incidente es el ejemplo más elocuente de por qué los principios que sostenemos en el producto —estrechar lo que expones, matar primero los fallos KEV, separar capas para reducir el radio de impacto, minimizar los datos que entregas— de verdad importan. No puedes evitar el zero-day en sí, pero una práctica que cierra de golpe la ventana posterior al parche y un diseño que contiene el daño cuando hay brecha son implementables por cualquiera, a cualquier escala.

Fuentes (registro público)

Los hechos aquí se basan en la siguiente información pública. Sin reproducción de ataques ni payloads, solo las lecciones defensivas.

  • CISA / FBI, "#StopRansomware: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability" (AA23-158A, 2023) — cisa.gov
  • Progress Software official advisory, "MOVEit Transfer Critical Vulnerability (CVE-2023-34362)" (2023) — community.progress.com
  • Mandiant (Google Cloud), "Zero-Day Vulnerability in MOVEit Transfer Exploited for Data Theft" (2023) — cloud.google.com
  • Rapid7, "CVE-2023-34362: MOVEit Vulnerability Timeline of Events" (2023) — rapid7.com

Lee a continuación

FAQ

Q¿Cuál fue la causa raíz de la filtración de MOVEit?
A

Una vulnerabilidad de inyección SQL desconocida (zero-day) (CVE-2023-34362) en el producto MOVEit Transfer, expuesto a internet. Los atacantes la explotaron para plantar un web shell (un programa malicioso de control remoto) y leer en masa los datos de los archivos almacenados en la base de datos detrás del producto. La combinación de explotación masiva antes de que existiera un parche, y una capa web que podía leer toda la base de datos de respaldo, lo hizo grave.

QNo uso MOVEit, ¿por qué me afecta esto?
A

La mayoría de las víctimas no eran usuarias de MOVEit; fueron arrastradas porque un proveedor, socio o prestador de servicios al que habían confiado datos usaba MOVEit. Es una fuga clásica de cadena de suministro: la seguridad de tus datos también depende de las prácticas de parcheo de aquel a quien se los entregas. Un inventario de proveedores y minimizar los datos que entregas ayudan.

Q¿Hay algo que pueda aprender un servicio pequeño?
A

Sí. (1) Las funciones de administración y transferencia de archivos expuestas a internet son objetivos prioritarios, así que minimiza la exposición y parchea cualquier cosa de la lista KEV (en explotación activa) en horas o días. (2) Segmenta la base de datos detrás de una aplicación web y restringe los privilegios para que la capa web no pueda leerlo todo. (3) Minimiza los datos que entregas a terceros. Todo esto funciona a cualquier escala.