Anthology of persistent execution techniques on Linux

This post is an anthology of techniques to establish persistence on Linux systems. What follows is a list and a short description of techniques to abuse legitimate system administration functionality that Linux systems offer.

The post is split into the following sections:

Persisting with Pluggable Authentication Module (PAM) configuration files

PAM is a system of libraries that handle the authentication tasks of applications (services) on a Linux system [1]. The nature of this authentication is dynamically configurable. The dynamic configuraton is set by the contents of the configuration file /etc/pam.conf or by individual configuration files located in /etc/pam.d/ [2].

An attacker with elevated permissions (root) can edit the configuration files to achieve persistent execution upon a trigger of an event, such as login of a user with SSH.

This technique - from the perspective of a legitimate user - is described in the post [3]. However, an attacker can re-purpose the technique to plant malware in the form of a malicious bash script or an elf binary and establish persistent execution by modifying the PAM configuration of a service.

More specifically, by adding the following line to /etc/pam.d/ssh, the script is executed as soon as a user logins with SSH (assuming UsePAM is set to Yes in the ssh configuration):

session required pam_exec.so /path/to/malicious/script.sh

Scheduled tasks - cron jobs

Just like on Windows systems, users can setup scheduled tasks (cron jobs in Linux terminology). This technique is documented as T1053.003 in the MITRE ATT&CK framework [5].

To execute a malicious script on system reboot, the following line could be appended in a crontab file:

@reboot sleep 60 && /path/to/malicious/script

The crontabs [4] (files that instruct the cron daemon of what and when to execute a command) of users are stored at the following location:

/var/spool/cron/crontabs

It is apparent that the above location is useful in terms of incident response investigations to recover scheduled tasks that execute malware.

To prevent users from running cron jobs, simply add the username into:

/etc/cron.d/cron.deny

To prevent all user accounts from running cron jobs, do:

echo ALL » /etc/cron.d/cron.deny

Shell initialization files

Words taken directly from [6]:

“When invoked interactively with the –login option or when invoked as sh, Bash reads the /etc/profile instructions. These usually set the shell variables PATH, USER, MAIL, HOSTNAME and HISTSIZE.”

Malware persistence on Linux systems can be established by modifying /etc/profile to execute a script or by planting a script in /etc/profile.d

This technique requires root privileges.

References

[1] https://linux.die.net/man/8/pam

[2] https://linux.die.net/man/5/pam.d

[3] https://medium.com/@alessandrocuda/ssh-login-alerts-with-sendmail-and-pam-3ef53aca1381

[4] https://linux.die.net/man/5/crontab

[5] https://attack.mitre.org/techniques/T1053/003/

[6] https://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_01.html


tags: #persistence