prernaprusty/RAT.Unknown.exe-malware-analysis

# RAT.Unknown.exe-Malware Analysis ## Static Analysis ### Tools required * HxD hex editor * HashMyFiles * Strings / FLOSS * Virustotal * PEview / PEStudio * IDA pro disassembler ### Process * **File identification and hashing:** * **Identifying the file type:** First we identify the file type using a hex editor such as HxD present in flareVM. We examine the first few bytes of the file known as magic bytes that tell us the type of the file instead of simply relying on file extensions. (4D 5A for .exe files).  * **Hashing:** Using HashMyFiles to find the cryptographic hash of the file to uniquely identify the malware sample.  * Upload the malware sample to **Virustotal** to match with known malware signatures to find whether the executable file is a malware or not.  * **String Extraction:** Using commands like 'strings' or using bintext to extract strings i.e. readable characters of information from the executable. * **Obfuscated string search:** To detect obfuscated strings within the malware using **FLOSS** and finding deobfuscated strings if possible.  * **Metadata and Header analysis:** Using tools like PEStudio or PEview to analyze the headers and find imported/exported functions.  * PEStudio analysis revealed: * Elevated `.text` section entropy (6.257), suggesting possible obfuscation or optimized compiled code * Large virtual memory allocation differences consistent with Nim runtime behavior * Presence of virtualized section characteristics * **Signature and Rule scanning:** To scan for known malware families, threat actor techniques and malicious traits by disassembling the malware and performing reverse engineering.  ### Findings * Identified Nim-based malware structure * Observed HTTP client creation for outbound communication * Identified startup persistence-related functions * Detected URI/path construction behavior * Located suspicious command/server-related functions ## Dynamic Analysis ### Tools Required * FlareVM (consists of all the tools required for dynamic analysis) * FakeNet-NG * Wireshark * Procmon * Command Prompt (ipconfig / ping) ### Environment Setup To perform dynamic analysis of a known malware sample, a safe and isolated environment needs to be configured so that the malware behavior can be studied efficiently without it affecting the host system. ### Process * Network Behavior: FakeNet-NG * FakeNet-NG was used to intercept and simulate network responses, preventing the malware from communicating with real infrastructure while capturing all attempted traffic. * C2 Beaconing: Upon execution, RAT.Unknown.exe (PIDs 1956 and 4924) immediately began sending DNS queries for the domain `serv1.ec2-102-95-13-2-ubuntu.local`. * After FakeNet resolved the domain, the malware established TCP connections to port 80 and issued HTTP GET requests. This DNS resolution followed by TCP connection repeated continuously in a tight loop, which is characteristic of C2 beaconing behavior. * The domain name itself (`ec2-102-95-13-2-ubuntu.local`) encodes an IP address in AWS EC2 format, suggesting the original C2 server was hosted on an Amazon EC2 instance.  * HTTP Requests Observed: Two distinct HTTP GET requests were captured across the two PIDs: * `GET /msdcorelib.exe HTTP/1.1`- sent with User-Agent `Nim httpclient/1.0.6`: This request attempts to fetch a file named `msdcorelib.exe`. The filename is deliberately crafted to resemble a legitimate Microsoft core library, a common masquerading technique. The `Connection: Keep-Alive` header indicates the malware expects to maintain a persistent connection, likely to complete a full file download. This confirms a **staged payload delivery** model - the initial dropper is designed to pull down and execute a secondary payload at runtime. * `GET / HTTP/1.1`- sent with User-Agent `intrt explr`: This uses the user-agent string `intrt explr` to impersonate Internet Explorer traffic and blend malicious activity with normal browsing behavior. * The presence of `Nim httpclient/1.0.6` directly confirms the binary is Nim-compiled, corroborating static analysis findings from PEStudio and FLOSS. * Background OS Noise: FakeNet also captured requests from `svchost.exe` (PID 7132) to `fs.microsoft.com` and from `explorer.exe` (PID 4736) to port 443. A Windows News Feed GET to `api.msn.com` was also present. These are background Windows processes and are not attributed to the malware.  * Procmon analysis: Process Monitor (Procmon) was filtered to `RAT.Unknown.exe` (PID 1800) to isolate host-based activity. * Payload Download and File Drop: After establishing TCP communication with the C2 server (FakeNet address `192.0.2.123`), the malware received data in alternating chunk sizes of 380, 4000, and 2108 bytes — consistent with downloading the staged payload requested via `GET /msdcorelib.exe`. * Immediately after the TCP receive events, the malware performed a `CreateFile` → sequential `WriteFile` → `CloseFile` sequence, writing the received data to: `C:\Users\\AppData\Roaming\Microsoft\...` * Writes were done in 4KB blocks (offsets 0, 4096, 8192, 12288 ... 28672), confirming the malware streams the payload to disk as it downloads it. The `AppData\Roaming` path requires no admin privileges, making it a common staging location for dropped payloads. * Multiple threads (IDs 5396, 5304, 7492, 6368, 4072) exited immediately after the file write completed, indicating the download and drop logic ran in dedicated worker threads that cleaned up on completion.  * Registry Key Access: The malware opened the Background Activity Moderator (BAM) registry key with `All Access` permissions: `HKLM\System\CurrentControlSet\Services\bam\State\UserSettings\S-1-5-21-4069915776-821494963-233` * BAM records the last execution time of binaries per user. Requesting `All Access` (rather than read-only) suggests the malware may be attempting to tamper with or delete its own execution record as an anti-forensics measure, instead of simply reading it.  * ICMP Connectivity Probing using Wireshark: The malware is sending ICMP echo requests in a rotating pattern to four different IPs, which are all public DNS resolvers, with "no response found" for all of them, i.e. there is no corresponding reply packet as we are performing the analysis in an isolated host-only VM. The following IPs are listed to which the request packets were being sent (Google and Cloudflare DNS): * `1.0.0.1` (Cloudflare DNS) * `8.8.8.8` (Google DNS) * `8.8.4.4` (Google DNS) * `1.1.1.1` (Cloudflare DNS) * All requests went unanswered in the isolated analysis environment, consistent with internet connectivity probing or sandbox-detection behavior prior to C2 communication.  * Loaded Modules of Interest: Two DLLs of significance were observed loaded by the process: * winhttp.dll: This module provides the HTTP client functionality used to communicate with the C2 server and issue the `GET /msdcorelib.exe` request observed in FakeNet.  * urlmon.dll: This module handles URL parsing and file download operations, directly supporting the staged payload fetching behavior.  * Both modules carry anomalous compile timestamps: 1983 and 1955 respectively, which are physically impossible for software built on Windows 10. This is a known artifact of Nim-compiled binaries and can be used to evade detection tools that rely on timestamp-based heuristics. ### Findings * Confirmed Nim-based RAT with active C2 beaconing over HTTP on port 80 * C2 domain `serv1.ec2-102-95-13-2-ubuntu.local` points to original AWS EC2-hosted infrastructure * Staged payload delivery: malware attempts to fetch and execute `msdcorelib.exe` from C2 * User-agent spoofing: uses both `Nim httpclient/1.0.6` and `intrt explr` to disguise traffic * Automated ICMP connectivity probing to public DNS resolvers before C2 communication * Key loaded modules `winhttp.dll` and `urlmon.dll` support HTTP communication and file download * Anomalous DLL timestamps (1983, 1955) consistent with Nim compiler artifacts, used for detection evasion