Los clientes de SonicWall están amenazados porque los atacantes explotan 2 días cero

Los clientes de SonicWall están intentando esquivar otro desafío de seguridad mientras los atacantes explotan un par de vulnerabilidades de día cero que han sido confirmadas por el proveedor.

La empresa reveló públicamente las vulnerabilidades: CVE-2026-15409 y CVE-2026-15410 – en un aviso de seguridad Martes. SonicWall le dio crédito a un empleado por descubrir los defectos, pero no dijo cuándo ocurrió el descubrimiento ni cuál fue el primer caso conocido de explotación.

Los investigadores de Rapid7 dijeron a CyberScoop que ambas vulnerabilidades fueron explotadas por primera vez el 22 de junio. «A partir de los casos que nuestro equipo ha observado, el objetivo probablemente sea el ransomware, aunque hemos impedido que los actores lograran la exfiltración y el cifrado», dijo Seth Lazarus, gerente senior de servicios de detección y respuesta de Rapid7.

Las tácticas, técnicas y procedimientos superpuestos de los ataques observados por Rapid7 indican que el mismo grupo de amenaza o atacante descubrió y explotó los días cero, agregó Lazarus.

SonicWall no respondió preguntas sobre los impactos de estos ataques hasta el momento, y la compañía no ha atribuido los ataques a un grupo conocido ni ha descrito los orígenes y motivaciones del atacante.

Sin embargo, el proveedor confirmó a CyberScoop que ambas vulnerabilidades se han encadenado para su explotación. Las vulnerabilidades que afectan a los dispositivos SonicWall SMA1000, incluido un defecto de gravedad máxima que permite a los atacantes realizar solicitudes autenticadas y una vulnerabilidad con clasificación 7.2 que permite la inyección de comandos autenticados.

«Cuando estos dos están encadenados, un atacante puede pasar de un acceso cero a un compromiso completo del sistema del dispositivo afectado», dijo Landon Rice, desarrollador senior de exploits en VulnCheck.

Ben Harris, fundador y director ejecutivo de watchTowr, dijo que dos características de las vulnerabilidades alimentan una sensación de temor. «Ambos fueron explotados como días cero antes de que las soluciones estuvieran disponibles, y juntos ofrecen un camino plausible para la ejecución remota de código desde Internet», dijo.

La Agencia de Seguridad de Infraestructura y Ciberseguridad agregó ambos días cero a su catálogo de vulnerabilidades explotadas conocidas Martes.

SonicWall alentó a los clientes a corregir las vulnerabilidades actualizando a la última versión del software, que lanzó tras la divulgación, y compartió algunos indicadores de compromiso para ayudar a los clientes a buscar posibles actividades maliciosas en sus sistemas.

«La velocidad de respuesta era una prioridad para nosotros», afirmó Bret Fitzgerald, director senior de comunicaciones globales de SonicWall. «A los pocos días de tomar conciencia del problema, nuestro equipo desarrolló un script que podemos ejecutar en nombre de los clientes afectados para ayudar con la resolución, y los esfuerzos de mitigación ya están en marcha».

SonicWall y los investigadores externos no han dicho cuántos clientes de SonicWall se ven afectados por las vulnerabilidades explotadas, pero el proveedor dijo que ya investigó múltiples casos de explotación activa.

Fitzgerald dijo que la compañía monitorea alrededor de un millón de sensores en todo el mundo y que «los dispositivos SMA1000 representan un subconjunto muy pequeño de esa huella, menos de 5000 unidades».

SonicWall dijo que el personal de soporte también está ayudando a los clientes a resolver casos de actividad sospechosa, advirtiendo que aplicar parches por sí solos no es suficiente.

El proveedor y sus clientes se han visto afectados durante años por una avalancha de días cero explotados activamente y defectos previamente revelados en dispositivos SonicWall. En 2025, un actor de amenazas no revelado patrocinado por el estado invadió el entorno de nube de la empresa y robó las configuraciones de firewall de todos los clientes de SonicWall.

Se han agregado diecisiete defectos que afectan a los productos del proveedor al catálogo de vulnerabilidades explotadas conocidas de CISA desde finales de 2021. Se sabe que diez de esos defectos se utilizan en campañas de ransomware, según CISA, incluida una ola de alrededor de 40 ataques de ransomware Akira entre mediados de julio y principios de agosto.

«Como siempre», dijo Harris, «cuando se confirma que algo ya está explotado en la naturaleza, lo mínimo indispensable es aplicar parches y se debe asumir que se ha producido una infracción».

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

La suplantación de ID de cliente de OAuth permite a los atacantes validar las credenciales de Microsoft Entra robadas – CYBERDEFENSA.MX

Al menos dos actores de amenazas distintos están utilizando como arma una novedosa técnica de evasión llamada Falsificación de ID de cliente de OAuth en campañas en la nube, evitando al mismo tiempo la telemetría.

La actividad permite a los usuarios enumerar cuentas de usuario y validar credenciales robadas en entornos Microsoft Entra ID, sin generar nunca un evento de inicio de sesión exitoso que, de otro modo, alertaría a los defensores. Y los malos actores han comenzado a explotar esta brecha para obtener acceso no autorizado a los servicios en la nube de una organización.

«Un punto ciego en la telemetría de inicio de sesión en la nube: Entra ID devuelve diferentes respuestas de error dependiendo de si la ID de cliente OAuth proporcionada es válida», dijo Proofpoint en un comunicado. «Los atacantes aprovechan esto para inferir nombres de usuario válidos y contraseñas correctas a escala, verificando efectivamente las listas de credenciales robadas sin registrar un inicio de sesión exitoso».

En otras palabras, los ataques aprovechan el ID del cliente OAuth, un identificador único global (GUID) asignado a las aplicaciones cuando solicitan acceso a los datos del usuario, y se pasa como «id_cliente» en solicitudes de autenticación. Al proporcionar ID de cliente falsificados, permite la enumeración de cuentas sin una aplicación OAuth registrada y permite a los atacantes inferir tanto la contraseña como la validez de la cuenta sin generar un evento de inicio de sesión exitoso.

«El Registros de inicio de sesión de Entra son una fuente de telemetría principal para identificar actividades de autenticación maliciosas, incluida la enumeración de usuarios, la difusión de contraseñas y los intentos de acceso inicial», afirma Rachel Rabin, investigadora de Proofpoint. dicho.

Ciberseguridad

Grupos de amenazas como UNK_CustomCloak Se ha observado que falsifican cadenas de User-Agent para orquestar campañas de fuerza bruta dirigidas a entornos Microsoft Entra ID mediante la explotación de una aplicación propia heredada y descontinuada llamada Windows Live Custom Domains para eludir las restricciones de inicio de sesión estándar y sondear las contraseñas de los usuarios en más de 4000 inquilinos.

Pero los últimos esfuerzos marcan una evolución de este oficio al falsificar las ID de los clientes de OAuth a través de solicitudes HTTP POST al punto final del token OAuth 2.0 de Microsoft utilizando las credenciales de contraseña del propietario del recurso (ROPC) flujo. Específicamente, esto implica proporcionar un ID de cliente sintácticamente válido pero que no corresponda a una aplicación real.

En tales escenarios, solo se registra el ID de la aplicación en el registro de inicio de sesión de Entra sin el nombre de la aplicación correspondiente. La respuesta, que contiene un servicio de token de seguridad de Azure Active Directory (AADSTS), código de error, se puede utilizar para inferir si la cuenta existe y si la contraseña es correcta sin una aplicación registrada.

«Si el ID de cliente falsificado no es un UUIDv4 adecuado, Entra no rechaza la solicitud directamente», explicó Proofpoint. «Por lo tanto, los atacantes pueden analizar esta respuesta de error para identificar cuentas y contraseñas válidas, a pesar de utilizar ID de cliente con formato incorrecto».

«Cuando se utiliza una identificación de cliente falsificada, no se registra ningún nombre de aplicación correspondiente en el registro de inicio de sesión. Esto significa que las detecciones que buscan aumentos en un nombre de aplicación específico pueden perder esta actividad por completo, ya que el campo está en blanco».

Armados con esta información, los atacantes podrían identificar cuentas que podrían ser explotadas para un acceso sigiloso, al mismo tiempo que dificultaría a los defensores identificar actividades sospechosas.

Ciberseguridad

Proofpoint dijo que ha identificado dos grandes campañas que adoptaron la técnica de forma independiente hacia finales de diciembre de 2025, lo que indica que el enfoque se está incorporando cada vez más a las técnicas de los atacantes en lugar de ser un incidente aislado:

  • UNK_pyreq2323 (de enero a marzo de 2026), que utilizó más de 700 000 ID de clientes falsificados de la infraestructura de Amazon Web Services (AWS) para apuntar a más de 1 millón de cuentas en casi 4000 inquilinos, lo que provocó bloqueos para aproximadamente el 28 % de los usuarios objetivo debido a intentos fallidos.
  • UNK_OutFlareAZ (a partir de diciembre de 2025), que aprovechó la infraestructura de Cloudflare para dirigirse a más de 2 millones de usuarios con 3,7 millones de ID de aplicaciones falsificadas aleatorias.

Se ha observado que ambas campañas utilizan UUID válidos en lugar de identificadores con formato incorrecto y demuestran patrones que se alinean con listas de palabras de nombres de usuarios precompiladas. Dicho esto, mientras UNK_OutFlareAZ enumeró a los usuarios alfabéticamente, UNK_pyreq2323 no lo hizo. Otro aspecto en el que diferían era en cómo se falsificaban las identificaciones de los clientes.

Se dice que UNK_pyreq2323 modificó los dígitos finales de una ID de aplicación conocida y luego reutilizó ID falsificadas en hasta 12 usuarios. Por el contrario, UNK_OutFlareAZ generó una identificación de cliente única por solicitud.

«Al fragmentar los intentos de autenticación en muchas aplicaciones ficticias, la actividad se vuelve más difícil de correlacionar y puede evadir las detecciones por aplicación y la limitación de velocidad», dijo Proofpoint. «Las organizaciones pueden intentar mitigar los ataques de enumeración tradicionales aplicando políticas de acceso condicional dirigidas a aplicaciones comúnmente destinadas a la enumeración. Las ID de clientes falsificadas no activarán políticas de CA que estén dirigidas a una aplicación específica».

11 antiguas cuñas UEFI de Linux firmadas por Microsoft podrían permitir a los atacantes evitar el arranque seguro – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto 11 aplicaciones antiguas de Interfaz de firmware extensible unificada (UEFI) firmadas por Microsoft de las que se podría abusar para evitar el arranque seguro en la mayoría de los sistemas que utilizan el estándar de firmware moderno.

«Un atacante que explote una de estas aplicaciones vulnerables puede ejecutar código que no es de confianza durante el arranque del sistema, permitiendo la implementación de bootkits UEFI maliciosos u otro malware», dijo el investigador de ESET Martin Smolár. dicho en un informe publicado hoy.

Los cargadores de arranque UEFI exponen cualquier máquina basada en UEFI que confíe en Microsoft «Corporación Microsoft UEFI CA 2011«Certificado de autoridad certificadora (CA) UEFI de terceros, independientemente del sistema operativo instalado. El certificado se utiliza para firmar componentes de arranque de terceros destinados a ejecutarse bajo arranque seguro. Expiró el 27 de junio de 2026 y ha sido reemplazado por Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.

El shim es un gestor de arranque UEFI liviano y de código abierto que actúa como intermediario entre el firmware de la placa base de una computadora y el sistema operativo Linux. Su objetivo principal es permitir que las distribuciones de Linux se inicien cuando el arranque seguro está habilitado. Vale la pena señalar que el shim en sí está firmado con una clave en la que confía el firmware, principalmente una firma de Microsoft, ya que sus certificados vienen preinstalados en dispositivos basados ​​en UEFI.

Ciberseguridad

La secuencia procede de la siguiente manera: el firmware UEFI carga el shim y valida su firma con la CA de Microsoft almacenada en el firmware. Luego, el shim valida el cargador de arranque de segunda etapa (en la mayoría de los casos, GRUB 2) con su propio certificado de proveedor integrado. GRUB 2 finalmente valida el kernel utilizando el mismo certificado de proveedor.

La compañía eslovaca de ciberseguridad dijo que los shims, obsoletos pero confiables, pueden explotarse para ejecutar código arbitrario cuando se inicia el sistema, lo que permite a los delincuentes implementar kits de arranque UEFI como Bootkitty, HybridPetya o BlackLotus incluso cuando las protecciones de arranque seguro están habilitadas.

Desde entonces, Microsoft ha revocado los gestores de arranque UEFI del proyecto shim de código abierto, principalmente de la versión 0.9 y anteriores, como parte de su Actualización del martes de parches de junio de 2026 tras la divulgación responsable a principios de febrero. La lista de los cargadores de arranque afectados se encuentra a continuación:

  • Spyrus WTGCreator del cargador de cuñas UEFI (0.7 o inferior)
  • RedHat RedHat Enterprise Linux (7.2) desde el cargador de cuñas UEFI (0.9)
  • RedHat CentOS (7.2) del cargador de cuñas UEFI (0.9)
  • Software Baramundi baramundi Management Suite (hasta 2024R1) desde UEFI shim loader (0.8)
  • WhiteCanyon/Blancco WipeDrive (8.0.0 a 8.1.3) del cargador de cuñas UEFI (0.7)
  • Junta de Examen de Matriculación de Finlandia Abitti 1 (1.0) del cargador de cuñas UEFI (0.8)
  • NTC IT ROSA, LLC ROSA Linux (R10, R9) del cargador de cuñas UEFI (0.9)
  • Oracle America, Inc. OracleLinux (7.2) del cargador de cuñas UEFI (0.9)
  • PC-Doctor, Inc. Centro de servicio PC Doctor (15, 16) del cargador de cuñas UEFI (0.9)
  • OpenSuse OpenSuse UEFI Cargador de cuñas (0.9)
  • OpenSuse OpenSuse Shim (2.1) del cargador UEFI Shim (0.9)

Una consecuencia de esta laguna jurídica es que un atacante podría aprovechar estos cargadores de arranque shim susceptibles para eludir los mecanismos de seguridad más nuevos haciendo uso de la técnica de ataque «traiga su propio controlador vulnerable» (BYOVD) para ejecutar código arbitrario durante la fase de arranque inicial, incluso antes de que se inicialice el sistema operativo.

Los sistemas Linux también vienen con una característica de seguridad llamada lista de permitidos de clave de propietario de máquina (MOK) que permite a los usuarios autorizar la carga de controladores no firmados mientras UEFI Secure Boot está activo. Aunque se introdujo una lista de denegados MOK en la versión 0.9 de shim como una forma de revocar certificados de firma antiguos asociados con un binario UEFI vulnerable y volver a firmar versiones parcheadas.

En este contexto, un atacante podría reemplazar el shim actualizado de la víctima con un shim UEFI más antiguo firmado por Microsoft y evitar la aplicación de la lista de denegados MOK aprovechando el hecho de que la lista de permitidos todavía confía en el certificado antiguo. Esto, a su vez, podría permitir que el shim de un atacante cargue binarios vulnerables sin restricciones y obtenga la ejecución de código arbitrario.

Eso no es todo. El ataque también subvierte el Secure Boot Advanced Targeting (SBAT), que está diseñado para revocar componentes de arranque vulnerables en lugar de mantener una enorme lista de bloqueo de hashes criptográficos individuales correspondientes a cada archivo. Dicho de otra manera, el mecanismo se utiliza para actualizar la generación mínima aceptable cada vez que se descubre una vulnerabilidad en un componente de la cadena de arranque. Si un intento de arranque utiliza una versión anterior y vulnerable, el sistema lo bloquea y arroja un error.

El Centro de Coordinación CERT (CERT/CC), en un aviso emitido el mes pasado, dijo que los cargadores de arranque específicos del proveedor no se han actualizado para abordar las vulnerabilidades en el proyecto ascendente después de que se conocieron públicamente y se solucionaron.

«Como resultado, los cargadores de arranque vulnerables permanecieron firmados y confiables para los sistemas de arranque seguro porque no habían sido revocados a través de la lista de revocación DBX firmada por Microsoft», dijo. anotado. «Esto creó una exposición a largo plazo en la cadena de suministro en la que los componentes de arranque obsoletos y vulnerables aún podían ejecutarse en sistemas completamente parcheados».

Ciberseguridad

El resultado es que un atacante con privilegios administrativos o la capacidad de modificar el proceso de arranque podría abusar de uno de los cargadores de arranque vulnerables mencionados anteriormente para eludir las protecciones de arranque seguro y ejecutar código arbitrario antes de que se cargue el sistema operativo, allanando el camino para una persistencia arraigada que puede sobrevivir a los reinicios del sistema operativo y, en algunos casos, a su reinstalación.

Debido a que todo esto ocurre antes de que se inicialicen el sistema operativo y los productos de seguridad, el código malicioso ejecutado a través de los cargadores de arranque también puede eludir la detección mediante controles de seguridad integrados y soluciones de detección y respuesta de endpoints (EDR).

Los problemas se rastrean bajo los identificadores CVE. CVE-2026-8863 y CVE-2026-10797, este último haciendo referencia a un problema de larga data en una corrección que permitía omitir el mecanismo de revocación basado en certificados modificando el encabezado de firma del gestor de arranque de la segunda etapa.

ESET ha advertido que la caducidad del certificado «Microsoft Corporation UEFI CA 2011» no influye en el proceso de verificación de Secure Boot siempre que los gestores de arranque firmados con el certificado caducado no sean revocados explícitamente mediante hash.

«Lo que hace que estas viejas correcciones sean peligrosas no es una vulnerabilidad novedosa, es que no se necesita ninguna vulnerabilidad nueva para evitar el arranque seguro UEFI», dijo ESET. «Un atacante no necesita primitivos de explotación complicados: solo una copia de un binario shim antiguo, aún confiable, pero no revocado y una comprensión básica de cómo funcionan los shims UEFI. Eso es suficiente para eludir una característica de seguridad tan esencial como UEFI Secure Boot».

Los atacantes aprovechan la vulnerabilidad ‘Ill Bloom’ para extraer 3,1 millones de dólares de las carteras de criptomonedas – CYBERDEFENSA.MX

Empresa de seguridad Coinspectar ha revelado una falla en la billetera criptográfica que llama Floración enfermay los atacantes ya lo están utilizando. El error está en cómo algunos programas de billetera generaron su frase de recuperación, las palabras que controlan el dinero. Cuando esa frase se hace con una aleatoriedad débil, un atacante puede descifrarla y tomar todo lo que controla.

Coinspect ha confirmado un barrido coordinado el 27 de mayo que drenó alrededor de $3,1 millones de 431 billeteras. Dice que desde entonces se han movido aproximadamente 2 millones de dólares más de carteras expuestas. Aún no está claro en qué medida fue robo y en qué medida los propietarios trasladaron sus propios fondos a un lugar seguro.

Como dice la empresa, «si los fondos se movieron recientemente sin su permiso, esta vulnerabilidad puede ser la razón».

La mayoría de la gente probablemente esté bien. Coinspectar dice que las billeteras creadas en dispositivos de hardware no se ven afectadas, y la mayoría de las billeteras de software convencionales tampoco. El riesgo real reside en las billeteras móviles más antiguas o menos conocidas, algunas de las cuales se remontan a 2018.

Coinspect no ha nombrado las aplicaciones involucradas, por lo que la única forma de saberlo es comprobarlo. Pegue la dirección de su billetera pública en el verificador gratuito en illbloom.org. Una coincidencia significa que la frase de recuperación debe considerarse comprometida, así que mueva sus fondos a una nueva billetera.

lo que realmente se rompió

Cada billetera de autocustodia comienza con una frase de recuperación, generalmente de 12 o 24 palabras, también llamada frase inicial. Esas palabras deben ser elegidas al azar de un grupo tan grande que adivinarlas es imposible. Las carteras afectadas no fueron lo suficientemente aleatorias. Su software utilizó un generador de números aleatorios débil cuando creó la frase.

Eso redujo el conjunto de posibles frases de astronómicamente grande a un rango que un atacante podría buscar. Coinspect no ha publicado exactamente qué tan pequeño.

Ciberseguridad

Coinspect dice que reconstruyó el ataque de un extremo a otro. Trabajó con el conjunto completo de frases que el generador débil podía producir, derivó las direcciones de billetera a las que conduce cada una y luego verificó los registros públicos de blockchain para las direcciones que aún contienen fondos.

El resultado es una lista de vigilancia de carteras que nacieron débiles, independientemente de qué aplicación las generó.

El robo, en cifras

Hasta el 30 de junio, Coinspect había rastreado 2114 direcciones expuestas con actividad en cadena en Bitcoin, Ethereum, Rootstock, Tron y Polygon. La redada del 27 de mayo drenó alrededor de 3,1 millones de dólares de 431 de ellos. Bitcoin se llevó la peor parte con aproximadamente 2,57 millones de dólares, y una sola dirección de Bitcoin perdió más de 1,1 millones de dólares por sí sola.

Coinspect pudo decir que se trataba de un robo coordinado porque cientos de billeteras no relacionadas enviaron sus saldos a las mismas pocas direcciones de cobro en cuestión de horas.

Contando estos últimos movimientos, más de 5 millones de dólares han salido de estas billeteras desde el 27 de mayo. Coinspect llama a eso un piso, no un techo: hasta ahora solo ha mapeado este conjunto de direcciones y espera más. En su pico de 2022, el mismo conjunto valía 12,56 millones de dólares reconstruidos, aunque la mayor parte de ese valor ya había caído con el mercado antes de la barrida del 27 de mayo.

que hacer

El verificador en illbloom.org compara una dirección de billetera pública con la lista de Coinspect de billeteras vulnerables conocidas. Acepta direcciones estilo Bitcoin, Tron, Solana y Ethereum (Ethereum, Polygon, BNB y otras cadenas EVM).

Una frase débil puede exponer fondos en cada cadena que controla, así que verifique cada dirección vinculada a la misma semilla, no solo las que ya están agotadas. Un resultado limpio no es garantía, ya que la lista está incompleta, pero una coincidencia es una advertencia clara.

Si su dirección coincide:

  1. Trate la frase de recuperación como comprometida. El dinero no está seguro sólo porque aún no se ha movido.
  2. Crea una billetera nueva con una frase nueva. Debería ver un conjunto nuevo de 12 a 24 palabras. Si una aplicación te pide que escribas tu frase anterior, estás reabriendo la billetera débil, no creando una nueva.
  3. Mueva sus fondos a la nueva billetera. Reinstalar la aplicación anterior o importar la misma frase en otro lugar no cambia nada.

Una advertencia más. Estafas como esta atraen a estafadores que se ofrecen a «rescatar» su dinero. Un verdadero inspector nunca necesita un secreto. Coinspect dice que «nunca solicitará frases iniciales, claves privadas, firmas o aprobaciones, ni pedirá a los usuarios que envíen fondos para ‘recuperar’ o proteger una billetera».

Nunca escriba su frase de recuperación, clave privada, contraseña o archivo de respaldo en ningún sitio o mensaje. Una billetera de hardware es el lugar más seguro para mover fondos, pero genera una frase nueva en el dispositivo en lugar de importar la anterior.

Hemos visto esto antes

Se trata de un viejo fracaso con un nuevo nombre. Coinspect tomó «Ill Bloom» de «illness Blossom», la primera frase débil que produce su generador, de la misma manera leche triste recibió el nombre de «leche triste» en 2023. Ese error (CVE-2023-39910), en la herramienta de línea de comandos Libbitcoin Explorer, permitió a los ladrones robar millones de una sola vez en julio.

Un primo cercano (CVE-2023-31290) golpeó el Extensión del navegador Trust Wallet el mismo año, descifrable en menos de un día.

Ciberseguridad

La misma trampa atrapó a Randstorm, el defecto de aleatoriedad débil que THN cubrió en 2023, lo que dejó a las carteras de Bitcoin fabricadas entre 2011 y 2015 descifrables porque el código del navegador detrás de ellas usaba números aleatorios deficientes.

Los investigadores notaron entonces que la falla se había grabado en esas billeteras para siempre, y la única solución era mover los fondos a una nueva billetera hecha con un mejor software. Esa es exactamente la solución para Ill Bloom.

Cada pocos años, el generador de números aleatorios de una billetera resulta ser predecible. Las carteras que parecían seguras se vuelven agotables. La solución es siempre la misma: trasladar el dinero a un lugar nuevo. La billetera se ve bien y las palabras parecen aleatorias, pero la máquina que las eligió era predecible. Una clave predecible apenas es una clave.

¿Qué sigue?

La pregunta abierta ahora es qué aplicaciones generaron las frases débiles. Una dirección pública no revela quién la creó, por lo que Coinspect está pidiendo a los usuarios coincidentes que informen lo que usaron y transmitiendo los hallazgos a los proveedores y equipos que pueden actuar en consecuencia.

The Hacker News se comunicó con Coinspect para comentar qué aplicaciones de billetera produjeron las frases de recuperación débiles y el alcance del conjunto expuesto, y actualizará esta historia con cualquier respuesta».

Las cuentas inactivas de GitHub ayudan a los atacantes a integrarse mientras mapean organizaciones corporativas – CYBERDEFENSA.MX

Datadog Security Labs advierte sobre «varias campañas superpuestas» que enumeran sistemáticamente organizaciones corporativas de GitHub, repositorios y cuentas de usuario a través de la API de GitHub.

«Los operadores dependen de herramientas de scraping automatizadas con agentes de usuario personalizados o que parecen legítimos, aprovechando cuentas ‘fantasmas’ de GitHub que a menudo tienen años de antigüedad, o tokens OAuth y tokens de acceso personal (PAT) comprometidos de usuarios legítimos», Julie Agnes Sparks, ingeniera de seguridad senior de Datadog, dicho.

Si bien la actividad en la mayoría de los casos implica apuntar a datos públicos, instancias seleccionadas han ido más allá de la enumeración de información pública para clonar con éxito repositorios privados.

La campaña emplea una combinación de herramientas de escaneo automatizadas, más de 50 cuentas inactivas y docenas de cuentas legítimas cuyos tokens de acceso personal (PAT) han sido expuestos involuntariamente o comprometidos mediante algún otro método para facilitar la enumeración.

Ciberseguridad

Lo notable de las cuentas «fantasma» es que se crearon hace entre dos y cinco años y se dejaron inactivas intencionalmente durante períodos prolongados antes de utilizarlas como arma para emitir tráfico API en múltiples organizaciones. Esta técnica es estratégica ya que tiene como objetivo evitar generar señales de alerta y hacer pasar la actividad como legítima, en lugar de crear nuevas cuentas y usarlas inmediatamente para raspar.

Debido a que se puede acceder a una gran parte de la superficie API de GitHub sin autenticación, las consultas de enumeración devuelven los datos necesarios, mientras se combinan con el uso normal de la API. Algunos de ellos incluyen –

  • Listado de los repositorios públicos de una organización
  • Recorrer los seguidores de un usuario y las listas de seguimiento
  • Enumerar lo esencial, los repositorios destacados y las membresías de organizaciones, y
  • Ejecutar consultas GraphQL contra objetos públicos

Un actor de amenazas puede utilizar esta información para realizar un reconocimiento y mapear programáticamente la actividad relacionada con GitHub de una organización, como sus repositorios públicos, sus miembros, a quién siguen esos miembros y qué proyectos modifican.

El acceso a los datos se ha confirmado en algunos escenarios, y los atacantes tomaron medidas para clonar un repositorio privado que pertenece a una sola organización.

«Individualmente, la mayoría de estas solicitudes no tienen nada de especial. Llegan a puntos finales públicos, se autentican limpiamente o no se autentican en absoluto y devuelven respuestas exitosas», dijo Datadog. «La preocupación radica en el agregado: un grupo de cuentas que se mueven sincronizadas entre las organizaciones GitHub de las empresas con herramientas personalizadas versionadas que se iteran durante semanas y, en el peor de los casos, actores que dejaron de enumerar y comenzaron a clonar».

Se encontraron agentes de codificación de IA que activan reglas de seguridad de endpoints diseñadas para atrapar a los atacantes – CYBERDEFENSA.MX

Sophos analizó una semana de datos de sus propios terminales y descubrió que agentes de codificación de IA como Claude Code, Cursor y OpenAI Codex están activando reglas de detección escritas para atrapar a intrusos humanos.

Los agentes no son maliciosos. Simplemente hacen muchas cosas que, para un motor de comportamiento, parecen exactamente un ataque.

Descifrar las credenciales del navegador, enumerar lo que se encuentra en el almacén de credenciales de Windows, extraer archivos con herramientas integradas del sistema, escribir en la carpeta de inicio: estas han sido durante mucho tiempo una señal importante para los defensores.

Lo que ha cambiado es quién lo genera. En las máquinas que observaba Sophos, a menudo era el asistente de inteligencia artificial de un desarrollador realizando el trabajo ordinario.

¿Qué hizo saltar las alarmas?

El análisis Se basa en siete días de telemetría de junio de 2026, tomados del motor de comportamiento de Sophos en Windows y contados por máquinas únicas, no por volumen de eventos sin procesar. Es una ventana estrecha sobre la flota de un proveedor, no un censo de la industria.

Los gráficos de Sophos sitúan el acceso a credenciales en el 56,2 por ciento de la actividad bloqueada y la ejecución en el 28,8 por ciento: agentes buscando secretos almacenados o ejecutando código como lo hacen los atacantes.

La mayor regla de acceso a credenciales, con un 42,6 por ciento de ese grupo, se activa cuando un proceso utiliza la API de protección de datos integrada de Windows, o DPAPI, para descifrar los datos de credenciales almacenados en el navegador. Sophos llama a GStack un paquete de habilidades ampliamente adoptado para agentes de codificación.

Ciberseguridad

Su habilidad /browse hace exactamente eso, ejecutando PowerShell que llama a DPAPI para desbloquear los datos guardados del navegador. Sophos lo detectó ejecutándose bajo Claude Code. En contexto, es casi seguro que se trata de una automatización del navegador en nombre del usuario. Para el motor de detección, se trata de robo de credenciales y la regla es despedir.

Algunos ejemplos de Python se veían peor en el papel. En un caso, Claude Code cerró el navegador en ejecución y ejecutó un script que extraía datos de su almacén de credenciales.

Por separado, ejecutó cmdkey /list para enumerar las credenciales que tenía Windows Credential Manager. Sophos señala que Claude Code se ejecutó aquí con su indicador –dangerfully-skip-permissions establecido, un modo contra el cual la propia documentación de Anthropic advierte e indica a los administradores cómo bloquear.

Cuando un enfoque falla, un agente intenta con otro. OpenAI Codex hizo precisamente eso, obteniendo un instalador de Python del python.org real, comenzando con certutil. Eso fue bloqueado, por lo que cambió a bitsadmin. Ambas son utilidades legítimas de Windows de las que los atacantes abusan habitualmente para extraer cargas útiles y vivir de la tierra.

El objetivo era inofensivo, pero el punto de Sophos es que este comportamiento de pivote cuando se bloquea es lo que separa a un atacante vivo de un script estático, y ahora los agentes benignos también lo hacen.

Cursor activó una regla de persistencia al usar PowerShell para eliminar un script de carpeta de inicio que se ejecutaría cada vez que se iniciara la máquina. Sophos no pudo confirmar qué hacía el script, pero escribir en el inicio fuera de un instalador confiable es el tipo de cosas que los defensores señalan a la vista.

Agentes de IA en ambos lados de la línea

La otra cara ya es visible. Un mes antes, Sophos documentado un atacante que utilizó agentes de inteligencia artificial para crear y probar malware contra productos EDR, uno de ellos ejecutando Claude Opus 4.5 para coordinar el trabajo.

Ese era el momento del desarrollo: agentes que ayudaban a un atacante a escribir mejores herramientas. Los agentes también atacan a sus propios usuarios en tiempo de ejecución. En un caso separado, los investigadores demostraron que se podía engañar a un agente de codificación para que ejecutara código de atacante a través de entradas envenenadas, una cadena que puede pasar por alto EDR porque el agente actúa dentro de la sesión confiable del usuario.

Estos son eventos separados con diferentes reglas de activación, pero comparten una superficie: las llamadas de credenciales del navegador, las descargas de LOLBin y las escrituras de inicio ahora provienen de agentes benignos, agentes ejecutados por atacantes y agentes secuestrados.

Es por eso que la acción cruda te dice menos que antes. Y se encuentra dentro de un cambio mayor en la apariencia de las intrusiones. CrowdStrike’s Informe de amenazas globales 2026 descubrió que el 82 por ciento de las detecciones en 2025 estaban libres de malware, y los atacantes utilizaban credenciales válidas y herramientas confiables en lugar de descartar archivos.

Ciberseguridad

Ese cambio es lo que empujó la detección hacia el comportamiento en primer lugar. Los agentes de IA ahora generan el mismo comportamiento por razones ordinarias, abarrotando la señal exacta en la que los defensores llegaron a confiar.

Qué significa para los defensores

Si los desarrolladores ejecutan estos agentes con sus propias cuentas, es de esperar que se activen reglas de punto final en sus máquinas. La respuesta de Sophos es dividir las reglas según lo que captan. El ruido de ejecución de un agente que reintenta una descarga o emite PowerShell con un formato extraño generalmente puede tener un alcance.

Introduzca la regla en el proceso principal del agente (claude.exe, cursor.exe y sus procesos secundarios), su espacio de trabajo o ruta temporal, o la reputación del destino de descarga. Eso impide que un agente conocido que realiza un trabajo normal genere alertas.

El comportamiento que toca las credenciales es donde usted mantiene la línea. Descifrar las credenciales del navegador o enumerar el Administrador de credenciales no es seguro porque lo hizo un agente en lugar de una persona, y un agente no debe heredar el acceso general a los almacenes de credenciales solo porque se ejecuta bajo un usuario confiable. Si el ruido proviene del modo de omisión peligrosa de permisos de Claude Code, desactive ese modo a través de la configuración administrada.

Sophos llama a esto una lectura temprana, no un veredicto, y señala que el cambio aún es pequeño incluso si la dirección es clara. La cuestión de política abierta es qué se le debería permitir tocar a un agente de codificación en un punto final, y los almacenes de credenciales son un lugar sensato para trazar la primera línea.

La falla de un agente fraudulento podría haber permitido a los atacantes secuestrar los chatbots CX de Google Dialogflow – CYBERDEFENSA.MX

Un defecto crítico en Dialogflow CX de Google podría haber permitido que un atacante con derechos de edición en un agente habilitado para Code Block comprometiera a otros agentes habilitados para Code Block en el mismo proyecto de Google Cloud.

Desde allí, podían leer conversaciones en vivo, robar los datos compartidos por los usuarios y hacer que los bots enviaran mensajes escritos por los atacantes, incluidas solicitudes para volver a ingresar una contraseña.

Empresa de seguridad varonis Lo encontró y lo nombró Agente rebelde. La falla afectó solo a las organizaciones que crearon agentes con los Playbooks de Dialogflow y bloques de código personalizados, que permitieron a los desarrolladores agregar su propio Python. Y no fue un ataque remoto y no autenticado.

Para lograrlo, se necesitaba el permiso dialogflow.playbooks.update en uno de esos agentes, lo que limita al atacante realista a un interno malicioso o una cuenta de desarrollador comprometida, no a un extraño en Internet. Sin embargo, desde ese único punto de apoyo, el alcance se extendió a todos los agentes del proyecto.

Google lo ha solucionado, y tanto Varonis como Google dicen que no hay señales de que la falla haya sido utilizada alguna vez en un ataque real.

Un archivo grabable ejecutó los bloques de código de cada agente

Los bloques de código de Dialogflow permiten a los desarrolladores agregar Python personalizado al flujo de conversación de un chatbot para verificar la entrada, controlar el comportamiento e invocar herramientas definidas. Ese código se ejecuta en un entorno Cloud Run administrado por Google y cada agente que usa bloques de código en el mismo proyecto de Google Cloud comparte una instancia del mismo.

Google maneja ese entorno, el cliente no puede verlo ni controlarlo, y Varonis no encontró un aislamiento real entre los agentes dentro de él.

Ciberseguridad

Cuando un agente ejecuta un bloque de código, el código del desarrollador se agrega al código de configuración interno y se pasa a la función exec() de Python. Ese código de configuración define las variables y funciones que el bloque puede tocar. Las variables incluyen el historial de la conversación completa y el estado de los detalles de la sesión, como el ID de la sesión. Las funciones incluyen responder(), que hace que el bot responda con una cadena determinada.

Varonis encontró el archivo que realiza este ajuste, code_execution_env.py, en el entorno compartido con acceso de escritura.

Como ese archivo se podía escribir, un solo bloque de código podría reemplazarlo. Ese bloque descarga un code_execution_env.py modificado desde un servidor controlado por un atacante y sobrescribe el original dentro del contenedor en ejecución.

A partir de ese momento, la versión del atacante se ejecuta para cada ejecución de bloque de código en cada agente que comparte ese entorno. Se encuentra en el mismo alcance que el código legítimo, con el mismo acceso al historial, estado y respuesta().

Eso le permite leer cada conversación, enviarla silenciosamente al servidor del atacante y hacer que el bot publique mensajes escritos por el atacante. Un ejemplo es el phishing: el bot le pide al usuario que vuelva a verificar su inicio de sesión y el atacante recopila todo lo que escribe.

Para cubrir las pistas, el atacante restaura el bloque de código original en la consola de Dialogflow. Eso cambia sólo lo que muestra la consola; el archivo sobrescrito ya se está ejecutando en el contenedor y sigue ejecutándose debajo.

La caja de arena se filtró de dos maneras más

Varonis informó dos problemas relacionados y ninguno necesitaba sobrescribir el archivo. Primero, el entorno Code Block tenía acceso saliente a Internet sin restricciones. Utilizando la biblioteca urllib incorporada, los investigadores enviaron datos directamente a un servidor externo y pudieron recibir comandos.

Varonis dice que esto pasa por alto los controles de servicio de VPC, el perímetro de Google Cloud destinado a evitar que los datos abandonen los servicios protegidos. El entorno se encuentra fuera de ese perímetro y puede llegar a Internet abierto, lo que lo convierte en un canal tanto para el robo de datos como para el control remoto.

En segundo lugar, y menos grave, el entorno expuso el Servicio de Metadatos de Instancia (IMDS), un punto final normalmente interno que entrega credenciales de nube. Al consultarlo se devolvió un token para una cuenta de servicio administrada por Google.

Esa cuenta tenía pocos privilegios, por lo que el riesgo directo era limitado; El verdadero punto es que un entorno limitado de ejecución de código no debería poder llegar a IMDS en absoluto.

Casi nada llegó a los registros.

La sobrescritura se produjo dentro del entorno de Google, donde los clientes no tienen visibilidad y Cloud Logging no registró el cambio de archivo ni el código inyectado.

Eso hace que sea difícil, aunque no imposible, captar la situación por parte del cliente. Las acciones de configuración aún dejan rastros, en los que se basan las comprobaciones siguientes.

Ciberseguridad

Varonis reveló la falla a través del Programa de recompensa por vulnerabilidades de Google en noviembre de 2025. Google envió una solución inicial en abril de 2026 y la resolvió por completo en junio de 2026, aproximadamente siete meses desde el informe hasta la resolución. No se asignó ningún CVE.

Qué verificar si usaste bloques de código

Si ejecutó agentes de Dialogflow CX con Code Block Playbooks antes de la solución y desea confirmar que no fue el objetivo, comience con el acceso.

El permiso dialogflow.playbooks.update es el punto de entrada completo, así que audite qué roles y cuentas lo tienen.

Entonces:

  • Revise sus registros de auditoría DATA_WRITE para la API de Dialogflow en busca de actualizaciones inesperadas del manual y correlacione con usuarios, direcciones IP u tiempos de acceso inusuales.
  • Ejecute una consulta de Cloud Logging para solicitudes fallidas de usuarios, donde los mensajes de error pueden revelar excepciones generadas por bloques de código maliciosos.
  • En la consola de Dialogflow, abra Playbooks para cada agente y confirme que cada bloque de código sea uno que haya aprobado.

Un tipo diferente de falla de la IA

Muchas fallas de seguridad recientes de la IA han funcionado engañando al modelo.

El propio Reprompt y SearchLeak de Varonis convirtieron un solo clic en robo de datos en Copilot de Microsoft. ForcedLeak de Noma Security ocultó instrucciones en un formulario web de Salesforce para extraer datos de CRM.

Los investigadores de Microsoft demostraron una inyección rápida convirtiéndose en ejecución de código en el marco del kernel semántico. Rogue Agent no tocó el modelo en absoluto. Abusó de una característica normal del desarrollador y de un tiempo de ejecución invisible y compartido, al que se puede acceder con un permiso de edición normal.

En una configuración como esta, un permiso que parece un derecho de edición de contenido es en realidad un derecho de ejecución de código. Cualquiera que pueda agregar un bloque de código puede ejecutar Python arbitrario dentro de un entorno compartido que el cliente no puede inspeccionar.

Trate los permisos de edición del agente como los controles de tiempo de ejecución que son. Incluso cuando el proveedor dice que no es necesario arreglar nada, los clientes todavía no tienen forma de mirar dentro de ese tiempo de ejecución por sí mismos.

Una falla sin parche en el servidor de repositorio de Argo CD podría permitir a los atacantes apoderarse de los clústeres de Kubernetes

CD Argouna herramienta ampliamente utilizada para implementar software en Kubernetes, tiene una falla sin parchear en su componente de servidor de repositorio que permite que un atacante no autenticado ejecute código, siempre que pueda alcanzar el puerto de red interno del componente.

sinácticoque encontró el error, dice que puede conducir a una toma de control total del clúster. No hay solución ni CVE. La empresa dice que informó la falla a los encargados de mantenimiento de Argo CD en enero de 2025; Aproximadamente dieciocho meses después, sigue sin parchear, por lo que publicó los detalles para advertir a los usuarios.

El error se encuentra en el servidor de repositorio, el componente de CD de Argo que lee los repositorios de Git y crea manifiestos de Kubernetes, los archivos que definen lo que implementa el clúster.

Su servicio gRPC interno no tiene autenticación; cualquiera que pueda acceder a él puede enviar una solicitud diseñada para ejecutar un comando. Synacktiv demostró el ataque contra Argo CD v2.13.3 y no informa ninguna versión parcheada; no publicó una lista completa de las versiones afectadas.

La técnica abusa personalizaruna herramienta estándar que ejecuta Argo CD para convertir archivos del repositorio en manifiestos. Kustomize tiene una opción –helm-command que apunta al binario de helm al que debe llamar.

Ciberseguridad

Synacktiv descubrió que una solicitud no autenticada al servicio GenerateManifest del servidor de repositorio puede establecer esa opción en un script, extraído de un repositorio Git controlado por un atacante. Cuando se ejecuta kustomize, ejecuta el script en lugar de helm.

Pero «interno» no significa aislado por defecto. CD Argo envía políticas de red de Kubernetes que separan el servidor de repositorio de todo excepto de sus propios componentes.

Synacktiv encontró el gráfico Helm, una forma común de instalar Argo CD, deja esas políticas desactivadas de forma predeterminadacon networkPolicy.create establecido en false. En esa configuración, un atacante que comprometa un solo pod en el clúster puede llegar al servidor de repositorio y desencadenar el error.

Ejecutar código en el servidor de repositorio no es el final. Synacktiv usó ese acceso para leer la contraseña de Redis del clúster desde una variable de entorno, conectarse al caché de Redis de Argo CD y envenenar los datos de implementación almacenados. En la siguiente sincronización automática, Argo CD implementó una carga de trabajo proporcionada por el atacante.

Ese paso revive CVE-2024-31989Cycode encontró una falla en 2024 donde Redis de Argo CD no tenía contraseña, lo que permitió que cualquier pod en el clúster envenenara el caché de implementación. Argo CD solucionó el problema agregando una contraseña de Redis, pero el caché en sí aún no está firmado, por lo que robar la contraseña vuelve a abrir el mismo ataque.

que hacer

No existe una versión parcheada, por lo que la defensa es el aislamiento de la red. Active las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan llegar al servidor de repositorio y a los puertos de Redis. Argo CD proporciona los archivos de políticas; Los usuarios de Helm tienen que habilitarlos porque el gráfico los deja fuera.

Comprueba qué está activo con: kubectl obtiene la política de red -A. Una instalación saludable muestra una política de red por componente, incluido el servidor de repositorio y Redis. Si faltan esas políticas, se puede acceder al servidor de repositorio y a los puertos de Redis desde el resto del clúster.

Ciberseguridad

Synacktiv creó una herramienta, argo-cdown, que automatiza el ataque completo. Está reteniendo la herramienta por ahora para darles tiempo a los defensores para bloquear sus políticas de red, y dice que la publicará en GitHub más adelante para que los administradores puedan probar sus propias implementaciones.

Esta no es la primera vez que Argo CD expone sus propios componentes internos. En septiembre de 2025, parchó CVE-2025-55190donde un token API con solo acceso de lectura básico podría recuperar las credenciales del repositorio Git de un proyecto, una falla que The Hacker News señaló en ese momento.

En mayo de 2026, otro error, CVE-2026-42880permitió a los usuarios de solo lectura leer secretos de Kubernetes en texto sin formato. Es difícil pasar por alto el patrón: Argo CD concentra el acceso al clúster y los secretos del repositorio, y sus superficies internas siguen entregándolos, a una solicitud no autenticada en un error y a un token de privilegios bajos en el siguiente.

Hasta que se envíe un parche, tratar la red del clúster como hostil es la única defensa real.

La falla de Progress Kemp LoadMaster podría permitir a los atacantes ejecutar comandos de raíz antes de la autenticación – CYBERDEFENSA.MX

Una vulnerabilidad crítica en Progress Kemp LoadMaster puede permitir que un atacante no autenticado ejecute comandos arbitrarios como root en el dispositivo enviando una solicitud diseñada a su API.

El defecto, rastreado como CVE-2026-8037lleva una puntuación CVSS de 9,8 según ZDI. Hay un parche disponible. Si ejecuta LoadMaster con la API habilitada, actualice ahora.

Progreso publicó su aviso el 4 de junio y dice que no ha recibido ningún informe de explotación. El 29 de junio, investigadores de watchTowr Labs publicaron un detallado artículo técnico que recorre toda la cadena de explotación.

¿Qué hace el defecto?

LoadMaster es un controlador de entrega de aplicaciones y un equilibrador de carga utilizado por las empresas para gestionar el tráfico entre servidores. Se encuentra en el borde de la red, lo que hace que cualquier falla de autenticación previa sea especialmente peligrosa.

La vulnerabilidad vive en una función llamada citas_de_escape()que se supone que desinfecta la entrada del usuario antes de pasar a un comando de shell. El trabajo de la función es escapar de las comillas simples para que un atacante no pueda salir de una cadena entrecomillada e inyectar comandos. El problema: asignó un búfer de memoria sin borrarlo primero y nunca escribió un terminador nulo al final de la cadena desinfectada.

Ciberseguridad

Ese terminador que falta es toda la hazaña. Sin él, el sistema sigue leyendo más allá del final de la entrada desinfectada en cualquier dato que se encuentre junto a él en la memoria. Un atacante puede controlar lo que hay ahí insertando claves JSON adicionales en la misma solicitud de API, cada una con una carga útil de inyección de comando. El sistema lee la entrada desinfectada, continúa, ataca la carga útil del atacante y la ejecuta.

El ataque tiene como objetivo el /accesov2 punto final, que maneja la validación de credenciales API. El atacante envía un cuerpo JSON con un valor de apiuser especialmente diseñado y docenas de pares clave-valor adicionales rociados con el comando que desea ejecutar. No se necesitan credenciales válidas. El comando se ejecuta como root.

Versiones afectadas y solución

La falla afecta a LoadMaster GA v7.2.63.1 y anteriores, y a LTSF v7.2.54.17 y anteriores, cuando la API está habilitada. Progress ha lanzado versiones corregidas: GA v7.2.63.2 y LTSF v7.2.54.18.

El parche en sí es mínimo. Dos cambios: la función de asignación de memoria se cambió de una que deja el búfer sin inicializar a una que lo llena con ceros, y se agregó un terminador nulo explícito después de la salida de escape. Dos líneas de código que cierran un camino a la raíz.

La vulnerabilidad fue descubierta por Syed Ibrahim Ahmed de TrendAI Research y reportada a Progress a través de Zero Day Initiative el 15 de abril de 2026. ZDI coordinó la publicación del aviso público el 9 de junio. watchTowr Labs analizó de forma independiente la diferencia del parche y publicó su propio desglose técnico completo con una prueba de concepto funcional el 29 de junio.

Progress también corrigió una segunda falla de alta gravedad en el mismo aviso: CVE-2026-33691, una omisión de WAF donde el relleno de espacios en blanco en los nombres de archivos podría eludir las comprobaciones de extensión de carga de archivos.

Ciberseguridad

Un patrón que vale la pena observar

Este no es el primer defecto crítico de LoadMaster. En noviembre de 2024, CISA agregó una falla de inyección de comando LoadMaster anterior (CVE-2024-1212, CVSS 10.0) a su catálogo de vulnerabilidades explotadas conocidas después de una explotación confirmada en la naturaleza.

En abril de 2026, Progress solucionó cinco fallos más de alta gravedad en LoadMaster, cuatro de ellos problemas de inyección de comandos. Progress también es el creador de MOVEit, cuyas vulnerabilidades de 2023 impulsaron una campaña de explotación masiva por parte del grupo de ransomware Cl0p.

El Centro Canadiense de Seguridad Cibernética También ha emitido un aviso instando a los administradores a aplicar las actualizaciones.

Aún no se han reportado ataques a CVE-2026-8037. Una prueba funcional de concepto ahora es pública. Parche y luego pregunte si es necesario que se pueda acceder a la API.

Los atacantes aprovechan SimpleHelp CVE-2026-48558 para implementar TaskWeaver y Djinn Stealer – CYBERDEFENSA.MX

Se ha observado que un actor de amenazas desconocido explota una falla de seguridad de máxima gravedad recientemente revelada en SimpleHelp para entregar dos familias de malware no reportadas anteriormente. Tejedor de tareas y Ladrón de genios.

La intrusión implica la explotación de CVE-2026-48558 (Puntuación CVSS: 10.0), una vulnerabilidad crítica de omisión de autenticación que afecta el flujo de OpenID Connect (OIDC) y que un atacante no autenticado podría aprovechar para obtener una «sesión de técnico» completamente autenticada mediante el envío de un token falsificado que contiene afirmaciones de identidad arbitrarias.

«TaskWeaver es un cargador Node.js muy ofuscado, entregado como jquery.js y ejecutado a través de node.exe, que implementa un canal de entrega de carga útil cifrado y reutilizable en lugar de un conjunto fijo de comandos posteriores a la explotación», Blackpoint Cyber dicho en un análisis. «La carga útil observada de la segunda etapa, Djinn Stealer, apunta a sistemas Windows, macOS y Linux».

Djinn Stealer está diseñado para recopilar credenciales asociadas con plataformas en la nube, control de fuentes, registros de paquetes, herramientas de infraestructura, asistentes de desarrollo de inteligencia artificial, navegadores, SSH y billeteras de criptomonedas.

Los detalles de CVE-2026-48558 surgieron a principios de este mes cuando Horizon3.ai, que descubrió la falla, dijo que afecta a servidores configurados para usar OIDC genérico o Azure AD OIDC y que se deriva de la forma en que SimpleHelp valida las afirmaciones de IdP.

«En muchas implementaciones de SimpleHelp que tienen habilitada la autenticación de tipo OIDC, un atacante no autenticado puede crear y autenticarse como un nuevo usuario ‘Técnico’», dijo el investigador de seguridad de Horizon3.ai, Zach Hanley. dicho. «Este técnico, de forma predeterminada, puede realizar actividades de administración privilegiadas, como comunicación remota a puntos finales administrados, ejecución de scripts y más».

Ciberseguridad

«Incluso cuando el servidor SimpleHelp está configurado para aplicar MFA a los técnicos, este problema permite al atacante evitar este mecanismo porque, en el primer inicio de sesión, los técnicos pueden registrar su propio método MFA».

En la cadena de ataque documentada por Blackpoint Cyber, se dice que la explotación exitosa de la falla en el software de administración y monitoreo remoto (RMM) permitió al actor de amenazas obtener una sesión de «técnico» autenticada en un servidor de acceso público, que luego fue abusado para implementar TaskWeaver y Djinn Stealer.

«La plataforma RMM comprometida proporcionó al operador un canal administrativo confiable capaz de transferir archivos y ejecutar comandos en sistemas administrados a través del servidor», dijeron los investigadores Nevan Beal y Sam Decker.

TaskWeaver es un cargador modular Node.js capaz de tomar huellas digitales del sistema, estableciendo comunicaciones cifradas con un servidor remoto («a.dev-tunnels[.]com») y recuperar y ejecutar cargas útiles de JavaScript adicionales con acceso elevado al tiempo de ejecución de Node.js. La etapa final es un ladrón de información diseñado para desviar datos valiosos de hosts Windows, macOS o Linux comprometidos.

La amplitud de la información a la que apunta el ladrón es la siguiente:

  • Credenciales, historial y marcadores almacenados en navegadores web
  • Datos de configuración y autenticación asociados con AWS, Azure, Google Cloud, Oracle Cloud Infrastructure, Okta, Cloudflare, DigitalOcean, Linode, Heroku, Vercel, Railway, Supabase, Pulumi, Terraform, HashiCorp Vault y Consul.
  • Datos de la CLI de GitHub
  • configuración de git
  • Claves SSH
  • autenticación acoplable
  • Información de registro del timón
  • Configuraciones de cliente S3 y MinIO
  • Credenciales de subversión
  • Credenciales para npm, pnpm, Yarn, NuGet, Cargo, Composer, Maven, Gradle, pip, PyPI, Conda, Bun, Ivy y Scala Build Tool
  • Datos de configuración, autenticación, sesión y proyecto asociados con Anthropic Claude, Google Gemini, OpenAI Codex, Cline, OpenCode y Kilo
  • Carteras de criptomonedas y almacenes de claves asociados con Bitcoin, Litecoin, Dogecoin, Dash, Ethereum, Monero, Zcash, Exodus, Atomic Wallet y Electrum

En los sistemas Linux, el malware también intenta leer el archivo «/proc//cmdline» y «/proc//environ» archivos virtuales que pueden contener información sobre un proceso en ejecución, como contraseñas, claves API, tokens de acceso, cadenas de conexión de bases de datos y otros valores confidenciales pasados ​​a través de argumentos de línea de comando o variables de entorno.

Ciberseguridad

Una vez recopilada la información, se empaqueta en un archivo TAR, se comprime con GZIP, se cifra utilizando una clave AES-256-GCM protegida por una clave pública RSA-2048 integrada en TaskWeaver y se extrae a una infraestructura controlada por el atacante («96.126.130[.]126:58942»).

La campaña ilustra cómo los actores de amenazas persiguen cada vez más plataformas impulsadas por inteligencia artificial (IA) a medida que la tecnología se integra en los flujos de trabajo empresariales, lo que les permite abusar de los privilegios de los asistentes de IA para acceder a datos confidenciales.

«Una única omisión de autenticación se convirtió en un camino hacia todo lo que los sistemas administrados podían alcanzar, desde plataformas en la nube y repositorios de códigos hasta herramientas de inteligencia artificial, billeteras de criptomonedas e infraestructura de clientes», dijeron los investigadores.

«Las credenciales a las que se puede acceder desde una estación de trabajo de desarrollador o administrador pueden proporcionar acceso a la infraestructura de producción, crear canales, repositorios de código fuente, plataformas de implementación, inquilinos de la nube y entornos de clientes mucho después de que se haya contenido el punto final original».

La explotación activa de CVE-2026-48558 ha llevado a la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) a agregar a las vulnerabilidades explotadas conocidas (KEV), que exige que las agencias del Poder Ejecutivo Civil Federal (FCEB) apliquen las correcciones antes del 2 de julio de 2026.