PRACTICE 9
DYNAMIC MALWARE ANALYSIS
ANDREA CAMILA TORRES GONZÁLEZ
MATEO SEBASTIAN FORERO FUENTES
DANIEL ALEJANDRO ACERO VARELA
IT SECURITY AND PRIVACY
DANIEL ESTEBAN VELA LÓPEZ
ESCUELA COLOMBIANA DE INGENIERÍA JULIO GARAVITO
FACULTY OF COMPUTER SCIENCE
BOGOTÁ D.C.
2025
Table of content
Introduction ................................................................................................................................... 3
Malware Analysis - Basic Setup ................................................................................................. 3
Malware Analysis - Detonation ................................................................................................... 9
Malware Analysis - Backdoor Connection .............................................................................. 12
Questions..................................................................................................................................... 14
Conclusion ................................................................................................................................... 16
Introduction
In this laboratory exercise, we simulated the detonation of a malware sample to analyze
its behavior in a controlled environment. To ensure the safety of our machine, we
implemented several precautions, such as proper network configurations, the use of
virtual machines, and creating snapshots. Our focus was on examining the putty.exe
malware, sourced from the HuskyHacks repository, using dynamic analysis tools like
Wireshark, Process Monitor, and TCPView, alongside previous static analysis techniques.
Malware Analysis - Basic Setup
First of all, a Host-Only Network is configured in VirtualBox to enable controlled
communication between FlareVM and REMnux without internet access. The DHCP
server is enabled with 10.0.0.2 as the gateway, a 255.255.255.0 subnet mask, and an IP
range from 10.0.0.3 to 10.0.0.254. Both VMs are assigned to this network, allowing
REMnux to monitor malware-generated traffic in a contained environment, capturing DNS
queries, HTTP requests, and other indicators for analysis.
In this step, the ipconfig command is used in REMnux to verify network connectivity within
the Host-Only Network. The system's Ethernet adapter (ensp0s3) is assigned the IP
address 10.0.0.3 with a 255.255.255.0 subnet mask, confirming its connection to the
virtual network.
In this step, the network settings of a Windows machine are verified to confirm its
connection to the Host-Only Network in VirtualBox. The IPv4 address is 10.0.0.4, which
falls within the previously configured DHCP range (10.0.0.3 - 10.0.0.254), indicating
successful network assignment. The IP settings are set to Automatic (DHCP), meaning
the system has obtained its address dynamically from the VirtualBox DHCP server.
This step shows the configuration of INetSim within the /etc/inetsim/inetsim.conf file,
accessed through the nano text editor with superuser privileges (sudo). This
configuration file defines the settings for INetSim, a tool designed to simulate common
internet services in a controlled environment, primarily for malware analysis.
In the image, several internet services such as DNS, HTTP, HTTPS, SMTP, POP3, FTP,
FTPS, NTP, and syslog are enabled using the start_service directive. However, we focus
specifically on the DNS service, as it is the one we will use on the machine where the
sample will be executed. This ensures an additional layer of security by preventing the
machine from querying unwanted services, allowing us to maintain control over the
network interactions.
This step shows the configuration of IPv4 network settings in the Windows Control
Panel under Network and Sharing Center. The settings window for Internet Protocol
Version 4 (TCP/IPv4) Properties is open, allowing us to manually configure DNS server
addresses.
The configuration sets the Preferred DNS server to 10.0.0.3, which is the DNS service we
are configuring on REMnux. This setup ensures that our FlareVM resolves domain names
through our controlled environment, preventing it from interacting with the internet
network.
This process demonstrates the setup and operation of INetSim, a tool used for simulating
internet services in a controlled environment, often for malware analysis.
First, the user runs netstat -tuln to check active internet connections, verifying which
services are currently running. By default, port 53 is listening, but in this case, we want to
ensure it is not active. To stop the default DNS service, the user executes the following
commands:
sudo systemctl stop systemd-resolved
sudo systemctl disable systemd-resolved
Then, the we start INetSim by executing the inetsim command, which initializes the tool
using predefined directories for logs, data storage, and configuration files. The tool
successfully parses the configuration file and starts listening on 10.0.0.3.
The screenshot shows a web browser accessing google.com/test.txt and receiving a
response from INetSim's fake HTTP server. The URL bar indicates an insecure HTTP
connection, but the displayed plain text confirms that the server is in "fake mode,"
simulating real services without relaying traffic externally.
INetSim is configured to serve default test documents, allowing for controlled analysis of
network behavior. The page contains a simple text message verifying that this is the
default response from INetSim’s HTTP server. This confirms that INetSim is successfully
intercepting HTTP requests and responding with predefined content, which is useful for
malware analysis, penetration testing, and forensic investigations.
Malware Analysis - Detonation
Since we are interacting with malicious files, we must take all necessary precautions.
Having a secure network is a good first step. Another important security measure is
creating a snapshot of the FlareVM machine, ensuring we can restore it in case malware
causes unintended damage. We are using VirtualBox, which facilitates this process, as
shown in the image.
With all these precautions in place, we will proceed to detonate the malware, which in this
case is the putty.exe file. At first glance, it presents the same interface as a legitimate
PuTTY application. To analyze its behavior and verify any malicious activity, we will use
Wireshark, Procmon, and TCPView.
Wireshark
When we open the application, Wireshark reveals that the malware attempts to resolve
the domain bonus2.corporatebonusapplication.local. Since our DNS server is the REMnux
machine, it responds by resolving the domain to our own IP address. This allows us to
infer that the domain is likely associated with malicious activity, potentially intended to
perform harmful actions on the system.
Procmon
The images show the scenario where the malicious PuTTY executable was opened. For
analysis, we used Process Monitor and applied filters for the process name putty and the
Process operation, as we suspected the malware might be executing a malicious
PowerShell script. Our search confirmed this suspicion, revealing that a process was
created, executed, and then terminated. Clicking on the created process provided
additional insightful details.
At this stage, Process Monitor highlights a critical system event involving the execution of
PowerShell. The event details show that a powershell.exe process was successfully
launched from the SysWOW64 directory. The associated command line parameters,
including -nop (no profile), -w hidden (window hidden), and -ep bypass (execution policy
bypass), indicate an attempt to evade detection and execute a script without restrictions.
Further inspection reveals that this process attempts to connect to the domain it
previously queried, reinforcing the suspicion of malicious intent.
TcpView
At this stage, TCPView is being used to monitor network activity, revealing an active
network connection initiated by powershell.exe. The highlighted entry indicates that
powershell.exe (PID 4520) is attempting to establish a connection to a remote IP (10.0.0.3)
on port 8443. The connection is in the SYN Sent state, meaning the system has initiated
a TCP handshake, but the remote server has not yet responded. This behavior could
indicate an outbound command-and-control (C2) communication attempt or an
automated script execution.
Malware Analysis - Backdoor Connection
From our previous analysis, we confirmed that putty.exe attempts to connect to
bonus2.corporatebonusapplication.local on port 8443. To simulate the behavior of the
malicious domain, we first set up a basic server to receive the connection initiated by the
malware. We used the command:
nc -l 8443
After executing the malware, we observed the output but found that it was unreadable
and did not provide any logical interaction. At this point, we analyzed the SYN packets
sent by PuTTY in TCPView, which suggested that the connection was likely using SSL
encryption.
To test this hypothesis, we set up a listener with Ncat to handle SSL connections:
ncat -l --ssl -p 8443
With this setup, we successfully established remote access to the victim's terminal. This
confirms that the malware is designed to create a remote connection with the
bonus2.corporatebonusapplication.local domain, allowing the attacker to execute
arbitrary commands.
In this test environment, we demonstrated the attacker's potential control by executing
calc.exe, which launched the Calculator on the victim’s machine. This highlights the level
of access an attacker could gain, reinforcing the severity of the backdoor's capabilities.
Questions
1. Describe initial detonation. Are there any notable occurrences at first detonation?
Without internet simulation? With internet simulation?
At initial detonation, when the malware is executed, the PuTTY user interface appears as
expected—mimicking a legitimate application. This initial benign appearance masks its
true intent because the malware executes a hidden PowerShell command in silent mode.
• Without Internet Simulation: The PuTTY UI appears normal, and no overtly
suspicious behavior is observed immediately.
• With Internet Simulation: Host-based and network monitoring tools (like
Wireshark and Process Monitor) reveal that the malware performs a DNS lookup
and later attempts to initiate a remote connection, exposing its malicious behavior.
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?
The main payload involves the execution of a PowerShell process (located in the
SysWOW64 directory) with command line parameters such as -nop (no profile), -w hidden
(hidden window), and -ep bypass (execution policy bypass). These flags indicate an
attempt to run scripts in a stealthy manner.
• Tools for Identification:
o Process Monitor (Procmon): This tool can trace the process creation
events, showing the PowerShell execution and the sequence of operations
performed by the malware.
o Wireshark: This can be used to observe the network interactions initiated
by the malware, such as DNS queries and connection attempts.
3. What is the DNS record that is queried at detonation?
The DNS record queried at detonation is:
bonus2.corporatebonusapplication.local
This query is clearly visible in network captures using Wireshark.
4. What is the callback port number at detonation?
Network analysis using TCPView shows that the callback is attempted on:
Port 8443
5. What is the callback protocol at detonation?
The analysis suggests that the callback protocol is SSL/TLS. This conclusion comes from
observing the SYN packets in TCPView and the fact that when we set up a listener with a
plain Netcat (nc -l 8443), the output was nonsensical. However, when using an SSL-
enabled listener with Ncat (ncat -l --ssl -p 8443), we were able to obtain a functional
remote shell. These observations confirm that the malware communicates over an
encrypted (SSL/TLS) channel.
6. How can you use host-based telemetry to identify the DNS record, port, and
protocol? Attempt to get the binary to initiate a shell on the localhost. Does a shell
spawn? What is needed for a shell to spawn?
• Using Host-Based Telemetry:
o Process Monitor: You can monitor process creation and execution events
to identify when PowerShell is launched along with its parameters. This
reveals the sequence of actions the malware performs, including attempts
to connect to the malicious domain.
o Wireshark: By capturing network traffic, you can see the DNS query for
bonus2.corporatebonusapplication.local, the SYN packets indicating an
attempt to connect to port 8443, and infer from the encryption handshake
that SSL/TLS is in use.
• Shell Spawning:
When the binary is executed, it attempts to establish a remote connection.
However, a functional shell on the localhost will only spawn if the listener is
correctly configured to handle SSL. In our experiment, using a plain Netcat listener
did not yield a usable shell. Conversely, setting up an SSL-enabled listener with
Ncat (ncat -l --ssl -p 8443) allowed the binary to establish a remote shell session.
o What Is Needed:
▪ Correct Listener Setup: The listener must support SSL/TLS to
match the encrypted callback attempted by the malware.
▪ Proper Port Configuration: The listener must be running on port
8443 to intercept the connection.
Conclusion
This laboratory exercise underscored the critical importance of robust security practices
in the IT field. We observed that even a seemingly benign program can execute malicious
actions such as establishing remote connections if not properly scrutinized. Through this
controlled simulation, we gained valuable insights into how attackers may exploit systems
and how host-based telemetry and network monitoring tools can be used to detect and
analyze malicious behavior. Ultimately, this exercise highlights the need for thorough
preparation, continuous monitoring, and careful analysis when handling potentially
dangerous files.
