helgesverre/livewire-honeypotHoneypot à haute interaction imitant une application Laravel/Livewire vulnérable. Capture les exploits RCE et les webshells ciblant CVE-2024-47823, CVE-2025-54068 et CVE-2025-14894, puis les analyse dans des conteneurs Docker sandboxés pour extraire les IOC.
Un honeypot à haute interaction qui se fait passer pour une application Laravel/Livewire vulnérable. Il capture les tentatives d'exploitation ciblant des CVE Livewire connues, stocke les fichiers malveillants téléversés (webshells) et les payloads d'exécution de code à distance (RCE) avec déduplication SHA-256, et les exécute éventuellement dans un conteneur Docker sandboxé afin d'en extraire les indicateurs de compromission (IOCs) — URL, adresses IP et domaines que le malware tente de contacter.
Le système s'exécute sous forme de deux processus distincts pour des raisons de sécurité : un serveur web qui capture les payloads (sans accès Docker) et un worker sandbox qui les analyse dans des conteneurs isolés.
Attacker → Nginx → FastAPI → SQLite ← Sandbox Worker (Docker)
(capture) (polls jobs, writes IOCs)
Façade — Sert des pages de connexion/inscription Laravel réalistes avec des attributs Livewire wire:, des jetons XSRF et des en-têtes X-Powered-By: PHP/8.3.12. Les scanners automatisés voient ce qui ressemble à une véritable application vulnérable.
Capture — Chaque requête HTTP est journalisée dans SQLite (IP, en-têtes, hash du corps, horodatage) par une couche middleware ASGI, de manière transparente, avant tout routage.
Pièges — Les endpoints Livewire acceptent les téléversements de fichiers et les messages de composants comme le ferait le vrai framework. Les payloads sont classifiés (code PHP, objets sérialisés, commandes shell) et stockés avec déduplication SHA-256. Chaque payload intéressant crée une tâche persistante dans la file sandbox_jobs.
Sandbox — Un processus worker séparé interroge les tâches en attente et exécute chaque payload dans un conteneur Docker éphémère (système de fichiers en lecture seule, sans réseau, cap_drop=ALL). Un shim LD_PRELOAD intercepte les appels réseau de la libc pour journaliser les tentatives de communication C2 (commandement et contrôle). L'analyseur extrait les IOCs et évalue les endpoints C2 potentiels à l'aide d'heuristiques.
| CVE | CVSS | Résumé | Endpoint du piège |
|---|---|---|---|
| CVE-2024-47823 | 9.8 Critique | RCE par téléversement de fichier Livewire via contournement du type MIME. Les extensions de fichier sont déduites du type MIME au lieu d'être validées à partir du nom de fichier, ce qui permet des téléversements .php déguisés en images. Affecte Livewire < 2.12.7 et < 3.5.2. | POST /livewire/upload-file |
| CVE-2025-54068 | 9.2 Critique | RCE par hydratation des propriétés Livewire. Le processus d'hydratation ne parvient pas à assainir les types d'objets lors des mises à jour de propriétés de composants, permettant à des payloads injectés de s'exécuter côté serveur. Affecte Livewire de 3.0.0-beta.1 à 3.6.3. | POST /livewire/message |
| CVE-2025-14894 | Critique | RCE par téléversement sans restriction dans Livewire Filemanager. L'absence de validation du type de fichier et du MIME permet le téléversement non authentifié de fichiers PHP exécutables. | POST /livewire/upload-file |
Un piège fourre-tout *.php capture également les sondages post-exploitation à la recherche de noms de webshell courants (par ex. accesson.php, wp-login.php, admin.php).
Prérequis : Python 3.11+ et uv.
git clone https://github.com/HelgeSverre/livewire-honeypot.git
cd livewire-honeypot
# Installer les dépendances
uv sync
# Démarrer le serveur web (capture uniquement, pas besoin de Docker)
DATA_DIR=./data uv run uvicorn honeypot.main:app --reload --port 8000
# Dans un second terminal — démarrer le worker sandbox (nécessite Docker)
DATA_DIR=./data uv run python -m honeypot.worker
# Exécuter les tests
uv run pytest tests/ -v
Le serveur web fonctionne de manière autonome — il capture et stocke tout, même sans le worker sandbox en cours d'exécution. Démarrez le worker lorsque vous souhaitez une analyse automatisée des payloads.
Remarque : Le répertoire
src/est dans le chemin Python viapyproject.toml(src-layout), donchoneypot.main:appcorrespond àsrc/honeypot/main.py.
Vous aurez besoin de :
Le déploiement complet se résume à une seule commande une fois le VPS créé. Le script gère chaque étape, du « droplet nu » au « service opérationnel avec TLS » — paquets apt, utilisateurs et groupes, venv Python, image sandbox, nginx, certbot et règles de pare-feu.
# 1. Créer un droplet à 6 $/mois (Ubuntu 24.04, 1 Go de RAM suffit).
# Sur DigitalOcean :
doctl compute droplet create veritron-honeypot \
--size s-1vcpu-1gb \
--image ubuntu-24-04-x64 \
--region fra1 \
--ssh-keys "$(doctl compute ssh-key list --format ID --no-header | head -1)" \
--wait
# 2. Pointez l'enregistrement A de votre domaine vers l'IP du droplet.
# Attendez que le DNS se résolve avant de continuer.
dig +short your-domain.example # doit renvoyer l'IP du droplet
# 3. Copiez le projet sur le droplet.
rsync -az --exclude='.git' --exclude='.venv' --exclude='data' \
./ root@<droplet-ip>:/opt/honeypot/
# 4. Exécutez le script d'amorçage. Fournir votre domaine active la TLS via certbot.
ssh root@<droplet-ip> 'cd /opt/honeypot && [email protected] \
bash deploy/setup.sh your-domain.example'
Et voilà. Le honeypot sert désormais une fausse page de connexion Laravel/Livewire en HTTPS, capture chaque requête dans SQLite et est prêt à analyser les payloads dans le sandbox Docker.
deploy/setup.sh est idempotent — le relancer est sans risque. Dans l'ordre, il :
honeypot (web) et sandbox (worker), ainsi que le groupe partagé honeypot-data.uv sync --python /usr/bin/python3.12. Nous utilisons délibérément le Python installé via apt plutôt que l'interpréteur fourni avec uv — le Python d'uv se trouve dans /root/.local/share/uv/, qu'un utilisateur de service non privilégié ne peut pas traverser, et vous obtenez un status=203/EXEC déroutant de systemd si vous laissez uv choisir l'interpréteur./var/honeypot/ avec le bit setgid et une propriété de groupe partagée, afin que les deux services puissent lire les écritures de l'autre.ExecStart du worker pour utiliser le démon Docker système (l'unité fournie suppose un Docker rootless, plus difficile à configurer).docker build -t honeypot-sandbox sandbox/).limit_req_zone dans /etc/nginx/conf.d/ (elle doit se trouver dans le bloc http {}, pas dans server {}).certbot --nginx si un domaine a été fourni.Si vous préférez piloter chaque étape vous-même plutôt que d'exécuter setup.sh, l'historique shell équivalent se trouve dans deploy/setup.sh sous forme d'étapes commentées.
| Service | Utilisateur | Rôle | Accès Docker |
|---|---|---|---|
honeypot.service | honeypot | Serveur web — capture les requêtes et les payloads | Non |
honeypot-worker.service | sandbox | Worker sandbox — analyse les payloads dans Docker | Oui |
Les deux services partagent /var/honeypot/ pour la base de données SQLite et le stockage des payloads. Le processus web n'a aucun accès au socket Docker, donc même s'il est compromis via le trafic des attaquants, il ne peut pas créer de conteneurs sur l'hôte.
# Voir les journaux
journalctl -u honeypot -f
journalctl -u honeypot-worker -f
# Redémarrer les services
systemctl restart honeypot honeypot-worker
# Mise à jour
cd /opt/honeypot && git pull && uv sync
docker build -t honeypot-sandbox sandbox/
systemctl restart honeypot honeypot-worker
Tous les paramètres sont contrôlés via des variables d'environnement (définies dans les fichiers d'unité systemd ou exportées avant l'exécution) :
| Variable | Défaut | Description |
|---|---|---|
DATA_DIR | /var/honeypot | Répertoire de base pour toutes les données |
DB_PATH | $DATA_DIR/captures.db | Chemin de la base de données SQLite |
SANDBOX_TIMEOUT | 60 | Secondes maximales par exécution sandbox |
SANDBOX_MEMORY | 128m | Limite de mémoire du conteneur |
SANDBOX_CPUS | 0.5 | Limite CPU du conteneur |
SANDBOX_MAX_CONCURRENT | 3 | Nombre maximal de conteneurs sandbox simultanés |
SANDBOX_IMAGE | honeypot-sandbox | Image Docker pour le sandbox |
WORKER_POLL_INTERVAL | 2.0 | Secondes entre les interrogations de tâches |
Toutes les données sont stockées dans une seule base de données SQLite (par défaut : /var/honeypot/captures.db).
# Requêtes récentes
sqlite3 /var/honeypot/captures.db \
"SELECT timestamp, source_ip, method, path, matched_trap
FROM requests ORDER BY id DESC LIMIT 20;"
# Payloads uniques par fréquence
sqlite3 /var/honeypot/captures.db \
"SELECT sha256, filename, payload_type, times_seen, sandbox_status
FROM payloads ORDER BY times_seen DESC;"
# Principales IP d'attaquants
sqlite3 /var/honeypot/captures.db \
"SELECT ip, total_requests, first_seen, last_seen
FROM attackers ORDER BY total_requests DESC LIMIT 10;"
# Résultats sandbox avec IOCs extraits (JSON)
sqlite3 /var/honeypot/captures.db \
"SELECT payload_id, exit_code, duration_seconds, c2_urls_found, iocs
FROM sandbox_runs ORDER BY id DESC LIMIT 5;"
# Tâches sandbox en attente
sqlite3 /var/honeypot/captures.db \
"SELECT id, payload_sha256, status, created_at
FROM sandbox_jobs ORDER BY id DESC LIMIT 10;"
Les données IOC dans sandbox_runs.iocs sont stockées en JSON avec les clés : domains, ips, emails, urls, hashes. Extrayez-les et alimentez votre plateforme de threat intel (MISP, OpenCTI, etc.) selon vos besoins.
src/honeypot/
main.py # Application web FastAPI (capture uniquement, sans Docker)
worker.py # Worker sandbox autonome (interroge SQLite, nécessite Docker)
config.py # Paramètres issus des variables d'environnement
capture/
database.py # SQLite asynchrone — requêtes, payloads, file sandbox_jobs
logger.py # Middleware ASGI — journalise chaque requête
payloads.py # Stockage avec déduplication SHA-256 + classification des payloads
facade/
routes.py # Pages à empreinte Laravel (connexion, inscription, etc.)
templates/ # HTML Jinja2 avec attributs Livewire wire:
static/ # Faux livewire.js (empreinte v3.5.1)
traps/
livewire.py # POST /livewire/message, /upload-file, /preview-file
php_catchall.py # Fourre-tout pour le sondage *.php
sandbox/
orchestrator.py # Cycle de vie des conteneurs Docker + durcissement
analyzer.py # Analyse des artefacts + extraction d'IOC + évaluation C2
deploy/
nginx.conf # Reverse-proxy avec limitation de débit
honeypot.service # Unité systemd (web)
honeypot-worker.service # Unité systemd (worker sandbox)
setup.sh # Script d'amorçage VPS
sandbox/
Dockerfile # Image du conteneur sandbox (PHP 8.3 + outils d'attaque)
entrypoint.sh # Point d'entrée du conteneur avec shim réseau LD_PRELOAD
Cet outil de recherche sert à collecter des échantillons de malwares et à observer le comportement des attaquants sur une infrastructure qui vous appartient. Ce n'est pas un produit de sécurité de production. Ne déployez que sur des systèmes que vous contrôlez, et sachez que la capture et l'exécution de payloads d'attaquants peuvent avoir des implications légales dans votre juridiction. La base de données SQLite et les fichiers de payloads croissent sans limite — surveillez l'utilisation du disque et mettez en place des politiques de rétention si nécessaire.
Les issues et les pull requests sont les bienvenues.