Los piratas informáticos utilizan una inscripción falsa de clave de acceso de Microsoft Entra para obtener acceso a Microsoft 365

Un actor de amenazas se ha dirigido a organizaciones que abarcan múltiples sectores con solicitudes de seguridad falsas basadas en voz que incitan a los usuarios de Microsoft 365 a registrar una nueva clave de acceso de Entra con el objetivo de llevar a cabo ataques de extorsión de datos.

El actor de amenazas, rastreado por Okta bajo el apodo O-UNC-066ha implementado un kit de phishing controlado por panel que es capaz de apuntar al proceso de inscripción de clave de acceso. La actividad ha destacado las industrias de alimentos y bebidas, tecnología, salud, automoción, construcción y aviación.

«El actor de amenazas registra dominios que incorporan la palabra clave de acceso como parte de un esquema de phishing (‘vishing’) habilitado por voz», dijo el investigador de Okta, Houssem Eddine Bordjiba. dicho. «El actor de la amenaza luego llama por teléfono a los usuarios objetivo en un intento de persuadirlos de que necesitan registrar una nueva clave de acceso».

Luego, los usuarios son dirigidos a un kit de phishing que es idéntico al proceso de inscripción de la clave de acceso de Microsoft, dando la impresión de que están agregando una clave de acceso con Microsoft, cuando, en realidad, el actor de la amenaza registra su propia clave de acceso en su cuenta de Microsoft, otorgándoles acceso no autorizado.

Ciberseguridad

El desarrollo coincide con Microsoft permitiendo a los administradores configurar campañas de registro para empujar a los usuarios a registrar claves de acceso durante el inicio de sesión en un intento de ayudar a las organizaciones a impulsar la adopción de claves de acceso a escala. En otras palabras, los actores de amenazas están abusando del proceso de actualización de seguridad resistente al phishing como un señuelo para registrar sus propias claves de acceso en las cuentas de las víctimas y facilitar las actividades de seguimiento.

A diferencia del adversario en el medio (AitM) que prevalecen en campañas de phishing diseñadas para robar credenciales y tokens de autenticación multifactor (MFA), el kit de phishing utilizado en estos ataques es un panel PHP controlado por un operador en el que se guía a la víctima a través del proceso de registro de clave de acceso casi en tiempo real.

«El operador puede utilizar el kit para adaptar la experiencia del usuario a los requisitos MFA de cada víctima (TOTP, notificación push con coincidencia de números, SMS OTP) durante la sesión», dijo la empresa de seguridad de identidad. «La persona que llama puede controlar y ajustar en tiempo real qué páginas de phishing y notificaciones ve un usuario objetivo».

Se sospecha que el actor de la amenaza está aprovechando el kit para hacerse cargo de la cuenta de la víctima y engañar al usuario para que apruebe un registro de una clave de acceso iniciado por el atacante. No hay indicios en este momento que sugieran que el kit esté redirigiendo a los usuarios a proveedores de identidad externos como Okta.

La secuencia completa de acciones se encuentra a continuación:

  • La primera página del kit de phishing (/gate) muestra un icono de carga de página mientras el kit de phishing realiza comprobaciones antianálisis en segundo plano.
  • La segunda página (/identify) solicita un nombre de usuario.
  • La página siguiente (/contraseña) solicita al usuario una contraseña.
  • Las credenciales recopiladas se envían en una solicitud POST a un panel del operador en «/backend.php».
  • El operador del kit de phishing (probablemente diferente de la persona que llama a la víctima) ingresa las credenciales robadas en la página de inicio de sesión legítima de Microsoft para el inquilino objetivo.
  • La víctima ve una página «/procesamiento» que muestra otra pantalla de carga mientras espera las instrucciones del operador basadas en los desafíos de MFA observados que se les presentan en el flujo legítimo.
  • La siguiente página del kit de phishing se presenta al usuario: «/submit-otp» para un desafío de contraseña de un solo uso (OTP) basado en SMS, «/submit-authenticator» para un desafío OTP basado en tiempo, o «/approve-authenticator» para un impulsar el desafío MFA.
  • La OTP capturada se envía en una solicitud POST a «/backend.php».

En este punto, la víctima ha sido engañada por teléfono para que apruebe el acceso del atacante a su cuenta de Microsoft 365. Luego, la cadena de ataque inicia otro conjunto de acciones centradas en el pretexto de la clave de acceso:

  • La víctima es redirigida a la página «/contraseña/registro», que le indica al usuario que cree una clave de acceso.
  • La página «/passkey» de Microsoft solicita al usuario que guarde su clave de recuperación para confirmar su clave de acceso.
  • La página «/passkey/check» solicita al usuario que verifique la última palabra utilizada en la frase inicial.
  • La página «/done» confirma que el registro de la clave de acceso se realizó correctamente.
Ciberseguridad

La clave de recuperación contiene una serie de 12 palabras que es similar a una frase de recuperación secreta o una frase mnemotécnica típicamente asociada con billeteras de criptomonedas. Se considera que el paso es un mecanismo de distracción para mantener a la víctima ocupada con la tarea, mientras registra su propia clave de acceso en la cuenta de Microsoft.

«El kit de phishing parece aprovecharse de la falta de familiaridad del usuario con la autenticación mediante clave de acceso», explicó Okta. «En una ceremonia real de registro de clave de acceso, el usuario podría esperar un cuadro de diálogo del sistema para registrar una clave de acceso en su dispositivo. Las páginas de clave de acceso en este kit de phishing parecen imitar este proceso sin registrar una clave de acceso».

Okta señaló que un actor de amenazas vinculado a O-UNC-066 ha estado operando un sitio de fuga de datos desde abril de 2026 con el nombre de Pink. La Unidad 42 de Palo Alto Networks está rastreando este grupo como CL-CRI-1147, describiéndolo como afiliado a un colectivo descentralizado de cibercrimen conocido como The Com, del cual forman parte Scattered Spider, ShinyHunters y LAPSUS$.

Un estudio de 281 aplicaciones VPN gratuitas para Android encuentra fugas de tráfico, datos no cifrados y seguimiento – CYBERDEFENSA.MX

Los investigadores ejecutaron 281 de las aplicaciones VPN gratuitas más populares en Google Play Store a través de un nuevo sistema de prueba y descubrieron que muchas fallan en lo básico para instalar una VPN, es decir, mantener su tráfico privado y seguro.

Las aplicaciones marcadas con al menos un problema se han instalado más de 2.400 millones de veces.

Los problemas son básicos, no sofisticados. 29 aplicaciones permiten que el tráfico de los usuarios se filtre fuera del túnel cifrado, incluidas las búsquedas de DNS que revelan qué sitios web visita. 61 aplicaciones envían algunos datos en texto plano que cualquiera que observe el tráfico en esa red puede leer.

Cinco de ellos envían el archivo de configuración de la aplicación en claro, lo que permite a un atacante en la red redirigir la conexión a un servidor que controlan.

El sistema, llamado MVPNalyzerfue presentado en la conferencia de seguridad NDSS en febrero de 2026 por investigadores de la Universidad de Michigan, la Universidad de Nuevo México y el IIT Delhi.

Es una contraparte móvil del estudio VPNalyzer anterior del mismo laboratorio sobre software VPN de escritorio, y los investigadores lo describen como el primer marco creado para auditar sistemática y repetidamente aplicaciones VPN de Android.

Una VPN envuelve su tráfico en un túnel cifrado para que su proveedor de Internet, o un espía en la red, no pueda ver lo que está haciendo. La desventaja es que la aplicación VPN ahora lo ve todo. No estás eliminando la necesidad de confiar en alguien. Estás trasladando esa confianza de tu proveedor de Internet a quien creó la aplicación.

Ciberseguridad

El estudio pregunta si estas aplicaciones se lo merecen. Para muchos, no es así.

El defecto más grave: el secuestro de túneles

El peor hallazgo involucra a esas cinco aplicaciones que descargan su archivo de configuración sin cifrado. Ese archivo le dice a la aplicación a qué servidor conectarse. Si viaja en texto plano, un atacante en la misma red, digamos un operador de Wi-Fi público, puede reescribirlo en tránsito y apuntar la aplicación a un servidor que controla.

Arquitectura del marco MVPNalyzer

El usuario se conecta, ve la pantalla habitual «conectado» y dirige todo a través del atacante. Los investigadores crearon este ataque y confirmaron que funcionó en teléfonos bajo su control.

Señalaron el tema como una prioridad para los cinco proveedores. Dos respondieron y ambos prometieron mover el archivo a HTTPS. Uno dijo que enviaría los archivos de configuración. «Usar HTTPS de forma segura con la validación de certificado adecuada». Los otros tres no lo habían reconocido.

Filtraciones y aplicaciones que no ocultan nada

De los 29, 24 filtraron tráfico DNS, exponiendo los sitios visitados por los usuarios a la red local; esas aplicaciones por sí solas representan alrededor de 360 ​​millones de instalaciones. Seis filtraron todo el tráfico de navegación fuera del túnel y cuatro ejecutaron «túneles» sin cifrado alguno, y algunas aplicaciones fallaron en más de una forma.

Por otra parte, 169 aplicaciones no intentaron disfrazar su tráfico como algo más que una VPN, por lo que un operador de red o un censor gubernamental puede detectarlas y bloquearlas con herramientas básicas. Casi dos tercios de esas aplicaciones anuncian que superan el bloqueo o el desbloqueo de contenido restringido. Hacen la promesa y no hacen nada para cumplirla.

Para alguien en un país donde usar una VPN es en sí mismo riesgoso, ser fácil de identificar como usuario de VPN es lo opuesto a lo que se registró.

Seguimiento, desde las aplicaciones creadas para detenerlo

La gente suele instalar VPN para evitar ser rastreados. Muchas de estas aplicaciones realizan un seguimiento de todos modos. 76 envió el ID de publicidad del dispositivo, un código único que los anunciantes utilizan para seguir a una persona de una aplicación a otra.

El estudio encontró que más del 80% de las aplicaciones, 246 de ellas, contactaron con servidores conocidos de publicidad y seguimiento. Muchos también enviaron detalles como el modelo de teléfono, la versión del sistema operativo y el tamaño de la pantalla.

Por sí solos, parecen inofensivos, pero combinados forman una «huella digital» que puede identificar un dispositivo. Una aplicación incluso envió las coordenadas GPS exactas del teléfono.

Configuraciones débiles bajo el capó

Los investigadores también separaron los archivos de configuración de OpenVPN incluidos con 108 de las aplicaciones, una verificación separada de las pruebas de tráfico en vivo anteriores. Solo uno siguió todas las mejores prácticas de seguridad medidas por el estudio.

Alrededor del 89% confió en un único método de autenticación, ya sea una contraseña o un certificado, en lugar de combinar los dos. Casi uno de cada cinco utilizó cifrado débil u obsoleto, incluido el antiguo cifrado Blowfish y triple DES. Algunos configuran el cifrado de datos del túnel en ninguno, lo que desactiva el cifrado por completo. Ambos cifrados antiguos conllevan debilidades conocidas desde hace mucho tiempo (CVE-2016-6329 y CVE-2016-2183) que permiten a un atacante recuperar datos de conexiones de larga duración.

Ciberseguridad

La mayoría de estos problemas tienen la misma raíz: las aplicaciones apenas reciben mantenimiento y las comprobaciones automáticas de Play Store las dejan pasar. Muchos se encuentran entre los primeros resultados de búsqueda, donde las etiquetas de seguridad de Google y su insignia «Verificada» para aplicaciones VPN pretenden indicar confianza. El estudio dice que esas etiquetas funcionan más como señales de marketing que como una garantía de seguridad real.

Esto no es algo único

Otras investigaciones recientes apuntan en el mismo sentido. En agosto de 2025, investigadores del Citizen Lab de la Universidad de Toronto y de la Universidad Estatal de Arizona encontró que varias aplicaciones populares de VPN para Android, con más de 700 millones de descargas combinadas, estaban vinculadas en secreto, compartían contraseñas codificadas y recopilaban datos de ubicación silenciosamente.

En octubre de 2025, la empresa de seguridad móvil Zimperium reportado que tres de las aproximadamente 800 aplicaciones VPN gratuitas que probó todavía incluían una versión de la biblioteca OpenSSL vulnerable a Heartbleed, un error muy conocido corregido en 2014. Muchas también pidieron permisos telefónicos mucho más allá de los que necesita una VPN.

Los tres estudios cuentan una historia: las aplicaciones VPN gratuitas siguen combinando un fuerte argumento de privacidad con una ingeniería débil, y siguen alcanzando millones de instalaciones antes de que alguien se dé cuenta.

Qué pueden hacer los usuarios

Los fallos más graves aquí, la búsqueda de configuración de texto sin cifrar y la configuración débil del túnel, son invisibles desde el lado del usuario. No puedes detectarlos mirando la aplicación, que es todo el problema. Entonces, la verdadera defensa no es qué protocolo anuncia la aplicación. Es quién está detrás.

Favorecer a los proveedores que publican una auditoría de seguridad independiente reciente. Tenga cuidado con las aplicaciones gratuitas que lo entierran en anuncios. Y trate las afirmaciones «verificadas» o «sin registros» como un punto de partida, no como una prueba.

Los investigadores enumeran todas las aplicaciones marcadas en el apéndice del artículo, para que puedas comprobar si la de tu teléfono está entre ellas.

El equipo planea hacer público MVPNalyzer para que las tiendas de aplicaciones y los reguladores puedan realizar estas comprobaciones ellos mismos. Teniendo en cuenta esta evidencia, tendrán que hacerlo.

Hacker News ha preguntado a Google si está revisando o eliminando las aplicaciones marcadas, y cuál es su respuesta al hallazgo del estudio de que las etiquetas de seguridad de Play Store y la insignia «Verificada» funcionan más como marketing que como garantías de seguridad. También le hemos pedido al equipo de investigación de MVPNalyzer que identifique las cinco aplicaciones vulnerables al secuestro de túneles y que confirme si los proveedores notificados han implementado correcciones desde entonces. Esta historia se actualizará con cualquier respuesta.

Seis nuevas fallas de U-Boot podrían permitir que imágenes maliciosas bloqueen dispositivos o ejecuten código en el arranque – CYBERDEFENSA.MX

Investigadores de la firma de seguridad de firmware Binarly han encontrado seis nuevas fallas en U-Boot, el pequeño programa que inicia hardware tan variado como enrutadores domésticos, cámaras inteligentes y chips de administración dentro de servidores de centros de datos.

Cuatro de los errores pueden bloquear un dispositivo. Los otros dos podrían permitir que un atacante que introduzca una imagen maliciosa delante del gestor de arranque ejecute su propio código, antes de que el dispositivo haya confirmado que el software es genuino.

Esa última parte es el punto. Un gestor de arranque se ejecuta antes que el sistema operativo, por lo que una falla aquí puede socavar todo lo que se carga después. Los seis errores se detectan mientras U-Boot todavía está leyendo una imagen que no es de confianza, antes de verificar la firma.

Lo que encontró Binarly

U-Boot puede agrupar un kernel, un árbol de dispositivos, un disco ram y otros componentes de arranque en un solo paquete, un FIT (árbol de imágenes planas), y verifica la firma digital de ese paquete antes de ceder el control.

Binarly buscó puntos débiles en ese cheque y encontró seis. La mayor parte del código vulnerable ha estado en U-Boot desde v2013.07, Binariamente diceen más de 50 versiones estables, y también se encuentra en los firmwares de muchos proveedores integrados sobre U-Boot.

Los errores se rastrean como avisos de Binarly. BRLY-2026-037 a BRLY-2026-042. Aún no se han asignado identificadores CVE. Se dividen en dos grupos: dos que pueden ejecutar código y cuatro que sólo fallan.

Ciberseguridad

Los dos son BRLY-2026-037 y BRLY-2026-038, y ambos rastrean hasta un valor no verificado. U-Boot llama a fdt_get_name, una búsqueda en la biblioteca de análisis del árbol de dispositivos que toma prestada, y en una imagen con formato incorrecto, esa búsqueda devuelve un puntero nulo y una longitud negativa. U-Boot usa ambos sin verificar ninguno.

Un error sigue al puntero nulo en una copia de memoria que, en dispositivos donde está asignada la dirección cero, se convierte en un desbordamiento del búfer de pila. El otro introduce la longitud negativa en la aritmética de punteros que retrocede hasta que sobrescribe una dirección de retorno guardada. En el diseño de memoria correcto, cualquiera de los dos puede controlar manualmente la codificación proporcionada por el atacante.

Los otros cuatro sólo bloquean el gestor de arranque. BRLY-2026-039 y BRLY-2026-041 leen más allá del final de la imagen confiando en un tamaño o desplazamiento que controla el atacante. BRLY-2026-040 elimina la referencia a un puntero nulo que un formato de imagen anterior devuelve sin marcar. BRLY-2026-042 agota la pila, activada por una imagen profundamente anidada que impulsa un paso de validación temprano para llamarse a sí mismo hasta que se agote.

Binarly publicó una imagen de prueba de concepto y pasos de reproducción para cada defecto y los demostró frente a compilaciones estándar de U-Boot. No se ha informado de explotación en ataques reales.

De los seis, los dos errores de corrupción de memoria son los que se deben priorizar: una falla puede dejar un dispositivo fuera de línea, pero la ejecución del código en el arranque podría subvertir toda su cadena de confianza.

que mal se pone

En el peor de los casos, recuperar un dispositivo que no arranca significa acceder físicamente y actualizar su chip de memoria con una imagen limpia. La ejecución del código es peor. El código que se ejecuta tan temprano se encuentra debajo del sistema operativo, donde las herramientas de seguridad comunes pueden no verlo.

El problema para un atacante es la entrega: estos errores solo aparecen una vez que una imagen maliciosa llega a la ruta de inicio, que generalmente requiere acceso físico o un punto de apoyo privilegiado. Ese punto de apoyo no siempre es local.

En En trabajos anteriores sobre los controladores de administración del servidor de Supermicro, el mismo investigador de Binarly demostró que un atacante con acceso remoto a la interfaz de administración podría abusar del propio proceso de actualización del dispositivo para mostrar una imagen maliciosa, sin tocar el hardware.

que hacer

Aún no existe una versión estable con la solución, por lo que los proveedores y mantenedores de productos basados ​​en U-Boot no deberían esperar: extraiga las correcciones ascendentes ahora, siguiendo los enlaces de confirmación en cada aviso de Binarly, y realice un seguimiento por ID de aviso, ya que no existen CVE.

U-Boot fusionó los seis parches en junio, pero la versión de julio (v2026.07) ya se había congelado en abril, por lo que se envió sin ellos; la próxima versión, v2026.10, no saldrá hasta octubre.

Ciberseguridad

Todos los demás ejecutan un dispositivo que otra persona construyó con U-Boot. Para ellos, la solución debe llegar como una actualización de firmware del proveedor del producto. Eso es lo que hay que tener en cuenta.

Esta verificación exacta ha fallado antes. La misma lógica de firma fue atacada meses antes por CVE-2026-33243que U-Boot parchó en abril; El gestor de arranque barebox relacionado, que utiliza las mismas herramientas de imagen, también se vio afectado.

En ese error, una propiedad destinada solo a enumerar lo que cubre la firma no estaba firmada, por lo que una imagen manipulada podría intercambiarse en partes que nunca fueron verificadas. El asistente detrás de los dos peores errores aquí, fdt_get_name, proviene de libfdt, la biblioteca de árbol de dispositivos aplanados que U-Boot comparte con el kernel de Linux, barebox y otros. El mismo error de devolución no comprobada puede surgir en cualquier lugar donde se utilice el código.

LogoFAIL, que THN cubrió en 2023, era un conjunto de errores de análisis de imágenes en el firmware de la PC que permitían que el código del atacante se ejecutara durante el arranque, antes de que Secure Boot pudiera verificar algo, en casi todas las principales marcas de PC. La firma recibe toda la atención; los insectos siguen aterrizando en las tuberías que corren delante de él.

Y como demostró BootHole en 2020, cuando una falla del gestor de arranque rompió el arranque seguro en todo el ecosistema, escribir el parche es la parte fácil. La parte lenta es introducirlo en millones de dispositivos que ejecutan la copia de U-Boot de otra persona.

Progress pide a los clientes de ShareFile que apaguen los controladores de zona de almacenamiento por amenaza a la seguridad – CYBERDEFENSA.MX

Progress Software ha dicho a los clientes de ShareFile que apaguen los servidores de Windows que ejecutan sus controladores de zona de almacenamiento, confirmando Las noticias de los piratas informáticos que está respondiendo a una «amenaza externa creíble a la seguridad».

La compañía ha deshabilitado temporalmente el acceso a las cuentas afectadas, un paso que dice que tomó «por precaución» mientras trabaja con expertos en seguridad internos y externos.

Dice que no tiene indicios de acceso no autorizado a ninguna cuenta o datos de ShareFile, y que notificó a los clientes después de enterarse de la amenaza.

Lo que Progress no ha dicho es cuál es la amenaza ni quién está detrás de ella.

El pedido se hizo público cuando un cliente publicó el correo electrónico de la empresa en Reddit. r/administrador de sistemas el 10 de julio. Progreso confirmó la interrupción en su página de estado, enumerando a los clientes de Storage Zone Controller como «no operativos» y el incidente como bajo investigación a partir de una actualización de las 12:12 pm EDT.

Ciberseguridad

Solo el controlador de zona de almacenamiento se ve afectado, no las cuentas ShareFile estándar solo en la nube. El controlador es un servidor que una empresa administra por sí misma, por lo que los archivos pueden permanecer en su propio almacenamiento mientras sigue usando la nube de ShareFile para compartirlos y administrarlos.

El controlador generalmente se encuentra en el borde de la red, al que se puede acceder desde Internet. Esa exposición lo convierte en útil y en un objetivo. Ordenar a los clientes que lo desconecten completamente, en lugar de simplemente parchearlo, es un paso notable.

Esa elección es en sí misma un indicador. Si existiera una solución para esta amenaza, Progress les diría a los clientes que la aplicaran; la orden de cierre sugiere que todavía no hay ninguno. Por lo general, eso significa una falla recién descubierta que la compañía está apresurándose a cerrar, aunque el mismo paso también se aplicaría a una amenaza que un parche no puede abordar, como claves robadas o un problema del propio Progress.

Su afirmación de que no se accedió a cuentas ni datos también es una redacción cuidadosa y no descarta problemas con los propios controladores.

Que hacer ahora

  1. Siga primero la orden de apagado. Mantenga los controladores afectados fuera de línea hasta que Progress diga cuál es la amenaza y cuándo es seguro reiniciar.
  2. Por separado, confirme que su versión esté actualizada: 5.12.4 o posterior en la línea 5.x, o una versión 6.x. Esto cierra las fallas reparadas a principios de este año, pero Progress no ha dicho que elimine la amenaza actual, por lo que no lo trate como un permiso para reiniciar.
  3. Si se puede acceder a un controlador desde Internet, trátelo como una posible incidencia. Conserve los registros e inicie su proceso de respuesta a incidentes, luego busque archivos .aspx desconocidos en las carpetas web y rutas de almacenamiento que no configuró. Un servidor que se vea limpio no es prueba de que esté limpio.

ShareFile se ha enfrentado a esto antes. En 2023, cuando el producto todavía pertenecía a Citrix, los atacantes explotaron una falla no autenticada en el mismo controlador de zonas de almacenamiento (CVE-2023-24489).

CISA lo marcó como explotado activamente y Citrix cortó los controladores sin parches de la nube ShareFile, el mismo bloqueo de acceso que ahora ha impuesto Progress.

Ciberseguridad

Progress, que adquirió ShareFile en 2024, ya había resistido su propio ataque de transferencia masiva de archivos: MOVEit, cuyo día cero de 2023 fue explotado por el grupo Clop y afectó a más de 2.700 organizaciones.

El controlador de zonas de almacenamiento también tenía dos fallas críticas que watchTowr reveló en abril y Progress parchó en marzo, aunque la compañía no ha relacionado la amenaza actual con ellas y ninguna ha sido reportada como explotada.

La pregunta central aún no tiene respuesta: Progress ha desconectado estos sistemas y está trabajando con expertos externos, pero no ha dicho cuál es la amenaza ni cuándo los clientes podrán volver a ponerlos en línea de manera segura.

El compromiso de GitHub de Injective Labs impulsa los paquetes npm para robar claves de billetera – CYBERDEFENSA.MX

Actores de amenazas desconocidos comprometieron el repositorio GitHub del proyecto Injective Labs SDK y lo aprovecharon para publicar un paquete malicioso en el registro npm para robar claves privadas de billeteras de criptomonedas y frases iniciales mnemotécnicas.

La versión comprometida, @injectivelabs/sdk-ts@1.20.21venía integrado con una funcionalidad de telemetría falsa que extraía datos de billeteras de criptomonedas. La versión se lanzó el 8 de julio de 2026, pero desde entonces ha sido obsoleto en el registro. Dicho esto, los artefactos de lanzamiento que pertenecen a la versión comprometida son todavía disponible para descargar desde GitHub al momento de escribir este artículo.

«La funcionalidad maliciosa se introdujo en el repositorio oficial de GitHub del proyecto a través de confirmaciones enviadas por una cuenta de GitHub que pertenece a un desarrollador con un historial establecido de contribuciones al repositorio», Socket dicho.

Ciberseguridad

La firma de seguridad de la cadena de suministro de software dijo que el actor de amenazas detrás del ataque también publicó la versión 1.20.21 en 17 paquetes adicionales con alcance de @injectivelabs que dependían y fijaban la versión maliciosa del SDK, poniendo así a los usuarios transitivos que tal vez no hayan instalado la biblioteca directamente. Esto incluye –

  • @injectivelabs/utils
  • @injectivelabs/redes
  • @injectivelabs/tipos-ts
  • @injectivelabs/excepciones
  • @injectivelabs/base-billetera
  • @injectivelabs/wallet-core
  • @injectivelabs/billetera-cosmos
  • @injectivelabs/billetera-clave-privada
  • @injectivelabs/billetera-evm
  • @injectivelabs/billetera-trezor
  • @injectivelabs/billetera-cosmostation
  • @injectivelabs/billetera-ledger
  • @injectivelabs/wallet-wallet-connect
  • @injectivelabs/billetera-mágica
  • @injectivelabs/estrategia-billetera
  • @injectivelabs/billetera-llave en mano
  • @injectivelabs/billetera-cosmos-estrategia

El malware presente en el paquete es bastante simple y directo, y se activa cuando un desarrollador desprevenido utiliza la funcionalidad de la biblioteca. Al evitar los scripts del ciclo de vida y no ejecutarlos durante la fase de instalación, se ayuda a que el malware pase desapercibido.

Específicamente, se ha descubierto que la versión envenenada modifica funciones legítimas utilizadas en flujos de trabajo para generar claves privadas al invocar una función «trackKeyDerivation()» con el pretexto de recopilar métricas de uso anónimas para la optimización del SDK.

«Rastrea qué métodos de derivación de claves se utilizan (hexadecimal versus mnemónico) y deriva patrones de tiempo para ayudar al equipo del SDK a identificar cuellos de botella en el rendimiento y comprender la adopción de diferentes formatos de claves en todo el ecosistema», se lee en la descripción de la supuesta función de telemetría. «Todas las métricas se activan y olvidan y nunca bloquean ni afectan la derivación de claves».

Según Socket, los parámetros pasados ​​a la función incluyen un marcador codificado que describe el método utilizado para generar la clave privada y la información confidencial real necesaria para generar la clave privada. El material capturado es suficiente para que el actor de la amenaza regenere la clave privada.

Ciberseguridad

«El malware agrega lógica de robo de billetera criptográfica a un paquete de billetera criptográfica, cada vez que un usuario legítimo crea o usa la lógica que lee frases mnemotécnicas, que son básicamente la clave maestra para cualquier billetera criptográfica, el malware las lee y las envía al servidor remoto», OX Security dicho.

En un intento por reducir el número de solicitudes salientes, el mecanismo de exfiltración es diseñado para agregar múltiples derivaciones de claves en una ventana de dos segundos en una sola cola y luego enviarlas en forma de una solicitud HTTPS POST a un servidor externo («testnet.archival.chain.grpc-web.injective[.]red») en una sola baliza.

PasoSeguridad anotado la liberación maliciosa se facilitó a través del canal de editor confiable (OIDC) del repositorio, agregando que las confirmaciones maliciosas fueron creadas y enviadas bajo la identidad de un mantenedor confiable existente («thomasRalee»).

Se recomienda a los usuarios que hayan instalado la versión maliciosa que actualicen a la versión limpia recién publicada del paquete (1.20.23), traten cualquier clave privada o frase mnemotécnica que pase a través del paquete como comprometida y las roten, y verifiquen si hay dependencias transitivas.

El servidor de hackers expuesto revela la puerta trasera WP-SHELLSTORM en miles de sitios de WordPress – CYBERDEFENSA.MX

Un equipo de cibercrimen dejó uno de sus propios servidores abierto en Internet durante tres semanas y expuso el funcionamiento interno de la operación: las herramientas de piratería, los registros de actividad y las listas de objetivos que nombran a más de 1,4 millones de sitios web.

En realidad, muchos menos fueron pirateados, pero los archivos expuestos mostraron a los investigadores cómo una operación de piratería masiva de sitios se ejecuta desde adentro.

La operación, ahora rastreada como WP-SHELLSTORMes lo que SOCRadar llama intermediación de acceso a webshell: un equipo que irrumpe en sitios a escala, coloca una puerta trasera oculta (un «webshell») en cada uno y empaqueta ese acceso para su reventa.

La actividad más fuerte afectó a los sitios de WordPress que ejecutan complementos desactualizados. Si ejecuta WordPress o Joomla, los dos defectos que más importaban estaban en el complemento de almacenamiento en caché Breeze y en el editor JCE de Joomla; salte a la lista de verificación a continuación si ese es usted.

Un servidor olvidado

Dos equipos excavaron en la misma carpeta expuesta. El equipo de inteligencia de amenazas de SOCRadar lo detectó el 11 de junio de 2026 en un servidor alquilado con sede en EE. UU. en 137.175.93.[.]126 sin contraseña alguna. En su interior había aproximadamente 800 MB en 434 archivos: webshells, scripts de explotación, resultados de escaneo, historial de comandos escritos por el operador y configuraciones de comando y control.

Ctrl-Alt-Intel También había analizado el mismo directorio, lo encontró en la plataforma de directorio abierto de Hunt.io y lo publicó el 22 de junio, semanas antes del artículo de SOCRadar del 9 de julio. La exposición se redujo a un desliz básico: el operador inició un simple servidor web Python para mover archivos y lo dejó funcionando durante 22 días.

Ciberseguridad

El equipo tomó errores conocidos públicamente en complementos de sitios web, la mayoría de ellos en WordPress, y construyó escáneres automáticos para disparar esos exploits a listas de objetivos masivas extraídas de FOFA, un motor de búsqueda chino para sistemas conectados a Internet, similar a Shodan.

Cuando un sitio ejecutaba una versión vulnerable, el exploit podía cargar un webshell: un pequeño script que permite al atacante ejecutar comandos en el servidor desde cualquier lugar, leer archivos, robar contraseñas y profundizar en la red.

El conjunto de herramientas cubría 27 fallas conocidas, aunque unos pocos hicieron la mayor parte del trabajo. El mayor productor fue un error en el complemento de almacenamiento en caché Breeze (CVE-2026-3844), que el equipo disparó contra más de 45.000 objetivos y, según sus propios cálculos, cerró por puerta trasera a más de 17.000 de ellos.

Esto tiene un inconveniente: solo funciona cuando está activada una configuración no predeterminada de «Hospedar archivos localmente – Gravatars», por lo que la mayoría de las instalaciones de Breeze nunca estuvieron expuestas.

Los números, en términos sencillos

La cifra principal necesita una advertencia. El recuento de 1,4 millones es cuántos dominios estaban en las listas de destino, no cuántos fueron divididos, y esas listas abarcaban WordPress, Joomla y otras plataformas. El archivo más grande era una lista de 587.034 destinos Joomla.

El número realmente comprometido fue mucho menor, y los dos equipos de investigación lo midieron de manera diferente: el recuento deduplicado de Ctrl-Alt-Intel encontró 25,195 sitios con evidencia de compromiso confirmada o validada, mientras que SOCRadar, contando webshells activos, colocó la cifra en vivo en más de 5,700.

Un error muestra claramente la brecha: un error de Joomla se disparó contra más de 560.000 objetivos, pero aterrizó sólo en 77 de ellos.

Estar en la lista de escaneo de alguien no es lo mismo que ser pirateado. Tenga esto en cuenta siempre que un informe comience con un número objetivo aterrador.

Las herramientas y una campaña anterior.

La puerta trasera principal, un archivo llamado down.php, estaba muy ofuscado, tenía cuatro capas de profundidad y parece derivar de un webshell chino de código abierto llamado BestShell. Una vez en ejecución, podía administrar archivos, ejecutar comandos, abrir shells inversos, escanear la red y verificar qué software de seguridad estaba ejecutando el host.

Para su propio acceso remoto, el equipo utilizó un cuentagotas SNOWLIGHT para instalar VShell, una puerta trasera sigilosa que disfraza el nombre de su proceso como [kworker/0:2] para mezclarse con los subprocesos del núcleo en una lista de procesos.

Esas dos herramientas tienen una historia: en abril de 2025, Sysdig vinculó esta cadena SNOWLIGHT a VShell con el presunto grupo estatal chino UNC5174, actividad cubierta por THN en ese momento. Sin embargo, el propio VShell es una herramienta común en los círculos criminales de habla china, por lo que su presencia por sí sola no apunta a un actor estatal.

El servidor también contenía rastros de un trabajo anterior muy diferente. SOCRadar descubrió que antes de la ruidosa ola de WordPress, el mismo equipo llevó a cabo una campaña más silenciosa a principios de mayo de 2026 contra los sistemas Java corporativos. Obtuvo 613 archivos de configuración de 11 sistemas en nueve empresas de tecnología financiera, comercio electrónico, logística, juegos y electrónica.

El botín incluyó claves de inicio de sesión en la nube para AWS, Alibaba Cloud, Oracle, Tencent y DigitalOcean, contraseñas de bases de datos y claves privadas Alipay RSA. Se apoyaba en un error antiguo y conocido en Nacos, un servidor de configuración (CVE-2021-29441), que permite a un atacante omitir el inicio de sesión falsificando un único encabezado web.

SOCRadar interpreta el momento como una secuencia: primero obtener credenciales corporativas de alto valor, luego, semanas después, pasar al trabajo de puerta trasera de mayor volumen, una ronda de financiación antes de ampliar la escala.

Comercio descuidado

Ambos equipos evalúan con confianza media a alta que el operador es chino o habla chino. Señalan el chino simplificado fluido a lo largo del código y el historial de comandos, la dependencia de FOFA (que, según los investigadores, necesita un número de teléfono chino para registrarse) y las herramientas Godzilla y VShell preferidas en los foros de habla china.

SOCRadar va un paso más allá y considera que la tripulación está motivada financieramente y no dirigida por el estado. Los nombres que aparecen en los archivos (tance, chen-kk, chenyk) se tratan como pistas sueltas, no como pruebas. Destaca un cabo suelto: una única dirección IP en Taiwán realizó más de 42.000 solicitudes descargando las propias herramientas del equipo. Podría ser un segundo operador, un cliente u otro investigador. Los troncos no pueden resolverlo.

Para ser un grupo que maneja una cadena de herramientas genuinamente capaz, el equipo fue descuidado. Dejó el servidor abierto, dejó un archivo de configuración de FOFA que FOFA puede rastrear a través de su canal de aplicación de la ley y dejó un historial de comandos sin editar que expuso todo. Cuando finalmente se dio cuenta de que había sido detectado, en algún momento entre el 2 y el 4 de julio, eliminó un lote de líneas de registro. Tres semanas demasiado tarde.

Ciberseguridad

El error es familiar. En marzo de 2026, el mismo taller de investigación detectó al Fancy Bear ruso (APT28) de la misma manera: un directorio abierto olvidado difundió las herramientas y registros de phishing del grupo, en una campaña llamada Hunt.io. Operación redondeada.

Que hacer ahora

Si ejecuta alguno de los programas específicos, compruébelo hoy. Estos no son errores desconocidos: dos de ellos están siendo explotados activamente en otros lugares.

Wordfence rastreó decenas de miles de ataques bloqueados contra la falla de Everest Forms Pro (CVE-2026-3300) esta primavera, y el error Joomla JCE (CVE-2026-48907) es una falla de máxima gravedad que CISA ha agregado a su lista de vulnerabilidades explotadas conocidas.

  • WordPress y Joomla, primero: parchear Breeze (CVE-2026-3844, corregido en 2.4.5) si la configuración no predeterminada «Hospedar archivos localmente – Gravatars» está activada; produjo la mayor cantidad de puertas traseras aquí. Trate la falla JCE de Joomla (CVE-2026-48907, corregida en 2.9.99.5) como urgente también, ya que es de máxima gravedad y está en la lista de explotaciones activas de CISA, a pesar de que apenas apareció en esta campaña.
  • WordPress y Joomla, consulte también: Complementos ThemeREX (CVE-2026-1969), Lista de archivos simple (CVE-2020-36847), CSS JS PHP personalizado (CVE-2026-6433), BerqWP (CVE-2025-7443), cargas de Ninja Forms (CVE-2026-0740), WavePlayer (CVE-2025-12057), WPBookit (CVE-2025-7852) y Administrador de archivos WP (CVE-2020-25213). Ambos informes enumeran la Lista de archivos simple bajo CVE-2025-34085, un duplicado ahora rechazado; la identificación válida es CVE-2020-36847.
  • Nacos: actualice a 2.2.1 o posterior y active la autenticación (nacos.core.auth.enabled=true). Si su instancia alguna vez estuvo expuesta, rote todas las credenciales que se encuentran en ella, no solo las obvias.
  • Bota de trabajo y primavera XXL: cierre los puntos finales de ejecutor no autenticados y deshabilite /actuator/heapdump en producción.
  • Busque las puertas traseras: busque los patrones de nombres de archivos webshell del equipo, como .bd.php, .wp-log.php y .brq-*.php. Luego verifique cualquier proceso llamado [kworker/X:Y]. Un hilo del kernel real no ejecuta ningún programa propio, por lo que su /proc//exe no apunta a nada. Tampoco tiene línea de comando ni sockets de red. A [kworker] eso demuestra que cualquiera de estos es un impostor. Bloquear la infraestructura conocida: 137.175.93[.]126, 43.108.17[.]80, y el dominio xs.xxooonline[.]UE[.]cc.

Lo que hace que WP-SHELLSTORM merezca atención no es lo avanzado que es, sino lo ordinario que es. Los exploits públicos, el escaneo automatizado y una lista de objetivos de un millón de líneas fueron suficientes para comprometer sitios a escala, sin necesidad de un día cero. Los detalles son públicos sólo porque el equipo olvidó cerrar su propio servidor.

The Hacker News se comunicó con SOCRadar para obtener más detalles sobre sus hallazgos y actualizará esta historia con cualquier respuesta.

Laser Attack restablece las contraseñas de Tangem Wallet en tarjetas que no se pueden parchear – CYBERDEFENSA.MX

Investigadores de Equipo de seguridad de Ledger’s Donjon han demostrado que un pulso láser sincronizado con precisión, dirigido al chip dentro de un tándem tarjeta de billetera criptográfica, puede restablecer la contraseña de la tarjeta a cualquier cosa que el atacante elija.

Sin contraseña antigua. Sin tarjeta de respaldo. Una vez que se reinicia, quien lo hizo controla la billetera y puede sacar las monedas.

Esta no es una emergencia para la mayoría de los propietarios. El ataque necesita la tarjeta física en la mano y un laboratorio que Donjon calcula en alrededor de 250.000 dólares. También significa cortar la tarjeta, lo que deja daños que nadie puede pasar por alto. No se puede hacer a través de Internet y no hay ninguna solución disponible: las tarjetas Tangem no pueden aceptar actualizaciones de software, por lo que todas las tarjetas ya vendidas tienen el defecto.

El único grupo que debería actuar ahora es cualquiera cuya tarjeta se pierda o sea robada y tenga un gran valor.

Cómo debe protegerle la tarjeta

Una billetera Tangem parece una simple tarjeta bancaria. Toquelo en su teléfono y una aplicación complementaria se comunicará con un chip Samsung S3D232A en su interior. Ese chip es un elemento seguro, construido para resistir manipulaciones y certificado con un alto grado llamado EAL6+.

Ciberseguridad

Contiene la clave secreta que controla su criptografía y nunca la deja salir. Hay dos cosas que deben interponerse entre un ladrón y su dinero: tener la tarjeta en la mano y conocer la contraseña.

El punto débil es la función de restablecimiento de contraseña. Tangem vende sus tarjetas en juegos vinculados y, si olvida su contraseña, puede establecer una nueva manteniendo dos de sus tarjetas juntas. En lo más profundo de ese proceso, la tarjeta ejecuta una única verificación: ¿está esta tarjeta en modo de recuperación? En caso afirmativo, acepta una nueva contraseña sin solicitar la anterior.

Un pulso láser disparado al chip en el momento exacto en que se ejecuta esa verificación no reescribe silenciosamente un valor almacenado. Perturba brevemente los propios circuitos del chip, por lo que la verificación falla y la tarjeta se comporta como si estuviera en modo de recuperación cuando no lo está.

Una vez rechazada la verificación, el comando SetPin normal de la tarjeta acepta una contraseña nueva: ni contraseña anterior, ni segunda tarjeta, ni paso de recuperación. Desactivar la función de recuperación no ayuda, porque todavía se ejecuta la misma verificación en todas las tarjetas.

Difícil de hacer e irreparable

Nada de esto es fácil. Se necesitó un equipo láser, un equipo de medición sensible, una profunda habilidad en hardware y un largo período de trabajo inicial para mapear el chip y encontrar el lugar y el momento exactos. Hay que cortar la tarjeta y exponer su chip, lo que deja daños evidentes.

No se puede hacer esto en silencio y guardar la tarjeta en el bolsillo. informes torreón que una vez fijadas las configuraciones, el ataque funcionó en todas las tarjetas que intentó, aproximadamente dos horas cada una. El equipo informó la falla a Tangem el 10 de febrero de 2026.

El mayor problema es la permanencia. Tangem fabrica sus tarjetas sin posibilidad de actualizar el firmware y lo presenta como una característica de seguridad: nada se puede cambiar, por lo que nada se puede alterar a distancia. Aquí, ese mismo diseño corta en sentido contrario, dejando un defecto en el código que nunca podrá corregirse.

Como dicen los investigadores, «no hay parche, pero el ataque es físico e invasivo», por lo que no se puede realizar de forma remota.

Lo que dice Tangem

Tangem retrocedió. en un respuesta públicala compañía llamó a esto un método físico exclusivo de laboratorio que funciona contra chips de elementos seguros en general, no algo exclusivo de sus tarjetas. También señaló que Donjon pertenece a Libro mayoruno de sus mayores rivales.

Su punto más agudo tiene que ver con el dinero: una tarjeta Tangem no lleva nada que diga quién es el propietario o cuánto tiene, por lo que un atacante que gasta 250.000 dólares y destruye tarjetas para sintonizar el ataque no tiene manera de saber si una tarjeta robada vale 50 o 50 millones de dólares. Tangem también dice que hasta ahora nadie ha perdido fondos debido a un ataque láser en ninguna billetera de hardware, y que para los usuarios cotidianos, «el riesgo práctico es prácticamente inexistente».

Ambas partes tienen parte de razón. Los investigadores de Donjon tienen razón en que la falla es real, se encuentra en cada tarjeta y nunca se puede reparar. Tangem tiene razón en que, para casi todo el mundo, el coste, las cartas arruinadas y las conjeturas sobre lo que contiene una carta la hacen inútil.

El lugar donde realmente se encuentran es limitado: una tarjeta perdida, robada o incautada que un atacante ya tiene motivos para pensar que vale la pena.

No es el primer chip de billetera que se rompe de esta manera

Este no es el único ataque láser de Donjon a una billetera de hardware este año. A principios de junio, Trezor y su socio de chips Tropic Square revelado un resultado relacionado: Donjon utilizó la misma técnica, inyección láser de fallas, en el chip TROPIC01 del nuevo Trezor Safe 7.

Esta vez, pasó la verificación de firma del firmware del chip para ejecutar su propio código. Trezor dijo que los fondos se mantuvieron seguros porque Safe 7 acumula tres capas de seguridad separadas y la capa que protege el PIN se mantuvo firme. A diferencia de Tangem, Trezor y Tropic Square, que podrían responder: enviaron un recurso provisional para los chips actuales y están endureciendo la próxima versión del silicio.

Ciberseguridad

Los ataques más baratos a billeteras se remontan a más atrás, pero alcanzan objetivos más débiles. Hace años, este mismo equipo sacó la semilla de la recuperación directamente de un robo Trezor One o Trezor T con una plataforma que costaba alrededor de $100, porque esas billeteras guardaban sus secretos con un microcontrolador ordinario y sin ningún elemento de seguridad.

El chip endurecido de Tangem es la diferencia: es por eso que el mismo tipo de ataque físico ahora necesita un laboratorio de un cuarto de millón de dólares. Sube el listón; Esta investigación muestra que no elimina el peligro. Y un grado como EAL6+ solo avala el chip y sus defensas integradas, no el código que un fabricante de billeteras coloca encima, que es donde reside esta falla.

También es el tercer hallazgo de Donjon en Tangem. Un Omisión de aplicaciones de Android Podría parchearse, porque estaba en los controles del software Tangem. Pero este ataque láser y un método de fuerza bruta de contraseña encontrado anteriormente, ambos se encuentran en el firmware de la tarjeta, que nunca se puede cambiar.

que hacer

Para casi todo el mundo, la respuesta no es nada nueva: conservar la tarjeta donde un ladrón no pueda alcanzarla. Este ataque no puede alcanzar una carta que aún tengas. Si pierde o le roban una tarjeta Tangem y está protegiendo un valor importante, mueva los fondos ahora, usando otra tarjeta de su conjunto (o una frase inicial, si configuró una), y deje de confiar en la contraseña para proteger una tarjeta que ya no controla.

Un investigador detalla la cadena de ataque de WhatsApp al host utilizando tres fallas de OpenClaw – CYBERDEFENSA.MX

Han surgido detalles sobre tres ahora parcheados. fallas de seguridad en el asistente personal de inteligencia artificial (IA) OpenClaw que, si se explota con éxito, podría permitir el robo de credenciales, la escalada de privilegios y la ejecución de código arbitrario en el host.

Una breve descripción de las vulnerabilidades de alta gravedad es la siguiente:

  • GHSA-hjr6-g723-hmfm (Puntuación CVSS: 8,8): una inyección de comando del sistema operativo y una lista incompleta de vulnerabilidades de entradas no permitidas que afectan el mecanismo de filtrado del entorno de ejecución del host y que podrían permitir ejecutar o persistir acciones más allá de la autorización prevista de la persona que llama.
  • GHSA-9969-8g9h-rxwm (Puntuación CVSS: 8,8): una inyección de comando del sistema operativo y una lista incompleta de vulnerabilidades de entradas no permitidas que afectan el mecanismo de filtrado del entorno de ejecución del host y que podrían permitir ejecutar o persistir acciones más allá de la autorización prevista de la persona que llama.
  • GHSA-575v-8hfq-m3mc (Puntuación CVSS: 8,4): una vulnerabilidad de recorrido de ruta y seguimiento de enlace que podría permitir soportes de enlace de caja de arena para eludir las comprobaciones de la lista de denegados del directorio principal y realizar acciones que deberían haberse asegurado con autorizaciones o comprobaciones de políticas más estrictas.

Las tres deficiencias se han solucionado en la versión 2026.6.6 de OpenClaw.

En una serie de avisos publicados la semana pasada, los mantenedores de OpenClaw dijeron que «el impacto práctico depende de la configuración del operador y de si las entradas de menor confianza pueden llegar a ese camino».

Sin embargo, el investigador de seguridad Chinmohan Nayak, a quien se le atribuye haber descubierto e informado los problemas, dijo en un informe compartió con The Hacker News que se pueden usar para activar la ejecución del código host desde un mensaje externo enviado a través de WhatsApp.

A diferencia de las vulnerabilidades de Claw Chain reveladas por Cyera en mayo, los errores recientemente identificados no requieren que un atacante establezca un punto de apoyo previo para extraer datos confidenciales, abrir una puerta trasera persistente, obtener ejecución remota de código arbitrario y facilitar un escape al host.

«`getBlockedReasonForSourcePath()` comprueba si la ruta de origen se encuentra en una ruta bloqueada», explicó el investigador sobre GHSA-575v-8hfq-m3mc. «Pero [it] nunca comprueba lo contrario: si una ruta bloqueada se encuentra en el origen (omisión del directorio principal)».

Ciberseguridad

Específicamente, la lista de denegación de montaje de enlace bloquea directorios como «~/.ssh», «~/.aws» y «~/.gnupg», pero permite montar el directorio principal «/home» o «/var», lo que socava efectivamente los bloques individuales.

«Monte /home en su contenedor y podrá leer las claves SSH, las credenciales de AWS y los secretos GPG de cada usuario», dijo Nayak. «Monte /var y obtendrá el socket Docker, lo que significa un escape completo del host desde el interior del ‘sandbox’».

Además de actualizar OpenClaw a la última versión, se recomienda habilitar el modo sandbox para todas las sesiones no principales, eliminar «exec» de la lista de herramientas permitidas para agentes orientados al canal y monitorear los comandos git clone que contienen el protocolo auxiliar externo «ext::» del que se podría abusar para ejecutar comandos arbitrarios del sistema.

«Antes de actualizar, restrinja la función afectada a operadores confiables o desactívela cuando no sea necesaria», dijo OpenClaw. «Como refuerzo general, mantenga estrechas las listas permitidas de canales y herramientas, evite compartir una puerta de enlace entre usuarios que no sean de confianza mutua y desactive la función afectada cuando no sea necesaria».

How Lumen Technologies Rebuilt Exposure Management at Scale – CYBERDEFENSA.MX

Most enterprises assume their asset inventory is close enough to accurate. The evidence suggests otherwise. According to a survey of over 600 security leaders in the 2026 Axonius Actionability Report, only 45% of organizations consolidate their asset and exposure data into a single view, and every downstream security program inherits whatever the inventory gets wrong.

Lumen Technologies, a telecommunications company with nearly a century of history, put this to the test. Geoff Krahn, Director of Product and Platform Security at Lumen, and his team used the Axonius asset intelligence platform to reconcile data from more than 40 disconnected systems into one trusted view. They uncovered 60 times more devices than they knew they had, then rebuilt their exposure management program on that foundation.

Why asset inventories break down at enterprise scale

Lumen’s environment is an extreme case of a problem most security teams recognize. More than 40 independent IT and security tools tracked different slices of reality at different levels of maturity, none agreeing on device counts, ownership, or coverage status. When leadership asked what percentage of servers had EDR, answering meant pulling from sources that contradicted each other.

«We were constantly in incident response calls with no idea who owned what,» Krahn said.

Axonius gave the team a way to reconcile all of those sources into one model. The scope turned out to be far larger than anyone expected:

  • Starting point: ~17,000 known cyber assets across existing inventories
  • After initial reconciliation: 500,000 devices identified and categorized
  • Current scope: Approximately 1.1 million devices

«It has really been an eye-opener for the organization as a whole how large our responsibilities are,» Krahn said. «Being able to quantify it and highlight gaps in controls has allowed us to gain the leadership support and funding we need.»

What trusted asset data makes possible

Zero-day response

When a critical vulnerability drops, speed depends on knowing what’s exposed and who owns it. Krahn’s team can now identify affected systems, confirm whether they’re externally exposed, and establish ownership within minutes, then push alerts to engineers through a chatbot built on top of Axonius.

«Being able to get near-instantaneous information on how many assets are susceptible to a 0-day vuln, who owns them, are they externally exposed… is pivotal to timely response and communication,» Krahn said.

Application posture visibility

Lumen runs thousands of internal applications. Knowing whether a server is patched doesn’t answer what it supports, who owns the application on it, or what revenue stream a compromise would put at risk.

By correlating CMDB relationships with control coverage, vulnerability data, and end-of-life status, Lumen built an Application Posture Dashboard within Axonius that evaluates risk at the application level rather than the infrastructure level alone. Krahn plans to connect this directly to the products Lumen sells, tying cybersecurity exposure to revenue.

How risk-based exposure management replaces «scan and spam»

Without reliable asset context, most teams default to sorting by CVSS score and working top-down. The Actionability Report found that 56% of organizations still rely primarily on CVSS for prioritization, despite broad agreement that exploitability, blast radius, and business impact should drive those decisions.

Critical issues end up buried behind thousands of medium-severity findings that pose no environment-specific risk. Krahn describes the old model bluntly: «scan and spam.» Scan everything, dump the results, hope the right things get fixed first.

With trusted asset data in place, Lumen took a different path. Axonius Exposures allowed the team to combine technical findings with asset context, business criticality, and control coverage to surface which remediations deliver the greatest risk reduction.

«Exposure management will allow us to evolve vulnerability management beyond scan and spam to intelligent risk-based requests driven by remediation actions that will deliver the most risk reduction,» Krahn said.

Better asset data enables smarter exposure management, and exposure management outcomes reveal where asset data still needs to improve.

What happened when Lumen’s leadership trusted the data

Trusted, quantified visibility changed what leadership was willing to decide:

  • Cloud migration: End-of-life visibility drove Lumen’s decision to migrate the majority of its infrastructure to the cloud
  • 10x security investment: Spending grew to roughly 10 times its previous level as leadership saw the full scope in terms they could act on
  • Board-level reporting: Lumen’s board now relies on Axonius-generated reports for asset coverage, EDR deployment, and compliance insights

«The visibility Axonius was able to shed on the end-of-life issues we had with our systems directly contributed to the decision to migrate the majority of our infrastructure to the cloud, reducing overall risk by 40%,» Krahn said.

Is your asset data carrying the same gaps?

If an organization with dedicated security leadership and 40-plus inventory systems found its cyber asset management picture was off by a factor of 60, most enterprises should assume their own data carries similar gaps. 

Every exposure management program inherits the quality of the asset data underneath it. If that foundation hasn’t been tested, the prioritization, ownership mapping, and remediation workflows built on top of it are working from assumptions, not evidence.

Learn more about Axonius Exposures and risk-based exposure management at enterprise scale.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Una falla XRING sin parche en XQUIC permite que los clientes remotos bloqueen los servidores HTTP/3

Una sola variable incorrecta en una línea en XQUIC, la biblioteca QUIC y HTTP/3 de Alibaba, permite que cualquier cliente remoto bloquee el servidor con una breve ráfaga de tráfico completamente legal. No hay ningún parche.

Sébastien Féry, investigador de FoxIO reveló la falla el 8 de julio y lo apodó XRING. Dice que no necesita inicio de sesión ni paquetes con formato incorrecto: alrededor de 260 bytes de tráfico QPACK normal desactivan el proceso del servidor.

XQUIC es de código abierto, por lo que el riesgo no es solo de Alibaba: cualquier servidor que lo incorpore y sirva HTTP/3 con la configuración QPACK predeterminada está expuesto. Eso incluye Tengine, el servidor web basado en Nginx de Alibaba, que según FoxIO está al frente de la nube y CDN de la compañía en sitios como Taobao y Alipay.

Todas las versiones hasta la v1.9.4, la más reciente, se ven afectadas. No hay ninguna versión fija ni CVE a partir del 10 de julio. Hasta que se envíe una solución, los operadores pueden establecer SETTINGS_QPACK_MAX_TABLE_CAPACITY en 0, lo que desactiva la tabla dinámica de QPACK, o eliminar por completo el soporte HTTP/3.

El error radica en cómo HTTP/3 comprime los encabezados. Para evitar enviar el mismo encabezado (por ejemplo, agente de usuario) una y otra vez, HTTP/3 usa QPACK. Mantiene una tabla compartida que el cliente le indica al servidor que cree y cambie de tamaño a través de un canal de control dedicado, el flujo del codificador.

Ciberseguridad

XQUIC almacena los bytes de esa tabla en un buffer de anilloun bloque fijo de memoria donde los datos se ajustan desde el final hasta el principio una vez que se llenan.

Cuando el cliente solicita hacer crecer la tabla, XQUIC asigna un búfer más grande y copia los datos antiguos. Esa copia tiene cuatro casos, dependiendo de si los datos se ajustan en el búfer antiguo, en el nuevo, en ambos o en ninguno. En uno de ellos, el código dimensiona los datos de cola sobrantes con respecto a la capacidad del nuevo búfer más grande en lugar de la del anterior. Se sobrecuenta mucho.

Haga crecer una tabla de 64 bytes con el cursor de escritura cerca del final y cambie el tamaño a 65, y XQUIC decide que hay 70 bytes finales para mover cuando en realidad hay 6.

Ese número incorrecto fluye hacia una copia de memoria. La longitud de la copia proviene de restar el recuento excesivo de un valor menor. Debido a que esa longitud es un size_t sin firmar, se desborda y se ajusta a un número casi máximo, y la copia se ejecuta hasta el final de la memoria.

En la versión de lanzamiento de FoxIO en Ubuntu 26.04, _FORTIFY_SOURCE=2 de glibc detectó la longitud incorrecta y finalizó el proceso. Sin esa verificación, la copia escribe fuera de los límites, desde el búfer antiguo más allá del final del nuevo. Féry mostró un fracaso, pero no probó si esa corrupción podría explotarse más.

Ninguno de los valores del ataque infringe las reglas de QPACK. XQUIC anuncia un límite de tabla dinámica de 16 KiB de forma predeterminada; la carga útil solicita 64 bytes, luego 65. El cliente solo tiene que conducir la tabla al diseño ajustado exacto que llega a la rama defectuosa. FoxIO dice que el error ha estado en XQUIC desde su primer lanzamiento público en enero de 2022, y una prueba de concepto es público.

XRING es el último de una serie de fallos remotos en pilas HTTP/2 y HTTP/3. Tres semanas antes, THN informó un uso después de la liberación en el módulo HTTP/3 de NGINX (CVE-2026-42530) al que un cliente remoto y no autenticado podría acceder a través del mismo flujo de codificador QPACK, abusos XRING, una clase de error diferente en la misma superficie de ataque.

Ciberseguridad

En junio, la bomba HTTP/2 de Calif provocó una denegación remota de servicio contra Nginx, Apache, IIS y Envoy al abusar de HPACK, la compresión de encabezados de HTTP/2 y el predecesor de QPACK.

En febrero, HAProxy parcheó dos fallas de QUICuno de ellos, un desbordamiento insuficiente de enteros durante la validación del token, el mismo tipo de error detrás de XRING, aunque necesitaba un paquete con formato incorrecto donde XRING no necesita ninguno. Esa diferencia es el punto: entrada legal, un error aritmético, un servidor muerto.

FoxIO demostró una falla, no una ejecución de código, y no informó ninguna explotación en la naturaleza. Dice que envió un correo electrónico a Alibaba el 7 de abril a través de la política de seguridad del proyecto, que promete una respuesta dentro de tres días hábiles, y luego hizo un seguimiento cuatro veces más hasta el 9 de mayo sin respuesta antes de hacerse público.

Hacker News ha preguntado a Alibaba si habrá una solución y un CVE, y si los cinco intentos de divulgación de FoxIO llegaron a su equipo de seguridad. Le ha preguntado a FoxIO si la falla ha sido explotada en la naturaleza y si la escritura en el montón subyacente puede superar una falla. La historia se actualizará con cualquier respuesta.