Microsoft revela cargas de vulnerabilidades 'la madre de todas', triplicando el récord anterior de junio

mensual de Microsoft Martes de parches El programa de seguridad alcanzó un punto máximo sin igual este mes, cuando el proveedor abordó 622 vulnerabilidades en su conjunto de productos y sistemas empresariales.

«El apocalipsis de los errores finalmente ha descendido sobre nosotros», escribió Dustin Childs, jefe de concientización sobre amenazas en la Iniciativa Día Cero de Trend Micro, en un publicación de blog Martes.

«La madre de todos los lanzamientos. Llamar a esto un récord es quedarse corto», añadió. «El recuento de CVE en lo que va del año supera los totales de todos los demás años».

El sorprendente aumento de las vulnerabilidades refleja un efecto compuesto que se está arraigando en el software a medida que la inteligencia artificial desempeña un papel cada vez más importante en el descubrimiento y desarrollo de parches para los defectos que acechan en aplicaciones plagadas de errores.

La actualización del martes de parches de junio de Microsoft rompió el récord histórico anterior con 206 vulnerabilidades.

La semana pasada, la compañía advirtió a sus clientes y defensores que se descubriría una avalancha de defectos al aplicar su arnés de escaneo agente multimodelo (MDASH) para descubrir y abordar vulnerabilidades a mayor velocidad y escala.

El aumento exponencial mensual de las vulnerabilidades de Microsoft ya coloca al proveedor en camino de batir un récord de todo el año, terminando 2026 con la mayor colección anual de defectos, superando el récord anterior de 1245 CVE en 2020, dijo Satnam Narang, ingeniero senior de investigación de Tenable, en un correo electrónico.

«Es probable que no sólo superemos los 2.000 CVE en un año calendario, sino potencialmente más de 3.000 CVE este año o más», añadió.

«El volumen es sorprendente, pero refleja cuán buenas se han vuelto estas herramientas para encontrar errores, no cuántos de esos errores realmente representan un riesgo para las organizaciones», dijo Narang.

Microsoft reveló dos vulnerabilidades de día cero explotadas activamente: CVE-2026-56155 y CVE-2026-56164defectos de escalada de privilegios en Active Directory Federation Services y Microsoft SharePoint Server, respectivamente.

El lote mensual de parches incluyó 416 defectos en Windows, 82 en Office y 46 en Microsoft Edge. Más de 1 de cada 10 vulnerabilidades que el proveedor reveló (63 en total) fueron calificadas como críticas.

«Los productos cubiertos este mes también son sorprendentes», dijo Childs. «Casi todo lo que has oído hablar se está parcheando».

La lista completa de vulnerabilidades abordadas este mes está disponible en Centro de respuesta de seguridad de Microsoft.

SAP también abordó un nueva variedad de vulnerabilidades Martes, incluidos defectos críticos. CVE-2026-44747 en el servidor de aplicaciones SAP NetWeaver y CVE-2026-27690 en SAP Approuter.

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

La suplantación de ID de cliente de OAuth permite a los atacantes validar las credenciales de Microsoft Entra robadas – CYBERDEFENSA.MX

Al menos dos actores de amenazas distintos están utilizando como arma una novedosa técnica de evasión llamada Falsificación de ID de cliente de OAuth en campañas en la nube, evitando al mismo tiempo la telemetría.

La actividad permite a los usuarios enumerar cuentas de usuario y validar credenciales robadas en entornos Microsoft Entra ID, sin generar nunca un evento de inicio de sesión exitoso que, de otro modo, alertaría a los defensores. Y los malos actores han comenzado a explotar esta brecha para obtener acceso no autorizado a los servicios en la nube de una organización.

«Un punto ciego en la telemetría de inicio de sesión en la nube: Entra ID devuelve diferentes respuestas de error dependiendo de si la ID de cliente OAuth proporcionada es válida», dijo Proofpoint en un comunicado. «Los atacantes aprovechan esto para inferir nombres de usuario válidos y contraseñas correctas a escala, verificando efectivamente las listas de credenciales robadas sin registrar un inicio de sesión exitoso».

En otras palabras, los ataques aprovechan el ID del cliente OAuth, un identificador único global (GUID) asignado a las aplicaciones cuando solicitan acceso a los datos del usuario, y se pasa como «id_cliente» en solicitudes de autenticación. Al proporcionar ID de cliente falsificados, permite la enumeración de cuentas sin una aplicación OAuth registrada y permite a los atacantes inferir tanto la contraseña como la validez de la cuenta sin generar un evento de inicio de sesión exitoso.

«El Registros de inicio de sesión de Entra son una fuente de telemetría principal para identificar actividades de autenticación maliciosas, incluida la enumeración de usuarios, la difusión de contraseñas y los intentos de acceso inicial», afirma Rachel Rabin, investigadora de Proofpoint. dicho.

Ciberseguridad

Grupos de amenazas como UNK_CustomCloak Se ha observado que falsifican cadenas de User-Agent para orquestar campañas de fuerza bruta dirigidas a entornos Microsoft Entra ID mediante la explotación de una aplicación propia heredada y descontinuada llamada Windows Live Custom Domains para eludir las restricciones de inicio de sesión estándar y sondear las contraseñas de los usuarios en más de 4000 inquilinos.

Pero los últimos esfuerzos marcan una evolución de este oficio al falsificar las ID de los clientes de OAuth a través de solicitudes HTTP POST al punto final del token OAuth 2.0 de Microsoft utilizando las credenciales de contraseña del propietario del recurso (ROPC) flujo. Específicamente, esto implica proporcionar un ID de cliente sintácticamente válido pero que no corresponda a una aplicación real.

En tales escenarios, solo se registra el ID de la aplicación en el registro de inicio de sesión de Entra sin el nombre de la aplicación correspondiente. La respuesta, que contiene un servicio de token de seguridad de Azure Active Directory (AADSTS), código de error, se puede utilizar para inferir si la cuenta existe y si la contraseña es correcta sin una aplicación registrada.

«Si el ID de cliente falsificado no es un UUIDv4 adecuado, Entra no rechaza la solicitud directamente», explicó Proofpoint. «Por lo tanto, los atacantes pueden analizar esta respuesta de error para identificar cuentas y contraseñas válidas, a pesar de utilizar ID de cliente con formato incorrecto».

«Cuando se utiliza una identificación de cliente falsificada, no se registra ningún nombre de aplicación correspondiente en el registro de inicio de sesión. Esto significa que las detecciones que buscan aumentos en un nombre de aplicación específico pueden perder esta actividad por completo, ya que el campo está en blanco».

Armados con esta información, los atacantes podrían identificar cuentas que podrían ser explotadas para un acceso sigiloso, al mismo tiempo que dificultaría a los defensores identificar actividades sospechosas.

Ciberseguridad

Proofpoint dijo que ha identificado dos grandes campañas que adoptaron la técnica de forma independiente hacia finales de diciembre de 2025, lo que indica que el enfoque se está incorporando cada vez más a las técnicas de los atacantes en lugar de ser un incidente aislado:

  • UNK_pyreq2323 (de enero a marzo de 2026), que utilizó más de 700 000 ID de clientes falsificados de la infraestructura de Amazon Web Services (AWS) para apuntar a más de 1 millón de cuentas en casi 4000 inquilinos, lo que provocó bloqueos para aproximadamente el 28 % de los usuarios objetivo debido a intentos fallidos.
  • UNK_OutFlareAZ (a partir de diciembre de 2025), que aprovechó la infraestructura de Cloudflare para dirigirse a más de 2 millones de usuarios con 3,7 millones de ID de aplicaciones falsificadas aleatorias.

Se ha observado que ambas campañas utilizan UUID válidos en lugar de identificadores con formato incorrecto y demuestran patrones que se alinean con listas de palabras de nombres de usuarios precompiladas. Dicho esto, mientras UNK_OutFlareAZ enumeró a los usuarios alfabéticamente, UNK_pyreq2323 no lo hizo. Otro aspecto en el que diferían era en cómo se falsificaban las identificaciones de los clientes.

Se dice que UNK_pyreq2323 modificó los dígitos finales de una ID de aplicación conocida y luego reutilizó ID falsificadas en hasta 12 usuarios. Por el contrario, UNK_OutFlareAZ generó una identificación de cliente única por solicitud.

«Al fragmentar los intentos de autenticación en muchas aplicaciones ficticias, la actividad se vuelve más difícil de correlacionar y puede evadir las detecciones por aplicación y la limitación de velocidad», dijo Proofpoint. «Las organizaciones pueden intentar mitigar los ataques de enumeración tradicionales aplicando políticas de acceso condicional dirigidas a aplicaciones comúnmente destinadas a la enumeración. Las ID de clientes falsificadas no activarán políticas de CA que estén dirigidas a una aplicación específica».

11 antiguas cuñas UEFI de Linux firmadas por Microsoft podrían permitir a los atacantes evitar el arranque seguro – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto 11 aplicaciones antiguas de Interfaz de firmware extensible unificada (UEFI) firmadas por Microsoft de las que se podría abusar para evitar el arranque seguro en la mayoría de los sistemas que utilizan el estándar de firmware moderno.

«Un atacante que explote una de estas aplicaciones vulnerables puede ejecutar código que no es de confianza durante el arranque del sistema, permitiendo la implementación de bootkits UEFI maliciosos u otro malware», dijo el investigador de ESET Martin Smolár. dicho en un informe publicado hoy.

Los cargadores de arranque UEFI exponen cualquier máquina basada en UEFI que confíe en Microsoft «Corporación Microsoft UEFI CA 2011«Certificado de autoridad certificadora (CA) UEFI de terceros, independientemente del sistema operativo instalado. El certificado se utiliza para firmar componentes de arranque de terceros destinados a ejecutarse bajo arranque seguro. Expiró el 27 de junio de 2026 y ha sido reemplazado por Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.

El shim es un gestor de arranque UEFI liviano y de código abierto que actúa como intermediario entre el firmware de la placa base de una computadora y el sistema operativo Linux. Su objetivo principal es permitir que las distribuciones de Linux se inicien cuando el arranque seguro está habilitado. Vale la pena señalar que el shim en sí está firmado con una clave en la que confía el firmware, principalmente una firma de Microsoft, ya que sus certificados vienen preinstalados en dispositivos basados ​​en UEFI.

Ciberseguridad

La secuencia procede de la siguiente manera: el firmware UEFI carga el shim y valida su firma con la CA de Microsoft almacenada en el firmware. Luego, el shim valida el cargador de arranque de segunda etapa (en la mayoría de los casos, GRUB 2) con su propio certificado de proveedor integrado. GRUB 2 finalmente valida el kernel utilizando el mismo certificado de proveedor.

La compañía eslovaca de ciberseguridad dijo que los shims, obsoletos pero confiables, pueden explotarse para ejecutar código arbitrario cuando se inicia el sistema, lo que permite a los delincuentes implementar kits de arranque UEFI como Bootkitty, HybridPetya o BlackLotus incluso cuando las protecciones de arranque seguro están habilitadas.

Desde entonces, Microsoft ha revocado los gestores de arranque UEFI del proyecto shim de código abierto, principalmente de la versión 0.9 y anteriores, como parte de su Actualización del martes de parches de junio de 2026 tras la divulgación responsable a principios de febrero. La lista de los cargadores de arranque afectados se encuentra a continuación:

  • Spyrus WTGCreator del cargador de cuñas UEFI (0.7 o inferior)
  • RedHat RedHat Enterprise Linux (7.2) desde el cargador de cuñas UEFI (0.9)
  • RedHat CentOS (7.2) del cargador de cuñas UEFI (0.9)
  • Software Baramundi baramundi Management Suite (hasta 2024R1) desde UEFI shim loader (0.8)
  • WhiteCanyon/Blancco WipeDrive (8.0.0 a 8.1.3) del cargador de cuñas UEFI (0.7)
  • Junta de Examen de Matriculación de Finlandia Abitti 1 (1.0) del cargador de cuñas UEFI (0.8)
  • NTC IT ROSA, LLC ROSA Linux (R10, R9) del cargador de cuñas UEFI (0.9)
  • Oracle America, Inc. OracleLinux (7.2) del cargador de cuñas UEFI (0.9)
  • PC-Doctor, Inc. Centro de servicio PC Doctor (15, 16) del cargador de cuñas UEFI (0.9)
  • OpenSuse OpenSuse UEFI Cargador de cuñas (0.9)
  • OpenSuse OpenSuse Shim (2.1) del cargador UEFI Shim (0.9)

Una consecuencia de esta laguna jurídica es que un atacante podría aprovechar estos cargadores de arranque shim susceptibles para eludir los mecanismos de seguridad más nuevos haciendo uso de la técnica de ataque «traiga su propio controlador vulnerable» (BYOVD) para ejecutar código arbitrario durante la fase de arranque inicial, incluso antes de que se inicialice el sistema operativo.

Los sistemas Linux también vienen con una característica de seguridad llamada lista de permitidos de clave de propietario de máquina (MOK) que permite a los usuarios autorizar la carga de controladores no firmados mientras UEFI Secure Boot está activo. Aunque se introdujo una lista de denegados MOK en la versión 0.9 de shim como una forma de revocar certificados de firma antiguos asociados con un binario UEFI vulnerable y volver a firmar versiones parcheadas.

En este contexto, un atacante podría reemplazar el shim actualizado de la víctima con un shim UEFI más antiguo firmado por Microsoft y evitar la aplicación de la lista de denegados MOK aprovechando el hecho de que la lista de permitidos todavía confía en el certificado antiguo. Esto, a su vez, podría permitir que el shim de un atacante cargue binarios vulnerables sin restricciones y obtenga la ejecución de código arbitrario.

Eso no es todo. El ataque también subvierte el Secure Boot Advanced Targeting (SBAT), que está diseñado para revocar componentes de arranque vulnerables en lugar de mantener una enorme lista de bloqueo de hashes criptográficos individuales correspondientes a cada archivo. Dicho de otra manera, el mecanismo se utiliza para actualizar la generación mínima aceptable cada vez que se descubre una vulnerabilidad en un componente de la cadena de arranque. Si un intento de arranque utiliza una versión anterior y vulnerable, el sistema lo bloquea y arroja un error.

El Centro de Coordinación CERT (CERT/CC), en un aviso emitido el mes pasado, dijo que los cargadores de arranque específicos del proveedor no se han actualizado para abordar las vulnerabilidades en el proyecto ascendente después de que se conocieron públicamente y se solucionaron.

«Como resultado, los cargadores de arranque vulnerables permanecieron firmados y confiables para los sistemas de arranque seguro porque no habían sido revocados a través de la lista de revocación DBX firmada por Microsoft», dijo. anotado. «Esto creó una exposición a largo plazo en la cadena de suministro en la que los componentes de arranque obsoletos y vulnerables aún podían ejecutarse en sistemas completamente parcheados».

Ciberseguridad

El resultado es que un atacante con privilegios administrativos o la capacidad de modificar el proceso de arranque podría abusar de uno de los cargadores de arranque vulnerables mencionados anteriormente para eludir las protecciones de arranque seguro y ejecutar código arbitrario antes de que se cargue el sistema operativo, allanando el camino para una persistencia arraigada que puede sobrevivir a los reinicios del sistema operativo y, en algunos casos, a su reinstalación.

Debido a que todo esto ocurre antes de que se inicialicen el sistema operativo y los productos de seguridad, el código malicioso ejecutado a través de los cargadores de arranque también puede eludir la detección mediante controles de seguridad integrados y soluciones de detección y respuesta de endpoints (EDR).

Los problemas se rastrean bajo los identificadores CVE. CVE-2026-8863 y CVE-2026-10797, este último haciendo referencia a un problema de larga data en una corrección que permitía omitir el mecanismo de revocación basado en certificados modificando el encabezado de firma del gestor de arranque de la segunda etapa.

ESET ha advertido que la caducidad del certificado «Microsoft Corporation UEFI CA 2011» no influye en el proceso de verificación de Secure Boot siempre que los gestores de arranque firmados con el certificado caducado no sean revocados explícitamente mediante hash.

«Lo que hace que estas viejas correcciones sean peligrosas no es una vulnerabilidad novedosa, es que no se necesita ninguna vulnerabilidad nueva para evitar el arranque seguro UEFI», dijo ESET. «Un atacante no necesita primitivos de explotación complicados: solo una copia de un binario shim antiguo, aún confiable, pero no revocado y una comprensión básica de cómo funcionan los shims UEFI. Eso es suficiente para eludir una característica de seguridad tan esencial como UEFI Secure Boot».

Microsoft mapea el robo de datos de Salesforce vinculado a ShinyHunters durante un año a través de tres caminos – CYBERDEFENSA.MX

Los atacantes cuyos métodos se alinean con los del grupo de extorsión de datos ShinyHunters pasaron el año pasado ingresando a entornos corporativos de Salesforce sin explotar una sola falla en la plataforma.

La forma de entrar ha sido la confianza que la organización ya había extendido, generalmente a través de las conexiones OAuth que vinculan a Salesforce con las aplicaciones y los proveedores externos que la rodean.

En investigación publicada el 13 de julioMicrosoft mapeó las campañas, que se desarrollaron desde mediados de 2025 hasta mediados de 2026, en tres técnicas distintas. También trabajó con Salesforce para implementar nuevas herramientas de detección y gobernanza destinadas a abordar los registros de autenticación de actividad perdidos.

Eso es lo que hace que esto sea difícil de detectar. Cuando el acceso proviene de un usuario real que aprobó una aplicación conectada, o de una integración en la que la empresa ya confía, el tráfico se lee como uso normal y el monitoreo de inicio de sesión y autenticación apenas lo registra.

Lo que importa es lo que hace la aplicación o cuenta una vez que está dentro, y eso es exactamente para lo que la mayoría de los registros de Salesforce no fueron creados para mostrar.

Ciberseguridad

Microsoft agrupa la actividad en tres rutas de intrusión:

  • llamadas vishing que engañan a los empleados para que aprueben una aplicación conectada maliciosa,
  • tokens OAuth robados de proveedores de software comprometidos, y
  • acceso de invitados mal configurado a sitios de Salesforce.

Cada uno se corresponde con un incidente de Salesforce del año pasado, y Microsoft dice que vio la actividad entre inquilinos en industrias que incluyen el comercio minorista, la educación y la fabricación.

la llamada telefonica

El primer camino es el que inició todo el recorrido. A partir de mediados de 2025, los actores realizaron llamadas de phishing de voz (vishing) haciéndose pasar por soporte de TI y hablaron con los empleados a través de la pantalla de consentimiento OAuth de Salesforce, logrando que autorizaran una aplicación conectada controlada por un atacante disfrazada de la propia herramienta de carga de datos de Salesforce.

Una vez que se otorgaba el consentimiento, la aplicación podía realizar llamadas API como ese usuario, permitiendo a los atacantes enumerar los datos de Salesforce de la organización, mantener acceso persistente a los registros de CRM y buscar credenciales que pudieran abrir la puerta a otras plataformas SaaS.

Sin malware, sin repetición de contraseñas robadas. Sólo una llamada telefónica y un clic de consentimiento.

Así es la campaña de Google Threat Intelligence Group (GTIG) y Mandiant documentado a mediados de 2025, rastreando el acceso inicial como UNC6040 y la extorsión posterior como UNC6240, los cuales seguían afirmando ser ShinyHunters para apoyarse más en las víctimas.

Google confirmó que una de sus propias instancias corporativas de Salesforce fue atacada en junio de 2025, y los atacantes tomaron datos de contactos comerciales en gran medida públicos antes de que Google los cortara. La misma ola se vinculó públicamente con violaciones en Chanel y Pandora, con Adidas, Qantas, Allianz Life y varias marcas de LVMH también mencionadas como objetivos.

El consejo de Mandiant a los defensores fue contundente: estas llamadas explotan el instinto de ayuda de la mesa de ayuda, los controles de identidad estándar a menudo no se aplican y la medida segura es colgar y volver a llamar a un canal que se sabe que es bueno.

Tokens robados de proveedores confiables

El segundo camino omite por completo al empleado. En lugar de hacer phishing a un usuario, los atacantes comprometen a un proveedor externo cuya aplicación ya tiene acceso OAuth a las organizaciones de Salesforce de sus clientes, roban los secretos o tokens de conexión y los utilizan para consultar y exportar datos en muchas instancias posteriores a la vez.

Debido a que el tráfico proviene de una integración aprobada, no activa alarmas de inicio de sesión y se integra con la automatización normal.

Microsoft señala tres incidentes aquí. El compromiso de Salesloft Drift de agosto de 2025 es el más grande y claro: los atacantes robaron OAuth y tokens de actualización vinculados a la integración del chat de Drift AI y los utilizaron contra los entornos de los clientes de Salesforce.

Google estimó que el robo del token Drift expuso potencialmente a más de 700 organizaciones, entre ellas Cloudflare, Zscaler, Palo Alto Networks, Proofpoint, PagerDuty y Tanium. Google rastrea el clúster como UNC6395; Cloudforce One de Cloudflare lo llama GRUB1.

Posteriormente, Salesloft rastreó la causa raíz hasta el acceso del atacante a su cuenta de GitHub ya en marzo de 2025, que se utilizó para llegar al entorno AWS de Drift y recolectar los tokens. Los operadores estaban allí en busca de secretos, ejecutando consultas SOQL para examinar casos de soporte y otros objetos en busca de claves de AWS, tokens Snowflake y contraseñas, y luego eliminando sus trabajos de consulta para ralentizar a cualquiera que investigara.

El incidente de Gainsight de noviembre de 2025 ejecutó la misma jugada contra un proveedor diferente. Salesforce retiró las aplicaciones publicadas por Gainsight después de detectar una actividad API inusual, y GTIG vinculó la campaña a los afiliados de ShinyHunters en más de 200 instancias de Salesforce afectadas.

Las personas detrás del nombre ShinyHunters afirmaron que las ondas Salesloft y Gainsight alcanzaron juntas cerca de 1.000 organizaciones, una cifra que no ha sido confirmada de forma independiente.

El caso más reciente, de junio de 2026, es el compromiso de Klue. Los atacantes ingresaron a la plataforma de inteligencia competitiva a través de una credencial heredada que estuvo en desuso durante mucho tiempo pero aún activa, sobrante de una integración de prueba que nunca se implementó, impulsaron una actualización de código que recopiló los tokens OAuth de los clientes y los utilizaron para acceder a los datos de Salesforce y Gong pertenecientes a los clientes de Klue, incluidos Cazadora y futuro grabado.

Ciberseguridad

Microsoft rastrea al actor de Klue como Storm-3138. Un problema de nomenclatura para cualquiera que haga referencias cruzadas de informes: la mayor parte de la industria, incluidos Huntress y Datadog, vincula la extorsión de Klue a un grupo que se hace llamar Icarus, y una cuenta de Telegram que afirma ser ShinyHunters también se atribuyó el mérito.

Las etiquetas se desdibujan porque estas identidades se superponen y se reivindican de manera oportunista, lo que se mantiene en todo este conjunto de campañas.

Acceso de invitados dejado abierto

El tercer camino no necesita ninguna credencial. Microsoft vio un aumento en la actividad sospechosa de usuarios invitados contra los puntos finales de Salesforce Aura, el marco detrás de los sitios de Experience Cloud. Cuando los permisos de los usuarios invitados estaban mal configurados, los actores accedían a la funcionalidad de Aura sin autenticarse.

Al llamar al controlador GraphQL Aura, utilizaron paginación basada en cursor para extraer registros más allá del límite de consulta estándar de 2000 registros, obteniendo mucho más de lo que el rol de invitado debía exponer.

La detección relacionada de Microsoft apunta a las herramientas AuraInspector utilizadas para sondear estos puntos finales. No hubo ningún exploit involucrado. La organización había dejado que el papel de invitado pudiera ver más de lo que debería, y los actores lo leyeron con todo lo que valía.

Lo que Microsoft y Salesforce enviaron para atraparlo

La señal que sí existe reside en lo que sucede después del acceso: qué aplicación conectada realizó una llamada, qué alcances de OAuth tiene, cuánto está consultando y si algo de eso es normal para el inquilino.

Microsoft trabajó con Salesforce para mostrar exactamente eso en Defender para aplicaciones en la nube. Para los clientes que ejecutan Salesforce Shield Event Monitoring, el conector de Salesforce actualizado incorpora el marco de monitoreo de eventos en tiempo real para una detección casi en tiempo real y agrega atribución de aplicaciones conectadas, vinculando la actividad a una identidad de aplicación específica y sus alcances OAuth otorgados, junto con más contexto de sesión y API.

Además de la detección, Microsoft agregó funciones de postura y gobernanza para las aplicaciones OAuth conectadas: una vista de aplicaciones altamente privilegiadas que tienen alcances elevados, una forma de mostrar aplicaciones no utilizadas que han permanecido inactivas durante 90 días o más mientras mantienen permisos activos, y una puntuación de riesgo de 0 a 100 por aplicación que los equipos pueden conectar a alertas y políticas.

El objetivo es encontrar las integraciones olvidadas y con permisos excesivos antes de que alguien más lo haga.

Reducir la superficie de ataque de OAuth

La guía de Microsoft es práctica y coincide con lo que dijeron los proveedores después de cada incidente: conecte instancias de Salesforce a Defender para aplicaciones en la nube para obtener telemetría adicional, active y observe los registros de eventos de Salesforce y bloquee el acceso de los usuarios invitados a Experience Cloud.

Más allá de los pasos específicos del producto, las soluciones duraderas son las conocidas. Haga un inventario de las aplicaciones conectadas, elimine las que nadie usa, limite el resto al privilegio mínimo y prepárese para revocar y rotar tokens en el momento en que una integración comience a comportarse de manera extraña.

El patrón bajo los tres caminos es el mismo. Los controles de identidad que la mayoría de las empresas dedicaron a construir durante la última década se crearon para inicios de sesión humanos: MFA, acceso condicional y políticas de sesión. Las aplicaciones OAuth, las cuentas de integración y las credenciales de servicio que realizan el trabajo real en una pila moderna de Salesforce en su mayoría se encuentran fuera de ella, sin vigilancia y con exceso de permisos.

Los atacantes que descubrieron esto lo utilizaron durante un año y, más de una vez, la entrada no fue nada más exótica que una credencial que alguien olvidó apagar.

The Hacker News se comunicó con Microsoft para obtener más detalles sobre la atribución de los actores detrás de estas campañas y actualizará esta historia con cualquier respuesta.

Google y Microsoft eliminan ModHeader con 1,6 millones de instalaciones después de que se encontrara un recopilador inactivo – CYBERDEFENSA.MX

Google y Microsoft se han retirado ModEncabezadouna popular extensión de edición de encabezados con aproximadamente 1,6 millones de instalaciones en Chrome y Edge, después de que los investigadores encontraran un recopilador de historial de navegación oculto integrado en su versión oficial de la tienda.

El coleccionista estaba inactivo. Una lista de permitidos vacía lo mantuvo apagado y no ha surgido ninguna prueba de que alguna vez haya recopilado o enviado un solo dominio de navegación.

El análisis surgió de OLT de rayasuna empresa de seguridad del Reino Unido, que verificó el código con la firma de la tienda web de Google y confirmó que el recopilador envió dentro de la extensión genuina, no una falsificación.

Su revisión cubre la versión de Chrome y sus aproximadamente 900.000 usuarios; Los rastreadores de terceros colocan otros 700.000 aproximadamente en Edge. Microsoft retiró la lista de Edge el 3 de julio y Google eliminó la de Chrome una semana después, el 10 de julio.

La versión 7.0.18 (ID de extensión idgpnmonknjnojddfkpgkljpfnnfcklj) todavía edita los encabezados HTTP como se anuncia. El mismo código de fondo minimizado también contiene un segundo sistema. En la primera ejecución, genera una huella digital del dispositivo y carga una clave de cifrado codificada. Mientras navega, toma el dominio de cada página que abre, lo cifra y lo almacena localmente, hasta 1000 dominios distintos.

Una vez al día, un programador agrupa la lista cifrada con su huella digital y la publica en api.stanfordstudies[.]com y borra la copia local. El tiempo de carga se compensa por instalación, por lo que los navegadores que lo ejecutan no generarían todas las balizas a la vez si el recopilador estuviera activado. Derribos separados, por HackIndex en la versión 7.0.18 e investigador yunus aydin el 7.0.17, describe la misma canalización.

Ciberseguridad

El recopilador se ejecuta solo si su navegador coincide con una entrada en una lista interna de permitidos y esa lista se envía vacía. La verificación falla cada vez, por lo que la canalización se detiene antes de recopilar un único dominio. Completar esa lista es un pequeño cambio, sin nuevos permisos ni clics de su parte, entregado como una actualización de rutina. La clave codificada, la URL del punto final, el programador y la lógica de almacenamiento ya están en la máquina.

No todo estaba dormido. Durante la instalación, actualización y desinstalación, la extensión hizo ping a un segundo dominio, extensions-hub[.]com, con el producto, versión y navegador. Y un script que se ejecuta en cada página ya había registrado metadatos de solicitudes reales en el almacenamiento local en texto sin formato, por lo que esa pieza claramente se había estado ejecutando.

Los verificadores automatizados habían calificado a ModHeader como de bajo riesgo, algunos de hasta 95 sobre 100. Cada parte del diseño puede frustrar un tipo diferente de verificación. Los datos están cifrados, por lo que un escáner ve el texto cifrado. La carga está bloqueada, por lo que una zona de pruebas no ve salir nada.

El código malicioso se minimiza a una base de código legítima. Los puntos finales no tenían una reputación maliciosa establecida que señalar. Y una extensión popular y firmada se lee como confiable. La firma de una tienda demuestra de dónde proviene un archivo, no qué hace.

Adónde conducen los dominios

Stripe OLT vinculó los dominios a una infraestructura real y mantenida. estudios de stanford[.]com no tiene ningún vínculo con Stanford; es un dominio antiguo reutilizado frente a un back-end de OpenSearch, mientras que extensions-hub[.]com está configurado para publicidad.

Los dos puntos finales de API se resolvieron en el mismo servidor de Amazon en el momento del análisis, lo que encaja con un operador sin probarlo. Un puñado de señales débiles apuntan vagamente hacia un operador de habla china: una configuración regional en chino simplificado, un marcador «sal» escrito con el carácter 盐 y un proveedor de correo de origen chino. Los investigadores no nombran ningún grupo, y nosotros tampoco.

Las señales de advertencia llegaron antes. ModHeader generó quejas por insertar anuncios en los resultados de búsqueda en 2023 y, según se informa, empezó a recibir publicidad en ese momento. No se ha confirmado quién se hizo cargo y los investigadores no hacen ninguna afirmación sobre el autor original.

El propio sitio de ModHeader todavía publica un plan publicitario que dice que no recopila datos del usuariolo cual es difícil de cuadrar con un recopilador de historial de navegación incorporado, incluso si está apagado. El desarrollador no ha respondido públicamente a los hallazgos al momento de la publicación.

Hacker News se ha puesto en contacto con ModHeader para hacer comentarios y hacer más preguntas a Stripe OLT, y actualizará esta historia con cualquier respuesta.

Ciberseguridad

En 2021, Brian Krebs descrito cómo las extensiones populares se compran silenciosamente y se convierten en canales de datos. Esto se parece a ese patrón, ahora con cifrado y una puerta que impide que los escáneres vean la carga. Sólo este año, se descubrió que una serie de extensiones de Chrome recopilaban datos bajo una etiqueta de «análisis anónimo», y un conjunto separado se hizo pasar por Workday y NetSuite para robar cookies de sesión. Los editores de encabezados y los administradores de cookies necesitan un amplio acceso para trabajar y, cuando se rompe la confianza, el radio de explosión es amplio.

que hacer

Si tienes ModHeader, elimínalo de Chrome y Edge; Es posible que su navegador ya lo haya desactivado. La desinstalación borra los datos almacenados, por lo que lo que hay que verificar es que la sincronización del perfil o una política de extensión administrada no los recupere.

Si pegó secretos en él, claves API, tokens de portador y cookies de sesión, rótelos, ya que los investigadores descubrieron que su función de historial de encabezados almacena encabezados HTTP completos en el disco.

Para los defensores, bloquear y registrar estudios de Stanford[.]com y extensiones-hub[.]com en DNS y proxy, y registros de búsqueda para el ID de extensión y cualquier POST en api.stanfordstudies[.]es/app/log. Stripe OLT publicado listo para ejecutarse consultas de búsqueda KQL para Defensor y Centinela.

Los derribos se encargan de esta extensión. El diseño es la parte que debería preocupar a la gente: un recopilador completo, verificado en la tienda, se encontraba dentro de una herramienta popular y confiable, aparentemente diseñada para activarse una vez que una actualización ordinaria llenaba la lista vacía. Los escáneres automatizados lo calificaron como de bajo riesgo, y la próxima herramienta construida de esta manera puede parecer igual de limpia.

La lección práctica es limitada: la revisión de la extensión debe estar atenta a rutas de código inactivo que las pruebas nunca activan, nuevos puntos finales de llamada a casa y una capacidad que una actualización de rutina puede agregar después de un cambio de manos.

Forg365 PhaaS apunta a Microsoft 365 con código de dispositivo y robo de sesión AitM – CYBERDEFENSA.MX

Una nueva operación de phishing como servicio (PhaaS) llamada Forg365 está utilizando una combinación de phishing de código de dispositivo, tácticas de adversario en el medio (AitM), evasión antibot, creación de señuelos asistida por inteligencia artificial (IA) y operaciones de buzón posteriores al compromiso dirigidas a cuentas de Microsoft 365.

Distribuidas a través de Telegram y con un costo de 400 dólares al mes (o 3.800 dólares al año), las cadenas de ataque aprovechan señuelos de phishing que utilizan infraestructura legítima de entrega de correo electrónico, como Amazon Simple Email Service (Amazon SES) y Twilio SendGrid, para imitar una cadena de redireccionamiento que se mezcla con el tráfico de correo electrónico normal antes de terminar en dominios controlados por Forg365.

«El panel expone un flujo de trabajo de operador maduro: cuentas, enlaces, invitaciones, configuración de aplicaciones OAuth, enlaces de redireccionamiento, generación de SVG, envío de campañas, perfiles SMTP, rotación SMTP, generación de correo electrónico AI, almacenamiento de tokens, inteligencia de cuentas, alertas de palabras clave, enlaces de visor y soporte de extensiones de navegador», ZeroBAC dicho.

La compañía de seguridad de correo electrónico dijo que el kit PhaaS se entiende mejor como similar al ecosistema Kali365 (también conocido como Octopi365 y Freedom365) y Sneaky 2FA, lo que refleja la industrialización del modelo de negocio, que ahora combina la creación de señuelos, la entrega, la evasión, el manejo de tokens/sesiones y las operaciones posteriores al compromiso bajo una configuración basada en suscripción que permite incluso a los actores de amenazas con poca o ninguna experiencia técnica orquestar campañas de phishing con un esfuerzo mínimo y en escala.

Se han observado cadenas de ataques que utilizan Forg365 utilizando señuelos con temas de documentos comerciales o de aprobación de remesas para engañar a los destinatarios para que hagan clic en enlaces maliciosos. El dominio del remitente utiliza Amazon SES para la entrega, mientras que el cuerpo del mensaje contiene imágenes alojadas en SendGrid o recursos de seguimiento.

Ciberseguridad

Los clientes que completan con éxito el registro de Telegram utilizan un panel de operador accesible a través de clearnet («logfriend[.]com/login»), desde donde pueden generar señuelos, configurar campañas y administrar tokens capturados.

«Forg365 incluye una rama de phishing de autenticación de dispositivo que presenta una página de códigos de verificación al estilo de Microsoft y empuja a la víctima a un flujo de inicio de sesión legítimo del Agente de autenticación de Microsoft», explicó ZeroBAC. «La víctima ve superficies de autenticación reales de Microsoft, pero el código autoriza una sesión controlada por el atacante».

Para el phishing de AitM, la plataforma emplea tokens de ruta, cookies de sesión y clasificación de tráfico para determinar si se entrega contenido de phishing o un señuelo benigno. Si se detecta una conexión VPN, el kit redirige a contenido señuelo inofensivo en lugar de exponer las páginas de phishing.

Un aspecto notable de la plataforma Forg365 es que ofrece una extensión llamada ForgCookie para navegadores basados ​​en Chromium como Google Chrome, Microsoft Edge y Brave que está diseñada para un acceso continuo a las cuentas comprometidas. Descrito como una «actualización automática de cookies SSO para los servicios de Microsoft», el complemento actúa como intermediario entre la adquisición del token y el acceso al navegador siguiendo los pasos que se enumeran a continuación:

  • Solicita datos de cuenta desde el backend de Forg365
  • Llama al punto final de generación de cookies para una cuenta seleccionada
  • Borra las cookies de sesión de Microsoft
  • Inyecta la cookie de credencial del token de actualización generada en el dominio de inicio de sesión de Microsoft.
  • Activa un flujo OAuth silencioso
  • Captura las cookies de Microsoft resultantes en todos los dominios de Microsoft

Forg365 va más allá de la simple recolección de credenciales y tokens para facilitar una amplia gama de acciones posteriores al compromiso, incluido el monitoreo de palabras clave específicas en cuentas de correo electrónico comprometidas y la redacción de una respuesta de mensaje a un hilo de correo electrónico en particular utilizando la ayuda de la IA.

«El resultado es una plataforma que reduce el umbral de habilidades al tiempo que aumenta la coherencia operativa. Los afiliados menos experimentados pueden usar plantillas prediseñadas, mientras que los operadores más capaces pueden personalizar las páginas de destino, rotar la infraestructura, administrar tokens, generar material de cookies y monitorear cuentas comprometidas», dijo ZeroBAC.

La divulgación coincide con el descubrimiento de varias campañas que emplean kits de phishing para el robo de credenciales.

  • Envío alertas falsas de actividad de cuentas de Microsoft desde una cuenta de remitente SaaS de terceros legítima pero comprometida para dirigir a los usuarios a páginas de phishing estilo Sneaky 2FA para iniciar una cadena de redireccionamiento que conduce al host de phishing final, no sin antes realizar comprobaciones para decidir si el visitante es un usuario real.
  • Usar correos electrónicos de phishing que dirigen a los destinatarios a un sitio web alojado en Canva, lo que luego activa el flujo de phishing del código del dispositivo para secuestrar cuentas de Microsoft utilizando el Kit de phishing Kali65. El kit admite más de 33 señuelos diferentes, un canal de pagos y una aplicación de escritorio llamada OctoLink Live (también conocida como Kali365 Live) que abusa del token robado para iniciar una sesión del navegador Chromium y abrir el buzón de correo de la víctima en OWA, OneDrive, SharePoint o admin.microsoft.com. La plataforma también ofrece una herramienta conocida como OctoLink Sender para enviar masivamente correos electrónicos de phishing desde la cuenta violada a otros contactos, una técnica llamada phishing lateral.
  • Campañas de phishing utilizando Kali365 También han distribuido páginas de phishing que se hacen pasar por el mensajero MAX de Rusia, lo que indica un intento de identificar a los usuarios en Rusia. «Un operador de phishing que puede convertir la apropiación de cuentas MAX en propagación tiene acceso a una de las mayores bases de mensajería instaladas en el mundo de habla rusa», Arctic Wolf dicho.
  • Envío de correos electrónicos que imitan al IRS y la Administración de la Seguridad Social, junto con Adobe, Microsoft, DocuSign y Dropbox, para entregar software legítimo de acceso remoto como ConnectWise ScreenConnect como parte de campañas de phishing utilizando un kit PhaaS llamado La cantera desarrollado, mantenido y vendido por un operador solitario llamado RockyBelling. El precio del kit oscila entre 500 y 3.000 dólares. Esto incluye herramientas como Rocky Gmail Sender (una herramienta de correo electrónico masivo), Rocky Email Sorter (para ordenar direcciones de correo electrónico por dominio en Gmail, Yahoo, Hotmail y AOL) y VioletRAT.
  • Envío mensajes SMS hacerse pasar por el Servicio Postal de EE. UU. (USPS) y UPS para engañar a las víctimas para que visiten una página de phishing que solicita a los usuarios que ingresen su información personal y financiera con el pretexto de una entrega fallida de un paquete y programar una nueva entrega. «Debajo del engaño, el kit captura datos en tiempo real», dijo Censys. «Abre un WebSocket de regreso a su origen y transmite los datos de la tarjeta de la víctima pulsación de tecla, ejecuta una búsqueda de BIN en el lado del servidor en el número de tarjeta y envía decisiones de enrutamiento (reintento, solicitud de PIN, solicitud de OTP, interruptor de apagado) de regreso al navegador de la víctima mientras escribe».
  • Usar flujos de trabajo de propuestas de ofertas falsas para hacerse cargo de las cuentas de Google mediante un marco llamado nyasher. La cadena de redireccionamiento incorpora una página de verificación de «presionar y mantener» para filtrar los escáneres y bots automatizados, antes de navegar a una URL de blob. «La página final mostraba una interfaz de inicio de sesión de Google, pero no era accesible como un documento HTML alojado normal», dijo ZeroBAC. «Existía como una URL de objeto creada por el navegador».
  • Uso de flujos de trabajo de inscripción falsos de Google Partners y Google Premier Partner en correos electrónicos de phishing para redirigir a los destinatarios a una página de inicio de sesión de Google falsa diseñada para capturar credenciales en tiempo real como parte de una campaña con nombre en código Tormenta GPPS.
  • Usar un alias de correo electrónico heredado para apuntar a la bandeja de entrada de un usuario e iniciar un flujo de phishing de código de dispositivo que utiliza el kit EvilTokens. «Se llegó al kit a través de un enlace de seguimiento de Mailjet, luego de un sitio de WordPress comprometido, luego de un intersticial CAPTCHA y luego del host de Cloudflare Workers», ZeroBAC dicho. «Tres saltos de infraestructura en vivo entre el cuerpo del correo electrónico y el kit, ninguno de los cuales es el kit en sí».
Ciberseguridad

Para contrarrestar estas amenazas, se recomienda bloquear la autenticación del código del dispositivo a menos que sea necesario, revisar los artefactos del buzón después de los eventos del código del dispositivo para detectar signos de actividad inusual, auditar las reglas de flujo de correo y retirar los alias heredados que ya no corresponden a empleados activos.

«La campaña logró llegar a la bandeja de entrada porque la organización destinataria aún mantenía una relación de reenvío activa desde un espacio de nombres previo a la adquisición a un buzón de correo actual», señaló ZeroBAC.

«El atacante utilizó una identidad histórica aún resoluble para entregar correo que, desde el punto de vista de la SEG, parecía correspondencia reenviada normal. Desde el punto de vista del usuario, el mensaje llegó a su bandeja de entrada de trabajo sin ninguna señal visible de que había tomado un camino indirecto».

Un servidor mal configurado revela tres operaciones de phishing de Evilginx dirigidas a Microsoft 365 – CYBERDEFENSA.MX

Un atacante que ejecutaba una operación de phishing en vivo de Microsoft 365 dejó un servidor web Python escuchando en un puerto público con la lista de directorios activada. El comando que lo hizo: python3 -m http.server 8080todavía estaba sentado en el legible .bash_history.

A partir de ese lapsus, la empresa de seguridad francesa lexfo levantó todo el conjunto de herramientas del operador y lo pasó a dos operadores de phishing más, tres campañas en total. Cada uno ejecutó una bifurcación personalizada del proxy Evilginx de código abierto, clonado del GitHub público.

El más grande de los tres había estado funcionando durante más de un año, y sus víctimas en su mayoría eran buzones corporativos.

Los tres superaron MFA de dos maneras mecánicamente diferentes: una mediante proxy del inicio de sesión en vivo y otra abusando de un flujo de inicio de sesión legítimo de Microsoft. Los dos necesitan defensas diferentes, que es la parte que más importa si ejecuta Microsoft 365.

La lista de directorios en un servidor de ataque en funcionamiento está cerca de ser una confesión completa. La lista exponía configuraciones de phishing, registros de recolección de credenciales, instaladores de RMM, listas combinadas, archivos de respaldo y los propios archivos de sesión de Telegram del operador.

Detrás de él se ejecutaba un proxy de adversario en el medio Evilginx y una consola remota SimpleHelp en el mismo host, en 185.163.204[.]7 en Budapest, catalogado a finales de abril de 2026 durante un escaneo de rutina en Internet.

El historial de bash y una serie de repositorios públicos apuntaban directamente al operador: un actor egipcio al que la empresa sigue como codificadoactivo en foros de piratería y VoIP desde 2018, ahora ejecuta una plataforma Microsoft 365 AiTM en picis[.]net y monetizar el acceso a través de un correo masivo que escribió llamado Blaster MaDoO.

Su campaña se puso en marcha el 20 de abril y continuó funcionando hasta el día en que se encontró el directorio, el 30 de abril, con nuevos subdominios y un certificado comodín renovado semanas después. Su propio robot registró capturas en dos cuentas corporativas de M365, una francesa y otra norteamericana.

Las capturas repetidas de las mismas cuentas de diferentes IP son consistentes, dice la firma, y ​​el operador actualiza los tokens robados a medida que caducan.

De dónde vinieron los kits

codemado no construyó el marco que ejecuta. Lo clonó y su historial de bash lo muestra comparando kits uno al lado del otro. El servidor contenía cuatro variantes de Evilginx extraídas de otros dos desarrolladores de GitHub, y ambos resultaron ser operadores activos por derecho propio.

La primera, reina rojaproviene de un operador nigeriano que el informe llama mail-argenta y muestra cuánto pulido se incorpora a un marco público. Su tenedor cambia el nombre del crossorigin y integrity Atributos HTML para anular las comprobaciones de integridad de los subrecursos y agrega un motor de reescritura de URL para http_proxy.go para esquivar la detección basada en rutas. Completa previamente la dirección de correo electrónico de la víctima para reducir el abandono.

También establece un TTL de un año, 31.536.000 segundos, en las cookies de sesión de Microsoft capturadas. El informe dice que un inicio de sesión interceptado puede durar más que un restablecimiento de contraseña y, sin una política de acceso condicional compatible con CAE, permanecer utilizable durante meses.

Un precompilado evilginx2.exe está comprometido con el repositorio, por lo que un comprador nunca tiene que construir nada. Una cookie M365 capturada que se encontraba en el repositorio tenía una fecha de vencimiento del 30 de junio de 2027.

correo-argenta Fue atrapado como lo hacen sus propias víctimas. La empresa encontró su correo electrónico y una contraseña en registros de robo de información, el tipo de datos de credenciales recopilados que sus paneles de phishing producen. Esa contraseña filtrada coincidía con la codificada como contraseña de MySQL en su panel Kraken y reutilizada en sus cuentas.

el tranquilo

El tercer tenedor, reina negraregistró muchas más capturas que los otros dos y nunca toca una contraseña. Su autor, a quien los investigadores no pudieron identificar más allá del identificador. sarola01lo creó en torno al flujo de código de dispositivo OAuth de Microsoft, una ruta de inicio de sesión legítima destinada a dispositivos con entrada restringida.

El ataque genera un código de dispositivo real, lo envuelve en una página señuelo con el tema del Autenticador y le dice al objetivo que lo ingrese en la página genuina. microsoft.com/devicelogin. La víctima inicia sesión en una página real de Microsoft y borra MFA por sí misma. El backend de saroula01 sondea el punto final del token y toma el token en el momento en que lo hace.

Llamar a esto «bypass de MFA» no comprende cómo funciona: no se omite nada. La página de señuelo tiene el tema de Authenticator y fue creada por el atacante, pero el código del dispositivo y la página de Microsoft donde termina la víctima son genuinos, por lo que el mensaje de MFA que la víctima satisface es real.

Una clave de acceso o FIDO2 tampoco ayuda, porque la víctima la borra en la infraestructura genuina de Microsoft mientras autoriza la sesión del atacante; el enlace de origen que detiene a Evilginx pasa limpiamente cuando el origen realmente es Microsoft.

microsoft documentó la técnica en febrero de 2025.en una campaña que evaluó con confianza media como alineada con Rusia. Desde entonces, se ha extendido mucho más allá del uso respaldado por el estado y ha llegado a campañas que afectan a cientos de organizaciones de Microsoft 365.

La versión de saroula01 funcionó silenciosamente durante más de un año. La empresa contó 218 cuentas capturadas distintas en los registros del bot de Telegram de la campaña en una docena de países entre junio de 2025 y julio de 2026, alrededor del 94 por ciento de ellas buzones de correo corporativos. Esas son capturas registradas, no objetivos de escaneo.

Un archivo de token enviado brevemente al repositorio y luego eliminado, aún legible en el historial de git, contenía 97 tokens de Microsoft activos vinculados a tres de esas víctimas, cada uno configurado para autoRefresh y algunos se actualizaron hasta 25 veces. El marco mantenía vivas las sesiones por sí solo.

Ambos dominios de phishing, picis.[.]neto y romnor[.]ca, estaban fuera de línea cuando The Hacker News revisó antes de la publicación, aunque la línea de tiempo del informe muestra fotografías.[.]net todavía aprovisiona nuevos subdominios en mayo de 2026. El equipo de Lexfo CTI le dijo a THN que los dominios ya se habían desconectado antes de tomar alguna medida, y lo interpreta como que los operadores rotan la infraestructura o se retiran en lugar de una eliminación coordinada, aunque no puede confirmar cuál.

Los tres se conectan, vagamente, con algo más grande. En junio de 2026, SOCRadar documentado un ecosistema de phishing como servicio al que llamó La canteraejecutado por un desarrollador al que llama RockyBelling y, según sus cálculos, vendido a cerca de 200 operadores.

MaDoO Blaster aparece promocionado dentro del canal Telegram de The Quarry como una herramienta de terceros, marcada de forma independiente en ambos artículos, que el informe enmarca como una relación con el proveedor, no como membresía en ella. Los artefactos no pueden demostrar si mail-argenta o saroula01 tienen algún vínculo directo. Sus kits estaban en GitHub público y cualquiera podría haberlos tomado.

Construido con ayuda

El informe encontró signos de desarrollo asistido por IA en las tres operaciones, aunque varían en intensidad. saroula01 dejó dos confirmaciones de git en coautoría con Claude Models. correo-argenta cometió un instructions.txt Se trata de una copia textual de una sesión de codificación de IA, con referencias a indicaciones anteriores y todo, que documenta cómo se creó la función de reescritura de URL.

El de Codemado es más delgado: créditos de uno de sus guiones CiberNeurovauna API paga de generación de código «sin censura», según el informe, que se anuncia con el mensaje «Constrúyeme un keylogger en Python». Dos de los tres pusieron un modelo directamente en el código; el tercero es una línea de crédito, y ninguno de ellos muestra cuánto de cada construcción hizo el modelo.

Tampoco se limita a estos tres. Microsoft ha documentado por separado Phishing de código de dispositivo basado en backend impulsado por IA Señuelos de automatización e IA generativa.

The Hacker News preguntó a los autores del informe cuántas herramientas de IA produjeron realmente en las tres operaciones. El equipo de Lexfo CTI dijo que las bifurcaciones de Evilginx solo llevaban cambios menores en el núcleo, y que los signos más claros del uso de IA se encontraban en el código adhesivo que los rodeaba, los scripts y los phishlets, varios de los cuales se leían como resultados directos del modelo. Según el equipo, no era tanto el marco en sí como el código creado a su alrededor.

¿Qué pueden hacer realmente los defensores?

Las dos técnicas no comparten una solución. MFA, FIDO2 o claves de acceso resistentes al phishing aún cierran el lado de Evilginx al vincular el inicio de sesión al dominio real. No detiene el abuso del código del dispositivo. Para eso, la palanca es Acceso Condicional.

La propia línea de Microsoft es bloquear el flujo de código del dispositivo siempre que sea posible. Un puñado de configuraciones realmente lo necesitan, en su mayoría hardware con restricciones de entrada, como dispositivos de sala de Teams y algunas herramientas de línea de comandos. Inventario que utiliza los registros de inicio de sesión, bloquea el flujo en todos los demás lugares y prueba la política en modo de solo informe antes de aplicarla.

Coloque políticas de ubicación de acceso condicional basadas en IP y evaluación de acceso continuo en la parte superior, de modo que en las cargas de trabajo compatibles de Microsoft 365, un token robado visto desde fuera de sus rangos permitidos se reevalúe en lugar de agotar su vida útil.

Para la detección, el informe marca las concesiones de tokens de actualización del ID de cliente de Microsoft Office. d3590ed6-52b3-4102-aeff-aad2292ab01c en los registros de inicio de sesión de Entra como dignos de atención, donde ese cliente de escritorio no está en uso normal; cotejarlos con direcciones IP de origen desconocidas.

La misma guía de Microsoft señala un problema: una sesión que comenzó con el flujo de código del dispositivo permanece etiquetada en actualizaciones posteriores incluso cuando el evento actual ya no lo muestra, así que busque en los registros Original transfer method campo, no solo el protocolo de autenticación en vivo.

En los endpoints, busque las herramientas RMM que estos operadores utilizan para lograr persistencia; El kit de Codemado llega a XEOX, así que comience con el agente en C:\Program Files (x86)\XEOX\xeox-agent_x64.exe y tareas programadas coincidentes *XEOX*Agent*Watchdog*. Los dominios y las IP están en el informe, pero esa infraestructura rota, así que trátelo como una contención, no como una solución.

Hacker News también preguntó a Microsoft sobre el abuso del flujo de código de su dispositivo y no había recibido respuesta al momento de la publicación. Esta historia se actualizará con cualquier respuesta.

Nada de esto requirió mucho: tres operadores, ninguno de los cuales construyó los marcos que ejecutaban, pusieron en marcha campañas de trabajo en repositorios públicos, kits que se venden por unos pocos cientos de dólares y un modelo que ayudaba con las piezas personalizadas.

El informe dice que la barrera para una campaña funcional ha caído a casi cero, y el equipo de Lexfo CTI espera que este tipo de ataque se vuelva significativamente más común en los próximos meses.

Un ecosistema barato ahora ofrece dos formas de evitar la MFA, y esa es la parte que dura más que cualquier campaña aquí: una tienda endurecida contra el phishing de proxy inverso todavía está abierta al abuso de códigos de dispositivos. Bloquear esa segunda ruta es una política de acceso condicional, no se agrega ninguna clave de acceso y existe solo una vez que alguien la escribe.

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

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

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

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

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

Ciberseguridad

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

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

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

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

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

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

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

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

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

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

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

Microsoft parchea la falla de RoguePlanet Defender que puede otorgar privilegios del SISTEMA – CYBERDEFENSA.MX

Microsoft ha publicado actualizaciones de seguridad para una vulnerabilidad de Defender conocida como RoguePlanet, casi un mes después de que los detalles de la falla se hicieran públicos.

La vulnerabilidad, rastreada como CVE-2026-50656 (puntuación CVSS: 7,8), es un problema de escalada de privilegios en Microsoft Malware Protection Engine («mpengine.dll»), que proporciona capacidades de escaneo, detección y limpieza para su software antivirus y antispyware.

El problema se solucionó en Microsoft Malware Protection Engine versión 1.1.26060.3008, junto con actualizaciones de defensa en profundidad para reforzar características relacionadas con la seguridad no especificadas.

RoguePlanet fue revelado por primera vez por un investigador de seguridad llamado Chaotic Eclipse (también conocido como Nightmare-Eclipse), y lo describió como una condición de carrera de la que se podría abusar para generar un shell con privilegios a nivel de SISTEMA. Esto, a su vez, otorga al atacante la capacidad de ejecutar código arbitrario o realizar acciones no autorizadas.

Ciberseguridad

Se ha descubierto que el exploit funciona en sistemas que ejecutan versiones actualizadas de Windows con las actualizaciones del martes de parches de junio de 2026 instaladas. Posteriormente, Chaotic Eclipse también reveló que el exploit funciona independientemente de si la protección en tiempo real está activada o no. Microsoft no ha acreditado oficialmente a Chaotic Eclipse por el descubrimiento de la vulnerabilidad.

RoguePlanet es la cuarta vulnerabilidad de Defender revelada por el investigador después de BlueHammer (CVE-2026-33825), UnDefend (CVE-2026-45498) y RedSun (CVE-2026-41091), todas las cuales desde entonces han sido parcheadas por Microsoft.

El fabricante de Windows dijo que no se requiere ninguna acción por parte del cliente para instalar la actualización para CVE-2026-50656, ya que el software se actualiza con frecuencia para proteger a los clientes contra amenazas nuevas y en evolución.

«Para implementaciones empresariales así como para usuarios finales, la configuración predeterminada en el software antimalware de Microsoft ayuda a garantizar que las definiciones de malware y el motor de protección contra malware de Microsoft se mantengan actualizados automáticamente», dijo Microsoft.

«Dependiendo del software antimalware de Microsoft que se utilice y de cómo esté configurado, el software puede buscar actualizaciones de motores y definiciones todos los días cuando esté conectado a Internet, hasta varias veces al día. Los clientes también pueden optar por buscar actualizaciones manualmente en cualquier momento».

Las herramientas DEBULL abusan del flujo de código de dispositivo de Microsoft para apuntar a cuentas M365 – CYBERDEFENSA.MX

Se ha observado una campaña de phishing de código de dispositivo Microsoft 365 que aprovecha señuelos con temas de colaboración para tomar el control de las cuentas de las víctimas entre la última semana de junio de 2026 y principios de julio, según recomendaciones de ZeroBEC.

«La campaña no dependía de una página de contraseña falsa de Microsoft. Utilizó un señuelo malicioso de estilo colaborativo para empujar a los usuarios a la experiencia legítima de inicio de sesión del dispositivo Microsoft, mientras que un agente backend generaba y sondeaba tokens de código de dispositivo del Agente de Autenticación de Microsoft», dijo la compañía de seguridad de correo electrónico en un informe compartido con The Hacker News.

Se evalúa que la actividad comparte superposiciones «fuertes» con una campaña documentada por Microsoft en febrero de 2025 bajo el nombre de Storm-2372, incluido el uso de mensajes o señuelos estilo Teams para engañar a víctimas desprevenidas para que ingresen un código de dispositivo proporcionado por el atacante, junto con sus credenciales, lo que permite efectivamente al actor de amenazas recuperar el token y secuestrar su cuenta.

A pesar de estas similitudes, se evalúa que los actores de amenazas están empleando técnicas de estilo Storm-2372 a través de lo que se ha descrito como una capa de herramientas reutilizable llamada DEBULL.

El phishing de código de dispositivo se refiere a una técnica de robo de identidad en la que los atacantes explotan un mecanismo de autenticación OAuth 2.0 legítimo, específicamente el flujo de concesión de autorización de dispositivo, para evitar la autenticación multifactor (MFA) y obtener acceso persistente a la cuenta sin tener que robar las contraseñas de los usuarios.

A diferencia de los ataques de phishing tradicionales que requieren que los operadores configuren páginas de inicio de sesión falsas de adversario en el medio (AitM), el phishing de código de dispositivo se basa en manipular a un usuario para que complete un mensaje de autenticación real y confiable.

Ciberseguridad

Autenticación de código de dispositivo, por microsoftes un flujo OAuth legítimo diseñado para dispositivos con interfaces limitadas, como televisores inteligentes o impresoras, que no pueden admitir un inicio de sesión interactivo tradicional. En este escenario, al usuario se le presenta un código corto en el dispositivo desde el que intenta iniciar sesión y se le solicita que ingrese ese código en un navegador web en un dispositivo separado para completar la autenticación.

Los actores de amenazas tienen abusado esta separación para insertarse y iniciar el flujo de autenticación. Luego, comparten ese código con el objetivo a través de un señuelo de phishing. Así, cuando el usuario ingresa el código, autoriza la sesión del actor de la amenaza sin su conocimiento, otorgándole acceso a la cuenta.

«El phishing del código del dispositivo no se abre camino», Huntress notas. «Utiliza un flujo de autenticación legítimo para atravesar la puerta principal, sin necesidad de contraseña, sin pasar por MFA y con tokens de sesión entregados directamente al atacante».

Los ataques exitosos de phishing de código de dispositivo pueden facilitar la apropiación total de la cuenta, el robo de información valiosa, el fraude, el compromiso del correo electrónico empresarial (BEC), el movimiento lateral dentro de un entorno comprometido e incluso ataques disruptivos como el ransomware.

«En la mayoría de los ataques de phishing de código de dispositivo actuales, el código se genera dinámicamente cuando un usuario hace clic en el enlace de phishing inicial. Este cambio aparentemente pequeño permite al usuario ver el correo electrónico en cualquier momento para iniciar la cadena de ataque», Proofpoint dicho en un análisis publicado en mayo de 2026. «Estas nuevas implementaciones de las cadenas de ataque de código de dispositivo se pueden comprar a través de ofertas de phishing como servicio (PhaaS), como EvilTokens o Tycoon, o pueden ser creadas y propiedad del actor de amenazas que realiza las campañas».

También se sabe que estas campañas aprovechan el salto de toma de control de cuenta (ATO), una técnica en la que un atacante compromete una cuenta de correo electrónico inicial y luego abusa de ella para enviar enlaces de phishing a un conjunto más amplio de contactos en forma de botón, texto con hipervínculo, incrustado en un documento o código QR. Los enlaces, cuando los visita el destinatario, inician una secuencia de ataque que emplea el proceso de autorización de dispositivos de Microsoft.

ZeroBEC dijo que la campaña que observó implica el uso de pretextos de pago y carpetas compartidas en correos electrónicos de phishing para engañar a las víctimas para que hagan clic en una URL que las lleva a un sitio web de alquiler croata legítimo pero comprometido, que, a su vez, actúa como un orquestador de códigos de dispositivos utilizado para iniciar la cadena de desafío de códigos de dispositivos de Microsoft.

El flujo de trabajo se caracteriza por la presencia de marcadores de desarrollador en idioma turco, aunque las pistas no son suficientes para atribuir definitivamente la procedencia de la campaña. Un análisis más detallado de la infraestructura ha revelado que DEBULL es probablemente una plataforma de phishing como servicio (PhaaS) que utiliza GraphSpy o un flujo de trabajo derivado de GraphSpy para Microsoft 365 y Entra post-explotación.

«Los operadores pueden definir un nombre de página y un slug, editar HTML, CSS y JavaScript directamente y luego elegir cómo se publica el señuelo», dijo ZeroBEC. «Las plantillas integradas incluían una página de autenticación de código de dispositivo de Microsoft 365, una página de devolución de llamada de OAuth y una página de inicio moderna. La plantilla de Microsoft 365 es especialmente importante porque expone el bloque de construcción exacto utilizado por la campaña: una visualización del código de usuario, un comportamiento de copia de código y un vínculo para iniciar sesión en el dispositivo de Microsoft».

«La conclusión más útil es que el arte de identidad al estilo Storm-2372 ahora se está empaquetando en una infraestructura de corredor reutilizable. DEBULL proporciona la capa orientada a la campaña y al operador. GraphSpy o el código derivado de GraphSpy probablemente maneja la capa posterior a la autenticación. El atractivo se puede cambiar sin cambiar la pila de identidades del backend».

La divulgación se produce como lo dijo Cisco Talos. identificado un panel de operador PhaaS con todas las funciones llamado ARToken que comparte infraestructura, contratos API y patrones operativos con la plataforma de phishing de código de dispositivo EvilTokens y está disponible para los afiliados.

Ciberseguridad

«El panel ARToken expone más de 80 puntos finales API para phishing de códigos de dispositivos, persistencia de tokens de actualización primaria (PRT), acceso a correo electrónico, operaciones de compromiso de correo electrónico empresarial (BEC) y exfiltración de SharePoint, todo accesible para los operadores a través de un panel basado en React», dijo Talos.

EvilTokens, como DEBULL, permiten a los atacantes utilizar tokens recolectados como armas para filtrar correos electrónicos, archivos y otros datos confidenciales de cuentas de Microsoft comprometidas, realizar reconocimientos a través de Microsoft Graph API y establecer acceso persistente. Además, incorpora Funciones impulsadas por inteligencia artificial (IA) para automatizar y escalar los flujos de trabajo de BEC, como examinar miles de correos electrónicos recopilados, identificar hilos de correo electrónico relacionados con finanzas y redactar borradores de correos electrónicos de BEC.

ARToken funciona como un conjunto de herramientas completo posterior al compromiso que permite a los operadores aprovechar el token de acceso capturado recuperado luego de una autenticación exitosa del código del dispositivo para mantener el acceso, realizar operaciones de correo electrónico, acceder a OneDrive y SharePoint, y explorar las sesiones de Microsoft 365 de las víctimas fuera del panel utilizando una herramienta dedicada conocida como ARTBrowser.

«Estas características indican que la plataforma es más madura que un simple kit de phishing de código de dispositivo: es un entorno de operaciones BEC completo», dijo el investigador de Talos, Michael Kelley.

El aumento de los ataques de phishing de códigos de dispositivos también ha llevado a otros kits PhaaS como Tycoon 2FA a adoptar la técnica para secuestrar cuentas de Microsoft 365 en sus rebote después de una operación policial, lo que indica un cambio más amplio dentro del panorama de amenazas.

«Los operadores de Tycoon 2FA han reutilizado su kit PhaaS existente como marco de entrega para el phishing de concesión de código de dispositivo OAuth», eSentire anotado en mayo de 2026. «El ataque comienza cuando una víctima hace clic en una URL de seguimiento de clics de Trustifi en un correo electrónico atractivo y culmina cuando la víctima, sin saberlo, otorga tokens OAuth a un dispositivo controlado por el atacante a través del flujo legítimo de inicio de sesión del dispositivo de Microsoft en microsoft.com/devicelogin».