Präambel
In unserem ersten Beitrag in unserer Detonate-Serie haben wir das Detonate-System vorgestellt und wofür wir es bei Elastic verwenden. Wir haben auch die Vorteile erörtert, die es unserem Team bietet, wenn wir die Leistung unserer Sicherheitsartefakte bewerten.
In dieser Veröffentlichung werden wir die Funktionsweise von Detonate aufschlüsseln und tiefer in die technische Implementierung eintauchen. Dazu gehört, wie wir in der Lage sind, diese Sandkastenumgebung in der Praxis zu erstellen, die Technologie, die die gesamte Pipeline unterstützt, und wie wir Informationen an die Pipeline übermitteln und Informationen aus der Pipeline lesen.
Interessiert an anderen Beiträgen zu Detonate? Schauen Sie sich Teil 1 an - Klick, Klick... Dröhnen! Hier stellen wir Detonate vor, warum wir es entwickelt haben, untersuchen, wie Detonate funktioniert, beschreiben Fallstudien und diskutieren Wirksamkeitstests.
Architektur
Im Folgenden finden Sie einen allgemeinen Überblick über die End-to-End-Architektur von Detonate.
Das Gesamtsystem besteht aus einer Reihe von Nachrichtenwarteschlangen und Python-Workern. Detonationsaufgaben werden von einem API-Server erstellt, wenn eine Anforderung mit so wenigen Informationen wie dem Hash der Beispieldatei akzeptiert wird. Die Aufgabe wird dann von Warteschlange zu Warteschlange verschoben und von Workern übernommen, die auf dem Weg verschiedene Vorgänge ausführen.
Der Server und die Worker werden in einem Container auf Amazon ECS ausgeführt. Die Pipeline kann auch lokal mit Docker Compose für die frühe Entwicklung und Funktionstests bereitgestellt werden.
API-Server
Der Detonate API-Server ist eine FastAPI-Python-Anwendung , die eine Vielzahl von Ausführungszielanforderungen akzeptiert: Hashes von Beispielen, native Befehle (in bash oder Powershell, mit oder ohne Argumente) und hochgeladene Dateien. Der Server stellt auch Endpunkte zum Abrufen von Warnungen und unformatierten Agent-Telemetriedaten von einem Elastic-Cluster zur Verfügung.
Die API-Dokumentation wird automatisch von FastAPI generiert und in unser globales API-Schema integriert.
Interagieren mit dem API-Server – CLI
Wir haben ein benutzerdefiniertes Python-CLI-Tool (Befehlszeilenschnittstelle) für die Interaktion mit unserem Detonate-Server entwickelt. Das CLI-Tool wurde mit der Python-Bibliothek click along with rich erstellt, um eine ansprechende Formatierung in einem Terminalfenster zu ermöglichen. Das Tool ist besonders nützlich für das Debuggen der Pipeline, da es auch für ein lokales Pipelinesetup ausgeführt werden kann. Das Tool wird mit Poetry installiert und ausgeführt, unserem bevorzugten Tool der Wahl zum Verwalten von Abhängigkeiten und Ausführen von Skripten.
❯ DETONATE_CLI_API_ROOT_URL="${API_ENDPOINT_URL}" \
DETONATE_CLI_API_AUTH_HEADER="${API_KEY}" \
poetry run cli \
--hash "${MY_FILE_HASH}"Interagieren mit dem API-Server – Web-Benutzeroberfläche
Intern hosten wir eine Website namens Protections Portal (geschrieben mit Elastic UI-Komponenten ), um unser Team bei der Recherche zu unterstützen. Für ein interaktiveres Erlebnis mit der Detonate-API haben wir eine Seite im Portal erstellt, auf der Sie mit ihr interagieren können. Neben dem Übermitteln von Aufgaben können Benutzer über die Webbenutzeroberfläche den Feed aller Detonationen und die Details jeder Aufgabe anzeigen.
Jede Aufgabe kann erweitert werden, um alle Details anzuzeigen. Wir stellen die Links zu den Daten und Telemetriedaten zur Verfügung, die während der Detonation gesammelt wurden.
Interagieren mit dem API-Server - HTTP-Client
Wenn unsere Benutzer anpassen möchten, wie sie mit der Detonate-API interagieren, können sie auch Befehle mit dem HTTP-Client ihrer Wahl ausführen (z. B. curl , httpie usw.). Dies ermöglicht es ihnen, Detonationen zu Skripten oder als letzte Schritte am Ende ihrer eigenen Arbeitsabläufe hinzuzufügen.
Queues
Die Pipeline basiert auf einer Reihe von Warteschlangen und Workern. Da wir sehr grundlegende Anforderungen an die Nachrichtenwarteschlangen-Engine hatten, haben wir uns für Amazon SQS entschieden. Einer der vielen Vorteile der Nutzung eines beliebten Dienstes wie SQS ist die Verfügbarkeit von Open-Source-Ressourcen und -Bibliotheken, auf denen wir aufbauen können. Zum Beispiel verwenden wir docker-Images von softwaremill/elasticmq als Warteschlangen-Engine, wenn wir die Pipeline lokal ausführen.
Die Warteschlangen werden mit Terraform-Code konfiguriert und bereitgestellt, der unsere gesamte Produktions- und Staging-Infrastruktur abdeckt.
Arbeiter
Jeder Worker ist ein Python-Skript, das sowohl als Warteschlangenkonsument als auch als Warteschlangenproduzent fungiert. Die Worker werden in unserem benutzerdefinierten Mini-Framework implementiert, wobei der Boilerplate-Code für Fehlerbehandlung, Wiederholungen und Überwachung integriert ist. Unser Basis-Worker lässt sich leicht erweitern, so dass wir neue Mitarbeiter hinzufügen und bestehende weiterentwickeln können, wenn zusätzliche Anforderungen auftreten.
Für die Überwachung verwenden wir die Observability-Lösung Elastic APM . Es ist unglaublich leistungsstark, gibt uns einen Einblick in den Ausführungsablauf und macht das Debuggen von Pipeline-Problemen zum Kinderspiel. Unten sehen wir, wie sich eine Detonate-Aufgabe zwischen Workern in der APM-Benutzeroberfläche bewegt:
Diese Software- und Infrastrukturkomponenten bieten uns alles, was wir brauchen, um die Übermittlung, Ausführung und Datenerfassung durchzuführen, die eine Detonation ausmachen.
Detonationen
Die Pipeline kann Befehle und Beispiele auf virtuellen Windows-, Linux- und macOS-Computern (VMs) ausführen. Für Windows- und Linux-Umgebungen verwenden wir VM-Instanzen in Google Compute Engine. Mit der großen Auswahl an öffentlichen Images ermöglicht es uns, Sandbox-Umgebungen mit verschiedenen Versionen von Windows, Debian, Ubuntu, CentOS und RHEL bereitzustellen.
Für macOS-Umgebungen verwenden wir mac1.metal-Instanzen in AWS und eine On-Demand-macOS-VM-Bereitstellungslösung von Veertu namens Anka. Anka gibt uns die Möglichkeit, mehrere macOS-VMs, die auf derselben macOS-Bare-Metal-Instanz ausgeführt werden, schnell zu rotieren.
Detonate konzentriert sich derzeit auf die Breite unserer Betriebssystemabdeckung, die Skalierbarkeit und die Sammlung kontextuell relevanter Daten aus der Pipeline. Der Einbau ausgeklügelter Anti-Analyse-Gegenmaßnahmen in Detonate wird derzeit erforscht und entwickelt.
VM-Bereitstellung
Um unseren Fußabdruck in der VM so gering wie möglich zu halten, verwenden wir Startskripte für die Bereitstellung. Die Minimierung unseres Speicherbedarfs ist wichtig, da unsere Aktivitäten innerhalb eines virtuellen Computers in den von uns erfassten Ereignissen enthalten sind, was die Analyse nach einer Ausführung komplizierter macht. Für Windows- und Linux-VMs werden GCP-Startskripts , die in PowerShell und bash geschrieben wurden, verwendet, um das System zu konfigurieren. Für macOS-VMs haben wir benutzerdefinierte Bash- und AppleScript-Skripts geschrieben.
Die Startskripts führen die folgenden Schritte aus:
- Konfigurieren Sie das System. Deaktivieren Sie beispielsweise MS Defender, aktivieren Sie die Ausführung von Makros in MS Office, deaktivieren Sie automatische Systemupdates usw.
- Laden Sie den Elastic-Agent herunter und installieren Sie ihn. Das Skript überprüft, ob der Agent ordnungsgemäß beim Flottenserver registriert ist und ob die Richtlinien angewendet werden.
- Laden Sie ein Sample herunter und zünden Sie es oder führen Sie eine Reihe von Befehlen aus. Die Ausführung erfolgt in einem Hintergrundprozess, während das Hauptskript die STDOUT/STDERR-Datenströme sammelt und N Sekunden lang in den Ruhezustand versetzt wird.
- Sammeln Sie Dateien aus dem Dateisystem (falls erforderlich) und laden Sie sie in den Speicher hoch. Dies ermöglicht es uns, zusätzliche Überprüfungen oder Fehlerbehebungen durchzuführen, sobald die Detonation abgeschlossen ist.
Der VM-Lebenszyklus wird von den start_vm und stop_vm Workern verwaltet. Da wir davon ausgehen, dass einige Detonationen den Ausführungsablauf des Startskripts unterbrechen (z. B. im Fall von Ransomware), hat jede VM einen TTL-Satz, der es dem stop_vm Worker ermöglicht, nicht mehr verwendete VMs zu löschen.
Dieser Clean-Slate-Ansatz, bei dem das Startskript verwendet wird, um alles zu konfigurieren, was für eine Detonation benötigt wird, ermöglicht es uns, VM-Images von den Anbietern aus dem öffentlichen Image-Katalog von Google Cloud ohne Änderungen zu verwenden!
Netzwerkkonfiguration
Einige der Samples, die wir detonieren, sind bösartig und können bösartigen Datenverkehr erzeugen, z. B. Netzwerkscans, C2-Callouts usw. Um unsere Cloud-Ressourcen und die Infrastruktur unseres Anbieters sicher zu halten, begrenzen wir den gesamten ausgehenden Datenverkehr von VMs. Die Instances werden in einer gesperrten VPC platziert, die ausgehende Verbindungen nur zu einer vordefinierten Liste von Zielen zulässt. Wir beschränken den Datenverkehrsfluss in VPC mithilfe der Routen und Firewall-Regeln von Google Cloud sowie der Sicherheitsgruppen von AWS.
Wir verwenden auch VPC-Flow-Protokolle in GCE. Diese Protokolle ermöglichen es uns, den privaten Netzwerkverkehr zu sehen, der von Sandbox-VMs in unserer VPC initiiert wurde.
Sammlung von Telemetriedaten
Um Detonationen zu beobachten, verwenden wir den Elastic Agent mit der Elastic Defend-Integration , die mit allen Schutzmaßnahmen im Modus "Erkennen" (anstelle von "Schützen") installiert ist. Auf diese Weise können wir so viele Informationen wie möglich von einer VM sammeln, während die Elastic Security-Lösung gleichzeitig Warnungen und Erkennungen erstellen kann.
Mit dieser Architektur decken wir zwei Anwendungsfälle ab: Wir können Schutzmaßnahmen validieren (durch Vergleichen von Ereignissen und Warnungen, die für verschiedene Betriebssystemversionen, Agent-Versionen, bereitgestellte Sicherheitsartefakte usw. erstellt wurden) und gleichzeitig Telemetriedaten für die Analyse (für neue Samples oder neuartige Malware) sammeln. Alle gesammelten Daten werden in einem persistenten Elastic-Cluster gespeichert und stehen unseren Forschern zur Verfügung.
Läuft in der Produktion
Vor kurzem haben wir einen ganzen Monat lang die Detonate-Pipeline in der Produktion laufen lassen, unter der Last mehrerer Datenintegrationen, die interne Benutzer gleichzeitig über die Benutzeroberfläche bedienen. Bisher haben wir 1034 Detonationen an einem einzigen Tag verzeichnet, und bisher haben wir keine Probleme mit der Skalierbarkeit oder Zuverlässigkeit festgestellt.
Der Großteil der Einreichungen sind vorerst Windows-spezifische Beispiele. Wir arbeiten daran, unsere Abdeckung auch über Linux und macOS zu erweitern – bleiben Sie dran für die Forschungsblog-Posts, die bald erscheinen!
Wir verbessern ständig unsere Unterstützung für verschiedene Dateitypen, um sicherzustellen, dass die Detonation so nah wie möglich am beabsichtigten Auslöseverhalten liegt.
Wenn wir uns die Detonationen des letzten Monats ansehen, sehen wir, dass die meisten Aufgaben in weniger als 13 Minuten erledigt wurden (mit einem Median von 515 Sekunden). Diese Zeit umfasst die Vorbereitung von Aufgabendaten, die Bereitstellung und Bereinigung von VMs, die Ausführung von Proben und die Verarbeitung nach der Detonation.
Dies sind noch die Anfänge des Dienstes, daher ist es normal, Ausreißer zu sehen. Da die meiste Zeit in einer Aufgabe damit verbracht wird, auf die Bereitstellung einer VM zu warten, können wir die Gesamtausführungszeit verbessern, indem wir benutzerdefinierte VM-Images verwenden, VM-Instanzen vorab starten und die Startskripts optimieren.
Wie geht es weiter?
Nachdem Sie nun gesehen haben, wie Detonate funktioniert, werden wir in unseren nächsten Beiträgen in detailliertere Anwendungsfälle von Detonate eintauchen. Wir werden weiter darauf eingehen, wie diese Detonationen dazu führen, dass mehr unserer Benutzer geschützt werden, auch hier bei Elastic!