We’ve made it this far to lab 4! On the offensive side, a successful brute force attack has allowed access to be gained on the target NAS server, followed by a successful privilege escalation attack to gain root access to the compromised system. Now it’s time to establish persistence on the target NAS server.
To establish persistence in this scenario I’m going to add a public SSH key to the user’s ~/ .ssh/authorized_keys file to be able to easily re-authenticate to the system.
To set that up I’m going to generate an SSH key pair on the Kali Linux machine, like so.
Then copy the public key to the target system
IN the /tmp directory on the target NAS system, verify that the id_rsa.pub public key file is there.
I'll then the file from the /tmp to /root directory on the system.
From there, I'll run the following commands to setup an ~/.ssh directory for this keypair, as well as use the echo command rename the id_rsa.pub file to authorized_keys, then assign permissions to the authorized_keys file and ~/.ssh directory.
Then from there, it’s time to test the persistence.
And we are back in.
In this scenario, you would still have to go through the steps of setting the TERM environment variable and exploiting the SUID bit in vim to escalate privileges. However, in establishing persistence, this would give you a way back into the system after a reboot.
Step 1 - Detection of SSH Key-Based Persistence
Audit: authorized_keys file.
SSH key-based persistence relies on the presence of unauthorized public keys in authorized_keys file. Check for unusual entries.
Well, here we have a concatenated public key file with an @kali, that right there would indeed be very suspicious and considered an IoC to immediately respond to and investigate.
Step 2 - Check SSH Logs:
This would be another case to go through the auth.log as done in the previous lab examples.
Step 3 - Check Recent File Modification
Identify Recent File Modifications
Identify recently modified .ssh/authorized_keys files
Here we have an example of using the find command to identify recently modified authorized _keys files. This command searches for any authorized_keys files modified within the last 7 days, a common indicator of unauthorized persistence.
Process Monitoring
Use the who command to identify active SSH sessions.
Here we see the user account ronny making a connection from the Kali Linux IP address.
Immediate Response
Upon detecting these active malicious/suspicious connections, I would immediately terminate them.
I would start using the kill command with the -9 to forcefully terminate any PID associated with the ronny user account.
Mitigation of SSH Key-Based Persistence
Step 1 - Remove Unauthorized Keys
Manually inspect and remove unauthorized entries from authorized_keys:
Step 2 - Change User Passwords
In case an attacker also knows the user’s password, reset it to prevent further access.
The overall detection of this activity would indeed call for immediate response in the event of discovering an active IoC with a suspicious IP, process, and/or unusual activity from a standard user account on the server. In this case and scenario, there are further mitigation options that are applicable in different circumstances depending on how the server is being used and the needs of the given environment. In lab 2, password-based authentication for SSH was disabled to mitigate from SSH brute force attacks. Which is typically a recommended practice to configure SSH and utilize public-key based authentication.
Even with that in place, on the offensive side if we manage to find another way into the system, this method of persistence could still be set up.
In such cases, depending on the use of the server and needs of the environment, there are a few different directions for mitigation that would be applicable in different scenarios.
If SSH isn’t really needed – the service could simply be disabled along with SSH key usage disabled to go the extra mile. However, SSH can always be re-enabled and setup if the server is compromised through a different method. If the operating system is granular enough to setup 2FA for SSH on accounts or explicit permissions for user accounts to use SSH, that’s another avenue. If SSH is needed, an IDS/IPS or other type of monitoring tool specifically set up to alert on authorized_keys would be my next consideration in my aim to mitigate against this.