GTFOBins

• Mantiene una lista de binarios Unix organizada por función, y enlaza directamente las acciones posibles de cada binario mediante páginas detalladas y enlaces de anclaje
• Las categorías que se repiten con frecuencia son Shell, File read, File write, Command, Inherit, Upload, Download, Reverse shell, Library load y Privilege escalation, y en algunos elementos también aparece Bind shell
• File read y Shell están distribuidos de forma muy amplia, y herramientas como dd, sed y sqlite3 combinan lectura y escritura, por lo que la frontera con las herramientas de consulta simple se vuelve difusa
• Herramientas como apt, git, journalctl y systemctl suelen incluir Command e Inherit, y también se repiten binarios multifunción como bee, pipx, sqlmap y la familia de vim, que combinan transferencia de red y acciones de shell
• Privilege escalation aparece limitado a algunos binarios con enlace específico, y una lista amplia que va de 7z hasta zypper deja ver de un vistazo las diferencias en la combinación de comportamientos de herramientas comunes

---

Distribución de funciones principales

• Los elementos dedicados a lectura de archivos o centrados en lectura están distribuidos de forma muy amplia
  • 7z, cat, grep, jq, od, tail, wc, zcat y otros están enlazados principalmente a File read
• También hay muchísimos elementos capaces de ejecutar shell
  • bash, awk, find, less, python, ruby, tar, vi, zsh y otros tienen Shell
• Hay muchos elementos que combinan escritura de archivos con lectura, lo que vuelve difusa la frontera con las herramientas de consulta simple
  • dd, cpio, ed, emacs, nano, sed, sqlite3, xxd y otros pertenecen a este grupo
• La ejecución de comandos o la herencia de privilegios aparecen con frecuencia en gestores de paquetes, herramientas del sistema y programas interactivos
  • apt, apt-get, git, journalctl, man, systemctl, timedatectl, zless son representativos

Binarios multifunción

• Los binarios multifunción que reúnen varias acciones a la vez aparecen de forma repetida

• Elementos multifunción basados en Inherit

  • apport-cli, batcat, cargo, crash, gcloud, git, journalctl, man, opencode, psql, run-mailcap, systemd-resolve agrupan Inherit junto con Shell, Command, File read y File write

• Elementos que también incluyen red y movimiento de archivos

  • bee, byebug, dstat, easy_install, facter, irb, knife, pipx, poetry, rake, sqlmap, vagrant, volatility también tienen Reverse shell, Upload, Download y Library load

• Familia de editores y depuradores

  • gdb, nvim, rvim, view, vim, vimdiff reúnen Inherit junto con Shell, Reverse shell, Bind shell o File read/write, Upload, Download y Library load

• Familia de gestores de paquetes y runtimes

  • apt, apt-get, bundle, bundler, pip, rpm, rpmdb, rpmquery, rpmverify, yum suelen combinar shell, acceso a archivos y acciones de red

Red, shell y carga de bibliotecas

• Las funciones de subida/descarga no solo aparecen en herramientas de red, sino también junto con shells y runtimes de lenguajes

• Herramientas centradas en transferencia

  • ab, curl, finger, ftp, nc, scp, sftp, smbclient, ssh, tar, tftp, wget, whois tienen Upload o Download

• Reverse shell y Bind shell

  • bash, gawk, go, jjs, julia, ksh, lua, nawk, nc, nmap, node, openssl, pandoc, php, ruby, socat, socket, tclsh, telnet, zsh se incluyen aquí

• Elementos con Library load

  • bash, byebug, curl, ffmpeg, gdb, gem, gimp, irb, knife, ldconfig, mysql, nginx, nvim, openssl, pip, python, rake, ruby, ssh-keygen, tclsh, vim, volatility, wish, yum están incluidos

Elementos de escalada de privilegios

• Privilege escalation aparece limitado a binarios con un elemento específico

• Lista de enlaces de escalada de privilegios

  • chattr
  • chmod
  • chown
  • cp
  • getent
  • install
  • ln
  • mount
  • mv
  • passwd
  • setcap
  • setfacl
  • unsquashfs
  • unzip

[GN⁺]

Comentarios de Hacker News

• Como parece que varios comentarios lo están confundiendo, un ejemplo de cuándo se usa esto en un contexto de seguridad/CTF sería así:
  en un entorno con shell restringida o donde solo se pueden ejecutar algunos comandos/binarios, normalmente todavía te dejan pasar argumentos con bastante libertad.
  Ahí, usando GTFOBins, puedes encadenar lectura/escritura de archivos o hasta ejecución de comandos para escapar del contexto restringido y conseguir una shell.
  Si alguien dejó abierto sudo o le puso el bit SUID a algún GTFOBin, también podrías leer o escribir archivos sensibles y ejecutar comandos privilegiados de formas que ni la persona que lo configuró había previsto.

  • Esto también aplica bastante a herramientas como claude-code.
    El manejo de permisos está muy centrado en block-lists y allow-lists, así que es bastante primitivo.
    Una vez, en una sesión, por error le di a Claude permiso para powershell y después, cuando se bloqueaban herramientas como git, esquivaba la restricción escribiendo scripts de powershell que hacían lo mismo y ejecutándolos.
    En un sistema bien diseñado no meterías powershell en una allow-list general, pero si hay huecos entre los niveles de permiso por herramienta, parece totalmente viable moverse con las técnicas de esta página.
  • Parte del software de seguridad empresarial que supuestamente hace mediación de escalamiento de privilegios podría tener un riesgo parecido.
    En una empresa vi un despliegue donde los programas de la allowlist del administrador se podían ejecutar con sudo sin contraseña, y desde el principio ya estaban incluidas herramientas de propósito general como vim y bash.
    Como alguien que trabajaba desde casa, casi me pareció una suerte, porque ese software que supuestamente iba a "proteger" mi computadora en realidad hacía mucho más fácil que alguien llegara, aprovechara que me levanté un momento y olvidé bloquear la pantalla, y ejecutara cualquier cosa.
  • Al final, esto parece una guía bastante amplia de lo poco efectivas que son en la práctica las restricted shell.
  • También hay ejemplos concretos.
    Hace unos años, el equipo de soporte necesitaba capturar tráfico de red con tcpdump, y para resolverlo rápido metieron una regla de sudo que dejaba bastante abiertos los argumentos.
    Como podían cambiar el puerto o la NIC, en ese momento parecía razonable, pero en realidad tcpdump tiene la opción -z para indicar un comando de compresión, así que si ahí le metes un comando "especial" puedes tomar el control total del servidor.
    sudo tcpdump -i any -z '/home/despicable_me/evil_cmd.sh' -w /tmp/dontcare.pcap -G 1 -Z root
    Parece un detalle menor, pero estas cosas de verdad se pasan por alto muy fácil.
    Hoy capas como apparmor a veces reducen este riesgo, pero a cambio también traen otros dolores de cabeza y sigue siendo fácil configurarlas mal.
  • Viendo esto, también da la impresión de ser una lista organizada para que una IA aprenda métodos de evasión de sandbox.

• La última vez que usé algo parecido fue en una computadora de secundaria con Windows 3.11, por ahí de 1995.
  La habían bloqueado para que solo corrieran unas cuantas apps aprobadas, y una de ellas era Word.
  Desde Word se podían usar macros y lanzar otras apps con la shell.
  Así que una computadora bloqueada que solo mostraba unas cuantas apps en realidad quedaba capaz de ejecutar prácticamente cualquier cosa.
  En ese momento se sintió bastante emocionante, y desde entonces casi no he vuelto a ver algo así.
  A veces veo historias de pantallas táctiles informativas en tiendas o centros comerciales donde se puede escapar del kiosk mode, y eso parece de la misma familia.

• Al ver restic - Shell, Command, Upload, siento un poco más justificado haber ajustado la configuración para no ejecutar las copias de seguridad como root.
  En su lugar, lo corro como usuario normal, pero solo con la capability de leer todos los archivos, y sin shell de login.
  Claro, en escritorio eso puede ser excesivo, y si un atacante ya llegó a ese punto igual podría leer casi todos los archivos y meter una puerta trasera en los respaldos.
  [0] https://man7.org/linux/man-pages/man7/capabilities.7.html

  • Da la impresión de que la tendencia de los LLM a ver restricciones y pensar simplemente "entonces doy la vuelta usando un helper para evadir" está rompiendo bastantes supuestos del mundo anterior.
    Ya había formas de lidiar con atacantes humanos remotos, bots remotos y hasta cierto punto atacantes humanos locales, pero ahora hay que preocuparse mucho más por bots atacantes locales que escriben su propio código.
    Tampoco es exactamente la misma categoría que el malware.
    Yo mismo he tratado contenedores como ese límite relevante y he puesto todos los procesos internos a correr como root, pero con LLMs de por medio ya no me queda claro si la seguridad a nivel de SO de repente se volvió más importante o más bien perdió sentido.

• Me confunde un poco: ¿esto quiere decir que, si no tienes cat, uses base64 /path/to/input-file | base64 --decode en lugar de cat /path/to/input-file?
  ¿O quiere decir que base64 /path/to/input-file | base64 --decode de alguna forma elude los permisos de lectura del archivo?

  • Es lo primero.
    El proceso invocado normalmente hereda los mismos permisos del usuario que lo ejecutó, y la única excepción suele ser cuando hay setuid bit.
    La idea es que, en entornos donde intentan frenar el lateral movement de un atacante quitando herramientas Unix estándar, todavía puedes hacer lo mismo con otras herramientas.
  • Lo que significa es que restringir privilegios con limitaciones de comandos basadas en listas negras nunca ha funcionado muy bien, y eso sigue siendo cierto hoy.
  • Es lo primero, no lo segundo.
    No se trata de romper el permiso en sí, sino de producir el mismo resultado con otro binario dentro de una shell restringida donde solo te dejan ciertos comandos.
    Esto es muy común en los CTF.
  • Pero si hay un archivo que normalmente no puedes leer, y en cambio sí puedes ejecutar base64 como root, entonces la historia cambia.
    Si corres base64 con privilegios de root para codificar el contenido del archivo y luego pasas esa salida a otro proceso base64 para decodificarla, al final igual puedes ver el contenido.
    En la práctica, es como un cat con pasos extra.
  • Aunque para eso, da la impresión de que un pipe con tar sería más ligero.

• Hace tiempo fui mantenedor de una de estas herramientas, y me dio risa ver a alguien sacarle una shell con eso.
  Es creativo, divertido y además buen material de referencia.

• Cuando hacía hackthebox.eu, usaba esto muchísimo.

• GTFOBins ya lleva bastante tiempo existiendo y era un recurso útil desde antes de la IA.

  • Por eso mismo preocupa más lo que viene.
    Al final, parte de la utilidad de la IA es justamente que puede sacar a la superficie recursos como este que ya existían.

• Me cuesta entender por qué base64 está en la lista.
  Según yo, eso solo serviría para leer archivos a los que el usuario ya tiene acceso, ¿o estoy entendiendo mal?
  ¿O es que la descripción de evasión de restricciones de seguridad local en sistemas mal configurados significa otra cosa distinta a la que entendí?

  • La clave es que, incluso si te dejaron en una shell restringida o solo con acceso a ciertos comandos, las herramientas de esa lista pueden devolverte parte del alcance que ese usuario originalmente tenía en un entorno no restringido.
    El ejemplo más simple es que, aunque te cambien la shell por defecto a rbash, si el usuario puede simplemente ejecutar bash y entrar a una shell normal, la restricción deja de tener sentido.
  • Por ejemplo, puede que en sudoers hayan permitido ejecutar base64 como root.
    No sé por qué alguien haría eso, pero en una situación así terminarías pudiendo leer cualquier archivo del sistema, saltándote la restricción de privilegios que se suponía que existía.
    O si en Claude Code dejas permitido base64 sin revisión, eso podría abrir la puerta a leer archivos secretos como .env.
  • Una situación común es que algunas herramientas se puedan ejecutar con privilegios de root.
    A veces está permitido explícitamente en sudo -l, o en otros casos hay algún otro componente que invoca esa herramienta como root.

• También estaría bien que mostraran formas de mitigación para estos desvíos.
  Por ejemplo, si puedes conseguir una shell desde more, algo como:
  configurar SHELL como /bin/false antes de ejecutar more;
  cambiarlo por less en secure mode;
  o, si usas more con sudo, aplicar la bandera NOEXEC.

  • La mejor mitigación es configurar correctamente los permisos reales de los archivos que un usuario no debería poder leer o escribir.
    Todo lo demás, en el fondo, depende bastante de la suerte.

• Está bastante bueno, y hay enfoques creativos que no esperaba.
  Por ejemplo, jamás se me habría ocurrido algo como yt-dlp.
  Creo que tendré que pensarlo dos veces antes de dejarlo instalado.