Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
reditrap — Minimal honeypot Redis per il rilevamento degli exploit RediShell (CVE-2025-49844). | Kitploit
Strumenti/GitHubGitHub/srozb/reditrap
Analisi delle VulnerabilitàSicurezza di ReteThreat IntelligenceRilevamento IntrusioniAnalisi dei Log
GitHubsrozb/reditrap

reditrap

Minimal honeypot Redis per il rilevamento degli exploit RediShell (CVE-2025-49844).

Vedi Repository
811 mesi faNon ancora revisionato

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Condividi

Honeypot RediTrap

RediTrap è un honeypot Redis minimale progettato per individuare i primi tentativi di sfruttamento di CVE-2025-49844 ("RediShell"), la critica vulnerabilità di Remote Code Execution descritta da Wiz Research. L'exploit abusa di un bug use-after-free di 13 anni fa nel motore Lua integrato: Redis memorizzava il nome del chunk Lua senza prima ancorarlo sullo stack, consentendo a un ciclo di garbage collection di recuperare la stringa mentre il codice C utilizzava ancora il puntatore. La patch di Redis d5728cb corregge il problema spingendo il nome del chunk sullo stack Lua (tramite setsvalue2s/incr_top) prima dell'analisi e facendolo poi uscire, prevenendo il puntatore obsoleto e chiudendo la primitiva RCE.

Poiché il percorso di exploit pubblicato si basa sull'invio di script Lua dannosi tramite EVAL, EVALSHA o SCRIPT LOAD, l'honeypot si concentra sull'evidenziazione di queste interazioni fingendo di essere un nodo Redis non patchato.

Cosa fa

  • Ascolta sulla porta TCP di Redis ( di default) e parla un piccolo sottoinsieme RESP così che i probe di base riescano (, , , ecc.).
6379
PING
INFO
AUTH
  • Registra ogni comando in un file di log in formato JSON-lines, con contesto aggiuntivo per l'attività degli script Lua (digest SHA-1, lunghezza, euristiche sui token, anteprima).
  • Contrassegna i comandi orientati agli script come sospetti e restituisce risposte di errore sicure così che i payload non attendibili non vengano mai eseguiti.
  • Imita il comportamento di Redis più vecchio (ad esempio, rifiutando HELLO) per incoraggiare gli attaccanti a continuare il loro flusso di lavoro.
  • Per iniziare

    root@kitploit:~
    python3 reditrap.py --host 0.0.0.0 --port 6379 --log-file logs/redis-honeypot-events.ndjson
    

    Usa --verbose per un logging stdout aggiuntivo durante lo sviluppo.

    Utilizzo con container

    Crea un'immagine compatta (base Alpine):

    root@kitploit:~
    docker build -t reditrap .
    # oppure: podman build -t reditrap .
    

    Eseguila con la porta Redis esposta e la directory dei log montata sull'host:

    root@kitploit:~
    mkdir -p honeypot-logs
    docker run -d --name reditrap \
      -p 6379:6379 \
      -v "$(pwd)/honeypot-logs:/data" \
      reditrap
    

    Il container usa di default --host 0.0.0.0 --port 6379 --log-file /data/redis-honeypot-events.ndjson, quindi i log finiscono sull'host in honeypot-logs/redis-honeypot-events.ndjson.

    Podman funziona allo stesso modo (aggiungi il flag SELinux se applicabile):

    root@kitploit:~
    podman run -d --name reditrap \
      -p 6379:6379 \
      -v "$(pwd)/honeypot-logs:/data:Z" \
      reditrap
    

    Sovrascrivi i valori predefiniti aggiungendo argomenti dopo il nome dell'immagine, ad esempio:

    root@kitploit:~
    docker run --rm -p 6379:6379 reditrap --redis-version 7.0.15 --log-file /data/attempts.ndjson
    

    Ispezione degli eventi

    Ogni richiesta in arrivo diventa una voce NDJSON. L'attività Lua sospetta include euristiche per rendere più facile il triage. Ad esempio:

    root@kitploit:~
    {
      "action": "lua_eval",
      "args": ["return debug.getregistry()", "0"],
      "command": "EVAL",
      "info": {
        "arg_count": 2,
        "heuristics": {
          "length": 26,
          "matched_tokens": ["debug."],
          "preview": "return debug.getregistry()"
        },
        "key_count": "0",
        "script_hash": "763200efa15885c9fa970d45cc2b11711c739c13"
      },
      "remote": {"host": "203.0.113.42", "port": 58231},
      "timestamp": "2025-10-07T15:04:12.123456+00:00"
    }
    

    Abbina i log alla telemetria di rete per tracciare la sorgente attaccante e decidere le azioni di risposta.

    Note di sicurezza

    • L'honeypot non esegue mai gli script Lua ricevuti; restituisce immediatamente una stringa di errore dopo aver registrato il tentativo.
    • Le grandi stringhe bulk sono limitate a 8 MiB e gli array a 128 elementi per ridurre la pressione sulla memoria da parte di client dannosi.
    • Esegui l'honeypot all'interno di un segmento di rete isolato e inoltra il traffico sulla porta Redis ad esso utilizzando regole firewall, port mirroring o NAT come appropriato per il tuo ambiente.
    Scarica lo strumento