Inhalt
Moderne EDR- bzw. XDR-Lösungen sind in der Lage, verdächtiges Verhalten zu detektieren. Die viel verbreitete Lösung Elastic integriert dieses Feature mit Elastic Defend seit 2019 und bietet eine in der Branche führende Transparenz. Im Folgenden zeigen wir, wie Security-Experten damit arbeiten. Zunächst ein paar allgemeine Informationen:
Endpoint Detection and Response
Endpoint Detection and Response Systeme (EDR) sind ein zentraler Bestandteil umfassender IT-Sicherheitskonzepte. Als Weiterentwicklung klassischer Antivirenprogramme überwachen sie kontinuierlich das Verhalten von Endpunkten und suchen nach Anzeichen für potenzielle Sicherheitsverletzungen oder Angriffe. Die Funktion eines EDR-Systems ist auch in den noch umfassenderen XDR-Systemen (eXtended Detection and Response) enthalten, die zusätzlich den Netzwerkverkehr bedrohungsorientiert analysieren. Managed Detection and Response (MDR) Systeme verfügen über die gleichen Funktionen wie EDR und XDR, bieten aber rund um die Uhr gemanagte Dienste zur Überwachung von Endgeräten sowie zur Beseitigung und Behebung von Bedrohungen.
Transparenz durch Open Source-Ansatz
Die Detection and Response Lösung Elastic Security wurde mit der Übernahme von Endgame im Jahr 2019 zu einer umfassenden Produktfamilie ausgebaut. Eine Besonderheit ist, dass der in der Open-Source-Bewegung verwurzelte Anbieter Elastic kurz darauf die entsprechenden Detektion-Regeln seiner EDR-Lösung Elastic Defend auf Github publiziert hat. Zuvor hatte das Unternehmen bereits seine SIEM-Detektionsregeln veröffentlicht.
Mit Ausnahme von Maschine Learning Komponenten finden sich im protections-artifacts Repo alle Erkennungslogiken für die Betriebssysteme Windows, Linux und macOS. Diese Transparenz ist in der IT-Security-Branche selten und mag auf den ersten Blick befremdlich wirken. Gemäß des Sicherheitsgedankens von Open-Source-Software ist diese Vorgehensweise jedoch sehr sinnvoll, da sie viele Vorteile mit sich bringt:
- Besseres Verständnis der Funktionsweise
- Erkennung von Lücken in Detektionsregeln
- Möglichkeit der Mitarbeit und des Austauschs
- Qualitätssicherung durch das Mehraugenprinzip
Herausfiltern verdächtiger Prozesse
Innerhalb der IT-Security Community sorgten Elastics Veröffentlichungen von Detektionsregeln wiederholt für positives Feedback, wie zuletzt bezüglich der Call Stack Telemetrie aus dem Microsoft-Windows-Threat-Intelligence Event Tracing for Windows (Ti-ETW). Zur Erklärung: Call-Stacks (Abrufstapel) sind sowohl für die technische Erkennung als auch für die Suche nach Bedrohungen sehr hilfreich, da sie viel Kontext zu den Aktivitäten eines Prozesses liefern. Dies ist wertvoll, da der Call-Stack – einfach formuliert – den logischen Ablauf aller von einen Programm aus der Microsoft API importieren und aufgerufenen Funktionen auflistet.
Transparenz und Eigenbetrieb
Mit der Entscheidung zur Veröffentlichung seiner Detektionslogiken stellt sich Elastic stellt sich bewusst gegen einen negativen Trend. Abgesehen von OpenEDR ist kein anderer EDR-Anbieter dazu bereit. Alle anderen Hersteller verweisen stattdessen bestenfalls auf abstrakte Metriken wie MITRE ATT&CK, die keine zuverlässige, qualitative Einordnung ermöglichen. Diese bequeme Politik kann für die Kunden mittelfristig problematisch werden. So verlangt etwa die BaFin im SIEM-Umfeld bereits seit langem von Banken & Versicherungen Transparenz bezüglich der Funktionsweise von Use Cases. Es ist nicht unwahrscheinlich, dass die Aufsichtsbehörde langfristig auch bei EDR-Systemen mehr Transparenz einfordert.
Darüber hinaus punktet Elastic aber auch beim Cloud-Zwang mit Wahlfreiheit und einem hohen Datenschutz, der unter dem Aspekt der Vertraulichkeit äußerst relevant ist und nicht zuletzt in Deutschland im Fokus steht. Denn es darf nicht vergessen werden, dass US-Konzerne verpflichtet sind, in ihrer Cloud gespeicherte Daten auf Zuruf an die eigenen Behörden durchzureichen, selbst wenn die Daten in einem EU-basierten Rechenzentrum gespeichert sind.
Detektionslogik
Die von Elastic veröffentlichten Erkennungslogiken lassen sich in folgende Kategorien unterteilen:
- YARA-Signaturen basierte Erkennung für Dateien und Arbeitsspeicher
- Verhaltenbasierte Detektion in Form von EQL, KQL oder ES|QL
- Ransomware Erkennung
Verhaltensbasierte Erkennung in Elastic Defend
Durch Korrelation von Dateioperationen, Netzwerkdaten, Speicherzugriffe und Systemereignissen wird bösartiges Verhalten erkannt und verhindert. Beispiele hierfür sind unter anderen:
- Ausführung von unbekannten oder verdächtigen Prozessen
- Verdächtige Dateiaktivitäten
- Ungewöhnliche Netzwerkaktivitäten
- Abnormale Benutzerverhaltensmuster
- Verdächtige Systemkonfigurationsänderungen
- Datei- und Ordnerzugriffsänderungen
- Ausführung von privilegierten Aktionen durch nicht autorisierte Benutzer
Die folgenden Beispiele zeigen, wie die verhaltensbasierte Erkennung in Elastic Defend umgesetzt wird:
Beispiel 1:
OS Credential Dumping: LSASS Memory (ID: T1003.001)
Beim so genannten „LSASS Memory Dumping“ wird auf den Arbeitsspeicher des LSASS-Prozesses (Local Security Authority Subsystem Service) zugegriffen, um sensible Informationen wie Anmeldeinformationen, Kennwörter oder Token zu extrahieren. Diese Informationen können dann vom Angreifer verwendet werden, um sich Zugang zu privilegierten Konten zu verschaffen oder später auf das System zuzugreifen.
Das erzeugte Dump File:
Der erzeugte Alarm in Elastic Defend:
Die entsprechende Regel aus der Elastic Repository:
In diesem Beispiel wird folgendes Verhalten erkannt:
- Aufruf der Windows API Calls OpenProcess bzw. OpenThread
- Ziel Prozess ist lsass.exe
- Der ausführende Prozess importiert die Funktion MiniDumpWriteDump aus den System- Bibliotheken dbgcore.dll oder comsvcs.dll
Beispiel 2:
In diesem Beispiel sehen wir die Ausführung von meterpreter shellcode in einen neugestarteten Prozess (calc.exe). Meterpreter ist ein Bestandteil des Metasploit Framework und neben Cobalt Strike eines der am häufigsten benutzen C2 Frameworks[1].
Ein Blick auf die Regel “Potential Injection via Asynchronous Procedure Call”:
[1] Quellen:
Meterpreter, a key component of the Metasploit framework, is one of the few highly-prevalent malware families we see impact Windows, Linux, and macOS. (Elastic Global Threat Report 2023)
Adversaries have long used open source and leaked versions of commercial frameworks, most notably Metasploit and Cobalt Strike. (Red Canary 2023 Threat Detection Report)
Diese Regel erkennt den Aufruf der Funktion QueueUserAPC
APC Queue
Wenn sich ein Process in eine Art wartenden oder schlafenden Zustand befindet, wird dieser als „alertable state“ bezeichnet. Weitere Anweisungen werden dann in eine sogenannte APC Queue geschrieben. Der Windows Kernel arbeitet diese Anweisungen ab, bis der Prozess den „alertable state“ verlässt. Der Ablauf der Code Injection ist wie folgt:
1. Neuen Prozess starten (calc.exe – Suspended)
2. Speicher im neuen Prozess zuweisen
3. Meterpreter Shellcode in den Speicher schreiben
4. Speicherbereich ausführbar machen
5. Einfügen des Codes in die APC Queue und starten des Prozesses:
Ergebnis
Die erfolgreiche Code Injection via APC Queue führt zu einer Meterpreter Session:
Die erfolgreiche Erkennung und Alarmierung in Elastic Defend:
Fazit
Wie diese Beispiele zeigen, ist die verhaltensbasierte Erkennung mit Elastic Defend ein mächtiges, aber einfach zu bedienendes Werkzeug, das bis auf die Ebene einzelner Funktionsaufrufe im Call-Stack reicht und sogar moderne Obfuskationsmethoden wie Threadless Injection oder PoolParty Incection umfasst.
Sie möchten Cyber-Angriffe umfassend erkennen, analysieren und abwehren, ohne in einer Flut von Alarmen unterzugehen? Entdecken sie jetzt die cloud-freie MDR-Lösung von SECUINFRA:
Weiterführende Links
https://www.elastic.co/security-labs/doubling-down-etw-callstacks
