helgesverre/livewire-honeypotHoneypot ad alta interazione che replica un'app Laravel/Livewire vulnerabile. Cattura exploit RCE e webshell che hanno come bersaglio CVE-2024-47823, CVE-2025-54068 e CVE-2025-14894, quindi li analizza in container Docker in sandbox per estrarre gli IOC.
Un honeypot ad alta interazione che si maschera da applicazione Laravel/Livewire vulnerabile. Cattura i tentativi di exploit che mirano a CVE note di Livewire, archivia file malevoli caricati (webshell) e payload di remote code execution (RCE) con deduplicazione SHA-256 e, opzionalmente, li esegue in un container Docker sandboxed per estrarre indicatori di compromissione (IOC) — URL, IP e domini che il malware tenta di contattare.
Il sistema funziona come due processi separati per sicurezza: un web server che cattura i payload (senza accesso a Docker) e un worker sandbox che li analizza in container isolati.
Attaccante → Nginx → FastAPI → SQLite ← Sandbox Worker (Docker)
(cattura) (polling dei job, scrive gli IOC)
Facade — Serve pagine di login/registrazione Laravel realistiche con attributi Livewire wire:, token XSRF e header X-Powered-By: PHP/8.3.12. Gli scanner automatici vedono quello che sembra una vera app vulnerabile.
Cattura — Ogni richiesta HTTP viene registrata su SQLite (IP, header, hash del body, timestamp) da un layer middleware ASGI, in modo trasparente, prima che avvenga qualsiasi routing.
Trappole — Gli endpoint Livewire accettano upload di file e messaggi dei componenti proprio come farebbe il framework reale. I payload vengono classificati (codice PHP, oggetti serializzati, comandi shell) e archiviati con deduplicazione SHA-256. Ogni payload interessante crea un job persistente nella coda sandbox_jobs.
Sandbox — Un processo worker separato esegue il polling dei job in attesa ed esegue ogni payload in un container Docker effimero (filesystem di sola lettura, nessuna rete, cap_drop=ALL). Uno shim LD_PRELOAD intercetta le chiamate di rete libc per registrare i tentativi di comunicazione C2 (command-and-control). L'analizzatore estrae gli IOC e valuta i potenziali endpoint C2 usando euristiche.
| CVE | CVSS | Riepilogo | Endpoint trappola |
|---|---|---|---|
| CVE-2024-47823 | 9.8 Critica | RCE tramite upload di file Livewire mediante bypass del tipo MIME. Le estensioni dei file vengono dedotte dal tipo MIME invece di essere validate dal nome file, consentendo upload .php mascherati da immagini. Colpisce Livewire < 2.12.7 e < 3.5.2. | POST /livewire/upload-file |
| CVE-2025-54068 | 9.2 Critica | RCE tramite idratazione delle proprietà di Livewire. Il processo di idratazione non riesce a sanificare i tipi di oggetto negli aggiornamenti delle proprietà dei componenti, consentendo a payload iniettati di essere eseguiti lato server. Colpisce Livewire 3.0.0-beta.1 fino a 3.6.3. | POST /livewire/message |
| CVE-2025-14894 | Critica | RCE tramite upload senza restrizioni in Livewire Filemanager. La mancanza di validazione del tipo di file e del MIME consente l'upload non autenticato di file PHP eseguibili. | POST /livewire/upload-file |
Una trappola catch-all *.php cattura anche il probing post-exploitation per i nomi di webshell comuni (ad es. accesson.php, wp-login.php, admin.php).
Prerequisiti: Python 3.11+ e uv.
git clone https://github.com/HelgeSverre/livewire-honeypot.git
cd livewire-honeypot
# Installa le dipendenze
uv sync
# Avvia il web server (solo cattura, Docker non necessario)
DATA_DIR=./data uv run uvicorn honeypot.main:app --reload --port 8000
# In un secondo terminale — avvia il worker sandbox (richiede Docker)
DATA_DIR=./data uv run python -m honeypot.worker
# Esegui i test
uv run pytest tests/ -v
Il web server funziona in modo autonomo — cattura e archivia tutto anche senza il worker sandbox attivo. Avvia il worker quando vuoi l'analisi automatica dei payload.
Nota: La directory
src/è nel Python path tramitepyproject.toml(src-layout), quindihoneypot.main:apppunta asrc/honeypot/main.py.
Ti serviranno:
Il deploy completo è un singolo comando una volta che il VPS esiste. Lo script gestisce ogni passaggio da "droplet nudo" a "servizio in esecuzione con TLS" — pacchetti apt, utenti e gruppi, venv Python, immagine sandbox, nginx, certbot e regole firewall.
# 1. Crea un droplet da $6/mese (Ubuntu 24.04, 1 GB di RAM è sufficiente).
# Su 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. Punta il record A del tuo dominio all'IP del droplet.
# Aspetta che il DNS risolva prima di continuare.
dig +short your-domain.example # dovrebbe restituire l'IP del droplet
# 3. Copia il progetto sul droplet.
rsync -az --exclude='.git' --exclude='.venv' --exclude='data' \
./ root@<droplet-ip>:/opt/honeypot/
# 4. Esegui lo script di bootstrap. Passare il tuo dominio abilita la TLS tramite certbot.
ssh root@<droplet-ip> 'cd /opt/honeypot && [email protected] \
bash deploy/setup.sh your-domain.example'
Questo è tutto. L'honeypot ora serve una falsa pagina di login Laravel/Livewire su HTTPS, cattura ogni richiesta su SQLite ed è pronto ad analizzare i payload nella sandbox Docker.
deploy/setup.sh è idempotente — rieseguirlo è sicuro. In ordine:
honeypot (web) e sandbox (worker), più il gruppo condiviso honeypot-data.uv sync --python /usr/bin/python3.12. Usiamo deliberatamente il Python installato via apt piuttosto che l'interprete fornito da uv — il Python di uv vive in /root/.local/share/uv/, che un utente di servizio non privilegiato non può attraversare, e ottieni un confuso status=203/EXEC da systemd se lasci che sia uv a scegliere l'interprete./var/honeypot/ con il bit setgid e la proprietà di gruppo condivisa, così entrambi i servizi possono leggere le scritture dell'altro.ExecStart del worker per usare il demone Docker di sistema (l'unità inclusa presuppone Docker rootless, che è più complicato da configurare).docker build -t honeypot-sandbox sandbox/).limit_req_zone in /etc/nginx/conf.d/ (deve stare nel blocco http {}, non in server {}).certbot --nginx se è stato passato un dominio.Se vuoi eseguire ogni passaggio da solo invece di usare setup.sh, la storia shell equivalente vive in deploy/setup.sh come fasi commentate.
| Servizio | Utente | Scopo | Accesso a Docker |
|---|---|---|---|
honeypot.service | honeypot | Web server — cattura richieste e payload | No |
honeypot-worker.service | sandbox | Worker sandbox — analizza i payload in Docker | Sì |
Entrambi i servizi condividono /var/honeypot/ per il database SQLite e l'archiviazione dei payload. Il processo web non ha accesso al socket Docker, quindi anche se compromesso tramite il traffico degli attaccanti, non può creare container sull'host.
# Visualizza i log
journalctl -u honeypot -f
journalctl -u honeypot-worker -f
# Riavvia i servizi
systemctl restart honeypot honeypot-worker
# Aggiornamento
cd /opt/honeypot && git pull && uv sync
docker build -t honeypot-sandbox sandbox/
systemctl restart honeypot honeypot-worker
Tutte le impostazioni sono controllate tramite variabili d'ambiente (impostate nei file delle unità systemd o esportate prima dell'esecuzione):
| Variabile | Default | Descrizione |
|---|---|---|
DATA_DIR | /var/honeypot | Directory di base per tutti i dati |
DB_PATH | $DATA_DIR/captures.db | Percorso del database SQLite |
SANDBOX_TIMEOUT | 60 | Secondi massimi per esecuzione sandbox |
SANDBOX_MEMORY | 128m | Limite di memoria del container |
SANDBOX_CPUS | 0.5 | Limite CPU del container |
SANDBOX_MAX_CONCURRENT | 3 | Numero massimo di container sandbox concorrenti |
SANDBOX_IMAGE | honeypot-sandbox | Immagine Docker per la sandbox |
WORKER_POLL_INTERVAL | 2.0 | Secondi tra i polling dei job |
Tutti i dati vivono in un singolo database SQLite (default: /var/honeypot/captures.db).
# Richieste recenti
sqlite3 /var/honeypot/captures.db \
"SELECT timestamp, source_ip, method, path, matched_trap
FROM requests ORDER BY id DESC LIMIT 20;"
# Payload unici per frequenza
sqlite3 /var/honeypot/captures.db \
"SELECT sha256, filename, payload_type, times_seen, sandbox_status
FROM payloads ORDER BY times_seen DESC;"
# Principali IP attaccanti
sqlite3 /var/honeypot/captures.db \
"SELECT ip, total_requests, first_seen, last_seen
FROM attackers ORDER BY total_requests DESC LIMIT 10;"
# Risultati sandbox con IOC estratti (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;"
# Job sandbox in attesa
sqlite3 /var/honeypot/captures.db \
"SELECT id, payload_sha256, status, created_at
FROM sandbox_jobs ORDER BY id DESC LIMIT 10;"
I dati IOC in sandbox_runs.iocs sono archiviati come JSON con chiavi: domains, ips, emails, urls, hashes. Estraili e inviali alla tua piattaforma di threat intelligence (MISP, OpenCTI, ecc.) secondo necessità.
src/honeypot/
main.py # App web FastAPI (solo cattura, niente Docker)
worker.py # Worker sandbox autonomo (polling SQLite, richiede Docker)
config.py # Impostazioni da variabili d'ambiente
capture/
database.py # SQLite asincrono — requests, payloads, coda sandbox_jobs
logger.py # Middleware ASGI — registra ogni richiesta
payloads.py # Archiviazione con dedup SHA-256 + classificazione dei payload
facade/
routes.py # Pagine con fingerprint Laravel (login, register, ecc.)
templates/ # HTML Jinja2 con attributi Livewire wire:
static/ # Falso livewire.js (fingerprint v3.5.1)
traps/
livewire.py # POST /livewire/message, /upload-file, /preview-file
php_catchall.py # Catch-all per probing *.php
sandbox/
orchestrator.py # Ciclo di vita del container Docker + hardening
analyzer.py # Parsing degli artefatti + estrazione IOC + valutazione C2
deploy/
nginx.conf # Reverse-proxy con rate limiting
honeypot.service # Unità systemd (web)
honeypot-worker.service # Unità systemd (worker sandbox)
setup.sh # Script di bootstrap VPS
sandbox/
Dockerfile # Immagine del container sandbox (PHP 8.3 + strumenti attaccante)
entrypoint.sh # Entry-point del container con shim di rete LD_PRELOAD
Questo è uno strumento di ricerca per raccogliere campioni di malware e osservare il comportamento degli attaccanti su infrastruttura di tua proprietà. Non è un prodotto di sicurezza in produzione. Distribuiscilo solo su sistemi che controlli e tieni presente che catturare ed eseguire payload degli attaccanti potrebbe avere implicazioni legali nella tua giurisdizione. Il database SQLite e i file dei payload crescono senza limiti — monitora l'uso del disco e implementa policy di conservazione secondo necessità.
Segnalazioni di problemi e pull request sono benvenuti.