Dradis Framework: Reporting, Findings e Automazione del Pentest

Dradis Framework: Come Centralizzare i Findings di un Pentest #

Un pentest reale produce output da tool diversi — Nessus, Nmap, Burp Suite, note manuali, screenshot. Alla fine dell’engagement, qualcuno deve mettere tutto insieme in un report coerente. Farlo a mano in Word è lento, error-prone, e ogni consulente scrive i finding in modo diverso. Dradis risolve esattamente questo: un punto centrale dove far confluire tutto, con un formato di output uniforme.

Quando usarlo: qualsiasi pentest/red team con più tool e/o più persone coinvolte, dove serve un report finale consistente. Cosa copre: installazione, import da tool esterni, Issue Library, generazione report. Cosa non copre: le funzionalità avanzate della Professional Edition (Rules Engine, portale risultati in tempo reale, integrazione Jira/ServiceNow) — qui ci concentriamo sulla Community Edition, gratuita e open source.

Fase 0 — Capire la logica prima dei comandi #

Dradis organizza tutto attorno a tre concetti:

1. Project — l’engagement specifico (un cliente, una data, uno scope)
2. Node — un host/target all’interno del progetto (struttura ad albero)
3. Issue — il finding vero e proprio, associato a uno o più Node come evidence

L’idea centrale: invece di scrivere lo stesso finding (“SMBv1 abilitato”) da zero ogni volta, lo scrivi una volta nella Issue Library e lo riusi — anche tra progetti diversi.

Fase 1 — Installazione #

Kali Linux (preinstallato) #

# Avvia il servizio
dradis-start

# Ferma il servizio
dradis-stop

Su Kali il comando storico dradis è deprecato — usa dradis-start/dradis-stop.

Da sorgente (altre distro) #

git clone https://github.com/dradis/dradis-ce.git
cd dradis-ce

# Segui le istruzioni del repo per bundle install e setup del database
# (richiede Ruby on Rails, essendo Dradis un'applicazione Rails)

Accesso #

http://127.0.0.1:3000

oppure, a seconda della configurazione:

https://127.0.0.1:3004

Al primo accesso imposti una password condivisa — a differenza di molti tool, Dradis CE non usa account individuali per utente ma una password di team unica per il progetto. Il campo “Login” serve solo per etichettare chi ha fatto cosa, non per l’autenticazione.

Fase 2 — Creare il Progetto e la Struttura #

Dopo il login, crea la struttura ad albero che rappresenta il tuo engagement:

1. Crea un "branch" (nodo) principale → rinominalo con il nome del progetto
   (es. "AssessmentClienteX-2026")

2. Click destro → "Add child" per creare la gerarchia
   Esempio struttura:
   AssessmentClienteX
   ├── 192.168.1.10 (DC)
   ├── 192.168.1.50 (Web Server)
   └── 192.168.1.100 (Workstation)

Pensa alla struttura prima di iniziare a importare dati — riorganizzarla dopo con centinaia di finding già importati è più laborioso.

Fase 3 — Import da Tool Esterni (il vero valore di Dradis) #

Dradis supporta l’import diretto da decine di scanner — Nessus, Nmap, Burp Suite, Qualys, e molti altri.

Import output Nessus #

Menu → Import from file → Nessus

Carica il file .nessus esportato dal tuo scan

Ogni host scansionato diventa un Node, ogni vulnerability un Issue — automaticamente, senza ricopiare nulla a mano.

Import output Nmap #

Menu → Import from file → Nmap
Carica l'output XML (nmap -oX output.xml)

Import output Burp Suite #

Menu → Import from file → Burp
Carica l'export XML di Burp

⚠️ Nota pratica: l’import diretto popola i finding grezzi dello scanner — servono comunque revisione e triage manuale (stesso discorso del “found vs exploitable” che vale per Nessus). Dradis centralizza i dati, non sostituisce l’analisi umana.

Fase 4 — Issue Library: Scrivi Una Volta, Riusa Sempre #

Questo è il pezzo che fa risparmiare più tempo nel lungo periodo.

Menu → Issue Library

Crea un nuovo Issue con:
- Titolo (es. "SMBv1 Enabled — EternalBlue Exposure")
- Descrizione standard
- Severity di default
- Raccomandazione di remediation standard

Al progetto successivo, invece di riscrivere la stessa descrizione per SMBv1, la importi dalla libreria e la associ ai nuovi Node trovati vulnerabili. Con il tempo, la libreria si arricchisce e ogni nuovo report richiede sempre meno scrittura da zero.

Pratica consigliata: dopo ogni engagement, prenditi qualche minuto per aggiungere alla libreria i finding “belli” scritti durante il progetto — quelli con la spiegazione più chiara o la remediation meglio argomentata. Il prossimo progetto li erediterà gratis.

Fase 5 — Aggiungere Findings Manuali #

Non tutto viene da uno scanner — molte vulnerabilità (logica di business, misconfigurazioni specifiche, chain di exploit) le scrivi a mano.

Sul Node specifico → Add Issue

Campi tipici:
- Title
- Description
- Evidence (dove si trova la vulnerabilità)
- Proof of concept / screenshot
- Severity
- Remediation

Puoi allegare screenshot direttamente come evidence — utile per documentare un exploit riuscito senza dover gestire file separati fuori dal sistema.

Fase 6 — Collaborazione in Team #

Se più persone lavorano sullo stesso progetto:

• Tutti condividono la stessa password di progetto
• I finding aggiunti da un consulente sono immediatamente visibili agli altri
• Puoi commentare i finding altrui per revisione (QA interna prima della consegna)

Workflow tipico in team:

1. Consulente A testa host 192.168.1.10-50, aggiunge finding man mano
2. Consulente B testa host 192.168.1.51-100, in parallelo
3. Report writer (o uno dei due) fa la revisione finale di tutti i finding
4. Generazione report unico, coerente, da tutto il lavoro del team

Senza uno strumento centrale, questo passaggio richiede solitamente di mettere insieme documenti Word separati — con Dradis è già tutto in un posto.

Fase 7 — Generazione del Report Finale #

Menu → Export → [formato desiderato]

Formati disponibili in Community Edition: HTML, testo semplice, e template esportabili (a seconda della configurazione).

Per template di report aziendali complessi (Word con logo, struttura a sezioni personalizzata, tabelle formattate secondo lo standard del tuo studio), la Community Edition richiede più lavoro manuale di adattamento rispetto alla Professional Edition, che offre conversione del template esistente e output diretto in .docx/.xlsx/.pdf.

Cosa include tipicamente un report generato:

• Executive summary
• Metodologia
• Findings raggruppati per severity
• Dettaglio tecnico per ogni finding (con evidence allegate)
• Raccomandazioni di remediation

Errori Comuni #

Dradis nel Workflow di un Pentest #

DURANTE L'ENGAGEMENT
  Ogni tool (Nessus, Nmap, Burp) gira e produce output
  → Import continuo in Dradis, non solo alla fine

PARALLELO AL TESTING
  Note manuali, screenshot, PoC vengono aggiunti man mano
  → Non aspettare la fine per scrivere i finding, il dettaglio si perde

FINE ENGAGEMENT
  Triage e QA di tutti i finding (grezzi + manuali) in un posto solo

CONSEGNA
  Export nel formato richiesto dal cliente
  → Un solo punto di verità, non file sparsi tra consulenti diversi

Il ruolo esatto di Dradis: non sostituisce l’analisi (quella resta umana), ma elimina il lavoro meccanico di mettere insieme dati sparsi in un documento finale coerente. Su un engagement con un solo tester e uno scan, il vantaggio è marginale. Su un team di più persone con più tool, il risparmio di tempo diventa sostanziale.

Cheat Sheet Finale #

FAQ #

Dradis sostituisce la scrittura manuale del report? No. Automatizza l’aggregazione e la formattazione, ma il contenuto (analisi, remediation, contesto) resta lavoro umano.

Serve un account per ogni consulente? No, in Community Edition la password è condivisa a livello di progetto. Il campo Login è solo etichetta informativa.

Posso importare dati da tool non ufficialmente supportati? Sì, tramite l’interfaccia di extension/API — se un tool non ha un import diretto, puoi costruire un connector custom (il progetto è open source ed estendibile).

Community Edition è sufficiente per un red team professionale? Per centralizzare findings e generare report base sì. Per template aziendali complessi, portale risultati in tempo reale, e integrazione con Jira/ServiceNow serve la Professional Edition.

Cosa succede se importo lo stesso scan due volte? Rischi duplicati — verifica sempre se un Node/Issue esiste già prima di re-importare uno scan aggiornato sullo stesso host.

Riferimenti: Dradis Framework GitHub, Dradis Community Edition. Per generare i finding di partenza da importare, vedi Nessus su HackIta. Per centralizzare findings raccolti dopo un pivoting multi-host, vedi Pivoting su HackIta.