Trojanised PuTTY keeps working while launching hidden TLS reverse shell

A working SSH client with something extra

According to a malware analysis by threat detection engineer Vasilis Mantas published on dev.to, the sample is a real, functioning PuTTY build that has been modified to start a hidden PowerShell process roughly one second after the SSH client opens. The PowerShell command line is base64-encoded and gzip-compressed; decoded, it is a reverse shell that connects over TLS to bonus2.corporatebonusapplication.local on port 8443. The SSH client works normally the entire time, and that is precisely what makes this class of implant effective.

Mantas is clear that the sample comes from a training set rather than a live incident. Nothing suggests real-world victims. Its value is instructional: it shows why a tampered-but-functional utility is harder to catch than an overtly malicious one, and why the delivery matters more here than the sophistication of the payload itself, which is a fairly standard PowerShell reverse shell of a kind that has circulated for years.

The file's identity checks out

Static analysis in the write-up found that almost everything about the binary's identity is genuine. The manifest identity reads PuTTY, the version resource names Simon Tatham, and an embedded URL points to the official PuTTY homepage. VirusTotal flagged it with 50 of 68 engines at the time of analysis, which settles that the file is worth examining but little else.

The interesting findings are the places where static tooling did not add up. The PE checksum is invalid; Mantas notes that a legitimately built PuTTY release carries a valid checksum, and this file's was never recalculated after someone altered the compiled binary. On its own that proves tampering rather than malice, but combined with an entropy of 7.394 and a writable-and-executable section in a 1.47 MB GUI binary, it justified detonation. Strings extraction produced over 41,000 strings dominated by ordinary Windows API calls, with no C2 address or encoded blob in the clear, because the payload simply was not sitting where string analysis looks.

Detection came from repeated runs

The first detonation was uneventful: PuTTY launched, the configuration window appeared, and the application behaved exactly as expected. Mantas writes that he would have called it clean after a single run. On the third or fourth execution he noticed a console window flash into existence and vanish about a second after startup, visible for only a fraction of a second. Process monitoring then confirmed what the eye had caught: PuTTY spawned powershell.exe from the 32-bit SysWOW64 path.

As Mantas frames it, an SSH client spawning a script interpreter is inherently anomalous, and that one parent-child relationship carries the entire detection. Automated sandboxing would have logged the process creation; a human clicking through once might have caught nothing at all.

An old payload in careful packaging

The command line stacks four flags before any code runs: no profile, hidden window, non-interactive, and execution policy bypass. Each has a plausible individual justification; together they describe a process designed to avoid being seen or logged in the usual way. The payload structure is base64 wrapped around gzip wrapped around a script block, so the actual code never appears as readable text in the process command line, the point where much logging stops.

Decoded on a Linux analysis VM, the script defines a function called powerfun that supports both bind mode, listening on port 8443, and reverse mode, dialling out to the hardcoded host. Reverse mode matters most on corporate networks, since outbound connections generally succeed where inbound ones are blocked. The TLS connection is not about authentication: the certificate validation callback returns true unconditionally, so the encryption serves to hide traffic from inspection while accepting any certificate, including a self-signed one generated on the attacker's machine. The domain itself is a deliberate choice, reading like the sort of dull internal application that nobody questions in a proxy log.

Why it matters

This sample is the supply-chain problem in miniature. A tampered utility that still does its job defeats the most basic validation a user will perform: open it, use it, see it work. Fifty VirusTotal engines flagged the file, but the signals that actually explained it, an invalid checksum and an SSH client launching a hidden script interpreter, came from deliberate analysis, and the behavioural clue surfaced only on repeated runs. The practical defences this suggests are behavioural alerting on GUI applications spawning script interpreters with hidden-window flags, integrity verification of downloaded tools before deployment, and scrutiny of outbound TLS connections to unfamiliar internal-sounding hosts. The sample is a training artefact, but the technique it demonstrates is exactly how real supply-chain tampering stays quiet.