Viper : plateforme de red teaming avec agent LLM, ce que le dépôt montre vraiment
Adversary simulation and Red teaming platform with AI
En bref
- De quoi s’agit-il ?
- Viper rassemble implants, modules post-exploitation et un agent LLM dans une interface unique, sous licence non précisée dans le dépôt. Voici ce que la documentation permet d'affirmer, et ce qu'elle laisse en suspens.
- À qui s’adresse-t-il ?
- Viper vise les équipes rouges qui veulent un implant multi-OS, une interface visuelle et une extensibilité Python sans acheter de licence commerciale. Il n'est pas adapté aux tests d'intrusion ponctuels sur un seul poste Windows, ni aux contextes où la licence du dépôt doit être connue avant tout déploiement.
- Puis-je l’utiliser commercialement ?
- Pas sans autorisation. GitHub ne trouve aucun fichier de licence dans ce dépôt, et sans licence tous les droits sont réservés par défaut : vous pouvez lire le code, mais pas le réutiliser. Consultez le README ou demandez l’accord des auteurs avant de l’utiliser.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 108 jours.
- En quel langage est-il écrit ?
- GitHub n’indique pas de langage principal pour ce dépôt.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème que Viper revendique résoudre
Une équipe rouge qui travaille sur Windows, Linux et macOS doit souvent assembler plusieurs outils : un framework d'exploitation, un système de gestion des sessions, des modules post-exploitation, un mécanisme de pivot. Viper se présente comme une plateforme qui regroupe ces briques. Le README liste les implants pour les trois systèmes, plus de 100 modules post-exploitation couvrant les étapes du framework MITRE ATT&CK, une interface visuelle, un graphe de pivot et des notifications automatisées.
Le public visé est explicitement l'équipe rouge et la simulation d'adversaire, pas l'audit de configuration ni la détection. Le tableau comparatif du README positionne Viper face à Cobalt Strike, NightHawk et BruteRatel sur des critères précis : systèmes d'exploitation pris en charge par les implants, langage des plugins, présence d'un agent LLM, prix. C'est une prise de position éditoriale du projet, pas une mesure indépendante, et il faut la lire comme telle.
Ce que le dépôt expose comme mécanismes
La description du dépôt mentionne un agent, un serveur MCP, un composant LLM et des thèmes comme cobalt-strike et metasploit-framework. Le README confirme un agent LLM intégré et des workflows automatisés avec orchestration et notifications. Il ne détaille pas le chemin des données entre l'agent, les modules et les sessions. On sait donc qu'un agent LLM existe et qu'il est présenté comme un appui à la décision et au traitement automatisé, sans pouvoir décrire sa boucle d'appel, son modèle, ni la façon dont il reçoit le contexte d'une session.
L'extensibilité est mieux documentée : les modules personnalisés s'écrivent en Python. C'est un choix qui ouvre l'écosystème à des personnes qui ne veulent pas apprendre un langage de script propriétaire, contrairement aux plugins CNA de Cobalt Strike. Le revers est qu'un module Python hérite des dépendances de l'environnement dans lequel il tourne, et le README ne dit rien sur l'isolation de ces modules.
Installation : ce que la documentation donne
Le README ne contient aucune commande d'installation. Il renvoie vers deux pages du site officiel, Getting-Started et Documentation, et vers une image Docker publiée sous le compte viperplatform sur Docker Hub. C'est tout ce que le matériel fourni permet d'affirmer sur la mise en route.
Je ne peux donc pas écrire ici une séquence de commandes vérifiée. Si vous évaluez Viper, la première étape concrète est d'ouvrir la page Getting-Started et de relever la commande de démarrage du conteneur ainsi que les variables d'environnement attendues. Tant que ces éléments ne sont pas extraits de la documentation, toute procédure d'installation citée ailleurs serait une reconstitution.
Le tableau comparatif et ses angles morts
Le tableau du README attribue à Viper la gratuité, les implants multi-OS, les plugins Python, l'évasion intégrée, l'automatisation, la collaboration d'équipe et l'agent LLM. Cobalt Strike y apparaît sans évasion intégrée ni automatisation, NightHawk sans collaboration d'équipe ni plugins, BruteRatel sans automatisation ni plugins. Les prix affichés sont de 12 600 dollars par utilisateur et par an pour Cobalt Strike, 10 000 pour NightHawk, 3 000 pour BruteRatel.
Ces colonnes sont utiles pour comprendre la stratégie du projet, pas pour trancher un choix technique. Un tableau rempli par le projet lui-même ne mesure ni la stabilité des implants, ni la qualité de la documentation, ni la réactivité en cas de correctif. Le prix de Viper est indiqué comme gratuit, mais le dépôt ne fournit pas d'identifiant de licence, et gratuit ne veut pas dire sans conditions.
Limites et cas où Viper n'est pas le bon outil
La première limite est documentaire. Le README est un argumentaire : il énumère des capacités et des captures d'écran, sans décrire les prérequis, les ports, le stockage des sessions ni la rotation des clés. Pour une plateforme qui pilote des accès persistants sur des machines cibles, l'absence de ces détails dans le matériel fourni est un point de vigilance, pas un détail.
La deuxième concerne l'agent LLM. Un agent qui intervient dans une chaîne d'exploitation reçoit du contexte sensible et propose des actions. Le README ne dit rien sur l'hébergement du modèle, sur le fait qu'un modèle distant soit appelé, ni sur ce qui est journalisé. Ces questions conditionnent l'usage en environnement client.
Enfin, Viper est un mauvais choix si votre besoin se limite à un poste Windows unique avec un script maison : la surface d'exploitation de la plateforme dépasse le problème. Il est également mal adapté aux équipes qui doivent faire valider un outil par un service juridique avant déploiement, puisque le dépôt ne déclare pas de licence.
Alternative réelle : Metasploit Framework
Metasploit Framework apparaît dans les thèmes du dépôt et constitue une alternative crédible pour une partie du périmètre. La différence d'approche est nette. Metasploit est piloté en ligne de commande avec msfconsole, les modules sont écrits en Ruby, et l'exploitation est lancée module par module. Il n'y a pas d'interface visuelle intégrée, pas de graphe de pivot, pas d'agent LLM.
Viper ajoute précisément la couche que Metasploit laisse à l'opérateur : interface, gestion des sessions, automatisation, notifications. Le prix de cette couche est une plateforme supplémentaire à maintenir et à comprendre. Si votre travail consiste à enchaîner des modules connus sur quelques cibles et que vous connaissez déjà msfconsole, Metasploit couvre le besoin sans introduire de composant LLM dans la chaîne.
Mise à jour, licence et coût réel
Le rythme de publication est soutenu : v3.1.9 en novembre 2025, v3.1.10 en janvier 2026, v3.1.11 en mars 2026, avec un dernier push sur master en mai 2026. Les titres de version sont descriptifs plutôt que techniques. Cela indique un projet actif, ce qui ne dit rien sur la compatibilité entre versions ni sur la procédure de migration.
Le coût d'exploitation se situe donc dans les mises à jour : chaque nouvelle version peut modifier les modules Python, le comportement de l'agent ou la structure des sessions. Le dépôt ne fournit pas de notes de migration dans le matériel disponible. Sur la licence, je ne peux rien affirmer : ni le fichier LICENSE, ni un identifiant SPDX, ni une mention dans le README ne figurent ici. Avant tout usage en production, c'est le premier élément à localiser dans le dépôt, car il détermine ce que vous avez le droit de faire du code et des modules que vous écrirez.
Conclusion éditoriale
Viper vise les équipes rouges qui veulent un implant multi-OS, une interface visuelle et une extensibilité Python sans acheter de licence commerciale. Il n'est pas adapté aux tests d'intrusion ponctuels sur un seul poste Windows, ni aux contextes où la licence du dépôt doit être connue avant tout déploiement. Avant d'aller plus loin, vérifiez deux choses dans le dépôt : le fichier de licence et la procédure de mise à jour depuis la version installée.
Notes de la communauté