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://ngusto-uro.ru/get/index.php?record=<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:
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 http://www.chiark.greenend.org.uk/~sgtatham/putty/keys.html); 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
Hardcoded User Agent String:
Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.9.168 Version/11.51
Identified Compromised Web Servers: