During a recent IR (Incident Response) engagement for a Bengaluru-based fintech startup, we identified a PHANTOMPULSE RAT infection that had moved laterally from a developer's Windows 11 workstation to a production Ubuntu cluster. The entry point was a DLL side-loading vulnerability in a popular, unpatched VS Code extension used for database visualization. Once the RAT gained execution on the local machine, it didn't need to crack the production password; it simply waited for the developer to initiate an SSH session and hijacked the SSH_AUTH_SOCK environment variable.

Introduction to SSH Security Hardening

We define SSH security hardening as the process of reducing the attack surface of the Secure Shell protocol by eliminating legacy cryptographic primitives, enforcing strict authentication workflows, and minimizing the window of opportunity for lateral movement. In the context of the PHANTOMPULSE RAT, hardening is not just about keeping external attackers out; it is about ensuring that a compromised local terminal cannot be used as a pivot point into the core infrastructure.

What is Security Hardening?

Security hardening is the systematic elimination of unnecessary functional capabilities to reduce the number of potential exploitation vectors. We operate on the principle of least privilege. If a service, port, or cryptographic cipher is not strictly required for the operation of the system, we disable it. In Indian development environments, where developers often bridge local unmanaged Windows machines with managed cloud environments in AWS Mumbai (ap-south-1), hardening acts as the primary barrier against cross-platform malware.

What is SSH Hardening?

SSH hardening specifically targets the /etc/ssh/sshd_config on the server and the ~/.ssh/config on the client. We focus on three layers:

• Authentication Layer: Moving from "something you know" (passwords) to "something you have" (cryptographic keys) and "something you are/possess" (MFA).
• Transport Layer: Enforcing modern ciphers like ChaCha20-Poly1305 to mitigate attacks like Terrapin (CVE-2023-48795).
• Operational Layer: Implementing timeouts, logging, and access control lists (ACLs) to limit the impact of a hijacked session.

The Importance of Securing Remote Access

Remote access is the most frequent target for state-sponsored actors and ransomware groups targeting Indian infrastructure. With the Digital Personal Data Protection (DPDP) Act 2023 now in effect, a single breached SSH session resulting in data exfiltration can lead to penalties up to ₹250 Crore for the organization. We observed that PHANTOMPULSE specifically targets developers because they hold the "keys to the kingdom"—literally. Implementing secure SSH access for teams prevents a local RAT from escalating its reach into the server-side environment.

---

Core SSH Security Hardening Best Practices

The first step in any hardening exercise is to move away from the default configuration. The default OpenSSH configuration is designed for compatibility, not security. We need to override these defaults to block the most common automated attack scripts.

Disabling Root Login via SSH

Allowing direct root login is a significant risk. If an attacker compromises a credential or a key, they immediately have full control over the kernel and filesystem. We enforce the use of a standard user account with sudo privileges instead. This creates an audit trail, as every administrative action is tied to a specific user identity.

# Check if PermitRootLogin is enabled
grep "PermitRootLogin" /etc/ssh/sshd_config
Disable it immediately
sudo sed -i 's/#PermitRootLogin prohibit-password/PermitRootLogin no/' /etc/ssh/sshd_config sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config

Implementing SSH Key-Based Authentication

We no longer accept RSA 2048-bit keys. They are computationally expensive and increasingly vulnerable to future breakthroughs. We standardize on Ed25519, which offers better security and faster performance. When generating keys, we use a high number of KDF (Key Derivation Function) rounds to slow down offline brute-force attacks on the private key file. Transitioning to SSH Key-Based Authentication is a critical step in modernizing your security posture.

# Generate a hardened Ed25519 key
ssh-keygen -t ed25519 -a 100 -C "dev-access-token" -f ~/.ssh/id_ed25519_hardened

The -a 100 flag ensures that the passphrase hashing takes longer, making it significantly harder for a RAT like PHANTOMPULSE to exfiltrate and crack the key file if it gains access to the local ~/.ssh directory.

Disabling Password-Based Authentication

Once keys are distributed, password authentication must be disabled. This completely eliminates the threat of brute-force and credential-stuffing attacks. We observed that many Indian SMEs leave password authentication on as a "backup," which is the exact hole attackers exploit.

# Edit /etc/ssh/sshd_config
PasswordAuthentication no ChallengeResponseAuthentication no UsePAM yes

Note that UsePAM yes is still required for certain MFA modules, but PasswordAuthentication no ensures that the PAM password module is bypassed for SSH.

Changing the Default SSH Port (Port 22)

While this is "security by obscurity," it is highly effective at reducing noise in your logs. Automated bots primarily scan port 22. Moving SSH to a high-numbered port (e.g., 2222 or 4433) reduces the log volume, making it easier to spot genuine targeted attacks.

# Change port to 4433
sudo sed -i 's/#Port 22/Port 4433/' /etc/ssh/sshd_config
Update firewall (UFW example)
sudo ufw allow 4433/tcp sudo ufw delete allow 22/tcp sudo systemctl restart ssh

---

Advanced SSH Hardening Techniques

To combat advanced threats like PHANTOMPULSE, we must go beyond basic configuration. These techniques focus on breaking the RAT's ability to automate lateral movement.

Implementing Multi-Factor Authentication (MFA)

We recommend using the Google Authenticator PAM module or a hardware security key (YubiKey). Even if a RAT steals your private key, it cannot initiate a session without the TOTP (Time-based One-Time Password) from your physical device.

# Install the PAM module on Ubuntu
sudo apt-get install libpam-google-authenticator
Run the setup as the user
google-authenticator

After setup, we modify /etc/pam.d/sshd to include auth required pam_google_authenticator.so and update sshd_config to require both public key and keyboard-interactive authentication.

Configuring Fail2Ban for Brute Force Protection

Fail2Ban monitors your log files for patterns of failed login attempts and dynamically updates your firewall rules to ban the offending IP addresses. While Fail2Ban is excellent for automated blocking, integrating these logs into a SIEM provides the centralized visibility needed for enterprise-wide threat detection.

# /etc/fail2ban/jail.local
[sshd] enabled = true port = 4433 filter = sshd logpath = /var/log/auth.log maxretry = 3 bantime = 3600

Restricting SSH Access Using IP Whitelisting

If your developers are working from a fixed office location or through a corporate VPN, you should whitelist those specific IP ranges. This is the single most effective way to block external PHANTOMPULSE C2 servers from attempting to connect back to your infrastructure.

# Using iptables to allow only a specific Indian ISP range (Example)
sudo iptables -A INPUT -p tcp -s 122.160.0.0/16 --dport 4433 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 4433 -j DROP

Setting Idle Timeout Intervals

PHANTOMPULSE often waits for an active session to be left open. By enforcing an idle timeout, we close inactive connections, forcing the user (and the RAT) to re-authenticate. This limits the window of opportunity for a hijacked socket.

# Add to /etc/ssh/sshd_config
ClientAliveInterval 300 ClientAliveCountMax 0

This configuration sends a "keep-alive" signal every 5 minutes. If the client doesn't respond (or is inactive), the session is terminated immediately.

---

Monitoring and Auditing SSH Security

Hardening is a continuous process. We must audit the configuration and monitor logs for signs of compromise.

Reviewing SSH Log Files

On modern Linux systems, journalctl is the most efficient way to parse SSH logs. We look for "Failed password" or "Invalid user" attempts to identify ongoing attacks.

# Extract unique IP addresses of failed login attempts in the last hour
journalctl -u ssh --since "1 hour ago" | grep "Failed password" | awk '{print $11}' | sort | uniq -c

If we see a high frequency of attempts from an IP address outside of India, we immediately add it to our global blocklist at the VPC edge.

Using SSH Audit Tools for Vulnerability Assessment

We use ssh-audit to identify weak ciphers and key exchange algorithms. This tool is essential for identifying susceptibility to CVE-2023-48795 (Terrapin) as documented in the NIST NVD.

# Run ssh-audit against a local server
python3 ssh-audit.py localhost:4433

The output will highlight "red" items that need immediate remediation, such as ssh-rsa or hmac-sha1. We then update the sshd_config to only allow secure primitives.

# Secure Ciphers and MACs for /etc/ssh/sshd_config
KexAlgorithms [email protected] Ciphers [email protected],[email protected] MACs [email protected],[email protected]

---

Maintaining a Hardened SSH Environment

The PHANTOMPULSE RAT thrives on the "soft middle" of Indian IT infrastructure—the space between a secure cloud and an insecure developer laptop. By enforcing these SSH hardening standards, we create a "zero-trust" boundary at the shell level.

SSH Security Hardening Checklist Summary

To ensure compliance with the DPDP Act 2023 and protect against modern RATs, we follow this rigorous checklist for every new server deployment:

• Protocol 2 Only: Ensure legacy Protocol 1 is disabled (default in modern OpenSSH).
• No Root Login: Set PermitRootLogin no.
• Key-Based Only: Disable PasswordAuthentication.
• Modern Crypto: Use Ed25519 keys and disable CBC ciphers.
• MFA Enabled: Require a second factor for all external SSH access.
• Agent Forwarding Disabled: Set AllowAgentForwarding no to prevent SSH_AUTH_SOCK hijacking.
• X11 Forwarding Disabled: Set X11Forwarding no to prevent GUI-based lateral movement.
• Max Auth Tries: Set MaxAuthTries 3 to limit brute-force speed.
• Whitelisting: Use AllowGroups or AllowUsers to restrict who can even attempt to log in.

We recently analyzed a sample of PHANTOMPULSE that attempted to use ssh-add -L to list keys in a hijacked agent. By setting AllowAgentForwarding no on our servers, we effectively neutralized this feature of the RAT, as it could no longer leverage the developer's local identity to jump to the next server in the cluster.

# Final verification of active listeners
ss -tulpn | grep :4433

The next command you should run is ssh-audit against your primary jump server to see how many legacy algorithms are still active in your environment.