Google tiene atribuido formalmente el compromiso de la cadena de suministro del popular paquete Axios npm con un grupo de actividades de amenazas de Corea del Norte con motivación financiera rastreado como UNC1069.

«Hemos atribuido el ataque a un presunto actor de amenazas norcoreano al que rastreamos como UNC1069», dijo John Hultquist, analista jefe de Google Threat Intelligence Group (GTIG), a The Hacker News en un comunicado.

«Los piratas informáticos norcoreanos tienen una profunda experiencia con ataques a la cadena de suministro, que históricamente han utilizado para robar criptomonedas. La magnitud total de este incidente aún no está clara, pero dada la popularidad del paquete comprometido, esperamos que tenga impactos de gran alcance».

El desarrollo se produce después de que los actores de amenazas tomaron el control de la cuenta npm del mantenedor del paquete para impulsar dos versiones troyanizadas 1.14.1 y 0.30.4 que introdujeron una dependencia maliciosa llamada «plain-crypto-js» que se utiliza para ofrecer una puerta trasera multiplataforma capaz de infectar sistemas Windows, macOS y Linux.

En lugar de introducir cambios de código en Axios, el ataque aprovecha un enlace posterior a la instalación dentro del archivo «package.json» de la dependencia maliciosa para lograr una ejecución sigilosa. Una vez instalado el paquete Axios comprometido, npm activa automáticamente la ejecución de código malicioso en segundo plano.

Específicamente, el paquete «plain-crypto-js» funciona como un «vehículo de entrega de carga útil» para un cuentagotas de JavaScript ofuscado denominado SILKBELL («setup.js»), que recupera la siguiente etapa apropiada de un servidor remoto basado en el sistema operativo de la víctima.

Como detalló anteriormente The Hacker News, la rama de ejecución de Windows ofrece malware PowerShell, un binario C++ Mach-O para macOS y una puerta trasera Python para sistemas Linux. El cuentagotas también realiza una limpieza para eliminarse y reemplazar el archivo «package.json» del paquete «plain-crypto-js» con una versión limpia que no tiene el enlace postinstalación.

Fuente de la imagen: Laboratorios de seguridad elástica

Se considera que la puerta trasera, con nombre en código WAVESHAPER.V2, es una versión actualizada de WAVESHAPER, una puerta trasera C++ implementada por UNC1069 en ataques dirigidos al sector de las criptomonedas. El actor de amenazas ha estado operativo desde 2018. Los vínculos del ataque a la cadena de suministro con UNC1069 fueron señalados por primera vez por Elastic Security Labs, citando superposiciones de funcionalidad.

Las tres variantes de WAVESHAPER.V2 admiten cuatro comandos diferentes, mientras se dirigen al servidor de comando y control (C2) en intervalos de 60 segundos:

• matarpara finalizar el proceso de ejecución del malware.
• correrpara enumerar listados de directorios, junto con rutas de archivos, tamaños y marcas de tiempo de creación/modificación.
• ejecutar scriptpara ejecutar AppleScript, PowerShell o comandos de shell según el sistema operativo.
• inyectarpara decodificar y ejecutar binarios arbitrarios.

«WAVESHAPER.V2 es una evolución directa de WAVESHAPER, una puerta trasera para macOS y Linux anteriormente atribuida a UNC1069», dijeron Mandiant y GTIG. «Mientras que el WAVESHAPER original utiliza un protocolo C2 binario ligero y sin formato y emplea empaquetado de código, WAVESHAPER.V2 se comunica mediante JSON, recopila información adicional del sistema y admite más comandos de puerta trasera».

«A pesar de estas actualizaciones, ambas versiones aceptan su URL C2 dinámicamente a través de argumentos de línea de comandos, comparten comportamientos de sondeo C2 idénticos y una cadena de agente de usuario poco común, e implementan cargas útiles secundarias en directorios temporales idénticos (por ejemplo, /Library/Caches/com.apple.act.mond)».

A mitigar la amenazase recomienda a los usuarios que auditen los árboles de dependencia para detectar versiones comprometidas (y bajen a una versión segura, si la encuentran), fijen Axios a una versión segura conocida en el archivo «package-lock.json» para evitar actualizaciones accidentales, verifiquen la presencia de «plain-crypto-js» en «node_modules», finalicen procesos maliciosos, bloqueen el dominio C2 («sfrclak»).[.]com», dirección IP: 142.11.206[.]73), aislar los sistemas afectados y rotar todas las credenciales.

«El ataque a Axios debe entenderse como una plantilla, no como un evento único. El nivel de sofisticación operativa documentado aquí, incluidas las credenciales de mantenimiento comprometidas, las cargas útiles preestablecidas creadas para tres sistemas operativos, ambas ramas de lanzamiento alcanzadas en menos de 40 minutos y la autodestrucción forense incorporada, reflejan un actor de amenazas que planeó esto como una operación escalable», dijo el arquitecto jefe de software de ReversingLabs, Tomislav Peričin, a The Hacker News.

«Si esta campaña aparece ahora en PyPI y NuGet, eso es consistente con lo que la mecánica de ataque ya sugiere: el objetivo era alcanzar el máximo alcance para los desarrolladores. Las organizaciones necesitan auditar no sólo sus dependencias npm, sino también cada administrador de paquetes que alimenta sus canales de compilación, y tratar cualquier secreto expuesto en los entornos afectados como comprometido, independientemente del registro que tocaron».

Los investigadores de ciberseguridad han revelado un «punto ciego» de seguridad en la plataforma Vertex AI de Google Cloud que podría permitir que un atacante utilice agentes de inteligencia artificial (IA) para obtener acceso no autorizado a datos confidenciales y comprometer el entorno de nube de una organización.

Según la Unidad 42 de Palo Alto Networks, el problema se relaciona con cómo se puede hacer un mal uso del modelo de permisos de Vertex AI aprovechando la agente de servicioEl alcance excesivo del permiso de forma predeterminada.

«Un agente mal configurado o comprometido puede convertirse en un ‘agente doble’ que parece cumplir su propósito previsto, mientras extrae secretamente datos confidenciales, compromete la infraestructura y crea puertas traseras en los sistemas más críticos de una organización», dijo el investigador de la Unidad 42, Ofir Shaty. dicho en un informe compartido con The Hacker News.

Específicamente, la empresa de ciberseguridad descubrió que el agente de servicio por proyecto y por producto (P4SA) asociado con un agente de IA implementado creado con el kit de desarrollo de agentes de Vertex AI (ADK) tenía permisos excesivos otorgados de forma predeterminada. Esto abrió la puerta a un escenario en el que los permisos predeterminados de P4SA podrían usarse para extraer las credenciales de un agente de servicio y realizar acciones en su nombre.

Después de implementar el agente Vertex a través de Motor de agentecualquier llamada al agente invoca el servicio de metadatos de Google y expone las credenciales del agente de servicio, junto con el proyecto de Google Cloud Platform (GCP) que aloja al agente de IA, la identidad del agente de IA y los alcances de la máquina que aloja al agente de IA.

La Unidad 42 dijo que pudo usar las credenciales robadas para saltar del contexto de ejecución del agente de IA al proyecto del cliente, socavando efectivamente las garantías de aislamiento y permitiendo el acceso de lectura sin restricciones a todos los datos de los depósitos de Google Cloud Storage dentro de ese proyecto.

«Este nivel de acceso constituye un riesgo de seguridad significativo, transformando al agente de IA de una herramienta útil a una potencial amenaza interna», añadió.

Eso no es todo. Con el Vertex AI Agent Engine implementado ejecutándose dentro de un proyecto de inquilino administrado por Google, las credenciales extraídas también otorgaron acceso a los depósitos de Google Cloud Storage dentro del inquilino, ofreciendo más detalles sobre la infraestructura interna de la plataforma. Sin embargo, se descubrió que las credenciales carecían de los permisos necesarios para acceder a los depósitos expuestos.

Para empeorar las cosas, las mismas credenciales del agente de servicio P4SA también permitieron el acceso a repositorios restringidos de Artifact Registry propiedad de Google que se revelaron durante la implementación de Agent Engine. Un atacante podría aprovechar este comportamiento para descargar imágenes de contenedores de repositorios privados que constituyen el núcleo de Vertex AI Reasoning Engine.

Es más, las credenciales de P4SA comprometidas no solo permitieron descargar imágenes que aparecían en los registros durante la implementación de Agent Engine, sino que también expusieron el contenido de los repositorios de Artifact Registry, incluidas varias otras imágenes restringidas.

«Obtener acceso a este código propietario no sólo expone la propiedad intelectual de Google, sino que también proporciona al atacante un modelo para encontrar más vulnerabilidades», explicó la Unidad 42.

«El Artifact Registry mal configurado resalta una falla adicional en la gestión del control de acceso para la infraestructura crítica. Un atacante podría potencialmente aprovechar esta visibilidad no intencionada para mapear la cadena de suministro de software interna de Google, identificar imágenes obsoletas o vulnerables y planificar futuros ataques».

Google desde entonces actualizó su documentación oficial para explicar claramente cómo Vertex AI utiliza los recursos, las cuentas y los agentes. El gigante tecnológico también recomendó que los clientes utilicen Traiga su propia cuenta de servicio (BYOSA) para reemplazar al agente de servicio predeterminado y hacer cumplir el principio de privilegio mínimo (PoLP) para garantizar que el agente tenga solo los permisos que necesita para realizar la tarea en cuestión.

«Otorgar a los agentes permisos amplios de forma predeterminada viola el principio de privilegio mínimo y es una falla de seguridad peligrosa por diseño», dijo Shaty. «Las organizaciones deben tratar la implementación de agentes de IA con el mismo rigor que el nuevo código de producción. Validar los límites de permisos, restringir los alcances de OAuth al mínimo privilegio, revisar la integridad de la fuente y realizar pruebas de seguridad controladas antes del lanzamiento de la producción».

Google está acelerando su cronograma para migrar sus productos al cifrado cuántico resistente hasta 2029, la última señal de que a los líderes tecnológicos les preocupa no haber sido lo suficientemente agresivos en la planificación para un futuro poscuántico.

en un blog Publicado el miércoles, la vicepresidenta de ingeniería de seguridad Heather Adkins y la ingeniera senior de criptología Sophie Schmieg dijeron que Google y otras empresas de tecnología han observado avances más rápidos de lo esperado en varios campos cuánticos.

«Este nuevo cronograma refleja las necesidades de migración para la era PQC a la luz del progreso en el desarrollo de hardware de computación cuántica, la corrección de errores cuánticos y las estimaciones de recursos de factorización cuántica», escribieron Adkins y Schmieg.

Google está reemplazando el cifrado obsoleto en sus dispositivos, sistemas y datos con nuevos algoritmos examinados por el Instituto Nacional de Estándares y Tecnología. Esos algoritmos, desarrollado durante una década por NIST y criptólogos independientes, están diseñados para proteger contra futuros ataques de computadoras cuánticas.

Si bien Google ha dicho que está en camino de migrar sus propios sistemas antes del cronograma de 2035 previsto en las pautas del NIST, el mes pasado los líderes de la compañía adelantaron un cronograma actualizado para la migración y pidieron a las empresas privadas y otras entidades que actuaran con más urgencia para prepararse.

A diferencia del gobierno federal, no existe ningún mandato para que las empresas privadas migren al cifrado resistente a los cuánticos, ni siquiera que lo hagan. Adkins y Schmieg dijeron que la esperanza es que otras empresas vean el agresivo calendario de Google como una señal para seguir su ejemplo.

«Como pioneros tanto en cuántica como en PQC, es nuestra responsabilidad predicar con el ejemplo y compartir un cronograma ambicioso», escribieron. «Al hacer esto, esperamos brindar la claridad y urgencia necesarias para acelerar las transiciones digitales no solo para Google, sino también para toda la industria».

Adelantar el cronograma interno de Google hasta 2029 –más ambicioso que el del gobierno federal de Estados Unidos– es un intento de adelantarse al problema. También se alinea con una creencia cada vez mayor entre los ejecutivos del sector cuántico de EE. UU., que dicen científicos chinos y laboratorios han logrado avances en todo varios diferente campos de la computación cuántica en los últimos dos años.

Esto también está haciendo que los responsables de las políticas tecnológicas estadounidenses estén ansiosos por implementar más rápidamente un cifrado más nuevo. Actualmente, el gobierno federal exige que las agencias cambien al cifrado resistente a los cuánticos para 2035, pero CyberScoop informó el año pasado que la Casa Blanca ha discutido la posibilidad de publicar su propia orden ejecutiva que retrasaría los plazos de las agencias hasta 2030 o antes.

Google el jueves anunciado un nuevo «flujo avanzado» para la descarga de Android que requiere un período de espera obligatorio de 24 horas para instalar aplicaciones de desarrolladores no verificados en un intento de equilibrar la apertura con la seguridad.

Los nuevos cambios se producen en el contexto de un mandato de verificación de desarrolladores que el gigante tecnológico anunció el año pasado que requiere que todas las aplicaciones de Android estén registradas por desarrolladores verificados para instalarse en dispositivos Android certificados. La medida, añadió, se hizo para detectar a los malos actores más rápidamente y evitar que distribuyan malware.

Esto también incluye escenarios potenciales en los que los ciberdelincuentes engañan a los usuarios desprevenidos que descargan dichas aplicaciones para que les otorguen privilegios elevados que permitan desactivar Play Protect, la función antimalware integrada en todos los dispositivos Android certificados por Google.

Sin embargo, el requisitos de registro obligatorios ha sido recibió críticas de más de 50 desarrolladores de aplicaciones y mercados, incluidos F-Droid, Brave, The Electronic Frontier Foundation, Proton, The Tor Project, Vivaldi, quienes dicen que corren el riesgo de crear fricciones y barreras de entrada, y plantean preocupaciones sobre privacidad y vigilancia en ausencia de claridad sobre qué información personal deben proporcionar los desarrolladores, cómo se almacenarán, protegerán y utilizarán estos datos, y si podrían estar sujetos a solicitudes gubernamentales o procesos legales.

Como una forma de sofocar algunos de estos problemas espinosos, Google ha enfatizado que el flujo avanzado recientemente desarrollado permite a los usuarios avanzados mantener la capacidad de descargar aplicaciones de desarrolladores no verificados con un proceso único que requiere que sigan los pasos a continuación:

• Habilite el modo desarrollador en la configuración del sistema.
• Confirme que están dando este paso por su propia voluntad y que no están siendo entrenados.
• Reinicie el teléfono y vuelva a autenticarse para evitar que un estafador controle las acciones que está realizando un usuario.
• Espere un período de 24 horas y confirme que realmente están realizando este cambio con autenticación biométrica o PIN del dispositivo.
• Instale aplicaciones de desarrolladores no verificados una vez que los usuarios comprendan los riesgos, ya sea de forma indefinida o por un período de siete días.

«En ese período de 24 horas, creemos que a los atacantes les resulta mucho más difícil persistir en su ataque», dijo el presidente del ecosistema Android, Sameer Samat. citado diciendo a Ars Técnica. «En ese tiempo, probablemente puedas descubrir que tu ser querido no está realmente encarcelado o que tu cuenta bancaria no está realmente bajo ataque».

Google también dijo que planea ofrecer «cuentas de distribución limitada» gratuitas que permitan a los desarrolladores aficionados y estudiantes compartir aplicaciones con hasta 20 dispositivos sin tener que «proporcionar una identificación emitida por el gobierno o pagar una tarifa de registro».

Vale la pena señalar que el proceso antes mencionado no se aplica a las instalaciones a través de Android Debug Bridge (ADB). Las cuentas de distribución limitadas para estudiantes y aficionados, así como el flujo avanzado para usuarios, estarán disponibles en agosto de 2026, antes de que los nuevos requisitos de verificación de desarrolladores entren en vigor el mes siguiente.

«Sabemos que un enfoque de ‘talla única’ no funciona para nuestro ecosistema diverso», dijo Google. «Queremos asegurarnos de que la verificación de identidad no sea una barrera de entrada, por lo que ofrecemos diferentes caminos para satisfacer sus necesidades específicas».

El desarrollo coincide con la aparición de un nuevo malware para Android llamado Perseus que se dirige activamente a usuarios en Turquía e Italia con el objetivo de realizar apropiación de dispositivos (DTO) y fraude financiero.

Durante los cuatro meses, se han detectado al menos 17 familias de malware para Android. Incluyen FvncBot, SeedSnatcher, ClayRat, Wonderland, Cellik, Frogblight, NexusRoute, ZeroDayRAT, Arsink (y su variante mejorada SURXRAT), deVixor, Phantom, Massiv, PixRevolution, TaxiSpy RAT, BeatBanker, Mirax y Oblivion RAT.

Google lanzó el jueves actualizaciones de seguridad para su navegador web Chrome para abordar dos vulnerabilidades de alta gravedad que, según dijo, han sido explotadas en la naturaleza.

La lista de vulnerabilidades es la siguiente:

• CVE-2026-3909 (Puntuación CVSS: 8,8): una vulnerabilidad de escritura fuera de límites en la biblioteca de gráficos Skia 2D que permite a un atacante remoto realizar acceso a memoria fuera de límites a través de una página HTML diseñada.
• CVE-2026-3910 (Puntuación CVSS: 8,8): una vulnerabilidad de implementación inapropiada en el motor V8 JavaScript y WebAssembly que permite a un atacante remoto ejecutar código arbitrario dentro de un entorno limitado a través de una página HTML diseñada.

Ambas vulnerabilidades fueron descubiertas y reportadas por el propio Google el 10 de marzo de 2026. Como es habitual en estos casos, no hay detalles disponibles sobre cómo se está abusando de los problemas en la naturaleza y quién está detrás de los esfuerzos. Esto se hace para evitar que otros actores de amenazas exploten los problemas.

«Google es consciente de que existen exploits tanto para CVE-2026-3909 como para CVE-2026-3910», dijo la empresa. anotado.

El desarrollo se produce menos de un mes después de que Google enviara correcciones para un error de uso después de la liberación de alta gravedad en el componente CSS de Chrome (CVE-2026-2441, puntuación CVSS: 8.8) que también había sido explotado como un día cero. Google ha parcheado un total de tres días cero de Chrome activamente armados desde principios de año.

Para una protección óptima, se recomienda a los usuarios actualizar su navegador Chrome a las versiones 146.0.7680.75/76 para Windows y Apple macOS, y 146.0.7680.75 para Linux. Para asegurarse de que estén instaladas las últimas actualizaciones, los usuarios pueden navegar a Más > Ayuda > Acerca de Google Chrome y seleccionar Reiniciar.

También se recomienda a los usuarios de otros navegadores basados ​​en Chromium, como Microsoft Edge, Brave, Opera y Vivaldi, que apliquen las correcciones cuando estén disponibles.

Los investigadores de ciberseguridad han revelado nueve vulnerabilidades entre inquilinos en Google Looker Studio que podrían haber permitido a los atacantes ejecutar consultas SQL arbitrarias en las bases de datos de las víctimas y filtrar datos confidenciales dentro de los entornos de Google Cloud de las organizaciones.

Las deficiencias han sido nombradas colectivamente. Looker con fugas por Tenable. No hay evidencia de que las vulnerabilidades hayan sido explotadas en la naturaleza. Tras la divulgación responsable en junio de 2025, Google solucionó los problemas.

La lista de fallas de seguridad es la siguiente:

«Las vulnerabilidades rompieron supuestos de diseño fundamentales, revelaron una nueva clase de ataque y podrían haber permitido a los atacantes filtrar, insertar y eliminar datos en los servicios de las víctimas y en el entorno de Google Cloud», dijo la investigadora de seguridad Liv Matan. dicho en un informe compartido con The Hacker News.

«Estas vulnerabilidades expusieron datos confidenciales en los entornos de Google Cloud Platform (GCP), afectando potencialmente a cualquier organización que utilice Google Sheets, BigQuery, Spanner, PostgreSQL, MySQL, Cloud Storage y casi cualquier otro conector de datos de Looker Studio».

La explotación exitosa de las fallas entre inquilinos podría permitir a los actores de amenazas obtener acceso a conjuntos de datos y proyectos completos en diferentes inquilinos de la nube.

Los atacantes podrían buscar informes públicos de Looker Studio u obtener acceso a informes privados que utilicen estos conectores (por ejemplo, BigQuery) y tomar el control de las bases de datos, permitiéndoles ejecutar consultas SQL arbitrarias en todo el proyecto GCP del propietario.

Alternativamente, una víctima crea un informe como público o lo comparte con un destinatario específico y utiliza una fuente de datos conectada a JDBC, como PostgreSQL. En este escenario, el atacante puede aprovechar una falla lógica en la función de copia de informes que permite clonar informes conservando las credenciales del propietario original, lo que le permite eliminar o modificar tablas.

Otra ruta de alto impacto detallada por la compañía de ciberseguridad implicó la exfiltración de datos con un solo clic, donde compartir un informe especialmente diseñado obliga al navegador de la víctima a ejecutar código malicioso que contacta un proyecto controlado por un atacante para reconstruir bases de datos completas a partir de registros.

«Las vulnerabilidades rompieron la promesa fundamental de que un ‘espectador’ nunca debería poder controlar los datos que está viendo», dijo Matan, y agregó que «podrían haber permitido a los atacantes filtrar o modificar datos en los servicios de Google como BigQuery y Google Sheets».

Investigadores de ciberseguridad han revelado detalles de un grupo de amenazas persistentes avanzadas (APT) denominado Dragón plateado que se ha relacionado con ataques cibernéticos dirigidos a entidades en Europa y el sudeste asiático desde al menos mediados de 2024.

«Silver Dragon obtiene su acceso inicial explotando servidores de Internet públicos y enviando correos electrónicos de phishing que contienen archivos adjuntos maliciosos», Check Point dicho en un informe técnico. «Para mantener la persistencia, el grupo secuestra servicios legítimos de Windows, lo que permite que los procesos de malware se mezclen con la actividad normal del sistema».

Se estima que Silver Dragon opera dentro del marco de APT41. APT41 es el criptonimo asignado a un prolífico grupo de hackers chino conocido por su objetivo de ciberespionaje en los sectores de salud, telecomunicaciones, alta tecnología, educación, servicios de viajes y medios de comunicación ya en 2012. También se cree que participa en actividades con motivación financiera potencialmente fuera del control estatal.

Se ha descubierto que los ataques organizados por Silver Dragon apuntan principalmente a entidades gubernamentales, y el adversario utiliza balizas Cobalt Strike para persistir en los hosts comprometidos. También se sabe que emplea técnicas como el túnel DNS para la comunicación de comando y control (C2) para evitar la detección.

Check Point dijo que identificó tres cadenas de infección diferentes para entregar Cobalt Strike: Secuestro de dominio de aplicaciónDLL de servicio y phishing basado en correo electrónico.

«Las dos primeras cadenas de infección, el secuestro de AppDomain y el Service DLL, muestran una clara superposición operativa», dijo la empresa de ciberseguridad. «Ambas se entregan a través de archivos comprimidos, lo que sugiere su uso en escenarios posteriores a la explotación. En varios casos, estas cadenas se implementaron tras el compromiso de servidores vulnerables expuestos públicamente».

Las dos cadenas utilizan un archivo RAR que contiene un script por lotes, y la primera cadena lo utiliza para colocar MonikerLoader, un cargador basado en NET responsable de descifrar y ejecutar una segunda etapa directamente en la memoria. La segunda etapa, por su parte, imita el comportamiento de MonikerLoader, actuando como un conducto para cargar la carga útil final de la baliza Cobalt Strike.

Por otro lado, la cadena de DLL del servicio utiliza un script por lotes para entregar un cargador de DLL de código shell denominado BamboLoader, que está registrado como un servicio de Windows. Es un malware C++ muy ofuscado que se utiliza para descifrar y descomprimir el código shell almacenado en el disco e inyectarlo en un proceso legítimo de Windows, como «taskhost.exe». El binario destinado a la inyección se puede configurar dentro de BamboLoader.

La tercera cadena de infección implica una campaña de phishing dirigida principalmente a Uzbekistán con accesos directos maliciosos de Windows (LNK) como archivos adjuntos. El archivo LNK armado está diseñado para iniciar código PowerShell mediante «cmd.exe», lo que lleva a la extracción y ejecución de cargas útiles de la siguiente etapa. Esto incluye cuatro archivos diferentes:

• documento señuelo
• Ejecutable legítimo vulnerable a la carga lateral de DLL («GameHook.exe»)
• DLL maliciosa también conocida como BamboLoader («graphics-hook-filter64.dll»)
• Carga útil cifrada de Cobalt Strike («simhei.dat»)

Como parte de esta campaña, el documento señuelo se muestra a la víctima, mientras que, en segundo plano, la DLL maliciosa se descarga a través de «GameHook.exe» para finalmente iniciar Cobalt Strike. Los ataques también se caracterizan por el despliegue de diversas herramientas posteriores a la explotación:

• Pantalla plateadauna herramienta de monitoreo de pantalla .NET utilizada para capturar capturas de pantalla periódicas de la actividad del usuario, incluida la posición precisa del cursor.
• SSHcmduna utilidad SSH de línea de comandos .NET que proporciona ejecución remota de comandos y capacidades de transferencia de archivos a través de SSH.
• Puerta de engranajesuna puerta trasera NET que comparte similitudes con MonikerLoader y se comunica con su infraestructura C2 a través de Google Drive.

Una vez ejecutada, la puerta trasera se autentica en la cuenta de Google Drive controlada por el atacante y carga un archivo de latido que contiene información básica del sistema. Curiosamente, la puerta trasera utiliza diferentes extensiones de archivo para indicar la naturaleza de la tarea a realizar en el host infectado. Los resultados de la ejecución de la tarea se capturan y cargan en Drive.

• *.pngpara enviar archivos de latidos.
• *.pdfpara recibir y ejecutar comandos, enumerar el contenido de un directorio, crear un nuevo directorio y eliminar todos los archivos dentro de un directorio específico. Los resultados de la operación se envían al servidor en forma de archivo *.db.
• *.taxipara recibir y ejecutar comandos para recopilar información del host y una lista de procesos en ejecución, enumerar archivos y directorios, ejecutar comandos a través de «cmd.exe» o tareas programadas, cargar archivos en Google Drive y finalizar el implante. El estado de ejecución se carga como un archivo .bak.
• *.rarpara recibir y ejecutar cargas útiles. Si el archivo RAR se llama «wiatrace.bak», la puerta trasera lo trata como un paquete de actualización automática. Los resultados se cargan como archivos .bak.
• *.7zpara recibir y ejecutar complementos en la memoria. Los resultados se cargan como archivos .bak.

Los vínculos de Silver Dragon con APT41 se derivan de superposiciones comerciales con scripts de instalación posteriores a la explotación anteriores. atribuido a este último y el hecho de que el mecanismo de descifrado utilizado por BamboLoader se ha observado en cargadores de shellcode vinculados a la actividad APT del nexo con China.

«El grupo evoluciona continuamente sus herramientas y técnicas, probando e implementando activamente nuevas capacidades en diferentes campañas», dijo Check Point. «El uso de diversos exploits de vulnerabilidad, cargadores personalizados y comunicación C2 sofisticada basada en archivos refleja un grupo de amenazas adaptable y con buenos recursos».

Google el lunes revelado que una falla de seguridad de alta gravedad que afecta a un componente de código abierto de Qualcomm utilizado en dispositivos Android ha sido explotada en la naturaleza.

La vulnerabilidad en cuestión es CVE-2026-21385 (Puntuación CVSS: 7,8), una lectura excesiva del búfer en el componente Gráficos.

«Corrupción de la memoria al agregar datos proporcionados por el usuario sin verificar el espacio disponible en el buffer», Qualcomm dicho en un aviso, describiéndolo como un desbordamiento de enteros.

El fabricante de chips dijo que se le informó sobre la falla a través del equipo de seguridad de Android de Google el 18 de diciembre de 2025. Los clientes fueron notificados sobre el defecto de seguridad el 2 de febrero de 2026.

Actualmente no hay detalles sobre cómo se está explotando la vulnerabilidad en la naturaleza. Sin embargo, Google reconoció en su boletín mensual de seguridad de Android que «hay indicios de que CVE-2026-21385 puede estar bajo explotación limitada y dirigida».

La actualización de Google de marzo de 2026 contiene parches para un total de 129 vulnerabilidades, incluida una falla crítica en el componente del sistema (CVE-2026-0006) que podría conducir a la ejecución remota de código sin requerir privilegios adicionales ni interacción del usuario. Por el contrario, Google abordó una vulnerabilidad de Android en enero de 2026 y ninguna el mes pasado.

Google también ha solucionado varios errores clasificados como críticos: un error de escalada de privilegios en Framework (CVE-2026-0047), una denegación de servicio (DoS) en el sistema (CVE-2025-48631) y siete fallas de escalada de privilegios en los componentes del Kernel (CVE-2024-43859, CVE-2026-0037, CVE-2026-0038, CVE-2026-0027, CVE-2026-0028, CVE-2026-0030 y CVE-2026-0031).

El boletín de seguridad de Android incluye dos niveles de parche (2026-03-01 y 2026-03-05) para brindar a los socios de Android la flexibilidad de abordar vulnerabilidades comunes en diferentes dispositivos más rápidamente.

El segundo nivel de parche incluye correcciones para los componentes del Kernel, así como los de Arm, Imagination Technologies, MediaTek, Qualcomm y Unisoc.

Google reveló el lunes una vulnerabilidad de día cero explotada activamente, advirtiendo que el defecto de alta gravedad que afecta a un componente de pantalla de código abierto de Qualcomm para dispositivos Android «puede estar bajo explotación limitada y dirigida».

La vulnerabilidad de la corrupción de la memoria CVE-2026-21385 – que el equipo de seguridad de Android de Google informó a Qualcomm el 18 de diciembre, afecta a 234 conjuntos de chips, dijo Qualcomm en un boletín de seguridad. Qualcomm dijo que notificó a los clientes sobre la vulnerabilidad el 2 de febrero.

Qualcomm se negó a decir cuándo ocurrió el primer caso conocido de explotación, cuántas víctimas se vieron afectadas directamente y qué ocurrió durante el período de 10 semanas entre el informe y la divulgación pública de la vulnerabilidad.

«Felicitamos a los investigadores del Grupo de Análisis de Amenazas de Google por utilizar prácticas de divulgación coordinadas», dijo un portavoz de Qualcomm a CyberScoop. «Las correcciones estuvieron disponibles para nuestros clientes en enero de 2026. Alentamos a los usuarios finales a aplicar actualizaciones de seguridad a medida que estén disponibles por parte de los fabricantes de dispositivos».

Un portavoz de Google dijo que Qualcomm marcó la vulnerabilidad como explotada. «No tenemos ninguna información ni acceso a los informes de explotación», añadió el portavoz.

Google solucionó 129 defectos en su actualización de seguridad mensual para dispositivos Android, lo que refleja un aumento en las divulgaciones de vulnerabilidades por parte del proveedor. La última actualización de seguridad de la compañía contiene la mayor cantidad de vulnerabilidades de Android parcheadas en un solo mes desde abril de 2018.

El programa público de divulgación e informes de vulnerabilidades de Google para Android ha sido desigual. La empresa normalmente publicaba docenas de parches de seguridad cada mes, pero esa cadencia se ha convertido en una rutina más ocasional.

En lo que va del año, Google abordó una vulnerabilidad de Android en enero y ninguna en febrero. También hubo pausas ocasionales el año pasado cuando Google no informó ninguna vulnerabilidad en julio y octubre, seis en agosto y dos vulnerabilidades en noviembre. Sin embargo, las divulgaciones para 2025 alcanzaron su punto máximo con 120 defectos en septiembre y repuntaron nuevamente en diciembre con 107 vulnerabilidades, incluidas dos de día cero.

Google respondió anteriormente a preguntas sobre caídas en la cantidad de vulnerabilidades que revela cada mes, señalando que sigue centrado en los defectos que representan el mayor peligro.

«Android detiene la mayor parte de la explotación de vulnerabilidades en la fuente con un amplio refuerzo de la plataforma, como nuestro uso del lenguaje Rust, seguro para la memoria, y protecciones antiexplotación avanzadas», dijo un portavoz de Google en diciembre. «Android y Pixel abordan continuamente las vulnerabilidades de seguridad conocidas y priorizan reparar y parchar primero las de mayor riesgo».

El boletín de seguridad de Android de marzo incluye dos niveles de parche (2026-03-01 y 2026-03-05), lo que permite a los socios de Android abordar vulnerabilidades comunes en diferentes dispositivos. Los fabricantes de dispositivos Android lanzan parches de seguridad según su propio calendario después de haber personalizado las actualizaciones del sistema operativo para su hardware específico.

La actualización de seguridad principal contiene 63 vulnerabilidades, incluidas 32 en el marco, 19 en el sistema y 12 que afectan a Google Play. Casi la mitad de esas vulnerabilidades tienen identificadores CVE a partir de 2025.

El segundo parche aborda 66 vulnerabilidades, incluidas 15 vulnerabilidades que afectan al kernel, un defecto de un componente Arm, siete fallas de Imagination Technologies y siete vulnerabilidades en los componentes de Unisoc.

El segundo nivel de parche también contiene correcciones para ocho vulnerabilidades en componentes de Qualcomm de código cerrado y siete defectos de alta gravedad en componentes de Qualcomm de código abierto, incluido CVE-2026-21385.

Google dijo que el código fuente de todas las vulnerabilidades abordadas en el boletín de seguridad de Android de este mes se publicará en el repositorio del Proyecto de Código Abierto de Android el miércoles.

Google ha anunciado un nuevo programa en su navegador Chrome para garantizar que los certificados HTTPS estén seguros frente al riesgo futuro que suponen los ordenadores cuánticos.

«Para garantizar la escalabilidad y eficiencia del ecosistema, Chrome no tiene un plan inmediato para agregar versiones tradicionales Certificados X.509 que contiene criptografía post-cuántica al Tienda raíz de Chrome«, el equipo de redes y web segura de Chrome dicho.

«En cambio, Chrome, en colaboración con otros socios, está desarrollando un evolución de certificados HTTPS basados ​​en Certificados de árbol Merkle (MTC), actualmente en desarrollo en el grupo de trabajo PLANTS.»

Como explica Cloudflare, MTC es un propuesta para la próxima generación de infraestructura de clave pública (PKI) utilizada para proteger Internet, cuyo objetivo es reducir la cantidad de claves públicas y firmas en el protocolo de enlace TLS al mínimo requerido.

Bajo este modelo, una Autoridad de Certificación (CA) firma un único ‘Tree Head’ que representa potencialmente millones de certificados, y el ‘certificado’ enviado al navegador es una prueba ligera de inclusión en ese árbol, dijo Google.

En otras palabras, los MTC facilitan la adopción de algoritmos poscuánticos sin tener que incurrir en ancho de banda adicional asociado con las cadenas de certificados X.509 clásicas. El enfoque, añadió la empresa, desacopla la seguridad del algoritmo criptográfico correspondiente del tamaño de los datos transmitidos al usuario.

«Al reducir al mínimo absoluto los datos de autenticación en un protocolo de enlace TLS, los MTC pretenden mantener la web poscuántica tan rápida y fluida como la Internet actual, manteniendo un alto rendimiento incluso cuando adoptamos una seguridad más sólida», dijo Google.

El gigante tecnológico dijo que ya está experimentando con MTC con tráfico de Internet real y que planea expandir gradualmente el lanzamiento en tres fases distintas para el tercer trimestre de 2027.

• Fase 1 (En curso): Google está llevando a cabo un estudio de viabilidad en colaboración con Cloudflare para evaluar el rendimiento y la seguridad de las conexiones TLS que dependen de MTC.
• Fase 2 (Primer trimestre de 2027): Google planea invitar a Certificate Transparency (CT) Registro operadores con al menos un «usable«Inicie sesión en Chrome antes del 1 de febrero de 2026 para participar en el arranque inicial de los MTC públicos.
• Fase 3 (Tercer trimestre de 2027): Google finalizará los requisitos para incorporar CA adicionales en el nuevo almacén raíz resistente a Chrome Quantum (CQRS) y el programa raíz correspondiente que solo admite MTC.

«Consideramos la adopción de MTC y un almacén raíz resistente a los cuánticos como una oportunidad crítica para garantizar la solidez de las bases del ecosistema actual», dijo Google. Al diseñar para las demandas específicas de una Internet moderna y ágil, podemos acelerar la adopción de la resiliencia poscuántica para todos los usuarios de la web.