Techniken zur Botnetz-Erkennung zum Aufspüren moderner C2-Systeme

Dieser Leitfaden befasst sich ausschließlich mit der Erkennungsschicht: Wie SOC-Analysten und Erkennungsingenieure Botnetz-Aktivitäten im Datenverkehr aufspüren und wo die jeweiligen Techniken an ihre Grenzen stoßen. Wenn Sie die Grundlagen benötigen – was ein Botnetz ist, wie die zugrunde liegende malware sich verbreitet und welche Hauptfamilien es gibt –, lesen Sie bitte zunächst die Übersichtsseite.

Bei der Botnetz-Erkennung werden kompromittierte Hosts anhand des Netzwerkverhaltens identifiziert, das ihr Command-and-Control-Verkehr (C2) erzeugt – beispielsweise anhand der Periodizität von Beacon-Signalen, DNS-Anomalien und Fingerabdrücken verschlüsselter Kanäle –, anstatt durch den Abgleich mit bekannten Signaturen. Da jeder Bot mit seinem Controller kommunizieren muss, um funktionsfähig zu sein, ist der Kontrollkanal der zuverlässigste Ansatzpunkt für die Suche.

Von Signaturen zum Verhalten – warum die Botnetz-Erkennung über IOCs hinausgeht

Wie werden Botnetze erkannt? In der Praxis durch eine Verhaltensanalyse des Kontrollkanals: Periodizität der Beacon-Signale, anomale DNS-Aktivitäten wie DGA-Abfragen (Domain Generation Algorithm) und Fast-Flux, Fingerabdrücke verschlüsselter Sitzungen sowie das Verhalten auf Flow-Ebene. Der Abgleich mit Signaturen und Indikatoren für eine Kompromittierung (IOCs) spielt zwar nach wie vor eine Rolle, erfasst jedoch nur Infrastrukturen, die bereits bekannt sind, gemeldet und katalogisiert wurden.

IP- und Domain-Reputationslisten bilden die Grundvoraussetzung. Eine Sperrliste verhindert, dass Standard-Bots die Infrastruktur des letzten Monats wiederverwenden, und ein signaturbasiertes System zur Erkennung und Abwehr von Eindringlingen (IDS/IPS) kennzeichnet zuverlässig die Payloads und C2-Handshakes, für die es Definitionen enthält. Das Problem ist die Veralterung: Jeder Eintrag beschreibt Infrastruktur oder Tools, die ein Angreifer innerhalb von Minuten ersetzen kann, sodass eine Liste bereits ab dem Zeitpunkt ihrer Veröffentlichung an Wert verliert.

Die Fluktuation ist messbar. In seinem „Botnet Threat Update“ für Januar bis Juni 2026 stellte Spamhaus fest, dass Sliver Cobalt Strike als das am häufigsten anzutreffende C2-Framework überholt hat – mit einem Anstieg von 58 % innerhalb von sechs Monaten –, während die Zahl der von Spamhaus erfassten Botnetz-Command-and-Control-Server um 30 % auf 14.952 zurückging. Spamhaus beobachtete zudem einen Anstieg der .cn-C&C-Domains um 771 %, während missbräuchliche Registrierungen beim Registrar REGRU um 90 % zurückgingen – die Betreiber verlagern ihre Aktivitäten in großem Umfang, sobald Druck entsteht. Jede Erkennung, die auf frameworkspezifische Signaturen basiert, jagt ein Ziel, das sich schneller bewegt, als die Signatur-Pipeline mithalten kann. Um diese Fluktuation aus der Perspektive eines Verteidigers zu betrachten, sehen Sie sich an, wie das Beaconing von Sliver in der Praxis aussieht.

Die verhaltensbasierte Erkennung kehrt das Problem um. Anstatt bekanntermaßen schädliche Artefakte aufzuzählen, legt man eine Basislinie fest, wie Hosts normalerweise kommunizieren – Ziele, Zeitabläufe, Datenvolumen, Protokolle – und deckt Abweichungen auf, die mit einem Kontrollkanal übereinstimmen. Die Erkennung von Netzwerkanomalien liefert diese Disziplin zur Festlegung der Basislinie; in den folgenden Abschnitten wird sie auf die Signale angewendet, die ein Botnetz unweigerlich erzeugt. Ein Bot kann über Nacht Frameworks, Domains und Server wechseln. Was er jedoch nicht tun kann, ist, das Einchecken einzustellen, seine Treffpunkte nicht mehr aufzulösen oder nicht mehr überall denselben Client zu versenden – und jedes dieser Verhaltensweisen ist beobachtbar.

Erkennung von Command-and-Control-Signalen

„Beaconing“ bezeichnet den Check-in-Rhythmus, den ein Bot mit seinen Befehl und Kontrolle Server: Das Implantat geht in den Ruhezustand, wacht auf, fordert Aufgaben an und geht wieder in den Ruhezustand. Dieser Rhythmus ist das spezifischste Botnetz-Signal in einem Netzwerk, und es zu erkennen, ist ein Timing-Problem, kein Payload-Problem. MITRE verfolgt den Transport als T1071, Protokoll der Anwendungsschicht, da Check-ins in der Regel über gewöhnliches HTTPS oder DNS erfolgen.

Der naive Detektor basiert auf Periodizität. Er gruppiert die Datenströme nach Host-Paaren, berechnet die Zeitabstände zwischen aufeinanderfolgenden Verbindungen und sucht nach einer zu regelmäßigen Verteilung – eine feste Wartezeit von 60 Sekunden führt zu nahezu identischen Zeitabständen zwischen den Verbindungen, wie sie bei keinem menschlichen Surfverhalten auftreten. Eine geringe Varianz über Dutzende von Beobachtungen hinweg macht einen Kandidaten zu einem starken Anhaltspunkt.

Angreifer wissen das, weshalb jedes seriöse C2-Framework Jitter einbaut: Jedes Warteintervall wird innerhalb eines konfigurierten Bereichs zufällig variiert, wodurch die Verteilung der Zeitabstände zwischen den Anrufen so gestreut wird, dass einfache Varianzschwellenwerte nicht mehr ausgelöst werden. Ein naiver Abgleich der Intervalle scheitert hier. Jitter variiert jedoch nur die einzelnen Zeitabstände – er hebt den zugrunde liegenden Zeitplan nicht auf.

Die Frequenzbereichsanalyse macht sich diese Schwäche zunutze. Wandelt man die Verbindungszeitachse in den Frequenzbereich um – hierfür ist die Fourier-Transformation das Standardwerkzeug –, konzentriert ein wiederkehrendes Signal die Energie zu einer Spitze bei seiner zugrunde liegenden Check-in-Frequenz. Jitter verbreitert diese Spitze, löscht sie jedoch nicht aus. Solange das Signal wiederkehrt, lässt sich seine Grundfrequenz ermitteln – ein Ansatz, der öffentlich gegen jitterbehaftete C2-Verbindungen demonstriert wurde.

‍

Flow-Datensätze bilden die praktische Grundlage für all dies: Sie enthalten die Zeitstempel, Byte-Anzahlen und Dauerangaben, die für die Analyse benötigt werden, ohne dass dabei Nutzdaten erfasst werden. In der Netzwerkverkehrsanalyse wird diese Methodik ausführlich behandelt.

Machen Sie sich vor der Bereitstellung mit den Fehlermodi vertraut. „Low-and-Slow“-Beacons, die stundenlang im Ruhezustand verharren, treten möglicherweise zu selten auf, um innerhalb Ihres Analysefensters ausgewertet zu werden. Ereignisgesteuerte Callbacks, die bei Benutzeraktivitäten ausgelöst werden, weisen überhaupt keine stabile Frequenz auf. Und in Unternehmen gibt es zahlreiche legitime periodische Vorgänge – NTP, Update-Prüfungen, Telemetrie-Agenten, Überwachungssonden –, sodass die Periodizität allein nur als Filter für eine Vorauswahl dient, nicht aber als endgültiges Urteil. Überprüfen Sie die Kandidaten anhand der Seltenheit der Ziele, der Konsistenz der Sitzungsgrößen und der DNS-Signale im nächsten Abschnitt, bevor ein Analyst überhaupt eine Warnmeldung sieht.

DNS-basierte Erkennung – DGA und Fast Flux

Bots stehen vor einem Rendezvous-Problem – sie müssen ihren Controller auch dann noch finden, wenn Domains beschlagnahmt wurden –, und die beiden vorherrschenden Lösungen, Algorithmen zur Domain-Generierung und „Fast Flux“, hinterlassen beide überall im DNS Spuren.

Ein DGA generiert nach einem festgelegten Zeitplan eine große Anzahl potenzieller Domains; der Betreiber registriert nur einige wenige davon, und jeder Bot geht die Liste durch, bis eine davon aufgelöst wird. MITRE katalogisiert diese Technik als T1568.002, und die dazugehörige Erkennungsstrategie DET0419 (Analytik AN1178–AN1181) fasst die Anzeichen zusammen, auf die sich die Verteidiger geeinigt haben: Domainnamen mit hoher Zeichenentropie und geringer lexikalischer Ähnlichkeit zur natürlichen Sprache, wiederholte Abfragen an bisher unbekannte Domains und – das deutlichste Anzeichen – anhaltende NXDOMAIN-Fehler, wenn ein Host Kandidaten durchläuft, die nie registriert wurden.

„Fast Flux“ greift das Takedown-Modell von der anderen Seite an: Die Domain bleibt bestehen, während die dahinterliegende Infrastruktur wechselt. Das 2025 „Five Eyes“-Warnmeldung zu „Fast Flux“ beschreibt den „Single-Flux“-Ansatz, bei dem sich die A-Einträge zwischen kompromittierten Hosts abwechseln, sowie den „Double-Flux“-Ansatz, bei dem sich auch die Nameserver abwechseln – MITREs T1568.001 (DET0485). Die beobachtbaren Merkmale sind konkret: Time-to-Live-Werte (TTL), die so niedrig sind, dass eine Domain ihre IP-Adresse alle 3–5 Minuten wechselt, Dutzende bis Hunderte von IP-Adressen, die täglich durchlaufen werden, sowie inkonsistente Geolokalisierung bei den Auflösungen einer Domain. In der Sicherheitsempfehlung wird auch erläutert, warum das Blockieren von IP-Adressen versagt – jede Adresse wird außer Betrieb genommen, bevor sich eine Sperrliste verbreiten kann. Das DNS kann den C2-Kanal auch selbst übertragen, der als T1071.004 (DET0400).

Die aussagekräftigsten DNS-Signale, in der Reihenfolge, in der die meisten Teams sie überprüfen:

1. Domainnamen mit hoher Entropie, die zufällig wirken und keine lexikalische Bedeutung haben
2. Anhaltende NXDOMAIN-Spitzen von einem einzelnen internen Host
3. Neu registrierte oder bisher unbekannte Domains, für die wiederholt Suchanfragen eingehen
4. Ungewöhnlich niedrige DNS-TTL-Werte – von Sekunden bis zu einigen Minuten
5. Eine Domain, die täglich auf Dutzende oder Hunderte von IP-Adressen verweist
6. Uneinheitliche Geolokalisierung bei den aufgelösten IP-Adressen einer Domain
7. Rotierende Nameserver-Einträge (NS) neben rotierenden A-Einträgen
8. Flow-Datensätze, die zahlreiche kurzlebige Verbindungen zu wechselnden IP-Adressen zeigen

‍

DGA und Fast Flux erzeugen unterschiedliche DNS-Signale, die jeweils ein anderes harmloses Doppelgänger-Signal aufweisen.

Diese zweite Risikospalte ist struktureller Natur, und der Ratgeber sagt dies ganz klar: Die Unterscheidung zwischen bösartigem „Fast Flux“ und legitimem CDN- und Load-Balancer-Verhalten „bleibt eine anhaltende Herausforderung“. Niedrige TTLs und rotierende IPs sind für jedes große CDN charakteristisch. Der Kontext unterscheidet sie voneinander – CDN-Rotationen bleiben innerhalb bekannter Hosting-Bereiche, während „Fast Flux“ eine große Anzahl kompromittierter Hosts durchläuft, die als Proxys und Relaispunkte in Dienst gestellt werden. Erstellen Sie zunächst eine Basislinie für Ihre Resolver-Protokolle; jedes der oben genannten Signale ist ein Maß für Abweichungen, kein absoluter Wert.

Erkennung verschlüsselter C2-Kommunikation ohne Entschlüsselung

Wenn der C2-Kanal verschlüsselt ist – MITRE bezeichnet diese Technik als T1573, Verschlüsselter Kanal — Die Überprüfung der Nutzdaten liefert keine Ergebnisse, und eine Entschlüsselung in großem Maßstab ist häufig nicht durchführbar: Das Abfangen von TLS-Verbindungen ist aufwendig, und Implantate, die Zertifikate festlegen, weigern sich schlichtweg, eine Verbindung darüber herzustellen. Die praktikable Alternative besteht darin, den Client anhand eines Fingerabdrucks zu identifizieren, ohne den Klartext zu berühren.

Beim TLS-Fingerprinting werden die Parameter, die ein Client während des Handshakes übermittelt – Versionen, Verschlüsselungssuiten, Erweiterungen –, als Hash-Werte verarbeitet; all diese Informationen sind bereits vor Beginn der Verschlüsselung sichtbar. Ein C2-Implantat liefert einen einzigen TLS-Stack aus, sodass sein Handshake überall gleich aussieht, egal wo es landet. JA3 entwickelte den ursprünglichen Fingerabdruck, doch im Jahr 2023 begann Chromium damit, die Reihenfolge der TLS-Erweiterungen zu randomisieren, was die Stabilität von JA3 für einen großen Teil des Webverkehrs beeinträchtigte und die Entwicklung seines Nachfolgers JA4, spezifiziert von FoxIO, motivierte. JA4 ist gegen diese Randomisierung resistent, und die umfassendere JA4+-Suite geht über TLS hinaus und erstellt Fingerabdrücke des TCP-Verkehrs selbst. Zeek fügte im Januar 2026 native JA4-Unterstützung hinzu und machte die Technik damit für jedes Team zugänglich, das Open-Source-Netzwerküberwachung einsetzt.

Nun zu der Einschränkung, die in den Primärquellen unerwähnt bleibt: Weder die JA4-Spezifikation noch der Zeek-Bericht quantifizieren Fehlalarme, Kollisionen oder Abweichungen. Beide Probleme sind real. Fingerabdrücke kollidieren – Tausende harmloser Anwendungen nutzen gemeinsame TLS-Bibliotheken, sodass ein Hash, der mit einem bekannten Implantat übereinstimmt, ebenso gut zu einem gewöhnlichen Tool passen kann, das auf demselben Stack basiert. Fingerabdrücke driften zudem – jedes Client-Update kann den Handshake verändern und Ihre Übereinstimmungslisten stillschweigend veralten lassen. Behandeln Sie einen Fingerabdruck als ein korrelierendes Signal, niemals als endgültiges Urteil.

Dies ist der allgemeine Ablauf einer „evasion-aware“-Erkennung. Durch die Verschlüsselung wird die Nutzlast entfernt, der Handshake und das Timing bleiben jedoch erhalten, sodass das Fingerprinting mit der Metadatenanalyse aus dem Abschnitt zum Beaconing kombiniert werden kann – Sitzungsdauern, Paketgrößenverteilungen und Byte-Verhältnisse bleiben im verschlüsselten Datenverkehr weiterhin beobachtbar. Das Argument für die Modellierung des C2-Verhaltens anstelle einer Entschlüsselung zieht sich durch den gesamten Stack.

Erkennung mittels maschinellem Lernen und das Problem der falsch-positiven Ergebnisse

Die veröffentlichten Ergebnisse zum maschinellen Lernen für die Botnetz-Erkennung sehen spektakulär aus. Eine Studie aus dem Jahr 2024 berichtete von einer Falsch-Positiv-Rate (FPR) von 1,53 % auf dem IoT-23-Datensatz, wobei 100 % der C2-Kommunikation auf Paketbasis und 94 % auf Flussbasis identifiziert wurden. Eine Veröffentlichung aus dem Jahr 2025 zum Thema „Stacking-Classifier“ berichtete von einer Testgenauigkeit von 97,94 % auf dem UNSW-NB15-Datensatz – bei einer Genauigkeit von 99,99 % auf dem Trainingsdatensatz. Lesen Sie das Kleingedruckte, bevor Sie auf der Grundlage solcher Zahlen Ihr Budget planen.

Beginnen wir damit, was die Datensätze eigentlich sind. IoT-23 besteht aus echter malware , die auf echter Hardware malware – allerdings in einer kontrollierten Laborumgebung und nicht in einem Produktionsnetzwerk. UNSW-NB15 ist synthetischer Datenverkehr, der von einem IXIA-Testtool generiert wurde. Keiner der beiden Datensätze enthält den unübersichtlichen, schwankenden und gegen Richtlinien verstoßenden Datenverkehr eines realen Unternehmens – und genau dort entstehen Fehlalarme. Die im Benchmark gemessene Genauigkeit spiegelt die Eignung für diesen Benchmark wider.

Nun zur Rechnung – und um es klarzustellen: Dies ist unsere Interpretation, keine Behauptung, die in einer der beiden Veröffentlichungen aufgestellt wird. Eine FPR von 1,53 % klingt vernachlässigbar, bis die Basisrate diesen Wert multipliziert: Bei einer Million Transaktionen pro Tag – einem für ein mittelständisches Unternehmen eher bescheidenen Volumen – entsprechen 1,53 % etwa 15.300 Fehlalarmen täglich. Kein SOC sortiert das aus. Nach derselben Logik interpretieren wir eine Trainingsgenauigkeit von 99,99 % als klassisches Anzeichen für Überanpassung – das Modell hat sich seine Testumgebung eingeprägt, und Testumgebungen lassen sich nicht auf die Praxis übertragen.

Benchmark-Ergebnisse messen die Übereinstimmung mit dem Benchmark, nicht die Leistung im realen Unternehmensdatenverkehr.

Nichts davon macht ML nutzlos – vielmehr wird die Präzisionsoptimierung zur eigentlichen Arbeit. Beschränken Sie Modelle auf eng gefasste, gut definierte Fragestellungen, korrelieren Sie deren Ergebnisse mit der oben genannten Periodizität und den DNS-Signalen, ergänzen Sie Kandidaten mit Bedrohungsinformationen und unterdrücken Sie bekanntermaßen harmlose periodische Dienste, bevor überhaupt ein Alarm ausgelöst wird. Diese Optimierungsdisziplin ist das „Detection Engineering“, und genau das unterscheidet einen Benchmark von einem Detektor. Die Erkenntnis ist herstellerunabhängig – die Basisrate, nicht das Modell eines bestimmten Produkts, ist der Grund, warum jede Erkennungskategorie mit Fehlalarmen bei Botnetzen zu kämpfen hat.

Erkennung dezentraler, agentenloser und P2P-Botnetze

Moderne Botnetze bestehen zunehmend aus Geräten, die von keinem Sicherheitsteam verwaltet werden. Im Netzwerk von Cloudflare ließ sich der DDoS-Angriff von Ende 2025, der ein Rekordausmaß erreichte – und den Cloudflare mit dem Aisuru-Kimwolf-Botnetz in Verbindung bringt –, auf eine Gruppe von „vorwiegend Android-TVs“ zurückführen, deren Anzahl auf 1 bis 4 Millionen Hosts geschätzt wurde. Im März 2026 zerschlugen das US-Justizministerium und internationale Partner die Infrastruktur hinter vier Botnetzen , die mehr als drei Millionen IoT-Geräte kompromittiert hatten , wie „Krebs on Security“ berichtete. Niemand installiert einen endpoint auf einem Fernseher: Bei nicht verwalteten IoT-Geräten ist die Spalte endpoint naturgemäß leer, und die Erkennung kann ausschließlich im Netzwerk erfolgen.

Endpoint Netzwerktelemetrie erfassen jeweils unterschiedliche Teile eines Botnetzes, wobei nur die Netzwerktelemetrie agentenlose Geräte abdeckt.

Botnetze mit privaten Proxys verschärfen das Problem. Im Jahr 2026 beschrieb Googles Threat-Intelligence-Gruppe (GTIG) das NetNut/Popa-Proxy-Netzwerk: Mindestens zwei Millionen Geräte, die über in Smart-TVs und Streaming-Boxen eingebettete SDKs registriert wurden, wobei in einer einzigen Woche 316 verschiedene Bedrohungscluster beobachtet wurden, die mutmaßliche NetNut-Exit-Knoten nutzten. Da dieser Datenverkehr aus dem Adressraum gewöhnlicher Verbraucher-ISPs stammt, wird er von Reputations- und Geolokalisierungs-Heuristiken als harmlos eingestuft – obwohl die Fluss- und Geolokalisierungs-Primitiven des „Fast Flux“-Hinweises weiterhin zum Tragen kommen.

Bei Peer-to-Peer-Architekturen entfällt der zentrale Server vollständig: Es gibt keinen einzelnen C2-Server, der als „Sinkhole“ genutzt werden könnte, und die Flussanalyse allein reicht für die Erkennung nicht aus. Graphbasierte Methoden modellieren stattdessen die Kommunikationstopologie – veröffentlichte topologische Detektoren erzielten im Durchschnitt einen F1-Wert von 99,140 %, allerdings im Jahr 2020 und auf Benchmark-Topologien. Betrachten Sie dies als wissenschaftlichen Nachweis dafür, dass der Ansatz funktioniert, nicht als einsatzbereite Funktion.

Die Abschaltungen erzählen dieselbe Geschichte aus einer anderen Perspektive. Europol meldete im Rahmen der Operation „Endgame“ die Beschlagnahmung von 1.025 Servern – was gerade deshalb so effektiv war, weil diese Operationen über eine zentralisierte C2-Steuerung verfügten. Fast-Flux-, DGA- und P2P-Techniken dienen alle dazu, diesem Ausfallmodus zu entgehen, weshalb das Aufspüren der in ein Botnetz eingezogenen Geräte nicht allein den Abschaltungen überlassen werden kann.

Zuordnung der Botnetz-Erkennung zu MITRE ATT&CK NIST CSF

Durch die Zuordnung zu einem Framework bleibt diese Arbeit nachvollziehbar. Aktuell MITRE ATT&CK ist Version 19.1 – 15 Taktiken, wobei die bisherige „Verteidigungsausweichung“ in „Tarnung“ (0005) und Verteidigungsbeeinträchtigung (0112) – und die damit verbundenen Konzepte für Erkennungsstrategien und Analysen wurden erstmals vorgestellt in Version 18, veröffentlicht am 28. Oktober 2025. Auf der NIST CSF 2.0 (CSWP 29, veröffentlicht am 26. Februar 2024) außerdem eine kontinuierliche Netzwerküberwachung unter DE.CM-01 ist der Hauptanker, DE.CM-09 umfasst die Überwachung endpoint Rechenressourcen sowie DE.AE-02, DE.AE-03und DE.AE-07 Umfassende Ereignisanalyse, Korrelation verschiedener Quellen und Anreicherung von Erkenntnissen. Die nachstehende Übersicht ordnet jedes Signal in diesem Leitfaden beiden Rahmenwerken zu – und bindet es in Ihren übergeordneten Erkennung von Bedrohungen Programm.

Jedes auf dieser Seite aufgeführte Botnetz-Erkennungssignal ist einer benannten MITRE ATT&CK und einer NIST CSF 2.0 DETECT-Unterkategorie zugeordnet.

Moderne Ansätze zur Botnetz-Erkennung

All dies läuft auf eine operative Vorgehensweise hinaus: Gehen Sie von einer Kompromittierung aus, überwachen Sie das Netzwerk und modellieren Sie das Verhalten – denn das Botnetz, das Sie am dringendsten aufspüren müssen, läuft auf einem Gerät, das Sie nicht verwalten, über einen Kanal, den Sie nicht entschlüsseln können, und nutzt eine Infrastruktur, die in keiner Blockliste erfasst ist. Network Detection and Response (NDR) ist die operative Ebene, auf der diese Techniken kontinuierlich als systematisch entwickelte, korrelierte Erkennungsmaßnahmen und nicht als einmalige Suchaktionen zum Einsatz kommen. Ein breiter Markt an Botnetz-Erkennungstools implementiert Teile dieses Stacks; die Bewertung dieser Landschaft ist eine andere Aufgabe als das Verständnis der Techniken, auf denen sie basiert.

Wie Vectra AI der Botnetz-Erkennung Vectra AI

Vectra AI die Botnetz-Erkennung eher als ein Problem der Verhaltensmodellierung denn als ein Signaturproblem. Attack Signal Intelligence das Verhalten von Befehls- und Kontrollkanälen im Netzwerk – Beaconing-Rhythmus, DNS-Muster, die mit der Domain-Generierung übereinstimmen, Merkmale verschlüsselter Kanäle – und korreliert diese Verhaltensweisen über verschiedene Hosts hinweg, um einen echten Kontrollkanal von routinemäßigen Periodizitäten zu unterscheiden. Da die Analyse netzwerkbasiert ist, lässt sie sich gleichermaßen auf agentenlose Geräte anwenden, bei denen niemals endpoint vorliegen werden.

Schlussfolgerung

Die Botnetz-Erkennung hat sich auf einen Bereich verlagert, dem Angreifer nicht folgen können: die Verhaltensweisen, die ein Bot zeigen muss, um zu funktionieren. Signaturen und Sperrlisten filtern zwar nach wie vor alltägliches Rauschen heraus, doch die beständigen Signale sind Periodizität, die Jitter übersteht, DNS-Verhalten, das Domain-Wechsel übersteht, Fingerabdrücke und Zeitabläufe, die Verschlüsselung überstehen, sowie Netzwerktransparenz, die auch ohne Agent erhalten bleibt. Bauen Sie diese vier Komponenten auf, ordnen Sie sie MITRE ATT&CK dem NIST CSF-Rahmenwerk zu und nehmen Sie die Feinabstimmung unter Berücksichtigung der Basisrate vor.

‍