SSH into a Compromised Server: Risks & What to Do

TL;DR

Yes, there are *significant* risks in SSHing into a server you suspect is compromised. It could allow the attacker further access or steal your credentials. Instead of logging in directly, focus on isolating the server and investigating without connecting via SSH.

What are the Risks?

SSHing into a compromised server isn’t just about what *you* do while logged in; it’s about what the attacker might already be doing. Here’s why it’s dangerous:

• Keyloggers: The attacker may have installed software to record everything you type, including your password.
• Backdoors: They could have created hidden ways for them to regain access even after you change passwords.
• Session Hijacking: Your SSH session might be monitored or controlled by the attacker in real-time.
• Credential Theft: The attacker may already have your credentials, and logging in confirms they still work.
• Malware Spread: Connecting could trigger malware to spread to *your* machine.

What Should You Do Instead? (Step-by-Step)

1. Isolate the Server: This is your first priority.
   • Network Disconnect: Physically disconnect the server from the network. If that’s not possible, block all inbound and outbound traffic using a firewall.
   • Cloud Console Access: Use the cloud provider’s console (AWS EC2 Instance Connect, Google Cloud Serial Console, Azure Bastion) if available – these often bypass SSH.
2. Initial Investigation (Without SSH): Gather information without directly logging in.
   • Console Logs: Check the server’s console logs for suspicious activity.
   • Cloud Provider Tools: Use your cloud provider’s security tools to scan for malware or unusual processes.
   • Snapshotting: Create a snapshot of the disk *before* making any changes. This allows you to revert if needed.
3. Forensic Analysis (If Possible): If you have the expertise, perform forensic analysis on the snapshot.
   • Memory Dump: Analyse a memory dump for running processes and malicious code. This is advanced!
   • File System Examination: Look for modified files, hidden directories, or unusual file names.
4. If SSH is Absolutely Necessary (Last Resort): If you *must* SSH in…
   1. Change Passwords First: Change the password of the user account you intend to use from a *different*, trusted system.
   2. Use Multi-Factor Authentication (MFA): Enable MFA if it isn’t already enabled.
   3. Monitor Everything: Use tools like auditd to log all commands executed during your session.

      sudo apt install auditd  # Example for Debian/Ubuntu

   4. Limited Scope: Only perform the essential tasks needed to secure or rebuild the server. Do not browse files unnecessarily.
5. Rebuild from Backup (Recommended): The safest option is usually to restore the server from a known-good backup.
   • Verify Backup Integrity: Ensure your backup wasn’t also compromised.
   • Patch and Update: After restoring, immediately apply all security patches and updates.

Checking for Suspicious Processes (Example)

If you have console access, you can try to identify unusual processes:

ps aux | grep -v grep # List all processes excluding the grep process itself

Look for unfamiliar user names or commands. Be cautious; attackers often disguise their processes.

Important Reminders

• Assume Breach: Treat any server you suspect is compromised as fully breached until proven otherwise.
• Document Everything: Keep a detailed record of all actions taken during the investigation and remediation process.
• Seek Expert Help: If you’re not comfortable with these steps, consult a cyber security professional.