El repositorio de modelos de IA más grande del mundo abrazando la cara violada por un agente de IA autónomo – CYBERDEFENSA.MX

En un giro irónico, la plataforma de inteligencia artificial (IA) de código abierto Hugging Face reveló que fue víctima de un ataque perpetrado por un sistema autónomo de agentes de IA.

La compañía dijo que detectó y respondió al incidente que tuvo como objetivo su infraestructura de producción a principios de la semana pasada.

«Identificamos acceso no autorizado a un conjunto limitado de conjuntos de datos internos y a varias credenciales utilizadas por nuestros servicios», dijo la empresa. dicho en un comunicado.

Si bien la investigación sobre la intrusión continúa en curso, Hugging Face dijo que no ha encontrado evidencia de que el agente de IA haya manipulado modelos, conjuntos de datos o espacios públicos orientados al usuario, ni su propia cadena de suministro de software.

Ciberseguridad

El punto de partida del ataque fue el proceso de procesamiento de datos en sí, con un conjunto de datos malicioso que abusaba de dos rutas de ejecución de código, a saber, en su cargador de conjunto de datos de código remoto y una inyección de plantilla en una configuración de conjunto de datos, para ejecutar código en un trabajador de procesamiento.

Con ese acceso, se dice que el actor de amenazas escaló al acceso a nivel de nodo, recopiló credenciales de nube y clúster y se movió lateralmente a varios clústeres internos durante un fin de semana.

El modelo de lenguaje grande (LLM) exacto utilizado para llevar a cabo el ataque no está claro, pero la campaña fue ejecutada por un marco de agente autónomo que realizaba «muchos miles de acciones individuales a través de un enjambre de entornos limitados de corta duración, con comando y control automigratorio organizado en servicios públicos».

Hugging Face dijo que desde entonces ha abordado la causa raíz del problema, precisamente las vías de ejecución del código utilizadas para el acceso inicial. Tambien llevo a cabo las siguientes medidas de remediacion:

  • Se eliminó el punto de apoyo del atacante en los clústeres afectados y se reconstruyeron los nodos comprometidos.
  • Se revocaron y rotaron las credenciales y tokens afectados, y se llevó a cabo una rotación más amplia de secretos como medida de precaución.
  • Implementó barreras de seguridad adicionales y controles de admisión más estrictos en sus grupos.
  • Detección y alertas mejoradas para garantizar que los socorristas reciban notificaciones en cuestión de minutos, 24 horas al día, 7 días a la semana.

Como medida de seguridad adicional, Hugging Face insta a los clientes a rotar los tokens de acceso y revisar la actividad reciente en sus cuentas.

Ciberseguridad

La compañía también dijo que recurrió a Z.ai. GLM 5.2un modelo chino de peso abierto, para realizar el análisis forense después de que los modelos de la frontera occidental rechazaran solicitudes que contenían comandos de ataque reales, cargas útiles de explotación y artefactos de comando y control (C2) porque se activaron sus barreras de seguridad y su incapacidad para diferenciar entre un atacante y un esfuerzo legítimo de respuesta a incidentes.

«Esta experiencia apunta a una brecha que vale la pena planificar», afirmó la empresa con sede en Nueva York. «No sabemos qué modelo impulsó a los agentes del atacante, si un modelo alojado con jailbreak o uno de peso abierto sin restricciones; de cualquier manera, el atacante estaba sujeto a una política de no uso, mientras que nuestro propio trabajo forense fue bloqueado por las barreras de los modelos alojados que probamos por primera vez».

«La lección práctica para los defensores: tener un modelo capaz que pueda ejecutar en su propia infraestructura, examinado y listo antes de un incidente, tanto para evitar el bloqueo de la barrera como para evitar que los datos y credenciales del atacante abandonen su entorno».

Una falla sin parche en el servidor de repositorio de Argo CD podría permitir a los atacantes apoderarse de los clústeres de Kubernetes

CD Argouna herramienta ampliamente utilizada para implementar software en Kubernetes, tiene una falla sin parchear en su componente de servidor de repositorio que permite que un atacante no autenticado ejecute código, siempre que pueda alcanzar el puerto de red interno del componente.

sinácticoque encontró el error, dice que puede conducir a una toma de control total del clúster. No hay solución ni CVE. La empresa dice que informó la falla a los encargados de mantenimiento de Argo CD en enero de 2025; Aproximadamente dieciocho meses después, sigue sin parchear, por lo que publicó los detalles para advertir a los usuarios.

El error se encuentra en el servidor de repositorio, el componente de CD de Argo que lee los repositorios de Git y crea manifiestos de Kubernetes, los archivos que definen lo que implementa el clúster.

Su servicio gRPC interno no tiene autenticación; cualquiera que pueda acceder a él puede enviar una solicitud diseñada para ejecutar un comando. Synacktiv demostró el ataque contra Argo CD v2.13.3 y no informa ninguna versión parcheada; no publicó una lista completa de las versiones afectadas.

La técnica abusa personalizaruna herramienta estándar que ejecuta Argo CD para convertir archivos del repositorio en manifiestos. Kustomize tiene una opción –helm-command que apunta al binario de helm al que debe llamar.

Ciberseguridad

Synacktiv descubrió que una solicitud no autenticada al servicio GenerateManifest del servidor de repositorio puede establecer esa opción en un script, extraído de un repositorio Git controlado por un atacante. Cuando se ejecuta kustomize, ejecuta el script en lugar de helm.

Pero «interno» no significa aislado por defecto. CD Argo envía políticas de red de Kubernetes que separan el servidor de repositorio de todo excepto de sus propios componentes.

Synacktiv encontró el gráfico Helm, una forma común de instalar Argo CD, deja esas políticas desactivadas de forma predeterminadacon networkPolicy.create establecido en false. En esa configuración, un atacante que comprometa un solo pod en el clúster puede llegar al servidor de repositorio y desencadenar el error.

Ejecutar código en el servidor de repositorio no es el final. Synacktiv usó ese acceso para leer la contraseña de Redis del clúster desde una variable de entorno, conectarse al caché de Redis de Argo CD y envenenar los datos de implementación almacenados. En la siguiente sincronización automática, Argo CD implementó una carga de trabajo proporcionada por el atacante.

Ese paso revive CVE-2024-31989Cycode encontró una falla en 2024 donde Redis de Argo CD no tenía contraseña, lo que permitió que cualquier pod en el clúster envenenara el caché de implementación. Argo CD solucionó el problema agregando una contraseña de Redis, pero el caché en sí aún no está firmado, por lo que robar la contraseña vuelve a abrir el mismo ataque.

que hacer

No existe una versión parcheada, por lo que la defensa es el aislamiento de la red. Active las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan llegar al servidor de repositorio y a los puertos de Redis. Argo CD proporciona los archivos de políticas; Los usuarios de Helm tienen que habilitarlos porque el gráfico los deja fuera.

Comprueba qué está activo con: kubectl obtiene la política de red -A. Una instalación saludable muestra una política de red por componente, incluido el servidor de repositorio y Redis. Si faltan esas políticas, se puede acceder al servidor de repositorio y a los puertos de Redis desde el resto del clúster.

Ciberseguridad

Synacktiv creó una herramienta, argo-cdown, que automatiza el ataque completo. Está reteniendo la herramienta por ahora para darles tiempo a los defensores para bloquear sus políticas de red, y dice que la publicará en GitHub más adelante para que los administradores puedan probar sus propias implementaciones.

Esta no es la primera vez que Argo CD expone sus propios componentes internos. En septiembre de 2025, parchó CVE-2025-55190donde un token API con solo acceso de lectura básico podría recuperar las credenciales del repositorio Git de un proyecto, una falla que The Hacker News señaló en ese momento.

En mayo de 2026, otro error, CVE-2026-42880permitió a los usuarios de solo lectura leer secretos de Kubernetes en texto sin formato. Es difícil pasar por alto el patrón: Argo CD concentra el acceso al clúster y los secretos del repositorio, y sus superficies internas siguen entregándolos, a una solicitud no autenticada en un error y a un token de privilegios bajos en el siguiente.

Hasta que se envíe un parche, tratar la red del clúster como hostil es la única defensa real.

El repositorio falso de filtros de privacidad OpenAI alcanza el puesto número 1 en abrazar la cara y atrae 244.000 descargas – CYBERDEFENSA.MX

Un repositorio malicioso de Hugging Face logró ocupar un lugar en la lista de tendencias de la plataforma al hacerse pasar por el modelo de peso abierto del filtro de privacidad de OpenAI para ofrecer un ladrón de información basado en Rust a los usuarios de Windows.

El proyecto, denominado Open-OSS/filtro de privacidaddisfrazado de su contraparte legítima, lanzado por OpenAI a fines del mes pasado (openai/filtro de privacidad), incluida la copia literal de la descripción completa para engañar a los usuarios desprevenidos para que la descarguen. Desde entonces, Hugging Face ha desactivado el acceso al modelo malicioso.

El filtro de privacidad era desvelado en abril de 2026 por la empresa de inteligencia artificial (IA) como una forma de detectar y redactar información de identificación personal (PII) en texto no estructurado con el objetivo de incorporar sólidas protecciones de privacidad y seguridad en las aplicaciones.

«El repositorio había escrito errores tipográficos en la versión legítima del filtro de privacidad de OpenAI, copió su tarjeta modelo casi palabra por palabra y envió un archivo loader.py que recupera y ejecuta malware de robo de información en máquinas con Windows», dijo el equipo de investigación de HiddenLayer. dicho en un informe publicado la semana pasada.

Ciberseguridad

El proyecto malicioso indica a los usuarios que clonen el repositorio y ejecuten un script por lotes («start.bat») para Windows o un script Python («loader.py») para sistemas Linux o macOS para configurar todas las dependencias necesarias e iniciar el modelo.

Una vez iniciado, el script Python activa un código malicioso responsable de deshabilitar la verificación SSL, decodificar una URL codificada en Base64 alojada en JSON Keeper y usarla para extraer un comando que se pasa a PowerShell para su posterior ejecución. El uso de JSON Keeper, un servicio público de pegado de JSON, como solucionador de entrega muerta permite a los atacantes cambiar cargas útiles sobre la marcha sin necesidad de modificar el repositorio.

El comando PowerShell se utiliza para descargar un script por lotes desde un servidor remoto («api.eth-fastscan[.]org») y ejecútelo usando «cmd.exe». El script por lotes funciona como un descargador de segunda etapa que prepara el entorno elevando sus privilegios mediante un mensaje de Control de cuentas de usuario (UAC), configurando exclusiones de Microsoft Defender Antivirus, descargando el binario de la siguiente etapa del mismo dominio y configurando una tarea programada que inicia un script de PowerShell para ejecutar el ejecutable.

Una vez que se inicia la tarea programada, el malware espera dos segundos antes de eliminarse. La etapa final es un ladrón de información diseñado para tomar capturas de pantalla y recopilar datos de Discord, billeteras y extensiones de criptomonedas, metadatos del sistema, archivos como configuraciones de FileZilla y frases iniciales de billetera, y navegadores web basados ​​en los motores de renderizado Chromium y Gecko.

«A pesar de utilizar una tarea programada, esta etapa no establece persistencia: la tarea se destruye antes de reiniciar. Se utiliza como un iniciador de contexto de SISTEMA de una sola vez», explicó HiddenLayer.

El ladrón también ejecuta comprobaciones para detectar depuradores y entornos sandbox, verifica que no se está ejecutando en una máquina virtual e intenta deshabilitar la interfaz de escaneo antimalware de Windows (AMSI) y el seguimiento de eventos para Windows (ETW) para evadir la detección de comportamiento. Los datos robados se exfiltran en formato JSON a la «recargapopular[.]dominio com».

Antes de ser desactivado, se dice que el modelo alcanzó la posición número 1 en tendencia en Hugging Face con aproximadamente 244.000 descargas y 667 me gusta en 18 horas. Se sospecha que estos números fueron inflados artificialmente para darle al repositorio una ilusión de confianza y lograr que los usuarios lo descargaran.

Un análisis más profundo de la actividad ha descubierto seis repositorios más que cuentan con un cargador de Python similar para implementar el ladrón:

  • anthfu/Bonsai-8B-gguf
  • anthfu/Qwen3.6-35B-A3B-APEX-GGUF
  • anthfu/DeepSeek-V4-Pro
  • anthfu/Qwopus-GLM-18B-Ferged-GGUF
  • anthfu/Qwen3.6-35B-A3B-Claude-4.6-Opus-Reasoning-Distilled-GGUF
  • anthfu/supergemma4-26b-sin censura-gguf-v2
Ciberseguridad

HiddenLayer dijo que también observó la «api[.]eth-fastscan[.]org» que se utiliza para servir un ejecutable de Windows diferente («o0q2l47f.exe«) que señala «welovechinatown[.]info», un servidor de comando y control (C2) que se utilizó anteriormente en una campaña que aprovechó un paquete npm malicioso llamado trevlo para entregar ValleyRAT (también conocido como Winos 4.0).

«El gancho postinstalación del paquete ejecuta silenciosamente un cargador de JavaScript ofuscado que genera un comando de PowerShell codificado en base64, que a su vez recupera y ejecuta un script de PowerShell de segunda etapa desde la infraestructura controlada por el atacante», Panther anotado mes pasado.

«Ese script descarga y ejecuta un binario stager de Winos 4.0 («CodeRun102.exe») con evasión completa, completo con ejecución de ventana oculta, eliminación del identificador de zona y separación de procesos».

El ataque es digno de mención por el hecho de que representa un nuevo vector de acceso inicial para ValleyRAT, un troyano modular de acceso remoto que se sabe que se distribuye a través de correos electrónicos de phishing y envenenamiento de optimización de motores de búsqueda (SEO). El uso de ValleyRAT se atribuye exclusivamente a un grupo de hackers chino llamado Silver Fox.

«La infraestructura compartida sugiere que estas campañas posiblemente estén vinculadas y probablemente formen parte de una operación de cadena de suministro más amplia dirigida a ecosistemas de código abierto», dijo HiddenLayer.

Trellix confirma violación del código fuente con acceso no autorizado al repositorio – CYBERDEFENSA.MX

La empresa de ciberseguridad Trellix tiene anunciado que sufrió una violación que permitió el acceso no autorizado a una «parte» de su código fuente.

Dijo que «identificó recientemente» el compromiso de su repositorio de código fuente y que comenzó a trabajar con «líderes expertos forenses» para resolver el asunto de inmediato. También dijo que había notificado el asunto a las autoridades.

Trellix no reveló la naturaleza exacta de los datos a los que los atacantes pudieron haber accedido. Sin embargo, señaló que no hay indicios de que su código fuente haya sido afectado o explotado.

Ciberseguridad

«Basándonos en nuestra investigación hasta la fecha, no hemos encontrado evidencia de que nuestro proceso de liberación o distribución de nuestro código fuente haya sido afectado, o que nuestro código fuente haya sido explotado», añadió la compañía.

La compañía no compartió ningún detalle sobre quién podría estar detrás del incidente y durante cuánto tiempo los atacantes tuvieron acceso a sus sistemas. Trellix señaló que se compartirá información adicional según corresponda una vez que se complete su investigación.

Trellix, propiedad de Symphony Technology Group, se fundó en enero de 2022 tras la fusión de McAfee Enterprise y FireEye. Casi al mismo tiempo, Mandiant, que era propiedad de FireEye, fue adquirida por Google en un acuerdo por valor de 5.400 millones de dólares.

The Hacker News se comunicó con Trellix para hacer comentarios y actualizaremos la historia si recibimos una respuesta.

(Esta es una historia en desarrollo. Vuelva a consultarla para obtener más detalles).

Checkmarx confirma que los datos del repositorio de GitHub se publicaron en la Dark Web después del ataque del 23 de marzo – CYBERDEFENSA.MX

Checkmarx ha revelado que su investigación en curso relacionada con el incidente de seguridad de la cadena de suministro ha revelado que un grupo cibercriminal publicó datos relacionados con la empresa en la web oscura.

«Basándonos en la evidencia actual, creemos que estos datos se originaron en el repositorio GitHub de Checkmarx, y que el acceso a ese repositorio se facilitó mediante el ataque inicial a la cadena de suministro del 23 de marzo de 2026», dijo la empresa de seguridad israelí. dicho.

También enfatizó que el repositorio de GitHub se mantiene separado del entorno de producción del cliente, y agregó que no se almacenan datos del cliente en el repositorio. Checkmarx dijo que su investigación forense sobre el incidente está en curso y que está trabajando activamente para verificar la naturaleza y el alcance de los datos publicados.

Además, la compañía dijo que bloqueó el acceso al repositorio de GitHub afectado como parte de sus esfuerzos de respuesta a incidentes.

«Si determinamos que la información del cliente estuvo involucrada en este incidente, notificaremos a los clientes y a todas las partes relevantes de inmediato», dijo.

Ciberseguridad

El desarrollo se produce después del Dark Web Informer. compartido en una publicación X que el grupo de cibercrimen LAPSUS$ se cobró tres víctimas en su sitio de filtración de datos, una de las cuales incluye a Checkmarx. Los datos, según el listado, contienen código fuente, base de datos de empleados, claves API y credenciales de MongoDB/MySQL.

Checkmarx sufrió una infracción a finales del mes pasado tras el ataque a la cadena de suministro de Trivy, como resultado del cual dos de sus flujos de trabajo de GitHub Actions y dos complementos distribuidos a través del mercado Open VSX fueron manipulados para impulsar a un ladrón de credenciales capaz de recolectar una amplia gama de secretos de desarrolladores. El actor de amenazas conocido como TeamPCP se atribuyó la responsabilidad del ataque.

La semana pasada, se sospecha que el grupo con motivación financiera comprometió la imagen KICS Docker de Checkmarx, junto con las dos extensiones de VS Code y un flujo de trabajo de GitHub Actions con un malware de robo de credenciales similar. Esto, a su vez, tuvo un impacto en cascada, lo que llevó a un breve compromiso del paquete npm de la CLI de Bitwarden.