Silent Swap Crypto Clipper utiliza una extensión falsa de Google Notes para reemplazar las direcciones de billetera – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han señalado una campaña activa de extensión del navegador diseñada para robar criptomonedas reemplazando sigilosamente las direcciones de billetera cuando usuarios desprevenidos inician una transacción.

La actividad del clipper de criptomonedas ha recibido un nombre en clave Intercambio silencioso por los laboratorios McAfee.

«La campaña se entrega a través de instaladores no firmados, observados tanto en las variantes .NET como en Golang, que implementan una extensión maliciosa de Chromium que se hace pasar por una utilidad benigna de ‘Google Notes’», dijo la empresa de ciberseguridad. dicho en un informe técnico compartido con The Hacker News.

El instalador .NET sin firmar, llamado BaseZipInstaller, está diseñado para recuperar un archivo ZIP, que sirve como base para la extensión maliciosa del navegador al escanear el sistema en busca de navegadores basados ​​en Chromium. Para cada perfil detectado en esos navegadores, finaliza por la fuerza el proceso del navegador e inyecta la extensión modificando las Preferencias seguras y los archivos de Preferencias.

El objetivo final de la extensión es actuar como un cortapelos capaz de interceptar y manipular direcciones de billetera copiadas en el portapapeles del sistema con el objetivo de redirigir los fondos a una billetera controlada por el atacante. Para lograr sus objetivos, la extensión falsa de Google Notes solicita a los usuarios que le otorguen permisos para acceder al portapapeles, a todas las URL y al historial de navegación.

Debido a que la mayoría de las transacciones en blockchain son irreversibles, un intercambio de direcciones puede resultar en una pérdida financiera permanente. McAfee Labs dijo que la actividad se superpone con una campaña anterior de CountLoader que entregó un cripto clipper, con evidencia que apunta al mismo actor de amenazas detrás de ambos grupos.

Ciberseguridad

Lo que distingue a Silent Swap es el uso de una técnica llamada EtherHiding que utiliza la cadena de bloques como solucionador de caída muerta para recuperar los detalles del servidor de comando y control (C2) activo. Esto permite al atacante actualizar trivialmente el valor de un contrato inteligente para que apunte al nuevo dominio en lugar de tener que volver a implementar el malware.

El segundo aspecto gira en torno a la instalación encubierta de la extensión del navegador en navegadores basados ​​en Chromium como Google Chrome, Microsoft Edge, Brave y Vivaldi mediante la modificación de archivos de configuración protegidos del navegador. El ataque, sin embargo, depende de habilitar el modo de desarrollador para versiones más nuevas de los navegadores, algo que un actor de amenazas puede lograr mediante tácticas de ingeniería social.

«Normalmente, estos navegadores almacenan datos de verificación de seguridad (valores hash/HMAC) junto con configuraciones sensibles para detectar cambios no autorizados», dijo McAfee. «El malware recalcula y actualiza estos valores de seguridad después de alterar los archivos, engañando al navegador haciéndole creer que la extensión maliciosa se instaló legítimamente».

«Esto permite que la extensión omita el proceso normal de instalación de la tienda web de extensiones y se cargue silenciosamente sin la aprobación del usuario».

La postura de persistencia y evasión de la campaña se ha caracterizado como deliberada y estratificada, con el enfoque principal en mantener una baja visibilidad para el usuario final y una alta resistencia contra la eliminación y el análisis estático. La persistencia se establece registrando la extensión modificando el archivo de Preferencias seguras del navegador para que se cargue en inicios posteriores del navegador sin necesidad de un mecanismo separado.

Además, el malware intenta habilitar el modo de desarrollador mediante programación en Brave y Opera, y el instalador se autoelimina después de la ejecución, lo que elimina efectivamente un indicador de compromiso inicial. Otra técnica de evasión es el uso de la sustitución dinámica de billetera, que es responsable de obtener una dirección de reemplazo correspondiente a la dirección original de la víctima.

«Envía la dirección de la billetera interceptada al servidor del atacante y utiliza la respuesta para sustituir dinámicamente la dirección original», dijo McAfee. «Si la solicitud de backend falla, la función recurre a una dirección de billetera codificada predefinida, lo que garantiza una actividad maliciosa ininterrumpida».

Para cada patrón de coincidencia de dirección de billetera asociado con Bitcoin (BTC), Ethereum, Bitcoin Cash, Ripple y Dash, se asigna a una dirección única controlada por el atacante en el lado del servidor. Por el contrario, todas las direcciones de Solana enviadas se resuelven en una única dirección de atacante. Al momento de escribir este artículo, se ha descubierto que la dirección de Solana tiene un saldo de $1,902.45.

«Cada dirección enviada se asigna a una dirección única controlada por el atacante. Volver a enviar el mismo original devuelve el mismo reemplazo, lo que indica una asignación determinista uno a uno mantenida en el lado del servidor.

Los datos de telemetría sugieren que las infecciones están distribuidas globalmente, con una mayor concentración de víctimas reportadas en la India. Otros países afectados por la campaña son Estados Unidos, Brasil, Indonesia y España.

«Esta campaña es una ilustración concisa de hacia dónde se dirige el robo de criptomonedas dirigido a los consumidores», dijo McAfee. «Las direcciones estáticas de los atacantes han sido reemplazadas por un mapeo por víctima del lado del servidor. Los dominios de comando y control frágiles y codificados han sido reemplazados por una búsqueda resuelta en blockchain que un operador puede rotar con una sola transacción».

Las extensiones de Chrome y Firefox que se hacen pasar por VPN gratuitas añaden ladrones de portapapeles

La divulgación se produce cuando Socket informó sobre un par de extensiones maliciosas para los navegadores Chrome y Mozilla Firefox, ambas con el nombre «VPN Go: Free VPN» en Chrome Web Store y en el mercado de complementos de Firefox.

Ciberseguridad

«Ambas extensiones se presentan como herramientas VPN gratuitas e incluyen una funcionalidad de proxy visible», afirman los investigadores de Socket Kirill Boychenko y Kush Pandya. dicho. «Bajo el capó, ambos también contienen una lógica maliciosa de robo de portapapeles que monitorea continuamente el texto copiado y lo exfiltra a una infraestructura controlada por el actor de amenazas».

El comportamiento se extiende más allá de las direcciones de billetera, ya que permite a los operadores desviar todo tipo de datos confidenciales, incluidas contraseñas, códigos de autenticación, claves API, tokens OAuth y frases iniciales.

Un examen más detallado de las extensiones ha revelado un patrón de actualización maliciosa por etapas, donde el desarrollador de la extensión publicó inicialmente una versión benigna en el escaparate de la extensión antes de introducir la capacidad de robo del portapapeles a través de una actualización posterior.

Si bien se ha descubierto que las versiones 1.1 y 1.2 de la extensión de Chrome filtran datos del portapapeles a «178.236.252[.]133», la versión 1.3 cambia el canal de exfiltración a una dirección IP diferente («77.91.123[.]187»). En el caso de su equivalente Firefox, 1.3.3 es la primera versión que incluye el ladrón de portapapeles y envía la información a «178.236.252».[.]133.» La actualización 1.3.4 mueve la infraestructura a «77.91.123[.]187.»

Se recomienda a los usuarios que hayan instalado cualquiera de las extensiones que las eliminen de inmediato y traten cualquier secreto mientras la extensión estuvo activa como comprometida.

«El código estático es suficiente para mostrar que las extensiones fueron diseñadas para funcionar como herramientas proxy, no simplemente para mostrar una interfaz VPN falsa», dijo Socket. «La capacidad del proxy aún aumenta el riesgo porque puede enrutar el tráfico del navegador a través de la infraestructura proporcionada por el actor de amenazas, exponer el tráfico HTTP en texto plano y los metadatos de conexión, y hacer que la extensión parezca útil mientras el monitor del portapapeles se ejecuta en paralelo».

Google detalla la nueva puerta trasera STOCKSTAY de Turla utilizada en ataques de espionaje en Ucrania – CYBERDEFENSA.MX

El actor de amenazas patrocinado por el estado ruso conocido como Turla ha sido atribuido a una puerta trasera .NET previamente indocumentada llamada ESTANCIA EN STOCK que se ha desplegado contra organizaciones gubernamentales y militares en Ucrania, y entidades que tienen intereses en la política exterior italiana.

Al describir la puerta trasera de Windows como desarrollada continuamente por el grupo de piratería, Google Threat Intelligence Group (GTIG) dijo que la herramienta de ciberespionaje comparte código significativo y superposiciones funcionales con Kazuar, un implante básico utilizado por el adversario desde 2017. La actividad de desarrollo sospechada de malware se remonta a diciembre de 2022.

«STOCKSTAY es una puerta trasera multicomponente escrita en .NET, que utiliza el marco Windows Forms, que se comunica con su comando y control (C2) a través de una conexión WebSocket segura, utilizando el código abierto. websocket-nítido biblioteca», GTIG dicho.

«STOCKSTAY consta de varios componentes distintos que se comunican entre sí a través de un canal de comunicación entre procesos (IPC), basado en el intercambio de WM_COPYDATA mensajes.»

Ciberseguridad

La evidencia indica que el implante fue diseñado originalmente para imitar una herramienta de visualización de datos del mercado de valores, antes de ser adaptado para hacerse pasar por otros programas inofensivos como visores de PDF y utilidades de calculadora. El punto de partida es un componente de descarga con nombre en código STOCKSTAY.MARKETMAKER que instala y ejecuta tres módulos adicionales:

  • STOCKSTAY.BROKER DE BOLSAun tunelizador con reconocimiento de proxy que facilita las capacidades de comunicación de red a la suite STOCKSTAY más amplia al establecer una conexión WebSocket segura a un servidor remoto específico.
  • STOCKSTAY.STOCKTRADERla principal puerta trasera que permite la recopilación de información.
  • STOCKSTAY.BOLSAun orquestador o controlador que analiza la configuración de la puerta trasera para establecer varias opciones con respecto a la ejecución del malware, como el servidor WebSocket, el intervalo de tiempo y los días en los que se supone que no debe funcionar. También se comunica con STOCKSTAY.STOCKBROKER para proporcionar los detalles del servidor y recibir mensajes a través de la conexión WebSocket establecida, así como con STOCKSTAY.STOCKTRADER para emitir comandos que se ejecutarán en el host comprometido.
Arquitectura del malware STOCKSTAY

Algunos de los comandos de soporte de STOCKSTAY.STOCKTRADER se enumeran a continuación:

  • Del, para eliminar los archivos especificados
  • Dir, para enumerar los directorios especificados.
  • Obtener, para recuperar uno o más archivos específicos que coincidan con ciertas extensiones
  • MkDir, para crear uno o más directorios
  • RmDir, para eliminar los directorios especificados
  • Imagen, para realizar una captura de pantalla de la pantalla del dispositivo
  • MultyTask, para ejecutar una lista de tareas separadas por punto y coma a la vez
  • Poner, para subir un archivo al dispositivo
  • RegRead, para leer un valor del Registro de Windows
  • RegDelete, para eliminar un valor del Registro de Windows
  • RegWrite, para establecer un valor del Registro de Windows
  • Ejecutar, para ejecutar un nuevo proceso.
  • Sysinfo, para recopilar información del sistema.
  • UnpackArchive, para extraer el archivo ZIP especificado a su directorio actual

Google dijo que identificó un repositorio GitHub de acceso público («ChikenFresh/google-ai-labs-it«) que contiene una implementación de Python del controlador de servidor STOCKSTAY WebSocket orientado a la víctima que es responsable de manejar los mensajes entrantes de un cliente conectado y registrar su dirección IP.

«La incapacidad del servidor para descifrar los mensajes entrantes impide la introspección por parte de los operadores de la plataforma y confunde aún más la ubicación de la infraestructura dedicada del actor de la amenaza», señaló GTIG. «Esta arquitectura se parece un poco a la infraestructura Kazuar C2 de múltiples saltos de Turla».

Los ataques que distribuyen STOCKSTAY han aprovechado constantemente señuelos de temática académica o diplomática para apuntar a organizaciones gubernamentales y militares dentro de Ucrania, y las primeras versiones de la puerta trasera se utilizaron en ataques dirigidos a entidades en Italia, los Países Bajos, Polonia y Alemania. Dicho esto, se desconoce qué entidades europeas fueron señaladas en estos ataques.

Cronología de las observaciones de STOCKSTAY

En al menos un caso observado a principios de 2025, se dice que los actores de Turla emplearon un correo electrónico de phishing que contenía un archivo adjunto RDP malicioso que, cuando se abre, establece una conexión entre el dispositivo de la víctima y la infraestructura controlada por el actor, a través de la cual se pueden implementar cargas útiles adicionales, incluido STOCKSTAY.

En noviembre de 2025, se descubrió que una ola de phishing por correo electrónico dirigida a Ucrania entregaba el implante a través de archivos RAR que explotan CVE-2025-8088, una vulnerabilidad de WinRAR que ha sido explotada por varios grupos de hackers rusos como Sandworm, Gamaredon y RomCom.

Otras campañas han aprovechado instaladores MSI (en un caso alojados en GitHub) y archivos RAR que contienen un script de aplicación HTML (HTA), el último de los cuales está diseñado para ejecutar una variante de STOCKSTAY.MARKETMAKER. Luego, el descargador recupera un archivo ZIP que contiene los componentes principales de STOCKSTAY alojado en una instancia comprometida de WordPress.

Ciberseguridad

Un aspecto digno de mención del malware es que Turla lo ha empleado en múltiples etapas distintas de sus operaciones, una como una forma de obtener acceso inicial a entornos que no han sido perfilados previamente y durante la post-explotación después del reconocimiento para su ejecución en un host específico.

«Esta configuración implica que, en esta etapa, el actor sabe exactamente qué máquina está siendo atacada, probablemente a través de los accesos existentes al entorno de destino», explicó GTIG. Esto se vio dentro de las redes ucranianas donde STOCKSTAY se desplegó hacia el final de una operación que anteriormente había dependido en gran medida de otras herramientas del grupo, como Kazuar».

Las superposiciones de STOCKSTAY con Kazuar surgen de las similitudes en cómo se delinean las responsabilidades entre los diferentes componentes. El uso de Kazuar de los módulos Kernel, Bridge y Worker dentro de Kazuar fue detallado ampliamente por el equipo de Microsoft Threat Intelligence el mes pasado. La separación de distintos componentes basados ​​en roles en STOCKSTAY se detectó por primera vez en una muestra cargada en VirusTotal en diciembre de 2023 desde los Países Bajos.

Estos puntos en común han planteado la posibilidad de que tanto STOCKSTAY como Kazuar hayan sido desarrollados y mantenidos en parte por el mismo desarrollador o equipo.

«Creemos que STOCKSTAY se está desarrollando a imagen de KAZUAR, y es probable que varias decisiones de diseño surjan de la gran experiencia del actor de amenazas en la realización de operaciones utilizando este conjunto de herramientas de larga data», dijo Google. «Ambos ecosistemas dependen en gran medida del desarrollo .NET y se ha observado que utilizan sitios de WordPress comprometidos durante varias etapas de sus operaciones».

«Evaluamos con poca confianza que nuestras observaciones del despliegue de STOCKSTAY junto a KAZUAR durante las operaciones activas pueden ser el resultado de que el actor de amenazas busca probar nuevas capacidades en operaciones activas, particularmente donde pueden esperar que su acceso existente sea remediado en un futuro cercano».

Google fija el 30 de septiembre como fecha límite para la verificación de desarrolladores de Android en cuatro países – CYBERDEFENSA.MX

Google ha fijado el 30 de septiembre de 2026 como el día en que comenzará a aplicar Verificación de desarrollador de Android en los primeros cuatro países, y las tiendas de aplicaciones de los principales fabricantes de dispositivos están presentes desde el principio.

En esa fecha, los teléfonos Android certificados en Brasil, Indonesia, Singapur y Tailandia bloquearán las instalaciones normales de aplicaciones cuyos desarrolladores no hayan registrado una identidad con Google, ya sea que la aplicación provenga de Google Play o de las tiendas administradas por Samsung, Xiaomi, OPPO, vivo, Honor y Transsion.

Los dispositivos certificados son los que se envían con los servicios de Google y Play Protect, que, según el recuento de F-Droid, representa más del 95 por ciento de los dispositivos Android fuera de China.

La mayoría de los usuarios no se darán cuenta, que es el punto. Las aplicaciones de desarrolladores verificados siguen instalándose como antes. La fricción recae en aplicaciones de desarrolladores que Google no ha verificado, y es más difícil en los canales independientes y de código abierto, basados ​​en que no necesitan el permiso de Google para enviar.

Ciberseguridad

Los desarrolladores que distribuyen a través de esas tiendas deben verificar y registrarse antes de la fecha límite. Google dice que las aplicaciones que no lo hagan no estarán disponibles para una nueva instalación en dispositivos certificados en los cuatro países.

Lo que cambia el 30 de septiembre

La verificación se ejecuta en el dispositivo. Google está impulsando una nueva servicio del sistemael Verificador de desarrolladores de Android, para teléfonos con Android 8 y versiones posteriores a partir de junio de 2026, y confirma que una aplicación está registrada para un desarrollador verificado antes de que se instale.

Después del 30 de septiembre, en los cuatro mercados de lanzamiento, una aplicación no registrada no se instalará mediante la ruta normal. Todavía se puede instalar a través de Android Debug Bridge (ADB) o mediante el flujo avanzado, la ruta deliberadamente de alta fricción que Google construyó a principios de este año. Esa ruta hace que el usuario active el modo de desarrollador, reinicie, espere 24 horas y se vuelva a autenticar antes de descargar una aplicación no verificada, y se globaliza en agosto.

El registro se abrió para todos los desarrolladores en marzo y Google dice que ya cubre casi todas las instalaciones en Google Play y una gran mayoría de las que se realizan fuera de él.

Para registrarse, un desarrollador proporciona a Google un nombre legal, una dirección y datos de contacto, es posible que deba cargar una identificación gubernamental y demuestra la propiedad de cada aplicación enviando un APK firmado con su clave privada.

Google también está agregando API para registro masivo y verificación de nombres de paquetes, con delegación de OAuth para que una tienda de terceros pueda ejecutar partes del proceso para los desarrolladores. Las dos interfaces, una API de estado de ID de desarrollador de Android y una API de consola de desarrollador de Android, llegarán en julio.

Un carril separado para cuentas gratuitas de distribución limitada ingresa al acceso anticipado en julio y se lanza a nivel mundial en agosto; permite a estudiantes y aficionados compartir aplicaciones con hasta 20 dispositivos, sin identificación gubernamental ni tarifa. La cuenta de desarrollador completa estándar conlleva una tarifa única de $25.

Por qué el campo del código abierto está luchando contra ello

El caso de Google es el malware. Dice que las fuentes descargadas contienen mucha más cantidad que Google Play, y que las estafas funcionan cada vez más convenciendo a la víctima para que instale un APK malicioso en el acto.

Un control de identidad y una espera de 24 horas están destinados a romper con eso. Google dice que eligió los cuatro países de lanzamiento porque se ven muy afectados por estafas de aplicaciones, a menudo por parte de infractores reincidentes.

Ciberseguridad

El rechazo ha sido fuerte desde que se anunció el programa en agosto de 2025. F-Droid, el repositorio de aplicaciones de software libre, dice que el requisito pondría fin a su proyectoporque crea y firma aplicaciones de muchos colaboradores seudónimos que no le darán a Google una identidad legal.

A Mantener Android abierto Una campaña respaldada por más de 70 organizaciones en 23 países ha pedido a Google que elimine las comprobaciones de identificación de las aplicaciones enviadas fuera de Play. Las concesiones de Google, el flujo avanzado y las cuentas de 20 dispositivos responden a la queja de que se estaba eliminando la descarga lateral. No tocan el problema más profundo: una sola empresa se sentaría en el camino de instalación de casi todos los dispositivos Android fuera de China y decidiría quién obtiene el camino fluido.

Quedan abiertas tres preguntas antes del lanzamiento global en 2027: si Google detalla un proceso de apelación para los desarrolladores que marca por error, qué mantiene en el registro de identidad y durante cuánto tiempo, y si ofrece alguna ruta para repositorios como F-Droid que no pueden cumplir con el control de propiedad por aplicación sin cambiar su funcionamiento.

El nuevo cargador OXLOADER utiliza anuncios maliciosos de Google para ofrecer CastleStealer – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una nueva campaña que ofrece CastleStealer mediante un cargador de malware no reportado previamente denominado OXLOADER.

Según Elastic Security Labs, la campaña aprovecha los anuncios maliciosos de Google como punto de partida para distribuir el malware. La evidencia indica que el actor de la amenaza probablemente habla ruso y tiene motivaciones financieras, debido a la presencia de exclusiones explícitas para evitar infectar máquinas ubicadas en la región de la Comunidad de Estados Independientes (CEI). La campaña lleva el nombre en código REF8372.

«El cargador utiliza varias capas de ofuscación (aplanamiento de flujo de control, predicados opacos, aritmética booleana mixta), códigos auxiliares de descifrado que se modifican automáticamente y abusa de la sección .reloc de Windows para preparar el código shell», afirman los investigadores Daniel Stepanic y Jia Yu Chan. dicho en una avería técnica.

El ataque comienza cuando usuarios desprevenidos ingresan consultas como «versión lts de node.js» en motores de búsqueda como Google, redireccionándolos a un sitio web falso («node-js[.]prentiva99[.]info») surgió a través de anuncios falsos publicados bajo el nombre verificado «ВОЛОДИМИР ТЕРЕЩЕНКО» que supuestamente tiene su sede en Ucrania.

Ciberseguridad

Actualmente se desconoce si la cuenta del anunciante está vinculada al actor de la amenaza real, o si es una cuenta frontal o una identidad comprada. La cuenta del anunciante, junto con sus campañas publicitarias, se eliminó de Google el 14 de mayo de 2026.

Los usuarios que terminan interactuando con el sitio reciben un script por lotes alojado en Storj, una plataforma descentralizada de almacenamiento en la nube de código abierto. El abuso de Storj ilustra una vez más cómo los actores de amenazas continúan aprovechando servicios legítimos para evadir los filtros de reputación basados ​​en dominios.

La ejecución del script por lotes muestra una interfaz de usuario (UI) del asistente de instalación falsa, mientras se descarga sigilosamente una carga útil de la siguiente etapa, una Ejecutable alojado en Storj denominado OXLOADER a través de un comando de PowerShell y ejecutándolo con -Verb RunAs para activar un mensaje de Control de cuentas de usuario (UAC) de Windows.

Luego, el ataque emplea la carga lateral de DLL para lanzar una DLL maliciosa, que luego procede a descifrar y ejecutar la carga útil de CastleStealer. OXLOADER también utiliza técnicas como el aplanamiento del flujo de control (CFF) y la aritmética booleana mixta (MBA) para evadir la detección estática, al mismo tiempo que toma medidas para garantizar que no se ejecute en entornos aislados.

Ciberseguridad

CastleStealer es un ladrón de información .NET que se distribuyó recientemente junto con CastleLoader a través de un señuelo estilo ClickFix disfrazado de herramienta gratuita de edición de imágenes como parte de una campaña con nombre en código BackgroundFix. CastleLoader se atribuye a un grupo de actividad de amenazas conocido como GrayBravo.

«OXLOADER se encuentra en una fase operativa temprana, pero la ingeniería detrás de él sugiere que vale la pena observar esta familia», dijo Elastic. «La ofuscación del código, las medidas anti-VM, el código de apariencia benigna utilizado para enmascarar sus archivos binarios y las técnicas de puesta en escena únicas reflejan decisiones de ingeniería deliberadas para evadir el análisis».

«Esa inversión está dando sus frutos, lo que da como resultado bajas tasas de detección en motores estáticos y ciclos de detonación, lo que le da a OXLOADER una ventana para operar antes de ser perseguido».

La falla del SDK de Google Vertex AI permite a los atacantes secuestrar cargas de modelos a través de Bucket Squatting – CYBERDEFENSA.MX

Una falla en el SDK de Google Cloud Vertex AI para Python permitió a un atacante sin acceso al proyecto de una víctima secuestrar el modelo de aprendizaje automático de la víctima, cargar y ejecutar código dentro de la infraestructura de servicio de Google.

Unidad 42 de Palo Alto Networks, que encontró y reportado El error a través del programa de recompensas por errores de Google, llama a la técnica «Pepinillo en el medio» y dijo que no vio ninguna explotación en la naturaleza. Google lo ha parcheado; si usa el SDK, actualice a la versión 1.148.0 o posterior.

El atacante solo necesitaba un proyecto propio de Google Cloud y el ID del proyecto de la víctima, que suele ser público. Sin credenciales, sin phishing, sin punto de apoyo en el objetivo.

La falla estaba en cómo el SDK eligió un depósito temporal de Cloud Storage para la carga de modelos. Si un usuario no configuró un depósito, el SDK generó un nombre predecible a partir del ID del proyecto y la región, como región-ensayo-vértice-del-proyecto. Comprobó si ese cubo existía, pero no si la víctima era su propietario.

Debido a que los nombres de los depósitos son globalmente únicos, un atacante podría crear primero el depósito esperado en su propio proyecto. El SDK de la víctima luego cargaría los archivos del modelo en el depósito del atacante. Luego, el atacante podría reemplazar el modelo cargado por uno malicioso.

Ciberseguridad

Muchos modelos de Python ML se guardan con conservar en vinagre o biblioteca de trabajoque puede ejecutar código cuando se carga un archivo. Cuando Vertex AI cargó más tarde el modelo intercambiado, el código del atacante se ejecutó dentro del contenedor de servicio.

El ataque dependía de la velocidad. La Unidad 42 midió aproximadamente 2,5 segundos entre la carga de la víctima y Vertex AI leyendo el archivo. En su prueba de concepto, el atacante utilizó una función en la nube que se activó después de la carga y reemplazó el modelo en 1,4 segundos, antes de que Vertex AI lo leyera.

Luego, la carga útil robó un token OAuth del servidor de metadatos del contenedor de servicio y lo envió al atacante. En el entorno de prueba de la Unidad 42, ese token no se limitó a la implementación comprometida. Podría acceder a otros artefactos del modelo en el mismo proyecto de inquilino administrado por Google, incluido un modelo TensorFlow completo con pesos entrenados, así como metadatos de BigQuery, listas de acceso, registros de inquilinos, nombres de clústeres de GKE y rutas de imágenes de contenedores internos.

El ataque solo funcionó bajo condiciones específicas: el depósito de preparación predeterminado de la víctima no existía aún en esa región y la víctima abandonó el cubo_puesta en escena parámetro desarmado. El primero es común para un nuevo proyecto en Vertex AI en una región.

El segundo depende de que el desarrollador confíe en el valor predeterminado del SDK en lugar de nombrar su propio depósito.

La Unidad 42 informó la falla a través del Programa de recompensa por vulnerabilidades de Google el 5 de marzo de 2026. Probó las versiones 1.139.0 y 1.140.0, las últimas disponibles en ese momento, y encontró que ambas eran vulnerables.

Google envió una solución inicial en v1.144.0 el 31 de marzo, agregando un uuid4 aleatorio al nombre del depósito. Completó la solución en v1.148.0 el 15 de abril, se agregó la verificación de propiedad del depósito para bloquear la okupación del depósito en Model.upload(). Al momento de su publicación, ni Unit 42 ni los boletines de seguridad Vertex AI de Google enumeran un CVE para el problema.

Ciberseguridad

Actualice a 1.148.0 o posterior para que la verificación de propiedad esté activa. Además, establezca un staging_bucket explícito en una ubicación de Cloud Storage que controle al cargar modelos. Debido a que la lógica defectuosa reside en el SDK del cliente, verifique la versión de google-cloud-aiplatform dondequiera que se ejecute, incluidos los cuadernos, los trabajos de CI y los canales de capacitación, no solo los servicios de producción.

Es la segunda falla con nombre de depósito predecible que surge en Vertex AI este año. Google parcheado CVE-2026-2473 en febrero, un error separado en Vertex AI Experiments que también permitió la ejecución de código entre inquilinos, el robo de modelos y el envenenamiento.

El trabajo anterior de la Unidad 42 sobre los permisos de agente de servicio predeterminados de Vertex AI trazó una ruta relacionada desde un agente de IA implementado hasta los datos de clientes e inquilinos.

Los piratas informáticos chinos abusaron de las reglas de Google Workspace para robar correos electrónicos de investigación y defensa

Un grupo de espionaje vinculado a China se ocultó dentro de las redes de investigación médica, académica y militar de América del Norte durante más de un año, robando silenciosamente correos electrónicos confidenciales de investigación y defensa.

La entrada era una puerta trasera en su Mozo de estación Servidores de investigación que robaron credenciales de inicio de sesión. La exfiltración fue la parte inusual: los atacantes reconfiguraron las propias reglas de Google Workspace de las víctimas para copiar cualquier mensaje que coincidiera con sus palabras clave a una bandeja de entrada que controlaban.

El Threat Intelligence Group (GTIG) de Google presentó la campaña en un informe publicado esta semana y lo atribuye con alto nivel de confianza a un grupo que rastrea como UNC6508.

El actor y su puerta trasera REDCap no son nombres nuevos; Google sacó a la luz ambas cosas por primera vez en febrero, en un informe más amplio sobre ataques respaldados por el Estado contra el sector de defensa. No nombró a las víctimas, sino que las describió únicamente como múltiples organizaciones en Estados Unidos y Canadá: proveedores clínicos, centros académicos, instituciones de salud militares, grupos de defensa y reguladores de salud.

Ciberseguridad

Google dice que les notificó e interrumpió la infraestructura del grupo.

¿Cómo entraron?

El punto de entrada fue Mozo de estación (Research Electronic Data Capture), una plataforma web que utilizan hospitales y universidades para crear y gestionar bases de datos de estudios. UNC6508 comprometió servidores REDCap externos.

Google no ha precisado el vector de acceso inicial, no ha nombrado un CVE específico ni ha enumerado las versiones afectadas, aunque vio que el grupo investigaba las versiones más antiguas y vulnerables.

Aproximadamente tres meses después de ingresar, el grupo implementó llamadas GTIG de malware personalizadas. INFINITERADOque troyaniza los propios archivos del sistema de REDCap y hace tres cosas.

  • Primero, secuestra el proceso de actualización para que cada nueva versión de REDCap reinyecte el código en lugar de borrarlo.
  • En segundo lugar, recopila nombres de usuario y contraseñas de la página de inicio de sesión y los almacena, cifrados, en tablas de bases de datos locales.
  • En tercer lugar, actúa como una puerta trasera, recibiendo comandos a través de cookies HTTP y ejecutándose en cada carga de página.

El primer compromiso conocido data de septiembre de 2023, y la actividad continuó hasta noviembre de 2025. Una vez en el servidor, UNC6508 ejecutó reconocimiento interno y descubrimiento de credenciales, extrayendo las credenciales de la base de datos y de la cuenta de servicio, luego usó esos inicios de sesión para pasar a la red interna y a una cuenta de administrador de dominio.

Google no explica la ruta exacta a esa cuenta de administrador. Con derechos de administrador, el grupo configuró la exfiltración.

Cómo robaron el correo electrónico

La exfiltración se basó en una característica que ya estaba allí. UNC6508 abusó de las reglas de cumplimiento de contenido, una función de administración legítima de Google Workspace que escanea el correo en busca de palabras clave y puede copiar o reenviar mensajes coincidentes.

Existen características similares en otras suites de correo en la nube. El grupo creó una regla, mal escrita «Patroit», que analizaba casi 150 palabras clave, términos de búsqueda y direcciones de correo electrónico. Cuando un mensaje coincidía, Workspace lo enviaba silenciosamente a una dirección de Gmail controlada por un atacante, que desde entonces Google ha desactivado. Sin malware en el servidor de correo, sin herramienta de exfiltración independiente, sin tráfico de red inusual. Solo una función de correo incorporada, destinada a copiar los secretos de la organización a una bandeja de entrada de propiedad de los atacantes.

MITRE ya cataloga Abuso de reglas de reenvío de correo electrónico como técnica conocida. Lo que GTIG señala como nuevo aquí es el uso de reglas de cumplimiento de contenido de dominio para hacerlo, un método que, según dice, no había visto antes en un actor vinculado a China.

Ciberseguridad

Las palabras clave de la regla se corresponden con las prioridades de recopilación de UNC6508: política geoestratégica, estrategia y equipo militar, tecnología avanzada que incluye inteligencia artificial y vehículos no tripulados, programas cibernéticos ofensivos e investigación médica. Un término destacó por su especificidad, chikunguñael virus transmitido por mosquitos detrás de un brote en 2025 en la provincia china de Guangdong.

que hacer

Comience con REDCap. Parchee los servidores externos y elimine las versiones antiguas directamente, no solo junto con la versión actual. REDCap permite que las versiones heredadas se ejecuten en paralelo, y eso es lo que permite los ataques de degradación, donde un atacante fuerza al software a volver a una versión vulnerable conocida.

Luego revisa el lado del correo. Revise las reglas de cumplimiento de contenido y reenvío de correo de Workspace, o su equivalente, para detectar cualquier cosa que haga CCO o redirija el correo a direcciones externas. Consulte los registros de auditoría del administrador para saber cuándo cambiaron las reglas, no solo lo que dicen ahora. Extraiga los indicadores publicados de GTIG y busque INFINITERED. Y coloque MFA resistente al phishing en las cuentas de administrador, ya que todo el paso del robo de correo dependía del acceso del administrador.

Google todavía no sabe cómo llegó UNC6508 por primera vez a los servidores REDCap. La parte que vale la pena observar es la regla del correo. Una vez que los atacantes obtienen acceso de administrador, una función incorporada en la nube puede convertirse silenciosamente en una ruta de exfiltración, y eso es lo que los defensores deben auditar, no solo la puerta trasera de REDCap.

Google expone un grupo de espionaje chino que ha estado acechando en las redes sin ser detectado desde 2023

Los cazadores de amenazas de Google detectaron otro grupo de espionaje patrocinado por el estado chino que durante años se había infiltrado en sistemas pertenecientes a organizaciones gubernamentales y privadas para robar datos en el ámbito académico, médico, militar, de ciberseguridad y de política exterior.

Google Threat Intelligence Group descubrió el grupo de amenazas previamente desconocido UNC6508que apuntó a organizaciones en Estados Unidos y Canadá, a finales de 2025, pero su primer compromiso conocido se remonta a septiembre de 2023.

La revelación refleja un patrón alarmante de grupos de espionaje chinos que abren puertas traseras en infraestructura crítica para posicionarse previamente para posibles sabotajes, interceptar investigaciones y robar datos con implicaciones para la seguridad nacional. Estos grupos que trabajaban a instancias del gobierno de China, incluido el UNC6508, operaron en secreto durante años antes de que las autoridades o los investigadores descubrieran su actividad.

«No conocemos el alcance total o el impacto de la campaña», dijo a CyberScoop Patrick Whitsell, ingeniero senior de seguridad de GTIG. Los investigadores dijeron que el grupo de amenazas irrumpió en una universidad de investigación médica en septiembre de 2023, robó credenciales y comunicaciones y permaneció activo en los sistemas de la institución hasta noviembre de 2025, cuando fue descubierto.

Google dijo que confirmó que había múltiples víctimas comprometidas con INFINITERED, una puerta trasera personalizada que el grupo de amenazas implementó en redes específicas para robar credenciales administrativas después de explotar servidores REDCap (Research Electronic Data Capture) externos.

Los investigadores aún no saben cómo UNC6508 obtuvo acceso inicial a los servidores REDCap. Google dijo que el software de encuestas y bases de datos, que se creó en la Universidad de Vanderbilt y emitió múltiples parches para vulnerabilidades críticas de ejecución remota de código a lo largo de 2023, se utiliza ampliamente en la comunidad de investigación médica.

«Dada la amplitud de los criterios de recopilación de inteligencia del actor de amenazas y su capacidad para permanecer sin ser detectados dentro de las redes comprometidas durante más de un año, evaluamos que las víctimas conocidas probablemente representen sólo una fracción de una campaña más grande», dijo Whitsell. «También evaluamos que este actor de amenazas altamente capaz permanecerá activo y seguirá siendo una amenaza para las industrias de defensa, tecnología y medicina en el futuro previsible».

Google dijo que la campaña estaba dirigida a proveedores clínicos, centros médicos académicos e instituciones de salud militares de EE. UU., demostrando capacidades avanzadas de un grupo de amenazas que actualmente no se superpone con ningún otro grupo conocido públicamente.

El grupo de amenazas abusó de las reglas de cumplimiento de dominio para robar datos, una técnica que no se basa en malware o herramientas de supervivencia, y enruta el tráfico a través de IP con sede en EE. UU. para mezclarse con el tráfico legítimo, dijeron los investigadores.

«Tenemos alguna evidencia que sugiere que se trata de un gran grupo de amenazas con múltiples subequipos, pero esto no está confirmado», dijo Whitsell.

Al igual que otros grupos de espionaje patrocinados por el Estado de China previamente identificados, UNC6508 permanece activo.

Google dijo que interrumpió parte de la infraestructura conocida de UNC6508 al deshabilitar una cuenta de Gmail que usaba para filtrar datos, notificó a las organizaciones afectadas y ayudó a remediar los compromisos antes de publicar una investigación sobre las actividades de UNC6508.

Whitsell dijo que varios casos de compromiso no confirmados siguen bajo investigación.

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.

Google demanda a la red china Smishing acusada de utilizar Gemini AI en phishing – CYBERDEFENSA.MX

Google dijo el viernes que está emprendiendo acciones legales contra una red china de cibercrimen, acusándola de utilizar su agente de inteligencia artificial (IA) Gemini para enviar mensajes de texto de phishing dirigidos a estadounidenses. Se dice que la red está detrás del desarrollo y gestión de un kit de software de phishing como servicio (PhaaS) llamado Outsider, según el gigante tecnológico. «La operación convirtió a Gemini en un arma para ayudar

PCPJack secuestra 230 servidores AWS, Google Cloud y Azure para una red de retransmisión SMTP encubierta – CYBERDEFENSA.MX

El actor de amenazas conocido como PCPJack ha secuestrado servidores en la nube asociados con Amazon Web Services (AWS), Google Cloud y Microsoft Azure para crear una red encubierta de retransmisión de correo electrónico SMTP.

«Los servidores empresariales comprometidos en EE. UU., Europa y Asia se convirtieron silenciosamente en servidores proxy SMTP, se verificó su capacidad de retransmisión de correo y se sincronizaron con un consumidor intermedio cada cinco minutos», dijo Hunt.io en un comunicado. «La infraestructura todavía estaba funcionando cuando la encontramos».

La empresa de inteligencia de amenazas dicho encontró código fuente, archivos binarios compilados, registros de estado de implementación, escáneres de Internet, herramientas de explotación y una configuración de Sliver en vivo después de que el actor de amenazas detrás de la operación dejó dos directorios abiertos en un servidor de comando y control (C2) («213.136.80[.]73») sin ninguna autenticación.

PCPJack fue descubierto por primera vez por SentinelOne en abril de 2026 después de que identificó un marco de robo de credenciales que apunta específicamente a los servicios en la nube, mientras tomaba medidas para terminar y eliminar procesos o artefactos asociados con TeamPCP, otro notorio grupo de piratería que ha llamado la atención en los últimos meses por sus ataques a la cadena de suministro de software.

Ciberseguridad

Organizado en uno de los directorios abiertos. Astilla-Kit de herramientas de implementación de proxy SMTP integrado, junto con tunelización Chisel y binarios de proxy para la mayoría de las arquitecturas de CPU de Linux, como AMD64, ARM64 y x86. En el lado de la víctima, el binario se elimina como un archivo oculto con prefijo de punto y se conserva en «/var/tmp/.xs».

También se encuentran en los directorios scripts de implementación diseñados para cargar la configuración del cliente Sliver C2 y filtrar las balizas de Linux que se han registrado en los últimos diez minutos. Las balizas son implantes que llaman periódicamente al servidor C2 a intervalos regulares para registrarse y recuperar comandos.

«Cada baliza recibe un puerto proxy SOCKS5 derivado de manera determinista de un hash MD5 de su UUID Sliver, asignado en el rango 10000-14999», señaló Hunt.io. «La misma baliza siempre se asigna al mismo puerto en todas las ejecuciones, lo que elimina la necesidad de un registro de puerto compartido».

El script también es capaz de ejecutar una puerta de calidad SMTP que busca acceso saliente a smtp.gmail.[.]Com:587. Los hosts que no pasan esta verificación se omiten con un código de salida de cero.

«Esta puerta define el propósito de la operación: los hosts que no pueden transmitir correo electrónico no tienen ningún valor para este canal», añadió la empresa de ciberseguridad. «Las balizas se procesan en lotes de 50, con una espera de 25 minutos después de la carga y 15 minutos después de la ejecución de los comandos, para dar cabida a registros de balizas a intervalos lentos».

Se ha descubierto que las iteraciones posteriores de los scripts de implementación eliminan la puerta SMTP y la lógica de procesamiento por lotes. También está presente un script de diagnóstico que selecciona cinco balizas activas y les asigna a cada una un comando de shell que verifica lo siguiente:

  • Presencia de archivos binarios de Chisel en rutas de caída conocidas
  • Se está ejecutando un proceso de Chisel
  • Espacio en disco
  • Accesibilidad del puerto 9000 en el C2, y
  • Presencia de artefactos de persistencia, como la entrada cron o el servicio systemd
Ciberseguridad

Además, el servidor C2 ejecuta un script Python llamado «chisel_verifier.py» como un demonio en segundo plano persistente, que enumera los puertos activos del túnel Chisel a través de ss -tlnp cada 60 segundos, prueba la capacidad SMTP de cada nuevo puerto y elimina los túneles fallidos o descartados del grupo activo.

Los proxies verificados se enriquecen con la dirección IP de salida, el país y el ASN a través de servicios como api.ipify.[.]org y ip-api[.]com. Luego, las listas de proxy se sincronizan cada cinco minutos a través del Protocolo de copia segura (SCP) con un servidor descendente independiente en 38.242.204.[.]245. Actualmente no se puede acceder al servidor. El objetivo final de la operación aún no está claro en este momento.

«El resultado de 230 nodos es el resultado observable. Si esta progresión refleja un solo operador iterando o múltiples actores que comparten la misma infraestructura no se puede determinar a partir de los archivos recuperados», dijo Hunt.io, describiéndola como una campaña oportunista.

«La lista de proxy verificada se sincroniza cada cinco minutos con ese servidor y alguien la está consumiendo. Ya sea para spam, phishing o cualquier otra cosa, la infraestructura para realizar entregas a escala claramente estaba funcionando».

La puerta trasera FlutterShell se propaga a macOS a través de anuncios maliciosos de Google y YouTube – CYBERDEFENSA.MX

Investigadores de ciberseguridad han arrojado luz sobre una campaña de publicidad maliciosa de macOS cuyo nombre en código es Operación FlutterBridge y que difunde una nueva puerta trasera llamada aleteoshell.

Según la Unidad 42 de Palo Alto Networks, se dice que la campaña es la siguiente etapa de un grupo de actividades previamente informado denominado JSCoreRunner (también conocido como ArchivoRipple) a finales de agosto de 2025. El grupo de ciberdelincuentes detrás de las dos cadenas de ataques está siendo rastreado bajo el nombre de CL-CRI-1089. Se estima que los atacantes están activos desde al menos 2023.

«Creado utilizando el marco Flutter, FlutterShell infecta objetivos con adware a través de aplicaciones de escritorio maliciosas», Unidad 42 dicho. «Además de su funcionalidad de adware, la carga útil posee capacidades de puerta trasera, incluida la ejecución de comandos de shell y la manipulación del sistema de archivos».

Las operaciones atribuidas a CL-CRI-1089 también incluyen Listador de recetas y Calendaromáticoambos bajo una designación más amplia conocida como TamperedChef (también conocido como EvilAI), una serie continua de campañas que implican el uso de versiones troyanizadas de software de productividad para entregar programas potencialmente no deseados (PUP) y adware.

Ciberseguridad

Estas campañas distribuyen anuncios maliciosos de Google y YouTube utilizando una red de empresas fantasma verificadas por Google, y los anuncios actúan como un señuelo para engañar a los objetivos para que implementen malware que se hace pasar por aplicaciones de escritorio legítimas. Algunas de las empresas fachada son AdsParkPro LTD, Ventaja Web Marketing LLCy SUAVE SOMOS ARTE LIMITADO (ahora PACIFIC TRADE SOLUTIONS LTD).

El público objetivo de estos anuncios son usuarios de macOS en EE. UU., Canadá, Australia, Francia y Alemania. Aunque actualmente no se puede acceder a ninguna de las cuentas de Google Ads a través del Centro de transparencia de Google Ads, los registros de YouControl y el registro de Companies House del gobierno del Reino Unido indican que todas las empresas tienen vínculos con individuos ucranianos.

La última versión implica la implementación de FlutterShell, que admite la ejecución de comandos arbitrarios, la interacción del sistema de archivos y la filtración de variables de entorno. Estos esfuerzos se detectaron en marzo de 2026.

«Al ejecutarse, el malware modifica los archivos de configuración de Google Chrome para secuestrar el navegador, forzando todo el tráfico a través de un sitio intermediario lleno de publicidad y controlado por el atacante», dijeron los investigadores Ido Asher, Noa Dekel y Tom Fakterman. «Todas las muestras observadas fueron firmadas con ID de desarrollador de Apple válidas y pasaron con éxito la certificación notarial, lo que significa que los controles de seguridad automatizados de Apple no las marcaron como maliciosas en el momento del envío».

Lo que hace que FlutterShell sea digno de mención es que implementa una arquitectura basada en WebView que utiliza un puente de JavaScript a nativo, lo que permite al adversario alojar lógica maliciosa en un sitio web externo, en lugar de incrustarla en el binario. Esto, a su vez, hace posible alterar dinámicamente el comportamiento del malware en tiempo real sin tener que recompilar o enviar una versión actualizada a los hosts comprometidos.

«En la arquitectura basada en WebView, una aplicación nativa utiliza un componente de navegador web integrado para mostrar contenido», explicó la Unidad 42. «El puente de JavaScript a nativo actúa como un canal de comunicación entre este contenido web y la aplicación nativa del host, permitiéndoles intercambiar datos e invocar funcionalidades de forma cruzada».

Se han identificado tres variantes diferentes de FlutterShell, a saber, PodcastsLounge, PDF-Brain y PDF-Ninja. Esto, junto con la presencia de funciones inacabadas en la lógica de JavaScript alojada en la infraestructura de los atacantes, sugiere que es probable que el malware esté en desarrollo activo.

Ciberseguridad

Algunas de las variantes, PDF-Brain y PDF-Ninja, cuentan con una capacidad de resumen impulsada por inteligencia artificial (IA) al transmitir documentos a través de un servidor controlado por un atacante antes de procesarlos. FlutterShell también permite la toma de huellas digitales del sistema y el robo de datos de la sesión del navegador.

También se ha descubierto que FlutterShell comparte similitudes técnicas con Calendaromático y Recipe Lister, siendo el más obvio la arquitectura de código basada en WebView para facilitar cambios dinámicos en la carga útil. Es más, se ha observado que Advantage Web Marketing LLC no solo difunde anuncios maliciosos sino que también actúa como signatario de variantes de adware de Windows asociadas con el clúster.

«La evolución de JSCoreRunner a FlutterShell representa un aumento significativo en la profundidad técnica para los atacantes detrás de CL-CRI-1089», dijo la Unidad 42. «Además, la escala de la red de distribución, junto con las entidades fantasma verificadas utilizadas para eludir la investigación de la red publicitaria, resalta el peligro persistente de la publicidad maliciosa. La coordinación de múltiples entidades fantasma y el rápido desarrollo y entrega de nuevas variantes de FlutterShell indican que esta campaña está lejos de terminar».