Basilisk
BASILISK
[cases_index]REAL ENGAGEMENTS · ANONYMIZED

Before it became a headline, it became a fix.

Tutti i casi qui sotto sono stati anonimizzati sotto NDA. Numeri, settore e vettore sono reali — il nome del cliente no.

200+
engagements delivered
4,500+
falle sfruttabili segnalate
R$ 180M+
impatto potenziale evitato
sector
Fintech · Open Finance
vector
API misconfig + IDOR
fix
72h
case/01

Accesso completo alla produzione tramite un'API interna senza autenticazione

Un endpoint di amministrazione era esposto per una configurazione errata del gateway API. Unito a un IDOR nelle rotte di bonifico, consentiva di raggiungere qualunque conto. Individuato al giorno 2 dell'engagement.

impact avoided:R$ 48 mln di movimenti potenziali bloccati
sector
Healthtech · SaaS
vector
Cloud misconfig
fix
24h
case/02

Esposizione di 1,2 mln di cartelle cliniche tramite un bucket S3 di staging

Il bucket di staging replicava dati di produzione senza cifratura né controllo degli accessi. Corretto prima dell'audit ISO esterno.

impact avoided:Sanzione sulla protezione dei dati evitata · incidente non notificabile
sector
Industry · OT
vector
Segmentazione + credenziali obsolete
fix
2 weeks
case/03

Movimento laterale dall'IT allo stabilimento industriale tramite una VPN obsoleta

Engagement di Red Team partito dal phishing. Salto da una postazione di ingegneria alla rete OT attraverso una VPN con credenziali predefinite. Risolto con segmentazione, jump host e MFA.

impact avoided:Fermo linea stimato in 8 giorni evitato
sector
E-commerce · B2C
vector
XSS + sessione senza rotazione
fix
96h
case/04

Catena di exploit: XSS → presa dell'account admin → saldo

Un XSS riflesso nella pagina di ricerca, insieme a una politica dei cookie troppo permissiva, permetteva di rubare la sessione dell'amministratore. Individuato in un pentest ordinario.

impact avoided:Frode bloccata, stimata in R$ 2,3 mln al mese

Perché ogni caso qui è anonimo

Pubblicare il nome di un cliente accanto alla falla che ha avuto lo espone due volte: una durante l'incidente e una per sempre. Descrivere il vettore e l'impatto insegna; identificare la vittima serve solo da vetrina — e disallinea l'incentivo, perché l'azienda disposta ad autorizzare la divulgazione diventa quella che aveva meno da perdere.

  • Nome, marchio e ogni dettaglio che permetta di identificare l'azienda restano fuori.
  • Il vettore tecnico viene mantenuto, perché è la parte di valore per chi legge.
  • Nulla viene pubblicato prima che la correzione sia conclusa e confermata dal ritest.
  • Tutto il materiale passa per l'autorizzazione del cliente prima di diventare testo pubblico.

Schemi che si ripetono

Settori diversi, architetture diverse, eppure le strade che funzionano si somigliano. Questi sono quelli che compaiono più spesso, e vale la pena guardarli prima di commissionare qualsiasi test.

// un ambiente che non dovrebbe esistere

Collaudo con copia della produzione, un vecchio pannello di amministrazione, un servizio acceso per una dimostrazione e mai spento. Di solito manca dall'inventario e resta perciò fuori da ogni protezione applicata al resto.

// autorizzazione a livello di oggetto

Il sistema verifica che tu sia autenticato, ma non che quel record sia tuo. È la falla che lo strumento automatico si lascia sfuggire più spesso, perché la richiesta sembra del tutto legittima.

// permesso temporaneo permanente

Accesso ampio concesso per sbloccare una consegna, con la promessa di stringerlo poi. Mesi dopo è ancora lì, ora ereditato da persone che non hanno mai saputo di averlo.

// un segreto nel posto sbagliato

Una chiave in una variabile d'ambiente esposta, una credenziale nella cronologia del repository, un token in un file di configurazione versionato. È la via più breve per entrare e la più facile da chiudere.

// fiducia tra sistemi

Due applicazioni che si autenticano per posizione di rete o con un segreto condiviso. Compromettere la meno protetta consegna la più protetta, e la segmentazione che dovrebbe contenerlo raramente è stata testata.

// detection che non arriva a nessuno

L'evento è stato registrato, l'allarme è scattato — ed è finito in una coda che nessuno legge. Tecnicamente rilevato, in pratica invisibile: la differenza emerge solo in un esercizio senza preavviso.

Domande frequenti

01Perché non c'è alcun nome di cliente?

Perché l'autorizzazione a pubblicare arriverebbe da chi ha meno da perdere, non da chi ha avuto il caso più istruttivo. Tutto il materiale è reso anonimo sotto accordo di riservatezza, e il vettore tecnico — la parte utile — viene conservato.

02Fate da referenza nel nostro processo d'acquisto?

Sì, con l'autorizzazione delle parti coinvolte. Per la maggior parte dei processi, però, ciò che risolve è la lettera di chiusura del tuo incarico, emessa dopo il ritest: è evidenza diretta, non l'opinione di un terzo su un altro lavoro.

03Un caso simile al nostro significa che il test sarebbe uguale?

No. Il percorso dipende dall'architettura, dalle integrazioni e da decisioni che emergono solo nel tuo ambiente. I casi mostrano il tipo di cosa che si trova di solito, non un copione che si ripete.

04Pubblicate una falla prima che sia corretta?

Mai. Nulla diventa testo pubblico prima che la correzione sia conclusa e confermata dal ritest, e comunque solo con autorizzazione. Lo stesso criterio vale per la ricerca interna, descritto nella politica di divulgazione responsabile.

// contatti

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.