Dos de las historias de este número empiezan igual: con un sistema de intercambio de archivos al que nadie vigilaba lo bastante de cerca.
En el Defense Manpower Data Center, personas ajenas tuvieron acceso a uno durante meses. Resultaron afectadas más de tres millones de personas, y algunos de los registros vinculaban datos personales con funciones militares. Después, en nuestra Investigación técnica, desmontamos un sistema de intercambio de archivos distinto. En ShareFile Storage Zone Controller, una redirección de inicio de sesión que en realidad no detenía la página, junto con una función de carga de archivos, bastó para dar a un atacante ejecución remota de código.
Los sistemas son distintos, pero el problema es el mismo. Un servidor de intercambio de archivos parece parte de la fontanería, pero está justo al lado de los datos que importan a las personas y, por lo general, está expuesto a internet a propósito.
Por eso el Análisis a fondo de este número plantea la pregunta obvia: ¿cuánto valen realmente esos registros del DMDC una vez que un nombre y un número de la Seguridad Social están vinculados a un puesto militar, y un año de monitorización crediticia atiende el riesgo que importa? De paso, hablamos de Have I Been Pwned y de su creador, Troy Hunt, presentamos la Octopus Conference del Consejo de Europa y repasamos las noticias de la semana.
En este número
🌡️ Nivel de amenaza: Elevado
⚡ Noticias: Tres incidentes que convierten infraestructura expuesta en riesgo para los datos
🔎 Análisis a fondo: 3 millones de registros militares expuestos. ¿Cuánto valían para quien se los llevó?
🎣 ¿Es phishing?
🔬 Investigación técnica: La página de inicio de sesión lo redirigía. También le enviaba el panel de administración.
🛠️ Herramienta de la semana: Have I Been Pwned
👏 Persona de la semana: Troy Hunt
📅 Evento de la semana: Octopus Conference 2026
📚 Libro de la semana: Kingpin
😅 El meme
❓ Una pregunta antes de despedirnos
Vamos al grano.
🌡️Nivel de amenaza
Cocina, a fuego vivo
⚡Sección 01: Noticias
Candidatos, para llevar
ShinyHunters afirma haberse llevado entre 2 y 3 TB del portal de empleo del FBI
El 23 de septiembre, el FBI dijo que investigaba un incidente cibernético después de que ShinyHunters afirmara haber entrado en fbijobs.gov y haberse llevado datos de empleados y candidatos.
El grupo asegura tener entre 2 y 3 terabytes de archivos. Como prueba, entregó a periodistas una muestra de unos 5,000 registros: nombres, direcciones, números de teléfono, fechas de nacimiento, números de la Seguridad Social y contactos de emergencia. Algunas entradas también indicaban oficinas de campo y trabajo en inteligencia, seguridad y contraespionaje.
Los periodistas pudieron verificar partes de la muestra, pero no el conjunto de datos completo. El FBI no ha confirmado el volumen ni cómo entraron los atacantes. Dijo que el punto de la intrusión podría estar en su propio entorno o en uno de los terceros que dan soporte al portal de reclutamiento.
Por qué importa: Un número de la Seguridad Social por sí solo es un problema de robo de identidad. Un número de la Seguridad Social junto a una oficina de campo, un tipo de trabajo y una lista de contactos familiares es otra cosa. Indica a quién vigilar, a quién suplantar, a quién presionar y a quién enviar un correo de phishing muy específico.
Los sistemas de reclutamiento también dicen mucho de la organización que hay detrás. Entre solicitudes, referencias, formularios médicos e historiales de destinos, se puede deducir quién trabaja dónde, qué equipos están contratando y quién recibiría con verosimilitud un mensaje interno sensible. La monitorización crediticia podría detectar fraude financiero. No hará nada contra eso.
El punto de intrusión poco claro es una advertencia en sí mismo. Los datos de los candidatos suelen pasar por la agencia, la plataforma de reclutamiento y varios contratistas. Si se tardan semanas en averiguar quién tenía los datos, quién gestionaba la aplicación y quién tiene los registros, esa confusión ralentiza toda la respuesta.
Clasifique los sistemas de reclutamiento y de RR. HH. por los datos que contienen, no por cómo se llame el portal.
Pasarelas, a la parrilla
Citrix corrige dos día cero de NetScaler ya explotados en la práctica
El 27 de septiembre, Citrix divulgó dos vulnerabilidades críticas en NetScaler ADC y Gateway, CVE-2026-88771 y CVE-2026-88772. Ambas tienen una calificación de 9.5, y Citrix afirma que ya las ha visto explotadas en despliegues sin mitigar.
CVE-2026-88771 es un fallo de validación de entradas que puede permitir a un atacante no autenticado ejecutar comandos en el appliance. CVE-2026-88772 es un desbordamiento de memoria que puede dar lugar a ejecución remota de código o a denegación de servicio cuando DTLS está habilitado.
Citrix indicó a los clientes que actualizaran de inmediato. CISA añadió ambos errores a su catálogo de vulnerabilidades explotadas conocidas y fue un paso más allá: busque señales de compromiso antes de aplicar el parche y conserve las evidencias forenses.
Por qué importa: Un NetScaler se sitúa entre los usuarios externos y las aplicaciones internas. Termina conexiones, intermedia el acceso remoto y, según la configuración, gestiona inicios de sesión, estado de sesión, certificados y el tráfico que va más adentro de la red. La ejecución de código en ese equipo coloca al atacante en una posición de mucha confianza.
Por eso aplicar el parche no es el final. La actualización cierra el agujero, pero no expulsa a quien entró antes y no cancela las sesiones, credenciales ni secretos que ya pueda tener.
Si tenía un NetScaler vulnerable expuesto a internet, trátelo como un posible incidente. Aplique el parche, cierre las sesiones activas, rote cualquier secreto al que pudiera acceder, revise los cambios en la configuración y en el sistema de archivos, y compare su actividad con registros guardados en un lugar al que el appliance no pudiera llegar.
«¿Está parcheado?» es la pregunta fácil. La útil es qué estaba haciendo el equipo antes de que lo parcheara.
Boletín de seguridad de Citrix
Botnets, con un giro
Una botnet está instalando un agente de IA en los hosts que controla
El 30 de septiembre, la Agencia de Ciberseguridad de Singapur advirtió sobre CARBONATO, una campaña dirigida a hosts Docker que exponen la Remote API a internet sin autenticación, normalmente en el puerto TCP 2375.
Cuando encuentra uno, la botnet usa la propia API de Docker para iniciar un contenedor privilegiado con acceso al sistema de archivos, los procesos y la red del host. Configura acceso remoto, añade varias capas de persistencia y escanea las redes cercanas cada cinco minutos en busca de más daemons de Docker expuestos.
También instala Hermes Agent, un framework de agentes de código abierto. Los atacantes apenas tocan el framework en sí. Sustituyen su archivo de personalidad por instrucciones que le ordenan recibir tareas por Telegram, ejecutar comandos y recopilar credenciales.
Por qué importa: Hermes no dirige la botnet. Los scripts de siempre siguen encargándose de la intrusión, la persistencia y la propagación. El agente llega cuando el host ya está tomado y da a los operadores una forma flexible de decidir qué hacer a continuación en cada equipo.
Eso es lo que lo hace digno de atención. Nadie ha construido aquí malware autónomo. Tomaron un framework de agentes existente, lo acoplaron a una cadena de intrusión estándar y cambiaron un archivo de texto corto. Eso es mucho más fácil de copiar que un malware a medida.
Las instrucciones también colocan las claves de API de IA a la cabeza de la lista del botín, por encima de las credenciales SSH, los tokens de acceso y las bases de datos. Las claves robadas pueden pagar la propia automatización de los atacantes, darles acceso a mejores modelos o abrirles una vía hacia los servicios internos de IA de una empresa.
Bloquear Hermes no es la respuesta, ya que mucha gente lo usa de forma legítima. Busque lo que lo rodea: API de Docker sin autenticación, contenedores privilegiados que nadie lanzó, tráfico de Telegram que nadie sabe explicar, archivos de personalidad modificados y persistencia que hace reaparecer los contenedores eliminados.
Aviso de la CSA de Singapur · Análisis de ThreatDown
🔎Sección 02: Análisis a fondo
Millones de registros militares expuestos. ¿Cuánto valían para quien se los llevó?
Registros, al peso
El 16 de julio de 2026, el Defense Manpower Data Center (DMDC) encontró una vulnerabilidad en uno de sus sistemas de intercambio de archivos. Aplicó el parche al sistema, lo volvió a poner en línea y envió cartas de notificación. A todas las personas afectadas se les ofreció un año de monitorización crediticia y servicios de restauración de identidad.
Sobre el papel, es una respuesta estándar a una filtración. Corregir el fallo, avisar a las personas implicadas, vigilar el fraude.
Sin embargo, las cartas incluyen un detalle que hace más difícil archivar el asunto. De cada persona afectada se expuso el número de la Seguridad Social y, al menos, otro dato más. Podía ser un nombre, una fecha de nacimiento, datos de contacto, sexo, raza o información de personal militar, incluida la especialidad ocupacional.
Así que la cuestión es si esto fue solo una gran fuga de datos personales o si alguien se llevó una lista útil para identificar y tener como objetivo al personal militar. Todavía no podemos responder a eso. Pero sí podemos examinar qué son estos datos, cómo se han usado datos similares antes y si la respuesta apunta al riesgo correcto.
Lo que sabemos y lo que no
El DMDC no es una oficina menor. Gestiona la verificación de identidad de los titulares de tarjetas de identificación del Departamento de Defensa y guarda registros de más de 60 millones de personas: militares en servicio, veteranos, civiles, contratistas y sus familias. Si alguna vez ha tenido una tarjeta de identificación militar, es casi seguro que su registro está allí.
Esta filtración afectó a más de 3 millones de ellas: unas 2.76 millones vivas y 294,000 fallecidas.
Según el aviso, un «pequeño número de usuarios no autorizados» tuvo acceso al servidor desde octubre de 2025 hasta que se encontró el fallo en julio de 2026, unos nueve meses. La información personal que contenía estaba sin cifrar. Las cartas están fechadas el 18 de septiembre, unas nueve semanas después del descubrimiento.
No sabemos mucho de lo que ocurrió en esos nueve meses. El departamento no ha dicho quiénes eran los intrusos, a cuántos datos accedieron ni si las personas afectadas tienen algo en común. Tampoco ha nombrado el sistema de intercambio de archivos. Dice que actualmente no hay indicios de que la información de nadie se haya utilizado de forma indebida.
Tener acceso no significa que se descargaran todos los registros, y los datos militares no prueban espionaje. Calificar esto de operación de inteligencia iría más allá de las evidencias. Pero tratarlo como un robo de identidad corriente también podría ser precipitarse.
Nueve meses es mucho tiempo sin ser detectado
Para dar contexto, el informe M-Trends 2026 de Mandiant sitúa el tiempo de permanencia mediano global, es decir, el tiempo entre una intrusión y su descubrimiento, en 14 días. A la mayoría de los atacantes se les encuentra, o se dan a conocer con ransomware, en un par de semanas.
Los que permanecen mucho más tiempo suelen ser los que no quieren que se les note. En el mismo informe, los casos de espionaje y las operaciones de trabajadores de TI norcoreanos tuvieron un tiempo de permanencia mediano de 122 días. El acceso al DMDC duró aproximadamente el doble.
Eso no nos dice quién estaba dentro. Muchas intrusiones largas se deben a una monitorización débil, y un intruso discreto no tiene por qué ser un actor estatal. Pero sí descarta la versión ruidosa, de «romper y llevarse lo que se pueda», de esta historia. Nadie publicó los datos ni exigió un rescate. Quien tuvo acceso o no se llevó mucho, o se lo llevó sin llamar la atención durante casi un año.
También dice algo sobre la monitorización. Un servidor con números de la Seguridad Social sin cifrar de millones de personas estuvo abierto a personas ajenas durante nueve meses antes de que alguien lo detectara. Eso es un problema sea quien sea el que estuvo dentro.
Los sistemas de intercambio de archivos siguen apareciendo en filtraciones como esta
No sabemos qué producto usaba el DMDC. Pero los sistemas de intercambio y transferencia de archivos han sido uno de los objetivos más fiables de los últimos cinco años.
Solo el grupo Cl0p fue a por Accellion FTA en 2020 y 2021, GoAnywhere a principios de 2023, MOVEit más tarde ese año y Cleo en 2024. Por sí sola, la campaña de MOVEit afectó a más de 2,600 organizaciones y expuso datos de decenas de millones de personas, muchas de ellas a través de organismos públicos y sus contratistas.
Estos sistemas existen para mover datos en bloque entre organizaciones, por lo que tienden a contener los archivos que quieren los atacantes: exportaciones, informes y hojas de cálculo llenas de registros, a menudo guardados allí más tiempo del previsto. Suelen ser accesibles desde internet para que los socios puedan usarlos. Y a menudo reciben menos atención que los sistemas centrales, porque se ven como fontanería y no como una base de datos.
Para los equipos de seguridad, la conclusión es que un sistema de intercambio de archivos que contiene datos personales debe tratarse como la base de datos de la que proceden los datos, con la misma monitorización y las mismas reglas de retención.
¿Cuánto valían realmente los registros?
Entonces, ¿qué compra realmente un atacante con un conjunto de datos así?
En 2023, investigadores de la Universidad de Duke compraron datos de militares estadounidenses a corredores de datos. Obtuvieron nombres, domicilios, patrimonio neto, religión, problemas de salud e información sobre hijos, por entre 0.12 y 0.32 dólares por persona. Algunos corredores sugirieron que el precio podría bajar a un centavo por registro en grandes volúmenes. Varios hicieron poca o ninguna comprobación de quién compraba.
Así que una lista de personal militar, por sí sola, ya es barata y legal de conseguir. Si alguien estuvo dentro de un sistema del Departamento de Defensa durante nueve meses, no fue una lista de nombres lo que hizo que valiera la pena el esfuerzo.
El valor está en dos cosas que los corredores no pueden vender de forma fiable. La primera es el número de la Seguridad Social, que tenía cada registro de esta filtración y que abre la puerta tanto al fraude como a suplantaciones convincentes. La segunda es la exactitud. Los datos de los corredores se extraen de internet, se infieren y a menudo son erróneos. Un registro del DMDC es el registro del propio Departamento de Defensa sobre quién es usted y a qué se dedica. Cuando indica una especialidad ocupacional, no es una conjetura basada en el perfil de LinkedIn de alguien.
Combine eso con datos de contacto y obtendrá algo cercano a un expediente de objetivos: quién es la persona, qué hace, cómo localizarla y suficientes detalles personales para sonar legítimo cuando se la contacta.
No todos los registros tenían tanto contexto. El departamento dice que los datos variaban según la persona y no ha dicho cuántos registros incluían detalles ocupacionales. Esa cifra importa mucho. Unos pocos cientos de registros con información del puesto son una situación muy distinta de unos pocos millones. Pero incluso un grupo pequeño puede ser valioso si es el grupo adecuado.
Así se usa ese tipo de datos
Dirigirse a militares con acercamientos personales y a medida no es una teoría. Hay casos bien documentados.
En 2018, el ejército israelí descubrió lo que llamó Operation Broken Heart. Operativos de Hamás usaron perfiles falsos en Facebook y WhatsApp para acercarse a soldados y lograr que instalaran aplicaciones de citas y del Mundial. Las aplicaciones eran spyware capaz de tomar fotos, grabar conversaciones, copiar archivos y rastrear la ubicación. Unos 100 soldados las instalaron.
Más cerca de casa, en junio de 2026 el Departamento de Justicia y el FBI desmantelaron 13 sitios web presuntamente gestionados por supuestos agentes chinos. Los sitios se hacían pasar por consultoras y reclutaban a empleados actuales y anteriores del Gobierno y del ejército de EE. UU., en especial a quienes tenían habilitación de seguridad, a través de plataformas de empleo corrientes. Usaban identidades robadas y fotos generadas por IA, e instaban a los reclutados a compartir información «interna» a cambio de dinero.
Ninguno de los dos casos implicó una filtración como esta. Ambos usaron el mismo método: encontrar a las personas en los puestos adecuados y luego contactarlas con un mensaje que encaje con su situación. Lo más difícil de ese método es saber a quién acercarse. Un conjunto de datos que vincula nombres y datos de contacto con ocupaciones militares hace esa parte mucho más fácil.
Imagine ahora un mensaje que parece proceder de una oficina de personal o de un proveedor de prestaciones. Menciona su especialidad y cita los últimos cuatro dígitos de su número de la Seguridad Social «para verificación». No engañaría a todo el mundo. Engañaría a muchas más personas que un correo de phishing genérico, y el remitente no tendría que adivinar quién es usted.
Las 294,000 personas a las que nadie vigila
Una cifra de esta filtración recibe menos atención de la debida: las 294,000 personas fallecidas.
La monitorización crediticia solo sirve si alguien lee las alertas. En el caso de una persona fallecida, a menudo nadie lo hace. Su número de la Seguridad Social puede seguir superando comprobaciones básicas, y el fraude a su nombre puede continuar durante mucho tiempo antes de que alguien lo note. Precisamente por eso las identidades de personas fallecidas son una herramienta popular entre los estafadores, ya sea usadas directamente o mezcladas con datos inventados para construir una nueva identidad «sintética».
Hay un segundo ángulo. El registro de un militar fallecido sigue describiendo una carrera real y familiares reales, lo que lo hace útil para estafas dirigidas a los familiares supervivientes, como falsas ofertas de prestaciones de supervivencia.
Se presume que las cartas sobre estos registros se envían a las familias, que quizá no se den cuenta de que son ellas quienes deben actuar.
Estos datos no caducan
Una tarjeta robada se puede cancelar y una contraseña filtrada se puede cambiar. El historial personal es distinto.
Su fecha de nacimiento no cambiará y su número de la Seguridad Social, casi con seguridad, tampoco. Su servicio militar, su especialidad y sus relaciones laborales siguen siendo relevantes durante años después de que se haya corregido el sistema con fugas. La vulnerabilidad estuvo abierta nueve meses, pero los datos pueden seguir siendo útiles durante décadas.
Nadie tiene por qué usarlos de inmediato, tampoco. Registros como estos pueden cruzarse más adelante con datos de corredores, perfiles públicos y filtraciones anteriores, y cada nueva fuente hace la imagen más nítida. El estudio de Duke muestra lo barata que es esa capa adicional. Un número de la Seguridad Social y una ocupación verificados procedentes de un registro oficial, combinados con el domicilio y los datos familiares de un corredor, valen mucho más que cualquiera de los dos por separado.
Lo que nos enseñó la OPM y dónde termina la comparación
La filtración de 2015 de la Oficina de Gestión de Personal de EE. UU. (OPM) es el punto de referencia obvio. Afectó a unos 21.5 millones de personas y expuso expedientes de investigación para habilitaciones de seguridad, algunos de los datos de personal más sensibles que posee el Gobierno. Un informe del Comité de Supervisión de la Cámara de Representantes afirmó después que puso en peligro la seguridad nacional de EE. UU. «durante más de una generación».
El incidente del DMDC no está a ese nivel. No hay pruebas públicas de que estuvieran implicados expedientes de habilitación ni investigaciones de antecedentes, y nadie ha atribuido la intrusión a un gobierno extranjero, a un grupo criminal ni a una persona de dentro.
La lección útil de la OPM es más simple: la gravedad de una filtración depende de lo que los registros dicen sobre las personas que figuran en ellos. Nombres y números de la Seguridad Social son un tipo de problema. Nombres y números de la Seguridad Social vinculados a funciones militares son otro, y la respuesta debe abordar ambos.
¿Se ajusta la respuesta al riesgo?
Un año de monitorización crediticia puede detectar algún uso indebido financiero. No servirá de mucho contra una campaña de phishing dirigido, una suplantación convincente o alguien que construye discretamente un perfil de un militar.
La Oficina de Rendición de Cuentas del Gobierno de EE. UU. ya ha señalado que los servicios de monitorización de identidad tienen límites reales y que no está claro hasta qué punto reducen el robo de identidad. La monitorización le dice que algo ha ocurrido. No impide que ocurra. Tras las filtraciones de la OPM, a las personas afectadas se les dieron finalmente diez años de cobertura.
Eso no significa que un año sea automáticamente demasiado poco en este caso. Puede que el aviso público no abarque todo lo que hace el departamento, y la respuesta adecuada depende de lo que encuentren los investigadores. Pero lo que podemos ver está construido sobre todo en torno al fraude financiero y es pasivo. Espera a que algo salga mal.
Si recibió una de estas cartas, unos cuantos pasos gratuitos sirven más que la monitorización por sí sola:
Congele su crédito con Equifax, Experian y TransUnion. Es gratis y bloquea la apertura de cuentas nuevas a su nombre. La FTC explica cómo hacerlo.
Obtenga un PIN de protección de identidad del IRS. Impide que otra persona presente una declaración de impuestos con su número de la Seguridad Social.
Desconfíe de cualquier contacto inesperado sobre su servicio, sus prestaciones o sus registros, sobre todo si conoce datos suyos. Cuelgue y vuelva a llamar a un número que haya buscado usted mismo.
Si la carta era sobre un familiar fallecido, avise a las tres agencias de crédito y pídales que marquen el expediente para que no se pueda emitir crédito nuevo.
Los dos últimos son donde la respuesta oficial es más escasa. Las personas cuyos datos del puesto pueden haberse expuesto necesitan advertencias específicas sobre acercamientos que usen su función, no solo un código de monitorización crediticia.
Lo que deberían sacar de esto los equipos de seguridad
Contar registros no basta para juzgar una filtración. Antes de decidir una respuesta, conviene preguntarse:
¿Qué campos aparecieron juntos y qué puede hacer alguien con esa combinación?
¿Cuáles de ellos no pueden cambiarse nunca?
¿Son los datos lo bastante exactos como para hacer más creíble una estafa?
¿Están algunos grupos, como las personas en puestos sensibles o las fallecidas, más expuestos que otros?
¿La protección que se ofrece se corresponde con cómo podrían usarse realmente los datos?
Y antes de que haya una filtración:
Sepa qué sistemas expuestos a internet contienen datos personales, incluidas las herramientas de intercambio y transferencia de archivos en las que nadie piensa como bases de datos.
No deje exportaciones masivas en sistemas compartidos una vez terminada la transferencia.
Vigile el acceso a esos sistemas tan de cerca como el de la base de datos de origen. Nueve meses de acceso sin detectar son un fallo de monitorización tanto como de aplicación de parches.
Lo que aún tenemos que averiguar
Nada confirmado hasta ahora apunta a una campaña de espionaje.
Lo que sí sabemos es que usuarios no autorizados tuvieron acceso a un sistema del Departamento de Defensa durante unos nueve meses, que resultaron afectadas más de 3 millones de personas y que algunos de los registros vinculaban números de la Seguridad Social con puestos militares.
El resto sigue sin saberse. No sabemos quién entró, qué registros miró, qué se llevó ni qué pretendía hacer con ello.
Esto podría resultar ser una fuga muy grande de datos personales, tratada razonablemente como un problema de robo de identidad. O los investigadores podrían descubrir que lo que lo hizo valioso fue el vínculo entre esas identidades y las funciones militares, que es lo único que un corredor de datos no puede venderle por 12 centavos.
El fallo está corregido. Lo más difícil es averiguar qué salió del sistema antes de que alguien lo notara y si un año de monitorización crediticia protege realmente a las personas del riesgo que más importa.
🎣Sección 03: ¿Es phishing?
Ofertas, a su gusto
Un reclutador le escribe sobre un puesto que encaja con su perfil exacto. La empresa es real, el trabajo tiene sentido y el mensaje es pulido y amable. Solo necesita que confirme unos datos y abra la descripción del puesto adjunta.
¿Es phishing?
🎣 Sí
✅ No
🔬Sección 04: Investigación técnica
La página de inicio de sesión lo redirigía. También le enviaba el panel de administración.
Administración, de guarnición
Pida a un servidor de intercambio de archivos su página de administración sin iniciar sesión y le redirigirá a la pantalla de inicio de sesión. Es lo esperable. Pero mire la propia respuesta y verá que el panel de administración completo también está ahí, más de diez mil caracteres, en el cuerpo, bajo la redirección.
Ese fue el punto de partida de una cadena de ejecución remota de código sin autenticación que watchTowr encontró en Progress ShareFile Storage Zone Controller, con los identificadores CVE-2026-2699 y CVE-2026-2701. ShareFile pertenece a Progress, el mismo proveedor que MOVEit. En el momento de la divulgación, unos 30,000 de estos controladores eran accesibles desde internet público.
Se relaciona con el análisis a fondo de este número, que trata de un sistema de intercambio de archivos del Defense Manpower Data Center que dejó entrar a personas ajenas durante nueve meses. Aquí vemos cómo uno de estos servidores puede entregar ese tipo de acceso y por qué el primer error de la cadena es fácil de cometer y fácil de pasar por alto.
Qué es el Storage Zone Controller
ShareFile es un producto SaaS, pero no todo el mundo quiere sus archivos en la nube del proveedor. El Storage Zone Controller es la pieza local que permite a una organización mantener los archivos en su propia infraestructura, un disco local, un recurso compartido SMB, SharePoint, S3 o Azure, mientras sigue usando la interfaz de administración alojada de ShareFile.
Así que, por diseño, es un equipo que:
Está en el perímetro, accesible para que el lado SaaS y los usuarios puedan comunicarse con él.
Tiene acceso directo al lugar donde viven realmente los archivos.
Se ejecuta en IIS. En la rama 5.x es ASP.NET clásico.
Ese es el tipo de sistema que les gusta a los atacantes. Está en internet, cerca de muchos datos y tiende a recibir menos atención que los sistemas que lo rodean.
Primer error: la redirección que no se detuvo
La comprobación de autenticación de la página de configuración de administración hacía lo obvio. Si no estaba autenticado, llamaba a una redirección para enviarle a la página de inicio de sesión.
El problema es cómo la llamaba. En ASP.NET, Response.Redirect(url, false) pone en cola una redirección pero indica al framework que no finalice la solicitud. La cabecera de redirección sale y luego el resto de la página sigue ejecutándose: se renderiza y el HTML se escribe en la misma respuesta.
Es una clase de error conocida y con nombre, Execution After Redirect, abreviada a veces como EAR. El modelo mental del desarrollador es «redirigir, por tanto detenerse». El código envía la redirección y sigue adelante.
Explotarlo es igual de simple. El servidor devuelve un 302 que apunta a la página de inicio de sesión, con todo el panel de administración en el cuerpo. Ignore la redirección, lea el cuerpo y estará viendo una interfaz a la que nunca debería haber llegado sin credenciales.
Eso es CVE-2026-2699, con una calificación de 9.8. No necesita contraseña, ni token, ni cuenta.
El panel de administración era el verdadero premio
Llegar a la página de configuración sin autenticarse ya es grave por sí solo. Lo que lo convirtió en un compromiso total es lo que la página permite cambiar.
La configuración de la zona controla cosas como dónde se encuentra el repositorio de almacenamiento y la frase de contraseña asociada a la zona. Dos detalles convirtieron «puedo ver los ajustes» en «controlo el equipo»:
Cuando un atacante edita estos campos, la interfaz vuelve a rellenar el campo de la frase de contraseña por él. No necesita conocer el secreto existente para que un cambio surta efecto.
La rutina que comprueba una nueva ubicación de almacenamiento solo verifica que el servidor pueda escribir y eliminar un archivo de prueba allí. No restringe dónde está «allí». Como dijo watchTowr, se puede apuntar la ubicación de almacenamiento a cualquier sitio donde la aplicación pueda escribir, y la validación sigue pasando.
Cualquier sitio donde la aplicación pueda escribir incluye la raíz web, y ahí es donde se conectan los dos errores. Si se puede cambiar dónde guarda el servidor los archivos cargados, y este acepta un directorio desde el que también sirve páginas web, lo que se cargue acaba junto a su código.
Segundo error: cargar y luego descomprimir en una carpeta que el servidor ejecuta
El controlador tiene un endpoint de carga, que es exactamente para lo que sirve un equipo de intercambio de archivos. También tiene una opción para descomprimir un archivo cargado al recibirlo.
La extracción conservaba las extensiones de archivo de dentro del archivo comprimido. Así, un archivo comprimido que contenía un archivo .aspx se extraía como archivo .aspx, no como un blob inerte con otro nombre.
Ponga las piezas en orden y el resultado se sigue:
Usar el primer error para llegar al panel de administración sin iniciar sesión.
Apuntar la ubicación de almacenamiento a un directorio bajo la raíz web, lo que la validación permite.
Cargar un archivo comprimido que contenga un archivo ASPX y hacer que el servidor lo extraiga en su sitio.
El archivo extraído queda en un lugar que IIS ejecutará, y solicitarlo.
Un archivo ASPX que el servidor ejecuta al solicitarlo es código del lado del servidor que se ejecuta como la aplicación web. Eso es ejecución remota de código, y eso es CVE-2026-2701, con una calificación de 9.1. La ruta de carga sí implicaba el secreto de firma de la zona, pero para entonces el atacante controlaba la frase de contraseña de la que se deriva el secreto, de modo que esa comprobación no protegía nada.
Describimos cómo funciona la cadena, no publicamos una receta. Lo que importa es el patrón: una función que conserva las extensiones de archivo, apuntada a un directorio que también sirve código.
Por qué esto sigue ocurriendo a los servidores de intercambio de archivos
watchTowr lo expresó bien en su análisis: si se mira de reojo el catálogo de vulnerabilidades explotadas conocidas de CISA, se podría pensar que está formado casi por completo por productos de transferencia de archivos. MOVEit, GoAnywhere, Accellion, Cleo y ahora ShareFile.
Eso no es mala suerte. Viene de aquello para lo que se construyen estos sistemas:
Estos sistemas existen para aceptar archivos del exterior. La carga y la extracción no son casos límite añadidos después. Son el producto.
Tienen que ser accesibles. Los socios y los usuarios remotos necesitan llegar a ellos, así que están en internet por defecto.
Están junto a los datos. Una pasarela con acceso directo a los almacenes de archivos convierte un único RCE en acceso a todo lo que hay detrás.
Se tratan como appliances. Se aplican parches a los sistemas que se consideran importantes. Un equipo de transferencia de archivos a menudo no está en esa lista hasta que aparece en el catálogo KEV.
No sabemos cómo entraron los intrusos en el sistema del DMDC. Esta cadena muestra lo poco que puede hacer falta: una redirección que no detuvo la página y una descompresión que conservó la extensión del archivo.
Qué sacar de ello
Execution After Redirect es una clase de error real, no un detalle de estilo. Una redirección en el código no garantiza que el código se haya detenido. En ASP.NET, Response.Redirect(url, true) finaliza la solicitud; la variante false sigue adelante y necesita un return explícito. Siempre que una comprobación de autenticación termine en una redirección, confirme que nada sensible se renderiza después. Pruébelo ignorando la redirección y leyendo el cuerpo.
«¿Puedo escribir aquí?» no es «¿debo escribir aquí?» Validar una ruta de almacenamiento escribiendo un archivo de prueba comprueba el permiso, no la seguridad. Los destinos de carga y de extracción necesitan una lista de permitidos que nunca pueda resolverse en un directorio servido por web o ejecutable.
No confíe nunca en las extensiones que salen de un archivo comprimido. Una extracción que conserva extensiones elegidas por el atacante en una carpeta accesible es como muchas funciones de carga acaban siendo RCE. Guarde las cargas fuera de la raíz web y sírvalas mediante código que establezca el tipo, en lugar de dejar que el servidor ejecute lo que aterrice allí.
Sepa dónde están sus sistemas de transferencia de archivos. Si ejecuta ShareFile Storage Zone Controller en la rama 5.x, la corrección es la 5.12.4 (o pasar a una versión 6.x compatible). En términos más generales, un equipo de transferencia de archivos que no tiene responsable es el que más probablemente se pase por alto cuando sale un parche.
🛠️Sección 05: Herramienta de la semana
Have I Been Pwned
Filtraciones, a la cuenta
Cuando una gran filtración está en las noticias, la primera pregunta de la mayoría es sencilla: ¿ha aparecido mi dirección de correo electrónico en una filtración de la que nunca oí hablar?
Have I Been Pwned lo responde. Introduzca una dirección y le dice en qué filtraciones conocidas apareció y qué filtró cada una: contraseñas, números de teléfono, fechas de nacimiento, etc.
Eso lo convierte en una comprobación rápida cuando una filtración llega a las noticias, y en un recordatorio de que una contraseña antigua que había olvidado quizá siga protegiendo una cuenta que le importa.
Empiece por su propia dirección. Introduzca un correo electrónico en la página de inicio de HIBP. Si aparece en una filtración, lea qué se expuso. Cambie cualquier contraseña que haya reutilizado en otro lugar, active la autenticación multifactor donde pueda y desconfíe de los mensajes que se apoyan en datos de esa filtración para parecer legítimos. También puede suscribirse a las notificaciones, y HIBP le enviará un correo cuando su dirección aparezca en algo nuevo.
Funciona también para un dominio entero. No es solo una herramienta para consumidores. Una organización puede verificar que controla un dominio y luego vigilar todo el dominio desde el panel de HIBP, viendo qué direcciones de ese dominio han aparecido en filtraciones conocidas. Para un equipo de seguridad, es una forma de detectar quién podría necesitar un restablecimiento de contraseña o una advertencia de phishing durante un incidente. También saca a la luz direcciones antiguas y cuentas olvidadas que siguieron en uso mucho más tiempo del que nadie suponía.
Sepa lo que no le dirá. HIBP solo conoce las filtraciones que han salido a la luz y se han cargado en él, así que no es un mapa completo de todas las exposiciones. Busca direcciones de correo electrónico, no números de la Seguridad Social, por lo que un resultado limpio no significa que sus datos personales estén a salvo. Los registros del DMDC del análisis a fondo, por ejemplo, no aparecerían aquí en absoluto. Y no puede decirle si un mensaje que tiene ahora mismo en la bandeja de entrada forma parte de una campaña de phishing activa. Trate un resultado positivo como un punto de partida: compruebe la cuenta afectada, sustituya las contraseñas reutilizadas y siga desconfiando de todo lo que le cite sus datos.
👏Sección 06: Persona de la semana
Troy Hunt
Guardián de las migas
Esta semana destacamos a Troy Hunt, investigador australiano de seguridad web y creador de Have I Been Pwned.
Hunt lanzó el servicio en 2013 como una forma sencilla de que las personas comprobaran si su dirección de correo electrónico había aparecido en una filtración de datos. Hoy Mozilla Monitor se basa en sus datos, y gobiernos nacionales lo usan para vigilar sus propios dominios.
Su verdadera aportación es hacer que la información sobre filtraciones sea algo sobre lo que las personas puedan actuar. En lugar de un titular que se desvanece en unos días, Have I Been Pwned permite a cualquiera comprobar su propia exposición y recibir un aviso cuando se añaden nuevos incidentes.
Eso importa en historias como el análisis a fondo de este número, donde los datos expuestos siguen siendo útiles mucho después de que se parchee el agujero. Por hacer que la información sobre filtraciones sea más fácil de entender y de aprovechar, Troy Hunt es nuestra Persona de la semana.
📅Sección 07: Evento de la semana
Octopus, en Francia
La Octopus Conference 2026 reúne a responsables políticos, organismos encargados de hacer cumplir la ley, investigadores, grupos de la sociedad civil y profesionales de la tecnología que trabajan en el ámbito del cibercrimen.
La organiza el Consejo de Europa y este año se cumple el 25.º aniversario del Convenio de Budapest sobre la Ciberdelincuencia. La agenda abarca la IA y el cibercrimen, la desinformación, la delincuencia internacional facilitada por medios cibernéticos y las salvaguardas que necesitan los investigadores cuando trabajan con evidencias digitales.
Gran parte de lo que ocurre después de una filtración como la del DMDC no es técnico: quién investiga, a quién se culpa, cómo circulan las evidencias entre fronteras y qué pasa después con los datos de las personas. Esas son las cuestiones en torno a las que se organiza esta conferencia.
📍 Palais de l’Europe, Estrasburgo, Francia 📅 14-16 de octubre de 2026
📚Sección 08: Libro de la semana
Kingpin, al fondo
Este número no deja de preguntar cuánto valen los datos personales robados. Kingpin responde desde el otro lado del trato.
Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground de Kevin Poulsen sigue a Max Butler, que no se limitó a robar números de tarjeta e identidades, sino que se apoderó de los mercados donde se comerciaba con ellos. Poulsen traza cómo un registro robado pasa de un sistema vulnerado a una verdadera economía criminal de foros, vendedores y equipos de cobro, la parte que una notificación de filtración nunca describe.
Mucho antes de ShinyHunters y de los grupos de extorsión de datos de hoy, el modelo era el mismo: entrar, llevarse los datos y dejar que un mercado los convierta en dinero. ShinyHunters dirige hoy una versión del mismo negocio.
Para entender por qué los datos de identidad robados conservan su valor durante años, Kingpin es un buen punto de partida.
😅Sección 09: El meme
Si un servidor de archivos de su organización estuviera expuesto en silencio durante nueve meses, ¿le avisaría algo de su monitorización antes que una carta de notificación?
Eso es todo por este número. Revise sus servidores de archivos, congele su crédito y nos vemos en el próximo número.
The Breach Brief, Equipo de Ostorlab