Cinco pasos para gestionar herramientas de IA en la sombra sin ralentizar a los empleados – CYBERDEFENSA.MX

Cuando un empleado instala un asistente de escritura con IA, conecta un copiloto de codificación a su IDE o comienza a resumir reuniones con una nueva herramienta de navegador, está haciendo exactamente lo que debería hacer un empleado productivo: encontrar formas más rápidas de trabajar.

Hoy en día, en la mayoría de las organizaciones, los empleados utilizan de tres a cinco herramientas de inteligencia artificial en un día determinado. La mayoría nunca fueron revisadas por TI. Una parte importante se conecta a los datos corporativos a través de tokens OAuth o sesiones de navegador, dándoles acceso a unidades compartidas, correos electrónicos y documentos internos que el empleado nunca tuvo la intención específica de exponer. Los equipos de seguridad a menudo no tienen visibilidad de nada de esto.

Esta es la brecha de la IA en la sombra, y se está ampliando rápidamente. La mayoría de las herramientas de seguridad se crearon para monitorear el correo electrónico y el tráfico de red que fluye a través de la red corporativa. Una herramienta de inteligencia artificial basada en navegador que se conecta a los datos de la empresa a través de una rápida aprobación de inicio de sesión evita esos controles por completo, porque nunca pasa a través de la red corporativa. De acuerdo a Gartnerel 69% de las organizaciones sospecha o ha confirmado que los empleados están utilizando herramientas de IA prohibidas en el trabajo, y solo el 37% cuenta con una política de gobernanza de la IA. El resultado es una desconexión cada vez mayor entre la forma en que trabajan los empleados y lo que pueden ver los equipos de seguridad.

Un programa que canaliza la adopción de la IA hacia un camino seguro, visible y aprobado brinda a los equipos de seguridad la visibilidad que necesitan y a los empleados las herramientas que desean. Los cinco pasos siguientes muestran exactamente cómo construir uno.

Paso 1: cree una imagen completa de lo que se está ejecutando

Un programa de seguridad sólo puede gestionar lo que puede ver. El primer paso es descubrir qué herramientas de IA se utilizan en toda la organización, y la mayoría de los equipos de seguridad encontrarán la respuesta sorprendente.

Tres áreas representan la mayor parte de la actividad de la IA en la sombra.

  • Conexiones OAuth. La mayoría de las herramientas de inteligencia artificial solicitan acceso a Google Workspace o Microsoft 365 a través de OAuth, lo que les otorga permisos de lectura o escritura sobre datos corporativos. Una auditoría trimestral de aplicaciones de terceros conectadas, clasificadas por alcance de permiso, generalmente muestra docenas de herramientas que el equipo de seguridad nunca revisó.
  • Extensiones del navegador. Muchas herramientas de inteligencia artificial se ejecutan como extensiones del navegador y nunca tocan el sistema operativo, por lo que las herramientas tradicionales de administración de terminales las pasan por alto por completo. Una solución de administración de navegador o un agente liviano instalado en los dispositivos de los empleados puede buscar e identificar qué extensiones están activas en toda la organización.
  • Funciones de IA incluidas en herramientas ya aprobadas. Microsoft Copilot, Google Gemini y Salesforce Einstein son ejemplos de capacidades de IA que pueden haberse introducido después de la revisión original del proveedor, a menudo sin una evaluación de seguridad separada.

También vale la pena realizar una sencilla encuesta a los empleados. Una encuesta enmarcada en ayudar a los empleados a trabajar de forma más segura tiende a obtener respuestas sinceras. Muchas herramientas ocultas surgen a través de encuestas que el descubrimiento automatizado pasa por alto por completo.

El objetivo de este paso es un inventario actual y preciso: cada herramienta de IA en uso, quién la usa y a qué datos tiene acceso.

Paso 2: escriba una política que funcione con los empleados

La mayoría de las políticas de uso aceptable de la IA se estancan por la misma razón: brindan a los empleados una lista de herramientas prohibidas sin orientación sobre cuál es la ruta aprobada. Una política diseñada como una guía práctica, que identifique las herramientas aprobadas y proporcione un proceso claro para solicitar otras nuevas, es la base que los empleados necesitan para tomar buenas decisiones.

Una política eficaz de gobernanza de la IA abarca cinco aspectos.

  • Una lista actualizada de herramientas aprobadas y dónde encontrarlas.
  • Reglas claras de clasificación de datos que especifican qué categorías de datos, incluidos registros de clientes, código fuente e información financiera, nunca deben ingresarse en ninguna herramienta de inteligencia artificial.
  • Un estado de exclusión voluntaria de la capacitación de datos verificado para cada herramienta aprobada. Muchas herramientas de IA utilizan aportaciones de la empresa para mejorar sus modelos de forma predeterminada, a menos que la configuración empresarial esté configurada explícitamente de otra manera. La aprobación debe requerir una exclusión voluntaria confirmada de cualquier herramienta que maneje datos confidenciales.
  • Un proceso definido para solicitar nuevas herramientas, con un tiempo de respuesta objetivo.
  • Una explicación en lenguaje sencillo de por qué existen las pautas.

Ese último elemento importa más de lo que parece. Los empleados que entienden por qué las conexiones OAuth conllevan un riesgo de exposición de datos aplican ese razonamiento a cada decisión que toman sobre herramientas. La política se convierte en una forma de educación cuando se incluye el razonamiento.

Paso 3: cree una vía rápida para solicitudes de nuevas herramientas

Shadow AI crece más rápido en organizaciones donde el proceso de aprobación oficial no puede seguir el ritmo de la tasa de lanzamientos de productos de IA. Un empleado que necesita una herramienta hoy y se enfrenta a una revisión de seguridad de seis semanas encontrará una solución en cuestión de días. El objetivo de este paso es eliminar esa fricción.

  • La mayoría de las solicitudes de herramientas de IA no justifican una revisión completa de la adquisición. Para la mayoría de las herramientas de menor riesgo es suficiente un formulario de admisión estructurado con criterios de evaluación definidos.
  • Un formulario de admisión estructurado y un conjunto definido de criterios de evaluación hacen posible tomar decisiones más rápidas. Para herramientas con acceso limitado a datos, muchas organizaciones consideran factible un plazo de entrega más corto una vez que los criterios de evaluación están documentados y aplicados de manera consistente.
  • Los criterios de evaluación deben cubrir el alcance del acceso a los datos, las prácticas de seguridad del proveedor, el estado de exclusión voluntaria de la capacitación en datos, las certificaciones de cumplimiento y si la herramienta ya tiene un equivalente funcional en la lista aprobada.

Los equipos de seguridad que publican abiertamente su lista de herramientas aprobadas y la mantienen actualizada suelen ver una reducción significativa en el uso de la IA en la sombra. Cuando los empleados saben dónde encontrar las herramientas adecuadas, las utilizan.

Paso 4: utilice la supervisión como capa de seguridad compartida

La visibilidad continua del uso de herramientas de IA en una organización sirve a dos grupos simultáneamente.

  • Los equipos de seguridad obtienen la imagen en tiempo real que necesitan para identificar y abordar la exposición antes de que se convierta en un incidente.
  • Los empleados obtienen una forma de protección que a menudo no tienen por sí solos: una señal cuando una herramienta que están utilizando puede estar poniendo en riesgo sus credenciales o los datos de la empresa.

Un enfoque de monitoreo nativo del navegador brinda a los equipos de seguridad visibilidad de la actividad de la IA sin desviar el tráfico web de los empleados ni agregar fricción al trabajo diario. Las señales que captura se alimentan del perfil de riesgo más amplio de cada empleado, junto con los resultados de la simulación de phishing y los datos de finalización de la capacitación en un solo lugar.

Esa visión combinada es importante porque los comportamientos riesgosos se agravan. Un empleado que hace clic en enlaces de phishing, se salta la capacitación y ejecuta herramientas de inteligencia artificial no aprobadas con acceso a datos confidenciales presenta un riesgo mucho mayor de lo que indicaría cualquier comportamiento individual. Ver el panorama completo en un solo lugar ayuda a los equipos de seguridad a centrarse en los empleados que más necesitan atención.

Paso 5: Facilite el buen comportamiento de seguridad

Los programas de seguridad que hacen que la elección segura sea la opción más fácil son los que siguen los empleados. En el contexto de la gobernanza de la IA, hay dos cosas que lo impulsan: el asesoramiento justo a tiempo y la capacitación que explica el razonamiento detrás de las reglas.

El coaching justo a tiempo ofrece un mensaje breve y contextual en el momento en que un empleado intenta utilizar una herramienta no autorizada. Esto es más efectivo que los módulos de capacitación trimestrales, porque la intervención ocurre en el momento de la decisión. Un mensaje bien diseñado le dice al empleado cuál es la preocupación, lo dirige a una alternativa aprobada y tarda menos de treinta segundos en leerse.

La capacitación que explica el razonamiento detrás de las políticas de gobernanza de la IA genera el tipo de juicio que los empleados pueden aplicar en cualquier situación que encuentren, incluidas las herramientas y amenazas que surgen mucho después de la capacitación misma. El panorama de las herramientas de IA está cambiando lo suficientemente rápido como para que ningún programa de capacitación pueda anticipar cada caso específico. Un empleado que comprenda que las conexiones OAuth al Google Workspace corporativo pueden exponer toda la unidad compartida a un proveedor externo aplicará ese conocimiento a herramientas que no existían hace seis meses.

Creación de un programa de seguridad basado en cómo funcionan los equipos

La adopción de la IA es una señal de que los equipos productivos están haciendo bien su trabajo. Las empresas que crean programas prácticos en torno a ese impulso, con caminos claros hacia herramientas aprobadas y visibilidad en tiempo real para los equipos de seguridad, tienden a manejarlo mejor.

Los equipos de seguridad que cierran esa brecha descubren que el uso de la IA en la sombra disminuye orgánicamente con el tiempo. La visibilidad nativa del navegador, los caminos claros hacia las herramientas aprobadas y el asesoramiento justo a tiempo en el momento del riesgo son lo que lo hacen posible. Cuando los empleados tienen acceso a herramientas efectivas y aprobadas y a un camino rápido y transparente para revisar las nuevas, el incentivo para evitar el sistema desaparece en gran medida.

El producto AI Governance de Adaptive Security brinda a los equipos de seguridad visibilidad en tiempo real de cada herramienta de AI y aplicación paralela que se ejecuta en su organización, con políticas automatizadas y capacitación integrada para empleados justo a tiempo. Obtenga más información en adaptivesecurity.com.

¿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.

La vulnerabilidad de Gitea expone imágenes de contenedores privados sin autenticación – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado una falla de seguridad en Gitea, una plataforma autohospedada de código abierto para control de versiones, que permite a atacantes remotos no autenticados extraer imágenes de contenedores privados de las implementaciones de Gitea sin requerir una cuenta, contraseña u otras credenciales.

La vulnerabilidad, rastreada como CVE-2026-27771 (puntuación CVSS: N/A), afecta a todas las versiones de Gitea anteriores a 1.26.2que aborda el tema.

Según Noscope, el defecto de seguridad probablemente afecte a más de 30.000 implementaciones en más de 30 países y no fue detectado durante casi cuatro años. La gran mayoría de las exposiciones se encuentran en China, EE. UU., Alemania, Francia y el Reino Unido. Las organizaciones afectadas abarcan proveedores de atención médica, fabricantes aeroespaciales, infraestructura minorista y proveedores de servicios de Internet.

«En las versiones afectadas, la designación privada en un repositorio de contenedores no brindó la protección que los operadores esperaban razonablemente», Noscope dicho.

Ciberseguridad

«El registro de contenedores de Gitea ha permitido a cualquier persona en Internet, sin cuenta, sin contraseña y sin acceso previo, extraer lo que a primera vista se considerarían imágenes de contenedores privadas de las instancias afectadas como si fueran públicas».

La compañía de seguridad con sede en el Reino Unido también señaló que cualquier bifurcación de Gitea debe tratarse como potencialmente afectada por la vulnerabilidad hasta que haya sido verificada de forma independiente por los respectivos mantenedores. En sus propias pruebas, se confirmó que Forgejo estaba afectado. Actualmente no hay detalles técnicos adicionales disponibles.

Se recomienda a los usuarios de Gitea que actualicen a la versión 1.6.2 para una protección óptima. Si aplicar parches no es una opción inmediata, una solución temporal es establecer [service].REQUIRE_SIGNIN_VIEW=true en la configuración de Gitea. Sin embargo, vale la pena señalar que este enfoque no es ideal si algunos contenedores deben exponerse públicamente intencionalmente.

Hacer que los controladores vulnerables sean explotables sin hardware: la perspectiva BYOVD

1 Introducción Este artículo proporciona un análisis técnico de con cuántos controladores en modo kernel de Windows se puede interactuar desde el modo de usuario sin el hardware para el que fueron desarrollados. Este trabajo fue motivado por la investigación de vulnerabilidades orientadas a los controladores y la necesidad de evaluar la explotabilidad de hallazgos individuales, que frecuentemente afectan el código cuya accesibilidad está controlada por hardware. El

Cuáles son las alertas de SOC más riesgosas que quedan sin respuesta – CYBERDEFENSA.MX

¿Por qué las alertas SOC más riesgosas quedan sin respuesta?

Los equipos de operaciones de seguridad están inundados de alertas. Pero el verdadero problema no siempre es el volumen de alertas; son los puntos ciegos. Las alertas más peligrosas son aquellas que nadie investiga.

Un informe reciente de The Hacker News examinó por qué ciertas categorías de alertas de alto riesgo (WAF, DLP, OT/IoT, inteligencia de la web oscura y señales de la cadena de suministro) no se investigan constantemente en los SOC empresariales. Los hallazgos apuntan a una brecha estructural en la forma en que se brinda la cobertura de seguridad hoy en día: no una falta de herramientas, sino un techo incorporado en cada modelo existente.

Su modelo SOC tiene un límite máximo de cobertura

Los equipos internos del SOC son los primeros en sentir la brecha. Sobrecargados con alertas rutinarias de gran volumen, los analistas rara vez tienen la capacidad o la experiencia especializada para investigar eventos WAF, anomalías DLP o señales de entornos tecnológicos operativos. Estos tipos de alertas requieren un conocimiento profundo y específico del dominio que la mayoría de los equipos SOC simplemente no tienen en su personal.

Los MSSP y MDR enfrentan una versión diferente del mismo problema. Investigar alertas complejas y especializadas requiere mucho tiempo y requiere un contexto empresarial que los proveedores gestionados no tienen. La economía no funciona a su favor, por lo que escalan estas alertas al cliente, el mismo equipo interno que carecía de la capacidad para investigarlas en primer lugar.

Las plataformas de automatización AI SOC han logrado avances significativos en los tipos de alertas comunes, pero la mayoría tiene un límite de cuatro a seis categorías predefinidas. Se basan en una lógica de clasificación estática y prediseñada. Cuando una alerta queda fuera de esa lógica, ya sea una amenaza nueva, una fuente de alerta desconocida o un vector de ataque emergente, la plataforma le quita prioridad o la transmite.

El resultado es un punto ciego en la intersección de todos los modelos SOC existentes: las alertas con mayor probabilidad de resultar en una infracción son precisamente aquellas para las cuales nadie tiene un flujo de trabajo que manejar.

¿Quién ofrece verdadera cobertura?

El 21 de mayo de 2026, Seguridad radiante y la empresa alemana de ciberseguridad Cirosec están organizando un seminario web técnico para abordar esta brecha directamente: «Cobertura de alerta que nadie más puede clasificar».

La sesión examinará las razones estructurales detrás del límite de cobertura, analizará los tipos de alertas específicas que más comúnmente no se investigan y hará una demostración en vivo de cómo la plataforma AI SOC de Radiant las clasifica.

Radiant se basa en una arquitectura fundamentalmente diferente a la de otras plataformas AI SOC. En lugar de depender de manuales prediseñados, su IA genera una lógica de clasificación personalizada sobre la marcha, para cualquier tipo de alerta, incluidas las que la plataforma nunca ha visto antes.

Detalles del seminario web

  • Fecha: 21 de mayo de 2026
  • Tiempo: 15:00 CEST (6:00 a. m. PDT)
  • Formato: Microsoft Teams: sesión técnica e interactiva
  • Anfitrión: Cirosec y Seguridad Radiante
  • Idioma: Inglés

Regístrese aquí para registrarse (haga clic en traducir página para Traductor de inglés en tu navegador)

Nota importante: el webinar será en inglés.

¿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.

Un fallo crítico sin parchear deja al LeRobot con cara abrazada expuesto a RCE no autenticado – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de una falla de seguridad crítica que afecta lerobotla plataforma robótica de código abierto de Hugging Face con casi 24.000 estrellas de GitHubque podría explotarse para lograr la ejecución remota de código.

La vulnerabilidad en cuestión es CVE-2026-25874 (Puntuación CVSS: 9,3), que se ha descrito como un caso de deserialización de datos no confiables derivada del uso del formato pickle inseguro.

«LeRobot contiene una vulnerabilidad de deserialización insegura en el proceso de inferencia asíncrona, donde pickle.loads() se utiliza para deserializar datos recibidos a través de canales gRPC no autenticados sin TLS en el servidor de políticas y los componentes del cliente del robot», según un Aviso de GitHub por el defecto.

«Un atacante no autenticado accesible en la red puede lograr la ejecución de código arbitrario en el servidor o cliente enviando una carga útil de pickle diseñada a través de las llamadas gRPC SendPolicyInstructions, SendObservations o GetActions».

Ciberseguridad

Según Resecurity, el problema es arraigado en el componente PolicyServer de inferencia asíncrona, lo que permite a un atacante no autenticado que pueda alcanzar el puerto de red de PolicyServer enviar una carga útil serializada maliciosa y ejecutar comandos arbitrarios del sistema operativo en la máquina host que ejecuta el servicio.

La empresa de ciberseguridad dijo que la vulnerabilidad es «peligrosa», ya que el servicio está diseñado para sistemas de inferencia de inteligencia artificial, que tienden a ejecutarse con privilegios elevados para acceder a redes internas, conjuntos de datos y costosos recursos informáticos. Si un atacante explotara la falla, podría permitir una amplia gama de acciones, que incluyen:

  • Ejecución remota de código no autenticado
  • Compromiso total del host PolicyServer
  • Robots conectados a impacto
  • Robo de datos confidenciales, como claves API, credenciales SSH y archivos de modelo.
  • Moverse lateralmente a través de la red
  • Servicios fallidos, modelos corruptos u operaciones de sabotaje que generan riesgos para la seguridad física

El investigador de seguridad de VulnCheck Valentin Lobstein, quien descubierto y publicó detalles adicionales de la deficiencia la semana pasada, dijo que había sido validado con éxito contra la versión 0.4.3 de LeRobot. El problema actualmente sigue sin parchear, con una solución. planificado en versión 0.6.0.

Curiosamente, el mismo defecto se detectó de forma independiente. reportado por otro investigador que utiliza el alias en línea «chenpinji» en algún momento de diciembre de 2025. El equipo de LeRobot respondió a principios de enero, reconociendo el riesgo de seguridad y señalando «que parte del código base debe refactorizarse casi por completo ya que su implementación original era más experimental».

Ciberseguridad

«Dicho esto, LeRobot ha sido hasta ahora principalmente una herramienta de investigación y creación de prototipos, por lo que la seguridad de la implementación no ha sido un foco importante hasta ahora», dijo Steven Palma, líder tecnológico del proyecto. «A medida que LeRobot siga siendo adoptado e implementado en producción, comenzaremos a prestar mucha más atención a este tipo de problemas. Afortunadamente, al ser un proyecto de código abierto, la comunidad también puede ayudar informando y solucionando vulnerabilidades».

Los hallazgos exponen una vez más los peligros del uso del formato pickle, ya que allana el camino para ataques de ejecución de código arbitrario simplemente cargando un archivo especialmente diseñado.

«Es difícil exagerar la ironía aquí», señaló Lobstein. «Hugging Face creó Safetensors, un formato de serialización diseñado específicamente porque pickle es peligroso para los datos de ML. Y, sin embargo, su propio marco robótico deserializa la entrada de red controlada por el atacante con pickle.loads(), con # comentarios de nosec para silenciar la herramienta que intentaba advertirles».

Tres Microsoft Defender Zero-Days explotados activamente; Dos aún sin parchear – CYBERDEFENSA.MX

La cazadora es advertencia que los actores de amenazas están explotando tres fallas de seguridad recientemente reveladas en Microsoft Defender para obtener privilegios elevados en sistemas comprometidos.

La actividad implica la explotación de tres vulnerabilidades que tienen el nombre en código Martillo azul (requiere iniciar sesión en GitHub), rojosoly Desdefendertodos los cuales fueron publicados como días cero por un investigador conocido como Chaotic Eclipse (también conocido como Nightmare-Eclipse) en respuesta al manejo por parte de Microsoft del proceso de divulgación de vulnerabilidades.

Si bien tanto BlueHammer como RedSun son fallas de escalada de privilegios locales (LPE) que afectan a Microsoft Defender, UnDefend se puede utilizar para desencadenar una condición de denegación de servicio (DoS) y bloquear eficazmente las actualizaciones de definiciones.

Ciberseguridad

Microsoft tomó medidas para abordar BlueHammer como parte de sus actualizaciones del martes de parches lanzadas a principios de esta semana. La vulnerabilidad se rastrea con el identificador CVE CVE-2026-33825. Sin embargo, las otras fallas no tienen solución al momento de escribir este artículo.

En una serie de publicaciones compartidas en X, Huntress dijo que observó que las tres fallas se explotaban en la naturaleza, con BlueHammer siendo utilizado como arma desde el 10 de abril de 2026, seguido del uso de RedSun y UnDefend prueba de concepto (PoC) el 16 de abril.

«Estas invocaciones siguieron a los típicos comandos de enumeración: whoami /priv, cmdkey /list, net group y otros que indican la actividad práctica del actor de amenazas en el teclado», añadió.

El proveedor de ciberseguridad dijo que ha tomado medidas para aislar a la organización afectada para evitar una mayor explotación posterior. The Hacker News se comunicó con Microsoft para hacer comentarios y actualizaremos la historia si recibimos una respuesta.

Fallo ShowDoc RCE CVE-2025-0520 explotado activamente en servidores sin parches – CYBERDEFENSA.MX

Una vulnerabilidad de seguridad crítica que afecta MostrarDocun servicio de colaboración y gestión de documentos popular en China, ha sido objeto de explotación activa en la naturaleza.

La vulnerabilidad en cuestión es CVE-2025-0520 (también conocido como CNVD-2020-26585), que tiene una puntuación CVSS de 9,4 sobre 10,0.

Se relaciona con un caso de carga de archivos sin restricciones que surge de una validación inadecuada de la extensión del archivo, lo que permite a un atacante cargar archivos PHP arbitrarios y lograr la ejecución remota de código.

«[In] Versión de ShowDoc anterior a 2.8.7, se encuentra un problema de carga de archivos sin restricciones y sin autenticación y [an] El atacante puede cargar un shell web y ejecutar código arbitrario en el servidor», según un aviso. liberado por Vulhub.

Ciberseguridad

La vulnerabilidad fue abordada en ShowDoc versión 2.8.7que se envió en octubre de 2020. La versión actual del software es 3.8.1.

De acuerdo a nuevos detalles compartido por Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck, CVE-2025-0520 ha sido objeto de explotación activa por primera vez.

El exploit observado implica aprovechar la falla para colocar un shell web en un honeypot con sede en EE. UU. que ejecuta una versión vulnerable de ShowDoc. Los datos compartidos por la empresa muestran que hay más de 2.000 instancias de ShowDoc en línea, la mayoría de las cuales están ubicadas en China.

El desarrollo es el último ejemplo de cómo los actores de amenazas están explotando cada vez más las vulnerabilidades de seguridad del día N, independientemente de su base de instalación. Se recomienda a los usuarios que ejecutan ShowDoc que actualicen a la última versión para una protección óptima.

'GrafanaGhost' supera las defensas de la IA de Grafana sin dejar rastro

Los investigadores de seguridad de Noma Security han revelado una nueva vulnerabilidad a la que llaman GrafanaGhost, un exploit capaz de robar silenciosamente datos confidenciales de entornos Grafana encadenando múltiples desvíos de seguridad, incluido un método que elude las barreras del modelo de IA de la plataforma sin requerir ninguna interacción del usuario.

Grafana se implementa ampliamente en organizaciones empresariales como un centro central para la observabilidad y el monitoreo de datos, y generalmente alberga métricas financieras en tiempo real, datos sobre el estado de la infraestructura, registros privados de clientes y telemetría operativa, entre otros usos. Esa concentración de información confidencial es lo que convierte a la plataforma en un objetivo importante. GrafanaGhost aprovecha cómo los componentes de inteligencia artificial de Grafana procesan la entrada controlada por el usuario para cerrar la brecha entre un entorno de datos privados y un servidor externo controlado por un atacante.

El ataque no requiere credenciales de inicio de sesión y no depende de que el usuario haga clic en un enlace malicioso. Comienza cuando un atacante crea una ruta URL específica utilizando parámetros de consulta que se originan fuera del entorno de la organización víctima. Debido a que Grafana maneja registros de entrada, un atacante puede obtener acceso a un entorno empresarial al que no tiene una conexión legítima. Luego, el atacante inyecta instrucciones ocultas que la IA de Grafana procesa (una táctica conocida como inyección rápida) utilizando palabras clave específicas para hacer que el modelo ignore sus propias barreras de seguridad.

Grafana tiene protecciones integradas diseñadas para evitar la inyección rápida, pero los investigadores de Noma encontraron una falla en la lógica subyacente a esa protección, una que podría explotarse formateando una dirección web de una manera que el control de seguridad de Grafana interpretara erróneamente como segura, mientras que el navegador la tratara como una solicitud a un servidor externo controlado por el atacante. La brecha entre lo que el control de seguridad creía que estaba permitiendo y lo que realmente sucedió fue suficiente para abrir la puerta al ataque.

El último obstáculo fue el propio instinto de autodefensa del modelo de IA. Cuando los investigadores intentaron por primera vez pasar instrucciones maliciosas, el modelo reconoció el patrón y se negó. Después de estudiar más a fondo cómo el modelo procesaba diferentes tipos de entradas, encontraron una palabra clave específica que provocó que se retirara, tratando lo que efectivamente era una instrucción de ataque como una solicitud rutinaria y legítima.

Con las tres circunvalaciones colocadas, el ataque se ejecuta por sí solo. La IA procesa la instrucción maliciosa, intenta cargar una imagen desde el servidor del atacante y, al hacerlo, transporta silenciosamente los datos confidenciales de la víctima junto con esa solicitud en una etiqueta de imagen. Los datos desaparecen antes de que alguien en la organización sepa que se realizó una solicitud.

Los investigadores de Noma notaron que había múltiples capas de seguridad presentes en la implementación de Grafana, pero cada una contenía su propia debilidad explotable. La lógica de validación del dominio, las barreras del modelo de IA y los controles de seguridad del contenido fallaron cuando se abordaron en secuencia.

Debido a que el exploit se activa mediante una inyección indirecta en lugar de un enlace sospechoso o una intrusión obvia, no hay nada que un usuario pueda notar, ningún error de acceso denegado que un administrador pueda encontrar y ningún evento anómalo que un equipo de seguridad deba investigar. Para un equipo de datos, un ingeniero de DevSecOps o un CISO, la actividad es indistinguible de los procesos rutinarios.

«La carga útil se encuentra dentro de lo que parece una fuente de datos externa legítima. La exfiltración ocurre a través de un canal que la propia IA inicia, lo que parece un comportamiento normal de la IA para cualquier observador. Las reglas SIEM tradicionales, las herramientas DLP y el monitoreo de endpoints no están diseñados para interrogar si la llamada saliente de una IA fue instruida por un usuario o por un mensaje inyectado», dijo a CyberScoop Sasi Levi, líder de investigación de vulnerabilidades en Noma Labs. «Sin una protección en tiempo de ejecución que entienda el comportamiento específico de la IA, monitoreando lo que se le preguntó al modelo, lo que recuperó y las acciones que tomó, este ataque sería efectivamente invisible».

El ataque es otro ejemplo de un cambio más amplio en la forma en que los adversarios abordan los entornos empresariales que tienen funciones integradas asistidas por IA. En lugar de explotar el código de aplicación roto en el sentido tradicional, los atacantes apuntan cada vez más a superficies de seguridad de IA débiles y métodos de inyección rápida indirecta que les permiten acceder y extraer activos de datos críticos mientras permanecen completamente invisibles para los equipos de seguridad responsables de protegerlos.

nomá ha encontrado problemas similares durante el año pasadoy Levi le dijo a CyberScoop que los investigadores siguen viendo la misma brecha fundamental: las funciones de IA se están incorporando a plataformas que nunca fueron diseñadas teniendo en mente modelos de amenazas específicos de IA.

«La superficie de ataque no es un firewall mal configurado o una biblioteca sin parches, sino que es la utilización como arma del propio razonamiento y comportamiento de recuperación de la IA. Estas plataformas confían demasiado implícitamente en el contenido que ingieren», dijo Levi.

La investigación es otro ejemplo de cómo los atacantes pueden convertir la IA en un arma de una manera que las defensas actuales no pueden seguir, lo que hace extremadamente difícil para los defensores mantener el ritmo.

“Los investigadores ofensivos y, cada vez más, los actores de amenazas sofisticados están muy por delante de la mayoría de los defensores empresariales en esto”, dijo Levi. «Los marcos, las firmas de detección y los manuales de respuesta a incidentes para ataques nativos de IA simplemente no existen a escala todavía. Lo que nos da cierto optimismo es que la conciencia está creciendo rápidamente, pero la conciencia y la preparación son cosas muy diferentes».

Grafana Labs fue notificado a través de protocolos de divulgación responsable, trabajó con Noma para validar los hallazgos y emitió una solución.

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.

La falla de la extensión Claude permitió la inyección rápida de XSS sin hacer clic a través de cualquier sitio web – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado una vulnerabilidad en la extensión Claude Google Chrome de Anthropic que podría haber sido explotada para activar mensajes maliciosos simplemente visitando una página web.

La falla «permitió que cualquier sitio web inyectara silenciosamente mensajes en ese asistente como si el usuario los hubiera escrito», dijo Oren Yomtov, investigador de Koi Security. dicho en un informe compartido con The Hacker News. «Sin clics, sin solicitudes de permiso. Simplemente visite una página y un atacante controlará completamente su navegador».

El problema encadena dos fallas subyacentes:

  • Una lista de origen demasiado permisiva en la extensión que permitía que cualquier subdominio que coincidiera con el patrón (*.claude.ai) enviara un mensaje a Claude para su ejecución.
  • Un modelo de objeto de documento (DOMINGO) basado en secuencias de comandos entre sitios (XSS) vulnerabilidad en un componente CAPTCHA de Arkose Labs alojado en «a-cdn.claude[.]ai.»
Ciberseguridad

Específicamente, la vulnerabilidad XSS permite la ejecución de código JavaScript arbitrario en el contexto de «a-cdn.claude[.]ai.» Un actor de amenazas podría aprovechar este comportamiento para inyectar JavaScript que emita un mensaje a la extensión Claude.

La extensión, por su parte, permite que el mensaje llegue a la barra lateral de Claude como si fuera una solicitud de usuario legítima simplemente porque proviene de un dominio incluido en la lista de permitidos.

«La página del atacante incorpora el componente vulnerable Arkose en un lugar oculto.

La explotación exitosa de esta vulnerabilidad podría permitir al adversario robar datos confidenciales (p. ej., tokens de acceso), acceder al historial de conversaciones con el agente de IA e incluso realizar acciones en nombre de la víctima (p. ej., enviar correos electrónicos suplantándolos, solicitar datos confidenciales).

Tras la divulgación responsable el 27 de diciembre de 2025, Anthropic implementó un parche en la extensión de Chrome que impone una estricta verificación de origen que requiere una coincidencia exacta con el dominio «claude[.]ai.» Desde entonces, Arkose Labs ha solucionado la falla XSS al final del 19 de febrero de 2026.

«Cuanto más capaces se vuelven los asistentes de navegador de IA, más valiosos son como objetivos de ataque», dijo Koi. «Una extensión que puede navegar por su navegador, leer sus credenciales y enviar correos electrónicos en su nombre es un agente autónomo. Y la seguridad de ese agente es tan fuerte como el origen más débil en su límite de confianza».

Los piratas informáticos aprovechan CVE-2025-32975 (CVSS 10.0) para secuestrar sistemas Quest KACE SMA sin parches – CYBERDEFENSA.MX

Según Arctic Wolf, se sospecha que los actores de amenazas están explotando una falla de seguridad de máxima gravedad que afecta al dispositivo de administración de sistemas (SMA) Quest KACE.

La empresa de ciberseguridad dicho observó actividad maliciosa a partir de la semana del 9 de marzo de 2026 en entornos de clientes que es consistente con la explotación de CVE-2025-32975 en sistemas SMA sin parches expuestos a Internet. Actualmente no se sabe cuáles son los objetivos finales del ataque.

CVE-2025-32975 (puntuación CVSS: 10,0) se refiere a un vulnerabilidad de omisión de autenticación que permite a los atacantes hacerse pasar por usuarios legítimos sin credenciales válidas. La explotación exitosa de la falla podría facilitar la toma completa de las cuentas administrativas. Quest solucionó el problema en mayo de 2025.

En la actividad maliciosa detectada por Arctic Wolf, se cree que los actores de amenazas han utilizado la vulnerabilidad como arma para tomar el control de cuentas administrativas y ejecutar comandos remotos para eliminar cargas útiles codificadas en Base64 desde un servidor externo (216.126.225[.]156) mediante el comando curl.

Ciberseguridad

Luego, los atacantes desconocidos procedieron a crear cuentas administrativas adicionales a través de «runkbot.exe«, un proceso en segundo plano asociado con el Agente SMA que se utiliza para ejecutar scripts y administrar instalaciones. También se detectaron modificaciones del Registro de Windows a través de un script de PowerShell para posibles cambios de persistencia o configuración del sistema.

Otras acciones emprendidas por los actores de amenazas se enumeran a continuación:

  • Realización de recolección de credenciales utilizando Mimikatz.
  • Realizar descubrimiento y reconocimiento enumerando los usuarios que han iniciado sesión y las cuentas de administrador, y ejecutando los comandos «net time» y «net group».
  • Obtención de acceso del protocolo de escritorio remoto (RDP) a la infraestructura de respaldo (Veeam, Veritas) y controladores de dominio.

Para contrarrestar la amenaza, se recomienda a los administradores que apliquen las últimas actualizaciones y eviten exponer las instancias de SMA a Internet. El problema se solucionó en las versiones 13.0.385, 13.1.81, 13.2.183, 14.0.341 (parche 5) y 14.1.101 (parche 4).