MisconfigHunter

Point de départ : l'investigation Lexfo « opendir to phishing operator ». Une simple erreur de configuration — un python3 -m http.server avec directory listing actif — expose toute l'infrastructure d'un opérateur de phishing. MisconfigHunter industrialise cette logique côté défense.

Ce que fait l'outil

• Surveiller — recherche quotidienne, multi-sources OSINT, des erreurs de configuration exposées sur le périmètre d'une entreprise.
• Détecter le phishing ciblé — typosquats et domaines visant l'entreprise, via crt.sh, OpenPhish et matching par mots-clés.
• Catégoriser — un listing ouvert devient phishing, infostealer/C2, outillage offensif ou dump de credentials, avec un drapeau de suspicion criminelle.
• Archiver — copie ZIP chiffrée AES-256-GCM d'un listing, avec chaîne d'intégrité.
• Piloter — console d'opérateur : règles de détection éditables et journal d'audit.

Catégoriser sans ouvrir les fichiers

La classification travaille sur les noms de fichiers d'un listing, jamais sur leur contenu — le contenu, c'est le harvesting, et c'est une autre affaire juridique. Dix catégories : phishing, infostealer/C2, outillage offensif, dump de credentials, malware, racine système exposée, exfiltration Telegram, agent IA ou configuration LLM, home directory Linux, bénin.

Un score de sensibilité de 0 à 100 est calculé sur les fichiers à haute valeur (.env, .sql, combolist, wallet). Une racine système complète vaut 100. Un seul signal fort — combolist, evilginx, ligolo, une CVE, un .apk — suffit à lever le drapeau criminel et à passer la criticité en CRITICAL.

Le travail sur les faux positifs compte autant que la détection : seuil minimal par catégorie, marques bornées pour éviter qu'appletv ne déclenche un phishing Apple, outils légitimes comme frp, ollama ou transmission non classés offensifs à eux seuls. Les listings vides, réduits à une image, ou bénins et pauvres en signal sont filtrés automatiquement de la file à traiter.

Le LLM complète les signatures, il ne les remplace pas

Sur les cas ambigus uniquement, un modèle peut trancher. Il reçoit la liste des noms de fichiers, jamais leur contenu, et ne reclasse que s'il est confiant à 60 % ou plus. Sans lui, l'analyse reste à 100 % signatures — c'est ce qui la rend testable seule et déployable en contexte pédagogique. Deux fournisseurs au choix : Ollama en local, où rien ne sort de l'infrastructure, ou une API compatible OpenAI, où les noms de fichiers partent chez un tiers. Le choix est explicite dans la configuration, pas implicite.

Architecture

Django pour le backoffice, l'ORM et l'admin. Huey pour le cron et les tâches asynchrones, pas Celery. PostgreSQL en production, SQLite en développement. Les connecteurs OSINT sont enfichables : une classe, une entrée dans le registre.

Neuf applications : core (garde SSRF, journal d'audit append-only, validateurs), targets, sources, scanning, analysis, harvesting, fuzzing, notifications, reporting et web. Le même codebase produit deux profils de build : un build complet et un build passif pour l'usage pédagogique.

Cadre légal — la partie qui décide de ce qui est activé

Deux fonctions sont des interactions actives avec des systèmes tiers et engagent une responsabilité.

• Harvesting — télécharge des données de victimes tierces. On devient responsable de traitement au sens du RGPD : base légale et périmètre à documenter.
• Fuzzing — accès à un système de traitement automatisé de données au sens de l'article 323-1 du code pénal. Aucune immunité, même contre une infrastructure de phishing.

Les deux sont derrière des feature flags désactivés par défaut, et chaque action est tracée dans un journal d'audit immuable. Le champ Target.authorized_scope consigne le périmètre autorisé par le client, et chaque action active y est reliée dans l'audit. Le build pédagogique se limite à la détection passive.