Au fil de ma formation, j'ai accumulé une trentaine de scripts Python de pentest — recon, analyse réseau, forensic, remédiation, sécurité web... Chacun fonctionnait très bien seul, en ligne de commande. Le problème est venu de leur nombre : les lancer un par un, relire un mur de texte défilant dans un terminal, recopier à la main un résultat intéressant pour ne pas le perdre. Ça marchait, mais ça ne passait pas à l'échelle. PenBox est né de cette friction : une interface graphique qui pilote ces scripts, garde une trace de chaque run, et rend les résultats triables et filtrables au lieu de les laisser disparaître dans le scroll.
Un catalogue, des cibles, des playbooks
Le principe reste simple : on ajoute une ou plusieurs cibles (IP, domaine, URL, fichier, dossier...), on coche un ou plusieurs scripts dans le catalogue, on lance. Le catalogue regroupe une dizaine de familles — reconnaissance, analyse réseau, cryptographie, exploitation, forensic/IR, OSINT, post-exploitation, remédiation, sécurité web, évaluation de vulnérabilités — et chaque script déclare le type de cible qu'il attend, pour éviter de le lancer sur une valeur qui n'a pas de sens pour lui.
Une fois qu'une combinaison de scripts revient souvent pour un type d'audit donné, elle se sauvegarde comme playbook — un scénario nommé qu'on recharge en un clic plutôt que de recocher la même liste à chaque fois. Les résultats, eux, atterrissent dans un tableau filtrable par niveau de risque, avec le détail JSON brut d'un clic, et un clic droit pour marquer un résultat comme faux positif ou surcharger son niveau de risque — utile quand un scan répété commence à s'accumuler.
Local ou à distance, sans jamais perdre la main
Certains scripts ne travaillent que sur le système de fichiers local (analyse de logs, extraction de métadonnées...) et n'ont aucun moyen d'aller chercher un fichier sur une machine distante par eux-mêmes. D'autres, à l'inverse, n'ont de sens que lancés directement sur la cible (vérification d'escalade de privilèges, durcissement système...). PenBox couvre les deux cas : un rapatriement de fichiers par SFTP pour les premiers, une exécution à distance par SSH pour les seconds — le script est uploadé, exécuté sur place, et son résultat rapatrié dans le même tableau que les runs locaux.
J'ai délibérément choisi SFTP plutôt que SMB pour ce transfert : SMB ne tient pas la route dans les conditions réelles d'un pentest externe (trafic sortant filtré, souvent détecté par un EDR), alors que SSH est presque toujours déjà le canal d'accès dont on dispose sur un engagement. Côté sécurité justement, PenBox mémorise l'empreinte de chaque hôte SSH contacté et refuse toute connexion dont la clé a changé depuis la dernière fois — la protection réelle contre une interception, pas une case cochée pour la forme. Les identifiants de connexion récurrents, eux, vivent dans un coffre-fort chiffré protégé par un mot de passe maître qui n'est jamais stocké nulle part.
Éprouvé en conditions réelles
Une interface qui compile n'est pas une interface qui fonctionne. J'ai testé PenBox contre une machine Debian de mon lab perso puis contre un VPS exposant une application volontairement vulnérable, et plusieurs vrais bugs sont sortis de ces sessions : une regex de détection de credential stuffing qui remontait un faux positif sur toute ligne contenant simplement "root", un script d'exploitation qui lisait la mauvaise clé dans le JSON produit par un autre script, une f-string imbriquée qui plantait purement et simplement un scanner de répertoires web. Ce dernier cas a même révélé un piège classique : le correctif initial faisait disparaître silencieusement une ligne qui alimentait le fichier de résultats — le script tournait, affichait des résultats à l'écran, mais n'écrivait plus rien d'exploitable. Rien ne remplace un run réel contre une vraie cible pour trouver ce genre de régression invisible.
Premier release, code ouvert
PenBox en est à sa version 1.0.0, packagée en un installateur Windows autonome (runtime Python embarqué, aucune dépendance externe, aucun droit administrateur requis) — le choix d'un bundle plutôt qu'un exécutable figé à la PyInstaller, pour ne pas casser la façon dont l'app lance chaque script comme un sous-processus indépendant. Le code, les scripts du catalogue et la notice d'utilisation complète sont sur GitHub :
Dépôt GitHub — old-dov/cybersec-toolkit
Release v1.0.0 — notes de version et installateur
Une liste de fonctionnalités priorisées attend déjà son tour pour les prochaines versions. En attendant, comme pour tout le reste de ce blog : ces outils sont pensés pour des audits autorisés, sur ses propres systèmes ou dans un cadre légitime — pas pour autre chose.