Indicators of Compromise (IoC) als Mittel zur Risikominimierung

Inhaber von IT-Infrastrukturen müssen ihre Ressourcen regelmäßig auf das Vorhandensein schädlicher Komponenten überprüfen. Eine Infektion kann beispielsweise infolge der Ausnutzung von Zero-Day-Sicherheitslücken durch Cyberkriminelle erfolgen. In solchen Fällen ist es möglich, dass selbst die Entwickler der Schutzlösungen, die auf dem entsprechenden IT-System laufen, noch nichts von dieser neuen Bedrohung wissen. Gleichzeitig können die Experten bereits Ermittlungen zu Vorfällen durchführen, die mit dieser neuen Bedrohung in Zusammenhang stehen. Es könnten sogar bereits einige Ergebnisse dieser Ermittlungen veröffentlicht worden sein.

Solche Veröffentlichungen haben einen praktischen Wert. Ein typischer Bericht über eine APT-Kampagne enthält die folgenden Informationen:

  • Opfer der Attacke und die Ziele, die die Cyberverbrecher verfolgen;
  • Zeiten, in denen die schädlichen Komponenten aktiv sind;
  • Liste der Knoten (IP-Adressen) der Opfer;
  • aktuelle Aktivität der Schadkomponenten und/oder der cyberkriminellen Gruppen;
  • detaillierte Beschreibung der Tools und Schadkomponenten, die die Cybergangster verwenden;
  • Beschreibung der C&C-Infrastruktur (Command and Control Server);
  • Kompromittierungsindikatoren (Indicators of Compromise – IoC, YARA-Rules usw.).

Unter den detaillierten technischen Informationen über die eine oder andere APT sind für jeden Administrator von IT-Sicherheitssystemen die „Kompromittierungsindikatoren“ von größtem praktischen Interesse. Es handelt sich dabei um eine Datensammlung, die dem Administrator einer IT-Infrastruktur helfen kann, schädliche Aktivität im System zu erkennen und die entsprechenden Maßnahmen zu ergreifen.

Was können IT-Administratoren in der Praxis mit diesen Indikatoren anfangen? In dem vorliegenden Artikel versuchen wir, eine Antwort auf diese Frage zu geben.

Indicators of Compromise sind strukturierte Informationen über Merkmale schädlicher Aktivität, die für den Import in automatisierte Mechanismen zur Überprüfung der Infrastruktur auf Anzeichen einer Infektion vorgesehen sind. Ein normiertes Format zur Beschreibung von Indikatordaten wurde bisher noch nicht entwickelt, allerdings sind in der Branche einige Typen von strukturierten Daten weit verbreitet und werden unterstützt.

IOC

Unter IOC (Indicators of Compromise) versteht man eine Liste von Daten über Bedrohungen (beispielsweise Zeilen, die den Pfad zu Dateien beschreiben, oder Registry-Schlüssel), die es unter Verwendung einer automatisierten Analyse mit Softwaremitteln ermöglichen, Bedrohungen in der Infrastruktur aufzudecken.

Einfache Szenarien des Einsatzes von IOC sehen die Suche nach spezifischen Dateien im System aufgrund verschiedener Merkmale vor: MD5-Hash, Dateiname, Erstellungsdatum, Größe und andere Attribute. Darüber hinaus kann man nach verschiedenen spezifischen Merkmalen im Speicher oder nach spezifischen Einträgen in der Registry des Betriebssystems Windows suchen.

Es gibt verschiedene Formate, in denen diese Daten dargestellt werden können, beispielsweise OpenIOC. Diese Formate ermöglichen den Import der Daten in die eine oder andere Schutzlösung für die darauffolgende Arbeit mit den Indikatoren. Der Administrator kann die Integration der IOC aus den Berichten in verschiedene Schutzlösungen umsetzen:

  • Schutzlösungen der Klasse „Endpoint Security“;
  • SIEM;
  • IDS/IPS;
  • HIDS/HIPS;
  • verschiedene Tools zur Ermittlung von Sicherheitsvorfällen.

Es gibt eine Vielzahl von kommerziellen Lösungen für die Arbeit mit IOC, allerdings sind die Möglichkeiten ihrer Open-Source-Pendants in einigen Fällen vollkommen ausreichend, um ein Zielsystem auf das Vorhandensein von Infektionsmerkmalen zu untersuchen. Loki ist beispielsweise ein IOC-Scanner, der unter einer GPL-Lizenz verbreitet wird und der es ermöglicht, auf dem Zielsystem nach verschiedenen Merkmalen zu suchen, die infolge schädlicher Aktivität auftreten.

Um Systeme mit Hilfe des Scanners Loki zu überprüfen, muss man lediglich das Archiv mit dem Tool entpacken und der Wissensdatenbank des Scanners die notwendigen IOC-Attribute hinzufügen. Im Verzeichnis “signature” der Anwendung befinden sich die folgenden IOC-Kategorien:

  • “filename-iocs” – eine Textdatei, die Listen verschiedener Attribute des Dateisystems enthält, die infolge der einen oder anderen Bedrohung auftreten;
  • “hash-iocs” – eine Aufstellung der MD5, SHA1 und SHA256-Hashes von schädlichen Komponenten, die im System nach einer Infektion vorhanden sind;
  • “falsepositive-hashes” – eine Liste von Ausnahmen von MD5-, SHA1- SHA256-Hashes, die bei der Detektion der entsprechenden Komponenten von dem Scanner als „falsch-positive Alarme“ eingeordnet werden.

Nehmen wir als Beispiel unseren Bericht über die Untersuchung der Carbanak-APT. Auf Seite 36 dieses Berichts befindet sich eine Auflistung der MD5-Hashes der Schadkomponenten, die im System nach dessen Infektion auftauchen können. Wir öffnen die Datei „hash-iocs“ des Scanners und tragen die entsprechende Regel im folgenden Format ein: <MD5>;<description> .

Liste der MD5-Hashes der Komponenten der Carbanak-APT in der Datei „hash-iocs” des Scanners Loki

Daraufhin erstellen wir in der Textdatei „filename-iocs“, die die Attribute der Schadkomponenten im Dateisystem beschreibt, den Indikator im Format:

# COMMENT

# REGULAREXPRESSION;SCORE

IOC für das Dateisystem in der Liste “filename-iocs“ des Scanners Loki

Nach der Aufnahme der notwendigen Indikatoren in die Wissensdatenbank des Scanners kann man mit dem Scan der Workstation beginnen. Zu diesem Zweck muss man die ausführbare Datei “loki.exe” mit Administratorenrechten starten (ansonsten hat der Scanner nicht die Möglichkeit, den Inhalt des Arbeitsspeichers auf das Vorhandensein der Attribute zu überprüfen) und den Abschluss der Prozedur abwarten.

Scanprozess des Tools Loki

Aufgrund der Scan-Resultate erstellt die Anwendung einen Bericht, der dann im Verzeichnis des Programms unter dem Namen “loki.txt” abgelegt wird.

YARA-Regeln

Neben verschiedenen Kompromittierungsindikatoren können den Berichten auch Dateien mit der Erweiterung „.yar“ hinzugefügt werden. Diese Dateien enthalten einer speziellen Syntax entsprechend zusammengestellte Regeln für YARA – ein Tool, das auf die Identifikation und Klassifizierung von schädlichen Samples ausgerichtet ist. Die so genannten YARA-Regeln beschreiben Merkmale für das Vorhandensein schädlicher Aktivität im System. Wenn eine der Regeln erfüllt wird, stellt der Analyser eine Infektion mit den entsprechenden Details fest (beispielsweise die Bezeichnung der Bedrohung).

Der oben beschriebene Scanner Loki unterstützt auch YARA-Regeln, das bedeutet, die aus den Berichten entnommenen yar-Dateien können dem Administrator für die Untersuchung des Systems auf das Vorhandensein der Bedrohung dienen, von der im Bericht die Rede ist. Zu diesem Zweck reicht es aus, die yar-Datei in den Ordner “signature” zu verschieben und die Untersuchung zu starten.

Für die Arbeit mit YARA-Regeln ist das offizielle Tool der Entwickler des YARA-Projekts besser geeignet, da dessen Wissensdatenbank regelmäßig aktualisiert wird und sie auch größer ist als die Datenbanken der analogen Tools. Dadurch erhält man infolge eines Scans ein vollständigeres Bild über die Sicherheit des IT-Systems sowie vollständigere Informationen über das Vorhandensein der einen oder anderen schädlichen Komponente darin.

Für die Überprüfung der Workstation muss man lediglich das YARA-Tool mit den notwendigen Parametern starten. Zum Beispiel:

yara32.exe –d md5= <MD5_hash><this_is_yara_rule.yar><dir_for_check>

wobei der Parameter „-d“ für die Definition der externen Variablen verwendet wird. Gibt es irgendwelche Übereinstimmungen mit den Bedingungen der Regel, wird eine Benachrichtigung mit dem Namen der Regel und der Komponente, die den Alarm ausgelöst hat, ausgegeben.

Beispiel für eine Benachrichtigung über eine Alarm auslösende YARA-Regel

Der Administrator kann derartige Überprüfungen beispielsweise beim Systemboot starten. Zu diesem Zweck muss man lediglich ein einfaches PowerShell-Skript schreiben, das die Tools mit den notwendigen Parametern startet und, wenn nötig, seinen Start für alle Hosts mit Hilfe von Active Directory festlegt: User configuration -> Windows configuration -> Scenarios ->Logon.

STIX und JSON

Structured Threat Information Expression (STIX) ist eine standardisierte Sprache für die strukturierte Aufzeichnung von Informationen über Bedrohungen und deren darauffolgenden Import in Softwarelösungen. Eine Vielzahl von Schutzlösungen ermöglicht den Import von Informationen im Format STIX (und ebenfalls in JSON, wovon später die Rede sein wird) für deren späterer Nutzung in der Infrastruktur:

  • SIEM,
  • auf Indikatoren basierende Schutzlösungen (beispielsweise Scanner),
  • Forensic-Plattformen,
  • Lösungen der Klasse „Endpoint Security“ und andere.

Der Import eines STIX-Berichts kann in der populären SIEM-Lösung IBM QRadar erfolgen, unter Verwendung eines eigens erstellten python-Skripts:

./stix_import.py -f STIXDocument.xml -i 192.168.56.2 -t XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX -r MyReferenceSet

Wobei „-f“ den Standort des lokalen STIX-Dokuments definiert, „-i“ den Host mit der installierten QRadar-Konsole bestimmt und „-t“ den Service-Token für QRadar vorgibt.

JSON ist eins der populärsten Formate zur Darstellung von Daten, das auch häufig in Appendizes in Berichten verwendet wird. Die Verwendung von Daten im Format JSON hängt von den Aufgaben des Administrators und den Besonderheiten der Software ab, in die der Import dieser Daten umgesetzt wird. Sind beispielsweise in einer JSON-Datei IP-Adressen von Steuerungsservern vorhanden, mit denen sich infizierte Workstations verbinden, kann der Administrator einer zu schützenden Infrastruktur diese IP-Adressen in die Schwarze Liste seiner Firewall aufnehmen, die den Import von JSON unterstützt. Wenn die Firewall den Import dieses Formats nicht unterstützt, so hat der Administrator die Möglichkeit, einen Parser (Bearbeitungsroutine von JSON-Dateien) für den Export der Liste von IP-Adressen aus den Dateien und für deren darauffolgenden Import in die Schwarze Liste der Firewall zu verwenden.

Richtige Aufbereitung

Die Kompromittierungsindikatoren werden für die effektive Nutzung von Daten über Bedrohungen verwendet: für das Aufspüren von Malware und ein umgehendes Reagieren auf Vorfälle. Dabei werden diese Indikatoren sehr häufig an Berichte über Bedrohungen angehängt, die viele quer lesen. Selbst wenn ein solches Dokument über eine neue Bedrohung kein eigenes Kapitel mit dem Titel „Indicators of Compromise“ enthält, kann man sich immer selbstständig nützliche Daten (Informationen über Merkmale, die in einem infizierten System auftreten) aus dem Berichtstext herausziehen, sie in eins der oben beschriebenen Formate umwandeln und sie in eine Schutzlösung importieren.

Unsere jüngsten Studien mit Kompromittierungsindikatoren:

Wild Neutron – Economic espionage threat actor returns with new tricks

The Mystery of Duqu 2.0: a sophisticated cyberespionage actor returns

The Great Bank Robbery: the Carbanak APT

Icefog OpenIOC Release

Darkhotel Indicators of Compromise (PDF)

Crouching Yeti — Appendixes (PDF)

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.