Live Active security incident? Get immediate response
MITRE ATT&CK® Technique

T1059.002: AppleScript

Adversaries may abuse AppleScript for execution. AppleScript is a macOS scripting language designed to control applications and parts of the OS via inter-application messages called AppleEvents.[1] These AppleEvent messages can be sent independently or easily scripted with AppleScript. These events can locate open windows, send keystrokes, and interact with almost any open application locally or remotely.

Scripts can be run from the command-line via osascript /path/to/script or osascript -e "script here". Aside from the command line, scripts can be executed in numerous ways including Mail rules, Calendar.app alarms, and Automator workflows. AppleScripts can also be executed as plain text shell scripts by adding #!/usr/bin/osascript to the start of the script file.[2]

AppleScripts do not need to call osascript to execute. However, they may be executed from within mach-O binaries by using the macOS Native APIs NSAppleScript or OSAScript, both of which execute code independent of the /usr/bin/osascript command line utility.

Adversaries may abuse AppleScript to execute various behaviors, such as interacting with an open SSH connection, moving to remote machines, and even presenting users with fake dialog boxes. These events cannot start applications remotely (they can start them locally), but they can interact with applications if they're already running remotely. On macOS 10.10 Yosemite and higher, AppleScript has the ability to execute Native APIs, which otherwise would require compilation and execution in a mach-O binary file format.[3] Since this is a scripting language, it can be used to launch more common techniques as well such as a reverse shell via Python.[4]

EnterpriseT1059.002Sub-techniqueObject v1.3 Modified
Discuss defensive coverage Back to ATT&CK
Glexia's Take

Analyst context for executives and security teams

Analyst confidence High

AppleScript matters because it is a built-in macOS automation capability that can be repurposed for execution without looking like a traditional malware binary. For organizations with meaningful Mac fleets, this technique can affect SOC visibility and incident response because scripts may run through osascript, Automator, Mail rules, Calendar alarms, shell-script style AppleScript files, or inside Mach-O applications using NSAppleScript or OSAScript.

Executive priority

Treat this as a macOS execution-risk and visibility question: do security teams know where AppleScript is legitimately used, and can they distinguish approved automation from suspicious execution? Priority is highest for environments where Macs handle privileged administration, development, executive access, regulated data, or incident response tooling. Control investment should focus on execution prevention, code-signing expectations, and evidence that macOS script execution is logged and reviewable.

Technical view

This is an execution sub-technique under Command and Scripting Interpreter for macOS. Validate monitoring for /usr/bin/osascript command-line use, inline AppleScript via osascript -e, script files using #!/usr/bin/osascript, and non-command-line launch paths such as Mail rules, Calendar.app alarms, and Automator workflows. Because AppleScript may also execute from Mach-O binaries through NSAppleScript or OSAScript, detections that only look for osascript process creation will be incomplete. Relationship context shows a specific detection strategy, DET0414, for AppleScript-based execution on macOS, and known ATT&CK software relationships include Dok, Bundlore, ThiefQuest, macOS.OSAMiner, Cuckoo Stealer, and GlassWorm.

Likely telemetry

  • macOS process execution records for osascript and parent/child process relationships
  • Command-line arguments showing script paths or inline AppleScript content
  • File-system evidence for AppleScript files, Automator workflows, Mail rules, Calendar alarms, and scripts with an osascript shebang
  • Endpoint telemetry indicating Mach-O applications invoking AppleScript-related APIs such as NSAppleScript or OSAScript
  • AppleEvent or automation-related activity where available from endpoint or operating-system logging

Detection direction

  • Use DET0414 as the ATT&CK-linked detection strategy to evaluate local detection logic, but verify what telemetry it depends on in the actual Mac environment.
  • Do not rely only on osascript command-line alerts; AppleScript can execute through workflows, application automation, and native API use from Mach-O binaries.
  • Baseline legitimate administrative and user automation to reduce false positives, then alert on unusual parents, inline scripts, unexpected application interaction, or script execution from user-writable or recently downloaded locations when such context is available.
  • Correlate AppleScript execution with follow-on command interpreters or scripting, including Python where observed, because ATT&CK notes AppleScript can launch other techniques.
  • Review detections against the related macOS software examples to ensure analytic coverage includes adware, stealers, trojans, miners, and supply-chain-style payload contexts without assuming any one actor or campaign.

Mitigation priorities

  • Apply execution prevention for unauthorized or malicious code where feasible, including script blocking and application control appropriate to macOS operations.
  • Use code-signing requirements and trust policies to reduce execution of untrusted scripts, applications, and automation artifacts.
  • Limit approved AppleScript and automation use to documented business cases, especially on privileged Macs and systems handling sensitive data.
  • Harden and monitor non-obvious launch paths such as Automator workflows, Mail rules, and Calendar alarms because they can bypass simple command-line assumptions.
  • Pair prevention with incident-response playbooks that collect scripts, workflow artifacts, parent processes, command lines, and related application activity before containment actions remove evidence.
Analyst notes and limits

MITRE does not provide official detection text for this object, but the relationship set includes DET0414, Detection of AppleScript-Based Execution on macOS. The technique is macOS-specific and belongs to the execution tactic. The most important defender decision is whether AppleScript visibility covers both osascript and API/workflow-based execution paths.

This take is based only on the supplied ATT&CK fields, references, and relationships. It does not establish current exploitation, customer exposure, or guaranteed detection. Local baselines are required because AppleScript has legitimate administrative and productivity uses, and available telemetry varies by macOS version, endpoint tooling, and logging configuration.

Official MITRE ATT&CK definition

AppleScript

Adversaries may abuse AppleScript for execution. AppleScript is a macOS scripting language designed to control applications and parts of the OS via inter-application messages called AppleEvents.[1] These AppleEvent messages can be sent independently or easily scripted with AppleScript. These events can locate open windows, send keystrokes, and interact with almost any open application locally or remotely.

Scripts can be run from the command-line via osascript /path/to/script or osascript -e "script here". Aside from the command line, scripts can be executed in numerous ways including Mail rules, Calendar.app alarms, and Automator workflows. AppleScripts can also be executed as plain text shell scripts by adding #!/usr/bin/osascript to the start of the script file.[2]

AppleScripts do not need to call osascript to execute. However, they may be executed from within mach-O binaries by using the macOS Native APIs NSAppleScript or OSAScript, both of which execute code independent of the /usr/bin/osascript command line utility.

Adversaries may abuse AppleScript to execute various behaviors, such as interacting with an open SSH connection, moving to remote machines, and even presenting users with fake dialog boxes. These events cannot start applications remotely (they can start them locally), but they can interact with applications if they're already running remotely. On macOS 10.10 Yosemite and higher, AppleScript has the ability to execute Native APIs, which otherwise would require compilation and execution in a mach-O binary file format.[3] Since this is a scripting language, it can be used to launch more common techniques as well such as a reverse shell via Python.[4]

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

ATT&CK relationship table

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.

2 rows
Domain ID Name Relationship / procedure
Enterprise T1059 Command and Scripting Interpreter This object subtechnique of Command and Scripting Interpreter.
Enterprise T1155 AppleScript AppleScript revoked by this object.
Associated objects

Groups, software, and campaigns

Malware Enterprise

S0595: ThiefQuest

ThiefQuest is a virus, data stealer, and wiper that presents itself as ransomware targeting macOS systems. ThiefQuest was first seen in 2020 distributed via trojanized pirated versions of popular macOS software on Russian forums sharing torrent links.[1] Even though ThiefQuest presents itself as ransomware, since the dynamically generated encryption key is never sent to the attacker it may be more appropriately thought of as a form of wiper malware.[2][3]

macOS
Malware Enterprise

S9010: GlassWorm

GlassWorm is a worm that propagated through supply chain attacks by compromising repository credentials from victim environments and having malicious payloads added to those compromised accounts for distribution to victims across the various development ecosystems.[1][2][3] GlassWorm has numerous variants, including Rust binaries, encrypted JavaScript and a variant leveraging invisible Unicode characters that made reverse engineering difficult.[4][1][5] GlassWorm has employed a unique command and control (C2) methodology using Solana blockchain.[6][1] GlassWorm was first reported in October 2025.[6][1][3]

macOSWindows
Malware Enterprise

S0482: Bundlore

Bundlore is adware written for macOS that has been in use since at least 2015. Though categorized as adware, Bundlore has many features associated with more traditional backdoors.[1]

macOS
Malware Enterprise

S1153: Cuckoo Stealer

Cuckoo Stealer is a macOS malware with characteristics of spyware and an infostealer that has been in use since at least 2024. Cuckoo Stealer is a universal Mach-O binary that can run on Intel or ARM-based Macs and has been spread through trojanized versions of various potentially unwanted programs or PUP's such as converters, cleaners, and uninstallers.[1][2]

macOS
Malware Enterprise

S1048: macOS.OSAMiner

macOS.OSAMiner is a Monero mining trojan that was first observed in 2018; security researchers assessed macOS.OSAMiner may have been circulating since at least 2015. macOS.OSAMiner is known for embedding one run-only AppleScript into another, which helped the malware evade full analysis for five years due to a lack of Apple event (AEVT) analysis tools.[1][2]

macOS
Relationship explorer

All related ATT&CK context

subtechnique of · Technique T1059: Command and Scripting Interpreter Enterprise mitigates · Mitigation M1045: Code Signing Enterprise revoked by · Technique T1155: AppleScript Enterprise uses · Malware S0281: Dok Enterprise mitigates · Mitigation M1038: Execution Prevention Enterprise uses · Malware S0595: ThiefQuest Enterprise detects · Detection Strategy DET0414: Detection of AppleScript-Based Execution on macOS Enterprise uses · Malware S9010: GlassWorm Enterprise uses · Malware S0482: Bundlore Enterprise uses · Malware S1153: Cuckoo Stealer Enterprise uses · Malware S1048: macOS.OSAMiner Enterprise
Mitigations

Mitigation direction

Mitigation Enterprise

M1045: Code Signing

Code Signing is a security process that ensures the authenticity and integrity of software by digitally signing executables, scripts, and other code artifacts. It prevents untrusted or malicious code from executing by verifying the digital signatures against trusted sources. Code signing protects against tampering, impersonation, and distribution of unauthorized or malicious software, forming a critical defense against supply chain and software exploitation attacks. This mitigation can be implemented through the following measures:

Enforce Signed Code Execution:

- Implementation: Configure operating systems (e.g., Windows with AppLocker or Linux with Secure Boot) to allow only signed code to execute. - Use Case: Prevent the execution of malicious PowerShell scripts by requiring all scripts to be signed with a trusted certificate.

Vendor-Signed Driver Enforcement:

- Implementation: Enable kernel-mode code signing to ensure that only drivers signed by trusted vendors can be loaded. - Use Case: A malicious driver attempting to modify system memory fails to load because it lacks a valid signature.

Certificate Revocation Management:

- Implementation: Use Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs) to block certificates associated with compromised or deprecated code. - Use Case: A compromised certificate used to sign a malicious update is revoked, preventing further execution of the software.

Third-Party Software Verification:

- Implementation: Require software from external vendors to be signed with valid certificates before deployment. - Use Case: An organization only deploys signed and verified third-party software to prevent supply chain attacks.

Script Integrity in CI/CD Pipelines:

- Implementation: Integrate code signing into CI/CD pipelines to sign and verify code artifacts before production release. - Use Case: A software company ensures that all production builds are signed, preventing tampered builds from reaching customers.

**Key Components of Code Signing**

- Digital Signature Verification: Verifies the authenticity of code by ensuring it was signed by a trusted entity. - Certificate Management: Uses Public Key Infrastructure (PKI) to manage signing certificates and revocation lists. - Enforced Policy for Unsigned Code: Prevents the execution of unsigned or untrusted binaries and scripts. - Hash Integrity Check: Confirms that code has not been altered since signing by comparing cryptographic hashes.

Mitigation Enterprise

M1038: Execution Prevention

Prevent the execution of unauthorized or malicious code on systems by implementing application control, script blocking, and other execution prevention mechanisms. This ensures that only trusted and authorized code is executed, reducing the risk of malware and unauthorized actions. This mitigation can be implemented through the following measures:

Application Control:

- Use Case: Use tools like AppLocker or Windows Defender Application Control (WDAC) to create whitelists of authorized applications and block unauthorized ones. On Linux, use tools like SELinux or AppArmor to define mandatory access control policies for application execution. - Implementation: Allow only digitally signed or pre-approved applications to execute on servers and endpoints. (e.g., `New-AppLockerPolicy -PolicyType Enforced -FilePath "C:\Policies\AppLocker.xml"`)

Script Blocking:

- Use Case: Use script control mechanisms to block unauthorized execution of scripts, such as PowerShell or JavaScript. Web Browsers: Use browser extensions or settings to block JavaScript execution from untrusted sources. - Implementation: Configure PowerShell to enforce Constrained Language Mode for non-administrator users. (e.g., `Set-ExecutionPolicy AllSigned`)

Executable Blocking:

- Use Case: Prevent execution of binaries from suspicious locations, such as `%TEMP%` or `%APPDATA%` directories. - Implementation: Block execution of `.exe`, `.bat`, or `.ps1` files from user-writable directories.

Dynamic Analysis Prevention: - Use Case: Use behavior-based execution prevention tools to identify and block malicious activity in real time. - Implemenation: Employ EDR solutions that analyze runtime behavior and block suspicious code execution.

Change history

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 .

ATT&CK release
19.1
Object version
1.3
Created
Modified
Raw hash
e75b79d85e78876c...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.3 Current bundle e75b79d85e78…
Raw source

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.

Open mirrored raw JSON Open MITRE-hosted copy
Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    Apple AppleScript

    Apple. (2016, January 25). Introduction to AppleScript Language Guide. Retrieved March 28, 2020.

    Open source URL
  2. [2]
    SentinelOne AppleScript

    Phil Stokes. (2020, March 16). How Offensive Actors Use AppleScript For Attacking macOS. Retrieved July 17, 2020.

    Open source URL
  3. [3]
    SentinelOne macOS Red Team

    Phil Stokes. (2019, December 5). macOS Red Team: Calling Apple APIs Without Building Binaries. Retrieved July 17, 2020.

    Open source URL
  4. [4]
    Macro Malware Targets Macs

    Yerko Grbic. (2017, February 14). Macro Malware Targets Macs. Retrieved July 8, 2017.

    Open source URL
  5. [5]
    mitre-attack T1059.002
    Open source URL
Source and licensing

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.

Official MITRE ATT&CK site Official STIX data repository MITRE ATT&CK terms of use