El nuevo MODBEACON RAT utiliza transmisión gRPC para tráfico C2 cifrado – CYBERDEFENSA.MX

El grupo de cibercrimen vinculado a China conocido como Zorro plateado se ha atribuido a un nuevo troyano de acceso remoto (RAR) basado en Rust llamado MODALIZADOR.

La empresa china de ciberseguridad QiAnXin dijo que si bien el grupo de amenazas puede parecer una operación poco sofisticada y de alta actividad que propaga malware a través de instaladores falsificados utilizando técnicas de envenenamiento de SEO, desmiente su verdadera estructura organizacional, que compromete a múltiples distribuidores.

«Estos distribuidores llevan a cabo actividades en toda Asia utilizando instaladores de software falsificados distribuidos a través de campañas de SEO, aprovechando variantes de las familias de troyanos Gh0st RAT y WinOS (ValleyRAT),», QiAnXin dicho.

Una de esas campañas observada a mediados de junio de 2026 involucró a un distribuidor que entregaba un RAT modular previamente indocumentado dirigido a la tecnología, la educación y las empresas estatales del país. La infraestructura de comando y control (C2) solicitada por MODBEACON está alojada en Amazon y la red de entrega de contenido (CDN) de Cloudflare.

Ciberseguridad

Se considera que el distribuidor es un actor de amenazas híbrido, que actúa como una combinación de «traficante de armas cibercriminal» y «corredor de tráfico». Una rama de sus operaciones implica expandir su huella de infección en toda Asia a través de operaciones diarias de SEO para negocios fraudulentos, mientras que la otra se centra en propagar troyanos avanzados, alquilar acceso de alto valor a clientes intermedios o establecer esquemas «criminal contra criminal» dirigidos al sector del juego camboyano.

La campaña recién descubierta combina ingeniería social, malware personalizado y herramientas posteriores al compromiso para establecer un acceso a largo plazo y al mismo tiempo minimizar la detección en hosts infectados. El malware residente en la memoria funciona como un implante remoto capaz de recuperar módulos adicionales, ejecutar comandos del operador y mantener comunicaciones cifradas con la infraestructura del atacante.

«El troyano es un marco C2 profesional y privado: el cargador y la baliza están separados, la configuración es inyectable, la baliza emplea una arquitectura basada en complementos (complementos nativos v3 con entrada/init/fini RVA) y utiliza transmisión de túnel gRPC para la comunicación», explicó QiAnXin. «La calidad general de la ingeniería es alta. Su principal punto destacado es la reutilización de la capa de transporte de un marco proxy anticensura de código abierto (Xray/V2Ray) como su canal C2».

Al igual que campañas anteriores atribuidas al ecosistema de intrusión de Silver Fox, la cadena de ataque utiliza dominios falsificados que anuncian instaladores falsos de software nacional popular como señuelo para engañar a los usuarios desprevenidos para que descarguen archivos ZIP maliciosos responsables de implementar el malware.

Ciberseguridad

Las capacidades principales de MODBEACON incluyen:

  • Tomando huellas dactilares del anfitrión
  • Cargando complementos en la memoria
  • Enviar mensajes de latidos del corazón
  • Informar los resultados de la ejecución del comando.
  • Configurar la persistencia mediante tareas programadas

«Esta capacidad se puede utilizar para la posterior expansión bajo demanda del robo de información, movimiento lateral, reenvío de proxy u otras cargas útiles», dijo QiAnXin.

La divulgación se produce en medio de una ampliación gradual del arsenal de Silver Fox, que ha implementado familias de malware rastreadas como Atlas RAT, ABCDoor, RomulusLoader y SilentRunLoader, lo que indica que el actor de amenazas está refinando activamente su oficio.

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.

Un ciudadano armenio se declara culpable de los ataques de ransomware Ryuk

Un ciudadano armenio que fue extraditado de Ucrania a Estados Unidos el año pasado. se declaró culpable a participar en una serie de ataques en 2019 y 2020 que involucraron el ransomware Ryuk, dijo el jueves el Departamento de Justicia.

Karen Serobovich Vardanyan se declaró culpable de fraude informático y conspiración para cometer fraude y extorsión. Acordó pagar casi 1,2 millones de dólares en restitución y enfrenta hasta 15 años de cárcel.

El hombre de 34 años admitió haber participado en delitos cibernéticos desde noviembre de 2019 hasta abril de 2020, cuando él y sus cómplices implementaron el ransomware Ryuk contra tres organizaciones con sede en EE. UU. mientras vivían en Ucrania y Rusia.

Las víctimas de Vardanyan incluyen una empresa con sede en Michigan que pagó un rescate de casi 1,2 millones de dólares en enero de 2020, una empresa de tecnología con sede en Watsonville, Oregón, que fue atacada en diciembre de 2019 y una escuela con sede en Texas violada en febrero de 2020.

Los fiscales acusaron previamente a Vardanyan y sus co-conspiradores (los ciudadanos ucranianos Oleg Nikolayevich Lyulyava y Andrii Leonydovich Prykhodchenko, y el ciudadano armenio Levon Georgiyovych Avetisyan) de acceder ilegalmente a redes informáticas para implementar el ransomware Ryuk en cientos de servidores y estaciones de trabajo comprometidos entre marzo de 2019 y septiembre de 2020.

El ransomware Ryuk prevaleció en 2019 y 2020, infectando a miles de víctimas en todo el mundo en el sector privado, municipios estatales y locales, distritos escolares locales e infraestructura crítica, incluida una ola de ataques a hospitales de EE. UU.

Las víctimas de los ataques de ransomware Ryuk incluyen el Hollywood Presbyterian Medical Center, Universal Health Services, Electronic Warfare Associates, una empresa de agua de Carolina del Norte y varios periódicos estadounidenses.

Los operadores de ransomware Ryuk extorsionaron a las empresas víctimas exigiendo pagos de rescate en Bitcoin a cambio de claves de descifrado. Los funcionarios del Departamento de Justicia dijeron que Vardanyan y sus cómplices recibieron alrededor de 1.160 bitcoins (valorados en más de 15 millones de dólares en ese momento) en pagos de rescate de las empresas víctimas.

Vardanyan, como parte de su declaración de culpabilidad, también reconoció que su condena tendrá consecuencias migratorias que resultarán en su expulsión de Estados Unidos después de cumplir su condena.

El Tribunal de Distrito de los Estados Unidos para el Distrito de Oregón aún no ha programado su sentencia.

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.

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.

La filtración de credenciales CISA provoca medidas de seguridad más estrictas

Una importante filtración de credenciales impulsó a la Agencia de Seguridad de Infraestructura y Ciberseguridad a fortalecer la protección de sus materiales confidenciales, mejorar la forma en que los investigadores pueden informar sobre las vulnerabilidades de la agencia y desarrollar planes para incidentes similares, dijo la agencia en un informe forense publicado el jueves.

La publicación del blog describe la respuesta de CISA a la filtración que el investigador que la descubrió en mayo calificó como una de las peores que jamás había visto, que también atrajo el escrutinio del Congreso.

«Compartir experiencias de actividades de respuesta a incidentes ayuda a otras organizaciones a aprender de dichas experiencias y les permite tomar las precauciones necesarias para evitar que ocurran incidentes similares en sus entornos», escribieron Preston Werntz, director de información en funciones, y Brad Libbey, director de seguridad de la información en funciones. «Durante años, CISA ha dicho que este tipo de intercambio de información es fundamental para identificar tendencias y contribuir a una conciencia nacional más amplia. Ahora es nuestro turno».

El 15 de mayo, después de enterarse de la filtración por parte de un contratista de claves privilegiadas de Amazon AWS GovCloud en un repositorio público de GitHub, CISA dijo que había tomado medidas para detener más daños. Eso significó desconectar el repositorio y su entorno de desarrollador y revocar el acceso de la persona responsable de la filtración.

Luego, CISA analizó el repositorio para tener una idea del alcance de la filtración. También analizó los archivos de registro para descubrir que ninguna de las credenciales filtradas se utilizó fuera de CISA y que no se expusieron datos de clientes o de la misión.

La respuesta se benefició al tomar en serio el incidente reportado, tener buenas capacidades de registro y utilizar principios de confianza cero, afirma la publicación del blog.

Pero también mostró algunas cosas que debían solucionarse.

CISA resolvió utilizar sus capacidades de respuesta y detección de puntos finales para monitorear y administrar las cargas a repositorios públicos. Rotó todos sus secretos después del incidente y ideó un plan para mejorar la gestión de sus secretos.

Determinó que facilitaría la denuncia de vulnerabilidades relacionadas con el propio CISA. Es mejor para recibir información sobre vulnerabilidades que son menos específicas de la agencia, dado su papel como centro de comunicación sobre riesgos cibernéticos para los Estados Unidos y el mundo en general, señaló la publicación.

CISA también dijo que tenía que crear un manual para incidentes relacionados con GitHub en medio del incidente, y reconoció la necesidad de crear manuales para todo tipo de incidentes con anticipación.

La persona que descubrió la filtración, el investigador de seguridad de GitGuardian, Guillaume Valadon, aplaudió la evaluación del incidente por parte de CISA.

«Creo que es realmente bueno. CISA logró explicar lo que sucedió, qué funcionó bien y qué se debe mejorar», dijo a CyberScoop por correo electrónico. «Para mí, esta última parte es la primera vez que una agencia nacional de ciberseguridad aboga por el escaneo de secretos y la simplificación de las relaciones con los investigadores».

Eso es algo de lo que Valadon y su equipo han hablado durante un tiempo, y dijo que estaba «orgulloso de leer que está reconocido por CISA».

Tim Starks

Escrito por Tim Starks

Tim Starks es reportero senior de CyberScoop. Sus paradas anteriores incluyen trabajar en The Washington Post, POLITICO y Congressional Quarterly. Originario de Evansville, Indiana, se ocupa de la ciberseguridad desde 2003. Envíe un correo electrónico a Tim aquí: tim.starks@cyberscoop.com.

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.