Malware Analysis – SillyPutty
For challenge 1 of TCM Security’s Practical Malware Analysis and Triage (PMAT) Course, we as the analyst has been tasked to investigate a suspicious file called putty.exe.
We are to use the methodology and tools used for basic static and dynamic analysis to answer the following questions:
Static
1) What is the SHA256 hash of the sample?
2) What architecture is this binary?
3) Are there any results from submitting the SHA256 hash to VirusTotal?
4) Describe the results of pulling the strings from this binary. Record and describe any strings that are potentially interesting. Can any interesting information be extracted from the strings?
5) Describe the results of inspecting the IAT for this binary. Are there any imports worth noting?
6) Is it likely that this binary is packed?
Dynamic
1) Describe initial detonation. Are there any notable occurrences at first detonation? Without internet simulation? With internet simulation?
2) From the host-based indicators perspective, what is the main payload that is initiated at detonation? What tool can you use to identify this?
3) What is the DNS record that is queried at detonation?
4) What is the callback port number at detonation?
5) What is the callback protocol at detonation?
6) How can you use host-based telemetry to identify the DNS record, port, and protocol?
7) Attempt to get the binary to initiate a shell on the localhost. Does a shell spawn? What is needed for a shell to spawn?
Executive Summary
The malware appears to be a legitimate Putty program modified to also execute malicious actions via powershell to execute a reverse TCP connection to an external host, possibly for remote code execution on the victim.
VMs, Tools Used
- FlareVM – Procmon, Wireshark, TCPView, PEStudio, Cyberchef
- Remnux (acting as the fake HTTP and DNS server via inetsim), Wireshark
Both VMs were isolated in their own network via VMware’s host-only networks. Drag and Drop and clipboard functions were disabled before dynamic analysis.
Static Analysis
I first defang the executable by adding a .malz to it to prevent accidental detonation.
I then use PEstudio to open the file and it generated the sha256 hash and also informed me that the file is a 32-bit Windows executable (see Figure 1).
Sha256: 0C82E654C09C8FD9FDF4899718EFA37670974C9EEC5A8FC18A167F93CEA6EE83
Putting this Sha256 file into Virustotal reveals that this file is very likely to be malicious as 62 out of 74 security vendors has flagged it to be so (see Figure 1).
Back to PEStudio, I wanted to investigate the import libraries, the sections and strings so that we can form some hypothesis on what this malware could be doing.
Import Libraries
Investigating the Import libraries, I filtered the technique column as there were too many imports to investigate and I wanted to see what were the more significant libraries. While there are some interesting calls to registry related apis, it is not clear if these calls were by the malware or by the legitimate putty app. However, when we do our dynamic analysis later, we will make it a point to investigate any modifications to registry keys (see Figure 3).
Sections
To answer the question of whether this malware is packed or not, I compared the size of the raw data versus the virtual data size. There are no indicators of any packing mechanisms such as UPX. This malware is likely not packed as the raw data size and the virtual data size under the text section header are similar. The large number of import libraries also further strengthen the theory that this malware is not packed.
Strings
We are presented with a huge list of strings as the default minimum string length is at 3. Doing a quick scroll reveals what appears to be rather benign strings that belong to the legitimate Putty software.
The first thing i tried is to filter the strings by size (bytes) so that the longer strings are on top and lo and behold, we found a very interesting string (see Figure 4).
The full value can be seen in Figure 5 below. What we see is some form of compression via Gzip and then encoding via Base 64. We used CyberChef to decode and then decompress the string and we find a Powershell script that invokes sockets and allows the attacker to choose a bind or a reverse shell (see figure 6). OF interest, we see a domain of “bonus2.corporatebonusapplication.local” and a port of 8443. At the final line, we note that the script is executed with the -Command reverse flag and the -Sslcon as true which means that the connection will be over TLS (see figure 7).
Summary of Static Session
- The file has been detected in the wild and has been flagged as malicious by a the majority of vendors.
- There are some api calls related to registry changes that we need to note when detonating the malware
- Of concern, is what appears to be a custom powershell command that is trying to establish a TCP connection with a suspicious domain of bonus2.corporatebonusapplication.local and using a high port of 8443. This is suspicious behaviour we have to watch for when detonating the malware.
Dynamic Analysis
Time to blow it up💥 I am going to do this in two phases. I am first going to blow it up without hosting any fake HTTP and DNS server on Remnux and then blow it up with the fake server to observe what happens.
SAFETY – It is important to ensure you are fully isolated before blowing anything up. I ensured that I was not able to communicate outwards from FLAREVM and that i disabled the drag&drop functionality.
Initial Detonation
I briefly saw a blueish terminal pop up and disappear before the Putty program appeared (see Figure 8, did not manage to capture the terminal in time). Given our previous findings from the static analysis of the strings, this is likely to be a powershell terminal.
This time, I set up Procmon to capture any processes that were spawned by the malware as well as wireshark to see any network traffic generated. Detonating the malware again, we see multiple events in ProcMon and DNS queries captured on Wireshark (Figure 9). Of importance is the confirmation that the malware spawned a powershell terminal (Figure 10) and validate our finding that it tried to query the suspicious domain of of bonus2.corporatebonusapplication.local (Figure 11)
We now want to spin up our fake server on Remnux to see what happens if the DNS query is resolved and a connection is established
Detonation with Inetsim
Executing the malware again, we see attempted TCP connections this time with Wireshark but the connection was not able to be established (see Figure 12).
We know that the malware is executing a reverse TCP connection out to the suspicious domain on port 8443. Hence we can impersonate as the domain and see if we can catch the connection via netcat. To do this, we edit the C:/Windows/System32/drivers/etc/hosts file on the FlareVM so that the sus domain resolves to our local host (see Figure 13) [You might be wondering how on earth do i have nano on FlareVM which is a Windows host. I used the cmder program to run this]
Set up a ncat listener on FLAREVM listening on port 8443 and then execute the malware. It seems we got a connection but it prints out a bunch of gibberish (see Figure 14). This is because the connection requires TLS keys which we dont possess. We at least can establish that this malware sets up a TCP reverse connection back to the sus domain which in reality probably hosts the TLS keys and allow the attacker to remotely execute commands on the victim.
Conclusion
This was a very fun first challenge where I could practice doing basic static and dynamic analysis on a malware. It was definitely not an easy first challenge as the malware itself contained a legitimate program and it was not easy to quickly ascertain any suspicious artifacts just from strings analysis and import libraries.
The reverse TCP connection using TLS threw a spanner in the works and we can only be left guessing at the full capabilities of this malware. That said, our basic analysis did manage to dig up quite a bit of information that would allow defenders to use the IOCs we have discovered to write rules such as blacklisting the sus domain and blocking outward traffic via port 8443.
