T1059.011: Lua
Adversaries may abuse Lua commands and scripts for execution. Lua is a cross-platform scripting and programming language primarily designed for embedded use in applications. Lua can be executed on the command-line (through the stand-alone lua interpreter), via scripts (.lua), or from Lua-embedded programs (through the struct lua_State).[1][2]
Lua scripts may be executed by adversaries for malicious purposes. Adversaries may incorporate, abuse, or replace existing Lua interpreters to allow for malicious Lua command execution at runtime.[3][4][5][6]
Analyst context for executives and security teams
Lua matters because it is a legitimate cross-platform scripting language that can become an execution path on endpoints, embedded applications, and network devices. The business issue is not “Lua is bad”; it is whether the organization knows where Lua interpreters or Lua-capable applications exist, whether script execution is authorized, and whether SOC/IR teams can distinguish expected embedded scripting from adversary-controlled runtime execution.
Executive priority
Prioritize this where Lua-capable software, network devices, or specialized operational environments are material to service continuity. Leaders should ask for evidence of inventory, application control, software installation restrictions, and audit coverage for Lua execution paths across Linux, Windows, macOS, and network devices. This is especially relevant to resilience and incident decision-making because ATT&CK relates Lua abuse to multiple malware families and to a network-device backdoor/web shell case, but local exposure depends on whether Lua is present and observable in the environment.
Technical view
T1059.011 is an execution sub-technique under Command and Scripting Interpreter. ATT&CK does not provide official detection text for this object, so defenders should validate coverage from first principles and against the related DET0101 detection strategy where available. SOC teams should identify standalone lua interpreter use, .lua script execution, and applications that embed Lua through runtime interpreters. For network devices, validate whether administrative, web, file-upload, and command execution logs can reveal unauthorized Lua script upload or execution. IR teams should treat unexpected Lua runtime activity as execution evidence and correlate it with parent process, user/session, file provenance, and device management activity.
Likely telemetry
- Endpoint process creation and command-line telemetry showing lua interpreter invocation where available
- File system events for creation, modification, or execution of .lua scripts
- Application logs from products or services that embed Lua scripting
- Application control, allowlist, script-blocking, and execution-prevention decision logs
- Software inventory and endpoint management records showing approved versus unauthorized Lua interpreters or Lua-capable applications
Detection direction
- Start by inventorying expected Lua usage; without a baseline, legitimate embedded Lua activity can create noise and hidden interpreters can create blind spots.
- Alert or hunt for newly introduced Lua interpreters, unusual .lua script creation, or Lua execution from unexpected directories, users, parent processes, or remote sessions.
- For network devices, validate logging for script upload and execution paths; endpoint-only telemetry will not cover the Network Devices platform listed for this technique.
- Correlate Lua activity with the broader T1059 command-and-scripting pattern rather than treating it as a standalone language problem.
- Use ATT&CK software relationships as test context: Remsec, EvilBunny, PoetRAT, Line Runner, and RedLine Stealer are associated with use of this technique, but do not assume those tools are present without local evidence.
Mitigation priorities
- Establish where Lua is approved: standalone interpreters, embedded application runtimes, and network-device capabilities.
- Apply M1033 Limit Software Installation so users or groups cannot introduce unauthorized Lua interpreters or Lua-capable tools without approval.
- Apply M1038 Execution Prevention through application control, script blocking, or allowlisting for unauthorized Lua interpreters and scripts where operationally feasible.
- Apply M1047 Audit by ensuring Lua-relevant execution, file, application, and device-management events are logged and periodically reviewed.
- Use least privilege and change control around systems or applications that can execute Lua scripts, especially network devices and business-critical platforms.
Analyst notes and limits
This take is based on ATT&CK T1059.011 Lua, its platforms, execution tactic, official description, external references, and supplied relationships. The relationships show mitigation mappings to Limit Software Installation, Execution Prevention, and Audit, plus software examples that use Lua-related execution. The most important local validation question is whether Lua exists as a sanctioned runtime, an embedded application feature, or an unmanaged interpreter.
The ATT&CK object provides no official detection text, and the related DET0101 details are not supplied beyond its name. Specific log sources, event IDs, product configurations, and detection logic must be validated in the local environment. The supplied data supports relevance across Linux, Windows, macOS, and Network Devices, but not a claim of active exploitation or confirmed exposure in any specific organization.
Lua
Adversaries may abuse Lua commands and scripts for execution. Lua is a cross-platform scripting and programming language primarily designed for embedded use in applications. Lua can be executed on the command-line (through the stand-alone lua interpreter), via scripts (.lua), or from Lua-embedded programs (through the struct lua_State).[1][2]
Lua scripts may be executed by adversaries for malicious purposes. Adversaries may incorporate, abuse, or replace existing Lua interpreters to allow for malicious Lua command execution at runtime.[3][4][5][6]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Related techniques
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1059 | Command and Scripting Interpreter | This object subtechnique of Command and Scripting Interpreter. |
Groups, software, and campaigns
S0396: EvilBunny
S0125: Remsec
S1240: RedLine Stealer
RedLine Stealer is an information-stealer malware variant first identified in 2020.[1][2][3] RedLine Stealer is a Malware as a Service (MaaS) and was reportedly sold as either a one-time purchase or a monthly subscription service.[1][4] Information obtained from RedLine Stealer has been known to be sold on the deep and dark web to Initial Access Brokers (IABs), who use or resell the stolen credentials for further intrusions.[5][4]
S1188: Line Runner
Line Runner is a persistent backdoor and web shell allowing threat actors to upload and execute arbitrary Lua scripts. Line Runner is associated with the ArcaneDoor campaign.[1][2]
S0428: PoetRAT
PoetRAT is a remote access trojan (RAT) that was first identified in April 2020. PoetRAT has been used in multiple campaigns against the private and public sectors in Azerbaijan, including ICS and SCADA systems in the energy sector. The STIBNITE activity group has been observed using the malware. PoetRAT derived its name from references in the code to poet William Shakespeare. [1][2][3]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.1 | Current bundle | 4ae5f4f107a5… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Lua main page
Lua. (2024, June 25). Getting started. Retrieved August 5, 2024.
Open source URL -
[2]
Lua state
Lua. (n.d.). lua_State. Retrieved August 5, 2024.
Open source URL -
[3]
PoetRat Lua
Mercer, Warren. (2020, October 6). PoetRAT: Malware targeting public and private sector in Azerbaijan evolves. Retrieved August 5, 2024.
Open source URL -
[4]
Lua Proofpoint Sunseed
Raggi, Michael. Cass, Zydeca. The Proofpoint Threat Research Team.. (2022, March 1). Asylum Ambuscade: State Actor Uses Lua-based Sunseed Malware to Target European Governments and Refugee Movement. Retrieved August 5, 2024.
Open source URL -
[5]
Cyphort EvilBunny
Marschalek, Marion. (2014, December 16). EvilBunny: Malware Instrumented By Lua. Retrieved August 5, 2024.
Open source URL -
[6]
Kaspersky Lua
Global Research and Analysis Team. (2016, August 9). The ProjectSauron APT. Retrieved August 5, 2024.
Open source URL -
[7]
mitre-attack T1059.011Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.