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:

As we can see in the screenshot, that file was last time modified on 5th May 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:

Thus, we can do something like:

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):

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:

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:

Enabling it is as simple as:

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

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

To examine the attributes, we can use lsattr:

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:

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

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):

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:

Of course, we can execute such files as well:

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:

Now, we run it:

And this is its view in the process list:

Now, let’s improve the script slightly:

And run it again:

And voilà:

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.