AppleScript und osascript: Missbrauch unter macOS erkennen

AppleScript ist fester Bestandteil von macOS und für sich völlig legitim - genau das macht es für Angreifer attraktiv. Über osascript lässt sich Skriptcode ausführen, ohne eine eigene ausführbare Datei mitzubringen, und der Aufruf geht im normalen Automatisierungsrauschen leicht unter. Dieser Beitrag bleibt auf der Erkennungsseite und zeigt, woran sich der Missbrauch erkennen lässt, welche macOS-Telemetrie das trägt und wo die Technik unsichtbar bleibt. Er setzt die Grundlagen aus macOS-Sicherheitsmonitoring voraus. Der Anker ist nicht eine Event-ID, sondern der osascript-Prozess mit seiner Befehlszeile.

Was der Angreifer tut

osascript führt AppleScript (und über einen Schalter auch JavaScript for Automation, JXA) aus. Die missbrauchten Muster sind überschaubar. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• Aus dem Skript in die Shell. Der Befehl do shell script führt beliebige Shell-Kommandos aus dem AppleScript heraus aus - die Brücke von der Automatisierung zur normalen Kommandoausführung, ein Klassiker in bewaffneten Dokumenten und Droppern.
• Den Rechte-Dialog nutzen. with administrator privileges lässt den bekannten macOS-Passwortdialog erscheinen. Gibt der Nutzer sein Passwort ein, läuft der Befehl als root - eine Rechteausweitung, die auf Täuschung statt auf einer Schwachstelle beruht.
• Inline statt Datei. Mit osascript -e wird das Skript direkt auf der Kommandozeile übergeben, ohne eine .scpt-Datei abzulegen - weniger Spuren auf der Platte, aber die Befehlszeile verrät es.
• Als Glied einer Kette. osascript wird von einer Shell, einem Download-Werkzeug oder einem Dokument gestartet, nicht interaktiv vom Nutzer - der Elternprozess verrät die Automatisierung.

Für die Erkennung ist entscheidend: All diese Muster laufen über den osascript-Prozess, dessen Befehlszeile und dessen Elternprozess. Genau daran setzen die Regeln an - und genau dort, wo AppleScript nicht über osascript läuft, endet ihre Reichweite.

Welche Telemetrie die Technik zeigt

• Endpoint Security Framework (ESF). Die tragende Echtzeit-Quelle über eslogger, Red Canary Mac Monitor oder EDR. Belastbar ist das Prozessereignis von osascript mit Image, vollständiger Befehlszeile und Elternprozess - die Grundlage aller drei Regeln.
• Unified Log. AppleScript, das andere Apps steuert, löst über das Automatisierungssystem (Apple Events) Einträge und teils TCC-Zustimmungsdialoge aus, die das Unified Log festhält. Das ist für die forensische Rekonstruktion nützlich, für die laufende Regelarbeit aber zu unspezifisch.
• OpenBSM/audit. Die ältere BSM-Audit-Spur zeigt den osascript-Prozessstart als Rückfallebene, wenn keine ESF-Quelle vorhanden ist - ohne den gleichen Kontext wie ESF.
• Dateisystem- und Artefaktsicht. Kompilierte Skripte (.scpt) und AppleScript-Applets (eine .app mit eingebettetem Skript) bleiben als Artefakt auf der Platte und lassen sich auch nachträglich finden - wichtig, weil genau diese Formen oft nicht über osascript laufen.

Das Muster

Das stärkste Signal ist osascript mit with administrator privileges: Ein Skript, das nach dem Admin-Passwort fragt, hat fast immer entweder einen klaren legitimen Grund (ein bekannter Installer) oder ist ein Täuschungsversuch. Fast ebenso deutlich ist do shell script, die Brücke von AppleScript in die Shell, besonders wenn osascript selbst von einer Shell oder einem Download-Werkzeug gestartet wurde. Der Elternprozess trägt viel: Ruft ein Nutzer osascript interaktiv auf, ist das Alltag; startet es aus einer Kette heraus, wird es auffällig. Keines dieser Signale ist für sich beweisend, weil Automatisierung dieselben Befehle nutzt. Belastbar wird der Fall aus der Verkettung von Herkunft, Befehl und dem, was danach passiert.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und setzen auf der Prozess-Logquelle auf (ESF-gespeist). Die erste nimmt die Brücke in die Shell, die zweite den Rechte-Dialog, die dritte den verdächtigen Elternprozess.

1. osascript führt eine Shell über do shell script aus (T1059.002). Die Brücke von AppleScript in die Shell, auf level: medium.

title: osascript fuehrt eine Shell ueber do shell script aus
id: 5b25feeb-8bf6-4b4e-a285-e5c6dd593d9c
status: experimental
description: |
  Erkennt osascript mit do shell script. AppleScript kann darueber direkt Shell-Befehle
  ausfuehren; das ist ein haeufiges Muster bei macOS-Schadsoftware und in bewaffneten
  Office-Dokumenten, um aus einem Skript heraus Code zu starten (AppleScript). Einzelne
  Admin- und Automatisierungsablaeufe nutzen es ebenfalls, der Kontext entscheidet.
references:
  - https://attack.mitre.org/techniques/T1059/002/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.execution
  - attack.t1059.002
logsource:
  product: macos
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/osascript'
  sel_cmd:
    CommandLine|contains: 'do shell script'
  condition: sel_img and sel_cmd
falsepositives:
  - Legitime Automatisierung und Admin-Skripte nutzen do shell script - bekannte Skripte und Konten als Baseline ausnehmen
level: medium

2. osascript fordert Administratorrechte an (T1059.002, T1548.004). Der Rechte-Dialog, auf level: high und mit beiden Techniken getaggt.

title: osascript fordert Administratorrechte an
id: 48676839-e600-44d5-9994-85eba03ae87e
status: experimental
description: |
  Erkennt osascript mit with administrator privileges. Darueber laesst AppleScript den
  bekannten macOS-Dialog erscheinen, der nach dem Administratorpasswort fragt, und
  fuehrt den Befehl danach mit erhoehten Rechten aus. Schadsoftware nutzt diesen Dialog,
  um den Nutzer zur Rechteausweitung zu verleiten (Elevated Execution with Prompt).
references:
  - https://attack.mitre.org/techniques/T1059/002/
  - https://attack.mitre.org/techniques/T1548/004/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.execution
  - attack.t1059.002
  - attack.privilege-escalation
  - attack.t1548.004
logsource:
  product: macos
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/osascript'
  sel_cmd:
    CommandLine|contains: 'with administrator privileges'
  condition: sel_img and sel_cmd
falsepositives:
  - Einzelne Installer und Admin-Werkzeuge fordern so legitim Rechte an - bekannte Faelle als Baseline ausnehmen
level: high

3. osascript als Kind einer Shell oder eines Interpreters (T1059.002). Der verdächtige Elternprozess, auf level: medium.

title: osascript als Kind einer Shell oder eines Interpreters gestartet
id: 1fbfed34-8147-4c4b-952c-a2f31574e7a2
status: experimental
description: |
  Erkennt osascript, das von einer Shell, einem Skript-Interpreter oder einem
  Download-Werkzeug gestartet wird. Interaktiv ruft ein Nutzer AppleScript selten so
  auf; der Elternprozess deutet auf eine automatisierte Kette, etwa aus einem
  heruntergeladenen Skript oder einem bewaffneten Dokument (AppleScript).
references:
  - https://attack.mitre.org/techniques/T1059/002/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.execution
  - attack.t1059.002
logsource:
  product: macos
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/osascript'
  sel_parent:
    ParentImage|endswith:
      - '/bash'
      - '/sh'
      - '/zsh'
      - '/curl'
      - '/python3'
      - '/python'
  condition: sel_img and sel_parent
falsepositives:
  - Eigene Automatisierungsskripte, die AppleScript aus einer Shell heraus aufrufen - bekannte Skripte und Hosts als Baseline ausnehmen
level: medium

Grenzen der Erkennung

• AppleScript ohne osascript. Eine App kann AppleScript direkt über die System-Schnittstellen (NSAppleScript, OSAKit) ausführen, ohne osascript zu starten. Dann gibt es keinen osascript-Prozess und die Regeln greifen nicht - sichtbar ist das nur über die Apple-Events-Ebene einer EDR oder über das Artefakt.
• Applets als eigene App. Ein AppleScript-Applet ist eine .app mit eingebettetem Skript und läuft über den eingebauten Applet-Starter, nicht über osascript. Die Regeln erfassen es nicht; hier hilft die Artefaktsicht auf die .app.
• Verschleierte Befehlszeilen. Die Regeln suchen nach festen Zeichenketten (do shell script, with administrator privileges). Wird das Skript aus einer Variablen oder einer Datei nachgeladen, steht der verräterische Text nicht in der Befehlszeile - dann trägt nur der Elternprozess oder die Folgeaktivität.
• Sichtbarkeit ist produktabhängig. Ohne ESF-Quelle gibt es kein Echtzeitsignal. Die Felder setzen voraus, dass die Quelle Prozessstart mit Befehlszeile und Elternprozess liefert.

Fehlalarme und Tuning

• Automatisierung ist Alltag. Viele Verwaltungs- und Produktivitätswerkzeuge nutzen osascript und do shell script. Bekannte Automatisierungen, MDM-Skripte und Konten als Baseline aufnehmen, bevor Regel 1 und 3 scharf laufen.
• Admin-Prompt gezielt prüfen. Regel 2 ist hochwertig, aber auch Installer nutzen den Dialog. Nach dem aufrufenden Programm und Kontext priorisieren statt pauschal zu alarmieren.
• Elternprozess als Filter. osascript interaktiv aus der Terminal-Shell eines Entwicklers ist anders zu werten als osascript aus curl oder aus einem Dokumentprozess. Den Elternkontext in die Bewertung aufnehmen.
• Kette schlägt Einzeltreffer. osascript, das aus einem Download startet und per do shell script etwas nachlädt oder per Admin-Dialog eskaliert - diese Abfolge ist weit aussagekräftiger als ein Treffer allein.

Analysten-Checkliste

1. Was steht in der osascript-Befehlszeile - do shell script, with administrator privileges, ein JXA-Schalter (-l JavaScript) oder ein Inline-Skript (-e)?
2. Welcher Elternprozess hat osascript gestartet - eine interaktive Shell, ein Download-Werkzeug oder ein Dokumentprozess?
3. Fragte das Skript nach Administratorrechten, und passt das zu einem bekannten, legitimen Installer?
4. Was tat das Skript danach - eine Datei nachgeladen, Persistenz angelegt, eine Verbindung aufgebaut?
5. Gibt es ein zugehöriges Artefakt - eine .scpt-Datei oder ein Applet im Benutzerprofil?
6. Stammt der Aufruf von einem Konto und zu einer Zeit, die zur normalen Automatisierung passen?

Härtung

• Apple Events und Automatisierung einschränken. Über MDM und TCC steuern, welche Programme andere Apps per AppleScript steuern dürfen - das begrenzt den Missbrauch der Automatisierung.
• ESF-Quelle bereitstellen. eslogger, Red Canary Mac Monitor oder eine EDR aktivieren und die osascript-Prozessereignisse mit vollständiger Befehlszeile zentral ins SIEM bringen.
• Makros und Dokument-Starter eindämmen. Bewaffnete Dokumente sind ein häufiger Einstieg; Office-Makros und das Starten von Skript-Interpretern aus Dokumenten über Richtlinien begrenzen.
• Nutzer für den Rechte-Dialog sensibilisieren. Der Passwortdialog aus with administrator privileges wirkt wie ein System-Prompt. Awareness hilft, dass niemand ihn für ein beliebiges Skript bestätigt.

Der Test im Lab

Die Erkennung lässt sich auf einem Test-Mac mit aktivem eslogger oder Red Canary Mac Monitor gefahrlos prüfen:

• Für Regel 1 osascript -e 'do shell script "id"' ausführen und prüfen, dass das ESF-Prozessereignis die Befehlszeile zeigt und die Regel greift.
• Für Regel 2 im Lab einen harmlosen Befehl mit with administrator privileges ausführen (den Dialog bestätigen) und den Treffer kontrollieren.
• Für Regel 3 osascript aus einem kurzen bash-Skript heraus starten und prüfen, dass der Elternprozess im Ereignis als Shell auftaucht.
• Breiter wird der Test mit den macOS-Fällen zu T1059.002 aus Atomic Red Team.

Fazit

AppleScript-Missbrauch läuft fast immer über osascript, und genau dort ist er gut zu fassen: do shell script als Brücke in die Shell, with administrator privileges als Täuschung für die Rechteausweitung und ein verdächtiger Elternprozess als Zeichen der Automatisierung. Die drei Regeln nehmen diese Muster aus dem ESF-Prozessereignis. Ehrlich bleibt die Grenze: AppleScript über die System-Schnittstellen oder als Applet läuft nicht über osascript und entgeht diesen Regeln, und eine verschleierte Befehlszeile zeigt den verräterischen Text nicht. Die wirksamste Härtung ist, Automatisierung und Apple Events per MDM einzuschränken und den Rechte-Dialog bewusst zu machen. Die Grundlagen stehen unter macOS-Sicherheitsmonitoring; die übrigen Beiträge dieser macOS-Reihe behandeln die LaunchAgents- und LaunchDaemons-Persistenz, die Gatekeeper- und Quarantine-Umgehung, den Keychain-Zugriff, die TCC-Manipulation und das Dylib-Hijacking.