Dylib- und Dyld-Hijacking unter macOS erkennen

Dylib-Hijacking ist das macOS-Gegenstück zum DLL-Hijacking unter Windows: Schadcode läuft nicht in einem eigenen, verdächtigen Prozess, sondern wird von einer vertrauenswürdigen Anwendung mitgeladen. Für die Erkennung ist das unbequem, und dieser Beitrag sagt offen, wo sie an Grenzen stößt, statt eine Sicherheit zu behaupten, die die Datenquelle nicht hergibt. Er bleibt auf der Erkennungsseite, setzt die Grundlagen aus macOS-Sicherheitsmonitoring voraus und zeigt, was sich wirklich belastbar fassen lässt - und was nicht.

Was der Angreifer tut

macOS-Programme laden Bibliotheken über einen Suchpfad und über Umgebungsvariablen. Beides lässt sich kapern. Bewusst auf der Ebene des Prinzips, nicht als Anleitung:

• DYLD_INSERT_LIBRARIES setzen. Startet ein Programm mit dieser Umgebungsvariablen, lädt der dynamische Linker die angegebene dylib zusätzlich - der Schadcode landet im Prozess. Die Variable kann in einer Befehlszeile, über launchctl für die ganze Sitzung, in einer plist oder direkt per API gesetzt werden.
• Eine dylib in den Suchpfad legen. Sucht eine Anwendung eine Bibliothek über einen relativen Pfad (rpath) oder lädt sie eine optionale (weak) dylib, die gar nicht vorhanden ist, füllt der Angreifer die Lücke mit seiner eigenen - das klassische Dylib-Hijacking.
• Warum das attraktiv ist. Der Code erbt Identität und Rechte des vertrauten Prozesses. Allerdings begrenzen Library Validation und die Hardened Runtime das stark: Signierte, gehärtete Programme lehnen eine fremde oder unsignierte dylib ab, sofern sie nicht ausdrücklich entsprechende Ausnahmen tragen. In der Praxis trifft es daher vor allem unsignierte oder nicht gehärtete Anwendungen.

Für die Erkennung ist das entscheidend: Das Setzen der Variablen und das Ablegen der dylib sind teilweise sichtbar. Der eigentliche Ladevorgang - die Stelle, an der die gekaperte dylib tatsächlich in den Prozess kommt - ist es mit portabler Telemetrie kaum.

Welche Telemetrie die Technik zeigt - und welche nicht

• Endpoint Security Framework (ESF), teilweise. Belastbar als Prozessereignis ist das Setzen von DYLD_INSERT_LIBRARIES in einer Befehlszeile und per launchctl setenv sowie als Dateiereignis das Ablegen einer dylib. Das sind die Ränder der Technik. Das eigentliche Laden einer dylib hat in der portablen macOS-Logquelle keine eigene Kategorie - nur eine EDR, die ESF-Image-Load- oder Mmap-Ereignisse auswertet, sieht den Ladevorgang.
• Unified Log. Lehnt die Hardened Runtime eine fremde dylib ab, protokolliert AMFI (die Code-Signatur-Durchsetzung) die Zurückweisung; auch dyld-Ladefehler erscheinen hier. Das ist ein wertvolles forensisches Signal für einen fehlgeschlagenen Versuch, aber kein Material für eine portable Regel.
• Dateisystem- und Artefaktsicht. Eine unsignierte dylib in einem App-Bundle oder im Suchpfad einer Anwendung ist das greifbare Artefakt. Mit otool oder codesign lassen sich die Lade-Pfade (rpath) und die Signatur einer Anwendung nachträglich prüfen - oft der verlässlichste Befund.
• OpenBSM/audit. Zeigt den Prozessstart als Rückfallebene, nicht aber den dylib-Ladevorgang.

Das Muster

Die belastbaren Signale liegen an den Rändern: DYLD_INSERT_LIBRARIES in einer Befehlszeile oder per launchctl setenv gesetzt, und eine dylib, die von einer Shell oder einem Download-Werkzeug geschrieben wird statt von einem Installer. Das stärkste zusätzliche Signal kommt aus dem Unified Log, wenn die Hardened Runtime eine fremde dylib ablehnt - dann ist ein Versuch belegt. Was dagegen fehlt, ist das verlässliche Einzelsignal für das erfolgreiche Laden einer gekaperten dylib in einen laufenden Prozess. Belastbar wird ein Fall deshalb nur aus der Zusammenschau: eine abgelegte oder per Variable eingeschleuste dylib, ein auffälliger Prozess, der sie lädt, und das, was dieser Prozess danach tut.

Drei Sigma-Regeln

Die Regeln sind mit sigma-cli geprüft und fassen bewusst nur die belastbaren Ränder: das Setzen der Variablen und das Ablegen der dylib. Keine von ihnen behauptet, das eigentliche Laden zu erkennen - diese Grenze steht ausdrücklich im Abschnitt darunter.

1. DYLD_INSERT_LIBRARIES in einer Befehlszeile (T1574.006). Nur die Kommandozeilen-Form, auf level: medium.

title: DYLD_INSERT_LIBRARIES in einer Befehlszeile gesetzt
id: 801c37dd-7715-4d3a-9cd2-56a1cb64e17c
status: experimental
description: |
  Erkennt das Setzen der Umgebungsvariablen DYLD_INSERT_LIBRARIES in einer Befehlszeile.
  Damit laesst sich beim Start eines Programms eine fremde dylib mitladen (Dynamic Linker
  Hijacking). Diese Regel fasst nur die Form, bei der die Variable in der Kommandozeile
  einer Shell auftaucht; ueber launchd, eine plist oder direkt per API gesetzt, ist sie
  hier nicht sichtbar. Entwickler und Debugger nutzen die Variable ebenfalls.
references:
  - https://attack.mitre.org/techniques/T1574/006/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.execution
  - attack.stealth
  - attack.t1574.006
logsource:
  product: macos
  category: process_creation
detection:
  sel:
    CommandLine|contains: 'DYLD_INSERT_LIBRARIES'
  condition: sel
falsepositives:
  - Entwickler, Debugger und Test-Frameworks setzen DYLD_INSERT_LIBRARIES legitim - bekannte Werkzeuge und Konten als Baseline ausnehmen
level: medium

2. Globale DYLD-Variable per launchctl setenv (T1574.006). Die sitzungsweite Injektion, auf level: high.

title: Globale DYLD-Variable per launchctl setenv gesetzt
id: 62f30e22-32d2-4beb-9fde-ec382e81a1c5
status: experimental
description: |
  Erkennt das Setzen einer DYLD-Umgebungsvariablen fuer die gesamte Sitzung mit
  launchctl setenv. Damit wird eine fremde dylib fuer danach gestartete Prozesse
  mitgeladen (Dynamic Linker Hijacking). launchctl setenv auf eine DYLD-Variable ist im
  normalen Betrieb sehr ungewoehnlich.
references:
  - https://attack.mitre.org/techniques/T1574/006/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.execution
  - attack.stealth
  - attack.t1574.006
logsource:
  product: macos
  category: process_creation
detection:
  sel_img:
    Image|endswith: '/launchctl'
  sel_cmd:
    CommandLine|contains: 'setenv'
  sel_dyld:
    CommandLine|contains: 'DYLD'
  condition: sel_img and sel_cmd and sel_dyld
falsepositives:
  - Sehr selten in Entwickler- oder Testumgebungen - auf Endpunkten als Alarm behandeln
level: high

3. dylib von einer Shell oder einem Downloader geschrieben (T1574.004). Das Ablegen, nicht das Laden, auf level: medium.

title: dylib von einer Shell oder einem Downloader geschrieben
id: 1f671a84-e950-47c3-91b5-044ff7465938
status: experimental
description: |
  Erkennt das Schreiben einer dylib durch eine Shell, einen Skript-Interpreter oder ein
  Download-Werkzeug. Beim Dylib-Hijacking legt der Angreifer eine praeparierte dylib
  dorthin, wo eine Anwendung sie ueber ihren Suchpfad (rpath, weak dylib) findet. Legitime
  dylibs bringt ein Installer mit, nicht bash oder curl. Die Regel erkennt das Ablegen,
  nicht das spaetere Laden der dylib.
references:
  - https://attack.mitre.org/techniques/T1574/004/
author: blue-team.net
date: 2026-10-07
tags:
  - attack.execution
  - attack.stealth
  - attack.t1574.004
logsource:
  product: macos
  category: file_event
detection:
  sel_file:
    TargetFilename|endswith: '.dylib'
  sel_writer:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/zsh'
      - '/curl'
      - '/python3'
      - '/python'
  condition: sel_file and sel_writer
falsepositives:
  - Entwickler- und Build-Werkzeuge erzeugen dylibs im Benutzerprofil - bekannte Build-Pfade und Werkzeuge als Baseline ausnehmen
level: medium

Grenzen der Erkennung

Dieser Abschnitt ist bei dieser Technik der wichtigste, weil die Datenquelle hier weniger hergibt als bei den anderen macOS-Beiträgen:

• Das Laden selbst ist der große Blindspot. Die portable macOS-Logquelle hat keine Kategorie für das Laden einer Bibliothek - kein Gegenstück zu Sysmon Event 7 unter Windows. Ob eine gekaperte dylib tatsächlich in einen Prozess geladen wurde, zeigt nur eine EDR, die ESF-Image-Load- oder Mmap-Ereignisse auswertet. Die drei Regeln erkennen das Setzen und das Ablegen, nicht das Laden - das ist keine Formulierungsfrage, sondern eine echte Lücke.
• DYLD-Variable abseits der Kommandozeile. Wird DYLD_INSERT_LIBRARIES in einer plist (EnvironmentVariables), über die Umgebung eines Elternprozesses oder direkt per API gesetzt, steht sie nicht in einer Befehlszeile. Regel 1 sieht sie dann nicht; portabel ist dieser Weg kaum zu fassen, weil Umgebungsvariablen eines Prozesses kein Standardfeld der macOS-Logquelle sind.
• Ablegen ist nicht gleich Hijack. Regel 3 zeigt, dass eine dylib geschrieben wurde - nicht, ob sie auf dem Suchpfad einer Anwendung liegt und je geladen wird. Ob ein echter Hijack vorliegt, klärt erst die Artefaktprüfung mit otool und codesign.
• Library Validation begrenzt die Technik. Gegen signierte, gehärtete Programme scheitert die dylib-Injektion meist von vornherein. Das verkleinert die Angriffsfläche auf unsignierte und nicht gehärtete Software - und verschiebt das verlässlichste Signal von der Erkennung hin zur Bestandsprüfung, welche Programme überhaupt angreifbar sind.

Fehlalarme und Tuning

• Entwicklung ist der Hauptfall. Debugger, Test-Frameworks und Instrumentierung setzen DYLD_INSERT_LIBRARIES völlig regulär. Ohne Baseline der bekannten Entwickler- und Testwerkzeuge ist Regel 1 laut - diese zuerst ausnehmen.
• Build-Prozesse erzeugen dylibs. Compiler und Build-Systeme schreiben laufend dylibs ins Benutzerprofil. Die bekannten Build-Pfade und Werkzeuge für Regel 3 als Baseline aufnehmen.
• launchctl setenv DYLD ist fast immer ein Alarm. Regel 2 sollte auf Endpunkten nicht getunt, sondern untersucht werden - der legitime Bedarf ist sehr gering.
• Das Unified Log hinzuziehen. Eine AMFI-Ablehnung oder ein dyld-Ladefehler neben einem Regeltreffer verdichtet den Verdacht erheblich - diese Korrelation lohnt die Mühe.

Analysten-Checkliste

1. Welches Signal liegt vor - DYLD_INSERT_LIBRARIES in der Befehlszeile, launchctl setenv DYLD oder eine geschriebene dylib?
2. Stammt der Aufruf aus einem Entwickler- oder Testkontext, oder von einem untypischen Konto und Elternprozess?
3. Wo liegt die dylib - im Bundle oder Suchpfad einer konkreten Anwendung? Mit otool die rpath-Einträge dieser Anwendung prüfen.
4. Ist die dylib signiert, und ist die Zielanwendung signiert und gehärtet? Eine unsignierte dylib bei einer nicht gehärteten App ist der kritische Fall.
5. Zeigt das Unified Log eine AMFI-Ablehnung oder einen dyld-Ladefehler zum passenden Zeitpunkt?
6. Gibt es EDR-Telemetrie zum tatsächlichen Laden der dylib, oder bleibt nur der Rand aus Setzen und Ablegen?

Härtung

• Nur signierte, gehärtete Software zulassen. Library Validation und die Hardened Runtime sind die wirksamste Gegenmaßnahme: Sie lehnen fremde dylibs ab. Wo möglich die Ausführung auf notarisierte, gehärtete Programme beschränken.
• Angreifbare Anwendungen inventarisieren. Unsignierte oder nicht gehärtete Programme mit rpath- oder weak-dylib-Abhängigkeiten gezielt suchen (otool, codesign) und ersetzen oder absichern - hier liegt die eigentliche Angriffsfläche.
• Benutzer aus Programmverzeichnissen heraushalten. Wo Nutzer nicht in App-Bundles und Programmpfade schreiben dürfen, lässt sich keine dylib neben eine installierte Anwendung legen.
• ESF-Quelle mit Ladeereignissen anstreben. Eine EDR, die ESF-Image-Load-Ereignisse auswertet, schließt den größten Blindspot - das tatsächliche Laden - so weit wie unter macOS möglich.

Der Test im Lab

Die Erkennung lässt sich auf einem Test-Mac mit aktivem eslogger oder Red Canary Mac Monitor gefahrlos prüfen, mit einer harmlosen Test-dylib und einem unsignierten Testprogramm:

• Für Regel 1 ein unsigniertes Testprogramm mit DYLD_INSERT_LIBRARIES=/pfad/test.dylib ./prog starten und prüfen, dass das ESF-Prozessereignis die Variable in der Befehlszeile zeigt.
• Für Regel 2 launchctl setenv DYLD_INSERT_LIBRARIES /pfad/test.dylib ausführen (und mit unsetenv zurücksetzen) und den Treffer kontrollieren.
• Für Regel 3 eine harmlose .dylib per bash in ein Benutzerverzeichnis schreiben und prüfen, dass der schreibende Prozess im Ereignis auftaucht.
• Den Blindspot bewusst gegentesten: dieselbe Injektion gegen ein signiertes, gehärtetes Programm versuchen und im Unified Log die AMFI-Ablehnung beobachten - so wird sichtbar, was die Prozess- und Dateiregeln nicht zeigen. Breiter wird der Test mit den macOS-Fällen zu T1574 aus Atomic Red Team.

Fazit

Dylib- und Dyld-Hijacking sind unter macOS real, aber mit nativer, portabler Telemetrie nur an den Rändern zu fassen: das Setzen von DYLD_INSERT_LIBRARIES in der Befehlszeile oder per launchctl und das Ablegen einer dylib. Das eigentliche Laden einer gekaperten dylib bleibt der ehrliche Blindspot, den nur eine EDR mit Image-Load-Telemetrie schließt. Die drei Regeln liefern deshalb Hinweise, keine Gewissheit, und das Unified Log (AMFI) sowie die Artefaktprüfung mit otool und codesign tragen den Rest. Die wirksamste Härtung ist zugleich der beste Schutz: nur signierte, gehärtete Software, die fremde dylibs ohnehin ablehnt. 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 AppleScript- und osascript-Missbrauch, den Keychain-Zugriff und die TCC-Manipulation. Den verwandten Windows-Fall zeigt das DLL-Hijacking.