Rig of Troy: A Suspicious Recovery Script Hidden Inside Roblox Toolbox Models

1. It Started With an Animation R6 models and animations in the Roblox Toolbox. Everything seemed normal until I inspected one of the models more closely.

Inside the character's Right Arm, I found something unexpected: a script called Runtime.lua, accompanied by a complex hierarchy of objects that seemed completely unrelated to the model's intended purpose. At first, I thought it was just an unusually complicated animation system. I was wrong.

Further investigation revealed suspicious scripts, hidden interface components, and code designed to convince developers to execute an external command. I decided to call this investigation Operation Rig of Troy. 2.

The Same Script, Different Models After finding the first suspicious model, I started examining other assets from the Toolbox. Surprisingly, I encountered very similar structures in multiple models, sometimes published by different creators. One recurring hierarchy looked like this: Right Arm └── Runtime └── RuntimeInput └── RuntimeInputContext └── MovementElevateAction └── InputBinding (ScreenGui) The most interesting detail was the location of the GUI.

In the models I examined, suspicious interface components repeatedly appeared under MovementElevateAction. Why would an R6 animation need an entire interface system hidden inside a character's arm? There might be legitimate explanations for unusual object hierarchies, but the repeated structure justified further investigation.

3. What Runtime.lua Actually Does I examined the source code without intentionally executing the suspicious recovery command. The first significant finding was: if RunService:IsStudio() then else return end This code only proceeds while running in Roblox Studio.

The script then locates a ScreenGui named InputBinding inside the MovementElevateAction hierarchy. After finding the interface, it clones the stored objects into the player's PlayerGui. During installation, it also renames several components: Original name Installed name RuntimeInput InputOverlay RuntimeInputContext InputOverlayContext RuntimeToggleContext FreecamToggleContext RuntimeToggleAction InputToggleAction The script also contains a fingerprinting mechanism based on object attributes and names, along with checks that can stop the installation under certain conditions.

This confirmed that the script was installing an interface, not simply controlling an animation. However, this script alone did not prove that a malicious remote module was being executed. 4.

The Hidden Window Driver The next important discovery was a client-side script named WindowDriver.lua. This script was responsible for building and displaying the interface. Its behavior included: Waiting for keyboard or mouse activity before showing the window.

Displaying a technical-looking notification. Applying visual effects to the screen. Temporarily blocking character movement.

Presenting troubleshooting instructions. Providing a selectable code snippet. One particularly interesting section waited until the script had detected sufficient user activity before presenting the notification.

This made the interface appear during an active Studio testing session. The script also assembled its text from attributes stored in the GUI rather than keeping all messages directly in the source code. That led to the next discovery.

5. The Recovery Command Several attributes were named Row22, Row23, and so on. These attributes contained fragments of a Lua command.

The fragments included references to: HttpService Enabling HTTP requests GetAsync() require(tonumber(id)) The suspicious command appeared designed to retrieve a module identifier from an external endpoint and load the corresponding module. Even more interestingly, the interface used two sets of attributes: Rows 22–27: The actual text placed inside the selectable text field. Rows 80–85: The text rendered in the syntax-highlighted preview.

The script made the underlying text transparent and displayed a separately rendered version above it. This design could potentially display different text from what the user copies. However, I did not establish that the two versions were different in the examined sample.

The confirmed concern was already significant: a model was presenting instructions that encouraged the developer to execute externally sourced code in Roblox Studio. This is consistent with a social engineering technique, rather than an ordinary animation dependency. 6.

Was It Really a Backdoor? This is where the distinction between evidence and assumptions matters. My investigation established that: Multiple examined models contained similar suspicious structures.

The Runtime.lua script could install an interface in PlayerGui. The interface was designed to appear during Studio testing. Its instructions encouraged the execution of a command involving external module loading.

The GUI and related scripts were embedded in places that were unexpected for the advertised assets. However, I did not identify or reverse engineer the final remotely loaded module. Therefore, I cannot conclusively state what the final payload would do.

It might have been intended to install a backdoor, but confirming that requires additional evidence. I also cannot establish who originally created the scripts or whether every model containing the same structure was distributed by the same actor. 7.

What Developers Can Learn From This The investigation illustrates why Roblox Toolbox assets should not automatically be trusted. A free model may contain much more than its visible parts. Before using unfamiliar assets: Inspect their scripts and object hierarchies.

Question unexpected network requests and dynamic module loading. Never execute unexplained Command Bar instructions from an untrusted model. Review unfamiliar plugins and third-party dependencies.

Keep backups and report suspicious assets through Roblox's official reporting channels. Importantly, do not execute unknown malware simply to see what happens. Static inspection can already reveal significant information.

8. Final Thoughts I originally wanted an R6 animation. Instead, I found a suspicious runtime system, unusual GUI structures, a hidden window driver, and a potential social engineering mechanism involving remote code execution.

I did not prove the existence of a functioning backdoor payload, but I documented a concerning method of persuading developers to execute untrusted code. For me, this investigation was also an introduction to practical cybersecurity research: examining source code, comparing artifacts, identifying suspicious behavior, and separating facts from hypotheses. And everything started with a character's arm.

Operation Rig of Troy — Case #002 — Digital Investigations* GET RUNTIMED. Disclaimer: This article documents static code analysis and observations from Roblox Studio. It does not claim to identify the original developer of the suspicious code or prove the functionality of an unexamined remote payload.