Viper: Red-Team-Plattform mit LLM-Agent, Python-Modulen und unklarer Lizenz

Welche Lücke Viper im Red-Team-Werkzeugkasten füllt

Die meisten kommerziellen Frameworks in diesem Segment liefern Implants für Windows. Das README von Viper nennt in der Vergleichstabelle für Cobalt Strike, NightHawk und BruteRatel jeweils Windows als einzige Implant-Plattform, während Viper Windows, Linux und macOS aufführt. Für Aufträge, in denen Linux-Server oder macOS-Arbeitsplätze Teil der Zielumgebung sind, bedeutet das: entweder ein zweites Werkzeug parallel betreiben oder auf eine Plattform setzen, die alle drei Systeme abdeckt. Viper positioniert sich genau dort.

Dazu kommt der Preis. Die Tabelle nennt 12.600 US-Dollar pro Nutzer und Jahr für Cobalt Strike, 10.000 für NightHawk und 3.000 für BruteRatel. Viper steht in derselben Zeile mit Free. Die Zielgruppe sind damit Red-Team-Einheiten mit begrenztem Werkzeugbudget, Ausbildungsbetriebe und interne Sicherheitsteams, die Angriffssimulation regelmäßig selbst durchführen wollen, statt sie einzukaufen. Ob Free hier auch für den kommerziellen Einsatz gilt, lässt sich aus dem Material nicht beantworten. Das Repository gibt keine Lizenz an.

Wie die Plattform aufgebaut ist: Implants, Module, Agent

Viper besteht aus mehreren Schichten, die das README und die Repository-Struktur erkennen lassen. Die unterste Schicht sind die Implants für Windows, Linux und macOS. Darüber liegen nach Angabe des Projekts über 100 Post-Exploitation-Module, die die Phasen des MITRE ATT&CK Framework abdecken sollen. Diese Module sind laut README in Python geschrieben und lassen sich erweitern, was den üblichen Weg für eigene Anpassungen darstellt: neues Modul als Python-Datei, Einbindung in die Plattform, Aufruf über die Oberfläche.

Die oberste Schicht ist der LLM-Agent. Das Repository führt die Topics agent, ai, llm und mcp-server. Ein MCP-Server bedeutet, dass der Agent nicht fest mit einer einzelnen Modell-API verdrahtet ist, sondern über das Model Context Protocol mit externen Modellen oder Werkzeugen kommunizieren kann. Welche Modelle konkret unterstützt werden und ob ein lokaler Betrieb möglich ist, geht aus dem vorliegenden Material nicht hervor. Die Release-Bezeichnungen deuten auf eine aktive Weiterentwicklung in diesem Bereich hin: v3.1.9 trägt den Titel Let's Summarize, v3.1.11 den Titel Skill is all you need.

Quer dazu liegen Funktionen, die das README unter More Advanced Features aufführt: anti-tracing, handler firewall, defense evasion, pivot graph und automated notification. Der Pivot Graph wird in der Vergleichstabelle auch für die kommerziellen Produkte als vorhanden markiert, die Evasion-Spalte dagegen nur für NightHawk und BruteRatel, nicht für Cobalt Strike.

Installation und Betrieb: Docker als einziger belegter Weg

Das README verweist für den Einstieg auf zwei Seiten: www.viperrtp.com/guide/getting_start und www.viperrtp.com/guide/welcome_to_viper. Konkrete Installationsbefehle stehen im Repository-Text nicht. Belegt ist ein Docker-Hub-Repository unter hub.docker.com/u/viperplatform, auf das ein Badge im README verlinkt. Wer Viper ausprobieren will, findet dort die Images; die eigentliche Anleitung liegt auf der Website und nicht im Repository.

Das ist ein wiederkehrendes Muster bei diesem Projekt: Das README beschreibt Fähigkeiten und vergleicht mit kommerziellen Produkten, überlässt die Betriebsdetails aber der externen Dokumentation. Für die Planung heißt das, dass sich der tatsächliche Ressourcenbedarf, die unterstützten Datenbanken und die Konfigurationsschlüssel aus dem vorliegenden Material nicht ableiten lassen. Wer eine Kapazitätsplanung braucht, muss die Guide-Seiten lesen, bevor er eine Entscheidung trifft.

Ein Hinweis auf die Betriebsart lässt sich aus der Funktionsliste ziehen: automated notification und der Anspruch, eine Zielumgebung 24/7 zu überwachen, setzen einen dauerhaft laufenden Dienst voraus, nicht nur eine Sitzung auf dem Laptop des Operators. Die Plattform ist damit eher als Serverinstallation mit mehreren zugreifenden Teammitgliedern gedacht. Die Spalte Team Collaboration ist in der Vergleichstabelle für Viper, Cobalt Strike und BruteRatel gesetzt, für NightHawk nicht.

Der LLM-Agent: nützlich, aber nicht überprüfbar dokumentiert

Der LLM-Agent ist das Unterscheidungsmerkmal, das in der Vergleichstabelle nur Viper trägt. Keines der drei kommerziellen Produkte ist dort mit einem LLM-Agenten markiert. Das README beschreibt den Nutzen allgemein: verbesserte automatisierte Verarbeitung und Unterstützung bei Entscheidungen. Was der Agent konkret tut, ob er Befehle auf Implants vorschlägt, Ausgaben zusammenfasst oder selbstständig Module auswählt, steht dort nicht.

Die Release-Titel geben zumindest eine Richtung. Let's Summarize in v3.1.9 deutet auf Zusammenfassung von Ausgaben hin, Skill is all you need in v3.1.11 auf eine Erweiterung um Fähigkeiten oder Werkzeuge. Das ist eine plausible Lesart der Versionsnamen, mehr nicht. Wer den Agenten produktiv einsetzen will, muss zwei Fragen vorab klären, die das Material offen lässt: Welche Daten verlassen die eigene Infrastruktur, wenn ein externes Modell aufgerufen wird? Und wie reproduzierbar sind die Vorschläge des Agenten, wenn ein Auftrag dokumentiert werden muss?

Der zweite Punkt wiegt schwerer, als er klingt. Red-Team-Berichte müssen nachvollziehbar sein. Ein Agent, der Schritte vorschlägt oder zusammenfasst, erzeugt eine zusätzliche Ebene zwischen Operator und Protokoll. Ob Viper diese Ebene protokolliert, geht aus dem README nicht hervor.

Wo Viper an Grenzen stößt

Die auffälligste Lücke ist die Lizenz. Das Repository gibt keine an. Für eine Plattform, die Implants auf fremden Systemen platziert und Post-Exploitation-Module ausführt, ist das kein Formalproblem. Ohne Lizenzangabe ist unklar, ob und unter welchen Bedingungen der kommerzielle Einsatz erlaubt ist, ob Modifikationen weitergegeben werden dürfen und ob es Haftungsregelungen gibt. Wer Viper in einem Kundenauftrag einsetzt, sollte das vorher klären. Eine rechtliche Bewertung kann dieser Artikel nicht liefern.

Der zweite Punkt betrifft die Reichweite der Module. Über 100 Post-Exploitation-Module klingen nach breiter Abdeckung, aber die Zahl allein sagt nichts über die Verteilung über die drei Implant-Plattformen. Erfahrungsgemäß konzentrieren sich solche Sammlungen auf Windows, weil dort die meisten Techniken dokumentiert sind. Ob die Linux- und macOS-Implants dieselbe Modulbasis nutzen, lässt sich aus dem Material nicht beantworten.

Der dritte Punkt ist die Automatisierung. Das README nennt Orchestrierung und Benachrichtigungen für 24/7-Monitoring. Automatisierte Aktionen in einer Zielumgebung erzeugen jedoch Spuren, die ein menschlicher Operator bewusst streuen würde. Wer den Automatikmodus einschaltet, verliert einen Teil der Kontrolle über das Timing. Das ist eine Abwägung, keine Fehlfunktion, aber sie gehört in die Einsatzplanung.

Cobalt Strike als Referenz: der Unterschied liegt im Plugin-Modell

Der naheliegendste Vergleich ist Cobalt Strike, weil Viper ihn in der eigenen Tabelle an erster Stelle nennt. Die Unterschiede sind in drei Zeilen greifbar. Implants: Cobalt Strike unterstützt laut Tabelle nur Windows, Viper zusätzlich Linux und macOS. Benutzerdefinierte Plugins: Cobalt Strike nutzt CNA, Viper Python. Automatisierung und eingebaute Evasion: bei Cobalt Strike in der Tabelle nicht gesetzt, bei Viper beides.

Der Plugin-Punkt ist der praktisch relevanteste. CNA ist eine projektspezifische Skriptsprache mit eigener Lernkurve und begrenzter Ökosystemgröße. Python hat eine deutlich größere Bibliotheksbasis und mehr Entwickler, die es ohnehin beherrschen. Für Teams, die eigene Module schreiben wollen, senkt das die Einstiegshürde. Der Preis dafür ist, dass Python-Module in einer Angriffsplattform mehr Angriffsfläche für Fehler bieten als eine eng gefasste Skriptsprache.

Was Cobalt Strike in der Tabelle nicht zeigt: Reife und Support. Die Tabelle vergleicht Funktionen, nicht Betriebserfahrung. Ein kommerzielles Produkt mit bezahltem Support hat bei einem Vorfall während eines laufenden Auftrags einen anderen Eskalationsweg als ein Projekt, dessen Hilfe über Discord und die Projektwebsite läuft. Das README verlinkt einen Discord-Server und ein X-Profil. Beides ist für eine schnelle Rückfrage brauchbar, aber nicht mit einem Support-Vertrag gleichzusetzen.

Wartung, Upgrades und was die Versionsnummern verraten

Die Release-Historie zeigt einen Takt von etwa zwei Monaten zwischen den letzten drei Versionen: v3.1.9 im November 2025, v3.1.10 im Januar 2026, v3.1.11 im März 2026. Der letzte Push ins Repository liegt laut Metadaten auf dem 31. Mai 2026, also nach der letzten Veröffentlichung. Das spricht für laufende Arbeit zwischen den Releases. Die Versionsnummern bleiben im 3.1.x-Zweig, was auf inkrementelle Änderungen statt größerer Umbauten hindeutet.

Für die Betriebsplanung ist relevant, dass die Release-Titel inhaltliche Schwerpunkte benennen: Zusammenfassung in v3.1.9, Fähigkeiten in v3.1.11. Beide betreffen den LLM-Agenten. Wer den Agenten nicht nutzt, profitiert von diesen Versionen möglicherweise weniger als von Änderungen an den Implants oder Modulen, die in den Titeln nicht auftauchen.

Ein Upgrade-Pfad lässt sich aus dem Material nicht ableiten. Ob Datenbankmigrationen nötig sind, ob Implants auf Agent-Seite aktualisiert werden müssen und ob laufende Sitzungen einen Versionswechsel überstehen, steht nicht im README. Bei einer Plattform, die auf fremden Systemen läuft, ist das ein realer Kostenfaktor: Ein Implant-Update bedeutet neue Bereitstellung auf allen aktiven Zielen. Wer Viper dauerhaft betreibt, sollte die Upgrade-Schritte aus der Guide-Dokumentation vor dem ersten Produktiveinsatz einmal durchspielen.

Redaktionelles Fazit

Viper passt zu Red-Team-Einheiten, die eine selbst gehostete Plattform mit Multi-OS-Implants, Python-Modulentwicklung und Team-Collaboration suchen und die fehlende Lizenzangabe vor dem Produktiveinsatz klären können. Wer ausschließlich Windows-Ziele bearbeitet und mit Cobalt Strike oder BruteRatel bereits eingespielte Workflows hat, findet hier keinen zwingenden Grund zu wechseln. Vor dem ersten echten Auftrag drei Dinge prüfen: die tatsächliche Lizenz im Repository, ob die in der Tabelle genannten Evasion- und Automatisierungsfunktionen in der eigenen Version aktiv sind, und ob die Post-Exploitation-Module auf den Zielbetriebssystemen den benötigten Abdeckungsgrad erreichen.

Offizielle Quellen

1. FunnyWolf/Viper on GitHub
2. Issues
3. Project website
4. README
5. Releases