Rubrik Zero Labs’ AI-assisted malware analysis pipeline recently identified a new remote access trojan (RAT) dubbed BeepRAT, distributed through a Chinese phone number management utility packaged within HFY 号码魔方.zip. The archive contained a .NET application named HFY.exe alongside several third-party libraries commonly associated with database-driven applications. At first glance, the software appeared to function as a legitimate telephone number management tool; however, further analysis revealed a sophisticated multi-stage infection chain that ultimately deployed the BeepRAT malware framework.

Figure 1: Zip Content

Upon execution, the application silently created a working directory at %LOCALAPPDATA%\TCC and dropped several additional components, including tcc.exe, temp.bin, and config.ini.c. The file tcc.exe is the Tiny C Compiler executable used to compile and execute C code directly on the victim system. Analysis revealed that config.ini.c contains the C source code responsible for loading and executing a shellcode payload stored within temp.bin. 

Shellcode Loader

The file config.ini.c functions as a lightweight shellcode loader responsible for executing the contents of temp.bindirectly from memory. The loader traverses the Process Environment Block (PEB) to enumerate loaded modules and dynamically resolve the required APIs at runtime. It uses a Rotate-Right-13 (ROR13) hashing algorithm and compares the calculated values against hardcoded hashes corresponding to kernel32.dll, LoadLibraryA, and GetProcAddress.

Figure 2: Dynamic API Resolution

The loader subsequently attempts to open temp.bin using the dynamically resolved CreateFileA API. If the file is not present, execution terminates immediately. Upon successfully opening the file, the loader determines its size using GetFileSize, allocates a memory region of equal size through VirtualAlloc, and reads the contents of temp.bin directly into memory using ReadFile.

After loading the shellcode into the allocated memory region, the buffer is cast to a function pointer and invoked directly, transferring execution to the first byte of the payload and initiating the next stage of the infection chain.

Figure 3: Reading the Shellcode

Shellcode

The temp.bin payload contains an embedded Portable Executable (PE). Prior to loading the embedded executable, the shellcode performs several initialization routines, including functionality designed to bypass security mechanisms such as the Antimalware Scan Interface (AMSI), Event Tracing for Windows (ETW), and Windows Lockdown Policy (WLDP). 

Following these preparations, the shellcode locates the embedded PE image within memory and performs a reflective loading process. The embedded executable is mapped into memory, its execution environment is initialized, and control is transferred to the payload's entry point. 

Figure 4: Shellcode

Service-Based Execution

Execution begins within the Main() function of the .NET payload, where the malware checks whether it was launched with the -service command-line argument. If present, execution is redirected to a Windows Service component. A service object is created, causing the constructor to execute and invoke the InitializeComponent() function, which performs the required service initialization and registers the internal service name.

Once the service is started by Windows, the OnStart() routine is invoked and transfers execution to the malware's primary initialization function. This routine is responsible for preparing the runtime environment, loading configuration settings, initializing communication components, establishing command-and-control connectivity, and launching additional functionality required for operation. 

Environment Validation and HWID Generation

When the -service command-line parameter is not present, the malware follows its primary execution workflow. Before proceeding with installation activities, it executes an anti-analysis routine that uses Windows Management Instrumentation (WMI) queries against the Win32_OperatingSystem and CIM_Memory classes to identify characteristics commonly associated with virtualized environments. The malware evaluates operating system attributes and installed memory device information before determining whether execution should continue.

The malware then generates a unique hardware identifier (HWID) using multiple system attributes, including the processor count, username, computer name, operating system version, and system drive size. These values are combined and processed using the MD5 hashing algorithm to produce a victim identifier that is subsequently used during command-and-control communications and host registration.

Figure 5: HWID Generation

Privilege Escalation via UAC Bypass

Next, the malware verifies whether it is running with administrative privileges by checking membership in the local Administrators group. If elevated privileges are not available, the malware initiates a User Account Control (UAC) bypass procedure.

To achieve privilege escalation, the malware determines the operating system architecture and loads either the UAC_x86or UAC_x64 component directly from its embedded resources into memory. It then invokes an exported function named Appinfo and passes a command line containing the parameters required to execute the Tiny C Compiler (TCC) loader chain.

As a result, the malware is relaunched with the arguments -nostdlib -run "%LOCALAPPDATA%\TCC\config.ini.c", directly invoking the TCC-based execution workflow responsible for loading and executing the shellcode stored in temp.bin. After launching the elevated instance, the original process terminates and execution continues through the newly spawned process with administrative privileges.

Persistence via Scheduled Tasks

Once administrative privileges have been obtained, the malware invokes the InstallEx() function to establish persistence on the compromised system.

The malware uses the Windows Task Scheduler COM interface to locate or create a scheduled task named WindowsUpdateTempFileCleanUp. If the task already exists, the malware performs a mutex check based on the victim's hardware identifier (HWID) to determine whether another instance is already active and terminates execution if one is found.

If the task is not present, the malware proceeds with task registration. During this process, it interacts with the Windows Task Scheduler service through WMI and utilizes an architecture-specific task management component (SchTask_x86 or SchTask_x64) loaded directly from its embedded resources. The resulting scheduled task is configured to execute with the highest available privileges and launch the malware using the command line:

• -nostdlib -run "%LOCALAPPDATA%\TCC\config.ini.c"

Runtime Initialization and Command-and-Control Setup

After establishing persistence, the malware transitions into its primary runtime initialization routine. During this stage, it prepares the execution environment, determines the installed .NET CLR version, and initializes internal components required for command-and-control communications. The malware also supports a plugin framework that leverages the detected CLR version to ensure compatibility when loading operator-supplied .NET assemblies.

The malware then performs several preparatory operations, including DPI-awareness configuration, command-and-control address initialization, and optional offline keylogger activation. Analysis revealed that the malware can retrieve an alternative command-and-control address from the registry path HKCU\Software\Creeper, allowing operators to update infrastructure without modifying the embedded configuration.

Next, the malware determines whether to use TCP or UDP for command-and-control communications. Analysis of the examined sample revealed that TCP communications were configured and used throughout the infection lifecycle.

Figure 6: Start() Function

To establish connectivity, the malware resolves the configured command-and-control infrastructure using DNS-over-HTTPS (DoH) requests to doh.pub. If the DoH resolution process fails, the malware falls back to the standard Windows DNS resolver. During analysis, the malware resolved the command-and-control domain spasss.org to 207.56.8.166 and subsequently established a TCP connection over port 18848.

Following a successful connection, the malware initializes its communication structures, transmits victim registration information to the command-and-control server, and begins processing operator commands.

Victim Registration

Immediately after establishing connectivity with the command-and-control server, the malware transmits an initial registration packet identified as ClientInfo. This packet serves as a victim profiling mechanism and provides operators with a detailed overview of the compromised environment, including system information, user context, security products, execution details, and malware metadata. In the analyzed sample, the malware reported version 0.0.1.

A typical ClientInfo packet contains the following fields:

• Packet – ClientInfo
• HWID – Unique victim identifier
• User – Logged-in username
• OS – Operating system version and architecture
• Camera – Number of detected webcam devices
• Path – Executable path of the malware
• Version – Malware version
• Admin – Current privilege level
• Active – Active foreground window title
• AV – Installed antivirus product
• Install-Time – Malware installation timestamp
• Group – Operator-defined grouping identifier
• ClrVersion – Installed .NET CLR version
• LoadedPlugins – Currently loaded plugin modules

The registration packet also contains a LoadedPlugins field, which reports any operator-supplied modules currently loaded into memory. The malware supports dynamic capability expansion through .NET assemblies delivered by the command-and-control server. These assemblies are loaded directly into memory without being written to disk and can extend the functionality of the core implant.

Before transmission, the collected information is serialized using the MessagePack format and encrypted using the Rijndael (AES) algorithm operating in ECB mode with PKCS#7 padding. The malware utilizes the hardcoded encryption key "Qi_An_Xin_Niu_Bi" to protect command-and-control communications. Notably, the key contains a Chinese-language phrase that roughly translates to "QiAnXin is awesome" or "QiAnXin is impressive," potentially indicating that the developer was familiar with the Chinese cybersecurity ecosystem. 

The resulting encrypted MessagePack structure is prefixed with a length field and transmitted to the command-and-control server over the established TCP connection, allowing operators to rapidly assess the victim environment before issuing additional commands.

Heartbeat Communications

Following victim registration, the malware creates a periodic timer that executes the KeepAlivePacket() routine at randomized intervals ranging from approximately 10 to 15 seconds. This routine generates heartbeat packets identified as ClientPing, which are used to maintain command-and-control communications and provide operators with continuous visibility into victim activity.

Each heartbeat packet contains the victim's HWID, the title of the currently active foreground window, the measured network round-trip latency, and the amount of time elapsed since the user's last keyboard or mouse interaction. The packet structure consists of the following fields:

• Packet – ClientPing
• HWID – Victim identifier
• Message – Active foreground window title
• Roundtrip – Network latency measurement
• LastInput – User idle time

The active window title is obtained through the GetActiveWindowTitle() function, allowing operators to monitor applications currently being used by the victim.

The network latency value is generated through the pingRoundtrip() routine, which sends ICMP echo requests containing the string "BEEP" as shown in the below figure and records the measured response time. User idle time is obtained through the GetLastInputTime() routine and provides an indication of whether the victim is actively interacting with the system.

 Figure 7: Beep ICMP Packet

Like the registration packet, heartbeat messages are serialized using MessagePack and encrypted using Rijndael (AES)in ECB mode with PKCS#7 padding before being transmitted to the command-and-control server. 

Figure 8: Data Exfiltration

Command Processing and Post-Compromise Capabilities

After establishing command-and-control communications and completing victim registration, the malware creates a persistent communication channel with the remote server and continuously monitors the connection for incoming commands. Data received from the command-and-control server is decrypted using the malware's Rijndael (AES) communication routine and deserialized using the MessagePack format. The malware then extracts the command identifier stored within the Packet field and dispatches the request to the appropriate handler.

The command framework provides operators with extensive control over the compromised host, enabling long-term access, system monitoring, surveillance, and remote administration capabilities. The supported commands and their associated functionality are summarized in the below table. 

Additional Findings

Historical telemetry revealed earlier variants of the framework leveraging a LuaJIT-based execution chain. Analysis of samples with SHA-256 hashes aecc807b09025bc39800403f866c964dfaf2ee6104600dfad3e26edd4b115440 and 4ca2c99995daaabeebca8d86052c3467a3798d0fb73eb8a7e130431e1dcaf6eb showed the use of a LuaJIT runtime to execute shellcode stored within temp.bin. In these variants, a Lua script (config.ini) loaded the shellcode into memory using Windows memory allocation and thread creation APIs before transferring execution to the next-stage payload.

Figure 9: Config.ini

The analyzed sample replaces the LuaJIT runtime with a Tiny C Compiler (TCC)-based loader while preserving the overall shellcode execution architecture. This evolution suggests continued development of the malware framework while maintaining its core in-memory execution and payload delivery mechanisms.

Victimology

Analysis of the original HFY 号码魔方.zip archive revealed a file named data.dll. Although disguised as a DLL, the file is actually a SQLite database containing 517,154 records of Chinese mobile number prefix information.

The database maps mobile number prefixes to associated province, city, telecommunications carrier, area code, and postal code data. Sample records reference major Chinese telecommunications providers, including China Unicom (中国联通) and China Telecom (中国电信).

The presence of this large telecommunications lookup database indicates that HFY.exe was designed to manage large telephone number datasets. Combined with the application's phone number management capabilities, the software appears tailored for telecommunications-related environments, suggesting that telecommunications providers and similar organizations may be among the likely targets of the campaign.

Attribution Assessment

Analysis of the BeepRAT execution chain revealed the use of the Tiny C Compiler (TCC) to load and execute shellcode from memory. Similar use of TCC as a shellcode execution environment was previously documented by Rapid7 during its analysis of the Chrysalis backdoor associated with the Lotus Blossom threat group. In both cases, TCC functions as an intermediary execution layer responsible for launching subsequent in-memory payloads. 

Infrastructure analysis identified three domains associated with BeepRAT command-and-control activity: spasss.org, liebian.org, and svip88.org. Pivoting from the associated infrastructure revealed additional systems hosted within AS54801 (Zillion Network Inc.), including infrastructure linked to ValleyRAT, VShell, Cobalt Strike, and other remote access frameworks. 

Notably, ValleyRAT has previously been associated with activity attributed to the Silver Fox cluster, while VShell has been observed in campaigns linked to UNC5174. The presence of BeepRAT infrastructure alongside these tools provides additional context when assessing the broader ecosystem in which the malware operates.

Recent reporting by Seqrite documented a China-nexus campaign targeting a Chinese telecommunications provider and utilizing VShell for post-compromise access. While no direct operational overlap was identified, the telecommunications-focused nature of both campaigns provides additional context when assessing the likely targeting of BeepRAT.

Combined with the use of a Chinese phone number management utility as the malware delivery mechanism and the presence of multiple Chinese-language elements throughout the framework, the observed tradecraft and infrastructure relationships strongly suggest that BeepRAT operates within a broader China-nexus ecosystem, and Rubrik Zero Labs assesses with medium confidence that the malware is associated with this cluster.

Conclusion

BeepRAT demonstrates the continued evolution of modern malware frameworks through the adoption of unconventional execution mechanisms and modular in-memory payload delivery. The transition from LuaJIT-based loaders to a TCC-based execution chain, combined with extensive post-exploitation capabilities and telecommunications-focused delivery themes, highlights a deliberate effort to improve operational flexibility and complicate detection.

The observed tradecraft, infrastructure relationships, and broader China-nexus characteristics indicate that BeepRAT is part of a mature and actively maintained threat ecosystem rather than a one-off malware campaign. As adversaries continue to evolve their tooling and delivery mechanisms, organizations should prioritize behavioral monitoring, memory-based detection, and threat hunting strategies capable of identifying malicious activity beyond traditional file-based indicators.

Indicators of Compromise (IOCs)

File indicators

Network Indicators

YARA Rule

rule rbrk_BeepRAT_Dropper

{

meta:

author = "Rubrik Zero Labs"

description = "Detects BeepRAT Dropper"

date = "2026-06-25"

hash = "8239aafcf3cc7dacbac3566773622bf9db3b043d2b49b8c1638c2546eecc180f"
 

strings:

    $a = "HFY.exe" ascii wide

    $b = "temp.bin" ascii wide

    $c = "config.ini" ascii wide

    $d = "tcc.exe" ascii wide

    $e = "LuaJit.exe" ascii wide

    $f = "LOADLIBRARYA_HASH" ascii wide

    $g = "payload_len" ascii wide
 

condition:

    $a and

    $b and

    $c and

    ($d or $e) and

    ($f or $g)
 

}

MITRE ATT&CK Mapping