Fake PuTTY in Google Search: How Attackers Trick IT Admins with a Trojanized Installer

IT administrators hunting for a trusted SSH client on Google can be lured to a convincing fake download page that drops a trojanized installer. The malicious MSI appears to install the legitimate PuTTY executable so the program opens and looks normal, while a stealthy Node.js-based loader runs in the background and connects to attacker-controlled infrastructure. Because the visible application behaves as expected and the bundled PuTTY binary is signed, many users may assume the installer is safe — but the real danger is the hidden multi-stage payload that can give attackers persistent, highly flexible remote control.

How the attack works

The lure begins with search-engine optimization and a lookalike website that mimics PuTTY’s official download page. When an administrator clicks the fake download, the site serves an MSI named Putty-x86_64.msi hosted on a Backblaze B2 bucket. Running the installer drops several files into a folder under the user’s AppDataLocal directory and launches putty.exe (a legitimate, signed PuTTY 0.85 build) to disguise the infection.

Behind the scenes, a batch script runs silently, checks for Node.js, and fetches the official Node.js 18.20.5 runtime if it’s absent. A small JScript stub then starts Node.js with an obfuscated JavaScript payload that becomes the attacker’s real launcher. Because Node.js itself is legitimate, simple checks for a benign runtime or for a signed executable can be misleading — the malicious behavior is contained within the JavaScript executed by Node.

Technical detail: EtherHiding and modular C2

Rather than hardcoding a single command-and-control (C2) URL, the JavaScript loader uses a technique researchers call “EtherHiding.” It queries an Ethereum smart contract through multiple public RPC endpoints, compares the responses, and selects the most common valid URL as the active C2 server. The loader repeats this lookup every five minutes, making static blocklists less effective. Once a C2 is chosen, the loader checks in frequently (about every 500 ms), fetching seemingly innocuous assets — images, CSS, icons — with filenames and extensions that blend into normal web traffic. If the response is non-trivial, the data is executed by the Node.js runtime, allowing the operator to push new JavaScript instructions for reconnaissance, exfiltration, and even near-real-time screen capture.

Observed capabilities and attacker goals

Unit 42’s analysis shows the campaign can collect rich system telemetry (OS, AV products, domain status, graphics hardware, and SMB sessions), harvest browser profiles and cookies, install WebSocket components, and run PowerShell routines that capture desktop screenshots at a high frame rate. The attacker’s ability to send new JavaScript means post-infection functionality can be updated without distributing a fresh installer, creating a highly modular and persistent foothold well-suited to targeting administrators who have privileged access and stored credentials.

Why IT teams should care

This campaign is not exploiting a vulnerability in PuTTY — it exploits trust. Administrators frequently download and install utilities, and a trusted-looking application window plus a signed binary can lower suspicion. Because infected machines may hold active remote sessions, saved access tokens, and privileged connections to internal infrastructure, a successful compromise of an admin workstation can be catastrophic.

Practical defensive steps include:

• Direct staff to verified download locations (PuTTY’s official site) and maintain an approved software portal for commonly used admin tools.
• Monitor for node.exe or similar runtime processes launching from user AppData folders, especially when invoked with unusual arguments (e.g., referencing an .ini file).
• Inspect MSI installers that create the campaign’s named files or staging folders.
• Look for outbound traffic to Ethereum RPC endpoints from endpoints that should not contact those services.
• Integrate threat intelligence feeds containing the IoCs below into SIEM and blocking tools.

Indicators of compromise (IoCs):-

Closing thoughts

This campaign is a reminder that supply-chain and distribution attacks increasingly rely on social engineering and infrastructure hiding techniques rather than zero-day software flaws. For defenders, the priority is reducing opportunities for users to install software from unvetted sources, monitoring for atypical runtime behavior from benign-sounding processes, and using threat intelligence to detect and block follow-up activity quickly.

Licensed under CC BY-ND 4.0 International