Effektive Erkennung von C2-Beaconing

Einführung

Angreifer erweitern ihre Malware um neue und ausgefeilte Command-and-Control-Funktionen (C2), die gängige statische Abwehrmaßnahmen auf Basis von IPS-Signaturen oder IP-/Domain-/URL-Sperrlisten leicht umgehen. Dazu verwenden sie gängige, weithin verfügbare C2-Framework-Tools wie Cobalt Strike, Brute Ratel, Mythic, Metasploit, Sliver und Merlin. Diese Tools bieten Post-Exploitation-Funktionen, darunter Command-and-Control, Rechteausweitung und Aktionen auf dem Host, und wurden ursprünglich für Penetrationstests und Red-Team-Operationen entwickelt.

Angreifer haben diese Toolkits jedoch übernommen und für böswillige Zwecke eingebettet, da viele Produkte wie Mythic und Merlin Open Source sind, während andere kommerzielle Produkte wie Cobalt Strike und Brute Ratel durch gehackte Kopien oder geleakten Quellcode in die Hände von Angreifern gelangt sind. Dadurch wurden dieselben Tools faktisch zu gegnerischen C2-Frameworks für böswillige Post-Exploitation-Aktivitäten.

Die Tools können viele Parameter der C2-Kommunikation problemlos gestalten und ändern. Dadurch kann Malware aktuelle Abwehrmaßnahmen noch einfacher und über längere Zeiträume umgehen und in den Netzwerken der Opfer größeren Schaden verursachen. Dazu gehören der Diebstahl größerer Datenmengen, die Entdeckung wertvollerer Daten, die Nichtverfügbarkeit geschäftlicher Anwendungen und Dienste sowie die Aufrechterhaltung eines verborgenen Netzwerkzugangs für zukünftige Angriffe.

Aktuelle Ansätze zur Erkennung der neuesten Malware, die C2-Frameworks verwendet, nutzen statische Signaturen und Indikatoren. Dazu gehören die Erkennung ausführbarer Implantatdateien, IPS-Signaturen zur Erkennung von C2-Datenverkehr sowie IP-/URL-Filter, die für den Umgang mit den dynamischen, formbaren Profilen der weithin verfügbaren C2-Framework-Tools unzureichend sind.

Erforderlich ist ein neuer Ansatz, der nicht so starr an bekannte Angriffe gebunden ist, sondern auf der Anomalieerkennung anhand eines umfassenden Satzes von Signalen beruht, die trainierten Machine-Learning-Modellen zugeführt werden, und eine fein abgestufte Nachverfolgung des Geräte- und Benutzerrisikos umfasst. Dieser Ansatz ergänzt bestehende Ansätze, kann die Erkennungsraten jedoch erheblich steigern, gleichzeitig die Anzahl falsch positiver Ergebnisse niedrig halten und einen zukunftssicheren Schutz vor sich weiterentwickelnden C2-Datenverkehrsmustern bieten, die durch dieselben C2-Framework-Tools leicht ermöglicht werden.

Dieses Whitepaper behandelt die Lücken aktueller Ansätze und die höhere Wirksamkeit eines fokussierten Machine-Learning-Ansatzes mit zusätzlichen Netzwerksignalen und fein abgestuften Risikometriken auf Grundlage von Modellen auf Benutzer- und Organisationsebene. Außerdem erörtern wir einige der zentralen Herausforderungen beim Testen der Wirksamkeit einer beliebigen Lösung zur Erkennung von C2-Beacons.

Gegnerische C2-Frameworks

Cobalt Strike, Metasploit, Mythic und Brute Ratel gehören zu den kommerziellen und quelloffenen Tools zur Gegnersimulation, die ursprünglich für Red-Team-Tests der Malware-Erkennung entwickelt wurden. Diese Toolkits werden gelegentlich als Tools zur Bedrohungsemulation oder als C2-Frameworks bezeichnet, da sie umfangreiche Funktionen (Gill) zur Simulation echter Bedrohungsaktivitäten während Red-Team-Operationen bereitstellen, wobei der Schwerpunkt auf den Post-Exploitation-Komponenten für Command-and-Control innerhalb der Angriffskette liegt.

Einige dieser Begriffe werden in diesem Whitepaper möglicherweise synonym verwendet. Im Allgemeinen verwenden wir jedoch die Bezeichnung C2-Frameworks, um zu betonen, dass diese Tools von böswilligen Akteuren eingesetzt werden, um Produktionsumgebungen zu beeinträchtigen, und dass das zu lösende Problem weit über Simulationen oder Emulationen durch wohlgesinnte interne Red Teams hinausgeht.

Diese C2-Framework-Tools wurden eingebettet, gehackt oder gestohlen und von zahlreichen Angreifern eingesetzt (“Cobalt Strike: Internationale Strafverfolgungsoperation geht gegen die illegale Nutzung des „Schweizer Taschenmessers“ unter den Pentesting-Tools vor”). Dazu gehören staatliche Akteure wie Russlands APT29 bei SolarWinds (“SolarWinds-Lieferkettenangriff verwendet SUNBURST-Backdoor”) und TA415 aus der Volksrepublik China (Larson und Blackford), die damit die verdeckten Kommunikationsfunktionen verschiedener RATs, Botnets und C2-fähiger Malware erweitern und weiterentwickeln.

Cobalt Strike ist das beliebteste C2-Framework-Tool und wird in diesem Whitepaper durchgehend als konkretes Beispiel verwendet, obwohl die Beobachtungen für alle ähnlichen Tools gelten. Das folgende Übersichtsdiagramm der Cobalt Strike-Architektur zeigt die grundlegenden Komponenten (Rahman) und den Angriffsablauf zur Laufzeit.

Cobalt Strike und ähnliche Toolkits ermöglichen eine einfache und umfassende Konfigurierbarkeit des HTTP/S-Datenverkehrs. Dadurch entsteht C2-Datenverkehr, der häufig legitim erscheint, wie normaler HTTP-/Web-Datenverkehr aussieht und dem Datenverkehr von Webbrowsern oder beliebten Anwendungen ähnelt. Die Tools stellen Standardkonfigurationen bereit, die sowohl bekannte Malware als auch bekannte legitime Anwendungen emulieren.

Obwohl DNS ebenfalls als C2-Protokoll unterstützt wird, konzentrieren wir uns auf HTTP/S-C2. Dieser Datenverkehr macht den Großteil des ein- und ausgehenden Netzwerkverkehrs einer Organisation aus, ist aufgrund der Vielzahl von Anwendungen, die HTTP/S verwenden, komplexer und zieht die Mehrheit der böswilligen Akteure an, die versuchen, sich im Netzwerkrauschen einschließlich legitimer, harmloser C2-Beacons zu verbergen.

Die Toolkits sind hochgradig konfigurierbar (über formbare Profile) und können Zeitplanung, Häufigkeit, Volumen, Anwendungsprotokolle, Ziel-IPs/-Domains, User Agents, HTTP-Header, HTTP-Verben, URIs, Parameter, SSL/TLS-Zertifikate, Beaconing-Verzögerungen mit zufälligem Jitter sowie Nutzlast und Inhalt problemlos variieren. C2-Framework-Tools ermöglichen außerdem eine große Anzahl von Post-Exploitation-Aktionen, die verschlüsselt, heruntergeladen und im Arbeitsspeicher ausgeführt werden. Dadurch sind Aktivitäten nach einer Kompromittierung auf Endpoints nur sehr schwer zu erkennen.

Wir konzentrieren uns auf die spezifischen C2-Kommunikationsfunktionen der C2-Framework-Tools, beispielsweise C2-Beaconing, darauf, wie einfach sich diese Kommunikation ändern lässt, beispielsweise über die C2 Malleable Profiles von Cobalt Strike, sowie auf die Herausforderungen für Organisationen, die verdeckte Malware erkennen möchten.

Es gibt mehrere gute Ressourcen, in denen die Funktionalität der Malleable Profiles von Cobalt Strike erläutert wird (Gill). Wir weisen jedoch auf einige der häufig verwendeten Funktionen hin. Nachfolgend finden Sie einen Ausschnitt aus dem formbaren Profil zur Nachahmung der Gmail-Browseranwendung in Cobalt Strike (Mudge):

Zu den wichtigsten Funktionen und Bereichen des Profils gehören:

# Use an existing certificate or generate a self-signed certificate as seen in the above example.

# These global options below set the C2 beacon sleep time to 60 seconds with a
# random jitter of +/- 15%, showing the ability to vary the call-home timing to avoid
# easy detection.
set sleeptime “60000”;
set jitter “15”;

# Other global options specify on-host post-exploit action parameters such as the
# process name spawned to execute commands using in-memory injection or the
# pipename used for IPC communications. These are not relevant to C2.
set pipename “interprocess_##“;
set spawnto “userinit.exe”;

# The uri path used for beacon->server communications can be varied with a list
set uri “//scs/mail-static//js/”;

# Client (beacon->server) communications including cookies, headers, and encoding
# can all be specified and varied easily at the HTTP protocol level
client {
    metadata {}
    header {}
}

# Similarly, server->beacon communications can also be varied at the HTTP
# protocol level
server {
    header {}
}

# Cobalt Strike allows shaping of the 2-way communications flow between the
# Beacon client and C2 Team Server (“A Beacon HTTP Transaction Walk-through”):
# 0. http-stager {}    optional stager to download full Beacon
# 1. http-get {client}  client  — call home -> server
# 2. http-get {server}  server  — cmds -> client
# 3. http-post {client} client  — cmd output -> server
# 4. http-get {server}  server  — confirm -> client

Wie oben zu sehen ist, können einfache Änderungen an diesen Profilen das Verhalten der C2-Kommunikation problemlos so verändern, dass gängige Anwendungen, deren Beacons und Web-Datenverkehr nachgeahmt werden. Allein für Cobalt Strike sind mehr als 240 öffentliche formbare Profile verfügbar, die direkt verwendet oder einfach geändert werden können.

Aktuelle Erkennungsansätze

Aktuelle Ansätze zur Erkennung bösartigen C2-Datenverkehrs gleichen in der Regel fest codierte Byte-Signaturen ab oder verwenden reguläre Ausdrücke, um Nutzlasten oder Header abzugleichen (IPS-Signaturen), oder sie basieren auf dem Abgleich von IP-/Domain-/URL-Listen. Diese Ansätze sind statisch und lassen sich aufgrund der dynamischen, konfigurierbaren Eigenschaften der von Angreifern eingebetteten C2-Framework-Toolkits leicht umgehen.

IPS-Signaturen

Zur Veranschaulichung der Herausforderungen bei IPS-Lösungen folgt hier eine der Snort-Regeln zur Erkennung des Zeus-Trojaners (Snort):

Snort und viele IPS-Lösungen ermöglichen verschiedene Abgleiche von Inhalten oder Headern auf den Schichten 3 und 4 sowie auf Anwendungsebene, wie durch die Aktionsverben in der Regel angegeben. Viele Abgleiche, beispielsweise die Regeloption content, sind statische Byte-/Zeichenabgleiche, während die Regeloption pcre einen Abgleich mit regulären Ausdrücken darstellt.

Bei einer Gegenüberstellung sowohl der Angreiferseite, beispielsweise des zuvor gezeigten C2 Malleable Profile für gmail, als auch der Abwehrseite, beispielsweise der Zeus-Regel von Snort, werden der statische, fest codierte Abgleich und dessen Fragilität deutlich. Stellen Sie sich vor, ein Angreifer hätte eine neue Zeus-Variante erstellt und bereitgestellt, die Cobalt Strike verwendet, und ein Snort-IPS hätte die oben genannte Zeus-Regel implementiert, mit der die neue Malware effektiv erkannt wird. Der Angreifer könnte problemlos ein einziges Zeichen im Profil ändern, beispielsweise durch Hinzufügen eines Leerzeichens in MSIE, um den folgenden Abgleich zu vermeiden: content:"|3B 20|MSIE|20|"; dadurch könnte die Malware die IPS-Signatur umgehen.

Obwohl Kontextbewusstsein und Zustandsverfolgung vorhanden sind, ist der IPS-Signaturansatz aufgrund seines statischen Abgleichs grundsätzlich begrenzt. Dies führt zu falsch negativen Ergebnissen und einer einfachen Umgehung – buchstäblich die Änderung eines einzigen Zeichens in einem einzigen Feld könnte eine IPS-Regel umgehen.

Das bedeutet nicht, dass IPS-Lösungen nicht nützlich sind. IPS-Signaturen sollten vielmehr beibehalten werden, da sie als nützliche Perimeterabwehr dienen und viele bekannte Netzwerk-Exploits schnell und effizient blockieren. Selbst wenn ein IPS in diesem Fall nur eine Erkennungsrate von 60 % erreichen würde, könnten diese 60 % problemlos blockiert oder gemeldet werden, wodurch eine aufwendige nachgelagerte Verarbeitung vermieden wird.

IP-/URL-Sperrlisten

Andere traditionelle Ansätze, beispielsweise die Verwendung von Sperrlisten für IPs oder URLs, werden häufig eingesetzt, um den Erstzugriff oder das Herunterladen von Malware beim Webbrowsing zu verhindern und potenziellen C2-Datenverkehr zu blockieren.

Eine häufige Herausforderung bei Sperrlisten besteht darin, dass sie oft veraltet sind, falsch positive Ergebnisse verursachen und reaktiv sind, da sie erst nach der Kompromittierung von Ziel Nr. 1 beziehungsweise Patient Null aktualisiert werden.

Dieses Problem wird durch IP-/Domain-Umleitungstechniken verschärft, mit denen die Domain oder IP-Adresse des C2-Servers verborgen wird. Cobalt Strike verfügt über Redirectors, bei denen es sich beispielsweise um einfache IP-Proxys handeln kann, mit denen die tatsächliche Domain oder IP des C2-Servers verschleiert wird. Darüber hinaus gibt es weitere Techniken wie Domain Fronting über CDNs oder Domain Masquerading, die Abweichungen zwischen TLS (SNI) und HTTPS (Host) ausnutzen, um die endgültige bösartige Domain vor bestimmten URL-Sicherheitsfiltern zu verbergen.

Heuristiken für Netzwerkverkehr

Ein anderer Ansatz umfasst die Verwendung von Heuristiken, die typischerweise auf volumen- oder zeitbasierten Netzwerkverkehrsmustern beruhen. Das klassische Beispiel ist die Erkennung regelmäßiger ausgehender Kommunikation, beispielsweise alle 60 Minuten, möglicherweise zu einer IP-Adresse ohne registrierten DNS-A-Eintrag.

Um die Erkennung zu umgehen, ermöglichen C2-Framework-Toolkits über die Jitter-Einstellung in einem Cobalt Strike Malleable Profile die einfache Konfiguration eines Zufallsfaktors für die Beaconing-Verzögerung:

Abbildung 4: Einstellungen des C2 Malleable Profile (Beaconing-Zeitsteuerung)

Diese Einstellungen geben ein Rückrufintervall von 60 Sekunden +/- 15 % an. Das tatsächliche Intervall liegt daher zwischen 51 und 69 Sekunden, wodurch einfache Prüfungen auf wiederkehrendes Beaconing in konstanten Intervallen umgangen werden.

Wirksamkeit

Das Problem aktueller Ansätze besteht darin, dass sie formbare C2-Kommunikation nicht effektiv erkennen und selbst bei einer spezifischen Abstimmung leicht umgangen werden können. Sie erfüllen einen Zweck, indem sie statische Angriffstechniken mit bekannten Indikatoren effizient erkennen, übersehen jedoch dynamischere oder ausgefeiltere Angriffe oder erzeugen eine große Anzahl falsch positiver Ergebnisse.

Als einzelner Datenpunkt zeigte sich beim Testen der gängigsten Cobalt Strike C2 Malleable Profiles aus öffentlichen Repositorys, dass standardmäßig konfigurierte IPS-Lösungen wie Snort und Suricata deutlich weniger als 20 % der C2-Kommunikation der gängigsten C2-Framework-Toolkits erkannten.

Selbst nach dem gezielten Hinzufügen von Regeln, um möglichst viele öffentliche Profile abzudecken und die Konfiguration für diesen spezifischen Test zu optimieren, konnte die Abdeckung nur auf etwa 60 % erhöht werden, ohne eine erhebliche Anzahl falsch positiver Ergebnisse zu verursachen, die in einer Produktionsumgebung äußerst problematisch wäre.

Bei der Wirksamkeit bestehen zahlreiche Probleme: Neben einer höheren Anzahl falsch positiver Ergebnisse ist die resultierende Konfiguration starr auf den jeweiligen Test zugeschnitten und kann durch geringfügige Änderungen der Profile leicht umgangen werden. Letztlich bleiben weiterhin etwa 40 % der Profile unentdeckt, was einer sehr hohen Rate falsch negativer Ergebnisse entspricht. Hinzu kommen weitere falsch negative Ergebnisse durch entschlossene Angreifer, die C2-Profile so anpassen, dass sie vorhandene bekannte Anwendungen auf geringfügig andere Weise nachahmen.

Neuer Erkennungsansatz

Erforderlich ist ein wirksamerer Ansatz, der nicht ausschließlich auf statischen Indikatoren beruht, sondern fokussierte Machine-Learning-Modelle verwendet. Diese können anhand zahlreicher Netzwerksignale Anomalien im Netzwerkverkehr erkennen, die im Vergleich zum normalen Verhalten legitimer Anwendungen für bestimmte Benutzer innerhalb einer bestimmten Organisation auf verdächtige Command-and-Control-Aktivitäten hindeuten. Darüber hinaus sollten fein abgestufte Risikometriken auf Benutzerebene nachverfolgt werden, um möglichst präzise und wirksame Maßnahmen zur Risikominderung zu ermöglichen. Innovationen in diesen drei Bereichen sind erforderlich, um die Erkennung verdeckten C2-Beaconings durch C2-Framework-Tools erheblich zu verbessern:

Umfassende Signale

Ein umfassender Satz von Signalen ist erforderlich. Dieser sollte Eigenschaften von Quelle, Ziel und Datenverkehr umfassen, beispielsweise SSL/TLS-Zertifikate, die sowohl an der Quelle – der Malware innerhalb der Umgebung – als auch am Ziel – dem C2-Server – verwendet werden, Domain/IP/URL, Quelleigenschaften wie User-Agent-/Prozesseigenschaften, Datenverkehrsgröße, Schwankungen und Muster sowie HTTP-Header, Nutzlast und URI, um nur einige zu nennen.

Durch die Betrachtung verschiedener Signale über Zeiträume, Volumen, Netzwerkschichten und das allgemeine Datenverkehrsprofil hinweg kann die verhaltensbasierte Erkennung einen allgemeinen und wirksamen Mechanismus zur Erkennung der neuesten Malware anhand verdächtiger und bösartiger C2-Beaconing-Aktivitäten bereitstellen.

Die Signaltypen umfassen mehrere Dimensionen:

• Netzwerkfluss: Quell- und Zielattribute sowie Datenverkehrsmuster
• Netzwerkschichten: unterschiedliche Signale von Schicht 3 bis 7 (Anomalien in TCP/IP-Headern, SSL/TLS-Fingerprints, HTTP-Headern/-Nutzlasten und Inhalten auf Anwendungsebene)
• Zeit: Häufigkeit und anomale Zeitmuster zur Erkennung seltener und langsamer Aktivitäten
• Daten: Inhalt und Volumen (anomale Paketgrößen, Bursts, kumulative Statistiken)

Darüber hinaus gibt es mehrere Signaltypen:

• Auf Datenverkehrsmustern basierend (Volumen, Zeitsteuerung, Inhalt), einschließlich wiederholten Beaconings in Verbindung mit einem ungewöhnlichen User Agent oder einer ungewöhnlichen Domain.
• Heuristiken (z. B. verdächtige Registrare oder bekannte bösartige SSL-Fingerprints)
• Anomalien (ungewöhnliche Domains, User Agents oder SSL-Fingerprints)

Ein wichtiger Punkt ist, dass einige der oben genannten Signale bereits Bestandteil aktueller Ansätze und bestehender Lösungen sind. Dies unterstreicht, dass ein bestimmtes Signal wie eine Datenverkehrsspitze – ein großes Volumen – für sich genommen weder gut noch schlecht, wirksam noch unwirksam ist. Vielmehr sind der Kontext und die Verarbeitung des Signals entscheidend. Bei der Verwendung an einem Netzwerkperimeter zum Blockieren oder Zulassen von Datenverkehr kann ein Signal, das zu falsch positiven Ergebnissen neigt, schwerwiegende betriebliche Probleme verursachen. Wird es jedoch einem System zur Anomalieerkennung zugeführt, das dieses Signal in eine granulare Risikometrik – wie nachfolgend erläutert – und ein gut trainiertes Modell integriert, kann es neue Bedrohungen äußerst effektiv, robust und mit wenigen falsch positiven Ergebnissen erkennen.

Anomalieerkennung

Die effektive Erkennung von C2-Beaconing durch C2-Framework-Toolkits erfordert Machine-Learning-Modelle, die auf einem umfassenderen Spektrum von Signalen basieren. Damit lassen sich heutige C2-Framework-Toolkits sowie zukünftiges verdächtiges Netzwerkverhalten erkennen, das auf C2-Aktivitäten hindeuten könnte.

Die Anomalieerkennung sollte auf Modellen auf Benutzer-/Geräte-, Rollen- und Organisationsebene basieren. Anomalien setzen also voraus, dass eine gültige „normale“ Basislinie für Aktivitäten oder Verhaltensweisen vorliegt, mit der ein Vergleich erfolgen kann. Verdächtige Aktivitäten können unter unterschiedlichen Umständen erkannt werden. Es gibt Anomalien, die auf dem Vergleich der Aktionen eines Benutzers mit seiner historischen „normalen“ Basislinie, mit der „normalen“ Basislinie der Organisation oder mit Personen in ähnlichen Rollen beruhen. Alle haben gültige, voneinander unabhängige Anwendungsfälle, und ein guter Ansatz umfasst mehrere Modelle mit unterschiedlichen Geltungsbereichen.

Trainingsdaten

Trainingsdatensätze sollten sowohl bösartigen als auch harmlosen Datenverkehr enthalten:

• Bösartiger Datenverkehr kann mithilfe allgemeiner C2-Testtools, spezifischer gegnerischer C2-Beaconing-Tests auf Grundlage öffentlich verfügbarer Konfigurationen von C2-Framework-Tools sowie angepasster Konfigurationen aus der Perspektive eines Red Teams und offizieller Red-Team-Übungen simuliert werden.
• Harmloser Datenverkehr oder legitimer Datenverkehr wird am besten über einen ausreichend langen Zeitraum von einer erheblichen Anzahl tatsächlicher Benutzer in realen Organisationen erfasst, um benutzer- und organisationsbedingte Verzerrungen zu normalisieren.

Trainingsdatensätze bilden die Kehrseite von Testdatensätzen. Daher sollte viel Zeit für die Analyse und Validierung guter Trainings- und Testdaten aufgewendet werden. Einige der Faktoren für die Erstellung geeigneter Testdatensätze werden in einem späteren Abschnitt behandelt.

Granulare Risikometriken

Die Ausgabe der Anomalieerkennung ist von entscheidender Bedeutung. Der beste Ansatz trifft keine einfachen Entscheidungen zum Blockieren oder Zulassen beziehungsweise zum Melden oder Ignorieren auf Grundlage eines Rohsignals. Stattdessen verfolgt und justiert er fein abgestufte Risikometriken auf Benutzer-, Rollen- und Organisationsebene. Diese können anschließend für Abhilfemaßnahmen wie Warnungen, Coaching oder Blockierungen verwendet werden.

Dieser Ansatz zur Nachverfolgung und Behandlung von Risiken unterscheidet sich grundlegend von den heute üblichen Verfahren. Die meisten präventiven Perimeterabwehrmaßnahmen, die Datenverkehr üblicherweise blockieren, melden oder zulassen, sind im Allgemeinen statisch und anfällig für hohe Raten falsch positiver Ergebnisse. Das führt dazu, dass diese Lösungen mit konservativen Richtlinien aktiviert werden, die bestimmte und bekannte Risiken blockieren, wodurch jedoch eine große Anzahl falsch negativer Ergebnisse entsteht. Bei Firewalls treten Probleme mit falsch positiven Ergebnissen auf, wenn auf IP-Bedrohungsinformationen basierende Blockierungsaktionen zu aggressiv sind. Bei IPS-Lösungen haben wir die Herausforderungen durch falsch positive Ergebnisse statischer Signaturen erörtert, die hochgradig konfigurierbaren und dynamischen C2-Datenverkehr erkennen sollen.

Falsch positive Ergebnisse auf einer Perimeterschicht können für eine intelligentere Schicht jedoch als Signal sehr nützlich sein. In diesem Szenario würde das Signal nicht für eine binäre Bewertung – zulassen/blockieren oder melden/ignorieren – verwendet, sondern als fein abgestufte Risikometrik, die im Zeitverlauf angepasst wird, beispielsweise als Benutzerrisikowert, wobei vor dem Ergreifen einer Maßnahme ein abgestimmter Schwellenwert überschritten werden muss. Eine granulare Risikometrik, beispielsweise ein Risikowert von 1000 (kein Risiko) bis 0 (extremes Risiko) für einen Benutzer, ein Gerät oder sogar eine IP-Adresse, ermöglicht die Modellierung des Graubereichs realer Bedrohungen, bei denen Bewertungen nur selten eindeutig zu 100 % bösartig oder zu 100 % harmlos ausfallen.

Konzeptionell wird dies in der folgenden Abbildung dargestellt. Dabei könnten drei verschiedene Signale erkannt werden, die für sich genommen zu falsch positiven Ergebnissen neigen würden. Werden sie jedoch einem inkrementellen Risiko zugeordnet und durch ein abgestimmtes Machine-Learning-Modell ausgewertet, bewerten dieselben Signale das kumulative Risiko im Zeitverlauf und führen letztlich zu einer Anomalieerkennung mit hoher Zuverlässigkeit.

Beachten Sie, dass die Signale in diesem Beispiel möglicherweise nicht so einfach wie statische Signale sind. Beispielsweise könnte eine „ungewöhnliche Domain, ein nicht erkannter User Agent und ein SSL/TLS-Zertifikat“ eine Anomalie darstellen, wenn dies mit der bisherigen „normalen“ Datenverkehrsbasislinie dieses spezifischen Benutzers, mit Benutzern in ähnlichen beruflichen Rollen oder mit der gesamten Organisation verglichen wird. Ein „verdächtiger Registrar“ kann eine Zusammenführung der im Zeitverlauf korrelierten Domain-Reputation darstellen. Und „periodisches Beaconing“ ist kein einfacher Abgleich einer festen Rate oder Dauer mehr, sondern kann anomale, jedoch regelmäßige und wiederholte Aktivitäten innerhalb eines Zeitfensters erkennen, die Bot-Aktivitäten ähneln und sich von legitimen Callouts eines Anwendungs-Daemons unterscheiden.

In der Praxis ermöglicht dies die schrittweise und angemessene Anpassung eines Risikowerts auf Grundlage eines Signals mit geringer Zuverlässigkeit. Es erfolgt keine Blockierung oder Warnung, bis der kumulative Risikowert einen abgestimmten, hohen Schwellenwert überschreitet. Dadurch können Fälle erfasst werden, in denen zahlreiche leicht riskante Indikatoren mit geringer Zuverlässigkeit vorliegen, die in Kombination mit einem Indikator höherer Zuverlässigkeit und höheren Risikos für einen bestimmten Benutzer oder ein bestimmtes Gerät kumulativ eine kritische Risikowarnung und Maßnahme erzeugen, wobei die Wahrscheinlichkeit falsch positiver Ergebnisse drastisch geringer ist.

Bewertung und Tests

Ein neuer Ansatz kann theoretisch fundiert sein und in der Praxis kläglich scheitern. Der Nachweis hängt häufig von Daten oder Tests ab. Anbieter von Lösungen und Organisationen, die nach Lösungen suchen, benötigen einen robusten Ansatz zum Testen neuer Bedrohungen und zur Bewertung von Lösungen. Um präzise Ergebnisse zu erzielen, müssen Tests mit einem vielfältigen Datensatz durchgeführt werden, der sowohl bösartigen als auch harmlosen Datenverkehr enthält.

Harmloser Datenverkehr

Harmloser Datenverkehr sollte hinsichtlich Benutzeranzahl und Aktivität realistisch, umfassend und mit der Produktion vergleichbar sein. Legitime Datenverkehrsdaten, die häufig vom Benutzer abhängen, sollten über eine große Benutzerstichprobe und einen angemessenen Zeitraum hinweg untersucht werden. Dieser Testdatensatz misst die Raten falsch positiver Ergebnisse (FP). Die wesentlichen Unterschiede in den Datensätzen betreffen Clientsignale wie die verwendeten Anwendungen, User Agents und Client-SSL/TLS-Zertifikate, Zielsignale in den Ziel-Domains/-IP-Adressen sowie Datenverkehrsmustersignale in Headern, Nutzlast, Größe und Zeitsteuerung.

Die gute Nachricht ist, dass sich geeigneter harmloser Datenverkehr problemlos aus dem täglichen Betrieb der Benutzer einer Organisation erfassen lässt. Die schlechte Nachricht ist, dass er als harmlos validiert werden muss. Der praktische Ansatz besteht darin, den harmlosen Datenverkehr statistisch zu beproben, um einen angemessenen Konfidenzfaktor zu erreichen, und anschließend den Großteil der Zeit auf die Warnungen der getesteten C2-Erkennungslösung zu verwenden, wobei die Warnungen als richtig positiv oder falsch positiv verifiziert werden. Anders ausgedrückt: Zunächst wird eine Stichprobe genommen und überprüft, um eine Basislinie zu erstellen. Anschließend wird davon ausgegangen, dass der harmlose Datensatz sauber ist, und mit der Ermittlung falsch positiver Ergebnisse auf Grundlage der Tests fortgefahren.

Bösartiger Datenverkehr

Die Verwendung öffentlicher Profile beliebter C2-Framework-Tools bietet eine solide Grundlage zum Testen bösartigen Datenverkehrs. Diese Profile stellen praktische, häufig verwendete Konfigurationen dar, die Abwehrmaßnahmen umgehen, und helfen bei der Messung der Raten falsch negativer Ergebnisse (FN). Bei der Erstellung eines repräsentativen Datensatzes für „bösartigen Datenverkehr“ müssen jedoch zahlreiche Aspekte berücksichtigt werden, da potenziell mehrere Ebenen der Abdeckung und der durch die Datensätze getesteten Eigenschaften bestehen, wie im folgenden Diagramm dargestellt:

1. Tools zur Simulation von Sicherheitsverletzungen und Angriffen wie SafeBreach eignen sich hervorragend für Abdeckungstests und wiederholte Tests. Ihre C2-Testfälle umfassen üblicherweise zumindest eine gewisse Simulation von C2-Framework-Aktivitäten. Der Vorteil besteht darin, dass ein breites Funktionsspektrum verfügbar ist, einschließlich allgemeiner Malware-Angriffe, gut konzipierter GUIs und Architekturen sowie wiederholbarer Testverfahren und Berichte. Diese Tools können ein breites Spektrum von Szenarien bereitstellen, darunter langsame Aktivitäten mit geringem Volumen, Datenverkehr zu IaaS-/CSP-Infrastrukturen, HTTP- und Nicht-HTTP-Datenverkehr, SSL-/HTTPS-Datenverkehr sowie die Nachahmung verschiedener User Agents.
2. C2-Framework-Tools (öffentliche Profile). Detaillierte Tests von C2-Frameworks erfordern fokussierte Arbeit. Ein Ansatz besteht darin, einen Testdatensatz auf Grundlage der spezifischen öffentlichen Profile von C2-Framework-Tools wie Cobalt Strike zu erstellen. Diese öffentlichen formbaren Profile werden häufig geteilt und von vielen Benutzern und böswilligen Akteuren verwendet, da sie nützliche Emulationen harmloser Anwendungen wie gmail enthalten. Dieser Ansatz ermöglicht in der Regel umfassendere Tests der jeweiligen C2-Frameworks.
3. C2-Framework-Tools (benutzerdefinierte Profile). Die interne Anpassung der C2 Malleable Profiles kann noch realistischere Tests von C2-Frameworks ermöglichen. Diese benutzerdefinierten Konfigurationen können im Rahmen interner Red-Team-Operationen erstellt werden. Dies erfordert mehr Arbeit und Investitionen, da die Red-Team-Operatoren die C2-Framework-Tools sicher beherrschen müssen.
4. Realistische Angriffe. Die realistischsten Tests umfassen Black-Box-Tests mit externen Penetrationstests oder Bug-Bounty-Programmen. In diesen Szenarien werden die Anforderungen der Übung sorgfältig so gestaltet, dass tatsächliche POC-Exploits erforderlich oder attraktiv sind, die bestimmte C2-Framework-Tools oder beliebiges C2-Beaconing-Verhalten verwenden, wobei die Erkennung über einen bestimmten Zeitraum vermieden werden muss. Die Ziele der Übungen bestehen nicht nur darin, wie üblich Erstzugriffsvektoren zu testen, sondern sich auf Aktivitäten nach einer Sicherheitsverletzung zu konzentrieren, indem die Fähigkeit zur Installation einer Backdoor-Nutzlast mit nachgewiesener C2-Aktivität demonstriert wird. Dadurch wird der Testdatensatz über die C2-Frameworks hinaus erweitert. Zudem können Backdoor-POC-Code mit benutzerdefinierter C2-Kommunikation sowie die Widerstandsfähigkeit eines beliebigen Erkennungstools gegenüber einem kompetenten „Angreifer“ getestet werden, der unterschiedliche oder benutzerdefinierte TTP verwendet.

Tests können einen oder mehrere Ansätze umfassen. Es sollten jedoch explizite Entscheidungen darüber getroffen werden, wie die Testdatensätze erstellt, erfasst und validiert und wie die erwarteten Ergebnisse gemessen werden. Die Erstellung und Erfassung der Testdatensätze ist sehr wichtig, damit die Tests automatisiert und problemlos wiederholt werden können.

Darüber hinaus ist es entscheidend, während der Tests vollständige Metriken zu messen: richtig und falsch positive sowie richtig und falsch negative Ergebnisse. Obwohl die Erfassung aller Metriken selbstverständlich erscheint, sind eine präzise Definition sowie eine klare und wiederholbare Messmethodik schwierig, was zu irreführenden Ergebnissen führen kann.

Zielwerte für falsch positive und falsch negative Ergebnisse

Für neuere Erkennungslösungen gegen die durch C2-Frameworks erzeugten neuen, ausweichenden Bedrohungen gibt es noch keine weithin akzeptierten FP- und FN-Raten. Dennoch ist es von entscheidender Bedeutung, FP- und FN-Zielwerte festzulegen. Mit bekannten, hochwertigen Testdatensätzen können Basislinien für die aktuelle Umgebung und die Benutzer beziehungsweise Geräte erstellt werden. Auf dieser Grundlage lassen sich im Verhältnis zu diesen Basislinien angemessene Zielwerte festlegen.

Angenommen, eine Organisation, die ausschließlich ein IPS verwendet, beginnt mit der Bewertung neuer C2-Erkennungslösungen, und es ist unklar, welche FP-/FN-Raten akzeptabel sind. Die Organisation kann dennoch angemessene Zielwerte festlegen, indem sie eine Testmethodik wie die folgende verwendet:

• Hochwertige Testdaten erstellen – für harmlosen Datenverkehr auf Grundlage von Produktionsdaten und für bösartigen Datenverkehr beispielsweise auf Grundlage öffentlicher formbarer C2-Profile für Cobalt Strike – und Stichproben dieser Datensätze manuell validieren.
• Eine klare, wiederholbare Testmethodik erstellen, indem Test- und Messwerkzeuge definiert werden.
• Alle Metriken (TP/TN/FP/FN) messen während der Tests.
• Neue Lösungen testen und Metriken vergleichen. Das IPS könnte beispielsweise gezielt auf bessere TP-Raten für bösartigen Datenverkehr abgestimmt werden. Dabei muss jedoch sichergestellt werden, dass auch die FP-/TN-/FN-Raten gemessen und validiert werden. Anschließend kann die Wirksamkeit unterschiedlicher Lösungen ordnungsgemäß bewertet werden, insbesondere hinsichtlich der gesamten Auswirkung auf die Organisation, wie im nachfolgenden Abschnitt „Auswirkungen“ beschrieben.
• Neue Datensätze testen und vergleichen. Die Datensätze sollten angepasst werden, um angemessene Veränderungen durch einen Angreifer widerzuspiegeln. Dafür gibt es mehrere Möglichkeiten.
  • Beim Testen von Cobalt Strike können beispielsweise dessen C2 Malleable Profiles leicht geändert werden, um harmlose Anwendungen geringfügig anders oder vollständig neue harmlose Anwendungen nachzuahmen, die innerhalb der jeweiligen Organisation verwendet werden. Dies kann durch das Erfassen ausgehenden HTTP/S-Datenverkehrs über einen Proxy erfolgen.
  • Testen Sie nicht nur ein, sondern mehrere C2-Framework-Tools, da sie sich hinsichtlich ihrer Funktionen und Techniken unterscheiden. Die Verwendung eines anderen C2-Framework-Tools stellt ebenfalls eine sinnvolle Änderung dar, da dessen Gestaltung des C2-Datenverkehrs anders ausfällt.
  • Die Erstellung einer benutzerdefinierten Testnutzlast mit eigener, manuell codierter C2-Kommunikation ist eine weitere Möglichkeit, die Testdatensätze zu ändern, erfordert jedoch den größten Zeit- und Investitionsaufwand.

Tests der Widerstandsfähigkeit

Durch Tests mit neuen Datensätzen über verschiedene Lösungen hinweg gewinnen wir außerdem wertvolle Erkenntnisse über die Starrheit beziehungsweise Widerstandsfähigkeit unterschiedlicher Lösungen. In diesem Whitepaper haben wir darauf hingewiesen, dass fest codierte und signaturbasierte Ansätze nicht nur weniger effektiv bei der Erkennung von C2-Frameworks sind, sondern auch starr. Dies führt zu hohen FP-/FN-Raten und ermöglicht eine einfache Umgehung durch geringfügige Änderungen des Angriffs, beispielsweise Änderungen an formbaren Profilen.

Die Widerstandsfähigkeit einer beliebigen Lösung kann getestet werden, indem sichergestellt wird, dass die Datensätze in angemessenem Umfang geändert werden, also innerhalb derselben TTP-Kategorie bleiben. Anders ausgedrückt können wir einen realistischen Test der Widerstandsfähigkeit durchführen, indem wir die C2-Kommunikation innerhalb des Datensatzes für bösartigen Datenverkehr mithilfe formbarer C2-Profile ändern und die TP-/TN-/FP-/FN-Raten überwachen. Dadurch erkennen wir, wie sich die Abdeckung verändert, und verstehen außerdem, welche Änderungen an der Erkennungslösung erforderlich sind, um die Abdeckung für bestimmte TP-/TN-/FP-/FN-Zielwerte aufrechtzuerhalten.

Das erneute Testen mit auf diese Weise geänderten Datensätzen entspricht der Änderung der TTP eines Angreifers. Es bewertet die Widerstandsfähigkeit und Effektivität der neuen Erkennungslösung, da festgestellt werden kann, ob sie Änderungen innerhalb derselben Bedrohungstechnikkategorie – C2-Kommunikation über HTTP/S – weiterhin erkennen kann.

Auswirkungen falsch positiver und falsch negativer Ergebnisse

Die Messung der FP-/FN-Raten ist sinnvoll und ermöglicht relative Verbesserungen. Wir müssen jedoch auch die Auswirkungen von FPs und FNs messen oder zumindest schätzen. Andernfalls ist es unmöglich, den tatsächlichen Nutzen einer Erkennungslösung zu bewerten. Eine FP-Rate von 1 % oder eine Verbesserung der FP-Rate um 5 % hat keinen Kontext, wenn wir die Auswirkungen dieser 1 % beziehungsweise +5 % nicht auf eine Weise messen können, die für Entscheidungsträger bei Sicherheitsbudgets sinnvoll ist.

Die folgenden zwei Ansätze können dabei helfen, TP-/TN-/FP-/FN-Raten in besser quantifizierbare Auswirkungen zu übersetzen:

1. Auswirkungen auf Benutzer im Zeitverlauf: Betrachten Sie die absolute Anzahl falsch positiver Ergebnisse, die den FP-Raten entspricht, und normalisieren Sie sie als Rate pro Benutzer im Zeitverlauf. Dies ist ein qualitatives Maß, häufig jedoch aussagekräftiger als prozentuale Raten oder absolute Zahlen. Statt 1 % FPs oder 2.437 falsch positiver Ergebnisse lassen sich die Auswirkungen beispielsweise anhand von 0,1 falsch positiven Ergebnissen pro Benutzer und Tag möglicherweise leichter bewerten. Wenn es sich um ein sicheres Web-Gateway handeln würde, könnte jemand in der Organisation anhand der Auswirkungen auf Benutzer im Zeitverlauf feststellen, ob ein bestimmter FP-Zielwert akzeptabel ist. In diesem Fall führt durch C2-Frameworks aktivierte Malware zu Sicherheitsverletzungen, und die Auswirkungen auf Benutzer lassen sich eher als Ausfallzeit oder Datenverlust pro Benutzer in einem bestimmten Zeitraum beschreiben. Es besteht eine Wahrscheinlichkeit von N % für einen Verlust von X $ pro Benutzer und Jahr. Dabei handelt es sich häufig um grobe Schätzungen, doch jeder Ausgangspunkt ist nützlich, da er durch regelmäßige Iteration überarbeitet und verbessert werden kann. Wenn die Auswirkungen anhand der Benutzer im Zeitverlauf bewertet werden, lassen sich Erkennungs- oder Schutzlösungen einfach beurteilen, da deren Preisgestaltung häufig auf der Anzahl der Benutzer pro Jahr basiert.
2. Auswirkungen auf den Sicherheitsbetrieb in Bezug auf Zeit, Geld und Wahrscheinlichkeit einer Sicherheitsverletzung. Neben den Auswirkungen auf Endbenutzer sollten auch die administrativen Auswirkungen bewertet werden, insbesondere für Mitarbeiter im Betrieb, die häufig Zeit mit der Bearbeitung von Erkennungswarnungen verbringen. Der Zeitaufwand für die Reaktion auf verrauschte Warnungen kann direkt in Gehaltskosten für Vollzeitmitarbeiter umgerechnet werden. Der zusätzliche Faktor der Warnungsmüdigkeit stellt eine reale Auswirkung dar, die hinsichtlich der Wirksamkeit – Reaktionszeit – und, was noch wichtiger ist, als Verlust von Zeit und Aufmerksamkeit für tatsächlich schwerwiegendere Bedrohungen geschätzt werden kann, die übersehen oder nicht untersucht werden. Diese letztgenannte Auswirkung wird zu einem Faktor für die Auswirkungen einer Sicherheitsverletzung: Sicherheitsverletzungen treten mit höherer Wahrscheinlichkeit auf, wenn der Sicherheitsbetrieb zu viele falsch positive Ergebnisse untersuchen und löschen muss.

Eine Folgenabschätzung ist häufig die einzige Möglichkeit, entscheidende Erkenntnisse wie die tatsächlichen Kosten der Erkennungswirksamkeit zu gewinnen. Eine übermäßig aggressive Erkennungslösung mit einer Konfiguration aus wenigen FNs und vielen FPs ist beispielsweise nutzlos und schädlich, da der Sicherheitsbetrieb unverhältnismäßig viel Zeit mit der Reaktion auf Warnungen geringer Zuverlässigkeit verschwendet, anstatt sich wirkungsvolleren Aktivitäten zu widmen. Ebenso setzt eine übermäßig konservative Erkennungslösung mit wenigen FPs, aber vielen FNs die Organisation einem hohen Risiko einer potenziellen Sicherheitsverletzung aus, was aus Sicht einer Gesamtrisikobewertung inakzeptabel sein kann.

Die Auswirkungen sollten gleichzeitig mit den zentralen TP-/FP-/TN-/FN-Metriken geschätzt und bewertet werden.

Realistische Tests

Setzen Sie ein Red Team mit Menschen ein, nicht nur automatisierte Tools für Sicherheitsverletzungs- oder Penetrationstests. Es wird dringend empfohlen, für das Testen von C2-Beaconing-Lösungen nicht nur Produktionsbenutzer und -umgebungen zu verwenden, sondern auch realistische gegnerische Szenarien wie Penetrationstests oder Bug-Bountys einzusetzen. Durch die Anpassung von Prämienhöhen und Anforderungen, sodass die explizite Implantation und erfolgreiche Durchführung von Post-Exploitation-Aktionen beliebter C2-Framework-Toolkits nachgewiesen werden muss, kann der „bösartige Datenverkehr“ real und messbar gemacht werden. Dies könnte auf beliebige C2-Beaconing-Aktivitäten einschließlich benutzerdefinierten Codes erweitert werden, um die Widerstandsfähigkeit der Erkennungslösung zu testen. Die Testanforderung sollte den Nachweis erfolgreicher täglicher Beaconing-Aktivitäten und der Befehlsausführung über eine Woche ohne Erkennung umfassen.

Wenn ein externer Penetrationstest oder ein Bug-Bounty-Programm wiederholt wird, sind die Unterschiede bei den Erkennungsraten messbar und für die Bewertung der Wirksamkeit und des ROI nützlich.

Mit einem rigorosen Testansatz lässt sich nicht nur die Wirksamkeit umfassend messen, sondern es können auch fortlaufende Zielwerte und Ziele im Verhältnis zu einer aktuellen oder historischen Basislinie festgelegt werden. Wenn dieselben Tests und Messungen für mehrere Lösungen durchgeführt werden, können deren Leistungen selbstverständlich problemlos verglichen und Kauf- beziehungsweise Implementierungsentscheidungen getroffen werden.

Designüberlegungen

Forschung und Design zu diesen Konzepten und zum Gesamtansatz werden ausführlicher behandelt in: Sicherheitssysteme und -methoden zur Erkennung formbarer Command-and-Control-Kommunikation (Mulugeta).

Vorteile

Anomalieerkennung neuer unbekannter Bedrohungen

Dieser Ansatz mindert unbekannte Bedrohungen wirksam, indem er Machine-Learning-Modelle nutzt, die auf dem für Benutzer innerhalb einer Organisation spezifischen Anwendungsverhalten trainiert wurden. Die granulare Benutzerrisikometrik reduziert falsch positive Ergebnisse erheblich.

Im Gegensatz dazu beruhen bestehende reaktive Ansätze auf der Identifizierung eines ersten Opfers beziehungsweise von Patient Null – einem Opfer für das Allgemeinwohl. Darauf folgen Analysen und Forschungen durch den Anbieter, die Tage oder sogar Monate dauern können, bevor der Anbieter eine neue Signatur oder Regel veröffentlicht, um die neue Bedrohung für diejenigen Kunden zu blockieren, die noch nicht angegriffen wurden. Dieser Ansatz ist konzeptbedingt unwirksam beim Blockieren neuer und aufkommender formbarer Bedrohungen.

Ein Ansatz zur Anomalieerkennung, der spezifische und abgestimmte Machine-Learning-Modelle verwendet, kann verdächtiges Verhalten auf einzigartige Weise erkennen, ohne dass ein Zyklus aus Analyse, Veröffentlichung und Aktualisierung erforderlich ist. Der Ansatz bleibt auch dann robust, wenn sich die Bedrohungstaktiken weiterentwickeln.

Umfassende Signalanalyse

Die Anomalieerkennung anhand eines umfassenden Satzes von Signalen wie Zeit, Volumen, TCP/IP-Kommunikation, SSL/TLS-Fingerprinting und Nutzlasten von Anwendungsprotokollen kann ausgefeilte, formbare C2-Kommunikation wirksam erkennen.

Erkennung gegnerischer Toolkits

Dieser Ansatz kann die Verwendung der neuesten C2-Framework-Tools und C2-Frameworks sowie neue und verdächtige C2-Beaconing-Aktivitäten wirksam erkennen. Dazu stützt er sich auf die Anomalieerkennung anhand eines breiten Spektrums von Netzwerksignalen, die für die Benutzer in der Umgebung spezifisch sind, und vergleicht diese mit dem legitimen, harmlosen Datenverkehr in der Umgebung.

Erkennungswirksamkeit

Aktuelle Ansätze – IPS-Signaturen und IP-/Domain-/URL-Sperren – übersehen einen hohen Anteil der fortschrittlichen C2-Kommunikation in der neuesten Malware, je nach Testszenario zwischen 40 % und 80 %.

Durch einen neuen Ansatz mit einem abgestimmten Machine-Learning-Modell, der Anomalieerkennung anhand eines umfangreichen Satzes von Signalen und einer granularen Risikometrik können mehr als 85–95 % dieser derzeit umgangenen Angriffe erkannt werden.

Dies führt zu einer Gesamterkennungsrate richtig positiver Ergebnisse von mehr als 95 % bei minimalen falsch positiven Ergebnissen.

Fazit

C2-Framework-Toolkits haben Angreifern ausgefeilte Techniken an die Hand gegeben, mit denen sie die Command-and-Control-Erkennung (C2) umgehen können. Insbesondere weithin verfügbare Toolkits wie Cobalt Strike, Brute Ratel und Mythic sind entweder als Open Source oder als gehackter beziehungsweise gestohlener kommerzieller Code zugänglich.

Traditionelle statische Ansätze, die sich stark auf statische Signaturen und Indikatoren wie IP-/URL-Sperrlisten stützen, weisen erhebliche Einschränkungen auf und können von diesen sich weiterentwickelnden Bedrohungen leicht umgangen werden.

Zur Bewältigung dieser Herausforderung ist ein grundlegend anderer Ansatz erforderlich, der Machine-Learning-Modelle verwendet. Diese Modelle integrieren einen umfassenden Satz von Netzwerksignalen und werden gezielt sowohl auf Benutzer- als auch auf Organisationsebene trainiert. Zusätzlich verwenden sie fein abgestufte Benutzerrisikometriken, um falsch positive Ergebnisse zu reduzieren und den Graubereich zu messen, der häufig mit Bedrohungen verbunden ist.

Die Wirksamkeit von Machine-Learning-Ansätzen sollte von den Benutzern sorgfältig bewertet werden. Rigorose Tests anhand einer robusten Testumgebung mit bösartigem und harmlosem Datenverkehr sind unerlässlich, um ihre Effektivität bei der Erkennung und Eindämmung dieser neuen Bedrohungen zu bestimmen.

Referenzen

1. „Cobalt Strike: Internationale Strafverfolgungsoperation geht gegen die illegale Nutzung des ‚Schweizer Taschenmessers‘ unter den Pentesting-Tools vor.“ The Record from Recorded Future News, 3. Juli 2024, https://therecord.media/cobalt-strike-law-enforcement-takedown. Abgerufen am 23. August 2024.
2. Gill, Andy. „Cobalt Strike-Profile verstehen – aktualisiert für Cobalt Strike 4.6.“ ZSEC Blog, 13. April 2022, https://blog.zsec.uk/cobalt-strike-profiles/. Abgerufen am 23. August 2024.
3. Larson, Selena, und Daniel Blackford. „Cobalt Strike: Bevorzugtes APT-Tool für Crimeware.“ Proofpoint, 29. Juni 2021, https://www.proofpoint.com/us/blog/threat-insight/cobalt-strike-favorite-tool-apt-crimeware.
4. Mudge, Raphael. „Malleable C2 Profiles: gmail.“ Malleable-C2-Profiles normal gmail.profile, rsmudge, 28. Februar 2018, https://github.com/rsmudge/Malleable-C2-Profiles/blob/master/normal/gmail.profile.
5. Mulugeta, Dagmawi. „Sicherheitssysteme und -methoden zur Erkennung formbarer Command-and-Control-Kommunikation.“ Free Patents Online, 20. August 2024, https://www.freepatentsonline.com/12069081.html.
6. Rahman, Alyssa. „Cobalt Strike | Definition der Komponenten von Cobalt Strike und BEACON.“ Google Cloud, 10. Dezember 2021, https://cloud.google.com/blog/topics/threat-intelligence/defining-cobalt-strike-components/.
7. Snort. „SID 1:25050.“ Snort-Regel: MALWARE-CNC Win.Trojan.Zeus variant outbound connection, https://www.snort.org/rule_docs/1-25050.
8. „SolarWinds-Lieferkettenangriff verwendet SUNBURST-Backdoor.“ Google Cloud, 13. Dezember 2020, https://cloud.google.com/blog/topics/threat-intelligence/evasive-attacker-leverages-solarwinds-supply-chain-compromises-with-sunburst-backdoor/.