Un banco aprobó un píxel Taboola. Ese píxel redirigió silenciosamente a los usuarios que iniciaron sesión a un punto final de seguimiento de Temu. Esto ocurrió sin el conocimiento del banco, sin el consentimiento del usuario y sin que un solo control de seguridad registrara una infracción.

Lea el desglose técnico completo en el Resumen de inteligencia de seguridad. Descargar ahora →

El punto ciego del «sesgo del primer salto»

La mayoría de las pilas de seguridad, incluidos WAF, analizadores estáticos y CSP estándar, comparten un modo de falla común: evalúan la origen declarado de un guión, no del destino de tiempo de ejecución de su cadena de solicitudes.

Si sync.taboola.com está en la lista permitida de su Política de seguridad de contenido (CSP), el navegador considera que la solicitud es legítima. Sin embargo, no revalida contra el destino terminal de un redirección 302. Cuando el navegador llega a temu.com, ha heredado la confianza otorgada a Taboola.

El rastro forense

Durante una auditoría realizada en febrero de 2026 de una plataforma financiera europea, Reflectiz identificó la siguiente cadena de redireccionamiento que se ejecuta en páginas de cuentas en las que se ha iniciado sesión:

1. Solicitud inicial: Una solicitud GET a https://sync.taboola.com/sg/temurtbnative-network/1/rtb/.
2. La redirección: El servidor respondió con un 302 encontradoredirigiendo el navegador a https://www.temu.com/api/adx/cm/pixel-taboola?….
3. La carga útil: La redirección incluía el encabezado crítico Access-Control-Allow-Credentials: true.

Este encabezado indica específicamente al navegador que incluya cookies en la solicitud de origen cruzado al dominio de Temu. Este es el mecanismo mediante el cual Temu puede leer o escribir identificadores de seguimiento en un navegador que ahora sabe que visitó una sesión bancaria autenticada.

Por qué las herramientas convencionales no lo lograron

«`html

«`

Las consecuencias regulatorias

Para las entidades reguladas, la ausencia de robo directo de credenciales no limita la exposición al cumplimiento. Nunca se informó a los usuarios que el comportamiento de su sesión bancaria estaría asociado con un perfil de seguimiento de PDD Holdings, una falla de transparencia según el art. 13. El enrutamiento en sí involucra infraestructura en un país no adecuado, y sin Cláusulas Contractuales Estándar que cubran esta relación específica de cuarto partido, la transferencia no está respaldada por el Capítulo V del RGPD. «No sabíamos que el píxel hacía eso» no es una defensa disponible para un controlador de datos según el art. 24.

La exposición al PCI DSS agrava esto. Una cadena de redireccionamiento que termina en un dominio de terceros no previsto queda fuera del alcance de cualquier revisión que evalúe sólo al proveedor principal, que es precisamente lo que Requerido 6.4.3 fue escrito para cerrar.

Inspeccionar el tiempo de ejecución, no sólo las declaraciones

En este momento, la misma configuración de píxeles de Taboola se ejecuta en miles de sitios web. La pregunta no es si se están produciendo cadenas de redireccionamiento como ésta. Ellos son. La pregunta es si su pila de seguridad puede ver más allá del primer salto, o si se detiene en el dominio que usted aprobó y da por terminado.

Para equipos de seguridad: inspeccionar el comportamiento del tiempo de ejecución, no solo las listas de proveedores declaradas.

Para equipos legales y de privacidad: Las cadenas de seguimiento a nivel del navegador en páginas autenticadas garantizan el mismo rigor que las integraciones de backend.

La amenaza entró por la puerta grande. Su CSP lo dejó entrar.

El registro completo de evidencia técnica se encuentra en el Security Intelligence Brief. Descárgalo aquí →

Una empresa se despierta con una noticia que afirma que ha sufrido una importante filtración de datos. Los detalles son específicos, técnicos y convincentes. Pero la infracción no se produjo. Ningún sistema se vio comprometido. No se tomaron datos. Un modelo de lenguaje generó la historia completa, completando detalles plausibles desde cero. Y antes de que la empresa pueda descubrir qué está pasando, un periodista de un medio de renombre retoma la historia y solicita comentarios. En cuestión de horas, la empresa está redactando declaraciones y movilizando a su equipo de comunicaciones para abordar un evento ficticio.

Un segundo incidente comienza con algo real. Años antes, una empresa había sufrido una auténtica infracción que recibió una amplia cobertura mediática. El incidente fue investigado, resuelto y cerrado. Luego, uno de los medios que informó originalmente sobre ello rediseñó su sitio web. Los artículos antiguos recibieron nuevas URL y marcas de tiempo actualizadas, y los motores de búsqueda los volvieron a indexar como contenido nuevo. Los agregadores de noticias impulsados ​​por inteligencia artificial captaron la señal y la marcaron como una historia en desarrollo. La empresa se encontró atendiendo consultas sobre un incidente que se había resuelto años antes.

[Ed. note: The authors are withholding full specifics about the incidents because full disclosure could cause harm, yet CyberScoop confirmed with the authors that the incidents did in fact take place].

Un tercer incidente introduce otra dimensión. Una publicación de ciberseguridad publicó una historia sobre un ataque de compromiso de correo electrónico empresarial que le costó a una empresa del Reino Unido cerca de mil millones de libras. El artículo citado un conocido investigador de seguridadpero en realidad no había hablado con la publicación. AI generó las citas, se las asignó con total confianza y la publicación las publicó como si fueran un hecho.

En conjunto, estos tres casos exponen una amenaza para la que la mayoría de las organizaciones aún no se han preparado. La IA ha desarrollado la capacidad de fabricar incidentes de seguridad convincentes a partir de la nada, con detalles técnicos, fuentes nombradas y credibilidad suficiente para desencadenar respuestas a crisis a gran escala. Cualquier organización que trate esto como un problema distante o teórico corre el riesgo de aprender por las malas cuán rápido la ficción generada por IA puede convertirse en una emergencia del mundo real.

La suposición que ya no se cumple

La respuesta a las crisis cibernéticas siempre se ha basado en una premisa simple: sucede algo real y luego se responde. Esa premisa se está rompiendo. Los sistemas de inteligencia artificial ahora generan, amplifican y validan reclamos antes de que los equipos de seguridad confirmen algo. Una vez que una narrativa ingresa al ecosistema, se puede incorporar a fuentes de inteligencia sobre amenazas, plataformas de calificación de riesgos y flujos de trabajo automatizados. La ficción se convierte en señal.

Para los equipos de seguridad, esto crea una nueva clase de falso positivo. No es una alerta ruidosa de una herramienta mal configurada, sino una narrativa externa completamente formada que parece creíble. Una infracción alucinada puede desencadenar investigaciones internas, escalada ejecutiva y acciones defensivas. El tiempo y los recursos se desvían hacia refutar algo que nunca sucedió.

Peor aún, puede influir en el comportamiento de un atacante real. Los actores de amenazas pueden utilizar como pretexto narrativas inventadas sobre violaciones. Los correos electrónicos de phishing que hacen referencia a un «incidente conocido» se vuelven más creíbles. La suplantación de equipos de TI o de respuesta a incidentes se vuelve más efectiva. La narrativa se convierte en parte de la superficie de ataque.

Qué significa esto para los equipos de seguridad

Los equipos de seguridad están acostumbrados a monitorear indicadores de compromiso. Ahora necesitan monitorear los indicadores de narrativa. Los canales de inteligencia de código abierto están cada vez más automatizados. Si esos oleoductos ingieren información falsa, los sistemas posteriores actuarán en consecuencia. Eso incluye el enriquecimiento de SIEM, la puntuación de riesgos de terceros e incluso decisiones de contención automatizadas en algunos entornos.

La implicación práctica es que los equipos de seguridad necesitan visibilidad de cómo se representa externamente su organización, no solo de lo que sucede internamente. Esta no es una inteligencia de amenazas tradicional, pero se comporta como tal. La detección temprana cambia los resultados.

También es necesaria una mayor integración con las comunicaciones. Cuando surge una narrativa falsa, la realidad técnica y la percepción externa divergen. Ambos deben gestionarse en paralelo.

Qué significa esto para los equipos de comunicaciones

Para los equipos de comunicaciones, el cronograma se ha colapsado. Es posible que la primera señal de una “infracción” no provenga del SOC. Puede provenir de un periodista, un cliente o una alerta automática.

El silencio ya no es neutral. Si existe una narrativa, los sistemas de IA llenarán los vacíos con cualquier información disponible. Eso puede reforzar las imprecisiones con cada iteración. Las respuestas deben diseñarse tanto para el consumo de las máquinas como para las audiencias humanas. Lenguaje claro y declarativo. Hechos comprobables. Declaraciones estructuradas que se pueden analizar y reutilizar fácilmente. El objetivo es establecer una presencia competitiva en la cadena de suministro de información.

La preparación se vuelve crítica. Lenguaje preaprobado que se puede implementar rápidamente. Coordinación establecida con el departamento legal y de seguridad antes de que surja algo.

Implicaciones compartidas

Tanto el equipo de seguridad como el de comunicaciones operan ahora en el mismo entorno, lo reconozcan o no. Una infracción alucinada puede desencadenar una verdadera perturbación operativa. Es posible que se interrumpan las relaciones con los proveedores, que se corten las conexiones con sistemas de terceros, que los reguladores se interesen y que los mercados reaccionen. Nada de eso requiere un compromiso real. Y esto crea un circuito de retroalimentación. Las narrativas externas impulsan las acciones internas. Las acciones internas, si son visibles, refuerzan las narrativas externas.

Romper ese círculo requiere velocidad, coordinación y claridad.

Auditorías de IA como mecanismo de control

Uno de los controles más eficaces en este nuevo entorno es la auditoría sistemática de la IA. Probar periódicamente cómo los sistemas de IA describen su organización, su postura de seguridad y cualquier presunto incidente. Esto proporciona visibilidad de lo que las máquinas «creen» antes de que esa creencia se difunda. Permite a las organizaciones identificar y corregir narrativas falsas de manera temprana, antes de que se propaguen a las herramientas, la toma de decisiones y el comportamiento de los atacantes. También destaca dónde debe existir información precisa. No en cualquier lugar en línea, sino en fuentes que los sistemas de inteligencia artificial priorizan.

El cambio de mentalidad

Esto marca un cambio de la respuesta al incidente a la respuesta narrativa. Los equipos de seguridad deben tratar cada alerta como potencialmente inventada. Los equipos de comunicación deben prepararse para narrativas que se formen independientemente de lo que realmente sucedió. Ambos deben operar con el entendimiento de que la percepción por sí sola puede desencadenar consecuencias reales. En este entorno, la capacidad de detectar y responder a narrativas falsas es tan importante como la capacidad de detectar y responder a violaciones reales.

Mary Catherine Sullivan es directora senior de Ciencia de Datos para Digital & Insights, dentro del segmento de Comunicaciones Estratégicas de FTI. Es líder en comunicaciones y ciencia de datos y se especializa en pruebas de mensajes, investigación de audiencias, análisis de comunicaciones digitales y evaluación de riesgos reputacionales. Como parte del equipo de ciencia de datos de FTI Consulting, desarrolla inteligencia artificial, procesamiento de lenguaje natural, aprendizaje automático y modelos estadísticos de última generación para analizar los ecosistemas de medios, el discurso de las partes interesadas y la respuesta de la audiencia, lo que respalda la toma de decisiones informada y defendible para los clientes que navegan en entornos reputacionales complejos.

Brett Callow es asesor senior en Comunicaciones de Ciberseguridad y Privacidad de Datos en FTI Consulting. Con más de dos décadas de conocimiento de la legislación y las políticas de ciberseguridad y una amplia experiencia en comunicaciones de ciberseguridad, la experiencia de Brett es ampliamente reconocida dentro de la industria, por los responsables políticos y los medios de comunicación. Ha estado involucrado en algunos de los incidentes de ransomware más destacados y ha participado en paneles y debates relacionados con políticas, incluso en la Oficina del Director de Inteligencia Nacional y el Instituto Aspen, y ha formado parte de la Junta Asesora del proyecto Ransomware Harms del Royal United Services Institute.

un porro informe de Cloud Security Alliance (CSA), el Instituto SANS y el Open Worldwide Application Security Project (OWASP) concluye que, en el corto plazo, es probable que las organizaciones “se vean abrumadas” por actores de amenazas que utilizan IA para encontrar y explotar vulnerabilidades más rápido de lo que los defensores pueden parchearlas.

Si bien esas organizaciones pueden utilizar herramientas de inteligencia artificial para acelerar sus propias defensas, los atacantes «todavía enfrentan una carga relativa más pesada debido a las limitaciones inherentes de la aplicación de parches. Esto a su vez conduce a «beneficios asimétricos» para los atacantes que pueden darse el lujo de adoptar la tecnología sin la misma cautela y burocracia que una empresa multimillonaria.

«El costo y la capacidad para explotar el descubrimiento están cayendo, el tiempo entre la divulgación y el uso de armas se está reduciendo a cero, y las capacidades que antes requerían recursos de los estados-nación ahora se están volviendo ampliamente accesibles», escribieron Robert Lee, director de inteligencia artificial del Instituto SANS, Gadi Evron, director ejecutivo de Knostic y Rich Mogull, analista jefe de CSA, quienes fueron los autores principales.

El informe marca una de las primeras respuestas integrales a las capacidades de Claude Mythos de los EE. UU., que cuenta con luminarias de la ciberseguridad que han establecido políticas en los niveles más altos como autores contribuyentes, incluida Jen Easterly, ex directora de la Agencia de Seguridad de Infraestructura y Ciberseguridad, Rob Joyce, ex alto funcionario de ciberseguridad de la Casa Blanca y la NSA, y Chris Inglis, ex director nacional de ciberseguridad.

También incluye a incondicionales del sector privado como Heather Adkins, CISO de Google, Katie Moussouris, directora ejecutiva de Luta Security, y Sounil Yu, director de tecnología de Knostic. Otros setenta CISO, CTO y otros ejecutivos de seguridad son nombrados editores y revisores.

También esta semana, el Instituto de Seguridad de IA (AISI) del Reino Unido detallado los resultados de las pruebas que realizó en una versión preliminar de Claude Mythos, calificándolo de «un paso adelante» con respecto a los modelos Anthropic anteriores en el ámbito de la ciberseguridad y capaz de «ejecutar ataques de múltiples etapas en redes vulnerables y descubrir y explotar vulnerabilidades de forma autónoma».

Utilizando una combinación de ejercicios de Capture the Flag y pruebas de alcance cibernético, los investigadores de AISI descubrieron que Mythos no solo elevó el límite de usuarios técnicos no expertos y de nivel aprendiz, sino que redujo la brecha general en la competencia de piratería entre los dos. En otras palabras, cada vez hay menos distinción entre las capacidades de los “script kiddies” aficionados y los hackers de nivel medio con conocimientos técnicos.

Antes de abril de 2025, ningún modelo de lenguaje grande podía completar un único problema CTF de nivel experto. Mythos resolvió con éxito casi tres cuartas partes (73%) de ellos.

En las pruebas de alcance cibernético, que están destinadas a simular ataques multicadena más complejos, los resultados fueron desiguales, pero también representaron un progreso significativo con respecto a los modelos Claude anteriores.

Mythos fue sometido a un manual de ataque de 32 pasos modelado en redes corporativas, que abarca desde el acceso inicial a la red hasta la toma total de control de la misma. En tres de las 10 simulaciones, el modelo completó un promedio de 24 de los 32 pasos. Las versiones más antiguas de Claude y otros modelos fronterizos nunca promediaron más de 16.

Mythos reprobó su prueba contra una torre de enfriamiento de tecnología operativa simulada, pero los investigadores notaron que esto no significa que la IA sea mala para explotar OT: el modelo en realidad falló durante la sección de TI del ejercicio.

Los investigadores del Reino Unido fueron más mesurados en su análisis de Mythos, señalando que sus pruebas indican que es “al menos capaz” de derribar de forma autónoma redes empresariales más pequeñas y débilmente defendidas.

Pero también señalan que sus rangos cibernéticos carecen de características de seguridad (como defensores activos y herramientas defensivas) que serían comunes en muchas redes del mundo real y presentarían obstáculos adicionales, y tampoco penalizaron al modelo por activar alertas de seguridad.

«Esto significa que no podemos decir con seguridad si Mythos Preview sería capaz de atacar sistemas bien defendidos», concluyeron los investigadores.

Deuda técnica vencida

Tanto el informe de EE.UU. como el del Reino Unido coinciden en que los grandes modelos lingüísticos se están moviendo en términos generales en una dirección similar de reducción de la barrera técnica. Los autores estadounidenses piden que las organizaciones adopten más rápidamente la IA para la ciberdefensa y, al mismo tiempo, revisen sus manuales de respuesta a incidentes y sus políticas corporativas para tener en cuenta posturas de defensa más automatizadas.

Por su parte, Anthropic ha dicho que no venderá Mythos comercialmente y la semana pasada anunció que el modelo estaría disponible para Project Glasswing, un consorcio de importantes empresas tecnológicas que lo utilizarán para erradicar y parchear vulnerabilidades en productos y servicios de uso común.

Pero otros expertos han advertido que las empresas y los gobiernos no están bien posicionados para absorber la afluencia de la explotación de vulnerabilidades esperada ni para aprovechar hábilmente sus propias herramientas de inteligencia artificial para contrarrestarlas.

Casey Ellis, director de tecnología y fundador de Bugcrowd, escribió que los recientes avances en las herramientas cibernéticas de IA han tenido éxito en gran medida porque “viven en lugares donde dejamos de mirar hace una década”.

Si bien la comunidad de ciberseguridad ha pasado años enfocándose en la seguridad de las aplicaciones, la clasificación de vulnerabilidades y otros problemas de seguridad de “capa superior”, las herramientas de inteligencia artificial y los grupos de piratería de nivel superior se han estado alimentando de vulnerabilidades en firmware olvidado o enrutadores cuyos fabricantes cerraron hace mucho tiempo.

Esta realidad de que herramientas como Mythos pueden convertir en un arma la enorme deuda técnica de las grandes organizaciones ha tomado el tradicional dilema del defensor y «la perilla que solía ir a diez y la giró a setecientos», escribió Ellis.

Además, las corporaciones y los gobiernos se basan en la creación de consenso, múltiples niveles de jerarquía y cumplimiento legal. Si bien todo esto es necesario cuando se entrega la ciberseguridad a herramientas automatizadas, también puede conducir a un proceso más lento y a una mayor asimetría contra los defensores en el corto plazo.

«La integración a la producción real se convierte en el campo de batalla», escribió Ellis. «El retraso es real. La burocracia es real. Las cadenas de suministro son reales».

Investigadores de ciberseguridad han levantado el telón sobre una botnet sigilosa diseñada para ataques distribuidos de denegación de servicio (DDoS).

Llamado masjesula botnet se ha anunciado a través de Telegram como un servicio de alquiler de DDoS desde que apareció por primera vez en 2023. Es capaz de apuntar a una amplia gama de dispositivos de IoT, como enrutadores y puertas de enlace, que abarcan múltiples arquitecturas.

«Construido para la persistencia y la baja visibilidad, Masjesu prefiere una ejecución cuidadosa y discreta a una infección generalizada, evitando deliberadamente rangos de IP bloqueados como los que pertenecen al Departamento de Defensa (DoD) para garantizar la supervivencia a largo plazo», dijo el investigador de seguridad de Trellix Mohideen Abdul Khader F. dicho en un informe del martes.

Vale la pena señalar que la oferta comercial también se conoce con el nombre de XorBot debido a su uso de cifrado basado en XOR para ocultar cadenas, configuraciones y datos de carga útil. Fue documentado por primera vez por el proveedor de seguridad chino NSFOCUS en diciembre de 2023, vinculándolo con un operador llamado «synmaestro».

A Se descubrió que la iteración posterior de la botnet observada un año después había agregado 12 exploits diferentes de inyección de comandos y ejecución de código para apuntar a enrutadores, cámaras, DVR y NVR de D-Link, Eir, GPON, Huawei, Intelbras, MVPower, NETGEAR, TP-Link y Vacron, y obtener acceso inicial. También se agregaron nuevos módulos para realizar ataques de inundación DDoS.

«Como familia de botnets emergente, XorBot está mostrando un fuerte impulso de crecimiento, infiltrándose y controlando continuamente nuevos dispositivos de IoT», dijo NSFOCUS en noviembre de 2024. «En particular, estos controladores están cada vez más inclinados a utilizar plataformas de redes sociales como Telegram como canales principales para el reclutamiento y la promoción, atrayendo ‘clientes’ objetivo a través de actividades promocionales activas iniciales, sentando una base sólida para la posterior expansión y desarrollo de la botnet».

Los últimos hallazgos de Trellix muestran que Masjesu ha comercializado la capacidad de llevar a cabo ataques DDoS volumétricos, enfatizando su diversa infraestructura de botnet y su idoneidad para apuntar a redes de entrega de contenido (CDN), servidores de juegos y empresas. Los ataques organizados por la botnet se originan principalmente en Vietnam, Ucrania, Irán, Brasil, Kenia e India, y Vietnam representa casi el 50% del tráfico observado.

Una vez implementado en un dispositivo comprometido, el malware crea y vincula un socket con un puerto TCP codificado (55988) para permitir que el atacante se conecte directamente. Si esta operación falla, la cadena de ataque se elimina inmediatamente.

De lo contrario, el malware procede a configurar la persistencia, ignorar las señales relacionadas con la terminación, detener procesos comúnmente utilizados como wget y curl, posiblemente para interrumpir las botnets competidoras, y luego se conecta a un servidor externo para recibir comandos de ataque DDoS para ejecutarlos contra objetivos de interés.

Masjesu también se jacta de capacidades de autopropagación, lo que le permite sondear direcciones IP aleatorias en busca de puertos abiertos e integrar con éxito los dispositivos comprometidos en su infraestructura. Una adición notable a la lista de objetivos de explotación son los enrutadores Realtek, que se lleva a cabo escaneando en busca de 52869, un puerto asociado con SDK de Realtekminiigd demonio. Múltiples botnets DDoS, como JenX y Satorihan abrazado el mismo enfoque en el pasado.

«La botnet continúa expandiéndose al infectar una amplia gama de dispositivos IoT en múltiples arquitecturas y fabricantes», dijo Trellix. «En particular, Masjesu parece evitar apuntar a organizaciones críticas sensibles que podrían generar una atención legal o policial significativa, una estrategia que probablemente mejora su capacidad de supervivencia a largo plazo».

En la rápida evolución del panorama de amenazas de 2026, ha surgido una paradoja frustrante para los CISO y los líderes de seguridad: Los programas de identidad están madurando, pero el riesgo en realidad está aumentando.

Según una nueva investigación del Instituto Ponemoncientos de aplicaciones dentro de una empresa típica permanecen desconectadas de los sistemas de identidad centralizados. Estas aplicaciones de «materia oscura» operan fuera del alcance de la gobernanza estándar, creando una superficie de ataque masiva y no administrada que ahora está siendo explotada agresivamente, no sólo por actores de amenazas humanas, sino también por agentes autónomos de IA.

La amenaza invisible: aplicaciones desconectadas y amplificación de IA

Las empresas modernas han invertido mucho en IAM y Zero Trust, pero la «última milla» de la identidad (aplicaciones heredadas, cuentas localizadas y SaaS aislado) sigue siendo un punto ciego obstinado.

La entrada de la IA en la fuerza laboral ha convertido esta brecha de un dolor de cabeza en materia de cumplimiento a una vulnerabilidad crítica. A medida que las organizaciones implementan copilotos de IA y agentes autónomos para aumentar la productividad, estos agentes a menudo requieren acceso a los mismos sistemas que se encuentran fuera de su control centralizado.

¿El resultado? Los agentes de IA están amplificando inadvertidamente los riesgos de credenciales, reutilizando tokens obsoletos y navegando por caminos de menor resistencia que su equipo de seguridad ni siquiera puede ver.

Únase a la sesión informativa sobre madurez de identidad 2026

Para ayudar a los líderes de seguridad a superar esta «brecha de confianza», Las noticias de los piratas informáticos es organizar un seminario web exclusivo que presenta Mike Fitzpatrick (Instituto Ponemon) y Matt Chiodi (CSO, Cerby).

Desglosarán los últimos hallazgos de más de 600 líderes de TI y seguridad y proporcionar una hoja de ruta táctica para cerrar las brechas de identidad que conducen a fricciones en las auditorías y al estancamiento de las iniciativas digitales.

En esta sesión descubrirás:

• Datos de referencia exclusivos de 2026: Vea cómo se compara la madurez de su identidad con la de sus pares.
• El factor «IA en la sombra»: Comprenda cómo los agentes de IA están ampliando su superficie desconectada.
• El costo de la gestión manual: Por qué confiar en correcciones manuales de contraseñas y credenciales es una estrategia perdedora en 2026.
• Pasos prácticos de remediación:Descubra exactamente qué están haciendo las organizaciones líderes ahora para recuperar el control de cada aplicación.

Por qué deberías asistir

Si lidera una estrategia de identidad, seguridad o cumplimiento, «hacer más de lo mismo» ya no es una opción. Esta conversación está diseñada para llevarlo más allá de la madurez teórica y hacia control operativo.

Asegura tu lugar ahora para obtener la información basada en datos que necesita para proteger el activo más fragmentado y más específico de su organización: Identidad.

Regístrese para el seminario web: Madurez de la identidad bajo presión →

Se ha observado que actores de amenazas probablemente asociados con la República Popular Democrática de Corea (RPDC) utilizan GitHub como infraestructura de comando y control (C2) en ataques de múltiples etapas dirigidos a organizaciones en Corea del Sur.

La cadena de ataque, por Laboratorios Fortinet FortiGuardinvolucra archivos de acceso directo de Windows (LNK) ofuscados que actúan como punto de partida para colocar un documento PDF señuelo y un script de PowerShell que prepara el escenario para la siguiente fase del ataque. Se considera que estos archivos LNK se distribuyen a través de correos electrónicos de phishing.

Tan pronto como se descargan las cargas útiles, a la víctima se le muestra el documento PDF, mientras que el script malicioso de PowerShell se ejecuta silenciosamente en segundo plano. El script de PowerShell realiza comprobaciones para resistir el análisis mediante la búsqueda de procesos en ejecución relacionados con máquinas virtuales, depuradores y herramientas forenses. Si se detecta alguno de esos procesos, el script finaliza inmediatamente.

De lo contrario, extrae un script de Visual Basic (VBScript) y configura la persistencia mediante una tarea programada que inicia la carga útil de PowerShell cada 30 minutos en una ventana oculta para evitar la detección. Esto garantiza que el script de PowerShell se ejecute automáticamente después de cada reinicio del sistema.

Luego, el script de PowerShell perfila el host comprometido, guarda el resultado en un archivo de registro y lo extrae a un repositorio de GitHub creado bajo la cuenta «motoralis» utilizando un token de acceso codificado. Algunas de las cuentas de GitHub creadas como parte de la campaña incluyen «God0808RAMA», «Pigresy80», «entire73», «pandora0009» y «brandonleeodd93-blip».

Luego, el script analiza un archivo específico en el mismo repositorio de GitHub para obtener módulos o instrucciones adicionales, lo que permite al operador utilizar como arma la confianza asociada con una plataforma como GitHub para integrarse y mantener un control persistente sobre el host infectado.

Fortinet dijo que las versiones anteriores de la campaña se basaban en archivos LNK para difundir familias de malware como Xeno RAT. Vale la pena señalar que el uso de GitHub C2 para distribuir Xeno RAT y su variante MoonPeak fue documentado por ENKI y Trellix el año pasado. Estos ataques fueron atribuidos a un grupo patrocinado por el Estado norcoreano conocido como Kimsuky.

«En lugar de depender de un complejo malware personalizado, el actor de amenazas utiliza herramientas nativas de Windows para su implementación, evasión y persistencia», dijo la investigadora de seguridad Cara Lin. «Al minimizar el uso de archivos PE caídos y aprovechar LolBins, el atacante puede apuntar a una audiencia amplia con una tasa de detección baja».

La divulgación llega como AhnLab detallado una cadena de infección similar basada en LNK de Kimsuky que, en última instancia, resulta en la implementación de una puerta trasera basada en Python.

Los archivos LNK, como antes, ejecutan un script de PowerShell y crean una carpeta oculta en la ruta «C:\windirr» para organizar las cargas útiles, incluido un PDF señuelo y otro archivo LNK que imita un documento de procesador de textos Hangul (HWP). También se implementan cargas útiles intermedias para configurar la persistencia e iniciar un script de PowerShell, que luego usa Dropbox como canal C2 para recuperar un script por lotes.

Luego, el archivo por lotes descarga dos fragmentos de archivos ZIP separados desde un servidor remoto («quickcon[.]store») y los combina para crear un único archivo y extrae de él un programador de tareas XML y una puerta trasera de Python. El programador de tareas se utiliza para iniciar el implante.

El malware basado en Python admite la capacidad de descargar cargas útiles adicionales y ejecutar comandos emitidos desde el servidor C2. Las instrucciones le permiten ejecutar scripts de shell, enumerar directorios, cargar/descargar/eliminar archivos y ejecutar archivos BAT, VBScript y EXE.

Los hallazgos también coinciden con el cambio de ScarCruft de las tradicionales cadenas de ataque basadas en LNK a un dropper basado en HWP OLE para entregar RokRAT, un troyano de acceso remoto utilizado exclusivamente por el grupo de hackers norcoreano, según S2W. Específicamente, el malware está incrustado como un objeto OLE dentro de un documento HWP y se ejecuta mediante carga lateral de DLL.

«A diferencia de cadenas de ataques anteriores que progresaron desde scripts BAT lanzados por LNK hasta shellcode, este caso confirma el uso de malware dropper y downloader recientemente desarrollado para entregar shellcode y la carga útil ROKRAT», dijo la compañía de seguridad de Corea del Sur. dicho.

Su superficie de ataque ya no reside en un sistema operativo, ni tampoco las campañas dirigidas a él. En entornos empresariales, los atacantes se mueven a través de terminales Windows, MacBooks ejecutivas, infraestructura Linux y dispositivos móviles, aprovechando el hecho de que muchos flujos de trabajo SOC todavía están fragmentados por plataforma.

Para los líderes de seguridad, esto crea una costosa brecha operativa: validación más lenta, visibilidad limitada en las primeras etapas, más escalaciones y más tiempo para que los atacantes roben credenciales, establezcan persistencia o profundicen antes de que comience completamente la respuesta.

El problema de los ataques a múltiples sistemas operativos para el que los SOC no están preparados

Un ataque a varios sistemas operativos puede convertir una amenaza en varias investigaciones diferentes a la vez. La campaña puede seguir un camino diferente según el sistema al que llegue, lo que rompe la velocidad y la coherencia de la que dependen los equipos SOC durante la clasificación inicial.

En lugar de pasar por un proceso de validación claro, el equipo termina saltando entre herramientas, reconstruyendo el comportamiento en todos los entornos e intentando ponerse al día mientras el ataque continúa.

Esto conduce rápidamente a problemas familiares dentro del SOC:

• Los retrasos en la validación aumentan la exposición empresarial ralentizando el momento en que el equipo puede confirmar el riesgo y contenerlo.
• La evidencia fragmentada reduce la claridad del incidente cuando se necesitan decisiones rápidas sobre el alcance, la prioridad y el impacto.
• El volumen de escalada crece porque muchos casos no pueden cerrarse con confianza en la etapa más temprana.
• La coherencia de la respuesta se rompe entre equipos y entornos, lo que dificulta la gestión de las investigaciones a escala.
• Los atacantes tienen más tiempo para moverse antes de que la organización tenga una idea clara de lo que está sucediendo.
• La eficiencia del SOC cae a medida que se pierde tiempo en el cambio de herramientas, la duplicación de esfuerzos y una toma de decisiones más lenta.

Cómo los principales SOC convierten la complejidad de múltiples sistemas operativos en una respuesta más rápida

Los equipos que manejan bien esto generalmente hacen una cosa diferente: hacen que la investigación multiplataforma sea más rápida, clara y consistente desde el principio. Con soluciones como Caja de arena ANY.RUNeso resulta mucho más fácil de hacer en todos los sistemas operativos empresariales.

Aquí hay tres pasos prácticos para lograrlo:

Paso 1: hacer que el análisis multiplataforma forme parte de la clasificación temprana

La clasificación temprana se vuelve más lenta en el momento en que los equipos asumen que la misma amenaza se comportará de la misma manera en todas partes. A menudo no es así. Un archivo, script o enlace sospechoso que revele un patrón en Windows puede tomar una ruta diferente en macOS, depender de diferentes componentes nativos y crear un nivel de riesgo diferente. Eso hace que la validación multiplataforma sea esencial desde el principio.

Por ejemplo, macOS suele considerarse el lado más seguro del entorno empresarial, lo que puede convertirlo en un un lugar más fácil para que las amenazas pasen desapercibidas tempranamente. A medida que crece la adopción entre ejecutivos, desarrolladores y otros usuarios de alto valor, los atacantes tienen más motivos para adaptar campañas a ese entorno.

Los expertos de ANY.RUN analizaron una campaña reciente de ClickFix que es un buen ejemplo. Consulte su cadena de ataque completa a continuación:

Vea el reciente ataque dirigido a los usuarios de Claude Code.

Los atacantes aprovecharon una redirección de anuncios de Google para atraer a las víctimas a una página de documentación falsa de Claude Code y luego utilizaron un flujo ClickFix para enviar un comando de Terminal malicioso. Ese comando descargó un script codificado, instaló AMOS Stealer, recopiló datos del navegador, credenciales, contenidos del llavero y archivos confidenciales, y luego implementó una puerta trasera para acceso persistente.

Cuando el análisis multiplataforma comienza temprano, los equipos pueden:

• Reconocer cómo cambia una campaña en todos los sistemas operativos antes de que la investigación se divida
• Validar actividad sospechosa anterior en el entorno que realmente está siendo atacada
• Reducir la posibilidad de pasar por alto el comportamiento específico de la plataforma durante la clasificación temprana

Paso 2: Mantenga las investigaciones multiplataforma en un solo flujo de trabajo

Los ataques a múltiples sistemas operativos se vuelven más difíciles de contener cuando un caso obliga al equipo a realizar varios flujos de trabajo desconectados. Un vínculo sospechoso en un sistema, un script en otro y una ruta de ejecución diferente en otro lugar pueden convertir rápidamente un solo incidente en una investigación desordenada que se extiende a través de múltiples herramientas. Eso ralentiza la validación, hace que la evidencia sea más difícil de seguir y crea más espacio para que la amenaza siga moviéndose.

Las campañas de ClickFix, por ejemplo, muestran por qué esto es importante. Se ha utilizado la misma técnica para apuntar a diferentes sistemas operativos, desde Windows hasta macOS, siguiendo diferentes rutas de ejecución según el entorno.

Si cada versión tiene que analizarse en una herramienta separada, la investigación lleva más tiempo, requiere más esfuerzo y resulta mucho más difícil mantener la coherencia. ConCaja de arena ANY.RUNlos equipos pueden investigar estas amenazas dentro de un único flujo de trabajo en los principales sistemas operativos empresariales, lo que facilita comparar comportamientos, seguir la cadena de ataque y comprender cómo cambia la campaña de un entorno a otro sin cambiar constantemente de contexto.

Cuando las investigaciones permanecen en un flujo de trabajo, los equipos:

• Reducir los gastos operativos que las investigaciones multi-OS crean
• Mantener una vista conectada de la actividad de campaña en lugar de gestionar fragmentos de casos separados
• Apoyar un respuesta más estandarizada proceso a medida que el alcance del ataque se expande por toda la empresa

Paso 3: Convierta la visibilidad multiplataforma en una respuesta más rápida

Ver la actividad en los sistemas operativos solo ayuda si el equipo puede comprender rápidamente lo que importa y actuar en consecuencia. En los ataques a varios sistemas operativos, suele ser ahí donde la respuesta comienza a ralentizarse. Un comportamiento aparece en un entorno, otros artefactos aparecen en otro lugar y el equipo debe intentar reconstruir todo antes de poder tomar una decisión segura.

Lo que ayuda es tener la información correcta presentada de una manera que sea más fácil de procesar bajo presión. Con ANY.RUN Sandbox, los equipos pueden revisar informes generados automáticamente, seguir el comportamiento de los atacantes, examinar los IOC en pestañas dedicadas y utilizar el Asistente de IA integrado para acelerar el análisis y comprender la actividad sospechosa más rápidamente.

Eso hace que sea más fácil pasar de la actividad en bruto a una visión más clara de lo que está haciendo la amenaza, su gravedad y lo que debe suceder a continuación.

Cuando es más fácil trabajar con la visibilidad multiplataforma, los equipos pueden:

• Hacer decisiones más rápidas con evidencia que sea más fácil de revisar y actuar
• Reducir retrasos causado por hallazgos dispersos y reconstrucción manual
• Pasar a la contención con más confianza incluso cuando el ataque se comporta de manera diferente en distintos entornos

Deje de dar espacio para que se muevan los ataques contra múltiples sistemas operativos

Los ataques con múltiples sistemas operativos ganan cuando los defensores pierden tiempo. Cada flujo de trabajo adicional, cada validación retrasada y cada fragmento de contexto faltante le da a la amenaza más espacio para propagarse antes de que el equipo pueda contenerla.

Con La zona de pruebas basada en la nube de ANY.RUNlos equipos pueden reducir ese retraso integrando el análisis multiplataforma en un flujo de trabajo más consistente en los principales sistemas operativos empresariales. Esto brinda a los equipos de SOC un contexto más claro, decisiones más rápidas y ganancias operativas mensurables:

• Eficiencia SOC hasta 3 veces mayor en todos los flujos de trabajo de investigación
• 21 minutos menos MTTR por caso cuando las amenazas se validan más rápido
• El 94% de los usuarios reportan una clasificación más rápida en las operaciones diarias
• Hasta un 20% menos de carga de trabajo de Nivel 1 de un esfuerzo manual reducido
• 30% menos escalaciones del Nivel 1 al Nivel 2 durante el análisis inicial
• Menor exposición a infracciones mediante una detección y respuesta más tempranas
• Menos fatiga de alerta con acceso más rápido a información sobre amenazas

Ampliar la visibilidad multiplataforma para reducir los retrasos en la investigación, limitar la exposición empresarial y darle a su SOC más control sobre las amenazas a múltiples sistemas operativos.

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.

Desenmascarar a los impostores es algo que el mundo del arte ha enfrentado durante décadas, y hay lecciones valiosas de las obras de Elmyr de Hory que pueden aplicarse al mundo de la ciberseguridad defensiva. Durante la década de 1960, De Hory ganó fama como falsificador de primer nivel, haciendo pasar obras maestras falsificadas de Picasso, Matisse y Renoir a coleccionistas desprevenidos y museos de renombre. Durante las siguientes décadas, más de mil de sus obras pasaron desapercibidas para los expertos que confiaban en firmas confiables, patrones familiares y procedencia acreditada.

No es diferente a los desafíos que enfrentan los SOC ahora. Estamos firmemente en la Era de la Imitación. Los ciberatacantes, equipados con inteligencia artificial, están dominando el arte de imitar lo familiar, haciéndose pasar por usuarios confiables y enmascarando su actividad dentro de procesos legítimos y tráfico de red ordinario. Como muestra la historia, a menudo es más fácil identificar a los impostores cuando sabes qué buscar.

Conclusiones clave para los defensores:

• El mimetismo es la nueva normalidad: El 81% de los ataques están libres de malware
• La IA agente ayuda a los atacantes a esconderse de manera más efectiva dentro del tráfico y comportamientos inocentes de la red.
• La defensa por capas ahora requiere más capas para extender la protección a través de las cadenas de suministro de software y las identidades federadas.
• NDR mejora la visibilidad para detectar y neutralizar «falsificaciones»

El auge del mimetismo en los ataques modernos

Así como De Hory reutilizó lienzos y pigmentos viejos para hacer que sus pinturas parecieran más auténticas, los atacantes emplean métodos similares en el ámbito digital, aprovechando herramientas y credenciales confiables para mezclar su actividad maliciosa. Y si bien las técnicas basadas en la imitación han sido durante mucho tiempo un elemento básico del manual del atacante, en los últimos años se han vuelto más sofisticadas. Los ataques Living-off-the-Land (LotL) y las herramientas de ataque mejoradas con IA han elevado el listón de la falsificación. Informe de amenazas globales 2026 de CrowdStrike afirma que el 81% de los ataques ahora están libres de malware y se basan en herramientas y técnicas legítimas, que es el sello distintivo de las tácticas de LotL. Detectar estas falsificaciones rápidamente no es sólo una opción: es una de las mejores posibilidades de interrumpir un ataque antes de que cause un daño real.

Una guía de campo para la falsificación de redes:

Actores agentes asistidos por IA

Autónomos o semiautónomos, generan identidades falsas, códigos e imitan comportamientos a escala.

de Hory contaba con una compleja red de apoyo para vender sus pinturas, en la que participaban marchantes de arte y otros representantes de muchos países y ciudades. Cuando algunos compradores potenciales empezaron a sospechar, empezó a vender sus obras bajo diversos seudónimos. Esto es similar a lo que está sucediendo ahora con el uso de agentes de IA económicos. Estos no sólo están acostumbrados a forjar identidades creíbles para realizar fraude, pero ahora se utilizan para producir explotar código para filtrar secretos y scripts para infectar puntos finales, formando la base de un ataque a mayor escala. Agentes sofisticados y de autoaprendizaje observan el comportamiento de la red y ajustan continuamente su propio tráfico, reflejando sus patrones para engañar las detecciones de anomalías. Cambian el tráfico C2 en ráfagas que coinciden con picos legítimos y manipulan sus señales lo suficiente para evitar destacarse. Y se están utilizando agentes legítimos como orquestadores de otras herramientas de explotación para automatizar y ampliar los ataques.

Impostores de la cadena de suministro y la nube

Componentes falsificados o comprometidos que se hacen pasar por software, actualizaciones o servicios en la nube confiables.

Los atacantes utilizan agentes de inteligencia artificial maliciosos para crear una capa de complejidad para las cadenas de suministro de software. Los agentes sustituyen software malicioso y disfrazan este código como otra actualización benigna, lo que hace que los orígenes del exploit y las causas fundamentales sean más difíciles de descubrir. Este tipo de exploits significa que los atacantes no necesitan engañar directamente a los defensores de la red o a los desarrolladores de software. esto es lo que Investigadores de Microsoft encontraron el gusano Shai Hulud v2. Los atacantes modificaron cientos de paquetes de software para proporcionar un ecosistema coordinado para recolectar credenciales de desarrollador y secretos de API, luego aumentaron su potencia propagándose a través de recursos compartidos de red internos confiables, todo mientras se hacían pasar por actualizaciones de software legítimas. Si bien los ataques a la cadena de suministro existen desde hace muchos años (piense en SolarWinds), los agentes de inteligencia artificial han hecho que su producción y distribución sean más rápidas.

El engaño basado en la nube también se ha acelerado. Durante años, los atacantes han utilizado páginas de inicio de sesión falsas y repositorios en la nube falsificados que imitan el diseño y la marca de servicios legítimos para engañar a los usuarios para que entreguen sus credenciales. Las herramientas impulsadas por IA tienen el potencial de intensificar la creación de estas falsificaciones convincentes, permitiendo a los atacantes generar sitios fraudulentos más rápidamente y a mayor escala.

Túneles encubiertos

Técnicas que ocultan el tráfico malicioso dentro de protocolos permitidos o canales cifrados

de Hory amplió su red utilizando galerías y otros representantes para enmascarar sus transacciones y vender sus falsificaciones. Los atacantes actuales hacen algo similar: ocultan sus conversaciones de red mediante túneles IP para ocultar la actividad maliciosa dentro del tráfico que parece legítimo. Otro mecanismo de encubrimiento utiliza solicitudes y respuestas intencionalmente no coincidentes, como solicitar datos web confidenciales desde un destino previamente desconocido para evadir la detección. Los atacantes también utilizan estos métodos para desactivar las protecciones de seguridad y luego permanecen inactivos dentro de una red corporativa durante meses, esperando el momento adecuado para atacar. A estos métodos se suman las tiendas de aplicaciones móviles, que han estado plagadas durante años de aplicaciones falsas que contienen malware, como este ejemplo más reciente de un herramienta de búsqueda visual que oculta un exploit de ejecución remota.

Infraestructura fraudulenta

Servidores, dominios o servicios controlados por atacantes diseñados para imitar infraestructura legítima.

De Hory evadió la detección moviéndose con frecuencia, de ciudad en ciudad, alrededor del mundo. Los ciberatacantes emplean una estrategia similar: ponen bajo su control servidores, dominios y servicios similares que se hacen pasar por una infraestructura confiable. Reciente investigación de microsoft muestra actores de amenazas que atraen a los usuarios con mensajes falsos de reuniones de Teams que condujeron a sitios de recolección de credenciales disfrazados de páginas de inicio de sesión legítimas. Conexiones falsas como esta pueden ser precursoras de una serie de movimientos para tomar el control de los recursos y datos de su red. Luego se pueden emplear servidores falsos para comprometer y extraer datos confidenciales, y luego aprovechar la información para lanzar una campaña de ransomware.

Finalmente, el phishing

Y la falsificación es el núcleo de cualquier campaña de phishing. Las campañas actuales utilizan todo tipo de falsificaciones, incluido el uso de direcciones de correo electrónico falsas que parecen ser parte de su dominio pero que son parte de ataques de homoglifos u homógrafos. Estos ataques pueden falsificar dominios legítimos con caracteres sustitutos similares para redirigir conversaciones bajo el control de un pirata informático o usarse como parte de campañas de phishing posteriores. De Hory estaría encantado, ya que se esforzó mucho en copiar las pinceladas, las opciones de color y los estilos de los maestros en sus falsificaciones.

Cómo NDR puede exponer las falsificaciones

Los paralelismos entre las falsificaciones de De Hory y los ciberataques modernos son sorprendentes. Ambos se basan en el mimetismo, el movimiento y la explotación de sistemas confiables. De Hory finalmente quedó expuesto cuando los expertos compararon múltiples obras y detectaron las huellas estilísticas que no podía ocultar. La detección y respuesta de red (NDR) puede detectar a los atacantes de la misma manera, al observar patrones de comportamiento y anomalías que delatan lo que realmente está sucediendo en la red.

Estas son algunas de las formas en que NDR ayuda a exponer actividades maliciosas ocultas a simple vista:

• Detección de anomalías de comportamiento: Identificar desviaciones de las líneas de base de red establecidas, como tiempos de inicio de sesión inusuales, transferencias de datos atípicas o movimientos laterales inesperados que pueden indicar que un impostor está trabajando, incluso cuando las credenciales parecen legítimas.
• Revelar inconsistencias de protocolo y metadatos: Detectar discrepancias que los atacantes no pueden ocultar fácilmente, como combinaciones extrañas de protocolos, tráfico a dominios homógrafos o recién registrados, o sesiones cifradas con detalles de certificados sospechosos.
• Proporcionar contexto: Enriquecer el tráfico sin procesar con metadatos que expliquen el panorama más amplio, como dónde se originan las conexiones, cómo se comportan a lo largo del tiempo y si se ajustan a patrones normales, para que los analistas puedan separar rápidamente las amenazas reales del ruido, como este ejemplo, que muestra cómo un analista de SOC puede probar varias hipótesis para descubrir un ataque.

A medida que los atacantes se vuelven más sofisticados y aprovechan la IA para ampliar su engaño, los defensores necesitan herramientas que puedan ver a través del ruido. NDR, en colaboración con otros productos de seguridad, brinda a los SOC la visibilidad necesaria para detectar estas amenazas de manera temprana, antes de que causen daños reales.

Plataforma NDR abierta de Corelight permite a los SOC detectar amenazas emergentes, incluidas aquellas que aprovechan las técnicas de IA. Su enfoque de detección de múltiples capas incluye detecciones de comportamiento y anomalías que pueden identificar una variedad de actividades de red únicas e inusuales. A medida que los adversarios desarrollan nuevos métodos de ataque, los equipos de seguridad que implementan NDR pueden fortalecer el juego defensivo de su empresa. Visita corelight.com/elitedefense para aprender más.

Los equipos de seguridad han pasado años creando controles de identidad y acceso para usuarios humanos y cuentas de servicio. Pero una nueva categoría de actor ha entrado silenciosamente en la mayoría de los entornos empresariales y opera completamente fuera de esos controles.

Claude Code, el agente de codificación de IA de Anthropic, ahora se ejecuta en organizaciones de ingeniería a escala. Lee archivos, ejecuta comandos de shell, llama a API externas y se conecta a integraciones de terceros llamadas servidores MCP. Hace todo esto de forma autónoma, con todos los permisos del desarrollador que lo lanzó, en la máquina local del desarrollador, antes de que cualquier herramienta de seguridad de capa de red pueda verlo. No deja ningún rastro de auditoría para cuya captura se construyó la infraestructura de seguridad existente.

Este tutorial cubre Ceros, una capa de confianza de IA creada por Más allá de la identidad que se encuentra directamente en la máquina del desarrollador junto con Claude Code y proporciona visibilidad en tiempo real, aplicación de políticas en tiempo de ejecución y un seguimiento de auditoría criptográfica de cada acción que realiza el agente.

El problema: Claude Code opera fuera de los controles de seguridad existentes

Antes de analizar el producto, es útil comprender por qué las herramientas existentes no pueden abordar este problema.

La mayoría de las herramientas de seguridad empresarial se encuentran en el borde de la red o en la puerta de enlace API. Estas herramientas ven el tráfico después de que sale de la máquina. Para cuando un SIEM ingiere un evento o un monitor de red señala tráfico inusual, Claude Code ya ha actuado: el archivo ya ha sido leído, el comando de shell ya se ha ejecutado y los datos ya se han movido.

El perfil de comportamiento de Claude Code agrava significativamente este problema. Vive de la tierra, utilizando herramientas y permisos que ya están en la máquina del desarrollador en lugar de traer los suyos propios. Se comunica a través de llamadas de modelos externos que parecen tráfico normal. Ejecuta secuencias complejas de acciones que ningún ser humano programó explícitamente. Y se ejecuta con todos los permisos heredados de quien lo lanzó, incluido el acceso a credenciales, sistemas de producción y datos confidenciales que los desarrolladores tienen en sus máquinas.

El resultado es una brecha que las herramientas de la capa de red estructuralmente no pueden cerrar: todo lo que Claude Code hace en la máquina local, antes de que cualquier solicitud abandone el dispositivo. Ahí es donde opera Ceros.

Primeros pasos: dos comandos, treinta segundos

Ceros está diseñado para que la instalación no interrumpa el flujo de trabajo del desarrollador. La configuración requiere dos comandos:

curl -fsSL https://agent.beyondidentity.com/install.sh | bash

ceros claude

El primer comando instala la CLI. El segundo lanza Claude Code a través de Ceros. Se abre una ventana del navegador, solicita una dirección de correo electrónico y envía un código de verificación de seis dígitos. Después de ingresar el código, Claude Code se inicia y funciona exactamente como antes. Desde la perspectiva del desarrollador, nada ha cambiado.

Para implementaciones en toda la organización, los administradores pueden configurar Ceros para que se solicite a los desarrolladores que se inscriban automáticamente cuando inicien Claude Code. La seguridad se vuelve invisible para el desarrollador, que es la única forma en que la seguridad se adopta a escala.

Una vez inscrito, antes de que Claude Code genere un único token, Ceros captura el contexto completo del dispositivo, incluido el sistema operativo, la versión del kernel, el estado de cifrado del disco, el estado de arranque seguro y el estado de protección del endpoint, todo en menos de 250 milisegundos. Captura la ascendencia completa del proceso de cómo se invocó Claude Code, con hashes binarios de cada ejecutable en la cadena. Y vincula la sesión a una identidad humana verificada a través de la plataforma de Beyond Identity, firmada con una clave criptográfica vinculada al hardware.

La consola: vea lo que Claude Code ha estado haciendo realmente

Después de registrar un dispositivo y ejecutar Claude Code normalmente durante unos días, navegar a la consola de administración de Ceros revela algo que la mayoría de los equipos de seguridad nunca antes habían visto: un registro completo de lo que Claude Code ha estado haciendo realmente en su entorno.

La vista de conversaciones muestra cada sesión entre un desarrollador y Claude Code en todos los dispositivos registrados, enumerados por usuario, dispositivo y marca de tiempo. Al hacer clic en cualquier conversación se muestra el intercambio completo entre el desarrollador y el agente. Pero entre las indicaciones y las respuestas, algo más es visible: llamadas a herramientas.

Cuando un desarrollador le pregunta a Claude Code algo tan simple como «¿qué archivos hay en mi directorio?», el LLM no simplemente sabe la respuesta. Le indica al agente que ejecute una herramienta en la máquina local, en este caso bash ls -la. Ese comando de shell se ejecuta en el dispositivo del desarrollador con los permisos del desarrollador. Una pregunta casual desencadena una ejecución real en una máquina real.

La vista Conversaciones muestra cada una de estas invocaciones de herramientas en cada sesión. Para la mayoría de los equipos de seguridad, esta es la primera vez que ven estos datos.

La vista Herramientas tiene dos pestañas. La pestaña Definiciones muestra todas las herramientas disponibles para Claude Code en el entorno inscrito, incluidas herramientas integradas como Bash, ReadFile, WriteFile, Edit y SearchWeb, así como todos los servidores MCP que los desarrolladores han conectado a sus agentes. Cada entrada incluye el esquema completo de la herramienta: las instrucciones dadas al LLM sobre lo que hace la herramienta y cómo invocarla.

La pestaña Llamadas muestra lo que realmente se ejecutó. No sólo lo que existe, sino lo que se invocó, con qué argumentos y lo que se devolvió. Los equipos de seguridad pueden profundizar en cualquier llamada de herramienta individual y ver el comando exacto que se ejecutó, los argumentos pasados ​​y el resultado completo que se obtuvo.

La vista del servidor MCP Es donde muchos equipos de seguridad tienen su momento de descubrimiento más significativo. Los servidores MCP son la forma en que Claude Code se conecta a herramientas y servicios externos, incluidas bases de datos, Slack, correo electrónico, API internas e infraestructura de producción. Los desarrolladores los agregan de manera casual, pensando en la productividad más que en la seguridad. Cada uno es una ruta de acceso a datos que nadie revisó.

El panel de Ceros muestra cada servidor MCP conectado a Claude Code en todos los dispositivos registrados, cuándo se vio por primera vez, en qué dispositivos aparece y si ha sido aprobado. Para la mayoría de las organizaciones, la brecha entre lo que los equipos de seguridad asumieron que estaba conectado y lo que realmente está conectado es significativa.

Políticas: Aplicación de controles en el código Claude en tiempo de ejecución

La visibilidad sin gobernanza pone de manifiesto el riesgo, pero no lo previene. La sección de Políticas es donde Ceros pasa de la observabilidad a la aplicación, y donde la historia del cumplimiento se vuelve concreta.

Políticas en Ceros se evalúan en tiempo de ejecución, antes de que se ejecute la acción. Esta distinción es importante para el cumplimiento: el control opera en el momento de la acción, no reconstruido después del hecho.

Lista de permitidos del servidor MCP es la política de mayor impacto que la mayoría de las organizaciones escriben primero. Los administradores definen una lista de servidores MCP aprobados y configuran el valor predeterminado para bloquear todo lo demás. A partir de ese momento, cualquier instancia de Claude Code que intente conectarse a un servidor MCP no aprobado se bloquea antes de que se establezca la conexión y el intento se registra.

Políticas a nivel de herramienta Permitir a los administradores controlar qué herramientas Claude Code puede invocar y bajo qué condiciones. Una política puede bloquear completamente la herramienta Bash para equipos que no necesitan acceso de shell por parte de sus agentes. Puede permitir lecturas de archivos dentro del directorio del proyecto mientras bloquea lecturas en rutas confidenciales como ~/.ssh/ o /etc/. El motor de políticas evalúa no sólo qué herramienta se está utilizando sino también qué argumentos se están pasando, lo cual es la diferencia entre una política útil y un teatro de políticas.

Requisitos de postura del dispositivo sesiones de Gate Claude Code sobre el estado de seguridad de la máquina. Una política puede requerir que se habilite el cifrado de disco y que se ejecute la protección de endpoints antes de que se permita iniciar una sesión. Ceros reevalúa continuamente la postura del dispositivo durante toda la sesión, no solo al iniciar sesión. Si la protección de endpoints está deshabilitada mientras Claude Code está activo, Ceros lo ve y actúa en consecuencia según la política.

El registro de actividad: evidencia lista para auditoría

El Registro de actividad es donde Ceros se vuelve directamente relevante para los equipos de cumplimiento. Cada entrada no es simplemente un registro; es una instantánea forense del entorno en el momento exacto en que se invocó el Código Claude.

Una única entrada de registro contiene la postura de seguridad completa del dispositivo en ese momento, la ascendencia completa del proceso que muestra cada proceso en la cadena que invocó Claude Code, firmas binarias de cada ejecutable en esa ascendencia, la identidad del usuario a nivel de sistema operativo vinculada a un humano verificado y cada acción que Claude Code realizó durante la sesión.

Esto es importante para el cumplimiento porque los auditores exigen cada vez más pruebas de que los registros son inmutables. Los archivos de registro estándar que los administradores pueden editar no cumplen este requisito. Ceros firma cada entrada con una clave criptográfica vinculada al hardware antes de salir de la máquina. El registro no se puede modificar después del hecho.

Para los marcos que requieren registros de auditoría a prueba de manipulaciones, incluidos CC8.1 de SOC 2, AU-9 de FedRAMP, requisitos de control de auditoría de HIPAA y Requisito 10 de PCI-DSS v4.0, este es el artefacto de evidencia específico que satisface el control. Cuando un auditor solicita evidencia de monitoreo y controles de acceso a agentes de IA, la respuesta es una exportación desde el panel de Ceros que cubre todo el período de auditoría, firmada criptográficamente, con atribución de usuario y contexto del dispositivo en cada entrada.

Implementación de MCP administrada: estandarización de las herramientas de Claude Code en toda la organización

Para las organizaciones que desean estandarizar las herramientas disponibles para Claude Code en lugar de bloquear únicamente las no aprobadas, Ceros proporciona implementación de MCP administrada desde la consola de administración.

Los administradores pueden enviar servidores MCP aprobados a la instancia de Claude Code de cada desarrollador desde una única interfaz, sin necesidad de ninguna configuración del desarrollador. El servidor MCP aparece automáticamente en el agente del desarrollador en el próximo lanzamiento.

Combinado con la lista de permitidos del servidor MCP, esto crea un modelo de gobierno completo: los administradores definen qué se requiere, qué se permite y qué se bloquea. Los desarrolladores trabajan dentro de ese ámbito sin fricciones.

El panel: postura de riesgo de IA agente en toda la organización

Lo que viene es El tablerouna vista única de la postura de riesgo de la IA en toda su organización inscrita. Mientras que las vistas a nivel de sesión le indican lo que hizo el agente de un desarrollador, el Panel le informa lo que está sucediendo en toda la flota: cuántos dispositivos están aprovisionados, inscritos y ejecutando activamente Claude Code, con señalización automática cuando las brechas de adopción indican que los agentes se están ejecutando fuera de la ruta de inscripción de Ceros y fuera de sus controles. Inscribirse para recibir una notificación cuando se envíe The Dashboard.

Conclusión

La brecha de seguridad que crea Claude Code no está en el borde de la red. Es en la máquina del desarrollador, donde opera el agente antes de que cualquier herramienta de seguridad existente pueda verlo. Ceros cierra esa brecha viviendo donde vive el agente, capturando todo antes de que se ejecute y produciendo evidencia firmada criptográficamente sobre la cual los equipos de seguridad y cumplimiento pueden actuar.

Para los equipos de seguridad cuyas organizaciones han implementado Claude Code y están comenzando a considerar lo que eso significa para su postura y controles de auditoría, el punto de partida es la visibilidad. No se puede gobernar lo que no se puede ver y, hasta ahora, no ha habido ninguna herramienta que pueda mostrar lo que Claude Code estaba haciendo realmente.

Ceros ya está disponible y comenzar es gratis. Los equipos de seguridad pueden registrar un dispositivo y ver la actividad de su Código Claude por primera vez en más allá de la identidad.ai.

Ceros está desarrollado por Beyond Identity, que cumple con SOC 2/FedRAMP y se puede implementar como SaaS en la nube, autohospedado o totalmente aislado en las instalaciones.