In meinem letzten Beitrag,"The Cutting Edge: AI's Inevitable Rise in Offensive Security", habe ich untersucht, wie KI beginnt, Red Team-Operationen zu automatisieren und zu verstärken. Wir bewegen uns von manuell gesteuerten Tools zu autonomen Agenten, die Strategien entwickeln und sich anpassen können. Wie in dem bereitgestellten Forschungspapier"MCP as a Malicious Control Protocol - Red Teaming with AI Agents"(MCP als bösartiges Kontrollprotokoll - Red Teaming mit KI-Agenten) hervorgehoben wird, stehen viele aktuelle generative Red Teaming-Methoden jedoch vor Herausforderungen wie Halluzinationen, Kontextbeschränkungen und Kompromissen zwischen spezialisierten Modellen und allgemeineren, modularen Frameworks.
Heute möchte ich auf eine Lösung eingehen, die in diesem Papier vorgeschlagen wurde und einen Paradigmenwechsel für die Befehls- und Kontrollsysteme (C2) darstellt: das Model Context Protocol (MCP). Dabei handelt es sich nicht nur um eine inkrementelle Verbesserung, sondern um eine neue Denkweise in Bezug auf Führung und Kontrolle.
Herkömmliche C2-Systeme funktionieren trotz ihrer Nützlichkeit nach einem vorhersehbaren, rhythmischen Zyklus: Das Implantat "funkt" zurück zum C2-Server, um nach neuen Befehlen zu suchen. Diese Regelmäßigkeit stellt ein erhebliches Risiko für die operative Sicherheit (OPSEC) dar. Moderne NDR-Lösungen sind speziell darauf ausgerichtet, diese Muster zu erkennen. Sobald ein NDR diesen gleichmäßigen Herzschlag feststellt, sind das Implantat und die Operation verbrannt.
Die MCP-Architektur ändert dieses Modell grundlegend, indem sie asynchrone, parallele Operationen ohne regelmäßiges Beaconing ermöglicht. Anstatt sich ständig zu melden, kommunizieren die Agenten verdeckt und vermischen ihren Datenverkehr mit dem, was wie normale KI-Aktivitäten im Unternehmen aussieht. Dies ist der Kern ihrer Stärke: Sie verstecken sich im Rauschen der legitimen Netzwerkaktivitäten und sind daher für Verteidiger nur schwer zu isolieren.
Unsere Architektur (Abbildung oben) besteht aus 3 Hauptkomponenten. Der MCP-Agent hat zwei Kommunikationswege: einen mit dem MCP-Server und einen weiteren mit dem LLM-Anbieter, in diesem Fall Anthropic.
- MCP-Server: Hier wird die übergeordnete Aufgabe zugewiesen und zurückgegeben.
- MCP-Agent: Stellt eine Verbindung zum MCP-Server her, um die Aufgabe zu übernehmen, trennt die Verbindung und erstattet später Bericht. Der MCP-Agent kommuniziert auch hin und her mit der LLM-API, die den Angriff ausführt.
- Anthropische API: Der eigentliche Angreifer in diesem Fall. Mit einer Kombination aus einer guten System-Eingabeaufforderung und einer High-Level-Aufgabe sind wir in der Lage, den gutartigen LLM dazu zu bringen, vollständige Exploits durchzuführen und zu melden, wenn die Aufgabe abgeschlossen ist.
Jenseits von Beaconing
Die nachstehende Abbildung zeigt einen Cobalt Strike , bei dem die Beaconing-Muster deutlich zu erkennen sind. Wenn der Angreifer angreift, stellen die signifikanten Spitzen große Datenmengen dar, die übertragen werden, hauptsächlich Befehlsausgaben.
Die nachstehende Abbildung zeigt dagegen, wie die Kommunikation mit unserem agentenbasierten Rahmenwerk aussieht. Diese Kommunikation ist ereignisgesteuert; eine Aufgabe wird einem Agenten zugewiesen, der mit dem MCP verbunden ist. Der Agent nimmt die Aufgabe an und schließt die Verbindung mit dem MCP-Server. Nachdem er seine Aufgabe erfüllt hat, verbindet er sich wieder mit dem Server und meldet seine Ergebnisse. In der folgenden Abbildung sind zwei solcher Fälle (zwei Angriffe) dargestellt. Der große blaue Spike im zweiten Spike eines jeden Angriffs zeigt den Punkt an, an dem der Agent alle wichtigen Informationen zurücksendet.
Lassen Sie uns nun einen dieser Angriffe näher betrachten. Das untere Diagramm in der Abbildung unten stellt die Kommunikation der Agenten mit dem MCP-Server dar, gezoomt auf einen der oben genannten Angriffe. Es ist deutlich zu erkennen, dass der Agent nur am Anfang und am Ende der Aufgabe Bericht erstattet, während die eigentliche Hin- und Her-Kommunikation zwischen dem Agenten und der Anthropic API stattfindet.
Wie wir sehen können, bildet sich ein Muster heraus, in dem wir dieses Verhalten erkennen können, z. B. zunehmende blaue Spitzen, wenn der Kontext im Laufe der Zeit stärker gefüllt wird. Aber schauen wir uns jetzt die folgende Abbildung an:
Die Änderung des Musters ist offensichtlich: Der Agent nutzte eine Streaming-Antwort und verwaltete sein Kontextfenster effektiver, wodurch das zuvor identifizierte Muster völlig verändert wurde. Erschwerend kommt hinzu, dass viele Technologieunternehmen Tools wie Claude Code oder Cursor einsetzen, die API-Aufrufe an Anthropic durchführen, wodurch diese Muster aufgrund des Rauschens der harmlosen Aufrufe noch schwieriger zu unterscheiden sind.
EDR-Umgehung und polymorpher Schwarm
Man kann sich dies als einen Wechsel von einem einsamen, statischen Spion zu einem dynamischen Team von Spähern vorstellen, die ihre Gestalt ändern. "Polymorph" bedeutet, dass diese Agenten ihre Eigenschaften ändern können, um sich je nach Umgebung der Entdeckung zu entziehen. "Verteilt" bedeutet, dass zahlreiche Agenten gleichzeitig arbeiten. Dieser "Schwarm" ist zu Folgendem in der Lage:
- Paralleles Arbeiten: Anstatt dass ein einzelner Agent eine Aufgabe nach der anderen ausführt, kann der Schwarm gleichzeitig verschiedene Netzwerksegmente abbilden, auf verschiedene Schwachstellen testen und Informationen sammeln.
- Austausch von Informationen in Echtzeit: Der MCP dient als zentrales Nervensystem für diesen Schwarm. Wenn ein Agent einen potenziellen Pfad, eine schwache Zugangsberechtigung oder einen ungepatchten Dienst entdeckt, gibt er diese Informationen sofort an den gesamten Schwarm weiter und ermöglicht so eine kollektive Neufestlegung der Prioritäten und die Nutzung neuer Möglichkeiten.
- Erhöhte Widerstandsfähigkeit: Sollte ein Agent entdeckt und neutralisiert werden, ist die Mission nicht gefährdet. Der verbleibende Schwarm passt sich an und setzt die Operation fort, wobei er aus der Entdeckung lernt, um seine eigene Tarnung zu verbessern.
Eine Fallstudie aus der Praxis: Schnelle Domain-Kompromittierung
Wie wir in den EDR-Umgehungsgraphen gesehen haben, ist dies nicht nur theoretisch, sondern wir haben unser Alter mit genau dieser Architektur in realen Netzwerken und auf Testmaschinen eingesetzt. Die Ergebnisse der EDR-Umgehung hängen stark von dem System ab, das der Agent verwendet, sowie von der Aufgabe, die ihm zugewiesen wurde. Zum Beispiel, wenn er die Aufgabe hat:
"Testen Sie die EDR-Umgehungsmöglichkeiten mit BYOVDKit und einfacher Prozessmanipulation. Identifizieren Sie zunächst die laufende EDR-Lösung und versuchen Sie dann, mit BYOVDKit einen anfälligen Treiber zu laden, um den Prozessschutz zu deaktivieren. Testen Sie die einfache Prozessinjektion und dokumentieren Sie, was erkannt wird. Wenn Sie erfolgreich sind, gehen Sie zu einfachen Techniken der lateralen Bewegung über. "
Erzählung über die Ausführung: Der Agent hat dieses Ziel selbstständig in einen Mehrphasenplan umgesetzt und ausgeführt.
1) Phase 1: EDR-Identifizierung (Erfolg)
Der Agent führte zunächst eine Erkundung durch, um die aktive Sicherheitslösung zu identifizieren. Er identifizierte MsMpEng.exe und MpDefenderCoreService.exe erfolgreich als die primären EDR-Prozesse. Außerdem wurde der Status des Verteidigers abgefragt und bestätigt, dass alle wichtigen Schutzfunktionen aktiv waren, einschließlich RealTimeProtectionEnabled: True und, besonders wichtig, IsTamperProtected: True|.
2) Phase 2: Erkundung des verwundbaren Fahrers (durch Härtung blockiert)
Nach seinem Plan, einen "Bring Your Own Vulnerable Driver"-Angriff (BYOVD) zu versuchen, durchsuchte der Agent das System nach gängigen anfälligen Treibern, fand aber keine. Dies zeigte, dass der Host nicht für diesen gängigen Angriffsvektor anfällig war, und hinderte den Agenten daran, mit der Manipulation auf Kernel-Ebene fortzufahren.
3) Phase 3: Versuch der Prozessinjektion (durch AMSI blockiert)
Nach dem fehlgeschlagenen BYOVD-Ansatz versuchte der Agent eine klassische Prozessinjektionstechnik in explorer.exe mithilfe von PowerShell. Der Versuch schlug sofort mit einem PowerShell-Parsing-Fehler fehl, der in der KI-Zusammenfassung des Agenten korrekt darauf zurückgeführt wurde, dass Microsofts Malware Scan Interface (AMSI) die Ausführung des bösartigen Skripts im Speicher verhindert.
Der Testlauf war aus Sicht der Bewertung ein durchschlagender Erfolg. Der Agent führte eigenständig einen komplexen Plan aus, identifizierte die aktiven Verteidigungsmaßnahmen korrekt und wurde schließlich von den mehrschichtigen Sicherheitskontrollen blockiert. Am wichtigsten ist jedoch, dass der gesamte Vorgang, einschließlich des fehlgeschlagenen Einschleusungsversuchs, von dem von uns verwendeten EDR zu keinerlei Erkennungen führte .
Gemeinsame Intelligenz mit Demo (Video)
In unserem Test haben wir zwei Agenten eingesetzt, um das Konzept der gemeinsamen Intelligenz zu testen. Das Ergebnis? Der Agent kompromittierte den Router im Netzwerk (Video unten).
Die Agenten haben erfolgreich einen Netzwerk-Router kompromittiert und damit die praktische Wirksamkeit des Übergangs von monolithischen Agenten zu einem koordinierten Schwarm demonstriert. Es kombiniert die hochentwickelten Planungsfähigkeiten von Large Language Models (LLMs) mit einem C2-Rahmen, der unauffällig und schnell sein kann.
Gut und schlecht:
Dieses Tool bietet erhebliche Vorteile für Penetrationstester, da es eine schnelle Bewertung der Netzwerksituation und eine proaktive Erkennung von LLM-gesteuerten Verhaltensweisen ermöglicht. Es stellt jedoch auch ein Risiko dar, da es Personen mit begrenzten Kenntnissen im Bereich der Cybersicherheit in die Lage versetzen könnte, mit "Vibe Hacking" erheblichen Schaden anzurichten.