Malware Analysis - Silly Putty

This piece of malware was one of the challenges in the TCM Practical Malware Analysis course. It’s not a particularly complicated piece of malware but it reinforces the concepts and techniques in first section of the course.

Here is the context that is provided with this sample:

Hello Analyst,

The help desk has received a few calls from different IT admins regarding the attached program.They say that they’ve been using this program with no problems until recently. Now, it’s crashing randomly and popping up blue windows when its run. I don’t like the sound of that. Do your thing!

IR Team

Executive Summary

Malware Identification

The analysis of this piece of malware indicate that it is a reverse shell trojan. This type of malware hides disguises itself as a legitimate piece of software and allows and attacker to gain control to the vicitim’s machine when it is executed.

The attacker has hid this malware inside a tool that is commonly used by employees called Putty.

Risk/Impact

Reverse shells are incredibly dangerous as they allow an attacker to run commands directly on a victim’s machine.

Next Steps

Communication should be sent out to all employees to avoid using the Putty application until we understand the scope of this infection.

  1. Block DNS queries for the domain bonus2.corporatebonusapplication[.]local

  2. Investigate the following data sources for signs of connections to the domain bonus2.corporatebonusapplication[.]local:

  • DNS Logs
  • Zeek Logs
  • HTTP Proxy Logs
  1. Check firewall logs for connections made over TCP port 8443

  2. Query hosts for the file hashes:

  • MD5: 334A10500FEB0F3444BF2E86AB2E76DA
  • SHA1: C6A97B63FBD970984B95AE79A2B2AEF5749EE463
  • SHA256:0C82E654C09C8FD9FDF4899718EFA37670974C9EEC5A8FC18A167F93CEA6EE83

Static Analysis

Initial static analysis did not clearly reveal the intent of the malware because it was embedded along with the legitimate executable of Putty.exe. This made it difficult to determine what strings/API calls belonged to the malware vs the actual components of putty.exe.

API Calls Strings Analysis

The following is a list of API calls that raised suspicion but with Putty being a tool designed to establish connections, it was difficult to find things that were out of place.

GetForegroundWindow Retrieves a handle to the foreground window (the window with which the user is currently working). The system assigns a slightly higher priority to the thread that creates the foreground window than it does to other threads.
AddDllDirectory Adds a directory to the process DLL search path.
RegDeleteValue Removes a named value from the specified registry key. Note that value names are not case sensitive.
ShellExecute Performs an operation on a specified file.
send The send function sends data on a connected socket.
recv The send function receives data on a connected socket.
bind The bind function associates a local address with a socket.

In the strings analysis, a URL (www.chiark.greenend[.]org.uk/~sgtatham/putty/) was uncovered but it was later terminated to be a link to the homepage of the legitimate Putty.exe



Dynamic Analysis

Running the malware proved to be more useful as there were clear differences between the intended functionality of Putty vs the malicious code living along side of it.

Look at a process tree, as the Putty executable starts running it spawns a powershell process

To learn what the powershell process is doing, I filtered on parent PID = 296.

The first record in ProcMon shows that the process started as a result of a obfuscated powerhsell script.

The script had instructions that indicated that the encoded command was base64 that had been gzipped. Using Cyberchef, decoding this string revealed more information about purpose of the script.

The powershell appeared to give the malware author the ability to choose if they wanted to use a reverse or bind shell and if they connection required SSL. If a reverse shell was selected the script would reach out to bonus2.corporatebonusapplication[.]local over port 8443 to establish a connection.

In our sample, the attacker chose to use a reverse shell and SSL.

From a network side, we see the script reach out to resolve the bonus2.corporatebonusapplication domain and then reach out to establish an SSL connection over port 8443.

To catch the reverse connection, I started netcat up on the Remnux box to listen over port 8443 but because there was not a certificate setup for that conenction, the SSL handshake would never be completed.


Theory Validation

To test the theory that the Powershell script could be ran in different configurations I made some modifications to the execution statement to not use SSL and to create a bind shell.

I then ran the script manually from within Powershell and noticed that there was a new port listening over 8443 as would be expected from a bind shell.

The last step was to connect to that port from the Remnux box using netcat. Once connected, I had a shell on the victim box can could run commands successfully.