Penetration test
Quello che farebbe un attaccante, noi lo facciamo prima.
Penetration test manuali allineati a OWASP, PTES e NIST. Pentester certificati mettono alla prova la sua applicazione web, le API, l'app mobile, il cloud e la rete esterna e interna come farebbe un vero attaccante. Troviamo a mano le falle di logica di business, gli exploit concatenati e le escalation di privilegi che gli scanner automatici non rilevano mai, e li consegniamo in un report corredato di prove.
Non è un servizio che lancia uno scanner e stampa un PDF. È una disciplina che simula un attaccante che trascorre giorni nel suo sistema, con risultati dimostrabili e un retest dopo le correzioni.
280+
Progetti di pentest
CVSS3.1
Punteggio di rischio
OSCP/CEH
Certificazioni
nmap -sV -p- target.partnerfy.co
443/tcp open https nginx 1.18.0 — TLS 1.2
22/tcp open ssh OpenSSH 7.4 (legacy)
gobuster dir -u https://target -w common.txt
/admin (Status: 200) [Size: 4821]
/api/v1/users (Status: 401) [Size: 38]
/.git/config (Status: 200) [Size: 263]
sqlmap -u 'target/login' --data 'u=a&p=b'
[INFO] testing 'AND boolean-based blind'
[INFO] parameter 'u' is vulnerable
[CRITICAL] SQL Injection — CVE-2024-XXXX — CVSS 9.8
Catena di attacco
MITRE ATT&CK
Report di pentest — Vulnerabilità rilevate
RPT-2026-0541
SQL Injection nel modulo di login
CVSS 9.8
CRIT
Secret JWT debole — brute force
CVSS 9.1
CRIT
IDOR su /api/v1/users/{id}
CVSS 8.2
HIGH
Stored XSS nei commenti
CVSS 7.4
HIGH
CORS configurato in modo errato
CVSS 6.1
MED
Intestazione HSTS mancante
CVSS 3.7
LOW
FIXED
Il problema
Perché gli scanner automatici non bastano?
Scanner come Nessus, Acunetix e OWASP ZAP sono utili, ma non sostituiscono un attaccante. Un attaccante concatena gli exploit, analizza le regole di business della sua azienda e le trasforma in un'arma, ignora il rumore e trova il vero punto di ingresso. Uno scanner esegue una checklist; un pentester formula ipotesi specifiche per il suo sistema.
Nessun exploit concatenato
Uno scanner mostra le vulnerabilità isolate; un attaccante ne combina tre a basso rischio in una catena critica.
Non vede la logica di business
Uno scanner non rileverà mai un errore logico come «moltiplicare il totale dell'ordine per -1».
Nessuna creatività
Un pentester formula ipotesi specifiche per la sua applicazione; uno scanner cerca solo firme.
Una montagna di falsi positivi
Il 70% di un report di scansione di 500 pagine è rumore. Un pentester verifica a mano ogni segnalazione.
Non conosce i limiti di autorizzazione
La regola «questo utente non deve vedere questo record» può verificarla solo chi conosce il suo dominio applicativo.
Non aggira CAPTCHA e WAF
Un attaccante aggira il WAF; uno scanner si ferma al primo 403.
Nessuna ingegneria sociale
A volte il vero ingresso è un'email. Uno scanner non può condurre una simulazione di phishing.
Nessun test anti-forense
Gli attaccanti cancellano le proprie tracce; se il suo SOC se ne accorge può misurarlo solo un red team.
Visualizzazione dell'attacco
Dove sono le falle e quanto sono critiche?
Per ogni progetto sintetizziamo le vulnerabilità rilevate in tre visualizzazioni: una heatmap per categoria, una checklist OWASP Top 10 e una timeline «scansione → rilevamento → correzione → retest → pulito».
Heatmap delle categorie di vulnerabilità
Critical
High
Med
Low
XSS
SQLi
Auth
CORS
Crypto
Logic
IDOR
CSRF
SSRF
Upload
Headers
Deps
Ogni cella è una categoria; i punti indicano numero e gravità delle vulnerabilità. Il suo responsabile vede a colpo d'occhio la zona a rischio.
OWASP Top 10 (2021)
Checklist
- A01 Broken Access Control
- A02 Cryptographic Failures
- A03 Injection (SQL/XSS/Cmd)
- A04 Insecure Design
- A05 Security Misconfiguration
- A06 Vulnerable Components
- A07 Identification & Auth Failures
- A08 Software & Data Integrity
- A09 Logging & Monitoring Failures
- A10 SSRF
Prima e dopo
Il flusso del pentest — scansione → rilevamento → correzione → retest → pulito
Ogni fase è documentata; ogni vulnerabilità viene verificata con un retest gratuito dopo la correzione.
01
Scansione
Ricognizione automatica + manuale
02
Rilevamento
Vulnerabilità verificate
03
Correzione
Proposta di correzione + codice di esempio
04
Retest
Verifica della chiusura
05
Pulito
Report pulito + certificato
Per chi è?
Chi ha davvero bisogno di questo pentest?
Il pentest non è obbligatorio per tutte le aziende, ma se rientra in uno di questi profili dovrebbe iniziare oggi, non un giorno. Ecco gli 8 profili tipici.
E-commerce con pagamenti
Dati delle carte, flussi 3DSecure, abuso di coupon, manipolazione dei prezzi.
SaaS con dati dei clienti
Isolamento multi-tenant, limiti di autorizzazione degli utenti, alto rischio IDOR.
Fintech regolamentate
PCI-DSS, autorità di vigilanza finanziaria, GDPR — almeno un pentest indipendente all'anno.
Sanità con dati PHI
Dati dei pazienti, sistemi di prenotazione, protezione di livello HIPAA.
Fornitori della pubblica amministrazione
Prima degli audit pubblici serve un'attestazione indipendente di pentest.
B2B con integrazioni API
API dei partner, flussi OAuth, catene di identità.
App mobile soggette a revisione App Store
Archiviazione dei token, rilevamento di jailbreak/root, SSL pinning, conformità MASVS.
Clienti dopo un incidente
Dopo un attacco: una risposta basata su prove alla domanda «c'è un'altra porta aperta?».
Ambito del servizio
10 competenze di pentest, un solo team.
Dal web al cloud, dal mobile al fisico — un unico team di ingegneri che copre l'intera superficie di attacco. Se le serve il test di una sola applicazione lo facciamo; se le serve un red team completo, anche.
Pentest della rete esterna
Tutti gli IP esposti su internet, porte aperte, servizi legacy.
Pentest della rete interna
Dall'interno, come un dipendente — il percorso fino a domain admin.
Pentest di applicazioni web
OWASP Top 10, logica di business e scenari di autenticazione e autorizzazione.
Pentest delle API
REST, GraphQL e gRPC; OWASP API Top 10, rate limit, BOLA.
Pentest di app mobile
iOS e Android, MASVS, Frida, reverse engineering.
Pentest del cloud (AWS/Azure/GCP)
Configurazioni IAM errate, bucket pubblici, IAM di Lambda, RBAC di K8s.
Ingegneria sociale
Campagne di phishing, vishing, USB drop — misurano la consapevolezza del personale.
Pentest fisico
Accesso agli uffici, clonazione dei badge, tailgating, raggiungimento della sala server.
Attività di red team
Scenario completo: dall'email al domain admin — il suo SOC riuscirà a intercettarlo?
Retest dopo la correzione
Verifica gratuita che le correzioni abbiano davvero chiuso le falle.
Processo
Il nostro metodo di pentest in 6 fasi.
Ogni progetto segue la stessa disciplina: documento di perimetro (RoE), ricognizione, valutazione delle vulnerabilità, sfruttamento reale, reportistica corredata di prove e, infine, un retest gratuito.
01
Perimetro e Rules of Engagement
Sistemi, scenari, orari consentiti e limiti di frequenza vengono sottoscritti in un documento RoE formale. Produzione o staging, ingegneria sociale inclusa o esclusa — tutto viene chiarito in anticipo.
02
Raccolta di informazioni (recon)
OSINT, enumerazione dei sottodomini, mappatura delle porte, fingerprinting tecnologico, ricerca di credenziali trapelate. Fotografiamo la superficie con gli occhi di un attaccante.
03
Valutazione delle vulnerabilità
L'output degli scanner viene filtrato a mano e si progettano scenari di logica di business. Ogni segnalazione diventa un'ipotesi.
04
Sfruttamento (exploitation)
Le ipotesi vengono dimostrate come farebbe un vero attaccante: exploit concatenati, escalation di privilegi, esfiltrazione di dati — entro limiti etici e con tutto registrato.
05
Reportistica
Executive summary, prove per ogni vulnerabilità, punteggio CVSS e roadmap di correzione con priorità. Il team di sviluppo può scendere fino agli esempi di codice.
06
Correzione e retest
Dopo il rilascio delle correzioni (di solito 4-8 settimane), tutte le vulnerabilità Critical/High vengono ritestate gratuitamente e se ne verifica la chiusura.
Strumenti
Gli strumenti che usiamo sul campo.
Gli strumenti contano, ma conta di più la mente che li usa. Il test manuale viene sempre prima dello scanner.
Burp Suite Pro
OWASP ZAP
Metasploit
Nmap
Nessus
Acunetix
Nuclei
Wireshark
John the Ripper
Hashcat
Cobalt Strike
Postman
ffuf
BloodHound
SQLmap
Frida
MobSF
Kali Linux
Responder
CrackMapExec
Dal campo
Alcune vulnerabilità reali che abbiamo individuato.
Manteniamo riservati i nomi dei clienti e condividiamo i dettagli tecnici. Ogni falla è stata chiusa prima dell'entrata in produzione o prima di qualsiasi abuso.
E-commerce
CRIT
SQL Injection prima del lancio
Blind SQLi nel parametro di ricerca prodotti: si poteva estrarre l'intera tabella degli ordini. Intercettata 4 giorni prima del lancio, con migrazione a ORM.
SaaS
CRIT
Bypass dell'autenticazione
Il JWT accettava «alg:none» — un attaccante poteva entrare in qualsiasi tenant come amministratore.
Mobile banking
CRIT
Archiviazione non sicura dei token
Il token di sessione veniva scritto in chiaro in NSUserDefaults ed era leggibile su un dispositivo con root. Migrazione a Keychain + biometria.
API B2B
HIGH
IDOR — dati di un'altra azienda
/api/invoices/{id} non verificava la proprietà; con gli ID sequenziali si accedeva alle fatture dei concorrenti.
Portale sanitario
HIGH
Link di reset non casuale
Il token di reset della password era ricavato da epoch + user_id; con un attacco brute force si poteva prendere il controllo di qualsiasi account.
AWS aziendale
MED
Bucket S3 pubblico
I log CI/CD finivano in un bucket pubblico e contenevano credenziali temporanee del database.
Domande frequenti
Le domande più frequenti sul pentest.
Uno scanner automatico (Nessus, ZAP, Acunetix ecc.) si basa sulle firme: cerca schemi noti, la maggior parte dei risultati sono falsi positivi e le falle di logica di business non vengono mai individuate. Un pentester, invece, formula ipotesi specifiche per la sua applicazione, concatena tre punti deboli in un attacco critico, tenta a mano l'escalation di privilegi e dimostra ogni vulnerabilità con passaggi riproducibili. In pratica, metà dei «10 critical» di uno scanner sono falsi allarmi; ogni vulnerabilità in un report di pentest è stata sfruttata e dimostrata — il team di sviluppo può saltare la discussione e passare subito alla correzione.
Sono tutti e tre validi e misurano cose diverse. Il black-box parte da un attaccante che non sa nulla della sua azienda: è il più vicino a un attacco reale, ma è costoso in termini di tempo e perimetro. Il white-box mette a disposizione del tester codice sorgente, diagrammi di architettura e account amministrativi: è il test più approfondito per ora di lavoro, ideale prima della produzione. Il gray-box sta nel mezzo: un normale account utente e una visione generale dell'architettura; per la maggior parte dei pentest aziendali è il compromesso più pratico, perché copre sia il modello di attaccante esterno sia quello interno in un unico progetto. La scelta giusta dipende dall'obiettivo; la definiamo insieme nel primo incontro.
Se gestito correttamente, no. Il documento Rules of Engagement (RoE) stabilisce orari consentiti, limiti di concorrenza, account di test isolati e azioni vietate (DoS, cancellazioni permanenti ecc.). Nella maggior parte dei progetti i controlli distruttivi (ad esempio brute force che attiva il blocco degli account, upload di payload) vengono eseguiti solo in staging; in produzione raccogliamo prove in sola lettura. C'è sempre un piano di rollback: snapshot prima del test e un ingegnere reperibile in caso di anomalie. Oltre 280 progetti e nessuna interruzione in produzione, perché questa disciplina esige rigore.
Dipende dal perimetro. Una singola applicazione web richiede in genere 5–10 giorni lavorativi; un progetto API di medie dimensioni 7–12 giorni; un'app mobile 8–14 giorni; uno scenario red team completo 4–8 settimane. A questi si aggiunge, dopo il rilascio delle correzioni (di solito entro 4–8 settimane), il retest gratuito, che richiede circa 2–3 giorni lavorativi. Tre fattori determinano la durata: l'ampiezza del perimetro, il numero di ruoli e permessi da controllare e l'accessibilità dell'ambiente di test. Nel primo incontro definiamo il perimetro e indichiamo giorni e prezzo fissi, che non cambiano in seguito.
Il report ha tre livelli. Il primo è un executive summary: 1–2 pagine con una tabella dei rischi non tecnica, il numero di vulnerabilità e il livello di sicurezza complessivo. Il secondo sono i dettagli tecnici: per ogni vulnerabilità descrizione, componente interessato, passaggi di sfruttamento con screenshot, punteggio CVSS 3.1 e correzione consigliata (con esempi di codice). Il terzo è un piano d'azione con priorità: cosa correggere prima e cosa dopo, in linea con il ritmo dei suoi sprint. L'intero report viene consegnato in Markdown + PDF; dopo il retest viene riemesso con la nota «remediated». I nostri clienti lo presentano direttamente agli audit ISO 27001, SOC 2 e PCI-DSS.
No. Il retest di tutte le vulnerabilità Critical e High del progetto principale è incluso nel prezzo del contratto. Unica condizione: le correzioni devono essere rilasciate entro 4–8 settimane (estendibili a 12 previo accordo) e deve essere disponibile un ambiente testabile. Le vulnerabilità chiuse vengono contrassegnate come «remediated»; quelle ancora aperte vengono segnalate di nuovo. È la nostra garanzia di qualità: non consegniamo un report per poi sparire, restiamo fino alla chiusura. Il retest delle vulnerabilità Medium e Low è facoltativo e costa una piccola parte del progetto principale.
Li usiamo tutti e tre nello stesso progetto. Per le applicazioni web OWASP Top 10 (2021) e OWASP ASVS Level 2; per le API OWASP API Top 10; per il mobile OWASP MASVS. La metodologia segue le fasi PTES (Penetration Testing Execution Standard): pre-engagement, raccolta di informazioni, threat modelling, analisi delle vulnerabilità, exploitation, post-exploitation e reporting. Per il punteggio di rischio usiamo CVSS 3.1; il formato del report fa riferimento a NIST SP 800-115. Il tutto è allineato a ISO 27001, SOC 2 e PCI-DSS: il report ha la forma che il suo auditor si aspetta. Combinare i tre standard garantisce sia la profondità tecnica sia l'idoneità agli audit.
Sì, in ogni progetto l'ingegnere responsabile ha almeno una certificazione riconosciuta dal settore: OSCP (Offensive Security Certified Professional), OSWE (Offensive Security Web Expert), CEH (Certified Ethical Hacker), CRTP (Certified Red Team Professional) o GPEN (GIAC Penetration Tester). Per il mobile preferiamo anche eMAPT, per il cloud AWS Security Specialty o AZ-500. Le certificazioni non sono obbligatorie, ma quando il cliente le richiede (soprattutto nelle gare del settore finanziario e pubblico) possiamo allegarle alla documentazione di acquisto. Più importante è che il team produca risultati riproducibili; le certificazioni ne sono un indicatore, non una garanzia — noi offriamo entrambe le cose.
Troviamo le sue falle
prima degli attaccanti.
In un incontro gratuito di 30 minuti definiamo insieme il piano del pentest: sistemi target, RoE, tempistiche e prezzo fisso.