T1623: Command and Scripting Interpreter
Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries. These interfaces and languages provide ways of interacting with computer systems and are a common feature across many different platforms. Most systems come with some built-in command-line interface and scripting capabilities, for example, Android is a UNIX-like OS and includes a basic Unix Shell that can be accessed via the Android Debug Bridge (ADB) or Java’s `Runtime` package.
Adversaries may abuse these technologies in various ways as a means of executing arbitrary commands. Commands and scripts can be embedded in Initial Access payloads delivered to victims as lure documents or as secondary payloads downloaded from an existing C2. Adversaries may also execute commands through interactive terminals/shells.
Security context for executives and security teams
T1623 matters because command and script interpreters turn a mobile device from a managed endpoint into a place where arbitrary commands, scripts, or binaries may be run. For Android and iOS programs, this can appear through built-in shell capability, Android Debug Bridge access, Java Runtime execution, embedded initial-access payloads, downloaded secondary payloads, or interactive shells. The business issue is not the shell itself; it is whether the organization can tell when a mobile device is being used to execute unapproved logic and whether compromised devices are blocked from enterprise access.
Executive priority
Prioritize this where mobile devices access sensitive enterprise resources, credentials, telecom services, or regulated data. Leaders should ask whether mobile threat defense, EMM/MDM, attestation, and compromised-device detection provide auditable evidence that rooted, jailbroken, or otherwise suspicious devices are identified and restricted. Because ATT&CK provides no official detection text for this technique, coverage should be validated rather than assumed.
Technical view
For SOC, detection engineering, and IR teams, validate Android and iOS visibility around command execution from mobile apps and shell-like interfaces. The supplied ATT&CK context specifically calls out Android UNIX-like shell access via ADB or Java Runtime, and the related sub-technique T1623.001 covers Unix Shell behavior on Android and iOS. Review whether DET0655 or equivalent mobile detection logic identifies suspicious command/script interpreter use, especially when paired with downloaded secondary payloads, C2-related activity, or evidence of rooting/jailbreaking. Treat legitimate developer, support, and device-management workflows as expected false-positive sources.
Likely telemetry
- Mobile threat defense alerts related to command or script interpreter execution
- EMM/MDM device posture, compliance, and security state records
- Remote attestation results, including pass/fail decisions
- Rooted or jailbroken device detection events
- Android Debug Bridge or developer-access indicators where available
Detection direction
- Map existing mobile detections to T1623 and the related DET0655 detection strategy; do not assume coverage because ATT&CK does not provide official detection logic here.
- Validate whether telemetry can distinguish routine administrative or developer activity from suspicious interpreter use on managed Android and iOS devices.
- Correlate command/script execution indicators with device compromise signals such as root or jailbreak status, failed attestation, newly downloaded payloads, or suspicious network activity.
- Include the Unix Shell sub-technique T1623.001 in detection testing, since the parent technique’s practical visibility may depend on shell-specific telemetry.
- Document blind spots for BYOD, unmanaged devices, privacy-limited mobile telemetry, and platforms where app-level command execution details are not collected.
Mitigation priorities
- Enable remote attestation where available and use failed attestation to restrict access to enterprise resources, consistent with M1002.
- Deploy compromised-device detection methods through built-in device capabilities, third-party mobile security applications, EMM/MDM, or other enterprise controls, consistent with M1010.
- Tie mobile access decisions to device posture so rooted, jailbroken, or otherwise failed devices cannot freely reach sensitive applications and data.
- Prioritize validation over tool presence: some compromised-device detection methods may be easier to evade than others, so control effectiveness should be tested with local evidence.
- Maintain incident response procedures for collecting and preserving mobile device posture, attestation, MTD, and MDM evidence when command execution is suspected.
Additional notes and limits
The relationship context shows this technique is used by the mobile software entries TianySpy and LightSpy, and that T1623.001 Unix Shell is a sub-technique. These relationships support using the behavior in threat modeling and detection validation, but they do not establish current exposure or active exploitation in any specific environment.
ATT&CK lists Android and iOS platforms but does not specify tactics or official detection details for this object. Practical detection depends heavily on local mobile telemetry, management scope, privacy constraints, device ownership model, and the specific MTD/EMM/MDM capabilities deployed.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Command and Scripting Interpreter
Adversaries may abuse command and script interpreters to execute commands, scripts, or binaries. These interfaces and languages provide ways of interacting with computer systems and are a common feature across many different platforms. Most systems come with some built-in command-line interface and scripting capabilities, for example, Android is a UNIX-like OS and includes a basic Unix Shell that can be accessed via the Android Debug Bridge (ADB) or Java’s `Runtime` package.
Adversaries may abuse these technologies in various ways as a means of executing arbitrary commands. Commands and scripts can be embedded in Initial Access payloads delivered to victims as lure documents or as secondary payloads downloaded from an existing C2. Adversaries may also execute commands through interactive terminals/shells.
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 |
|---|---|---|---|
| Mobile | T1623.001 | Unix ShellSub-technique | Unix Shell subtechnique of this object. |
Groups, software, and campaigns
S1185: LightSpy
First observed in 2018, LightSpy is a modular malware family that initially targeted iOS devices in Southern Asia before expanding to Android and macOS platforms. It consists of a downloader, a main executable that manages network communications, and functionality-specific modules, typically implemented as `.dylib` files (iOS, macOS) or `.apk` files (Android). LightSpy can collect VoIP call recordings, SMS messages, and credential stores, which are then exfiltrated to a command and control (C2) server.[1]
S1056: TianySpy
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.2 | Current bundle | e95ab18606f8… |
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]MelikovBlackBerry LightSpy 2024
Melikov, D. (2024, April 11). LightSpy Returns: Renewed Espionage Campaign Targets Southern Asia, Possibly India. Retrieved January 14, 2025.
Open source URL - [2]Threatfabric LightSpy 2024
ThreatFabric. (2024, October 29). LightSpy: Implant for iOS. Retrieved January 30, 2025.
Open source URL - [3]LinkedIn Dmitry LightSpy 2025
Dmitry Bestuzhev. (2025, April 7). The Coordinated Kill Switch: LightSpy's iOS Destructive Plugin Architecture Manages Device Disablement. Retrieved April 14, 2025.
Open source URL - [4]trendmicro_tianyspy_0122
Trend Micro. (2022, January 25). TianySpy Malware Uses Smishing Disguised as Message From Telco. Retrieved January 11, 2023.
Open source URL - [5]Samsung Knox Mobile Threat Defense
Samsung Knox Partner Program. (n.d.). Knox for Mobile Threat Defense. Retrieved March 30, 2022.
Open source URL - [6]Samsung Knox Mobile Threat Defense
Samsung Knox Partner Program. (n.d.). Knox for Mobile Threat Defense. Retrieved March 30, 2022.
Open source URL - [7]mitre-attackT1623Open source URL
- [8]mitre-attackT1623Open 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.