The Gentlemen RaaS utiliza el marco GentleKiller EDR dirigido a 400 procesos de seguridad – CYBERDEFENSA.MX

La operación Gentlemen ransomware-as-a-service (RaaS) está desarrollando y manteniendo activamente un conjunto de asesinos de detección y respuesta de puntos finales (EDR) que entrega a los afiliados para que deterioren las defensas del sistema antes de implementar el cifrado.

Esta cartera madura de herramientas de terminación de EDR se centra en un marco conocido como gentil asesino.

«También incorporan herramientas de terceros o filtradas como HexKiller, ThrottleBlood y HavocKiller», afirma el investigador de seguridad de ESET Jakub Souček. dicho en un informe compartido con The Hacker News. «Estas herramientas están estandarizadas a través de una capa de evasión de defensa compartida, haciéndose pasar predominantemente por proveedores de seguridad que utilizan información de versión falsa y certificados e íconos legítimos copiados».

La compañía eslovaca de ciberseguridad también criticó al equipo de ransomware por su capacidad para «poner en funcionamiento inusualmente rápido» exploits de prueba de concepto (PoC) recientemente revelados relacionados con una técnica de ataque llamada técnica de «traiga su propio controlador vulnerable» (BYOVD), en muchos casos a los pocos días de su lanzamiento público.

Desde su aparición en marzo de 2025, The Gentlemen ha ascendido rápidamente de rango y se ha hecho un nombre como uno de los grupos de ransomware más activos. Según datos de Ransomware.live, el grupo ha afirmado 504 víctimas hasta la fechay la mayoría de ellos están ubicados en el sudeste asiático, América del Sur y Europa occidental.

Ciberseguridad

Informes recientes del periodista de ciberseguridad Brian Krebs y PRODAFT han revelado que un ciudadano ruso de 36 años llamado Alexander Andreevich Yapaev (alias hastalamuerte) ha estado liderando la operación, después de actuar como afiliado de otros esquemas de ransomware, incluido Qilin.

ESET ha descrito a The Gentlemen como uno de los grupos RaaS técnicamente más ágiles, utilizando un conjunto de técnicas para garantizar que las muestras asesinas de EDR compiladas eviten la detección. Esto incluye protección binaria usando Enigma o Themida y el uso de nombres de archivos que se asemejan a proveedores de ciberseguridad conocidos, hasta la información de su versión, firmas digitales e íconos.

El más frecuente de ellos es GentleKiller, que viene en ocho variantes diferentes, cada una de las cuales imita un producto legítimo diferente y abusa de un controlador vulnerable o malicioso diferente como parte del ataque BYOVD. GentleKiller busca específicamente 400 procesos asociados con 48 programas de seguridad distintos de varios proveedores.

La lista de controladores explotados por cada una de las variantes es la siguiente:

  • Kaspersky («eb.sys»)
  • FACEIT Anti-Cheat («nseckrnl.sys»)
  • Valorante («GameDriverX64.sys»)
  • Javelin («stpm_old.sys» o «stpm_new.sys»)
  • Perro guardián («dmx.sys»)
  • Bloqueador de red («360netmon_wfp.sys»)
  • Limpiador («IMFForceDelete.sys»)
  • G11 («PoisonX.sys»)

Vale la pena señalar que en los últimos meses se ha registrado un abuso de «PoisonX.sys» en relación con varios ataques BYOVD, uno de los cuales fue utilizado para matar CrowdStrike Falcon EDR. Una segunda campaña, detallado de Huntress, implicó una intrusión en la que actores de amenazas desconocidos aprovecharon BeyondTrust Remote Support para implementar con éxito ransomware en la red, no sin antes finalizar las herramientas de seguridad a través de «PoisonX.sys» y «hrwfpdrv.sys».

«Al abstraer la capa de suplantación y los controladores específicos utilizados, el código subyacente revela numerosos puntos en común estructurales y de comportamiento que sugieren fuertemente el uso de una plantilla de desarrollo compartida», dijo Souček.

«Este diseño prioriza la facilidad de implementación y la flexibilidad operativa para los afiliados, al tiempo que minimiza el esfuerzo de desarrollo para los operadores. Permite a los operadores de The Gentlemen integrar controladores maltratados en su conjunto de herramientas muy poco después de que se revela una PoC asesina de EDR».

Los asesinos de EDR externos basados ​​en BYOVD empleados por el grupo se encuentran a continuación:

  • HexKiller («googleApiUtil64.sys»), una herramienta que anteriormente se suponía era exclusiva de la banda de ransomware Warlock
  • ThrottleBlood («ThrottleBlood.sys»), una herramienta observada en ataques organizados por afiliados de MedusaLocker y DragonForce
  • HavocKiller o HwAudKiller («havoc.sys»)

ESET dijo que también detectó un ladrón de credenciales basado en Rust con nombre en código OxideHarvest (también conocido como buildx641) que es capaz de recopilar datos de navegadores web populares, incluidos Google Chrome, Microsoft Edge, Torch, Comodo, Epic Privacy Browser, Vivaldi, Brave, Opera, OperaGX, Mozilla Firefox, Waterfox, BlackHawk y IceCat.

Ciberseguridad

«Si bien la mayoría de las bandas de ransomware continúan delegando la eliminación de EDR a sus afiliados, Gentlemen ha optado por centralizar esta función ofreciendo a los afiliados una suite de eliminación de EDR estandarizada y lista para usar», dijo ESET. «Esta decisión convierte a Gentlemen en un operador atractivo para los afiliados, ya que reduce sustancialmente la barrera de entrada para ellos y, en consecuencia, facilita su trabajo».

La divulgación se produce cuando el Centro de Coordinación CERT (CERT/CC) emitió un aviso sobre múltiples aplicaciones UEFI firmadas por proveedores que son vulnerables a la omisión de arranque seguro a través de un ataque BYOVD. Al investigador de ESET, Martin Smolár, se le atribuye la investigación y el informe de la vulnerabilidad. Las aplicaciones afectadas son de Acer, AMD, ASUS, ECS, Getac, GIGABYTE, Toshiba y Uniwill.

«Si un sistema objetivo confía en el certificado del proveedor afectado, un atacante [with administrative privileges or physical access] puede explotar estas aplicaciones para ejecutar código arbitrario durante la fase inicial previa al arranque antes de que se inicialice el sistema operativo», dijo CERT/CC.

«Para mitigar este riesgo, los administradores del sistema deben aplicar actualizaciones a la base de datos de firmas prohibidas (DBX) UEFI que revoquen la confianza en los archivos binarios firmados por el proveedor afectados, evitando que estas aplicaciones vulnerables se ejecuten durante el proceso de arranque».

El exploit ‘usbliter8’ que no se puede reparar rompe la cadena de arranque SecureROM de Apple A12 y A13 – CYBERDEFENSA.MX

Los investigadores de seguridad de Paradigm Shift han publicado un exploit funcional, denominado usbliter8que logra la ejecución de código arbitrario dentro de la SecureROM de los chips A12 y A13 de Apple.

Ese código se graba en el silicio durante la fabricación. Ninguna actualización de software puede alcanzarlo. Los dispositivos afectados conservarán este defecto mientras permanezcan en uso.

Este no es un ataque remoto. Requiere posesión física del dispositivo, que debe estar en modo DFU y conectado mediante USB a una placa de microcontrolador dedicada basada en RP2350. Con esa configuración, el exploit finaliza en menos de dos segundos, antes de que se cargue la cadena de arranque firmada por Apple.

el completo redacción técnica y un trabajo prueba de concepto se hizo público el 18 de junio de 2026, luego de una divulgación coordinada con Apple Product Security.

Dispositivos afectados

La PoC pública admite SoC A12, A13, S4 y S5. La compatibilidad con A12X y A12Z se describe como teóricamente posible pero aún no implementada.

Ciberseguridad

Las familias de dispositivos en ese rango incluyen iPhone XS, XS Max y XR; el iPhone 11, 11 Pro, 11 Pro Max; el iPhone SE (segunda generación); el iPad Air de 3.ª generación, el iPad mini de 5.ª generación y el iPad de 8.ª generación; Apple Watch Series 4 y 5; el Apple Watch SE de primera generación; el HomePod mini; y otros productos Apple construidos con esos chips. A11 no se ve afectado. A14 y posteriores parecen estar fuera del alcance de esta ruta de explotación.

El error

La raíz del problema es una falla de hardware en el controlador USB Synopsys DWC2.

El controlador almacena los paquetes de configuración USB entrantes a través de DMA, almacena en buffer hasta tres y luego restablece su puntero de escritura en el cuarto disminuyéndolo en 24 bytes fijos. También acepta paquetes más pequeños que los estándar, incrementando el puntero sólo por los bytes reales escritos. Esa falta de coincidencia se acumula en un desbordamiento repetible del búfer, lo que hace que el puntero de escritura retroceda a través de la memoria 12 bytes a la vez.

Lo que hace que esto sea explotable en A12 y A13 es cómo Apple configura el USB DART (Tabla de resolución de direcciones del dispositivo, IOMMU del chip) dentro de SecureROM. En los dispositivos afectados, se ejecuta en modo bypass, por lo que el puntero DMA insuficiente puede alcanzar y sobrescribir SRAM arbitraria.

A11 no se ve afectado porque su controlador USB restablece manualmente la dirección DMA después de cada paquete, por lo que la falta de coincidencia nunca se acumula. A14 y posteriores parecen configurar DART correctamente, lo que, según Paradigm Shift, hace que la vulnerabilidad no se pueda explotar en hardware más nuevo.

Obtener la ejecución del código

En A12, el búfer DMA se encuentra junto a la pila de tareas USB en el montón. Sobrescribir un registro de enlace guardado le da al programa atacante el control del contador en el siguiente cambio de contexto.

A13 es más difícil. La autenticación de puntero (PAC) protege las direcciones de retorno almacenadas en la pila. Paradigm Shift lo pasó por alto por etapas. La corrupción de estructuras de montón relacionadas con DART creó primitivas de escritura limitadas. Al sobrescribir el contador de profundidad del pánico, el chip se repitió ante errores en lugar de reiniciarse. La sincronización cuidadosa de la escritura DMA evitó dañar los registros guardados de la tarea USB.

El último paso sobrescribió el puntero del controlador de interrupciones USB en BSS. La siguiente interrupción del USB ejecutó el código proporcionado por el atacante. Cualquiera de las rutas termina con la ejecución en EL1, el modo privilegiado del chip, dentro de SecureROM.

Lo que obtiene un atacante

Después de la explotación, usbliter8 inyecta un controlador de solicitudes USB personalizado y marca PWND:[usbliter8] en la cadena serie USB del dispositivo. A partir de ahí, un atacante puede degradar temporalmente el modo de producción del SoC o iniciar una imagen de iBoot sin firmar y sin verificación de firma, saliendo por completo de la cadena de confianza de Apple.

La investigación no muestra un compromiso de Secure Enclave. Secure Enclave de Apple está diseñado como un límite de protección independiente, aislado del procesador de aplicaciones. Paradigm Shift advierte que el control a nivel de BootROM puede abrir nuevas rutas para atacarlo.

Sin parche de software

El precedente público más cercano es checkm8, el exploit SecureROM de 2019 que dejó permanentemente los dispositivos A5 a A11 fuera de la autoridad de parches de Apple.

Ciberseguridad

Al igual que checkm8, usbliter8 requiere acceso físico y modo DFU y no se puede cerrar con una actualización de firmware. usbliter8 extiende esa condición a la próxima generación de chips.

Hasta el 19 de junio de 2026, no se había emitido ningún CVE, puntuación CVSS, aviso de seguridad de Apple ni alerta CISA, y no se había informado públicamente de ninguna explotación en estado salvaje.

Para la mayoría de los usuarios, el riesgo práctico es bajo: un atacante necesita el dispositivo físico, el cable adecuado y el conocimiento para forzar el modo DFU. Para entornos de alta seguridad, esto ahora es un problema de retirada de hardware y custodia de dispositivos.

Si un dispositivo ejecuta uno de los chips afectados, el límite físico desaparece permanentemente; la seguridad depende de controlar cuándo y dónde se puede conectar el dispositivo. Haga un inventario del hardware A12, A13, S4 y S5 en roles sensibles, priorice las actualizaciones hacia A14 o más reciente y evite el modo DFU sobre cables o hosts USB que no sean de confianza.

El código es público. Por lo general, así es como la investigación de exploits deja de ser una demostración y comienza a ser la herramienta de otra persona.

El ataque AutoJack permite que una página web secuestre al agente de IA para la ejecución del código del host – CYBERDEFENSA.MX

Los investigadores de Microsoft han detallado una cadena de exploits, denominada AutoJackque convierte un agente de navegación de IA en un vehículo de entrega para la ejecución remota de código.

Dirige al agente para que cargue la página web de un atacante, y el JavaScript de esa página puede llegar a un servicio local privilegiado en la misma máquina y generar un proceso en el host.

Sin credenciales, sin pantalla de inicio de sesión y sin más interacción del usuario una vez que el agente carga la página. El atacante sólo tiene que lograr que el agente lo abra, y un enlace colocado, un campo URL o una inyección rápida serán suficientes.

El defecto se encuentra en Estudio AutoGenla interfaz de creación de prototipos de código abierto para el marco multiagente AutoGen de Microsoft Research. Este no es un error que afecta a todos los que instalan el paquete, y vale la pena corregir los detalles del paquete.

Un autogenstudio de instalación de pip simple extrae la versión estable actual, 0.4.2.2, la compilación que Microsoft inspeccionó, y no tiene ninguna ruta de protocolo de contexto modelo (MCP).

Esa es la base de la declaración de Microsoft de que la superficie vulnerable MCP WebSocket «nunca se incluyó en una versión de PyPI». Es válido para la construcción estable. Pero el controlador vulnerable se envió a PyPI, en dos versiones preliminares, 0.4.3.dev1 y 0.4.3.dev2.

Ciberseguridad

The Hacker News descargó e inspeccionó ambos. La ruta MCP WebSocket está presente, el controlador toma el comando para ejecutarlo directamente desde la solicitud y no autentica a la persona que llama. Ninguna construcción ha sido eliminada.

pip no instala versiones preliminares a menos que pase –pre o fije la versión, por lo que nunca se expuso una instalación simple. Cualquiera que haya instalado una de esas versiones preliminares lo fue. Todavía no existe una compilación de PyPI que lleve el refuerzo de la rama principal para ellos; el código fijo está en GitHub principal en la confirmación b047730.

Como funciona la cadena

AutoJack encadena tres debilidades en el MCP WebSocket.

Primero, el socket confiaba en localhost, una verificación destinada a bloquear un navegador normal que apunta a un sitio malicioso. Pero un agente de navegación que se ejecuta en el mismo cuadro es localhost, por lo que todo lo que carga hereda esa identidad de localhost y pasa la verificación.

En segundo lugar, el middleware de autenticación omitió las rutas de MCP suponiendo que el controlador verificaría los tokens por sí mismo. Nunca lo hizo, por lo que el socket aceptó conexiones no autenticadas independientemente del modo de autenticación configurado.

En tercer lugar, el punto final tomó un comando directamente de un parámetro de solicitud y lo ejecutó, sin una lista de permitidos en la que se pudiera iniciar el ejecutable.

En conjunto, una página en Internet abierta, representada por un agente local, podría ejecutar un comando elegido por el atacante en la cuenta que ejecuta AutoGen Studio.

Microsoft describe esto como una investigación, no como una campaña activa, y no informó ninguna explotación en la naturaleza. La prueba de concepto utilizó un agente «Resumen de contenido web» que, cuando se alimenta con una URL del atacante, muestra calc.exe en el escritorio del desarrollador, iniciado por el proceso AutoGen Studio.

Microsoft informó del comportamiento al Centro de respuesta de seguridad de Microsoft y los mantenedores reforzaron la rama principal en cometer b047730 (PR #7362). El controlador fijo ya no lee el comando de la URL; Los parámetros se almacenan en el lado del servidor detrás de una ID de sesión única y las ID desconocidas se rechazan. Las rutas MCP ahora pasan por la ruta de autenticación normal. Ese endurecimiento aún no ha llegado a una versión de PyPI.

que hacer

Una simple instalación de pip en autogenstudio le proporciona 0.4.2.2, que no tiene ruta MCP, por lo que no se ve afectado.

Si instaló una versión preliminar, tiene el controlador vulnerable y no tiene una compilación de PyPI parcheada a la que trasladarse. Extraiga de GitHub principal en o después de la confirmación b047730. Esa es la verdadera solución.

Ciberseguridad

Hasta que haya una liberación, separe las piezas que necesita el ataque. No ejecute AutoGen Studio en la misma máquina que un agente de navegación o ejecución de código que toque contenido que no sea de confianza, porque la cadena solo funciona cuando ambos comparten el mismo host local. Si tienen que ejecutarse juntos, aíslelos en contenedores o máquinas virtuales separados y ejecute AutoGen Studio con una cuenta con pocos privilegios.

Los errores de AutoGen Studio están parcheados en la fuente. El patrón no lo es. Microsoft espera la misma forma en otros marcos de agentes: un servicio local con demasiada potencia, una verificación del host local tratada como seguridad y un agente que abre páginas que no son de confianza.

THN lo vio el mes pasado en ChatGPhish, donde los resúmenes de páginas de ChatGPT se convirtieron en un vector de phishing. Microsoft presentó un argumento similar sobre el host local en su Investigación del núcleo semántico RCErastreado como CVE-2026-26030 y CVE-2026-25592.

Otra verificación de localhost no es suficiente. Autentique el plano de control, mantenga la ejecución del proceso detrás de una lista de permitidos y proporcione al agente una identidad que no sea la propia sesión del desarrollador. Una vez que un agente puede navegar por la web abierta y acceder a servicios locales privilegiados, localhost ya no es un límite de confianza.

CISA advierte a los clientes de Fortinet que FortiBleed llega a 86.644 dispositivos FortiGate – CYBERDEFENSA.MX

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) el jueves instado Los clientes de Fortinet con dispositivos FortiGate deben tomar medidas para protegerse contra la actividad maliciosa continua dirigida a miles de dispositivos con acceso a Internet.

La amplia campaña, que se cree que es obra de actores de amenazas de habla rusa, ha recibido el nombre en código FortiBleed. El número de dispositivos comprometidos asciende a 86.644 al 19 de junio de 2026.

Según datos de SOCRadar, las cuentas de administrador genéricas (35%) y las cuentas integradas del sistema Fortinet (28,3%) juntas constituyen la mayoría de las credenciales comprometidas. Las cuentas específicas de la organización representan el 36,7% de las credenciales violadas restantes.

«Esto apunta directamente a una falla generalizada a la hora de cambiar el nombre de las cuentas predeterminadas o rotar las credenciales de fábrica, dando al atacante una lista de objetivos altamente confiable antes de que fuera necesaria cualquier fuerza bruta», dijo SOCRadar.

«Las cuentas específicas de organizaciones que encabezan la lista son significativas. Significa que el atacante no solo está recopilando credenciales predeterminadas sino que también ha comprometido con éxito cuentas creadas por las propias organizaciones, posiblemente provenientes de infracciones anteriores donde las contraseñas nunca se cambiaron».

Las telecomunicaciones, el gobierno y la educación se han convertido en los tres sectores más afectados, con la mayor exposición ubicada en India, Estados Unidos, México, Colombia y Tailandia.

Ciberseguridad

Se dice que el actor de amenazas escaneó masivamente Internet en busca de puntos finales de inicio de sesión remoto de Fortinet y luego empleó una herramienta personalizada para rociar esos puntos finales identificados con combinaciones conocidas de inicio de sesión y contraseña en un intento de ingresar a ellos.

El ataque totalmente automatizado se basa en un enfoque autosostenible de dos pasos:

  • El actor de amenazas intenta obtener una lista seleccionada de contraseñas de Fortinet filtradas en dispositivos a través de Internet.
  • Una vez obtenido el acceso, monitorean pasivamente el tráfico de red que pasa por los dispositivos para recopilar credenciales adicionales, que luego se utilizan para comprometer más dispositivos.

Las credenciales son legítimas y válidas, y los atacantes verifican cada una de ellas antes de agregarlas a una base de datos de inicios de sesión confirmados y funcionales.

«La magnitud de esta brecha afecta a casi todos los sectores de la economía global, sin escatimar a ninguna industria», Hudson Rock dicho. «Los actores de amenazas han creado una base de datos verificada de credenciales de trabajo para algunas de las empresas más grandes del planeta».

El Centro Nacional de Seguridad Cibernética del Reino Unido (NCSC) ha descrito FortiBleed como una campaña global dirigida a firewalls Fortinet y puertas de enlace VPN de Internet utilizando métodos como fuerza bruta, ataque de diccionario y relleno de credenciales.

Se sospecha que los actores de la amenaza probablemente explotaron mecanismos de hash de credenciales más antiguos y la forma en que históricamente se han almacenado las credenciales dentro de los archivos de configuración de FortiGate para llevar a cabo el ataque a gran escala.

«Fortinet introdujo el hash de contraseñas basado en PBKDF2 para las credenciales de administrador en FortiOS 7.2.11, 7.4.8 y 7.6.1, reemplazando el mecanismo de almacenamiento heredado basado en SHA-256», Arctic Wolf dicho. «Sin embargo, al actualizar desde versiones anteriores, las contraseñas de administrador existentes permanecen almacenadas como hashes SHA-256 hasta que el administrador correspondiente inicie sesión exitosamente después de la actualización».

«Como resultado, es probable que muchas organizaciones continúen almacenando credenciales de administrador utilizando SHA-256 más antiguo con mecanismos de hash de Salt».

Ciberseguridad

En una declaración compartida con The Hacker News, un portavoz de Fortinet dijo que «los datos involucrados probablemente sean un intercambio de datos de incidentes anteriores, así como fuerza bruta de credenciales, y no están relacionados con ningún incidente o aviso actual», instando a las organizaciones a seguir las mejores prácticas, incluida la rotación periódica de credenciales de seguridad y la habilitación de la autenticación multifactor (MFA).

CISA ha esbozado las siguientes recomendaciones para defenderse de la actividad:

  • Termine todas las sesiones administrativas y VPN SSL activas, restablezca todas las contraseñas administrativas y VPN de Fortinet, especialmente en sistemas con acceso a Internet, y aplique políticas de contraseñas seguras.
  • Asegúrese de utilizar la función de derivación de clave basada en contraseña 2 (PBKDF2) algoritmo para almacenar credenciales de administrador y eliminar hashes heredados más débiles.
  • Revise los registros de firewall, VPN, autenticación y controlador de dominio para detectar signos de acciones sospechosas, incluidos cambios de configuración no autorizados.
  • Habilite MFA resistente al phishing en todas las puertas de enlace externas e interfaces administrativas.
  • Reduzca la superficie de ataque y bloquee la gestión.

El incidente de FortiBleed salió a la luz por primera vez la semana pasada después de que el investigador de seguridad Volodymyr «Bob» Diachenko descubriera un servidor que contenía la base de datos de credenciales de inicio de sesión en funcionamiento para miles de firewalls y puertas de enlace VPN en 194 países. Según SOCRadar, el servidor también organizó las herramientas y los scripts de automatización del atacante.

Los hallazgos demuestran una vez más cómo la reutilización de credenciales y la mala higiene de las contraseñas pueden ser utilizadas como armas por actores maliciosos, sin mencionar que los dispositivos de seguridad perimetral siguen siendo un objetivo lucrativo para obtener acceso inicial a entornos empresariales.

La operación Endgame interrumpe los servidores de SocGholish y limpia 14.971 sitios de WordPress – CYBERDEFENSA.MX

Las autoridades policiales holandesas, junto con sus homólogas de Canadá Alemania y EE. UU. han interrumpido la infraestructura maliciosa asociada con SocGholish y han limpiado casi 15.000 sitios web infectados de WordPress.

«Con estas acciones privamos a los ciberdelincuentes del acceso a sistemas informáticos infectados», Maikel Rollman, de la Unidad Nacional de Delitos de Alta Tecnología de los Países Bajos. dicho.

«Esto evita mayores daños a los sistemas digitales de ciudadanos, empresas y organizaciones de todo el mundo y limita la propagación de malware. También reduce el riesgo de que estos sistemas se utilicen para ciberataques a infraestructuras críticas y otros procesos sociales esenciales. Esto marca el comienzo de nuevas acciones contra SocGholish».

El derribo es parte de Operación finaluna iniciativa internacional en curso de aplicación de la ley para combatir las botnets y las infraestructuras criminales asociadas. Fue lanzado en 2024.

Como parte del esfuerzo, 106 servidores vinculados a SocGholish han sido desactivados y 14.971 sitios de WordPress han sido eliminados de las infecciones. Se ha notificado a los propietarios de sitios web para que actualicen su sistema de gestión de contenidos (CMS), cambien sus credenciales y eliminen cualquier cuenta sospechosa.

Activo desde 2017 y también conocido como FakeUpdates, SocGholish es un malware de descarga basado en JavaScript (JS) que normalmente sirve como conducto para el malware de siguiente etapa de varios actores de amenazas como Evil Corp (también conocido como DEV-0243, Indrik Spider y UNC2165), LockBit, RansomHub, Dridex y Raspberry Robin (también conocido como Roshtyak).

Ciberseguridad

Se distribuye a través de sitios web comprometidos haciéndose pasar por actualizaciones engañosas para navegadores web como Google Chrome o Mozilla Firefox y otro software popular. Los operadores del malware han sido rastreados bajo varios alias, como Gold Prelude, Mustard Tempest, Purple Vallhund, TA569 y UNC1543.

«Las infecciones de SocGholish normalmente se originan en sitios web comprometidos que han sido infectados de múltiples maneras diferentes», señaló Silent Push en un análisis del malware el año pasado. «Las infecciones de sitios web pueden implicar inyecciones directas, donde la entrega de carga útil de SocGholish inyecta JS cargado directamente desde una página web infectada o mediante una versión de la inyección directa que utiliza un archivo JS intermedio para cargar la inyección relacionada».

En noviembre de 2025, el lobo ártico reveló que los actores de amenazas de RomCom estaban utilizando SocGholish para entregar el Agente Mítico, destacando el uso de los servicios del intermediario de acceso inicial por parte de una amplia gama de actores con diversas motivaciones.

Sitios de WordPress comprometidos con SocGholish geolocalizados por IP por país

Orange Cyberdefense dijo que ha observado infecciones de SocGholish que entregan cargadores como Gholoader (otro cargador basado en JavaScript) y MintsLoader, que, a su vez, conducen al despliegue de cargas útiles adicionales como GhostWeaver, LockBit, AsyncRAT y NetSupport RAT.

«SocGholish utiliza un modelo de entrega en capas y se ha observado que permite múltiples categorías de cargas útiles de seguimiento», la empresa de ciberseguridad. dichoy agrega que el actor de amenazas también colabora con operadores de sistemas de distribución de tráfico (TDS) como TA2726.

Muchas de las instancias comprometidas de WordPress han sido modificadas para incluir infraestructura criminal operada por SocGholish, según la Fundación Shadowserver. La gran mayoría de los sitios pirateados estaban ubicados en Estados Unidos, seguidos por Alemania, Francia, India, Brasil, Singapur, Italia, Indonesia, Canadá y Vietnam.

«El abuso también incluye el uso de un proceso conocido como ‘Domain Shadowing’», dijo la organización sin fines de lucro. dicho. «Esta es una técnica en la que un actor de amenazas obtiene acceso al proveedor de DNS autorizado o al panel de cuenta del registrador para un dominio legítimo, y utiliza su acceso para crear silenciosamente subdominios adicionales debajo del dominio principal (‘apex’)».

«Estos subdominios maliciosos a menudo reciben nombres de host comunes que se ocultan a simple vista y se mezclan con la infraestructura DNS legítima del propietario del dominio, pero apuntarán a una infraestructura maliciosa externa operada por delincuentes, aprovechando efectivamente la reputación establecida de un dominio y dificultando que los defensores detecten o bloqueen fácilmente actividades ilícitas».

Una vista simplificada de los afiliados que llevan a las víctimas potenciales a SocGholish

Es más, los sitios web infectados con frecuencia son explotados por múltiples actores de amenazas, exponiendo a los visitantes desprevenidos del sitio a un sofisticado grupo de amenazas potenciales. El comportamiento malicioso exhibido por estos sitios está dictado por varios factores cruciales, incluido el país de origen del usuario, el tipo de navegador utilizado y el sistema operativo subyacente.

«TA569 compromete sitios web indiscriminadamente y es oportunista, aunque los sitios con mayor tráfico generan más víctimas», Proofpoint dicho. «El actor también ha comprometido sitios web en prácticamente todas las industrias, desde organizaciones sin fines de lucro y escuelas, hasta atención médica y hospitales, pasando por organizaciones legales y de bienes raíces».

La firma de inteligencia de amenazas DNS Infoblox describió a SocGholish como un marco JavaScript de múltiples etapas que convierte sitios web comprometidos en vehículos de entrega de malware de descarga automática. El marco está habilitado por cuatro pasos principales: adquisición de tráfico, filtrado de tráfico, señuelos de carga útil y ejecución de implante en el dispositivo.

Ciberseguridad

«TA569 compromete un gran número de sitios web», afirma. dicho. «Pero también aceptan tráfico de afiliados. Es una relación comercial clásica: cuando un usuario visita el sitio, el afiliado generalmente les toma las huellas digitales y luego pasa a las víctimas potenciales a SocGholish a través de un enlace integrado. A cambio, el afiliado recibirá un pago por estos ‘clientes potenciales’».

Algunos de los afiliados destacados que han vendido tráfico al marco SocGholish a lo largo de los años incluyen TA2726, Parrot TDS y JunkyTDS. Los actores de amenazas también han empleado ofertas comerciales como Keitaro y zTDS para filtrar el tráfico y redirigirlo a SocGholish, o enviarlo al sitio web original o cualquier otro contenido si el visitante del sitio comprometido no cumple con los criterios.

Los datos de Infoblox muestran que aproximadamente el 55% de sus clientes de la nube intentaron acceder a la infraestructura de SocGholish solo este año, y los ataques se dirigieron a casi «todos los sectores industriales» durante los últimos cinco meses. Algunas de las verticales más específicas incluyeron gobierno, educación, banca, atención médica, servicios no relacionados con TI, servicios financieros, consultoría de TI, servicios públicos, seguros y transporte.

«Esta distribución […] «Refuerza que SocGholish no es una amenaza de nicho limitada a una vertical», dijo la compañía. «En cambio, su ecosistema TDS y webinject a gran escala llega tanto al sector público como a entornos comercialmente importantes, lo que lo convierte en una amenaza ampliamente relevante en toda nuestra base de clientes».

El cambio de IA que está redefiniendo la gestión de amenazas – CYBERDEFENSA.MX

Introducción

El equipo de seguridad empresarial promedio tiene 40 o más herramientas de seguridad, lo que brinda mucha visibilidad de la telemetría interna y los datos de activos. Pero a menudo, estas herramientas funcionan en silos, generando alertas y datos (superpuestos). Y, sin embargo, los tiempos de permanencia de las infracciones siguen siendo obstinadamente largos (~43 días), las ventanas de respuesta siguen cerrándose antes de que los equipos puedan actuar y los analistas eliminan el ruido de clasificación en lugar de detener las amenazas.

El problema no es el esfuerzo. Es arquitectura.

Los programas de seguridad se crearon para un mundo donde las amenazas se movían lo suficientemente lentamente como para que los humanos coordinaran las respuestas manualmente. Ese mundo ya no existe. Con la forma en que se desarrollan y utilizan las capacidades de IA, especialmente con herramientas de IA de vanguardia, se necesita una postura de seguridad mucho más proactiva, así como una respuesta de velocidad de las máquinas para combatir a los adversarios que se mueven rápidamente. El marco de Gestión Continua de la Exposición a Amenazas (CTEM) de Gartner ayuda a este cambio de evaluaciones reactivas en un momento dado a un ciclo continuo e iterativo de alcance, descubrimiento, priorización, validación y movilización. Pero para la mayoría de las organizaciones, poner en funcionamiento CTEM de extremo a extremo sigue estando fuera de su alcance, porque las herramientas necesarias para hacerlo aún no se comunican entre sí.

El problema de la arquitectura detrás de cada brecha de seguridad

Las pilas de seguridad modernas son colecciones de herramientas especializadas: una plataforma de inteligencia de amenazas por aquí, un escáner de vulnerabilidades por allá, una herramienta BAS (simulación de ataques e infracciones) separada y un SIEM que intenta unirlo todo. Cada uno genera datos. Ninguno de ellos cierra el círculo.

Cuando se correlaciona la inteligencia, se priorizan las exposiciones, se ejecuta la validación y se actúa sobre un ticket de remediación, el adversario a menudo ya se ha movido. El cuello de botella no es una única herramienta. Es el espacio en blanco entre ellos.

Este es el problema de arquitectura que mantiene despiertos a los líderes de seguridad, y es el que los asistentes genéricos de IA, incorporados a los flujos de trabajo existentes, en realidad no resuelven. Es útil pedirle a un chatbot que resuma un informe de amenazas. No es lo mismo que tener un sistema de inteligencia artificial que correlaciona de forma autónoma ese informe con su superficie de exposición en vivo, valida si sus controles se mantienen y prioriza qué arreglar primero.

Qué significa realmente «agentic» y por qué es importante ahora

El término «IA» se ha sobrecargado tanto en el marketing de seguridad que vale la pena ser precisos sobre lo que realmente significa IA agente en este contexto.

La IA asistida espera que se la pidan. Resume, traduce y recupera. Hace que los analistas hagan más rápido las mismas cosas que ya estaban haciendo.

La IA agente actúa. Entiende el contexto, establece prioridades de forma autónoma y ejecuta flujos de trabajo de varios pasos en todos los sistemas, no como una consulta única, sino de forma continua, en segundo plano, a la velocidad de la máquina.

La distinción es importante porque el entorno de amenazas también opera cada vez más a la velocidad de la máquina. Con los rápidos avances en los modelos de IA de vanguardia, los plazos desde el descubrimiento hasta la explotación se están reduciendo significativamente. Los equipos de seguridad que se mantengan a la cabeza no serán los que tengan más analistas. Serán ellos aquellos cuya infraestructura de IA pueda igualar ese ritmo de forma autónoma.

Específicamente para CTEM, esto significa que tres funciones deben dejar de ser flujos de trabajo separados:

  1. Operacionalización de la inteligencia sobre amenazas: ingesta, estructuración y contextualización continua de datos sobre amenazas, exposición y vulnerabilidad en su entorno. Entender qué los adversarios están haciendo y cual Los activos y la infraestructura están potencialmente expuestos a esos riesgos.
  2. Probar y validar su postura de seguridad: probar continuamente si sus controles, equipos y procesos realmente resisten los comportamientos adversarios que está rastreando.
  3. Movilización de respuesta: priorizar y enrutar automáticamente acciones de remediación basadas en evidencia y riesgos validados e impulsados ​​por inteligencia.

Cuando esas tres funciones operan como un circuito cerrado, con agentes de IA moviendo información y decisiones entre ellos sin esperar transferencias humanas, un programa CTEM deja de ser un marco sobre una diapositiva y comienza a ser una realidad operativa.

IA agente para operacionalizar CTEM y la seguridad proactiva

Una arquitectura de gestión de amenazas Agentic es lo que marca la diferencia entre un marco CTEM que reside en un documento de estrategia y uno que se ejecuta continuamente en segundo plano. Esto requiere una capa de orquestación de IA dedicada que actúe como una capa contextual fundamental con agentes interconectados. En lugar de que los analistas conecten manualmente la inteligencia sobre amenazas con la validación de la exposición, los agentes hacen el trabajo pesado de forma continua y con el contexto y el razonamiento adecuados. Todo el flujo de trabajo es autónomo, donde los agentes transfieren tareas de uno a otro y entre productos, manteniendo al mismo tiempo al ser humano informado para la toma de decisiones finales. Los analistas pueden convertirse verdaderamente en orquestadores de acciones impulsadas por la inteligencia.

Los equipos de seguridad que crean esta capacidad ahora no están esperando un conjunto de herramientas perfecto. Primero están construyendo el modelo operativo y dejando que la arquitectura se ponga al día. Los que lleguen primero tendrán una ventaja estructural que se agravará con el tiempo: mejores datos, mejores análisis, mejores pruebas y, además, una IA mejor adaptada. Los LLM de propósito general no están hechos para esto, requieren contexto y conocimiento basado en el producto.

Las organizaciones que lo cierran más rápido son las que tratan a CTEM como un modelo operativo, no como una herramienta única, y eligen una infraestructura de IA construida específicamente para ejecutarlo de un extremo a otro. Puede ver el modelo operativo en funcionamiento con Asistente XTM One CTEM.

Míralo en la práctica: seminario web en vivo

Filigran está llevando a cabo una sesión en vivo que explica cómo se ve esto en la práctica: cómo los equipos de seguridad utilizan IA agente para conectar inteligencia, validación de exposición y respuesta en un único flujo de trabajo continuo, sin las brechas de transferencia que ralentizan cada paso intermedio.

La sesión cubrirá:

  • Por qué el cambio a la IA agente cambia el modelo operativo de los programas de seguridad, no solo las herramientas
  • Donde los agentes diseñados específicamente superan a la IA de propósito general cuando la precisión importa
  • Cómo evaluar la infraestructura de IA agente para su propio programa

Regístrese para una sesión en vivo u obtenga la grabación:

¿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.

La verdadera amenaza de Shadow AI es el control de acceso – CYBERDEFENSA.MX

La primera ola de preocupación por la IA empresarial fue sencilla. Simplemente eran empleados que pegaban datos confidenciales en herramientas públicas de inteligencia artificial. Los equipos de seguridad respondieron con políticas de uso, bloqueos de dominio y reglas de prevención de pérdida de datos. Esa respuesta tenía sentido en ese momento.

Ya no se ajusta al problema.

La IA en la sombra ha pasado de ser un problema de fuga de datos a un problema de control de acceso. La amenaza no se trata de lo que los empleados escriben en las herramientas de inteligencia artificial. Se trata de qué agentes de IA se ejecutan dentro de la organización, a qué sistemas empresariales están conectados y qué acciones están autorizados o no a realizar.

De herramientas pasivas a actores activos

Los empleados y las unidades de negocio están creando agentes de IA a un ritmo que la mayoría de los equipos de seguridad no pueden seguir. Se están creando asistentes personalizados, agentes de codificación, automatizaciones de flujo de trabajo y aplicaciones de agentes en todos los departamentos, algunos de ellos en plataformas autorizadas, pero muchos a través de extensiones de navegador, funciones nativas de SaaS, herramientas de desarrollo, servidores MCP, agentes basados ​​en terminales y scripts personalizados. Muchos comienzan como experimentos rápidos. Algunos se integran en procesos comerciales críticos en cuestión de días.

El perfil de riesgo de estos agentes es fundamentalmente diferente del de la TI tradicional en la sombra. Una aplicación SaaS no autorizada es un destino de datos. Un agente de IA es un actor que puede llamar a API, usar credenciales almacenadas, recuperar registros, modificar configuraciones, desencadenar flujos de trabajo posteriores y tomar acciones en sistemas de producción, a menudo sin que un humano autorice explícitamente cada paso.

Que un empleado pegue el registro de un cliente en una herramienta pública de inteligencia artificial es un incidente de fuga de datos. Un agente de IA personalizado conectado a Salesforce, Snowflake, GitHub, Gong y Slack es un incidente de control de acceso a punto de suceder. Podría exponer datos, pero también podría realizar acciones de lectura, escritura y eliminación de esos datos. También puede ejecutarse en cuentas de servicio con permisos que nadie auditó y permanecer activo seis meses después de que el empleado que lo creó cambió de rol o dejó la empresa. Nueva investigación de Token Security y Cloud Security Alliance mapea exactamente qué tan extendida se ha vuelto esta exposición.

¿Por qué los controles existentes no lo alcanzan?

La mayoría de los controles de seguridad empresarial se diseñaron para identidades humanas y cargas de trabajo deterministas. Las políticas de IAM, las reglas de DLP y la supervisión de la red suponen un comportamiento predecible y rutas de acceso definidas. Los agentes de IA rompen esos supuestos.

Un agente encargado de resolver una implementación fallida podría leer registros, consultar sistemas de monitoreo, modificar configuraciones de infraestructura, abrir tickets, activar canales de automatización y notificar a los equipos de ingeniería, todo en secuencia, todo usando las mismas credenciales heredadas. Para evitar interrumpir los flujos de trabajo, los desarrolladores otorgan amplios permisos por adelantado. Esos permisos se acumulan. Los agentes heredan privilegios a nivel de creador, el acceso temporal se vuelve permanente y los equipos de seguridad e identidad pierden visibilidad de lo que esas identidades están haciendo realmente.

Bloquear dominios públicos de IA no llega a nada de esto. Cuando un agente tiene credenciales para los sistemas empresariales, ya se ha cruzado el límite. Remediación automatizada de identidades no humanas es donde se cierra esa brecha.

Cómo se ve un inventario real de IA en la sombra

Descubrir la IA en la sombra requiere observar los entornos donde realmente viven los agentes, como plataformas de IA, aplicaciones SaaS con automatización incorporada, cuentas en la nube, herramientas de desarrollo, puntos finales y proveedores de identidad. A continuación se presentan seis preguntas para definir si los equipos de seguridad tienen el control real.

  1. ¿Dónde se crean o instalan los agentes? Esto incluye plataformas obvias de IA, pero también asistentes de codificación, funciones de agentes nativos de SaaS, herramientas de desarrollo local y aplicaciones internas que han agregado silenciosamente capacidades de IA.
  2. ¿Quién es el propietario de cada agente y quién puede utilizarlo? Sin propiedad, no hay responsabilidad. Un agente creado para un equipo financiero de tres personas que se comparte en toda la organización conlleva un perfil de riesgo muy diferente al de uno dirigido a un solo usuario.
  3. ¿A qué recursos y servicios está conectado el agente? Un agente puede parecer inofensivo a nivel de plataforma mientras mantiene conexiones con bases de datos confidenciales o sistemas de producción a través de credenciales que se otorgaron de manera informal y nunca se revisaron.
  4. ¿Qué identidades y secretos utiliza? Los agentes se autentican a través de cuentas de servicio, claves API, tokens OAuth, roles de IAM en la nube y secretos de larga duración. Cada tipo de credencial conlleva diferentes riesgos.
  5. ¿Cuál es la intención del agente y qué ha hecho realmente? La configuración por sí sola no muestra si un agente está leyendo datos, escribiendo registros o accediendo a sistemas fuera de su alcance previsto. Es necesario comprender la intención y el contexto de comportamiento para priorizar la respuesta.
  6. ¿El agente sigue activo? Los datos de Agentic Pulse de Token Security encontraron que el 65,4% de los chatbots agentes nunca se han utilizado desde su creación, pero sus credenciales permanecen activas. Los agentes inactivos con acceso en vivo son una exposición persistente y subestimada.

La curva de madurez para garantizar la seguridad de la IA agente

La mayoría de las organizaciones se encuentran en el comienzo de esto y tienen poco o ningún inventario de agentes. El siguiente paso es obtener visibilidad parcial para saber qué agentes existen, incluso sin el contexto completo. Después de eso, necesitan enriquecimiento y contexto para comprender la intención y asignar la propiedad, el acceso y las credenciales a cada agente. El siguiente paso es aplicar medidas de control con controles automatizados que corrijan los permisos excesivos, notifiquen a los propietarios de agentes inactivos y señalen nuevos agentes que se conectan a sistemas confidenciales.

El objetivo no es bloquear la adopción de la IA. Los equipos están bajo una presión real para utilizar estas herramientas y muchas de las ganancias de productividad son legítimas. Si la seguridad se convierte en un obstáculo, el uso se vuelve más clandestino y invisible. El mejor resultado es la habilitación gobernada para proporcionar un camino para que los equipos implementen agentes con controles automatizados que se ejecutan continuamente en segundo plano.

Esto requiere tratar a los agentes de IA de la misma manera que trataría a cualquier otra identidad en la empresa con descubrimiento continuo, propiedad definida, acceso con alcance y gestión del ciclo de vida desde la creación hasta el desmantelamiento.

La cuestión de la IA en la sombra ha cambiado. Ya no se trata de: ¿qué datos están incorporando los empleados a la IA? La cuestión ahora es: ¿qué agentes operan en nuestro entorno y a qué les dimos acceso? Esas son preguntas diferentes. El segundo es el que define la exposición y el riesgo de una organización. Si estás trabajando en ese inventario ahora, Vale la pena ver cómo otros lo abordan..

¿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.

Salesforce deshabilita la integración de la aplicación Klue después de que el abuso del token OAuth exponga los datos del cliente

Salesforce reveló que deshabilitó la integración de la aplicación Klue Battlecards dentro de su plataforma en respuesta a un incidente de seguridad que afectó a la empresa de inteligencia competitiva el 11 de junio de 2026.

Con ese fin, las organizaciones no podrán conectarse a Salesforce a través de la aplicación hasta nuevo aviso, señaló la compañía estadounidense de software basado en la nube en una alerta publicada esta semana.

«Salesforce tomó esta acción porque nuestros equipos de seguridad detectaron recientemente una actividad inusual relacionada con la aplicación que puede haber resultado en un acceso no autorizado a un subconjunto de datos del cliente a través de la conexión de la aplicación a Salesforce», anotado. «Este problema se limita a la conexión de la aplicación de Klue y no surge de una vulnerabilidad dentro de la plataforma Salesforce».

El desarrollo se produce cuando un grupo de extorsión denominado Icarus comprometió y exfiltró datos de los clientes de Klue, incluida la empresa de ciberseguridad Huntress.

«Los datos que se copiaron de nuestra cuenta de Salesforce incluyen contactos comerciales, cotizaciones de precios y otros datos y mensajes relacionados con las ventas», Huntress dicho. «Ningún dato de amenazas, contraseñas, información de tarjetas de pago o datos de ingeniería relacionados con el agente Huntress o la telemetría que recopilamos se vieron afectados».

En su propia actualización, Klue dijo que detectó actividad no autorizada que afectó una parte de la infraestructura de integración de Klue el 12 de junio de 2026, y agregó que los atacantes obtuvieron acceso a través de una credencial heredada comprometida asociada con un servicio de integración.

Ciberseguridad

«El atacante utilizó ese acceso para obtener tokens OAuth utilizados para conectar Klue con ciertas plataformas de terceros, incluido Salesforce, y posteriormente accedió a datos dentro de varios entornos de clientes conectados», dijo Jason Smith, director ejecutivo de Klue. dicho. «Según nuestra investigación hasta la fecha, el incidente se limitó a las plataformas de terceros afectadas y no hay evidencia de que el contenido del cliente almacenado dentro de la plataforma Klue se haya visto afectado».

Específicamente, se dice que la intrusión permitió al actor de amenazas impulsar una actualización de código capaz de recopilar tokens OAuth que sus clientes utilizan para conectar Klue a sus propios sistemas. En respuesta a la infracción, Klue tomó medidas para revocar las credenciales y tokens afectados, eliminar el código no autorizado, detener el acceso remoto, desactivar las integraciones potencialmente afectadas e iniciar una investigación exhaustiva.

A partir del 16 de junio de 2026, algunos de los empleados de Huntress recibieron un correo electrónico con el asunto «correo electrónico ultrasecreto» y una advertencia que dice: «Sus datos de Salesforce han sido descargados… Tiene 48 horas para comunicarse con nosotros. Tome la decisión correcta».

«El actor de la amenaza parece haber aprovechado una credencial en desuso durante mucho tiempo pero aún activa para llevar a cabo el compromiso inicial, una que fue creada originalmente por Klue para que crearan un prototipo de una integración de terceros que luego abandonaron», dijo la compañía. «El actor de amenazas luego ingresó a la infraestructura de Klue para robar los tokens utilizados por los clientes de Klue, luego usó esas credenciales robadas para consultar las herramientas CRM de esos clientes directamente y, eventualmente, exfiltrar los datos».

No se sabe mucho sobre el actor de Ícaro aparte del hecho de que ha estado activo desde el 28 de abril de 2026 y ha reclamado un total de dos víctimas hasta la fecha. Dicho esto, la campaña de robo de datos refleja oleadas de ataques anteriores montados por ShinyHunters y UNC6395.

ReliaQuest, en su propio análisis del abuso de integración de Klue, dijo que la actividad comparte similitudes con el manual de estrategias de abuso de OAuth de terceros asociado con el Los compromisos de Salesloft Drift y Gainsight que se dirigieron a los entornos de Salesforce el año pasado.

Ciberseguridad

«En los ataques que observamos, el adversario primero se autenticó a través de una cuenta de servicio de integración Klue comprometida, generó tokens OAuth y ejecutó scripts Python automatizados (identificables por cadenas de agente de usuario Python-urllib)», los investigadores de ReliaQuest Thassanai McCabe y Alexa Feminella. dicho.

«Estos scripts primero enumeraron el catálogo de objetos de la organización a través de GET /services/data/v59.0/sobjects, luego realizaron un bucle de consultas de API REST contra el punto final de consulta de Salesforce (/services/data/v59.0/query) y paginaron los resultados a través del cursor QueryMore durante casi 24 horas».

Se considera que son acciones de recuperación masiva de datos diseñadas para extraer grandes volúmenes de registros de CRM a través de la API REST de Salesforce. Esto incluyó una «ráfaga concentrada» de casi mil consultas en 15 minutos contra al menos un entorno y una ventana de extracción que duró más de seis horas en otro caso.

No está claro cuántos clientes de Salesforce se vieron afectados por los últimos ataques, aunque Klue dijo que se ha estado comunicando directamente con los clientes afectados, compartiendo hallazgos de investigación y ayudándolos con sus esfuerzos de respuesta.

«El hilo común es el abuso de tokens o credenciales de OAuth de un proveedor externo confiable», dijo ReliaQuest. «Estas integraciones son identidades no humanas con acceso persistente y a menudo amplio a datos confidenciales, pero normalmente se monitorean mucho menos estrechamente que las cuentas de los empleados. Esa brecha es la razón por la cual se podría ejecutar un ciclo de consulta automatizado de 24 horas desde una cuenta de integración ‘confiable’ sin activar las alarmas habituales».

Apple parchea la falla de Studio Buds que permite a atacantes cercanos espiar a través del micrófono – CYBERDEFENSA.MX

Apple ha actualizado sus auriculares inalámbricos Beats Studio Buds para solucionar una vulnerabilidad de alta gravedad que podría ser aprovechada por piratas informáticos cercanos para espiar a los usuarios.

La vulnerabilidad, rastreada como CVE-2025-20701 (Puntuación CVSS: 8,8), se refiere a un caso de autorización incorrecta que afecta al SDK de audio Bluetooth de Airoha que permite emparejar un dispositivo de audio Bluetooth sin el consentimiento del usuario.

Explotación exitosa La falla podría conducir a una escalada remota de privilegios sin requerir privilegios de ejecución adicionales o interacción del usuario. El problema se solucionó en la actualización de firmware Beats 1B211.

«Un atacante dentro del alcance de Bluetooth puede escuchar a través del micrófono de un dispositivo que aún no está emparejado y que busca activamente solicitudes de emparejamiento», dijo Apple en un aviso publicado esta semana.

Los detalles de la vulnerabilidad surgieron por primera vez en junio de 2025 cuando los investigadores de ERNW GmbH Dennis Heinze y Frieder Steinmetz lo marcó junto con otros dos defectos en SoC Airoha (CVE-2025-20700 y CVE-2025-20702) en la conferencia de seguridad TROOPERS en Alemania. Parches similares fueron liberado por Jabra en diciembre de 2025.

Ciberseguridad

«En la mayoría de los casos, estas vulnerabilidades permiten a los atacantes apoderarse completamente de los auriculares a través de Bluetooth. No se requiere autenticación ni emparejamiento», señalaron los investigadores en ese momento. «Las vulnerabilidades pueden activarse a través de Bluetooth BR/EDR o Bluetooth Low Energy (BLE). Estar dentro del alcance de Bluetooth es la única condición previa. Es posible leer y escribir en la RAM y la memoria flash del dispositivo».

«Estas capacidades también permiten a los atacantes secuestrar relaciones de confianza establecidas con otros dispositivos, como el teléfono emparejado con los auriculares. Estas capacidades permiten múltiples escenarios de ataque».

Nuevo exploit no parcheable descubierto en los chips A12 y A13 de Apple

La revelación se produce cuando Paradigm Shift reveló un novedoso iPhone. ROM segura (también conocida como BootROM) que afecta a los chips A12 y A13 de Apple, además de un exploit de prueba de concepto (PoC) con nombre en código usbliter8.

«El exploit aprovecha tanto un error de hardware en el controlador USB como un fallo de configuración específico presente en el firmware del dispositivo», afirma la empresa europea de ciberseguridad. dicho. «Como estas vulnerabilidades residen en código inmutable, los usuarios afectados deben ser conscientes de que migrar a un hardware más nuevo sigue siendo la mitigación más eficaz».

En un nivel alto, el exploit funciona aprovechando una falla en el controlador USB integrado en los SoC de Apple. El controlador utiliza un buffer de memoria para almacenar los paquetes SETUP y OUT transmitidos al inicio de la transferencia de datos. La investigación encontró que es posible desencadenar una primitiva de desbordamiento de buffer aprovechando el hecho de que el controlador también acepta paquetes más pequeños, lo que permite efectivamente la inyección y ejecución de código malicioso bajo ciertas condiciones.

El problema, señaló Paradigm Shift, probablemente tenga su origen en el hardware del controlador USB, no en el software de Apple. El chip A11 no es susceptible a la vulnerabilidad, mientras que se confirma que A12 y A13 son susceptibles.

Ciberseguridad

«La diferencia es que el controlador USB A11 restablece manualmente la dirección DMA a su valor inicial después de recibir cada paquete», dijo la compañía. «En A12 y A13, USB DART está configurado en modo bypass, lo que nos permite sobrescribir datos SRAM libremente. Por el contrario, A14 y generaciones posteriores parecen configurar DART correctamente en SecureROM, lo que hace que la vulnerabilidad no se pueda explotar».

El exploit usbliter8 es comparable a checkm8, el exploit BootROM de este tipo conocido públicamente que afectó a todos los dispositivos iOS, desde el iPhone 4s (chip A5) hasta el iPhone 8 y el iPhone X (chip A11).

«El exploit usbliter8 demuestra que incluso en las generaciones más recientes de SecureROM, incluidas aquellas protegidas por Autenticación de punteroaún se pueden aprovechar errores sutiles de hardware para lograr la ejecución completa del código y romper la cadena de confianza», dijo Paradigm Shift.

«La seguridad de BootROM es crítica: las vulnerabilidades en este nivel pueden comprometer la integridad de todo el dispositivo. Aunque usbliter8 no afecta a SEP en sí, abre vectores de ataque más amplios para comprometer Secure Enclave».