Entre Marilyn & Manson: Vulnerando IPv6 con Man-in-the-middle usando NDP en la red de tu casa con Kali Linux

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.

Figura 1: Entre Marilyn & Manson - Vulnerando IPv6 con Man-in-the-middle

usando NDP en la red de tu casa (atacando con Kali Linux)

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.

Figura 2: Contactar con Carlos Ralli Ucendo

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

Figura 3: Foto de la ponencia IPv6 Council llamada “Firechat - Coloquio: entendiendo Shadow-IPv6 como viento a favor” en MTW/OpenExpo con Tony de la Fuente, Carlos Ralli, Federico Teti, Chema Alonso, Fran Gómez y Rafa Sánchez

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.

Escasa Documentación

Lamentablemente, no se dispone de mucha documentación al respecto a día de hoy. La IPv6 Council toma como referencia el libro Ataques en redes de datos IPv4 e IPv6 publicado por 0xWord y escrito por Juan Luis García Rambla, Chema Alonso y Pablo González. 

Figura 4: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

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

Figura 5: Índice del libro "Ataques en redes de datos IPv4&IPv6 (4ª Edición)" 

En la charla impartida en MTW/OpenExpo (en la sala Microsoft Room) Chema Alonso estuvo comentando acerca de la preocupación por no disponerse de mucha materia sobre el tema. Mencionó uno de los últimos libros escritos por la editorial: “Hacking Home Devices I: PoCs & Hacks Just for Fun” & “Hacking Home Devices II: PoCs & Hacks Just for Fun” escritos por Gerard Fuguet (escritos por mí ;) ) y antes de que siguiera hablando, yo, levanté la mano… “Ah que estás aquí” dijo el Dr. dr. Maligno. 

Figura 6: Hacking Home Devices I: PoCs & Hack Just for Fun!

Escrito por Gerard Fuguet.

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.

Figura 7: Índice del libro Hacking Home Devices I: PoCs & Hack Just for Fun!

Escrito por Gerard Fuguet.

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.

Figura 8: ¿Quieres aprender informática desde cero? De David Casas M.

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

- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (1)
- Hacking en redes de datos IPv6: Conceptos básicos IPv6 (2)
- Hacking en redes de datos IPv6: Te hackearán por IPv6 por creer que no lo usas
- Hacking en redes de datos IPv6: Neighbor Spoofing
- Hacking en redes de datos IPv6: Captura de SMB con Neighbor Spoofing
- Hacking en redes de datos IPv6: FC00::1 (Algunos) Ataques en redes de datos
- Hacking en redes de datos IPv6: Man in the middle en redes IPv4 usando IPv6
- Hacking en redes de datos IPv6: Desactivar IPv6 para evitar D.O.S. SLAAC
- Hacking en redes de datos IPv6: Topera - Scanner de puertos sobre IPv6
- Hacking en redes de datos IPv6: Predecir direcciones IPv6 Local-Link de OS X
- Hacking en redes de datos IPv6: Ataques en redes de datos IPv 4 e IPv6
- Hacking en redes de datos IPv6: Evil FOCA: Ataque SLAAC
- Hacking en redes de datos IPv6: Evil FOCA: Bridging HTTP(IPv6) - HTTPs (IPv4)
- Hacking en redes de datos IPv6: Pasar de IPv4 a IPv6 con una respuesta DNS
- Hacking en redes de datos IPv6: Cómo activar IPv6 en Google Chrome
- Hacking en redes de datos IPv4: Ataque DHCP ACK Injector

No obstante, si quieres aprender todos los conceptos de IPv6, en este blog tienes esta serie de artículos que hizo Chema Alonso durante tiempo preparando su charla de Defcon 21 de "Fear the Evil FOCA: Attacking Internet connection with IPv6" que podéis ver también en Español cuando la impartió en Ekoparty.

Figura 9: "Fear the Evil FOCA: Attacking Internet connection with IPv6"

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. 

Figura 10: Hacking Home Devices II: PoCs & Hack Just for Fun!

Escrito por Gerard Fuguet.

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.

Figura 11: Índice del libro Hacking Home Devices II: PoCs & Hack Just for Fun!

Escrito por Gerard Fuguet

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…). 

Figura 13: Darse de alta en la conversación Pública de El lado del mal

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. 

Maria Gomez Prieto, Marta Tobarias, Chema Alonso y Gerard Fuguet

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)

con Maria Gomez Prieto y Mikeldi en la MTW/OpenExpo 2025

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. 

Figura 17: Pentesting con Kali Silver Edition

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

Figura 19: Escenario del ataque que vas a ver a continuación.

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?

Figura 20: Entre Marilyn & Manson: Vulnerando IPv6 conMan-in-the-middle usando NDP en la red de tu casa con Kali Linux

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!!!

And Remember… Be Good. Be Hackers!!!

Autor: Gerard Fuguet (Contactar con Gerard Fuguet) Escrito de los libros “Hacking Home Devices I: PoCs & Hacks Just for Fun” & “Hacking Home Devices II: PoCs & Hacks Just for Fun”

¿Se puede reemplazar a un Pentester con un Agente de IA basado en LLMs? Cómo realizar ataques completos a redes complejas con agentes de Inteligencia Artificial

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.

Figura 1: Cómo realizar ataques completos a redes

complejas con agentes de Inteligencia Artificial

El trabajo, que lleva por título: "On the Feasibility of Using LLMs to Execute Multistage Network Attacks" intenta resolver la pregunta de si un LLM, con acceso a las herramientas utilizadas en los ataques realizados a las redes de organizaciones que hemos conocido recientemente, sería capaz de tener éxito en su ataque, y si no fuera así, qué habría que hacer para que incrementara su probabilidad de conseguir el objetivo. Ya hemos visto estudios anteriores para ver un LLM puede hackear autonomamente un Web Site o para ver si un LLM puede crear y ejecutar exploits de 1-day a partir de sus CVEs.

Figura 2: On the Feasibility of Using LLMs to Execute Multistage Network Attacks

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.

Figura 3: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

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.

Figura 4: Escenarios de redes creados para la prueba.

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.

Figura 5: Grafo multi-fase del ataque a Equifax

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.

Figura 6: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

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.

Figura 7: Los LLMs no fueron muy exitosos, aunque Sonnet

consiguió una vez resolver un escenario de cuatro fases.

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.

Figura 8: Los modelos se suelen bloquear entre el 1-30% de las fases

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.

Figura 9: Porcentaje de aciertos y errores (y motivos) en

escenario más complejo (Equifax) y más sencillo (4 fases)

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.

Figura 10: De integrar tools al LLM a usar MCP

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.

Figura 11: El MCP Client está en la configuración del LLM.

El MCP Server es la capa de abstracción del servicio

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.

Figura 12: Arquitectura con Incalmo para atacar redes

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. 

Figura 13: Definición de APIs en 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.

Figura 14: Prompt para instruir al LLM sobre cómo usar Incalmo (parte 1)

Figura 15: Prompt para instruir al LLM sobre cómo usar Incalmo (parte 2)

Figura 16: Prompt para instruir al LLM sobre cómo usar Incalmo (parte 3)

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.

Figura 17: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

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.

Figura 18: Información inicial que da Incalmo al LLM

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.

Figura 19: Llamada del LLM a Incalmo para escanear 

a red y hosts encontrados en la respuesta

Figura 20: Búsqueda de servicios

Figura 21: Ataque a un servicio web detectado

Figura 22: Búsqueda de credenciales

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.

Figura 23: Resultados tras 5 intentos

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. 

Figura 24: Incremento de éxito con Incalmo en las fases de la intrusión

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? 

Figura 25: Libro de Machine Learning aplicado a Ciberseguridad de

Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

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

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

IPv6 Council Madrid 2024: Una charla sobre despliegue, seguridad y hacking en redes IPv6

Durante la pasada OpenExpo Europe 2024, donde cómo podéis ver sucedieron muchas cosas, como la presentación del libro de Hacking Web3: [New] Challenge Acepted! o la mesa de debate con INCIBE sobre el programa de capacitación en ciberseguridad para empresas, también participé en el IPv6 Council MeetUp que este año se realizó dentro de OpenExpo Europe 2024, y donde estuve con Carlos Ralli, Fran Gómez, o Rafa Sánchez, entre otros ponentes.

Figura 1: IPv6 Council Madrid 2024 - Una charla sobre

despliegue, seguridad y hacking en redes IPv6

La verdad es que estuvo todo superbien organizado y he de felicitar a estos tres compañeros de muchas batallas por su trabajo en empujar IPv6 en el mundo de la empresa, donde además ellos en primera persona llevan muchos años trabajando.

Figura 2: Contactar con Carlos Ralli Ucendo

Si quieres colaborar con ellos, puedes contactar con Carlos Ralli, Fran Gómez, o Rafa Sánchez, que todos ellos tiene su buzón en MyPublicinbox, y así ser parte de este movimiento que intenta empujar el uso de IPv6 para mejorar la seguridad de las redes que tenemos hoy en día.

Figura 3: [2024] Chema Alonso en el IPV6 Council

La sesión de preguntas y respuestas no está grabada entera, pero uno de los asistentes la grabó, y la he subido a mi canal youtube en dos formatos. El que tienes arriba por si la quieres ver la televisión en un monitor "horizontal", y el que te dejo al final del artículo por si la quieres ver en "vertical".

Figura 4: Contactar con Fran Gómez

Como os podéis imaginar, hablamos de este libro que escribimos para los que se adentran en este mundo del hacking y auditoría de redes IPv4 e IPv6 - que a veces se hace menos común para muchos jóvenes pentesters - y que va ya por la 4ª Edición.

Figura 5: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

El libro lo lanzamos inicialmente en Informática 64, y lo hemos ido actualizando periódicamente en 0xWord. Tiene mucho de ataques en redes IPv4, pero explica también lardo y detallado el funcionamiento de IPv6, que sigue siendo uno de los talones de Aquiles de muchos jóvenes que vienen a entrevistas de trabajo. Cuando les pido que me expliquen cómo se hace un ataque de man in the middle en IPv6 no todos están sueltos para explicarme las diferentes alternativas.

Figura 6: Índice del libro "Ataques en redes de datos IPv4&IPv6 (4ª Edición)" 

Aquí tienes el índice del libro de Ataques en redes de datos IPv4&IPv6 (4ª Edición), que además tiene 100 Tempos gratuitos en todas las compras que puedes utilizar para consultar dudas a través de MyPublicInbox, donde estamos Pablo González y yo. En esta edición he hecho un pequeño prólogo, y lo mejor es que los ataques de man in the middle siguen estando tan de actualidad como siempre, que aún seguimos jugando con el Network Packet Manipulation en muchos entornos...

Figura 7: Contactar con Rafa Sánchez

Por último, os dejo la grabación original en vertical, por si quieres ver la en un terminal móvil, aunque esto no es muy Generación X, pero si eres de la siguiente, todo tuyo.

Figura 8: [2024] Chema Alonso en el IPV6 Council [vertical]

Y eso es todo por hoy domingo que, recordad, hay un partido esta noche entre España e Inglaterra que sólo puede acabar de una manera posible...(esperamos).

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Microsoft declara oficialmente obsoleto el protocolo de autenticación NTLM en Windows

Hace unos días, Microsoft anunció que finalmente optará por “deprecar” NTLM. Aunque esto pueda parecer un cambio drástico en la postura de Windows y su conocida retro-compatibilidad, lo cierto es que se trataba de “una muerte anunciada”. Este cambio era previsible, y tanto Microsoft como sus empleados lo han estado manifestando desde octubre de 2023 a través de diferentes medios. 

Figura 1: Microsoft declara oficialmente obsoleto el protocolo

de autenticación NTLM en Windows

Podemos verlo en esta charla de Steve Syfuhs, Principal Engineer en Microsoft, y también en este post del blog de Microsoft escrito por Matthew Palko, donde ambos hablan de la evolución de la autenticación en Windows y cómo NTLM está quedando relegado por Kerberos. NTLM siempre ha sido uno de los grandes problemas de seguridad que obliga a tomar medidas de fortificación en Windows para evitar riesgos.

Figura 2: "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición"

de Sergio de los Santos en 0xWord.

Sin embargo, no ha sido hasta ahora, el 11 junio de 2024, que Microsoft, en su lista de funcionalidades “deprecated” para Windows ha anunciado oficialmente la desaparición y “deprecación” del mítico protocolo de autenticación NTLM, que será oficialmente reemplazado por Kerberos siempre que sea posible. Esto significa, que Microsoft dejará de mantener de forma activa este protocolo y priorizará el soporte de otros como Kerberos.

Figura 3: Anuncio de que NTLM está en la lista de

funciones deprecadas en Windows

Si bien en el anuncio se comenta que seguirá funcionando en la próxima versión de Windows Server y en la próxima versión anual de Windows, es cierto que todas las llamadas a NTLM deberían intentar autenticarse haciendo uso de Kerberos, de esta forma solo se recurriría a NTLM en los casos que sea estrictamente necesario.

Funcionamiento y Riesgos de NTLM

Ya sabéis que NTLM, tuvo un predecesor (y también unos cuantos sucesores o alternativas), todos conoceréis LM o LAN Manager. Este protocolo que nació en 1987 cuando Microsoft, junto con IBM, desarrollaban un sistema operativo de redes, el denominado OS/2. No tardaron en mostrarse al mundo las vulnerabilidades inherentes del algoritmo de hash LM. 

Para crear estos hashes, comenzamos con la primera de las restricciones, contraseñas de un máximo de 14 caracteres. Luego, a pesar de permitir introducir mayúsculas y minúsculas, todas las letras se convertían a mayúsculas, por lo que el conjunto de caracteres se reducía a la mitad, y contraseñas como “HaCkEr” o “hacker” generaban el mismo hash. 

Por último, y para más “inri”, se generaban dos hashes concatenados al segmentar la contraseña de 14 caracteres en dos de 7 caracteres cada una. El resultado, cómo podéis imaginar, todo un protocolo digno de aplicar un ataque de fuerza bruta. En la siguiente imagen os dejo una explicación básica de este algoritmo:

Figura 4: Funcionamiento del Hash LM

Microsoft tenía que hacer algo, y nació NTLM (New Technology LAN Manager), el protocolo de autenticación sucesor de LAN Manager. Este protocolo, que apareció por primera vez en 1993 junto a Windows NT 3.1, utiliza un mecanismo de desafío-respuesta para autenticar a un cliente en un servidor mediante una contraseña. El flujo de funcionamiento de NTLM es el siguiente:

1) El cliente comienza una negociación con un servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades y características de seguridad soportadas. 

 

2) Una vez negociados los detalles de la comunicación (por ejemplo, la versión de LDAP a utilizar), el servidor responde con un CHALLENGE_MESSAGE, que incluye un nonce (un número aleatorio) que el cliente tendrá que cifrar con el hash de su contraseña (que debe ser igual al hash NTLM guardado en la SAM). Este nonce es de 8 bytes en NTLMv1 y de 16 bytes en NTLMv2. 

 

3) Tras esto, el cliente responde con un AUTHENTICATE_MESSAGE, que contiene el nonce cifrado con el hash NT de la contraseña del usuario, junto con otros datos de autenticación.

• En el caso de un entorno de Active Directory, el servidor envía el desafío y la respuesta enviada por el cliente al controlador de dominio para que este verifique su validez.
• El controlador de dominio verifica la respuesta y envía la confirmación de autenticación al servidor.

4) Finalmente, si la verificación enviada por el controlador de dominio es correcta, el servidor validará correctamente al usuario o, por el contrario, devolverá un error.

Figura 5: Flujo de autenticación NTLM

Como se puede comprobar, en este proceso de autenticación NTLM no se ha utilizado en ningún momento la contraseña del usuario de manera directa, sino que se emplea para crear su hash NTLM, hash que está almacenado en la SAM (Security Account Manager) del equipo. Debido a la ausencia de “salting” y que el hash NTLM y la contraseña son equivalentes a nivel de secreto en el protocolo NTLM, el conocido ataque PassTheHash tiene sentido. En este tipo de ataque, un atacante que ha obtenido el hash NTLM de un usuario puede autenticarse como ese usuario sin necesidad de conocer su contraseña en texto plano.

Figura 6: Hacking Windows: Ataques a sistemas y redes Microsoft 2ª Edición

escrito por Carlos García, Valentín Martín y Pablo González en 0xWord.

Por último, comentar acerca del sucesor definitivo de NTLM, Kerberos, un protocolo de autenticación creado por el MIT en 1989, de código abierto y mantenido por una gran comunidad, entre la cual se encuentra Microsoft que desarrolla su propia versión (compatible en gran medida con la “oficial”).

Kerberos, deja atrás el método de desafío-respuesta propio del protocolo de autenticación NTLM y pasa a utilizar un sistema de tickets para autenticar a los usuarios. En Kerberos encontramos componentes claves como el centro de distribución de claves (KDC), el servidor de autenticación (AS), el servidor de concesión de tickets (TGS), … Todo esto, da para verlo con más detalle en otro post.

Figura 7: Misión de Kerberos.org

La misión de Kerberos es establecerse como la plataforma universal de autenticación en todas las redes del mundo, así lo comentan kerberos.org. Actualmente, Kerberos es el protocolo de autenticación principal por defecto, mientras que NTLM interviene en circunstancias específicas. Por ejemplo, se utiliza NTLM cuando se autentica a través de sistemas configurados en un grupo de trabajo en lugar de un dominio, en la autenticación local en controladores que no forman parte de un dominio o en aplicaciones que no soportan otros tipos de protocolos.

Tú mismo puedes hacer uso de un Fiddler (un proxy que registra todo el tráfico HTTP/HTTPS entre el equipo e Internet) para recopilar todas las peticiones realizadas, y mediante la observación de las cabeceras, detectar en qué casos se está usando Kerberos o NTLM. En una cabecera de autorización, si el token comienza por “YII” estaremos ante un caso donde se está utilizando Kerberos. Si, por el contrario, comienza por “TlR” estaremos ante un protocolo de autenticación distinto a Kerberos (normalmente NTLM). Por ejemplo:

• Cabecera de autenticación de Kerberos:
• Authorization: Negotiate YIIVDAYGKwYBE...

• Cabecera de autenticación no perteneciente a Kerberos:
• Authorization: Negotiate TlRMTVNTUA...

Volviendo a la noticia, con este anuncio, Microsoft se ha comprometido a trabajar para eliminar y mitigar todos estos escenarios que hacen uso de NTLM en componentes de Windows, y en el momento que lo vean oportuno lo deshabilitaran por completo. Este movimiento ha provocado toda una ola de reacciones entre los usuarios. Algunos elogian este cambio, otros se preguntan por qué ahora y no hace 20 años, y otros defienden el uso de NTLM, criticando la falta de retro-compatibilidad que esta modificación implicará para los equipos más antiguos.

Figura 8: Libro de Ethical Hacking 2ª Edición  de 0xWord
escrito por Pablo González Pérez

Ahora toca esperar y ver cómo Microsoft sigue moviendo ficha hasta que veamos por completo la eliminación de NTLM. No obstante, es un cambio positivo ya que pasamos de utilizar un protocolo de autenticación donde el conocimiento del hash del usuario rompe por completo la seguridad; a utilizar por defecto un protocolo más seguro como es Kerberos. Y para los Ethical Hacking, pues a ponerse las pilas con Pass-the-ticket.

Saludos,

Autor: Javier Álvarez Páramo (Investigador en el IdeasLocas)

Contactar con Javier Álvarez Páramo