LabubaRAT: A Rust Based Remote Access Tool Masquerading as NVIDIA Software 

Key Takeaways 

• Blackpoint Cyber’s Adversary Pursuit Group (APG) identified a previously undocumented malware sample that we are tracking as LabubaRAT, a Rust based remote access tool masquerading as NVIDIA software. 

• LabubaRAT creates a reusable foothold for hands-on activity. Once deployed, it can profile the host, identify security tools, receive operator commands, move files, capture screenshots, and proxy traffic through the affected system. 

• The sample used fake NVIDIA metadata and runtime artifacts to blend into a Windows environment, including references to NVIDIA Container Runtime Monitor, a local nvctr_sys.db SQLite database, and an NVIDIA themed single instance mutex. 

• The implant supported multiple communication methods, including standard HTTPS polling, WebView2 based communication, and DNS tunneling, giving operators more than one path to maintain remote access. 

• Recovered functionality showed a full remote access capability set, including command execution, PowerShell execution, JavaScript execution, screenshot capture, file upload and download, archive handling, and SOCKS5 proxy support. 

• The associated command and control infrastructure presented a LabubaPanel title and Labubu themed favicon, which is where the LabubaRAT name was derived from. 

Executive Summary 

Blackpoint’s Adversary Pursuit Group (APG) discovered a previously undocumented malware sample that we are tracking as LabubaRAT, a Rust based remote access tool masquerading as NVIDIA software. The executable, nvidia-sysruntime.exe, used NVIDIA themed metadata and runtime naming, but its internal behavior showed a configurable implant built to register infected systems, receive operator tasking, execute commands, transfer files, capture screenshots, and proxy traffic. 

The LabubaRAT name is derived from the LabubaPanel title and Labubu themed favicon exposed by associated command and control infrastructure. The Windows implant also used a ZM_ prefixed configuration namespace for runtime settings, tying the sample to an agent model that accepted operator supplied values for organization, group, server, and key configuration. 

LabubaRAT was not built as a simple one-off payload. Its configuration model gave the operator a way to define an organization, assign a group tag, provide a server URL, and supply an API key at launch. After enrollment, the implant stored local state in a SQLite database and could communicate through several different paths, including HTTPS polling, WebView2 based communication, and DNS tunneling. That structure made the binary feel more like a reusable access framework than a single deployment artifact. 

Once running, the implant provided the operator with the core capabilities expected from a remote access tool. LabubaRAT supported shell execution, PowerShell execution, JavaScript execution, screenshot capture, file upload and download, archive handling, SOCKS5 proxy functionality, and optional user level persistence through HKCU Run. Those capabilities gave the operator enough control to interact with the host, move files in and out of the environment, route traffic through the system, and maintain access without relying on a separate loader or narrowly scoped follow-on tool. 

Technical Analysis 

Rust in the Runtime 

The sample, nvidia-sysruntime.exe, presented itself as part of NVIDIA’s container runtime tooling, but its structure and behavior did not match a legitimate NVIDIA component. The file was an unsigned 64 bit Windows GUI executable compiled in Rust. Its version information reinforced the NVIDIA theme with references to NVIDIA Corporation, NVIDIA Container Runtime Monitor, and NVIDIA Container Toolkit, making the file look like NVIDIA software at a glance. 

That NVIDIA identity also continued into the implant’s runtime artifacts. The sample created a single instance mutex named Local\NVIDIAContainerMonitor_SingleInstance, which prevented multiple copies of the implant from running at the same time while keeping the same monitor themed naming convention. Malware often uses a mutex to enforce one active instance per host, reducing duplicate execution and avoiding conflicts between multiple running copies. 

The file also exposed several development artifacts tied to its build environment. The PE compile timestamp was 2026-06-17 23:16:55 UTC, and Rust build paths referenced C:\Users\funt\.cargo\registry\…, identifying funt as the build environment username. The debug path, nvidia_container.pdb, continued the NVIDIA masquerade, but the surrounding Rust artifacts and recovered behavior identified the executable as a remote access implant rather than a legitimate runtime component (Figure 1). 

Figure 1: NVIDIA themed metadata and Rust artifacts exposed the sample’s masquerade. 

A Panel With Teeth 

The sample did not contain a hard coded C2 address. Instead, it accepted runtime configuration through command line arguments and matching environment variables. Those values allowed an operator to define the organization, API key, server, group, device name, DNS settings, and polling intervals used by the implant. Each setting could be supplied in one of two ways: as a command line argument passed to the executable, or as a matching environment variable using the ZM_ prefix. In that model, –server and ZM_SERVER represent the same configuration value, just delivered through different input sources. 

The sample also supported a –b parameter that acted as a Base64 encoded wrapper for the same runtime arguments. Instead of passing –org, –key, –group, and –server as separate visible switches, an operator could pack those values into one encoded argument and let the implant decode them at startup (Figure 2). The embedded help text described –b as Base64 encoded arguments used by the autostart entry, tying the feature directly to the sample’s persistence model. 

A Figure 2: The –b value decoded into the runtime configuration used by the agent. 
  

In the observed execution, the operator used that –b format. The encoded value decoded to –org luxespa, –key 8c4e4804f21649e5ddc6a5670f3b3828a43bff304f02f184f9842c2569570f3d, –group rabbit, and –server hxxps[://]pipicka[.]xyz. Because those values were provided at launch, the same compiled binary could be reused with different infrastructure, organizations, or campaign groupings instead of relying on a hardcoded server. 

Once configured, the implant maintained local state in a SQLite database named nvctr_sys.db. The database schema created a key value table and an event table, with SQLite write ahead logging enabled and synchronous mode set to normal. That structure gave the implant a simple way to preserve enrollment data, runtime configuration, and operational events between executions. 

Figure 3: The SQLite schema defined local storage for configuration, device state, and event tracking. 

The local database also matched the implant’s runtime configuration model. The agent defined stored keys for server_url, device_name, device_token, dns_domain, dns_resolver, poll_min_secs, and poll_max_secs. Those values mapped back to the launch arguments and showed how the implant could register once, retain its assigned identity, and reuse the same configuration during later polling. 

Registration extended that local state into a host profile for the operator. The agent prepared fields for token, org_slug, api_key, group, hostname, cpu_model, ram_gb, ip, connection_type, domain, uac_enabled, antivirus_list, and browsers. The browser inventory included Chrome, Firefox, Microsoft Edge, and Brave, while security product discovery relied on uninstall registry keys and product name matching. This gave the operator enough context to understand where the agent had landed before issuing follow on tasking, 

Security product discovery focused on installed software and Defender configuration. The agent checked common uninstall registry paths, including SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall, along with SOFTWARE\Microsoft\Windows Defender. The product matching covered a broad set of security tools, including Microsoft Defender, CrowdStrike, SentinelOne, Carbon Black, Sophos, Malwarebytes, Bitdefender, ESET, Kaspersky, McAfee, Symantec, Trend Micro, and others. 

The fingerprinting gave the operator useful context before tasking began. By collecting browser inventory, UAC state, domain information, and security product details, the agent gave the panel a quick view of the host and the controls around it. That context matters for a RAT because later actions such as shell execution, file transfer, screenshot capture, and proxying may be shaped by the security tools present on the system. 

The registration model also looked more like a panel backed service than a simple hardcoded RAT configuration. The observed luxespa organization and rabbit group values mapped directly to the binary’s supported arguments, while the embedded help text gave group examples such as room-1, sauna, and vip-chair. That kind of organization and grouping structure suggests the backend was designed to sort enrolled agents across tenants, campaigns, customers, or operator defined collections. This suggests that LabubuRAT may be a Malware as a Service (MaaS) style platform, where the same agent can be reused across multiple deployments and managed through shared infrastructure. (Figure 4) 

Figure 4: The host profiling logic of the RAT collected endpoint details before tasking. 

The observed server, pipicka[.]xyz, presented a mostly blank page in a browser, but the page title exposed LabubaPanel and the favicon used a Labubu themed image (Figure 5). APG derived the LabubaRAT tracking name from that panel artifact. 

Figure 5: The LabubaPanel title and Labubu themed favicon used by the C2 domain. 

That panel structure also provided useful infrastructure pivots. APG pivoted from the pipicka[.]xyz C2 page structure and identified three additional C2 IP addresses hosted on German providers using the same panel structure. Those servers appeared over time beginning in early June, which aligned with the compile timestamp from the binary. The timing suggests this infrastructure and sample were part of the same broader LabubaRAT rollout rather than an isolated one-off deployment. 

The Rust implementation included standard HTTP client components associated with reqwest, hyper, rustls, tokio, and JSON serialization. Its request construction supported bearer authentication, JSON content type headers, accepted language values, and multiple browser style User-Agent options, including Chrome, Edge, Firefox, Opera, and macOS Chrome profiles. That path gave the implant a standard HTTPS polling mechanism for registration and tasking while authenticating requests back to the panel with a bearer token. 

The implant also included WebView2 based communication components, with source path references to src\webview_login.rs and src\webview_poll.rs. The embedded JavaScript used fetch() and returned responses through window.chrome.webview.postMessage(…), allowing the agent to communicate through an embedded Microsoft Edge WebView2 context instead of relying only on the Rust HTTP client. That gave the implant a second web communication path that blended more closely with browser backed application behavior while still returning data into the agent. 

DNS tunneling provided another supported communication path. The DNS agent logic referenced resolver, domain, polling, Base32 decoding, payload chunking, and timeout handling (Figure 6). Error handling for oversized DNS payloads and chunk counts showed that this mode was built to move tasking data through encoded DNS queries rather than only perform simple domain resolution. That gave the implant a fallback transport that could operate separately from normal HTTPS polling. 

Figure 6: The RAT supported HTTPS, WebView2, and DNS based communication paths. 

A Full Bag of RAT Tricks 

Once the agent was configured and able to communicate, its tasking model gave the operator direct control over the host. Task objects used fields such as request_id, command, action, and args, allowing the backend to send work to the agent and associate returned output with the original request. The supported commands showed that the sample was not only a downloader. It already contained the functionality needed for remote interaction, file movement, host visibility, and traffic relay. 

For execution, the agent supported cmd, powershell, and javascript commands. The cmd and powershell paths gave the operator access to native Windows shell and scripting functionality, while the JavaScript path wrote task content to a temporary wupd_ prefixed script file and executed it through Windows Script Host. Each execution path included timeout handling, allowing the agent to return control instead of hanging indefinitely when a command failed or never completed. 

The JavaScript task path wrote a temporary script file using a wupd_ prefix and invoked Windows Script Host style flags including //NoLogo and //E:JScript. That gives an operator a second script execution path separate from PowerShell. In environments where PowerShell logging or controls are stronger than Windows Script Host coverage, this flexibility can change what defenders see first. 

The screenshot command used Windows GDI APIs to capture the desktop and return the image as Base64 encoded data. API references included GetDC, CreateCompatibleBitmap, BitBlt, and GetDIBits, which are common building blocks for screen capture on Windows (Figure 7). For an operator, that capability provided visibility into the user session without requiring interactive remote desktop access. 

Figure 7: LabubaRAT supported command execution and screenshot capture through built in task handlers. 

File system tasking expanded the operator’s control beyond command execution. The agent supported download, upload, delete, mkdir, archive, and unarchive actions, giving it the ability to retrieve files from the host, write operator supplied content to disk, remove artifacts, create directories, and package file collections for transfer. Archive support made the file module more useful than basic upload and download because it allowed the agent to bundle data before movement or unpack staged content after delivery. 

The sample also included SOCKS5 relay functionality through socks5_start and socks5_stop commands. The relay logic expected a tunnel_url, which allowed the agent to connect back to operator-controlled relay infrastructure and proxy traffic through the compromised host. That capability turned the endpoint into more than a remote shell; it gave the operator a way to route traffic through the system. 

Persistence was supported through a user level HKCU Run model. The embedded help text described an –install mode that added the agent to Windows user level autostart and an –uninstall mode that removed it (Figure 8). Combined with the Base64 encoded –b argument, the persistence path could preserve the same runtime configuration while keeping the visible autostart command line shorter and less obvious than separate plaintext switches. 

Figure 8: The RAT combined file handling, proxy support, and user level persistence. 

At that point, LabubaRAT had everything it needed to operate as a full remote access tool. It could check in, receive tasking, run commands, move files, capture the screen, proxy traffic, and preserve its configuration through user level autostart. The result was not a lightweight downloader waiting for another payload to do the real work, but an agent with enough built-in capability to give an operator immediate control over the host. 

Conclusion 

LabubaRAT is more than a renamed binary with fake NVIDIA metadata. The sample combined runtime configuration, local state, host profiling, multiple communication paths, and operator tasking into a complete remote access tool. Its design allowed the same compiled agent to be pointed at different infrastructure, assigned to different groups, and managed through a panel-backed workflow without requiring a new build for each deployment. 

The implant’s configuration model was one of the clearest signs of that broader structure. The –b argument packed deployment values into a Base64 encoded block, while the ZM_ namespace provided matching environment variable support for the same settings. Once configured, the agent could retain state in SQLite, register host details, communicate over HTTPS, WebView2, or DNS, and wait for operator issued commands. 

That combination makes LabubaRAT feel less like a one-off payload and more like reusable access infrastructure. The malware gave an operator a practical way to enroll hosts, understand the environment around each agent, execute commands, move files, capture screenshots, proxy traffic, and maintain user level autostart. The LabubaPanel branding provided the clearest external naming clue, but the more important finding is the framework-like structure behind it: a Rust based RAT built to be configured, enrolled, and operated across multiple deployments. 

Recommendations for Prevention and Detection 

• Validate unsigned binaries with mismatched vendor metadata. Prioritize unsigned executables that claim a trusted vendor identity, such as NVIDIA, while running from unexpected paths or showing network, tasking, or persistence behavior. 

• Hunt for abnormal Base64-like command line arguments. Prioritize uncommon executables launched with long encoded blobs, especially when paired with persistence, network activity, or decoded values that reveal server, group, key, DNS, or polling configuration. 

• Review user level autoruns with encoded arguments. Check HKCU\Software\Microsoft\Windows\CurrentVersion\Run entries that launch unknown executables with Base64-like blobs or deployment configuration. 

• Hunt for local enrollment artifacts. Search for nvctr_sys.db, associated -wal and -shm files, and stored keys such as server_url, device_token, dns_domain, and polling intervals. 

• Detect RAT task execution from unusual parent processes. Alert on uncommon processes spawning cmd.exe, powershell.exe, wscript.exe, or cscript.exe, creating wupd_ prefixed JavaScript files, invoking screenshot APIs, or performing file archive and transfer activity. 

• Review outbound traffic for LabubaRAT transport patterns. Look for non-browser processes using browser style User-Agents with bearer authentication, WebView2 backed requests, high entropy DNS tunneling, or SOCKS5/WebSocket relay behavior. 

Indicators of Compromise 

Type	Indicator	Context
File name	nvidia-sysruntime.exe	Analyzed Windows executable
SHA-256	b7443b0ab48d2f5786d1b6f3a580f02621e9ae5a3877ee3a44e01df13d984328	Analyzed LabubaRAT sample
MD5	d8bf355a198fb5db3ea65cfdfcdfbd19	Analyzed LabubaRAT sample
PDB path	nvidia_container.pdb	Debug path artifact
Build path username	C:\Users\funt\.cargo\registry\…	Rust build path artifact
Mutex	Local\NVIDIAContainerMonitor_SingleInstance	Single instance mutex
Local database	nvctr_sys.db	SQLite local state database
C2 URL	hxxps://pipicka[.]xyz	Observed configured server
IP Address	191.44.109[.]130	Identified related infrastructure
IP Address	87.120.108[.]18	Identified related infrastructure
IP Address	168.222.254[.]204	Identified related infrastructure