Dejamos que OpenClaw se moviera libremente por una red interna. Esto es lo que descubrió

En mi anterior artículo sobre OpenClaw escribí:

«Incluso las organizaciones más «arriesgadas», con una amplia experiencia en IA y seguridad, probablemente encontrarán difícil configurar OpenClaw de manera que mitigue eficazmente el riesgo de compromiso o pérdida de datos, al tiempo que se mantiene cualquier valor de productividad ».

El Red Team de Sophos lo tomó como un «reto aceptado», así que nos marcamos un objetivo: equipar a OpenClaw con un conjunto estándar de herramientas de red teaming, darle acceso a una de nuestras redes locales heredadas y dejarlo suelto para que encontrara y explotara cualquier vulnerabilidad. Y hacerlo de forma segura.

Enfoque

Objetivo

Elegimos una red local heredada por varias razones:

Mitigación de riesgos: aunque se trata de redes de producción reales, no de entornos de prueba, la mayoría de las cargas de trabajo críticas se encuentran en entornos nativos de la nube aislados. Queríamos mantener una distancia prudencial entre la herramienta y nuestras joyas de la corona.

Control: los sistemas modernos distribuidos nativos de la nube son complejos de supervisar. Consideramos que un enfoque centrado en la red con controles estrictos de entrada y salida era el adecuado para supervisar, comprender y, cuando fuera necesario, controlar. No es imposible en los sistemas nativos de la nube, solo más difícil, y queríamos controlar el alcance.

Optimización para el éxito: elegimos una red heredada que nuestro programa de Red Teaming no había atacado en bastante tiempo. ¡Queríamos que la herramienta tuviera una oportunidad decente de encontrar algo!

Discreción

No intentamos ser discretos. Llevamos a cabo esta prueba de penetración de forma deliberadamente ruidosa, no como una operación encubierta del equipo rojo: priorizamos la cobertura, la velocidad y la reproducibilidad por encima de la evasión. Como resultado, la actividad generó un gran número de detecciones y alertas internas en toda nuestra pila de monitorización —lo cual, en este contexto, fue una ventaja más que un problema. Una operación sigilosa al estilo del equipo rojo habría requerido una arquitectura diferente y probablemente habría chocado con muchas más barreras de seguridad del modelo.

Seguridad

Sin duda, las partes más importantes de la prueba fueron las barreras de seguridad y las habilidades que desarrollamos. El equipo dedicó la mayor parte de su tiempo a crear el marco operativo para garantizar que nuestro agente no destruyera por completo el entorno y, lo que es más importante, no borrara todos nuestros correos electrónicos.

Nuestro principal modelo mental aquí fue la «Trifecta Letal». Teníamos que evitar que el agente pudiera: a) recibir contenido no fiable, b) acceder a datos confidenciales y c) filtrar esos datos al exterior.

Nuestra primera línea de defensa fueron los estrictos controles de entrada y salida mencionados antes. Aunque el agente podría acabar accediendo a datos confidenciales (¡que es el objetivo de una prueba de penetración!), podíamos gestionar el riesgo de inyección y filtración inmediatas.

También debíamos protegernos contra consecuencias no deseadas derivadas del comportamiento del agente en su búsqueda de objetivos. Nuestro objetivo final era hacer que el entorno fuera más seguro, pero un agente con este único objetivo podría llegar a la conclusión de que la mejor manera de lograrlo sería hacerse con el control del dominio, cifrarlo todo y tirar la llave. Aunque sin duda sería técnicamente impresionante, un ataque de ransomware autoinfligido sería un resultado poco óptimo.

Para alcanzar el nivel deseado de seguridad y control, acabamos utilizando solo habilidades personalizadas, desarrolladas internamente, para la evaluación.

Como el equipo ya contaba con procedimientos bien documentados para llevar a cabo este tipo de evaluaciones, convertir esos procedimientos en habilidades fue bastante rápido (con la ayuda de algunos agentes). Este enfoque resultó ser más sencillo que buscar y auditar las habilidades externas disponibles públicamente (que suelen ser de baja calidad).

Este enfoque también nos permitió incorporar un mecanismo de aprobación ligero con intervención humana, lo que nos proporcionó un equilibrio razonable entre autonomía y control para el experimento. A continuación incluimos algunos extractos (Figuras 1-3), y también hemos publicado nuestra interfaz principal del sistema y las habilidades asociadas en GitHub, así como los resultados.

Figura 1: límites de seguridad del agente del red team de OpenClaw

Figura 2: fragmento del alcance de las habilidades de reconocimiento de Active Directory

Figura 3: fragmento de los límites de seguridad de las habilidades de reconocimiento de Active Directory

Principales conclusiones

En general, el experimento superó nuestras expectativas:

1. El agente se ciñó a los límites configurados durante toda la prueba; no tuvimos ningún problema relacionado con la búsqueda de objetivos que provocara consecuencias no deseadas
2. El equipo logró una enorme mejora en la eficiencia a lo largo de todo el proceso: por ejemplo, redujo la fase de reconocimiento de Active Directory de tres días a tres horas
3. La evaluación generó 23 hallazgos prácticos y de alta calidad (el desglose de los hallazgos se encuentra en el apéndice)
4. La metodología de evaluación generó un registro de auditoría de alta calidad con un nivel de detalle imposible de lograr manualmente, lo que simplificó drásticamente la redacción del informe
5. El agente demostró creatividad y autonomía. Por ejemplo, cuando bloqueamos una vía de ataque prometedora, el agente sugirió y (tras recibir autorización) procedió a poner en marcha una instancia EC2 con GPU para descifrar un hash obtenido
6. Los modelos que utilizamos se negaban a menudo a cooperar debido a preocupaciones sobre su uso malicioso. El equipo fue capaz de sortear estas restricciones en su mayor parte, pero sí que introdujeron fricciones en el proceso
7. Los pentesters están en una posición única para aprovechar herramientas nuevas —y potencialmente arriesgadas—. Las pruebas de penetración suelen implicar herramientas de código abierto potencialmente peligrosas y pruebas de concepto de exploits en fase inicial, lo que crea un entorno de cadena de suministro de software complejo. Por ello, el equipo ya había creado un marco para ejecutar herramientas no fiables en entornos sensibles con un alto grado de confianza. En el apéndice se ofrece más información sobre esta infraestructura subyacente

Reflexiones finales

Este exitoso experimento demostró claramente de primera mano la compleja disyuntiva a la que se van a enfrentar los equipos de ciberseguridad. Sí, estas herramientas son peligrosas, pero no adoptarlas podría ser aún más peligroso. El mundo sigue avanzando y la seguridad de la IA autónoma se está convirtiendo rápidamente en el reto que definirá esta era para la comunidad de ciberseguridad.

También me demostró que los equipos de ciberseguridad están, de hecho, mejor posicionados que nadie para estar a la vanguardia de su adopción. En primer lugar, ¿quién mejor para manejar una herramienta peligrosa y poderosa que los operadores que, por naturaleza, piensan en la seguridad en cada paso del camino? En segundo lugar, cuanta más experiencia de primera mano tengan los profesionales de la ciberseguridad en este ámbito, más posibilidades tendrán de predecir hacia dónde van las cosas, dónde están los puntos de control adecuados y, como mencioné en mi artículo anterior, cómo es la gestión práctica del riesgo en la práctica.