Arresto de delincuente abre discusión sobre posibilidades de rastreo de dispositivos Windows

El FBI utilizó un identificador de dispositivo de Microsoft, denominado GDID, para vincular a un adolescente con un ataque informático atribuido a Scattered Spider, lo que generó preocupación sobre la privacidad y las capacidades de vigilancia de Windows.

El grupo habría estado implicado en más de 100 intrusiones, obteniendo más de 100 millones de dólares en rescates. En el caso que se le atribuye el hacker detenido no se consiguió rescate alguno, pese a que la demanda era de 8 millones de dólares. Eso sí, se ha confirmado que la empresa de joyas de lujo sufrió al menos 2 millones de dólares en pérdidas por interrupción del negocio, investigación y mitigación.

Según una denuncia federal sustitutiva presentada en el Distrito Norte de Illinois, se utilizó un identificador persistente de dispositivo de Microsoft para desenmascarar a un presunto operador de Scattered Spider. Peter Stokes, de 19 años, con doble nacionalidad estadounidense y estonia, quien supuestamente usaba los alias "Bouquet", "Spencer" y "Jordan", fue arrestado en Finlandia el 10 de abril de 2026, cuando intentaba abordar un vuelo a Japón.

Los fiscales alegan que es miembro de Scattered Spider, también conocido como Octo Tempest, UNC3944 y 0ktapus, un grupo vinculado a más de 100 intrusiones y pagos de rescate por más de 100 millones de dólares.

La detención de un joven ha revelado que Microsoft puede rastrear un PC con Windows y su actividad en línea mediante un "Identificador Global de Dispositivo" que, al parecer, no permite desactivarlo fácilmente, lo que ha generado temores sobre una posible vigilancia.

La semana pasada, Estados Unidos anunció la extradición de Peter Stokes, de 19 años, desde Europa, por presuntamente pertenecer al conocido grupo de hackers Scattered Spider. Sin embargo, el caso destaca porque Microsoft desempeñó un papel clave al vincular a Stokes con los presuntos delitos informáticos, según una denuncia penal que se hizo pública.

Al parecer, Stokes hackeó una joyería de lujo (cuyo nombre no se ha revelado) en mayo de 2025 utilizando una VPN. Finalmente, se extrajeron datos utilizando Teleport.sh y Amazon S3, por un total de al menos 77 GB, seguido de una amenaza de despliegue de ransomware y una demanda de extorsión de 8 millones de dólares que quedó impaga.

La denuncia penal de 39 páginas revela que el FBI utilizó los registros de Microsoft para descubrir que su dirección IP estaba asociada a un identificador de dispositivo de Microsoft conocido como ID Global de Dispositivo (GDID).

"Según un representante de Microsoft, un ID Global de Dispositivo en el ecosistema de Windows es un identificador persistente a nivel de dispositivo, diseñado para identificar de forma única una instalación del sistema operativo Windows en un dispositivo, ya sea físico (por ejemplo, un teléfono móvil o un portátil) o virtual, en determinados servicios y escenarios de Microsoft", explica la denuncia.

El ID Global de Dispositivo no resulta sorprendente, dado que es práctica habitual asignar un ID único a cada cuenta o dispositivo para que un proveedor de tecnología pueda reconocerlos y distinguirlos. Sin embargo, la denuncia revela que Microsoft puede asociar el GDID con servicios de terceros y también con la hora de uso, lo que le permite, en teoría, rastrear la actividad en línea de un usuario. En otras palabras, Microsoft podría rastrear la actividad en línea de su PC con Windows sin necesidad de cookies de navegador de terceros.

Se descubrió que Stokes estaba utilizando la herramienta ngrok para eludir las defensas de la red de la joyería. La denuncia indica que Microsoft tenía registros que mostraban que el 12 de mayo de 2025, a las 19:21 UTC, el GDID asociado al ordenador de Stokes "accedió, entre otras páginas de ngrok, a https://dashboard[.]ngrok.com/signup, la página de ngrok para crear una cuenta".

El documento añade que los registros de Microsoft también mostraban que el GDID accedió a "múltiples sitios" desde servidores de Tzulo, un proveedor de alojamiento web, para facilitar el ataque.

Por lo tanto, el hecho de que los investigadores federales usaran el identificador de Microsoft para atrapar a un presunto delincuente genera preocupación por su posible uso indebido con otros fines de vigilancia.

El identificador del dispositivo se menciona brevemente en esta página de soporte, pero Microsoft no se ha pronunciado públicamente al respecto. Según la denuncia penal, un usuario de Windows puede restablecer el GDID por sí mismo, aunque no es sencillo. "Un GDID se mantiene constante tras las actualizaciones del sistema operativo Windows en un dispositivo, pero una reinstalación de Windows, ya sea en el mismo dispositivo o en otro, se vinculará a un nuevo GDID único", indica el documento judicial. En una nota a pie de página, añade: "Por lo tanto, un usuario de Microsoft podría tener varios GDID".

¿Se puede desactivar el GDID?

No hay una forma clara y oficial de desactivar el GDID de Windows desde los ajustes del sistema. De hecho, Microsoft no ofrece ningún tipo de información al respecto en sus webs oficiales de soporte. Lo que sí existen son aplicaciones de terceros que permiten reducir la telemetría, bloquear servicios de diagnóstico, desactivar identificadores publicitarios, limitar experiencias personalizadas o impedir conexiones automáticas a ciertos servidores de Microsoft.

Entre las aplicaciones más populares tenemos, WinDebloat, O&O ShutUp10++, WPD, Privatezilla, DoNotSpy, MajorPrivay, WinTenPrivacy, y BlackBird que se han hecho un hueco entre muchos usuarios de Windows 11. Estas permiten modificar opciones de privacidad, diagnóstico, anuncios, permisos de aplicaciones, historial de actividad o sincronización desde una misma pantalla.

Fuente: PCMag

Seguir leyendo...

Vulnerabilidad BlueHammer de Windows es explotada por bandas de ransomware

CISA confirmó que grupos de ransomware han comenzado a explotar una vulnerabilidad de escalamiento de privilegios de alta gravedad en Microsoft Defender, la cual ya se había utilizado en ataques de día cero.

La vulnerabilidad, denominada BlueHammer (CVE-2026-33825), fue filtrada a principios de abril por un investigador de seguridad conocido como "Nightmare Eclipse", junto con un código de prueba de concepto para su explotación, en protesta por la forma en que el Centro de Respuesta de Seguridad de Microsoft (MSRC) gestiona el proceso de divulgación.

"La insuficiente granularidad del control de acceso en Microsoft Defender permite que un atacante autorizado eleve sus privilegios localmente", explica Microsoft en un aviso de seguridad.

Will Dormann, analista principal de vulnerabilidades en Tharros, declaró que, si bien la vulnerabilidad no es fácil de explotar, permite a los atacantes locales acceder a la base de datos del Administrador de Cuentas de Seguridad (SAM), que contiene los hashes de las contraseñas de las cuentas locales.

Con este acceso, pueden escalar a privilegios de SYSTEM y potencialmente tomar el control total del sistema objetivo. "En ese momento, [los atacantes] básicamente controlan el sistema y pueden hacer cosas como generar una shell con privilegios de SYSTEM", dijo Dormann.

Microsoft corrigió la vulnerabilidad el 14 de abril como parte de la actualización de seguridad de abril de 2026. Sin embargo, días después, investigadores de seguridad de Huntress Labs revelaron que ciberdelincuentes la habían estado explotando como una vulnerabilidad de día cero en ataques que mostraban evidencia de actividad directa del atacante.

Durante los últimos meses, Nightmare Eclipse ha revelado múltiples exploits de día cero para Windows, incluyendo las vulnerabilidades BlueHammer, MiniPlasma, RedSun, UnDefend, YellowKey, RoguePlanet, GreenPlasma. Algunas de estas vulnerabilidades afectan a Microsoft Defender, mientras que otras tienen como objetivo BitLocker y componentes de Windows.

Microsoft corrigió las vulnerabilidades de seguridad GreenPlasma, MiniPlasma y YellowKey hace tres semanas como parte de las actualizaciones de seguridad de junio de 2026.

La CISA añadió la vulnerabilidad BlueHammer a su Catálogo de Vulnerabilidades Explotadas Conocidas (KEV) el 22 de abril, ordenando que se actualizaran los dispositivos Windows para protegerse contra los ataques en curso de la vulnerabilidad CVE-2026-33825 en un plazo de dos semanas, hasta el 7 de mayo.

Si bien Microsoft aún no ha identificado esta vulnerabilidad como explotada en ataques, la CISA también la ha señalado como explotada en campañas de ransomware en una actualización del Catálogo KEV publicada el lunes.

Fuente: BC

Seguir leyendo...

"Bad Epoll" permite a los usuarios sin privilegios obtener root en Linux y Android

Una falla del kernel de Linux recientemente revelada llamada Bad Epoll (CVE-2026-46242) permite a un usuario común y corriente sin acceso especial tomar el control total de una máquina como root. Afecta a los escritorios, servidores y Android de Linux, y ya existe una solución.

Bad Epoll se encuentra en el mismo pequeño tramo de código del kernel donde el modelo de IA más poderoso de Anthropic, Mythos, encontró recientemente un error diferente.

Epoll es una característica estándar de Linux que permite a un programa observar muchos archivos o conexiones de red a la vez. Los servidores, los servicios de red y los navegadores web se basan en él. No puedes simplemente apagarlo.

Jaeyoung Chung presentó la falla como un día cero al programa kernelCTF de Google, y los detalles técnicos completos se encuentran en su artículo público. No hay señales de que se haya utilizado en ataques reales: al momento de escribir este artículo, no está en la lista de vulnerabilidades explotadas conocidas de CISA, y el único código que funciona es la prueba de concepto de kernelCTF. Aún se está desarrollando una versión para Android del exploit.

Bad Epoll es un error de "uso después de la liberación". Dos partes del kernel intentan limpiar el mismo objeto interno al mismo tiempo. Uno libera la memoria mientras el otro sigue escribiendo en ella. Esa breve colisión permite que un atacante corrompa la memoria del kernel y luego pase de una cuenta normal a root.

El problema es el tiempo. La ventana donde chocan los dos caminos tiene sólo seis instrucciones de máquina de ancho, por lo que un intento aleatorio casi nunca aterriza en ella. El exploit amplía esa ventana y lo reintenta sin fallar, alcanzando root aproximadamente el 99% de las veces en los sistemas probados.

Dos cosas lo hacen más peligroso: según su cuenta, puede activarse desde dentro del entorno limitado de procesamiento de Chrome, que bloquea casi todos los demás errores del kernel, y puede llegar a Android, algo que la mayoría de los errores de privilegios de Linux no pueden.

Ambos errores se remontan a un único cambio de 2023 en el código epoll. Chung dice que Mythos encontró el primero de los dos, ahora rastreado como CVE-2026-43074, con un aterrizaje fijo a principios de 2026.

Anthropic ha dicho por separado que Mythos encontró errores de escalamiento de privilegios en el kernel de Linux, aunque no ha vinculado públicamente ese trabajo con Bad Epoll. Encontrar el primero fue un resultado real, porque los errores en las condiciones de carrera son notoriamente difíciles de detectar.

Epoll no se puede desactivar, por lo que no existe ninguna solución, se debe aplicar la actualización de su distribución cuando llegue. Los kernels creados con la versión 6.4 o posterior se ven afectados a menos que ya tengan la solución. Los kernels más antiguos basados ​​en 6.1, incluidos algunos teléfonos Android como el Pixel 8, no lo son, porque el error llegó en 6.4.

Fuente: THN

Seguir leyendo...

El malware Umbrij abusa de OAuth para acceder a Gmail a través de la API de Google.

El grupo de ciberdelincuentes conocido como ToddyCat ha sido atribuido a un nuevo malware llamado Umbrij, diseñado para obtener acceso subrepticio al GMail de las víctimas a través de la API de Google.

"En esta campaña, los atacantes centraron su atención en las comunicaciones de correo electrónico corporativas alojadas en Gmail, con el objetivo de comprometer el acceso a través de las API", afirmó Kaspersky en un informe detallado publicado esta semana. "Dado que la API de Google se basa en el protocolo OAuth 2.0 para la autorización, las aplicaciones pueden usar un token OAuth para acceder a los recursos de correo electrónico solicitados".

Se cree que el atacante desarrolló Umbrij para obtener este token y usarlo para conectarse a la consola de administración del navegador en modo sin interfaz gráfica (headless mode) a través de un puerto de depuración remota.

Posteriormente, se emitieron varias solicitudes para obtener un código de autorización OAuth, que luego se intercambió por un token de acceso para acceder a los recursos objetivo a través de la API. Esta técnica ha sido denominada "Shadow Token via Remote Debug" (STRD) por el proveedor ruso de ciberseguridad.

Lo más destacable de este ataque es que funciona en navegadores basados ​​en Chromium y aprovecha una sesión activa de Gmail. En otras palabras, la idea es ejecutar el navegador en modo sin interfaz gráfica, conectarse a través del puerto de depuración remota para tomar el control y utilizar una sesión de Gmail ya iniciada para acceder a los recursos de la cuenta de Google.

Se han descubierto tres versiones diferentes de Umbrij, incluyendo versiones con funciones auxiliares para la depuración y para buscar y seleccionar cuentas de usuario dentro del navegador.

ToddyCat es el nombre asignado a una amenaza persistente avanzada (APT) que ha atacado a diversas organizaciones en Europa y Asia desde al menos 2020. En noviembre de 2025, Kaspersky detalló el uso que hizo el grupo de una herramienta personalizada llamada TCSectorCopy para obtener datos de correo electrónico de Microsoft Outlook pertenecientes a las empresas objetivo.

La empresa de ciberseguridad declaró haber descubierto Umbrij durante una operación de búsqueda de amenazas, en la que se utilizó una tarea programada que suplantaba la identidad de su software ("KasperskyEndpointSecurityEDRAvp") para ejecutar un archivo firmado digitalmente. Este archivo, a su vez, ejecutó Umbrij mediante la carga lateral de DLL.

Para lograrlo, se aprovecharon tres binarios legítimos vulnerables a la carga lateral de DLL:

• BDSubWiz.exe, un componente del Asistente de Envío de Bitdefender ConnectAgent;
• VSTestVideoRecorder.exe, un componente de la herramienta de grabación de vídeo utilizada para realizar pruebas con Microsoft Visual Studio;
• GoogleDesktop.exe, una aplicación de búsqueda de escritorio de Google ya descontinuada que se utilizaba para indexar archivos y realizar búsquedas rápidas en un equipo Windows local.

Independientemente del ejecutable utilizado, el resultado final es el mismo: la ejecución de la DLL maliciosa de Umbrij, escrita en .NET y ofuscada con ConfuserEx, un ofuscador de código abierto. La herramienta también puede ejecutarse mediante parámetros de línea de comandos que especifican los navegadores a los que dirigirse (Google Chrome o Microsoft Edge), le indican que guarde una captura de pantalla del perfil de usuario como archivo PDF y proporcionan el nombre de usuario del sistema con el que se ejecutará la herramienta.

Umbrij, al igual que la mayoría de las herramientas del conjunto de herramientas de ToddyCat, registra sus acciones en detalle y las guarda en un archivo. También guarda el código de autorización recuperado en este archivo de registro, que el operador posteriormente extrae del host comprometido."

"El código de autorización obtenido se intercambia por un token de acceso OAuth. Los ciberdelincuentes utilizan ese token para conectarse a la cuenta de Gmail a través de la API, comprometiendo así las comunicaciones de correo electrónico corporativas."

Para contrarrestar la amenaza, se recomienda revisar los códigos de autorización otorgados a las aplicaciones accediendo a "myaccount.google[.]com/connections" y buscando aplicaciones llamadas "Google Workspace Migration for Microsoft Outlook" o "Google Workspace Sync for Microsoft Outlook". Si alguna de estas aplicaciones está presente y no se utiliza en la organización, es fundamental revocar su acceso para invalidar los tokens OAuth.

"El grupo APT ToddyCat continúa buscando formas de comprometer las comunicaciones de correo electrónico corporativas", afirmó Andrey Gunkin, analista sénior de malware en Kaspersky. Su nueva herramienta, Umbrij, automatiza los intentos de los atacantes por acceder a las cuentas de correo electrónico de las organizaciones. Esta automatización no solo contribuye a aumentar la escala y la frecuencia de sus ataques, sino que también demuestra la gran motivación y las avanzadas habilidades técnicas de ToddyCat.

Fuente: THN

Seguir leyendo...

Ataque de fuerza bruta masivo contra CLI de Azure

Investigadores de ciberseguridad de Huntress han alertado sobre un ataque masivo, continuo y automatizado de fuerza bruta contra contraseñas dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, que ha comprometido decenas de cuentas.

Según Huntress, la actividad se origina en un rango de direcciones IPv6 (2a0a:d683::/32) controlado por el proveedor de infraestructura de internet LSHIY LLC (AS32167).

Entre el 12 y el 26 de junio, el atacante realizó más de 81 millones de intentos de inicio de sesión y logró comprometer al menos 78 cuentas de Microsoft en 64 organizaciones. "La estrategia de estos ataques parece basarse exclusivamente en la frecuencia de las contraseñas en las listas de combinaciones de contraseñas comprometidas, sin estar específica para ningún tipo de empresa o sector".

Lo que hace que este ataque de fuerza bruta sea relevante no es solo su magnitud, sino también el hecho de que muchas de las organizaciones afectadas tenían habilitadas las políticas de acceso condicional. En concreto, se ha descubierto que la campaña aprovecha un flujo de OAuth obsoleto llamado Credenciales de Contraseña del Propietario del Recurso (ROPC) para eludir las protecciones de la Política de Acceso Condicional (CAP).

ROPC es un tipo de concesión de OAuth 2.0 heredado en el que un usuario proporciona directamente su nombre de usuario y contraseña a una aplicación cliente, que luego envía estas credenciales a un servidor de autorización para intercambiarlas por un token de acceso. Se dejó de usar en OAuth 2.1.

En su documentación, Microsoft recomienda a los clientes no usar el flujo ROPC, argumentando que es incompatible con la autenticación multifactor (MFA).

"En la mayoría de los casos, existen alternativas más seguras que se recomiendan. Este flujo requiere un alto grado de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Solo debe usarse cuando no sea viable usar flujos más seguros", afirma el gigante tecnológico.

Se dice que los ataques de fuerza bruta contra credenciales y tokens resultaron en un puñado de inicios de sesión exitosos por día entre el 12 y el 21 de junio de 2026, con un promedio de dos a cuatro cuentas comprometidas diariamente, con la excepción del 19 de junio, cuando se vieron comprometidas 12 cuentas de usuario (también conocidas como identidades). El ritmo constante cambió el 22 de junio, cuando 30 identidades de 23 empresas se vieron afectadas.

En total, 78 cuentas de usuario se vieron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de los ataques de fuerza bruta contra contraseñas provino de LSHIY LLC. Algunas de las direcciones IP corresponden a Estados Unidos, mientras que otras corresponden a China.

"Estos ataques forman parte de una oleada generalizada de ataques de fuerza bruta contra credenciales en varios sistemas autónomos (ASN)", declaró Huntress, añadiendo que ha observado un aumento de más de 155 veces en el volumen de ataques de este tipo entre sus clientes. "Los ataques surgieron especialmente entre finales de mayo y principios de junio, con un promedio actual de aproximadamente 1964 ataques fallidos al mes por cada cliente protegido por Huntress".

La actividad parece centrarse específicamente en el uso de combinaciones antiguas de nombre de usuario y contraseña que ya habían sido vulneradas, pero que nunca se habían actualizado. El uso del vector ROPC permitió a los atacantes dirigirse a empresas que habían implementado la autenticación multifactor (MFA), pero que no la tenían configurada para gestionar los inicios de sesión ROPC de la CLI de Azure.

"ROPC se considera problemático por varias razones, pero una de ellas es que no ofrece compatibilidad con flujos de autenticación modernos como MFA o SSO. Esto significa que, como vimos en esta campaña, ROPC envía la contraseña directamente al punto final /token sin solicitar la autenticación multifactor de forma interactiva", explica Huntress.

Esto incluía escenarios en los que no se activaba la autenticación multifactor (MFA):

• Aplicar la MFA solo para aplicaciones específicas, en lugar de para "Todas las aplicaciones en la nube", lo que impedía cubrir los inicios de sesión de la CLI de Azure utilizados por los ciberdelincuentes.
• Aplicar la MFA solo para grupos de usuarios específicos, como los administradores.
• Aplicar la MFA solo cuando las solicitudes se originaban en ubicaciones no confiables.

"Cabe destacar que ocho empresas afectadas por la campaña no contaban con ninguna política de autenticación multifactor (MFA): Si bien los ciberdelincuentes lograron acceder a pesar de tener MFA configurada, la conclusión no debe ser que MFA no funcione en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas correctamente para abordar el flujo de autorización utilizado en estos incidentes".

Para contrarrestar este tipo de ataque, se recomienda a las organizaciones que exijan MFA para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente al habilitar CAP, que restrinjan el acceso a la aplicación Azure CLI para usuarios que no sean administradores y que prioricen la respuesta según la validez de las credenciales.

Este ataque revela vulnerabilidades en los CAP que no se han configurado adecuadamente. Todavía existen posibles debilidades en la implementación de los CAP que pueden permitir que los ciberdelincuentes se filtren. Un error evidente es que los protocolos heredados como ROPC pueden eludir por completo algunos CAP mal configurados, ya que no pasan por el punto final de autorización donde se aplican las políticas.

El rango de direcciones IPv6 desde el que se originaron los ataques pertenece a LSHIY, un proveedor de infraestructura de internet registrado en Hong Kong, Wuhan (China) y Nueva York. También existen otros informes que indican que los rangos de IPv6 asociados con AS32167 y AS955, dos sistemas autónomos (ASN) operados por la empresa, se originan en China.

Fuente: THN

Seguir leyendo...

CitrixBleed: seis vulnerabilidades de NetScaler permiten la lectura de archivos y ataques de denegación de servicio

Ayer Citrix publicó actualizaciones de seguridad para solucionar múltiples fallos en NetScaler ADC (anteriormente Citrix ADC) y NetScaler Gateway (anteriormente Citrix Gateway) que podrían ser explotados por un atacante para facilitar la lectura arbitraria de archivos o provocar una denegación de servicio (DoS).

Las vulnerabilidades se enumeran a continuación:

• CVE-2026-8451 (CVSS: 8.8): Vulnerabilidad de validación de entrada insuficiente que provoca una lectura excesiva de memoria cuando NetScaler ADC o NetScaler Gateway se configura como un IDP SAML.
• CVE-2026-8452 (CVSS: 8.8): Vulnerabilidad de desbordamiento de memoria que provoca un comportamiento impredecible o erróneo y una denegación de servicio cuando el dispositivo se configura como una puerta de enlace o un servidor virtual AAA.
• CVE-2026-8655 (CVSS: 8.8): Múltiples vulnerabilidades de desbordamiento de memoria que provocan un comportamiento impredecible o erróneo y una denegación de servicio cuando NetScaler ADC se configura como un balanceador de carga de tipo Oracle, un proxy DNS o una implementación de resolución recursiva DNS.
• CVE-2026-10816 (CVSS: 7.7): Control externo del Vulnerabilidad de ruta de archivo que permite la lectura arbitraria de archivos sin autenticación cuando el acceso a NSIP, la IP de administración del clúster o SNIP con acceso de administración está habilitado.
• CVE-2026-10817 (CVSS: 6.9): Vulnerabilidad de validación de entrada insuficiente que provoca una lectura excesiva de memoria cuando TCP TimeStamp está habilitado en el perfil TCP y asociado con el servidor virtual (de tipo LB, CS, VPN) o el servicio configurado en NetScaler.
• CVE-2026-13474 (CVSS: 8.7): Vulnerabilidad de liberación de memoria faltante después del tiempo de vida efectivo que provoca una denegación de servicio mediante solicitudes HTTP/2 mal formadas cuando HTTP/2 está habilitado en el perfil HTTP y asociado con el servidor virtual (de tipo LB, CS, VPN) o el servicio configurado en NetScaler.

Se han publicado parches para las vulnerabilidades de seguridad en las siguientes versiones:

• NetScaler ADC y NetScaler Gateway 14.1-72.61 y versiones posteriores
• NetScaler ADC y NetScaler Gateway 13.1-63.18 y versiones posteriores de la versión 13.1
• NetScaler ADC 14.1-FIPS, 14.1-72.61 FIPS y versiones posteriores de la versión 14.1-FIPS
• NetScaler ADC 13.1-FIPS y 13.1-NDcPP, 13.1.37.272 y versiones posteriores de las versiones 13.1-FIPS y 13.1-NDcPP

En cuanto a la vulnerabilidad CVE-2026-13474, se recomienda a los clientes que actualicen sus configuraciones modificando el parámetro Http2SmallWndTimeout, que controla el tiempo de espera (en segundos) para las transmisiones HTTP/2 de ventana pequeña bloqueadas.

Para los dispositivos que utilizan perfiles HTTP estrictos, este parámetro tiene un valor predeterminado de 30 segundos. La solución se aplica inmediatamente después de la actualización.

Para los dispositivos que NO utilizan perfiles HTTP estrictos, el valor predeterminado es 0. En este caso, la simple actualización a las versiones que incluyen la solución no resolverá la vulnerabilidad por completo. Los clientes deben configurar manualmente Http2SmallWndTimeout a 30 segundos.

El comando para configurar este parámetro se muestra a continuación:

set ns httpProfile <profile_name> -http2SmallWndTimeout <value_in_seconds>

Cisco reconoció la labor de Michael Tucker del equipo XOR de JPMorgan Chase, Aliz Hammond de watchTowr y Maxim Suhanov por reportar las vulnerabilidades. No hay evidencia de que estos problemas se hayan explorado en entornos reales.

watchTowr Labs, en un informe técnico publicado junto con el boletín de Citrix, indicó que la vulnerabilidad CVE-2026-8451 se descubrió y reportó a finales de marzo de 2026 tras intentos de reproducir la CVE-2026-3055 (CVSS: 9.3), una vulnerabilidad independiente de validación de entrada insuficiente que se dio a conocer a principios de este año.

La empresa de ciberseguridad afirmó que la vulnerabilidad se origina en la forma en que NetScaler analiza las solicitudes de autenticación SAML y comparte la misma causa raíz que la vulnerabilidad de marzo de 2026, lo que provoca lecturas de memoria fuera de los límites al enviar solicitudes SAML mal formadas.

"Un aspecto que nos interesa destacar es que, a diferencia de la vulnerabilidad original CVE-2026-3055, que permitía la filtración de kilobytes de datos binarios, esta lectura excesiva interrumpe la lectura fuera de límites cuando se leen diversos caracteres de control, como NULL (o incluso >)", explicó el investigador de seguridad Hammond. "En la práctica, comprobamos que, variando la longitud de la solicitud, podíamos extraer consistentemente algunos bytes del servidor. Sin embargo, lo que debería preocuparnos es el panorama general: la tendencia, que sugiere claramente que la gestión de memoria sigue siendo vulnerable en los dispositivos Citrix NetScaler, hasta el punto de que incluso una configuración incorrecta accidental puede provocar la filtración de memoria".

En los últimos años, los dispositivos Citrix han sido un objetivo lucrativo para los ciberdelincuentes, quienes han explotado múltiples fallos de seguridad en su software para el despliegue de ransomware. Por ello, es fundamental que los usuarios apliquen los parches para una protección óptima.

Fuente: THN

Seguir leyendo...

Explotan activamente una vulnerabilidad crítica de Oracle E-Business Suite

Actores maliciosos están explotando activamente la vulnerabilidad CVE-2026-46817, una vulnerabilidad crítica de acceso remoto sin autenticación en Oracle E-Business Suite (EBS). Se detectó actividad de ataque en tiempo real en infraestructura honeypot durante el fin de semana del 27 y 28 de junio de 2026.

CVE-2026-46817 es una vulnerabilidad de gravedad crítica que reside en el producto Oracle Payments dentro de Oracle E-Business Suite, específicamente en el componente de transmisión de archivos. La vulnerabilidad tiene una puntuación base CVSS de 9.8 y permite que un atacante no autenticado con acceso a la red a través de HTTP comprometa completamente Oracle Payments, lo que conlleva el control total de la confidencialidad, la integridad y la disponibilidad.

Esta vulnerabilidad de seguridad se descubrió en el componente de transmisión de archivos del producto Oracle Payments de EBS y permite que agentes maliciosos no autenticados con acceso a la red HTTP se apoderen de sistemas vulnerables mediante ataques de baja complejidad.

Las versiones afectadas abarcan desde Oracle E-Business Suite 12.2.3 hasta 12.2.15. El vector CVSS refleja la baja complejidad del ataque y la ausencia de requisitos de autenticación, lo que facilita su explotación a gran escala.

Aunque no existe código de prueba de concepto (PoC) público, esta es la primera explotación real conocida de esta vulnerabilidad, lo que indica que el atacante podría estar utilizando capacidades de explotación desarrolladas de forma privada.

El tráfico de ataque capturado en los honeypots de Defused reveló solicitudes POST dirigidas a /OA_HTML/ibytransmit, el punto final de transmisión de archivos de Oracle iPayment.

La IP del atacante, 45.84.137[.]125, operando a través de AS136787 PacketHub S.A. (Francia), se dirigió al puerto 443 y envió una carga útil XML DeliveryRequest manipulada.

La carga útil contenía un esquema de transmisión CODEX_PULL, con el parámetro FULL_FILE_PATH configurado en /etc/passwd, un indicador clásico de una cadena de explotación de lectura de archivos locales/recorrido de rutas diseñada para extraer archivos confidenciales del sistema.

Según Shadowserver, el 28 de junio se registraron un total de 456 ataques en todas las regiones monitorizadas, con Norteamérica (193) y Asia (181) concentrando la mayor parte del tráfico. Europa registró 53 ataques, Sudamérica 18, África 9 y Oceanía 2.

Oracle abordó la vulnerabilidad CVE-2026-46817 en su Actualización Crítica de Parches de Seguridad (CSPU), publicada el 28 de mayo de 2026. Esta actualización corrigió 35 vulnerabilidades CVE distintas en diversas familias de productos de Oracle, 11 de las cuales se clasificaron como críticas.

Oracle recomendó encarecidamente a todos sus clientes que aplicaran los parches inmediatamente después de su publicación. Posteriormente, el 16 de junio de 2026, se publicó una CSPU complementaria que reforzó la postura de Oracle respecto a las vulnerabilidades.

Las organizaciones que utilizan Oracle E-Business Suite deben actuar de inmediato:

• Aplicar sin demora el parche CSPU de mayo de 2026 para las versiones 12.2.3 a 12.2.15 de EBS.
• Bloquee o restrinja el acceso público a internet a las interfaces de Oracle EBS, en particular a la ruta /OA_HTML/.
• Auditar los registros del servidor web en busca de solicitudes POST a /OA_HTML/ibytransmit con cargas útiles XML inusuales.
• Investigar la IP del atacante (45.84.137[.]125) y la cadena User-Agent (ibytransmit-lab-poc/1.0) en los registros del firewall y del proxy.
• Realizar una evaluación de la vulnerabilidad si la aplicación del parche se retrasó más allá del 28 de mayo de 2026.

Dada la ausencia de código PoC público y la aparición confirmada de herramientas de explotación privadas, las implementaciones de Oracle EBS sin parchear siguen expuestas a un grave riesgo de sufrir una vulneración total del sistema.

Fuente: CyberSecurityNews

Seguir leyendo...

Microsoft extiende el soporte gratuito de ESU para Windows 10 hasta octubre de 2027

El 14 de octubre de 2025, Windows 10 llegó al final del soporte y Microsoft ya no brinda soporte técnico, actualizaciones de funciones o actualizaciones de seguridad para el sistema operativo a menos que esté ejecutando una versión LTSC de Windows.

Para aquellos que no pueden actualizar a Windows 11, Microsoft originalmente ofreció a los consumidores un año adicional de actualizaciones de seguridad si se inscribían en un programa gratuito de actualizaciones de seguridad extendidas (ESU) que expiraría el 12 de octubre de 2026.

Ahora, Microsoft ha extendido silenciosamente su programa gratuito de Actualizaciones de seguridad extendidas (ESU) de Windows 10 para consumidores por un año adicional, lo que permite que los dispositivos inscritos continúen recibiendo actualizaciones de seguridad hasta el 12 de octubre de 2027.

El cambio se realizó sin un anuncio formal y, en cambio, apareció en actualizaciones de la documentación ESU de Windows 10 de Microsoft y como una "nota del editor" de una publicación del blog Windows Experience publicada ayer.

"Nota del editor – 25 de junio de 2026 – Esta publicación se actualizó para reflejar que el programa de Actualizaciones de seguridad extendidas (ESU) de Windows 10 para dispositivos de uso personal se proporciona por un año adicional, con cobertura ahora disponible hasta el 12 de octubre de 2027", se lee en la publicación de blog actualizada.

Esta extensión brinda a los clientes más tiempo para realizar la transición a una nueva PC con Windows 11 mientras continúan recibiendo actualizaciones de seguridad críticas.

Los clientes empresariales también podrían inscribirse en el programa ESU por hasta tres años, lo que eleva el costo total por dispositivo a $427 durante ese período.

Cuando se le preguntó por qué se amplió el programa ESU gratuito, Microsoft compartió la siguiente declaración con BleepingComputer: "Entendemos que pasar a una nueva PC puede llevar tiempo. Como parte de nuestro compromiso continuo de ayudar a los clientes a mantenerse seguros durante la transición, el programa de actualizaciones de seguridad extendidas (ESU) de Windows 10 para dispositivos personales se ofrece por un año adicional", explicó Microsoft.

Los consumidores pueden seguir recibiendo seguridad ampliada de forma gratuita utilizando uno de estos métodos:

• Pagando $30.
• Hacer una copia de seguridad de su configuración de Windows en su cuenta de Microsoft.
• Canjear 1000 puntos de recompensa de Microsoft.
• Los usuarios del Espacio Económico Europeo pueden recibir ESU de forma gratuita iniciando sesión en Windows 10 con una cuenta de Microsoft.

Microsoft dice que una licencia ESU se puede usar en hasta 10 dispositivos asociados con la misma cuenta de Microsoft, y los usuarios ya inscritos permanecerán cubiertos automáticamente hasta la nueva fecha final de octubre de 2027.

La compañía señala que el programa ESU para consumidores es solo para dispositivos personales y no está disponible para sistemas unidos a dominios de Active Directory, Microsoft Entra o administrados a través de Mobile Device Management (MDM). Sin embargo, los dispositivos registrados en Microsoft Entra son elegibles.

Fuente: BC

Seguir leyendo...

Pedit COW: nueva vulnerabilidad en Linux permite a los usuarios obtener root

Una nueva vulnerabilidad de Linux permite el acceso de administrador mediante la manipulación de binarios en caché. La vulnerabilidad en el subsistema de control de tráfico del kernel de Linux permite que un usuario local sin privilegios obtenga acceso de root en los sistemas afectados.

La vulnerabilidad CVE-2026-46331, apodado "pedit COW", permite a los usuarios locales obtener acceso de administrador en sistemas Linux afectados corrompiendo la memoria caché de páginas a través de act_pedit.

Esta vulnerabilidad es una escritura fuera de límites en la acción de edición de paquetes (act_pedit) que corrompe la memoria caché de páginas compartida. Un exploit público y funcional apareció apenas un día después de la asignación de la CVE, el 16 de junio. Red Hat considera esta vulnerabilidad importante.

El exploit nunca accede al archivo en disco. Envenena la copia en caché de un binario de root setuid (/bin/su) en memoria, inyecta una pequeña carga útil y ejecuta esa imagen modificada como root. Las comprobaciones de integridad de archivos no generan ningún problema mientras ya hay una shell de root abierta.

El exploit requiere dos condiciones: que act_pedit sea cargable y que los espacios de nombres de usuario sin privilegios estén abiertos, lo que otorga al atacante la capacidad de red local del espacio de nombres (CAP_NET_ADMIN) necesaria para activar el fallo.

En los sistemas RHEL y Debian probados, ambas condiciones estaban presentes.

Cómo funciona el error

La herramienta de control de tráfico tc de Linux puede reescribir las cabeceras de los paquetes en tránsito mediante una acción llamada pedit. La función del kernel que realiza esta acción, tcf_pedit_act(), debería crear una copia privada de los datos antes de editarlos, siguiendo el patrón estándar de copia en escritura.

Se verifica el rango de escritura una sola vez, antes de conocerse los desplazamientos finales. Algunas claves de edición solo resuelven su desplazamiento en tiempo de ejecución. Cuando esto sucede, la escritura se produce fuera de la región copiada privadamente, por lo que el kernel modifica una página de la caché de páginas compartida en lugar de una copia privada. Si esa página pertenece a un archivo en caché, la imagen en memoria del archivo se corrompe.

El patrón es conocido. Dirty Pipe, Copy Fail, Dirty Clone y Dirty Frag comparten la misma estructura: una ruta rápida del kernel escribe en una página que no le pertenece exclusivamente, y la caché de páginas sufre la penalización.

La novedad reside en el punto de entrada. Un usuario sin privilegios puede configurar las acciones de tc desde dentro de un espacio de nombres de usuario, lo que le otorga el CAP_NET_ADMIN que necesita el exploit.

Sistemas afectados

El autor de la prueba de concepto informó de una explotación de usuario sin privilegios a root en RHEL 10 y Debian 13 (trixie), donde los espacios de nombres de usuario sin privilegios están abiertos por defecto. Ubuntu 24.04 requería enrutar la ejecución a través de perfiles de AppArmor que aún permitían espacios de nombres de usuario. Ubuntu 26.04 bloquea esta ruta por defecto, ya que sus perfiles de AppArmor restringen los espacios de nombres de usuario sin privilegios, aunque el kernel subyacente sigue siendo vulnerable.

Las correcciones varían según el proveedor.

• Debian ha corregido trixie a través de su canal de seguridad. Debian 11 y 12 siguen figurando como vulnerables.
• Ubuntu enumera las versiones compatibles desde la 18.04 hasta la 26.04 como vulnerables a fecha de 25 de junio.
• Red Hat enumera RHEL 8, 9 y 10 como afectadas; RHEL 7 no aparece en el boletín.

Qué hacer

Instalar el kernel parcheado y reiniciar. Priorizar los sistemas donde "usuario local" no significa usuario de confianza: hosts multiusuario, ejecutores de CI/CD, nodos de Kubernetes, trabajadores de compilación y máquinas compartidas de investigación o laboratorio.

Si aún no puedes aplicar el parche, existen dos medidas para interrumpir la cadena de explotación. En sistemas que no requieren reglas de `tc pedit`, verifica si el módulo está en uso:

lsmod | grep act_pedit
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf`

Como alternativa, desactivar los espacios de nombres de usuario sin privilegios (user.max_user_namespaces=0 en RHEL, kernel.unprivileged_userns_clone=0 en Debian/Ubuntu). Esto elimina la capacidad de acceso local al espacio de nombres que necesita la explotación, pero afecta a los contenedores sin privilegios de root, a algunos entornos aislados de CI y a los navegadores aislados. Realiza pruebas antes de comenzar.

Dado que la sobrescritura se realiza en la memoria caché, es posible que las comprobaciones de integridad de archivos no la detecten. Se puede vaciar la caché de páginas:

echo 3 > /proc/sys/vm/drop_caches

Con esto se borra la copia en memoria infectada, pero no se soluciona el problema de la shell de root que el atacante ya había abierto. Se debe considerar el host como comprometido.

La solución se publicó en la lista de correo de netdev a finales de mayo, presentada como un parche rutinario para la corrupción de datos. El detalle explotable permaneció en una lista de correo pública durante semanas. Se incluyó en la advertencia de seguridad CVE. La CVE se asignó cuando se integró la solución el 16 de junio. La prueba de concepto con potencial de explotación se publicó al día siguiente. Para los errores de corrupción de la caché de páginas del kernel, esperar a que se complete una regla de escaneo es demasiado lento.

Aquí hay un repositorio para validarlo.

Fuente: THN

Seguir leyendo...

Vulnerabilidades explotadas: ya no puedes salir de esto con parches

Durante treinta años, la gestión de vulnerabilidades se ha basado en lo que ahora parece un lujo imposible: un margen de meses entre el momento en que se encontró una vulnerabilidad y el momento en que alguien pudo descubrir cómo convertirla en un arma. Clasificar por gravedad, programar la solución, validar y seguir adelante.

Ese generoso amortiguador es lo que hizo que todo el sistema funcionara.

La IA ha eliminado el arrastre manual que hacía que la creación y utilización de "armas" fuera lenta. Leer el aviso, encontrar el camino, dar forma a la cadena, probar qué funciona: nada de eso puede darse el lujo de moverse a la velocidad humana. Hoy en día, los plazos desde la divulgación hasta la explotación son de horas, no de meses.

El Zero Day Clock, que rastrea esto en tiempo real, actualmente tiene un promedio de alrededor de 8 horas para 2026, frente a aproximadamente 53 días hace apenas dos años. La cifra cambia a medida que llegan nuevos datos, pero en este punto se sitúa firmemente por debajo de las 24 horas.

No puedes salir de esto con parches

El reflejo suele ser simplemente parchear más rápido. Pero la remediación no es simplemente un interruptor que se activa. Los parches esperan una serie de contingencias: pruebas de regresión, ventanas de cambio y compromisos de tiempo de actividad. Y hoy, lamentablemente, todos los números que importan van en la dirección equivocada.

El Informe de investigaciones de vulneración de datos de 2026 de Verizon, elaborado en más de 13.000 organizaciones, encontró que:

• El tiempo medio de reparación de vulnerabilidades conocidas y explotadas es ahora de 43 días, frente a los 32 del año pasado.
• La proporción de organizaciones que los parchean completamente se redujo del 38% al 26%.
• Incluso los que tienen mejor desempeño cierran sólo entre el 30 y el 40% de estas vulnerabilidades en la primera semana, una tasa que apenas ha variado en años.

Cuando la infracción se desarrolla en horas y la reparación en semanas, la infracción se produce en el medio. Y la pista cada vez es más larga.

El volumen lo garantiza: 48.185 CVE en 2025, menos del 0,6% jamás parcheados. "Parchear para salir" ha dejado de ser una matemática viable.

Mythos es el umbral en el que los modelos de IA fueron capaces de encontrar y convertir en armas vulnerabilidades por sí solos, y no es teórico: el modelo de clase Mythos de Anthropic encontró una falla que había estado oculta en OpenBSD, ampliamente considerado como uno de los sistemas operativos más seguros del mundo, durante 27 años.

La línea de base para 2025 se ha convertido en el piso, no en el techo.

La pregunta ya no es "¿qué es vulnerable?" porque en una lista donde todo tiene una puntuación de 9 o 10, esto efectivamente no prioriza nada. La verdadera pregunta es: "¿Qué es realmente explotable contra nosotros en este momento, con los controles que ya estamos aplicando?". Encontrar la exposición nunca fue la parte difícil. Demostrar la decisión correcta (parchear, mitigar, monitorear o aceptar) es la brecha crítica.

Las herramientas de pentesting automatizados toman la prueba de penetración manual que solía realizarse una vez por trimestre y la ejecutan continuamente, a escala, activando cadenas de exploits reales contra activos reales. Donde se puede ejecutar eso, es la prueba más fuerte que existe: ves cómo el exploit tiene éxito. Pero, aunque automatizar el lanzamiento te hace más rápido; no cambia lo que puede alcanzar la explotación.

La explotación en vivo solo funciona cuando es seguro activar un exploit y cuando existe un exploit funcional. Eso deja tres espacios en la herramienta pentest que se pueden cerrar, y apilarlos juntos tampoco ayuda. ¿Por qué?

• Sin exploit, nada que ejecutar. Una gran parte de los CVE divulgados nunca obtienen un exploit público o seguro. Sin nada que iniciar, la ejecución no puede indicarle si son explotables en su entorno.
• Activos que no puedes arriesgar. Los sistemas críticos para el negocio, regulados y aislados son exactamente aquellos contra los que no se puede detonar un exploit de forma segura y, por lo general, son los que más importan.
• La ventana del primer día. Armar un nuevo exploit y conectarlo a sus herramientas lleva tiempo. Los atacantes ya se están moviendo mientras tu lanzamiento todavía está en el banco.

En una empresa típica, la porción que puede explotar de forma segura en vivo suele ser sólo del 10 al 15% de su imagen de exposición total. Para el 85% o 90% restante, la ejecución no tiene respuesta que dar.

Probar en tierra un cohete que no se puede lanzar

La forma más segura de demostrar que un cohete volará es lanzarlo. Pero ningún programa espacial demuestra que su flota sea así.

Algunos existen sólo como un diseño en papel, otros cuentan con tripulación y son demasiado valiosos para arriesgarlos, y otros todavía están en la línea de ensamblaje. Así que los ingenieros los prueban en tierra: el motor empuja en una posición estática, prueba el sistema de combustible bajo presión total y el escudo térmico contra su carga térmica máxima. Si algún componente requerido falla, el cohete no puede volar y ellos lo saben sin abandonar la plataforma.

Ésa es la misma brecha de tres partes que enfrentan los equipos de seguridad.

• El CVE sin exploits es el cohete que sólo existe en el papel.
• El activo prohibido es el cohete tripulado que no arriesgarás.
• El CVE del primer día es el fuselaje parcialmente construido mientras se agota la ventana de lanzamiento.
• El lanzamiento es la prueba a la que llegas cuando puedes; la prueba sobre el terreno es la prueba en la que confías cuando no puedes.

Romper la cadena, rompe el exploit

Un exploit no es mágico. Es una cadena de técnicas específicas, los TTP que un atacante tiene que ejecutar en secuencia: obtener ejecución, eludir una protección, escalar privilegios, deshacerse de credenciales, avanzar hacia el objetivo.

Cada enlace depende de las condiciones de su entorno, y cada uno puede probarse por sí solo con los controles implementados reales, de la misma manera que un ingeniero prueba un motor en un soporte estático sin tener que arrancar todo el vehículo.

Esa es la validación de la cadena TTP. Usted asigna un CVE a la cadena de técnicas que requiere su explotación y luego valida cada técnica con sus controles existentes. Si su entorno rompe algún vínculo requerido, el exploit no podrá tener éxito allí y usted lo sabrá sin tener que activar un exploit activo. Si todos los vínculos se mantuvieran, la exposición sería genuinamente explotable, con evidencia.

Cuatro cosas distintas que veredicto de una etiqueta CVSS o EPSS estática:

• Valida por inferencia, no por detonación. Por lo tanto, funciona donde la explotación en vivo sería insegura o imposible.
• Es consciente del control. El veredicto refleja su EDR, GPO, protección LSASS, lista de permitidos y firewall reales, no solo un número en una hoja de datos.
• Pesa la accesibilidad. Las exposiciones contenidas no se contabilizan en exceso.
• Envía pruebas. La cadena, los controles probados y el resultado: una pista de auditoría que llega hasta la junta directiva.

Cómo se ve en un CVE real

Tomemos como ejemplo CVE-2025-29824, un uso después de la liberación de CLFS de Windows que escala a SYSTEM (visto en estado salvaje en la actividad Storm-2460 o RansomEXX).

En lugar de activar un exploit, lo descompones en la cadena que un atacante debe ejecutar y prueba cada paso con tu pila:

• Ejecución de certutil y MSBuild – T1105 / T1127
• Bypass KASLR / SysInfo – T1082
• Explotación CLFS UAF → ejecución del kernel – T1068
• modificación de token e inyección de dllhost – T1134 / T1055
• Volcado de LSASS a través de dllhost enmascarado – T1003

Cada técnica se prueba con respecto a la política de EDR, GPO/refuerzo, protección LSASS, lista de aplicaciones permitidas y NGFW.

Si su lista de permitidos detiene el ejecutivo de MSBuild, o su protección LSASS bloquea el volcado de credenciales, la cadena se rompe, el CVE no es explotable en ese activo y puede mostrar exactamente por qué. No se necesita un exploit certificado y funciona en la caja aislada a la que nunca apuntarías un exploit en vivo. Y al hacerlo, ha pasado de una nueva identificación CVE a una decisión defendible en horas, el día de la divulgación, en lugar de semanas después.

Pruébelo en todas partes, no sólo donde pueda lanzarlo

El lanzamiento y la prueba en tierra no son rivales, son simbióticos. Los programas más potentes ejecutan ambos y siguen probando a medida que el entorno avanza a través del tiempo y las configuraciones.

Se pueden ejecutar cadenas de exploits en vivo donde el disparo es seguro, encadenamiento TTP para los activos fuera de los límites y CVE del primer día que un lanzamiento no puede alcanzar, y validación de control continuo para que la "aceptación" del último trimestre se vuelva a probar, no se asuma.

Esto da una respuesta a la única pregunta que importa: "¿Qué es realmente explotable aquí y ahora?"

Fuente: BC

Seguir leyendo...