GitHub agrega un tiempo de reutilización de Dependabot de 3 días para limitar la adopción de paquetes envenenados – CYBERDEFENSA.MX

GitHub ha anunciado un nuevo mecanismo de enfriamiento en Dependabot, que permite que la herramienta espere al menos tres días después de la publicación de un lanzamiento antes de abrir una solicitud de extracción.

«Sin embargo, la opción de configuración de enfriamiento en dependabot.yml todavía controla el comportamiento, por lo que puedes elegir un parámetro de enfriamiento diferente que se ajuste a tu proyecto», la subsidiaria propiedad de Microsoft. dicho.

Según GitHub, el tiempo de reutilización predeterminado de tres días solo se aplica a las actualizaciones de versión, que están diseñadas para mantener actualizadas las dependencias del software. Las actualizaciones de seguridad seguirán publicándose de inmediato, lo que permitirá al Dependabot emitir una alerta y abrir una solicitud de extracción para mover el proyecto a la versión parcheada.

Con esta actualización, la idea es manejar escenarios en los que un actor de amenazas logra enviar una versión envenenada de un paquete popular, que luego es rápidamente retirado por proyectos posteriores antes de que esa versión sea eliminada del registro. Aunque estos paquetes troyanizados son de corta duración, el período de tiempo durante el cual permanecen accesibles es suficiente para ampliar el radio de explosión de un ataque a la cadena de suministro.

GitHub dijo que llegó a tres días como valor predeterminado, ya que considera que la duración está en la zona de Ricitos de Oro. «Tres días como valor predeterminado equilibran dos objetivos: te empujan más allá de la ventana donde viven la mayoría de estos ataques y no retienen tus dependencias más de lo necesario», agregó.

Ciberseguridad

Al mismo tiempo, la plataforma de desarrollo de software enfatizó que el control debería ser solo una capa de defensa entre varias otras, incluida la fijación de dependencias con archivos de bloqueo, la desactivación de scripts de instalación en CI, el alcance de los tokens en los canales de compilación y la revisión de las actualizaciones antes de que se fusionen.

«Un tiempo de reutilización se crea para un patrón específico: una versión maliciosa que se envía, se propaga y se detecta rápidamente», dijo GitHub. «Hace poco contra los ataques que duran más tiempo, incluidas las puertas traseras colocadas en las versiones y que se dejan inactivas, el sabotaje del mantenedor o un sistema de compilación comprometido».

Vale la pena señalar que se anunciaron controles de enfriamiento similares en varios ecosistemas de paquetes durante el año pasado, incluidos Microsoft Visual Studio Code (VS Code), Ruby, Bun, npm, pnpm y Yarn.

La defensa basada en el tiempo de GitHub se produce cuando los mantenedores del Python Package Index (PyPI) anunciaron planes para impedir que los mantenedores agreguen nuevos archivos a la versión de un paquete después de que hayan pasado 14 días desde su publicación.

«La medida tiene como objetivo evitar que los atacantes que comprometen los tokens de publicación o los flujos de trabajo envenenen versiones antiguas y confiables», señaló PyPI.

TELESHIM abusa de Telegram para C2 en ataques contra gobiernos de Medio Oriente – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han detectado una nueva actividad cibernética maliciosa por parte de un actor de amenazas con vínculos con el este de Asia y dirigida a entidades gubernamentales en el Medio Oriente.

Las intrusiones han dado lugar a la implementación de familias de malware no denunciadas anteriormente denominadas TELESHIM, MIXEDKEY y BINDCLOAK, según Zscaler ThreatLabz. La firma de ciberseguridad dijo que detectó la campaña a principios de este mes.

«La campaña utilizó una cadena de ataque de múltiples etapas para establecer y mantener el acceso a los sistemas infectados, con TELESHIM abusando de la API de Telegram para la comunicación de comando y control (C2) para mezclarse con el tráfico legítimo de Internet», Sudeep Singh, gerente senior de investigación APT en Zscaler ThreatLabz, dicho en un artículo técnico publicado la semana pasada.

La cadena de ataque comienza con un archivo ISO que contiene un ejecutable legítimo («RegSchdTask.exe») que se utiliza para descargar una DLL maliciosa («AsTaskSched.dll»), una puerta trasera de Windows de 32 bits llamada TELESHIM que luego aprovecha Telegram como C2 para recuperar componentes de la siguiente etapa.

Ciberseguridad

Dos de estas cargas útiles se utilizan para activar una segunda Carga lateral de DLL cadena que comprende «GoProAlertService.exe» y «pthreadVC2.dll», y este último actúa como un cargador reflectante con nombre en código MIXEDKEY para descifrar el contenido de «C99F29AC08454855B3D538960BB2F34F.PCPKEY» y ejecutarlo.

Se ha descubierto que tanto TELESHIM como MIXEDKEY dependen de técnicas de ofuscación de código pesado, incluido el cifrado de cadenas, el aplanamiento del flujo de control (CFF), la aritmética booleana mixta (MBA) y predicados opacos para disuadir los esfuerzos de ingeniería inversa. TELESHIM también emplea una variedad de métodos para detectar la presencia de entornos de análisis basados ​​en virtualización. Algunos de estos se enumeran a continuación:

  • Detección de hipervisor mediante CPUID
  • Comprobación de la velocidad de la RAM mediante el Instrumental de administración de Windows (WMI)

Las comunicaciones TELESHIM C2 admiten dos tipos de mensajes:

  • Mensajes de control, que se utilizan para registrar el host infectado enviando la dirección MAC del host y ejecutando los comandos recibidos y exfiltrando los resultados al servidor en fragmentos si la salida tiene más de 1000 bytes.
  • Descargar y ejecutar mensajes, que se utilizan para descargar y ejecutar cargas útiles secundarias como tareas programadas.

Lo notable de la carga útil final es que está bloqueada detrás de dos capas de cifrado XOR, la segunda capa utiliza una técnica llamada clave ambiental cifrándolo mediante una clave de descifrado derivada del número de serie del volumen de la máquina infectada. Esto se hace para que el malware detone sólo en los objetivos previstos.

La secuencia de ataque culmina con la implementación de BINDCLOAK, un implante C2 de 64 bits escrito en C++ que contacta con un servidor externo («cert.hypersnet[.]com»).

Ciberseguridad

ThreatLabz señaló que identificó actividad posterior al compromiso del operador C2, como comandos de reconocimiento de sistema, usuario y red, así como la entrega de cargas útiles de la siguiente etapa, la mayoría de las cuales ocurrieron entre el 7 de julio de 2026 y el 9 de julio de 2026. Los comandos C2 se ejecutaron solo entre las 4 am y las 12 pm UTC, y una gran parte de la actividad tuvo lugar entre las 7 am y las 11 am UTC.

Según la dirección IP pública del actor de la amenaza, la configuración regional del sistema configurada en su servidor Windows, la geolocalización de la dirección IP y las horas operativas activas, se evalúa con confianza moderada a alta que la campaña es obra de un adversario originario del este de Asia. No se ha atribuido a ningún actor o grupo de amenazas conocido en este momento.

«La actividad también refleja tendencias más amplias como la evasión de EDR, la mezcla con el tráfico legítimo de Internet mediante el abuso de plataformas confiables y el uso de técnicas de ofuscación de códigos como MBA y CFF para obstaculizar la ingeniería inversa», dijo Singh.

La publicidad maliciosa envía malware en pedazos y luego hace que el navegador cree el ejecutable – CYBERDEFENSA.MX

Una operación de publicidad maliciosa denominada Comercio amargo está haciendo que los navegadores de las víctimas creen ellos mismos el ejecutable final de Windows, utilizando un tiempo de ejecución legítimo de Bun como base en lugar de servir un archivo malicioso completo desde una URL fija.

Confiante, que detalló la campaña el 23 de julio de 2026, dijo que ha operado desde finales de 2024 y se hizo pasar por TradingView, Solana y Luno para dirigirse a comerciantes minoristas e inversores en criptomonedas en 12 países en 25 idiomas.

Sus páginas de destino toman las huellas dactilares de los visitantes, mostrando a los investigadores y robots sospechosos una página vacía, mientras que los objetivos seleccionados reciben una copia convincente del servicio suplantado. La defensa contra esto es la ordinaria: instalar software comercial y de billetera desde el sitio del propio proveedor, no desde un anuncio.

La cadena documentada no se basa en una vulnerabilidad del navegador ni elimina la Marca de la Web (MotW). El análisis de Confiant documenta la entrega, no la ejecución, del archivo dentro del navegador, y no establece si la descarga final comienza automáticamente o requiere un clic.

La página de destino comienza a preparar la ruta de entrega sin esperar un clic de descarga. Registra un ServiceWorker con ámbito de página en /sw.jsluego crea un SharedWorker a partir de JavaScript ya incrustado en la página, por lo que la fuente del trabajador nunca aparece como una recuperación separada.

Las solicitudes de SharedWorker /configque devuelve una plantilla, una URL de ejecución secundaria y valores aleatorios específicos de la sesión. El navegador recupera y descomprime un tiempo de ejecución de Bun limpio de ese segundo dominio, purelogicbox.[.]org en la respuesta de muestra publicada.

Ciberseguridad

Los blobs Base64 en la configuración proporcionan el encabezado del ejecutable portátil (PE), la tabla de secciones y un .bun sección que contiene código de bytes JavaScriptCore malicioso para app.js. Bun se ejecuta en el motor JavaScriptCore de Apple y es compatible legítimamente compilar aplicaciones y código de bytes en ejecutables independientes de Windows.

Luego, el trabajador genera un gran flujo de bytes pseudoaleatorios utilizando AES en modo contador (AES-CTR). Luego sigue la plantilla proporcionada como una receta de copia de bytes, combinando rangos seleccionados del tiempo de ejecución de Bun, el flujo generado y el material ejecutable controlado por el atacante.

Cada víctima puede recibir un archivo ensamblado diferente: rotando la semilla y el tamaño en cada uno /config La respuesta cambia el hash manteniendo el código de carga útil ejecutable. «Nunca existe ningún malware terminado en la red», escribió Michael Steele del equipo de inteligencia de amenazas de Confiant. Ningún binario completo lo hace, aunque las estructuras PE y el código de bytes llegan como Base64 en /config.

Una vez ensamblada, la página pasa el ejecutable al ServiceWorker como una secuencia legible. Un iframe oculto navega a una URL del mismo origen y el trabajador devuelve los bytes generados con un Content-Disposition encabezado del archivo adjunto. El registro MotW resultante identifica la página de destino como la fuente de descarga, no el dominio separado que proporcionó el tiempo de ejecución de Bun. El propio MotW sigue presente.

El método evolucionó a partir de la actividad que Confiant rastreó hasta el 30 de abril de 2026, cuando se cargaron las páginas. StreamSaver.jsuna biblioteca de descarga continua de código abierto, desde la dirección de GitHub Pages de su autor. Eso dejó la ruta de descarga registrada apuntando a la URL de GitHub de la biblioteca. Las páginas actuales mantienen su arquitectura de streaming, incluyendo la streamsaver: nombres de mensajes, pero ya no los recupera de GitHub.

Bitdefender documentado el clúster de publicidad maliciosa TradingView relacionado en septiembre de 2025, identificando su carga útil final como el ladrón que Check Point rastrea como JSCEAL y con Secure como GorgojoProxy.

Ciberseguridad

Confiant identifica la campaña compartida y las características ejecutables, pero no demuestra que las tres muestras publicadas lleven esa carga útil. El informe también dice que Bitdefender encontró un ejecutable Bun modificado en este clúster.

Hacker News no encontró ninguna mención de Bun en los enlaces de Confiant de la publicación de septiembre de 2025, que nombra su detección de cargador Variant.DenoSnoop.Marte.1. Por lo tanto, el robo de credenciales, el registro de teclas, la interceptación de tráfico, el robo de billeteras y las capacidades de acceso remoto documentadas en la campaña anterior aún no se pueden asignar a los archivos actuales.

The Hacker News se comunicó con Confiant para solicitar aclaraciones sobre su referencia a los hallazgos anteriores de Bitdefender y actualizará esta historia con cualquier respuesta.

No es necesario aplicar ningún parche de software. La evasión es más estrecha de lo que parece a primera vista. La propia sección de implicaciones prácticas de Confiant lo expresa de manera más modesta: las compilaciones únicas por sesión limitan el valor de las detecciones simples basadas en hash. El material PE y el código de bytes controlados por el atacante aún cruzan la red.

Los defensores deben examinar toda la cadena, desde la referencia del anuncio y la página de destino encubierta hasta la /config solicitud, la recuperación del tiempo de ejecución del dominio secundario y la descarga de ServiceWorker, en lugar de tratar cualquier artefacto de red o archivo como decisivo.

Confiant publicó tres hashes SHA-256 y una lista de dominios maliciosos, 96 según el recuento de The Hacker News. La empresa no nombró a ningún actor y detuvo su análisis en el momento en que el archivo llega al disco.

El portal DevMan RaaS centraliza la creación de carga útil, la gestión de víctimas y los pagos de afiliados – CYBERDEFENSA.MX

Los operadores del esquema de ransomware como servicio (RaaS) de DevMan mantienen una plataforma web dedicada que ofrece a los afiliados la capacidad de crear cargas útiles, supervisar las ganancias y gestionar diversos aspectos relacionados con las víctimas.

La empresa suiza de ciberseguridad PRODAFT está siguiendo la operación RaaS administrada centralmente bajo el nombre Mantis funky.

«El portal combinaba funciones de generación de edificios, finanzas, chat para víctimas, soporte, registros de víctimas, equipos y pagos», dijo la empresa. dicho en un extenso informe compartido con The Hacker News.

«El servicio integraba la intermediación de acceso o la distribución de acceso con la implementación de ransomware. Los administradores ofrecieron ‘redes’ específicas de cada país, preguntaron si un afiliado usaría acceso personal o proporcionado por el programa e impusieron ventanas de finalización de dos a tres días».

Varios análisis muestran que DevMan apareció por primera vez en escena en abril de 2025 como afiliado de Qilin, DragonForce, Apos y RansomHub, antes de pasar a su propia operación RaaS. El ADN del casillero es «inconfundiblemente DragonForce», Vectra AI anotado en octubre de 2025, destacando la linaje compartido del ransomware.

En una entrevista con el investigador de seguridad Jon DiMaggio publicado En octubre de 2025, DevMan reconoció que habían trabajado con Conti y afirmaron que habían desarrollado un «casillero SCADA especializado» para apuntar a una compañía de gas anónima que fue diseñado para infligir daño físico progresivo más allá del cifrado.

Ciberseguridad

Según el actor de la amenaza, el malware «empujaría los sistemas de control industrial más allá de sus parámetros operativos, procesadores, memoria y límites térmicos, obligando a los sistemas a acelerar y funcionar en caliente hasta que el hardware fallara».

«El actor de amenazas está operando con una presencia en línea de alto perfil y actualizando sobre desarrollos, actualizaciones y declaraciones generales principalmente en inglés y a veces también en ruso», dijo la Dirección Nacional Cibernética de Israel (INCD) dicho en un boletín publicado el año pasado. «A menudo ‘se jactan’ de sus logros, hasta el punto de publicar artículos que describen la forma en que obtuvieron acceso y realizaron el ataque».

Las operaciones de DevMan sufrieron un golpe en junio de 2025 después de que un misterioso denunciante se hiciera llamar GangExposed. públicamente engañado identidades de los operadores, lo que provocó que algunos afiliados abandonaran la operación. DevMan también alegó que GangExposed intentó extorsionarlos por 0,3 a 1 Bitcoin durante sus interacciones en Telegram.

De acuerdo a estadística En Ransomware.Live, el grupo se ha cobrado 184 víctimas hasta la fecha, y no se han reportado nuevas víctimas después del 4 de febrero de 2026. Casi 50 víctimas se encuentran en los EE. UU., siendo los sectores de tecnología, atención médica, servicios financieros, servicios profesionales y gobierno los más atacados.

Desde entonces, el portal de afiliados asociado con la operación, que originalmente giraba en torno a funciones de constructores, finanzas, chat para víctimas y mesa de ayuda, ha recibido una actualización. La tercera versión («v3) de la plataforma lanzada en enero de 2026 incluye soporte para registros estructurados de víctimas, estados del ciclo de vida, creación de equipos, controles de invitación, opciones de creación por víctima, seguimiento de fechas límite, campos de ingresos y acceso operativo compartido.

«Esta progresión indica un esfuerzo por formalizar los flujos de trabajo de los afiliados y gestionar múltiples intrusiones a través de una plataforma común en lugar de depender únicamente de la coordinación basada en chat», dijo PRODAFT.

La empresa de ciberseguridad ha identificado cinco roles distintos dentro de las operaciones de DevMan:

  • LARVA-367 – Administrador/propietario y coordinador central
  • LARVA-546 – Coordinador de acceso nombrado como punto de contacto alternativo para el acceso a la red
  • LARVA-547 – Operador senior
  • LARVA-548 – Operador o coordinador senior
  • LARVA-550 – Afiliado/operador al que se le acreditó una instalación en un mensaje grupal controlado por un actor

«Los afiliados fueron agregados al chat corporativo después de producir una primera víctima y se les asignó un curador experimentado», dijo PRODAFT. «Podrían ser eliminados después de un mes sin una nueva víctima. La formación del equipo y la divulgación de la afiliación al programa requerían la aprobación del curador, lo que limitaba la coordinación independiente y la asociación pública con el servicio».

La dirección central también se reserva el derecho de hacerse cargo de una conversación si un afiliado se comporta de forma inapropiada o no cumple un compromiso. El modelo de gobernanza reduce la autonomía de los afiliados, al tiempo que otorga a los administradores el poder de hacer cumplir el ritmo operativo y proteger sus ingresos.

Los ingresos ilícitos obtenidos después de una extorsión exitosa se dividen entre el 80% y el 20%, lo que permite al afiliado obtener una parte de las ganancias. Las reglas de la plataforma v3 establecen que los fondos del rescate se envían a dos billeteras, una para el afiliado y otra vinculada al programa RaaS.

La política de focalización declarada de DevMan permite a los afiliados atacar entidades fuera de los países de la CEI y Serbia. También excluye a los consulados de la CEI y a las empresas vinculadas a la CEI, y levanta una restricción anterior impuesta a Arabia Saudita. Además de fomentar explícitamente los ataques contra infraestructura crítica, instruye a los afiliados a solicitar un cifrador separado para los sistemas SCADA, corroborando su desarrollo en un casillero SCADA especializado.

Sin embargo, la política prohíbe a los afiliados atacar empresas de atención médica relacionadas con niños y filtrar intencionalmente datos personales de personas menores de 18 años.

La última versión del portal permite a los afiliados crear un casillero para Windows, ESXi o Linux. Un análisis de la versión de Windows ha identificado funciones relacionadas con la verificación de privilegios para determinar si se está ejecutando como administrador, deterioro del control de seguridad, terminación de procesos y servicios, inhibición de recuperación, borrado de registros de eventos, descubrimiento de recursos compartidos locales y de red, movimiento lateral, cifrado multiproceso, creación de notas de rescate y autoeliminación opcional.

El casillero cifra archivos con ChaCha20-Poly1305. Los archivos de hasta 3 MiB inclusive se cifran completamente, mientras que los que superan el umbral se cifran parcialmente procesando un fragmento de 1 MiB cada 51 MiB.

«Las organizaciones deberían prohibir el inicio de sesión interactivo de VPN a las cuentas de servicio y de respaldo a menos que exista un requisito operativo documentado», dijo PRODAFT. «El acceso remoto y la administración privilegiada deben utilizar MFA resistente al phishing. Los equipos deben rotar las credenciales expuestas a dispositivos VPN, integraciones LDAP, scripts y herramientas de respaldo, dando prioridad a los secretos que pueden otorgar acceso administrativo local o de dominio».

Huntress enfrenta acusaciones de amenazas internas

La revelación también llega en un momento en que Ben Folland, un ex empleado de la firma de seguridad Huntress, acusado otro analista del paso de comunicaciones de las fuerzas del orden estadounidenses a DevMan. El incidente Se dice que tuvo lugar en diciembre de 2025.

En una publicación de blog posterior, el director ejecutivo de Huntress, Kyle Hanslovan, dijo que la compañía está al tanto de «comunicaciones cuestionables y de largo plazo de actores de amenazas» entre un investigador de amenazas que todavía trabaja en la empresa de seguridad y un cibercriminal, y lo calificó de «falta de juicio».

Ciberseguridad

«En un intercambio particular, nuestro actual compañero de equipo le reveló a un actor de amenazas que las autoridades se habían comunicado con ellos sobre el actor de amenazas», Hanslovan dicho. «Si bien esta divulgación no fue ilegal, reflejó un mal criterio».

«Como resultado de la investigación, mi equipo implementó políticas más sólidas para nuestros investigadores, capacitó a sus compañeros de equipo sobre cómo interactuar con los actores de amenazas y tomó las medidas administrativas apropiadas. Si bien no hemos encontrado evidencia de conducta ilegal, actividad interna o divulgaciones adicionales, continuamos nuestra investigación».

Holland, sin embargo, no está de acuerdo con la evaluación y afirma que las acciones del empleado «cumplen la definición de amenaza interna». El ex empleado de Huntress también cuestionó a Huntress si al analista se le permitía interactuar con DevMan para «apoyar investigaciones activas».

Según Folland, se dice que la Oficina Federal de Investigaciones (FBI) de EE. UU. se puso en contacto con el empleado de Huntress para recopilar información sobre DevMan. «Ella inmediatamente envió las comunicaciones exactas del FBI al actor de la amenaza, incluidas capturas de pantalla que contenían los nombres de los agentes del FBI», Folland dicho. «Ella informó a DevMan que las autoridades lo estaban investigando activamente. También se negó a cooperar porque querían a DevMan».

«Esto no fue sólo un ‘mal juicio’», continuó Folland. «Se trataba de un empleado de Huntress que tomó conocimiento sensible sobre un enfoque de aplicación de la ley y se lo pasó directamente a la persona que estaba siendo investigada. Si alguien dentro de un banco advierte a un estafador que la policía lo está investigando, nadie lo describiría simplemente como ‘falta de juicio’. Lo llamarían como es: un insider».

Los afiliados de Cl0p apuntan a PTC Windchill y FlexPLM expuestos a Internet con RCE no autenticado – CYBERDEFENSA.MX

Los actores de amenazas vinculados a la campaña de ransomware Cl0p (también conocido como Chubby Scorpius, FIN11, Graceful Spider y Lace Tempest) están explotando fallas en las implementaciones de PTC Windmill y FlexPLM expuestas a Internet como parte de una nueva campaña de extorsión de datos.

«Los atacantes encadenan una divulgación de información de autenticación previa en el punto final FlexPLM WSDL con una falla del lado del servidor en el servlet de inicio de sesión de Windchill, lo que permite la ejecución remota de código no autenticado y la implementación de shells web JSP con nombres hexadecimales en /Windchill/login/», según un nuevo aviso coordinado publicado por Ransom-ISAC junto con eCrime.ch y DEFUSED.

Al lograr un punto de apoyo inicial, se descubrió que los atacantes realizaban enumeraciones del sistema de archivos, escenificaban datos de ingeniería/diseño y, en última instancia, llevaban a cabo doble extorsión y robo de datos. Los objetivos de la campaña incluyen los sectores manufacturero, automotriz, aeroespacial y minorista.

Ciberseguridad

Se sospecha que los actores de amenazas están explotando CVE-2026-12569 (puntuación CVSS: 9,3), una falla de seguridad crítica en PTC Windmill que se agregó al catálogo de vulnerabilidades explotadas conocidas (KEV) de la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) a fines del mes pasado.

En un aviso, PTC advirtió a los clientes que había «recibido informes continuos de una mayor actividad de amenazas», y agregó que atacantes desconocidos están explotando la vulnerabilidad para implementar shells web JSP contra sistemas susceptibles.

«En las intrusiones observadas, este RCE está encadenado con un defecto separado de divulgación de información previa a la autenticación en el punto final FlexPLM WSDL (CVSS v3.1 7.5) para permitir la explotación no autenticada», dijeron los investigadores Brandon Parsons, Corsin Camichel y Simo Kohonen.

Ransom-ISAC ha compartido cuatro direcciones IP como indicadores de compromiso (IoC), todas las cuales coinciden con las compartidas por PTC.

  • 216.152.148.54
  • 216.152.151.204
  • 104.243.35.63
  • 5.180.41.35

Los correos electrónicos de extorsión parecen provenir de cuentas previamente comprometidas y se envían a cientos de usuarios dentro de una organización afectada, junto con formas de contactar al equipo de ransomware Cl0p.

Ciberseguridad

En una publicación separada en X, ReliaQuest dijo que observó actores de amenazas explotando activamente CVE-2026-12569 para facilitar la «ejecución remota de código no autenticado y la implementación de shell web JSP para la ejecución remota de comandos y la exfiltración de datos confidenciales de productos».

«El actor detrás de estos ataques aún no está confirmado. Sin embargo, el arte observado comparte características con campañas anteriores de Cl0p dirigidas a aplicaciones empresariales y repositorios de datos de alto valor», dice. agregado.

La pandilla Cl0p tiene un historial de perseguir fallas de seguridad en productos empresariales ampliamente utilizados para ingresar a organizaciones objetivo de robo de datos y ataques de extorsión. Las campañas anteriores montadas por el grupo han convertido en armas dispositivos de transferencia de archivos, incluidos los de Accellion FTA, GoAnywhere MFT, SolarWinds Serv-U FTP, Cleo y MOVEit Transfer, así como una vulnerabilidad en Oracle E-Business Suite.

La investigación de CTM360 revela cómo el phishing de seguros ha evolucionado hacia el secuestro de cuentas en tiempo real – CYBERDEFENSA.MX

Durante años, las campañas de phishing dirigidas a instituciones financieras siguieron el mismo manual. Se engañó a las víctimas para que ingresaran nombres de usuario y contraseñas, los atacantes recopilaron las credenciales y las cuentas se vieron comprometidas más tarde cuando surgió la oportunidad.

Ese modelo está cambiando.

Investigaciones recientes sobre operaciones de phishing centradas en seguros revelan un enfoque más inmediato. En lugar de recopilar credenciales para su uso posterior, los atacantes ahora sincronizan su actividad con las víctimas en tiempo real, autenticándose en portales de seguros legítimos cuando las víctimas completan el proceso de inicio de sesión sin saberlo. Todo el ataque puede desarrollarse en una sola sesión de navegación.

Este cambio pone de relieve una tendencia más amplia en todo el panorama de la ciberseguridad. A medida que las campañas de phishing se vuelven más sofisticadas, ya no basta con identificar sitios web maliciosos y dominios de suplantación de identidad. Las organizaciones necesitan cada vez más comprender la infraestructura, las técnicas y los flujos de trabajo operativos detrás de estos ataques.

Lea el informe completo aquí: https://www.ctm360.com/reports/insuretrap-fake-insurance-phishing-account-hijacking

Los seguros se han convertido en un objetivo cada vez más atractivo

Los proveedores de seguros han ampliado rápidamente sus servicios en línea. Los clientes ahora pueden comprar pólizas, renovar coberturas, presentar reclamos, administrar cuentas, actualizar información personal y completar pagos completamente a través de portales digitales.

Si bien esto mejora la experiencia del cliente, también crea un entorno atractivo para los actores de amenazas.

A diferencia de los ataques bancarios tradicionales que apuntan principalmente a transacciones financieras, las cuentas de seguros comprometidas a menudo contienen amplia información personal, documentos de identidad, registros de pólizas, métodos de pago y otros datos confidenciales de los clientes que pueden respaldar el fraude mucho más allá del compromiso inicial.

Durante la investigación, se identificó una operación de phishing coordinada dirigida a múltiples proveedores de seguros en varias regiones. En lugar de hacerse pasar por una sola organización, la campaña reutilizó la misma infraestructura operativa en numerosas marcas de seguros, adaptando el lenguaje, la marca y el contenido para adaptarse a los mercados locales. Arabia Saudita parecía ser el objetivo principal, mientras que se observó actividad adicional en Europa, Estados Unidos e India.

Los anuncios de Google se están convirtiendo en el vector de ataque inicial

Una de las observaciones más notables fue el uso constante de anuncios patrocinados de Google como principal mecanismo de entrega.

En lugar de depender de correos electrónicos de phishing o campañas de SMS, los atacantes compran anuncios que aparecen cuando los usuarios buscan cotizaciones de seguros, renovaciones o comparaciones de precios. Los anuncios promocionaban ofertas como «Compare ofertas de seguros de automóvil» o «Seguro a terceros más barato», animando a los usuarios a hacer clic en lo que parecían ser servicios de cotización legítimos.

Después de hacer clic en el anuncio, las víctimas son redirigidas a sitios web de phishing diseñados para parecerse mucho a proveedores de seguros genuinos. Estos sitios replicaron marcas, interfaces de usuario, flujos de trabajo de cotizaciones y portales de clientes con un nivel de realismo destinado a reducir las sospechas durante la interacción.

La infraestructura que apoyaba estas campañas era igualmente desechable. En lugar de depender de alojamiento malicioso dedicado, los operadores frecuentemente aprovechaban creadores de sitios web legítimos y plataformas de alojamiento gratuitas como GitHub Pages, Netlify, Hostinger, Wix, Lovable y otros servicios en la nube. Los dominios aleatorios con poca o ninguna semejanza con las marcas de seguros permitieron que las campañas rotaran rápidamente y al mismo tiempo redujeron la efectividad de los esfuerzos convencionales de monitoreo de marcas.

El phishing ha evolucionado hacia el secuestro de cuentas en tiempo real

Las campañas de phishing se han utilizado durante mucho tiempo para robar información confidencial, incluida información personal, detalles financieros, datos de tarjetas de pago, registros de seguros y credenciales de cuentas. En muchos casos, el objetivo era recopilar la mayor cantidad de información posible y explotarla posteriormente mediante la apropiación de cuentas, el fraude de identidad o el abuso financiero.

Las modernas campañas de phishing en seguros representan una evolución significativa de este modelo. En lugar de funcionar como páginas estáticas de recopilación de datos, estos portales de phishing interactúan activamente con las víctimas durante todo el proceso de autenticación. A medida que las víctimas envían su información, los atacantes utilizan simultáneamente los datos recopilados para interactuar con el portal de seguros legítimo en tiempo real, convirtiendo la página de phishing en un intermediario vivo entre la víctima y el servicio genuino.

Este enfoque permite a los atacantes superar los mecanismos de autenticación que tradicionalmente limitarían la utilidad de las credenciales robadas. Cuando el proveedor de seguros legítimo envía una contraseña de un solo uso (OTP) u otro desafío de verificación, la página de phishing solicita inmediatamente a la víctima que ingrese el mismo código bajo la apariencia de una verificación de identidad de rutina. Luego, la OTP enviada se transmite al portal legítimo antes de que caduque, lo que permite a los atacantes completar el proceso de autenticación mientras la víctima no se da cuenta.

En lugar de simplemente recopilar información para uso futuro, estas campañas sincronizan cada etapa del proceso de inicio de sesión, lo que permite a los atacantes validar credenciales, satisfacer requisitos de autenticación multifactor y establecer sesiones autenticadas en tiempo real. El resultado es una forma mucho más efectiva de phishing que transforma lo que alguna vez fue un ejercicio de recopilación de datos en una operación activa de secuestro de cuentas, reduciendo significativamente la oportunidad para que las víctimas o los defensores detecten e interrumpan el ataque antes de obtener acceso.

Los kits de phishing modernos funcionan como plataformas operativas

El análisis de la infraestructura de phishing reveló que estas campañas están respaldadas por mucho más que páginas de phishing estáticas.

Durante la investigación, CTM360 identificó un kit de phishing previamente indocumentado y lo nombró Kit InsureOTP. El kit está diseñado específicamente para operaciones de phishing relacionadas con seguros y proporciona gestión de sesiones en vivo, recopilación de datos en tiempo real, administración de backend y múltiples métodos de exfiltración de datos.

A diferencia de los kits de phishing más antiguos que simplemente enviaban por correo electrónico las credenciales capturadas, este marco permite a los operadores gestionar activamente cada sesión de la víctima.

Las capacidades observadas incluyeron:

  • Monitoreo de víctimas en tiempo real
  • Paneles administrativos de backend
  • Flujos de trabajo de aprobación manual
  • Seguimiento de sesiones
  • Integraciones de Telegram Bot
  • Comunicación API de backend directa
  • Manejo de OTP en vivo

Algunas variantes se basaban en las API de Telegram Bot para recibir envíos estructurados de las víctimas al instante, mientras que otras transmitían información directamente a servidores backend controlados por el atacante. Los investigadores también observaron interfaces de backend capaces de solicitar envíos OTP adicionales cada vez que fallaba la autenticación, lo que permitía a los operadores continuar intentando acceder a la cuenta antes de que caducaran los códigos de autenticación.

Estas capacidades demuestran cómo los kits de phishing continúan evolucionando desde simples recolectores de credenciales hasta plataformas de ataque interactivas diseñadas para comprometer cuentas reales.

La infraestructura puede revelar toda la operación

Uno de los aspectos más valiosos de la inteligencia sobre amenazas cibernéticas es la capacidad de ir más allá de las páginas de phishing individuales y comprender el ecosistema de campaña más amplio.

Durante la investigación, CTM360 identificó recursos backend de acceso público asociados con la infraestructura de phishing. El análisis de los archivos expuestos reveló componentes administrativos, código fuente backend, bases de datos SQLite, registros operativos e infraestructura de soporte que proporcionaron información sobre cómo funcionaba el marco de phishing.

La investigación demuestra por qué la inteligencia sobre amenazas moderna va más allá de la identificación de dominios maliciosos o sitios web de phishing. Al analizar la infraestructura subyacente, las herramientas, los componentes backend y los flujos de trabajo de los atacantes, los defensores pueden obtener una comprensión mucho más profunda de cómo se desarrollan, gestionan y ejecutan las campañas.

en lugar de preguntar «¿Dónde está la página de phishing?» los investigadores estan preguntando «¿Cómo funciona la campaña?»

Este cambio refleja uno de los cambios más significativos en la inteligencia moderna sobre amenazas cibernéticas, yendo más allá de la detección de amenazas individuales hacia la comprensión de la infraestructura, las herramientas y la metodología operativa del adversario.

Por qué los defensores necesitan un enfoque diferente

La característica definitoria de esta campaña no es simplemente el robo de credenciales; es compromiso de tiempo de sesión.

La respuesta tradicional a incidentes supone que existe un retraso entre el robo de credenciales y el abuso de cuentas. Esa suposición ya no siempre se cumple.

En estas operaciones, la recolección de credenciales, la interceptación de OTP y la adquisición de cuentas se producen como parte de un único flujo de trabajo continuo. Cuando una víctima se da cuenta de que algo anda mal, es posible que el atacante ya se haya autenticado exitosamente y haya obtenido acceso a la cuenta legítima.

Para los defensores, esto significa que la detección no puede depender únicamente de la identificación de dominios de phishing después de que aparecen en línea.

Las organizaciones deben monitorear los anuncios pagados que abusan de sus marcas, dominios similares recientemente registrados, infraestructura de phishing desechable alojada en la nube y patrones de autenticación que indiquen una interceptación de OTP en tiempo real.

Igualmente importante es comprender el ecosistema de atacantes detrás de estas campañas en lugar de tratar cada sitio de phishing como un incidente aislado.

Mirando más allá de la página de phishing

Las campañas de phishing en seguros son un claro ejemplo de cómo las amenazas externas siguen evolucionando.

Los atacantes están optimizando la velocidad, la automatización y el acceso inmediato en lugar de retrasar la explotación. La infraestructura es cada vez más desechable, los kits de phishing se están convirtiendo en plataformas operativas y el compromiso de la cuenta ahora ocurre durante la sesión activa de la víctima y no después.

Para los defensores, esto refuerza una realidad importante. Ya no basta con identificar sitios web maliciosos. Los equipos de seguridad necesitan cada vez más inteligencia contextual que conecte la infraestructura, los flujos de trabajo de los atacantes, las herramientas y el comportamiento de las campañas para comprender cómo evolucionan las amenazas y dónde pueden interrumpirse antes de que lleguen a los clientes.

Esto también refleja un cambio más amplio que se está produciendo en toda la industria de la ciberseguridad. La protección contra riesgos digitales (DRP) se ha centrado tradicionalmente en identificar amenazas externas, como sitios web de phishing, suplantación de marcas y dominios maliciosos. Hoy en día, las organizaciones requieren cada vez más de Cyber ​​Threat Intelligence (CTI) que explique cómo operan las campañas, cómo se conecta la infraestructura de los atacantes, cómo evolucionan los kits de phishing y cómo los adversarios ejecutan y adaptan sus operaciones.

CTM360 ha experimentado esta misma evolución, expandiéndose desde una plataforma de protección de riesgos digitales a una plataforma más amplia de inteligencia contra amenazas cibernéticas. A principios de este año, CTM360 fue reconocido como uno de los proveedores incluidos en el Magic Quadrant™ inaugural de Gartner para tecnologías de inteligencia contra amenazas cibernéticas.

Si bien esta investigación se centra en una campaña de phishing de seguros, también demuestra por qué los programas de seguridad modernos requieren inteligencia que va más allá de identificar indicadores individuales para comprender las operaciones completas del adversario.

Lea el informe completo aquí: https://www.ctm360.com/reports/insuretrap-fake-insurance-phishing-account-hijacking

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

Vulnerabilidad Fastjson 1.x RCE dirigida a ataques sin parches disponibles – CYBERDEFENSA.MX

Las firmas de seguridad ThreatBook e Imperva dicen que los atacantes están apuntando a una falla crítica en Fastjson, la biblioteca JSON de Alibaba para Java. En las aplicaciones Spring Boot afectadas, una solicitud JSON maliciosa puede ejecutar código sin autenticación, con los privilegios del proceso Java.

Seguimiento como CVE-2026-16723la vulnerabilidad tiene una puntuación CVSS de 9,0 asignada por Alibaba. La cadena confirmada requiere Fastjson 1.2.68 a 1.2.83, un fat-JAR ejecutable de Spring Boot, una ruta accesible en la red que envía JSON controlado por el atacante a un analizador afectado y SafeMode dejado en su valor predeterminado deshabilitado. AutoType puede permanecer deshabilitado y no se requiere ningún gadget de classpath.

Hasta el 25 de julio, Alibaba no había lanzado una versión fija de Fastjson 1.x. Las organizaciones que no pueden migrar inmediatamente deben habilitar SafeMode con -Dfastjson.parser.safeMode=true o usar com.alibaba:fastjson:1.2.83_noneautotype. Alibaba enumera la migración a Fastjson2 como la solución a largo plazo.

Alibaba publicó su aviso el 21 de julio tras la divulgación responsable por parte de Kirill Firsov de FearsOff Ciberseguridad. Los mantenedores describieron la vulnerabilidad como que no requiere «activación de AutoType» ni «ningún dispositivo classpath». Verificaron la cadena en Spring Boot 2.x, 3.xy 4.x con JDK 8, 11, 17 y 21.

Ciberseguridad

Firsov rastreó el problema hasta la ruta de resolución de tipos de Fastjson. Un atacante controlado @type El valor se puede convertir en una búsqueda de recursos de clase. En un fat-JAR Spring Boot compatible, una ruta JAR anidada diseñada puede recuperar el código de bytes controlado por el atacante. Un @JSONType La anotación en ese recurso se puede tratar como una señal de confianza, lo que permite que la clase pase las comprobaciones de tipo y la carga de Fastjson.

Su análisis técnico también describe una ruta JDK más nueva que descarga un JAR remoto y hace referencia a él a través de /proc/self/fd.

El exploit depende del cargador fat-JAR ejecutable de Spring Boot. Alibaba enumera los JAR simples, los uber-JAR genéricos y las implementaciones de Tomcat o Jetty WAR como no afectadas. Los puntos de entrada accesibles incluyen JSON.parse, JSON.parseObject(String)y JSON.parseObject(String, Class). Vincular la entrada a una clase fija no es suficiente cuando un objeto contiene una Object o Map campo donde se puede anidar la carga útil.

ThreatBook dijo el 22 de julio que su plataforma había capturado la explotación en estado salvaje después de agregar soporte de detección dos días antes. Sus resultados de laboratorio fueron más limitados: reprodujo la ejecución completa del código en un Spring Boot fat-JAR en JDK 8, mientras que su prueba Tomcat integrada produjo solo una búsqueda remota de JAR o una falsificación de solicitudes del lado del servidor.

Imperva reportado actividad contra servicios financieros, atención médica, informática, comercio minorista y otras organizaciones, principalmente en los Estados Unidos, con volúmenes más pequeños en Singapur y Canadá. Dijo que los imitadores de navegadores generaron la mayoría de las solicitudes, mientras que las herramientas Ruby y Go representaron alrededor del 30% en conjunto.

Ninguno de los proveedores publicó recuentos de ataques, solicitudes sin procesar, evidencia de ejecución, víctimas nombradas o compromisos confirmados. Sus informes establecen una actividad de explotación observada, no pruebas de una ejecución exitosa del código contra un objetivo del mundo real o una infracción.

un 23 de julio Evaluación CISA-ADP Sin embargo, marcó la explotación como none. The Hacker News confirmó el 25 de julio que la falla no estaba presente en el informe actual de CISA. Catálogo de vulnerabilidades explotadas conocidas. Las fuentes disponibles no explican el desajuste.

Ciberseguridad

The Hacker News tampoco encontró ningún artefacto Fastjson 1.x parcheado en el proyecto Etiquetas de GitHub o Repositorio central de Maven a partir del 25 de julio. La versión 1.2.83 sigue siendo la última versión estándar 1.x, mientras que 1.2.83_noneautotype sigue siendo la versión restringida disponible.

Las organizaciones deben inventariar las dependencias Fastjson directas y transitivas e inspeccionar los sistemas afectados en busca de sospechas. @type valores, URL JAR anidadas, conexiones salientes inesperadas, procesos secundarios, cambios de archivos y shells web. Fastjson2 no se ve afectado porque no utiliza la misma ruta de confianza basada en anotaciones o sondeo de recursos.

The Hacker News se comunicó con Alibaba para obtener aclaraciones sobre las versiones afectadas y los planes de parche Fastjson 1.x, y con Imperva para obtener detalles sobre la actividad de explotación reportada. Actualizaremos la historia con cualquier respuesta.

Fastjson 1.2.83 fue la actualización recomendada por Alibaba para una omisión de AutoType separada divulgada en 2022. Esa versión final 1.x ahora se encuentra dentro del rango afectado para CVE-2026-16723.

Investigador publica GitLab RCE PoC que permite a usuarios autenticados ejecutar comandos como Git – CYBERDEFENSA.MX

El investigador de seguridad Yuhang Wu en Depthfirst ha publicado un exploit de prueba de concepto (PoC) funcional que ejecuta comandos como git en un GitLab autoadministrado sin parches 18.11.3 servidor.

Un usuario autenticado normal lo activa confirmando dos cuadernos Jupyter diseñados y solicitando su diferencia. La cadena no necesita derechos de administrador, acceso al corredor de integración continua (CI), interacción con la víctima ni acceso al proyecto de otro usuario.

El exploit público es específico de GitLab. 18.11.3 en x86-64; los errores subyacentes de Oj afectan versiones más amplias. Las gamas afectadas son GitLab Community Edition (CE) y Enterprise Edition (EE). 15.2.0 a través de 18.10.7, 18.11.0 a través de 18.11.4y 19.0.0 a través de 19.0.1.

Las primeras versiones fijas son 18.10.8, 18.11.5y 19.0.2. Oj es un analizador JSON de alto rendimiento para Ruby con importante código C nativo.

Gemas publicadas 3.13.0 a través de 3.17.1 son vulnerables; 3.17.3 es la primera versión publicada que contiene ambas correcciones. Las fallas afectan a Free, Premium y Ultimate. Ruby en sí no se ve afectado.

Ciberseguridad

La explotación exitosa se ejecuta como git. Su alcance efectivo depende del aislamiento de la implementación, pero puede incluir código fuente, secretos de Rails, credenciales de servicio, datos de CI/CD y servicios internos accesibles desde la aplicación. GitLab.com fue parcheado el 10 de junio.

Los clientes dedicados no necesitan ninguna acción. Los operadores autogestionados deben pasar a una versión compatible que contenga la solución. Los usuarios de Helm y Operador deben verificar la versión de GitLab dentro de la imagen del servicio web, no solo el gráfico o la versión del Operador. Depthfirst dijo que no tenía conocimiento de explotación en estado salvaje hasta el 24 de julio.

Ni el primera revelación en profundidad ni las notas de la versión de GitLab del 10 de junio enumeran identificadores CVE o puntuaciones CVSS para los dos errores de la cadena. Ninguno de los dos proporciona una solución temporal; ambos dirigen a los operadores autogestionados a actualizarse.

Hacker News ha preguntado a GitLab sobre el estado, la clasificación y la evidencia de explotación de CVE. También preguntó en profundidad sobre la portabilidad de los exploits y si existe una mitigación temporal compatible. Las respuestas están pendientes. Depthfirst enumera nueve CVE para otras fallas del DO encontradas en la misma revisión.

El renderizador de portátiles de GitLab pasa controlado por el repositorio .ipynb JSON a Oj::Parser.usual.parse Dentro de un longevo trabajador de Puma. Eso envía datos del cuaderno controlado por el atacante al estado de analizador nativo de Oj dentro del proceso de solicitud de GitLab.

profundidad primero análisis técnico muestra cómo un error controla un puntero de devolución de llamada, mientras que el otro filtra una dirección de montón necesaria para limitar la búsqueda de aleatorización del diseño del espacio de direcciones (ASLR).

Oj almacena el estado de anidamiento en una pila fija de 1024 bytes, pero nunca comprueba si la profundidad la excede. Por lo tanto, los arreglos profundamente anidados pueden escribir 0x01 bytes en el estado del analizador adyacente. El exploit corrompe buf.headlo que hace que Oj pase un puntero interior falsificado a realloc(). Una asignación posterior de Ruby Array recupera la misma región jemalloc de 3584 bytes y sobrescribe p->start.

Oj asigna una clave de objeto de 65.565 bytes, trunca su longitud a 29 en un campo firmado de 16 bits y devuelve 29 bytes que contienen el puntero de asignación de claves en vivo. GitLab lleva ese puntero a la diferencia del cuaderno renderizado, dándole al exploit la fuga de dirección necesaria para limitar la búsqueda de ASLR. En el GitLab perfilado de dos trabajadores 18.11.3 instalación, la búsqueda solía tardar entre cinco y diez minutos. Los investigadores proyectaron de una a dos horas en el rango más amplio de trabajadores maduros.

Ciberseguridad

Dos archivos de cuaderno ordenados léxicamente en uno diffs_stream La solicitud mantiene ambas etapas dentro del mismo trabajador Puma, que reutiliza el analizador Oj de proceso global. El primer archivo corrompe la devolución de llamada y genera un error que GitLab detecta antes de continuar con la diferencia. El siguiente análisis invoca el puntero sobrescrito y llega system() a través de una secuencia de gadgets específica de la construcción.

El manifestación pública empaqueta la cadena en un GitLab local 18.11.3 laboratorio x86-64 y hace que el trabajador de Puma se conecte nuevamente como git.

Depth informó por primera vez los errores de Oj el 21 de mayo, y el mantenedor fusionó las correcciones el 27 de mayo. DO 3.17.3 enviado el 4 de junio. Los investigadores informaron sobre la cadena GitLab el 5 de junio; Depthfirst dijo que GitLab lo confirmó el 8 de junio.

GitLab lanzó las versiones fijas el 10 de junio y resolvió el informe el 17 de julio, según profundidadprimero. Una revisión de The Hacker News encontró que GitLab enumeró el DO 3.17.3 aparece debajo de las correcciones de errores en lugar de en la tabla de correcciones de seguridad y no describe la cadena RCE de diferencias del cuaderno.

Los agentes de Kimi K3 encontraron Redis Zero-Days y construyeron un exploit RCE, dicen los investigadores – CYBERDEFENSA.MX

Redis enviado siete comunicados de seguridad el 23 de julio después de que los investigadores publicaran PoC de RCE autenticados para el stock Redis 6.2.22, 7.4.9, 8.6.4 y 8.8.0.

Las cuatro cadenas requieren RESTAURAR. Las cadenas Streams también necesitan EVAL y XGROUP; la cadena 8.8.0 necesita EVAL y el módulo RedisBloom incluido. Redis dice que la memoria subyacente Las fallas pueden conducir a la ejecución remota de código..

Redis 6.2.23, 7.2.15 y 7.4.10 corrigen el uso después de la liberación de NACK compartido de Streams; Redis 8.2.8, 8.4.5 y 8.6.5 solucionan el problema de Streams y las escrituras fuera de límites de RedisBloom y TDigest; Redis 8.8.1 corrige los cargadores RedisBloom y TDigest, mientras que la protección Streams ya estaba presente en Redis 8.8.0.

Dos objetivos de PoC, Redis 6.2.22 y 7.4.9, fueron las actualizaciones de seguridad de mayo que Redis les dijo a los usuarios que instalaran, pero esas versiones no incluían la protección de propiedad NACK compartida.

Actualice a la versión fija para la rama implementada. Hasta entonces, revoque RESTORE de las cuentas que no lo necesiten estrictamente y bloquee el acceso a la red que no sea de confianza. Restringir RESTORE corta ambos caminos revelados.

Ciberseguridad

Ni las notas de la versión de Redis del 23 de julio ni el repositorios públicos de PoC revisó la explotación en estado salvaje reportada al 24 de julio de 2026.

Dos caminos a través de RESTORE

La ruta de Redis Streams es un error de propiedad compartida. Un objeto RDB corrupto puede hacer que dos consumidores apunten al mismo registro de entrada pendiente, por lo que eliminar a ambos consumidores libera el mismo objeto dos veces.

El script publicado está diseñado para convertir la corrupción de la memoria resultante en un acceso arbitrario a la memoria y, en última instancia, invocar el sistema().

La ruta de RedisBloom es una escritura fuera de límites en el cargador TDigest RDB. El cargador asignó memoria a partir de un valor serializado, pero confió en un campo de capacidad independiente controlado por el atacante al decidir cuántos datos cargar.

El script de Redis 8.8.0 está diseñado para convertir esa discrepancia en primitivas de lectura y escritura, filtrar direcciones de Redis y libc y llamar al sistema().

La cadena NACK compartida de Streams

El primer camino está en Redis Streams. Un objeto RDB corrupto puede hacer que dos consumidores apunten al mismo registro de entrada pendiente, representado internamente por un streamNACK. Quitar al primer consumidor libera el objeto y deja al segundo con un puntero colgando. Luego, los scripts también eliminan al segundo consumidor. Un trozo, dos gratis.

Notas de la versión de Redis 8.6.4 citar PR #15081. Pero una revisión de la fuente realizada por The Hacker News encontró que el etiquetado fuente 8.6.4 carece de la verificación de propiedad duplicada agregada por ese cambio. El guardia aparece en Redis 8.6.5lanzado el 23 de julio.

El script Redis 8.6.4 publicado está diseñado para convertir la doble liberación en acceso a memoria arbitrario y luego envenenar una función hash de base de datos para que un GET diseñado invoque system(). Restaura el puntero y comprueba si Redis todavía responde.

La cadena RedisBloom TDigest

La segunda ruta se encuentra en el cargador RedisBloom TDigest RDB. Asignó sus matrices de centroides a partir de un valor de compresión serializado y luego confió en un campo de capacidad separado controlado por el atacante al decidir cuántos nodos se podían cargar. Una pequeña asignación real combinada con metadatos inflados produce una escritura fuera de límites.

El Secuencia de comandos de Redis 8.8.0 está diseñado para convertir la escritura en primitivas de lectura y escritura, filtrar direcciones Redis y libc y envenenar una función hash de base de datos para que un GET diseñado llame al sistema(). A prueba de concepto separada publicó la misma causa raíz y una cadena RCE autenticada contra Redis 8.8.0.

Ciberseguridad

Redis arreglo de julio requiere que la capacidad TDigest cargada coincida con la asignación derivada del valor de compresión. También limita los contadores de nodos fusionados y no fusionados antes de leer las matrices.

Siete lanzamientos, ningún nuevo registro CVE

El repositorio considera que el problema de Streams es parte de una «familia de arreglos incompletos» CVE-2026-25589, pero Redis asigna ese CVE a la corrupción de memoria de RedisBloom durante la RESTAURACIÓN, no a la falla de NACK compartido de Streams. Las notas de la versión de julio de Redis no enumeran ninguna puntuación CVE o CVSS para ninguna de las nuevas clases de errores.

Hasta el 24 de julio, las búsquedas realizadas por The Hacker News no encontraron ningún registro NVD separado para los hallazgos compartidos de NACK o TDigest de julio. NVD todavía enumera los registros de mayo para CVE-2026-25243 y CVE-2026-25589. una búsqueda de Catálogo de vulnerabilidades explotadas conocidas de CISA no devolvió ninguna entrada para ninguno de los identificadores.

La divulgación sigue a otra falla de Redis RCE descubierta por IA y corregida en mayo. Amigos de Bera se describe a sí mismo como «Investigación de agentes de IA». chaofan shou dijo en X que los agentes de Kimi K3 encontraron 19 días cero de Redis en aproximadamente 90 minutos, y dijo otra carrera produjo el exploit Redis 8.8.0 en 27 minutos.

Esos recuentos, tiempos y el grado de autonomía reclamado siguen siendo autoinformados. El registro público de Redis confirma las fallas y las soluciona. No valida el recuento de días cero reclamado ni la independencia con la que trabajaron los agentes.

Redis 6.2.22 y 7.4.9 fueron el destino de mayo. En julio, ambos necesitaban otra actualización. Verifique la versión exacta de la rama, no si Redis fue simplemente «parcheado recientemente».

Golden Chickens resurge con cuatro nuevas familias de malware e implantes modulares – CYBERDEFENSA.MX

Los actores de amenazas detrás del ecosistema de malware como servicio (MaaS) de Golden Chickens han resurgido con cuatro nuevas familias de malware, lo que indica que los operadores no dan señales de detenerse a pesar de las amplias revelaciones públicas sobre su funcionamiento interno.

Las familias de malware en cuestión son: TinyEgg, ChonkyChicken, una variante modularizada de ChonkyChicken y una utilidad de robo de credenciales de navegador web modificada con nombre en código ChromEggscalator. Insikt Group de Recorded Future está rastreando al grupo bajo el nombre de TAG-195.

TAG-195 es un desarrollador de malware como servicio (MaaS) con motivación financiera cuyas herramientas se han vinculado previamente a TAG-127 como operador y cliente. La compañía de inteligencia de amenazas dijo que también observó a TAG-127 implementando TinyEgg a través de Campañas de ingeniería social estilo ClickFix que engañan a los usuarios desprevenidos para que ejecuten manualmente comandos maliciosos.

«Las cuatro nuevas familias indican una transición arquitectónica y una evolución en el ecosistema TAG-195 MaaS», dijo Recorded Future. «Las cuatro familias comparten un conjunto común de rasgos arquitectónicos: mecanismos consistentes de comando y control, un enfoque de persistencia compartido, ofuscación de cadenas y ejecución a través del mismo modelo de entrega».

Ciberseguridad

Una breve descripción de cada una de las herramientas es la siguiente:

  • TinyEgg, una puerta trasera ligera de acceso inicial que proporciona perfiles de host, acceso interactivo al shell y gestión de persistencia
  • ChonkyChicken, un implante con todas las funciones que amplía TinyEgg con robo de credenciales del navegador, control de sesión en vivo del navegador mediante el protocolo Chrome DevTools (CDP), ejecución remota respaldada por credenciales, reconocimiento de red y vigilancia sostenida.
  • Una versión modularizada de ChonkyChicken que introduce una arquitectura de controlador y complemento que permite al controlador solicitar y cargar 14 módulos de capacidad discretos según demanda en lugar de incorporar toda la funcionalidad en el implante.
  • ChromEggscalator, un sucesor de TerraStealerV2 y una versión modificada de una herramienta de omisión de cifrado de Chrome disponible públicamente llamada ChromElevator

El cambio es una señal de que Golden Chickens, también llamado Venom Spider, está refinando activamente su arsenal a través del desarrollo activo, mientras deliberadamente pasa a herramientas modulares impulsadas por operadores para la evasión de defensa.

Asociadas con una familia de malware llamada More_eggs, las herramientas del actor de amenazas han sido utilizadas por otros grupos de delitos cibernéticos como Cobalt Group (también conocido como Cobalt Gang), Evilnum y FIN6. Otro actor de amenazas asociado con Golden Chickens MaaS es TAG-127, que utiliza ClickFix o VenomLNK como métodos de entrega.

Se ha descubierto que las cadenas de ataque aprovechan los señuelos ClickFix para ejecutar cargas útiles OCX descargadas de la infraestructura de preparación controlada por el atacante, lo que resulta en la instalación de TinyEgg. La funcionalidad del malware se limita al acceso inicial y las funciones de creación de perfiles, y toda la capacidad posterior a la explotación se transfiere a ChonkyChicken. TinyEgg también está diseñado para finalizar la ejecución si se detectan entornos de pruebas y de análisis automatizados.

El malware establece conexiones con un servidor C2 utilizando WebSockets para facilitar un shell de comandos interactivo, ejecutar entradas proporcionadas por el operador a los comandos de sesión de shell activos, enviar la salida al controlador y preparar cargas útiles OCX.

Ciberseguridad

La versión modular de ChonkyChicken, por otro lado, admite 14 componentes diferentes que se obtienen de la infraestructura C2 según sea necesario, lo que permite a los operadores ofrecer selectivamente ciertas funciones sobre la marcha que las arquitecturas monolíticas de malware no pueden admitir fácilmente sin un mecanismo de actualización. Los 14 módulos permiten las siguientes funciones:

  • Gestión de procesos
  • Captura de pantalla y enumeración de monitores.
  • Manipulación de archivos
  • Ejecución de comando
  • Reconocimiento de red
  • Reconocimiento basado en dominios
  • Captura del portapapeles
  • Registro de teclas
  • captura de audio
  • Comprobación de tiempo de inactividad
  • Solicitud HTTP/S a través del host
  • Robo del navegador a través de ChromEggscalator
  • Gestión de persistencia

La versión modular también admite un módulo llamado «wtrack» cuyo propósito aún se desconoce. Esto sugiere la adición de una capacidad activa en desarrollo.

«Es casi seguro que la transición de TAG-195 a una arquitectura modular reduce la exposición a la detección estática del implante base y probablemente también refleja los incentivos comerciales inherentes al modelo MaaS, incluida la capacidad de proporcionar capacidades selectivamente a los operadores, limitar la exposición si un cliente se ve comprometido y atender una gama más amplia de requisitos operativos», dijo la compañía de ciberseguridad.