El mecanismo puede afectar también a cuentas laborales o secundarias, planteando interrogantes sobre la separación de identidades digitales y el control que tienen los usuarios sobre sus datos personales.

Utilizar varias cuentas de Google en un mismo teléfono Android es una práctica habitual. Una cuenta personal, otra para el trabajo y quizás una tercera destinada a actividades que requieren mayor privacidad. Aunque cada una tenga una dirección de correo diferente, esa separación no necesariamente se mantiene en todos los niveles.

Una función de Android denominada Phone number verification (verificación del número de teléfono) permite a Google utilizar el número asociado al dispositivo para verificarlo y vincularlo con las cuentas de Google presentes en él.

La característica plantea una cuestión importante: tener distintas cuentas no significa necesariamente mantener distintas identidades frente al proveedor del servicio.

Cómo funciona la verificación automática del número

Google dispone de mecanismos para verificar números telefónicos en dispositivos Android. Estos pueden utilizar información del dispositivo y de la conexión móvil para confirmar que un determinado número pertenece al usuario.

Según la configuración y las condiciones del servicio, el número verificado puede incorporarse a las cuentas de Google utilizadas en el teléfono.

Esto significa que una persona que utiliza varias cuentas en un mismo dispositivo podría terminar asociando el mismo número telefónico con identidades que pretendía mantener separadas.

El problema no se limita a la cuenta principal.

También puede afectar a cuentas secundarias, profesionales o creadas específicamente para registrarse en determinados servicios sin utilizar la identidad personal habitual.

Es importante distinguir dos situaciones: que Google pueda relacionar internamente diferentes cuentas y que el número telefónico aparezca efectivamente incorporado a la información de cada una. No son necesariamente lo mismo.

Además, la asociación de un número no implica automáticamente que este sea público o visible para otros usuarios.

Cómo desactivar la verificación del número

Los usuarios de Android pueden revisar la configuración de esta función desde los ajustes del dispositivo.

La ruta indicada es:

Configuración → Google → Todos los servicios → Verificación del número de teléfono

Desde allí es posible revisar la opción de verificación automática y desactivarla, cuando esté disponible.

Los nombres y la ubicación exacta de los controles pueden variar según la versión de Android, el fabricante y la configuración del dispositivo.

Sin embargo, hay una advertencia importante: desactivar la verificación automática no significa eliminar los números telefónicos que Google ya haya asociado con las cuentas.

Para revisar esa información, también conviene acceder a la configuración de cada cuenta desde myaccount.google.com y comprobar qué números aparecen registrados en sus datos personales y opciones de seguridad.

Antes de eliminar un número, es recomendable verificar si se utiliza para recuperación de acceso o autenticación en dos pasos.

Una función activada por defecto, sin consentimiento individual para cada cuenta

La controversia ganó visibilidad el 14 de octubre, cuando Android Authority informó sobre usuarios que habían recibido correos electrónicos notificándoles que sus números telefónicos habían sido verificados.

Los mensajes procedían de la dirección noreply-phone-verification@google.com y, según los testimonios, aparecieron sin que los usuarios hubieran solicitado expresamente vincular sus números con esas cuentas.

La publicación también comprobó que la función estaba habilitada en varios dispositivos de su equipo.

Sin embargo, no se trata necesariamente de una característica introducida esta semana. Según la investigación de Android Authority, Google modificó su documentación entre agosto y octubre de 2025 para explicar que la verificación estaba activada por defecto y que los números podían incorporarse a todas las cuentas del dispositivo. Android Authority

La documentación oficial de Google confirma expresamente el comportamiento:

La verificación del número de teléfono está activada de forma predeterminada.

También establece que los números verificados se agregan a todas las cuentas de Google que hayan iniciado sesión en el dispositivo, incluidas las que se incorporen posteriormente. Google Help

Esto no demuestra que Google haya comenzado recientemente a recopilar números telefónicos, pero sí confirma que existe un mecanismo de asociación automática cuyo alcance puede pasar inadvertido para los usuarios.

El problema de fondo: la separación de identidades digitales

El aspecto más delicado de esta función no es necesariamente la recopilación del número telefónico, sino su utilización como elemento común entre diferentes identidades digitales.

Un investigador de seguridad, por ejemplo, puede mantener una cuenta personal, otra profesional y una tercera destinada a investigaciones OSINT.

Cada cuenta puede tener credenciales diferentes, utilizar distintos perfiles de navegación y no compartir información personal visible.

Sin embargo, si todas están configuradas en el mismo teléfono Android, la verificación automática puede terminar vinculándolas con un mismo número.

La separación que el usuario establece entre sus cuentas no necesariamente existe dentro de la infraestructura de Google.

Para periodistas, investigadores, activistas y personas que trabajan con identidades seudónimas, esta diferencia puede tener implicaciones relevantes.

Conviene aclarar que no existe evidencia, a partir de esta función, de que Google exponga públicamente las relaciones entre cuentas o las comparta automáticamente con terceros.

El riesgo identificado es otro: la generación de asociaciones entre identidades que el usuario podría haber decidido mantener independientes.

Seguridad y privacidad: dos objetivos que pueden entrar en conflicto

Google justifica la verificación telefónica por su utilidad para diferentes servicios.

Entre ellos se encuentran la recuperación de cuentas, determinadas funciones de seguridad, la localización de dispositivos perdidos, las comunicaciones RCS y herramientas para compartir archivos.

La compañía también explica que Google y los operadores móviles pueden volver a verificar periódicamente los números asociados al dispositivo. Google Help

Estas funcionalidades tienen beneficios concretos.

El problema aparece cuando un mecanismo pensado para mejorar la seguridad y facilitar el uso de los servicios también establece relaciones entre cuentas sin solicitar una confirmación individual para cada asociación.

Desde la perspectiva de la privacidad, resulta especialmente cuestionable que una función de este alcance esté habilitada por defecto.

La existencia de un control para desactivarla no elimina completamente esa discusión, especialmente cuando el usuario puede desconocer que la asociación ya se produjo.

El control sobre la identidad digital

El caso vuelve a poner sobre la mesa una característica fundamental de los ecosistemas tecnológicos actuales: los usuarios pueden administrar sus cuentas, pero no siempre controlan todas las relaciones que las plataformas establecen entre ellas.

Un número telefónico es mucho más que un dato de contacto. También puede funcionar como identificador persistente, capaz de relacionar servicios, dispositivos y cuentas utilizadas en contextos diferentes.

En este caso, el mecanismo no es una vulnerabilidad ni requiere que un atacante comprometa el dispositivo. Es una funcionalidad documentada del propio sistema.

Para quienes necesitan mantener identidades digitales separadas, la recomendación es revisar tanto la verificación automática del dispositivo como los números registrados individualmente en cada cuenta.

Y, sobre todo, no asumir que utilizar distintas direcciones de correo electrónico garantiza el anonimato o la independencia entre identidades.

La discusión trasciende una opción de configuración de Android: plantea hasta qué punto la privacidad depende de decisiones que los usuarios desconocen y que las plataformas toman por defecto.

Fuentes:

• Google — Cómo administrar la verificación del número de teléfono en Android

• Google — Cómo cambiar el número de teléfono de una cuenta y administrar su uso

• Android Authority — Google is silently linking your phone number across all Google accounts

  ---

  ¡Gracias por leer! Suscríbete gratis para recibir nuevos posts y apoyar nuestro trabajo.

Los responsables aseguran haber comprometido dispositivos de personas cercanas al primer ministro y ofrecen material adicional a cambio de Bitcoin. El episodio se suma a otras filtraciones que afectan al círculo político de Benjamin Netanyahu.

Una nueva filtración de información sensible vuelve a poner bajo presión la seguridad digital del entorno del primer ministro israelí, Benjamin Netanyahu. Un canal de Telegram comenzó a difundir fotografías y videos aparentemente obtenidos de dispositivos pertenecientes a personas cercanas al mandatario, incluyendo material registrado durante desplazamientos oficiales.

Entre los archivos difundidos aparecen imágenes del interior del Wing of Zion, el avión utilizado para los viajes oficiales del gobierno israelí, y grabaciones realizadas a bordo de un helicóptero militar en el que viajaba Netanyahu.

Los responsables de la publicación aseguran haber accedido a teléfonos vinculados con Yossi Shelley, embajador israelí en Emiratos Árabes Unidos y antiguo jefe de la oficina del primer ministro, y con Sara Netanyahu, esposa del mandatario.

El canal también afirma disponer de información adicional y solicita 1.011 dólares en Bitcoin a cambio de un primer paquete de archivos.

Sin embargo, hasta el momento no existe confirmación independiente de que el teléfono de Sara Netanyahu haya sido comprometido ni de que todos los materiales ofrecidos por los responsables sean auténticos.

Fotografías y videos desde el círculo más cercano al poder

El incidente no se limita a la posible exposición de fotografías privadas.

Las imágenes atribuidas a la cuenta de Yossi Shelley incluyen registros de desplazamientos oficiales del primer ministro, entre ellos videos grabados durante un vuelo en helicóptero militar.

Según informó Palestine Chronicle el 12 de octubre, las autoridades de seguridad israelíes investigan la filtración relacionada con Shelley, mientras crece la preocupación por la exposición de información vinculada al entorno del jefe de gobierno.

La publicación de fotografías tomadas dentro de instalaciones y medios de transporte oficiales plantea interrogantes que van más allá de la privacidad de sus protagonistas.

Dependiendo de su contenido, este tipo de material podría revelar detalles sobre procedimientos de seguridad, distribución de espacios, equipamiento o personas que acompañan a funcionarios de alto nivel.

No obstante, la existencia de imágenes tomadas en un avión presidencial o un helicóptero militar no implica automáticamente que se hayan expuesto secretos de Estado. Para determinar su sensibilidad sería necesario analizar el contenido, la fecha y el contexto de cada archivo.

Una sucesión de filtraciones que afecta al gobierno israelí

La publicación de estas imágenes ocurre en medio de otros incidentes de seguridad digital que involucran a colaboradores cercanos a Netanyahu.

El 11 de octubre comenzaron a circular conversaciones privadas de WhatsApp atribuidas a Jonatan Urich, uno de los principales asesores políticos del primer ministro.

Los mensajes incluían presuntos intercambios con periodistas, dirigentes políticos y consultores vinculados a la estrategia comunicacional del gobierno.

El periódico israelí Haaretz informó haber verificado parte del material, mientras que los abogados de Urich reconocieron que había sufrido un ataque informático. También denunciaron que algunas conversaciones difundidas habían sido modificadas.

El incidente adquirió particular relevancia porque semanas antes se había conocido que Urich desarrolló una herramienta de monitoreo de medios utilizando inteligencia artificial.

Según investigaciones periodísticas, el código de esa aplicación quedó expuesto públicamente y contenía información sensible, incluyendo números telefónicos de funcionarios.

Aunque existe una relación temporal entre aquella exposición y la posterior filtración de conversaciones, no está demostrado públicamente que esa vulnerabilidad haya sido el mecanismo utilizado para comprometer su cuenta de WhatsApp.

Tampoco hay evidencia suficiente para establecer que las filtraciones de Urich, Shelley y las presuntas imágenes obtenidas del entorno familiar de Netanyahu sean producto de una misma operación.

¿Hackeo de teléfonos, cuentas comprometidas o filtración interna?

Uno de los aspectos centrales del episodio es que todavía se desconoce cómo se obtuvo el material.

Los responsables aseguran haber comprometido teléfonos, pero esa afirmación no permite establecer que hayan explotado vulnerabilidades de los dispositivos.

Existen diferentes mecanismos capaces de producir filtraciones similares.

El acceso indebido a cuentas de almacenamiento en la nube, el robo de credenciales, el secuestro de sesiones de aplicaciones de mensajería o la extracción de archivos desde dispositivos previamente comprometidos pueden permitir obtener fotografías y conversaciones sin necesidad de vulnerar directamente el sistema operativo de un teléfono.

También debe considerarse la posibilidad de filtraciones provenientes de terceros que recibieron originalmente los archivos.

Por ahora, atribuir el incidente a una herramienta específica de espionaje, a una vulnerabilidad desconocida o a una operación estatal sería especulativo.

La ausencia de detalles técnicos verificables impide determinar el alcance real del compromiso.

Telegram y Bitcoin: la exposición pública como mecanismo de presión

La utilización de Telegram para distribuir material presuntamente robado responde a una dinámica cada vez más visible en las operaciones de filtración.

A diferencia de un ataque orientado exclusivamente al robo silencioso de información, la publicación abierta busca amplificar el impacto del incidente.

Los atacantes pueden utilizar pequeñas muestras de archivos como demostración de acceso, generar atención mediática y aumentar la presión sobre las personas u organizaciones afectadas.

En este caso, el pedido de 1.011 dólares en Bitcoin introduce además un componente económico.

Sin embargo, no está claro si el objetivo principal es obtener dinero, desacreditar políticamente a Netanyahu, demostrar capacidades de acceso o combinar varias de estas motivaciones.

La publicación de archivos auténticos tampoco garantiza que quienes los distribuyen posean el volumen de información que aseguran tener.

El contexto político: filtraciones antes de las elecciones

El momento elegido para divulgar este material resulta especialmente significativo.

Israel tiene previstas elecciones para el 27 de octubre de 2026 y las últimas semanas estuvieron marcadas por controversias relacionadas con la seguridad nacional y el manejo de información dentro del gobierno.

Las filtraciones de comunicaciones de asesores cercanos a Netanyahu ya habían generado repercusiones políticas y mediáticas.

En ese contexto, la difusión de imágenes personales y material vinculado a desplazamientos oficiales puede convertirse en un instrumento de presión política, independientemente de quién haya obtenido originalmente los archivos.

Esto no significa que exista evidencia de una operación coordinada para influir en las elecciones.

La coincidencia temporal merece atención, pero por sí sola no permite establecer una motivación electoral ni identificar responsables.

Cuando la seguridad del Estado depende de dispositivos personales

El episodio expone un problema estructural de la seguridad de altos funcionarios: la frontera entre información personal, comunicaciones políticas y actividades oficiales puede ser extremadamente difusa.

Una fotografía aparentemente cotidiana puede contener información sobre ubicaciones, acompañantes o procedimientos. Una conversación privada puede revelar relaciones políticas o decisiones que nunca estuvieron destinadas a circular públicamente.

La protección de información sensible no depende únicamente de los sistemas informáticos de ministerios, organismos de inteligencia o fuerzas armadas.

También involucra los dispositivos, cuentas y servicios digitales utilizados por funcionarios, asesores, familiares y colaboradores.

En el caso israelí, las sucesivas filtraciones muestran cómo la exposición de información del entorno político puede generar consecuencias que trascienden a los titulares de las cuentas comprometidas.

Por ahora, las principales incógnitas siguen abiertas: quién obtuvo los archivos, mediante qué mecanismo, cuánto material permanece sin publicar y si las distintas filtraciones están relacionadas.

La respuesta a esas preguntas determinará si estamos frente a incidentes independientes de seguridad digital o ante una operación de mayor alcance dirigida contra el entorno del primer ministro israelí.

Su objetivo es permitir que agentes de IA investiguen aplicaciones, comprendan su funcionamiento y reconstruyan funcionalidades sin disponer del código fuente original.

La ingeniería inversa de software ha sido históricamente una disciplina que exige conocimientos especializados, herramientas complejas y numerosas horas de análisis. Comprender cómo funciona una aplicación sin acceder a su código fuente implica examinar archivos ejecutables, interpretar instrucciones de bajo nivel y reconstruir manualmente la lógica de sus componentes.

Un proyecto de código abierto llamado REA (Reverse Engineer Anything) busca transformar ese proceso mediante agentes de inteligencia artificial capaces de interactuar directamente con herramientas de análisis y desarrollar investigaciones guiadas por objetivos.

La herramienta, distribuida bajo licencia MIT, utiliza el protocolo Model Context Protocol (MCP) para conectar asistentes de programación con motores de ingeniería inversa. De esta manera, un investigador puede solicitarle a un agente que examine una aplicación, identifique cómo funciona determinada característica y presente sus conclusiones acompañadas de evidencia técnica.

El proyecto no pretende reemplazar las herramientas tradicionales, sino proporcionar una capa de automatización que permita utilizarlas de manera coordinada.

De analizar código a conversar con una aplicación

La propuesta de REA parte de una idea relativamente sencilla: en lugar de navegar manualmente por miles de funciones, referencias y estructuras de datos, el investigador describe qué quiere comprender y deja que un agente de IA organice buena parte del trabajo.

Por ejemplo, un desarrollador podría solicitar que se investigue cómo funciona el sistema de búsqueda sin conexión de una aplicación de notas.

A partir de esa instrucción, el agente puede identificar los archivos relevantes, examinar sus componentes, localizar funciones relacionadas con la búsqueda y seguir las conexiones entre ellas.

El proceso se organiza en tres etapas principales:

Descompilar: examinar los archivos de la aplicación para recuperar representaciones legibles de código, cadenas de texto, símbolos y otras pistas sobre su funcionamiento.

Comprender: relacionar esos elementos para reconstruir el comportamiento de una funcionalidad, identificando llamadas entre funciones, dependencias y flujos de ejecución.

Recrear: utilizar el conocimiento obtenido para desarrollar una implementación equivalente, adaptada a otro proyecto o entorno tecnológico.

Esta última etapa resulta especialmente interesante porque conecta directamente la investigación técnica con el desarrollo de software.

Sin embargo, existe una distinción fundamental: REA no recupera necesariamente el código fuente original ni garantiza que pueda clonar automáticamente una aplicación. Lo que proporciona es un procedimiento para investigar su comportamiento y producir implementaciones basadas en los resultados del análisis.

Ghidra, Hopper y múltiples tecnologías bajo una misma interfaz

Uno de los principales atractivos del proyecto es su capacidad para integrar diferentes herramientas y técnicas de análisis.

Para investigar ejecutables nativos, REA puede utilizar motores como Ghidra y Hopper, que permiten obtener representaciones de código descompilado, instrucciones ensamblador, referencias cruzadas y relaciones entre funciones.

En lugar de obligar al investigador a trasladar manualmente información entre herramientas, el agente puede solicitar esos datos mediante una interfaz común y utilizarlos para continuar su investigación.

El alcance también se extiende más allá de los ejecutables tradicionales.

Entre las capacidades documentadas se encuentran el análisis de aplicaciones JavaScript y Electron, la inspección de metadatos y código intermedio de .NET, y la observación controlada de determinados comportamientos durante la ejecución.

Esto permite abordar aplicaciones compuestas por múltiples capas tecnológicas, donde una funcionalidad aparentemente sencilla puede involucrar código JavaScript, comunicaciones entre procesos y bibliotecas nativas.

La documentación también contempla distintos flujos de análisis de artefactos, aunque su disponibilidad depende de la plataforma, las herramientas instaladas y el grado de madurez de cada integración.

Por lo tanto, el nombre Reverse Engineer Anything debe entenderse como la aspiración del proyecto, no como una garantía de compatibilidad universal.

Resultados verificables, no solamente respuestas de una IA

Uno de los aspectos más relevantes de REA es su enfoque en la trazabilidad de los resultados.

Los modelos de lenguaje pueden generar explicaciones técnicamente convincentes que, sin embargo, contienen errores o interpretaciones sin fundamento.

En ingeniería inversa, este problema es particularmente delicado. Una interpretación incorrecta del comportamiento de una función puede comprometer toda una investigación.

REA intenta reducir ese riesgo mediante un modelo que distingue entre los datos obtenidos de las herramientas de análisis y las conclusiones elaboradas por el agente.

Los resultados pueden incluir referencias a funciones, instrucciones, relaciones entre componentes y otras evidencias que permiten revisar las conclusiones.

El proyecto presenta demostraciones de este enfoque. En una de ellas, relacionada con el videojuego DX-Ball, se reconstruyó una función de cálculo de posición del sonido y se verificó su comportamiento mediante 3.205 casos de prueba sobre la implementación original en x86.

Según la documentación publicada, la reconstrucción también reprodujo los 63 bytes de la función compilada.

Otra demostración examina el funcionamiento del portapapeles de Notion, siguiendo las interacciones entre los diferentes componentes de su arquitectura Electron.

Estos ejemplos muestran cómo un agente puede pasar de identificar una funcionalidad a reconstruirla y contrastar los resultados mediante pruebas.

No obstante, se trata de demostraciones específicas y no constituyen evidencia de que la herramienta pueda reproducir con la misma precisión cualquier aplicación.

¿Qué cambia para los investigadores de seguridad?

La incorporación de agentes de IA a los procesos de ingeniería inversa abre posibilidades para distintas actividades de ciberseguridad.

En el análisis de malware, por ejemplo, un investigador podría utilizar estas capacidades para localizar funciones relacionadas con comunicaciones de red, persistencia o manipulación de archivos.

En auditorías de seguridad, podrían facilitar la comprensión de componentes propietarios cuando no existe acceso al código fuente.

También podrían resultar útiles para estudiar protocolos no documentados, investigar vulnerabilidades en aplicaciones o comprender dependencias tecnológicas utilizadas por sistemas heredados.

El principal cambio no consiste en eliminar la necesidad de conocimientos técnicos, sino en reducir el trabajo manual necesario para reunir, relacionar e interpretar evidencias.

Esto podría permitir que investigadores experimentados dediquen más tiempo a formular hipótesis y validar hallazgos, mientras los agentes realizan parte de las tareas repetitivas.

Al mismo tiempo, estas capacidades podrían reducir las barreras de entrada para personas con menos experiencia en ingeniería inversa.

Esa accesibilidad tiene una contrapartida: las mismas herramientas que facilitan las investigaciones legítimas también pueden utilizarse para estudiar mecanismos de protección, descubrir debilidades o comprender aplicaciones con fines maliciosos.

Como sucede con otras tecnologías de doble uso, el impacto depende tanto de las capacidades disponibles como de quién las utiliza y con qué objetivos.

El desafío de la privacidad y la ejecución segura

Aunque REA está diseñado para realizar el análisis en el equipo local, esto no significa necesariamente que toda la información permanezca dentro de ese entorno.

La herramienta no requiere enviar el ejecutable completo a un servicio de análisis remoto. Sin embargo, cuando se utiliza un agente conectado a un modelo de IA alojado por un tercero, los resultados de la investigación pueden transmitirse como parte del contexto necesario para procesar las solicitudes.

Esta distinción es importante cuando se trabaja con aplicaciones propietarias, software confidencial o componentes de infraestructura crítica.

También existen riesgos asociados con el análisis dinámico.

A diferencia de la inspección estática, que examina archivos sin ejecutarlos, determinadas operaciones de observación requieren iniciar procesos o interactuar con aplicaciones.

La documentación del proyecto advierte que varios de estos mecanismos operan con los permisos del usuario y no constituyen entornos de aislamiento de seguridad.

Por esa razón, analizar software potencialmente malicioso exige mantener las precauciones habituales, incluyendo el uso de entornos controlados y mecanismos de aislamiento adecuados.

La automatización mediante IA no elimina los riesgos de ejecutar código desconocido.

Una nueva etapa para la ingeniería inversa

REA representa una tendencia que comienza a consolidarse en el desarrollo de herramientas de seguridad: utilizar agentes de inteligencia artificial como intermediarios entre el investigador y los instrumentos técnicos especializados.

En este modelo, la IA no necesita reemplazar al descompilador, al depurador ni al analista. Su función consiste en coordinar herramientas, interpretar resultados y proponer los siguientes pasos de una investigación.

El enfoque también plantea una cuestión relacionada con la independencia tecnológica.

Facilitar el análisis de software sin disponer del código fuente puede contribuir a comprender mejor componentes propietarios, documentar sistemas heredados y reducir ciertas dependencias respecto de sus fabricantes.

Sin embargo, cuando ese análisis depende de modelos de inteligencia artificial externos, aparece una nueva dependencia tecnológica que debe considerarse, especialmente en organizaciones que manejan información sensible.

La verdadera utilidad de herramientas como REA dependerá de su capacidad para producir resultados reproducibles, mantener límites de seguridad claros y permitir que los investigadores conserven el control sobre las decisiones técnicas.

La ingeniería inversa no deja de requerir conocimientos especializados. Lo que empieza a cambiar es cuánto trabajo necesita realizar manualmente una persona para comprender qué ocurre dentro de un programa.

Un nuevo informe de Derechos Digitales busca poner esos incidentes en perspectiva regional.

La seguridad digital en América Latina ya no puede entenderse únicamente en términos de malware, ransomware o vulnerabilidades técnicas. Detrás de muchos incidentes existe otra dimensión: quién controla la información, quién puede vigilar a quién y qué ocurre cuando la tecnología utilizada para proteger a una sociedad también puede convertirse en una herramienta de control.

Esa es una de las lecturas que deja “En la Mira 2: Un panorama de las amenazas digitales en América Latina”, la segunda edición del informe publicado por Derechos Digitales el 30 de septiembre.

El trabajo analiza más de 100 casos ocurridos entre junio de 2024 y mayo de 2025 y documenta fenómenos que van desde vigilancia y censura hasta filtraciones masivas de información, desinformación electoral, violencia de género facilitada por tecnologías, explotación de datos biométricos y cortes deliberados de internet.

Un problema que excede a la ciberseguridad tradicional

El informe fue elaborado en el marco del Observatorio Latinoamericano de Amenazas Digitales (OLAD), una alianza integrada por 14 organizaciones de América Latina dedicadas a la defensa de los derechos humanos en el entorno digital.

La perspectiva importa.

Una filtración de datos puede ser analizada como un incidente de seguridad. Pero cuando esa información pertenece a activistas, periodistas o grupos vulnerables, las consecuencias pueden ir mucho más allá de la confidencialidad de una base de datos.

Lo mismo sucede con tecnologías como el reconocimiento facial o los sistemas biométricos. Desde una mirada puramente técnica son herramientas de identificación. Desde una perspectiva de derechos digitales aparece otra pregunta: quién puede utilizarlas, sobre qué población, con qué controles y para qué propósito.

Ese cambio de enfoque permite observar una característica cada vez más evidente del ecosistema digital latinoamericano: las fronteras entre ciberseguridad, vigilancia, privacidad, libertad de expresión y política son cada vez menos claras.

Vigilancia y censura

Entre los fenómenos documentados por el informe se encuentra el avance de distintas formas de vigilancia y censura en la región.

El problema no necesariamente requiere sofisticadas plataformas de espionaje.

La recopilación sistemática de información disponible públicamente, el monitoreo de redes sociales, el perfilamiento de personas o el cruce de diferentes bases de datos pueden construir imágenes extremadamente detalladas sobre individuos y organizaciones.

Derechos Digitales ha advertido además sobre el denominado ciberpatrullaje, especialmente cuando el monitoreo estatal de internet se realiza bajo criterios poco transparentes. La organización señala que estas prácticas pueden generar efectos sobre la privacidad y la libertad de expresión e incluso producir autocensura entre quienes saben —o sospechan— que sus actividades están siendo observadas.

La cuestión deja entonces de ser solamente qué información está disponible en internet.

También importa quién tiene capacidad para recopilarla a escala, correlacionarla y convertirla en inteligencia.

Los datos biométricos agregan otra capa de riesgo

Otro de los puntos destacados es la explotación de información biométrica.

Contraseñas y credenciales pueden cambiarse después de una filtración. Un rostro o una huella digital, no.

Por eso, la expansión de sistemas de reconocimiento facial, bases biométricas y mecanismos automatizados de identificación plantea un desafío particular para América Latina: cuanto más centralizada y reutilizable sea esa información, mayor es el impacto potencial de un abuso, una filtración o un acceso indebido.

Además, el riesgo no depende exclusivamente de que los sistemas sean vulnerados.

Un sistema puede funcionar exactamente como fue diseñado y aun así plantear problemas si permite una vigilancia desproporcionada, carece de controles independientes o termina utilizándose para objetivos distintos de aquellos que justificaron originalmente su implementación.

Desinformación y elecciones

El informe también incluye casos de desinformación vinculados a procesos electorales.

Esto amplía todavía más el concepto tradicional de amenaza digital.

Una operación destinada a alterar una conversación pública no necesita comprometer servidores gubernamentales ni explotar una vulnerabilidad zero-day. Puede apoyarse en redes sociales, cuentas coordinadas, contenido manipulado y mecanismos de amplificación capaces de modificar la percepción de determinados acontecimientos.

En ese escenario, proteger una elección no significa solamente asegurar las máquinas, sistemas o bases de datos utilizadas durante el proceso electoral.

También implica entender cómo la infraestructura informativa sobre la que una sociedad construye su percepción de la realidad puede ser manipulada.

Cuando apagar internet también es una herramienta de control

Entre los fenómenos registrados aparecen además los cortes de internet.

La disponibilidad suele pensarse como uno de los pilares clásicos de la seguridad informática. Pero cuando la interrupción de conectividad es deliberada, deja de ser simplemente un problema técnico.

Controlar la infraestructura de comunicaciones permite también controlar quién puede comunicarse, acceder a información, documentar acontecimientos o publicar lo que está ocurriendo.

Internet se convierte así en infraestructura crítica no solamente por su importancia económica, sino por su papel político y social.

América Latina necesita mirar sus amenazas con sus propios ojos

Quizás uno de los mayores valores de trabajos como En la Mira sea precisamente su perspectiva regional.

Buena parte del discurso global sobre ciberseguridad está construido alrededor de las prioridades de Estados Unidos, Europa, China o Rusia. Vulnerabilidades, espionaje estatal, ransomware e infraestructura crítica dominan —con razón— buena parte de esa conversación.

Pero América Latina tiene además sus propias tensiones.

Instituciones con capacidades muy diferentes, marcos regulatorios desiguales, grandes bases de datos estatales, creciente incorporación de biometría, dependencia de plataformas tecnológicas extranjeras y sociedades donde periodistas, activistas y organizaciones civiles pueden encontrarse particularmente expuestos.

Eso obliga a ampliar la pregunta.

No alcanza con preguntarnos si nuestros sistemas son seguros.

También tenemos que preguntarnos quién controla esos sistemas, qué información concentran, quién puede acceder a ella y qué mecanismos existen para evitar que una herramienta tecnológica termine convirtiéndose en una herramienta de vigilancia o abuso de poder.

En una región cada vez más digitalizada, la seguridad informática y los derechos digitales dejaron hace tiempo de ser conversaciones separadas.

Son partes del mismo problema.

Parte de esa información habría terminado en un sistema construido sobre tecnología de Palantir y fue utilizada para búsquedas de reconocimiento facial. El gobierno sostiene que fueron incidentes aislados y niega mantener una base de datos de manifestantes.

Una fotografía tomada durante una protesta puede parecer un dato aislado. Una matrícula, otro. Una dirección, un número de teléfono o una imagen obtenida de una licencia de conducir, también.

El problema cambia cuando todos esos elementos terminan conectados dentro de los sistemas de inteligencia de un Estado.

Eso es precisamente lo que se discute en Hilton v. Noem, una demanda presentada ante un tribunal federal de Maine contra el Departamento de Seguridad Nacional de Estados Unidos (DHS) y varias de sus agencias. Documentos judiciales recientemente hechos públicos aportan nuevos detalles sobre cómo agentes federales recopilaron y almacenaron información sobre personas que observaban y registraban operativos del Servicio de Inmigración y Control de Aduanas (ICE).

Entre los datos recopilados aparecen fotografías, matrículas de vehículos y otra información personal. Al menos parte de ella fue incorporada a Investigative Case Management (ICM), el sistema utilizado por Homeland Security Investigations (HSI) para administrar investigaciones y construido por Palantir sobre su plataforma Gotham.

El caso plantea una cuestión que va mucho más allá de Palantir o de una operación concreta de ICE: qué ocurre cuando la infraestructura tecnológica creada para investigar amenazas permite convertir rápidamente una actividad pública y potencialmente protegida por la Constitución en un perfil dentro de un sistema policial.

De observar un operativo a aparecer en ICM

La demanda se centra, entre otros episodios, en lo ocurrido durante Operation Catch of the Day, un operativo de inmigración realizado en Maine en enero de 2026.

Según los documentos judiciales citados por WIRED, un agente identificado como “J.C.” creó registros en ICM sobre al menos seis observadores; el gobierno sitúa el número en ocho. Dos personas fotografiadas en el estacionamiento de un Home Depot fueron etiquetadas con la descripción “Threat to Law Enforcement, Professional Protestor”.

Las fotografías también fueron enviadas a un agente de Customs and Border Protection (CBP) para realizar búsquedas mediante reconocimiento facial utilizando una aplicación denominada Mobile Query.

En otro episodio, después de que Polyxenia Pantos observara y fotografiara un arresto en Portland, el agente consultó la matrícula del automóvil que estaba utilizando. El vehículo pertenecía a su pareja, Carlyn Williams.

A partir de allí, según la documentación presentada ante el tribunal, el agente obtuvo mediante Accurint —una plataforma de LexisNexis utilizada por fuerzas de seguridad— información que incluía dirección, números telefónicos y personas asociadas al domicilio. Posteriormente habría distribuido una fotografía de Williams entre otros agentes tratando de identificar si era la persona que había observado el operativo.

La investigación no quedó limitada a identificar personas.

Los demandantes sostienen que agentes también pasaron frente a las viviendas de algunos observadores y que, en determinados casos, las consecuencias se trasladaron a controles fronterizos posteriores.

La llamada sobre una “lista de terrorismo doméstico”

Uno de los episodios más sensibles ocurrió horas después del operativo.

Según Williams, un agente que se identificó como perteneciente al DHS la llamó por teléfono y le indicó que debía recomendar a su pareja que no volviera a realizar ese tipo de actividades porque quienes lo hacían podían terminar incluidos en una “domestic terrorism watchlist”.

La versión es disputada.

El agente declaró posteriormente que había advertido sobre una posible detención si la conducta continuaba, mientras que abogados del gobierno sostuvieron que negó haber mencionado una lista de terrorismo doméstico.

La diferencia es importante porque la demanda sostiene que esas acciones produjeron un efecto inhibidor sobre actividades amparadas por la Primera Enmienda. De acuerdo con los demandantes, algunas de las personas involucradas dejaron posteriormente de observar operaciones de ICE.

Palantir es la infraestructura, no necesariamente quien tomó la decisión

La participación de Palantir requiere una distinción importante.

Los documentos no sostienen que Palantir haya decidido vigilar a esas personas. Lo que aparece es su tecnología como infraestructura utilizada por el gobierno.

ICE adjudicó a Palantir en 2014 el desarrollo de Investigative Case Management, basado en Gotham y adaptado a las necesidades de la agencia. En 2022 volvió a contratar a la compañía para mantener el sistema mediante un acuerdo de cinco años inicialmente valorado en hasta unos 96 millones de dólares. En 2025 el contrato fue ampliado en casi 30 millones para trabajar en una nueva plataforma denominada ImmigrationOS.

ICM permite a los investigadores de HSI crear y administrar expedientes. Pero su relevancia en este caso está también en cómo la información puede circular entre sistemas.

Según una evaluación de privacidad del DHS citada en los documentos, determinados registros creados en ICM se comparten automáticamente con TECS, el sistema utilizado por CBP para controles y evaluación de viajeros en las fronteras.

Un registro creado durante un encuentro en una calle de Maine, por lo tanto, potencialmente puede tener efectos mucho después y en otro contexto.

Ahí aparece una característica central de las modernas arquitecturas de vigilancia: el poder no está solamente en recolectar información, sino en conectarla.

El gobierno niega mantener una base de manifestantes

El DHS rechaza las acusaciones y calificó la demanda como carente de mérito.

El gobierno sostiene que no existe una base de datos de “terroristas domésticos” como la descrita por los demandantes y argumenta que los hechos denunciados fueron incidentes aislados y contrarios a las políticas del propio departamento. También afirma que el agente creó registros sobre personas que consideraba potenciales amenazas para las fuerzas de seguridad y que no intentó incorporarlas formalmente a una lista de vigilancia terrorista.

ICE también había afirmado anteriormente que no mantiene una base de datos específica de ciudadanos estadounidenses por protestar contra sus actividades.

El tribunal todavía no ha resuelto el fondo del caso.

En marzo, el juez John A. Woodcock Jr. rechazó una solicitud de orden de restricción temporal presentada por los demandantes, al considerar que la evidencia disponible en ese momento no justificaba esa medida de emergencia y que parte de lo solicitado era demasiado amplio. Sin embargo, el propio fallo señaló que la demanda plantea “serias cuestiones constitucionales” que debían analizarse mediante el procedimiento judicial ordinario.

Cuando una base de datos cambia la escala de la vigilancia

El caso resulta especialmente relevante desde la perspectiva tecnológica porque muestra cómo herramientas que individualmente pueden parecer rutinarias adquieren otra dimensión cuando funcionan como un ecosistema.

Una cámara permite obtener un rostro.

Una matrícula permite identificar un vehículo.

Una base comercial puede relacionarlo con un domicilio y un teléfono.

Un sistema de reconocimiento facial puede intentar identificar a una persona.

Una plataforma de inteligencia puede consolidar esos elementos en un expediente.

Y la interoperabilidad entre sistemas puede hacer que ese expediente reaparezca posteriormente durante un control fronterizo u otra interacción con el Estado.

No hace falta imaginar una gigantesca base de datos denominada literalmente “manifestantes” para que exista capacidad de vigilancia sobre manifestantes. La cuestión técnica y jurídica relevante es qué información se recopila, bajo qué criterio, cómo se etiqueta, cuánto tiempo permanece almacenada, con qué otros sistemas se comparte y qué decisiones pueden tomarse a partir de ella.

Eso es lo que Hilton v. Noem está poniendo bajo la lupa.

Y también explica por qué el debate sobre Palantir y otras plataformas de inteligencia gubernamental no puede reducirse simplemente a qué datos almacenan. En sistemas capaces de cruzar identidades, vehículos, fotografías, ubicaciones y registros provenientes de múltiples fuentes, la arquitectura de datos determina buena parte del poder de vigilancia disponible.

El tribunal todavía deberá decidir si en este caso ese poder cruzó una línea constitucional. Los documentos conocidos hasta ahora, sin embargo, permiten observar algo que normalmente permanece invisible: cómo una persona que mira y fotografía un operativo desde un espacio público puede terminar convertida, unas horas después, en un registro dentro de la infraestructura digital de seguridad del Estado.

El ataque podía superar los principales mecanismos de autenticación de correo y expuso, además, una llamativa historia de correcciones incompletas que se extendió durante más de un año.

Un correo llega a la bandeja de entrada. El remitente parece ser tim.cook@icloud.com. SPF pasa. DKIM pasa. DMARC también.

Todo parece indicar que el mensaje salió legítimamente de la infraestructura de Apple.

Pero no.

Investigadores de SEC Consult demostraron que era posible utilizar los propios servidores de iCloud para enviar correos aparentando provenir de cualquier dirección @icloud.com, incluso cuentas que no pertenecían al atacante. El problema no estaba en romper DKIM ni en falsificar desde afuera los servidores de Apple: estaba en cómo distintas partes de la propia infraestructura interpretaban un mismo mensaje.

La investigación, publicada el 1 de octubre de 2026 por Timo Longin, documenta dos vulnerabilidades de email spoofing basadas en discrepancias de parsing dentro de la infraestructura SMTP de iCloud.

Cuando dos servidores entienden cosas diferentes

El ataque parte de una idea conocida en seguridad: si dos componentes interpretan los mismos datos de manera diferente, el espacio entre ambas interpretaciones puede convertirse en una vulnerabilidad.

Es el mismo principio detrás de técnicas como HTTP Request Smuggling y, en el mundo del correo electrónico, SMTP Smuggling.

Normalmente, Apple no permite autenticarse en iCloud con una cuenta y luego enviar un mensaje declarando otra dirección @icloud.com como remitente. Si alguien autenticado como usuario@icloud.com intenta enviar directamente como admin@icloud.com, el servidor rechaza el mensaje.

El problema descubierto por SEC Consult estaba en lo que ocurría después.

Los investigadores encontraron diferencias en la forma en que distintas etapas de la infraestructura de iCloud procesaban el encabezado From:. Manipulando caracteres de retorno de carro (CR), podían conseguir que un componente validara como legítima la dirección del atacante mientras otro terminara interpretando como remitente una dirección diferente.

En otras palabras:

Apple verificaba una identidad, pero terminaba enviando otra.

El correo podía parecer completamente legítimo

El detalle que vuelve especialmente interesante al ataque es que no se trataba del típico spoofing donde DMARC termina delatando la falsificación.

Los mensajes manipulados podían superar SPF, DKIM y DMARC.

SPF comprueba, simplificando, si el servidor que envió el correo está autorizado por el dominio. En este caso el mensaje realmente estaba saliendo de infraestructura de Apple.

DKIM agrega una firma criptográfica al correo. Pero la firma se generaba después de que el mensaje hubiera atravesado el procesamiento vulnerable, por lo que Apple terminaba firmando criptográficamente el mensaje ya manipulado.

Y DMARC utiliza, entre otras cosas, los resultados y la alineación de SPF y DKIM.

El resultado era especialmente convincente: el receptor podía observar un mensaje proveniente de infraestructura legítima de iCloud, firmado por Apple y con las verificaciones de autenticación aprobadas. SEC Consult mostró como prueba de concepto un correo aparentemente enviado desde tim.cook@icloud.com.

Apple corrigió el problema. Pero apareció otro camino

La historia no terminó con el primer reporte.

SEC Consult informó inicialmente la vulnerabilidad a Apple el 21 de mayo de 2024. Meses después, los investigadores comprobaron que el método original ya no funcionaba y Apple dio el reporte por remediado en noviembre de ese año. La compañía otorgó además una recompensa de 15.000 dólares a través de su programa de bug bounty.

Pero en diciembre los investigadores encontraron otra forma de explotar discrepancias similares.

Esta vez utilizaron el funcionamiento de dot-stuffing, un mecanismo histórico de SMTP que agrega y elimina puntos al comienzo de determinadas líneas durante la transmisión de mensajes.

Otra vez, dos componentes interpretaban el mensaje de manera diferente.

Y otra vez era posible terminar enviando correo como una dirección @icloud.com arbitraria.

Una corrección bastante peculiar

La cronología publicada por SEC Consult contiene uno de los episodios más llamativos de toda la investigación.

El 11 de diciembre de 2024, los investigadores comprobaron que una de las correcciones implementadas no solucionaba realmente el problema de parsing: simplemente bloqueaba la cadena utilizada en la prueba de concepto.

Concretamente, según SEC Consult, se había colocado en una lista negra la palabra “admin”.

El resultado era que el PoC utilizado originalmente dejaba de funcionar, pero otras direcciones seguían siendo falsificables. Los investigadores respondieron enviando una nueva prueba utilizando security@icloud.com.

La vulnerabilidad continuó atravesando distintas rondas de correcciones y bypasses durante 2025. En junio de ese año, SEC Consult volvió a confirmar que el ataque todavía podía reproducirse.

Recién en noviembre Apple desplegó nuevos cambios y, en diciembre de 2025, los investigadores confirmaron que los métodos conocidos habían quedado finalmente mitigados. La investigación técnica completa se hizo pública casi un año después, el 1 de octubre de 2026.

El problema no era SPF, DKIM ni DMARC

El caso deja una enseñanza técnica importante porque sería fácil concluir que SPF, DKIM y DMARC “fallaron”.

No fue exactamente eso.

Los mecanismos hicieron lo que debían hacer sobre la información que recibieron.

El correo realmente provenía de infraestructura autorizada de Apple. Y Apple realmente había firmado el mensaje.

La vulnerabilidad estaba antes: en el sistema que decidió qué identidad estaba autorizada a enviar ese correo.

Es una distinción importante.

Los controles criptográficos pueden garantizar que determinado sistema produjo o autorizó determinada información. Pero si ese sistema fue engañado antes de realizar la firma, la criptografía puede terminar certificando algo incorrecto con absoluta legitimidad matemática.

La identidad del remitente sigue siendo una capa frágil

SEC Consult señala además que todavía podían quedar rastros útiles para detectar estos mensajes. Por ejemplo, el Return-Path y algunos encabezados de autenticación podían revelar la cuenta de iCloud utilizada realmente por el atacante, permitiendo construir heurísticas adicionales de detección.

Pero eso no elimina el problema de fondo.

El correo electrónico arrastra décadas de compatibilidad, extensiones y comportamientos implementados de maneras ligeramente diferentes. Y cada diferencia de interpretación entre componentes crea una posible superficie para ataques de smuggling.

Este caso lo demuestra de una manera particularmente clara: no hizo falta quebrar una firma criptográfica ni comprometer las claves de Apple.

Alcanzó con conseguir que dos partes de su infraestructura no estuvieran de acuerdo sobre qué decía exactamente el mismo correo.

Y durante un tiempo, esa pequeña diferencia fue suficiente para que cualquiera pudiera parecer Tim Cook.

El informe también aporta nuevos elementos sobre los ataques que comprometieron los teléfonos de dos ministros españoles en 2021.

Durante años, una de las grandes preguntas alrededor de Pegasus no fue qué podía hacer el spyware, sino quién estaba detrás de determinados ataques.

Una nueva investigación de Amnesty International intenta cerrar parte de ese círculo.

Publicada el 1 de octubre de 2026 bajo el título “We start with the verdict: Inside Morocco’s Surveillance Machine”, la investigación reconstruye lo que la organización describe como un amplio ecosistema de vigilancia utilizado por las autoridades marroquíes, particularmente por la Direction Générale de la Surveillance du Territoire (DGST), el servicio de inteligencia interior del país.

El trabajo combina testimonios de personas que trabajaron dentro de los servicios de inteligencia, datos filtrados, documentación interna de proveedores de tecnología de vigilancia, análisis forense e investigaciones periodísticas.

El resultado va bastante más allá de Pegasus.

Según Amnesty, Marruecos habría construido durante años una infraestructura capaz de combinar spyware comercial, interceptación de telecomunicaciones, herramientas forenses, seguimiento físico, cámaras, IMSI catchers, infiltración de dispositivos e incluso teléfonos previamente comprometidos antes de ser vendidos a determinados objetivos.

Pero entre todos esos elementos aparece uno particularmente sensible: España.

Los teléfonos de dos ministros españoles

En 2022, el gobierno español reveló que los teléfonos de la entonces ministra de Defensa, Margarita Robles, y del ministro del Interior, Fernando Grande-Marlaska, habían sido infectados con Pegasus.

Los ataques se habían producido en 2021, en medio de una fuerte crisis diplomática entre España y Marruecos.

La cuestión que permanecía abierta era la atribución.

La nueva investigación de Amnesty sostiene que documentación judicial española permite vincular los ataques contra ambos ministros con infraestructura asociada a un mismo operador de Pegasus que también habría atacado a objetivos relacionados con Marruecos.

Según la investigación, una orden judicial española identifica una cuenta de Apple utilizada para ejecutar ataques zero-click mediante iMessage contra los dispositivos de Robles y Grande-Marlaska.

Ese mismo identificador habría sido utilizado también contra un periodista marroquí exiliado y contra un activista francés favorable a la causa saharaui.

La relevancia técnica de esa coincidencia está en cómo funcionaba la infraestructura de Pegasus.

Una infraestructura distinta para cada cliente

Documentación interna de NSO Group analizada por Amnesty aporta nuevos detalles sobre la arquitectura operativa del spyware.

Según esos documentos, la empresa registraba infraestructura de ataque específica para cada cliente. Esto permite utilizar determinados componentes técnicos como una forma de agrupar operaciones y vincular ataques aparentemente independientes con un mismo operador.

Amnesty sostiene que este conocimiento permite reforzar metodologías utilizadas durante años por investigadores de spyware para identificar clusters de actividad.

En el caso marroquí, la organización afirma que esa infraestructura permite conectar ataques contra personas dentro de Marruecos con operaciones contra periodistas, activistas, diplomáticos y funcionarios en el extranjero.

Esto no convierte automáticamente cada infección en una prueba judicial de quién dio una orden concreta, pero sí aporta una pieza técnica importante para reconstruir quién operaba determinada infraestructura.

La investigación concluye que las autoridades marroquíes utilizaron Pegasus entre 2017 y 2021, y señala que su utilización podría haberse extendido posteriormente. Marruecos ha negado anteriormente acusaciones relacionadas con el uso de Pegasus; Amnesty afirma que contactó a las autoridades marroquíes antes de publicar este nuevo informe y no recibió respuesta.

Pegasus no empezó apuntando a terroristas

Otro de los hallazgos relevantes del informe está en los primeros meses de utilización del sistema.

Amnesty analizó 103 personas cuyos números habrían sido introducidos en el sistema operado por la DGST entre septiembre y diciembre de 2017.

De ellas, 65 eran defensores de derechos humanos, periodistas, abogados o académicos. Solo 25 eran políticos o funcionarios.

Para Amnesty, estos datos muestran que la sociedad civil no apareció accidentalmente entre los objetivos del sistema: representó aproximadamente dos tercios de los blancos identificados durante los primeros meses de operación.

Esto resulta especialmente significativo frente a la posición histórica de NSO Group, que sostiene que Pegasus se licencia para investigaciones relacionadas con terrorismo y delitos graves.

La investigación describe además diferentes mecanismos utilizados para comprometer dispositivos: ataques mediante enlaces, exploits zero-click y técnicas de network injection capaces de aprovechar la infraestructura de telecomunicaciones para introducir el spyware.

Casi 13.000 números bajo la lupa

El alcance potencial sería mucho mayor.

De acuerdo con la documentación analizada por Amnesty, cerca de 13.000 números telefónicos fueron seleccionados como posibles objetivos dentro del sistema atribuido a la DGST.

Seleccionar un número no significa necesariamente que el dispositivo haya sido comprometido. Esa distinción es importante: una lista de objetivos potenciales no constituye por sí sola evidencia forense de una infección.

Pero el volumen permite dimensionar la escala de la infraestructura.

Y Pegasus era solo una parte.

El informe identifica contratos o utilización de tecnologías vinculadas con empresas como Hacking Team, Verint, Amesys y Cellebrite, además de IMSI catchers, sistemas de interceptación de comunicaciones y herramientas capaces de extraer información de dispositivos bajo custodia física de las autoridades.

Amnesty también describe una técnica mucho más difícil de detectar desde el punto de vista del usuario: dispositivos móviles que habrían sido previamente infectados y luego colocados en comercios para terminar en manos de personas específicas.

La vigilancia, en ese escenario, comienza antes de que la víctima saque el teléfono de la caja.

El problema no es solamente Pegasus

Durante años, Pegasus se convirtió en el símbolo de la industria del spyware mercenario. Pero concentrarse únicamente en una herramienta puede ocultar un fenómeno más amplio.

El informe de Amnesty describe un ecosistema donde diferentes tecnologías se complementan: comprometer remotamente un teléfono, interceptar tráfico de telecomunicaciones, extraer físicamente información de un dispositivo, localizar personas, controlar cámaras o recurrir directamente a vigilancia tradicional.

El atacante no necesita que todas las técnicas sean sofisticadas. Necesita suficientes caminos para llegar al objetivo.

Y ahí aparece una de las dimensiones más incómodas de este caso.

La industria de la vigilancia comercial permitió que capacidades que hace algunas décadas estaban reservadas a un pequeño grupo de servicios de inteligencia pudieran adquirirse como productos y servicios especializados.

Pegasus representa quizá su expresión más conocida, pero no la única.

La investigación sobre Marruecos muestra además que esas capacidades no necesariamente permanecen dentro de las fronteras del Estado que las adquiere. Cuando la infraestructura permite comprometer silenciosamente un teléfono situado en otro país, la vigilancia se convierte también en un problema de soberanía digital.

Un ministro, un periodista o un activista pueden encontrarse físicamente en Europa mientras el dispositivo que llevan en el bolsillo responde a una infraestructura operada desde otro lugar.

La frontera política sigue existiendo.

La frontera digital es bastante más difícil de defender.

Fuente principal: Amnesty International Security Lab — “We start with the verdict: Inside Morocco’s Surveillance Machine”

Micrófonos, cámaras, GPS, sistemas de infotainment y conexiones con smartphones convierten al automóvil en una plataforma capaz de recopilar una enorme cantidad de información.

Durante años aprendimos a desconfiar de nuestros teléfonos cuando entramos a una reunión sensible. Ahora quizá haya que empezar a mirar también el auto estacionado afuera.

La Algemene Inlichtingen- en Veiligheidsdienst (AIVD), el servicio de inteligencia y seguridad de Países Bajos, publicó el 30 de septiembre una advertencia sobre los riesgos de espionaje asociados a los vehículos modernos.

El problema no es necesariamente una vulnerabilidad específica. Es algo más estructural: los automóviles se transformaron en computadoras conectadas, equipadas con sensores y rodeadas de servicios digitales.

Y esas computadoras saben bastante sobre nosotros.

Según la AIVD, los vehículos modernos pueden recopilar información sobre sus ocupantes, sobre el propio automóvil e incluso sobre personas y objetos que se encuentran en sus alrededores. Fabricantes, concesionarios, empresas de leasing, proveedores de mantenimiento, desarrolladores de aplicaciones, fabricantes de componentes y servicios cloud pueden tener acceso a distintas partes de ese ecosistema de datos.

El interés tampoco termina en las empresas.

La inteligencia neerlandesa advierte que actores estatales pueden considerar esas fuentes de información particularmente atractivas.

Un micrófono estacionado frente a la reunión

Uno de los puntos más llamativos de la advertencia está en los micrófonos.

Los vehículos modernos suelen incorporar varios para llamadas manos libres, asistentes de voz, cancelación de ruido y otras funciones.

La AIVD sostiene que técnicamente es posible activar remotamente esos micrófonos y utilizarlos para escuchar conversaciones. Su recomendación para quienes manejan información especialmente sensible es contundente: no mantener conversaciones confidenciales dentro ni alrededor del vehículo.

El mismo principio se aplica a las cámaras.

Cada vez más automóviles incorporan cámaras interiores y exteriores para asistencia a la conducción, estacionamiento, vigilancia o conducción semiautónoma. La agencia considera técnicamente posible que un atacante que consiga acceso a determinados sistemas pueda utilizarlas para obtener imágenes.

Por ese motivo recomienda incluso evitar vehículos con cámaras externas cuando se viaja hacia ubicaciones sensibles.

No significa que cualquier atacante pueda encender mágicamente la cámara o el micrófono de cualquier automóvil. La advertencia describe una superficie potencial de espionaje y está dirigida especialmente a funcionarios públicos, ejecutivos y personas que trabajan con información sensible.

El auto sabe dónde estuviste

El espionaje tampoco necesita escuchar una conversación para resultar útil.

Los sistemas GPS y de seguimiento pueden reconstruir movimientos y rutinas. Los fabricantes pueden utilizar estos mecanismos para conocer la ubicación de un vehículo y registrar desplazamientos.

A eso se suma el sistema de infotainment, que funciona como uno de los principales centros de recopilación y almacenamiento de información dentro del automóvil.

Dependiendo del vehículo y de los dispositivos conectados, allí pueden terminar identificadores de teléfonos, contactos, información de navegación, mensajes o datos relacionados con el tráfico de Internet.

Para un servicio de inteligencia, saber quién viajó, dónde estuvo, qué dispositivo llevaba y con qué lugares se relacionó puede ser tan interesante como escuchar una conversación.

La AIVD señala además dos posibles caminos para que actores estatales accedan a esta información: obtenerla de empresas que poseen los datos o comprometer mediante operaciones de hacking los sistemas donde se encuentran almacenados.

Hasta cargar el teléfono entra en el modelo de amenaza

Algunas recomendaciones de la agencia probablemente resulten exageradas para un conductor común, pero muestran hasta dónde puede extenderse el análisis cuando el objetivo potencial maneja información sensible.

La AIVD recomienda evitar la conexión automática mediante Bluetooth o Wi-Fi y no utilizar la carga inalámbrica. Para conexiones USB aconseja utilizar un USB data blocker, un dispositivo que permite suministrar energía bloqueando los pines utilizados para transmisión de datos.

También aconseja pensar qué información se introduce en los sistemas de navegación.

Guardar como “Casa” una dirección particular puede resultar cómodo. Hacer lo mismo con una instalación sensible puede no ser una buena idea.

El mensaje detrás de todas estas recomendaciones es bastante simple: cada nueva conexión entre el vehículo, Internet, el teléfono y los servicios del fabricante crea también una nueva relación de confianza.

El automóvil entró definitivamente en la superficie de ataque

Durante décadas pensamos la seguridad de un vehículo alrededor de amenazas físicas: robo, sabotaje o seguimiento.

La digitalización cambió ese modelo.

Un automóvil moderno incorpora conectividad celular, GPS, Bluetooth, Wi-Fi, cámaras, micrófonos, aplicaciones móviles, servicios cloud, actualizaciones remotas y sistemas capaces de almacenar información personal.

Desde el punto de vista de seguridad, dejó de ser solamente un medio de transporte.

Es un endpoint móvil lleno de sensores.

Y existe otra diferencia importante respecto de una computadora tradicional: el propietario tiene mucho menos control sobre lo que sucede detrás de escena.

La propia AIVD reconoce que el usuario muchas veces no sabe qué información está almacenando o transmitiendo el vehículo porque estos procesos ocurren automáticamente. Además, determinados riesgos asociados a telemática, GPS o infraestructura de carga no pueden eliminarse simplemente cambiando una configuración.

Cuando la comodidad se convierte en infraestructura de inteligencia

La advertencia neerlandesa expone un problema que excede ampliamente a los automóviles.

Estamos rodeando nuestra vida cotidiana de dispositivos capaces de observar el mundo físico y transmitir esa información hacia infraestructuras que no controlamos.

Televisores, cámaras, relojes, teléfonos, asistentes domésticos y ahora automóviles generan enormes cantidades de datos porque esos datos permiten ofrecer servicios útiles.

Pero exactamente la misma infraestructura puede adquirir otro valor cuando quien la observa es un servicio de inteligencia.

No hace falta instalar un micrófono clandestino debajo del escritorio si la sala, el bolsillo y hasta el estacionamiento ya están llenos de micrófonos conectados a Internet.

Para la mayoría de las personas, eso no significa que haya un Estado escuchando sus conversaciones desde el auto. El nivel de amenaza debe analizarse según quién sea el objetivo y qué información maneje.

Para funcionarios, diplomáticos, investigadores, ejecutivos de sectores estratégicos o personas vinculadas con infraestructura crítica, en cambio, la advertencia de la AIVD introduce una pregunta incómoda.

Quizá el dispositivo que había que dejar fuera de la reunión no era solamente el teléfono.

También era el auto.

El resultado: acceso de lectura y escritura al núcleo, ejecución de payloads y soporte reportado incluso para PS5 Pro.

La escena de seguridad y modificación de PlayStation 5 acaba de dar uno de sus saltos más importantes de los últimos años.

Un nuevo proyecto denominado Relapse Exploit permite explotar consolas PS5 con firmware comprendido entre las versiones 7.00 y 13.60, un rango considerablemente más amplio que el cubierto hasta ahora por muchos métodos públicos. El repositorio fue publicado por el investigador y desarrollador ntfargo y describe una cadena de explotación que comienza dentro del navegador de la consola y termina consiguiendo acceso de lectura y escritura sobre el kernel.

El método también ha sido probado, según los primeros reportes, sobre PS5 Pro, ampliando su alcance más allá del modelo original.

Del navegador al kernel

El interés técnico de Relapse no está solamente en la cantidad de versiones soportadas, sino en cómo encadena distintas vulnerabilidades.

La primera etapa ocurre en el entorno WebKit utilizado por la consola. El README del proyecto señala que el exploit aprovecha filtraciones de información en JavaScriptCore y un problema relacionado con el manejo de objetos clonados para provocar corrupción de memoria sobre un TypedArray.

A partir de allí entra en juego la segunda etapa: un exploit contra el kernel basado en una condición de carrera use-after-free relacionada con aio_multi_wait. El objetivo final es conseguir primitivas de lectura y escritura arbitrarias sobre memoria del kernel.

Ese punto cambia completamente el nivel de acceso.

Una vulnerabilidad en el navegador permite inicialmente romper parte del aislamiento del entorno donde se ejecuta el código web. Conseguir control sobre el kernel significa atravesar una frontera mucho más importante: pasar de explotar una aplicación a modificar el funcionamiento del propio sistema operativo de la consola.

Un jailbreak que se ejecuta desde una página web

Otra de las características que llama la atención es la simplicidad del punto de entrada.

El propio proyecto puede cargarse utilizando una página web alojada por los desarrolladores o ejecutando localmente el servidor incluido en el repositorio. Una vez que la cadena funciona correctamente, se inicia un cargador ELF capaz de recibir payloads adicionales.

En demostraciones publicadas durante las últimas horas, el exploit puede completar el proceso en cuestión de segundos, una diferencia considerable respecto de métodos anteriores que en determinadas versiones podían requerir largos tiempos de espera.

Eso no significa, sin embargo, que el exploit sea completamente estable.

Los propios desarrolladores advierten que la etapa WebKit puede requerir varios intentos y que la fase del kernel puede bloquear o incluso provocar un panic de la consola. También están apareciendo reportes de usuarios que encuentran fallos o bloqueos durante determinadas etapas de la explotación.

Homebrew, payloads y backups

Una vez obtenido acceso al kernel, Relapse permite cargar código adicional mediante payloads.

Entre los proyectos utilizados alrededor de la cadena aparecen herramientas como kstuff, ShadowMount Plus y etaHEN, utilizadas dentro de la comunidad de modificación de PS5 para habilitar funciones adicionales, ejecutar software homebrew y trabajar con copias de juegos.

Conviene separar aquí dos conceptos que suelen mezclarse.

El exploit proporciona el acceso inicial a la consola. Las funcionalidades posteriores dependen de herramientas y payloads adicionales. Que una consola pueda ser explotada no significa automáticamente que cualquier juego, aplicación o función vaya a funcionar en cualquier firmware.

La compatibilidad continúa dependiendo de la versión del sistema y de las herramientas utilizadas después de conseguir acceso al kernel.

No es persistente

Relapse tampoco modifica permanentemente la consola.

Después de reiniciar la PS5, el jailbreak debe ejecutarse nuevamente. Es lo que habitualmente se denomina un método tethered: el acceso obtenido durante una sesión desaparece cuando el sistema vuelve a arrancar.

Esta limitación reduce el impacto práctico respecto de una modificación persistente del sistema, pero al mismo tiempo mantiene el método relativamente simple para quienes utilizan la consola específicamente para investigación o homebrew.

El límite está en firmware 13.60

El detalle más importante para los usuarios es la versión del sistema.

Relapse declara soporte para firmware 7.00 a 13.60. La actualización 14.00 queda fuera del rango actualmente documentado.

Esto vuelve a poner sobre la mesa una dinámica clásica en la seguridad de consolas.

Sony actualiza continuamente el sistema operativo de PlayStation para introducir nuevas funciones, corregir errores y cerrar vulnerabilidades. Las comunidades de investigación, mientras tanto, suelen conservar consolas con firmware antiguo precisamente para mantener abiertas superficies de ataque que probablemente hayan sido corregidas en versiones posteriores.

Cada actualización se transforma así en una decisión: actualizar para mantener compatibilidad completa con la plataforma y sus servicios, o permanecer en una versión vulnerable con potencial para investigación y homebrew.

Una consola moderna también es una plataforma de seguridad compleja

Casos como Relapse muestran algo que muchas veces queda oculto detrás del concepto de “consola de videojuegos”.

Una PS5 moderna es, en la práctica, una plataforma informática sofisticada con navegador, aislamiento entre procesos, kernel protegido, mecanismos criptográficos y múltiples capas diseñadas para impedir la ejecución de código no autorizado.

Romper esa arquitectura raramente depende de una única vulnerabilidad.

Lo interesante de Relapse es precisamente la cadena: una debilidad permite obtener información, otra provoca corrupción de memoria, otra atraviesa la frontera del kernel y finalmente distintas herramientas aprovechan ese acceso para ejecutar software.

Es el mismo patrón que aparece repetidamente en sistemas operativos, teléfonos móviles y dispositivos embebidos.

La seguridad real no depende de que una sola barrera sea perfecta, sino de cuántas barreras independientes debe atravesar un atacante antes de conseguir control significativo del sistema.

En este caso, varias de esas barreras terminaron cayendo una detrás de otra.

Entre los datos potencialmente comprometidos aparecen direcciones confidenciales de personas con órdenes de protección. El FBI investiga el incidente mientras las autoridades intentan determinar qué se llevaron exactamente los atacantes.

Un ciberataque contra el sistema judicial de Arizona acaba de mostrar una de las consecuencias más delicadas que puede tener una filtración de datos públicos: cuando la información comprometida no sirve solamente para cometer fraude, sino que puede poner físicamente en riesgo a una persona.

La Corte Suprema de Arizona confirmó el 25 de septiembre que el sistema judicial estatal fue atacado por hackers, o herramientas automatizadas operadas por ellos, y que los responsables habrían conseguido copiar información personalmente identificable de numerosos ciudadanos.

El personal de tecnología detectó la intrusión e intervino para detenerla. Desde entonces, la Administrative Office of the Courts comenzó a contactar a las personas cuyos datos considera que pudieron haber sido comprometidos.

Pero entre esas notificaciones apareció un detalle particularmente sensible.

Direcciones que estaban diseñadas para permanecer confidenciales

Entre las personas afectadas hay ciudadanos que tienen, o tuvieron, órdenes de protección.

Los avisos enviados por el sistema judicial indican que los atacantes pudieron copiar información relacionada con esas personas y su ubicación, incluyendo la dirección registrada ante el tribunal.

No se trata simplemente de información que casualmente no era pública.

En los procedimientos de protección de Arizona, la dirección y determinados datos de contacto del solicitante pueden mantenerse expresamente confidenciales para evitar que sean revelados a la persona contra la cual se solicita protección. La documentación oficial utilizada por los tribunales incluso identifica esos campos como información confidencial.

Es precisamente esa barrera la que un incidente de ciberseguridad puede terminar atravesando.

Una persona afectada explicó a AZFamily que mantiene desde hace años una orden de protección contra su abusador y que conocer que información sobre su ubicación pudo haber sido copiada la hizo sentirse vulnerable.

Ahí cambia completamente la naturaleza del incidente.

Una contraseña puede cambiarse. Una tarjeta puede bloquearse. Una cuenta comprometida puede recuperarse.

Una dirección residencial es otra cosa.

Qué se sabe del ataque

Por ahora, las autoridades han publicado pocos detalles técnicos.

La Corte Suprema confirmó que el ataque fue detectado por su personal de TI y que los atacantes consiguieron copiar información personalmente identificable, pero no informó públicamente qué vulnerabilidad fue utilizada, qué sistemas fueron comprometidos ni cuántos ciudadanos están afectados.

Tampoco está claro todavía hasta qué punto los datos obtenidos son utilizables.

En las comunicaciones enviadas a algunas víctimas, el sistema judicial señaló que, debido al formato en que fue copiada la información, no está claro si la mayor parte de esos datos puede ser leída fácilmente por los atacantes.

Además, hasta el momento las autoridades dicen no tener evidencia de que la información haya sido compartida con terceros.

El ataque tampoco parece haber estado dirigido específicamente contra las personas que poseen órdenes de protección: habría afectado de forma más amplia a registros almacenados por el sistema judicial.

Son distinciones importantes.

Que los datos hayan sido copiados no significa necesariamente que hayan sido descifrados, publicados o utilizados. Pero tampoco permite descartar ese escenario mientras continúe la investigación.

El FBI entra en escena

La presidenta de la Corte Suprema de Arizona, Ann Scott Timmer, confirmó que contactó personalmente al máximo responsable del FBI en el estado.

Según Timmer, el sistema judicial está colaborando con la agencia para investigar a los responsables y reducir las posibilidades de que la información obtenida sea utilizada para perjudicar a los ciudadanos afectados.

La Justicia de Arizona también creó un centro específico de información sobre el incidente, aunque al momento de esta publicación todavía contiene información limitada y anticipa que incorporará nuevas preguntas y respuestas a medida que avance la investigación.

Por ahora tampoco existe una atribución pública del ataque.

Cuando la confidencialidad depende de la ciberseguridad

El incidente deja una cuestión que va bastante más allá de Arizona.

Los sistemas judiciales acumulan algunas de las bases de datos más sensibles que puede administrar un Estado.

Direcciones. Teléfonos. Identidades. Expedientes penales. Conflictos familiares. Información sobre víctimas. Documentos legales. Órdenes judiciales.

Parte de esa información es pública por definición. Otra parte, en cambio, se mantiene deliberadamente fuera del alcance de determinadas personas porque revelarla podría generar un riesgo.

Y esa diferencia desaparece si alguien consigue entrar por detrás.

Un tribunal puede establecer mediante normas quién tiene derecho a consultar un documento. Puede sellar un expediente. Puede ordenar que una dirección no aparezca en una resolución pública.

Pero ninguna de esas restricciones sirve frente a un atacante que obtiene acceso al sistema que almacena los datos.

Por eso, en determinadas infraestructuras públicas, la ciberseguridad deja de ser solamente un problema de continuidad operativa o protección de información.

Se convierte en parte del propio mecanismo de protección de las personas.

El caso de Arizona es un ejemplo especialmente incómodo: algunos ciudadanos entregaron su ubicación al Estado bajo la expectativa explícita de que permanecería confidencial.

Ahora, al menos parte de esa información puede estar en manos de desconocidos.

Todavía falta saber quiénes fueron, cómo entraron y qué pueden hacer realmente con los datos que consiguieron copiar.

Atacantes vinculados a Corea del Norte se hacen pasar por reclutadores para comprometer desarrolladores, robar criptomonedas y obtener acceso a entornos corporativos. Al menos 30.000 equipos en más de 100 países habrían sido infectados.

Una oferta laboral atractiva. Una entrevista técnica por videollamada. Un repositorio que hay que descargar para resolver una prueba de programación. O, simplemente, un pequeño problema con la plataforma de videoconferencia que requiere ejecutar un comando.

Lo que parece un proceso de selección normal puede ser, en realidad, el comienzo de un ataque.

El 18 de septiembre, organismos de seguridad de Estados Unidos, Japón, Australia y Alemania publicaron una alerta conjunta sobre WaterPlum, un grupo asociado a Corea del Norte y ampliamente conocido en la industria como Contagious Interview. Las autoridades atribuyen sus operaciones, junto con parte de la actividad de trabajadores IT norcoreanos, al 313 General Bureau del Munitions Industry Department, dependiente del Comité Central del Partido de los Trabajadores de Corea.

La magnitud de la campaña es considerable: entre diciembre de 2025 y julio de 2026, WaterPlum habría comprometido al menos 30.000 computadoras en más de 100 países. Más de 7.000 billeteras de criptomonedas fueron afectadas y aproximadamente 10,71 millones de dólares en criptoactivos terminaron transferidos hacia Corea del Norte, según las autoridades.

Pero el robo de criptomonedas es apenas una parte del problema.

Cuando la entrevista es el ataque

La operación explota algo particularmente interesante desde el punto de vista de seguridad: los desarrolladores están acostumbrados a ejecutar código que reciben de terceros.

WaterPlum contacta a programadores, freelancers y profesionales IT mediante redes sociales, plataformas laborales y marketplaces de trabajo independiente. Los atacantes se presentan como reclutadores o empresas, frecuentemente relacionadas con inteligencia artificial, criptomonedas, NFT o tecnología.

Luego llega la entrevista técnica.

La víctima puede recibir un proyecto que debe descargar y ejecutar como parte de una prueba de programación. En otros casos, durante la videollamada aparece un supuesto problema técnico y el candidato recibe instrucciones para descargar archivos o ejecutar código para solucionarlo.

El mecanismo funciona precisamente porque la acción solicitada no resulta necesariamente extraña para alguien acostumbrado a GitHub, Node.js, VS Code y procesos de selección que incluyen ejercicios técnicos.

Entre las herramientas maliciosas identificadas aparecen BeaverTail, InvisibleFerret, OtterCookie, OtterCandy y StoatWaffle, distribuidas, entre otros mecanismos, mediante paquetes NPM y repositorios aparentemente legítimos.

Una vez ejecutado el código, los atacantes pueden desplegar loaders, troyanos de acceso remoto e infostealers para mantener persistencia, comunicarse con infraestructura de comando y control y extraer información del sistema.

Un proyecto de VS Code puede ser suficiente

Uno de los vectores descritos en la alerta merece especial atención.

StoatWaffle utiliza proyectos de Visual Studio Code relacionados aparentemente con blockchain como señuelo. Dentro del proyecto puede existir una configuración maliciosa de VS Code capaz de disparar automáticamente la ejecución de código cuando el usuario abre la carpeta y decide confiar en ella.

En particular, las autoridades advierten sobre el archivo:

.vscode/tasks.json

Un proyecto que parece ser simplemente una prueba técnica puede, por lo tanto, transformarse en el punto inicial de compromiso de la computadora del desarrollador.

Por ese motivo, una de las recomendaciones oficiales es abrir proyectos desconocidos utilizando Restricted Mode y revisar cualquier tasks.json antes de otorgar confianza al repositorio.

El clásico mensaje de VS Code —“Do you trust the authors of the files in this folder?”— deja de ser una advertencia rutinaria para convertirse en una barrera de seguridad relevante.

De la computadora del desarrollador a la empresa

Aquí aparece la dimensión más peligrosa de la campaña.

Una estación de trabajo de desarrollo rara vez contiene solamente código.

Puede tener sesiones autenticadas, tokens, repositorios privados, credenciales almacenadas en el navegador, accesos VPN, secretos de desarrollo, claves API, documentación interna o conexiones con infraestructura corporativa.

La alerta señala que WaterPlum busca información de autenticación almacenada en navegadores, contenido del portapapeles, pulsaciones de teclado, capturas de pantalla, claves privadas y seed phrases de billeteras, además de archivos como pasaportes y documentos de identidad.

Pero comprometer al desarrollador también puede proporcionar un camino hacia la organización para la que trabaja.

Las agencias advierten que una infección exitosa puede permitir espionaje, robo de propiedad intelectual y movimiento lateral dentro de ambientes empresariales. Las credenciales robadas también podrían utilizarse posteriormente contra empleadores, clientes o contratantes de la víctima.

Esto transforma una campaña que inicialmente parece dirigida contra individuos en un problema de seguridad corporativa y cadena de suministro.

El otro lado de la operación: conseguir empleo dentro de empresas

La investigación muestra además una segunda estrategia que funciona prácticamente en sentido inverso.

Mientras WaterPlum se hace pasar por empleador para atacar candidatos, ciudadanos norcoreanos también buscan ser contratados remotamente por compañías extranjeras utilizando identidades falsas y una infraestructura diseñada para ocultar su ubicación real.

Una pieza central son las llamadas “laptop farms”.

Se trata de lugares, muchas veces viviendas de colaboradores, donde se instalan computadoras proporcionadas por empresas. Los trabajadores norcoreanos se conectan remotamente a esos equipos, haciendo parecer que están trabajando físicamente desde el país donde se encuentra la computadora.

También utilizan VPS, documentos de identidad suministrados por intermediarios y cuentas bancarias de terceros para cobrar por sus servicios.

Japón informó en esta investigación haber desmantelado por primera vez una laptop farm operada por un facilitador dentro del país. Estados Unidos, por su parte, continúa procesando a personas acusadas de proporcionar infraestructura y asistencia a trabajadores IT norcoreanos.

Las autoridades encontraron además una conexión técnica especialmente relevante: WaterPlum y trabajadores IT norcoreanos utilizaron las mismas direcciones IP al acceder a laptop farms, plataformas de trabajo y procesos de selección de una empresa japonesa de criptomonedas.

La frontera entre espionaje, ciberdelito y generación de ingresos comienza entonces a desdibujarse.

No siempre termina solamente en cobrar un sueldo

El objetivo habitual de los trabajadores IT norcoreanos sería generar divisas mediante empleos legítimos obtenidos bajo identidades falsas.

Sin embargo, la alerta documenta situaciones donde la relación terminó convirtiéndose en un incidente de seguridad.

En un caso, un trabajador extorsionó a una empresa por un problema relacionado con pagos y posteriormente publicó código fuente propietario. En otro, una persona contratada para mantener un sitio web lo modificó maliciosamente y lo dejó inaccesible.

Por eso el riesgo no debería limitarse al área de Recursos Humanos.

Es un problema que cruza reclutamiento, seguridad de endpoints, identidad, gestión de accesos, desarrollo seguro y riesgo de terceros.

Las señales que pueden aparecer durante una entrevista

La alerta incluye incluso observaciones obtenidas durante procesos reales de contratación.

En mayo de 2025, una empresa japonesa de criptomonedas recibió la candidatura de una persona que las autoridades consideran vinculada al esquema norcoreano. El currículum mostraba una cantidad inusualmente amplia de conocimientos técnicos, experiencia en múltiples ciudades de Europa y Asia y competencias que el candidato posteriormente no pudo demostrar durante la entrevista. La compañía detectó las inconsistencias y no realizó la contratación.

En otros casos se observaron negativas reiteradas a encuentros presenciales, solicitudes de cobrar en criptomonedas o mediante cuentas a nombre de terceros, miradas frecuentes hacia otro monitor, voces de otras personas durante la entrevista y problemas recurrentes de audio o video.

Los investigadores detectaron incluso el uso de software de intercambio de rostros mediante inteligencia artificial durante entrevistas.

Ninguna de estas señales, por sí sola, demuestra actividad maliciosa. Pero combinadas con inconsistencias de identidad, experiencia o ubicación pueden justificar verificaciones adicionales.

Qué deberían cambiar desarrolladores y empresas

La recomendación más sencilla para los profesionales es también la más difícil de aplicar en la práctica: tratar cualquier código recibido durante un proceso de selección como código no confiable.

Las autoridades recomiendan ejecutar proyectos desconocidos únicamente dentro de entornos aislados o máquinas virtuales, inspeccionar código ofuscado, revisar scripts antes de ejecutarlos y prestar especial atención a comandos que descarguen o decodifiquen contenido adicional.

Para las organizaciones, el problema requiere controles más amplios: EDR en estaciones de trabajo, privilegios mínimos, segmentación de accesos, verificación de identidad durante la contratación y procedimientos capaces de detectar anomalías en trabajadores y contratistas remotos.

Y hay una lección adicional que trasciende esta campaña.

Durante años, buena parte de la concientización sobre phishing se concentró en enseñar a los usuarios a no abrir adjuntos o enlaces sospechosos. Pero un desarrollador tiene un perfil operativo diferente: su trabajo consiste precisamente en descargar repositorios, instalar dependencias y ejecutar código.

WaterPlum convierte ese comportamiento profesional legítimo en el vector de entrada.

El desarrollo de software entra definitivamente en el terreno de la inteligencia

La operación expuesta por Estados Unidos, Japón, Australia y Alemania muestra una evolución interesante de las campañas norcoreanas.

No estamos únicamente frente a malware distribuido mediante falsas ofertas laborales, ni solamente ante trabajadores remotos utilizando identidades falsas. Ambos mecanismos forman parte de un ecosistema en el que infraestructura técnica, ingeniería social, robo de identidad, criptomonedas y trabajo remoto pueden utilizarse para obtener acceso y generar ingresos.

En ese escenario, el desarrollador deja de ser solamente quien construye el software.

También se convierte en un objetivo de alto valor.

Y quizás ese sea el aspecto más importante de Contagious Interview: la superficie de ataque ya no termina en el perímetro corporativo. Puede comenzar mucho antes, en una conversación privada entre un programador y alguien que aparentemente solo quiere ofrecerle un mejor trabajo.

Fuente principal: alerta conjunta de NPA, NCO, FBI, DC3, ASD/ACSC, BND y BfV, publicada el 18 de septiembre de 2026. Consultar el advisory completo del FBI/IC3

Horas después, el fabricante confirmó ocho vulnerabilidades en NetScaler, incluidas dos críticas que ya estaban siendo explotadas. El episodio también ofrece una primera mirada a un cambio importante en Europa: desde septiembre, los fabricantes están obligados a informar vulnerabilidades activamente explotadas antes de que necesariamente exista una solución.

Durante buena parte del 26 de septiembre, los administradores de Citrix NetScaler se encontraron frente a uno de los escenarios más incómodos posibles en seguridad: había indicios creíbles de ataques reales contra dispositivos expuestos a Internet, pero prácticamente ninguna información pública sobre qué vulnerabilidad estaban utilizando los atacantes.

No había CVE conocido. No había parche. Y todavía no existía un boletín público del fabricante.

Las primeras advertencias comenzaron a circular en comunidades de seguridad y entre administradores, mientras organizaciones recibían recomendaciones para desconectar o aislar sus appliances NetScaler. La firma de investigación watchTowr señaló que estaba reaccionando a información sobre múltiples vulnerabilidades RCE no corregidas y que había podido validar la credibilidad de esas advertencias con fuentes consideradas autoritativas.

Menos de 24 horas después, el panorama cambió.

Citrix publicó el 27 de septiembre un boletín de seguridad que confirma ocho vulnerabilidades en NetScaler ADC y NetScaler Gateway, identificadas como CVE-2026-88771 a CVE-2026-88778. Y, más importante todavía, confirmó que dos de ellas ya habían sido explotadas contra instalaciones que no contaban con mitigaciones.

La emergencia ya tenía nombre.

Dos vulnerabilidades críticas explotadas antes del parche

Las dos fallas más graves recibieron una puntuación CVSS 4.0 de 9,5.

La primera, CVE-2026-88771, permite ejecución remota de código debido a una validación incorrecta de entradas. El escenario es especialmente preocupante porque, según Citrix, afecta a todos los despliegues de NetScaler ADC y NetScaler Gateway, incluso aquellos con la configuración predeterminada. No es necesario habilitar ninguna funcionalidad adicional para quedar expuesto.

La segunda, CVE-2026-88772, es un desbordamiento de memoria capaz de provocar ejecución remota de código o denegación de servicio. En este caso existe una condición: DTLS debe estar habilitado. Sin embargo, Citrix advierte que DTLS está activado por defecto en los servidores virtuales VPN, lo que amplía considerablemente la superficie potencialmente afectada.

Citrix confirmó explícitamente haber observado explotación de ambas vulnerabilidades.

Y eso cambia completamente la prioridad: ya no estamos frente a fallas que podrían convertirse eventualmente en herramientas de ataque. Los atacantes llegaron primero.

Por qué NetScaler es un objetivo particularmente delicado

El problema no es solamente la gravedad técnica de las vulnerabilidades, sino dónde se encuentra NetScaler dentro de una infraestructura empresarial.

NetScaler ADC y NetScaler Gateway suelen cumplir funciones de balanceo de carga, publicación de aplicaciones, autenticación, VPN y acceso remoto. En muchos despliegues están directamente expuestos a Internet y funcionan, literalmente, como una de las puertas de entrada hacia las redes internas.

Comprometer un dispositivo de este tipo es muy diferente a explotar una vulnerabilidad en una estación de trabajo cualquiera.

El atacante está intentando controlar precisamente la infraestructura que media entre Internet, usuarios autenticados y servicios internos.

Por eso los appliances de borde se han convertido en objetivos especialmente valiosos para operaciones de espionaje, ransomware y acceso inicial. Citrix, además, arrastra un historial reciente de vulnerabilidades graves en NetScaler; durante 2026 watchTowr ya había documentado otros problemas pre-authentication en la plataforma, incluyendo fallas de divulgación de memoria y ejecución remota de código.

No eran solamente dos vulnerabilidades

El boletín de Citrix reveló además que la actualización corrige un conjunto mucho mayor de problemas.

Además de los dos RCE explotados activamente, aparecen:

• CVE-2026-88773, un HTTP Request Smuggling con CVSS 9,3.

• CVE-2026-88774, un bypass de políticas relacionado con expresiones basadas en URL.

• CVE-2026-88775, un desbordamiento de memoria que puede generar comportamiento impredecible o denegación de servicio.

• CVE-2026-88776, otro desbordamiento de memoria asociado a configuraciones de balanceo Oracle.

• CVE-2026-88777, un problema de memoria que afecta determinadas configuraciones con protocolos Layer 7 no HTTP.

• CVE-2026-88778, que permite predecir números de secuencia iniciales TCP.

No todas requieren las mismas condiciones de explotación, pero Citrix señala que todos los NetScaler ADC y NetScaler Gateway están afectados por al menos una de las vulnerabilidades incluidas en el boletín.

Los parches ya están disponibles

La situación cambió sustancialmente respecto de las primeras advertencias del 26 de septiembre.

Ya no corresponde simplemente desconectar los equipos mientras se espera una solución: Citrix publicó versiones corregidas y recomienda instalarlas inmediatamente.

Las versiones indicadas son:

• NetScaler ADC y NetScaler Gateway 14.1-73.37 o posteriores.

• NetScaler ADC y NetScaler Gateway 13.1-64.23 o posteriores.

• NetScaler ADC 14.1-FIPS 14.1-73.37 FIPS o posteriores.

• NetScaler ADC 13.1-FIPS y 13.1-NDcPP 13.1-37.279 o posteriores.

La actualización, sin embargo, resuelve solamente una parte del problema.

Cuando una vulnerabilidad fue explotada como zero-day, instalar el parche evita nuevas explotaciones pero no demuestra que el dispositivo no haya sido comprometido anteriormente.

Las organizaciones con NetScaler expuestos durante el período de explotación deberían considerar la situación también desde la perspectiva de respuesta a incidentes: revisar evidencias de compromiso, actividad anómala y potencial persistencia, en lugar de limitar el procedimiento a instalar la nueva versión y devolver el appliance a producción.

La otra historia: el Cyber Resilience Act empieza a mostrar sus efectos

Hay además un elemento particularmente interesante en la forma en que apareció esta vulnerabilidad.

Desde el 11 de septiembre de 2026 entraron en vigor en la Unión Europea las obligaciones de reporte de vulnerabilidades activamente explotadas establecidas por el Cyber Resilience Act.

Los fabricantes de productos con elementos digitales deben enviar una advertencia temprana dentro de las 24 horas desde que toman conocimiento de una vulnerabilidad activamente explotada. Luego disponen de 72 horas para presentar información adicional.

Para hacerlo, ENISA puso en funcionamiento su nueva Single Reporting Platform, que permite realizar una única notificación y distribuirla hacia las autoridades correspondientes. Los CSIRT europeos pueden utilizar esa información para coordinar y difundir advertencias.

Esto introduce una dinámica poco habitual.

Históricamente, buena parte de la divulgación de vulnerabilidades seguía una secuencia relativamente intuitiva: el fabricante investigaba, desarrollaba una corrección, asignaba o coordinaba el CVE y finalmente publicaba el advisory junto con el parche.

El CRA introduce deliberadamente otra variable cuando existe explotación activa: la obligación de informar puede aparecer antes de que todo ese proceso esté terminado.

Eso ayuda a explicar por qué defensores pueden recibir una advertencia sobre una amenaza real cuando todavía no existe un CVE público ni una actualización disponible.

Seguridad con información incompleta

El episodio NetScaler muestra tanto la ventaja como la dificultad de ese modelo.

Desde la perspectiva defensiva, saber que una vulnerabilidad desconocida está siendo explotada permite tomar decisiones extraordinarias: restringir accesos, aislar sistemas, aumentar el monitoreo o incluso desconectar temporalmente infraestructura crítica.

Pero también genera una situación incómoda para los equipos de seguridad.

¿Cómo se evalúa el riesgo de una vulnerabilidad cuyo funcionamiento todavía se desconoce? ¿Qué se busca en los logs? ¿Qué controles compensatorios funcionan? ¿Qué versiones están realmente afectadas?

Durante varias horas, esas preguntas no tenían respuestas públicas claras.

Ese vacío informativo no significa necesariamente que el sistema haya fallado. Puede ser precisamente la consecuencia de haber adelantado la advertencia antes de que terminara la investigación técnica y estuviera disponible el parche.

Y ese matiz importa.

El objetivo no debería ser publicar todos los detalles de una vulnerabilidad zero-day mientras continúa siendo explotable, algo que incluso podría facilitar nuevos ataques. El desafío consiste en conseguir que la información suficiente llegue rápidamente a quienes deben defender la infraestructura sin entregar simultáneamente una hoja de ruta a potenciales atacantes.

De un rumor a ocho CVE en menos de un día

La cronología de NetScaler condensa muy bien cómo está cambiando la gestión moderna de vulnerabilidades.

El 26 de septiembre, administradores recibían advertencias sobre vulnerabilidades desconocidas y algunos optaban por sacar equipos de producción.

El 27, Citrix confirmó ocho vulnerabilidades, identificó dos RCE críticos bajo explotación activa y publicó las versiones corregidas.

La lección operativa es bastante menos novedosa que la regulación europea: cuando un dispositivo situado directamente en el perímetro está siendo atacado mediante un zero-day, esperar a que aparezca un CVE perfectamente documentado puede significar esperar demasiado.

Pero el caso deja además una pregunta más interesante para los próximos meses.

Si el flujo observado en NetScaler se vuelve habitual, Europa podría estar inaugurando una etapa en la que los defensores se enteren de ciertas vulnerabilidades críticas antes de que el fabricante esté preparado para explicarlas públicamente en detalle.

Eso traerá incertidumbre y decisiones difíciles.

También puede regalar algo que, frente a un zero-day activamente explotado, vale muchísimo más que un CVE perfectamente redactado: tiempo.

DEY. Ideas + Influence, la agencia que representa al gurú del pánico algorítmico Eliezer Yudkowsky, gestionó en secreto las apariciones mediáticas de Coxon mientras este negaba ante Fox News cualquier ayuda externa

La historia del investigador de 27 años que renunció a Anthropic para advertir al mundo de que la inteligencia artificial podría “matarnos a todos antes de que acabe la década” acaba de revelar su verdadera naturaleza: no fue un acto espontáneo de conciencia, sino una operación de comunicación cuidadosamente coreografiada por profesionales del sector.

Según una investigación publicada por Pirate Wires y corroborada por múltiples fuentes, Jacob Coxon trabajó con DEY. Ideas + Influence, una firma de comunicaciones que representa a algunas de las figuras más prominentes del movimiento “doomer” —incluido Eliezer Yudkowsky, el autoproclamado “Científico Jefe del Pánico” que lleva más de dos décadas predicando el apocalipsis algorítmico.

La revelación adquiere una gravedad particular porque Coxon, cuando el presentador de Fox News Bret Baier le preguntó directamente si había contado con ayuda de terceros para organizar su tour mediático, respondió con un escueto “not at all” (”en absoluto”). Era mentira.

La arquitectura de una campaña fabricada

Los detalles de la operación, reconstruidos a partir de dos fuentes con conocimiento directo del asunto y un correo electrónico al que tuvo acceso Pirate Wires, dibujan el retrato de una campaña meticulosamente planificada:

• DEY. estaba gestionando activamente entrevistas para Coxon el 9 de septiembre, apenas un día después de que este publicara su hilo viral en X.

• La misma firma había reservado entrevistas para Nate Soares, presidente del Machine Intelligence Research Institute (MIRI) y coautor de Yudkowsky, programadas para solaparse deliberadamente con el debut público de Coxon.

• Coxon no aparece en la lista pública de clientes de DEY., pero la firma ya había trabajado con él antes de que su cuenta de X —que apenas tenía menos de 100 seguidores cuando publicó el hilo— acumulara 173,8 millones de visualizaciones de la noche a la mañana.

El hilo de Coxon, publicado el 8 de septiembre tras una entrevista exclusiva con The Wall Street Journal, se convirtió en un fenómeno viral prácticamente instantáneo. Fue amplificado por cuentas prominentes del ecosistema “doomer”, recogido por medios de todo el espectro político y citado por figuras que van desde Bernie Sanders hasta Steve Bannon. Su Wikipedia se creó al día siguiente de su irrupción pública.

DEY.: la agencia que mueve los hilos del pánico

La lista de clientes de DEY. no deja lugar a dudas sobre su orientación ideológica. En su propia página web, bajo el epígrafe “The Institutions We Advise” y “Visionaries Shaping Artificial Intelligence”, la firma presume de representar a Eliezer Yudkowsky, Timnit Gebru, Toby Ord, Fei-Fei Li y Yuval Harari. También asesora directamente a MIRI y al Stanford Institute for Human-Centered AI.

Más allá del ecosistema “doomer”, la firma gestiona la comunicación de instituciones como la Fundación Bill y Melinda Gates, la Fundación Ford y las Open Society Foundations de George Soros. En su web, DEY. se describe a sí misma como una firma para “artistas, científicos, disidentes y soñadores”.

Lo que la investigación de Pirate Wires no cuestiona es la sinceridad de las creencias de Coxon. De hecho, sugiere lo contrario: que cree profundamente en lo que dice y buscó ayuda profesional para amplificar su mensaje. Lo que pone en cuestión es algo diferente y políticamente mucho más relevante: quién está financiando y moldeando la campaña que convirtió a un investigador de preentrenamiento prácticamente desconocido en la cara visible de la seguridad en IA en apenas 48 horas, precisamente en un momento en que Washington debate cómo regular la tecnología más poderosa del planeta.

Una operación bajo sospecha desde el primer día

La velocidad y el volumen de la cobertura que recibió Coxon levantaron ampollas desde el principio. Elon Musk fue uno de los primeros en cuestionar públicamente cómo alguien que había trabajado en Anthropic apenas cuatro meses podía aterrizar un perfil en The Wall Street Journal y apariciones en las principales cadenas de televisión de Estados Unidos de forma tan fulminante.

Los indicios de coordinación eran numerosos: el jefe de alineación de Anthropic respaldó inmediatamente el argumento de Coxon; su cuenta de X, prácticamente inactiva hasta entonces, recibió reposts de organizaciones y personalidades prominentes del movimiento “doomer” en menos de 15 minutos; y su primer post —el único que había publicado jamás— se convirtió en un fenómeno global.

En su intervención en Fox News, Bret Baier formuló a Coxon una pregunta que ahora resuena con una ironía demoledora: si su gira mediática había sido orquestada. La respuesta del investigador fue una negación categórica. Los hechos, documentados por Pirate Wires, demuestran que mentía.

La cuadratura del círculo: de “whistleblower” a activo de comunicación

La revelación plantea preguntas incómodas sobre la integridad del debate público en torno a la regulación de la IA. El movimiento “doomer” —que sostiene que la inteligencia artificial general representa un riesgo existencial para la humanidad— ha conseguido en los últimos años una influencia desproporcionada en los medios y en los círculos políticos, a pesar de representar una corriente minoritaria dentro del propio sector tecnológico.

Figuras como Jensen Huang, CEO de Nvidia, han criticado abiertamente que el “doomerismo” ha hecho “mucho daño” y “no es útil para la sociedad”. Guillaume Verdon, fundador del movimiento aceleracionista e/acc, ha señalado que los “doomers” nunca pueden explicar con detalle cómo la IA supuestamente acabará con la humanidad: “Soy matemático. Muéstrame las matemáticas”.

La operación Coxon, ahora desvelada, refuerza la tesis de que el pánico algorítmico no es solo una corriente de opinión, sino también un producto de comunicación estratégicamente gestionado. DEY., la firma que lo orquestó, no es un actor neutral: representa los intereses de las mismas voces que llevan años amplificando el miedo como herramienta de influencia política.

Mientras tanto, Coxon —el hombre que dijo haber actuado en solitario movido únicamente por su conciencia— se ha convertido, según la investigación, en el último activo de una maquinaria de relaciones públicas que lleva años moldeando la conversación global sobre inteligencia artificial.

La pregunta ya no es si Jacob Coxon cree lo que dice. La pregunta es quién decidió que lo dijera, cuándo y en qué medios.

No se habrían comprometido tarjetas ni datos bancarios, pero nombres, información de contacto y registros de compras podrían terminar alimentando campañas de phishing especialmente convincentes.

ASUS comenzó a notificar a clientes de su tienda online tras detectar un acceso no autorizado a parte de la infraestructura de ASUS eShop. La investigación continúa abierta y, por ahora, todavía quedan preguntas importantes sin respuesta: no se conoce públicamente cuántas personas fueron afectadas, durante cuánto tiempo estuvo comprometido el entorno ni cómo consiguió ingresar el atacante.

Lo que sí confirmó la compañía es el tipo de información potencialmente comprometida: datos de contacto y registros relacionados con pedidos realizados en la tienda.

Hay también una diferencia importante frente a otras filtraciones de comercio electrónico: ASUS asegura que no estuvieron involucrados números de tarjetas de crédito, cuentas bancarias ni otra información financiera. La compañía afirma además que, hasta el momento, no tiene conocimiento de que los datos expuestos hayan sido utilizados de manera maliciosa.

Pero eso no convierte al incidente en algo inocuo.

El verdadero riesgo puede llegar después

Una base de datos que combina identidad, información de contacto y compras realizadas tiene una característica especialmente útil para un atacante: contexto.

El phishing tradicional suele funcionar intentando adivinar qué mensaje podría resultar relevante para la víctima. Los datos provenientes de un comercio eliminan parte de esa incertidumbre.

Un atacante podría conocer que determinada persona compró un producto ASUS y utilizar esa información para construir comunicaciones relacionadas con pedidos, entregas, garantías, devoluciones o soporte técnico.

La propia ASUS reconoce ese riesgo. En la comunicación enviada a los afectados advierte que la información comprometida podría utilizarse para crear correos electrónicos, mensajes de texto o llamadas telefónicas convincentes que aparenten estar relacionadas con productos, servicios o pedidos de la compañía.

Es precisamente ahí donde una filtración aparentemente limitada puede convertirse en un problema mayor.

Un mensaje genérico diciendo “su cuenta ha sido comprometida” puede despertar sospechas. Uno que haga referencia a una compra que la víctima realmente realizó tiene muchas más posibilidades de superar esa primera barrera de desconfianza.

Qué información maneja normalmente la tienda

La política de privacidad de ASUS permite dimensionar el tipo de información asociada normalmente a una compra en sus tiendas oficiales.

Para gestionar pedidos, la compañía indica que puede recopilar nombre, dirección de envío o facturación, información de contacto —como correo electrónico y teléfono— y detalles del pedido. En determinados países, parte de esa información también puede ser procesada por revendedores autorizados encargados de operar las tiendas oficiales.

Esto no significa que todos esos campos hayan sido comprometidos en este incidente. Hasta ahora, la comunicación conocida habla específicamente de información de contacto y registros de pedidos.

Tampoco hay información pública que permita determinar qué tiendas regionales fueron afectadas.

ASUS dice haber contenido el acceso

Según la notificación enviada a los clientes, ASUS tomó medidas para contener el incidente después de identificarlo, inició una investigación y aplicó controles adicionales sobre los sistemas afectados.

La empresa asegura además que hasta ahora no encontró evidencia de que continúe existiendo acceso no autorizado.

Sin embargo, la investigación sigue abierta.

No se ha informado públicamente el vector inicial utilizado por los atacantes. Tampoco se conoce si el incidente comenzó mediante una vulnerabilidad, credenciales comprometidas, acceso a un proveedor externo u otro mecanismo.

Atribuir por ahora una causa técnica concreta sería especulativo.

Una filtración sin tarjetas también puede ser valiosa

Durante años, la gravedad de muchas brechas de comercio electrónico se midió principalmente por una pregunta: ¿se filtraron las tarjetas?

El ecosistema actual del fraude digital obliga a mirar más allá.

Los datos personales y transaccionales funcionan como materia prima para ataques posteriores. Cuanto más contexto tiene un atacante sobre una persona, más fácil resulta construir una interacción creíble.

Una compra real puede convertirse en el punto de partida para solicitar una supuesta actualización de dirección, el pago de un costo de envío, la renovación de una garantía o incluso el contacto con un falso servicio de soporte.

La contraseña o la tarjeta no necesariamente tienen que estar dentro de la base de datos original.

El atacante puede intentar conseguirlas después.

Por eso, para quienes hayan recibido una notificación de ASUS, el riesgo más inmediato probablemente no esté en la compra que ya realizaron, sino en el próximo correo, SMS o llamada que parezca saber demasiado sobre ella.

Hasta que la investigación avance, conviene tratar con especial cautela cualquier comunicación inesperada relacionada con pedidos de ASUS, evitar ingresar a enlaces recibidos por mensaje y verificar cualquier solicitud directamente desde los canales oficiales de la compañía.

Por ahora, el alcance completo del incidente sigue sin conocerse. ASUS asegura que no existen indicios de uso indebido de la información ni de acceso persistente a sus sistemas. La pregunta pendiente es cuánto contexto sobre sus clientes llegó realmente a manos de terceros y qué intentarán hacer con él.

El organismo confirmó que investiga actividad no autorizada relacionada con FBIJobs.gov, pero no confirmó el robo de datos ni la existencia del nuevo zero-day. El episodio vuelve a poner bajo presión a Oracle PeopleSoft, apenas meses después de otra vulnerabilidad crítica explotada por el mismo grupo.

ShinyHunters asegura haber conseguido uno de sus objetivos más sensibles hasta el momento: el FBI.

El grupo de ciberdelincuentes afirma haber comprometido la infraestructura vinculada al portal de empleos de la agencia estadounidense mediante una vulnerabilidad zero-day todavía sin parchear en Oracle PeopleSoft. Según sus declaraciones, el ataque le habría permitido acceder posteriormente a otros sistemas y extraer entre 2 y 3 terabytes de información.

Por ahora, esa dimensión del incidente debe tratarse como una afirmación de los atacantes.

El FBI sí reconoció que existe un incidente bajo investigación. En una declaración recogida por distintos medios, señaló que está al tanto de reportes sobre actividad no autorizada que afecta a FBIJobs.gov y que se encuentra investigándolos. No confirmó, sin embargo, que ShinyHunters haya obtenido los volúmenes de información que asegura poseer.

Reuters también informó sobre las afirmaciones del grupo y señaló que, al momento de sus primeras consultas, el FBI no había ofrecido una confirmación pública del supuesto robo de información.

El objetivo: la plataforma de reclutamiento del FBI

El punto de entrada habría sido particularmente interesante.

Según ShinyHunters, los atacantes comprometieron infraestructura asociada a apply.fbijobs.gov, utilizada en los procesos de incorporación de personal de la agencia.

El grupo sostiene que aprovechó una vulnerabilidad desconocida en Oracle PeopleSoft. A diferencia de una falla conocida para la cual una organización simplemente no instaló el parche, un zero-day implica que el atacante dispone de una vulnerabilidad que todavía no cuenta con una solución pública del fabricante.

Al momento de escribir este artículo, no existe información técnica pública suficiente para validar de forma independiente la vulnerabilidad específica que ShinyHunters asegura haber utilizado. Tampoco se ha publicado un CVE correspondiente a este supuesto nuevo fallo.

Esa distinción es importante: que el incidente esté siendo investigado no confirma automáticamente todos los detalles técnicos proporcionados por quienes reivindican el ataque.

Entre 2 y 3 TB de información

La parte potencialmente más grave no es el acceso inicial, sino qué información pudo haber quedado expuesta.

ShinyHunters afirma haber obtenido datos correspondientes a empleados actuales y anteriores del FBI, además de personas que se postularon para trabajar en la agencia. Algunos reportes señalan que el grupo proporcionó muestras de datos como evidencia de sus afirmaciones.

TechCrunch advierte además sobre una consecuencia particularmente delicada si la información sustraída incluye datos personales de agentes: más allá del fraude o el robo de identidad, esa información podría tener valor para operaciones de inteligencia, coerción o extorsión contra funcionarios y sus familias.

En una organización como el FBI, por tanto, una filtración de recursos humanos puede transformarse en algo bastante más serio que una brecha tradicional de datos personales.

No hace falta robar investigaciones clasificadas para provocar un problema de seguridad nacional.

Una extorsión diferente: no están pidiendo dinero

Hay otro elemento que hace especialmente particular al episodio.

ShinyHunters sostiene que el ataque fue una represalia contra el propio FBI.

El grupo está molesto con un informe publicado por la agencia en mayo relacionado con sus operaciones y exige que sea corregido o retirado. Según los atacantes, el FBI tiene una semana para hacerlo antes de que decidan qué hacer con la información obtenida.

No se trataría, al menos según la narrativa pública del grupo, de la habitual extorsión económica.

Los datos estarían siendo utilizados como mecanismo de presión contra una agencia federal.

Eso tampoco convierte automáticamente la versión de ShinyHunters sobre el conflicto en verdadera. Los grupos criminales utilizan sus canales públicos no solamente para extorsionar, sino también para construir reputación, disputar narrativas y aumentar el impacto psicológico de sus operaciones.

Pero el cambio de incentivo resulta relevante.

Los datos robados pueden funcionar como moneda de cambio incluso cuando no hay dinero de por medio.

PeopleSoft ya estaba en la mira de ShinyHunters

El supuesto vector de entrada tampoco aparece de la nada.

En junio de este año, Google Threat Intelligence Group y Mandiant documentaron una campaña atribuida a UNC6240/ShinyHunters que explotaba Oracle PeopleSoft contra organizaciones de distintos sectores.

En aquel caso, los atacantes utilizaron CVE-2026-35273, una vulnerabilidad crítica de ejecución remota de código en PeopleSoft PeopleTools. La actividad maliciosa había comenzado antes de que Oracle publicara su alerta de seguridad, por lo que durante parte de la campaña los atacantes también dispusieron efectivamente de un zero-day.

Google identificó actividad entre finales de mayo y comienzos de junio y notificó a más de 100 organizaciones potencialmente expuestas. El 68% pertenecía al sector educativo estadounidense.

Aquella vulnerabilidad podía explotarse remotamente sin autenticación y recibió una puntuación CVSS de 9,8.

El nuevo fallo que ShinyHunters asegura haber utilizado contra el FBI sería, según el grupo, una vulnerabilidad diferente y todavía desconocida.

Eso aún necesita confirmación independiente.

El problema de las aplicaciones empresariales olvidadas

Más allá de si finalmente se confirman los 2 o 3 TB reclamados por ShinyHunters, el caso vuelve a mostrar un patrón conocido en seguridad empresarial.

Los sistemas de recursos humanos, ERP, gestión financiera y otras grandes plataformas corporativas pueden resultar objetivos extraordinariamente valiosos.

No suelen recibir la misma atención pública que un firewall, un servicio VPN o una plataforma cloud. Pero detrás de ellos pueden existir décadas de información sobre empleados, postulantes, proveedores y operaciones internas.

Y muchas veces están profundamente integrados con el resto de la organización.

Un sistema aparentemente administrativo puede convertirse así en una puerta de entrada hacia activos mucho más sensibles.

PeopleSoft es especialmente relevante en este contexto porque sigue formando parte de infraestructuras de grandes organizaciones y organismos públicos. Para un atacante especializado en robo masivo de información, encontrar una vulnerabilidad reutilizable en este tipo de plataforma puede proporcionar una lista completa de potenciales víctimas.

Eso es precisamente lo que ya ocurrió durante la campaña documentada por Google en junio.

Cuando el atacante tiene el parche antes que el fabricante

El episodio también expone uno de los escenarios más incómodos para cualquier equipo de seguridad.

Si la nueva vulnerabilidad realmente existe y continúa sin parche, no hay actualización que instalar.

La defensa pasa entonces por reducir superficie de exposición, limitar accesos, segmentar adecuadamente la infraestructura y buscar comportamientos anómalos alrededor de las aplicaciones afectadas mientras aparece más información técnica.

Pero hay una lección todavía más amplia.

Durante años, buena parte de la gestión de vulnerabilidades se estructuró alrededor de una lógica relativamente sencilla: aparece un CVE, el fabricante publica un parche, la organización evalúa su criticidad y lo instala.

Las campañas modernas de explotación están reduciendo ese margen.

En junio, ShinyHunters ya demostró que podía explotar PeopleSoft antes de que existiera una solución pública. Ahora afirma haber encontrado otro camino hacia la misma plataforma y haberlo utilizado contra una de las principales agencias policiales del mundo.

Todavía falta determinar cuánto de esa historia puede verificarse.

Pero si el nuevo zero-day se confirma, la pregunta más preocupante probablemente no sea cómo logró ShinyHunters entrar al FBI.

Será quién más utiliza la misma tecnología y ya fue visitado antes de que el resto del mundo supiera que había una puerta abierta.

El problema expone una de las paradojas centrales de los asistentes autónomos: cuanto más útiles se vuelven, más valioso resulta comprometerlos.

Meta lanzó Muse con una promesa ambiciosa: un agente de inteligencia artificial capaz de operar sobre buena parte de la vida digital del usuario. Puede trabajar con correo, calendario, archivos, mensajería y servicios web, ejecutar tareas complejas e interactuar con otras aplicaciones.

El problema es que esa capacidad depende necesariamente de una enorme cantidad de confianza.

Y ahora un investigador de seguridad demostró que un proceso local sin privilegios especiales puede aprovechar precisamente esa confianza.

Patrick Wardle, especialista en seguridad de macOS y fundador de Objective-See, publicó este 21 de septiembre una prueba de concepto denominada “not-a-mused” que explota una configuración interna no documentada de Muse.

Según la investigación, la aplicación expone una preferencia llamada endo_voyager_dictation_endpoint, que determina hacia dónde se envía el tráfico asociado al dictado de voz.

El problema: un proceso ejecutándose como el usuario puede modificarla sin necesitar privilegios elevados.

Eso permite redirigir las comunicaciones hacia infraestructura controlada por un atacante.

Y ahí comienza el verdadero problema.

De interceptar un prompt a controlar el agente

En condiciones normales, cuando un usuario dicta una instrucción, Muse envía esa información hacia infraestructura de Meta para procesarla.

Wardle descubrió que es posible modificar el destino de ese tráfico.

De esta forma, malware ejecutándose localmente podría colocar un servidor controlado por el atacante entre el usuario y Muse.

La prueba de concepto muestra que esto podría permitir capturar los prompts dictados por el usuario, modificar instrucciones mediante prompt injection y obtener material de autenticación utilizado por el propio agente.

Pero el impacto no termina ahí.

La documentación del PoC resume el riesgo de una forma particularmente clara:

“Muse’s access can potentially become the attacker’s access.”

Es decir: el acceso concedido a Muse puede terminar convertido en acceso para el atacante.

Y esto cambia significativamente el modelo de amenaza.

El agente como amplificador de privilegios

Existe un argumento habitual cuando se analiza una vulnerabilidad que requiere ejecución local: si un atacante ya puede ejecutar malware en una computadora, entonces el sistema ya está comprometido.

En muchos escenarios, ese razonamiento tiene sentido.

En este caso, no necesariamente.

Muse puede disponer de permisos y autenticaciones que un proceso local común no posee.

Dependiendo de lo que haya autorizado el usuario, el agente podría tener acceso a archivos, Mail, Messages, Calendar, Notes, micrófono, cámara u otros servicios conectados.

El propio Wardle explica que esto convierte a Muse en una especie de amplificador de privilegios: en lugar de desarrollar malware especializado capaz de robar información de múltiples aplicaciones, un atacante podría intentar secuestrar al agente que ya posee esas capacidades.

Según Ars Technica, Wardle desarrolló pruebas que permiten utilizar Muse para realizar acciones como escribir archivos o tomar fotografías aprovechando los permisos previamente concedidos al asistente.

El problema, por lo tanto, no es solamente que malware pueda comprometer Muse.

El problema es que Muse puede tener más privilegios que el propio malware.

La arquitectura de los agentes cambia el modelo de seguridad

Los asistentes tradicionales respondían preguntas.

Los agentes modernos ejecutan acciones.

Esa diferencia aparentemente simple tiene consecuencias importantes.

Para ser útil, un agente necesita acumular acceso: debe leer correos, revisar calendarios, consultar documentos, acceder a servicios web y, eventualmente, realizar acciones en nombre del usuario.

Muse representa precisamente esa evolución.

Meta lo describe como un agente capaz de trabajar en segundo plano, lanzar subagentes, construir herramientas e incluso interactuar con un shell. En su propia explicación sobre la arquitectura de seguridad del producto, la compañía reconoce que el desarrollo implicó entregar inboxes, calendarios y acceso a comandos a software que podía funcionar de forma autónoma.

Ese modelo crea una nueva concentración de privilegios.

Antes, un atacante podía necesitar vulnerar varias aplicaciones para obtener determinada información.

Ahora puede existir un único componente que ya tenga acceso a todas ellas.

El agente.

Una configuración interna con consecuencias externas

Uno de los aspectos más llamativos del descubrimiento es la aparente simplicidad del vector.

El problema no requiere explotar corrupción de memoria, romper el aislamiento del sistema operativo ni utilizar una vulnerabilidad sofisticada del kernel.

La prueba de concepto aprovecha una configuración de la propia aplicación.

El parámetro que controla el endpoint de dictado puede ser modificado por un proceso local ejecutándose con permisos normales del usuario.

Wardle señala que, desde el punto de vista de diseño, Meta podría haber reducido el riesgo manteniendo el procesamiento del dictado dentro del propio dispositivo, utilizando mecanismos disponibles en macOS.

En cambio, el sistema envía esa información hacia infraestructura remota.

Una combinación de decisiones arquitectónicas termina creando una superficie de ataque difícil de ignorar.

No es un ataque remoto

También es importante colocar el descubrimiento en contexto.

La vulnerabilidad no permite comprometer remotamente una Mac desde Internet por sí sola.

El atacante necesita primero conseguir ejecución de código bajo la cuenta del usuario.

Eso puede ocurrir mediante malware, ingeniería social u otros mecanismos.

Wardle menciona específicamente la posibilidad de combinar el problema con técnicas similares a ClickFix, donde se convence al usuario de copiar y ejecutar comandos aparentemente legítimos.

Una vez obtenida esa ejecución inicial, el atacante podría utilizar Muse como plataforma para expandir el alcance del compromiso.

Por eso hablar simplemente de “malware local” puede minimizar el impacto.

La vulnerabilidad funciona como una vía de amplificación de capacidades.

Las dudas sobre privacidad ya habían comenzado

El descubrimiento aparece además en un momento complicado para Muse.

En los días posteriores al lanzamiento surgieron cuestionamientos sobre la forma en que el agente accede a información del sistema.

Un usuario relató que Muse parecía conocer información proveniente de Messages pese a que, según él, no había concedido explícitamente ese acceso. Meta indicó posteriormente que el agente había interpretado incorrectamente la procedencia de la información y que el acceso dependía de los permisos otorgados por el usuario.

Amazon también comenzó a bloquear el acceso de Muse a su plataforma, argumentando que los agentes externos deben identificarse correctamente y respetar las decisiones de los servicios con los que interactúan.

Son problemas diferentes, pero convergen en una misma cuestión:

¿qué nivel de confianza estamos dispuestos a entregar a software autónomo que puede actuar en nuestro nombre?

Un exresponsable de seguridad de Meta también expresó preocupación

La publicación de la vulnerabilidad recibió además una reacción particularmente incómoda para la compañía.

Un gerente de ingeniería de seguridad de Meta que dejó la empresa este mismo mes afirmó públicamente que no utilizaría Muse, citando preocupaciones vinculadas a seguridad y privacidad.

La declaración no demuestra por sí misma que el producto sea inseguro, pero adquiere relevancia porque proviene de alguien que ocupó una posición directamente relacionada con seguridad dentro de la compañía.

Meta, al mismo tiempo, ha presentado Muse como un producto diseñado desde el principio alrededor de la seguridad y la privacidad.

La compañía publicó recientemente una extensa explicación técnica detallando las medidas utilizadas para reducir riesgos en agentes autónomos.

El descubrimiento de Wardle demuestra lo difícil que resulta cumplir esa promesa cuando el producto necesita concentrar tantos permisos.

El problema no es solamente Muse

Sería sencillo interpretar el episodio como una falla puntual de Meta.

Pero el problema es más amplio.

Todo el ecosistema tecnológico está avanzando hacia agentes que necesitan permisos cada vez mayores para funcionar.

Leer correos.

Enviar mensajes.

Modificar archivos.

Operar navegadores.

Realizar compras.

Ejecutar comandos.

Interactuar con sistemas corporativos.

Cada nueva integración aumenta la utilidad del agente, pero también incrementa el impacto potencial de comprometerlo.

En términos de seguridad, estos sistemas pueden convertirse en puntos de concentración de confianza.

Algo similar ocurrió históricamente con los gestores de contraseñas, navegadores o herramientas de administración remota: cuanto más acceso concentra una aplicación, más atractiva se vuelve para un atacante.

Los agentes de IA llevan esa lógica todavía más lejos.

No solamente almacenan credenciales.

También pueden tomar decisiones y ejecutar acciones.

Una nueva frontera para la seguridad de endpoints

La prueba de concepto de Wardle deja una conclusión que probablemente se repetirá en los próximos años.

La seguridad de los agentes no puede evaluarse únicamente observando el modelo de inteligencia artificial.

También hay que analizar la aplicación que lo rodea, sus configuraciones, los permisos del sistema operativo, las credenciales que almacena, las integraciones que utiliza y los canales por los que recibe instrucciones.

Muse puede tener sofisticados mecanismos para detectar prompt injection o limitar acciones peligrosas.

Pero si un proceso local puede modificar el lugar donde recibe sus instrucciones o interceptar sus credenciales, esas defensas pueden quedar relegadas a un segundo plano.

Los agentes prometen convertirse en una nueva capa entre el usuario y el sistema operativo.

Eso los convierte también en una nueva capa que los atacantes intentarán controlar.

Y probablemente este sea apenas uno de los primeros ejemplos.

Los casos muestran además un fenómeno cada vez más difícil de separar: actores políticos, ciberdelincuentes y desarrolladores de malware compartiendo herramientas, infraestructura y tácticas.

La frontera entre ciberdelincuencia, espionaje y hacktivismo hace tiempo que dejó de ser clara. Pero la guerra entre Rusia y Ucrania ha convertido esa zona gris en un laboratorio particularmente visible.

Una serie de investigaciones publicadas por Kaspersky y recogidas esta semana por The Hacker News describe la actividad de tres grupos diferentes contra organizaciones rusas: NightEagle, Hacking Cat y Toy Ghouls. Sus motivaciones no son necesariamente las mismas y tampoco utilizan exactamente las mismas herramientas. Sin embargo, vistas en conjunto, sus operaciones muestran cómo está evolucionando el ecosistema ofensivo alrededor del conflicto.

Hay espionaje y persistencia silenciosa. Hay ransomware. Hay operaciones directamente destructivas. Y, cada vez más, hay herramientas que parecen circular entre distintos grupos, haciendo más difícil determinar quién está realmente detrás de cada ataque.

NightEagle: entrar por la VPN y llegar hasta Active Directory

El primer caso es probablemente el más reconocible para cualquier equipo de seguridad corporativa.

NightEagle —también identificado como APT-Q-95 y activo al menos desde 2023— ha conseguido en varios incidentes acceso inicial utilizando credenciales legítimas comprometidas para conectarse a las VPN corporativas. Desde allí, el objetivo es avanzar progresivamente hacia los sistemas más sensibles de la organización.

Una de sus herramientas es GhostContainer, una puerta trasera modular desplegada sobre servidores Microsoft Exchange comprometidos. El malware permite ejecutar código, manipular archivos, cargar módulos adicionales y utilizar el servidor como punto de entrada o túnel hacia otras partes de la infraestructura.

Una vez dentro, los atacantes emplean diferentes mecanismos para desplazarse lateralmente, incluyendo túneles sobre RDP y herramientas disponibles públicamente. Kaspersky también observó intentos de explotar vulnerabilidades en Active Directory y ataques DCSync para obtener información de autenticación del dominio.

El objetivo final es mucho más importante que comprometer una computadora: controlar la identidad corporativa.

Obtener hashes de contraseñas, generar accesos persistentes mediante Kerberos y alcanzar los controladores de dominio puede permitir que un atacante pase de controlar una máquina a controlar prácticamente toda la organización.

Y el detalle más incómodo es que buena parte de la operación no depende de malware extraordinariamente sofisticado. Credenciales robadas, VPN, herramientas legítimas, software abierto y vulnerabilidades conocidas siguen siendo suficientes cuando se combinan correctamente.

Hacking Cat: cuando el ransomware deja de buscar un rescate

El segundo caso introduce una dimensión diferente.

Hacking Cat es descrito por Kaspersky como un grupo hacktivista pro-ucraniano activo desde 2024. Inicialmente asociado principalmente con defacements y filtraciones de información, habría evolucionado hacia operaciones de cifrado y destrucción contra organizaciones rusas.

Entre sus herramientas aparece Gorilla RAT, un troyano de acceso remoto escrito en Go capaz de ejecutar comandos, recopilar información del sistema, transferir archivos y crear túneles hacia las redes internas.

Pero el elemento más interesante es Monkey, una familia de ransomware con variantes desarrolladas en Rust, .NET, C++ y Go y preparada para atacar Windows, Linux e incluso entornos VMware ESXi.

Algunas variantes utilizan algoritmos criptográficos legítimos como ChaCha20-Poly1305 o AES-256-CBC. El problema no está en la criptografía, sino en lo que ocurre con las claves.

En determinadas versiones, la clave utilizada para cifrar los archivos no se almacena en ningún lugar.

Eso cambia completamente la naturaleza del ataque.

Si no existe una clave recuperable, tampoco existe una posibilidad real de descifrar los archivos, incluso aunque la víctima quisiera pagar. El supuesto ransomware se convierte entonces, en la práctica, en un wiper disfrazado de ransomware: malware cuyo objetivo real es destruir información.

Esa diferencia resulta fundamental para interpretar este tipo de incidentes. En el ransomware tradicional existe una lógica económica: el atacante necesita que la recuperación sea técnicamente posible porque pretende cobrar por ella. En una operación destructiva, el cifrado puede ser simplemente el mecanismo elegido para inutilizar los sistemas.

Herramientas compartidas y atribuciones cada vez más complicadas

La investigación también señala conexiones entre Hacking Cat y otros colectivos pro-ucranianos, entre ellos Cyber Anarchy Squad y Ukrainian Cyber Alliance.

En operaciones conjuntas aparecen herramientas como ClearWater, otro ransomware, y Nemo Wiper, diseñado directamente para sobrescribir archivos con datos aleatorios y ocupar el espacio disponible en disco.

Kaspersky plantea una hipótesis especialmente interesante: diferentes grupos podrían estar utilizando herramientas desarrolladas por una fuente común, posiblemente uno o varios desarrolladores encargados de crear y mantener malware posteriormente utilizado por distintos colectivos.

Pero esa atribución está discutida.

Tras la publicación de la investigación, Hacking Cat reconoció que algunas herramientas eran propias pero negó específicamente ser responsable de los lockers que Kaspersky le atribuye, acusando a la compañía de mezclar herramientas pertenecientes a actores diferentes.

La discrepancia importa porque ilustra uno de los problemas centrales de la inteligencia de amenazas: encontrar una herramienta en una operación no demuestra automáticamente quién la desarrolló, quién la controla o quién decidió utilizarla.

Cuando código, infraestructura y malware circulan entre grupos, la atribución basada exclusivamente en indicadores técnicos se vuelve mucho más frágil.

Toy Ghouls y el malware que se esconde detrás de servicios legítimos

El tercer actor completa el panorama desde otra dirección.

Toy Ghouls —también conocido como Bearlyfy, Laboo.boo y Feral Wolf— es considerado un grupo principalmente motivado por razones económicas y activo desde 2025. Anteriormente utilizaba constructores filtrados de ransomware como Babuk y LockBit, pero progresivamente comenzó a desarrollar herramientas propias.

En julio de 2026 apareció una nueva puerta trasera denominada Bird Agent.

Lo interesante no es solamente el malware, sino sus canales de comunicación.

Una variante utiliza HiveMQ, basado en MQTT, mientras que otra aprovecha Element, el cliente de mensajería construido sobre Matrix, como infraestructura de comando y control. Una vez establecido el canal, los operadores pueden enviar órdenes al equipo comprometido y recibir los resultados.

Para un defensor, este tipo de técnicas genera un problema importante: bloquear conexiones hacia un dominio claramente malicioso es relativamente sencillo; distinguir tráfico legítimo de comunicaciones maliciosas que atraviesan plataformas y protocolos perfectamente válidos resulta bastante más complejo.

Es una tendencia que excede ampliamente este caso: la infraestructura legítima de Internet también puede convertirse en infraestructura ofensiva.

Rusia como laboratorio de un ecosistema nacido de la guerra

Los tres casos no deberían interpretarse como una única campaña coordinada. Las motivaciones y capacidades son diferentes y, especialmente en el terreno del hacktivismo, las atribuciones deben tratarse con cautela.

Pero forman parte de un fenómeno más amplio.

Investigaciones anteriores ya mostraban una fuerte concentración de ataques contra organizaciones rusas desde el comienzo de la guerra. Positive Technologies estimó que Rusia concentró el 73% de los ataques observados contra organizaciones de países de la Comunidad de Estados Independientes durante 2023 y la primera mitad de 2024, vinculando el incremento de actividad con el contexto geopolítico.

La guerra produjo además una proliferación de grupos que combinan motivaciones políticas, económicas y de inteligencia.

Eso está generando algo parecido a un ecosistema ofensivo distribuido.

No necesariamente existe una estructura central que ordene cada operación. Puede haber grupos hacktivistas, actores profesionales, desarrolladores independientes, ciberdelincuentes y comunidades informales reutilizando código, intercambiando herramientas o atacando objetivos compatibles con sus intereses.

El resultado es una zona gris donde distinguir entre ransomware, sabotaje y operación política resulta cada vez más difícil.

Y quizás esa sea la parte más relevante de estas campañas.

La guerra digital contemporánea no ocurre únicamente entre unidades militares o agencias de inteligencia. También se desarrolla a través de actores privados y semiautónomos que operan sobre la misma infraestructura, utilizan muchas de las mismas herramientas que los ciberdelincuentes y, en ocasiones, persiguen simultáneamente objetivos económicos y políticos.

En ese escenario, saber qué malware atacó una organización puede ser relativamente sencillo.

Determinar quién estaba realmente detrás, para quién trabajaba y qué buscaba conseguir es otra historia.

Marginalia no pretende destronar a Google: quiere demostrar que otra forma de encontrar información en Internet todavía es posible.

Durante años nos acostumbramos a utilizar dos conceptos casi como sinónimos: Internet y Google.

Si una página no aparece en los primeros resultados de una búsqueda, para buena parte de los usuarios es como si no existiera.

Pero Internet es mucho más grande que aquello que un buscador decide mostrarnos.

Esa diferencia es precisamente el territorio que Viktor Löfgren, un ingeniero de software sueco, decidió explorar cuando comenzó a desarrollar Marginalia, un pequeño buscador independiente cuyo objetivo no es competir frontalmente con Google o Bing, sino mirar hacia los lugares que ellos suelen dejar fuera del foco.

El proyecto comenzó en 2021. Löfgren estaba frustrado porque cada vez encontraba menos blogs, foros y sitios independientes mediante los grandes buscadores. Su pregunta era sencilla: ¿habían desaparecido esas páginas o simplemente habíamos dejado de encontrarlas?

Para averiguarlo hizo algo bastante radical para un proyecto personal: construyó su propio motor de búsqueda.

No es otra interfaz para Google

La distinción es importante.

Muchos servicios presentados como alternativas a los grandes buscadores dependen, total o parcialmente, de índices construidos por terceros. Marginalia hace algo diferente: utiliza su propio crawler para recorrer Internet, procesa las páginas y construye su propio índice.

Eso significa que puede tomar decisiones completamente diferentes acerca de qué merece aparecer primero.

Y las toma.

Marginalia está diseñado para privilegiar sitios pequeños, antiguos, extraños y principalmente textuales: blogs personales, páginas de aficionados, documentación técnica, viejos sitios universitarios y otros rincones de Internet que tienen pocas posibilidades de competir dentro del ecosistema comercial moderno.

Su propia descripción lo resume como un buscador orientado a descubrir el lado más humano y no comercial de Internet.

No utiliza inteligencia artificial para responder preguntas. En su página principal incluso lo anuncia explícitamente: “Simple technology, no AI”. El motor continúa utilizando búsquedas basadas fundamentalmente en palabras clave.

Hay una filosofía detrás de esa aparente regresión tecnológica.

Un buscador puede ser extraordinariamente bueno respondiendo qué queremos saber y, al mismo tiempo, volverse progresivamente peor permitiéndonos explorar dónde está ese conocimiento.

No es exactamente el mismo problema.

Buscar información o descubrir Internet

Los buscadores modernos intentan reducir la distancia entre una pregunta y su respuesta.

Marginalia intenta conservar esa distancia.

Su interfaz incluye herramientas específicamente orientadas al descubrimiento. Su modo Explore, por ejemplo, permite recorrer sitios del índice sin partir necesariamente de una consulta convencional. También ofrece información y filtros relacionados con características de las páginas que encuentra.

La lógica es casi opuesta a la Web hiperoptimizada que conocemos.

En lugar de preguntarse qué resultado tiene mayores probabilidades de satisfacer inmediatamente nuestra intención, Marginalia intenta mostrarnos lugares que quizá ni siquiera sabíamos que existían.

Eso también explica por qué penalizar publicidad excesiva, elementos de seguimiento u otras características comerciales tiene sentido dentro de su modelo. Löfgren explicó que puede analizar el HTML de una página y utilizar esas señales para modificar su posición o permitir que el usuario filtre determinado tipo de contenido.

No pretende ser neutral.

Pero esa es precisamente una de las ideas interesantes del experimento: ningún ranking lo es completamente.

El problema de quién construye el índice

La discusión se vuelve bastante más profunda cuando dejamos de mirar a Marginalia como una curiosidad tecnológica.

Para Löfgren, uno de los problemas centrales de la búsqueda moderna es la escasa diversidad de índices disponibles.

Construir una interfaz de búsqueda es relativamente sencillo. Construir la infraestructura capaz de recorrer Internet, almacenar cientos de millones de documentos y decidir cómo relacionarlos es otra historia.

El propio proyecto reconoce que esa concentración tiene consecuencias.

Cuando una parte enorme de nuestra capacidad para encontrar información depende de unas pocas infraestructuras, también aumenta la facilidad con la que determinado contenido puede volverse invisible, incluso sin que exista una intención explícita de censurarlo.

Marginalia agrega otra dimensión: si los principales motores están concentrados geográficamente, sus decisiones técnicas inevitablemente incorporan determinadas prioridades culturales sobre qué constituye información relevante.

El buscador se define por eso como una especie de “minority report”: una mirada alternativa que no pretende convertirse en el nuevo árbitro de Internet, sino existir junto a los grandes buscadores.

Su FAQ es todavía más explícita: no quiere reemplazar Google. Quiere complementarlo.

Una infraestructura sorprendentemente pequeña

Quizá el aspecto más provocador de Marginalia sea su escala.

El proyecto llegó a indexar aproximadamente 300 millones de documentos en 2024, ocupando alrededor de un terabyte, aunque Löfgren advierte que el tamaño del índice es una métrica poco representativa de la calidad de un buscador.

El crawler realiza actualmente grandes ciclos de actualización aproximadamente cada ocho a diez semanas, complementados con consultas diarias a feeds RSS y algunas actualizaciones adicionales.

Y todo esto está diseñado deliberadamente para funcionar sobre hardware relativamente accesible.

Según la información publicada por el propio proyecto, sus gastos operativos rondan apenas los US$ 200 mensuales. Marginalia no tiene préstamos ni inversores esperando un retorno financiero y busca sostenerse mediante donaciones, subvenciones y acuerdos comerciales relacionados con su API.

No significa que construir un competidor global de Google cueste US$ 200 al mes.

Marginalia tiene objetivos, tráfico y cobertura radicalmente diferentes.

Pero demuestra algo igualmente interesante: construir infraestructura independiente de búsqueda en Internet no es una capacidad reservada exclusivamente a corporaciones con centros de datos multimillonarios.

Un buscador que cualquiera puede estudiar

Hay otra diferencia importante.

El código de Marginalia es abierto.

La mayor parte del proyecto se publica bajo licencia AGPL 3.0 y puede utilizarse para ejecutar una instancia propia o incluso como base para construir un buscador especializado sobre otros conjuntos de información.

Eso convierte al proyecto en algo más que un buscador alternativo.

Es también una demostración práctica de cómo funcionan algunas de las capas más invisibles de Internet: crawling, procesamiento documental, indexación y ranking.

Y muestra que esas capas pueden construirse fuera de Google, Microsoft o las grandes plataformas tecnológicas.

La soberanía digital también empieza por poder encontrar

Durante años la discusión sobre soberanía digital se concentró principalmente en sistemas operativos, servicios cloud, redes sociales, infraestructura de telecomunicaciones o almacenamiento de datos.

Pero existe otra capa menos visible: la infraestructura que determina qué información podemos encontrar.

Un índice de búsqueda es, en cierto sentido, un mapa de Internet.

Y quien construye el mapa necesariamente decide qué caminos aparecen, cuáles parecen importantes y cuáles terminan convertidos en pequeñas calles que casi nadie recorre.

Marginalia no resuelve esa concentración. Tampoco pretende hacerlo.

Su escala es pequeña, su cobertura tiene limitaciones —el propio proyecto reconoce que actualmente se concentra principalmente en contenido en inglés— y su ciclo de actualización lo vuelve poco apropiado para determinadas búsquedas recientes.

Pero su existencia demuestra algo valioso.

Internet todavía permite construir mapas alternativos.

Y quizá el verdadero aporte de Marginalia no sea encontrar mejores respuestas que Google, sino recordarnos que buscar no debería significar necesariamente mirar Internet a través del mismo mapa que utiliza todo el mundo.

La fintech confirmó que entregó información sensible de clientes ante solicitudes fraudulentas enviadas desde un dominio gubernamental legítimo. Los atacantes ahora publican datos y exigen un pago, mientras aseguran haber comprometido organismos policiales italianos durante meses. El caso expone un problema que va más allá de Revolut: ¿qué ocurre cuando el atacante no falsifica a la autoridad, sino que logra hablar desde sus propios sistemas?

La historia parecía, en un primer momento, un sofisticado caso de suplantación.

Un atacante había conseguido enviar a Revolut solicitudes de información que aparentaban provenir de una agencia gubernamental. Los mensajes llegaban desde un dominio oficial y superaban los mecanismos habituales de autenticación del correo electrónico. Revolut los procesó como solicitudes legítimas y entregó información de sus clientes.

Pero durante las últimas horas el incidente tomó otra dimensión.

Los responsables comenzaron a publicar supuestos datos de clientes de alto perfil y a utilizar la información como mecanismo de extorsión. Paralelamente, aseguran que la infraestructura utilizada para obtener los datos de Revolut no fue simplemente falsificada: habría formado parte de una intrusión más amplia contra organismos policiales italianos.

Esta segunda parte todavía depende principalmente de las afirmaciones de los propios atacantes y de información publicada por International Cyber Digest, por lo que debe tratarse como no verificada de manera independiente. La primera, en cambio, ya está confirmada: Revolut reconoce que entregó información confidencial a un tercero no autorizado que utilizó una dirección perteneciente a un dominio gubernamental legítimo.

El atacante no entró a Revolut: Revolut le entregó los datos

Esta distinción es fundamental para entender el incidente.

No hay evidencia pública de que los atacantes hayan vulnerado los sistemas centrales de Revolut. La propia compañía sostiene que sus sistemas y los fondos de sus clientes permanecieron intactos.

El problema estuvo en otro lugar.

Un tercero no autorizado consiguió utilizar una cuenta perteneciente al dominio legítimo de una agencia gubernamental y la empleó para enviar solicitudes fraudulentas de información. Los mensajes pasaron los controles técnicos de autenticación del dominio y fueron procesados como solicitudes oficiales.

Revolut respondió.

Según las notificaciones enviadas a clientes afectados, entre la información potencialmente entregada aparecen nombres, fechas de nacimiento, direcciones postales, correos electrónicos, teléfonos, ocupaciones, copias de pasaportes o licencias de conducir y las fotografías utilizadas durante los procesos de verificación de identidad.

Pero el alcance no termina en el KYC.

También pudieron entregarse IBAN, estados de cuenta, registros de retiros y el historial completo de transacciones, incluyendo operaciones con Bitcoin.

Es una combinación particularmente delicada.

Un pasaporte filtrado ya representa un problema. Una dirección particular también. Un historial financiero completo, otro.

Cuando todo aparece asociado a una misma identidad, el atacante obtiene algo mucho más valioso: un perfil financiero extremadamente preciso de la víctima.

Y en el caso de las criptomonedas existe una consecuencia adicional. La pseudonimidad de determinadas direcciones blockchain puede quedar erosionada si una institución financiera entrega información capaz de vincularlas con nombres, documentos, domicilios y movimientos bancarios.

Cerca de 700 clientes afectados

Inicialmente Revolut se limitó a hablar de un número “muy limitado” de usuarios.

Información publicada posteriormente por Financial Times eleva esa cifra a 680 clientes afectados, mientras la autoridad británica de protección de datos investiga el incidente. Entre las personas afectadas estaría también Mark Karpelès, ex CEO de Mt. Gox.

La cifra es pequeña comparada con los aproximadamente 80 millones de clientes que Revolut dice atender globalmente.

Pero ese número puede ser engañoso a la hora de evaluar la gravedad.

El investigador blockchain ZachXBT había advertido desde el comienzo que el incidente parecía estar dirigido específicamente contra usuarios de alto patrimonio.

Si esa hipótesis es correcta, no estamos ante una extracción masiva e indiscriminada de información, sino frente a algo potencialmente más sofisticado: utilizar mecanismos legítimos de cooperación con las autoridades para construir dossiers financieros sobre objetivos seleccionados.

Los datos empiezan a aparecer públicamente

La situación escaló durante el fin de semana.

International Cyber Digest informó que los responsables comenzaron a publicar información que atribuyen a clientes de Revolut, incluyendo personas de alto perfil.

Entre los nombres mencionados aparecen el tenista Alexander Shevchenko y Felix Römer, vinculado a Gamdom y Skinscom. Otros medios han reportado la publicación de documentos y fotografías de verificación atribuidos a estas víctimas.

Los atacantes estarían utilizando la información como herramienta de extorsión y amenazan con continuar publicando datos, comunicaciones y detalles sobre el funcionamiento interno de los procesos de Revolut si la empresa no paga.

La existencia de la extorsión y de publicaciones atribuidas a clientes ha sido reportada por varias fuentes, aunque la autenticidad y procedencia de todo el material publicado por los atacantes no ha sido verificada independientemente.

Esto transforma el incidente.

Ya no se trata únicamente de determinar cómo Revolut validó incorrectamente una solicitud gubernamental.

Ahora existe una segunda pregunta: cómo consiguió el atacante emitirla desde infraestructura aparentemente legítima de una autoridad pública.

La pista italiana

Es aquí donde aparece la parte más inquietante de la historia.

International Cyber Digest afirma estar en contacto con un actor que se identifica como responsable de la operación, bajo el alias IAmNotAVillain.

Según su relato, los atacantes habrían comprometido sistemas pertenecientes a varios departamentos de las fuerzas de seguridad italianas y utilizado esa infraestructura para enviar solicitudes de información a Revolut durante aproximadamente seis meses.

La afirmación todavía no cuenta con confirmación oficial.

El actor asegura además poseer unos 147 GB de información obtenida del lado italiano, incluyendo documentos internos, calendarios y material personal perteneciente a funcionarios. Medios italianos ya comenzaron a recoger las afirmaciones sobre una posible intrusión contra organismos policiales, aunque por ahora continúan siendo acusaciones provenientes del atacante.

Este detalle podría explicar una de las grandes incógnitas del caso inicial.

Los correos fraudulentos no parecían simples mensajes de phishing enviados desde un dominio parecido al de una agencia pública.

Provenían de un dominio gubernamental real.

Eso importa porque mecanismos como SPF, DKIM y DMARC pueden ayudar a demostrar que un correo fue autorizado por la infraestructura de determinado dominio. Pero no pueden demostrar que la persona detrás de esa cuenta tiene realmente autoridad legal para solicitar información sobre un ciudadano.

Es una diferencia pequeña desde el punto de vista técnico y enorme desde el punto de vista de seguridad.

Cuando comprometer al policía permite atacar al banco

La operación, si las afirmaciones del atacante terminan confirmándose, representa un ejemplo particularmente interesante de ataque a una relación de confianza.

En lugar de atacar directamente la infraestructura mejor protegida, se compromete uno de los actores en los que esa infraestructura confía.

Las instituciones financieras necesitan responder regularmente solicitudes de jueces, policías, fiscalías, reguladores y otros organismos estatales. Esos canales forman parte del funcionamiento normal del sistema financiero.

Pero también crean una superficie de ataque.

Si un atacante consigue controlar una cuenta o plataforma utilizada por una autoridad legítima, puede intentar heredar indirectamente esa confianza.

Desde la perspectiva de Revolut, el mensaje técnicamente era auténtico: había sido enviado desde infraestructura correspondiente a quien decía enviarlo.

Lo que no era auténtico era la autoridad humana detrás de la solicitud.

Ese problema no se resuelve simplemente agregando otro filtro antispam.

Requiere procedimientos de validación independientes: canales secundarios para confirmar solicitudes especialmente sensibles, controles sobre el alcance de la información solicitada, identificación individual del funcionario responsable y mecanismos que permitan detectar patrones anómalos.

Una solicitud técnicamente válida no debería equivaler automáticamente a una solicitud jurídicamente válida.

El problema incómodo de acumular KYC

El incidente también vuelve a poner sobre la mesa una contradicción inherente a los sistemas modernos de identificación financiera.

Las regulaciones obligan a bancos y fintech a recopilar cantidades enormes de información para conocer a sus clientes, prevenir lavado de activos y colaborar con investigaciones.

Pasaportes.

Selfies.

Direcciones.

Teléfonos.

Movimientos bancarios.

Información laboral.

Historiales financieros.

En algunos casos, actividad relacionada con criptomonedas.

Todo eso permite cumplir obligaciones regulatorias.

También crea bases de datos extraordinariamente atractivas.

Y cuanto más completa es la identificación, mayor es el impacto cuando alguien consigue extraerla mediante una vulnerabilidad técnica, una cuenta comprometida, ingeniería social o, como aparentemente ocurrió aquí, abusando de un mecanismo legítimo de cooperación gubernamental.

El problema deja entonces de ser únicamente quién puede entrar a la base de datos.

También importa quién está autorizado a pedir que alguien desde adentro saque la información por él.

Una infraestructura de confianza que también puede ser atacada

Hay una lectura más amplia del caso Revolut.

Buena parte de la seguridad digital moderna está construida alrededor de cadenas de confianza.

Confiamos en certificados digitales para identificar servidores. En proveedores de identidad para autenticar usuarios. En dominios para identificar organizaciones. En autoridades certificadoras. En proveedores cloud. En instituciones públicas.

Y confiamos en que un mensaje proveniente de determinados sistemas gubernamentales representa realmente al Estado.

Pero ninguna de esas relaciones es absoluta.

Si el extremo confiable resulta comprometido, el atacante puede comenzar a operar con parte de su legitimidad.

Es el equivalente digital a robar no solamente una credencial, sino el sello oficial con el que se firman las órdenes.

El incidente de Revolut todavía tiene importantes incógnitas. No conocemos públicamente qué organismo fue comprometido, cómo se obtuvo acceso a su infraestructura ni hasta dónde llega realmente la intrusión que reivindican los atacantes. Las afirmaciones sobre los organismos policiales italianos y los 147 GB de información requieren confirmación independiente.

Pero hay algo que ya sabemos.

Revolut recibió solicitudes que parecían provenir de una autoridad legítima, las consideró auténticas y entregó información extremadamente sensible de cientos de personas.

El atacante no necesitó romper la puerta del banco.

Consiguió que alguien con autoridad tocara el timbre.

Y la puerta se abrió desde adentro.

Ahora, una nueva publicación asegura que el investigador fue empleado de Microsoft, terminó despedido y transformó su conflicto con la compañía en una campaña de divulgación de vulnerabilidades zero-day. Parte de la historia puede comprobarse. Otra parte depende, por ahora, de su propio relato. Pero las consecuencias de esa guerra ya escaparon ampliamente de sus protagonistas.

Durante meses, uno de los episodios más extraños de la seguridad informática de 2026 tuvo un protagonista sin rostro.

Bajo los nombres Nightmare Eclipse y Chaotic Eclipse, un investigador comenzó a publicar vulnerabilidades desconocidas de Windows acompañadas, en varios casos, por código capaz de explotarlas. BlueHammer, RedSun, UnDefend, YellowKey, RoguePlanet, LegacyHive y ShieldBreak fueron apareciendo mientras el conflicto con Microsoft se hacía cada vez más público.

Ahora ese protagonista tiene nombre.

Según una publicación de International Cyber Digest, Nightmare Eclipse es Abdelhamid Naceri, un investigador de seguridad con un largo historial encontrando vulnerabilidades en Windows y, según su relato, exempleado de Microsoft.

La revelación cambia considerablemente la lectura de una historia que hasta ahora podía parecer simplemente la de un bug hunter furioso con una multinacional.

Porque Naceri no apareció de la nada.

El investigador existía mucho antes que Nightmare Eclipse

La trayectoria pública de Abdelhamid Naceri como investigador de seguridad puede verificarse años antes de los acontecimientos actuales.

La Zero Day Initiative de Trend Micro lo acredita como descubridor de múltiples vulnerabilidades de Windows. Entre ellas aparecen CVE-2021-26431, una vulnerabilidad de escalada de privilegios en Windows Update; CVE-2021-26426, en Windows User Profile Service; y CVE-2021-42280, relacionada con el servicio DiagTrack.

Su nombre también llegó a los medios en 2021 por InstallerFileTakeOver, un exploit que permitía pasar desde una cuenta estándar de Windows hasta privilegios SYSTEM. The Register confirmó entonces que su prueba de concepto funcionaba contra sistemas actualizados.

Ya entonces existían tensiones con Microsoft.

Naceri explicó públicamente que había dejado de informar determinadas vulnerabilidades anticipadamente como protesta por la reducción de las recompensas del programa de bug bounty de la compañía.

Es decir: la disputa sobre cómo Microsoft trata a los investigadores externos no comenzó en 2026.

Pero algo cambió radicalmente este año.

De investigador a Nightmare Eclipse

A comienzos de abril apareció BlueHammer.

El exploit aprovechaba el comportamiento de Microsoft Defender para conseguir una escalada local de privilegios. Desde una cuenta sin privilegios, determinadas condiciones permitían terminar ejecutando código como SYSTEM, uno de los niveles de privilegio más altos de Windows.

No quedó simplemente como una demostración académica.

Huntress detectó posteriormente herramientas asociadas a Nightmare Eclipse dentro de una intrusión real. BlueHammer, RedSun y UnDefend aparecieron en una cadena de ataque que comenzó aparentemente mediante acceso comprometido a una VPN FortiGate.

CISA terminó además reconociendo explotación activa de BlueHammer, incluyendo su utilización en ataques de ransomware.

La consecuencia es importante para entender todo lo que vino después.

Lo que empezó como una pelea entre un investigador y Microsoft terminó colocando herramientas ofensivas funcionales en manos de atacantes reales.

La versión de Naceri

Aquí comienza la parte de la historia que todavía requiere cautela.

International Cyber Digest afirma haber identificado a Nightmare Eclipse como Abdelhamid Naceri y asegura que su conflicto tiene raíces mucho más profundas que una disputa por recompensas de bug bounty.

Según ese relato, Naceri trabajó para Microsoft y fue posteriormente despedido. La compañía habría explicado la terminación mediante motivos que él considera vagos y nunca habría aclarado completamente el supuesto incidente de seguridad que habría originado la decisión.

Naceri sostiene además que, después del despido, un vicepresidente de Microsoft le comunicó que sería bloqueado para futuras contrataciones dentro de la compañía y recibiría una referencia laboral negativa.

El contexto migratorio habría convertido el despido en algo especialmente grave: según su versión, estaba a pocos meses de conseguir residencia permanente en la Unión Europea.

International Cyber Digest también afirma que el conflicto terminó en los tribunales alemanes y que Microsoft habría ofrecido 55.000 euros más aproximadamente un año de salario para cerrar el litigio, mientras Naceri asegura haber gastado más de 200.000 dólares continuando el proceso.

Ojo Cibernético no pudo verificar independientemente estos elementos del conflicto laboral ni acceder a documentación judicial que permita confirmar esas cifras. Por eso deben considerarse, por ahora, parte de la versión presentada por Naceri y la publicación que reveló su identidad.

Lo que sí puede comprobarse independientemente es el conflicto posterior entre Nightmare Eclipse y Microsoft.

Microsoft contra Nightmare Eclipse

En mayo, Microsoft rompió públicamente el silencio.

La compañía criticó las divulgaciones no coordinadas y sostuvo que las vulnerabilidades publicadas por Nightmare Eclipse no habían sido reportadas previamente mediante sus canales oficiales. Microsoft calificó este tipo de divulgación como injustificable debido al riesgo que generaba para sus clientes.

La tensión aumentó cuando Microsoft mencionó a su Digital Crimes Unit y la posibilidad de colaborar con autoridades frente a actividades que provocaran daños.

Una parte de la comunidad de investigadores interpretó el mensaje como una amenaza contra Nightmare Eclipse.

La reacción fue suficientemente fuerte como para que Microsoft aclarara días después que no tenía intención de perseguir legalmente a investigadores de seguridad que actuaran de buena fe.

Pero para entonces la relación estaba completamente destruida.

Nightmare Eclipse siguió publicando vulnerabilidades.

Y siguieron apareciendo zero-days

En junio llegó RoguePlanet, otra vulnerabilidad de Microsoft Defender capaz de permitir escalada hasta SYSTEM en sistemas Windows actualizados. Microsoft reconoció que estaba investigando el problema y terminó corrigiéndolo.

En julio apareció LegacyHive, relacionada con Windows User Profile Service. Esta vez el propio investigador publicó deliberadamente una prueba de concepto limitada que requería credenciales adicionales, dificultando su utilización inmediata por atacantes. Microsoft terminó asignándole CVE-2026-62832 y corrigiéndola.

En agosto apareció otra.

ShieldBreak permitía nuevamente alcanzar privilegios SYSTEM y, según el investigador, eludía la corrección implementada anteriormente por Microsoft para RoguePlanet.

Otros investigadores comprobaron que el exploit funcionaba.

A esta altura ya no estamos frente a un descubrimiento aislado.

Estamos frente a una persona con un conocimiento extraordinariamente profundo de los mecanismos internos de Windows demostrando, una vulnerabilidad detrás de otra, su capacidad para romper componentes fundamentales del sistema operativo.

El problema incómodo de la divulgación responsable

Sería sencillo convertir esta historia en una narrativa de héroes y villanos.

También sería un error.

Si la versión de Naceri sobre su relación laboral con Microsoft es correcta, podría existir una historia seria sobre cómo una de las compañías tecnológicas más poderosas del mundo gestionó a un empleado altamente especializado, su situación migratoria y posteriormente el conflicto con él.

Microsoft debería responder esas acusaciones.

Pero ninguna injusticia laboral transforma automáticamente la publicación de exploits funcionales contra sistemas sin parchear en una acción inocua.

Una vulnerabilidad zero-day publicada no golpea solamente a Microsoft.

Golpea a hospitales, empresas, administraciones públicas, infraestructuras críticas y millones de organizaciones que ejecutan Windows.

Y en este caso ya existe evidencia de que herramientas publicadas por Nightmare Eclipse abandonaron el laboratorio y aparecieron dentro de ataques reales.

Ese dato hace imposible reducir la discusión a una simple reivindicación contra una corporación.

Pero Microsoft tampoco puede reducirlo a “divulgación irresponsable”

Existe otro riesgo en la interpretación del caso.

Presentar a Nightmare Eclipse únicamente como un investigador irresponsable permite ignorar una pregunta bastante más incómoda:

¿cómo llegó la relación entre uno de los investigadores con mayor capacidad demostrada para encontrar vulnerabilidades en Windows y Microsoft hasta este punto?

La comunidad de seguridad reaccionó fuertemente cuando Microsoft endureció públicamente su posición. No porque exista consenso en favor de publicar zero-days sin coordinación, sino porque muchos investigadores reconocieron problemas propios en su relación con el Microsoft Security Response Center.

El sistema de divulgación responsable funciona sobre algo mucho menos técnico que un CVE o un exploit: confianza.

El investigador confía en que la empresa estudiará seriamente el reporte, reconocerá su trabajo y corregirá el problema.

La empresa confía en que el investigador le dará tiempo suficiente para proteger a sus usuarios antes de hacer pública la vulnerabilidad.

Cuando cualquiera de las dos partes rompe ese contrato, el mecanismo empieza a fallar.

Cuando ambas consideran que la otra lo rompió primero, aparece algo parecido a Nightmare Eclipse.

Un riesgo sistémico

Hay además una dimensión todavía más importante.

Windows no es simplemente un producto comercial.

Está presente en gobiernos, bancos, hospitales, empresas, redes industriales y organizaciones estratégicas de prácticamente todos los países. Microsoft Defender forma parte, por defecto, de una enorme cantidad de esos equipos.

Eso convierte la seguridad de Windows en una cuestión de infraestructura digital global.

Y revela una dependencia incómoda: una disputa entre una corporación estadounidense y un único investigador puede terminar modificando el riesgo informático de organizaciones situadas a miles de kilómetros que no participaron de ese conflicto y tienen escasa capacidad para influir sobre él.

La historia de Nightmare Eclipse es, por supuesto, la historia de Abdelhamid Naceri y Microsoft.

Pero también es una demostración bastante brutal de cómo funciona nuestra infraestructura digital.

Una persona descubre una vulnerabilidad. Una empresa controla el producto. Ambos entran en conflicto. El exploit aparece públicamente. Criminales lo incorporan a sus operaciones.

Y el resto del mundo instala el parche.

Cuando existe semejante concentración tecnológica, una pelea privada puede convertirse rápidamente en un problema público.

Tal vez esa sea la parte más importante de esta historia.

OC-EKO26-A7F3