redcell

Agenti AI che eseguono un penetration test end to end e scrivono il report.

[!WARNING] REDCELL è fornito esclusivamente per scopi di educazione, ricerca e test di sicurezza legali e autorizzati. Usalo solo per testare sistemi che possiedi o per cui hai esplicita autorizzazione scritta, e solo entro uno scope concordato. L'accesso non autorizzato o l'interferenza con sistemi informatici è un reato in Azerbaigian (articoli da 271 a 273 del Codice Penale) e secondo le leggi della maggior parte degli altri paesi. Come lo usi, e il rispetto della legge, è interamente tua responsabilità.

---

Cos'è

REDCELL mette in azione una squadra di agenti LLM durante un pentest. Un orchestratore pianifica l'ingaggio e assegna obiettivi agli agenti esecutori, che eseguono strumenti reali all'interno di un container Kali e riportano i risultati. Puoi osservare e guidare l'esecuzione da una console operatore: una chat che pilota l'orchestratore, un grafo degli agenti e un feed di attività in tempo reale, una vista live del browser che l'agente controlla, un terminale su qualsiasi reverse shell catturata dall'agente e un report da consegnare al termine del lavoro.

I modelli sono intercambiabili tramite LiteLLM, quindi puoi puntarlo a OpenAI, Anthropic, Google, GLM, DeepSeek, Kimi, un Ollama locale o qualsiasi altro provider supportato. Ogni esecuzione salva checkpoint man mano, quindi un crash o un riavvio riprende da dove era rimasto.

Funzionalità

• Motore multi-agente. Un ciclo plan/act basato su LangGraph. L'orchestratore delega gli obiettivi agli agenti esecutori che eseguono strumenti shell e registrano finding, loot e host mentre lavorano.
• Strumenti strutturati. Strumenti dedicati per nmap, nuclei, discovery di directory e vhost, e ricerca ed esecuzione di Metasploit. Ognuno analizza il proprio output nella attack surface o nei finding, così una scansione registra host e vulnerabilità senza passaggi aggiuntivi. run_command copre tutto ciò che non ha uno strumento dedicato.
• Esecuzione reale, locale o remota. Gli strumenti girano in un container Kali tramite docker exec. Scegli localhost o un server salvato per sessione; un server remoto esegue lo stesso container via SSH con host networking.
• Browser dell'agente. Per flussi di login e applicazioni ricche di JavaScript che gli strumenti shell non riescono a raggiungere, un agente controlla un vero Chromium nel container Kali. Puoi guardarlo in diretta e prendere il controllo per cliccare tu stesso, poi restituirlo all'agente.
• Reverse shell. Un agente apre un listener, cattura la shell e ti fornisce un terminale interattivo su di essa. Puoi anche aprire i tuoi terminali ed eseguire comandi da solo.
• Pivoting di rete. Instrada il traffico degli strumenti attraverso una reverse shell catturata per raggiungere host visibili solo dalla macchina compromessa. Un tunnel SOCKS inverso basato su chisel lo trasporta, e nmap passa automaticamente attraverso il tunnel.
• La chat guida l'esecuzione. Dì alla chat cosa vuoi e questa guiderà l'orchestratore in tempo reale, oppure riapri un'esecuzione conclusa per affrontare nuovo lavoro. Risponde anche a domande sull'ingaggio.
• Sessioni di scansione del codice. Punta una sessione a un repository git pubblico o a una cartella locale per una revisione di sicurezza del codice sorgente, con i finding mappati a file e riga.
• Configurazione per sessione. Imposta il server di esecuzione, il modello e un proxy di uscita opzionale per sessione. Server e proxy includono un vero test di connessione così sai che funzionano prima di affidarti a loro.
• Triage dei finding. Verifica o scarta i finding e unisci i duplicati che l'agente ha registrato due volte. Il report esclude quelli scartati e contrassegna quelli verificati.
• Report. Esporta un PDF più JSON e SARIF. Il write-up è generato dal modello della sessione e ripulito per leggersi come se l'avesse scritto una persona, con executive summary, metodologia, finding e remediation in ordine di priorità.
• Console live. Il feed di attività, i terminali e il browser dell'agente vengono trasmessi via WebSocket; il grafo degli agenti, i finding, il loot, la attack surface, i listener e la cronologia del proxy si aggiornano con un polling breve. Tutto si aggiorna in tempo reale mentre l'esecuzione procede.
• Notifiche. Toast in-app, più notifiche del browser quando la scheda è in background, così una domanda dell'agente o una shell catturata non restano inosservate.

Architettura

flowchart LR
  UI["Operator console<br/>React + Vite"] -->|REST + WebSocket| API["FastAPI"]
  API --> PG[(PostgreSQL)]
  API --> RS[(Redis<br/>pub/sub + queue)]
  API --> S3[(MinIO<br/>files & reports)]
  RS --> W["Worker (arq)"]
  W --> ENG["Engine<br/>LangGraph + LiteLLM"]
  ENG -->|docker exec| KALI["Kali container<br/>local or remote over SSH"]
  KALI --> TGT["Targets"]
  W -->|events / chat / shell| RS
  RS -->|stream| API

L'API non esegue gli agenti. Mette in coda un'esecuzione, il worker la esegue e il worker pubblica l'output sui canali Redis che l'API inoltra al browser tramite WebSocket.

Stack

Python 3.12, FastAPI, async SQLAlchemy + asyncpg, Alembic, arq, LangGraph, LiteLLM, ReportLab, PostgreSQL, Redis, MinIO, asyncssh. Frontend: React 18, Vite, TypeScript, Tailwind, TanStack Query, xterm. Tooling: uv per Python, bun per il frontend.

Avvio rapido

Ti servono Docker, uv e bun.

# 1. infrastructure (Postgres, Redis, MinIO)
docker compose -f docker-compose.dev.yml up -d

# 2. Python deps, database, and seed data
uv sync --group live
uv run rc db upgrade
uv run rc seed              # admin user, provider catalog, buckets

# 3. copy the env template
cp .env.example .env

# 4. run the three processes (separate terminals)
cd apps/api    && uv run uvicorn app.main:app --host 127.0.0.1 --port 8080
cd apps/worker && uv run arq worker.settings.WorkerSettings
cd apps/web    && bun install && bun run dev

Oppure avvia tutti e tre insieme con un process manager (sono dichiarati nel Procfile): pipx install honcho poi honcho start.

Apri http://localhost:5183 e accedi con admin / admin.