Zum Inhalt springen

AusführungLogs

Gatekeeper- und XProtect-Spuren unter macOS

Gatekeeper, XProtect und XProtect Remediator hinterlassen Logs und Datenbanken, die zeigen, welcher Code geprüft, zugelassen, gemeldet oder entfernt wurde.

Speicherort
/var/db/SystemPolicyConfiguration/ExecPolicy
Belegt
Ob macOS ein bestimmtes Programm geprüft, zugelassen, blockiert oder bereinigt hat und welche Verhaltensweisen es gemeldet hat
Zeitstempel
Unified Log: Anzeige in der mit jedem Eintrag gespeicherten Zeitzone, sofern --timezone fehlt; XPdb dt: Datum und Uhrzeit als Text; ExecPolicy: Unix-Sekunden
Zugriff
root; Full Disk Access; XPdb ist ab 26.2 ein Data Vault
Aufbewahrung
Unified Log: Tage bis Wochen; Datenbanken: bis zum Neuaufbau (variiert)
Sicherung
Aftermath, mac_apt, UAC, log collect, sysdiagnose

Was es ist

Gatekeeper ist die macOS-Richtlinie, die Code in Quarantäne beim ersten Start prüft: Signatur, Developer ID, Notarisierung und XProtect-Signaturen. Umgesetzt wird sie von syspolicyd. XProtect ist Apples signaturbasierter Malware-Schutz (YARA-Regeln und zugehörige Daten in XProtect.bundle). XProtect Remediator ist eine Sammlung von Scannern in XProtect.app, die regelmäßig laufen und bekannte Malware entfernen können. Ab macOS 13 Ventura protokolliert der XProtect Behavior Service (Bastion-Regeln) Prozesse, die sensible Orte berühren, blockiert sie aber nicht.

Keine dieser Komponenten führt eine einzige saubere Historie. Die Belege verteilen sich auf das Unified Log, mehrere SQLite-Datenbanken und Versions-Plists.

Wo es liegt

ArtefaktPfadmacOSSchutz
Gatekeeper- und Exec-Policy-DB/var/db/SystemPolicyConfiguration/ExecPolicyDokumentiert seit 10.14; Tabelle provenance_tracking ab 13root
DB der Notarisierungstickets/var/db/SystemPolicyConfiguration/TicketsDokumentiert seit 10.14root
Gatekeeper-Richtlinien-DB/var/db/SystemPolicy (Tabelle authority); auf neueren Versionen /var/db/SystemPolicyConfiguration/SystemPolicySeit Langem vorhanden, Ort je nach Versionroot
Letzte Ablehnung durch Gatekeeper/private/var/db/SystemPolicyConfiguration/.LastGKReject; ältere Versionen: /private/var/db/.LastGKRejectAktueller Pfad im Security-Quellcode von Apple ab macOS 15; davor der alte Pfadroot
Gatekeeper-Daten/private/var/db/gkopaque.bundle; gke.bundle je nach Version in /private/var/db oder /var/db/SystemPolicyConfigurationAktuelle Versionenroot
XProtect-Daten (alt)/Library/Apple/System/Library/CoreServices/XProtect.bundle10.15-14; Fallback ab 15SIP
XProtect-Daten (primär)/var/protected/xprotect/XProtect.bundleAb 15 SequoiaSIP
XProtect Remediator/Library/Apple/System/Library/CoreServices/XProtect.appAb 12.3SIP
DB des Behavior Service/var/protected/xprotect/XPdbAb 13 Venturaroot
DB des Behavior Service (verschoben)/var/protected/xprotect/db/XPdbAb XProtectPayloads 156Data Vault ab 26.2
LogsUnified Log (/private/var/db/diagnostics)Alleroot zum Lesen

Ab macOS 26.2 ist der Ordner db ein Data Vault, den auf dem laufenden System selbst root nicht öffnen kann; Forschende berichten, dass er von einem eingehängten Data-Volume (Recovery oder ein lokaler Snapshot) lesbar ist. Das xattr com.apple.provenance (11 Byte) an App-Bundles enthält einen Schlüssel in provenance_tracking.

Was es belegt

  • Dass eine App von Gatekeeper geprüft wurde und ob sie akzeptiert oder abgelehnt wurde (Log-Einträge von syspolicyd, .LastGKReject).
  • Dass ein Benutzer Gatekeeper bewusst übergangen hat (Log-Einträge; Endpoint Security ES_EVENT_TYPE_NOTIFY_GATEKEEPER_USER_OVERRIDE ab macOS 15).
  • Dass eine App nach dem Download erstmals ausgeführt werden durfte, und ihren cdhash zu diesem Zeitpunkt (provenance_tracking, ab Ventura).
  • Dass XProtect Remediator eine benannte Bedrohung erkannt oder bereinigt hat (Log-Kategorie XPEvent.structured; ES-Ereignisse ES_EVENT_TYPE_NOTIFY_XP_MALWARE_DETECTED / ..._REMEDIATED ab macOS 13).
  • Dass ein Prozess eine Regel des Behavior Service ausgelöst hat, mit Hashes und Team-IDs des ausführbaren und des verantwortlichen Prozesses (XPdb).
  • Welche Versionen von XProtect und Remediator installiert waren (Info.plist des Bundles).

Ein sauberes Urteil von Gatekeeper oder XProtect belegt nicht, dass Code harmlos ist; Signaturen decken nur bekannte Familien ab.

Wichtige Felder

Tabelle events in XPdb (ab Ventura): violated_rule, exec_path, exec_cdhash, exec_signing_id, exec_team_id, exec_sha256, exec_is_notarized, responsible_path, responsible_cdhash, responsible_signing_id, responsible_team_id, responsible_sha256, responsible_is_notarized, reported, profile_hash, dt.

ExecPolicy: provenance_tracking (ab Ventura) speichert die Herkunft pro App mit cdhash; ältere Tabellen sind unter anderem legacy_exec_history_v4, scan_targets_v2 und executable_measurements_v2. Die Schemata sind undokumentiert, prüfen Sie sie daher mit .tables und .schema.

Versions-Plists: CFBundleShortVersionString in der Contents/Info.plist jedes Bundles.

Zeitstempel

  • Unified Log: log show beachtet TZ nicht; ohne --timezone gibt es jeden Eintrag in der Zeitzone aus, die beim Schreiben gespeichert wurde. Verwenden Sie --timezone UTC für Zeitleisten (siehe Unified Logs).
  • XPdb dt: Datum und Uhrzeit als Text (zum Beispiel 2023-06-30 06:34:28); prüfen Sie die Zeitzone auf einem Testsystem.
  • Ganzzahlige Zeiten in ExecPolicy sind Unix-Sekunden; die ExecPolicy-Module von APOLLO wandeln sie mit UNIXEPOCH um.
SELECT dt, violated_rule, exec_path, exec_team_id, responsible_path
FROM events ORDER BY dt DESC;

Aufbewahrung

Einträge im Unified Log altern mit dem Log-Speicher heraus (typischerweise einige Tage bis wenige Wochen, je nach Volumen). XPdb erfasst jeden eindeutigen Regel-Fingerabdruck einmal pro Prozess und Boot und wird an Apple übertragen; erwarten Sie keine vollständige Historie. Zeilen in ExecPolicy und SystemPolicy bleiben bestehen, bis macOS sie neu aufbaut. XProtect-Bundles werden bei jedem Update ersetzt.

Sicherung

# Logs first: they age out
sudo log collect --last 7d --output ./case/system.logarchive
# Databases (root, Full Disk Access)
sudo ditto /var/db/SystemPolicyConfiguration ./case/spc
# Older releases keep SystemPolicy and .LastGKReject in /var/db (the ditto above copies the current .LastGKReject)
sudo cp -p /var/db/SystemPolicy /private/var/db/.LastGKReject ./case/ 2>/dev/null
# db/ is a Data Vault on 26.2+: copy it from a snapshot or from Recovery
sudo cp -p /var/protected/xprotect/XPdb* /var/protected/xprotect/db/XPdb* ./case/ 2>/dev/null
spctl --status
  • Aftermath sichert Daten des XProtect Behavior Service (vom alten Pfad /var/protected/xprotect/XPdb, nicht db/XPdb), XProtect-Versionen und den Gatekeeper-Status.
  • UAC files/system/xprotect.yaml sichert die Info.plist-Dateien von XProtect, XProtect Remediator und MRT.
  • sysdiagnose enthält ein Log-Archiv.

Auswertung

  • log auf einem Live-System oder einem .logarchive:
log show ./case/system.logarchive --info \
  --predicate 'subsystem == "com.apple.XProtectFramework.PluginAPI" AND category == "XPEvent.structured"'
log show ./case/system.logarchive --info --predicate 'subsystem == "com.apple.syspolicy.exec"'
log show ./case/system.logarchive --info --predicate 'process == "syspolicyd"'
  • Plugin XPROTECT von mac_apt (Diagnosedateien von XProtect und DB des Behavior Service) und Plugin QUARANTINE (.LastGKReject).
  • sqlite3 für XPdb und ExecPolicy, auf Kopien.
  • Ein Sample auf einem Analyse-Mac prüfen: spctl --assess --type execute -vv <app>, codesign -dv --verbose=4 <app>.

Unified Log Parser öffnet ein .logarchive, die Ordner diagnostics und uuidtext oder einen log show-Export im Browser, wendet DFIR-Triage-Regeln an und exportiert als CSV oder für Timesketch; es wird nichts hochgeladen.

Quarantine Parser liest .LastGKReject zusammen mit der Quarantäne-Datenbank, sodass sich eine Ablehnung ihrem Download zuordnen lässt.

Tipps für die Untersuchung

  • Bauen Sie die Kette auf: Quarantäne-Ereignis, dann Gatekeeper-Prüfung, dann Zeile in provenance_tracking, dann launchd-Persistenz.
  • Ab macOS 15 gibt es die Umgehung per Control-Klick nicht mehr; Übersteuerungen laufen über die Systemeinstellungen. Ein Override durch den Benutzer ist daher eine bewusste Handlung, die dokumentiert werden sollte.
  • responsible_path in XPdb nennt oft die Eltern-App (Terminal, ein Browser, ein Installer), was bei der Zuordnung von Aktivität hilft.
  • /var/protected/xprotect/XPdb kann ab 26.2 alt oder veraltet sein: Prüfen Sie den Unterordner db.
  • Notieren Sie die Versionen von XProtect und Remediator zum Zeitpunkt der Sicherung: Eine Erkennung, die nach einem Update auftaucht, zeigt, wann die Abdeckung kam, nicht wann die Infektion stattfand.
  • Pfade unter AppTranslocation in Logs bedeuten, dass eine App in Quarantäne von einem zufällig benannten, schreibgeschützten Mount lief.
  • Korrelieren Sie Installationspakete mit der Installationshistorie und Datenschutzfreigaben mit TCC.db.

Siehe auch