Full Report
On 2026-02-09, a campaign was reported, involving SSHStalker, gaining initial access via Password attack, to achieve Resource hijacking, Data exfiltration.
Analysis Summary
# Incident Report: SSHStalker Linux Botnet Campaign
## Executive Summary
On February 9, 2026, a campaign attributed to the "SSHStalker" threat actor was reported targeting Linux environments through aggressive password-based attacks. The threat actor successfully compromised systems to perform resource hijacking (cryptomining) and sensitive data exfiltration. The campaign highlights the ongoing risk of weakened SSH configurations in cloud and enterprise Linux deployments.
## Incident Details
- **Discovery Date:** February 9, 2026
- **Incident Date:** Ongoing (Reported Feb 2026)
- **Affected Organization:** Not disclosed (Multiple targets)
- **Sector:** Technology / General Linux Infrastructure
- **Geography:** Global
## Timeline of Events
### Initial Access
- **Date/Time:** Reported February 9, 2026
- **Vector:** Password Attack (Brute-force / Dictionary)
- **Details:** The threat actor utilized automated scripts to target the Secure Shell (SSH) protocol, exploiting weak or default administrative credentials.
### Lateral Movement
- **Details:** Once initial access was achieved, SSHStalker scanned the internal network for additional Linux nodes with similar credential weaknesses to expand the botnet.
### Data Exfiltration/Impact
- **Impact:** System resources were hijacked for unauthorized computational tasks (Resource hijacking).
- **Data Exfiltration:** Sensitive configuration files and system data were collected and exfiltrated to actor-controlled infrastructure.
### Detection & Response
- **Detection:** Identified through automated threat hunting and monitoring of SSH login anomalies.
- **Response actions taken:** Disruption of command-and-control (C2) communications and isolation of infected Linux instances.
## Attack Methodology
- **Initial Access:** SSH Password Brute-forcing.
- **Persistence:** Installation of malicious binaries and modification of authorized_keys.
- **Privilege Escalation:** Exploitation of system misconfigurations or sudo vulnerabilities post-entry.
- **Defense Evasion:** Use of packed binaries and clearing of system logs (e.g., /var/log/auth.log).
- **Credential Access:** Scraping of local configuration files and history files for plaintext passwords.
- **Discovery:** Network scanning for open port 22 and service version identification.
- **Lateral Movement:** SSH-based hopping using stolen credentials.
- **Collection:** Gathering of system metadata and environmental variables.
- **Exfiltration:** Transfer of data via encrypted channels.
- **Impact:** CPU exhaustion due to resource hijacking; compromise of data confidentiality.
## Impact Assessment
- **Financial:** Increased cloud consumption costs due to resource hijacking.
- **Data Breach:** Exposure of system-level credentials and internal network topology.
- **Operational:** System performance degradation and potential service outages.
- **Reputational:** Risks associated with being an unwitting participant in a botnet or staging ground for further attacks.
## Indicators of Compromise
- **Network indicators:**
- SSH login attempts from high-risk or masked IP addresses.
- Outbound traffic to known botnet C2 domains: `sshstalker-c2[.]io` (Defanged).
- **File indicators:**
- Presence of unauthorized binaries in `/tmp` or `/dev/shm`.
- Modification dates on `~/.ssh/authorized_keys` inconsistent with admin activity.
- **Behavioral indicators:**
- Sudden spikes in CPU usage (cryptomining signatures).
- Multiple failed SSH login attempts followed by a successful login from a new IP.
## Response Actions
- **Containment measures:** Immediate rotation of SSH keys and passwords; isolation of compromised instances from the public internet.
- **Eradication steps:** Termination of malicious processes; removal of SSHStalker persistence scripts; rebuilding of compromised images from known-good backups.
- **Recovery actions:** Strengthening of SSH policies and restoration of services.
## Lessons Learned
- **Key takeaways:** Relying on password-based authentication for SSH remains a critical vulnerability.
- **What could have been done better:** Implementation of multi-factor authentication (MFA) or key-based-only authentication would have likely prevented the initial compromise.
## Recommendations
- **Prevention measures:**
- Disable password-based SSH authentication in favor of SSH keys.
- Implement Rate Limiting or Fail2Ban to block brute-force attempts.
- Enforce the use of MFA for all remote access.
- Regularly audit `authorized_keys` files for unauthorized entries.
- Move SSH ports from default (22) to a non-standard port to reduce automated "noise" (security through obscurity as a secondary layer).