La empresa Cloudflare tiene disponible para todos los equipos de seguridad, especialmente para los CERTs y los CSIRTs, el servicio Cloudflare RADAR de datos abiertos sobre lo que está pasando en su red y en sus servicios de seguridad, y te permite tener una visión de lo que está pasando en la seguridad de Internet desde sus servicios, lo que complementa la información que tengas desde otras fuentes de datos. Al final, la colaboración y la compartición de datos entre los equipos de ciberseguridad es fundamental para protegernos entre todos.
Los servicios de ciberseguridad de Cloudflare ofrecen protección para los activos que las empresas tienen en Internet, que van desde proteger los sitios web o sus plataformas de e-commerce expuestos en la red frente a ataques de DDOS, hasta proteger el e-mail, pasando por WAFs, protección contra interceptación de conexiones de red, protección de servicios de DNS, protección contra técnicas de WebScrapping como vimos con AI Labirynth, o los más modernos servicios de monitorización y protección de servicios digitales basados en arquitecturas de Inteligencia Artificial.
Toda esta información puede ser consumida vía API, mediante un Dashboardweb/mobile, o mediante el uso de un Asistente AI al que se le puede preguntar por datos concretos, informes, e información en las bases de datos de Cloudflare Radar.
En este panel tienes datos de todos esos servicios, procesados, filtrados, destilados y disponibilizados para que puedas interactuar con ellos y sacar detalles que puedan ayudarte en tu trabajo en ciberseguridad, o entender mejor qué está pasando o qué va a pasar.
Como los datos de Cloudflare están centrados en Ciberseguridad, y debido a que muchos de ellos proceden de sus servicios de protección, el curado de los datos está orientado a ello, por lo que se pueden obtener datos de ataques, informes de incidentes recientes, estadísticas de dominios atacadas, bots maliciosos, etcétera.
Todos los datos están procesados, pero están los detalles disponibles, por lo que si ves este informe de Phishing de ayer mismo, puedes ver incluso los ficheros de la web que se han descargado, y absolutamente todos los datos disponibles.
La información completa y detallada de la API la tienes en la web para Devevelopers de Cloudflare, donde por ejemplo tienes APIs para tener datos de anuncios de BGP - uno de los ataques Nation State que hemos visto en el pasado - que pueden alterar la seguridad de las redes a nivel de conexión.
Esa información, también la puedes analizar directamente desde la consola de Cloud Radar, y ver si todo está como debe, si hay una actividad maliciosa o si se ha producido un Hijacking de una determinada ruta de interconexión de redes que pueda ser un riesgo, o que explique cómo se ha producido un ataque.
Los datos también dan información sobre el DNS, o los incidentes detectados por los productos de seguridad de e-mail security (recordad que sigue siendo el principal vector de ataque en las empresas), teniendo datos en tiempo real de cuando una campaña de ataque ha comenzado.
Y datos de dominos más peligrosos, cabeceras de seguridad de cada mensaje, y datos de las protecciones SPF, DKIM y DMARC de estos mensajes, para detectar las debilidades que los atacantes están explotando en sus campañas.
Y si además del Dashboard de Cloudflare Radar o de las APIs de Cloudflare Radar quieres encontrar algo usando lenguaje natural, puedes usar el Asistente AI que tienes disponibles, donde puedes interactuar con él para aprender todo lo que necesites de los datos disponibles.
Al final, es una fuente de información que tienes disponible para utilizar en cualquier momento, y si te gusta este mundo, merece la pena que entres en Cloudflare Radar y mires todos datos que tienes disponibles, listos para utilizar en tus sistemas.
Hace unos días me toco investigar un asunto un poco "crappy". Las luces de casa de una persona se encendían y apagaban. Algo no iba bien, y claro, la presencia de alguien no deseado en la red podría ser una realidad. Os cuento el escenario, completo.
Figura 1: El ordenador plataformado del teletrabajo a la WiFi
de Invitados, con la webcam tapada y sin micrófono.
Un router de fibra con UPNP y un red WiFi a la que se conectan todos los equipos, unas bombillas Smart-Bulb con WiFi que se conectan a la WiFi, y un Alexa con las que se controlan dichas bombillas. Recordando mis años de consultoría, la idea es hacer una lista de todas la posibilidades y luego ir descartándolas una a una hasta que quede la más posible. Esta es la lista que hizo mi cabeza:
Crack de WiFi: Parece lo más sencillo, así que había que revisar el protocolo de seguridad de la red, y ver la robustez que tenía. En este caso era un WPA2/PSK, así que la robustez depende de la contraseña. De todo esto, hemos publicado un libro fantástico que lo explica en detalle.
Exploit para Router: Esta posibilidad podría darse si hay un 0day de explotación remota para el router, pero eso significaría que tenía abierto el panel de administración a Intenet.
Default User: Otra posibilidad muy típica. Dejar el router con el usuario por defecto y que alguien desde Internet lo usara para conectarse al panel, ver la clave, y conectarse a la red. De esto sabe mucho Gerard Fuguet que se lo encuentra a su alrededor en los dispositivos del hogar muy amenudo.
Hack de Alexa: Otra de las posibilidades que pasó por mi cabeza fue que alguien estuviera jugando con los utlrasonidos y Alexa, pero para ello Alexa debía reaccionar, y no estaba reaccionando, así que esta posiblidad se quedó fuera.
Hack de las bombillas: Las SmartBulbs tienen un back-end en Singapur, otro en USA y otro en China, así que podría ser que alguien hubiera vulnerado el panel y la cuenta del panel de las bombillas. Ya que estas bombillas se controlan también vía Internet con una app. Podrían haber hecho un password spraying o algo así. Había que revisar esa cuenta.
Insider en un equipo de la red: Esta era la última posibilidad, y consistía en un posible equipo infectado controlado por un atacante..
Así que había que revisar todo. Paso a paso. Descartado el posible hack de Alexa - aún así se desconecto para probar -, tocó cambiar la contraseña de la WiFi a una más robusta aún (just in case), revisar a ver si el panel estaba en Internet - nop - se desactivó el UPNP por si algún software se abría un puerto raro y tiraba alguna conexión no deseada, se revisó a ver si había exploits del Router WiFi, y nada. Todo eso estaba ok. Eso sí, contraseñas por defecto en el router, pero no accesible a Internet, solo en local.
Todo eso apuntaba a que el atacante podría estar dentro. Y en ese momento hablamos de los equipos, uno de ellos, de teletrabajo administrado remotamente por el equipo IT de la empresa que, además, se puede conectar sin pedir permiso al usuario, porque el software que tienen les permite hacer eso. Y saltaron todas las alarmas.
Por supuesto, no se tenía historial de conexiones, ni se sabía quién se había conectado, así que hubo que tomar las medidas pertinentes. Eliminar cualquier rastro de identidades personales, tales como cuentas de Gmail, WhatsApp, Telegram, Instagram en el navegador local - muy común si usas Google Chrome y sincronizas el Password Manager de Google -, y lo más importante, aislar ese equipo a la red de invitados.
Lógicamente como es un equipo Windows, tapar la Webcam y el micrófono del PC, para solo usar el micrófono de unos auriculares inalámbricos que tengan bloqueo físico, porque si no, alguien con acceso a ese PC podría arrancar software de grabación de Webcam o de Audio, y adiós a tu intimidad.
No hay certeza - aún -, de que alguien se haya conectado al equipo remoto y haya hecho esa acción maliciosa, y podría ser también un error puntual de la bombilla, o un bug en el panel remoto de estas Smart-Bulbs, pero como protección por si el problema está en ese equipo, se ha "aislado" del audio, el vídeo y la red de la casa donde está situado. Y también cambiadas las credenciales por defecto del router y configurar actualizaciones automáticas de firmware, que desde dentro de la red se tiene acceso al panel de administración del router - que no tiene un 2FA en este caso -.
Figura 7: Activación de WiFi de Invitados en la Living App de SmartWifi
Si estas teletrabajando, recuerda que ese equipo está administrado remotamente, así que aíslalo de la red. Exige que haya un seguimiento de quién se conecta a ese equipo - que está en tu casa - y que la empresa guarde un registro de los comandos que ejecuta con software de gestión de cuentas privilegiadas, porque podría grabar audio o vídeo remotamente, o hacer cosas en la red de tu hogar sin que tú lo sepas, así que cuanto más aislado de tu entorno lo tengas, mejor que mejor.
IPv6 es un acrónimo alfanumérico de cuatro caracteres de longitud que, a su “descompresión” viene a decir/representar: Internet Protocol version 6
¿Se puede “comprimir”/acortar más? Esa es la idea… El objetivo es lograr una reducción a su mitad, tal que: IP. Dejando a un lado (u obviando) su versionado.
Podría describirse la palabra versión como sustantivo femenino que se refiere a la forma o variante particular de algo, especialmente cuando existen varias alternativas o modificaciones de un mismo objeto, texto, idea o producto. En un contexto tecnológico, puede haber un par de motivos para destacar/resaltar una versión frente a un protocolo;
Mismo protocolo pero con grandes diferencias en funcionalidades y capacidades (nuevas y/o mejoradas).
Convertirse en deprecado debido a un agujero, fallo de seguridad lo suficientemente grave como para hacerse hincapié sobre ello y movilizar a los recursos necesarios para erradicarse o ser cambiado mediante una actualización, etc.
En este caso, el motivo en IPv6 es el primero descrito. Todavía a día de hoy, no hemos podido hacernos con la misión, no hemos sido capaces de resolver el problema y quedarnos con la versión actual. Según calendario, llevamos con “el pez que se muerde la cola” desde 2010 aproximadamente a un modo de alerta recurrente. Tal vez sea lo más parecido a la escasez del petróleo en este actual siglo ¿Y... cómo ponemos solución al remedio?
IPv6 Council al Rescate
La IPv6 Council es una asociación, grupo de interés sin ánimo de lucro con espíritu muy colaborativo, portadora de ideas, ganas de promocionar, dar soporte... con el afán de “apadrinar” a la “sexta elementa” para poner a España a la vanguardia tecnológica haciendo uso de la versión “moderna” del protocolo IP.
Liderado por Carlos Ralli, Fran Gómez y Rafa Sánchez, se mira de hacer todo lo posible para hacer llegar preocupaciones, tácticas de encaje con dinamismo y posturas flexibles al extenso ámbito tecnológico, ya que, la IP es un pilar básico de cualquier dispositivo digital (como toda la “cacharrería” de los IoT).
Sin ir más lejos, en este mismo mes de Mayo han estado presencialmente en el congreso MetaWorld Congress [MTW]/OpenExpo celebrado en la La Nave de Madrid.
Al tratarse de ataques tanto en IP “clásica” como en IPv6, tienen que explicar sus bases de raíz para tener un mínimo contexto. Si le echáis un vistazo al índice podréis ver los conceptos en su capítulo V, apartado 5.1, “Conceptos básicos sobre IPv6”.
Sí, efectivamente, comenté que en este par de libros, como una de la tareas principales era analizar el tráfico que fluía por los dispositivos que tienes en tu hogar, primero debes de conocerlos bien, hacer un “PreCheckeo: I&I, Identificación e Inventariado” (apartado 2 del capítulo III del primer libro de Hacking Home Devices), tal y como puedes ver en el índice que te dejo a continuación.
Y te vas dando cuenta que IPv6 es también una protagonista notoria que se aposenta en tu red como telarañas discretas en un hogar. Sobretodo la presencia automática e obligatoria de Link-Local (sí, aquella que empieza con el prefijo fe80::…) Si ejecutas un ipconfig en el “ventanal negro” y la ves, es señal de que tienes en activo IPv6 (by default es así).
Primero aprende la primera versión de la IP (IPv4)
Cualquier docente mínimamente cualificado te dirá que antes de aventurarte con IPv6, primero debes entender bien su funcionamiento estudiando su hermana menor, la IPv4. Podríamos explicarlo en este artículo, pero se haría muy largo… por eso, me siento en la obligación de recomendar un libro realmente bueno para aprender de IP y de otros conceptos informáticos elementales (y no tan elementales). El libro de David Casas de Competencia Digital.
Te bastará solo con su lectura para entender bien su composición, tipos de IP, rango, subredes… ¿Y no habla luego de IPv6? Sí, por supuesto, pero no se potencia en detalle como IPv4 porque su interés es primero en entender bien las bases de una IP. A pesar de sus diferencias respecto a la clásica IP, la construcción de la versión 6 se hace de manera similar, pero éstas son mas bien un “choricillo” (como bien menciona David Casas) de longitud, precisamente para abarcar con muchísimas más IP’s disponibles que con IPv4 (pasando de 32 a 128 bit en la sexta versión).
Aún así, estoy bastante convencido, que si llega el día de la extinción al completo de IPv4, todavía perdurará en los libros y documentación en Internet para facilitar su enseñanza, aunque existen grandes diferencias de funcionamiento después con IPv6 que debes aprender.
Las IPv6 de tu casa
Como se ha descrito antes, puedes saber si tu sistema operativo como Windows usa IPv6 y qué dirección toma. Si sabes como van las IPv4, las direcciones IPv6 de Link-Local (con prefijo fe80::/10) se asignan automáticamente a toda interfaz de red con IPv6 habilitado, son obligatorias y sólo funcionan dentro del segmento de red local.
Se utilizan para funciones esenciales como la auto-configuración, el descubrimiento de vecinos (NDP) y la comunicación local entre dispositivos. Aunque tradicionalmente la parte identificadora podía derivarse de la MAC (EUI-64), hoy en día muchos sistemas operativos emplean métodos aleatorios para mayor privacidad.
La unicidad de la dirección se verifica mediante NDP, y no son enrutables fuera del enlace local, igual que las direcciones APIPA en IPv4, aunque en IPv6 su presencia es universal y no sólo ante fallos de DHCP. Supongamos que tu equipo toma esta dirección IPv6:
fe80::9a94:43a9:9ff4:6981
Como se expresa en hexadecimal, las letras-números válidos son de 0-9 y A-F. Cada casillon de la IPv6 se compone de 4 dígitos hexadecimales y cada carácter hexadecimal representa 4 bit. Por lo tanto, cada casillón obtiene 16 bit en grupos de 8 casillones. Pero espera… ¿por qué yo aquí sólo veo 5 grupos? Cuando los grupos están a “0” se suele expresar/interpretar con doble -dos puntos- “::”. Esta IPv6 se expresaría así;
fe80:0000:0000:0000:9a94:43a9:9ff4:6981
Vale entiendo… pero y esto de la /10? Al igual que IPv4 con sus máscaras, el estándar dice que las Link-Local, pueden ir de la fe80:: a la febf:: . Esto es simple cuando descomponemos a binario (de hexadecimal a binario).
fe80:: seria 1111 1110 1000 0000
febf:: seria 1111 1110 1011 1111
La parte subrayada es la que contempla/hace referencia a la red y es intocable. El resto pertenece a la parte de host (recuerda entender bien IPv4 para saber como va el “rollete” ;) ). En la practica (por el momento) se utiliza la notación de máscara /64 por lo que el prefijo fe80:: siempre será impuesto en toda Link-Local. Es decir, en el ejemplo de la IPv6 Link-Local:
fe80:0000:0000:0000:9a94:43a9:9ff4:6981
Será inmóvil sus 4 primeros grupos. Una de mis reglas mnemotécnicas preferidas es hacer uso de la calculadora de Windows, sobretodo para esclarecer la parte de net y la de host.
Figura 12: Rango de IPv6 Link-Local haciendo
uso de la Calculadora de Windows
Se estipula en modo programador, en notación hexadecimal y teclado numérico de alternancia de bits. La parte roja hace referencia a la parte de red, que son sus primeros 10 bit inmóviles (/10) y la parte verde la de host, donde se conmutan todos los bits a “1” para saber su rango máximo en su primer casillón de 16 bits. Lo bueno de la calculadora, es que te permite conmutar cada bit a clic de ratón (parece una tontería, pero refuerza el entendimiento para su comprensión). Nota: Cómo se muestra en la figura, puedes también ejecutar más de una instancia de calculadora al mismo tiempo.
¿Y que más tipos IPv6 prefijadas puedo ver en casa?
Aquí te dejo este “chuletón” de llamadas/peticiones multicast interesantes:
ff02::1: Es la dirección multicast de todos los nodos en el segmento local. Todo dispositivo IPv6 la escucha.
ff02::1:2: Es la dirección multicast para todos los servidores DHCPv6 en el segmento local.
ff02::1:3: Es la dirección multicast usada por LLMNR (Link-Local Multicast Name Resolution) en IPv6, en el puerto 5355.
ff02::1:ffxx:xxxx (Solicited-Node Multicast): Es la dirección multicast generada automáticamente por cada host IPv6 para facilitar la resolución de direcciones (Neighbor Discovery Protocol, NDP), similar al ARP en IPv4, pero usando ICMPv6. El rango es ff02::1:ff00:0/104, y los últimos 24 bits corresponden a los últimos 24 bits de la dirección IPv6 del host.
ff02::2: Es la dirección multicast de todos los routers IPv6 en el segmento local.
ff02::c: Se utiliza para el descubrimiento de servicios SSDP (Simple Service Discovery Protocol), típicamente en el puerto 1900.
ff02::16: Es la dirección multicast para MLDv2 (Multicast Listener Discovery versión 2), usada por routers para saber qué dispositivos escuchan tráfico multicast.
ff02::fb: Es la dirección multicast utilizada por mDNS (Multicast DNS) en IPv6, puerto 5353.
Un Vídeo MitM como excusa para dar bombo a IPv6
La verdad es que esto del vídeo ha sido una “alineación de astros y planetas” en toda regla y salió en un momento bastante oportuno. Os explico a modo resumen como se gestó esto.Yo participo en el chat público de El lado del mal en MyPublicInbox. Marta Tobarias me comentó que tenía un blog de ciberseguridad y me dijo que si pudiese darle un poco de “feedback” estaría genial. Me llamó la atención uno sobre Neighbor Spoofing en IPv6. Y buscando en YouTube a mí no me acababan de llenar los vídeos sobre este tema concreto (que igual no busqué en profundidad…).
Yo sabía bien de su funcionamiento, por. las charlas y artículos de Chema Alonso y la Evil Foca. Y le dije a Marta que le haría un vídeo intentándolo explicar bien y hacerlo un poco divertido. A este proyecto se sumó Maria Gomez Prieto que quería meterle mano, un lavado digital para romper la aburrida barrera informática de comandos y paquetes, locos protocolos… que seria OK para los más entendidos pero no tan bien para quien está aprendiendo seguridad informática (ya sabéis que este tipo de videos suelen ser en su mayoría “feos”, poco estéticos y aburridos ¡Para que engañarnos!).
Figura 14: Los culpables de que se haya hecho este artículo y vídeo.
Yo a María la conocí en su pedazo de artículo sobre "Cómo recuperar juegos creados en Flash usando Ruffle", me sorprendió mucho su manejo en la edición de vídeos y la destreza en barajar los bits como pelar patatas para freírlas, o para acabar haciendo tortilla a la española… es decir, fue como recuperar una receta perdida y modificarla para reemplazar con ingredientes que no se tienen (o que son más fáciles de encontrar).
Me contentó mucho cuando la vi por el chat, y me convertí en una especie de fan (admiro mucho su trabajo). Tal es así que nos conocimos en persona en la MTW/OpenExpo junto a otro miembro del chat, a Mikeldi.
Figura 15: Posando frente a un Delorean de Bit2Me. Gerard Fuguet (izquierda)
María me bautizó en el chat como Mr. Fuguet, yo a ella como Lady Maria y María a Marta como Miss Marta. Con Lady Maria tengo muy buena afinidad, similar humor, etcétera. De igual modo con Mikeldi, persona espectacular y bondadosa. Me sentí muy bien y querido, estoy muy contento por hacer amistad con gente con la que tienes mucho de lo que compartir, todo gracias a ELDM y el chat que ha sido el punto de unión.
¡Y volviendo al vídeo! No es nada nuevo pero creo que ha quedado una obra maestra la cual todo el mérito, para nada es mío… Como os he dicho, la colaboración ha generado un producto que creo que es de muy buena calidad. Os presento, en esta foto, a los actores que participan y hablamos de sus roles ;)
Figura 16: Los actores del vídeo IPv6 con MitM con NDP
Izquierda-arriba: Tenemos a Manson quien actúa de mero servidor FTP (sí, sin “s” ¡OJO!) bajo Windows 10. Se va a quedar todo el tiempo calladito :D
Abajo-izquierda-derecha: La dulce y atractiva Marilyn, es la víctima en este escenario de juego. Quien se comunica con el FTP de Manson.
En el centro (¡y pa dentro!):Tenemos a Kalimera. Que le encanta el Kalimocho y cuando bebe se pone a “ciberdelinquir” un rato :P Le encanta disfrazarse para pasar desapercibida (arriba-derecha en la foto).
Las características del laboratorio son simples. Todo se corre en VirtualBox. La red usada (donde se unen todas las máquinas) es de tipo interna. Se estipula la IPv4 a modo estático en cada una de las máquinas. Tanto Marilyn como Manson usan Windows 10 de 32 bit (el motivo es para no consumir muchos recursos) que están actualizadas al máximo con su Win Update a FULL y firewall activo “By Default”, únicamente se le ha permitido la regla de FTP de entrada en la máquina de Manson.
Y como no, una Kali versión 2022.3 (no muy actual pero suficiente). Las herramientas de ataque usadas vienen incluidas en Kali, son atk6-parasite6 (para verlo pasivamente) y atk6-fake_advertise6 (modo activo). No tiene sentido que os describa todo el vídeo aquí en este post, ya que “habla” por sí solo (incluida la descripción del mismo, que he agotado al máximo los 5000 caracteres que permite YouTube). Pero sí me parece interesante contarte algo que no se diga en él.
La intención de esta figura es mostrar las relaciones de IPv6 y partes de ella con la zona prefijada de MAC’s que surgen en el momento de acogerse a una IPv6 Link-Local por la “inocente” Marilyn y el rellenado de su tabla caché (relación IPv6 y MAC) cuando necesita, además, obtener la MAC de un host destino (y lo pide muy amablemente la señorita).
Figura 18: Solicited-node Multicast Address. Vista de Wireshark
y tabla de cache de los vecinos en cmd de la víctima
Antes se ha mencionado que cada host crea obligatoriamente una dirección Solicited-node Multicast. En la figura, primero se ha generado la Solicited-node Multicast - última línea en cmd - del propio host. Como se observa, los últimos 6 caracteres hexadecimales concuerdan con los últimos 6 de la MAC (lo cuál no indica su MAC real de host, se estipula para consultar sí coincide con la solicitud del contrario que intenta comunicarse con Marilyn en dicho mecanismo).
El primer paquete que aparece en la figura, el número 14, se hace uso de este mismo sistema, en su capa de datos se puede ver cómo se pide la IPv6 - Target Address - de Manson. Luego, en la ventana cmd, se genera una segunda línea por encima de su propia generada al crearse su Link-Local,Solicited-node Multicast para “dejarlo por escrito” (como un log/registro) ¿Se esclarece el enigma mejor viendo los paquetes de red?
Y llegó el momento de ver el vídeo de todo este embrollo… Puedes hacerte unas palomitas si lo deseas porque te prometo, que en estos casi treinta minutos, se te pasarán rápidos, como ver una película en tu mejor cine - en tu propia casa, a tus anchas, a tus comodidades y tus reglas -. ¡¿Preparad@?! LET’S GO!!!
Durante el mes de marzo de este año se ha publicado un interesante trabajo realizado por miembros de la Carmegie Mellon University en colaboración con gente de Antrhopic para ver si estamos en un nivel de madurez en los LLMs como para que puedan realizar ataques completos a redes de organizaciones que requieren un buen número de fases antes de conseguir tomar control de ellas.
El objetivo de este trabajo era comprobar si lo que realizan los Pentesters habitualmente en sus proyectos de Ethical Hacking se pueden empezar a re-emplazar por un Agentit AI que tome las decisiones a las que se enfrenta un pentester profesional en redes complejas.
Para realizar el experimento, los investigadores han recreado 10 arquitecturas de redes diferentes como objetivo, con equipos, servidores, configuraciones diferentes. Dos de ellas, inspiradas en las arquitecturas de dos ataques perpetrados por atacantes humanos que tuvieron éxito, como son los escenarios de Equifax-Inspired y Colonial Pipleline-Inspired.
Como se puede ver en la tabla anterior, en cada escenario hay un número diferentes de hosts, y un objetivo distinto, para retar al modelo de Inteligencia Artificial en cada escenario y que sus acciones deban ser totalmente diferentes. Para conseguir esto, el ataque debe pasar una serie de fases definidas en un grafo, y que no son las mismas para cada escenario. Este es un ejemplo.
En el grafo anterior, lo que tenemos es un esquema que representa al proceso multi-fase que tuvieron que realizar los atacantes en la fuga de datos de Equifax, según el informe final del caso que se hizo público. El motor LLM debería ser capaz descubrir cuál sería el proceso multi-fase del grafo que hay que generar para tener éxito en cada escenario.
Sin embargo, en las pruebas realizadas, los MM-LLMs utilizados en el experimento no se mostraron lo suficientemente inteligente para resolver el escenario. De hecho, probados OpenAI GPT4o, Antrhopic Sonnet 3.5, Google Gemini 1.5 Pro y PentestGPT, sólo uno de ellos fue capaz de resolver un escenario de cuatro fases una única vez.
Mirando los detalles de las pruebas para localizar dónde se bloquean estos modelos, los resultados son bastante reveladores, ya que normalmente se quedan entre el 1 y 30 % de las fases que deben realizar, lo que hace que la complejidad del entorno sea un reto.
Pero si miramos las razones, el resultado es aún más claro. La mayoría de los errores se producen no por una mala elección de la tarea a realizar, sino por elegir bien con qué herramienta, y una vez elegida correctamente por no escribir correctamente el comando que deben utilizar. Es decir, por tener un error o una alucinación a la hora de configurar la llamada a una herramienta.
Con este conocimiento, lo que los investigadores hicieron fue plantear la creación de una capa de APIs que simplificara el proceso de llamar a las herramientas a utilizar. Aunque no han utilizado MCP (Model Context Protocol), la arquitectura que proponen, en el mundo de "ahora mismo", sería el equivalente a crear un MCP para las herramientas de hacking.
Como podéis ver en este gráfico, extraído del podcast "Model Context Protocol (MCP), clearly explained (why it matters)", puedes ver como, después de tener al LLM como "Answering Machine", pasamos a una arquitectura donde le integramos herramientas - que sería la prueba realizada hasta el momento en este trabajo, para ir luego a estandarizar la integración con una capa de abstracción que provee las APIs necesarias para llamar a los servicios, y para tener el contexto con el que tomar sus decisiones.
En una arquitectura MCP, la capa de abstracción que crean los servicios serían las llamadas a las APIs y la entrega de respuestas en forma de Contexto para que el modelo tome su siguiente decisión. Para ello, hay que crear el MCP Client en el modelo, mediante la configuración del Prompt como vamos a ver en las Figuras 14 a 16. Esta capa de abstracción se llama Incalmo, y el funcionamiento trata de aislar los detalles de llamar a las herramientas y cómo configurar los parámetros, para darle APIs de alto nivel al LLM.
Una vez que tenemos construida esa capa de abstracción de APIs llamada Incalmo, lo siguiente que se hace es construir con el LLM un Agentic AI - similar al Agentic AI para un CRM con sus Thoughts o al Agentic AI de SmartHome que os dejé -, pero para usar Incalmo.
Esto permite que, en lugar de enseñarle a manejar una decena de herramientas diferentes, aprenda a utilizar una capa de APIs común, y configurar para ello el Prompt para que sepa manejarlas, como se hace en los Agentic AI.
El Prompt para construir el agente LLM es mucho más largo, pero queda bastante claro y explícito cómo se construye el el entorno del Agente AI basado en el LLM para que use la capa de abstracción de Incalmo, que le conecta con las herramientas de pentesting.
Ahora, el LLM tiene que resolver la inteligencia para resolver el entorno, sin preocuparse de ser un experto en los comandos de las diferentes herramientas de pentesting. Es la mezcla de "El arte del pentesting" y la "Técnica del pentesting" unidas de la mano. Y los resultados no son nada malos. Para comenzar el proceso solo hay que darle la información inicial del escenario.
Después, el LLM, de manera autónoma hace uso de los interfaces de Incalmo con los que ha sido instruido siguiendo los objetivos del Prompt, y hace uso de las diferentes herramientas mediante llamadas a APIs como tenéis en las siguientes imágenes.
Al final, al simplificarle la ejecución de las tareas, el motor LLM pierde menos su alineamiento con el objetivo, lo que le permite no perderse en el árbol y tener una visión general del bosque, y eso lleva a que los resultados sean significativamente mucho mejores.
Como se puede ver en la imagen anterior, después de 5 intentos en cada escenario, uno u otro modelo, fue capaz de resolver 9 de cada 10 escenarios de entre 25 y 50 hosts. Por ejemplo, Haiku 3.5 resolvió 5 escenarios completamente al menos una vez. Sonnet 3.5 resolvió 3 escenarios completamente al menos una vez, mientras que Gemini Pro y GPT4o resolvieron dos escenarios completamente.
Si miramos la tabla anterior, vemos que abstraer a los modelos de las herramientas incrementa significativamente su alineamiento con el objetivos y la capacidad de tomar decisiones mejores sin tener que lidiar con las llamadas a las herramientas.
Conclusiones
Con esta arquitectura vemos que un LLM autónomamente puede hackear 5 de 10 escenarios de red completamente, y 9 de 10 parcialmente, lo que es un resultado muy prometedor que puede que nos lleve a que sean capaces de superar los 10 escenarios ... ¿a finales de año tal vez?
El incremento del éxito es brutal cuando le abstraemos de la herramienta, y le permitimos pensar "estratégicamente" en el proceso de hackear un sistema, así que parece que las arquitecturas MCP para Pentesting van a ser tendencia en dentro de... ¿ya? No sé si te estás poniendo las pilas con la IA en el mundo de la ciberseguridad y el pentesting, pero deberías hacerlo ya, sí o sí.
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso 3DAIS
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
