Cómo llega el fraude de identidad sintético a las identidades de máquinas – CYBERDEFENSA.MX

La mayoría de las personas entienden el robo de identidad como un atacante que roba información confidencial de una persona real y se hace pasar por ella. El fraude de identidad sintético es mucho más difícil de detectar. En lugar de robar una identidad real, el atacante fabrica una nueva, uniendo varios puntos de datos reales con otros inventados para crear una persona que no existe. Dado que ninguna víctima real monitorea el uso indebido, una identidad falsa puede acumular silenciosamente permisos y credibilidad con el tiempo antes de ser detectada. Este mismo principio tiene un paralelo en gran medida inexplorado con las identidades no humanas (NHI).

Los equipos de seguridad están realizando importantes esfuerzos para proteger los NHI contra el robo. Aún así, rara vez se analiza el equivalente del fraude de identidad sintético en el lado de las máquinas: identidades que nunca fueron proporcionadas legítimamente desde el principio. Siguiendo este enfoque, un atacante no secuestra una cuenta de servicio existente, sino que fabrica una, mezclando atributos ambientales reales con otros falsos para que parezca pertenecer. A medida que las empresas acumulan NHI más rápido de lo que pueden rastrearlos, uno fabricado puede colarse fácilmente en la mezcla si la gobernanza es débil y no hay propiedad humana.

Cómo se ve el fraude de identidad sintético para las identidades de las máquinas

Para los seres humanos, el fraude de identidad sintético se entiende bien como una identidad ensamblada, no robada, para pasar controles sin conectarse con ninguna persona real. La misma construcción funciona contra las identidades de las máquinas, pero la mayoría de las organizaciones se centran en credenciales de NHI robadas en lugar de identidades fabricadas. Con identidades de máquinas fabricadas, un atacante no toma prestada una identidad real, sino que crea una que nunca se suponía que existiera. En lugar de iniciar sesión como una cuenta de servicio legítima, el atacante registra una nueva identidad de nivel de administrador con una estructura de nombres similar, le otorga privilegios y la deja pasar desapercibida. Dado que no se secuestra nada, no hay ningún usuario comprometido al que alertar ni ningún comportamiento sospechoso que señalar.

Lo que hace que estas identidades sean convincentes es la combinación de atributos reales e inventados. Un NHI fabricado hereda las convenciones de nomenclatura de su entorno, existe en el dominio correcto, lleva metadatos que parecen plausibles y solicita los tipos de permisos que otros NHI ya tienen. Para un administrador que hojea un directorio de decenas de miles de cuentas de servicio, es simplemente una carga de trabajo rutinaria más, razón por la cual ésta es una de las Riesgos del NHI que más se pasan por alto.

Cómo se construyen las identidades de máquinas fabricadas

Ninguna de las técnicas que utilizan los atacantes para crear identidades de máquinas falsas es nueva. Lo nuevo, sin embargo, es verlos como un patrón de inserción de una identidad aparentemente creíble pero ilegítima en un entorno predispuesto a confiar en ella. En la práctica, los atacantes crean identidades de máquinas fabricadas de varias formas principales:

  • Cuenta de servicio fraudulenta: En lugar de comprometer una cuenta que ya existe, un atacante que ha obtenido acceso crea una nueva cuenta que aspecto como uno existente, con atributos de apariencia similar y acceso permanente. Una cuenta que nunca fue sancionada pero que se comporta como tal es la forma más pura de una identidad de máquina fabricada.
  • DCSombra: Al operar a nivel de infraestructura, un atacante no fabrica una cuenta sino más bien una fuente completa de autoridad. Debido a que depende de los derechos de administrador de dominio que el atacante ya posee, es un movimiento posterior al compromiso más que una forma de entrada: el atacante registra temporalmente un controlador de dominio no autorizado para que los cambios maliciosos parezcan tráfico de replicación legítimo de un par confiable. Una vez que se acepta esa infraestructura suplantada, cualquier cosa que impulse hereda la propia credibilidad del sistema.
  • Credenciales en la sombra: Un atacante implanta una autenticación fabricada en un objeto existente, inyectando material controlado por el atacante para que pueda autenticarse como ese objeto a voluntad. Dado que la identidad ya existe y parece intacta, éste es el medio más sutil de demostrar que una identidad ha sido forjada silenciosamente.

Si bien los mecanismos difieren, todos implican una identidad ilegítima que el entorno ha aceptado como propia. Es importante separar esto de una idea relacionada llamada persona sintéticadefinido por el NHI Management Group como una identidad fabricada creada para parecer creíble ante gente y se utiliza para engañar a usuarios humanos a través de perfiles falsos y tácticas de ingeniería social. Eso es lo contrario de una identidad de máquina fabricada, que no es un humano falso destinado a engañar a la gente, sino una máquina falsa que vive dentro de sistemas, tiene privilegios reales y no responde ante nadie.

La falta de atención que recibe este equivalente del lado de la máquina es lo que lo hace tan peligroso. Las identidades de máquinas fabricadas pueden evadir la detección creada para identificar las robadas porque el verdadero propietario de una identidad robada puede notar un inicio de sesión desde un lugar desconocido o recibir una alerta de la web oscura. Mientras tanto, una identidad fabricada sin propietario no generará ninguna alarma sobre comportamientos sospechosos, secretos filtrados o cualquier cosa digna de mención. Dado que los NHI están creciendo rápidamente a un ritmo que supera en número a los usuarios humanos, es posible que las empresas no noten una identidad no monitoreada como un valor atípico si oculta y acumula permisos silenciosamente.

Por qué la IA agente hace que esto sea más oportuno

Hasta hace poco, fabricar la identidad de una máquina requería que un atacante ingresara a un sistema, creara una cuenta falsa y asignara sus privilegios manualmente. La IA agente está empezando a eliminar esa fricción. Los agentes de IA ya adquieren credenciales dinámicamente en tiempo de ejecución y son cada vez más capaces de activar otros agentes con identidades propias. A medida que la creación de identidades por máquinas se convierte en una actividad automatizada en segundo plano, la línea entre una identidad creada legítimamente y una fabricada comienza a desdibujarse.

Cómo defenderse de las identidades de máquinas sintéticas

Si las identidades fabricadas pasan desapercibidas, las organizaciones no pueden esperar protegerse detectando manualmente cada una de ellas. Una gobernanza sólida garantiza que las identidades fabricadas no puedan mezclarse, acumularse o persistir desde el principio.

Asignar la propiedad de cada NHI

Lo que permite que una identidad fabricada sobreviva es el hecho de que nadie sabe cómo controlarla. Cada NHI debe tener un propietario humano registrado, un propósito documentado y una fecha de vencimiento, eliminando la posibilidad de que las identidades permanezcan permanentes por defecto. Una identidad de máquina con un propietario garantiza que alguien rinda cuentas y ayuda a proteger las identidades legítimas en el proceso.

Rotar secretos

Varias técnicas de fabricación tienen éxito al inyectar credenciales ocultas en un objeto existente, donde un atacante deja claves que controla para autenticarse a voluntad. La gestión centralizada de secretos con rotación automatizada corta esos caminos. Cada secreto abovedado, rastreado y rotado prohíbe que una credencial inyectada o fabricada tenga una vida útil prolongada. Las organizaciones deben intentar dejar a los atacantes en una posición en la que no puedan anclar la autenticación de una identidad fabricada.

Hacer cumplir el privilegio mínimo

Las identidades fabricadas introducen importantes riesgos de seguridad debido a lo que pueden alcanzar y el acceso permanente que tienen las cuentas de servicio típicas. Las organizaciones que imponen el acceso con privilegios mínimos y el acceso justo a tiempo (JIT) minimizan el impacto de las identidades fabricadas en todos los entornos. Si una identidad posee sólo los permisos que necesita durante el tiempo que los necesite, entonces una identidad fabricada heredará una ventana pequeña y de tiempo limitado en lugar de acceso permanente. Esto limita el daño que puede causar cualquier identidad, real o falsa, por lo que es eficaz contra amenazas que las organizaciones tal vez ni siquiera hayan detectado.

Verificar continuamente el comportamiento

La principal ventaja de una identidad fabricada es que parece legítima desde su creación, con el nombre correcto, metadatos plausibles y el dominio correcto. Si la confianza se establece solo una vez durante el aprovisionamiento, será menos probable que las organizaciones noten actividad inusual. La verificación continua cambia la base de la confianza de las credenciales en el momento de la creación al comportamiento a lo largo del tiempo, basándose en lo que realmente hace la identidad y a qué accede. Verificar continuamente el comportamiento es la forma en que las organizaciones pueden detectar más fácilmente las identidades falsas que fueron lo suficientemente convincentes para ingresar.

Cuenta de las falsificaciones en seguridad de identidad

Proteger las identidades ha significado proteger las identidades reales de la explotación. Si bien sigue siendo importante rotar las credenciales filtradas y bloquear las cuentas comprometidas, eso supone que se supone que todas las identidades en un entorno están ahí. Las organizaciones deben ser capaces de detectar identidades que nunca fueron creadas legítimamente pero que se comportan como si fueran reales. La seguridad de la identidad de las máquinas exige que cada identidad sea propiedad de cada identidad, que cada secreto sea de corta duración y que cada comportamiento sea monitoreado de cerca, todo lo cual se puede hacer desde una plataforma de seguridad de identidad como GuardiánPAM®. Al gestionar la propiedad, los secretos y el acceso privilegiado, las organizaciones tienen más posibilidades de eliminar los escondites de identidad fabricados y garantizar que nada se pueda acumular.

Nota: Este artículo fue escrito cuidadosamente y contribuido para nuestra audiencia por Ashley D’Andrea, redactora de contenido de Keeper Security.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

SleeperGem utiliza tres paquetes maliciosos de RubyGems para atacar las máquinas de los desarrolladores – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han señalado un nuevo ataque a la cadena de suministro de software con nombre en código SleeperGem dirigido al ecosistema Ruby después de que se publicaran tres gemas maliciosas en RubyGems con el objetivo final de servir cargas útiles adicionales.

Las gemas rebeldes se enumeran a continuación:

«Cada lanzamiento malicioso es un cargador», StepSecurity dicho en un análisis. «Obtiene una segunda etapa de un host Forgejo controlado por un atacante, verifica si se está ejecutando en un sistema de compilación y lo omite si lo está, y en una máquina de desarrollo coloca un demonio nativo e instala la persistencia».

Ciberseguridad

Un aspecto del ataque que se destaca de inmediato es que «git_credential_manager» se hace pasar por el administrador oficial de credenciales Git de Microsoft, mientras que los otros dos habían estado inactivos durante años antes de recibir las actualizaciones maliciosas. «Dendreo» se actualizó por última vez el 24 de octubre de 2020 y «fastlane-plugin-run_tests_firebase_testlab» permaneció inactivo desde el 9 de marzo de 2019, antes de las nuevas versiones.

Otro rasgo definitorio de la actividad es que los lanzamientos se publicaron directamente en el registro sin ningún compromiso o etiqueta coincidente en los proyectos fuente.

Curiosamente, «git_credential_manager» ha sido agregado como una dependencia de cinco paquetes, incluidos «Dendreo» y «fastlane-plugin-run_tests_firebase_testlab», lo que permite efectivamente que la carga maliciosa se propague a los usuarios existentes de los paquetes.

  • dendreo
  • fastlane-plugin-run_tests_firebase_testlab
  • holguraHtmlToMarkdown
  • seo_optimizador
  • métodos_rápidos_array

Todos los paquetes antes mencionados, a excepción de «fastlane-plugin-run_tests_firebase_testlab», se mantienen en la misma cuenta («LR-DEV«). El hecho de que la gema pertenece a un mantenedor diferente («habitación rosa«) indica que es probable que más de una cuenta haya sido comprometida para enviar las versiones no autorizadas a RubyGems.

Una vez instalado, el malware integrado en estos paquetes escanea el sistema infectado en busca de aproximadamente 30 variables de entorno, incluidas las relacionadas con GitHub Actions, GitLab, CircleCI, Travis, Jenkins y Vercel. Si se identifica alguno de ellos, se cierra de inmediato. Se considera que la verificación es un intento intencional de evitar la ejecución en corredores de CI efímeros y garantizar que se ejecute en una máquina de desarrollador.

En el caso de «git_credential_manager», el código malicioso se activa cuando se requiere la biblioteca, lo que provoca que descargue dos cargas útiles desde una instancia pública de Forgejo («git.disroot[.]org/git-ecosystem»): un script de shell («deploy.sh») y un binario nativo que lleva el mismo nombre que la herramienta que disfraza la gema. En Windows, la carga útil recuperada se ejecuta a través de PowerShell.

Mientras que la versión 2.8.2 simplemente prepara las cargas útiles, la versión 2.8.3 de la gema pasa a la siguiente fase del ataque. Esto implica usar el script de instalación para iniciar el binario como un demonio en segundo plano, después de lo cual establece la persistencia usando una entrada cron y como un servicio de usuario systemd y consulta los grupos sudo y wheel.

«Si el usuario puede ejecutar sudo sin contraseña, el script se vuelve a ejecutar como root, y cuando se ejecuta como root coloca una copia raíz setuid del shell del sistema en una ruta elegida para imitar una utilidad de red», dijo StepSecurity.

Se recomienda a los usuarios que hayan instalado cualquiera de las gemas antes mencionadas que traten las máquinas y los secretos asociados como si estuvieran comprometidos. También se recomienda eliminar el demonio eliminado en «~/.local/share/gcm/», borrar los métodos de persistencia, buscar un shell setuid en «/usr/local/sbin/ping6» y rotar todas las credenciales.

«Una cuenta de RubyGems que ha permanecido inactiva durante seis o siete años no parece riesgosa para nadie», Charlie Eriksen, investigador de Aikido Security dicho. «Ese es exactamente el perfil que vale la pena tomar. De ahí proviene el nombre SleeperGem: no es un activo de atacante plantado y de largo plazo, sino una cuenta real y ordinaria que simplemente había quedado inactiva y parecía lo suficientemente inofensiva como para secuestrarla sin que nadie se diera cuenta».

RubyGems como punto muerto de filtración de datos

La divulgación se produce más de dos meses después de que RubyGems detuviera brevemente los registros de cuentas después de que los delincuentes impulsaran docenas de paquetes maliciosos como parte de una campaña coordinada de publicación de spam. Casi al mismo tiempo, los investigadores de Socket señalaron una campaña paralela que inundó el registro con 150 gemas y abusó de ellas como canal de filtración de datos.

Ciberseguridad

A principios de este mes, Mend.io reveló detalles de un ataque a la cadena de suministro de software no documentado que empleó otro conjunto de 14 paquetes RubyGems para almacenar datos de credenciales robadas.

Específicamente, se descubrió que una extensión de navegador maliciosa recopiló credenciales a través de una API accesible localmente, empaquetó la información en archivos .gem válidos completamente dentro del navegador usando JavaScript y API web estándar, y cargó esos paquetes directamente en RubyGems.org usando una clave API de RubyGems codificada.

«El botín incluyó contraseñas de texto plano, claves privadas SSH, credenciales de AWS, frases iniciales de billeteras criptográficas, números de Seguro Social, números de tarjetas de crédito y detalles de cuentas bancarias en 63 elementos de la bóveda», Maciej Mensfeld dicho.

«RubyGems no era el mecanismo de entrega aquí. Era el punto muerto: un dominio confiable y de alto tráfico donde los datos robados permanecían hasta que el atacante regresaba a buscarlos, invisible entre las cargas normales de los desarrolladores».

Una falla de KVM de Linux de hace 16 años permite que las máquinas virtuales invitadas escapen al host en sistemas Intel y AMD x86

Se puede activar un error de uso después de la liberación en el hipervisor KVM de Linux desde una máquina virtual invitada para corromper el estado de la página oculta del kernel host que lo ejecuta.

Apodado ‘Januscape‘ y rastreado como CVE-2026-53359la falla se encuentra en el código MMU oculto que KVM comparte tanto en Intel como en AMD. La prueba de concepto pública hace que el anfitrión entre en pánico; El investigador afirma que un exploit separado e inédito convierte el mismo error en la ejecución completa del código host.

investigador de seguridad Hyunwoo Kim (@v4bel) encontró e informó el error. Describió a Januscape como el primer exploit de huésped a host que se puede activar tanto en Intel como en AMD, hasta donde el público sabe. El defecto pasó desapercibido durante aproximadamente 16 años.

Según Kim, el exploit se utilizó como envío de día cero en kvmCTF de Googleel programa de recompensas por vulnerabilidades de KVM controladas que ofrece hasta 250 000 dólares por escapadas completas de invitado a anfitrión.

Cómo funciona

Para ejecutar una máquina virtual, KVM mantiene su propio conjunto privado de tablas de páginas que reflejan el diseño de la memoria del invitado. Cuando necesita una de estas páginas de seguimiento, busca una existente para reutilizarla.

El problema: los comparó solo por la dirección de memoria e ignoró qué tipo de página de seguimiento estaba tomando. Dos tipos diferentes pueden compartir la misma dirección pero realizar trabajos completamente diferentes, por lo que KVM a veces reutiliza el tipo incorrecto.

Ciberseguridad

Esa confusión codifica los registros internos de KVM sobre qué página pertenece y dónde, y una vez que esos registros son incorrectos, algo tiene que ceder.

La mayoría de las veces, el núcleo se da cuenta del desorden y se apaga en el acto para evitar causar daños. Ese bloqueo es lo que desencadena la demostración pública: un invitado puede derribar todo el host, derribando con él a todas las demás máquinas virtuales de esa máquina.

El caso más raro y peor ocurre cuando la página de seguimiento liberada se entrega para otro uso antes de que el kernel se limpie. Luego, la limpieza escribe un valor en la memoria que ya no posee. Un atacante solo controla dónde llega esa escritura, no lo que se escribe, pero incluso ese punto de apoyo limitado se puede convertir en código ejecutable en el host.

La falla se comporta igual en los chips Intel y AMD; sólo el paso final y más difícil de convertirlo en control total requiere un trabajo diferente en cada uno.

¿Quién se ve afectado?

El código vulnerable ha estado presente desde cometer 2032a93d66fa en agosto de 2010 (era del kernel 2.6.36) y fue reparado por cometer 81ccda30b4e8se fusionó con mainline el 19 de junio de 2026.

El ataque requiere dos cosas por parte del huésped: raíz dentro de la VM, una condición común en instancias de nube alquiladas, y virtualización anidada expuesta por el host. Incluso en hosts que ejecutan hardware EPT o NPT de forma predeterminada, la virtualización anidada obliga a KVM a retroceder a través de la MMU oculta heredada, que es donde se encuentra el error.

El exploit no necesita la cooperación de QEMU ni de ningún VMM del espacio de usuario. Es puramente un error de KVM en el kernel.

La preocupación práctica es cualquier entorno x86 que aloje invitados que no sean de confianza y con la virtualización anidada habilitada. Un atacante que alquila una sola instancia de este tipo puede provocar pánico en el host y desactivar todas las demás máquinas virtuales de la misma máquina física.

Kim dijo que el exploit completo retenido ejecuta código como root en el host, lo que expondría a otros invitados en la misma máquina a ese acceso de root. En distribuciones como RHEL, donde /dev/kvm se puede escribir en todo el mundo (0666), Kim notó que el mismo error también podría servir como una escalada de privilegios locales a la raíz, aunque la ruta de invitado a host es el uso de mayor impacto.

Unos meses muy ocupados para un investigador

Januscape es la tercera revelación de Kim sobre un exploit del kernel de Linux en aproximadamente dos meses. En mayo de 2026, reveló Dirty Frag (CVE-2026-43284 / CVE-2026-43500), una cadena de vulnerabilidad de escritura en caché de página que ofrece raíz determinista en la mayoría de las distribuciones principales, extendiendo la misma clase de error que Dirty Pipe y Copy Fail.

En junio publicó SU paisaje (CVE-2026-46316), el primer escape de huésped a host demostrado públicamente en KVM/arm64, que explota una condición de carrera en el controlador de interrupción virtual. Januscape ahora añade el lado x86; el mismo disparador se activa tanto en Intel como en AMD, y el PoC lleva una ruta de código separada para cada proveedor.

Ciberseguridad

Google lanzó kvmCTF en 2024 específicamente porque KVM sustenta tanto a Android como a Google Cloud. Un uso-después libre de paginación oculta KVM x86 independiente (CVE-2026-46113) que involucraba una discrepancia de rmap relacionada pero distinta, se solucionó en mayo de 2026.

Eso hace que dos MMU en la sombra se liberen en la misma ruta de código heredado en dos meses.

Qué hacer

La solución es una adición de una línea a kvm_mmu_get_child_sp(): la condición de reutilización ahora verifica role.word junto con gfn, por lo que una página oculta solo se reutiliza cuando tanto el número de fotograma como el rol coinciden. El mantenedor de KVM Paolo Bonzini escribió el parche.

Versiones estables fijas enviadas el 4 de julio de 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 y 5.10.260. NVD aún no ha asignado una puntuación CVSS; no esperes uno.

Si opera un host KVM x86 que acepta invitados multiinquilino con virtualización anidada, confirme que su kernel incluya la confirmación 81ccda30b4e8. Los backports de distribución pueden contener la solución con un número de versión diferente, así que verifique el registro de cambios del paquete en lugar de confiar solo en uname -r.

Si no puede parchear inmediatamente, deshabilitar la virtualización anidada (kvm_intel.nested=0 o kvm_amd.nested=0) elimina la ruta de ataque para invitados que no son de confianza. Los hosts ARM64 no se ven afectados por Januscape; ITScape (CVE-2026-46316) es un problema separado de KVM/arm64.

La PoC pública demuestra un pánico de host confiable por parte de un invitado con un módulo de kernel cargable y segundos o minutos de carrera. Trate los hosts KVM x86 expuestos con virtualización anidada como objetivos de parches de alta prioridad.

Las amenazas electorales se centran en los sistemas de campaña, no en las máquinas de votación

Las amenazas a la ciberseguridad para las elecciones intermedias de 2026 están dirigidas a las cuentas y plataformas que las campañas, los donantes y los votantes utilizan para comunicarse, según un informe de seguridad publicado el lunes por Check Point Software Technologies.

En lo que va de este ciclo electoral, las amenazas no están dirigidas a las máquinas de votación ni a los sistemas de conteo de votos. En cambio, los actores de amenazas van tras las cuentas de correo electrónico, los sitios web y las plataformas de recaudación de fondos de las que dependen las organizaciones electorales.

Jeremy Fuchs, director de campaña de Check Point, dijo a CyberScoop que los principales hallazgos del informe reflejan una tendencia más amplia en ciberseguridad: los malos actores están utilizando la IA para hacer que sus ataques sean más grandes y más efectivos.

«La barrera de entrada es menor y la calidad es mucho mayor que hace tres o diez años, por lo que todo parecerá más realista y será más eficaz para lograr cualquier objetivo». [attackers] tengo”, dijo.

El correo electrónico sigue siendo la forma más fácil para que los piratas informáticos ataquen a grupos relacionados con las elecciones. Check Point descubrió que el 82% de los ataques maliciosos llegan a través del correo electrónico. El informe también encontró una gran cantidad de contraseñas robadas de los principales sitios de recaudación de fondos. A ActBlue, que recauda donaciones para los candidatos demócratas, le robaron unas 9.500 contraseñas. WinRed, la plataforma republicana de recaudación de fondos, tenía alrededor de 6.500.

Fuchs señaló que esta información puede no usarse directamente para esquemas relacionados con las elecciones, pero podría aprovecharse para intentos oportunistas de seguimiento de acceder a otras cuentas.

«Cada vez que ocurre una exposición como esta, ya sea con un sitio político o no, muchas veces se guarda para más adelante», dijo. «Si tengo su correo electrónico y contraseña, si tengo su número de teléfono, puedo iniciar un ataque, un simple ataque de phishing que no tiene nada que ver con las elecciones en este momento».

Los actores de amenazas también están registrando muchos sitios web nuevos con nombres relacionados con las elecciones. En enero, alrededor de 1.300 nuevos sitios web incluyeron la palabra “elección” y alrededor de 4.010 incluyeron la palabra “voto”. Estos sitios web se pueden utilizar para estafas de phishing, en las que los piratas informáticos engañan a las personas para que revelen sus contraseñas haciéndose pasar por organizaciones electorales legítimas.

Fuchs señaló que no todos los sitios web pueden resultar maliciosos, pero la velocidad con la que se han establecido estos sitios (especialmente cuando los sitios de campaña legítimos han estado funcionando años antes de una elección) ha llevado a los investigadores a creer que la mayoría se utilizarán con fines nefastos.

«Si estás creando estos sitios web muy rápidamente y a escala, hay una razón para ello», afirmó.

La desinformación y el contenido manipulado presentan otra capa de preocupación, especialmente porque el contenido político generado por IA se ha vuelto cada vez más visible en el ciclo 2026. A principios de este mes, OpenAI lanzó un conjunto de herramientas y salvaguardas destinadas a proporcionar una capa de seguridad para este ciclo electoral en particular.

Fuchs dijo que esta manipulación impulsada por la IA solo crecerá a medida que nos acerquemos al día de las elecciones, y a medida que los modelos mejoren, también lo hará la capacidad de los actores para engañar a las personas con contenido falso.

«Es realmente difícil encontrarle sentido a estas cosas cuando la IA y los ataques se han vuelto tan buenos», dijo. «Era difícil cuando no eran buenos. Así que ahora imaginen cuánto más difícil será cuando sean buenos y sigan mejorando cada vez más».

Fuchs advirtió que la velocidad a la que están evolucionando las amenazas electorales impulsadas por la IA presenta un desafío que se extiende más allá de las defensas técnicas, y dijo que el verdadero desafío radica en un panorama de amenazas que está cambiando más rápido de lo que la comprensión pública puede seguir.

«Hay mucho más que nosotros, como sociedad, realmente podemos comprender», dijo a CyberScoop. La IA generativa «se está moviendo muy rápido. Se está volviendo tan buena. Y si no tenemos esas conversaciones sobre, 'oye, así es como las cosas podrían cambiar', todo esto seguirá volviéndose cada vez más difícil. Y va a estallar en estos puntos de inflexión, si una elección es el lugar perfecto para ello, porque hay mucho en juego para tanta gente».

Has leído el informe completo sobre Check Point's sitio web.

Greg Otto

Escrito por Greg Otto

Greg Otto es el editor en jefe de CyberScoop y supervisa todo el contenido editorial del sitio web. Greg ha dirigido una cobertura de ciberseguridad que ha ganado varios premios, incluidos los de la Sociedad de Periodistas Profesionales y la Sociedad Estadounidense de Editores de Publicaciones Empresariales. Antes de unirse a Scoop News Group, Greg trabajó para Washington Business Journal, US News & World Report y WTOP Radio. Tiene una licenciatura en periodismo televisivo de la Universidad de Temple.

Cómo LiteLLM convirtió las máquinas de los desarrolladores en bóvedas de credenciales para los atacantes – CYBERDEFENSA.MX

La parte más activa de la infraestructura empresarial de la empresa es la estación de trabajo del desarrollador. Esa computadora portátil es donde se crean, prueban, almacenan en caché, copian y reutilizan las credenciales en servicios, bots, herramientas de compilación y, ahora, agentes de IA locales.

En marzo de 2026, el actor de amenazas TeamPCP demostró lo valiosas que son las máquinas de desarrollo. Su ataque a la cadena de suministro contra LiteLLM, una popular biblioteca de desarrollo de inteligencia artificial descargada millones de veces al día, convirtió los puntos finales de los desarrolladores en operaciones sistemáticas de recolección de credenciales. El malware solo necesitaba acceso a los secretos de texto sin formato que ya se encontraban en el disco.

El ataque LiteLLM: un estudio de caso sobre el compromiso de los terminales de los desarrolladores

El ataque fue sencillo en ejecución pero devastador en alcance. TeamPCP comprometió los paquetes LiteLLM versiones 1.82.7 y 1.82.8 en PyPI, inyectando malware de robo de información que se activaba cuando los desarrolladores instalaban o actualizaban el paquete. El malware recopiló sistemáticamente claves SSH, credenciales de nube para AWS, Azure y GCP, configuraciones de Docker y otros datos confidenciales de las máquinas de los desarrolladores.

PyPI eliminó los paquetes maliciosos a las pocas horas de su detección, pero la ventana de daño fue significativa. El análisis de GitGuardian encontró que se configuraron 1.705 paquetes PyPIpara extraer automáticamente las versiones comprometidas de LiteLLM como dependencias. Paquetes populares como dspy (5 millones de descargas mensuales), opik (3 millones) y crawl4ai (1,4 millones) habrían desencadenado la ejecución de malware durante la instalación. El efecto cascada significó que las organizaciones que nunca usaron LiteLLM directamente aún podrían verse comprometidas a través de dependencias transitivas.

Por qué las máquinas de desarrollo son objetivos atractivos

Este patrón de ataque no es nuevo; es simplemente más visible. El Campañas de Shai-Hulud demostró tácticas similares a escala. Cuando GitGuardian analizó 6.943 máquinas de desarrollador comprometidas a partir de ese incidente, los investigadores encontraron 33.185 secretos únicos, de los cuales al menos 3.760 aún eran válidos. Más sorprendente: cada secreto activo apareció en aproximadamente ocho ubicaciones diferentes en la misma máquina, y el 59% de los sistemas comprometidos eran ejecutadores de CI/CD en lugar de computadoras portátiles personales.

Los adversarios ahora entran en la cadena de herramientas a través de dependencias comprometidas, complementos maliciosos o actualizaciones envenenadas. Una vez allí, recopilan datos del entorno local con el mismo enfoque sistemático que utilizan los equipos de seguridad para buscar vulnerabilidades, excepto que buscan credenciales almacenadas en archivos .env, perfiles de shell, historial de terminal, configuraciones IDE, tokens almacenados en caché, artefactos de compilación y almacenes de memoria de agentes de IA.

Los secretos viven en todas partes en texto plano

El malware LiteLLM tuvo éxito porque las máquinas de los desarrolladores son puntos de concentración densos para las credenciales de texto sin formato. Los secretos terminan en árboles de fuentes, archivos de configuración locales, resultados de depuración, comandos de terminal copiados, variables de entorno y scripts temporales. Se acumulan en archivos .env que se suponía que eran solo locales pero que se convirtieron en una parte permanente del código base. La comodidad se convierte en residuo, que a su vez se convierte en oportunidad.

Los desarrolladores ejecutan agentes, servidores MCP locales, herramientas CLI, extensiones IDE, canalizaciones de compilación y flujos de trabajo de recuperación, todos los cuales requieren credenciales. Esas credenciales se distribuyen a través de rutas predecibles donde el malware sabe buscar: ~/.aws/credentials, ~/.config/gh/config.yml, archivos .env del proyecto, historial de shell y directorios de configuración del agente.

Protección de los puntos finales de los desarrolladores a escala

Es importante crear una protección continua en todos los puntos finales del desarrollador donde se acumulan las credenciales. GitGuardian aborda esto extendiendo la seguridad de los secretos más allá de los repositorios de código hasta la propia máquina del desarrollador.

El ataque LiteLLM demostró lo que sucede cuando las credenciales se acumulan en texto sin formato en los puntos finales de los desarrolladores. Esto es lo que puede hacer para reducir esa exposición.

Comprenda su exposición

Comience con la visibilidad. Trate la estación de trabajo como el entorno principal para escanear secretos, no como una ocurrencia tardía. Utilice ggshield para escanear repositorios locales en busca de credenciales que se filtraron en el código o persisten en el historial de Git. Analice las rutas del sistema de archivos donde se acumulan secretos fuera de Git: espacios de trabajo de proyectos, archivos de puntos, resultados de compilación y carpetas de agentes donde las herramientas locales de IA generan registros, cachés y almacenes de «memoria».

ggshield detecta un secreto en un archivo específico desde una ruta

No asuma que las variables de entorno son seguras sólo porque no están en archivos. Los perfiles de Shell, las configuraciones IDE y los artefactos generados a menudo persisten en los valores del entorno en el disco de forma indefinida. Escanee estas ubicaciones de la misma manera que escanea los repositorios.

Agregue ganchos de confirmación previa de ggshield para dejar de crear nuevas fugas en las confirmaciones mientras limpia las antiguas. Esto convierte la detección secreta en una barrera de seguridad predeterminada que detecta los errores antes de que se conviertan en incidentes.

Comando de confirmación previa de ggshield que detecta un secreto

Mover secretos a bóvedas

La detección sin remediación es sólo ruido. Cuando se filtra una credencial, la remediación generalmente requiere la coordinación entre varios equipos: la seguridad identifica la exposición, la infraestructura es propietaria del servicio, es posible que el desarrollador original haya abandonado la empresa y los equipos de producto se preocupan por las interrupciones en la producción. Sin una propiedad clara y una automatización del flujo de trabajo, la remediación se convierte en un proceso manual al que se le quita prioridad.

La solución trata los secretos como identidades administradas con propiedad definida, políticas de ciclo de vida y rutas de reparación automatizadas. Mueva las credenciales a una infraestructura de bóveda centralizada donde los equipos de seguridad puedan aplicar programas de rotación, políticas de acceso y monitoreo de uso. Integre la gestión de incidentes con sus sistemas de emisión de tickets existentes para que la solución se produzca en contexto en lugar de requerir un cambio constante de herramientas.

GitGuardian Analytics que muestra el estado de los secretos que se están monitoreando

Trate a los agentes de IA como riesgos de credenciales

Las herramientas agentes pueden leer archivos, ejecutar comandos y mover datos. Con los agentes estilo OpenClaw, la «memoria» son literalmente archivos en el disco (SOUL.md, MEMORY.md) almacenados en ubicaciones predecibles. Nunca pegue credenciales en los chats de los agentes, nunca les enseñe secretos a los agentes «para más tarde» y escanee de forma rutinaria los archivos de memoria de los agentes como almacenes de datos confidenciales.

Eliminar clases enteras de secretos

La forma más rápida de reducir la proliferación de secretos es eliminar la necesidad de categorías enteras de secretos compartidos. En el lado humano, adopte WebAuthn (claves de acceso) para reemplazar las contraseñas. En cuanto a la carga de trabajo, migre a la federación OIDC, para que las canalizaciones dejen de depender de las claves almacenadas en la nube y los secretos de las cuentas de servicio.

Comience con las rutas de mayor riesgo donde las credenciales filtradas perjudican más y luego amplíe. Mueva el acceso de desarrollador a claves de acceso y migre flujos de trabajo de CI/CD a autenticación basada en OIDC.

Utilice credenciales efímeras

Si aún no puede eliminar los secretos, hágalos de corta duración y reemplácelos automáticamente. Utilice SPIFFE para emitir documentos de identidad criptográficos (SVID) que rotan automáticamente en lugar de depender de claves API estáticas.

Comience con claves de nube, tokens de implementación y credenciales de servicio de larga duración que los desarrolladores conservan localmente para su comodidad. Cambie a tokens de corta duración, rotación automática y patrones de identidad de cargas de trabajo. Cada migración es un secreto menos duradero que puede ser robado y convertido en arma.

El objetivo es reducir el valor que un atacante puede extraer de cualquier punto de apoyo exitoso en una máquina de desarrollador.

Honeytokens como sistemas de alerta temprana

Los Honeytokens brindan protección provisional. Coloque credenciales señuelo en ubicaciones a las que los atacantes apuntan sistemáticamente: directorios de inicio de desarrolladores, rutas de configuración comunes y almacenes de memoria de agentes. Cuando se recolectan y validan, estos tokens generan alertas inmediatas, comprimiendo el tiempo de detección de «descubrir daños semanas después» a «detectar ataques mientras se desarrollan». Este no es el estado final, pero cambia la ventana de respuesta mientras continúa la limpieza sistemática.

Los puntos finales de desarrollador ahora son parte de su infraestructura crítica. Se encuentran en la intersección del privilegio, la confianza y la ejecución. El incidente de LiteLLM demostró que los adversarios entienden esto mejor que la mayoría de los programas de seguridad. Las organizaciones que traten las máquinas de desarrollo con la misma disciplina de gobernanza que ya se aplica a los sistemas de producción serán las que sobrevivan al próximo compromiso de la cadena de suministro.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.