Verstecken spielen

Nov 03, 2023

21. Oktober 2022

In Teil 1 haben wir erklärt, was Intel SGX-Enklaven sind und welchen Nutzen sie für Ransomware-Autoren haben. In Teil 2 untersuchen wir eine hypothetische schrittweise Implementierung und skizzieren die Einschränkungen dieser Methode.

Sehen Sie sich diese Live-Angriffsdemo an, um zu erfahren, wie die CrowdStrike Falcon®-Plattform und das von CrowdStrike Falcon Complete™ verwaltete Erkennungs- und Reaktionsteam vor Ransomware schützen.

In diesem Abschnitt erstellen wir Schritt für Schritt ein Beispiel für eine Ransomware, die Enklaven für asymmetrische Verschlüsselung verwendet. Die Ransomware gliedert sich in zwei Teile:

Auszüge des hier vorgestellten Codes stammen aus dem regulären Kern der Anwendung (main.c) oder aus der Enklave (enclave.c). Die Enklave generiert ein Paar RSA-Schlüssel, versiegelt den privaten Schlüssel und verschlüsselt die Daten des Opfers innerhalb der Enklave mithilfe der Intel SGX-API. Werfen wir einen Blick darauf, wie dies geschieht und wie der Kern der Anwendung mit der Enklave interagiert.

Zunächst initialisiert der reguläre Kern der Anwendung die für die Ransomware-Ausführung erforderlichen Ressourcen, einschließlich der Erstellung und Einrichtung der Enklave. Um die Enklave zu laden, verwenden wir die Funktion sgx_create_enclave() aus sgx_urts.lib.1. Der Funktionsprototyp ist:

Argumente dieser Funktion stellen einige der Enklavenattribute dar, beispielsweise den Kompilierungsmodus oder Informationen zu früheren Ladevorgängen. Beispielsweise ist sgx_launch_token_t eine undurchsichtige Struktur, die das Enklave-Starttoken darstellt. Die Token-Informationen enthalten während der gesamten Ausführung Informationen über die Enklave und können gespeichert werden, um zukünftige Ladevorgänge der Enklave zu erleichtern.

Abbildung 1. Auszug aus dem Code, der die Enklave erstellt (zum Vergrößern anklicken)

Sobald die Enklave geladen ist, kann der reguläre Kern der Anwendung einen ECALL ausführen, um den Schlüsselgenerierungsprozess zu starten.

Innerhalb der Enklave basiert die Schlüsselgenerierung auf dem Intel SGX SDK mit der Bezeichnung sgx_tcrypto.lib. Dies ist eine dokumentierte API, die direkt von der Enklave aus aufgerufen werden kann. Unter der Haube basiert die API auf anderen von Intel entwickelten kryptografischen Bibliotheken: den Integrated Performance Primitives (Intel® IPP) und der kryptografischen Bibliothek Intel® Software Guard Extensions SSL (Intel® SGX SSL),2 die beide auf OpenSSL basieren .

Der erste Schritt in diesem Prozess besteht darin, mithilfe der Funktion sgx_create_rsa_key_pair() RSA-Komponenten für den privaten und den öffentlichen Schlüssel aus der Enklave zu generieren. Dabei handelt es sich um einen vorläufigen Aufruf, der vor den Funktionsaufrufen zum Erstellen von Schlüsseln durchgeführt wird und dazu dient, Komponenten zu generieren, die der vordefinierten RSA-Schlüsselmodulgröße und dem öffentlichen Exponenten entsprechen.

Abbildung 2. Auszug aus dem Code, der die RSA-Schlüsselkomponenten generiert (zum Vergrößern anklicken)

Aus diesen RSA-Schlüsselkomponenten verwenden wir die Funktion sgx_create_rsa_pub1_key(), um den öffentlichen RSA-Schlüssel zu generieren, der zum Verschlüsseln der Dateien des Opfers verwendet wird.

Abbildung 3. Auszug aus dem Code zur Erstellung des öffentlichen RSA-Schlüssels (zum Vergrößern anklicken)

Der nächste logische Schritt wäre normalerweise die Generierung des privaten Schlüssels, wie wir es mit dem öffentlichen Schlüssel getan haben. In diesem Fall benötigen wir den privaten Schlüssel jedoch noch nicht, da der private Schlüssel nur zu Entschlüsselungszwecken verwendet wird, sofern das Opfer den Forderungen der Ransomware-Autoren nachkommt. Zu diesem Zeitpunkt müssen wir lediglich die privaten Schlüsselkomponenten sicher speichern und verstecken, um einen zukünftigen Abruf zu ermöglichen. Zu diesem Zweck verwenden wir die Datenversiegelungsmethode, um sicherzustellen, dass der private Schlüssel verschlüsselt auf der Festplatte geschrieben und gespeichert werden kann, ohne jemals als Klartext im regulären Speicher des Betriebssystems zu erscheinen.

Eine Möglichkeit, dies zu tun, besteht darin, den privaten Schlüssel zu generieren und ihn dann direkt auf der Festplatte zu versiegeln. Wir werden jedoch nicht auf diese Weise vorgehen. Betrachten Sie den Funktionsprototyp des Intel SGX SDK3, der den unten gezeigten privaten Schlüssel generiert.

Beachten Sie, dass der Wert des privaten Schlüssels in ein Leerzeichen** geschrieben wird, aber unter der Haube handelt es sich bei der tatsächlich verwendeten Struktur um eine EVP_PKEY-Struktur, eine komplexe Struktur, die aus der OpenSSL-Bibliothek stammt.

Abbildung 4. Auszug aus dem Code, der die EVP_PKEY-Struktur definiert, aus der OpenSSL-Bibliothek (zum Vergrößern anklicken)

Wenn wir daher den privaten Schlüssel versiegeln wollten, müssten wir die Struktur EVP_PKEY verwenden. Allerdings ist die Entwicklungsarchitektur von Enclave nicht für den einfachen Import externer Bibliotheken ausgelegt, sodass die direkte Verwendung der Open SSL-Bibliothek umständlich wäre. Andernfalls könnten wir versuchen, die Struktur von Grund auf neu zu erstellen, was jedoch mehrere Analysevorgänge erfordern würde. Angesichts der Komplexität der Speicherung des privaten Schlüssels in der entsprechenden Struktur ist es viel einfacher, die Komponenten des privaten Schlüssels zu speichern und den privaten Schlüssel zu einem späteren Zeitpunkt zu erstellen. Um diesen Prozess zu unterstützen, haben wir eine Struktur zum Sammeln der privaten Schlüsselkomponenten erstellt.

Abbildung 5. Auszug aus dem Code, der die PrivateKey-Struktur definiert (zum Vergrößern anklicken)

Wir haben jetzt die Möglichkeit, die privaten Schlüsselkomponenten für eine mögliche zukünftige Entschlüsselung zu versiegeln. Wir verwenden dieselben Werte, die bei der Generierung der Schlüsselkomponenten erzeugt wurden, und weisen sie den entsprechenden Feldern in unserer benutzerdefinierten PrivKeyComp-Struktur zu. Sobald die Struktur korrekt eingerichtet ist, können wir die privaten Schlüsselkomponenten mit sgx_seal_data_ex() aus sgx_tservice.lib.4 versiegeln

Abbildung 6. Auszug aus dem Code, der die RSA-Privatschlüsselkomponenten versiegelt (zum Vergrößern anklicken)

Hier verwenden wir sgx_seal_data_ex(), die erweiterte Version von sgx_seal_data(), die uns die Verwendung der MRENCLAVE-Richtlinie ermöglicht. Wir haben diese Richtlinie gewählt, weil sie garantiert, dass andere Enklaven, die von den Autoren derselben Enklave signiert wurden, nicht auf die versiegelten Daten zugreifen können. Sollte die Enklavensignatur des Angreifers gestohlen werden, könnte sie zum Entschlüsseln der Daten verwendet werden.

Nach der Versiegelung können die privaten Schlüsselkomponenten an den regulären Kern der Anwendung zurückgegeben und auf die Festplatte geschrieben werden.

Ab diesem Zeitpunkt haben wir zwei Möglichkeiten, die Daten des Opfers zu verschlüsseln. Die erste Möglichkeit besteht darin, den öffentlichen Schlüssel an den regulären Kern der Anwendung zurückzugeben und die Dateien des Opfers außerhalb der Enklave zu verschlüsseln. Die andere Möglichkeit besteht darin, den öffentlichen Schlüssel innerhalb der Enklave zu behalten und Funktionen der Intel SGX-API zu verwenden, um die Daten des Opfers zu verschlüsseln. Letzteres ist komplexer als ein klassisches Verschlüsselungsverfahren außerhalb der Enklave, wir werden diese Methode jedoch nutzen, um Möglichkeiten der SGX-Programmierung zu demonstrieren.

Der nicht vertrauenswürdige Teil der Anwendung ist für das Öffnen und Lesen der Akte des Opfers zuständig. Um die verschlüsselten Daten zu erhalten, die innerhalb der Enklave generiert werden, müssen wir den Ausgabepuffer im regulären Kern der Anwendung initialisieren. Andernfalls kann der im geschützten Speicher generierte Puffer nicht an den nicht vertrauenswürdigen Bereich gesendet werden.

Die Verschlüsselung erfolgt mit der Funktion sgx_rsa_pub_encrypt_sha256(), die ein RSA-OAEP-Verschlüsselungsschema mit SHA-256 durchführt. Dabei wird eine Verschlüsselungs- und Kodierungsoperation für Puffer berechnet, die auf die Größe des RSA-Moduls n beschränkt ist und zu einem Puffer gleicher Länge führt. In diesem Fall ist der Ausgabepuffer von sgx_rsa_pub_encrypt_sha256() bei einem RSA-Modul n von 256 Bytes 256 Bytes lang.5 Daher weisen wir dem Ausgabepuffer, der die verschlüsselten Daten enthält, einen Puffer von 256 Bytes zu.

Als Nächstes senden wir diesen Ausgabepuffer zusammen mit dem Puffer, der die zu verschlüsselnden Daten enthält.

Abbildung 7. Auszug aus dem Code, der den Inhalt einer Datei verschlüsselt, aus der Hauptdatei (zum Vergrößern anklicken)

Die Enklave empfängt die Puffer und verwendet den zuvor generierten öffentlichen Schlüssel, um die Verschlüsselung durchzuführen. Dies erfolgt in drei Schritten. Der erste Schritt ist der Aufruf von sgx_rsa_pub_encrypt_sha256(), um die Größe des resultierenden verschlüsselten Puffers zu ermitteln. Sobald die Größe zurückgegeben wird, überprüfen wir, ob sie 256 Bytes entspricht (der Größe, die wir dem Ausgabepuffer zugewiesen haben). Wenn es übereinstimmt, führen wir einen zweiten Aufruf von sgx_rsa_pub_encrypt_sha256() durch, um die verschlüsselten Daten im Ausgabepuffer abzurufen.

Abbildung 8. Auszug aus dem Code, der den Inhalt einer Datei verschlüsselt, aus der Enklave (zum Vergrößern anklicken)

Schließlich überschreibt der reguläre Kern der Anwendung den ursprünglichen Dateiinhalt mit dem verschlüsselten Inhalt, der von der Enklave zurückgegeben wird.

Die gleiche Logik gilt für den Entschlüsselungsprozess. Die versiegelten Daten werden an die Enklave gesendet, die sie mit sgx_unseal_data() entsiegelt und die privaten Schlüsselkomponenten in der globalen Variablen PrivKeyComp speichert. Verschlüsselte Daten werden an die Enklave gesendet, der private Schlüssel wird mithilfe der globalen Variablen PrivKeyComp als Parameter für sgx_create_rsa_priv2_key() erstellt und die Daten werden dann mit der Funktion sgx_rsa_priv_decrypt_sha256() entschlüsselt. Die entschlüsselten Daten werden dann an den regulären Kern der Anwendung zurückgegeben, der verschlüsselte Dateien mit dem ursprünglichen Klartext überschreibt.

Wie wir festgestellt haben, hat die Verwendung von Enklaven erhebliche Vorteile, z. B. stellt sie sicher, dass Ransomware-Ziele nicht in der Lage sind, ihre Entschlüsselungsschlüssel abzurufen. Allerdings weist diese Taktik auch erhebliche Einschränkungen auf, die ihre begrenzte Verbreitung bei Ransomware-Angriffen erklären.

Erstens haben Enklaven strenge Hardware-Spezifikationen. Da es sich bei SGX um eine proprietäre Technologie handelt, ist eine Intel-CPU erforderlich. Obwohl AMD über eine entsprechende Technologie namens ARM TrustZone verfügt, funktioniert Code, der auf Basis von Intel SGX-Bibliotheken kompiliert wurde, nicht auf Nicht-Intel-CPUs. Darüber hinaus unterstützen nur bestimmte Intel-CPU-Modelle SGX, da Intel die Funktion für die Desktop-Generationen mit 11. und 12. Kernprozessoren nicht mehr unterstützt.6 Als letzte Hardwareanforderung muss die Intel SGX-Funktion über das BIOS aktiviert werden, was nicht erfolgt Standard.

Angesichts all dieser Anforderungen ist die Wahrscheinlichkeit, dass ein Zielsystem eine Binärdatei mithilfe von Enklaven ausführen kann, sehr gering. Da die Nutzung der SGX-Technologie möglicherweise nicht auf jedem infizierten System aktiviert ist, sind die Chancen, ein Ziel erfolgreich zu infizieren, erheblich gering, insbesondere im Vergleich zu gängigeren Ransomware-Methoden.

Zu Beginn dieses Blogs haben wir erklärt, dass Enklaven einen Verifizierungsprozess abschließen müssen, um im Release-Modus kompiliert zu werden. Dennoch kann eine im Debug-Modus kompilierte Enklave weiterhin auf einem Intel SGX-fähigen Computer ausgeführt werden, wenn die erforderlichen Bibliotheken mit der schädlichen Binärdatei importiert werden. Die Größe der für den Angriff erforderlichen Binärdateien wäre viel größer als die einer klassischen Ransomware-Binärdatei, aber ein solches Szenario ist plausibel.

Wenn Angreifer darüber hinaus beabsichtigen, eine Enklave im Freigabemodus zu verwenden, bleiben sie möglicherweise vom Intel-Verifizierungsprozess unentdeckt, wenn die Enklave nur scheinbar ein Paar RSA-Schlüssel generiert und Puffer zum Verschlüsseln und Versiegeln von Daten empfängt. Wie würde Intel in einer solchen Situation feststellen, ob die Enklave böswilligen Zwecken dient?

Forscher der Technischen Universität Graz behaupten, dass „Intel keine einzelnen Enklaven inspiziert und signiert, sondern Signaturschlüssel auf weiße Listen setzt, die nach Ermessen der Enklavenentwickler zum Signieren beliebiger Enklaven verwendet werden sollen.“7 Sie führen das Beispiel eines unabhängigen Studenten an, der dies getan hat Intels Prozess zur Erlangung eines Signaturschlüssels wurde erfolgreich abgeschlossen. Dies wirft die Frage auf, ob Malware-Autoren Enklaven nutzen könnten, indem sie den Whitelist-Prozess von Intel durchlaufen.

Eine weitere Möglichkeit für Ransomware-Autoren wäre der Diebstahl einer legitimen Signatur. Dies erhöht die Komplexität des Angriffs noch weiter, wurde jedoch bereits in der Vergangenheit durchgeführt. In diesem Fall entfernt Intel die verwendete Enklave-Signatur von der Zulassungsliste, sobald der Angriff erkannt und an Intel gemeldet wird, und verhindert so das Laden der bösartigen Enklave. Unabhängig davon, ob die Signatur gestohlen oder rechtmäßig erworben wurde, steigt das Risiko einer Entdeckung schnell, sobald die Ransomware-Kampagne im Gange ist, was die Frage nach der Gültigkeitsdauer der Signatur aufwirft.

Um mehr Flexibilität bei der Nutzung von Enklaven zu bieten, veröffentlichte Intel 2018 die flexible Launch-Control-Alternative.8 Mit dieser Funktion können Dritte steuern, welche Enklaven auf entsprechend konfigurierten Maschinen geladen werden können, und so den Intel-Verifizierungsprozess umgehen. Es erfordert, dass die Zielmaschinen die flexible Startsteuerungsfunktion unterstützen und aktivieren, die im BIOS jeder Maschine konfiguriert ist. Dieser Ansatz erfordert Zugriff auf das BIOS vor der Infektion und Administratorrechte zum Konfigurieren der Umgebung, was den Angriff komplexer macht.

Innerhalb der Enklave wird Code in einem bestimmten Kontext ausgeführt, was zu einer langsameren Ausführung als in einer regulären Betriebssystemumgebung führt. Je länger die Ausführung der Ransomware dauert, desto wahrscheinlicher ist es, dass der Benutzer auf verdächtige Aktivitäten aufmerksam gemacht wird und Zeit hat, darauf zu reagieren, was die Chancen auf einen erfolgreichen Angriff weiter gefährdet.

Intel betrachtet Seitenkanalangriffe nicht als Teil des SGX-Bedrohungsmodells. Im Intel® Software Guard Extensions Developer Guide9 heißt es: „Intel SGX bietet keinen expliziten Schutz vor Seitenkanalangriffen. Es liegt in der Verantwortung des Enklavenentwicklers, Bedenken hinsichtlich Seitenkanalangriffen auszuräumen.“

Dies impliziert, dass es Möglichkeiten gibt, zu beobachten, was innerhalb einer Enklave geschieht, und so möglicherweise den Entschlüsselungsschlüssel abzufangen, was weiter unterstreicht, dass die Verwendung von Enklaven alles andere als narrensicher ist und in der Vergangenheit erfolgreich durchgesickert ist, was im Papier „SGAxe: How“ besprochen wird SGX versagt in der Praxis.“10

Es gibt auch Grenzen für die Sicherheit des auf die Festplatte geschriebenen versiegelten Schlüssels.

Im Entwicklerleitfaden von Intel heißt es: „Enklaven dürfen unabhängig von der Anzahl der definierten vertrauenswürdigen Threads nicht mit der Annahme entworfen werden, dass die nicht vertrauenswürdige Anwendung die ISV-Schnittstellenfunktionen in einer bestimmten Reihenfolge aufruft. Sobald die Enklave initialisiert ist, kann ein Angreifer beliebige aufrufen.“ ISV-Schnittstellenfunktion, ordnen Sie die Aufrufe in beliebiger Reihenfolge an und stellen Sie beliebige Eingabeparameter bereit. Behalten Sie diese Tricks im Hinterkopf, um zu verhindern, dass eine Enklave für Angriffe geöffnet wird.“11

Eine aktuelle Frage im Community-Forum von Intel stellte die Frage, ob verschiedene Anwendungen dieselbe Enklave verwenden. Intel antwortete darauf: „Es gibt keine eingebaute Möglichkeit, zu verhindern, dass eine nicht vertrauenswürdige App die Enklave einer anderen lädt.“12 Daher sollten forensische Ermittler die Enklave abrufen Wenn sie die Binärdatei, die bei einem Ransomware-Angriff verwendet wird, und den versiegelten privaten Schlüssel verwenden, können sie möglicherweise eine Anwendung neu erstellen, die mit der Enklave interagiert, um sie dazu zu bringen, den privaten Schlüssel zu entsiegeln, zumindest im Debug-Modus.

In der Praxis erfordert die Erstellung einer solchen Anwendung den Import der Enclave-EDL-Datei, die die ECALLs-Definition enthält. Da es unwahrscheinlich ist, dass diese Datei in die Binärdateien des Angriffs importiert wird, besteht die einzige Möglichkeit darin, die .edl-Datei wiederherzustellen, was noch komplizierter werden könnte, wenn Angreifer die Binärdateien der Enklave verschleiern.

In einem Szenario, in dem der private Schlüssel mithilfe der MRSIGNER-Richtlinie versiegelt wurde, ist die Sicherheit des versiegelten Schlüssels noch fraglicher. Wenn forensische Ermittler in der Lage sind, die Signatur des Autors der Enklave abzurufen, könnten sie mit Unterstützung von Intel eine ähnlich signierte Enklave neu erstellen und diese neue Enklave veranlassen, die Daten zu entsiegeln. Da die Daten tatsächlich mit der Signatur des Enklavenautors versiegelt wurden, wäre eine andere Enklave mit derselben Signatur in der Lage, sie zu entsiegeln.

Obwohl jede dieser Einschränkungen den Angriff einschränkt, können sie alle dennoch gemildert werden. Die Aktivierung der SGX-Funktion kann mit ein paar Schritten vor der Infektion umgangen werden. Um die Nutzung von Enklaven zu erleichtern, hat Intel eine Aktivierungs-App13 veröffentlicht, mit der Benutzer Intel SGX auf kompatiblen Intel Core-basierten Prozessorplattformen aktivieren können, indem sie einfach auf die Schaltfläche „Aktivieren“ klicken, wie in Abbildung 9 dargestellt. Die Anwendung muss aktiviert sein Mit Administratorrechten ausgeführt, aber ein Social-Engineering-Ansatz könnte ein Opfer leicht dazu bringen, in einer legitimen Anwendung auf eine Schaltfläche zu klicken.

Abbildung 9. Screenshot der Aktivierungs-App „Intel® Software Guard Extensions“ (zum Vergrößern anklicken)

Sobald auf dem Zielsystem die Intel SGX-Funktion aktiviert ist, könnte ein Angreifer die Signaturanforderungen umgehen, indem er eine im Debug-Modus kompilierte Enclave-Binärdatei verwendet, um Abhängigkeiten in den Angriff einzubetten. Um die Ausführung ihres Codes zu beschleunigen, könnten sie eine Multithreading-Implementierung oder einen externalisierten Verschlüsselungsprozess innerhalb des regulären Kerns der Anwendung verwenden. Wenn die Enclave-Binärdatei nach dem Angriff außerdem vollständig aus dem infizierten System entfernt wird, kann der Angreifer darauf vertrauen, dass der versiegelte private Schlüssel nicht entsiegelt wird, bis er dies zulässt. Schließlich ist es sehr unwahrscheinlich, dass vor der Infektion Seitenkanalangriffe durchgeführt werden, was es höchst unwahrscheinlich macht, dass diese einen Ransomware-Angriff mithilfe von Enklaven erfolgreich vereiteln würden.

Die Intel SGX-Technologie bietet Entwicklern eine einzigartige Möglichkeit, ihren Code zu schützen. Wir haben untersucht, wie die Architektur von Enklaven eine Umgebung bietet, die dem Schutz sensibler Daten förderlich ist und verschiedene Mechanismen zur sicheren Manipulation dieser Daten einbettet, beispielsweise durch Versiegelung.

Obwohl dies im täglichen Betrieb von Vorteil sein kann, kann es auch für böswillige Zwecke ausgenutzt werden, wie wir im Fall der kryptografischen Schlüsselverwaltung durch Ransomware-Autoren gesehen haben. Enklaven ermöglichen Ransomware-Autoren die sichere Generierung kryptografischer Schlüssel und verhindern so, dass Angriffsopfer zwei der häufigsten Szenarien ausnutzen, die Ransomware-Autoren vermeiden möchten: das Abrufen von Entschlüsselungsschlüsseln und das Verhindern einer Infektion mit Offline-Zielen.

Die geringe Verbreitung der Enklave-Nutzung durch Ransomware ist größtenteils auf die technischen Einschränkungen durch Intel SGX zurückzuführen. Seine Hardwareanforderungen und die Abschaffung künftiger CPU-Generationen verringern die Chancen, dass Zielsysteme alle für die Enklavenausführung erforderlichen Bedingungen erfüllen können. Darüber hinaus erfordert die Freigabe einer Enklave im Produktionsmodus das Durchlaufen des Signaturprozesses von Intel, der bei erfolgreichem Abschluss zu einer Signatur führt, die über Nacht schnell widerrufen werden kann, was die Chancen der Ransomware auf eine erfolgreiche Ausführung weiter verringert.

Wie wir gezeigt haben, können sich Ransomware-Autoren nicht ausschließlich auf Enklaven verlassen, um Angriffe zu orchestrieren, sondern können von deren Verwendung für die Verwaltung kryptografischer Schlüssel profitieren. Da es legitime Verwendungsmöglichkeiten für Enklaven gibt, sollte ein vorbeugender Ansatz gegen diese Ransomware-Angriffe nicht ausschließlich auf der Erkennung der Auslastung einer Enklave beruhen.

Als Teil unseres Engagements, Kunden eine kontinuierliche Transparenz in ihrem gesamten Unternehmen zu ermöglichen, bietet der CrowdStrike Falcon-Sensor Einblick in die Nutzung von Enklaven und nutzt diese Daten zusammen mit der Ereignistelemetrie, um festzustellen, ob ein Prozess bösartig ist, und um auf erkannte Bedrohungen zu reagieren. Letztendlich ist eine Enklave nur ein Hinweis – nicht mehr und nicht weniger.

Überzeugen Sie sich selbst, wie die branchenführende CrowdStrike Falcon-Plattform vor modernen Bedrohungen wie Ransomware schützt. Starten Sie noch heute Ihre 15-tägige kostenlose Testversion.

Melden Sie sich jetzt an, um die neuesten Benachrichtigungen und Updates von CrowdStrike zu erhalten.

Erkennen, verhindern und reagieren Sie auf Angriffe – auch Angriffe ohne Schadsoftware – in jeder Phase mit Endpunktschutz der nächsten Generation.