OpenClaw, agentes descontrolados e higiene de aplicaciones

Agradecimientos: Un agradecimiento especial a los equipos de Huntress Adversary Tactics y de Producto por su trabajo en el desarrollo de telemetría de identidad, Rogue Applications y detecciones de SIEM que hicieron posible esta investigación. Gracias especiales a Dave Kleinatland y a Matt Kiely por su ayuda con las herramientas y la investigación sobre aplicaciones de Azure.

Contexto

Desde su lanzamiento, OpenClaw ha tenido una adopción rápida en una amplia variedad de organizaciones que experimentan con agentes de IA y automatización en entornos de producción. En una publicación anterior, nos enfocamos en un falso OpenClaw que funcionaba como vector de entrega de malware e infostealer, y repasamos cómo el proyecto evolucionó desde Moltbot y ClawdBot hasta su forma actual.

Esta vez, analizamos un problema distinto pero relacionado: cómo OpenClaw aparece como una aplicación en la nube dentro de los inquilinos de Microsoft, qué permisos recibe y cómo esos permisos se traducen directamente en exposición de identidad y datos. En lugar de centrarnos en el análisis a nivel de código, vamos a tratar a OpenClaw como lo que efectivamente se ha convertido en muchos entornos: una entidad de servicio poderosa y semiconfiable que se ubica en el centro de tu superficie de ataque de identidad.

¿Qué es OpenClaw en un contexto de nube?

OpenClaw es un agente de IA de código abierto ampliamente adoptado que se puede conectar al correo, el calendario, el almacenamiento de archivos y otros sistemas empresariales para automatizar tareas rutinarias. Según cómo se implemente, puede que ni siquiera parezca "malware". En varios inquilinos que examinamos, OpenClaw (y nombres anteriores como "Moltbot") fue instalado por usuarios individuales como un "asistente de productividad" y se le dio acceso a su buzón de correo o calendario para que pudiera redactar correos, resumir hilos o programar reuniones. Desde la perspectiva de la identidad, eso es justo lo que hace que OpenClaw sea tan peligroso. Se le puede otorgar:

• Permisos de aplicación: acceso directo a todo el inquilino otorgado a la app, que opera sin un usuario conectado. Este es el modo de mayor riesgo; piensa en "leer o modificar todos los buzones del inquilino". Estos requieren el consentimiento del administrador.
• Permisos delegados: acceso otorgado en nombre de un usuario específico y limitado (en teoría) por los propios permisos y alcance de ese usuario. Por defecto, los usuarios pueden otorgar estos permisos sin ninguna aprobación ni visibilidad por parte del administrador, lo que crea una brecha de supervisión importante. Deshabilitar el consentimiento del usuario para aplicaciones es una mitigación clave.

En la práctica, hemos visto ambos casos, y la línea entre un "asistente útil" y un "proxy de identidad sin límites" puede desaparecer rápidamente en cuanto entran en juego permisos de aplicación amplios.

¿Qué hace que estas apps sean tan riesgosas?

Cuando se deja de lado la marca amigable y se observa únicamente lo que la app puede hacer, algunas entidades de servicio relacionadas con OpenClaw aparecen con conjuntos de permisos que son indistinguibles de herramientas de administración de alto valor. Por ejemplo, observamos apps con:

• UserAuthMethod‑Email.ReadWrite.All: la capacidad de modificar los métodos de autenticación del usuario a través del correo electrónico, lo que crea una vía directa hacia la toma de control de una cuenta si se abusa de ella.
• Directory.ReadWrite.All: acceso completo de lectura/escritura al directorio de Entra ID, incluidos usuarios, grupos y roles.
• Application.ReadWrite.All: la capacidad de registrar, modificar o eliminar cualquier aplicación en el inquilino.
• DelegatedPermissionGrant.ReadWrite.All y AppRoleAssignment.ReadWrite.All: la capacidad de otorgar permisos de OAuth y asignar roles de aplicación en nombre de otros, lo que en la práctica permite evadir el consentimiento y la escalada de privilegios.
• Sites.FullControl.All: control total sobre todos los sitios de SharePoint, incluida la gestión de permisos y el acceso al contenido.

En ese punto, la etiqueta de la app (OpenClaw, Moltbot, "Assistant" o cualquier otra) importa mucho menos que la realidad: le has dado a un agente externo vía libre para actuar en todo tu inquilino. Si un actor de amenazas compromete ese agente, roba sus secretos o manipula su infraestructura de backend, hereda esos privilegios de inmediato.

Observaciones de Huntress en los inquilinos de los clientes

Para entender qué tan extendido está este patrón, escaneamos los entornos de los clientes en busca de aplicaciones en la nube con nombres asociados a OpenClaw y sus marcas anteriores, incluidos "OpenClaw", "Moltbot" y variantes similares. Los escaneos iniciales identificaron del orden de decenas de apps a fines de febrero, y los escaneos posteriores en marzo mostraron que esa cifra siguió creciendo a medida que más organizaciones experimentaban con agentes de IA y automatización.

La mayor parte de lo que encontramos se agrupaba en dos grandes categorías:

1. Asistentes instalados por el usuario: casos en los que un solo usuario le había dado a la app acceso a su propio buzón o calendario. Estos aún importan, en particular cuando el usuario tiene privilegios altos (TI, finanzas, personal ejecutivo), pero al menos están limitados a una sola identidad.
2. Entidades de servicio "demasiado poderosas": casos en los que una app de marca OpenClaw se había registrado de forma centralizada y había recibido permisos amplios de directorio, correo y SharePoint, muy por encima de lo necesario para el caso de uso documentado.

En ambas categorías, el hilo conductor fue la falta de una higiene sostenida de las aplicaciones. Los equipos sabían que "estamos probando asistentes de IA", pero no existía un proceso duradero para revisar qué podían hacer realmente esos asistentes, cómo cambiaba ese alcance con el tiempo, ni qué aprobaciones se habían otorgado en un principio.

Otro punto débil de identidad más

Los agentes instalados y las aplicaciones en la nube (ya sea para monitoreo remoto, asistencia de IA o simple productividad) se han convertido en un nuevo punto débil en muchos entornos. El riesgo se presenta en dos lugares:

• La instalación en sí. Si no controlas y auditas de forma estricta quién puede dar consentimiento a las apps, un solo usuario puede introducir con un solo clic una nueva vía de identidad poderosa en tu inquilino.
• El acceso que permanece. Una vez que la app está activa, se convierte en un punto de entrada persistente. Si un atacante compromete al proveedor, roba los secretos de la app o abusa de un error de configuración, obtiene acceso directo a los privilegios que ya le otorgaste a ese agente, a menudo evadiendo en el proceso tus defensas tradicionales centradas en endpoints.

Como con cualquier agente RMM poderoso, una vez que estas apps están en funcionamiento, se convierten en un objetivo principal. La diferencia es que a menudo se ubican directamente dentro de tu plano de control de identidad y SaaS, no solo en los endpoints, y los antivirus tradicionales o el EDR pueden no llegar a detectarlos nunca.

Buscar OpenClaw y aplicaciones similares con Huntress

Los clientes de Huntress tienen dos ventajas principales a la hora de encontrar y comprender los agentes de estilo OpenClaw en su entorno:

1. Aplicaciones no autorizadas – Inventario de aplicaciones en la nube
2. Huntress Managed SIEM – Búsqueda de actividad de identidad y aplicaciones

Paso 1: Haz un inventario de lo instalado

Comienza en Identity Threat Detection & Response → Rogue Applications → Cloud Applications para obtener una vista consolidada de los service principals y las aplicaciones en la nube en tu inquilino, incluidos derivados de OpenClaw y Moltbot. Usa búsquedas por palabras clave con cadenas como:

• OpenClaw
• Moltbot
• Nombres de proyectos internos o heredados que envolvían la misma funcionalidad de agente

Para cada coincidencia, revisa:

• Quién instaló o dio su consentimiento a la aplicación
• Cuándo se agregó al inquilino
• Qué nivel de permiso le ha asignado Huntress (por ejemplo, "Powerful" para conjuntos de permisos de alto impacto)

Esto te da el inventario base que necesitas para que cualquier cosa nueva o inesperada se note de inmediato.

Figura 1: Huntress Rogue Applications muestra el nombre de la aplicación, los permisos y quién autorizó la aplicación

Paso 2: Comprende qué puede hacer

A continuación, enfócate en los permisos, no solo en la presencia. Presta especial atención a:

• Permisos a nivel de directorio (cualquier *.ReadWrite.All sobre el directorio, las aplicaciones o los roles de aplicación)
• Permisos de buzón y SharePoint que operan sobre todos los objetos
• Cualquier alcance que permita a la aplicación otorgar, modificar o propagar sus propios permisos

El acceso otorgado a cada aplicación debe ser el mínimo absoluto necesario para su función documentada, y debes estar atento a la "desviación de configuración" de permisos a medida que se agregan funciones o se cambia la configuración con el tiempo. También puedes revisar tu inquilino en busca de aplicaciones que Huntress haya marcado como Powerful, para buscar o filtrar según los permisos que la aplicación haya consentido, además, y seguir a partir de ahí.

Paso 3: Sigue el rastro en SIEM

Una vez que hayas identificado las aplicaciones relacionadas con OpenClaw, pasa a Huntress Managed SIEM para entender qué han hecho realmente. Un buen punto de partida es buscar en los registros de auditoría de Identity y Entra los eventos de consentimiento y actualización de aplicaciones vinculados a los nombres OpenClaw o Moltbot.

Por ejemplo, si tu nomenclatura interna todavía usa un nombre heredado como moltbot, puedes comenzar con una consulta ESQL de la forma:

from logs

| WHERE itdr.Target LIKE "%moltbot%"

or

from logs

| WHERE itdr.Target LIKE "%openclaw%"

Figura 2: Huntress Managed SIEM muestra eventos asociados con una instalación de OpenClaw

A partir de ahí, pasa a:

• Eventos de consentimiento – ¿cuándo se le otorgó acceso a la aplicación por primera vez y quién lo hizo?
• Operaciones de actualización – ¿han cambiado sus permisos y eso coincidió con alguna otra actividad sospechosa?
• Acciones posteriores – ¿con qué buzones, archivos o identidades interactuó la aplicación después del consentimiento? ¿Qué leyó, escribió o modificó?

Esa es la diferencia entre "sabemos que OpenClaw existe aquí" y "podemos decirte exactamente qué hizo, cuándo y a quién."

Para más ideas y consultas, puedes encontrar más ejemplos aquí.

Guía de mitigación y endurecimiento

OpenClaw y otros agentes de IA similares no son inherentemente malos, y algunas organizaciones decidirán que los beneficios de productividad valen el riesgo. Pero esa decisión debe ser explícita, guiada por una política y respaldada por monitoreo continuo.

Algunos pasos prácticos que puedes tomar hoy:

• Establece políticas claras sobre quién puede dar consentimiento a aplicaciones de terceros en la nube y bajo qué circunstancias. Trata a los agentes de IA potentes como parte de tu superficie de ataque de identidad, no como complementos de productividad inofensivos.
• Busca en tu entorno de Entra (y en Huntress Rogue Applications) los nombres OpenClaw, Moltbot y relacionados. Confirma que reconoces cada implementación y entiendes su propósito.
• Valida los permisos y el alcance. Cuando sea posible, cambia las aplicaciones de permisos de aplicación a permisos delegados, y recorta agresivamente cualquier exposición "*.ReadWrite.All" que no sea estrictamente necesaria.
• Revisa la actividad mediante SIEM. Usa Huntress Managed SIEM para identificar qué han hecho realmente estas aplicaciones: sobre qué identidades actuaron, a qué contenido accedieron y si ese comportamiento coincide con lo esperado.
• Elimina o deshabilita las aplicaciones innecesarias. Si una implementación de OpenClaw ya no es necesaria, o nunca fue aprobada en primer lugar, revoca su consentimiento, deshabilita el service principal y documenta esa decisión antes de que se convierta en un informe de incidente en lugar de una tarea de higiene.

Puntos clave

• Límites difusos: OpenClaw sirve como caso de estudio de la rapidez con la que los agentes de IA pueden pasar de ser una "herramienta" útil a convertirse en una peligrosa "superficie de amenaza".

• Riesgo basado en permisos: El riesgo principal no proviene de nuevos exploits o días cero, sino de permisos bien documentados y de alto impacto que se otorgan silenciosamente a los asistentes de IA dentro del plano de identidad.

• Gestión proactiva: Puedes transformar las "vulnerabilidades fantasma" en riesgos manejables si:
• Mantienes un inventario continuo de las aplicaciones y agentes en tu inquilino.
• Obtienes una comprensión clara de sus capacidades específicas.
• Monitoreas cómo evolucionan su acceso y sus permisos con el tiempo.

• Defensa preventiva: Una visibilidad adecuada garantiza que, si un atacante intenta secuestrar un agente potente, ya sepas su ubicación, su alcance y los pasos necesarios para desactivarlo.

Esperamos que te lleves las herramientas para saber dónde se ha implementado OpenClaw o algún agente derivado y, si es así, qué hizo. Lo último que quieres es enterarte demasiado tarde.