LucidRook & UAT-10362: Rust/Lua Stagers Hitting Taiwanese NGOs
Just caught the report on UAT-10362 targeting Taiwanese entities with a new stager, LucidRook. It's an interesting blend of Rust and Lua, delivered via DLLs in spear-phishing campaigns. The use of Rust isn't new, but embedding a Lua interpreter inside the DLL for flexibility is a clever twist.
Technical Breakdown
- Payload: A DLL containing a Lua interpreter and Rust-compiled libraries.
- Capabilities: Acts as a stager to download and execute further payloads.
- Target: NGOs and universities in Taiwan.
Detection Ideas
Since it's a Lua interpreter running within a process memory, standard signature-based detection might struggle initially. We should probably look for:
- DLL Side-Loading: Monitor for unsigned DLLs loading into common processes (e.g., Office, utilities).
- API Calls: Unusual
VirtualAllocorCreateThreadpatterns followed by network activity.
Here’s a quick Sigma rule concept to catch potential DLL side-loading or unsigned modules loading:
title: Potential LucidRook DLL Side-Loading
description: Detects unsigned DLLs loading into suspicious processes
status: experimental
references:
- https://thehackernews.com/2026/04/uat-10362-targets-taiwanese-ngos-with.html
author: SecurityArsenal_User
date: 2026/04/24
tags:
- attack.defense_evasion
- attack.t1574.002
logsource:
category: image_load
product: windows
detection:
selection:
ImageLoaded|endswith: '.dll'
Signed: 'false'
filter:
Image|contains:
- '\Windows\System32\'
- '\Program Files\'
condition: selection and not filter
falsepositives:
- Legitimate unsigned software
level: medium
Has anyone else seen similar Lua-embedded malware in the wild? It feels like we're seeing a trend towards interpreters for obfuscation.
How are you handling detection for these multi-language stagers in your environments?
The Lua interpreter approach is definitely a move to evade static analysis. From a SOC perspective, we've started looking for specific Lua API calls that might be exposed via the Rust wrapper. It's not common to see luaL_loadstring or lua_pcall in your average process tree unless they're running legitimate scripts.
For those using Sysmon, keep an eye on LoadImage events where the Signed flag is false and the process is something like winword.exe or excel.exe.
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-Sysmon/Operational'; ID=7} | Where-Object {$_.Message -match 'Signed=false' -and $_.Message -match 'Office'}
It's noisy, but in a targeted environment, it's a good starting point.
I work mainly with NGOs, and this kind of targeting is all too common. The spear-phishing angle here is key—they aren't spraying and praying; they're crafting specific lures.
Beyond detection, user awareness is still the first line of defense. We've been advising our clients to strip macros and enforce strict attachment filtering, but threat actors are moving to links (e.g., OneDrive, Dropbox) to download the DLL.
For the technical side, can we export the Lua script from memory for analysis? If the interpreter is embedded, the bytecode should be there, right?
Great post. The Rust compilation makes reverse engineering a pain due to the lack of standard C-style symbols. If you get a sample, I'd recommend dumping the strings early; Rust binaries often retain verbose error messages and URLs.
For detection, why not look for the Lua library specifically? If they are embedding an interpreter, they might be linking against a specific version of lua51.dll or similar.
strings suspected_malware.dll | grep -i 'lua\|liblua'
Might give us a quick indicator without full reversing.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access