Kombinieren von überwachtem und unüberwachtem Machine Learning für die Erkennung von DGA

Mit großer Freude geben wir die Veröffentlichung unserer allerersten überwachten ML- und Security-Integration bekannt! Am heutigen Tag veröffentlichen wir ein Lösungspaket für überwachtes ML, das Ihnen bei der Erkennung von DGA(Domain Generation Algorithm)-Aktivität in Ihren Netzwerkdaten hilft.

Außer einem vollständig trainierten Erkennungsmodell enthält das Paket auch Ingest-Pipeline-Konfigurationen, Anomalieerkennungsjobs und Erkennungsregeln, mit denen Sie die DGA-Erkennung einfach und schnell einrichten und laufen lassen können. Wenn Sie erfahren möchten, was Sie tun müssen, um mithilfe von überwachtem Machine Learning DGA-Aktivität in Ihrem Netzwerk zu erkennen, besuchen Sie unser Erkennungsregel-Repository. Und wenn Sie noch kein Elastic Security-Nutzer sind, nutzen Sie unser Angebot, Elastic Security kostenlos auszuprobieren. 

Was sind DGAs?

DGA steht für „Domain Generation Algorithm“ und bezeichnet ein Verfahren, mit dem Malware-Entwickler versuchen, Verteidigungsmaßnahmen infizierter Client-PCs zu umgehen. Das Ziel besteht dabei darin, die Kommunikation zwischen dem infizierten Client-PC und dem Command-&-Control-Server (C2-Server oder C-&-C-Server) zu verbergen. Dazu werden Hunderte oder Tausende zufällig erzeugter Domain-Namen verwendet, die alle zur IP-Adresse eines C2-Servers führen.

Das, was bei einem DGA-Angriff abläuft, lässt sich vielleicht besser verstehen, wenn Sie sich in die Rolle eines Soldaten in einem Kampfeinsatz hineinversetzen. Wie viele Soldaten verfügen Sie über Kommunikationsausrüstung, die mit Funkfrequenzen arbeitet. Der Feind könnte versuchen, Ihre Kommunikation zu stören, indem er auf Ihren Funkfrequenzen Störsignale sendet. Eine Möglichkeit, dem einen Riegel vorzuschieben, wäre die Verwendung des sogenannten „Frequency Hopping“ (Frequenzsprungverfahren), bei dem während der Übertragung ständig in kurzen Abständen die Frequenz gewechselt wird. Für den Feind sehen diese Frequenzwechsel zufällig und unvorhersehbar aus, was es ihm erschwert, die Kommunikation zu stören.

DGAs sind wie ein Frequency-Hopping-Kommunikationskanal für Malware. Sie wechseln Domains so häufig, dass es unmöglich wird, den C2-Kommunikationskanal der Malware per DNS-Domain-Namen-Sperre zu blockieren. Es gibt einfach zu viele zufällig erzeugte DNS-Namen, um sie alle auszuprobieren, zu identifizieren und zu sperren. 

Dieses Verfahren ist 2009 eine feste Größe in der Malware-Welt. Es wurde richtig groß, als der Wurm „Conficker“ begann, für die Kommunikation eine sehr große Zahl zufällig generierter Domain-Namen zu verwenden. Damit reagierten die Wurmentwickler auf die von einem Konsortium von Security-Experten veranlasste Unterbrechung des C2-Kanals des Wurms, indem die DNS-Domains, die der Wurm für seine Kommunikation genutzt hatte, abgeschaltet wurden. Auch beim weltweiten Ausbruch der Ransomware „WannaCry“ im Jahr 2017 wurden DNS-Bekämpfungsmaßnahmen angewendet.

Tarnung ist alles

Man sagt, der beste Ort, einen Baum zu verstecken, sei der Wald. Auch Malware-Betreiber wissen seit Langem, dass die beste Möglichkeit, unentdeckt zu bleiben, darin besteht, sich als normaler Webverkehr zu tarnen. Eine HTTP-Anforderung mit einem zufällig generierten Domain-Namen ist für die Mechanismen zur Überwachung von Netzwerken und zur Erkennung von Security-Problemen eine harte Nuss. Angesichts der riesigen Mengen von HTTP-Daten in modernen Netzwerken scheidet die Möglichkeit aus, sie manuell zu prüfen. Einige Malware und Bots weisen ungewöhnliche Nutzer-Agent-Zeichenfolgen auf, die mit Suchregeln erkannt werden können. Für Malware-Entwickler ist es aber ein Leichtes, Nutzer-Agent-Zeichenfolgen zu verwenden, die denen eines Webbrowsers zum Verwechseln ähnlich sehen.

Mit der Verbreitung von mobilen und IoT-Anwendungen ist die Zahl der Nutzer-Agent-Zeichenfolgen so groß geworden, dass ein manuelles Prüfen auf verdächtige Aktivitäten ebenfalls nicht mehr möglich ist. Web-Proxys haben lange Zeit mit Kategorisierung gearbeitet, um URLs ausfindig zu machen, die bereits als verdächtig bekannt sind, aber DGA-Domains sind so voluminös und kurzlebig, dass sie sich häufig der Kategorisierung entziehen. Threat-Intelligence-Feeds können zwar IP-Adressen und HTTP-Anforderungen identifizieren, bei denen es einen Zusammenhang mit bekannten Malware-Familien und ‑Kampagnen gibt, diese Adressen und Anforderungen lassen sich von Malware-Betreibern aber so leicht ändern, dass die entsprechenden Listen für die Suche innerhalb kürzester Zeit veraltet sind.

Die schiere Masse an Daten zum Netzwerkverkehr, die in vielen Organisationen erfasst werden, sowie die Zufälligkeit, mit der DGAs Domains generieren, machen es regelbasierten Verfahren schwer, diese Aktivität zu erkennen – und erweisen sich gleichzeitig als perfekte Basis für unser Modell zum überwachten Machine Learning! Das Elastic-ML-Modell zur Erkennung von DGA-Aktivität ermittelt beim Ingestieren von Packetbeat-DNS-Daten in Ihren Elasticsearch-Cluster anhand von Inferenz automatisch, welche Domains potenziell schädlich sind. Im folgenden Abschnitt zeigen wir Ihnen, wie Sie dies einrichten können. 

Einrichten der DGA-Erkennung

Für die Einrichtung der Erkennung von DGA-Aktivität in der Security-App haben wir unserem öffentlich zugänglichen Regel-Repository ein paar neue Funktionen hinzugefügt, die beim Import von Machine-Learning-Modellen in den Elastic Stack helfen. Dieses Repository bietet unserer Community nicht nur einen Ort für die Zusammenarbeit bei der Erkennung von Threats, sondern auch die Möglichkeit, anderen Community-Mitgliedern die Tools an die Hand zu geben, die für das Testen und Validieren der Regeln nötig sind.

Wenn Sie mehr über die zugehörige Initiative erfahren möchten, sehen Sie sich unseren Blogpost und das Webinar zum Thema an. Nutzer, die noch kein Elastic Cloud-Abonnement haben, können Elastic Cloud 14 Tage lang kostenlos ausprobieren und damit beginnen, mithilfe des überwachten Machine Learnings DGA-Aktivität aufzuspüren.

Zum Regel-Toolkit gehört auch eine Befehlszeilenschnittstelle (Command Line Interface, CLI), mit der Sie nicht nur Regeln testen, sondern auch mit Ihrem Stack interagieren können. So haben wir beispielsweise verschiedene Python-Bibliotheken für die Interaktion mit der Kibana-API veröffentlicht. Damit konnten wir das Importieren der Modellabhängigkeiten vereinfachen und so die Voraussetzung für den operativen Einsatz der Regeln schaffen. Für das Anreichern von DNS-Daten und das Benachrichtigen über DGA-Aktivität sind drei Schritte erforderlich:

Schritt 1: Importieren des Modells

Als Erstes müssen Sie das DGA-Modell, Painless-Skripts und Ingest-Prozessoren in Ihren Stack importieren. DGA-Modelle und unüberwachte Modelle für die Anomalieerkennung (Weiteres ist in Planung) sind derzeit im Repo „detection-rules“ verfügbar und können über Github-Releases genutzt werden. Zum Hochladen ist der folgende CLI-Befehl zu verwenden:

python -m detection_rules es <args_or_config> experimental setup-dga-model -t <release-tag>

Nach dem Upload müssen Sie Ihre Packetbeat-Konfiguration aktualisieren, denn das Modell reichert Packetbeat-DNS-Ereignisse mit einem DGA-Wert an. Das geht recht einfach, indem Sie Ihrer Elasticsearch-Ausgabekonfiguration die folgende zusätzliche Konfiguration hinzufügen:

output.elasticsearch:
  hosts: ["your-hostname:your-port"]
  pipeline: dns_enrich_pipeline

Das überwachte Modell analysiert dann Packetbeat-DNS-Ereignisse, die die folgenden ECS-Felder enthalten, und reichert sie an:

dns.question.name
dns.question.registered_domain

Das Modell fügt diese Felder anschließend verarbeiteten DNS-Ereignissen hinzu:

Die folgende Abbildung zeigt anhand eines Screenshots ein Beispiel für angereicherte DNS-Daten:

Hinweis: Wenn Sie mehr darüber wissen möchten, sehen Sie sich bitte die „detection-rules“-Readme-Datei an.

Informationen zu den DGA-Regeln

Sehen wir uns jetzt einige Bedingungs-Suchregeln zur Erkennung von und Benachrichtigung über DGA-Aktivität an. Im Paket werden zwei Suchregeln bereitgestellt, die in der Erkennungs-Engine in der Elastic Security-App aktiviert und ausgeführt werden können:

1. Machine Learning Detected a DNS Request Predicted to be a DGA Domain
2. Machine Learning Detected a DNS Request With a High DGA Probability Score

Die erste Regel fördert DNS-Ereignisse zutage, bei denen der Wert des Feldes „ml_is_dga.malicious_prediction“ 1 ist, weil der DNS-Domain-Name wahrscheinlich das Ergebnis von DGA-Aktivität und damit verdächtig ist. Die Regel, die Sie hier finden, sucht einfach nach der folgenden Bedingung:

event.category:network and network.protocol:dns and ml_is_dga.malicious_prediction: 1

Die zweite Regel fördert DNS-Ereignisse zu Tage, bei denen der Wert des Feldes „ml_is_dga.malicious_probability“ größer als 0.98 ist, was darauf hindeutet, dass der DNS-Domain-Name mit einiger Wahrscheinlichkeit das Ergebnis eines DGA und damit verdächtig ist. Die Regel, die Sie hier finden, sucht einfach nach der folgenden Bedingung:

event.category:network and network.protocol:dns and ml_is_dga.malicious_probability > 0.98

Wie alle Regeln in der Elastic-Erkennungs-Engine können auch diese geforkt und an die lokalen Bedingungen angepasst werden. Wenn Sie der Ansicht sind, dass ein anderer Wahrscheinlichkeitswert für Ihre DNS-Ereignisse besser geeignet ist, kann der Wahrscheinlichkeitswert in der zweiten Regel nach oben oder unten korrigiert werden. Bei beiden Regeln ist es möglich, den Risikowert anzupassen, wenn die Priorität von DGA-Erkennungsregeln in Ihrer Alert-Warteschlange erhöht werden soll. Sie können den Regeln Ausnahmen hinzufügen, um zu erreichen, dass falsch-positive Ergebnisse, wie z. B. CDN(Content Distribution Network)-Domains, bei denen durchaus pseudozufällige Domain-Namen zum Einsatz kommen können, ignoriert werden.

Eine weitere Möglichkeit, die wir gern nutzen möchten, ist die Verwendung von EQL (Event Query Language) für die Suche nach Anomalie-Clustern oder suchbasierte Alerts mit Mehrfachkorrelation. Wenn wir zum Beispiel einen Cluster von Alerts von einem Host sehen, der mit möglicher DGA-Aktivität in Zusammenhang gebracht wird, können wir einigermaßen sicher sein, dass es sich im konkreten Fall um Malware handelt, die unserer Aufmerksamkeit bedarf.

Ein solcher Cluster könnte aus DGA-Alerts in Kombination mit anderen Anomalieerkennungs-Alerts (z. B. seltener Prozess, Netzwerkprozess, Domain oder URL) bestehen. Diese zusätzlichen Anomalieerkennungsregeln werden von der ML-Paket-Bibliothek in der Elastic Security-App erzeugt.

Schritt 2: Importieren der Regeln

Die Regeln im DGA-Paket können mit der Kibana-Funktion „upload-rule“ in der „detection-rules“-CLI (im Format .toml) importiert werden. Da die im Repo „detection-rules“ releases bereitgestellten Repos im Format .toml vorliegen, reicht es, zum Hochladen der Regel aus dem Repo den folgenden Befehl auszuführen:

python -m detection_rules kibana upload-rule -h
Kibana client:
Options:
  --space TEXT Kibana space
  -kp, --kibana-password TEXT
  -ku, --kibana-user TEXT
  --cloud-id TEXT
  -k, --kibana-url TEXT
Usage: detection_rules kibana upload-rule [OPTIONS] TOML_FILES...
  Upload a list of rule .toml files to Kibana.
Options:
  -h, --help  Show this message and exit.
  -h, --help  Show this message and exit.

Schritt 3: Regel aktivieren und Ernte einfahren

Nachdem wir nun das trainierte überwachte ML-Modell in den Stack importiert, DNS-Ereignisse angereichert und Regeln zur Verfügung haben, müssen wir nur noch bestätigen, dass die Regel gelten soll, und auf die ersten Alerts warten. 

Wie es aussehen muss, wenn die Regel in der Erkennungs-Engine aktiviert ist, sehen Sie in der folgenden Abbildung:

Und jetzt warten wir darauf, dass die ersten Alerts eintreffen. Sobald ein Alert generiert wird, können Sie beginnen, das DNS-Ereignis mithilfe der Timeline-Funktion zu untersuchen.

Bedenken Sie jedoch, dass auch Machine-Learning-Modelle niemals perfekt sind! Es kann und wird vielleicht auch passieren, dass harmlose Domains fälschlicherweise als Ergebnis eines DGA-Angriffs eingestuft werden. Im folgenden Abschnitt sehen wir uns an, wie Sie die vorkonfigurierten Anomalieerkennungsjobs und zugehörigen Regeln nutzen können, die mit dieser Version ausgeliefert werden, um die Ausgabe falsch-positiver Ergebnisse zu justieren.

Falsch-positive Ergebnisse? Anomalieerkennung vor!

Bei jedem Erkennungsverfahren gibt es immer auch falsch-positive Ergebnisse. Diese können das Resultat von CDN-Verkehr oder benutzerdefinierten Domains sein, die schädlich aussehen, aber in ihrer Umgebung ganz normal sind. Um sicherzustellen, dass sich unsere DGA-Erkennung an die konkrete Umgebung des Nutzers anpasst, haben wir einen vorkonfigurierten Anomalieerkennungsjob namens experimental-high-sum-dga-probability erstellt. Nach seiner Aktivierung prüft dieser ML-Job die vom überwachten DGA-Modell generierten DGA-Werte und sucht nach anomalen Mustern ungewöhnlich hoher Werte für eine bestimmte Quell-IP-Adresse. Diesen Ereignissen wird dann ein Anomaliewert zugeordnet.

Damit Sie die Vorteile des Anomalieerkennungsjobs bestmöglich genießen können, packen wir noch eine ergänzende Regel oben drauf: Potenzielle DGA-Aktivität. Diese erzeugt auf der Erkennungs-Engine-Seite der Security-App einen anomaliebasierten Alert.

Sowohl der vorkonfigurierte Anomalieerkennungsjob als auch die ergänzende Regel sind in unserem Erkennungsregel-Repo releases zu haben. 

Auswahl der richtigen Konfiguration für Ihre Umgebung

Alles fängt mit dem überwachten DGA-Modell an. Jede per Packetbeat ingestierte DNS-Anforderung wird vom Modell analysiert und mit einem Wahrscheinlichkeitswert versehen, der besagt, wie wahrscheinlich es ist, dass die fragliche Domain schädlich ist. Mithilfe der im Abschnitt „Einrichten der DGA-Erkennung“ besprochenen Bedingungslogikregeln können Sie die Ergebnisse des überwachten Modells direkt in der Security-App verwenden oder unseren vorkonfigurierten Anomalieerkennungsjob und die Regeln importieren und aktivieren, um die Erkennung an die konkreten Gegebenheiten Ihrer Umgebung anzupassen. 

Wie finden Sie nun die richtige Konfiguration für Ihre Umgebung? Fangen Sie mit einer einfachen Konfiguration an. Aktivieren Sie die Bedingungsregeln für die Suche, wie im Abschnitt „Einrichten der DGA-Erkennung“ beschrieben. Diese Regeln wirken sich direkt auf die Ausgaben des überwachten Modells aus und vermitteln schnell ein Bild davon, wie viel falsch-positives Hintergrundrauschen es in Ihrer Umgebung gibt. Wenn Sie den Eindruck haben, dass die auf die direkten Ausgaben des überwachten Modells angewendeten Bedingungsregeln für die Suche zu viele Alerts erzeugen, lohnt es sich möglichweise für Sie, den Anomalieerkennungsjob zu importieren und zu aktivieren. 

Insbesondere die ML-Erkennungsregel, die auf die Ergebnisse des Anomalieerkennungsjobs angewendet wird, kann sich für das Finden von Quellen mit aggregiert hohem Aufkommen von DGA-Aktivität als sinnvoller erweisen als Benachrichtigungen über einzelne DGA-Werte. Wenn das Modul bei Ihnen noch nicht im Einsatz ist, nutzen Sie unser Angebot eines kostenlosen Probeabonnements oder probieren Sie es in Elastic Cloud aus.

Die folgenden Abbildungen zeigen Beispiele für das Anomalieerkennungsmodell und die zugehörigen Regeln, die mit der neuen Version bereitgestellt werden:

Fallstudie aus der Praxis: Erkennung von DGA-Aktivität beim SUNBURST-Angriff

Lassen Sie uns einmal versuchen, diesen experimentellen DGA-Workflow auf die SUNBURST-Kampagne anzuwenden, die seit Dezember Schlagzeilen macht. 

Zur Erinnerung: Am 13. Dezember 2020 veröffentlichte SolarWinds eine Security Advisory bezüglich eines erfolgreichen Lieferkettenangriffs (supply-chain attack) auf die Netzwerkverwaltungsplattform Orion. Derzeit sind von diesem Angriff Orion-Versionen mit einem Veröffentlichungsdatum zwischen März und Juni 2020 betroffen. Ebenfalls am 13. Dezember 2020 informierte FireEye über eine globale Kampagne, die sich Schwachstellen in der SolarWinds-Lieferkette zunutze machte und einige Versionen der Software Orion betraf.

Wir haben damals einen Blogpost veröffentlicht, der sich damit beschäftigt, wie sich der allgemein unter dem Namen SUNBURST bekannt gewordene Angriff auf SolarWinds auf Elastic-Nutzer auswirkt. In diesem Blogpost wird darauf hingewiesen, dass die Elastic Security-Technologie zum Schutz vor Malware, die sowohl in Elastic Endgame als auch bei der Elastic-Endpoint-Security zum Einsatz kommt, so aktualisiert worden ist, dass sie die in der SolarWinds-Mitteilung beschriebenen Angriffe erkennt.

Bei SUNBURST handelte es sich um einen technisch fortgeschrittenen Angriff auf die Softwarelieferkette, der den Berichten zufolge Malware in das SolarWinds-Produkt Orion einschleuste und diese mithilfe eines Auto-Update-Mechanismus verteilte. Die Größe, der Umfang und das Ausmaß des Vorfalls werden derzeit noch untersucht. 

Bestehende Elastic Security-Erkennungsmechanismen

Ein Security-Experte hat eine Liste von 1722 DGA-generierten Domain-Namen veröffentlicht, die von der SUNBURST-Malware genutzt worden sind. Eine der bestehenden ML-basierten Erkennungsregeln in Elastic Security, „DNS Tunneling“, erzeugt zwei anomaliebasierte Alerts für die DNS-Namen in dieser Liste. Ähnlich wie bei „DNS Tunneling“ ist das Verhältnis von untergeordneten zu übergeordneten Domains in der Liste der SUNBURST-Domain-Namen sehr hoch. Der mit dieser Regel verknüpfte ML-Job ist auf das Analysieren von Packetbeat-Daten ausgerichtet, aber er kann geklont und so geändert werden, dass er andere DNS-Ereignisse im ECS(Elastic Common Schema)-Format ingestiert. Der „DNS Tunneling“-ML-Job sieht wie folgt aus:

Mit diesem ML-Job ist eine Erkennungsregel namens „DNS Tunneling“ verknüpft:

Mithilfe von Elastic Security-Regeln lassen sich diese Anomalieerkennungsregeln (siehe unten) in Erkennungs-Alerts und optionale Benachrichtigungen umwandeln, um sie in die entsprechenden Warteschlangen für die Incident-Einstufung und Incident-Reaktion einzureihen. In der Elastic Machine Learning-App sehen die SUNBURST-Anomalieerkennungsregeln wie folgt aus:

Dies ist zweifelsohne eine nützliche Erkennungsregel, aber es kann passieren, dass sie nicht immer sämtliche DGA-Aktivität erkennt. Um die DGA-Erkennung zu stärken, veröffentlichen wir den experimentellen DGA-Erkennungs-Workflow.

Der experimentelle DGA-Workflow

Wir haben festgestellt, dass der experimentelle ML-basierte DGA-Erkennungs-Workflow den größten Teil dieser Aktivität erkennen kann. Dazu haben wir das hier besprochene überwachte DGA-Erkennungsmodell (Näheres zum Herunterladen und Ausführen des Modells und seiner Regeln finden Sie oben) auf die Liste der SUNBURST-DGA-Domains angewendet. Das Modell hat 82 % der Namen auf der Liste als DGA-generiert gekennzeichnet, was zu 1420 Alerts geführt hätte. Der folgende Screenshot zeigt die SUNBURST-DNS-Namen, die vom überwachten Modell als DGA-Aktivität markiert wurden:

Diese Ereignisse können mithilfe der Erkennungsregel Machine Learning Detected a DNS Request Predicted to be a DGA Domain in Erkennungs-Alerts umgewandelt werden. Wir können auch eine Kopie dieser Regel anfertigen und sie so ändern, dass sie die beobachtete übergeordnete Domain findet, die von einer bestimmten Malware-Instanz wie SUNBURST verwendet wird. Um das Finden der SUNBURST-DGA-Ereignisse in dieser Liste zu ermöglichen, können wir der Regelabfrage den folgenden Test hinzufügen:

network.protocol:dns and ml_is_dga.malicious_prediction: 1 and dns.question.registered_domain: "avsvmcloud.com"

Anschließend können wir dieser Regel eine kritische Priorität und einen hohen Risikowert von 99 zuweisen, um sie in der Alert- und Analyse-Warteschlange ganz weit nach vorn zu schieben. Der folgende Screenshot zeigt Alerts, die von der Regel generiert wurden, nachdem sie so umgeschrieben worden ist, dass sie SUNBURST-DGA-Aktivität erkennt:

Wir haben in das Paket die Regel Machine Learning Detected DGA activity using a known SUNBURST DNS domain aufgenommen. Unter Praxisbedingungen könnte eine Population hochfrequenter Malware-Instanzen, die mit DGA arbeiten, so viele Alerts produzieren, dass der standardmäßige „max_signals“-Schwellenwert von 100 überschritten wird. In einem solchen Fall hätten wir Alerts für einige Malware-Instanzen, aber nicht für andere. Welche erfasst werden, hinge davon ab, welche Ereignisse von der Suche zuerst gefunden werden. 

Um nun sicherzustellen, dass wir mehr von den Hosts finden, die an der DGA-Aktivität beteiligt sind, haben wir den „max_signals“-Wert in den DGA-Suchregeln auf 10.000 hochgesetzt. Hinweis: Diese Einstellung lässt sich nicht im Regeleditor bearbeiten. Sie muss in einer externen Regeldatei geändert und dann importiert werden. Die Einstellung kann beobachtet werden, indem eine Regeldatei in einem Editor betrachtet wird.

Bei starker DGA-Aktivität und einer damit einhergehenden großen Zahl von Alerts können wir die DGA-Alerts oder Ereignisse auch aggregieren und sieben, um sie in einer Datentabelle wie der folgenden nach Hostname oder Quellen-IP-Adresse zu filtern und zu zählen:

Wir fügen auch ein Beispiel-Dashboard für Packetbeat-DGA-Ereignisse mit Visualisierungen und Aggregationen bei, einschließlich dieser Datentabellenvisualisierung, die nach der Quellen-IP-Adresse („source.ip“) aggregiert wird. Sie können stattdessen auch nach dem Hostnamen („host.name“) aggregieren, wenn Ihre DNS-Ereignisse ein entsprechendes Feld enthalten. Diese Datei heißt „dga-dashboard.ndjson“ und kann in Kibana importiert werden, indem Sie auf der Seite Saved Objects, die Sie nach dem Auswählen von Stack Management finden, Import wählen.

Die folgende Abbildung zeigt, wie dieses Dashboard DGA-Ereignisse in einem „packetbeat-*“-Index darstellt:

Wir sind für Sie da

Sie sind nicht allein! Wenn Sie auf Probleme stoßen oder einfach nur mehr über unsere Herangehensweise an die Erkennung von Bedrohungen und das Machine Learning erfahren möchten, sind wir für Sie da. Sie erreichen uns über unseren Community-Slack-Kanal und unsere Diskussionsforen. Oder Sie packen mit an und leisten Ihren eigenen Beitrag zur Weiterentwicklung unseres offenen Erkennungsregel-Repositorys. Vielen Dank und viel Spaß!