AN0279: Analytic 0279
Detects invocation of lua or luajit interpreters by users or services outside of expected packages, chained with script drop or memory artifacts.
Analyst context for executives and security teams
This analytic matters because Lua or LuaJIT execution on Linux can be legitimate in some software stacks, but unexpected interpreter use by users or services, especially near script drops or memory artifacts, is a signal worth validating. For leaders, the decision value is not “block Lua everywhere,” but knowing whether the organization can distinguish approved package-driven interpreter activity from unusual execution that may require investigation.
Executive priority
Prioritize this as a Linux monitoring and response-readiness question: which systems are expected to run lua or luajit, which services are allowed to invoke them, and can the SOC prove that with telemetry? The business value is reducing ambiguity during an incident by having baseline evidence for sanctioned interpreter use and a process to investigate deviations without disrupting legitimate packages or services.
Technical view
For Linux SOC and detection engineering teams, validate process execution visibility for lua and luajit, including parent process, user, service context, command line, working directory, file paths, and nearby file or memory evidence. Because the official analytic specifies invocation outside expected packages chained with script drop or memory artifacts, detection should combine interpreter execution with context rather than alerting on interpreter name alone. No ATT&CK tactic mapping or relationship context was supplied, so local baselining is essential.
Likely telemetry
- Linux process execution events for lua and luajit
- Command-line arguments, parent/child process relationships, user and service account context
- Package or software inventory showing expected Lua/LuaJIT dependencies
- File creation or modification events indicating script drops
- Memory or runtime artifacts where available from endpoint telemetry
Detection direction
- Inventory where lua or luajit are legitimately installed and which packages or services are expected to invoke them.
- Tune detections to focus on unexpected users, service accounts, paths, parent processes, or recently dropped scripts rather than interpreter execution alone.
- Correlate interpreter invocation with script creation/modification and memory artifacts, as specified by the analytic description.
- Review false positives from package managers, monitoring tools, application runtimes, and administrative scripts before escalating broadly.
- Document coverage gaps where Linux endpoint telemetry does not capture command line, file creation, service context, or memory-related evidence.
Mitigation priorities
- Establish an approved-use baseline for Lua/LuaJIT on Linux systems.
- Limit unnecessary interpreter installation or execution where operationally feasible.
- Apply least-privilege controls for users and services that can execute scripting interpreters.
- Ensure endpoint logging captures process, file, and service context needed to investigate this analytic.
- Create incident response triage guidance for unexpected lua or luajit execution, including package validation and script artifact review.
Analyst notes and limits
The supplied object is a detection analytic for Linux with a concise description but no official detection logic and no relationship context. Treat it as a detection design prompt: validate interpreter execution in context, not as a standalone indicator of malicious behavior.
This take is limited to the supplied STIX fields and external reference. No tactics, related techniques, procedure examples, adversary attribution, active exploitation claims, or complete detection logic were provided. Local package inventory, service baselines, and endpoint telemetry quality determine practical usefulness.
Analytic 0279
Detects invocation of lua or luajit interpreters by users or services outside of expected packages, chained with script drop or memory artifacts.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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.0 | Current bundle | 86afbdf900de… |
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]
mitre-attack AN0279Open 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.