Featured image of post Strix

Strix

Strix - AI pentesting tool

Savoir si on est vulnérable : mon test de Strix sur mon blog

Je passe beaucoup de temps à construire des systèmes, mais je vérifie rarement s’ils sont vraiment solides. Il y a une différence entre croire que son infrastructure est sécurisée et en avoir la preuve. Pour sortir de la théorie, j’ai décidé de lancer un exercice de Red Teaming sur mon propre blog en utilisant Strix, un agent de pentesting basé sur l’IA.

L’idée était simple : voir si un attaquant automatisé pouvait trouver une faille et s’infiltrer.

Strix : plus qu’un simple scanner

D’habitude, on utilise des scanners comme Nmap ou Burp Suite. Ils sont efficaces pour lister des ports ouverts ou détecter des versions de logiciels obsolètes, mais ils sont statiques. Ils cherchent des signatures connues.

Strix fonctionne différemlement. C’est un agent qui raisonne. S’il tombe sur un formulaire, il ne va pas juste tester des injections SQL classiques ; il va essayer de comprendre comment le serveur traite la donnée pour adapter son attaque. On passe d’un scan automatique à une simulation de comportement humain.

J’ai lié Strix à mon serveur local Ollama.

Le test sur blog.thomasplantain.fr

J’ai lancé l’outil directement sur l’URL de mon blog. L’installation est rapide et l’agent commence par une phase de reconnaissance : il cherche des sous-domaines, analyse les headers HTTP et identifie les technos utilisées, comme Hugo et Docker.

Strix scan

L’attaque n’est pas brutale. Strix ne balance pas des milliers de requêtes par seconde, ce qui évite d’être bloqué immédiatement par un pare-feu. Il tente des approches ciblées, comme chercher des dossiers /admin ou /config en utilisant des mots-clés liés au contexte du site.

Résultats : Un bilan vide, mais utile

Après plusieurs minutes, Strix n’a trouvé aucune vulnérabilité critique. Il a testé les vecteurs classiques : l’énumération de fichiers sensibles (/.git, /.env), les failles XSS sur les formulaires et la configuration des headers de sécurité. Rien.

Strix view

Ce résultat est logique quand on regarde la stack : mon blog est basé sur Hugo, un générateur de site statique. Contrairement à un site WordPress, il n’y a pas de base de données à injecter, pas de session utilisateur à voler, ni de moteur de rendu côté serveur à exploiter. Strix a cherché des portes ouvertes là où il n’y a que des murs de briques.

Strix issues

Cela ne veut pas dire que le site est invulnérable. Un humain pourrait trouver des failles de logique ou des problèmes au niveau du DNS que l’IA a ignorés. Mais ça confirme que la surface d’attaque est minimale.

Conclusion : la sécurité est un processus

L’exercice m’a rappelé qu’on ne peut pas se contenter d’une installation “propre” au départ. La sécurité n’est pas un état stable, c’est une habitude.

L’intérêt de Strix n’est pas forcément de trouver une faille à chaque fois, mais de permettre un diagnostic rapide et régulier. En faisant tourner ce genre d’agent périodiquement, on détecte une régression dès qu’on ajoute une nouvelle brique à l’infrastructure. C’est la seule façon de construire des systèmes robustes : arrêter de faire confiance et commencer à vérifier.