thomasareed/pictModulares Incident-Response-Toolkit zur Erfassung forensischer Daten von potenziell infizierten macOS-Endpunkten, das Browser-Artefakte, Persistenzmechanismen, Prozesse und Netzwerkkonfigurationen sichert.
Diese Skriptsammlung soll eine Vielzahl von Daten von einem als infiziert vermuteten Endpunkt sammeln, um den Incident-Response-Prozess zu unterstützen. Diese Daten sollten nicht als vollständige forensische Datensammlung betrachtet werden, erfassen aber eine Menge nützlicher forensischer Informationen.
Wenn Sie echte forensische Daten wünschen, sollten Sie tatsächlich einen vollständigen Speicherauszug erfassen und die gesamte Festplatte abbilden. Das liegt außerhalb des Rahmens dieses Toolkits.
Das Skript muss auf einem Live-System ausgeführt werden, nicht auf einem Abbild oder einem anderen forensischen Datenspeicher. Es benötigt streng genommen keine Root-Berechtigungen zur Ausführung, kann aber ohne diese viele der vorgesehenen Daten nicht sammeln.
Die Daten werden in zwei Formen gesammelt. Erstens in Form von Zusammenfassungsdateien, die die Ausgabe von Shell-Befehlen, aus Datenbanken extrahierte Daten und Ähnliches enthalten. Zum Beispiel gibt das Modul browser eine Datei browser_extensions.txt aus, die eine Zusammenfassung aller installierten Browsererweiterungen für Safari, Chrome und Firefox enthält.
Zweitens vollständige Dateien, die vom Dateisystem gesammelt werden. Diese werden in einem Unterordner artifacts innerhalb des Sammlungsordners gespeichert.
Das Skript ist sehr einfach auszuführen. Es benötigt nur einen Parameter, der erforderlich ist, um ein Konfigurationsskript im JSON-Format zu übergeben:
./pict.py -c /path/to/config.json
Das Konfigurationsskript beschreibt, was das Skript sammeln soll und wie. Es sollte etwa so aussehen:
{
"collection_dest" : "~/Desktop/",
"all_users" : true,
"collectors" : {
"browser" : "BrowserExtCollector",
"persist" : "PersistenceCollector",
"suspicious" : "SuspiciousBehaviorCollector",
"browserhist" : "BrowserHistoryCollector",
"bash_config" : "BashConfigCollector",
"bash_hist" : "BashHistoryCollector",
"processes" : "ProcessCollector",
"network_config" : "NetworkConfigCollector",
"profiles" : "ProfileCollector",
"certs" : "TrustedCertCollector"
},
"settings" : {
"keepLSData" : true,
"zipIt" : true
},
"moduleSettings" : {
"browser" : {
"collectArtifacts" : true
}
},
"unused" : {
"installs" : "InstallationCollector"
}
}
Dies gibt den Pfad an, in dem die gesammelten Daten gespeichert werden sollen. Es kann ein absoluter Pfad oder ein relativer Pfad zum Home-Ordner des Benutzers sein (indem er mit einer Tilde beginnt). Der Standardpfad, falls nicht angegeben, ist /Users/Shared.
Die Daten werden in einem an diesem Ort erstellten Ordner gesammelt. Dieser Ordner hat einen Namen der Form PICT-Computername-JJJJ-MM-TT, wobei der Computername der Name des Rechners ist, der unter Systemeinstellungen > Freigaben angegeben ist, und das Datum das Datum der Sammlung ist.
Bei true werden nach Möglichkeit Daten von allen Benutzern des Rechners gesammelt. Bei false werden nur Daten des Benutzers gesammelt, der das Skript ausführt. Wenn nicht angegeben, ist dieser Wert standardmäßig true.
PICT ist modular und kann leicht erweitert oder im Umfang reduziert werden, indem einfach geändert wird, welche Collector-Module verwendet werden.
Die collectors-Daten sind ein Wörterbuch, bei dem der Schlüssel der Name eines zu ladenden Moduls ist (der Name der Python-Datei ohne die Erweiterung .py) und der Wert der Name der in diesem Modul gefundenen Collector-Unterklasse ist. Sie können zusätzliche Einträge für benutzerdefinierte Module hinzufügen (siehe Eigene Module schreiben) oder Einträge entfernen, um die Ausführung dieser Module zu verhindern. Eine einfache Möglichkeit, Module zu entfernen, ohne später die genauen Namen nachschlagen zu müssen, falls Sie sie wieder hinzufügen möchten, besteht darin, sie in ein übergeordnetes Wörterbuch mit dem Namen unused zu verschieben.
Dieses Wörterbuch enthält globale Einstellungen.
keepLSData gibt an, ob die Datei lsregister.txt – die recht groß sein kann – behalten werden soll. (Diese Datei wird automatisch generiert und von einigen anderen Modulen zur Ausgabeerstellung verwendet. Sie enthält eine Fülle nützlicher Informationen, kann aber gut über 100 MB groß sein. Wenn Sie all diese Daten nicht benötigen oder nicht mit so vielen Daten umgehen möchten, setzen Sie dies auf false, und die Datei wird nach Abschluss der Sammlung gelöscht.)
zipIt gibt an, ob automatisch eine Zip-Datei mit dem Inhalt des Sammlungsordners erstellt werden soll. Beachten Sie, dass das Zip- und Unzip-Verfahren einige Attribute wie Dateieigentümer ändert.
Dieses Wörterbuch legt modulspezifische Einstellungen fest. Nicht alle Module haben eigene Einstellungen, aber wenn ein Module eigene Einstellungen zulässt, können Sie diese hier angeben. Im obigen Beispiel sehen Sie eine boolesche Einstellung namens collectArtifacts, die mit dem Modul browser verwendet wird.
Es gibt auch globale Moduleinstellungen, die von der Collector-Klasse verwaltet werden und für jedes Modul einzeln gesetzt werden können.
collectArtifacts gibt an, ob die Datei-Artefakte gesammelt werden sollen, die normalerweise vom Modul gesammelt werden. Bei false werden alle Artefakte für dieses Modul weggelassen. Dies kann erforderlich sein, wenn der Speicherplatz eine Rolle spielt und die gesammelten Artefakte groß sind, oder wenn die gesammelten Artefakte ein Datenschutzproblem für den Benutzer darstellen könsen, dessen System analysiert wird.
Module müssen aus einer Datei bestehen, die eine Klasse enthält, die von Collector abgeleitet ist (definiert in collectors/collector.py), und sie müssen im Ordner collectors abgelegt werden. Ein neues Collector-Modul kann einfach durch Duplizieren der Datei collectors/template.py und Anpassung an Ihre eigenen Bedürfnisse erstellt werden.
def __init__(self, collectionPath, allUsers)Diese Methode kann bei Bedarf überschrieben werden, aber in einem solchen Fall muss der super Collector.init() aufgerufen werden, vorzugsweise bevor Ihr benutzerdefinierter Code ausgeführt wird. Dies gibt dem Objekt die Möglichkeit, seine Eigenschaften einzurichten, bevor Ihr Code versucht, sie zu verwenden.
def printStartInfo(self)Dies ist eine sehr einfache Methode, die aufgerufen wird, wenn die Sammlung dieses Moduls beginnt. Ihr Zweck ist es, eine Nachricht an stdout auszugeben, um dem Benutzer ein Gefühl für den Fortschritt zu geben, indem Rückmeldung darüber gegeben wird, was gerade passiert.
def applySettings(self, settingsDict)Dies gibt dem Modul die Möglichkeit, benutzerdefinierte Einstellungen anzuwenden. Jedes Modul kann seine eigenen selbstdefinierten Einstellungen haben, aber das settingsDict sollte auch an die übergeordnete Klasse übergeben werden, damit die Collection-Klasse alle von ihr definierten Einstellungen verarbeiten kann.
def collect(self)Diese Methode ist der Kern des Moduls. Sie wird aufgerufen, wenn das Modul mit der Sammlung beginnen soll. Es kann so viele Dateien schreiben, wie nötig, sollte diese Aktivität jedoch auf Dateien innerhalb des Pfades self.collectionPath beschränken und Dateinamen verwenden, die nicht bereits von anderen Modulen belegt sind.
Wenn Sie Artefakte sammeln möchten, versuchen Sie nicht, dies selbst zu tun. Fügen Sie einfach Pfade zum Array self.pathsToCollect hinzu, und die Collector-Klasse kümmert sich darum, diese in die entsprechenden Unterpfade im Ordner artifacts zu kopieren und die Metadaten (Berechtigungen, erweiterte Attribute, Flags usw.) der Artefakte zu erhalten.
Wenn die Methode beendet ist, rufen Sie unbedingt die übergeordnete Methode (Collector.collect(self)) auf, damit die Collector-Klasse ihre Aufgaben erledigen kann, z. B. das Sammeln von Artefakten.
Ihre collect-Methode kann alle Daten verwenden, die in den Dateien basic_info.txt oder lsregister.txt unter self.collectionPath gesammelt wurden. Diese werden zu Beginn vom Skript pict.py gesammelt und sollten für andere Module als verfügbar gelten. Sie sollten sich jedoch nicht auf die Ausgabe anderer Module verlassen, da nicht garantiert ist, dass die Dateien verfügbar sind, wenn Ihr Modul läuft. Module werden möglicherweise nicht in der Reihenfolge ausgeführt, in der sie in Ihrer Konfigurations-JSON erscheinen, da Python-Wörterbücher ungeordnet sind.
Dank an Greg Neagle für FoundationPlist.py, das viele Probleme beim Lesen von binären Plists, Plists mit Datumsdatentypen usw. gelöst hat.