Widespread Linux Bugs Expose Password Hashes on a Global Scale
June 2, 2025Multiple WordPress Plugins Vulnerabilities
June 2, 2025Widespread Linux Bugs Expose Password Hashes on a Global Scale
June 2, 2025Multiple WordPress Plugins Vulnerabilities
June 2, 2025Severity
High
Analysis Summary
A sophisticated malware campaign has been uncovered exploiting legitimate SSH tools specifically PuTTY and Windows' built-in OpenSSH client to establish persistent backdoors on compromised systems.
While trojanized versions of PuTTY have been known threats for years, recent analysis by Researchers highlights how attackers now weaponize the native OpenSSH client in Windows, which became a default component starting with version 1803. This marks a significant evolution in attacker tactics, as they increasingly leverage trusted administrative utilities to mask their presence, aligning with the "Living Off the Land Binaries" (LOLBINs) strategy.
The malware targets the legitimate ssh.exe binary located at C:\Windows\System32\OpenSSH\ssh.exe, blending its malicious operations with standard administrative behavior. Once executed, the malware attempts to start the "SSHService" service; if that fails, it retrieves a stored random port from the registry path SOFTWARE\SSHservice, which it had previously generated and saved. The malware also creates a custom SSH configuration file at c:\windows\temp\config that communicates with a command-and-control (C2) server at IP over port 443, mimicking encrypted HTTPS traffic to evade detection.
The configuration file contains several persistence-focused parameters: ServerAliveInterval 60, ServerAliveCountMax 15, and StrictHostKeyChecking no, which ensure continuous connectivity while bypassing key verification warnings. It also attempts to use the RemoteForward directive, though researchers noted errors in the syntax that could affect functionality. The malware repeatedly launches ssh.exe with the malicious config in an infinite loop with extended sleep cycles, a technique used to evade behavioral analysis tools that flag rapid or repeated network activity.
To defend against such threats, organizations must monitor SSH-related activity across their environments, including unauthorized config files, connections to unknown SSH servers, and changes in SSH-related registry keys. Application whitelisting and behavioral detection tools are crucial in identifying abuse of legitimate binaries like OpenSSH. This campaign highlights a broader trend where attackers exploit trusted native tools to maintain stealthy, long-term access, emphasizing the need for vigilance around legitimate Windows components with network capabilities.
Impact
- Sensitive Data Theft
- Unauthorized Access
- Security Bypass
Indicators of Compromise
MD5
e58777bd5d52fe5ec4ea20ccd1b92c57
SHA-256
b701272e20db5e485fe8b4f480ed05bcdba88c386d44dc4a17fe9a7b6b9c026b
SHA1
c059ee9b367a7e8cfdfcc2da3d9cc851c47f4ffd
Remediation
- Block all threat indicators at your respective controls.
- Search for indicators of compromise (IOCs) in your environment utilizing your respective security controls.
- Continuously audit SSH-related activity across endpoints and servers.
- Flag any unexpected or unauthorized SSH configuration files (e.g., in unusual paths like C:\Windows\Temp\config).
- Investigate any usage of ssh.exe with custom config files or abnormal parameters.
- Monitor and audit registry keys such as SOFTWARE\SSHservice for unauthorized or suspicious modifications.
- Implement alerts for new or modified keys associated with SSH services or custom port settings.
- Use tools like Microsoft AppLocker or third-party solutions to allow only approved applications and scripts to run.
- Restrict execution of SSH tools to specific users or administrative groups.
- Utilize endpoint detection and response (EDR) tools that can identify misuse of legitimate tools (LOLBIN abuse).
- Look for patterns like delayed execution, infinite loops, or network connections mimicking HTTPS traffic.
- Regularly update OpenSSH and related tools to patch known vulnerabilities.
- Enforce strict SSH policies such as requiring certificate-based authentication and enabling host key verification (StrictHostKeyChecking yes).
- Add known C2 addresses (e.g., 193[.]187[.]174[.]3) to firewall and endpoint blacklists.
- Monitor for outbound connections on port 443 that do not match expected HTTPS patterns.
- Search for signs of persistence mechanisms (e.g., repeated ssh.exe executions with long sleep cycles).
- Perform retrospective analysis on systems for dropped payloads like dllhost.exe.