Penetration test con risultati validati a mano.
Test di intrusione condotto da persone, con sfruttamento manuale e ogni riscontro riprodotto prima di finire nel rapporto. L'obiettivo non è elencare ciò che sembra vulnerabile: è dimostrare cosa riesce a fare un attaccante con ciò che oggi è esposto.
Cosa risponde un pentest che uno scanner non risponde
Uno strumento automatico segnala ciò che sembra vulnerabile. Un test di intrusione dimostra cosa è davvero sfruttabile e fin dove arriva l'accesso. La differenza emerge nel concatenamento: una falla di autorizzazione che isolata sarebbe classificata come bassa diventa critica quando permette di raggiungere un dato che quell'utente non dovrebbe mai toccare. Nessuno strumento costruisce da solo quel percorso, ed è il percorso — non l'etichetta — a cambiare la priorità della correzione.
- Ogni riscontro viene riprodotto a mano prima di entrare nel rapporto: l'output grezzo di uno strumento non è una consegna.
- Il rischio è descritto per l'impatto sulla tua attività, non solo con il punteggio generico di una base pubblica.
- I falsi positivi non arrivano a te: ciò che non siamo riusciti a riprodurre resta fuori dal documento.
- Il percorso di sfruttamento è registrato passo per passo, così il tuo team può ripeterlo e confermare la correzione.
What's included
L'ambito qui sotto è lo standard per un engagement tipico. Tutto è modificabile durante lo scoping, senza costi.
- Autenticazione, sessione e recupero password
- Autorizzazione orizzontale e verticale per oggetto
- Iniezione in query, comandi e template
- Logica di business e flussi aggirabili
- Caricamento, elaborazione e distribuzione di file
- Configurazione di intestazioni, cookie e CORS
- Enumerazione di risorse e identificatori prevedibili
- Controllo degli accessi tra account e tra tenant
- Validazione dello schema e tipi inattesi
- Limiti di frequenza, costo e abuso automatizzato
- Autenticazione tra servizi e rotazione dei segreti
- Esposizione eccessiva di dati nella risposta
- Superficie esposta al perimetro e servizi dimenticati
- Versioni senza supporto e correzioni in sospeso
- Segmentazione tra ambienti e tra reti
- Servizi interni raggiungibili dal perimetro
- Configurazione TLS e terminazione del traffico
- Movimento laterale da un accesso iniziale
- Provider di identità e flussi di federazione
- Secondo fattore: copertura, aggiramento e recupero
- Privilegi ereditati e accumulo di permessi
- Account di servizio e credenziali nel codice
- Sessioni su più dispositivi e revoca
- Registrazione e onboarding di nuovi utenti
- App Android e iOS, inclusa l'archiviazione locale
- Comunicazione tra app e API e pinning del certificato
- Protezione dalla manomissione e comportamento su dispositivo compromesso
- Wi-Fi aziendale, rete ospiti e separazione tra le due
- Infrastruttura on-premise e ciò che raggiunge nel cloud
- Chioschi, terminali e dispositivi a uso condiviso
- Iniezione: SQL, NoSQL, LDAP, comandi e template
- Autenticazione, autorizzazione, IDOR ed elevazione di privilegi
- SSRF, XXE e deserializzazione insicura
- Falle di logica di business e nel flusso di pagamento
- XSS, CSRF e clickjacking con impatto dimostrato
- Crittografia mal applicata, token prevedibile e JWT fragile
Modalities
adjustable to scopeScatola nera
Partiamo senza informazioni privilegiate, nella stessa posizione di chi attacca dall'esterno. Misura ciò che la tua superficie consegna a uno sconosciuto e fa emergere regolarmente risorse che nessuno sapeva esposte.
Scatola grigia
Riceviamo credenziali e una visione d'insieme dell'architettura. È la modalità che copre più superficie a parità di tempo, perché lo sforzo va allo sfruttamento invece che alla ricognizione, ed è dove emergono le falle di autorizzazione.
Scatola bianca
Accesso a codice, configurazione e documentazione. Permette di raggiungere percorsi che raramente appaiono dall'esterno, come condizioni di gara, gestione degli errori e logica sensibile nascosta sotto più livelli.
Quando un pentest fa davvero la differenza
Non è un adempimento annuale. Ci sono momenti in cui il test restituisce più di quanto costa, perché la superficie è cambiata o perché qualcuno dall'esterno sta per chiedere.
Una riscrittura, un nuovo provider di identità o una migrazione spostano presupposti che nessuno riesamina. Testare prima costa meno che scoprirlo dopo, con traffico reale sopra.
Contratti enterprise, questionari di sicurezza e processi di acquisto richiedono di norma un test indipendente. Il rapporto risponde in modo oggettivo, senza affidarsi a un'autodichiarazione.
Team nuovo, servizio nuovo, integrazione nuova. La crescita accelerata crea superficie che nessuno ha mappato per intero, e permessi concessi in via temporanea e mai revocati.
Sistemi interni datati, pannelli di amministrazione e integrazioni legacy restano fuori da ogni ambito per anni, proprio perché considerati troppo interni per preoccupare.
How we conduct it
[pipeline]Definizione e regole d'ingaggio
Prima che parta un solo pacchetto mettiamo per iscritto cosa rientra nell'ambito, cosa resta fuori, quali finestre sono ammesse e chi viene contattato se qualcosa esce dal previsto. Concordiamo anche il criterio di arresto per riscontri critici, così una scoperta grave ti arriva lo stesso giorno invece di attendere il rapporto.
Ricognizione e mappatura
Ricostruiamo la superficie reale: domini, sottodomini, servizi esposti, tecnologie, punti di ingresso e ciò che è già pubblico sull'ambiente. È la fase che fa emergere risorse fuori inventario: un ambiente di collaudo raggiungibile, un pannello dimenticato, un servizio acceso per una prova e mai spento.
Scansione e triage
L'automazione entra qui, e solo qui: copre volume e propone candidati. Ogni risultato passa per un triage manuale, perché gran parte di ciò che uno strumento segnala non regge quando qualcuno prova a riprodurlo. Ciò che sopravvive diventa ipotesi di sfruttamento.
Sfruttamento manuale
Qui il test si separa da una scansione. Concateniamo falle, sondiamo la logica di business, tentiamo l'elevazione di privilegi e proviamo a raggiungere dati che dovrebbero essere protetti, sempre entro le regole concordate e senza toccare la disponibilità della produzione.
Post-sfruttamento e portata
Trovare la porta non basta: conta dove porta. Misuriamo la portata di un accesso iniziale, cosa si può leggere, modificare o rendere persistente da lì, e se diventa raggiungibile un altro sistema. È questa misura a trasformare un punteggio tecnico in rischio di business.
Rapporto e ritest
Il rapporto porta il percorso riproducibile, l'impatto e la correzione consigliata, con la lettura per la direzione separata dal dettaglio tecnico. Dopo la correzione ritestiamo gli elementi trattati e registriamo cosa si è chiuso, perché un riscontro corretto conta solo quando qualcuno lo conferma.
Riferimenti pubblici che guidano il lavoro
Lavoriamo su metodologie aperte e riconosciute. Questo rende l'ambito confrontabile tra fornitori e permette alla tua funzione di audit di verificare la copertura senza doversi fidare della nostra parola.
- OWASP WSTG
- La guida OWASP ai test sulle applicazioni web organizza la copertura per categoria — autenticazione, sessione, autorizzazione, validazione, logica di business — e offre una base chiara per mostrare cosa è stato verificato.
- OWASP API Security
- L'elenco dei rischi API copre ciò che il test web tradizionale gestisce male: autorizzazione a livello di oggetto, esposizione eccessiva di dati e consumo senza limiti.
- PTES
- Il Penetration Testing Execution Standard descrive le fasi di un test, dal pre-ingaggio al rapporto, ed è la spina dorsale del flusso descritto sopra.
- MITRE ATT&CK
- Il catalogo di tattiche e tecniche avversarie dà un nome a ciò che è stato eseguito, così il tuo team di difesa può confrontare ogni passo con ciò che la detection ha visto, o mancato.
- NIST SP 800-115
- La guida tecnica NIST alla valutazione della sicurezza definisce pianificazione, esecuzione e attività post-test, ed è il riferimento più citato nei requisiti contrattuali.
- CVSS
- Il punteggio standardizza la gravità tecnica, ma entra come dato di ingresso: la priorità segue l'impatto nel tuo contesto, descritto in testo chiaro accanto al numero.
Deliverables
dual view · NDASintesi per la direzione
Una lettura breve per chi decide budget e priorità: cosa è stato testato, cosa rappresenta un rischio reale e cosa richiede una decisione. Scritta senza gergo, per reggere un confronto in consiglio.
Riscontri con riproduzione completa
Ogni voce porta il percorso passo per passo, con richiesta, risposta ed evidenza. Chi sviluppa può riprodurlo senza chiedere chiarimenti e senza dipendere da chi ha eseguito il test.
Valutazione di impatto e priorità
Gravità tecnica e impatto di business compaiono separati, perché non sempre coincidono. L'ordine suggerito tiene conto dello sforzo di correzione, così il team non parte dall'intervento più costoso e meno urgente.
Indicazioni di correzione specifiche
Indicazioni applicate al tuo codice e alla tua architettura, non un paragrafo generico copiato dalla documentazione. Quando esiste più di una strada, il rapporto descrive il compromesso di ciascuna.
Confronto con il tuo monitoraggio
Un riepilogo di quanto eseguito, mappato per tecnica, perché il team di detection lo confronti con ciò che registri e allarmi hanno catturato. Spesso rivela quanto l'elenco delle vulnerabilità.
Ritest e lettera di chiusura
Dopo le correzioni rivediamo gli elementi trattati e registriamo lo stato finale. La lettera serve a clienti, partner e revisori che hanno bisogno di evidenza che il ciclo si sia chiuso.
Frequently asked
Per impostazione predefinita non testiamo la disponibilità. Il denial of service e ogni azione ad alto rischio restano fuori ambito salvo richiesta esplicita con finestra concordata. Se un test potesse toccare la produzione, viene spostato su un ambiente equivalente o eseguito in finestra concordata, con un contatto diretto aperto dall'inizio alla fine.
Un ambito definito, credenziali di prova per ogni profilo utente e un contatto tecnico disponibile. Se una protezione perimetrale può bloccare il test, decidiamo insieme se rientra nell'ambito o riceve un'eccezione: testare il blocco e testare l'applicazione sono obiettivi diversi.
La scansione confronta ciò che trova con una base nota e restituisce un elenco. Il pentest tenta lo sfruttamento, concatena le falle e misura fin dove arriva l'accesso. La scansione costa poco e serve al monitoraggio continuo; il test manuale risponde a ciò che l'elenco non risponde: se quella voce è sfruttabile nel tuo contesto.
Sì. La sintesi per la direzione è scritta per lettori non tecnici e può essere condivisa con cliente, partner o revisore. Il dettaglio tecnico resta in una sezione separata, e la lettera di chiusura emessa dopo il ritest è il documento normalmente accettato come evidenza nei processi di acquisto.
Dipende dal rischio. Un ambiente di collaudo fedele alla produzione è preferibile quando esiste, perché consente test più aggressivi. Quando c'è solo la produzione — il caso più comune — limitiamo le azioni distruttive, concordiamo una finestra e teniamo un canale aperto per tutta l'esecuzione.
Si applica il criterio di arresto concordato all'inizio: un riscontro critico viene comunicato subito, con il minimo necessario per agire, senza attendere il rapporto finale. Se il caso lo richiede, l'esecuzione si sospende fino al contenimento.
Dipende dal ritmo di cambiamento. Un'applicazione con rilascio continuo cambia superficie ogni settimana, e un test annuale guarda a un sistema che non esiste più. Una pratica diffusa unisce un test periodico dell'ambito principale a test puntuali a ogni cambiamento strutturale: nuova integrazione, nuovo provider di identità, nuovo ambiente.
Pronto a scoprire le tue falle?
La prima call di scoping è gratuita e coperta da NDA. In 48 ore ricevi proposta tecnica, scope e cronoprogramma. Senza moduli burocratici.