Casi d’Uso
Come si presenta il successo, in tre fette di traffico di produzione reale.
I numeri nella nostra sezione risultati — una riduzione mediana dei chargeback di circa il 47%, un tasso di falsi positivi inferiore alla metà di un punto percentuale, la verifica che risponde in pochi millisecondi — provengono da integrazioni come quelle qui sotto. I casi presentati sono compositi anonimizzati; i pattern sono reali.
Marketplace
Il problema: anelli di account falsi che creano decine di account per fare review-bombing, manipolare le classifiche dei venditori o abusare delle promozioni di benvenuto.
Il segnale: dodici account creati nell’arco di due ore, tutti da connessioni diverse — ma con segnali del browser e di manomissione che puntano a un singolo cluster automatizzato.
Come il segnale si compone
Una singola registrazione da una connessione domestica su un browser reale è irrilevante. Dodici registrazioni da dodici connessioni domestiche diverse, su quello che sembra lo stesso browser automatizzato con la stessa firma di manomissione, è un anello di account falsi.
Le categorie che si attivano insieme qui:
- Automazione e bot (01) — firme di browser headless su ogni account.
- Manomissione del fingerprint (02) — drawing test che non corrispondono alla versione del browser dichiarata.
- Abuso dell’infrastruttura (03) — proxy residenziali venduti da un operatore di frode noto.
- Anomalie comportamentali (06) — form di registrazione compilati con pattern identici, stesso timing.
Nessuna singola categoria segnalerebbe l’anello. Il punteggio di rischio combinato sì.
La policy
Il marketplace blocca al livello più alto — l’anello, non i clienti — e applica una verifica telefonica quando il rischio è alto e la confidenza è solida. Tutto il resto passa senza ostacoli. In pratica l’intera policy è poche righe di codice che leggono il livello di rischio che Noxtica restituisce.
Il risultato
Le registrazioni false calano di circa il 70% entro un mese dall’integrazione. Il tasso di conversione delle registrazioni dei clienti reali rimane invariato.
Servizi Finanziari
Il problema: frode card-not-present, in particolare gli attacchi di account takeover in cui l’attaccante ha i dati della carta ma non i dispositivi noti del titolare.
Il segnale: una sessione il cui profilo non corrisponde ai dispositivi noti del titolare. La risposta è una verifica aggiuntiva, non un blocco diretto. I clienti reali non vedono attrito; gli anelli di frode incontrano un controllo extra a ogni transazione.
Come il segnale si compone
La frode card-not-present usa sempre più dati di carte reali rubate su dispositivi controllati dall’attaccante. Il dispositivo è il fattore differenziante. Manteniamo un profilo per cliente; quando una transazione arriva da un profilo che non abbiamo mai visto per quel cliente, la segnaliamo.
Le categorie che si attivano insieme qui:
- Verifiche hardware (05) — il nuovo dispositivo potrebbe avere una firma grafica, audio o di memoria diversa.
- Abuso dell’infrastruttura (03) — gli anelli di frode spesso si trovano dietro rotte da datacenter anche quando usano proxy residenziali in facciata.
- Anomalie comportamentali (06) — timing del checkout che non corrisponde alla storia del titolare.
Il segnale di nuovo dispositivo da solo non è malevolo — i clienti comprano telefoni, cambiano laptop, reinstallano sistemi operativi. Lo pestiamo rispetto alle altre categorie per separare “cliente su un nuovo dispositivo” da “attaccante con dati di carta rubati.”
La policy
Un cliente di ritorno su un dispositivo noto, sotto il livello più alto, passa direttamente senza attrito. Quando il rischio è alto — o un nuovo dispositivo compare su una transazione insolitamente grande — la sessione riceve una verifica aggiuntiva invece di un blocco diretto. Il bias è sempre verso il lasciar completare l’acquisto ai clienti reali.
Il risultato
Le perdite da chargeback calano di circa il 45-50% entro tre mesi. La verifica aggiuntiva è vista solo da una piccola frazione delle transazioni, e la grande maggioranza di queste viene completata con successo — clienti reali che superano il controllo.
Piattaforme Sensibili all’Identità
Il problema: le piattaforme passwordless e single-sign-on devono confermare che l’entità che clicca un link di login sia la stessa che lo ha richiesto. I kit di phishing e i servizi di link-relay rompono questa assunzione.
Il segnale: un link cliccato da un profilo diverso da quello che lo ha richiesto attiva un passaggio di verifica extra. I kit di phishing e i servizi di link-relay vengono intercettati a questo gate.
Come il segnale si compone
Quando viene richiesto un link di login, registriamo il profilo richiedente. Quando il link viene cliccato, riverifichiamo il profilo e lo confrontiamo. Se corrispondono — stesso browser, stesso dispositivo — il link si autentica automaticamente. Se non corrispondono, trattiamo il click come una sessione diversa e richiediamo un passaggio di verifica extra.
Le categorie che si attivano insieme qui:
- Manomissione del fingerprint (02) — i kit di phishing spesso usano browser headless i cui profili non corrispondono al dispositivo reale dell’utente.
- Anomalie comportamentali (06) — il tempo tra la richiesta e il click, l’origine del traffico e come cambia la sessione contano tutti.
- Abuso dell’infrastruttura (03) — i servizi di link-relay tipicamente girano da infrastruttura cloud.
La policy
Se il dispositivo che clicca corrisponde al dispositivo che ha richiesto il link, il link di login funziona automaticamente. Se non corrisponde, la piattaforma richiede un secondo fattore prima di lasciar passare la sessione. Il controllo di corrispondenza è un semplice confronto con il profilo registrato quando il link è stato emesso.
Il risultato
Il successo del phishing contro le campagne con link di login cala drasticamente — tipicamente una riduzione di oltre il 90% negli attacchi di credential-relay riusciti. Gli utenti reali che cambiano dispositivo legittimamente vedono un passaggio di verifica extra, poi vengono aggiunti alla lista dei dispositivi fidati per i link futuri.
Schema: quando bloccare, quando applicare una challenge
Across tutti e tre i casi d’uso, la struttura della policy è la stessa:
- Rischio critical — blocca con logging. Queste sessioni non valgono il costo di una challenge.
- Rischio high — challenge: verifica aggiuntiva, un secondo fattore o revisione manuale. I clienti reali la superano; i bot no.
- Rischio medium — osserva. Registra la sessione e portala in superficie nella dashboard, ma non aggiungere attrito.
- Rischio low o minimal — consenti. La grande maggioranza del traffico.
Queste quattro azioni si mappano sul modello di rischio a cinque livelli: i due livelli più bassi collassano entrambi su “consenti” per quasi tutti, ma mantenerli separati è utile nella dashboard per capire dove si trova la tua popolazione.
Letture Correlate
- Threat categories — dettaglio su ciascuna delle sei categorie a cui fanno riferimento questi casi d’uso.
- Why calibration, not verdicts — perché la policy è tua, non nostra.
- Engineering principles — i vincoli operativi dietro i valori predefiniti.