zurück zum Artikel

Digitale Einbruchs- und Infektionsspuren, so genannte Indicators of Compromise, kann man clever nutzen, statt sie einfach zu beseitigen. Wir erklären, wie.

Nach einem Einbruch in ein Firmengebäude käme wohl kaum jemand auf die Idee, alle Relikte der Tat achtlos in einen Müllsack zu stopfen, einmal gründlich durchzusaugen und dann zum Business as usual zurückzukehren. Schließlich kann jede Spur vom Stofffetzen über das verlorene Werkzeug bis hin zum kaputten Türschloss helfen, den Täter zu ermitteln. Kombiniert man solche Hinweise, entsteht bestenfalls ein umfassendes Gesamtbild des Einbruchsgeschehens.

Gleiches gilt im digitalen Raum. Letztlich sind kompromittierte Netzwerke nichts anderes als digitale Tatorte voller Relikte unberechtigten Zugriffs, sogenannter Indicators of Compromise (IoCs, deutsch: Kompromittierungsindikatoren). Indem man sie sammelt, auswertet und zueinander in Beziehung setzt, lernt man die Kompromittierung, sei es nun ein gezielter Angriff oder eine großflächige Schadcode-Infektion, besser verstehen.

Aber auch über einen aktuellen Vorfall hinaus, sind IoCs nützlich. So deutet ihr Vorhandensein in anderen Netzen darauf hin, dass dort ebenfalls was im Argen liegen könnte. Und ein Verständnis der Vorgehensweise hilft, effektive Erste-Hilfe-Maßnahmen umzusetzen und passgenaue Verteidigungsstrategien zu entwickeln. Zudem befähigt es IT-Verantwortliche, Details zum Sicherheitsvorfall präzise zu kommunizieren. Im eigenen Team, aber auch gegenüber Mitarbeitern, der Öffentlichkeit oder anderen gefährdeten Organisationen.

In den letzten Jahren haben sich IoCs folgerichtig zu einem wichtigen Werkzeug für IT-Verteidiger entwickelt. So wichtig, dass das britische National Cyber Security Centre (NCSC) und die Internet Engineering Task Force (IETF) vor wenigen Monaten einen wegweisenden Informationsbeitrag in Form des Request for Comments 9424 [1] (RFC 9424) zu diesem Thema veröffentlicht haben. Wir erklären auf dieser Grundlage, was IoCs konkret sind, was man mit ihnen machen kann und was es zu beachten gilt.

[2]

IoC-Basics zum Einstieg

First things first: So etwas wie eine Liste aller denkbaren Typen von Kompromittierungsindikatoren existiert nicht. Denn grundsätzlich sind alle Arten von Einbruchsspuren – sei es die IP-Adresse eines Command-and-Control-Angreiferservers, ein seltsamer Eintrag in der Registry, eine durch Schadcode angelegte Konfigurationsdatei oder die Betreffzeile einer Phishing-Mail – als IoCs verwendbar. So vielfältig wie die Indikatoren selbst sind auch deren mögliche Fundorte: im Netzwerk-Traffic, in Logfiles verwendeter Sicherheitslösungen und auf kompromittierten Systemen.

Mitunter kann man sie leicht aufspüren, in anderen Fällen sind mehr oder weniger aufwendige Suchmaßnahmen etwa in Gestalt gezielten Monitorings oder manueller System- und Dateianalysen vonnöten. Und auch der Vorgang des "Einsammelns", also Dokumentierens eines IoCs kann unterschiedlich anspruchsvoll sein.

So kann man etwa eine IPv4- oder -v6-Adresse ohne weitere Umstände einer Liste hinzufügen, um sie später einer Firewall zu füttern oder anderweitig zu verarbeiten. Es gibt aber auch deutlich abstraktere Indikatoren, die etwa verdächtige Muster im Datenverkehr oder bestimmte Aktivitäten eines Schadcodes abbilden. Mit textuellen Beschreibungen oder auch speziellen Standardformaten gelingt in solchen Fällen die Dokumentation; mehr dazu später.

Schnelle Recherchen

Die Entscheidung darüber, wie viel Aufwand man beim Sammeln und Dokumentieren betreibt, hängt letztlich davon ab, was man mit den gefundenen IoCs anfangen will. Zur ersten Einordnung einer Bedrohung per Online-Recherche genügt oftmals schon ein einziger gefundener Indikator.

Wirft man etwa eine verdächtige IP-Adresse in die Suchfunktion von Open Threat Exchange (OTX) [3], einer Plattform für den Austausch von Bedrohungsinformationen, so liefert diese mit etwas Glück zusätzlichen Kontext. Etwa die Information, dass die gefundene IP auf einen C2-Server von Angreifern deutet, die gecrackte Versionen des kommerziellen Tools Cobalt Strike zum Fernsteuern von Systemen missbrauchen.

Mit dieser Information könnte man dann unter anderem in der Malpedia-Datenbank des Fraunhofer FKIE [4] unter Eingabe des Stichworts "Cobalt Strike" weiter recherchieren. Und auf diesem Wege erfahren, dass sich auf den kompromittierten Hostsystemen mit hoher Wahrscheinlichkeit sogenannte Cobalt Strike Beacons verbergen, die den Angreifern dauerhaften und umfassenden Zugang gewähren.

Der Online-Analysedienst VirusTotal (VT) umfasst seit Ende 2021 ein Feature, mit dem Nutzer IoC-Sammlungen anlegen können [5]. Je nach Einstellungen sind diese dann auch öffentlich sicht- und durchsuchbar. Im konkreten Fall erhält man durch Querlesen der in einer Cobalt Strike-Sammlung [6] verlinkten Analyse-Reports technische Informationen zu verschiedenen Beacon-Versionen. Und damit wiederum eine große Menge potenziell weiter verwertbarer Kompromittierungsindikatoren wie kontaktierte URLs, Datei-Hashes und -größen. Außerdem umfassen die Reports Verhaltensinformationen aus einer Sandbox-Analyse sowie in einigen Fällen hilfreiche Kommentare aus der VT-Community.

Mit eigenen IoCs nach Bedrohungen suchen

Die gesammelten Informationen könnte man im nächsten Schritt nutzen, um die Aufräumarbeiten zu erleichtern oder gar zu beschleunigen. So geschehen beispielsweise 2019 an der Uni Gießen [7]: Nach einem massiven Malware-Befall verwendeten IT-Verantwortliche Schadcode-IoCs zur automatisierten Überprüfung potenziell infizierter Systeme, bevor diese wieder ans Netz konnten.

Ihr Werkzeug: der Universal-Scanner YARA [8] im Kontext von Desinfec't und unter Verwendung selbst geschriebener Signaturen, sogenannter YARA-Regeln. Dank frisch eingesammelter Kompromittierungsindikatoren aus manuell aufgespürtem Schadcode gelang die Erkennung eines wandlungsfreudigen Schädlings, an der zuvor mehrere Virenscanner gescheitert waren.

Lesen Sie auch

Malware-Signaturen mit Yara selbst schreiben

Ausflug zu den Pyramiden

Aber Vorsicht: Um mit IoCs erfolgreich auf Malware-Suche zu gehen, ist es wenig sinnvoll, nach dem Motto "viel hilft viel" einfach wahllos drauflos zu kombinieren. Denn verschiedene IoCs sind je nach Beschaffenheit für unterschiedliche Aufgaben mehr oder wenig gut geeignet. Um diesen Sachverhalt besser zu verstehen, lohnt es sich, einen Blick auf die im RFC dargestellte "Pyramid of Pain" (PoP) [9] zu werfen. Sie unterteilt Kompromittierungsindikatoren in Gruppen mit ähnlichen Eigenschaften.

Die Pyramidenbasis bilden kryptografische Hashwerte (z.B. MD5, SHA256), die man aus schädlichen Dateien auf Hostsystemen selbst berechnen oder beispielsweise auch den bereits erwähnten VT-Reports entnehmen kann. Ein solcher Hash ist als Kompromittierungsindikator, wie auch seitlich an der Pyramide vermerkt, extrem präzise: Verpackt in eine selbst geschriebene Signatur oder ein einfaches Skript, könnte man ihn zum automatisierten Aufspüren aller identischen Dateien im Netzwerk verwenden – Verwechslung ausgeschlossen.

Die Sache hat jedoch einen Haken: Je präziser ein IoC, desto fragiler – also kurzlebiger – ist er laut PoP auch. Logisch: Leicht modifiziert und neu kompiliert oder durch ein Packprogramm zur Komprimierung geschleust, ändert sich der Hashwert der resultierenden Schadcode-Datei. Dem verantwortlichen Cybergangster bereitet diese Anpassung wenig Mühe, wie die Beschriftung "less pain" an der PoP-Darstellung verdeutlicht.

Präzision versus Langlebigkeit

Will man nun etwa eine YARA-Regel schreiben, die nicht nur Hash-basiert eine einzige, sondern dauerhaft mehrere Varianten einer Malware oder eines Tools erkennt, sollte man in der PoP ein ganzes Stück nach oben klettern. Nämlich bis zur langlebigeren Gruppe "Tools", die Angriffswerkzeuge auf einer allgemeinen Ebene beschreibt, statt anhand eines spezifischen Datei-Hashes nur eine einzige Variante zu benennen. Und die deshalb letztlich auch länger ihre Wirksamkeit behält ("less fragile").

Wie man solche unpräziseren, abstrakteren IoCs in der Praxis nutzen kann, illustrieren beispielsweise von Google via GitHub veröffentlichte YARA-Regeln zur Erkennung von Cobalt Strike-Beacons [11]. Sie verwenden als IoCs Hex-Strings, die typische Befehlsfolgen aus dem Code der Beacons repräsentieren. Eingestreute Platzhalter für einzelne variierende Hexwerte ("??") oder für eine bestimmte Anzahl variierender Bytes (z.B. "[4]") weiten die Erkennung zusätzlich ein wenig aus. So wie in diesem Beispiel:

$decode = { B1 ?? 30 88 [4] 40 3D 28 01 00 00 7C F2 }

Anhand eines solchen Indikators dürften nun mehrere Varianten erkannt werden. Allerdings gibt es auch hier laut RFC wieder etwas zu bedenken: Je unpräziser ein Indikator, desto größer die Gefahr von Falscherkennungen [12]. Schließlich könnten auch legitime Dateien auf dem jeweiligen System Varianten der Befehlsfolge enthalten.

Um die Wahrscheinlichkeit eines solchen False Positives abzuschwächen, empfehlen die RFC-Autoren, immer mehrere unpräzise IoCs miteinander zu kombinieren. Die hier als Beispiel verwendeten Regeln von Google folgen dieser Strategie, indem sie zwei Hex-Strings mit der Bedingung "all of them" verknüpfen: Nur wenn beim Scan einer Datei oder eines laufenden Prozesses beide Strings (oder ihre jeweiligen Varianten) auftauchen, schlägt der YARA-Scanner an.

Das große Ganze

Die vorangegangenen Beispiele dürften gezeigt haben, dass das Aufspüren und Verwenden einzelner IoCs im Nachgang einer Kompromittierung auch ohne viel Vorwissen praktikabel ist. Die PoP vollständig zu erklimmen und eine umfassende Spurensicherung auf allen Eben durchzuführen, erfordert hingegen einen nochmals deutlich höheren Aufwand und Profiwissen. Hier sei der Vollständigkeit halber nur kurz erwähnt, dass die in der Pyramidenspitze dargestellten "Tactics, Techniques and Procedures", kurz: TTPs, das noch fehlende Puzzleteil darstellen, um in Kombination mit den übrigen IoC-Gruppen ein umfassendes Bild des Kompromittierungsgeschehens nachzuzeichnen.

Unabhängig davon, wie umfassend die jeweilige Spurensuche ausfällt, besteht der nächste Schritt nach dem Sammeln und Auswerten sinnvollerweise im Teilen der Erkenntnisse. Um im Zuge eines firmeninternen Sicherheitsvorfalls Geschäftspartner und Mitarbeiter über Details zu informieren oder befreundete Organisationen zu warnen, dürfte hierfür meist eine Beschreibung der gesammelten Erkenntnisse in Textform ausreichen.

Sicherheitsforscher hingegen, die mit großen Datenmengen arbeiten und umfassende Analysen durchführen, setzen auf standardisierte Formate wie STIX [13], das MISP Core Format [14] oder OpenIOC [15]. Die einheitliche Erfassung auch abstrakter IoCs erleichtert den Abgleich mit großen Mengen vorhandener Daten. Im Zuge dessen kann etwa auch eine Attribution, also die Zuordnung bestimmter Angriffsmerkmale zu bekannten (APT-)Gruppen [16] gelingen.

Bereits vorhandenes Wissen nutzen

Ein weiterer wichtiger Vorteil von IoC-Standardformaten ist die automatisierte Verarbeitbarkeit von IoCs im Kontext von Sicherheitssoftware, die mit Threat Intelligence, also Bedrohungsinformationen, arbeitet. Zumeist verpacken deren Hersteller Kompromittierungsindikatoren zusammen mit weiteren relevanten Daten in Feeds, die den Schutzkomponenten laufend neue Informationen zu spezifischen Bedrohungen liefern. Indem IoC-Sammlungen komplexe Angriffsmuster auf verschiedenen Infrastrukturebenen beschreiben, können sie zu einer wirkungsvollen, mehrstufigen Gefahrenabwehr ("Defense in Depth") beitragen.

In diesem Zusammenhang interessant: Ebenso wie es bei GitHub zahlreiche Repositories mit frei verfügbaren YARA-Regeln gibt, bieten Plattformen wie das bereits erwähnte OTX [17] oder die Malware Information Sharing Platform [18] (MISP) frei verfügbare IoC-Sammlungen in verschiedenen Formaten an. Diese kann man vielfach als Ergänzung oder auch kostenlose Alternative zu kommerziellen Threat Intelligence Feeds nutzen.

Wie dies im Einzelnen funktioniert, sprengt den Rahmen dieses Artikels. Es dürfte sich jedoch lohnen, nach weiteren IoC-Quellen und den jeweiligen Anbindungsmöglichkeiten an verschiedene Schutzsysteme zu recherchieren. So widmet beispielsweise Microsoft in der Online-Hilfe zum SIEM-System Sentinel dem Integrieren von Bedrohungsdaten aus externen Quellen [19] einen ausführlichen Abschnitt.

Ausprobieren lohnt sich

Indicators of Compromise sind als vielseitiger und meist sogar kostenloser Baustein zur IT-Verteidigung das Ausprobieren und Experimentieren wert. Greift man dabei auf vorhandene Quellen zurück, muss man nicht einmal besonders tief in die Materie einsteigen.

Für alle, die dies dennoch tun wollen, bietet das RFC des National Cyber Security Centre eine fundierte und – gute Englischkenntnisse vorausgesetzt – relativ anfängerfreundliche Informationsquelle. Insbesondere lesenswert: die näheren Details zur Pyramid of Pain [20] sowie die Fallbeispiele zur IoC-Nutzung [21].

Weiterhin ist es sinnvoll, sich mit dem (endlichen) Lebenszyklus der Indikatoren [22] zu befassen und daran zu denken, dass kurzfristig wirksame Schutzmechanismen, die auf präzisen Indicators of Compromise fußen, nicht unbedingt dauerhaft wirksam sein müssen.

• RFC9424: Indicators of Compromise (IoCs) and Their Role in Attack Defence [23]
• Blogpost zum RFC National Cyber Security Centre [24]
• Kurz erklärt: Request for Comments [25]

[26]

(ju [27])

URL dieses Artikels:
https://www.heise.de/-9606508

Links in diesem Artikel:
[1] https://datatracker.ietf.org/doc/html/rfc9424
[2] https://www.heise.de/heisec-pro
[3] https://otx.alienvault.com/
[4] https://malpedia.caad.fkie.fraunhofer.de/
[5] https://blog.virustotal.com/2021/11/introducing-virustotal-collections.html
[6] https://www.virustotal.com/gui/collection/malpedia_win_cobalt_strike/iocs
[7] https://www.heise.de/news/Trojaner-Befall-Uni-Giessen-nutzt-Desinfec-t-fuer-Aufraeumarbeiten-4617154.html
[8] https://virustotal.github.io/yara/
[9] https://datatracker.ietf.org/doc/html/rfc9424#name-ioc-types-and-the-pyramid-o
[10] https://www.ncsc.gov.uk/blog-post/rfc-indicators-of-compromise-for-ietf
[11] https://github.com/chronicle/GCTI/blob/main/YARA/CobaltStrike/CobaltStrike__Resources_Beacon_Dll_All_Versions_MemEnabled.yara
[12] https://datatracker.ietf.org/doc/html/rfc9424#name-specificity
[13] https://oasis-open.github.io/cti-documentation/stix/intro
[14] https://www.misp-project.org/datamodels/
[15] https://www.mandiant.com/resources/blog/openioc-basics
[16] https://www.heise.de/hintergrund/Auf-Taetersuche-Herausforderungen-bei-der-Analyse-von-Cyber-Angriffen-5043620.html
[17] https://otx.alienvault.com/
[18] https://www.misp-project.org/
[19] https://learn.microsoft.com/de-de/azure/sentinel/threat-intelligence-integration
[20] https://datatracker.ietf.org/doc/html/rfc9424#name-ioc-types-and-the-pyramid-o
[21] https://datatracker.ietf.org/doc/html/rfc9424#name-case-studies
[22] https://datatracker.ietf.org/doc/html/rfc9424#name-ioc-lifecycle
[23] https://datatracker.ietf.org/doc/html/rfc9424
[24] https://www.ncsc.gov.uk/blog-post/rfc-indicators-of-compromise-for-ietf
[25] https://www.heise.de/select/ix/2016/7/1467003811475572
[26] https://www.heise.de/heisec-pro
[27] mailto:ju@ct.de

Copyright © 2024 Heise Medien