Overview:

The binary njRAT.exe is a Remote Access Trojan (RAT) that allows an attacker to take control of a victim’s computer remotely. njRAT.exe monitors and records the victim’s activity for surveillance purposes. When executed on the victim’s system, it can launch additional payloads. If internet access is available, njRAT listens for incoming connections from an attacker. Once connected, the malware reports all running activities on the host and continues to update the attacker as new activities occur.

Basic Static Analysis:

SHA256 Hash

Table 1: ShHA256 Hash of njRAT.exe

Malware Repo Search: VirusTotal

I put the file hashes on VirusTotal to see if the sample had been submitted before, how recently, and what telling behaviour could be found about it.

The report showed that most antivirus engines did not flag the njRAT-v0.6.4.zip file as malicious. However, 63 out of 73 engines found the actual malware sample, njRAT.exe, malicious.

Figure 1: VirusTotal Report on njRAT-v0.6.4.zip hash

Figure 2: : VirusTotal Report on njRAT.exe hash

To glean for clues. I extracted strings from the binary using the floss command in Flare VM.

String Extraction

Table 2: Notable strings in the binary

Capability

I checked for the MITRE Cyber Analytics Repository Behavior Classification for the malware with the Capa tool. It showed that the malware is a process creator.

Table 3: Investigating the malware behaviour with the Capa tool

Command	capa njRAT.exe
Capa output

PEstudio

I checked the executable on PE studio and found information such as the compile and debug time, the debug information, and the original file name. I also identified possible malicious indicators, such as obfuscation with base64 encoding, file download processes, and code execution.

Table 4: Investigation with PEStudio

PEstudio Overview

PEstudio Indicators

Basic Dynamic Analysis:

Initial Detonation without Internet Simulation

I executed the binary on FlareVm without internet access. An error message popped up stating that the njRAT.exe application was unable to find or load the NAudio.dll assembly, specifically version 1.5.4.0. The fact that njRAT.exe requires NAudio.dll indicates that it might use audio-related features. I ignored the error and clicked continue.

Figure 3: Malware detonation and error message

ProcMon

I filtered for the njRAT.exe process name on Process Monitor (ProcMon) and observed some file creation activities.

Figure 4: Filtered output from Procmon

I used the process tree feature on Procmon to investigate the malware it is responsible for further.

The njRAT.exe (PID 948) created and executed the second-stage payloads, njRAT.exe (PID 3624) and njq8.exe (PID 624) in the C:\ directory.

The njq8.exe payload dropped and executed the windows.exe in the C:\Users\secopsbro\AppData\Local\temp directory. The windows.exe then launched the netsh.exe (a command-line utility in Windows that is used to configure and manage network settings, including firewall settings.) with the command,

netsh firewall add allowedprogram "C:\Users\secopsbro\AppData\Local\temp\windows.exe"

Essentially, the command adds windows.exe, located in the C:\Users\secopsbro\AppData\Local\temp directory, to the list of programs allowed by the Windows Firewall. Once added, windows.exe will be able to establish and receive network connections without being blocked by the firewall.

Figure 5: Procmon process tree

Figure 6: File path to the windows.exe

Investigating the second-stage payloads:

I began investigating the second stage payload by grabbing file hashes.

Sha256 Hashes

Table 5: File hashes for the second state payloads

I observed that the SHA256 hash values for njq8.exe and windows.exe are an exact match, meaning that the executables are the same.

Second stage payload: njq8.exe in C:\

I ran capa against njq8.exe to observe its behaviour according to the MITRE behaviour classification. The result indicated that the file is a downloader and has data collection capabilities, including keylogging and screen capture.  

Figure 7: capa output for the second stage payload, njq8.exe

PEstdudio

I observed the import flags of the binary from PEStudio and noticed some potential indicators.

Figure 8: Observing njq8.exe in PEstudio

Second-Stage Payload: njRAT.exe in C:\

Running Capa on njRAT.exe revealed that the file is a launcher with data collection abilities. 

Figure 9: capa output for njRAT.exe in C:\ directory

PEstudio

Some notable information about the binary observed in PEstudio are captured in the image below. The tools section showed that the binary was written in C#, Basic.NET and Microsoft.NET.

Figure 10: Information on the binary from PEstudio

Second Stage Payload: windows.exe

NOTE: njq8.exe has the same hash value as windows.exe, and the two files behave the same way.

Malware Detonation with Internet Simulation

I began by running inetsim on Remnux machine. Inetsim serves a default page for all attempts at internet connection, tricking the malware into acting as if the compromised machine has internet connection. This allows us to investigate network indicators without being connected to the real internet.

Figure 11: Running inetsim on Remnux

I filtered for the process name njRAT.exe, njq8.exe and windows.exe in ProcMon.

I spurned up TCPview on the Flare host and Wireshark on RemNux to monitor network activities. Then, I ran the binary with administrative privileges.

Figure 12: Setting Wireshark

Upon detonation, I observed the second-stage payloads from basic static analysis (windows.exe) running with a listener on port 1177.

Figure 13: Listening instace of windows.exe captured on tcpview

I simulated the attacker by connecting to the host via netcat. I received some system information such as the computer name (FlareVM), current user (secopsbro), date (2024-10-24), system architecture (Win 10 Enterprise EvaluationSPO x64), version number (presumably of the windows.exe file) and some base64 encoded strings as output.

Figure 14: Running netcat to connect to the victim host

Figure 15: Showing connection establishment on tcpview.

Upon decoding the first base64 encoded string, the message was Hacked?E5FE0CB

Figure 16: Decoding base64 encoded strings

Upon decoding the other base64 string, we see information about running application on the Flare host.

NOTE: The invalid input from the screenshot above is the response to the whoami command immediately the reverse shell was established. Therefore, we can safely assume that the windows.exe malware was not designed with command execution capabilities.

As more processes open on the Flare host, the information is displayed on Remnux.

Figure 17: Activities encoded in base64

I found found the same activities on Wireshark by filtering for tcp connections

Figure 18: Activities encoded in base64 in Wireshark

Detection Rules

Detection rules are predefined sets of criteria used in cybersecurity to identify suspicious or malicious activities, files, or behaviors within a network, system, or file. These rules help security tools and analysts detect threats, respond to incidents, and mitigate potential risks.

Yara Rule

YARA is a tool aimed at helping malware researchers identify and classify malware samples. YARA rules are used to define patterns to match against files or data streams to detect malicious files or suspicious content.

rule njRAT-v0.6.4_Detection
{

    meta:

        author = "SecOpsBro"

        description = "YARA rule to detect njRAT.exe"

        date = "2024-11-11"

        sha256_hash = "FD624AA205517580E83FAD7A4CE4D64863E95F62B34AC72647B1974A52822199"

    strings:

        $string1 = "netsh firewall add allowedprogram" ascii

        $string2 = "windows.exe" ascii

        $string3 = "zaaptoo.zapto.org" ascii

        $string4 = "njq8.exe" ascii

        $string5 = "NAudio.dll" ascii

        $base64_encoded_indicator = "Hacked?E5FE0CB" ascii

    condition:

        (uint16(0) == 0x5A4D) and // PE file signature (MZ header) and

               ($string2 and $string4) or

               string1

}

Sigma Rule

Sigma is a generic and open format for writing rules to detect suspicious activity in log files. It is often referred to as the “SIEM detection rule language,” as it is designed to create platform-independent rules that can be converted into formats specific to various SIEM (Security Information and Event Management) solutions.

title: njRAT-v0.6.4 Malicious Behavior Detection
id: 65215bcd-e686-4601-8925-518d3bfa62a2
description: Detects behavior associated with the execution of njRAT malware, including firewall modifications and suspicious file executions.
status: experimental
author: SecOpsBro
refrence: https://github.com/ytisf/theZoo/tree/master/malware/Binaries/njRAT-v0.6.4 
date: 2024-11-11
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    EventID:
      - 4688  # Windows Event ID for process creation
    Image|endswith: 
      - '\windows.exe'
      - '\njRAT.exe'
      - '\njq8.exe'
    CommandLine|contains:
      - 'netsh firewall add allowedprogram'
      - 'C:\Users\*\AppData\Local\temp\windows.exe'
  condition: selection
fields:
  - EventID
  - Image
  - CommandLine
  - ParentImage
  - User
  - ProcessId
falsepositives:
  - Legitimate use of netsh for firewall modifications
  - Testing or administrative scripts using similar commands
level: high
tags:
  - attack.persistence
  - attack.defense-evasion
  - attack.execution
  - attack.t1071

Conclusion

In this exercise, I analyzed a Remote Access Trojan binary, njRAT.exe, sourced from the Zoo malware repository on GitHub. Analysis revealed that the sample was originally compiled in 2013 as EnKSaR.HaCKeR.exe. The malware is designed to grant an attacker remote control over a victim’s computer. My analysis revealed that, upon execution, the sample launched additional payloads, including njRAT.exe, njq8.exe, and windows.exe. The second-stage payload, njq8.exe, generated windows.exe, adding itself to the Windows Firewall exceptions and listening to port 1177 for a remote connection. Simulating an attack from a Remnux machine, I connected to the open port and observed the malware recording system details, such as architecture, date, and active applications.

Although audio activities were not detected, the NAudio.dll error message during execution indicates the malware likely has audio-related capabilities, potentially for eavesdropping or audio manipulation.