# Introduction

Following the static analysis of the sample, I came up with a few findings that needed confirmation, as well as, some things that are either contradicting or weird that needed further clarification. In this post I will try to clarify/confirm these things through dynamic analysis.

# Main Findings

From the static analysis I gathered some clues and made the following hypothesis;

1. The main exe is only a dropper and not the actual payload/malicious software.
2. The presence of the malware is unknown to the user since ShowInTaskBar is set to false and the opacity of the window is set to 0.0.
3. Conflicting manifests suggest that one of them (the default) is used as a decoy or a means to escalate privileges.
4. Uses TCP Client to communicate and possibly exfiltrate data to the C2 server.
5. Uses camera and microphone
6. Makes changes to the registry for persistence
7. Makes configuration changes to the firewall
8. zaaptoo C2 server

The main goal of this paper is to go through my setup, the problems faced, the tools I used and finally confirm the above hypothesis through dynamic analysis.

# Analysis Environment

The environment I have is a simple vmware workstation virtual machine running windows 10 home that has flare set up in it.

The following tools were used to carry out this analysis;

There are certain problems that I had to work around, for example, I had a suspicion that the domain I found was the C2 server. When I tried to ping it, it was down. I feared that if the malware tried to call home while the server is down, it might decide to terminate and not go through with any other operation. I went around this problem by using FakeNet, which simulated and a fake response from the alleged C2 server just to get the malware going.

The plan was to have procmon running while the malware ran, to see the processes that the malware spawns or terminates. By default there is a ton of noise that is in procmon, so I have the following filters set up.

Wireshark is also set to capture packets on localhost. It is set that way since FakeNet is running.

Before everything, I took a snapshot of the registry before running the malware. Later on, I took another one once the malware has ran for a few minutes.

# Execution & Observations

Procmon gave me a clear outline of what happens exactly when the malware first runs. The diagram below showcases my understanding of the timeline from when the malware first ran until it seems to have ceased activity.

From the moment the malware ran a few things were confirmed. Firstly that specific exe is actually a dropper. The 2 files njq8.exe and njRat.exe have been dropped and a process for them has been created.

From there onwards, 2 other files have been created. The first is a log file in "C:$LogFile", the contents of which seem useless (which is weird — I thought it would be valuable. The second file is another executable that seems to take over from the first 3, since procmon only shows logs for that new exe only and not the other 3. The exe is windows.exe created in C:\Users\raad\AppData\Local\Temp\windows.exe. This exe must be analyzed separately later.

Another thing that was confirmed is that the malware does in fact communicate with a C2 server through TCP Send. windows.exe itself send a TCP Connect to the C2 server through outbound port 1177.

Finally, the last obvious confirmation is that the windows registries are actually being changed by the malware. This is confirmed through 2 things, procmon and also regshot. The difference between the 2 snapshots shows HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\ecc7c8c51c0850c1ec247c7fd3602f20. Confirming both persistence and persistence through registry keys.

Procmon also confirmed that there are firewall configuration changes that are being made.

Digging deeper into the FakeNet logs, there seems to be a beacon beginning-of-communication packet that looks like the C2 server is fingerprinting victims. I have broken down the packet to the following table;

The "cam" field makes the idea of the malware also spying on webcams not ridiculous or far fetched anymore.

Also the communication pipeline is plaintext and not encrypted by TripleDES as I initially thought.

# Confirmation

# Conclusion

The dynamic analysis verified the most hypotheses proposed in the static analysis. The sample is a two-stage chain; its operation begins with the silent dropper that unpacks and runs njRAT.exe and njq8.exe, which further distribute the payload as windows.exe, a file name that is selected to disguise it as the typical system process. Persistence is ensured through Run keys in both HMLM and HKCU, making it possible for the sample to persist across reboots irrespective of the user logging in. In addition, changes are made to the firewall to enable incoming TCP and UDP connections for windows.exe in the public profile, allowing for operator communication with the infected host. The connection to the C2 server takes place right after the infection is launched, using port 1177 and the initial packet containing the plaintext victim fingerprint data. The use of plaintext C2 beacon conflicts with the indication of TripleDES encryption observed during static analysis; the encryption seems to be applied to the following operator commands, not the first registration packet. The camera value of "No" from the C2 beacon, where the virtual machine does not have an active camera, matches the NAudio.dll observed in the static analysis, but the capture of audio and video data cannot be verified until the camera is connected.