Cisco Blogs

Trojanized PuTTY Software

- May 18, 2015 - 6 Comments

This post was authored by Cisco CSIRT’s Robert Semans, Brandon Enright, James Sheppard, and Matt Healy.

In late 2013­­­–early 2014, a compromised FTP client dubbed “StealZilla,” based off the open source FileZilla FTP client was discovered. The attackers modified a few lines of code, recompiled the program, and disbursed the trojanized version on compromised web servers. This new attack appears to involve the same actors who reused the same techniques to alter the source code of the widely used open source Telnet/SSH client, PuTTY, and used their network of compromised web servers to serve up similar fake Putty download pages. This new campaign is like the StealZilla campaign in almost every way. This trojanized version of PuTTY harvests credentials and relays the information back to a collection server in the same way too. The operation is very quick and quiet. Login details are sent to attackers using an HTTP GET connection ONLY once.

The primary mode of infection relies on users to search for PuTTY and follow a link to a fake mirror rather than the legitimate PuTTY page. To increase the chances users reach the malicious mirrors, the attackers have used search engine optimization techniques. Some HTML pages hosted on the compromised servers reference PuTTY for Mac, PuTTY for Android platforms, or even more obscure things like PuTTY and shampoo, for example. The malicious PUTTY.exe (MD5 b5c88d5af37afd13f89957150f9311ca) comes in the PE format, just like the original. This trojanized version of PuTTY maintains a user interface and function seemingly similar to the original. One difference is the binary was compiled with a different version of Microsoft Visual C++ than PuTTY traditionally has been, and results in a slightly altered user interface. Also, the “About” button reveals altered information, being listed as “Unidentified build, Nov 29 2013 21:41:02.” Given that presumable compile time, that is only a couple of months after the release of PuTTY v0.63, which labels itself as “Release 0.63” under “About.”


 Comparison of MalPutty on left and legitimate PuTTY on right

When an SSH session is initiated, the credentials are harvested and sent in the same format used in the StealZilla campaign, except with SSH in place of FTP for the protocol.

“ssh://<username>:<password>@<IP address or domain>:<port>”

This string is then Base64 encoded and appended to the URI before the HTTP GET request is sent. This is the only malicious network traffic witnessed from this binary.

hxxp://<base64 encoded credentials>










Instructions reused in MalPutty that were also found in StealZilla

Compromised servers host seemingly legitimate copies of the HTML pages used for PuTTY, but with small variations including words to catch attention and even a picture of the malicious version of PuTTY. All of the fake pages are dumped in a /putty directory on the compromised web servers. The compromised web servers have nothing to do with PuTTY or SSH clients outside of this directory. The following are some examples of the compromised URI structures:


Further research into the delivery infrastructure of compromised web servers used in this campaign revealed interesting results. Posts on various forums referenced an IP address ( contained in injected JavaScript code used on multiple compromised sites containing various PHP frameworks. The domains used by the threat actors for StealZilla and MalPuTTY currently resolve to this IP address, and previously used Some of these domains include the current MalPutty domain ( along with previously seen and All were used previously in the StealZilla campaign. The injected JavaScript uses the URI hxxp://, which appears to be running the Traffic Direction Systems (TDS) framework sTDS (a Russian-based project). TDS services are not uncommon in the malware world, being used for various nefarious activities such as delivering exploit kits. The JavaScript in question appears to attempt to identify characteristics of the device it was launched on to form a key sent to the TDS service, ultimately determining how the device is routed. One could also argue that servers with viable credentials previously harvested through the FTP and later SSH campaigns could be used to compromise legitimate web servers. We currently have no further information on the actors’ ultimate goal with the TDS system.

This type of attack is extraordinarily simple but surprisingly effective. The nature of users to download unsigned and unverified files exposes a major flaw in the way many people operate on a daily basis. Hashes of the legitimate versions of PuTTY are provided on the official web page, but with no way to generate cryptographic sums on a plain vanilla install of Windows, the average user will not go through the trouble.

PuTTY does provide a mechanism for validating releases (described at; however, the process has several issues. Even under ideal conditions, manually verifying hashes is useless because Windows does not provide any mechanism for computing MD5/SHA hashes, and even if it did, it’s trivial to provide fake hashes on the fake mirror. Instead, users would need to validate the binary with the provided RSA/DSA signatures. However, doing so is beyond the skill level of even most Windows system administrators. It’s also not clear how users would validate that the RSA/DSA key used to validate the signatures is legitimate and not just a fake key on the fake mirror. Finally, the existing legitimate PuTTY RSA/DSA keys cannot be used by current versions of GPG because they’re signed with MD5, which has been deprecated. Thus, even sophisticated security-conscious users simply have no realistic way of verifying the legitimacy of PuTTY.

Indicators of Compromise (IOC):


Windows PE File
MD5 b5c88d5af37afd13f89957150f9311ca
SHA1 51c409b7f0c641ce3670b169b9a7515ac38cdb82
SHA256 d3e866e5bf18f2d9c667563de9150b705813e03377312b6974923f6af2e56291

C2 Domains: MalPuTTY StealZilla StealZilla

IPV4 Addresses: Previous Previous Current

Hardcoded User Agent String:

Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.51

Identified Compromised Web Servers:



All comments in this blog are held for moderation. Your comment will not display until it has been approved

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.


  1. It should be noted that Windows actually has a perfectly good native command line utility for computing file hashes: certutil -hashfile somefile SHA1 Algorithm could also be MD5, SHA256 or SHA512. Simon Zuckerbraun HP Zero Day Initiative

      Hey Simon, good tip. C:\Users\cfry>certutil -hashfile test.txt SHA256 SHA256 hash of file test.txt: 26 57 9d 94 b6 f0 f9 03 3a e4 2b 8a b8 af c6 f3 de 64 09 68 55 31 a1 c5 2a cf 63 c2 d2 3e a3 9f CertUtil: -hashfile command completed successfully. Thanks!

  2. Also fciv: fciv -md5 file fciv -both file

  3. Windows 8.1 and Server 2012 R2 definitely have a native way to verify a file hash. Powershell cmdlet: Get-Filehash.

  4. There is a reason why legit sites provide download managers that verify the checksum of downloaded files without the user doing a thing but simply electing to use the download manager provided at the beginning of the download rather than without. Microsoft and many other entities that provide software downloads provide this functionality so end users do not have to go through the hassle of manually trying to accomplish the same thing. The Putty site can do the same.

    • ... but then one would have to download the download manager, possibly from the malware mirror... would you then trust it?