LabubaRAT — Rust-Based RAT Masquerading as NVIDIA Software

LabubaRAT is an unsigned 64-bit Rust remote access trojan that impersonates NVIDIA container runtime software (nvidia-sysruntime.exe) to establish a durable, hands-on-keyboard foothold on Windows hosts. It is not a downloader: the operator gets host profiling, command execution (cmd/PowerShell/JavaScript), file transfer, screenshot capture, and SOCKS5 traffic-proxying from a single binary, enrolled at launch via command-line flags or ZM_-prefixed environment variables (org, group, server, API key) rather than a hardcoded C2. That configuration model, three redundant C2 channels (HTTPS polling, WebView2, DNS tunneling), and a panel-branded backend ("LabubaPanel") point to a reusable, multi-tenant access framework consistent with a malware-as-a-service offering rather than a one-off implant.

The attacker's objective is durable remote access with built-in pivot capability: LabubaRAT's SOCKS5 proxy support lets an operator route further traffic and tooling through the compromised host, and its renamed-MSBuild follow-on stage (BuildCoordinator.exe proxy-executing a build project that loads DotNetZip.dll) shows the operator escalating from the implant into trusted-utility abuse once access is confirmed.

The single highest-value defensive angle is the masquerade itself: nvidia-sysruntime.exe is not a real NVIDIA binary name under any legitimate install, so any execution of a file by that name is a near-zero-false-positive tripwire (Q1, below). Pair that with blocking the three confirmed C2 IPs and the pipicka[.]xyz domain (Q7) and an ASR rule against untrusted new executables (§12), and the highest-confidence portion of this campaign is covered without waiting on deeper DNS-tunnel or in-memory analysis.

Defender priority: block/detect the confirmed C2 (Q7, §10 CSV) and hunt for nvidia-sysruntime.exe execution (Q1) and its HKCU Run-key persistence (Q3) fleet-wide this week — those three checks alone cover the implant's entry point, its C2, and its survival mechanism.

Four sources were fetched directly and saved verbatim to LabubaRAT-Hunt-sources/ for provenance tracing. All four trace to a single primary research effort — Blackpoint Cyber's Adversary Pursuit Group (APG) — republished by two secondary outlets that cite Blackpoint and add no independent atomic indicators of their own. The original technical disclosure was published 2026-07-14; the Blackpoint Threat Snapshot dated 2026-09-17 is a condensed re-publication of the same research and is the most current dated reporting, not a new investigation. No corroborating IOC set from a second, independently-researching vendor (Mandiant, Talos, Microsoft, Unit 42, etc.) was located as of 2026-09-23.

Corrections against the task brief: the brief's atomic values (hashes, domain, IPs, config values) were verified character-for-character against the fetched sources and are accurate as given. One brief claim is softened here: the brief states LabubaRAT is "offered under a malware-as-a-service model" as fact; both Blackpoint's own original analysis and both secondary outlets frame this as an inference from the framework-like architecture (configurable org/group/server/key, panel branding) rather than a confirmed commercial offering — Help Net Security explicitly notes Blackpoint "stopped short of attributing it to a malware-as-a-service offering." This pack treats MaaS as likely, evidence-based, not confirmed.

Because every atomic indicator in this pack traces to a single research origin (Blackpoint APG), no indicator ships at Falcon CSV action prevent regardless of narrative severity — all IOC-management rows in §10 ship as detect. This matches HuntPack's standing two-source policy for prevent/critical-severity action, and the §4 IOC table's Action column is kept consistent with that CSV rather than diverging from it.

Hunt hypotheses

1. H1 (high conf): A process file-named nvidia-sysruntime.exe executing anywhere in the environment is LabubaRAT — the name is not a real NVIDIA artifact. → Q1.
2. H2 (high conf): A process command line or environment carries --org/--key/--group/--server, a long Base64 blob after -b, or a ZM_-prefixed variable — the implant's enrollment configuration. → Q2.
3. H3 (high conf): An HKCU Run-key entry combines a long Base64 value with an NVIDIA-themed or LabubaRAT-named target — the implant's persistence mechanism. → Q3.
4. H4 (high conf): A process file-named BuildCoordinator.exe is a renamed MSBuild binary used to proxy-execute a follow-on build project. → Q4.
5. H5 (medium conf): Elevated or bursty DNS query volume with long subdomain labels toward a single low-reputation domain indicates the DNS-tunneling C2 channel. → Q5.
6. H6 (high conf): A WebView2 runtime process is spawned by the LabubaRAT process tree rather than a browser — the implant's WebView2 C2 channel. → Q6.
7. H7 (high conf): Any connection to the three confirmed host IPs or the pipicka[.]xyz domain is LabubaRAT C2 traffic. → Q7.
8. H8 (medium conf): A flagged LabubaRAT process fanning out to many distinct remote IPs indicates the SOCKS5 proxy/relay capability in use. → Q8.
9. H9 (medium conf): Creation or access of nvctr_sys.db (+ -wal/-shm) is the implant's local enrollment/state database. → Q9.
10. H10 (high conf): wscript.exe/cscript.exe invoked against a wupd_-prefixed temporary script with //NoLogo //E:JScript is the implant's JavaScript task handler. → Q10.

Attack chain

All atomic indicators below trace to a single research origin (Blackpoint APG) — see §2. Action values are held to detect/hunt/enrich/pivot only; nothing ships at a blocking/prevent action from a single source.

For endpoints without Falcon sensor coverage, or as compensating telemetry, the following native Windows checks cover the same behaviors as the CQL queries in §8.

• Event ID 4688 (Process Creation, with command-line auditing enabled via Include command line in process creation events GPO) filtered for NewProcessName ending nvidia-sysruntime.exe or BuildCoordinator.exe, or CommandLine matching the ZM_/--org/--key/--group/--server/-b patterns from Q2.
• Event ID 4104 (PowerShell Script Block Logging) for encoded or unusual blocks spawned under a nvidia-sysruntime.exe parent — covers the implant's PowerShell task handler where Falcon is absent.
• Event ID 4657 (registry value modified, requires SACL on the Run key) on HKCU\Software\Microsoft\Windows\CurrentVersion\Run for newly added values containing a long Base64 blob.
• Windows Defender ASR audit events 1121 (Block) / 1122 (Audit) for the "Block executable files from running unless they meet a prevalence, age, or trusted list criterion" rule (GUID 01443614-cd74-433a-b99e-2ecdc07bfc25) — see §12/§13.
• DNS server / resolver query logs (on-prem DNS, Umbrella, Cloudflare Gateway, or Defender for DNS) for high query-volume or long-label subdomains resolving to pipicka[.]xyz or an unclassified parent domain — works even without endpoint telemetry and is often the fastest way to catch the DNS-tunnel channel at the network edge.
• Sysmon Event ID 1 (Process Create) as a fallback where Falcon is not deployed, matching the same filenames and command-line patterns as Q1/Q2/Q4/Q10.
• Sysmon Event ID 3 (Network Connection) as a fallback for Q7/Q8's remote-IP matching.

The Local\NVIDIAContainerMonitor_SingleInstance mutex is not observable via Windows Security auditing, default Sysmon configuration, or Falcon telemetry — none of these log named-object (mutex/event/semaphore) creation by default. Confirming it requires a custom ETW consumer (Threat-Intelligence provider, Microsoft-Windows-Kernel-Object) or live triage with Sysinternals Handle/Process Explorer. Treat it as a manual-triage artifact, not a scalable hunt signal — see §15.

Six queries are deterministic enough (specific filename, hash, or campaign-confirmed C2 value) to promote directly to Custom IOA rules. The remaining four (Q2, Q5, Q6, Q8) ship as hunt/investigate-only pending tenant-specific tuning — see §8 TUNING notes.

Promote Q2 (CLI/ZM_ config), Q6 (WebView2 lineage), and Q8 (proxy fan-out) to Custom IOA only after a monitoring period confirms the TUNING exclusions hold in your environment. Q5 (DNS tunneling) is best left as a scheduled hunt search or routed to your DNS-security product's own tunneling detector rather than a Falcon Custom IOA, since its FP profile depends heavily on your SaaS footprint.

All rows below are single-sourced to Blackpoint APG (see §2). Action is capped at detect/hunt — nothing ships as prevent from a single source, consistent with §4.

type,value,action,severity,expiration,description,tags
sha256,b7443b0ab48d2f5786d1b6f3a580f02621e9ae5a3877ee3a44e01df13d984328,detect,critical,2027-03-23,LabubaRAT entry point nvidia-sysruntime.exe. Single-sourced to Blackpoint APG.,campaign:LabubaRAT
md5,d8bf355a198fb5db3ea65cfdfcdfbd19,detect,critical,2027-03-23,LabubaRAT entry point nvidia-sysruntime.exe MD5. Single-sourced.,campaign:LabubaRAT
sha256,3d2b22b6bc51e0918263f4420e6bdf7d982d961b54176c470cac11841d1c9b33,detect,high,2027-03-23,Renamed MSBuild BuildCoordinator.exe LOLBIN loader. Single-sourced.,campaign:LabubaRAT
domain,pipicka.xyz,detect,critical,2027-03-23,LabubaRAT / LabubaPanel C2 domain. Single-sourced.,campaign:LabubaRAT
ipv4,191.44.109.130,detect,high,2027-03-23,LabubaPanel C2 host infrastructure. Single-sourced.,campaign:LabubaRAT
ipv4,87.120.108.18,detect,high,2027-03-23,LabubaPanel C2 host infrastructure. Single-sourced.,campaign:LabubaRAT
ipv4,168.222.254.204,detect,high,2027-03-23,LabubaPanel C2 host infrastructure. Single-sourced.,campaign:LabubaRAT
filename,nvidia-sysruntime.exe,hunt,high,2026-12-23,LabubaRAT masquerading entry-point filename.,campaign:LabubaRAT
filename,BuildCoordinator.exe,hunt,medium,2026-12-23,Renamed msbuild.exe used as a LOLBIN loader.,campaign:LabubaRAT
filename,nvctr_sys.db,hunt,high,2026-12-23,LabubaRAT local SQLite state database.,campaign:LabubaRAT

# LabubaRAT behavioral signatures -- hunt patterns, not import-ready indicators
Unsigned 64-bit PE claiming NVIDIA Corporation / NVIDIA Container Runtime Monitor /
NVIDIA Container Toolkit version metadata, running from a non-NVIDIA install path.
Process command line or environment containing --org / --key / --group / --server
or a ZM_ prefixed variable.
Process command line containing a long Base64 blob following a -b flag (LabubaRAT's
packed autostart argument).
msedgewebview2.exe spawned by a non-browser, non-Microsoft-signed parent process.
High-volume DNS queries with long (40+ character) subdomain labels toward a single
low-reputation parent domain.
wscript.exe/cscript.exe invoked against a temp script file with a wupd_ prefix.

LabubaRAT (nvidia-sysruntime.exe implant) -- Rust-based RAT, likely MaaS, tracked
by Blackpoint Cyber APG. First observed 2026-07-02.
LabubaPanel -- C2 panel/backend infrastructure; page title "LabubaPanel" with a
Labubu-themed favicon.
BuildCoordinator.exe -- renamed Microsoft Build Engine (MSBuild) used as a
trusted-utility proxy loader (T1127.001).
DotNetZip.dll -- follow-on payload loaded via the renamed-MSBuild project build;
sample unrecovered at publication.

# Flags HKCU Run-key entries matching LabubaRAT's Base64-packed autostart pattern.
# Run per-endpoint or wrap for RMM fleet deployment.
$runKey = 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run'
if (Test-Path $runKey) {
  (Get-Item $runKey).Property | ForEach-Object {
    $val = (Get-ItemProperty $runKey -Name $_).$_
    if ($val -match '-b\s+[A-Za-z0-9+/=]{20,}' -or $val -match 'nvidia-sysruntime') {
      Write-Output "FLAG: $_ = $val"
    }
  }
}
# Pair with ASR rule 01443614-cd74-433a-b99e-2ecdc07bfc25
# (Block executable files unless prevalence/age/trusted-list criteria are met) -- see Sec13.

LabubaRAT is entirely a Windows-endpoint threat in current reporting (no AD, cloud, or non-Windows surface observed). Controls below are cited to MITRE ATT&CK Mitigations (the why) plus CIS Microsoft Windows Benchmark / Microsoft Security Baselines and Microsoft's own ASR/WDAC documentation (the what/where), per platform_hardening_routing.md.

Playbook: LabubaRAT Masquerade & LOLBIN-Rename Prevention (T1036.005, T1127.001, T1547.001)

MITRE: T1036.005, T1127.001, T1547.001 → M1037, M1038, M1040, M1042, M1045, M1047
Estimated deploy time: 1-2 hours (Immediate-tier steps); 1 day per pilot ring (WDAC enforcement)
Prerequisites: Windows 10 1809+/Server 2019+ with Defender enabled, local admin on target endpoints, Falcon sensor installed for steps 3 and 5
Reboot required: No for steps 1, 3, 4, 5; No for step 2 (AppLocker policy refresh via gpupdate; a reboot is not required but is recommended for full session cleanup)

Step 1 — Block confirmed LabubaRAT C2 via Windows Firewall (host-level compensating control)

What it does: Blocks outbound connections to the three confirmed C2 IPs at the host firewall as an immediate compensating control ahead of a perimeter/DNS-security change.
Why it works: Even if the implant executes, it cannot reach its enrollment server over these addresses.

$badIPs = @('191.44.109.130','87.120.108.18','168.222.254.204')
New-NetFirewallRule -DisplayName 'Block-LabubaRAT-C2' -Direction Outbound `
  -RemoteAddress $badIPs -Action Block -Profile Any -Enabled True
Write-Output "Firewall rule Block-LabubaRAT-C2 created for $($badIPs.Count) address(es)."

Verify:

Get-NetFirewallRule -DisplayName 'Block-LabubaRAT-C2' |
  Get-NetFirewallAddressFilter | Select-Object RemoteAddress

Rollback:

Remove-NetFirewallRule -DisplayName 'Block-LabubaRAT-C2'

Step 2 — Enable ASR rule: block untrusted/unsigned executables

What it does: Blocks execution of new, low-prevalence, unsigned executables such as a freshly dropped nvidia-sysruntime.exe.
Why it works: LabubaRAT's entry point is unsigned and has no install-base prevalence, so it fails this rule's trust criteria outright.

$asrRule = '01443614-cd74-433a-b99e-2ecdc07bfc25'
Set-MpPreference -AttackSurfaceReductionRules_Ids $asrRule `
                 -AttackSurfaceReductionRules_Actions Enabled
Write-Output "ASR rule $asrRule set to Enabled (Block)."

GPO path: Computer Configuration > Administrative Templates > Windows Components > Microsoft Defender Antivirus > Microsoft Defender Exploit Guard > Attack Surface Reduction > Configure Attack Surface Reduction rules — add value name 01443614-cd74-433a-b99e-2ecdc07bfc25, value data 1 (Block), or 2 (Audit) during pilot.

Verify:

$ids = (Get-MpPreference).AttackSurfaceReductionRules_Ids
$actions = (Get-MpPreference).AttackSurfaceReductionRules_Actions
for ($i = 0; $i -lt $ids.Count; $i++) {
  if ($ids[$i] -eq '01443614-cd74-433a-b99e-2ecdc07bfc25') {
    "ASR rule action: $($actions[$i]) (1=Block, 2=Audit, 6=WarnUser)"
  }
}

Monitor for false positives: Event ID 1121 (Block) / 1122 (Audit) in Microsoft-Windows-Windows Defender/Operational.

Rollback:

Set-MpPreference -AttackSurfaceReductionRules_Ids '01443614-cd74-433a-b99e-2ecdc07bfc25' `
                 -AttackSurfaceReductionRules_Actions Disabled

Step 3 — Restrict MSBuild execution to a designated build-host group (AppLocker publisher rule)

What it does: Prevents MSBuild (original or renamed to any filename, such as BuildCoordinator.exe) from executing outside an approved build/CI host group.
Why it works: AppLocker publisher rules match the Authenticode publisher, not the filename, so a rename does not evade the rule.
Prerequisites: Application Identity service running, AppLocker policy applied via GPO to a security group covering non-developer endpoints.

Start-Service -Name AppIDSvc -ErrorAction SilentlyContinue
$rule = New-AppLockerPolicy -RuleType Publisher -User Everyone -Optimize `
  -ExecutablesFilePath 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe' `
  -Xml
Write-Output "Generated AppLocker publisher rule for MSBuild.exe -- import into the non-developer GPO and set to Deny."

GPO path: Computer Configuration > Windows Settings > Security Settings > Application Control Policies > AppLocker > Executable Rules — import the generated publisher rule scoped to the non-developer OU/security group, action Deny.

Verify:

Get-AppLockerPolicy -Effective -Xml | Select-String 'MSBuild'
# Confirm the deny rule is present and applied to the target OU/group

Rollback: Remove the imported publisher rule from the AppLocker GPO and run gpupdate /force on affected endpoints.

Step 4 — Confirm Falcon prevention policy posture

What it does: Ensures Falcon's ML/behavioral prevention and tamper protection are active for unsigned/unknown-reputation execution — a layer independent of the static controls above.
Not a script — Falcon Console UI: Endpoint security > Prevention policies > for policies applied to workstations/servers: Sensor visibility all ON; Cloud machine learning Detection Aggressive / Prevention Moderate-or-Aggressive; Suspicious Processes ON (Block); Tampering Protection ON.

Verify (from a target endpoint):

Get-Service CSFalconService | Select-Object Name, Status
# Status: Running

Rollback: Revert the prevention-policy toggles in Falcon Console to their prior saved values (export policy JSON before changing, for a clean revert).

Step 5 — Import LabubaRAT Custom IOCs

What it does: Loads the §10 CSV into Falcon's IOC Management so the confirmed hashes/domain/IPs generate Detect-severity alerts fleet-wide.
Not a script — Falcon Console UI: Endpoint security > IOC Management > Upload CSV > select the §10 grab-csv export > confirm action=detect for every row (do not change to Prevent given the single-source caveat in §2/§4).

Verify: Endpoint security > IOC Management > filter by tag campaign:LabubaRAT — confirm 10 indicators present, all action=Detect.

Rollback: Delete the imported indicators by tag campaign:LabubaRAT from IOC Management.

Every gate in §11 (Telemetry ready / Benign baseline / Positive test / Promotion criteria) must pass before a query listed as "Yes" above is promoted beyond Detect-mode Custom IOA.

Full verbatim text of all four sources is saved in LabubaRAT-Hunt-sources/ alongside this file for provenance re-verification.