Los paquetes npm vinculados a Corea del Norte imitan los Polyfills acumulativos para robar secretos de los desarrolladores – CYBERDEFENSA.MX

Los actores de amenazas con vínculos con Corea del Norte han sido vinculados a un nuevo conjunto de paquetes npm maliciosos que se hacen pasar por herramientas Rollup polyfill para facilitar el acceso remoto y el robo de datos.

Según JFrog, los paquetes «rollup-packages-polyfill-core» y «rollup-runtime-polyfill-core» imitan el legítimo «nodo-polyfill-del-complemento acumulativo«proyecto, hasta la descripción, los metadatos del repositorio y la forma del paquete.

«Los paquetes similares se ubican en el mismo espacio de nombres de rollup, polyfill, núcleo y nodo, lo que puede parecer plausible durante una revisión rápida de dependencia», JFrog dicho en un informe técnico de la campaña.

La campaña también involucra otros cuatro paquetes, todos los cuales han sido eliminados del registro npm:

  • ficha peculiar
  • reaccionar-icono-svgs
  • complemento-rollup-polyfill-connect
  • flujo de análisis rápido

Lo que es digno de mención aquí es que «rollup-packages-polyfill-core» instala y carga «swift-parse-stream», mientras que «rollup-runtime-polyfill-core» instala y «quirky-token». De manera similar, se ha descubierto que «react-icon-svgs» instala «rollup-plugin-polyfill-connect» como segunda etapa.

Ciberseguridad

«Los paquetes de la segunda etapa son utilidades SVG casi idénticas que obtienen un objeto JSON de JSONKeeper y evalúan el campo del modelo», dijo la compañía de ciberseguridad. «Esta estructura en capas, junto con los nombres parecidos, los metadatos de apariencia legítima, la ejecución oculta en el momento de la instalación, las comprobaciones del entorno y las cargas útiles de robo de credenciales/acceso remoto, es similar a campañas anteriores de npm vinculadas a Lazarus de Corea del Norte».

Vale la pena enfatizar aquí que esta no es la primera vez que los actores de amenazas norcoreanos cargan paquetes npm que se hacen pasar por herramientas Rollup Polyfill. En abril de 2026, Panther detalló una campaña sostenida de npm que implicó la publicación de 108 paquetes npm maliciosos que abarcan 261 versiones para entregar BeaverTail y OtterCookie, dos conocidas familias de malware vinculadas a Contagious Interview. Entre esos paquetes se encontraba «rollup-plugin-polyfill-route», que se publicó el 20 de marzo de 2026.

El punto de partida del ataque es un comando de instalación npm codificado en Base64 para «swift-parse-stream» (o «quirky-token») que está oculto dentro de «rollup-packages-polyfill-core» (o «rollup-runtime-polyfill-core»). Los dos paquetes de la segunda etapa están disfrazados de utilidades de desinfección de SVG, mientras acceden a una URL de JSON Keeper para recuperar y ejecutar un malware de JavaScript.

El código JavaScript ejecuta comprobaciones para evitar la ejecución en entornos de desarrollo en la nube, entornos sandbox, tiempos de ejecución sin servidor e infraestructura de análisis. Pasada esta puerta, el malware instala las dependencias necesarias y llega a un servidor externo («216.126.236[.]244») para recuperar una carga útil de JavaScript cifrada.

Luego, la carga útil descifrada actúa como un cargador de secuencias de comandos adicionales responsables de permitir el acceso remoto al host comprometido para admitir sesiones de terminal interactivas, ejecución de comandos, captura de pantalla, terminación de procesos, movimiento del mouse solo para Windows, clics, desplazamiento, pulsaciones de teclado y teclas de acceso rápido usando el paquete «@nut-tree-fork/nut-js», así como robar datos de navegadores web y billeteras de criptomonedas, recopilar archivos que coincidan con extensiones específicas y capturar periódicamente el contenido del portapapeles.

Las características se superponen con las de OtterCookie, y el uso de «@nut-tree-fork/nut-js» para el control remoto del mouse y el teclado también se observa en un paquete llamado «express-session-js» que fue detallado por SafeDep en abril de 2026. Se ha descubierto que el componente recopilador de archivos busca específicamente el historial del editor asociado con Microsoft Visual Studio Code, Windsurf y Cursor, junto con configuraciones de herramientas de inteligencia artificial y desarrolladores, como AWS, Microsoft Azure, Google Gemini, Anthropic Claude, Foundry, SSH y Z shell (Zsh).

«Los complementos acumulativos se cargan comúnmente desde archivos de configuración locales, estaciones de trabajo de desarrolladores y trabajos de CI», dijo JFrog. «Estos entornos a menudo tienen acceso a activos confidenciales como código fuente, tokens npm, credenciales de Git, claves de nube, claves SSH, datos del navegador y secretos de proyectos».

«La carga útil también es más amplia que un simple descargador. Una vez que se ejecutan las etapas posteriores, el atacante obtiene capacidades de recopilación y control. Esto hace que la carga útil sea relevante para las estaciones de trabajo de los desarrolladores y las máquinas de construcción, donde las claves API, las claves SSH, el material de la billetera, las credenciales de la nube y los secretos del proyecto a menudo están presentes».

Ciberseguridad

La divulgación coincide con el descubrimiento de múltiples ataques a la cadena de suministro de software por parte de Checkmarx, SafeDep y el investigador de seguridad de AWS, Chi Tran, destinados a envenenar repositorios de paquetes de código abierto y robar datos valiosos.

  • Un grupo de al menos ocho horquillas «pirograma» troyanizadas publicado por un actor de amenazas que opera bajo múltiples identidades entre noviembre de 2025 y junio de 2026, incluida una puerta trasera oculta que les otorga control remoto total sobre cualquier servidor que ejecute el paquete PyPI infectado mediante la ejecución de código Python arbitrario o comandos de shell enviados por el atacante. Los resultados de la ejecución del comando se filtran a través de Telegram. Checkmarx ha denominado a la actividad Operación Fantasma de la Marina.
  • un grupo de paquetes de 30 npm imitando las herramientas de Polymarket y las bibliotecas de matemáticas generales publicadas por cuentas de mantenimiento de 10 npm que apuntaban a los desarrolladores de DeFi para entregar un ladrón de información de JavaScript que lee bóvedas de billeteras criptográficas, credenciales del navegador, claves SSH, credenciales de AWS, tokens npm, configuraciones de Docker, historial de shell y bases de datos del administrador de contraseñas.
  • un grupo de paquetes de 25 npm publicado bajo el alcance @marketfront por una cuenta npm llamada «marketfront» que contiene un recolector de credenciales posterior a la instalación que lee 20 archivos secretos y de credenciales, incluidos ~/.ssh, ~/.aws/credentials, ~/.kube/config, ~/.docker/config.json, ~/.npmrc, ~/.netrc, ~/.pgpass, ~/.git-credentials, ~/.env y shell historial y extrae los datos.
  • Un paquete de Python llamado «alertas-de-seguridad-sdk» que afirma ser una herramienta de monitoreo de violaciones de datos pero alberga un código para iniciar una puerta trasera que sondea periódicamente un servidor externo («142.93.211[.]30:5000») para comandos y filtra claves privadas SSH, credenciales de AWS, tokens Docker/npm/PyPI/git, archivos .env y bases de datos de credenciales del navegador al mismo servidor.
  • un grupo de paquetes de 15 npm publicado por un único actor de amenazas que opera bajo alcances de 13 npm que activa una carga útil de JavaScript posterior a la instalación responsable de descargar y ejecutar un binario ELF compilado por Rust alojado en GitHub, que luego recopila una amplia gama de datos de billeteras de criptomonedas, navegadores web y otras aplicaciones, incluidos tokens de proveedores de nube, claves SSH, sesiones de plataformas de mensajería, configuraciones de clientes de bases de datos y credenciales de desarrollador.
  • Un paquete npm llamado «tiempo de ejecución de eventos» que escribe en cuclillas «eventos» y genera condicionalmente un ladrón de billeteras de criptomonedas, filtra datos de reconocimiento del host a través de Slack y Telegram, abre un canal de comando bidireccional de Slack y lee fragmentos de configuración y carga útil de un contrato inteligente de Ethereum utilizado como solucionador de entrega muerta. La lógica maliciosa se activa solo cuando el ID del evento es «eventId0».
  • Un paquete npm llamado «o3formas» que roba las credenciales del proveedor de servicios en la nube, escanea los secretos de los desarrolladores y los entornos CI/CD, realiza un reconocimiento de la red interna y exfiltra los datos a un punto final de Cloudflare Workers controlado por el atacante. «El atacante dividió el ataque en un paquete publicado en el registro deliberadamente benigno y una subdependencia *-utils fijada en GitHub que lleva tanto los ganchos de instalación como el malware real», dijo Tran. «Esta estructura está diseñada específicamente para derrotar el script estático y del ciclo de vida escaneo en el que se basan la mayoría de las herramientas del lado del registro y del lado CI».

Se recomienda a los usuarios que hayan instalado cualquiera de los paquetes antes mencionados que los eliminen de sus estaciones de trabajo, asuman compromisos y roten las credenciales, bloqueen los canales de salida maliciosos y habiliten el escaneo de dependencias en las canalizaciones de CI/CD para marcar paquetes sospechosos o recién publicados.

Likho blindado apunta a agencias gubernamentales y al sector energético con BusySnake Stealer – CYBERDEFENSA.MX

Un actor de amenazas previamente indocumentado conocido como Likho blindado se ha atribuido a ataques cibernéticos dirigidos a agencias gubernamentales y al sector de energía eléctrica en Rusia, Brasil y Kazajstán.

«Armored Likho combina campañas motivadas financieramente dirigidas a particulares con ciberespionaje dirigido a organizaciones», Kaspersky dicho en un análisis técnico publicado hoy. «Su conjunto de herramientas incluye RAT modulares ofuscados y ladrones de información diseñados específicamente para eludir el análisis dinámico».

Los ataques también se caracterizan por el uso de herramientas como Go2Tunnel para acceso remoto y tunelización de red. La amplia variedad de herramientas en su arsenal permite al actor de amenazas mantener un acceso persistente a los hosts comprometidos, robar credenciales y datos confidenciales y entregar dinámicamente módulos adaptados al perfil de la víctima.

El proveedor ruso de ciberseguridad dijo que Armored Likho comparte posibles superposiciones con un grupo de amenazas rastreado por BI.ZONE bajo el nombre de Eagle Werewolf, que ha estado activo desde mayo de 2023. El grupo de hackers tiene un historial de apuntar a organizaciones gubernamentales y de defensa, específicamente aquellas involucradas en el desarrollo y fabricación de vehículos aéreos no tripulados, utilizando cuentagotas, troyanos de acceso remoto (RAT) y utilidades para establecer túneles SSH.

«Los actores de amenazas pueden utilizar canales de Telegram comprometidos para distribuir el malware», BI.ZONE notas en su descripción del actor de la amenaza. «Si bien la principal motivación del grupo es el ciberespionaje, también se han registrado campañas destinadas a robar fondos a las víctimas».

En febrero de 2026, se observó a Eagle Werewolf comprometiendo un canal de Telegram centrado en drones para distribuir AquilaRAT a través de un cuentagotas Rust que se hace pasar por una lista de verificación para la activación del dispositivo Starlink. También se utiliza en los ataques Go2Tunnel para establecer un túnel SSH inverso a un servidor de comando y control (C2) utilizando una clave privada.

Ciberseguridad

Los últimos hallazgos muestran que el actor de amenazas también ha empleado un ladrón de información basado en Python no reportado anteriormente llamado BusySnake Stealer dirigido a sistemas Windows, una versión del cual incluye un módulo para robar cookies de navegadores web. Los orígenes exactos del Likho Blindado siguen siendo desconocidos.

El punto de partida de la cadena de ataque es un correo electrónico de phishing que utiliza señuelos relacionados con avisos oficiales del gobierno o programas sociales para distribuir un archivo RAR que contiene binarios EXE que sirven como goteros para cargas útiles adicionales recuperadas de un repositorio de GitHub, incluida la carga útil del ladrón.

El malware dropper también crea dos archivos Visual Basic Script (VBScript) que son responsables de borrar los rastros de la ejecución inicial, así como de iniciar el ladrón mediante una tarea programada.

Las cadenas alternativas utilizan accesos directos de Windows (LNK) en lugar de cargas EXE que convierten en arma una vulnerabilidad ahora parcheada relacionada con la forma en que Windows maneja dichos archivos, lo que resulta en la ejecución remota de código. El defecto, rastreado como CVE-2025-9491 (también conocido como ZDI-CAN-25373) fue abordado por Microsoft como parte de sus actualizaciones del martes de parches para noviembre de 2025. La evidencia descubierta por Trend Micro el año pasado reveló que la deficiencia había sido utilizada como arma por una docena de grupos de piratas informáticos desde 2017.

En la cadena de ataque documentada por Kaspersky, se abusa de la vulnerabilidad del acceso directo para desencadenar la ejecución de un comando PowerShell ofuscado que lanza un cargador responsable de mostrar un documento señuelo, mientras prepara el entorno para la ejecución del ladrón de Python. Luego, el malware establece persistencia mediante una combinación de un archivo VBScript y una tarea programada, como antes.

El ladrón, llamado BusySnake, implementa múltiples técnicas de evasión para complicar el análisis estático y la detección de elusiones. Su objetivo principal es establecer comunicación con un servidor C2 y luego esperar instrucciones entrantes. También admite la siguiente funcionalidad:

  • Robar datos del portapapeles del sistema.
  • Enumere archivos en todo el sistema y registre sus metadatos en una base de datos local.
  • Cargue documentos de usuario al servidor C2.
  • Realice capturas de pantalla y colóquelas en un directorio local.
  • Archive las capturas de pantalla capturadas y elimine los archivos creados previamente del disco.
  • Evite que se ejecuten varias instancias del ladrón simultáneamente en el host infectado.
  • Garantice la persistencia comprobando si la tarea programada existe y, en caso contrario, elimine un VBScript para registrar una nueva tarea programada.

Además, los comandos emitidos por el servidor C2 le permiten tomar capturas de pantalla en un intervalo designado, registrar datos de pulsaciones de teclas, recopilar archivos de billetera de criptomonedas con una extensión JSON, recopilar datos de credenciales y sesiones de Telegram, establecer un túnel SSH inverso usando Go2Tunnel, instalar RustDesk y extraer cookies de los navegadores basados ​​en Mozilla Firefox y Chromium, junto con las contraseñas.

Si RustDesk ya está instalado en la máquina, se inicia el software de escritorio remoto de código abierto y se le solicita a la víctima que ingrese sus credenciales, luego de lo cual el ladrón toma una captura de pantalla de las credenciales y las filtra al servidor C2.

«El malware descifra dinámicamente su código de bytes sólo en el momento exacto en que se llama a una función, volviendo a cifrar los datos inmediatamente después», dijo Kaspersky. «Además, el malware se ejecuta en segundo plano sin generar una ventana de consola, como lo indica su extensión de archivo PYW».

Ciberseguridad

Kaspersky dijo que también identificó una versión más nueva de BusySnake que itera sobre el diseño arquitectónico del predecesor para incluir un nuevo marco de administración de tareas para manejar los comandos C2 entrantes y asignarles dinámicamente estados operativos, como PROGRAMADO, EN PROGRESO, EXITOSO o FALLADO, para mejorar los informes al servidor.

Los vínculos del actor de amenazas con Eagle Werewolf también surgen de superposiciones entre AquilaRAT y BusySnake Stealer, particularmente en la forma en que ambas familias de malware reciben tareas del servidor C2, registran persistencia a través de tareas programadas y utilizan puntos finales similares para las comunicaciones C2.

También hay indicios de que las cargas útiles de la primera etapa, que comprenden cargadores y etapas, probablemente se generaron con la ayuda de herramientas de inteligencia artificial (IA), dada la presencia de comentarios y bloques de código redundantes.

«Esta campaña destaca varias tendencias concurrentes: la creciente madurez técnica de Armored Likho, el polimorfismo de herramientas y un cambio hacia esquemas más complejos destinados a eludir las soluciones de seguridad, que van desde la ofuscación del código fuente de Python hasta la incorporación de mecanismos de red directamente en el código de malware», dijo Kaspersky.

«En paralelo, el grupo está refinando y modificando agresivamente su conjunto de herramientas principal. Si bien Go2Tunnel anteriormente operaba como una utilidad independiente, su funcionalidad de túnel inverso ahora se ha integrado directamente en el ladrón como una característica incorporada que ingiere parámetros del servidor C2».

Miembro del Parlamento Europeo que investiga el software espía fue pirateado con Pegasus – CYBERDEFENSA.MX

Un nuevo informe del Citizen Lab ha revelado que el dispositivo móvil del ex miembro del Parlamento Europeo Stelios Kouloglou fue pirateado repetidamente con el famoso software espía Pegasus mientras formaba parte de un comité encargado de investigar el abuso de este tipo de herramientas de vigilancia comercial en el bloque.

«A través del análisis forense de su dispositivo, descubrimos que los atacantes podrían haber tenido acceso a documentos confidenciales y a deliberaciones del comité», dijeron los investigadores del Citizen Lab John Scott-Railton, Bill Marczak, Bahr Abdul Razzak, Kate Pundyk, Siena Anstis y Ron Deibert. dicho.

Las infecciones no se han atribuido a ningún gobierno en particular hasta el momento y no hay evidencia de que el gobierno griego esté detrás de la actividad. Sin embargo, el laboratorio de investigación interdisciplinario canadiense señaló que identificó una superposición entre la primera infección y una campaña anterior dirigida a periodistas y activistas de habla rusa y bielorrusa exiliados en Europa.

Esto indica que un cliente de Pegasus con autorización para espiar en varios países europeos probablemente sea responsable del esfuerzo, añadió Citizen Lab.

Kouloglou era un miembro del «Comité de investigación para investigar el uso de Pegasus y software espía de vigilancia equivalente» del Parlamento Europeo del 24 de marzo de 2022 al 18 de julio de 2023. El Comité PEGA fue configuración el 10 de marzo de 2022, para investigar presuntos usos indebidos de las ofertas comerciales de software espía según la legislación de la UE, centrándose específicamente en recopilar información sobre hasta qué punto los estados miembros y otros países están utilizando dichas herramientas en contravención de los derechos y libertades de la región.

Ciberseguridad

Citizen Lab dijo que un análisis forense de los artefactos recopilados de su iPhone en mayo de 2026 encontró que estaba comprometido con el software espía Pegasus alrededor del 21 de octubre de 2022, y nuevamente el 6 y 7 de marzo de 2023.

«El 21 de octubre de 2022 a las 10:16, se buscó una dirección de correo electrónico de HomeKit rauharepo888[@]gmail.com. Dos minutos más tarde, un proceso de Pegasus utilizó datos móviles», explicaron los investigadores. Se ha evaluado que un exploit sin clic en el software de hogar inteligente de Apple, con nombre en código PWNYOURHOME, se utilizó para entregar el software espía. Apple solucionó el problema en iOS 16.3.1.

También se dice que la actividad posterior de Pegasus observada en marzo de 2023 convirtió el mismo exploit en un arma. En ambos momentos, el dispositivo de Kouloglou ejecutaba iOS 15.5. Un análisis más detallado del teléfono reveló que Kouloglou recibió notificaciones de amenazas de Apple sobre haber sido atacado con software espía mercenario en tres ocasiones: el 2 de marzo de 2023, el 29 de agosto de 2023 y el 10 de abril de 2024.

Curiosamente, durante la primera vez que el teléfono de Kouloglou fue pirateado, fue ingresado en un hospital para una cirugía electiva y había sido visitado por el periodista de investigación griego Thanasis Koukakis, quien tenía su propio teléfono comprometido con el software espía Predator de Intellexa y había testificó ante el Comité PEGA un mes antes.

El momento de la segunda infección en marzo de 2023 también es significativo, ya que coincidió con las intensas discusiones relacionadas con el proceso de redacción final, seguidas de una serie de audiencias de PEGA. El incidente tuvo lugar dos meses antes de la adopción del primer informe del Comité PEGA.

Este hecho marca la primera vez que un miembro del Comité PEGA ha sido identificado públicamente como víctima del software espía Pegasus mientras formaba parte del comité.

La conexión entre el caso de Kouloglou y la campaña dirigida a periodistas independientes y activistas de la oposición de habla rusa y bielorrusa radicados en Europa se basa en el uso de la misma dirección de correo electrónico «rauharepo888[@]gmail.com.»

«Según nuestro conocimiento de la infraestructura de infección de Pegasus durante este período, creemos que estos correos electrónicos son exclusivos de operadores específicos», dijo Citizen Lab. «No podemos decir si la segunda infección en 2023 está relacionada de manera similar con este operador o con otro operador».

«Según lo que sabemos de la licencia del Grupo NSO, esto probablemente indicaría que el cliente tenía una licencia que permitía infecciones en múltiples jurisdicciones de la UE, reduciendo la lista de posibles operadores de Pegasus que podrían ser responsables de este caso».

Los hallazgos plantean nuevas preocupaciones sobre cómo los gobiernos aprovechan el software espía aparentemente comercializado para combatir delitos graves, como el terrorismo y el abuso sexual infantil, para espiar las comunicaciones de periodistas, legisladores, disidentes y críticos.

El desarrollo se produce días después de que Citizen Lab revelara que las autoridades rusas utilizaron las herramientas forenses UFED de Cellebrite para ingresar al iPhone del activista opositor detenido Andrey Pivovarov en junio de 2021, tres meses después de que Cellebrite anunciara que dejaría de ofrecer sus herramientas y servicios a Rusia y Bielorrusia.

«Las autoridades buscaron en los dispositivos de Pivovarov organizaciones y contactos clave, así como figuras destacadas de la oposición», dijo el Citizen Lab. «Los términos de búsqueda incluyeron a Mikhail Khodorkovsky, quien fundó Open Russia, Anastasiya Burakova, quien en ese momento era abogada de derechos humanos en Open Russia y actualmente dirige un destacado grupo contra la guerra, y la ex coordinadora de Open Russia y socia de Pivovarov, Tatiana Usmanova».

Ciberseguridad

Algunas de estas personas, incluida Burakova, fueron posteriormente objetivo de una campaña de phishing orquestada por un grupo de hackers ruso conocido como COLDRIVER, lo que plantea la posibilidad de que el uso de las herramientas de Cellebrite haya ayudado a facilitar el reconocimiento y permitir una mayor focalización y vigilancia de otros opositores al régimen en el extranjero.

En abril, el Citizen Lab también descubierto dos campañas de espionaje distintas y de larga duración que están abusando de conocidas debilidades en la infraestructura global de telecomunicaciones para rastrear la ubicación de las personas. En particular, estos ataques no requieren la implementación de malware, lo que los hace sigilosos y más difíciles de detectar.

Una de las dos campañas funcionó enviando un tipo especial de mensaje de texto con comandos SMS ocultos maliciosos a los objetivos en un esfuerzo por «convertir el dispositivo en una baliza de seguimiento encubierta», según el informe. La segunda campaña se basó en debilidades en los protocolos de señalización del Sistema de Señalización No. 7 (SS7) y Diámetro para rastrear el paradero de un individuo sin requerir acceso a sus dispositivos.

Se dice que las dos campañas han abusado de tres proveedores de telecomunicaciones específicos, a saber, 019Mobile, Airtel Jersey (parte de Sure Group) y Tango Networks UK, que actúan como «puntos de entrada y tránsito de vigilancia dentro del ecosistema de telecomunicaciones» y «permiten que el tráfico se mueva a través de interconexiones de señalización confiables al tiempo que otorgan acceso a actores de amenazas que se esconden detrás de su infraestructura».

«Ambos actores utilizaron herramientas de vigilancia personalizadas para falsificar las identidades de los operadores, manipular protocolos de señalización y dirigir el tráfico a través de rutas de red de interconexión específicas para evadir las defensas y enmascarar la atribución», dijo la organización de derechos digitales.

«Los hallazgos exponen cómo los proveedores de vigilancia comercial (CSV) sospechosos explotan el ecosistema global de interconexión de telecomunicaciones, aprovechan las redes de operadores privados y llevan a cabo operaciones encubiertas de seguimiento de ubicación que pueden persistir sin ser detectadas durante años».

PamStealer utiliza sitios Maccy falsos y comprobaciones PAM para robar contraseñas de inicio de sesión de Mac – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han detectado un nuevo ladrón de información de macOS llamado PamStealer que emplea una serie de trucos inteligentes para infectar sistemas y desviar datos confidenciales.

El ladrón, descubierto por Jamf Threat Labs, se distribuye como un archivo AppleScript compilado (.scpt) que se hace pasar por Maccy, un administrador de portapapeles legítimo de código abierto. Su nombre en código es PamStealer debido a su capacidad para validar la contraseña de inicio de sesión de la víctima a través de los módulos de autenticación conectables (PAM) de macOS antes de capturarla.

El malware se entrega en dos etapas: un AppleScript compilado distribuido dentro de una imagen de disco que está diseñado para descargar y organizar una carga útil de seguimiento. El artefacto secundario es un ladrón de información basado en Rust capaz de robar credenciales, recopilar datos del navegador, persistir y exfiltrar.

El vector de acceso inicial para el malware es un sitio similar («maccyapp[.]com») que imita maccy («maccy[.]app»). El AppleScript («Maccy.scpt») presente dentro de la imagen del disco ejecuta un descargador de JavaScript para automatización (JXA) autónomo que recupera y organiza la carga útil del ladrón utilizando API nativas de Objective-C.

Ciberseguridad

Lo que es notable aquí es que el script, una vez iniciado a través del Editor de scripts, muestra instrucciones para ejecutarlo usando el método abreviado de teclado «⌘ + R» o haciendo clic en el botón Ejecutar del Editor de scripts, lo que provoca que se ejecute la lógica maliciosa oculta en el archivo debajo de un gran bloque de líneas vacías.

«En particular, esto funciona incluso cuando el archivo todavía lleva el atributo com.apple.quarantine, que es lo que hace que el enfoque sea atractivo para los atacantes mientras Apple continúa reforzando Gatekeeper y Terminal», dijo el investigador de seguridad Thijs Xhaflaire. dicho. «Combinado con una segunda etapa basada en Rust y un flujo de trabajo de captura de contraseñas que valida las credenciales localmente a través de PAM, el resultado es una cadena de ejecución más silenciosa de lo que normalmente observamos en los ladrones básicos de macOS».

El cuentagotas AppleScript incorpora funciones compatibles con el entorno que permiten que la ejecución continúe solo después de tomar las huellas digitales del host y determinar que se está ejecutando en Apple Silicon. Para ello, obtiene una clave basada en la huella digital, que incluye detalles como la arquitectura de la CPU, la configuración regional, la distribución del teclado y la zona horaria, y luego la utiliza para desbloquear una configuración cifrada que contiene la URL de carga útil y la ruta de instalación.

En Mac con procesador Intel, la clave de descifrado derivada difiere y no logra decodificar la configuración, lo que resulta en la terminación del cuentagotas. El script también evita la ejecución dentro de entornos aislados o de análisis, así como sistemas cuya zona horaria, configuración regional del sistema y entrada de teclado se resuelven en países ubicados en Europa del Este, como Rusia, Bielorrusia, Kazajstán, Armenia, Azerbaiyán, Kirguistán, Moldavia, Tayikistán, Uzbekistán, Turkmenistán y Georgia.

Una vez que se pasan las comprobaciones, el script llega al servidor externo y descarga un binario Mach-O escrito en Rust que se hace pasar por la aplicación Finder y es responsable de recopilar datos de los navegadores web, extensiones de billetera de criptomonedas, llavero de iCloud y contenido del portapapeles. Luego, la información capturada se cifra y se extrae a una infraestructura controlada por el atacante («avenger-sync[.]live») a través de una solicitud HTTP saliente.

Además de obligar al usuario a otorgarle acceso completo al sistema de archivos, el ladrón envía una solicitud de contraseña nativa que recopila la contraseña del sistema de la víctima y luego valida la contraseña ingresada cotejándola a través de la API PAM. Si la validación falla, le pide al usuario que vuelva a ingresar la contraseña y repite el ciclo hasta que se proporcione la contraseña correcta.

Ciberseguridad

«Una vez que se captura una contraseña válida, el ladrón muestra una segunda alerta falsa: ‘Maccy está dañada y no se puede abrir. Debes moverla a la Papelera’, una copia cercana del mensaje genuino de Gatekeeper», dijo Jamf. «Esto es un señuelo. En el momento en que aparece, la carga útil ya se ha ejecutado, ha capturado la contraseña y se ha registrado para persistencia, por lo que el mensaje sólo sirve para que la víctima descarte el señuelo y asuma que la descarga se interrumpió».

También está integrado en el binario de Rust un pequeño arm64 Mach-O que se hace pasar por la configuración del sistema macOS y se utiliza para configurar la persistencia.

El desarrollo tiene incitado Alex Rodionov, el desarrollador de Maccy, para incluir una advertencia en su sitio web y en el repositorio de GitHub que decía: «Cuidado con los sitios web falsos que se hacen pasar por Maccy. Los sitios maliciosos (como maccyapp[.]net y maccyapp[.]com) distribuye malware disfrazado de Maccy. maccy.app es el único sitio web oficial.»

«En conjunto, estos comportamientos ilustran cómo los ladrones de productos básicos de macOS continúan evolucionando, adoptando cadenas de ejecución más silenciosas e implementaciones nativas que reducen las oportunidades de detección tradicionales sin dejar de ser compatibles con las características estándar de macOS», dijo Jamf.

Los grupos de ransomware recurren a Citrix Bleed 2, BYOVD y las credenciales de la cadena de suministro – CYBERDEFENSA.MX

Actores de amenazas asociados con el Anubis Se ha observado que una operación de ransomware aprovecha la vulnerabilidad Citrix Bleed 2 (CVE-2025-5777) para obtener acceso inicial.

«Aunque las tácticas difieren entre los afiliados, surgieron patrones comunes en el oficio mediante el uso de herramientas legítimas de monitoreo y administración remota (RMM), acceso a credenciales y procedimientos prácticos con el teclado utilizados para el movimiento lateral», Arctic Wolf dicho en un informe publicado esta semana.

«Los afiliados de Anubis abusaron repetidamente de herramientas legítimas de administración y acceso remoto, incluidas ScreenConnect, Zoho Assist, MeshAgent, Remotely, UltraVNC y Total Software Deployment, para integrarse con la actividad normal de TI mientras mantenían el control de los sistemas de las víctimas».

Anubis es un grupo de ransomware como servicio (RaaS) que surgió por primera vez a finales de 2024 como un cambio de marca del ransomware Sphinx. La operación de ransomware se anunció formalmente en el foro clandestino Ransomware and Advanced Malware Protection (RAMP) en febrero de 2025. Según datos de Ransomware.Live, el grupo de delitos cibernéticos se ha cobrado 91 víctimas en su sitio de filtración de datos, y solo en junio de 2026 se reportaron 11 víctimas.

Algunos de los sectores destacados a los que se dirigen incluyen la atención sanitaria, los servicios empresariales, la fabricación, la tecnología y los servicios financieros. Más del 50% de las víctimas se encuentran en Estados Unidos, seguido por el Reino Unido, Australia, Francia y Canadá.

En un informe publicado en julio de 2025, Rubrik Zero Labs dijo que Anubis anuncia atractivas divisiones de ganancias, ofreciendo a los afiliados el 80% de los montos del rescate pagado, y lo combina con una función de borrado de datos irreversible que aumenta la presión sobre las víctimas para que paguen.

«Cuando se activa el módulo /WIPEMODE de Anubis, los archivos permanecen en los directorios pero se reducen a un tamaño de 0 KB independientemente del pago del rescate», Rubrik anotado En el momento. «Saber que los actores de amenazas pueden revertir los entornos de las víctimas a este estado de tierra arrasada con un solo comando aumenta significativamente la presión sobre las víctimas para que paguen antes de que el limpiador se active por completo».

Ciberseguridad

Las intrusiones de ransomware, observadas este año, implican tanto el uso de credenciales VPN válidas como la explotación de CVE-2025-5777 (puntuación CVSS: 9,3), una falla crítica que afecta a Citrix NetScaler ADC y Gateway y que un atacante podría abusar de ella para evitar la autenticación cuando el dispositivo está configurado como Gateway o servidor virtual AAA.

Se desconoce la fuente exacta de las credenciales de VPN utilizadas en estas intrusiones. Sin embargo, es posible que se hayan obtenido tras un compromiso previo, o mediante intermediarios de acceso inicial (IAB), relleno de credenciales o actividad de ladrón de información.

«Además de la explotación de CitrixBleed 2, se observaron inicios de sesión válidos de Cisco AnyConnect VPN desde varios ASN de alojamiento, incluidos AS20473 – The Constant Company y AS55286 – ServerMania», explicó Arctic Wolf. «La autenticación de VPN maliciosa fue seguida por una actividad de inicio de sesión que involucraba a RDP y SMB, lo que conducía al acceso a credenciales, la creación de servicios PsExec, la implementación de RMM y, en última instancia, la invocación de herramientas de transferencia a la nube para la exfiltración».

El movimiento lateral se facilita a través de RDP y PsExec, lo que luego conduce al despliegue de varias herramientas RMM legítimas para acceso persistente, otorgando a los atacantes la capacidad de transferir archivos y ejecutar código de forma remota, mientras permanecen fuera del radar. Algunas intrusiones también configuran un túnel Cloudflare (también conocido como cloudflared) para establecer túneles hacia los entornos de las víctimas.

La siguiente fase de los ataques implica recopilar credenciales para facilitar un acceso más profundo al entorno comprometido, después de lo cual se instalan herramientas como S3 Browser, rclone, s5cmd, WinSCP y PuTTY para la transferencia o exfiltración de datos antes de la implementación del ransomware. Paralelamente, se toman medidas para debilitar las defensas del sistema y complicar el análisis posterior al incidente.

«Estas técnicas incluían la desactivación de la protección en tiempo real de Windows Defender, la actividad de desinstalación de Sophos, artefactos relacionados con PCHunter y limpieza o manipulación de registros en múltiples sistemas», explicó la empresa de ciberseguridad. «En al menos una intrusión, se eliminó un cifrador Anubis después de la ejecución, lo que redujo la disponibilidad de artefactos de carga útil en el disco para su posterior análisis».

La puerta trasera de los caballeros y el exploit de día 0 detallados

La revelación se produce como lo detalló Kaspersky. los caballeros La explotación por parte del grupo RaaS de vulnerabilidades conocidas y credenciales de inicio de sesión robadas o débiles para violar objetivos y su uso de una puerta trasera basada en Go para permitir la ejecución remota de comandos después del reconocimiento, el movimiento lateral a través de la Política de grupo o PsExec y la evasión de defensa utilizando la técnica de traer su propio controlador vulnerable (BYOVD).

El implante está diseñado para recopilar información del sistema y exfiltrarla a un servidor externo («81.177.215[.]15:9443») a través de una conexión TCP bidireccional y espera respuestas del operador que luego se ejecutan en el host usando «cmd.exe» si el byte de respuesta es «c». Si el byte es «s», se establece una conexión de proxy SOCKS.

«Esta funcionalidad probablemente permita al equipo rojo de The Gentlemen girar dentro de la red objetivo y ampliar su cobertura de escaneo», Kaspersky dicho. «Dadas las capacidades del implante de puerta trasera, como establecer comunicación bidireccional, ejecutar comandos, configurar un proxy SOCKS y recopilar información, está claro que también se puede utilizar para expandir la cadena de ataque según sea necesario».

Según Expel, el grupo RaaS también ha utilizado como arma una vulnerabilidad de día cero en un controlador de proveedor externo poco conocido como parte de su arsenal BYOVD para obtener acceso a nivel de kernel, eludir las protecciones de seguridad de Windows y eliminar los procesos de seguridad protegidos asociados con Microsoft, ESET, Palo Alto Networks y SentinelOne. El conductor en cuestión es ktapi.sysque forma parte de una API desarrollada por Kontron.

Ciberseguridad

«Aún no está claro cómo los actores de la amenaza llegaron a poseer el archivo o obtuvieron conocimiento de su vulnerabilidad», Marcus Hutchins. dicho. «BYOVD sigue siendo una gran amenaza para las empresas, ya que permite a los atacantes desactivar sistemas de seguridad de última generación en segundos. Incluso utilizando la última versión de Windows, con todas las mitigaciones de exploits habilitadas, no proporciona una protección completa».

Asociación de ransomware entre VECT y TeamPCP

Los hallazgos también surgen tras una investigación de la Unidad Contra Amenazas de Sophos sobre la asociación entre VECT y TeamPCP, que se anunció en marzo de 2026 para combinar el robo de credenciales impulsado por ataques a la cadena de suministro con la implementación de ransomware.

«La asociación formal entre TeamPCP y VECT permite a VECT implementar ransomware en todas las organizaciones comprometidas en los ataques a la cadena de suministro de Trivy y LiteLLM», dijo Sophos en un informe compartido con The Hacker News. «Antes de la asociación con VECT, TeamPCP ejecutaba otra operación de ransomware bajo la marca CipherForce. CipherForce enumeró a seis víctimas en su sitio de filtración en febrero de 2026 y lo renombró como sitio de filtración de TeamPCP en mayo».

Análisis recientes de Check Point y SALTO SEC han descubierto que VECT contiene fallas de implementación que causan que cualquier archivo de más de 128 KB se destruya permanentemente en lugar de cifrarse, lo que llevó a TeamPCP a emitir una declaración indicando que nunca habían usado el cifrado de VECT en ataques. «Somos dueños de CipherForce, nuestro propio casillero privado», afirmó el grupo.

«La alianza Vect/TeamPCP representa un cambio significativo en el panorama de amenazas de ransomware, incluso teniendo en cuenta las deficiencias técnicas que socavan su eficacia operativa», Sophos dicho.

«La convergencia del robo de credenciales de la cadena de suministro a gran escala, una operación RaaS madura y la movilización masiva de foros clandestinos constituye un modelo sin precedentes de implementación de ransomware industrializado que reduce significativamente la barrera de entrada del ciberdelito».

Google interrumpe la red de proxy residencial NetNut que abarca 2 millones de dispositivos domésticos – CYBERDEFENSA.MX

Google se ha degradado significativamente tuerca netauna de las redes más grandes que convierte los dispositivos domésticos en repetidores alquilados para el tráfico de otras personas.

En colaboración con el FBI, Lumen y otros, el Threat Intelligence Group (GTIG) de Google dijo esta semana había reducido en millones el conjunto de dispositivos utilizables de la red.

Google identifica NetNut, también rastreado como popacomo una red extendida a través de dispositivos domésticos en todo el mundo, incluidos televisores inteligentes y cajas de transmisión, y GTIG estima que la red tiene al menos 2 millones de dispositivos.

Si uno de esos dispositivos está en su casa, los extraños pueden dirigir su propio tráfico a través de su conexión a Internet y su dirección es la culpable de lo que hagan con él.

Cómo funciona

Una red de proxy residencial vende acceso a direcciones de Internet residenciales reales. Los atacantes pagan para dirigir su tráfico a través de su conexión de modo que parezca una navegación doméstica normal, no el tráfico del centro de datos que las herramientas de seguridad tienden a bloquear.

Para crear ese grupo, los operadores necesitan que su código se ejecute en dispositivos domésticos. Algunos dispositivos se envían con él preinstalado en hardware económico de otra marca; otros lo detectan cuando alguien instala una aplicación gratuita que lo oculta. Una vez que está en funcionamiento, el dispositivo se convierte en un «nodo de salida», una puerta por la que fluye el tráfico de otras personas.

Ciberseguridad

Google dice que un nodo de salida lleva el tráfico externo al interior de la red doméstica, dando a los atacantes un punto de apoyo para llegar a otros dispositivos en ella. Algunos de estos dispositivos domésticos también han sido incluidos en grandes botnets de ataque como Mirai y Badbox 2.0.

En una sola semana de junio, GTIG contó 316 grupos de amenazas distintos que utilizaban nodos de salida sospechosos de NetNut, incluidos grupos de ciberdelincuentes y de espionaje, para ocultar su ubicación real y ejecutar Ataques para adivinar contraseñas.

La empresa detrás de esto

A diferencia de la mayoría de las botnets proxy, NetNut se remonta a una empresa pública. En junio, investigadores en Qurium, Synthient, Nokia Deepfield y Spur vincularon a Popa con NetNut.

NetNut es un proveedor de proxy propiedad de la empresa israelí que cotiza en bolsa Alarum Technologies (NASDAQ: ALAR). En una prueba controlada, Synthient dijo El tráfico que envió al portal comercial de NetNut salió a través de un dispositivo que había inscrito en Popa.

Synthient lo planteó como evidencia de la ruta del tráfico, no como prueba de lo que NetNut sabía o pretendía. La propia inteligencia de Google coincide: trata a NetNut y Popa como la misma red, y dice que los informes públicos coinciden con su visión de cómo NetNut construye su botnet. Hacker News cubrió los hallazgos de los investigadores cuando fueron publicados.

Alarum rechaza la etiqueta de «botnet». Califica la investigación como «afirmaciones demostrablemente inexactas y deducciones erróneas en lugar de hechos verificados», y dice que su software es para compartir ancho de banda de forma consentida que no compromete los dispositivos en los que se ejecuta.

Las pruebas de los investigadores complican esa defensa: Synthient informó que ninguna de las más de 20 aplicaciones que examinó realmente mostró a los usuarios una solicitud de consentimiento.

Por qué un derribo no es suficiente

Cortar NetNut es complicado por diseño. NetNut ejecuta un programa de revendedores que permite a otras empresas vender su red con sus propias marcas. Google dice que tiene gran confianza en que muchas marcas de proxy populares, aparentemente separadas, en realidad están revendiendo el mismo grupo de NetNut.

Entonces, una sola eliminación afecta a muchas marcas que parecen independientes pero no lo son.

Ciberseguridad

Es también por eso que Google llama a esto degradación, no muerte. Dice que su acción anterior contra una red IPIDEA similar demostró que estas redes pueden parecer resistentes: los operadores comienzan a comprar capacidad de sus rivales y, de hecho, se convierten ellos mismos en revendedores. Un daño real y duradero, dice Google, significa perseguir a varios proveedores conectados a la vez.

En enero, Google y sus socios interrumpieron IPIDEA, una red con sede en China que en su apogeo era una de las más grandes de su tipo. En julio de 2025, Google llevó ante los tribunales a los operadores de Badbox 2.0, la botnet de dispositivos Android TV secuestrados cuyos componentes se superponen con los de Popa. En cada ocasión, las redes se mostraron testarudas.

Qué deberían hacer los consumidores

La señal de advertencia más clara es una aplicación que ofrece pagarle por su «ancho de banda no utilizado» o por «compartir su Internet». Esa es una de las principales formas en que crecen estas redes.

Más allá de eso:

  • Cíñete a las tiendas de aplicaciones oficiales y comprueba qué permisos solicita una aplicación VPN o proxy.
  • Mantenga activadas las protecciones integradas como Google Play Protect.
  • Compre cajas de transmisión y hardware de TV inteligente de fabricantes conocidos, no de marcas anónimas.

La demanda de estas direcciones particulares no desaparece cuando una red deja de funcionar; simplemente se mueve. Para los defensores y las plataformas, la siguiente señal a observar es si el tráfico vinculado a NetNut resurge bajo las marcas de revendedores.

AI Compute Hijacking, Apple Email Flaw, BlueHammer Ransomware + 14 Stories – CYBERDEFENSA.MX

This week’s security news is mostly about weak spots.

Browsers, bots, sandboxes, AI systems, and email flows all show the same problem in different ways. Everything looks normal until someone tests a small gap and finds a way through.

This is not one big break. It is small permissions, weak checks, open systems, and normal tools doing things they were allowed to do. That same pattern runs through the stories below.

The lesson this week is simple: attackers do not need the front door when the side door is already open. A copied command, an exposed server, a trusted bot, a weak check. Small things become entry points when nobody treats them like one.

So read the list with that in mind. The loud part is the breach. The useful part is the quiet mistake that made it possible. Until next ThreatsDay.

El malware Umbrij vinculado a ToddyCat abusa de OAuth para acceder a Gmail a través de la API de Google – CYBERDEFENSA.MX

El actor de amenazas conocido como toddygato se ha atribuido a un nuevo malware llamado Umbrij que está diseñado para obtener acceso subrepticio a la correspondencia de correo electrónico de una víctima a través de la API de Google.

«En esta campaña, los atacantes centraron su atención en las comunicaciones corporativas por correo electrónico alojadas en Gmail, apuntando a comprometer el acceso a través de API», Kaspersky dicho en un informe detallado publicado esta semana. «Debido a que la API de Google se basa en el protocolo OAuth 2.0 para la autorización, las aplicaciones pueden usar un token OAuth para acceder a los recursos de correo electrónico solicitados».

Se dice que el adversario desarrolló Umbrij para adquirir este token y usarlo para conectarse a la consola de administración del navegador en modo sin cabeza a través de un puerto de depuración remota.

Posteriormente, se emitieron una serie de solicitudes para obtener un código de autorización OAuth, que luego se intercambió por un token de acceso para llegar a los recursos de destino a través de la API. La técnica ha recibido el nombre en código. Token de sombra a través de depuración remota (STRD) del proveedor ruso de ciberseguridad.

Lo notable del ataque es que es viable en navegadores basados ​​en Chromium y explota una sesión activa de Gmail. En otras palabras, la idea es iniciar el navegador en modo sin cabezaconéctese a través del puerto de depuración remota para tomar el control y aproveche una sesión de Gmail ya iniciada para obtener acceso a los recursos de la cuenta de Google.

Se han descubierto tres versiones diferentes de Umbrij, incluidas versiones que cuentan con funciones auxiliares para depurar y buscar y seleccionar cuentas de usuario dentro del navegador.

Ciberseguridad

ToddyCat es el nombre asignado a una amenaza persistente avanzada (APT) que tiene un historial de atacar a varias organizaciones en Europa y Asia desde al menos 2020. En noviembre de 2025, Kaspersky detalló el uso por parte del grupo de piratería de una herramienta personalizada denominada TCSectorCopy para acceder a los datos de correo electrónico de Microsoft Outlook que pertenecen a las empresas objetivo.

La compañía de ciberseguridad dijo que descubrió a Umbrij durante lo que describió como una «operación de búsqueda de amenazas», como parte de la cual se utilizó una tarea programada que se hacía pasar por su software («KasperskyEndpointSecurityEDRAvp») para lanzar un archivo firmado digitalmente. El archivo firmado luego empleó Carga lateral de DLL para lanzar Umbrij.

Para realizar esta tarea, se abusó de tres archivos binarios legítimos susceptibles a la carga lateral de DLL:

  • BDSubWiz.exeun componente del Asistente de envío en Bitdefender ConnectAgent
  • VSTestVideoRecorder.exeun componente de la herramienta de grabación de vídeo utilizada para realizar pruebas con Microsoft Visual Studio
  • GoogleDesktop.exeuna aplicación discontinuada de Google Desktop Search que se utiliza para indexar archivos y realizar búsquedas rápidas en una computadora local con Windows

Independientemente del ejecutable utilizado, el resultado final es el mismo: iniciar la DLL Umbrij escrita en .NET y ofuscada con ConfuserEx, un ofuscador de código abierto. La herramienta también se puede invocar junto con parámetros de línea de comandos que especifican a qué navegadores apuntar (Google Chrome o Microsoft Edge), le indican que guarde una captura de pantalla del perfil del usuario como un archivo PDF y proporcionan el nombre de usuario del sistema bajo el cual se ejecutará la herramienta.

Diagrama de flujo de trabajo de Umbrij

Umbrij, una vez iniciado, realiza una serie de acciones preparatorias en un host de Windows comprometido para violar la cuenta de Gmail.

  • Verifique la disponibilidad del puerto que se designará para la depuración del navegador.
  • Recupere el contexto del usuario buscando el proceso «explorer.exe» y duplicando el token del primer proceso que encuentre para conservar todos los privilegios del usuario que ha iniciado sesión. Alternativamente, el usuario El interruptor se puede utilizar junto con la herramienta para especificar el usuario objetivo cuyo token debe duplicarse.
  • Construya la ruta a la carpeta de la aplicación del navegador web dentro del repositorio de datos de la aplicación local del usuario y luego analice el archivo de estado local correspondiente a Chrome o Edge para recopilar información sobre los perfiles de usuario del navegador almacenados.
  • Enumere todos los perfiles y escanéelos en busca de un campo llamado «nombre_usuario» que incluya una dirección de correo electrónico. Vale la pena señalar que la presencia de una dirección de correo electrónico indica que el usuario está autenticado en un servicio de Google.
  • Cree un directorio llamado «BackupFiles» dentro de «%LOCALAPPDATA%\Google\Chrome\» y «%LOCALAPPDATA%\Microsoft\Edge\».
  • Copie los siguientes archivos y carpetas de cada destino. perfil de usuario en ellos: IndexedDB, Almacenamiento local, Red, Datos de inicio de sesión, Datos de inicio de sesión para cuenta, Preferencias, Preferencias seguras y Datos web. En caso de que otros procesos bloqueen estos archivos, la herramienta incluye un mecanismo de copia forzada.
  • Busque en las carpetas «Archivos de programa» y «Archivos de programa (x86)» la carpeta de instalación del navegador Chrome y Edge.
  • Inicie los navegadores en modo sin cabeza utilizando el perfil de usuario copiado en la carpeta «BackupFiles», lo que hace que el navegador aplique todas las cookies del usuario activo, incluida la cuenta de Google que inició sesión, y omita la autenticación.
  • Usar Titiriterouna biblioteca de JavaScript utilizada para controlar los navegadores basados ​​en Chromium a través del protocolo Chrome DevTools, para conectarse al puerto de depuración remota y enviar una solicitud de código de autorización para dirigir el navegador a «accounts.google[.]com/o/oauth2/v2/auth/identifier» URL que contiene un «client_id» que corresponde a un herramienta de migración se utiliza para importar archivos PST locales y datos de cuentas de Microsoft Exchange a una cuenta de Google Workspace. La solicitud HTTP GET también especifica el conjunto de permisos requeridos por la aplicación. Utilice JavaScript para emular eventos de clic del mouse para seleccionar la cuenta de Google adecuada después de navegar a la URL y otorgarle los permisos necesarios, incluido el acceso completo a Gmail, Drive, Contactos, Calendario y Tareas.
  • Redirija la sesión del navegador a una dirección local especificada en la solicitud inicial y extraiga de ella el código de autorización OAuth.
Ciberseguridad

«Umbrij, como la mayoría de las otras herramientas del arsenal de ToddyCat, registra sus acciones en detalle y las guarda en un archivo», dijo Kaspersky. «También guarda el código de autorización recuperado en este archivo de registro, que posteriormente el operador extrae del host comprometido».

«El código de autorización adquirido luego se intercambia por un token de acceso OAuth. Los actores de amenazas usan ese token para conectarse a la cuenta de Gmail a través de la API, comprometiendo así las comunicaciones corporativas por correo electrónico».

Para contrarrestar la amenaza, se recomienda revisar los códigos de autorización otorgados a las aplicaciones navegando a «myaccount.google».[.]com/connections» y luego busque aplicaciones llamadas «Google Workspace Migration for Microsoft Outlook» o «Google Workspace Sync for Microsoft Outlook». Si cualquiera de esas aplicaciones está presente y no se utiliza realmente dentro de la organización, es esencial revocar su acceso para invalidar los tokens de OAuth.

«El grupo ToddyCat APT continúa buscando formas de comprometer las comunicaciones corporativas por correo electrónico», dijo Andrey Gunkin, analista senior de malware de Kaspersky. «Su nueva herramienta, Umbrij, automatiza los intentos de los atacantes de obtener acceso a las cuentas de correo electrónico de la organización. Esta automatización no sólo ayuda a aumentar la escala y la frecuencia de sus ataques sino que también demuestra la fuerte motivación y las habilidades técnicas avanzadas de ToddyCat».

Identity Lifecycle Management Wasn’t Built for AI Agents  – CYBERDEFENSA.MX

Identity lifecycle management was architected around a person with an employment record, a manager, and a departure date. AI agents have none of those. As autonomous principals proliferate across enterprise environments, the governance model built for humans develops structural blind spots that traditional IGA tools weren’t designed to detect. This guide covers where that model breaks, what it fails to govern, and what extending it to agents actually requires.

What Identity Lifecycle Management Was Designed to Handle

To understand why identity lifecycle management breaks down around AI agents, you need to understand what it was built to do well and who it was built for. The entire architecture rests on a single foundational assumption: every identity maps to a human being whose organizational status changes through documented, HR-driven events.

The identity lifecycle management process governs access from an identity’s first provisioning event through every modification it accumulates to its eventual deactivation. At its core, it’s an event-driven control system built around three canonical transitions: joiner, mover, and leaver.

HR as the Authoritative Engine

The HR platform, whether Workday, SAP SuccessFactors, or ServiceNow HR, functions as the system of record that drives the entire identity and access management lifecycle. A new hire record triggers automated provisioning into Active Directory or Azure AD, which propagates entitlements to downstream applications through IGA connectors. A department transfer updates role attributes and recalculates the appropriate entitlement set. A termination event triggers deprovisioning workflows across all connected systems.

The strength of the model is its determinism. Access rights reflect a verifiable organizational fact: a person holds a specific role in a specific team under a specific manager. Role-based access control maps those attributes to defined entitlement sets, delivering the right permissions at onboarding without manual negotiation per account.

Identity governance lifecycle management builds accountability on top of that structure. Access certification campaigns route to the identity manager or application owner for attestation. Separation-of-duties controls detect conflicting permissions. Audit logs tie every provisioning action back to the originating HR event and the approver who authorized it, providing the compliance evidence that frameworks such as SOX, HIPAA, and PCI DSS require.

What the Identity Lifecycle Management Phases Enforce in Practice

When an employee changes roles, attribute updates automatically recalculate entitlements, revoking what the new role doesn’t require and granting what it does. When an employee leaves, the HR termination event triggers deprovisioning across all connected applications. Certification campaigns run on a defined cadence to fill the gaps between events, requiring managers to attest to current access against current role requirements.

Every control in the standard identity lifecycle management phases assumes a human principal with an employment record, a manager relationship, and a predictable transition pattern. Access review workflows route to humans. Provisioning triggers are triggered by humans entering or changing their status in the HR system. Offboarding fires when a human’s organizational status changes.

The model is coherent, auditable, and well-supported by decades of IGA tooling. It reliably governs the human identity population. The problem begins precisely at its edges, where the principals accumulating access inside enterprise environments no longer have employment records, managers, or departure dates.

Where AI Agents Fall Outside That Model

AI agents don’t arrive through HR. They don’t have employment records, reporting structures, or defined role profiles that map to entitlement sets. They are created by engineers, orchestration frameworks, or automated deployment pipelines, and they land in production with whatever permissions the developer scoped at creation time or whatever the platform granted by default.

That origin story breaks every assumption the identity lifecycle management model depends on.

No Authoritative Source, No Governed Entry Point

Standard identity and access management lifecycle controls require an authoritative source to initiate provisioning. For humans, that source is the HR system. For AI agents, provisioning typically happens through a developer committing a configuration file, a platform API call that instantiates a new agent runtime, or an orchestration layer like LangChain, AutoGen, or AWS Bedrock Agents spinning up a new execution context. None of those events touches an IGA platform. None generates a provisioning record tied to a defined identity owner.

The agent arrives with credentials already attached: a manually created service account, an API key generated and stored in an environment variable, or an OAuth grant issued through a developer consent flow. The IGA platform, if it sees the credential at all, treats it as a static machine identity with a fixed purpose. What it’s actually dealing with is an autonomous principal that will make access decisions, traverse API boundaries, and accumulate behavioral scope in ways no static service account ever does.

Dynamic Scope in a System Built for Fixed Roles

Role-based access control works because human job functions are, within limits, predictable. A database administrator needs specific permissions. A finance analyst needs access to a defined set of systems. Entitlement sets get designed around those functions and updated when roles change through documented HR events.

AI agents don’t operate within fixed functional boundaries. An agent built to summarize internal documents may, through tool-calling or RAG retrieval patterns, end up querying APIs it wasn’t explicitly provisioned for, writing outputs to storage systems outside its original scope, or chaining actions across multiple enterprise systems to complete a task. The access surface expands at runtime, driven by the agent’s objective-seeking behavior rather than by any policy decision made in advance by a governance team.

Identity lifecycle management phases weren’t designed to govern runtime-expanding scope. They were designed to govern access defined at provisioning and adjusted at known transition points.

Simultaneous Multi-Environment Instantiation

A human identity exists in one place at a time. An AI agent can run as dozens of parallel instances across cloud environments, containerized workloads, and SaaS API surfaces simultaneously. Each instance may carry its own credential set, its own tool permissions, and its own session context, none of which is correlated in any IGA system.

In multi-agent architectures, the complexity compounds further. Orchestrator agents spawn sub-agents, delegate tasks, and pass credentials between execution contexts. The identity and access management lifecycle has no native model for a principal that forks, delegates, and recombines access rights dynamically across a distributed execution graph.

What IGA Tools Actually See

When an IGA platform encounters an agent identity, it sees a service account with an API key or an OAuth client credential. Identity governance lifecycle management tooling applies the same governance logic it applies to any machine identity: it checks for an owner, verifies the credential age, and notes whether the account appeared in the last access review.

What it doesn’t see is that the account is actively making authorization decisions, traversing application boundaries, and operating with a degree of autonomy that no traditional service account possesses. The governance record looks static. The actual access behavior is anything but.

The Lifecycle Events Agents Never Trigger

The joiner-mover-leaver model works because human employment generates a continuous stream of structured events that governance systems can act on. AI agents generate none of them. Every control point in the standard identity lifecycle management phases depends on a signal that agent deployments never produce by design.

No Joiner Event, No Governed Entry

When a new employee joins, the creation of an HR record triggers provisioning. Access gets scoped to a role definition, routed through an approval chain, and recorded in the IGA platform with an owner attached. The identity enters the governance boundary on day one.

An AI agent enters production through a deployment pipeline, a Terraform apply, or a direct API call to an agent orchestration platform. No IGA workflow fires. No access request gets submitted. No manager approves the entitlement set. The agent’s credentials, whether a service account, an OAuth client, or an API key, are created inline with the deployment, often by the same automated process that provisions the compute environment. The identity and access management lifecycle never receives a joiner signal, so the governance record for that agent starts as a blank.

No Mover Event, No Entitlement Recalculation

When a human employee changes roles, HR attribute updates flow into the IGA platform, triggering entitlement recalculation. Access appropriate to the old role gets revoked. Access required by the new role gets provisioned. The governance record reflects the current organizational reality.

AI agents change scope constantly, and none of those changes generate a mover event. An agent retooled to access a new data source, extended to call additional APIs, or redeployed against a different environment doesn’t update any HR system. No IGA connector receives an attribute change. No access review fires to reconcile what the agent now reaches against what it was originally provisioned for. Identity governance lifecycle management has no visibility into scope expansion that happens entirely within the deployment layer.

No Access Review Signal

Periodic access certification depends on a manager or application owner receiving a review task tied to a specific identity. That routing logic requires an identity with a human owner on record and an organizational relationship that the IGA platform can traverse.

Agent identities accumulate permissions across deployment iterations without generating any of the signals that recertification workflows depend on. Each new tool integration, each additional API scope, and each expanded OAuth grant layer is added to the agent’s access profile without triggering a review. The what is identity lifecycle management question, answered honestly for agents, is a model that produces no certification record, no attestation history, and no evidence of ongoing governance.

No Leaver Event, No Deprovisioning

Offboarding fires when an HR termination record closes the employment relationship. The agent equivalent, a deployment being retired, a workflow being deprecated, or a project being shut down, produces no equivalent signal.

Retired agent credentials persist in secrets managers, environment variable stores, and OAuth authorization servers long after the workload they served stopped running. An identity lifecycle management solution built around HR-triggered deprovisioning has no mechanism to detect that an agent is gone. The credentials remain valid. The access paths remain open. The governance record shows an active identity because, from the IGA platform’s perspective, nothing has changed.

What This Means for Provisioning, Reviews, and Offboarding

The governance gaps described above aren’t theoretical edge cases. They produce concrete risks, compounding them at every operational stage of an agent’s existence. When provisioning has no defined scope, when reviews produce no actionable signal, and when offboarding has no trigger, the access surface expands in only one direction.

Provisioning: Over-Permission as the Default Starting Point

Human provisioning starts from a role definition. The IGA platform maps job functions to an entitlement set, and the new identity receives access calibrated to what that function requires. Scope is defined before the identity exists.

Agent provisioning works in reverse. A developer needs the agent to complete a task and grants access broad enough to ensure success. The path of least resistance across major cloud and SaaS platforms is permissive: AWS IAM policies default toward broad resource access when scoped to wildcards, OAuth consent flows issue all requested scopes without challenging individual permissions, and service account creation in Azure AD or Google Workspace carries no built-in entitlement governance check.

The agent arrives in production over-permissioned from its first moment of operation, with no minimum-necessary baseline, no approval chain, and no IGA record linking the granted access to a defined business requirement.

Access Reviews: Routing Logic That Finds No Owner

Certification campaigns in standard identity governance lifecycle management platforms route review tasks based on identity attributes, specifically manager relationships and application ownership records. A reviewer receives a list of identities and their entitlements, confirms each access grant remains appropriate, and submits an attestation.

Agent identities break the routing logic at its foundation. Most carry no manager attribute. Many have no defined human owner in the IGA platform. Where application ownership records exist, they typically point to a team rather than an individual, and that team’s familiarity with what the agent currently accesses rarely matches what was originally provisioned.

When certification campaigns do reach agent identities, reviewers attest to the access record in the IGA system, which reflects what was provisioned at creation rather than what the agent has accumulated through iterative deployment changes. The attestation is formally complete and operationally meaningless.

Offboarding: Credentials That Outlive Their Workload

HR-triggered deprovisioning is deterministic. A termination record closes, the IGA platform sends deprovisioning instructions to every connected application, and the access path closes at a defined moment.

Agent deprecation generates no equivalent signal. A development team retires a workflow, archives the repository, and decommissions the compute environment. The service account persists in Active Directory or Entra ID. The API key remains valid in the secrets manager. The OAuth authorization grant remains valid on the authorization server. None of the systems that issued those credentials received a revocation instruction because no system monitored the agent’s operational status in the first place.

Stale agent credentials aren’t a minor hygiene issue. A long-lived API key with production database access, attached to a workload that no longer runs, is an ungoverned access path with no owner, no review history, and no expiration. In environments running large numbers of agents across iterative deployment cycles, those credentials accumulate faster than any manual audit process can keep up with.

The identity and access management lifecycle, as currently implemented across most enterprise environments, has no mechanism to detect agent inactivity, flag credential age against operational status, or trigger revocation when a workload goes dark.

How to Extend Identity Lifecycle Management to Cover Agents

Extending identity lifecycle management to cover AI agents doesn’t mean retrofitting HR-driven workflows onto a principal type for which they were never designed. It means rebuilding the governance logic around the agent’s actual operational characteristics: how it gets created, how its scope evolves, and how its operational life ends.

Automated Discovery Across Every Deployment Surface

Agent identities get created across cloud provider IAM systems, SaaS OAuth authorization servers, Kubernetes service accounts, secrets managers, and CI/CD pipeline credential stores. No single system maintains a complete inventory, and agents deployed through automated pipelines frequently appear in none of the places a traditional IGA platform looks for them.

A genuine identity lifecycle management solution for agents requires continuous, automated discovery that instruments the environments where agents actually live: reading IAM policy attachments in AWS and Azure, extracting OAuth client registrations from authorization servers, surfacing service account configurations from Kubernetes namespaces, and identifying API keys embedded in runtime configurations. Discovery has to be ongoing because agent deployments change faster than any quarterly audit cycle can capture.

Attribute Modeling Built Around Agent Behavior

Human identity attributes map to organizational structure: department, job title, manager. Those attributes anchor entitlement decisions and review routing. Agent identity requires an entirely different attribute model.

Each agent identity needs a documented owning team, a defined operational purpose, a bounded list of the systems and APIs it’s authorized to reach, a deployment timestamp, and an expected operational lifetime tied to the workload it serves. Behavioral attributes matter equally: which APIs the agent calls, how often, and across which data surfaces. An identity governance lifecycle management approach built for agents treats observed access patterns as governance inputs, using behavioral baselines to surface permission grants the agent holds but never exercises.

Policy-Driven Provisioning Scoped to Agent Function

Rather than granting access at deployment time and reviewing it later, provisioning for agent identities should follow the same least-privilege logic that mature IAM program frameworks apply to privileged human accounts: define the minimum access the agent requires to perform its documented function, enforce that scope through policy at credential issuance, and attach the credential to a defined owner who carries accountability for any scope changes.

In practice, this means integrating agent provisioning into IGA intake workflows rather than leaving it entirely within the deployment pipeline. When an agent requires access to a production API or a sensitive data store, that request routes through an access governance control, not around it.

Continuous Behavioral Monitoring as the Review Substitute

Periodic access certification produces no actionable signal for agent identities. The operational substitute is continuous behavioral monitoring: tracking what each agent actually calls, comparing observed access against the provisioned entitlement set, and flagging divergence in real time.

When an agent starts calling APIs outside its provisioned scope, that divergence is a governance event requiring immediate response, not a finding to surface at the next quarterly review. Behavioral monitoring closes the gap left by recertification campaigns across the identity and access management lifecycle for agent principals.

Deprecation Workflows Triggered by Operational Status

Offboarding for agents requires a trigger mechanism that reflects operational reality. Inactivity monitoring tied to credential usage logs provides the signal: an API key that hasn’t generated an authenticated request within a defined window is a candidate for revocation review. Scope change detection flags when a deployment modifies the permissions attached to an agent credential, generating a governance event that routes to the owning team for reauthorization.

Connecting those signals to automated revocation workflows, integrated with AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault, closes the offboarding gap without requiring a manual discovery step. The identity lifecycle management phases for agents end when operational status ends.

Where Orchid Security Fits In

Most enterprise IAM stacks govern the identity population they can see through their existing connectors. Agent identities, ungoverned credentials, and authentication paths that bypass the corporate IdP fall into the space that those connectors don’t reach. That’s the gap Orchid Security was built to close.

Continuous Discovery Across the Full Identity Surface

Orchid deploys lightweight orchestrators that instrument applications directly, extracting authentication flows, authorization logic, account configurations, and credential storage patterns from both managed and unmanaged environments. The result is a continuously updated identity inventory that reflects what the environment actually contains, including every agent identity, service account, and API credential that never passed through an IGA intake workflow.

For organizations asking what identity lifecycle management is in practice, Orchid’s answer starts with visibility: you govern what you’ve found, and most programs haven’t found everything.

An Identity Graph That Reflects Agent Reality

Orchid’s identity graph maps every principal, human and non-human, to the authentication flows, entitlements, and application access paths it actually uses. For agent identities specifically, the graph surfaces the owning team, the provisioned permission set, observed behavioral patterns, and credential age, producing the attribute model that identity governance lifecycle management for agents requires, but traditional IGA platforms don’t generate.

Guardrails for Autonomous Identity

Orchid’s guardrails for the autonomous identity apply policy-driven controls directly to agent identity populations: scoped provisioning tied to documented agent function, continuous monitoring of behavioral divergence from provisioned entitlements, and deprecation workflows triggered by inactivity signals rather than HR events.

The platform integrates with existing IAM, PAM, and IGA infrastructure, routing remediation through the tools organizations already operate rather than replacing them. Governance scope expands to match the actual identity surface, including agent identities, and the identity and access management lifecycle extends to cover the principals that every traditional identity lifecycle management solution leaves outside its boundary.

Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.

Robo de credenciales de FortiBleed vinculado a operaciones de INC y Lynx Ransomware – CYBERDEFENSA.MX

Los recientemente descubiertos con motivación financiera FortiBleed La campaña se ha atribuido a las operaciones de ransomware INC y Lynx, lo que indica que las credenciales robadas y verificadas estaban destinadas a intrusiones posteriores.

«Se encontró que un operador vinculado a la infraestructura de FortiBleed trabajaba activamente en paneles de negociación para ambos grupos, vinculando el robo masivo de credenciales de FortiGate directamente con la implementación de ransomware por primera vez», SOCRadar dicho en un nuevo informe publicado el miércoles.

La compañía dijo que rastreó la actividad de escaneo en aproximadamente 11,250 portales FortiGate en más de 150 países, seguido del acceso confirmado a nivel de administrador en 409 objetivos y la finalización exitosa de la cadena de ataque completa en 354 de ellos. En total, al menos 12 implementaciones de ransomware han resultado de este acceso, lo que ha provocado que se cifren cientos de puntos finales en las organizaciones afectadas.

Ciberseguridad

La operación de recolección de credenciales a gran escala, que salió a la luz el mes pasado, involucró a los actores de amenazas escaneando sistemáticamente Internet en busca de dispositivos Fortinet expuestos, intentando ingresar a ellos usando combinaciones de credenciales conocidas y luego implementando rastreadores de paquetes personalizados para recopilar pasivamente credenciales y otros datos de autenticación del tráfico de la red.

Se estima que la campaña se dirigió a 430.000 firewalls FortiGate en todo el mundo, reuniendo más de 110 millones de credenciales en el proceso. La actividad quedó expuesta después de que un error de seguridad operativo por parte de los atacantes dejara un servidor que contenía credenciales robadas de miles de dispositivos Fortinet expuestos en Internet.

Se estima que el rastreador Golang se instaló en unos 12.000 dispositivos Fortinet, lo que lo convierte en un subconjunto del número total de equipos de red objetivo.

Los últimos hallazgos de SOCRadar muestran que se encontró que un operador con acceso a la infraestructura de FortiBleed inició sesión en los paneles de negociación de INC Ransom y Lynx, y las víctimas enumeradas por INC Ransom se superponen con los datos de la campaña. Los enlaces se basan en uno de los 200 servidores recientemente descubiertos asociados con la infraestructura FortiBleed que otorga visibilidad a archivos internos, registros y documentación operativa.

Las herramientas, los registros y las horas de trabajo indican que la actividad es obra de un actor de amenazas de habla rusa que probablemente opera como intermediario de acceso inicial. Gran parte de la focalización se ha centrado en los sectores de manufactura, tecnología y logística en América Latina y las regiones de Asia Pacífico.

Ciberseguridad

SOCRadar también dijo que descubrió un documento interno que indica que se trata de una operación organizada que comprende a unas 20 personas con una clara división del trabajo. «Un pequeño núcleo de operadores líderes impulsa la mayoría de las intrusiones de alto impacto, respaldados por especialistas y personal de apoyo», añadió.

Además, se cree que los actores de amenazas poseen al menos una vulnerabilidad de día cero en Nextcloud. La firma de inteligencia de amenazas dijo que está coordinando activamente con el proveedor afectado.

La divulgación llega como eSentire dicho observó que los actores de amenazas explotaban una falla en Fortinet FortiClient EMS (CVE-2026-35616, puntuación CVSS: 9.1) para implementar un ladrón de información llamado EKZ Stealer contra un cliente en el sector de energía, servicios públicos y residuos con el objetivo final de recolectar credenciales de navegadores basados ​​en Chromium y Firefox y exfiltrarlas a través de PowerShell.