Setuid and Setgid

An adversary may abuse configurations where an application has the setgid bits set in order to get code running in a different (and possibily more privileged) user's context. On Linux or macOS, when the setuid or setgid bits are set for an application binary, the application will run with the privileges of the owning user or group respectively. Normally an application is run in the current user's context, regardless of which user or group owns the appliation. However, there are instances where programs need to be executed in an elevated context to function properly, but the user running them may not have the specific required privileges.

Instead of creating an entry in the sudoers file, which must be done by root, any user can specify the setuid or setgid flag to be set for their own application. The chmod command can set these bits with bitmasking, chmod 4777 [file] or via shorthand naming, chmod u+s [file]. This will enable the setuid bit. To enable the setgid bit, chmod 2775 and chmod g+s can be used.

Adversaries can use this mechanism on their own malware to make sure they're able to execute in elevated contexts in the future. This abuse is often part of a "shell escape" or other actions to bypass an execution environemnt with restricted permissions.

Alternatively, adversaries may choose to find and target vulnerable binaries with the setuid or setgid bits already enabled. The setuid and setguid

An example of these binaries I've built a simple payload that will take commands as an argument but the binary will execute this with root level permissions

When a file that contains this level of privilege, we can easily find these with the "find" command

Let's look at this binary by executing commands only root can execute and directories only root can access

And example of these GTFOBINS can be shown with the find binary if this binary contains the permissions mentioned here, we can actually escape and elevate to root permissions