Offensive Linux tricks every defender should know about

Offensive Linux tricks every defender should know about

Everyone doing a proper job of administrating nix-like systems should know these scenarios. The list below was put together based on my own experience. It is a set of tricks and features that becomes handy when attacking nix-like systems (most of these techniques were very useful during our Red Team operations). Obviously, I highly recommend visiting https://gtfobins.github.io/ to discover many more interesting capabilities of regular system commands and utilities one can find in most nix-like systems.

All the scenarios are considered and described from an attacker perspective.


Messing with file modification dates

Let’s consider a scenario when we as attackers got root on a GNU/Linux system. We want to persist by adding our backdoor (reverse shell, C2 implant, whatever really) into some existing cron script, e.g. /etc/cron.daily/logrotate:

Atos cybersecurity Blog Security Dive-Offensive Linux 1

As we can see in the screenshot, that file was last time modified on 5thMay 2015. We want to add our backdoor code into /etc/cron.daily/logrotate (which will change the modification timestamp). Then we will restore the old modification date, so the file will appear like it wasn’t tampered with, making the intrusion more difficult to notice and investigate.

Ever heard of the touch command? Interestingly, the command everyone is using to create new, empty files, has quite different description in its own manual:

Atos cybersecurity Blog Security Dive-Offensive Linux 2

Thus, we can do something like:

Atos cybersecurity Blog Security Dive-Offensive Linux 3

As we can see in the screenshot, the new file /tmp/foo has fake modification date (copied from /etc/cron.daily/logrotate).

Now, let’s assume we modify /etc/cron.daily/logrotate by adding our custom persistence code (CUSTOM_PERSISTENCE_CODE is just a holder, in reality this would be a path to a script/executable (e.g. reverse shell, meterpreter, etc.) or a pair of download (wget) and execute commands):

Atos cybersecurity Blog Security Dive-Offensive Linux 4

As we can see, the filesystem modification date changed. Now, let’s restore the old one, so it appears like nothing was tampered in /etc/cron.daily/logrotate:

Atos cybersecurity Blog Security Dive-Offensive Linux 5


Making persistence more persistent

Another interesting feature that is not so well known is the immutable filesystem attribute, one of the extended attributes supported by chattr:

Atos cybersecurity Blog Security Dive-Offensive Linux 6

Enabling it is as simple as:

Atos cybersecurity Blog Security Dive-Offensive Linux 7

Now, the same append operation we did earlier won’t work, even though we are performing it as root:

Atos cybersecurity Blog Security Dive-Offensive Linux 8

To change the file again, first the immutable attribute needs to be lifted:

Atos cybersecurity Blog Security Dive-Offensive Linux 9

To examine the attributes, we can use lsattr:

Atos cybersecurity Blog Security Dive-Offensive Linux 10

This feature might be used as a security measure preventing important files from being changed, but might as well serve as a way of preventing a backdoor from being removed/overwritten (e.g. by an upgrade/some other automated process). Even if we, as attackers, were faced by an unexperienced administrator trying to manually remove our backdoor from their system, having the immutable attribute on it would definitely buy us some time.


Bypassing lack of +x

Sometimes we might end up in a system with no execute mount attributes on commonly writable locations like /tmp and /dev/shm. Or just upload an executable to a location, whereas upon upload it is created without the executable bit and we don’t have the permission to change that file attributes.

In the screenshot below, a copy of the whoami command is copied into /dev/shm. As we can see, by default the executable runs just fine. If we take away the executable attribute, attempting to run it again fails:

Atos cybersecurity Blog Security Dive-Offensive Linux 11

The lack of the executable attribute can by bypassed with the GNU/Linux dynamic linker/loader:

Atos cybersecurity Blog Security Dive-Offensive Linux 12


Easy & dirty backdoor with /bin/ksh

It is possible to easily create local root backdoors by abusing the SUID feature (more such backdoor examples can be found here https://gtfobins.github.io/gtfobins/ld.so/#suid). My favorite has always been ksh (KornShell).

Turning ksh into such a backdoor is as easy as setting the suid bit on it while being root (might require deployment – installation or just planting your own copy, as it is not installed by default):

Atos cybersecurity Blog Security Dive-Offensive Linux 13


Hiding files and directories from command line view, under whitespace names

Now, this one is quite funny. We can create files and directories with names consisting of white characters only, for instance spaces. Such files are harder to notice in command line output, e.g. when listing the contents of a directory or looking at process list with command lines referring to those files.

Let’s see this in action:

Atos cybersecurity Blog Security Dive-Offensive Linux 14

Of course, we can execute such files as well:

Atos cybersecurity Blog Security Dive-Offensive Linux 15

This trick nicely fits with the ksh suid backdoor (creating a suid copy of the legitimate ksh under ‘/bin/ ‘- yes, in the /bin directory, with a space as a name). The resulting command line (‘/bin/ ‘) makes it more difficult to identify where the executable file actually is and thus how to examine or remove it.


Blending into the process list – changing the process name

Let’s consider a hypothetical malicious perl script:

Atos cybersecurity Blog Security Dive-Offensive Linux 16

Now, we run it:

Atos cybersecurity Blog Security Dive-Offensive Linux 17

And this is its view in the process list:

Atos cybersecurity Blog Security Dive-Offensive Linux 18

Now, let’s improve the script slightly:

Atos cybersecurity Blog Security Dive-Offensive Linux 19

And run it again:

Atos cybersecurity Blog Security Dive-Offensive Linux 20

And voilà:

Atos cybersecurity Blog Security Dive-Offensive Linux 21

For those curious about what actually happens here, this does not change the process’s /proc/PID/cmdline value, but instead modifies something referred to as process legacy name – more can be found at https://perldoc.perl.org/variables/$0.

Share this article

Follow us on