Alles, was Sie schon immer über Sigma-Regeln wissen wollten. Teil 1

Bei der Entwicklung von Produkten und der Entwicklung von Know-how orientieren wir uns in erster Linie an dem Wunsch, die Sicherheit von Unternehmen zu verbessern. Unsere Forschung basiert jedoch nicht nur auf der Kundenbetreuung. Lange Zeit hatten wir den Wunsch, auf freiwilliger Basis Nachforschungen für die Informationssicherheitsgemeinschaft anzustellen , und jetzt tun wir dies aktiv: Wir veröffentlichen hochkarätige Netzwerkangriffe auf Twitter , liefern Verkehrsanalyseregeln an den ANY.RUN-Dienst und fügen ETOpen-Regeln hinzu . Es gibt viele Open-Source-Projekte, an die Sie eine Pull-Anfrage senden können, aber bis vor kurzem haben Host-Erkennungen ihre Hände noch nicht erreicht.



Und dann erfuhren wir, dass eine Gruppe von Enthusiasten beschlossen hatte, einen zweiwöchigen Sprint zu organisierenüber das Schreiben von Regeln für das Sigma-Projekt , das erstellt wurde, um ein einheitliches Format zur Beschreibung von Regeln für SIEM-Systeme zu entwickeln, und von mehr als 140 Teilnehmern unterstützt wird. Wir waren an den Neuigkeiten über die Veranstaltung interessiert, da wir als SIEM-Anbieter die Entwicklung der Community genau verfolgen.



Stellen Sie sich unsere Überraschung vor, als die Organisatoren uns kontaktierten und das Team des PT Expert Security Center zur Teilnahme am Sprint einluden ! Die Veranstaltungsteilnehmer bildeten die Open Security Collaborative Development (OSCD) - eine internationale Initiative von Spezialisten für Informationssicherheit, die darauf abzielt, Wissen zu verbreiten und die Computersicherheit im Allgemeinen zu verbessern. Wir haben uns gerne zur Teilnahme bereit erklärt, um unsere Erfahrungen zum Wohle der gemeinsamen Sicherheit anzuwenden.

Wie dieser Artikel entstanden ist

Als wir anfingen, die Regeln zu schreiben, stellten wir fest, dass es keine erschöpfende Beschreibung der Syntax von Sigma-Regeln gab, insbesondere auf Russisch. Die wichtigsten Wissensquellen sind GitHub und persönliche Erfahrung. Es gibt mehrere gute Artikel (auf Russisch und Englisch ), aber in ihnen wird der Schwerpunkt von der Syntax der Regeln auf die Analyse des Anwendungsbereichs von Sigma-Regeln oder die Erstellung einer bestimmten Regel verlagert. Wir haben uns entschlossen, Anfängern das Kennenlernen des Sigma-Projekts zu erleichtern, unsere eigenen Erfahrungen auszutauschen und an einem Ort Informationen über die Syntax und die Funktionen seiner Verwendung zu sammeln. Und wir hoffen natürlich, dass dies dazu beitragen wird, die OSCD-Initiative zu erweitern und in Zukunft eine große Community zu schaffen.



Da es viel Material gab, haben wir beschlossen, eine Beschreibung in einer Reihe von drei Artikeln zu veröffentlichen:

1. , ( ).
2. . , .
3. (, , , , ) .

Sigma

Sigma ist ein einheitliches Format zur Beschreibung von Erkennungsregeln basierend auf Daten aus Protokollen. Regeln werden in separaten YAML-Dateien gespeichert. Mit Sigma können Sie eine Regel einmal mit einer einheitlichen Syntax schreiben und dann mithilfe eines speziellen Konverters die Regel in der Syntax eines unterstützten SIEM-Systems abrufen. Neben der Syntax von Abfragen verschiedener SIEM-Systeme wird die Erstellung von Abfragen der folgenden Typen unterstützt:

• Elasticsearch-Abfrage,
• Startzeile des grep-Dienstprogramms mit den erforderlichen Parametern,
• PowerShell-Zeichenfolge für Windows-Überwachungsprotokolle.

Die letzten beiden Typen zeichnen sich dadurch aus, dass für die Analyse von Protokollen keine zusätzliche Software erforderlich ist. Das grep-Dienstprogramm und der PowerShell-Interpreter werden unter Linux bzw. Windows sofort unterstützt.



Das Vorhandensein eines einheitlichen Formats zur Beschreibung von Erkennungen anhand von Protokollen erleichtert den Wissensaustausch, die Entwicklung von Open-Source-Sicherheit und die Unterstützung der Informationssicherheitsgemeinschaft bei der Bekämpfung neu auftretender Bedrohungen.

Allgemeine Syntax

Zunächst sollte gesagt werden, dass es erforderliche und optionale Teile der Regel gibt. Dies ist im offiziellen Wiki auf GitHub dokumentiert . Der Umriss der Regel (Quelle: offizielles Wiki) ist unten dargestellt:







Fast jede Regel kann grob in drei Teile unterteilt werden:

1. Attribute, die die Regel beschreiben (Metainformationen);
2. Attribute, die Datenquellen beschreiben;
3. Attribute, die die Bedingungen zum Auslösen der Regel beschreiben.

Jeder der Teile entspricht den erforderlichen übergeordneten Attributen für Titel (zusätzlich zum Titel enthält die letzte Gruppe weitere optionale übergeordnete Attribute), Protokollquelle und Erkennung .



Es gibt noch ein weiteres Merkmal der Regelstruktur, über das es sich zu sprechen lohnt. Da die Regeln in der YAML-Auszeichnungssprache beschrieben sind, haben die Sigma-Entwickler eine Verwendung dafür gefunden, da das YAML-Format das Platzieren mehrerer YAML-Dokumente in einer Datei ermöglicht. Und für Sigma - mehrere Regeln, die in einer Datei kombiniert werden sollen, dh "Regelsammlungen" erstellen. Dieser Ansatz ist praktisch, wenn es mehrere Möglichkeiten gibt, einen Angriff zu erkennen, und Sie den beschreibenden Teil nicht duplizieren möchten (wie im entsprechenden Abschnitt beschrieben, können Sie nicht nur den beschreibenden Teil der Regel duplizieren).



In diesem Fall ist die Regel herkömmlicherweise in zwei Teile unterteilt:

• ein Teil mit allgemeinen Attributen für Sammlungselemente (normalerweise alle Felder mit Ausnahme der Abschnitte Protokollquelle und Erkennung),
• ein oder mehrere Teile, die die Erkennung beschreiben (Abschnitte Protokollquelle und Erkennung).

Wenn die Datei eine einzelne Regel enthält, gilt diese Aussage auch, da wir aus einer Regel eine entartete Sammlung erhalten. Regelsammlungen werden im dritten Teil dieser Artikelserie ausführlich besprochen.



Als nächstes betrachten wir ein Beispiel einer hypothetischen Regel. Es ist zu beachten, dass Kommentare in dieser Form normalerweise nicht in Regeln verwendet werden, hier nur zur Beschreibung von Feldern.

Beschreibung der typischen Regel

Ein Beispiel zum Erstellen einer Sigma-Regel

Bevor wir die Details der Syntax beschreiben und über die Funktionen von Sigma-Regeln sprechen, betrachten wir ein kleines Beispiel für die Erstellung einer solchen Regel, um zu verdeutlichen, woher diese oder jene Attributwerte in der Praxis stammen. Es gibt einen guten Artikel zu diesem Thema auf Englisch. Wenn Sie bereits versucht haben, Ihre eigenen Regeln zu schreiben und herausgefunden haben, welche Daten Sie im Attribut der YAML-Datei angeben müssen, können Sie mit dem nächsten Abschnitt mit einer detaillierten Beschreibung des Abschnitts Ereignisquellen fortfahren (wir werden diesen Abschnitt auch als Protokollquellen bezeichnen).



Lassen Sie uns beschreiben, wie Sie eine Regel erstellen, die die Verwendung von SettingSyncHost.exe als LOLBin (Living Off The Land Binary) erkennt. Die Regelerstellung umfasst normalerweise drei Phasen:

1. einen Angriff ausführen und die notwendigen Protokolle sammeln,
2. Beschreibung der Erkennung in der Regel,
3. Überprüfen der erstellten Regel.

Einen Angriff durchführen

Die Idee für die Regel ist im Hexacorn-Blog gut dokumentiert . Nach sorgfältiger Lektüre wird klar, welche Schritte unternommen werden müssen, um das im Artikel beschriebene Ergebnis zu wiederholen:

1. Kopieren Sie das Programm, das Sie ausführen möchten, in ein beschreibbares Verzeichnis. Der Artikel schlägt vor,% TEMP% zu wählen. Sie können jedoch den Pfad Ihrer Wahl wählen. Es ist zu beachten, dass in diesem Verzeichnis ein Unterverzeichnis mit dem Namen erstellt wird, den Sie in Schritt 4 angegeben haben.
2. , , , (wevtutil.exe, makecab.exe, reg.exe, ipconfig.exe, settingsynchost.exe, tracelog.exe). , findstr.exe. , SettingSyncHost.exe Binary Search Order Hijacking (MITRE ATT&CK ID: T1574.008).
3. , ( settingsynchost.exe cmd PowerShell, cd < >).
4. : c:\windows\system32\SettingSyncHost.exe -LoadAndRunDiagScript <___>
5. SettingSyncHost.exe.

Sysmon wird mit einer Konfigurationsdatei aus dem sysmon-modularen Projekt auf dem System installiert . Somit wurde die Sammlung von Protokollen automatisch durchgeführt. Welche Art von Protokollen zum Schreiben einer Erkennung nützlich sind, wird beim Schreiben einer Regel angezeigt.

Beschreibung der Erkennung in Form einer Sigma-Regel

In diesem Schritt sind zwei Ansätze möglich: Suchen Sie eine vorhandene Regel, die der Erkennungslogik am nächsten kommt, und ändern Sie sie an Ihre Anforderungen, oder schreiben Sie eine Regel von Grund auf neu. In der Anfangsphase wird empfohlen, sich an den ersten Ansatz zu halten. Aus Gründen der Klarheit werden wir eine Regel mit dem zweiten Ansatz schreiben.



Wir erstellen eine neue Datei und versuchen, ihre Essenz im Namen kurz und prägnant zu beschreiben. Hier sollten Sie sich an den Stil der vorhandenen Regeln halten. In unserem Fall haben wir den Namen win_using_settingsynchost_to_run_hijacked_binary.yml gewählt. Als nächstes füllen wir es mit Inhalten. Beginnen wir mit dem Ausfüllen der Metainformationen am Anfang der Regel. Wir haben bereits alle dafür notwendigen Daten.

Wir beschreiben kurz, welche Art von Angriff die Regel im Feld erkennttitle, detailliertere Erklärungen - im Beschreibungsfeld ist es für neue Regeln üblich, den Status festzulegen: experimentell. Die eindeutige Kennung kann auf verschiedene Arten generiert werden. Unter Windows ist es am einfachsten, den folgenden Code in einem PowerShell-Interpreter auszuführen:

PS C:\> "id: $(New-Guid)"
id: b2ddd389-f676-4ac4-845a-e00781a48e5f

Der Rest der Felder spricht für sich selbst. Ich möchte nur darauf hinweisen, dass es ratsam ist, Links zu Quellen bereitzustellen, die zum Verständnis des Angriffs beigetragen haben. Dies wird Menschen helfen, die diese Regel besser verstehen, und es ist auch eine Hommage an die Bemühungen des Autors der ursprünglichen Studie, den Angriff zu beschreiben.



Unsere Regel in dieser Phase lautet wie folgt:







Als Nächstes müssen Sie die Quellen der Protokolle beschreiben. Wie oben erwähnt, werden wir uns auf Sysmon-Protokolle verlassen. Mit dem Aufkommen generischer Kategorien ist es jedoch üblich, die Kategorie process_creation zum Erstellen von Prozessen zu verwenden. Weitere Informationen zu verallgemeinerten Kategorien werden unten erläutert. Beachten Sie, dass es üblich ist, Kommentare und Ratschläge zum Konfigurieren von Quellen in das Definitionsfeld zu schreiben, z. B. Sysmon-Konfigurationsfunktionen:







Nun ist es notwendig, die Erkennungslogik zu beschreiben. Dies ist der zeitaufwändigste Teil. Dieser Angriff kann anhand vieler Kriterien erkannt werden. In unserem Beispiel wird nicht behauptet, alle möglichen Erkennungsmethoden abzudecken. Daher werden wir eine der möglichen Optionen beschreiben.



Wenn Sie sich die Ereignisse ansehen, die passiert sind, können Sie die folgende Kette erstellen.

Zuerst haben wir den Prozess (PID: 4712) mit der Startzeile c: \ windows \ system32 \ SettingSyncHost.exe -LoadAndRunDiagScript join_oscd gestartet. Beachten







Sie, dass das aktuelle Arbeitsverzeichnis des Prozesses das TEMP-Verzeichnis des Benutzers ist.



Als Nächstes erstellt der laufende Prozess eine Batchdatei und startet deren Ausführung.











Der Prozess der Ausführung von Anweisungen für Batchdateien erhielt die Kennung 7076. Bei weiterer Analyse der Ereignisse sehen wir den Start der Datei ipconfig.exe, die die in Systemdateien enthaltenen Metadaten nicht enthält und sich außerdem in dem Ordner mit temporären Dateien befindet:







Es wird vorgeschlagen, den Start von Prozessen zu berücksichtigen, deren ausführbare Dateien nicht lügen im Systemverzeichnis (C: \ Windows \ System32) und auch, wenn die Startzeile des übergeordneten Prozesses die Teilzeichenfolgen "cmd.exe / c", "RoamDiag.cmd" und "-outputpath" enthält. Lassen Sie uns dies in der Sigma-Syntax beschreiben und die endgültige Regel erhalten (eine detaillierte Analyse der Konstruktionen, die zur Beschreibung der Erkennungslogik verwendet werden können, finden Sie im nächsten Teil unserer Artikelserie über Sigma):

Überprüfen, ob die Regel funktioniert

Wir starten den Konverter in eine PowerShell-Abfrage:







In unserem Fall liefert diese Abfrage nicht das gewünschte Ergebnis, da der Ausschlussfilter auch den Pfad zum ausführbaren Dateibild des übergeordneten Prozesses findet. Daher geben wir einfach an, dass vor dem Wort Bild kein Buchstabe t stehen darf - das Ende des Wortes Eltern:







Wir sehen, dass unser Ereignis gefunden wurde. Die Regel funktioniert.



So werden Sigma-Regeln in der Praxis erstellt. Als nächstes werden wir die Felder, die für die Erkennung verantwortlich sind, detailliert beschreiben, nämlich die Beschreibung der Protokollquellen.

Beschreibung erkennen

Der Hauptteil der Regel ist die Beschreibung der Erkennung, da hier Informationen darüber enthalten sind, wo und wie nach Anzeichen eines Angriffs gesucht werden soll. Diese Informationen sind in den Feldern der Attribute Logsource (wo) und Detection (wie) enthalten. In diesem Artikel werden wir uns den Abschnitt logsource genauer ansehen und den Abschnitt zur Erkennung im nächsten Teil unserer Serie beschreiben.

Beschreibung des Abschnitts Ereignisquellen (Attribut logsource)

Die Beschreibung der Ereignisquellen ist im Wert des Felds logsource enthalten . In diesem Abschnitt werden die Datenquellen beschrieben, aus denen Ereignisse für den Erkennungsabschnitt bereitgestellt werden (das Erkennungsattribut wird im nächsten Abschnitt erläutert). Der Abschnitt beschreibt die Quelle selbst, die Plattform und die Anwendung, die für die Erkennung erforderlich sind. Es kann drei Attribute enthalten, die von Konvertern automatisch verarbeitet werden, sowie eine beliebige Anzahl optionaler Elemente. Grundfelder:

• Kategorie - beschreibt die Produktklassen. Beispiele für Werte für dieses Feld: Firewall, Web, Antivirus. Das Feld kann auch verallgemeinerte Kategorien enthalten, auf die weiter unten eingegangen wird.
• Produkt ist ein Softwareprodukt oder Betriebssystem, das Protokolle erstellt.
• Dienst - Beschränkung von Protokollen auf eine bestimmte Teilmenge von Diensten, z. B. "sshd" für Linux oder "Security" für Windows.
• Definition - Ein zusätzliches Feld zur Beschreibung der Funktionen der Quelle, z. B. Anforderungen zum Einrichten der Überwachung (selten verwendet, ein Beispiel für eine Regel mit diesem Feld finden Sie auf GitHub ). Es wird empfohlen, dieses Attribut zu verwenden, wenn die Quelle Besonderheiten aufweist.

 

Das offizielle Wiki auf GitHub definiert eine Reihe von Feldern, die verwendet werden müssen, damit die Regeln produktübergreifend sind. Diese Felder sind in der folgenden Tabelle zusammengefasst.





Als nächstes werden wir einige Protokollquellen detaillierter beschreiben, die verwendeten Ereignisfelder angeben und Beispiele für Regeln geben, in denen diese Felder verwendet werden.

Ereignisfelder für Proxy-Kategorien

Firewall-Ereignisfelder

Ereignisfelder der Webserverkategorie

Verallgemeinerte Kategorien

Da Sigma ein verallgemeinertes Format zur Beschreibung protokollbasierter Erkennungsregeln ist, sollte die Syntax solcher Regeln in der Lage sein, die Erkennungslogik für verschiedene Systeme zu beschreiben. Einige Systeme verwenden Tabellen mit aggregierten Daten anstelle von Ereignissen, und Daten aus verschiedenen Quellen können eingehen, um dieselbe Situation zu beschreiben. Um die Syntax zu vereinheitlichen und ähnliche Probleme zu lösen, wurde ein generischer Protokollquellenmechanismus eingeführt. Im Moment wurde eine solche Kategorie erstellt - process_creation. Weitere Informationen hierzu finden Sie im patzke.org-Blog . Die Liste der Felder für diese Kategorie finden Sie auf der Taxonomieseite (auf dieser Seite werden auch andere unterstützte Kategorien beschrieben).

Verallgemeinerte Kategorieereignisfelder process_creation

AKTUALISIEREN

In Vorbereitung auf diesen Artikel wurden neue generische Kategorien hinzugefügt:

• network_connection (Beispiel sysmon_powershell_network_connection )
• dns_query (Beispiel sysmon_regsvr32_network_activity )
• registry_event (Beispiel sysmon_rdp_settings_hijack )
• file_creation
• process_access (Beispiel sysmon_lsass_memdump )
• image_load (Beispiel sysmon_mimikatz_inmemory_detection )
• process_terminated

Sie alle enthalten doppelte Informationen in Windows-Protokollereignissen und Sysmon-Protokollereignissen. Wir empfehlen Ihnen, beim Schreiben Ihrer Regeln vorhandene allgemeine Kategorien zu verwenden. Da sich das Projekt aktiv weiterentwickelt, ist es ratsam, die Entstehung neuer Kategorien zu verfolgen und Ihre Regeln entsprechend weiteren Innovationen zu aktualisieren.

Nutzungsstatistik für Ereignisquellen in vorhandenen Regeln

Die folgende Tabelle zeigt die gängigsten Konstrukte zur Beschreibung von Protokollquellen. Höchstwahrscheinlich finden Sie unter ihnen diejenige, die Ihrer Regel entspricht.



Statistiken zur Verwendung einer Kombination von Beschreibungsfeldern für einige der häufigsten Quellen (Bindestrich bedeutet das Fehlen dieses Felds):

Tipps zum Schreiben von Regeln

Beim Schreiben einer neuen Regel sind folgende Situationen möglich:

1. Die richtige Ereignisquelle wurde bereits in vorhandenen Regeln verwendet.
2. Es gibt keine einzige Regel im Repository, die diese Ereignisquelle verwendet.

Wenn Sie mit dem ersten Fall konfrontiert sind, verwenden Sie eine der vorhandenen Regeln als Vorlage. Möglicherweise wird die erforderliche Protokollquelle bereits in anderen Regeln verwendet. Dies bedeutet, dass die Autoren von Plugins (Backend-Konvertern) für verschiedene SIEM-Systeme dies höchstwahrscheinlich bei ihrer Zuordnung berücksichtigt haben und Ihre Regel sofort korrekt verarbeitet werden sollte.



In der zweiten Situation ist es am Beispiel vorhandener Regeln erforderlich, zu verstehen, wie die Kennungen für Kategorien, Produkte und Dienstleistungen korrekt verwendet werden. Wenn Sie eine eigene Protokollquelle erstellen, wird empfohlen, diese allen Zuordnungen vorhandener Backends hinzuzufügen. Andere Mitwirkende oder sogar Entwickler können dies tun. Die Hauptsache ist, über einen solchen Bedarf zu informieren.



Wir haben eine Visualisierung der Kombination von Protokollquellenbeschreibungsfeldern in den vorhandenen Regeln erstellt:

Verteilung von Protokollquellen

Verwenden Sie Statistiken für Kombinationen von Logsource-Attribut-Unterfeldern

In diesem Artikel haben wir ein Beispiel für die Erstellung einer einfachen Regel gegeben und über die Beschreibung von Ereignisquellen gesprochen. Jetzt können Sie das gewonnene Wissen anwenden, die Regeln im Sigma-Repository überprüfen und herausfinden, welche Quellen in einer bestimmten Regel verwendet werden. Folgen Sie unseren Veröffentlichungen: Im nächsten Teil werden wir uns mit dem schwierigsten Teil der Sigma-Regeln befassen - dem Abschnitt, der die Erkennungslogik beschreibt.



Autor : Anton Kutepov, Spezialist der Abteilung für Expertendienste und Entwicklung positiver Technologien (PT Expert Security Center)