Comment ça marche

La sécurité offensive a toujours souffert d'un problème d'interface : pour utiliser les outils, il fallait être expert des outils. Nmap, Burp Suite, Metasploit - autant d'outils puissants dont la courbe d'apprentissage éloigne précisément ceux qui en auraient le plus besoin.

Hacksessible inverse ce modèle. Vous décrivez le risque que vous voulez évaluer en termes métier, et nos agents s'occupent de la traduction technique. « Est-ce qu'un concurrent peut accéder à nos données contractuelles via notre portail client ? » est une question aussi valide que « Tester SQLi sur le endpoint /api/v2/contracts avec bypass d'authentification ».

Notre système de parsing d'intention extrait les entités pertinentes (actifs, périmètre, type d'attaque souhaitée), les résout contre votre inventaire d'actifs enregistrés, et construit un plan d'investigation structuré que vous pouvez valider avant exécution.

Exemples de questions acceptées :

L'investigation est orchestrée par un agent-maître qui décompose la question en sous-tâches et les délègue à des agents spécialisés. Cette architecture multi-agents est au coeur de ce qui différencie Hacksessible d'un scanner classique.

L'agent de reconnaissance commence par cartographier la surface d'attaque : résolution DNS, détection de sous-domaines, fingerprinting des technologies, analyse des headers HTTP, collecte OSINT. Ces informations alimentent l'agent de scan, qui adapte ses tests en fonction du contexte : il ne scan pas un WordPress comme il scanne une API GraphQL.

L'agent d'exploitation reçoit les vulnérabilités candidates et tente de les confirmer avec des payloads adaptés au contexte découvert précédemment. Si l'agent de reconnaissance a identifié un WAF, l'agent d'exploitation adapte ses techniques de bypass automatiquement. Si plusieurs vulnérabilités sont détectées, l'agent d'analyse évalue les possibilités de chaînage pour identifier des chemins d'attaque composites.

Tout ce processus est journalisé en temps réel dans votre dashboard. Vous voyez les agents travailler, les découvertes s'accumuler, et les hypothèses se confirmer ou s'infirmer - sans avoir à intervenir.

Une vulnérabilité sans preuve n'est qu'une hypothèse. Et les hypothèses ne font pas ouvrir des tickets de remédiation prioritaires. C'est pourquoi la preuve technique est au coeur de notre philosophie produit.

Lorsqu'un agent confirme une vulnérabilité, il génère automatiquement un dossier de preuve complet. Pour une injection SQL : la requête exacte envoyée, la réponse du serveur avec les données extraites, le temps de réponse (pour les injections basées sur le temps), et le script Python ou curl reproduisant l'exploitation en une commande. Pour un SSRF : l'URL malformée, la réponse du serveur interne, et la preuve que la requête a atteint l'infrastructure interne.

Ce dossier de preuve est structuré pour être utilisable immédiatement par différentes parties prenantes. Pour les développeurs : le contexte technique précis pour comprendre et corriger. Pour les RSSI : un résumé exécutif avec impact métier. Pour les auditeurs : une trace horodatée et signée de la découverte et du processus d'exploitation.

Si la vulnérabilité n'est pas exploitable dans votre contexte spécifique - parce que votre WAF la bloque, parce que la version patchée est en production, ou parce que la configuration réseau empêche l'accès - vous recevez aussi cette information, avec l'explication des contrôles qui l'ont rendue inexploitable. C'est aussi précieux que la preuve d'exploitation.

# Exemple de preuve générée automatiquement
curl -X POST "https://api.example.com/v2/users" \
  -H "Content-Type: application/json" \
  -d '{"username": "admin'''--", "password": "x"}' \
  # Réponse: HTTP 200 - {"token": "eyJ...", "role": "admin"}
  # Preuve: bypass d'authentification confirmé

Identifier une vulnérabilité sans indiquer comment la corriger, c'est livrer un diagnostic sans ordonnance. Hacksessible complète chaque investigation par un plan de remédiation structuré, spécifique à votre contexte technologique.

Le plan est organisé en trois niveaux temporels. La remédiation immédiate s'adresse aux équipes DevOps qui doivent agir dans les 24-48 heures : commandes exactes, paramètres de configuration, versions à installer. Pour une dépendance vulnérable : la commande npm update exacte avec la version cible. Pour une misconfiguration nginx : le bloc de configuration corrigé à copier-coller. Pour une injection SQL : le paramètre Prepared Statement à utiliser dans le code existant.

La mesure compensatoire temporaire est proposée quand le correctif définitif nécessite un cycle de développement long : règle WAF spécifique au vecteur d'attaque identifié, restriction d'accès réseau, désactivation de la fonctionnalité vulnérable si non critique. Ces mesures réduisent immédiatement la fenêtre d'exposition pendant que la correction est développée.

La recommandation architecturale long terme adresse la cause racine plutôt que le symptôme : refactoring de la couche d'accès aux données, migration vers un pattern d'authentification plus robuste, séparation des périmètres réseau. Ces recommandations sont générées par notre modèle de raisonnement à partir du contexte architectural déduit de l'investigation.

Chaque recommandation est assignable à une équipe ou un individu directement depuis notre dashboard, avec une date d'échéance et un suivi de completion.