Menú

Mostrar Mensajes

Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.

Mostrar Mensajes Menú

Mensajes - Dragora

#161

Microsoft ha anunciado oficialmente que desactivará por defecto el protocolo de autenticación NTLM (New Technology LAN Manager) en las próximas versiones de Windows y Windows Server, poniendo fin a más de tres décadas de uso de un mecanismo heredado que ha sido ampliamente explotado por actores maliciosos en ciberataques contra organizaciones de todo el mundo.

Esta decisión marca un cambio estratégico clave en la seguridad de los entornos Windows, alineado con la transición hacia autenticación sin contraseña, resistente al phishing y basada en Kerberos, y supone un paso decisivo para reducir la superficie de ataque en dominios corporativos.

Qué es NTLM y por qué representa un riesgo de seguridad

NTLM es un protocolo de autenticación de desafío-respuesta introducido en 1993 con Windows NT 3.1 como sucesor del antiguo LAN Manager (LM). Aunque fue diseñado para una época en la que las amenazas eran muy limitadas, su arquitectura criptográfica ha quedado obsoleta frente a los estándares actuales.

Desde Windows 2000, Kerberos reemplazó a NTLM como protocolo de autenticación por defecto en dispositivos unidos a dominio. Sin embargo, NTLM ha seguido utilizándose durante años como método de respaldo cuando Kerberos no está disponible, una práctica que ha generado graves problemas de seguridad.

El principal inconveniente de NTLM es que no ofrece protección adecuada contra ataques modernos, carece de verificación mutua robusta y permite múltiples técnicas de abuso ampliamente documentadas.

NTLM y su explotación en ataques reales

A lo largo de los años, NTLM ha sido uno de los vectores favoritos de los atacantes en redes Windows empresariales. Entre los ataques más comunes destacan:

Ataques de retransmisión NTLM (NTLM Relay)

En este tipo de ataque, los actores maliciosos fuerzan a un sistema legítimo a autenticarse contra un servidor controlado por el atacante, reutilizando esa autenticación para escalar privilegios o comprometer servicios críticos.

NTLM ha sido explotado mediante técnicas como:

  • PetitPotam
  • ShadowCoerce
  • DFSCoerce
  • RemotePotato0

Estas vulnerabilidades permiten eludir mitigaciones parciales y tomar el control completo de un dominio Windows, incluso en entornos aparentemente bien configurados.

Ataques de Pass-the-Hash

NTLM también es especialmente vulnerable a ataques de paso de hash, donde los atacantes roban los hashes NTLM de memoria o disco y los reutilizan para autenticarse como el usuario comprometido sin necesidad de conocer la contraseña en texto plano.

Esta técnica facilita:

  • Movimiento lateral
  • Robo de credenciales
  • Acceso persistente
  • Exfiltración de datos sensibles

En muchos incidentes de ransomware y espionaje corporativo, NTLM ha sido el eslabón débil inicial.

Microsoft bloquea NTLM por defecto: un cambio histórico

Como parte de un impulso más amplio hacia métodos de autenticación modernos y resistentes al phishing, Microsoft confirmó que NTLM será deshabilitado por defecto en la próxima gran versión de Windows Server y en las versiones de cliente asociadas.

Citar"Desactivar NTLM por defecto no significa eliminar completamente NTLM de Windows todavía", aclaró Microsoft.
"Significa que Windows se entregará en un estado seguro por defecto, donde la autenticación NTLM de red está bloqueada y ya no se usa automáticamente".

Esto implica que el sistema operativo priorizará Kerberos y otros mecanismos más seguros, reduciendo drásticamente la exposición a ataques conocidos.

Plan de transición de NTLM: tres fases clave

Para minimizar el impacto en organizaciones que aún dependen de NTLM, Microsoft ha diseñado un plan de transición en tres fases:

Fase 1: Auditoría y visibilidad

Disponible en Windows 11 24H2 y Windows Server 2025, esta fase introduce herramientas de auditoría mejoradas que permiten a los administradores identificar con precisión:

  • Dónde se sigue usando NTLM
  • Qué aplicaciones o servicios dependen de él
  • Qué cuentas y sistemas lo invocan

Esta etapa es crítica para planificar una migración controlada.

Fase 2: Eliminación de retrocesos a NTLM

Prevista para la segunda mitad de 2026, esta fase incorporará nuevas capacidades como:

  • IAKerb
  • KDC Local (Centro Local de Distribución de Claves)

Estas tecnologías están diseñadas para resolver escenarios comunes que hoy fuerzan el uso de NTLM, permitiendo mantener compatibilidad sin comprometer la seguridad.

Fase 3: NTLM desactivado por defecto

En la fase final, la autenticación NTLM de red quedará bloqueada por defecto en futuras versiones de Windows. Aunque el protocolo seguirá presente por compatibilidad, solo podrá reactivarse explícitamente mediante políticas de seguridad, lo que refuerza el principio de secure by default.

Una retirada anunciada desde hace años

Este movimiento no es inesperado. Microsoft:

  • Anunció la retirada progresiva de NTLM en octubre de 2023
  • Desaconsejó oficialmente su uso en julio de 2024

Lleva desde 2010 recomendando a desarrolladores y administradores que migren a Kerberos o Negotiate[/b][/color]

Además, ha instado repetidamente a bloquear ataques de retransmisión NTLM mediante AD CS, aunque ahora reconoce que la única solución real es dejar de usar NTLM.

Qué deben hacer las organizaciones ahora

La desactivación por defecto de NTLM obliga a las empresas a:

  • Auditar dependencias heredadas
  • Actualizar aplicaciones antiguas
  • Revisar configuraciones de Active Directory
  • Adoptar autenticación moderna y sin contraseña

Las organizaciones que no actúen con antelación podrían enfrentarse a interrupciones operativas o brechas de seguridad evitables.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#162

Un investigador de seguridad ha revelado pruebas técnicas detalladas que demuestran que algunos perfiles privados de Instagram estuvieron filtrando enlaces a fotos y pies de foto privados a visitantes no autenticados, lo que supone un grave fallo de privacidad y control de acceso en una de las plataformas sociales más grandes del mundo.

Instagram, propiedad de Meta, ofrece desde hace años la opción de cuenta privada, diseñada para limitar el acceso a fotos, vídeos, historias y reels únicamente a seguidores aprobados por el propietario del perfil. Sin embargo, los hallazgos publicados por el investigador muestran que, bajo determinadas condiciones, parte del contenido privado se incrustaba directamente en las respuestas HTML del servidor, haciéndolo accesible a cualquier persona sin iniciar sesión.

Cómo funcionaba la filtración en perfiles privados de Instagram

El investigador de seguridad Jatin Banga demostró que ciertos perfiles privados devolvían enlaces CDN a imágenes privadas y textos de pies de foto dentro del propio código fuente HTML, incluso cuando el perfil mostraba el mensaje estándar de restricción de acceso.

CitarCuando un usuario no autenticado visitaba estos perfiles privados desde determinados dispositivos móviles o con agentes de usuario específicos, Instagram mostraba visualmente el aviso habitual:

"Esta cuenta es privada. Síguela para ver sus fotos y vídeos."

No obstante, al inspeccionar el código fuente de la página, Banga descubrió que el backend de Instagram incluía un objeto JSON llamado polaris_timeline_connection, el cual contenía URLs directas a fotografías privadas almacenadas en la CDN de Meta, además de metadatos como pies de foto.

Esto significa que, aunque el contenido no se renderizaba en pantalla, los enlaces a las imágenes privadas estaban disponibles para cualquiera con conocimientos básicos de inspección HTML, lo que representa un fallo crítico de autorización en el lado del servidor.

Prueba de concepto y alcance del problema

Banga publicó una prueba de concepto en vídeo (PoC) donde se observa claramente cómo los perfiles privados afectados filtran información sensible en tiempo real. Para mantener una divulgación responsable, el investigador limitó sus pruebas exclusivamente a cuentas privadas creadas por él mismo o para las que tenía permiso explícito.

Los resultados fueron alarmantes: al menos el 28% de los perfiles privados analizados devolvían enlaces a fotos privadas y pies de foto, sin requerir autenticación ni aprobación del propietario del perfil.

Desde una perspectiva de ciberseguridad, este tipo de fallo no es una simple filtración accidental, sino un problema estructural de control de acceso, ya que el servidor entregaba datos sin validar correctamente si el visitante estaba autorizado a recibirlos.

Meta parcheó el fallo, pero lo cerró como "no aplicable"

Según el investigador, el fallo fue reportado oficialmente a Meta el 12 de octubre de 2025. Inicialmente, la compañía clasificó el problema como un fallo de caché de CDN, una explicación que Banga rechazó de forma tajante.

Citar"Esto no fue un problema de caché de CDN. El backend de Instagram no comprobaba la autorización antes de rellenar la respuesta", explicó el investigador, calificándolo como un fallo de autorización del lado del servidor.

Tras presentar un segundo informe aclaratorio y mantener largas conversaciones durante varios días, Meta cerró el caso como "no aplicable", alegando que la vulnerabilidad no podía reproducirse. Sin embargo, el exploit dejó de funcionar alrededor del 16 de octubre, apenas unos días después del reporte inicial.

Esto sugiere que Meta aplicó un parche silencioso, sin reconocer oficialmente la existencia del problema ni realizar un análisis de causa raíz.

Divulgación responsable y falta de transparencia

Banga afirmó que respetó ampliamente la ventana estándar de divulgación coordinada de 90 días, esperando 102 días completos antes de hacer pública la información. A pesar de ello, Meta nunca confirmó formalmente la naturaleza del fallo.

Citar"El exploit dejó de funcionar en todas las cuentas que probé, pero sin un análisis de causa raíz por parte de Meta, no hay confirmación de que el problema subyacente esté realmente resuelto", señaló el investigador.

Además de publicar un repositorio en GitHub con abundante evidencia técnica y correspondencia con Meta, Banga compartió materiales adicionales con BleepingComputer, medio especializado que verificó la existencia del fallo.

Por qué la Wayback Machine no pudo capturar la prueba

Ante la pregunta de por qué no se utilizó la Wayback Machine para archivar el HTML afectado, el investigador explicó que los rastreadores de Internet Archive no envían el agente de usuario móvil ni los encabezados específicos necesarios para activar la filtración en el servidor de Instagram.

En otras palabras, el fallo solo se manifestaba bajo condiciones muy concretas, lo que no invalida su gravedad, sino que refuerza la necesidad de auditorías exhaustivas en plataformas de gran escala.

Un problema mayor de privacidad y confianza

CitarBanga fue claro al afirmar que no buscaba una recompensa económica:

"Al hacer pública esta revelación, he perdido cualquier posibilidad de recompensa. El objetivo es la transparencia."

Según el investigador, Meta parcheó una filtración crítica de privacidad en menos de 96 horas, pero se negó a reconocerla públicamente, calificándola como un "efecto secundario no intencionado". Esta actitud plantea serias dudas sobre la gestión interna de vulnerabilidades, la transparencia y la protección real de los datos de los usuarios.

A día de hoy, nadie sabe cuánto tiempo estuvo activa esta filtración, ni si fue explotada por terceros maliciosos. BleepingComputer intentó contactar con Meta en tres ocasiones antes de la publicación del informe, sin obtener respuesta

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#163

De pequeño, muchos crecimos soñando con jugar a los títulos más nuevos y emocionantes. Para algunos fueron FIFA, Zelda o Command & Conquer: Red Alert. Hoy, para nuestros hijos, los nombres han cambiado: Roblox, Minecraft y Call of Duty. Sin embargo, el patrón se mantiene intacto: el deseo de acceder a contenido premium, desbloquear funciones ocultas o mejorar el rendimiento del juego.

Antes, ese impulso nos llevaba a buscar "descarga gratuita de FIFA 2003". Hoy, conduce a búsquedas como "Roblox FPS Booster gratis 2025" o "mod Roblox sin baneos". Lo que parece un comportamiento infantil e inocente se ha convertido en uno de los vectores de infección más eficaces del cibercrimen moderno.

El clic que lo cambia todo

El escenario es tan común que resulta inquietante. Un niño quiere que Roblox funcione más rápido, desbloquear una función o usar el mismo mod que sus amigos. Busca en Google o YouTube, encuentra un vídeo con un título llamativo, entra a un servidor de Discord, descarga un archivo ZIP y hace doble clic en un ejecutable llamado algo como RobloxExecutor.exe.

  • El juego se abre. Todo parece normal.
  • Pero en segundo plano, acaba de ejecutarse un malware infostealer.

En cuestión de segundos, ese programa ha recolectado todas las credenciales almacenadas en el sistema: contraseñas del navegador, cookies de sesión, tokens de autenticación y accesos activos a servicios como Gmail, Discord, Steam, Microsoft, e incluso VPN corporativas, Okta, Slack o GitHub.

  • La infección ocurre en el salón de tu casa.
  • La brecha ocurre en tu empresa.

Los gamers como vector de ataque principal

Esto no es un caso aislado ni una exageración. Investigaciones recientes de inteligencia de amenazas confirman que más del 40% de las infecciones por malware infostealer se originan en archivos relacionados con videojuegos: mods, trucos, cracks, launchers falsos y supuestas "mejoras de rendimiento".

Desde la perspectiva de un atacante, los jugadores son objetivos ideales:

  • Mayoría niños o adolescentes
  • Descargan software de terceros constantemente
  • Desactivan el antivirus para "hacer que funcione el mod"
  • Confían en enlaces de Discord y repositorios de GitHub
  • Buscan atajos, trampas y bypass
  • Ejecutan archivos sin verificar su origen

Lo más importante: están entrenados para ejecutar código no confiable. Ese comportamiento es exactamente lo que necesitan los operadores de robo de información.

El flujo moderno de infección con mods de Roblox

Una infección típica sigue este patrón:


1. Búsquedas como:

  • "Desbloqueador FPS Roblox"
  • "Roblox executor free"
  • "Inyector de scripts Roblox"

2. El usuario llega a:

  • Un vídeo de YouTube
  • Un servidor de Discord
  • Un repositorio de GitHub
  • Un enlace de Google Drive

3. Descarga un archivo:

Código: text
RobloxMod.zip
  └── install.exe

4. Al ejecutar install.exe, no se instala ningún mod. Se ejecuta Lumma, RedLine, Vidar o Raccoon, algunos de los infostealers más activos del planeta.

  • No hay exploit.
  • No hay vulnerabilidad.
  • No hay hackeo.

Solo ingeniería social y un doble clic.

¿Qué hace realmente un infostealer?

Una vez en ejecución, un infostealer moderno comienza inmediatamente a recopilar:

  • Contraseñas guardadas del navegador
  • Cookies de sesión
  • Datos de autocompletado
  • Tokens OAuth
  • Tokens de Discord
  • Credenciales VPN
  • Monederos de criptomonedas
  • Accesos a servicios en la nube
  • Claves SSH
  • Credenciales FTP

Desde navegadores como Chrome, Edge, Firefox o Brave, clientes de correo, gestores de contraseñas, herramientas de desarrollo y software corporativo.

Todo el proceso dura segundos. Los datos se empaquetan en un "stealer log", una instantánea completa de la identidad digital del usuario, que luego se sube a Telegram, mercados rusos, foros clandestinos y plataformas de Stealer-as-a-Service.

De un juego infantil a una brecha empresarial

Aquí está el punto crítico que muchos pasan por alto: a los infostealers no les importa quién ejecutó el archivo, sino qué identidades existen en ese dispositivo.

Ese portátil también puede usarse para:

  • Revisar el correo corporativo
  • Acceder a Slack o Teams
  • Iniciar sesión en Okta
  • Conectarse a la VPN
  • Aprobar solicitudes MFA
  • Acceder a GitHub o paneles internos

Así, un simple mod de Roblox puede exfiltrar:

  • Credenciales SSO corporativas
  • Contraseñas de Active Directory
  • Cookies de sesión que eluden MFA
  • Acceso a plataformas SaaS internas

Y ahora tu empresa está comprometida, no por una vulnerabilidad técnica, sino por una descarga de ocio.

La economía criminal detrás del robo de identidad

En el subsuelo digital, los actores maliciosos compran y venden:

  • Registros completos de infostealers
  • Accesos por país, empresa o rol
  • Servicios gestionados de Stealer-as-a-Service
  • Tutoriales paso a paso para monetización

La identidad se ha convertido en la mercancía más valiosa del cibercrimen moderno.

No es un problema de niños, es un problema de identidad

El verdadero peligro de los infostealers no es el malware en sí, sino el cambio de paradigma que representan. Hoy, los ataques ya no comienzan con exploits sofisticados, sino con:

  • Robo masivo de credenciales
  • Compra de identidades al por mayor
  • Inicio de sesión legítimo
  • Bypass de MFA mediante cookies
  • Movimiento lateral sin levantar alertas

Por eso, cada vez más brechas empiezan con la misma frase:

Citar"Se utilizaron credenciales válidas."

Y no con:

Citar"Se explotó una vulnerabilidad."

Los infostealers han reemplazado silenciosamente a los exploits como vector de acceso inicial dominante.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#164

El ecosistema global de ciberamenazas ha marcado un nuevo punto de inflexión tras confirmarse el mayor ataque de denegación de servicio distribuida (DDoS) jamás registrado. La botnet Aisuru, también conocida como Kimwolf, lanzó una campaña hipervolumétrica que alcanzó un pico de 31,4 terabits por segundo (Tbps) y más de 200 millones de solicitudes HTTP por segundo, superando todos los récords anteriores conocidos.

El ataque fue detectado y mitigado por Cloudflare el 19 de diciembre de 2025, como parte de una campaña dirigida principalmente contra proveedores de servicios de telecomunicaciones y organizaciones del sector TI. Debido a su proximidad con las festividades, Cloudflare bautizó esta ofensiva como "La Noche Antes de Navidad", describiéndola como un bombardeo sin precedentes contra infraestructuras críticas de Internet.

Un nuevo récord absoluto en ataques DDoS

Según el informe técnico publicado por Cloudflare el 29 de enero de 2026, la campaña de Aisuru combinó ataques DDoS HTTP hipervolumétricos con ataques de Capa 4 (transporte), alcanzando cifras nunca antes divulgadas públicamente.

Citar"Los ataques superaron las tasas de 200 millones de solicitudes por segundo y alcanzaron un máximo de 31,4 Tbps, convirtiéndose en el mayor ataque DDoS jamás hecho público", señaló Cloudflare.

Este nuevo récord supera el ataque anterior atribuido a la misma botnet, que había alcanzado 29,7 Tbps, así como otro incidente documentado por Microsoft que llegó a 15,72 Tbps, originado desde aproximadamente 500.000 direcciones IP.

Ataques breves, pero extremadamente intensos

Uno de los aspectos más llamativos de esta campaña es su duración limitada, pero con una intensidad extrema. Cloudflare reveló que:

  • Más del 50% de los ataques duraron entre uno y dos minutos
  • Solo el 6% superó ese umbral
  • El 90% alcanzó picos de entre 1 y 5 Tbps
  • Aproximadamente el 94% se situó en el rango de 1 a 5 mil millones de paquetes por segundo (Bpps)

A pesar de su magnitud, Cloudflare confirmó que todos los ataques fueron detectados y mitigados de forma automática, sin necesidad de intervención humana ni activación de alertas internas. Este dato subraya la evolución de los sistemas de mitigación DDoS basados en automatización y análisis en tiempo real.

Android TV como fuente principal del ataque

Tradicionalmente, la botnet Aisuru ha estado asociada a routers y dispositivos IoT comprometidos, una constante en las campañas DDoS modernas. Sin embargo, en esta ocasión, Cloudflare identificó que Android TV fue la principal fuente del tráfico malicioso durante la campaña "La Noche Antes de Navidad".

Este hallazgo confirma una tendencia creciente: la convergencia entre dispositivos de consumo y amenazas a gran escala, donde sistemas aparentemente inofensivos se convierten en armas dentro de botnets masivas debido a configuraciones inseguras, firmware desactualizado o credenciales débiles.

2025: un año récord para los ataques DDoS

El Informe de Amenazas DDoS del cuarto trimestre de 2025 de Cloudflare ofrece una visión preocupante del panorama global. A lo largo de 2025, la compañía mitigó 47,1 millones de ataques DDoS, lo que representa un aumento del 121% en comparación con 2024.

En promedio, Cloudflare bloqueó 5.376 ataques DDoS por hora, una cifra que ilustra la escala industrial que han alcanzado estas ofensivas. Del total:

  • El 73% correspondió a ataques de capa de red (L3/L4)
  • El resto fueron ataques HTTP (capa de aplicación)

El cuarto trimestre del año mostró un crecimiento adicional del 31% trimestre a trimestre y del 58% interanual, confirmando que la tendencia al alza continúa sin señales de desaceleración.

Sectores más atacados y origen del tráfico

Durante este periodo, las industrias más afectadas fueron:

  • Proveedores de servicios de telecomunicaciones
  • Empresas de TI y servicios gestionados
  • Plataformas de juegos de azar y casinos
  • Empresas de videojuegos y entretenimiento online

En cuanto al origen geográfico del tráfico malicioso, Bangladés lideró la lista como principal fuente de ataques, seguido de Ecuador e Indonesia. Un dato relevante es que Argentina ascendió al cuarto puesto, mientras que Rusia descendió cinco posiciones hasta el décimo lugar.

Por otro lado, los principales objetivos de los ataques DDoS en 2025 se concentraron en China, Hong Kong, Alemania, Brasil y Estados Unidos, reflejando la focalización en economías digitales altamente conectadas.

Ataques más potentes y mejor organizados

El informe también destaca una escalada cualitativa en las capacidades ofensivas de las botnets modernas:

  • Incremento del 600% en ataques de capa de red que superan los 100 millones de paquetes por segundo (Mpps)
  • Aumento del 65% en ataques que superan el umbral de 1 Tbps
  • Más del 71,5% de los ataques HTTP DDoS provienen de botnets conocidas o previamente documentadas

Estos datos confirman que los atacantes están reutilizando y perfeccionando infraestructuras existentes, reduciendo costes y aumentando la eficacia de sus campañas.

Un escenario que exige defensas automatizadas

El ataque récord de Aisuru demuestra que los DDoS hipervolumétricos ya no son eventos excepcionales, sino parte de una realidad operativa constante. Para las organizaciones, especialmente aquellas que operan infraestructuras críticas, la conclusión es clara: la mitigación DDoS debe ser automática, escalable y siempre activa.

En un entorno donde los ataques pueden alcanzar decenas de terabits por segundo en cuestión de segundos, la resiliencia de red se ha convertido en un requisito estratégico, no en una opción.

Funete: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#165

SmarterTools ha publicado actualizaciones de seguridad urgentes para su plataforma de correo electrónico SmarterMail, abordando dos vulnerabilidades críticas que podrían permitir a atacantes remotos ejecutar código arbitrario y comprometer por completo servidores de correo corporativos. Una de estas fallas ya ha sido explotada activamente en la naturaleza, lo que eleva significativamente el nivel de riesgo para organizaciones que aún no han aplicado los parches.

La vulnerabilidad más grave, identificada como CVE-2026-24423, cuenta con una puntuación CVSS de 9,3 sobre 10, lo que la clasifica como crítica. Afecta a todas las versiones de SmarterMail anteriores a la Build 9511, y permite ejecución remota de código (RCE) sin autenticación, un escenario especialmente peligroso en servicios expuestos a Internet como los servidores de correo.

CVE-2026-24423: ejecución remota de código sin autenticación

Según la descripción oficial publicada en You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, la falla reside en el método de la API ConnectToHub, el cual no valida correctamente los datos suministrados por el usuario remoto.

Citar"Un atacante puede apuntar SmarterMail a un servidor HTTP malicioso que entregue comandos del sistema operativo. Estos comandos son posteriormente ejecutados por la aplicación vulnerable."

En términos prácticos, esto significa que cualquier atacante remoto, sin necesidad de credenciales válidas, podría tomar el control total del servidor SmarterMail, ejecutar comandos del sistema operativo subyacente, instalar malware persistente o utilizar el sistema como punto de partida para ataques laterales dentro de la red corporativa.

La vulnerabilidad fue descubierta y reportada de forma responsable por los investigadores Sina Kheirkhah y Piotr Bazydlo (watchTowr), Markus Wulftange (CODE WHITE GmbH) y Cale Black (VulnCheck), quienes han sido reconocidos oficialmente por SmarterTools.

Parche crítico disponible desde enero de 2026

SmarterTools corrigió CVE-2026-24423 en la Build 9511, publicada el 15 de enero de 2026. Esta misma versión también soluciona otra falla crítica, CVE-2026-23760 (CVSS 9,3), que ha sido explotada activamente en ataques reales durante las últimas semanas.

Aunque SmarterTools no ha revelado detalles técnicos completos sobre la explotación activa de CVE-2026-23760, la combinación de alta severidad, explotación confirmada y exposición directa a Internet convierte a SmarterMail en un objetivo atractivo para actores maliciosos, incluidos grupos de ransomware y operadores de botnets.

CVE-2026-25067: riesgo de ataques NTLM y autenticación no autorizada

Además de las fallas críticas, SmarterTools también abordó una vulnerabilidad de gravedad media, CVE-2026-25067, con una puntuación CVSS de 6,9. Aunque menos severa en apariencia, esta vulnerabilidad puede facilitar ataques avanzados de red en entornos Windows.

VulnCheck describió el problema como un caso de coerción de rutas no autenticadas que afecta al endpoint de vista previa en segundo plano de SmarterMail.

Citar"La aplicación decodifica en base64 la entrada suministrada por el atacante y la utiliza como una ruta del sistema de archivos sin ningún tipo de validación."

En sistemas Windows, esta debilidad permite resolver rutas UNC (Universal Naming Convention), lo que provoca que el servicio SmarterMail inicie conexiones SMB salientes hacia servidores controlados por el atacante. Este comportamiento puede ser explotado para:

  • Coacción de credenciales
  • Ataques de retransmisión NTLM
  • Autenticación no autorizada en la red
  • Movimiento lateral dentro del dominio

Este tipo de ataques es especialmente peligroso en entornos empresariales que aún dependen de NTLM para autenticación interna, una práctica que continúa siendo común en muchas infraestructuras heredadas.

Corrección adicional en la Build 9518

La vulnerabilidad CVE-2026-25067 fue corregida en la Build 9518, publicada el 22 de enero de 2026. SmarterTools recomienda actualizar directamente a esta versión o superior para garantizar que todas las fallas conocidas estén mitigadas.

Dado que al menos dos vulnerabilidades en SmarterMail han sido explotadas activamente en la última semana, los expertos en seguridad subrayan la necesidad de aplicar las actualizaciones de inmediato, especialmente en servidores expuestos a Internet o integrados en infraestructuras críticas de correo electrónico.

Impacto para organizaciones y administradores de correo

Los servidores de correo siguen siendo uno de los activos más valiosos y atacados dentro de las redes corporativas. Una explotación exitosa de SmarterMail podría permitir:

  • Robo masivo de correos electrónicos
  • Acceso a credenciales internas
  • Instalación de puertas traseras persistentes
  • Uso del servidor para campañas de phishing
  • Despliegue de ransomware

La situación refuerza la importancia de gestionar el correo electrónico como infraestructura crítica, aplicando controles como segmentación de red, autenticación robusta, monitorización continua y parches de seguridad oportunos.

Recomendaciones de seguridad

Los equipos de TI y ciberseguridad deben:

  • Actualizar inmediatamente a SmarterMail Build 9518 o superior.
  • Restringir el acceso a APIs administrativas.
  • Monitorizar tráfico SMB saliente inusual.
  • Deshabilitar NTLM cuando sea posible.
  • Auditar logs en busca de indicadores de compromiso.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#166

El rápido avance y adopción de la inteligencia artificial (IA) de código abierto está transformando la forma en que empresas y particulares despliegan grandes modelos de lenguaje (LLM). Sin embargo, esta democratización tecnológica también está generando una nueva superficie de ataque masiva y poco controlada, según una investigación conjunta de SentinelOne, SentinelLABS y Censys.

El estudio revela la existencia de una "capa no gestionada y públicamente accesible de infraestructura de IA", compuesta por más de 175.000 hosts únicos de Ollama expuestos a Internet en 130 países. Esta infraestructura, que opera fuera de los mecanismos de seguridad y monitorización tradicionales, representa un riesgo crítico para la seguridad global de los sistemas de IA.

Ollama: IA local convertida en un riesgo global

Ollama es un framework de código abierto que permite descargar, ejecutar y gestionar modelos de lenguaje de gran tamaño de forma local en Windows, macOS y Linux. Por defecto, el servicio se vincula a la dirección local 127.0.0.1:11434, lo que limita su acceso al propio sistema.

No obstante, los investigadores advierten que un cambio de configuración trivial —vincular el servicio a 0.0.0.0 o a una interfaz pública— basta para exponer completamente el endpoint a Internet, sin autenticación ni controles de acceso adecuados. Esta facilidad de exposición es uno de los factores clave detrás de la proliferación de instancias vulnerables.

Un problema verdaderamente global

El análisis de Censys muestra que más del 30% de las exposiciones se concentran en China, seguida de países como Estados Unidos, Alemania, Francia, Corea del Sur, India, Rusia, Singapur, Brasil y Reino Unido. Los hosts detectados no se limitan a entornos cloud, sino que incluyen redes residenciales, lo que complica enormemente la gobernanza y la visibilidad para los equipos de seguridad.

Esta dispersión geográfica y topológica refuerza la idea de que la infraestructura de IA ya no está confinada a centros de datos corporativos, sino que se está desplegando en el borde (edge computing), muchas veces sin políticas de seguridad formales.

Llamadas de herramientas: el verdadero punto crítico

Uno de los hallazgos más preocupantes es que más del 48% de los hosts Ollama expuestos anuncian capacidades de llamada de herramientas (tool calling) a través de sus APIs. Esta funcionalidad permite que los LLM:

  • Ejecuten código
  • Accedan a APIs externas
  • Consulten bases de datos
  • Interactúen con sistemas internos

Según los investigadores Gabriel Bernadett-Shapiro y Silas Cutler, casi la mitad de los sistemas observados están integrados en flujos operativos reales, lo que amplía drásticamente el impacto potencial de una explotación.

Citar"Las capacidades de llamada de herramientas alteran fundamentalmente el modelo de amenaza. Un endpoint de generación de texto puede producir contenido dañino, pero un endpoint habilitado por herramientas puede ejecutar operaciones privilegiadas".

Cuando esta capacidad se combina con autenticación insuficiente y exposición directa a Internet, se crea lo que los expertos califican como el riesgo de mayor gravedad dentro del ecosistema LLM actual.

Modelos sin censura y capacidades avanzadas

La investigación también identificó 201 hosts que ejecutan plantillas de prompts sin censura, eliminando salvaguardas básicas y permitiendo usos potencialmente maliciosos. Además, se detectaron instancias con capacidades multimodales avanzadas, que incluyen:

  • Razonamiento complejo
  • Procesamiento de visión
  • Interacciones más allá del texto tradicional

Este tipo de configuraciones expuestas incrementa el valor de la infraestructura para actores maliciosos.

LLMjacking: monetización criminal de la IA expuesta

La consecuencia directa de esta exposición es el LLMjacking, una técnica mediante la cual los atacantes secuestran recursos LLM ajenos para su propio beneficio, mientras la víctima asume los costes de computación.

Los usos maliciosos documentados incluyen:

  • Generación masiva de spam
  • Campañas de desinformación
  • Minería de criptomonedas
  • Reventa de acceso a infraestructura de IA

Lejos de ser un riesgo teórico, un informe reciente de Pillar Security confirma que los atacantes están explotando activamente endpoints LLM expuestos como parte de una campaña denominada Operación Bizarre Bazaar.

Un mercado negro de IA plenamente operativo

Según los investigadores Eilon Cohen y Ariel Fogel, esta operación criminal consta de tres fases bien definidas:

  • Escaneo sistemático de Internet en busca de instancias Ollama, servidores vLLM y APIs compatibles con OpenAI sin autenticación.
  • Validación de los endpoints, evaluando la calidad y utilidad de las respuestas.
  • Comercialización del acceso a precios reducidos a través de plata[.]inc, una pasarela API LLM unificada.

Esta infraestructura ha sido atribuida a un actor de amenazas conocido como Hecker, también identificado como Sakuya o LiveGamer101, y representa el primer mercado documentado de LLMjacking con atribución completa.

Un nuevo reto para la ciberseguridad moderna

La naturaleza descentralizada de Ollama y otros frameworks de IA local crea brechas significativas de gobernanza, especialmente cuando se despliegan en entornos residenciales. Además, estas instancias pueden utilizarse como proxies para tráfico malicioso, facilitando inyecciones rápidas y evasión de controles tradicionales.

Los investigadores concluyen que los LLM ya no deben tratarse como simples aplicaciones experimentales:

Citar"Los LLM se están desplegando cada vez más en el borde para traducir instrucciones en acciones. Por ello, deben contar con los mismos controles de autenticación, monitorización y segmentación de red que cualquier infraestructura accesible externamente".

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#167

Investigadores en ciberseguridad han identificado que actores amenazantes vinculados a China están utilizando una versión actualizada de la puerta trasera COOLCLIENT como parte de campañas de ciberespionaje en curso durante 2025. El objetivo principal de estas operaciones es facilitar el robo integral de datos desde puntos finales comprometidos, ampliando significativamente las capacidades tradicionales de espionaje digital.

La actividad ha sido atribuida al conocido grupo Mustang Panda, también rastreado bajo los nombres Earth Preta, Fireant, HoneyMyte, Polaris y Twill Typhoon. Según los hallazgos, las intrusiones se han dirigido principalmente contra entidades gubernamentales y organismos públicos en países como Myanmar, Mongolia, Malasia y Rusia, lo que refuerza el carácter geopolítico de estas campañas.

COOLCLIENT como parte de un ecosistema de malware más amplio

La empresa de ciberseguridad Kaspersky, que publicó un análisis técnico detallado del malware actualizado, indicó que COOLCLIENT se despliega como una puerta trasera secundaria, normalmente junto a infecciones de PlugX y LuminousMoth, dos familias de malware ampliamente asociadas con grupos APT chinos.

Según Kaspersky, COOLCLIENT se entrega habitualmente mediante archivos de cargador cifrados, que contienen datos de configuración protegidos, shellcode y módulos DLL de siguiente etapa cargados directamente en memoria. Este enfoque reduce la huella en disco y dificulta la detección por soluciones de seguridad tradicionales.

Un elemento clave del ataque es el uso sistemático de carga lateral de DLL (DLL sideloading) como método principal de ejecución. Para ello, los atacantes emplean ejecutables legítimos firmados digitalmente, que cargan de forma inadvertida bibliotecas DLL maliciosas.

Abuso de software legítimo firmado

Entre 2021 y 2025, Mustang Panda ha aprovechado binarios firmados de múltiples productos de software conocidos, incluyendo:

  • Bitdefender (qutppy.exe)
  • VLC Media Player (vlc.exe, renombrado como googleupdate.exe)
  • Ulead PhotoImpact (olreg.exe)
  • Sangfor (sang.exe)

Las campañas más recientes, observadas entre 2024 y 2025, muestran un abuso reiterado de software legítimo desarrollado por Sangfor. En una de estas oleadas, dirigida específicamente contra Pakistán y Myanmar, los atacantes distribuyeron una variante de COOLCLIENT capaz de cargar y ejecutar un rootkit previamente desconocido, elevando el nivel de sofisticación del ataque.

Evolución histórica de COOLCLIENT

COOLCLIENT fue documentado por primera vez en noviembre de 2022 por Sophos, en un informe que detallaba el uso generalizado de la carga lateral de DLL por parte de grupos APT con sede en China. Posteriormente, Trend Micro atribuyó formalmente la puerta trasera a Mustang Panda, destacando sus capacidades para leer y eliminar archivos, así como monitorizar el portapapeles y las ventanas activas.

En junio de 2024, Symantec y el Carbon Black Threat Hunter Team de Broadcom revelaron que COOLCLIENT también se utilizó en ataques prolongados contra múltiples operadores de telecomunicaciones en un país asiático, en una campaña de espionaje que podría haberse iniciado tan pronto como en 2021.

Capacidades avanzadas de espionaje y control

El diseño de COOLCLIENT está claramente orientado a la exfiltración masiva de información y al control persistente del sistema comprometido. El malware recopila información del sistema y del usuario, incluyendo:

  • Pulsaciones de teclas (keylogging)
  • Contenido del portapapeles
  • Archivos locales
  • Credenciales proxy HTTP, extraídas del tráfico de red del host

La comunicación con el servidor de comando y control (C2) se realiza a través de TCP, desde donde los operadores pueden enviar instrucciones específicas. COOLCLIENT también puede establecer túneles inversos o proxies, así como recibir y ejecutar plugins adicionales directamente en memoria, lo que amplía dinámicamente sus funcionalidades.

Entre los plugins observados se incluyen:

  • ServiceMgrS.dll: gestión y supervisión de todos los servicios del sistema
  • FileMgrS.dll: enumeración, creación, movimiento, lectura, compresión, búsqueda y eliminación de archivos y carpetas
  • RemoteShellS.dll: shell remota que lanza cmd.exe y permite ejecutar comandos y capturar su salida

Robo de credenciales y post-explotación

Mustang Panda también ha sido observado desplegando múltiples programas especializados en el robo de credenciales almacenadas en Google Chrome, Microsoft Edge y otros navegadores basados en Chromium. En al menos un incidente documentado, el adversario ejecutó un comando cURL para exfiltrar el archivo cookies.sqlite de Mozilla Firefox directamente a Google Drive, una técnica discreta que aprovecha servicios legítimos para el robo de datos.

Estos ladrones de credenciales, detectados en ataques contra el sector público en Myanmar, Malasia y Tailandia, parecen formar parte de estrategias más amplias de post-explotación, destinadas a mantener acceso prolongado y ampliar el alcance del espionaje.

Uso combinado de TONESHELL y otras cargas

Las campañas también se caracterizan por el uso del malware TONESHELL (también conocido como TOnePipeShell), empleado para establecer persistencia y desplegar cargas adicionales como:

  • QReverse, un troyano de acceso remoto con shell remota, gestión de archivos, capturas de pantalla y recopilación de información
  • TONEDISK, un gusano USB diseñado para propagación lateral en entornos aislados

El análisis de Kaspersky reveló además similitudes de código entre el ladrón de cookies de COOLCLIENT y herramientas utilizadas por LuminousMoth, lo que sugiere compartición de recursos y colaboración técnica entre distintos clústeres de amenazas.

Un cambio hacia la vigilancia activa

Según Kaspersky, las campañas atribuidas a HoneyMyte / Mustang Panda representan una evolución clara del espionaje tradicional hacia modelos de vigilancia activa y continua.

"Con capacidades como keylogging, monitorización del portapapeles, robo de credenciales proxy y exfiltración masiva de archivos, estas campañas van mucho más allá del simple robo de documentos", concluyó la compañía. Este enfoque indica un interés creciente en observar el comportamiento de los usuarios en tiempo real, capturar credenciales sensibles y mantener una visibilidad persistente sobre los sistemas comprometidos.

En fin...

El uso avanzado de COOLCLIENT por parte de Mustang Panda confirma que los grupos APT vinculados a China continúan refinando sus tácticas, técnicas y procedimientos (TTP). La combinación de malware modular, abuso de software legítimo firmado y capacidades de vigilancia activa convierte estas campañas en una amenaza significativa para gobiernos, infraestructuras críticas y sectores estratégicos, subrayando la necesidad de detección avanzada, defensa en profundidad y monitoreo continuo.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#168

Investigadores en ciberseguridad han identificado una nueva extensión maliciosa en el marketplace oficial de Microsoft Visual Studio Code (VS Code) que suplanta a Moltbot, anteriormente conocido como Clawdbot. La extensión se presentaba como un asistente gratuito de programación basado en inteligencia artificial (IA), pero en realidad ejecutaba de forma sigilosa una cadena de infección diseñada para comprometer completamente los sistemas de los desarrolladores.

La extensión fraudulenta, denominada "ClawdBot Agent – AI Coding Assistant" (clawdbot.clawdbot-agent), fue publicada el 27 de enero de 2026 por un usuario llamado clawdbot y posteriormente retirada por Microsoft tras ser reportada. El incidente pone nuevamente de relieve los riesgos de seguridad en la cadena de suministro de software, incluso dentro de repositorios oficiales ampliamente utilizados por desarrolladores.

Aprovechando la popularidad de Moltbot

Moltbot ha experimentado un crecimiento explosivo, superando las 85.000 estrellas en GitHub al momento de la investigación. El proyecto de código abierto, creado por el desarrollador austriaco Peter Steinberger, permite a los usuarios ejecutar un asistente personal de IA impulsado por un gran modelo de lenguaje (LLM) de forma local y comunicarse con él mediante plataformas ampliamente utilizadas como WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, Microsoft Teams y WebChat.

Un aspecto clave del ataque es que Moltbot no cuenta con una extensión legítima para VS Code. Los actores maliciosos aprovecharon esta ausencia y la creciente notoriedad del proyecto para engañar a desarrolladores desprevenidos, que asumieron erróneamente que la extensión era oficial o estaba respaldada por el proyecto original.

Ejecución automática y entrega de malware

Una vez instalada, la extensión maliciosa estaba diseñada para ejecutarse automáticamente cada vez que se iniciaba el IDE de VS Code, sin interacción adicional del usuario. En segundo plano, la extensión descargaba un archivo config.json desde un servidor externo controlado por los atacantes (clawdbot.getintwopc[.]sitio).

Este archivo configuraba la ejecución de un binario llamado Code.exe, cuya función principal era instalar una aplicación legítima de acceso remoto, ConnectWise ScreenConnect. Aunque se trata de una herramienta utilizada comúnmente para soporte técnico remoto, en este contexto se empleó como un implante de acceso persistente.

Tras su instalación, el cliente ScreenConnect se conectaba automáticamente a la infraestructura del atacante en la dirección meeting.bulletmailer[.]net:8041, otorgando a los operadores del malware control remoto completo y persistente sobre el host comprometido.

Uso de herramientas legítimas como arma

Según explicó Charlie Eriksen, investigador de seguridad en Aikido, los atacantes configuraron su propio servidor de retransmisión de ScreenConnect, generaron un instalador cliente preconfigurado y lo distribuyeron directamente a través de la extensión de VS Code.

Este enfoque encaja con la tendencia creciente de "living-off-the-land", en la que los atacantes utilizan software legítimo y firmado para evadir detecciones tradicionales, dificultando la identificación del compromiso por parte de soluciones de seguridad.

Múltiples mecanismos de respaldo para la carga útil

La extensión no dependía de un único método de entrega. Incorporaba mecanismos de respaldo sofisticados para garantizar que la carga útil se desplegara incluso si parte de la infraestructura de comando y control (C2) fallaba.

Uno de estos métodos consistía en recuperar una DLL especificada en config.json, cargarla lateralmente y obtener la misma carga útil desde Dropbox. La DLL, denominada DWrite.dll y escrita en Rust, estaba diseñada para asegurar la instalación del cliente ScreenConnect incluso si los servidores primarios dejaban de estar disponibles.

Además, la extensión incluía URLs codificadas de forma estática que permitían descargar manualmente tanto el ejecutable como la DLL. Un segundo método alternativo utilizaba un script por lotes para obtener las cargas útiles desde otro dominio controlado por los atacantes (darkgptprivate[.]com).

Riesgos estructurales de seguridad en Moltbot

La revelación coincide con investigaciones adicionales sobre debilidades de seguridad en despliegues de Moltbot. El investigador Jamieson O'Reilly, fundador de Dvuln, descubrió cientos de instancias de Moltbot accesibles sin autenticación, exponiendo datos de configuración, claves API, credenciales OAuth e historiales completos de conversaciones privadas.

"El verdadero problema es que los agentes Clawdbot tienen agencia", explicó O'Reilly. Estos agentes pueden enviar mensajes en nombre de los usuarios, ejecutar herramientas y obedecer instrucciones, lo que abre la puerta a suplantación de identidad, manipulación de conversaciones y exfiltración silenciosa de datos sensibles.

Un atacante podría incluso distribuir una 'habilidad' maliciosa a través de MoltHub (antes ClawdHub), habilitando ataques a la cadena de suministro capaces de propagarse entre múltiples usuarios y entornos.

Problemas arquitectónicos y configuraciones inseguras

La empresa Intruder confirmó hallazgos similares, observando configuraciones erróneas generalizadas, exposición de credenciales, vulnerabilidades de prompt injection y entornos comprometidos en múltiples proveedores de nube.

"El problema central es arquitectónico", afirmó Benjamin Marr, ingeniero de seguridad en Intruder. Según explicó, Clawdbot prioriza la facilidad de despliegue por encima de una configuración segura por defecto, permitiendo que usuarios no técnicos integren servicios críticos sin validaciones, sandboxing de plugins ni controles de red obligatorios.

Recomendaciones de mitigación

Se recomienda a los usuarios que ejecutan Moltbot o Clawdbot con configuraciones predeterminadas:

  • Auditar exhaustivamente la configuración del sistema
  • Revocar todas las integraciones de servicios conectados
  • Rotar y proteger credenciales expuestas
  • Implementar controles de red y firewall estrictos
  • Supervisar indicadores de compromiso y accesos no autorizados

En fin...

Este incidente demuestra cómo la combinación de IA, herramientas para desarrolladores y marketplaces oficiales se ha convertido en un vector atractivo para campañas de malware avanzadas. La falsa extensión de Moltbot no solo representa un caso claro de supply chain attack, sino también una advertencia sobre la necesidad de verificación rigurosa, configuraciones seguras por defecto y controles adicionales en el ecosistema de desarrollo moderno.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#169

El Buró Federal de Investigación (FBI) ha tomado el control del infame foro de ciberdelincuencia RAMP, una plataforma ampliamente utilizada para la publicidad de servicios de malware, hacking y operaciones de ransomware. RAMP era considerado uno de los pocos foros que aún permitía abiertamente la promoción de campañas de ransomware, convirtiéndose en un punto neurálgico para bandas criminales y afiliados que operaban principalmente en el cibercrimen de habla rusa.

Tanto el sitio accesible a través de la red Tor como su dominio clearnet, ramp4u[.]io, muestran ahora un aviso oficial de incautación que indica de forma explícita: "El Buró Federal de Investigación ha incautado RAMP". El mensaje señala que la operación se llevó a cabo en coordinación con la Fiscalía de los Estados Unidos para el Distrito Sur de Florida y con la Sección de Delitos Informáticos y Propiedad Intelectual del Departamento de Justicia (DOJ).

Un mensaje con tono irónico para los operadores criminales

El banner de incautación no solo confirma la acción de las fuerzas del orden, sino que también se burla abiertamente de los operadores del foro. En él aparece el propio eslogan de RAMP, "¡EL ÚNICO LUGAR PERMITIDO POR RANSOMWARE!", acompañado de un guiño de ojo del popular personaje de la caricatura rusa infantil "Masha y el Oso". Este detalle sugiere una intención clara de enviar un mensaje psicológico a la comunidad criminal que utilizaba la plataforma.

Aunque hasta el momento no se ha publicado un comunicado oficial detallado, varios indicadores técnicos refuerzan la legitimidad de la incautación. Los servidores de nombres de dominio (DNS) del foro han sido modificados y ahora apuntan a la infraestructura utilizada habitualmente por el FBI en operaciones de este tipo, incluyendo:

  • You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
  • You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login

Riesgo extremo para los usuarios del foro

Si la incautación se confirma en su totalidad, las fuerzas del orden estadounidenses tendrían acceso a una cantidad masiva de datos sensibles vinculados a los usuarios de RAMP. Esto podría incluir direcciones de correo electrónico, direcciones IP, mensajes privados, registros de actividad y otra información potencialmente incriminatoria.

Para los actores amenazantes que no mantuvieron una seguridad operativa (OPSEC) estricta, esta situación representa un riesgo significativo de identificación, investigación y arrestos. Históricamente, este tipo de incautaciones ha dado lugar a operaciones encubiertas posteriores, análisis forense de comunicaciones y la identificación de redes criminales más amplias.

Origen y evolución del foro RAMP

El foro de ciberdelincuencia RAMP fue lanzado en julio de 2021, poco después de que los populares foros de hackeo de habla rusa Exploit y XSS prohibieran la promoción de operaciones de ransomware. Esta prohibición se produjo como consecuencia directa del aumento de la presión de las fuerzas del orden occidentales, especialmente tras el ataque de ransomware de DarkSide contra Colonial Pipeline, un incidente que afectó a infraestructura crítica de Estados Unidos.

Ante este nuevo escenario, surgió RAMP como uno de los últimos espacios donde el ransomware podía promocionarse sin restricciones. Esto atrajo rápidamente a bandas de ransomware, intermediarios de acceso inicial (IAB) y reclutadores de afiliados, que utilizaron el foro para comprar y vender accesos a redes comprometidas, negociar pagos y coordinar campañas.

El papel de "Orange" y los vínculos con Babuk

RAMP fue creado por un actor amenazante conocido como Orange, que también operaba bajo los alias Wazawaka y BorisElcin. Orange fue anteriormente el administrador de la operación de ransomware Babuk, que se disolvió tras su ataque al Departamento de Policía Metropolitana de Washington D.C.

Según informes, surgieron disputas internas dentro de Babuk sobre la publicación de datos robados a fuerzas del orden. Tras la filtración de esa información, el grupo se fragmentó, y Orange reutilizó la infraestructura de Tor de Babuk para lanzar RAMP en un dominio onion previamente empleado por la banda.

Ataques DDoS y decadencia del foro

Poco después de su lanzamiento, RAMP comenzó a sufrir ataques de denegación de servicio distribuida (DDoS) que afectaron seriamente su disponibilidad. Orange culpó públicamente a antiguos socios de Babuk, aunque estos negaron cualquier implicación, afirmando que no tenían interés en sabotear el foro.

Con el tiempo, la popularidad de RAMP disminuyó, en parte debido a estos ataques constantes y a la falta de rentabilidad, según reconoció posteriormente su creador.

Identificación de Mijaíl Matveev y acciones legales

El individuo detrás de los alias Orange y Wazawaka fue identificado públicamente por el periodista de ciberseguridad Brian Krebs como el ciudadano ruso Mijaíl Matveev. En una entrevista con Recorded Future, Matveev confirmó haber creado RAMP reutilizando el antiguo dominio onion de Babuk.

En 2023, Matveev fue acusado formalmente por el Departamento de Justicia de EE. UU. por su participación en múltiples operaciones de ransomware, incluyendo Babuk, LockBit y Hive, dirigidas contra organizaciones sanitarias, agencias gubernamentales e infraestructuras críticas. Además, fue sancionado por la OFAC, incluido en la lista de los más buscados del FBI, y el Departamento de Estado ofreció una recompensa de hasta 10 millones de dólares por información que condujera a su arresto o condena.

En fin...

La incautación del foro RAMP representa un golpe estratégico contra el ecosistema del ransomware y refuerza el mensaje de que incluso las plataformas consideradas "seguras" dentro del cibercrimen no están fuera del alcance de las fuerzas del orden. Para la comunidad de ciberseguridad, este evento subraya la importancia de la cooperación internacional, el seguimiento de infraestructuras criminales y la presión constante sobre los mercados que facilitan ataques a gran escala.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#170

Dos vulnerabilidades de alta gravedad descubiertas recientemente en la plataforma de automatización de flujos de trabajo n8n podrían permitir a atacantes comprometer completamente las instancias afectadas, acceder a datos sensibles, ejecutar código arbitrario y, en última instancia, obtener control total del host subyacente. Los fallos, identificados como CVE-2026-1470 y CVE-2026-0863, fueron descubiertos y reportados por investigadores de la empresa de DevSecOps JFrog, y vuelven a poner en el foco los riesgos de seguridad asociados a entornos de automatización autoalojados.

¿Qué es n8n y por qué es un objetivo atractivo?

n8n es una plataforma de automatización de flujos de trabajo de código abierto que permite a los usuarios conectar aplicaciones, APIs y servicios para crear procesos complejos mediante un editor visual. Gracias a su flexibilidad y a su capacidad para integrarse con servicios de inteligencia artificial y modelos de lenguaje grandes (LLM), n8n se ha convertido en una herramienta ampliamente adoptada tanto por desarrolladores como por equipos DevOps.

Con más de 200.000 descargas semanales en npm, n8n se utiliza en tareas críticas como la automatización de procesos empresariales, el manejo de credenciales, la integración de servicios cloud y la orquestación de flujos de datos sensibles. Precisamente esta popularidad convierte a la plataforma en un objetivo atractivo para actores maliciosos.

CVE-2026-1470: ejecución arbitraria de JavaScript y RCE completo

La vulnerabilidad más grave de las dos es CVE-2026-1470, que recibió una puntuación crítica de 9,9 sobre 10. Aunque su explotación requiere autenticación, JFrog explicó que la severidad se debe a que permite la ejecución arbitraria de código en el nodo principal de n8n, lo que equivale a un RCE completo.

El fallo se origina en un escape del sandbox basado en AST (Abstract Syntax Tree) causado por un manejo incorrecto de la instrucción with en JavaScript. En concreto, un identificador constructor independiente puede evadir los mecanismos de sanitización y resolverse como Function, permitiendo la ejecución de código JavaScript arbitrario fuera del entorno restringido.

Esto implica que un usuario con permisos limitados para crear o modificar flujos de trabajo puede romper el aislamiento del sandbox, ejecutar comandos en el sistema anfitrión y pivotar hacia un control a nivel de infraestructura, algo especialmente crítico en despliegues empresariales.

CVE-2026-0863: escape del sandbox en Python y ejecución de comandos del sistema

La segunda vulnerabilidad, CVE-2026-0863, afecta al entorno Python utilizado por n8n cuando se ejecuta como subproceso en el nodo principal. El fallo combina técnicas de introspección de objetos mediante cadenas de formato con el comportamiento de AttributeError.obj en Python 3.10 y versiones posteriores.

Esta combinación permite recuperar acceso a funciones integradas e importaciones restringidas, lo que facilita la ejecución de comandos del sistema operativo y desemboca igualmente en un RCE completo. La investigadora Rhoda Smart explicó en detalle este comportamiento en una entrada técnica de blog y anunció la publicación de un exploit de prueba de concepto (PoC), lo que podría acelerar la explotación activa de instancias vulnerables.

Un problema estructural: el sandboxing en lenguajes dinámicos

Según JFrog, estas vulnerabilidades ponen de manifiesto lo difícil que resulta implementar sandboxing seguro en lenguajes dinámicos y de alto nivel como JavaScript y Python. Incluso cuando se emplean múltiples capas de validación, listas de denegación y controles basados en AST, existen comportamientos sutiles del lenguaje y del tiempo de ejecución que pueden ser explotados para eludir las suposiciones de seguridad.

Este tipo de fallos no solo afectan a n8n, sino que representan un desafío más amplio para plataformas que permiten la ejecución de código definido por el usuario en entornos supuestamente aislados.

Versiones afectadas y parches disponibles

Los desarrolladores de n8n ya han corregido ambas vulnerabilidades.

  • CVE-2026-1470 fue solucionada en las versiones 1.123.17, 2.4.5 y 2.5.1.
  • CVE-2026-0863 se corrigió en 1.123.14, 2.3.5 y 2.4.2.

Se recomienda a los usuarios actualizar inmediatamente a las versiones más recientes. Es importante destacar que la plataforma n8n Cloud ya ha mitigado estos problemas, y que solo las versiones autoalojadas que ejecutan versiones vulnerables se ven afectadas.

Contexto preocupante: fallos previos y baja tasa de parcheo

Estas vulnerabilidades llegan en un momento especialmente delicado para n8n. A principios de este mes se reveló "Ni8mare", una falla de máxima gravedad que permitía a atacantes remotos y no autenticados tomar el control de instancias locales de n8n. Una semana después de su divulgación, los escaneos mostraron que 60.000 instancias seguían expuestas.

Aunque a fecha del 27 de enero esta cifra se redujo a 39.900 instancias vulnerables, los datos reflejan una tasa de parcheo extremadamente lenta, lo que incrementa el riesgo de campañas de explotación masiva.

En fin...

Las vulnerabilidades CVE-2026-1470 y CVE-2026-0863 confirman que las plataformas de automatización como n8n, especialmente en entornos autoalojados, deben ser tratadas como infraestructura crítica. La combinación de ejecución de código, acceso a integraciones sensibles y baja tasa de actualización convierte estos fallos en una amenaza real y activa.

Actualizar de inmediato, revisar permisos de usuarios y aplicar principios de mínimo privilegio son pasos esenciales para reducir la superficie de ataque y evitar compromisos de alto impacto.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#171

Investigadores en ciberseguridad han revelado los detalles de una nueva familia de ransomware denominada Osiris, responsable de un ataque altamente sofisticado contra un importante operador de franquicias de servicios de restauración en el sudeste asiático en noviembre de 2025. El incidente destaca por el uso de técnicas avanzadas de evasión, incluyendo Bring Your Own Vulnerable Driver (BYOVD) y un controlador malicioso personalizado llamado POORTRY, diseñado específicamente para desactivar soluciones de seguridad.

El análisis técnico fue realizado por los equipos de Symantec y Carbon Black Threat Hunter, ambos pertenecientes a la división de ciberseguridad de Broadcom, quienes describieron a Osiris como una carga útil de cifrado eficaz, operada probablemente por actores experimentados con conocimientos profundos de sistemas Windows y entornos corporativos.

Osiris no guarda relación con el ransomware homónimo de 2016

A pesar de compartir nombre, Osiris no está relacionado con la variante de ransomware que apareció en diciembre de 2016 como una iteración del ransomware Locky. Los investigadores subrayan que se trata de una cepa completamente nueva, sin código reutilizado ni infraestructura conocida.

Actualmente, no se conoce la identidad de los desarrolladores, ni está claro si Osiris se ofrece como Ransomware como Servicio (RaaS). Sin embargo, Broadcom indicó haber identificado indicios técnicos y operativos que sugieren una posible relación con los actores detrás del ransomware INC, también conocido como Warble.

Citar"La exfiltración de datos a buckets de Wasabi y el uso de una versión de Mimikatz con el mismo nombre de archivo previamente observado en ataques de INC apuntan a posibles vínculos entre ambas operaciones", señalaron los investigadores.

El papel clave de POORTRY y el uso avanzado de BYOVD

Uno de los aspectos más relevantes del ataque es el uso del controlador POORTRY, que se aparta del enfoque tradicional de BYOVD. En lugar de aprovechar un driver legítimo pero vulnerable, POORTRY es un controlador personalizado, creado expresamente para elevar privilegios y terminar procesos de seguridad.

Este enfoque demuestra una madurez técnica superior, ya que reduce la dependencia de vulnerabilidades públicas y complica la detección basada en firmas. Además, durante la intrusión también se desplegó la herramienta KillAV, utilizada para cargar controladores vulnerables con el objetivo de neutralizar software de protección.

Cadena de ataque: exfiltración antes del cifrado

Los primeros indicios de compromiso en la red objetivo revelan que los atacantes priorizaron la exfiltración de datos sensibles antes del cifrado, siguiendo el modelo de doble extorsión. Para ello, utilizaron Rclone para transferir información a un bucket de almacenamiento en la nube de Wasabi.

Durante la fase de reconocimiento y movimiento lateral, se emplearon diversas herramientas de vida en la tierra (LOLBins) y utilidades de doble uso, entre ellas:

  • Netscan y Netexec para descubrimiento de red
  • MeshAgent para acceso remoto persistente
  • Una versión personalizada del software de escritorio remoto RustDesk
  • Acceso remoto mediante RDP, que estaba habilitado en la red comprometida

Este conjunto de herramientas permitió a los atacantes operar durante largos periodos sin levantar alertas inmediatas.

Capacidades técnicas del ransomware Osiris

Descrito como una carga de cifrado flexible y eficiente, Osiris emplea un esquema híbrido de cifrado, generando una clave única por archivo, lo que dificulta la recuperación sin la clave privada de los atacantes.

El ransomware ofrece múltiples opciones configurables, entre ellas:

  • Detener servicios y procesos críticos
  • Definir carpetas y extensiones específicas a cifrar
  • Finalizar procesos activos
  • Generar y desplegar notas de rescate personalizadas

Por defecto, Osiris está programado para eliminar una amplia lista de procesos y servicios asociados a aplicaciones empresariales, incluyendo Microsoft Office, Microsoft Exchange, Mozilla Firefox, WordPad, Notepad, Volume Shadow Copy, Veeam, entre otros, maximizando el impacto operativo del ataque.

El ransomware sigue evolucionando

Este incidente se produce en un contexto donde el ransomware continúa siendo una de las mayores amenazas para las organizaciones. Según un análisis de sitios de filtración de datos realizado por Symantec y Carbon Black, los actores de ransomware reclamaron 4.737 ataques durante 2025, frente a 4.701 en 2024, lo que representa un incremento del 0,8 %.

Los grupos más activos durante el último año incluyeron Akira, Qilin, Play, INC, SafePay, RansomHub, DragonForce, Sinobi, Rhysida y CACTUS, con campañas cada vez más sofisticadas y adaptativas.

Tendencias clave observadas en 2025

Entre los desarrollos más relevantes del panorama de ransomware destacan:

  • Akira explotando controladores vulnerables y VPN SSL de SonicWall, además de utilizar señuelos CAPTCHA tipo ClickFix para desplegar SectopRAT.
  • LockBit 5.0 introduciendo un modelo de despliegue en dos etapas, separando el cargador de la carga útil principal para mejorar evasión y modularidad.
  • La aparición de Sicarii, un nuevo RaaS con posibles indicios de operación de falsa bandera.
  • Storm-2603 abusando de herramientas DFIR legítimas como Velociraptor y múltiples controladores para ataques BYOVD.
  • Makop utilizando RDP expuesto, BYOVD y el cargador GuLoader para distribuir ransomware.
  • La identificación de un fallo de diseño en Obscura que provoca la pérdida permanente de archivos grandes cifrados.
  • La emergencia de 01flip, un ransomware escrito en Rust que ataca Windows y Linux en la región Asia-Pacífico.

Recomendaciones defensivas

Para reducir el riesgo frente a ataques dirigidos como Osiris, los expertos recomiendan:

  • Monitorizar el uso de herramientas de doble uso
  • Restringir y proteger el acceso RDP
  • Aplicar autenticación multifactor (MFA)
  • Implementar listas blancas de aplicaciones
  • Mantener copias de seguridad offline y fuera del sitio

Citar"El ransomware ya no es solo cifrado. Se está convirtiendo en parte de un ecosistema de extorsión más amplio", concluyeron Symantec y Carbon Black.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#172

Una nueva vulnerabilidad de seguridad en el software de correo SmarterMail ha sido detectada bajo explotación activa en la naturaleza apenas dos días después de la publicación del parche oficial, lo que vuelve a poner en evidencia la rapidez con la que los atacantes analizan, reconstruyen y operacionalizan fallos de seguridad a partir de actualizaciones recientes.

El fallo, inicialmente sin identificador CVE y rastreado por watchTowr Labs como WT-2026-0001, fue corregido por SmarterTools el 15 de enero de 2026 con el lanzamiento de SmarterMail Build 9511, tras una divulgación responsable realizada el 8 de enero de 2026. Posteriormente, a la vulnerabilidad se le asignó el identificador CVE-2026-23760, con una puntuación CVSS de 9,3, lo que confirma su criticidad elevada.

Un bypass de autenticación con impacto total

La vulnerabilidad fue descrita como un fallo de evasión de autenticación que permite a cualquier usuario remoto, sin necesidad de credenciales válidas, restablecer la contraseña de una cuenta administradora del sistema SmarterMail mediante una solicitud HTTP especialmente diseñada al endpoint:

Código: text
/api/v1/auth/force-reset-password


Según los investigadores de watchTowr Labs, Piotr Bazydlo y Sina Kheirkhah, este fallo no solo concede acceso administrativo completo, sino que abre la puerta directa a la ejecución remota de código (RCE) mediante funcionalidades legítimas integradas en la plataforma.

Citar"Lo más interesante es que dicho usuario puede usar funciones de RCE incorporadas para ejecutar directamente comandos del sistema operativo", explicaron los investigadores.

Análisis técnico del fallo

El origen del problema se encuentra en la función interna SmarterMail.Web.Api.AuthenticationController.ForceResetPassword, que presenta dos fallos críticos de diseño:

  • Permite acceder al endpoint sin ningún tipo de autenticación previa.
  • Confía ciegamente en una bandera booleana controlada por el usuario, denominada IsSysAdmin, para determinar si la solicitud debe tratarse como una acción privilegiada.

Cuando el atacante establece esta bandera como verdadera, la lógica del backend ejecuta automáticamente una secuencia de acciones de alto riesgo:

  • Recupera la configuración del usuario especificado en la solicitud HTTP.
  • Crea o modifica un objeto de administrador del sistema con una nueva contraseña.
  • Actualiza la cuenta de administrador existente con la contraseña proporcionada por el atacante.

En la práctica, cualquier atacante que conozca o pueda adivinar el nombre de usuario de un administrador puede tomar control total del sistema SmarterMail enviando una sola petición HTTP.

De acceso administrativo a ejecución remota de código

El impacto no se limita al control de la interfaz de administración. Una vez autenticado como administrador del sistema, el atacante obtiene acceso a una funcionalidad incorporada que permite ejecutar comandos del sistema operativo subyacente.

Esto puede lograrse navegando a la sección de Configuración, creando un nuevo volumen y suministrando un comando arbitrario en el campo "Comando de Montaje de Volumen", el cual es ejecutado directamente por el sistema operativo del host. De esta forma, el atacante puede obtener un shell con privilegios de SISTEMA, comprometiendo por completo el servidor de correo.

Explotación tras el parche: ingeniería inversa en tiempo récord

watchTowr Labs decidió hacer público el hallazgo tras la aparición de una publicación en el Portal de la Comunidad SmarterTools, donde un usuario afirmó haber perdido el acceso a su cuenta de administrador. Los registros mostraban el uso del endpoint vulnerable para cambiar la contraseña el 17 de enero de 2026, apenas dos días después del lanzamiento del parche.

Este incidente sugiere con alta probabilidad que los atacantes realizaron ingeniería inversa del parche, identificaron el fallo corregido y reconstruyeron el exploit en un periodo de tiempo extremadamente corto.

La situación se vio agravada por el hecho de que las notas de lanzamiento de SmarterMail fueron deliberadamente vagas. En el caso de la Build 9511, una simple línea indicaba: "IMPORTANTE: Correcciones críticas de seguridad", sin detallar la naturaleza del problema.

Debate sobre transparencia y comunicación

En respuesta a las críticas, el CEO de SmarterTools, Tim Uzzanti, defendió esta práctica como una medida para no proporcionar pistas adicionales a actores maliciosos, aunque reconoció la necesidad de mejorar la comunicación.

Uzzanti afirmó que la empresa planea enviar correos electrónicos a los administradores cada vez que se descubra un nuevo CVE y nuevamente cuando se publique una versión que lo corrija. No obstante, no está claro si esta notificación se envió en este caso concreto.

Un patrón preocupante: vulnerabilidades críticas recurrentes

Este incidente se produce menos de un mes después de que la Agencia de Ciberseguridad de Singapur (CSA) revelara una vulnerabilidad de máxima gravedad en SmarterMail, identificada como CVE-2025-52691 (CVSS 10.0), que también permite ejecución remota de código y que, según Huntress, ha sido explotada de forma masiva.

Huntress informó que CVE-2025-52691 se está utilizando para desplegar webshells de baja sofisticación y cargadores de malware escritos en directorios de inicio, logrando persistencia y ejecución tras reinicios del sistema.

Respecto a CVE-2026-23760, Huntress confirmó explotación activa en la naturaleza, con intentos de toma de control de cuentas privilegiadas que podrían derivar en RCE. Todas las IPs observadas estaban asociadas a infraestructura virtual en Estados Unidos, aunque sin atribución clara a un actor de amenazas específico.

Recomendaciones urgentes

Dada la gravedad del fallo, la explotación activa confirmada y el historial reciente de vulnerabilidades críticas en SmarterMail, los expertos recomiendan:

  • Actualizar inmediatamente a la última versión de SmarterMail
  • Auditar sistemas en busca de signos de compromiso
  • Revisar cuentas administrativas y rotar credenciales
  • Monitorizar logs HTTP y accesos sospechosos al endpoint de autenticación
  • Eliminar o aislar sistemas obsoletos expuestos a Internet

Este caso refuerza una realidad incuestionable en ciberseguridad moderna: el tiempo entre parche y explotación es cada vez más corto, y retrasar una actualización crítica puede traducirse en una comprometida total del sistema.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#173

Investigadores de seguridad han identificado una campaña coordinada de explotación activa dirigida contra una vulnerabilidad de gravedad crítica recientemente revelada en el servidor telnetd de GNU InetUtils, un fallo que ha permanecido oculto en el código durante más de 11 años. El problema de seguridad, registrado como CVE-2026-24061, permite a un atacante remoto evadir completamente la autenticación y obtener acceso root en sistemas vulnerables.

La vulnerabilidad fue reportada públicamente el 20 de enero de 2026 y, según los expertos, resulta trivial de explotar, con múltiples pruebas de concepto y exploits funcionales disponibles de forma pública. Aunque Telnet es un servicio heredado y considerado inseguro, su persistencia en sistemas antiguos, dispositivos embebidos y entornos industriales ha convertido este fallo en una amenaza real.

Un fallo crítico oculto desde 2015

El investigador y colaborador de código abierto Simon Josefsson explicó que el componente telnetd de GNU InetUtils contiene una vulnerabilidad de evasión de autenticación remota provocada por un manejo incorrecto de variables de entorno al invocar el binario /usr/bin/login.

El problema se origina porque telnetd pasa la variable de entorno USER, controlada completamente por el usuario remoto, directamente a login(1) sin ningún tipo de sanitización o validación. Esta omisión permite a un atacante manipular el proceso de autenticación de forma directa.

Al establecer la variable de entorno como USER=-f root y conectarse utilizando el comando telnet -a, el atacante puede forzar el acceso como usuario root sin proporcionar credenciales, saltándose por completo los mecanismos de autenticación tradicionales del sistema.

Versiones afectadas y parche disponible

El fallo afecta a todas las versiones de GNU InetUtils desde la 1.9.3, lanzada en 2015, hasta la versión 2.7. El problema fue finalmente corregido en GNU InetUtils 2.8, que introduce la sanitización adecuada de las variables de entorno antes de llamar al proceso de login.

Para los administradores de sistemas que no pueden actualizar inmediatamente, las recomendaciones de mitigación incluyen:

  • Desactivar completamente el servicio telnetd
  • Bloquear el puerto TCP 23 en todos los cortafuegos perimetrales y locales
  • Limitar el acceso mediante listas de control estrictas
  • Auditar sistemas heredados y dispositivos embebidos

GNU InetUtils y la persistencia de Telnet

GNU InetUtils es un conjunto histórico de herramientas cliente y servidor de red mantenido por el Proyecto GNU, que incluye utilidades como telnet, telnetd, ftp, ftpd, rsh, ping y traceroute. Estas herramientas siguen presentes en numerosas distribuciones Linux y Unix por motivos de compatibilidad.

Aunque Telnet ha sido reemplazado en gran medida por SSH debido a su falta de cifrado y autenticación segura, todavía se utiliza en entornos especializados, especialmente en el sector industrial y en redes de Tecnología Operativa (OT), donde prima la simplicidad, el bajo consumo de recursos y la compatibilidad con hardware antiguo.

En muchos dispositivos heredados e integrados, el software puede permanecer sin actualizaciones durante más de una década, lo que explica la presencia continua de telnetd en dispositivos IoT, cámaras IP, sensores industriales y controladores industriales.

Un usuario técnico confirmó públicamente que sigue utilizando Telnet "para conectarse a dispositivos Cisco antiguos que ya han alcanzado el final de su vida útil, donde incluso SSH deja de ser viable".

¿Por qué se consideró inicialmente menos crítica?

A pesar de su impacto técnico, algunos investigadores calificaron inicialmente CVE-2026-24061 como una vulnerabilidad de menor riesgo debido a que son relativamente pocos los sistemas expuestos a Telnet en Internet público. Sin embargo, esta percepción ha cambiado tras la confirmación de explotación real en entornos activos.

Explotación detectada en la naturaleza

La empresa de monitorización de amenazas GreyNoise confirmó haber detectado actividad maliciosa real explotando CVE-2026-24061 contra un número reducido de objetivos vulnerables.

Según su informe, la actividad fue observada entre el 21 y el 22 de enero, originándose desde 18 direcciones IP únicas en 60 sesiones Telnet, todas ellas clasificadas como 100 % maliciosas. Durante los ataques se enviaron 1.525 paquetes, con un volumen total de 101,6 KB de datos.

Los atacantes abusaron de la negociación de opciones IAC (Interpret As Command) de Telnet para inyectar valores como USER=-f <usuario>, lo que permitió obtener acceso a la shell sin autenticación. En el 83,3 % de los casos, el objetivo era directamente el usuario root.

GreyNoise indicó que la mayoría de la actividad parecía automatizada, aunque se identificaron algunos casos de "humano en teclado", evidenciados por variaciones en la velocidad del terminal, tipos de sesión y valores de la variable DISPLAY de X11.

Post-explotación y riesgos futuros

Tras lograr el acceso inicial, los atacantes llevaron a cabo reconocimiento automatizado, intentaron persistir claves SSH y desplegar malware en Python. En los sistemas monitorizados, estos intentos no tuvieron éxito debido a la ausencia de binarios o directorios necesarios.

No obstante, los expertos advierten que, aunque la campaña actual es limitada en alcance, los atacantes podrían optimizar rápidamente sus cadenas de explotación, especialmente si identifican entornos industriales o dispositivos embebidos con configuraciones estándar.

En fin...

Todos los sistemas potencialmente afectados por CVE-2026-24061 deben ser parcheados de inmediato o protegidos mediante controles compensatorios. La combinación de servicios heredados, software sin actualizar y exploits públicos convierte esta vulnerabilidad en un riesgo latente, especialmente en infraestructuras críticas.

Este incidente refuerza una lección clave en ciberseguridad: el software heredado no desaparece, y las vulnerabilidades latentes pueden convertirse en amenazas reales incluso más de una década después.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#174

El proyecto curl, una de las utilidades de línea de comandos más utilizadas en el mundo para la transferencia de datos a través de múltiples protocolos, ha anunciado una decisión drástica pero reveladora del estado actual de la seguridad informática: el fin de su programa de recompensas por errores (bug bounty) en HackerOne. La medida llega tras verse completamente desbordado por una avalancha de informes de vulnerabilidades de baja calidad, muchos de ellos aparentemente generados por inteligencia artificial.

La decisión fue detectada inicialmente en una documentación pendiente de commit dentro del repositorio oficial del proyecto, concretamente en el archivo You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login, donde se eliminaron todas las referencias al programa de recompensas gestionado a través de HackerOne. Una vez fusionado el cambio, el documento indicará explícitamente que curl ya no ofrece recompensas económicas por errores de seguridad, ni tampoco asistirá a investigadores que intenten obtener compensación de terceros.

Citar"Hasta finales de enero de 2026 había una recompensa por los bugs de curl. Ya no existe", señala el texto actualizado. "El proyecto curl ya no ofrece ninguna recompensa por errores o vulnerabilidades reportadas, ni ayuda a los investigadores de seguridad a obtener compensaciones de otras fuentes".

Qué es curl y por qué es crítico para Internet

Curl es una herramienta de línea de comandos esencial para la comunicación con servicios web, utilizada para transferir datos mediante protocolos como HTTP, HTTPS, FTP, SFTP y muchos otros. Su biblioteca asociada, libcurl, está integrada en miles de aplicaciones, sistemas embebidos, plataformas cloud, dispositivos IoT y software empresarial.

Debido a su amplia adopción, cualquier vulnerabilidad en curl o libcurl puede tener un impacto masivo, lo que explica por qué el proyecto lanzó en 2019 un programa de recompensas por errores, gestionado a través de HackerOne e Internet Bug Bounty, incentivando la divulgación responsable de fallos de seguridad.

El problema: informes basura y vulnerabilidades inexistentes

Según Daniel Stenberg, fundador y desarrollador principal de curl, el programa comenzó a experimentar un crecimiento descontrolado de reportes de bajo esfuerzo, inválidos o directamente inútiles, muchos de los cuales parecen haber sido generados por herramientas de IA.

CitarEste fenómeno, al que el propio Stenberg se refiere como "basura de IA", describe una creciente cantidad de contenido que "suena bien", utiliza terminología técnica y formatos correctos, pero carece de análisis real, pruebas funcionales o impacto de seguridad verificable.

En una publicación reciente en su lista de correo personal, Stenberg detalló el nivel de saturación alcanzado por el equipo de seguridad:

Citar"Empezamos la semana recibiendo siete informes de HackerOne en un periodo de dieciséis horas. Algunos parecían bugs reales, lo que me llevó bastante tiempo investigarlos. Finalmente concluimos que ninguno identificaba una vulnerabilidad real".

A comienzos de 2026, el proyecto ya había recibido 20 envíos solo en el primer mes del año, una carga insostenible para un proyecto pequeño, mantenido por un número limitado de desarrolladores activos.

El cierre del bug bounty como medida de supervivencia

Stenberg fue claro al explicar que el objetivo principal de cerrar el programa de recompensas es eliminar el incentivo económico que impulsa el envío masivo de informes poco investigados, independientemente de si son generados por humanos o por IA.

Citar"La avalancha actual de envíos ha puesto una carga enorme sobre el equipo de seguridad de curl. Esto es un intento de reducir el ruido y proteger la salud mental de los mantenedores".

Aunque reconoce que abandonar HackerOne no garantiza que los informes basura desaparezcan, considera que la medida es necesaria para asegurar la sostenibilidad del proyecto a largo plazo.

Un problema creciente en la seguridad open source

Stenberg también compartió datos que muestran un aumento desproporcionado de reportes en curl en comparación con otros proyectos open source alojados en HackerOne, lo que sugiere que los programas de recompensas más visibles y antiguos están siendo objetivo preferente de envíos automatizados.

Citar"Parece que tenemos datos que confirman que la recompensa por errores de curl ha recibido un aumento considerable en la tasa de envíos hasta 2025, mientras que otros proyectos similares no lo han hecho", publicó en Mastodon.

Este escenario plantea un debate más amplio sobre el impacto de la IA generativa en los programas de bug bounty, donde la cantidad de informes puede aumentar exponencialmente, pero la calidad y el valor real disminuyen.

Nuevo proceso de reporte de vulnerabilidades en curl

El abandono de HackerOne no será inmediato, sino que se realizará de forma escalonada:

  • Hasta el 31 de enero de 2026, curl seguirá aceptando informes enviados a través de HackerOne.
  • Los reportes en curso continuarán siendo evaluados.
  • A partir del 1 de febrero de 2026, el proyecto dejará de aceptar nuevas propuestas en HackerOne.
  • Los investigadores deberán reportar vulnerabilidades directamente a través de GitHub, siguiendo los canales oficiales del proyecto.

Este cambio también se refleja en una reciente actualización del archivo security.txt, donde curl deja claro que no ofrece compensación económica y advierte que los envíos considerados "basura" pueden resultar en bloqueos e incluso ridiculización pública.

Un precedente para la industria

Daniel Stenberg ha adelantado que publicará una entrada detallada en su blog con más información sobre esta transición. Mientras tanto, la decisión de curl sienta un precedente importante: los programas de recompensas por errores no son inmunes a los efectos negativos de la automatización y la IA mal utilizada.

Para la comunidad de seguridad, este caso pone sobre la mesa la necesidad de replantear los modelos de bug bounty, mejorar los filtros de calidad y reforzar la colaboración responsable, especialmente en proyectos open source críticos que sostienen gran parte de la infraestructura de Internet.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#175

Los actores maliciosos están explotando activamente aplicaciones web intencionadamente vulnerables, utilizadas habitualmente para entrenamiento en ciberseguridad y pruebas internas de penetración, con el fin de comprometer entornos en la nube de grandes empresas y proveedores de seguridad. Entre las aplicaciones abusadas se encuentran Damn Vulnerable Web Application (DVWA), OWASP Juice Shop, Hackazon y bWAPP, todas ellas ampliamente utilizadas en laboratorios de seguridad.

Una investigación reciente de la empresa de pruebas de penetración automatizadas Pentera confirma que este vector de ataque ya está siendo utilizado en escenarios reales, permitiendo a los atacantes acceder a infraestructuras cloud corporativas, desplegar mineros de criptomonedas, instalar webshells persistentes y pivotar hacia sistemas críticos dentro de la red.

Aplicaciones de prueba: un riesgo crítico cuando se exponen a Internet

Las aplicaciones web de entrenamiento están diseñadas deliberadamente con vulnerabilidades conocidas para facilitar el aprendizaje práctico. Sin embargo, cuando estas aplicaciones se exponen accidentalmente a Internet y se ejecutan desde cuentas cloud con privilegios elevados, se convierten en un punto de entrada extremadamente peligroso.

Pentera identificó 1.926 aplicaciones vulnerables activas accesibles desde la web pública, desplegadas en entornos cloud de Amazon Web Services (AWS), Google Cloud Platform (GCP) y Microsoft Azure. En muchos casos, estas aplicaciones estaban asociadas a roles de Gestión de Identidad y Acceso (IAM) excesivamente privilegiados, incumpliendo de forma crítica el principio de menor privilegio.

Empresas Fortune 500 afectadas

Según el informe, las aplicaciones expuestas pertenecían a múltiples organizaciones de gran tamaño, incluidas empresas Fortune 500 y proveedores líderes de seguridad, como Cloudflare, F5 y Palo Alto Networks. Pentera aclaró que estas compañías fueron notificadas de forma responsable, y que los problemas ya han sido corregidos tras la divulgación.

En muchos de los casos analizados, las aplicaciones:

  • Exponían credenciales cloud en texto claro
  • Utilizaban credenciales predeterminadas
  • No aplicaban políticas de menor privilegio
  • Permitían acceso directo a recursos críticos de la nube

Estas malas prácticas facilitaron enormemente la toma de control de los entornos afectados.

Acceso total a servicios cloud críticos

Las credenciales descubiertas durante la investigación podrían haber permitido a los atacantes:

  • Acceder completamente a buckets S3, Google Cloud Storage y Azure Blob Storage
  • Leer y escribir secretos en AWS Secrets Manager y servicios equivalentes
  • Interactuar con registros de contenedores
  • Obtener privilegios administrativos en entornos cloud completos

Este nivel de acceso convierte una simple aplicación de laboratorio en un punto de compromiso total de la infraestructura.

Explotación activa confirmada en la naturaleza

Pentera Labs confirmó a BleepingComputer que el riesgo no es teórico. Durante la investigación, los analistas detectaron evidencias claras de explotación activa por parte de actores maliciosos.

Citar"Descubrimos pruebas claras de que los atacantes están explotando activamente estos vectores de ataque, desplegando mineros criptográficos, webshells y mecanismos de persistencia en sistemas comprometidos", señalaron los investigadores.

Al analizar instancias vulnerables, los investigadores desplegaron shells de prueba y enumeraron datos para identificar a los propietarios de los sistemas comprometidos.

Uno de los hallazgos más preocupantes fue que, de las 616 instancias de DVWA descubiertas, aproximadamente el 20 % ya contenía artefactos maliciosos instalados por atacantes reales.

Cryptojacking con XMRig y Monero

La actividad maliciosa más común detectada fue la minería de criptomonedas, utilizando la herramienta XMRig para minar Monero (XMR) de forma encubierta en segundo plano. Este tipo de ataque, conocido como cryptojacking, permite a los atacantes monetizar el acceso no autorizado mientras consumen recursos cloud de alto coste.

Los investigadores también descubrieron un mecanismo avanzado de persistencia basado en un script denominado You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login. Si el script es eliminado, se restaura automáticamente desde una copia de seguridad codificada en Base64, vuelve a descargar XMRig desde GitHub y reanuda la actividad maliciosa.

Además, el script:

  • Descarga herramientas adicionales desde Dropbox
  • Utiliza cifrado AES-256
  • Elimina mineros competidores del sistema comprometido

Webshells y pistas sobre el origen de los atacantes

En otros casos, los atacantes desplegaron un webshell PHP denominado filemanager.php, capaz de realizar acciones avanzadas como:

  • Lectura, escritura y eliminación de archivos
  • Subida y descarga de ficheros
  • Ejecución de comandos del sistema

El webshell incluía credenciales de autenticación codificadas y estaba configurado con una zona horaria Europa/Minsk (UTC+3), un detalle que podría ofrecer pistas sobre el origen geográfico de los operadores, aunque no constituye una atribución definitiva.

Pentera subrayó que estos artefactos fueron descubiertos tras notificar previamente a las empresas afectadas, y que los sistemas ya han sido asegurados.

Recomendaciones de seguridad para entornos cloud

Pentera recomienda a las organizaciones adoptar medidas inmediatas para reducir este riesgo:

  • Mantener un inventario completo de todos los recursos cloud, incluidas aplicaciones de prueba
  • Aislar entornos no productivos de los sistemas de producción
  • Aplicar estrictamente roles IAM de menor privilegio
  • Cambiar y rotar credenciales predeterminadas
  • Configurar caducidad automática para recursos temporales
  • Monitorizar activamente la exposición de servicios a Internet

El informe también ofrece un desglose técnico detallado de las técnicas utilizadas para descubrir aplicaciones vulnerables, identificar propietarios y analizar la explotación activa.

En fin...

La explotación de aplicaciones web de pruebas mal configuradas demuestra cómo errores básicos de configuración pueden derivar en compromisos graves de seguridad cloud, incluso en organizaciones de primer nivel. En un contexto donde los atacantes buscan continuamente nuevos puntos de entrada, la gestión rigurosa de activos y privilegios sigue siendo una de las defensas más efectivas.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#176

Los clientes de Fortinet están enfrentando una situación crítica de seguridad tras detectarse que atacantes están explotando activamente una vulnerabilidad de evasión de autenticación en FortiGate, incluso en dispositivos que ya han sido parcheados. El problema está vinculado a la vulnerabilidad CVE-2025-59718, una falla crítica en el mecanismo de inicio de sesión único (SSO) de FortiCloud, que supuestamente había sido corregida con las versiones más recientes de FortiOS.

Sin embargo, múltiples informes indican que los parches lanzados por Fortinet no solucionaron completamente el problema, lo que ha permitido a los atacantes comprometer cortafuegos FortiGate completamente actualizados, creando cuentas de administrador de forma no autorizada y obteniendo control total del dispositivo.

CVE-2025-59718: una vulnerabilidad que sigue activa

La vulnerabilidad CVE-2025-59718 fue corregida inicialmente a principios de diciembre con el lanzamiento de FortiOS 7.4.9, una actualización destinada a cerrar un fallo de evasión de autenticación en FortiCloud SSO. Posteriormente, Fortinet lanzó FortiOS 7.4.10, que debía reforzar la mitigación del problema.

No obstante, administradores de sistemas afectados aseguran que la vulnerabilidad persiste incluso en FortiOS 7.4.10, algo que, según ellos, habría sido confirmado por el propio equipo de desarrollo de Fortinet. Como respuesta, la compañía planea lanzar nuevas versiones —FortiOS 7.4.11, 7.6.6 y 8.0.0— con el objetivo de corregir definitivamente la falla de seguridad.

Evidencias de explotación en entornos parcheados

Uno de los administradores afectados describió un incidente en el que un inicio de sesión malicioso a través de SSO derivó en la creación de una cuenta de administrador local en un FortiGate FGT60F que ejecutaba FortiOS 7.4.9 desde finales de diciembre.

Citar"Tuvimos un inicio de sesión SSO malicioso en uno de nuestros FortiGate con la versión 7.4.9. Nuestro SIEM detectó la creación de una cuenta de administrador local. Tras investigar, todo coincidía con la explotación de CVE-2025-59718, aunque el sistema estaba parcheado desde el 30 de diciembre", explicó el administrador.

Los registros compartidos mostraban que el usuario administrador fue creado tras un inicio de sesión SSO procedente de la cuenta You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
 desde la dirección IP 104.28.244.114. Esta actividad coincide de forma notable con los indicadores de compromiso previamente documentados por la empresa de ciberseguridad Arctic Wolf en diciembre de 2025.

Ataques mediante mensajes SAML maliciosos

Según Arctic Wolf, los atacantes estaban explotando la vulnerabilidad mediante el envío de mensajes SAML maliciosos, lo que les permitía eludir los controles de autenticación y tomar control de cuentas de administrador en dispositivos FortiGate expuestos.

CitarOtro administrador afectado confirmó un patrón idéntico:

"Observamos la misma actividad, incluso en la versión 7.4.9. El mismo usuario, la misma IP. Se creó un nuevo administrador del sistema llamado 'helpdesk'. Tenemos un ticket abierto con soporte y el equipo de desarrollo de Fortinet ha confirmado que la vulnerabilidad persiste en la 7.4.10".

Estos testimonios refuerzan la preocupación de que los parches actuales son incompletos, dejando a miles de cortafuegos empresariales en riesgo de compromiso total.

Falta de respuesta oficial y medidas temporales de mitigación

BleepingComputer intentó contactar con Fortinet en varias ocasiones para obtener aclaraciones oficiales sobre estos informes, pero la empresa no ha emitido una respuesta pública hasta el momento.

Mientras se espera una versión completamente corregida de FortiOS, los expertos recomiendan desactivar temporalmente la función vulnerable de inicio de sesión FortiCloud SSO, siempre que esté habilitada, como medida preventiva para reducir la superficie de ataque.

Cómo desactivar FortiCloud SSO en FortiGate

Los administradores pueden desactivar el inicio de sesión SSO de FortiCloud desde la interfaz gráfica o mediante la línea de comandos (CLI):

Código: text
config system global
set admin-forticloud-sso-login disable
end

Desde la interfaz web, la opción se encuentra en:
System > Settings > Allow administrative login using FortiCloud SSO → Off

Alcance real del problema: miles de dispositivos expuestos

Aunque Fortinet indicó en su aviso original que FortiCloud SSO no está habilitado por defecto si el dispositivo no está registrado en FortiCare, la realidad es que miles de sistemas sí tenían esta función activada.

La organización Shadowserver Foundation identificó más de 25.000 dispositivos Fortinet expuestos en Internet con FortiCloud SSO habilitado a mediados de diciembre. Aunque más de la mitad ya han sido asegurados, más de 11.000 dispositivos siguen accesibles públicamente, lo que los convierte en objetivos atractivos para atacantes.

CISA y otras amenazas activas de Fortinet

La gravedad del problema ha llevado a la Agencia de Ciberseguridad y Seguridad de Infraestructuras de EE. UU. (CISA) a añadir CVE-2025-59718 a su catálogo de vulnerabilidades explotadas activamente, ordenando a las agencias federales aplicar parches en un plazo máximo de una semana.

Además, los atacantes también están explotando de forma activa una vulnerabilidad crítica en Fortinet FortiSIEM, para la cual ya existe código de exploit de prueba de concepto disponible públicamente, permitiendo la ejecución de código con privilegios root en dispositivos sin parchear.

En fin...

La explotación continua de CVE-2025-59718 incluso en sistemas parcheados pone en evidencia los riesgos de correcciones incompletas en infraestructuras de seguridad críticas como los cortafuegos FortiGate. Hasta que Fortinet publique versiones definitivas de FortiOS que mitiguen completamente la vulnerabilidad, desactivar FortiCloud SSO y monitorizar activamente los registros se convierte en una medida esencial.

En un entorno donde los atacantes reaccionan con rapidez a cada parche publicado, la gestión de vulnerabilidades y la defensa en profundidad siguen siendo pilares clave para proteger la red corporativa.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#177

LastPass, uno de los gestores de contraseñas más utilizados a nivel global, ha emitido una alerta de seguridad tras detectar una nueva campaña activa de phishing diseñada para suplantar su identidad y engañar a los usuarios con el objetivo de robar sus contraseñas maestras. Este tipo de ataque representa una amenaza crítica, ya que la contraseña maestra es la llave que protege todas las credenciales almacenadas en la bóveda del usuario.

La campaña maliciosa comenzó aproximadamente el 19 de enero de 2026 y se basa en una técnica clásica pero altamente efectiva: ingeniería social combinada con urgencia artificial. Los atacantes envían correos electrónicos que aparentan proceder de LastPass, en los que se informa falsamente de un mantenimiento inminente de la infraestructura y se insta a los usuarios a crear una copia de seguridad local de su bóveda en un plazo máximo de 24 horas.

Asuntos de correo utilizados en la campaña de phishing

Para aumentar la tasa de éxito, los actores de la amenaza utilizan asuntos cuidadosamente redactados que refuerzan la sensación de urgencia y legitimidad. LastPass ha identificado, entre otros, los siguientes asuntos:

  • Actualización de infraestructura de LastPass: Asegura tu bóveda ahora
  • Tus datos, tu protección: crea una copia de seguridad antes del mantenimiento
  • No te lo pierdas: haz una copia de seguridad de tu bóveda antes del mantenimiento
  • Importante: Mantenimiento de LastPass y la seguridad de tu bóveda
  • Protege tus contraseñas: Haz una copia de seguridad de tu bóveda (ventana de 24 horas)

Estos mensajes están diseñados para generar ansiedad y presión temporal, empujando al usuario a actuar sin verificar la autenticidad del correo, una de las tácticas más comunes y efectivas en ataques de phishing dirigidos.

Infraestructura maliciosa y redirecciones fraudulentas

Los correos electrónicos redirigen inicialmente a los usuarios a un sitio alojado en una infraestructura aparentemente legítima, concretamente un bucket de Amazon S3:

  • group-content-gen2.s3.eu-west-3.amazonaws[.]com/5yaVgx51ZzGf
  • Desde allí, la víctima es redirigida automáticamente al dominio fraudulento:
  • mail-lastpass[.]com

Este dominio ha sido cuidadosamente elegido para simular una dirección legítima de LastPass, aumentando la probabilidad de que incluso usuarios experimentados caigan en el engaño. Una vez en el sitio de phishing, se solicita a la víctima que introduzca su contraseña maestra, lo que permite a los atacantes tomar control total de la bóveda.

Direcciones de correo utilizadas por los atacantes

LastPass también ha compartido las direcciones de correo electrónico desde las que se han originado los mensajes de phishing, entre ellas:

  • support@sr22vegas[.]com
  • support@lastpass[.]server8
  • support@lastpass[.]server7
  • support@lastpass[.]server3

Estas direcciones no pertenecen a la infraestructura oficial de LastPass y deben considerarse indicadores claros de compromiso (IOCs) para equipos de seguridad y usuarios finales.

LastPass: nunca pediremos la contraseña maestra

En respuesta a la campaña, LastPass ha sido tajante al reiterar un principio fundamental de su modelo de seguridad: la compañía nunca solicita la contraseña maestra de un usuario, ni por correo electrónico, ni a través de enlaces externos, ni bajo ninguna circunstancia.

Citar"Esta campaña está diseñada para crear una falsa sensación de urgencia, que es una de las tácticas más comunes y efectivas que vemos en ataques de phishing", explicó un portavoz del equipo de Inteligencia, Mitigación y Escalada de Amenazas (TIME) de LastPass.

El portavoz añadió que la empresa está colaborando activamente con socios terceros para desmantelar la infraestructura maliciosa y bloquear los dominios utilizados en la campaña, además de agradecer a los usuarios que continúan reportando actividades sospechosas.

Un patrón recurrente: campañas previas contra usuarios de macOS

Este incidente no es un caso aislado. Meses atrás, LastPass ya había advertido sobre una campaña de robo de información dirigida específicamente a usuarios de Apple macOS, en la que los atacantes utilizaban repositorios falsos de GitHub para distribuir software malicioso que se hacía pasar por gestores de contraseñas y otras aplicaciones populares.

Estas campañas demuestran una tendencia clara: los gestores de contraseñas se han convertido en objetivos prioritarios para los ciberdelincuentes debido al enorme valor de las credenciales que protegen.

Recomendaciones de seguridad para usuarios de LastPass

Ante este tipo de amenazas, los expertos recomiendan:

  • No hacer clic en enlaces incluidos en correos electrónicos no solicitados.
  • Verificar siempre el dominio antes de introducir cualquier credencial.
  • Acceder a LastPass únicamente desde la aplicación oficial o escribiendo manualmente la URL.
  • Activar y mantener habilitada la autenticación multifactor (MFA).

Reportar correos sospechosos directamente a LastPass.

En fin...

La nueva campaña de phishing que suplanta a LastPass pone de manifiesto que, incluso los usuarios de herramientas de seguridad avanzadas, siguen siendo vulnerables a ataques basados en ingeniería social. La combinación de urgencia, suplantación de marca y dominios falsos cuidadosamente diseñados sigue siendo altamente efectiva.

Mantenerse informado, desconfiar de solicitudes inesperadas y recordar que ningún proveedor legítimo pedirá una contraseña maestra son medidas clave para evitar caer en este tipo de fraudes. En un panorama de amenazas en constante evolución, la concienciación del usuario continúa siendo una de las defensas más importantes.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#178

Zoom y GitLab han publicado recientemente actualizaciones de seguridad urgentes para corregir múltiples vulnerabilidades de alta y crítica gravedad que podrían ser explotadas para provocar denegación de servicio (DoS), elusión de autenticación multifactor (2FA) e incluso ejecución remota de código (RCE) en entornos vulnerables. Estas fallas representan un riesgo significativo para organizaciones que dependen de estas plataformas en entornos corporativos, híbridos y de desarrollo colaborativo.

Vulnerabilidad crítica en Zoom MMR permite ejecución remota de código

La vulnerabilidad más grave identificada en este ciclo de parches afecta a los Zoom Node Multimedia Routers (MMR), un componente clave en las infraestructuras de Zoom utilizadas para optimizar el tráfico de reuniones en implementaciones locales e híbridas. El fallo de seguridad ha sido registrado como CVE-2026-22844 y cuenta con una puntuación CVSS de 9,9 sobre 10, lo que la sitúa en la categoría de vulnerabilidad crítica.

Según informó Zoom en su alerta de seguridad, el problema tiene su origen en una vulnerabilidad de inyección de comandos, que podría permitir que un participante de una reunión, con acceso a la red, ejecute código arbitrario de forma remota en el MMR afectado.

Citar"Una vulnerabilidad de inyección de comandos en los Zoom Node Multimedia Routers (MMR) anteriores a la versión 5.2.1716.0 podría permitir a un participante de la reunión realizar ejecución remota de código mediante acceso a la red", señaló la compañía.

Este tipo de vulnerabilidad es especialmente peligrosa, ya que abre la puerta a compromisos completos del sistema, permitiendo a un atacante ejecutar comandos con los privilegios del servicio afectado, pivotar dentro de la red o desplegar malware adicional.

Versiones afectadas y recomendaciones de mitigación

Zoom confirmó que el fallo afecta a los siguientes despliegues y versiones:

  • Versiones del módulo MMR de Zoom Node Meetings Hybrid (ZMH) anteriores a la 5.2.1716.0
  • Versiones del módulo MMR del Zoom Node Meeting Connector (MC) anteriores a la 5.2.1716.0

Aunque la compañía aseguró que no existen evidencias de explotación activa en el entorno real, recomienda encarecidamente a los clientes que utilicen Zoom Node Meetings, Hybrid o Meeting Connector que actualicen de inmediato a la versión más reciente disponible para reducir el riesgo de compromiso.

La detección temprana de esta vulnerabilidad por parte del equipo interno de Seguridad Ofensiva de Zoom pone de relieve la importancia de los programas de seguridad proactivos, aunque también subraya el impacto potencial que estas fallas pueden tener si son descubiertas por actores maliciosos.

GitLab publica parches para múltiples fallos de alta gravedad

De forma paralela, GitLab ha lanzado correcciones de seguridad que afectan tanto a su Community Edition (CE) como a la Enterprise Edition (EE). Las vulnerabilidades corregidas podrían permitir ataques de denegación de servicio, así como la elusión de la autenticación de dos factores (2FA), una de las capas de seguridad más críticas en entornos de desarrollo y DevOps.

Vulnerabilidades de alta gravedad corregidas por GitLab

Entre los fallos más relevantes se encuentran los siguientes:

CVE-2025-13927 (CVSS: 7,5)
Vulnerabilidad que permite a un usuario no autenticado provocar una condición de DoS mediante el envío de solicitudes con datos de autenticación malformados.
Versiones afectadas: todas las versiones desde la 11.9 hasta antes de 18.6.4, 18.7.2 y 18.8.2.

CVE-2025-13928 (CVSS: 7,5)
Error de autorización incorrecta en la API de Releases, que podría ser explotado por un atacante no autenticado para causar una denegación de servicio.
Versiones afectadas: desde la 17.7 hasta antes de 18.6.4, 18.7.2 y 18.8.2.

CVE-2026-0723 (CVSS: 7,4)
Vulnerabilidad especialmente preocupante que permite eludir la autenticación 2FA si el atacante conoce previamente el ID de credencial de la víctima, enviando respuestas falsificadas desde dispositivos.
Versiones afectadas: todas las versiones desde la 18.6 hasta antes de los parches mencionados.

Este último fallo destaca por su impacto potencial, ya que socava directamente los mecanismos de protección de acceso, exponiendo cuentas privilegiadas y repositorios sensibles.

Otros errores de gravedad media corregidos

GitLab también solucionó dos vulnerabilidades adicionales de gravedad media que podrían derivar en condiciones de DoS:

  • CVE-2025-13335 (CVSS: 6,5) – Manipulación de documentos Wiki malformados que eluden la detección de ciclos.
  • CVE-2026-1102 (CVSS: 5,3) – Envío repetido de solicitudes de autenticación SSH malformadas.

Aunque estas fallas presentan un menor impacto individual, su explotación combinada podría facilitar ataques de agotamiento de recursos en servidores GitLab expuestos a Internet.

Actualización inmediata como prioridad de seguridad

La publicación de estas vulnerabilidades críticas en Zoom y GitLab refuerza la necesidad de mantener estrategias de gestión de parches sólidas y una monitorización continua de la superficie de ataque. La ejecución remota de código, la denegación de servicio y la elusión de 2FA siguen siendo vectores de ataque prioritarios para los actores maliciosos.

Las organizaciones que utilizan estas plataformas deben actualizar de inmediato, revisar sus configuraciones de red y reforzar los controles de acceso para minimizar riesgos. En un contexto de amenazas cada vez más sofisticadas, la rapidez en la aplicación de parches marca la diferencia entre la prevención y el compromiso.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#179

Wine 11 es la nueva versión mayor de la conocida capa de compatibilidad que permite ejecutar aplicaciones y juegos de Windows en Linux y macOS, y llega fiel a su calendario anual con cifras que reflejan la magnitud del proyecto: más de 6.300 cambios introducidos y más de 600 errores corregidos. Como es habitual, el objetivo no cambia, pero sí se refuerza: mejorar la compatibilidad, el rendimiento y la estabilidad, tres pilares fundamentales para un componente clave del ecosistema Linux moderno.

Más allá de la larga lista de correcciones incrementales, Wine 11 destaca por dos avances estructurales de gran calado que marcarán la evolución del proyecto a medio y largo plazo. Ambos cambios no solo mejoran el comportamiento actual de Wine, sino que sientan una base técnica más limpia y eficiente para el futuro.

NTSYNC: un nuevo backend de sincronización con impacto real en el rendimiento

La principal novedad técnica de Wine 11 es la incorporación del soporte para NTSYNC, un nuevo backend de sincronización que permite a Wine apoyarse directamente en un módulo específico del kernel Linux, siempre que el sistema utilice Linux 6.14 o superior.

La sincronización es un aspecto crítico en la ejecución de software moderno. Los programas, especialmente los juegos y aplicaciones complejas, utilizan múltiples hilos de ejecución que deben coordinarse mediante primitivas como bloqueos, semáforos y eventos para evitar conflictos al acceder a recursos compartidos. Tradicionalmente, esta capa de sincronización suponía una sobrecarga considerable para Wine.

Con NTSYNC, Wine puede delegar parte de ese trabajo en el kernel de Linux, reduciendo de forma significativa la sobrecarga asociada a estas operaciones. El resultado es especialmente notable en aplicaciones intensivas en multihilo, donde una gestión más eficiente de la concurrencia se traduce en mejoras tangibles de rendimiento, menor latencia y un comportamiento más estable.

Este avance no es un simple ajuste interno, sino un cambio de arquitectura que refuerza la integración entre Wine y el sistema anfitrión, alineándose con la tendencia general de optimización a bajo nivel que está impulsando el gaming en Linux.

WoW64 completo: una arquitectura más limpia y preparada para el futuro

El segundo gran pilar de Wine 11 es la finalización de la nueva arquitectura WoW64, un rediseño profundo iniciado en versiones anteriores que ahora alcanza un estado considerado completo por los desarrolladores.

Esta nueva implementación unifica los cargadores, elimina la necesidad de prefijos exclusivamente de 32 bits y amplía la compatibilidad incluso con aplicaciones heredadas de 16 bits, algo especialmente relevante en entornos corporativos y software legacy.

El objetivo principal de este rediseño es reducir la complejidad interna de Wine al ejecutar aplicaciones Windows de 32 bits sobre sistemas de 64 bits. Según el proyecto, el resultado es una base más coherente, mantenible y flexible, que facilita la evolución futura del código y la introducción de nuevas mejoras sin arrastrar limitaciones históricas.

Mejoras continuas en Wayland y escritorios modernos

Wine 11 continúa avanzando en el soporte para Wayland, el protocolo gráfico que progresivamente está sustituyendo a X11 en los escritorios Linux modernos. Aunque el controlador Wayland de Wine sigue en evolución, esta versión introduce mejoras importantes en:

  • Integración con el entorno de escritorio
  • Manejo del portapapeles
  • Entrada de texto
  • Comunicación entre procesos más eficiente

Todo ello se traduce en mejor rendimiento general y una experiencia más consistente, especialmente en distribuciones que ya han adoptado Wayland como opción predeterminada.

También se han realizado avances en escalado DPI y soporte para pantallas de alta resolución, un apartado cada vez más relevante en equipos modernos y configuraciones multimonitor.

Avances en gráficos: Direct3D, Vulkan y multimedia

El subsistema gráfico es otro de los grandes beneficiados en Wine 11. Esta versión amplía y actualiza su compatibilidad con Vulkan, mejora la traducción de llamadas desde Direct3D y refuerza la interoperabilidad con tecnologías gráficas modernas.

Entre las novedades más destacadas se encuentra la habilitación de la decodificación de vídeo H.264 acelerada por hardware en determinados escenarios, lo que tiene un impacto directo en el rendimiento multimedia y la compatibilidad con aplicaciones que hacen un uso intensivo de vídeo.

A esto se suman mejoras repartidas por otros subsistemas clave, como:

  • Audio
  • Fuentes tipográficas
  • Red
  • Multimedia
  • Compatibilidad con distintas versiones de Windows

Además de numerosas correcciones específicas para aplicaciones populares y juegos ampliamente utilizados, junto a ajustes destinados a casos más particulares.

Wine y el ecosistema del gaming en Linux

Aunque Wine sigue siendo una herramienta muy particular y rara vez se utiliza de forma aislada, su evolución está íntimamente ligada al auge del gaming en Linux. Proyectos como Proton, Steam Play y el impulso de Valve no podrían entenderse sin los avances constantes de Wine como base tecnológica.

Wine 11 refuerza esa posición, consolidándose como uno de los pilares silenciosos que permiten que cada vez más usuarios consideren Linux como una alternativa real a Windows para jugar y ejecutar software propietario.

Rama estable y disponibilidad

Wine 11 inaugura una nueva rama estable, que se mantendrá y recibirá mantenimiento durante el próximo año, mientras el desarrollo continúa de forma activa en la rama experimental. Para quienes priorizan la estabilidad, esta versión es la opción recomendada.

Los usuarios interesados pueden consultar el listado completo de cambios en las notas de lanzamiento oficiales y descargar tanto el código fuente como los paquetes binarios desde el sitio web del proyecto. No obstante, en la práctica, la mayoría de usuarios acceden a Wine a través de distribuciones, gestores de paquetes o soluciones integradas como Proton.

En fin...

Wine 11 no es una revolución visible a simple vista, pero sí un paso decisivo a nivel técnico. Con NTSYNC y la nueva arquitectura WoW64 ya completada, el proyecto consolida una base más eficiente, moderna y preparada para el futuro. En un ecosistema Linux que no deja de ganar relevancia, Wine sigue demostrando que su evolución es tan silenciosa como imprescindible.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login
#180

Opera GX, el navegador web orientado al público gamer, llegará oficialmente a Linux durante el primer trimestre de 2026. Así lo ha confirmado la cuenta oficial de Opera GX en la red social X (antes Twitter), poniendo fin a años de especulación y peticiones por parte de la comunidad. Aunque la compañía no ha concretado todavía una fecha exacta ni ha ofrecido detalles técnicos adicionales, el anuncio marca un hito relevante para los usuarios de Linux interesados en alternativas de navegador con un enfoque claramente diferenciado.

La noticia no deja de ser llamativa si se tiene en cuenta que Opera GX fue lanzado originalmente en Windows hace más de siete años. Desde entonces, el navegador ha conseguido hacerse un hueco propio gracias a una propuesta muy clara: ofrecer una experiencia adaptada a jugadores, streamers y usuarios intensivos, con un fuerte énfasis en el control de recursos, la personalización y la integración con servicios clave del ecosistema gaming.

¿Qué es Opera GX y por qué genera interés en Linux?

Opera GX no es un navegador completamente distinto a Opera "clásico", sino una variante especializada que añade una capa de funcionalidades pensadas para un perfil de usuario concreto. Entre sus características más destacadas se encuentran:

  • Limitadores de CPU, RAM y ancho de banda, diseñados para evitar que el navegador interfiera con el rendimiento de juegos o aplicaciones exigentes.
  • Integración nativa con Twitch y Discord, facilitando el seguimiento de streams y comunidades sin salir del navegador.
  • Personalización visual avanzada, con temas, efectos sonoros y una estética inspirada en el mundo gaming.
  • Herramientas adicionales como GX Cleaner, GX Control o GX Corner, orientadas a la gestión del sistema y el descubrimiento de contenidos relacionados con videojuegos.

Estas funciones han permitido a Opera GX diferenciarse en un mercado de navegadores altamente saturado, especialmente en Windows. Su llegada a Linux, aunque tardía, responde a una realidad cada vez más evidente: Linux ya no es una plataforma marginal para jugar en PC.

El contexto: Linux y el auge del gaming en PC

La llegada de Opera GX a Linux no puede entenderse sin el contexto actual del ecosistema. Durante años, Linux fue percibido como una opción minoritaria y poco viable para el gaming. Sin embargo, esta percepción ha cambiado de forma radical gracias a varios factores clave:

  • Proton y Steam Play, impulsados por Valve, han mejorado de forma notable la compatibilidad con juegos diseñados originalmente para Windows.
  • El éxito de Steam Deck, basado en Linux, ha contribuido a normalizar esta plataforma entre jugadores.
  • Mejores controladores gráficos, avances en Vulkan y una comunidad cada vez más activa han reforzado la posición de Linux como alternativa real.

En este escenario, resulta lógico que empresas de software orientadas al público gamer empiecen a prestar más atención al escritorio Linux. Opera GX encaja perfectamente en esta tendencia.

¿Por qué ahora y no antes?

Una de las preguntas más repetidas tras el anuncio es evidente: ¿por qué Opera GX llega a Linux en 2026 y no antes? La compañía no ha dado una respuesta clara. No obstante, el contexto del anuncio resulta revelador.

Los responsables de Opera aprovecharon una conversación relacionada con Windows 11 —concretamente, los planes de Microsoft para ejecutar Copilot dentro del Explorador de archivos— para deslizar la noticia. Este tipo de decisiones de Microsoft no han sido bien recibidas por parte de muchos usuarios avanzados, lo que ha reavivado el debate sobre alternativas al ecosistema Windows.

En este sentido, anunciar Opera GX para Linux en medio de esa polémica no parece casual: refuerza la idea de que existen opciones fuera del entorno de Microsoft, incluso en ámbitos tradicionalmente dominados por Windows, como el gaming.

Dudas, críticas y la reputación de Opera

No todo han sido reacciones positivas. La noticia ha generado un volumen considerable de comentarios críticos, especialmente en X, donde no han faltado acusaciones de spyware y preocupaciones sobre privacidad. Opera arrastra desde hace años una reputación controvertida en este ámbito, en parte por su modelo de negocio y por decisiones pasadas que han generado desconfianza entre usuarios más concienciados con el software libre.

La pregunta de fondo es inevitable: ¿es Opera GX más intrusivo que alternativas como Chrome, Edge o incluso ciertas aplicaciones ofimáticas ampliamente utilizadas? El debate está abierto y, como casi siempre, depende del nivel de tolerancia y de las prioridades de cada usuario.

El gran interrogante: ¿cómo llegará Opera GX a Linux?

Más allá de la polémica, existe una preocupación legítima entre usuarios de Linux: la calidad del soporte. Experiencias anteriores con productos como Opera One en Linux dejaron un sabor agridulce, con problemas de estabilidad, rendimiento y una sensación general de abandono.

Por ello, muchos se preguntan si Opera ha aprendido de sus errores y si esta nueva versión de Opera GX llegará con:

  • Soporte adecuado para distribuciones populares
  • Integración correcta con entornos de escritorio
  • Actualizaciones regulares y corrección de errores
  • Un rendimiento comparable al de otras plataformas
  • Hasta que la versión para Linux no esté disponible, estas preguntas seguirán sin respuesta.

¿Necesita Linux otro navegador más?

Desde un punto de vista práctico, Linux no necesita más navegadores. Firefox, Chromium, Brave, Vivaldi y otros funcionan de manera excelente y cubren prácticamente todos los casos de uso. Sin embargo, también es cierto que toda alternativa suma, incluso cuando se trata de software privativo.

La clave está en la libertad de elección. Que Opera GX llegue a Linux no obliga a nadie a usarlo, pero sí amplía el abanico de opciones disponibles, especialmente para un perfil de usuario concreto como el gamer.

En fin...

La llegada de Opera GX a Linux en el primer trimestre de 2026 es una señal clara de la madurez de la plataforma y de su creciente relevancia en el mundo del gaming y el software de escritorio. Aunque existen dudas legítimas sobre privacidad, soporte y calidad, el anuncio refuerza una idea cada vez más evidente: Linux ya no es una opción secundaria.

Cuando Opera GX finalmente desembarque en Linux, será el momento de evaluar si está a la altura de las expectativas. Hasta entonces, el simple hecho de que llegue ya es, en sí mismo, una noticia relevante.

Fuente: You are not allowed to view links. You are not allowed to view links. Register or Login or You are not allowed to view links. Register or Login