Seeing the confusion in the comments I want to provide some examples of situations where this might come up in a security or CTF context:
* You have a restricted shell or other way to execute a restricted set of commands or binaries, often with arbitrary parameters. You can use GTFOBins in interesting ways to read files, write files, or even execute commands and ultimately break out of your restricted context into a shell.
* Someone allowed sudo access or set the SUID bit on a GTFOBin. Using these tricks, you may be able to read or write sensitive files or execute privileged commands in a way the person configuring sudo did not know about.
This is pretty relevant for things like claude-code, which has a fairly rudimentary way of dealing with permissions with block-lists and allow-lists.
I once accidentally gave my claude "powershell" permissions in one session, and after that any time it found it was blocked from using a tool, e.g. git, it would write a powershell script that did the same thing and execute the script to work around the blocked permission.
Obviously no sane system would have "powershell" in a generic allow-list, but you could imagine some discrepancy in allowed levels between tools which can be worked around with the techniques on this page.
Power Shell or Python scripts to work around restrictions are the go to for LLMs.
And it doesn't stop there.
Yesterday I was trying to figure out some icons issue in KDE plasma (I know nothing about KDE). Both Claude and Codex would run complex bus and debug queries and write and execute QML scripts with more and more tools thrown into the mix.
There's no way to properly block them with just allow- and block lists
I am confused. Is this saying that if you don't have access to `cat`, instead of `cat /path/to/input-file` you can use `base64 /path/to/input-file | base64 --decode`?
Or is it saying that `base64 /path/to/input-file | base64 --decode` can bypass read file permission flags?
It's the former. Not bypassing permissions but in shells that might be highly restricted to just a couple commands. Like others have said, very very common in CTFs.
The first thing. Invoked processes inherit the permissions of the user who invoked them (unless they have the setuid bit). It's just in case you land access to a computer which has all the standard Unix tools disabled to stop attackers from lateral movement.
If there's a file your user does not have read access to, but you have the ability to run the `base64` binary as root, you can run `base64` as root, (thus encoding the file contents as base64), then pipe the output to another base64 process to decode the file contents.
So yes, the end result is just `cat` with extra steps.
I'm not sure I get it. base64 is on the list. That can't do anything but read a file to which the user already has access, I think. Am I mistaken or does "a curated list of Unix-like executables that can be used to bypass local security restrictions in misconfigured systems" not mean what I think it does?
I think the idea is that if you're given an improperly configured restricted shell/command access, you can use any of the listed tools to gain access to some subset of what that user would normally have access to in an unrestricted environment.
A very simple version of this would be if you set a user's default shell to "rbash" but the user can just run "bash" to get a real shell.
Maybe sudoers is configured to allow you to run base64 as root. Why would someone do this? No idea. But if you are in such a situation, now you know how to bypass the intended permissions and read any file on the system.
Or maybe you give Claude Code permission to run `base64` without review without realizing this lets it read any file, including maybe your secrets in .env or something.
As someone who has had to do some grub editing on the computer in an AirBnB because peripherals were all messed up on the guest account (no internet, no sound, you could only see a tiny part of the screen, I honestly don't know how they had managed to do it) I am super pleased to see this resource. Stuff like this is a bit, you know, hopefully you never need this, but when you do, it is so useful to have it.
Like it says in the preamble on the site, don't think of this as a collection of exploits, but rather as a compendium of knowledge about escalation techniques for use in emergencies.
I can't tell you how many times I burned my fingers as a young Unix developer in the 80's by untar'ing things wrongly, or fat-fingering an 'rm -rf /' and thus having a running system that will be catastrophic if I don't fix it before reboot, shell still active and .. what do? Consult this list of great advice and use it to rebuild the system and/or do things that need to be done that otherwise wouldn't be possible ..
GTFOBins is not just for hacking. Its also for system repair and recovery. I'd be as likely to consult this knowledge base after a hacker attack as before, if not more ..
Not just shell access, but the server would need to be configured to also enable your user to run any of these binaries as root (such as an administrator putting them in the sudoers file).
So they're a pretty niche attack vector, and oftentimes crop up as a result of lazy/incompetent sysadmins.
These come up in CTFs all the time. One trick I don't see here is you can use `dd` to write into the `/proc` hierarchy to achieve all sorts of fuckery including patching shellcode into a running process.
You learn the most random ways to abuse program features, one I still remember because of how long it took to figure it out was an htb box that (after a long exploitation path) used NTFS ADS to hide the flag within the alternate stream in a decoy file; and of course the normal way to extract the stream was disabled so had to do some black magic with other binaries to get it
Hey you know what, I've used dd to write into process memory but haven't actually used it to disable KASLR, so it's possible I am misremembering. My bad.
I think docker was used for these things before. I remember some big service had secrets in env vars and a shell access inside the docker image from a npm post install script let them evacuate these secrets
It's only relevant as a privilege escalation vector when you're able to execute those programs as root, but don't otherwise have root access on the server.
It's a pretty niche circumstance. Unless an admin allows users on a server to execute some of these random types of binaries as root, it's not going to be a concern. And, if it wasn't already obvious, distros are almost never configured this way OOTB
I've seen plenty of servers in companies configured to allow sudoers to run a restricted subset of binaries as root, usually without a password. Some of them were GTFObins that the admins were not aware of until I reached out to let them know. I've also seen a couple of restricted shell setups where users could only run a handful of commands. Can't recall if I checked to see if any of them were GTFObins.
I wouldn't say this is the most useful h4x0r tool ever, but I wouldn't say it's particularly niche, either. This kinda stuff is definitely relevant in older large enterprise-type Linux/Unix environments.
Seeing the confusion in the comments I want to provide some examples of situations where this might come up in a security or CTF context:
* You have a restricted shell or other way to execute a restricted set of commands or binaries, often with arbitrary parameters. You can use GTFOBins in interesting ways to read files, write files, or even execute commands and ultimately break out of your restricted context into a shell.
* Someone allowed sudo access or set the SUID bit on a GTFOBin. Using these tricks, you may be able to read or write sensitive files or execute privileged commands in a way the person configuring sudo did not know about.
This is pretty relevant for things like claude-code, which has a fairly rudimentary way of dealing with permissions with block-lists and allow-lists.
I once accidentally gave my claude "powershell" permissions in one session, and after that any time it found it was blocked from using a tool, e.g. git, it would write a powershell script that did the same thing and execute the script to work around the blocked permission.
Obviously no sane system would have "powershell" in a generic allow-list, but you could imagine some discrepancy in allowed levels between tools which can be worked around with the techniques on this page.
Power Shell or Python scripts to work around restrictions are the go to for LLMs.
And it doesn't stop there.
Yesterday I was trying to figure out some icons issue in KDE plasma (I know nothing about KDE). Both Claude and Codex would run complex bus and debug queries and write and execute QML scripts with more and more tools thrown into the mix.
There's no way to properly block them with just allow- and block lists
In a previous employer, they block the chmod command. I took the habit to python -c "import os; os.chmod('my_file',744)".
Glad to see LLM re-discover this trick.
I am confused. Is this saying that if you don't have access to `cat`, instead of `cat /path/to/input-file` you can use `base64 /path/to/input-file | base64 --decode`?
Or is it saying that `base64 /path/to/input-file | base64 --decode` can bypass read file permission flags?
This is saying that restricting privileges by blacklisting commands do not work (and never worked).
It's the former. Not bypassing permissions but in shells that might be highly restricted to just a couple commands. Like others have said, very very common in CTFs.
The first thing. Invoked processes inherit the permissions of the user who invoked them (unless they have the setuid bit). It's just in case you land access to a computer which has all the standard Unix tools disabled to stop attackers from lateral movement.
Wouldn't a tar pipe be even lighter?
If there's a file your user does not have read access to, but you have the ability to run the `base64` binary as root, you can run `base64` as root, (thus encoding the file contents as base64), then pipe the output to another base64 process to decode the file contents.
So yes, the end result is just `cat` with extra steps.
Haha, as a former maintainer to one of these tools, it makes me laugh to see someone pop a shell. Creative, nice work, nice resource.
I'm not sure I get it. base64 is on the list. That can't do anything but read a file to which the user already has access, I think. Am I mistaken or does "a curated list of Unix-like executables that can be used to bypass local security restrictions in misconfigured systems" not mean what I think it does?
I think the idea is that if you're given an improperly configured restricted shell/command access, you can use any of the listed tools to gain access to some subset of what that user would normally have access to in an unrestricted environment.
A very simple version of this would be if you set a user's default shell to "rbash" but the user can just run "bash" to get a real shell.
Maybe sudoers is configured to allow you to run base64 as root. Why would someone do this? No idea. But if you are in such a situation, now you know how to bypass the intended permissions and read any file on the system.
Or maybe you give Claude Code permission to run `base64` without review without realizing this lets it read any file, including maybe your secrets in .env or something.
As someone who has had to do some grub editing on the computer in an AirBnB because peripherals were all messed up on the guest account (no internet, no sound, you could only see a tiny part of the screen, I honestly don't know how they had managed to do it) I am super pleased to see this resource. Stuff like this is a bit, you know, hopefully you never need this, but when you do, it is so useful to have it.
But you would already have to have shell access to the system to execute those commands, right?
You might have WiFi access to mtr, allowing you to traceroute as root but not launch a shell or read files. But with these tools you can escalate.
But that sort of access is only a social engineer away. People still click on stuff in emails, or run commands because a computer says so.
Like it says in the preamble on the site, don't think of this as a collection of exploits, but rather as a compendium of knowledge about escalation techniques for use in emergencies.
I can't tell you how many times I burned my fingers as a young Unix developer in the 80's by untar'ing things wrongly, or fat-fingering an 'rm -rf /' and thus having a running system that will be catastrophic if I don't fix it before reboot, shell still active and .. what do? Consult this list of great advice and use it to rebuild the system and/or do things that need to be done that otherwise wouldn't be possible ..
GTFOBins is not just for hacking. Its also for system repair and recovery. I'd be as likely to consult this knowledge base after a hacker attack as before, if not more ..
Not just shell access, but the server would need to be configured to also enable your user to run any of these binaries as root (such as an administrator putting them in the sudoers file).
So they're a pretty niche attack vector, and oftentimes crop up as a result of lazy/incompetent sysadmins.
These come up in CTFs all the time. One trick I don't see here is you can use `dd` to write into the `/proc` hierarchy to achieve all sorts of fuckery including patching shellcode into a running process.
You learn the most random ways to abuse program features, one I still remember because of how long it took to figure it out was an htb box that (after a long exploitation path) used NTFS ADS to hide the flag within the alternate stream in a decoy file; and of course the normal way to extract the stream was disabled so had to do some black magic with other binaries to get it
I don't think I've used any of these in a CTF tbh
I've definitely used one or two in the last 6 months
For what kind of challenge? Most of these are not even available in CTF environments
https://ippsec.rocks/
I don't see a simple way to link directly to a search, but you'll find a good chunk of examples typing in "gtfo"
I've used them for pwncollege CTFs but pwncollege is way below your level (I've seen some of your write ups before).
Huh? How does that work exactly? I've heard of /proc fuckery before but didn't know you could disable aslr with it.
If you have /proc available, you don't even need to disable ASLR (all mappings are available to you)
Hey you know what, I've used dd to write into process memory but haven't actually used it to disable KASLR, so it's possible I am misremembering. My bad.
:(
Sounds super 1337 and I hope it's actually possible somehow.
Parse /proc/<pid>/maps to find the relevant target_addr in your process-under-attack. And then its a matter of:
See also: DDExechttps://github.com/arget13/DDexec
Ok. It have hundrends o example for all sort of tools, 7z, dig, git. Those are very popular.
Question from security newbie. Why it is not used to hack all sort of servers all the time then?
You need initial access. This is just a list of tools you can use if you can't spawn a standard interactive shell, for whatever reason.
It doesn't make it easier to "hack" servers, it's just a list of things that you could use once you're already inside.
I think docker was used for these things before. I remember some big service had secrets in env vars and a shell access inside the docker image from a npm post install script let them evacuate these secrets
In certain circumstances, they might be :-)
But you can't "hack a server" using just these techniques: they would be a (small) part of a chain of exploits.
Because you have to have shell access to the server to use any of these.
It's only relevant as a privilege escalation vector when you're able to execute those programs as root, but don't otherwise have root access on the server.
It's a pretty niche circumstance. Unless an admin allows users on a server to execute some of these random types of binaries as root, it's not going to be a concern. And, if it wasn't already obvious, distros are almost never configured this way OOTB
I've seen plenty of servers in companies configured to allow sudoers to run a restricted subset of binaries as root, usually without a password. Some of them were GTFObins that the admins were not aware of until I reached out to let them know. I've also seen a couple of restricted shell setups where users could only run a handful of commands. Can't recall if I checked to see if any of them were GTFObins.
I wouldn't say this is the most useful h4x0r tool ever, but I wouldn't say it's particularly niche, either. This kinda stuff is definitely relevant in older large enterprise-type Linux/Unix environments.
See also:
LOLBAS (https://lolbas-project.github.io/)