Einführung
Im ersten Teil dieser Blogserie mit Schwerpunkt CTI haben wir den Intelligence Production Cycle vorgestellt und eine funktionale und technische Architektur für eine Cyber-Threat-Intelligence-Plattform vorgeschlagen, die sowohl in die SOC- als auch in die Incident-Response-Aktivitäten integriert ist und diese unterstützt.
In diesem zweiten Teil geht es darum, wie Cyber Threat Intelligence die Aktivitäten des SOC zur Bedrohungsjagd und -erkennung durch gezielte Threat Actor Intelligence unterstützen kann.
Zur Erinnerung: Cyber Threat Intelligence
Wie wir bereits gesehen haben, kann der Prozess zur Erstellung von Threat Intelligence in 5 Schritten dargestellt werden:
- Planung & Ausrichtung: Erarbeitung der Informationsanforderungen
- Sammlung: Sammeln von Rohdaten
- Verarbeitung & Verwertung: Synthese und Standardisierung von Rohdaten
- Analyse & Produktion: Informationsproduktion aus standardisierten Daten
- Verbreitung: Übermittlung der gewonnenen Informationen
Threat Hunting & Detection Engineering
Threat Hunting und Detection Engineering können beide als entscheidende Aktivitäten im modernen SOC-Betrieb angesehen werden. Obwohl ihre Bedeutung weithin anerkannt ist, überschneiden sich die damit verbundenen Definitionen und die damit verbundenen Aktivitäten häufig. Die Definitionen von Kostas in seinem Artikel „Threat Hunting Series: Detection Engineering VS Threat Hunting“ verdeutlicht den Unterschied zwischen diesen beiden Konzepten:
Threat Hunting ist eine proaktive Praxis der Suche nach Beweisen für feindliche Aktivitäten, die von herkömmlichen Sicherheitssystemen möglicherweise übersehen werden. Dabei wird aktiv nach Anzeichen für bösartiges Verhalten und Anomalien in einem Netzwerk oder einzelnen Hosts gesucht. Detection Engineering hingegen ist der Prozess der Entwicklung und Pflege von Erkennungsmethoden, um bösartige Aktivitäten zu identifizieren, nachdem sie bekannt geworden sind.
In diesem Blogbeitrag werden wir versuchen, einen Einblick zu geben, wie wir unseren Intelligence-Production-Prozess konzipiert haben, um sowohl die Threat-Hunting- als auch die Detection-Engineering-Aktivitäten innerhalb der SOC-Operationen zu unterstützen und auszurichten.
Identifizierung von Bedrohungsakteuren und Extraktion relevanter TTPs
Planung & Ausrichtung: Identifizierung der Bedrohungsakteure, auf die man sich konzentrieren sollte
Die Identifizierung der Bedrohungsakteure, auf die man sich konzentrieren sollte, ist der Schlüssel zur Bereitstellung wertvoller und umsetzbarer Informationen für SOC- und IR-Operationen. Angesichts begrenzter Ressourcen ist es offensichtlich, dass das CTI-Team nicht in der Lage ist, detaillierte Analysen für alle derzeit aktiven Threat Actors (TA) zu erstellen.
Um sich zu orientieren und die verschiedenen TAs zu priorisieren, kann man beschließen, verschiedene frei nutzbare CTIPs zu verwenden, die strategische CTI in Verbindung mit einem bestimmten TA bereitstellen, wie z. B.:
Hinweis: Wenn Sie über ein eigenes CTIP verfügen, werden Sie Ihre Analyse natürlich auf das stützen, was Sie bereits wissen; es kann jedoch immer nützlich sein, Querverweise zu ziehen und mit mehreren Quellen zu analysieren.
Anhand von Informationen wie Viktimologie (Zielsektoren und -länder), Ausgereiftheit, Häufigkeit der Aktivitäten, … können Sie hier eine Unterliste interessanter Gruppen ermitteln, die für Ihr Unternehmen relevante Bedrohungen darstellen. Sie können sich auch auf vertrauenswürdige Partner, z. B. nationale Behörden, verlassen, um weitere Erkenntnisse zu gewinnen und möglicherweise bestimmte Bedrohungsakteure zu identifizieren.
Jetzt haben Sie ein klares und leicht zu präsentierendes Dokument, das Ihre Entscheidung, an bestimmten Bedrohungen zu arbeiten, untermauert; machen wir uns an die bibliothekarische Arbeit: die Literaturliste jedes TAs.
Sammlung: TA-spezifische Literatur
Wie Sie vielleicht schon erraten haben, geht es in dieser Phase darum, alle verfügbaren Ressourcen aufzulisten, entweder offizielle Veröffentlichungen und Artikel oder interne IR-Berichte, SOC-Ermittlungen oder TLP RED, die Sie über einen bestimmten Gegner haben.
Hier gibt es nicht viel zu erläutern, aber es ist wichtig, einen bestimmten Zeitrahmen für die Erstellung des Backlogs zu wählen und sich darauf zu konzentrieren (d. h. wo man in der Zeit zurückgehen sollte): Wenn ein Angreifer seit mehr als einem Jahrzehnt existiert, sind ältere Artikel möglicherweise veraltet, da sich Methoden und Angriffsmuster ständig weiterentwickeln. Es hilft auch, sich nicht von der schieren Menge der verfügbaren Informationen überfluten zu lassen.
Für unsere erste Iteration dieses Prozesses beschlossen wir, mit einem zweijährigen Rückstand zu beginnen, da wir uns auf gut dokumentierte und aktive Angreifer konzentrierten und unsere Aktivitäten entwickeln wollten.
Verarbeitung & Analyse: TTP-Extraktion und Identifizierung von Jagdmöglichkeiten
Nachdem Sie nun alle Ressourcen, die mit Ihrem Gegner in Verbindung stehen, definiert und aufgelistet haben, müssen Sie sich an die Arbeit machen. Bei dieser TTP-Extraktion handelt es sich nicht um eine „einfache“ MITRE ATT&CK-Zuordnung von hervorgehobenen (oder bereits markierten) Techniken in den betreffenden technischen Artikeln. Stattdessen müssen Sie in die Tiefe gehen, verstehen, welche Technik der Gegner verwendet hat und wie sie implementiert wurde, und sich gleichzeitig fragen, wie man nach einem solchen Verhalten suchen (d. h. gesammelte Daten abfragen) könnte.
Dazu ist es oft notwendig, einen Artikel mehrmals zu lesen, sich auf die zur Verfügung gestellten Ressourcen wie technische Screenshots zu konzentrieren und auf externe Quellen zurückzugreifen, um zu verstehen, was dargestellt wird.
Auf diese Weise werden Sie in der Lage sein, ein gutes, auf die Jagd ausgerichtetes TTP-Inventar in Bezug auf Ihren Gegner zu erstellen; vorzugsweise in einem standardisierten Format.
Werfen wir einen Blick auf ein reales Beispiel: den Artikel von Volexity über Charming Kitten, der im Juni 2023 veröffentlicht wurde. Dieser Artikel bietet sowohl einen klaren Überblick über die aktuellen Aktivitäten von Charming Kitten als auch eine eingehende Analyse ihrer Backdoor mit dem Namen POWERSTAR. Im Abschnitt „Backdoor-Analyse“ wird Folgendes erwähnt:
Interessanterweise wurden in der ursprünglichen Konfiguration zwar ein AES-Schlüssel und ein IV festgelegt, Volexity beobachtete jedoch, dass der C2 den Schlüssel nach dem ersten Beacon-Traffic dynamisch aktualisierte. Darüber hinaus setzt POWERSTAR den IV auf einen Zufallswert und übergibt diesen dann über den „Content-DPR“-Header jeder Anfrage an den C2. In früheren Versionen von POWERSTAR wurde anstelle von AES eine benutzerdefinierte Chiffre zur Verschlüsselung der Daten während der Übertragung verwendet. Die Verwendung von AES könnte als Verbesserung der Funktionsweise der Malware gegenüber früheren Versionen angesehen werden.
Auf den ersten Blick könnte man die Änderung des Verschlüsselungsmechanismus in POWERSTAR bemerken und dieses neue TTP wie folgt extrahieren:
Das ist großartig, aber gibt es hier noch mehr zu extrahieren? Möglicherweise müssen wir uns einige zusätzliche Fragen stellen.
Schauen wir uns das noch einmal an. In dem Artikel heißt es: „POWERSTAR setzt den IV-Wert auf einen Zufallswert und gibt ihn dann über den „Content-DPR“-Header jeder Anfrage an C2 weiter„.
→ Ist diese Implementierung spezifisch für POWERSTAR C2-Aktivitäten?
→ Was ist der Content-DPR-Header?
→ Wird es häufig verwendet?
→ Was ist normalerweise darin gespeichert?
Laut der Mozilla-Entwicklerdokumentation ist dieser Header veraltet und wird üblicherweise verwendet, um „das Verhältnis von Bildgerät zu Pixel in Anfragen zu bestätigen, bei denen der Screen-DPR-Client-Hinweis zur Auswahl einer Bildressource verwendet wurde„. Übliche Werte scheinen Zahlen zwischen 0 und 100 zu sein.
POWERSTAR speichert AES-Initial-Vector-Werte in diesem Header, der ein 128-Bit-Array ist, also ein längerer und recht ungewöhnlicher Wert, der in diesem Header zu finden ist.
→ Ist er für die Jagd oder die Erkennung relevant?
→ Welche Daten sind erforderlich, um ein solches Verhalten zu erkennen?
→ Wird erwartet, dass diese Art von Verhalten sehr ausführlich ist?
Der Wert des Inhalts sollte hier ungewöhnlich sein, was durch Paketanalyse oder besonders ausführliche Web-Traffic-Inspektionsprotokolle ermittelt werden kann. In der Dokumentation heißt es außerdem, dass bei normaler Verwendung von DPR „ein Server sich zunächst für den Empfang des DPR-Headers entscheiden muss, indem er den Antwort-Header Accept-CH sendet, der die Direktive DPR enthält„; man könnte auch nach einem unaufgeforderten Content-DPR-Header in der oben erwähnten Telemetrie suchen, da das Vorhandensein des Accept-CH-Headers in dem Artikel nicht erwähnt wird.
Da dieser Header außerdem als veraltet gekennzeichnet ist, könnte seine einfache Verwendung ein Hinweis sein. Diese Hypothese ist ein Glücksspiel und daher für den Betrieb gefährlich. Es sollte eine statistische Analyse in der Produktionsumgebung durchgeführt werden, um diese Hypothese zu bewerten und möglicherweise zu verwerfen.
Auf jeden Fall ergibt sich daraus nun die folgende TTP-Extraktion:
| TA name |
Source |
Tactic |
Technique |
Details |
Hunting opportunities |
Required telemetry |
Comment / Warning |
| Charming Kitten |
https://www.volexity.com/blog/2023/06/28/charming-kitten-updates-powerstar-with-an-interplanetary-twist/ |
TA0011 Command and Control |
Encrypted Channel: Symmetric Cryptography |
POWERSTAR update now relies on AES cipher rather than custom cipher. |
Abnormal values in “Content-DPR” header
Unsolicited “Content-DPR” header in client response |
SSL – interception with according HTTP header extraction |
Requires specific sensors and configurations.
Possibly resource consuming hunt:’) |
Dieses Beispiel veranschaulicht natürlich, wie wir versucht haben, TPP und insbesondere Jagd-/Erkennungsmöglichkeiten innerhalb von CTI-Artikeln zu extrahieren. Das Erkennen von Jagd- und Erkennungsmöglichkeiten ist eine komplizierte und subjektive Aufgabe;
Möglicherweise sind Sie mit dem, was wir gerade extrahiert haben, nicht einverstanden. Es ging darum, die verschiedenen Fragen hervorzuheben, die wir uns gestellt haben, und welche zusätzlichen Informationen wir zusammen mit den „Standard“-TTPs zu extrahieren versuchten.
Verbreitung: Mind Map & Hunting Use Cases
In diesem letzten Teil geht es um die Formatierung und Zusammenfassung dessen, was Sie gerade produziert haben. Sie können zum Beispiel eine synthetisierte Mind Map erstellen, um einen handlungsfähigen Überblick über TTPs und Jagdmöglichkeiten für einen bestimmten Bedrohungsakteur zu schaffen:
Sie können dieses Wissen auch in Ihren CTIP aufnehmen und formatieren, wenn Sie einen solchen haben. Denken Sie jedoch daran, dass die Anpassung an das Format, das für Ihre Informationsanforderungen erforderlich ist, einige Anpassungen und Kompromisse erfordern kann.
Operative Einblicke – aus MSSP-Perspektive
Bevor wir uns damit befassen, wie die zuvor beschriebenen Erkenntnisse genutzt werden können, wollen wir einige operative Schwierigkeiten erörtern, mit denen wir konfrontiert waren.
Aus der MSSP-Perspektive war es leichter gesagt als getan, die zu priorisierenden Bedrohungsakteure zu identifizieren. Die Vielfalt der Kunden und deren Tätigkeitsbereiche, geografische Lage usw. machten es recht schwierig, eine begrenzte Liste von Bedrohungsakteuren zu erstellen, die unsere Kunden ins Visier nehmen könnten. Wir haben das ThreatBox-Modell verwendet und einige „Archetypen“ unserer Kunden miteinander verglichen, jedoch mit wenig Erfolg. Daher beschlossen wir, zunächst mehrere aktive und bereits aufgetretene Bedrohungen auszuwählen und mit der Entwicklung dieser Aktivität fortzufahren. Es ist wichtig zu erwähnen, dass wir davon ausgehen, dass das ThreatBox-Modell für interne SOC/CERT-Aktivitäten weitaus relevanter ist als in unserem Fall.
Da wir zu diesem Zeitpunkt nicht über einen richtigen CTIP verfügten, dokumentierten wir die extrahierten TTPs manuell mit Hilfe von Excel-Tabellen und Versionskontrolle. Dies war nicht ideal, da wir mit diesem Tool einige Probleme bei der Zusammenarbeit hatten, und die Weitergabe an externe Teams erfolgte manuell und bot keine wichtigen Funktionen, die von CTIP-Tools angeboten werden, wie z. B. automatische Verknüpfung, Abfrage von Indikatoren usw. Wir gehen davon aus, dass die Modellierung dieser Informationen in einem CTIP sowohl die Zusammenarbeit als auch die Weitergabe und Nutzung der gewonnenen Erkenntnisse vereinfachen sollte.
Schließlich ist es wichtig zu erwähnen, dass wir während der Entwicklung dieser Aktivität keine klare Spezifikation der Anforderungen an die erzeugten Informationen hatten. Wir haben uns auf bestehende, bekannte und dokumentierte Prozesse gestützt, aber wir haben uns auch dafür entschieden, uns zunächst auf die Bedrohungsakteure zu konzentrieren. Vielleicht möchten Sie es andersherum machen und als Input Ihre tägliche CTI-Überwachung wählen. Mit anderen Worten: Es handelt sich um ein Experiment, und Sie können diesen Prozess nach eigenem Ermessen anpassen.
Einsatz von Threat Hunting & Detection Engineering
Von Intelligence zu Hunting
In den letzten Jahren haben neue Technologien und Tools den Fundus an Telemetriedaten, auf den ein SOC-Team beim Aufbau seiner Aktivitäten zurückgreifen kann, erheblich erweitert und gleichzeitig den Zugang erleichtert. Die breitere Akzeptanz dieser Fähigkeiten (vielleicht im Vergleich zu einer Sysmon+SIEM-Kombination) bringt das Gleichgewicht ins Wanken. EDRs, XDRs, NDRs, Cloud-Sicherheitsmodule und SOARs ermöglichen mehr Datenquellen für leistungsfähige Abfragesprachen, mehr Kontextualisierung und mehr Möglichkeiten, Ereignisse miteinander zu korrelieren und komplexere Abfragen durchzuführen. Gleichzeitig erleichtert die Weiterentwicklung der Ergonomie den Betriebsteams die Nutzung dieser Tools. Diese neuen Möglichkeiten sind für uns die perfekte Gelegenheit, die Ergebnisse der Threat Intelligence effizient zu nutzen.
Hier kommen die Threat Hunting und Detection Engineering Aktivitäten ins Spiel. Mit den zahlreichen Tools, die dem SOC zur Verfügung stehen, ist es möglich, Suchanfragen zu erstellen, die auf die von der Threat Intelligence gefundenen TTPs abgestimmt sind. Dieser Prozess der Zusammenarbeit kann auch iterativ erfolgen, wobei Threat Intelligence TTPs zum Backlog hinzufügt und sowohl Threat Hunting als auch Detection Engineering diesen Backlog aufbrauchen.
Eine Suchanfrage kann sowohl für das Hunting als auch für das Detection Engineering zwei Hauptzwecke haben. Die meisten dieser Sensoren bieten die Möglichkeit, die Erkennung auf der Grundlage einer Suchanfrage zu planen, die auf die Telemetrie des Sensors abzielt. So kann jede Suchabfrage entweder für die Erkennung geplant oder in einer Suchabfrage-Bibliothek gespeichert werden, die den SOC-Analysten zur Verfügung steht. Eine (von Detection Engineering bereitgestellte) Erkennungsregel ist Teil des SOC-Warnsystems und muss genau sein, eine geringe Anzahl von Fehlalarmen erzeugen und über eine ausreichende Qualitätsdokumentation verfügen, um qualifiziert und rund um die Uhr einsatzfähig zu sein. Jagdregeln können eine höhere Anzahl von Ergebnissen oder statistischen Ergebnissen liefern und im Allgemeinen mit einer größeren Datenmenge arbeiten. Der Mehrwert von all dem ist die Möglichkeit, nach einer Threat-Hunting-Sitzung vergangene Kompromittierungen zu finden und zusätzliche Erkennungsmöglichkeiten für das SOC.
Wenn wir zum ersten Mal eine Suchabfrage erstellen, wissen wir noch nicht, ob sie zu einer Hunting-Abfrage oder einer Erkennungsregel wird. Die Abfrage wird zunächst in einem echten überwachten Netzwerk getestet (im Falle eines MSSP in mehreren Client-Netzwerken). Die Ergebnisse der Abfrage führen uns zu einer Hunting-Abfrage oder zu einer Detection-Regel.
Threat Hunting
Der Zweck von Threat Hunting besteht darin, gezielt auf vergangene Aktivitäten zurückzublicken, um Hinweise auf Kompromittierungen zu finden. Nach der Ausführung von Abfragen, die speziell für die Suche nach bestimmten TTPs erstellt wurden, können wir die Ergebnisse manuell überprüfen und mit zusätzlichen Abfragen und anderen externen Untersuchungen auswerten.
Bei dieser Art von Abfragen ist es normal, dass einige legitime Aktivitäten in den Ergebnissen zu finden sind. Beim Hunting geht es darum, zu überprüfen, ob diese Aktivitäten tatsächlich rechtmäßig sind. Eine Suchabfrage kann generisch und unspezifisch sein, solange die Anzahl der Ergebnisse noch überschaubar ist, andernfalls ist eine Aggregation der Ergebnisse für statistische Analysen möglich.
Wenn eine Abfrage nicht in eine Erkennungsregel umgewandelt werden kann, fügen wir sie zu unserer Sammlung von Suchabfragen hinzu. Die Suche kann während der Erstellung der Regel durchgeführt werden. Es ist auch möglich, die gesamte Abfragesammlung regelmäßig zu wiederholen, aber wir haben festgestellt, dass diese Art von Aktivität zeitaufwändig ist und nur eine geringe Chance auf Ergebnisse bietet. Schließlich ist es äußerst nützlich, eine solche Sammlung von Abfragen zur Verfügung zu haben, um weitere Untersuchungen durchzuführen, wenn eine Warnung aus einem anderen Grund oder während einer Reaktion auf einen Vorfall erzeugt wird. Dies ist der Punkt, an dem wir das Hauptinteresse an Hunting-Abfragen gefunden haben.
Detection Engineering
Der Zweck einer Erkennungsregel besteht darin, in einem Warnsystem verwendet zu werden und eine Untersuchung durch das SOC einzuleiten. Um dies zu erreichen, ist es absolut notwendig, so wenig legitimes Verhalten wie möglich zurückzugeben und nur auf bösartige Aktivitäten zu stoßen.
Wenn dies nicht bereits nach der Erstellung der Abfrage der Fall ist, ist eine Phase der Abstimmung erforderlich. Die Abstimmung einer Erkennungsregel besteht darin, jede legitime Aktivität auszuschließen, die die Abfrage zurückgeben könnte, und Einschränkungen hinzuzufügen, damit die Regel spezifisch genug ist, um nur erwartete Ergebnisse zurückzugeben. Eine gute Erkennungsregel löst nicht zu viele Warnungen aus, die für die SOC-Analysten zeitaufwendig sind, und erkennt dennoch die erwarteten Verhaltensweisen.
Diese Abstimmungsarbeit muss sehr gründlich sein und wir müssen das überwachte Netzwerk gut kennen, um ein gutes Ergebnis zu erzielen. In unserem Fall, als MSSP, bedeutet dies, dass wir den Kunden und seine Aktivitäten gut kennen müssen. Beispiele für die Optimierung könnten das Whitelisting bestimmter Software, Kontonamen oder Rechner sein, die zu viele “False Positives” erzeugen und als legitim bekannt sind.
Bereitstellung und Zusammenarbeit
Die Kommunikation in einer operativen Umgebung ist von größter Bedeutung. Sie möchten nicht, dass jemand Amok läuft und zwielichtige Dinge auf Ihren Erkennungssystemen einrichtet, die Ihr Bereitschaftsteam um 3 Uhr morgens auslöst, ohne auch nur eine Erklärung abzugeben. Insbesondere ist es wichtig, das Format festzulegen, in dem die Regeln geschrieben werden (proprietäre Sprache speziell für einen Sensor? Open-Source-Standard? usw.), einschließlich des Codierungsstils (Umbenennung von Feldern, Kommentare, Untersuchungs-Pivots usw.); den Einsatzstatus auf jedem Client zu verfolgen; eine Versionierung der Regeln zu haben und in der Lage zu sein, Aktualisierungen zu verfolgen. In unserem Fall haben wir uns entschieden, die Anwendungsfälle für die Jagd in einem eigenen YAML-Format innerhalb eines Git-Projekts zu dokumentieren. Auf diese Weise konnten wir automatisch eine Markdown-Dokumentation generieren, wenn sie in die Produktion ging.
Zunächst dachten wir daran, die TaHiTI-Methodik für die Berichterstattung und Kommunikation zu verwenden. Diese Methode war zwar sehr interessant, passte aber nicht zu unseren speziellen Anforderungen (TaHiTI ist in erster Linie für die Berichterstattung über eine Bedrohungsjagd konzipiert, wir haben versucht, sie an unseren UC-Entwicklungszyklus anzupassen, aber sie erwies sich in diesem Zusammenhang als zu schwerfällig). Stattdessen haben wir uns für Jira entschieden, ein Ticketingsystem, das sowohl für die Berichterstattung als auch für die Verteilung von Aufgaben verwendet wird. Jedes auffindbare TTP erhält ein Ticket. Die Analysten können sich die Tickets dann selbst zuweisen und mit der Arbeit an einer Abfrage beginnen. Die Abfrage selbst wird von den verschiedenen Teams in einem Git-Repository gemeinsam genutzt. Die Struktur des Git-Repository klassifiziert die TTPs nach ihren MITRE ATT&CK-Taktiken und wird von einer in yaml geschriebenen Metadaten-Datei begleitet. Die kontinuierliche Integration wird genutzt, um die Gültigkeit der Daten sicherzustellen und die Dokumentation auf dieser Grundlage zu erstellen. Auf diese Weise enthält das Repository alle wichtigen Informationen wie die Version der Regeln, ob es sich um eine Jagdregel oder eine Erkennungsregel handelt, den Hauptzweck der Regel und worauf im Falle eines Alarms zu achten ist.
Für die externe Kommunikation mit unseren MSSP-Kunden stellen wir eine Mitteilung mit allen neuen verfügbaren Erkennungsregeln, einem Überblick über einige der Abfragen und deren Zweck sowie dem Status der Bereitstellung zur Verfügung.
In der Praxis
Lassen Sie uns ein Beispiel nehmen. In diesem Szenario sind Sie Teil des Detection Engineering/Threat Hunting-Teams. Sie arbeiten hauptsächlich mit Endpoint Detection & Response (EDR)-Sensoren, die Ihnen umfangreiche Systemtelemetriedaten liefern und es Ihnen ermöglichen, mit überwachten Hosts zu interagieren, um proaktiv nach Bedrohungen zu suchen oder sie zu beseitigen.
Ihr CTI-Team hat bei seiner Arbeit die folgende Persistenzskript-Vorlage identifiziert, die in mehreren APT41 zugeschriebenen Kampagnen verwendet wurde:
Cybersecurity 
