Truffe online, bonifici fraudolenti e financial cybercrime

Guida operativa per acquisire e correlare prove bancarie, email, chat, account, dispositivi, siti, fatture, carte e transazioni in criptoattività dopo una frode digitale.

Dott. Marcello Quaranta · Studio Quaranta Digital Forensics · Aggiornato il 13 luglio 2026

  • Ambito: truffe online, bonifici fraudolenti, BEC, phishing, carte, falso trading e criptoattività
  • Area: Roma e Lazio
  • Fonti: banca, ricevute, email, chat, account, dispositivi, siti, domini e blockchain
  • Output: hash, timeline, confronto documenti, matrice delle evidenze, flusso dei fondi e relazione tecnica

Introduzione

Una truffa online può iniziare con un’email apparentemente inviata da un fornitore, una telefonata proveniente dal numero visualizzato della banca, un messaggio WhatsApp, un annuncio pubblicitario, una richiesta urgente del presunto amministratore delegato, un falso consulente finanziario o un sito che riproduce l’interfaccia di un servizio reale.

Il trasferimento di denaro rappresenta spesso soltanto l’ultima fase di una sequenza più ampia:

raccolta di informazioni sulla vittima
        ↓
contatto mediante email, telefono, social o chat
        ↓
costruzione di urgenza, fiducia o timore
        ↓
furto di credenziali o manipolazione della persona
        ↓
accesso a un account oppure ordine di pagamento
        ↓
trasferimento verso un conto, carta, wallet o intermediario
        ↓
spostamento rapido dei fondi
        ↓
tentativo di occultamento e nuova vittimizzazione

Le forme più comuni comprendono:

  • phishing;
  • smishing;
  • vishing;
  • quishing mediante codici QR;
  • spoofing del mittente o del numero chiamante;
  • compromissione di una casella email;
  • sostituzione dell’IBAN;
  • Business Email Compromise;
  • CEO fraud;
  • false fatture;
  • frodi su carte;
  • pagamenti verso falsi venditori;
  • investimenti inesistenti;
  • falso trading online;
  • truffe in criptoattività;
  • romance scam;
  • falsi servizi di recupero del denaro;
  • uso di voci clonate o video sintetici.

La Banca d’Italia indica phishing, smishing, vishing, spoofing e social engineering tra le tecniche ricorrenti nelle frodi sui pagamenti. Europol considera le frodi da investimento e il Business Email Compromise tra i principali schemi di frode online contro cittadini e organizzazioni. Banca d’Italia — Truffe nei pagamenti · Europol — Take control of your digital life

Dal punto di vista informatico-forense, la domanda non è soltanto:

“Dove sono finiti i soldi?”

Occorre ricostruire:

  1. chi ha materialmente disposto l’operazione;
  2. attraverso quale account e dispositivo;
  3. se il pagamento fosse riconosciuto o non riconosciuto dal titolare;
  4. se la vittima sia stata indotta a eseguire personalmente il trasferimento;
  5. se sia stata compromessa una casella email;
  6. se siano stati alterati fatture, PDF o coordinate bancarie;
  7. se siano state utilizzate sessioni, token o applicazioni remote;
  8. quale identificativo abbia la transazione;
  9. quali intermediari siano coinvolti;
  10. quali dati possano essere ancora preservati;
  11. quali elementi siano utili per un’eventuale attribuzione;
  12. quali limiti impediscano conclusioni più forti.

Un pagamento non riconosciuto dal titolare non è tecnicamente identico a un pagamento eseguito personalmente dalla vittima sotto l’effetto di un inganno.

In entrambi i casi può esistere una frode. Tuttavia, le tracce disponibili, le modalità di contestazione, la ricostruzione della volontà e la valutazione delle responsabilità possono essere differenti.

Il perito informatico non decide se la banca debba rimborsare il cliente, non stabilisce la responsabilità penale e non promette il recupero delle somme.

Può invece:

  • acquisire le prove;
  • ricostruire gli eventi;
  • individuare le fonti;
  • correlare dispositivi, account e pagamenti;
  • documentare le modalità tecniche;
  • evidenziare anomalie;
  • predisporre una timeline;
  • indicare i limiti;
  • supportare il legale, il cliente, l’azienda e il CTP.

Sintesi operativa

1. contattare immediatamente banca o prestatore di pagamento;
2. chiedere blocco, revoca o richiamo delle operazioni, ove ancora possibile;
3. bloccare carte, account e dispositivi compromessi;
4. non utilizzare un dispositivo sospetto per cambiare credenziali;
5. conservare notifiche, SMS, email, chat e registri chiamate;
6. acquisire le ricevute del pagamento nella forma originaria;
7. annotare CRO, TRN, EndToEndId, UETR e ogni riferimento disponibile;
8. acquisire IBAN, nome del beneficiario e banca destinataria;
9. acquisire account, sito, dominio e profilo utilizzati dal truffatore;
10. conservare il messaggio che ha indotto il pagamento;
11. non cancellare chat, email, applicazioni o file;
12. calcolare l’hash dei reperti;
13. costruire una timeline in ora locale e UTC;
14. distinguere operazione non autorizzata e operazione indotta;
15. verificare eventuali compromissioni di email e account;
16. analizzare smartphone e computer utilizzati;
17. documentare reclami, denunce e richieste di recupero;
18. ricostruire il percorso osservabile dei fondi;
19. indicare separatamente dati, deduzioni e dichiarazioni;
20. descrivere sempre limiti e ipotesi alternative.

Nelle frodi finanziarie la tempestività può aumentare le possibilità di contenimento, ma l’urgenza non deve trasformarsi nella cancellazione incontrollata delle prove.

1. Avvertenza preliminare

Attività esclusivamente autorizzate. Le procedure non autorizzano accessi a conti, account, wallet, dispositivi o dati di terzi e non sostituiscono la valutazione legale e bancaria.

Questo capitolo descrive attività tecniche lecite e autorizzate.

Le procedure devono essere eseguite:

  • sul proprio conto o account;
  • su strumenti aziendali amministrati legittimamente;
  • con autorizzazione del titolare;
  • nell’ambito di un incarico professionale;
  • su dati messi lecitamente a disposizione;
  • nel rispetto della riservatezza e della minimizzazione.

Non è lecito utilizzare le procedure per:

  • accedere al conto del beneficiario;
  • tentare password;
  • ottenere credenziali con inganno;
  • intercettare OTP;
  • entrare in wallet altrui;
  • utilizzare seed phrase o chiavi private di terzi;
  • installare software su dispositivi non autorizzati;
  • modificare siti o account sospetti;
  • contattare il truffatore impersonando altre persone;
  • tracciare soggetti con strumenti invasivi;
  • pubblicare dati bancari o personali;
  • sequestrare autonomamente fondi.

Il cliente non dovrebbe inviare al perito tramite email ordinaria:

- password;
- OTP;
- PIN;
- codici di recupero;
- chiavi private;
- seed phrase;
- cookie;
- token;
- numeri completi di carta;
- codici CVV;
- credenziali home banking.

Il perito non deve mai chiedere tali dati quando non sono indispensabili.

2. In caso di frode ancora in corso

Quando il pagamento è appena avvenuto o il truffatore conserva l’accesso al conto, la priorità è il contenimento.

2.1 Contattare immediatamente l’intermediario

Utilizzare:

  • numero ufficiale della banca;
  • applicazione ufficiale;
  • filiale;
  • canale di emergenza;
  • numero presente sulla carta;
  • recapito verificato sul sito ufficiale.

Richiedere, secondo il caso:

[ ] blocco della carta;
[ ] blocco dell’home banking;
[ ] revoca delle sessioni;
[ ] sospensione dell’operazione;
[ ] richiamo del bonifico;
[ ] segnalazione alla banca beneficiaria;
[ ] blocco cautelativo del beneficiario;
[ ] disconoscimento delle operazioni;
[ ] apertura di una pratica frode;
[ ] preservazione dei log.

La Banca d’Italia raccomanda di segnalare subito alla banca le operazioni fraudolente, chiedere il rimborso quando pertinente e conservare il percorso di reclamo; indica inoltre la possibilità di ricorrere all’Arbitro Bancario Finanziario dopo il preventivo reclamo all’intermediario. Banca d’Italia — Truffe cyber

2.2 Non usare recapiti ricevuti dal presunto operatore

Il numero visualizzato può essere falsificato mediante caller ID spoofing.

Non richiamare:

  • il numero indicato nell’SMS;
  • il numero fornito dal chiamante;
  • un recapito presente nella falsa email;
  • un numero ricevuto in chat.

La visualizzazione del numero della banca non dimostra che la chiamata provenga realmente dall’istituto. La Polizia di Stato richiama espressamente l’attenzione sulle truffe realizzate mediante spoofing. Polizia di Stato — Attenzione alle truffe tramite spoofing

2.3 Presentare una denuncia

La segnalazione online non sostituisce necessariamente la denuncia formale.

È opportuno coordinarsi con:

  • avvocato;
  • Polizia Postale;
  • Polizia di Stato;
  • Carabinieri;
  • altra autorità competente.

Il portale della Polizia Postale indica che, in presenza di un reato informatico, è possibile rivolgersi alle sedi territoriali per formalizzare la denuncia. Commissariato di PS Online — Segnalazioni

2.4 Conservare il numero della pratica

Annotare:

Banca:
Numero pratica:
Data apertura:
Ora:
Operatore:
Canale:
Operazioni segnalate:
Richiesta effettuata:
Risposta:
Documenti inviati:
Passaggi successivi:

3. Quattro categorie tecniche da distinguere

3.1 Operazione non riconosciuta

La vittima afferma di non aver:

  • inserito il pagamento;
  • autorizzato il bonifico;
  • utilizzato la carta;
  • approvato la transazione;
  • fornito consapevolmente il consenso.

Possibili cause:

  • credenziali sottratte;
  • carta clonata;
  • account takeover;
  • sessione rubata;
  • malware;
  • dispositivo sottratto;
  • token compromesso.

3.2 Operazione disposta sotto inganno

La vittima:

  • inserisce il bonifico;
  • approva l’operazione;
  • comunica un codice;
  • segue le istruzioni del falso operatore;
  • paga il falso fornitore;
  • trasferisce denaro a un presunto investimento.

Il sistema può registrare un’autenticazione formalmente riuscita, mentre il consenso economico è stato ottenuto attraverso una manipolazione.

La valutazione giuridica e bancaria deve essere effettuata caso per caso.

3.3 Operazione su coordinate alterate

L’azienda intende pagare un fornitore reale, ma riceve:

  • fattura modificata;
  • email compromessa;
  • IBAN sostituito;
  • PDF contraffatto;
  • messaggio proveniente da dominio simile;
  • richiesta urgente apparentemente autentica.

3.4 Operazione verso un servizio inesistente

Esempi:

  • falso trading;
  • falso marketplace;
  • falso prestito;
  • falso recupero crediti;
  • romance scam;
  • falsa raccolta fondi;
  • acquisto di bene inesistente;
  • piattaforma cripto non autorizzata.

4. Inquadramento normativo essenziale

4.1 Truffa

L’articolo 640 del codice penale riguarda la condotta di chi, mediante artifici o raggiri, induce una persona in errore e procura a sé o ad altri un ingiusto profitto con altrui danno. Normattiva — Articolo 640 del codice penale

4.2 Frode informatica

L’articolo 640-ter riguarda l’alterazione del funzionamento di un sistema o l’intervento senza diritto su dati, informazioni o programmi, quando ne derivi un ingiusto profitto con altrui danno.

La formulazione vigente considera anche ipotesi aggravate collegate al trasferimento di denaro, valore monetario o valuta virtuale e all’indebito utilizzo dell’identità digitale. Gazzetta Ufficiale — Disposizioni sui reati relativi agli strumenti di pagamento

4.3 Strumenti di pagamento diversi dai contanti

L’articolo 493-ter disciplina, nei relativi presupposti, l’indebito utilizzo e la falsificazione di carte e altri strumenti di pagamento diversi dal contante. Gazzetta Ufficiale — Decreto legislativo 184/2021

4.4 Accesso abusivo

La compromissione di una casella, di un account bancario o di un servizio cloud può richiamare anche i profili già trattati nel Capitolo 18 — Accessi abusivi ad account email, social e cloud.

4.5 Operazioni di pagamento non autorizzate

Il decreto legislativo n. 11/2010 disciplina, tra gli altri aspetti, la contestazione delle operazioni non autorizzate.

La comunicazione deve avvenire senza indugio. La disposizione prevede un termine massimo di tredici mesi dalla data di addebito o accredito, fatti salvi i casi previsti dalla norma, ma il termine massimo non deve essere interpretato come un invito ad attendere. Gazzetta Ufficiale — Decreto legislativo 11/2010

La Banca d’Italia ricorda che, quando ricorrono i presupposti di un’operazione non autorizzata, il prestatore è generalmente tenuto al rimborso immediato e comunque entro la fine della giornata operativa successiva alla conoscenza dell’operazione, salvo il caso di sospetto di frode dell’utilizzatore comunicato per iscritto all’Autorità. Banca d’Italia — Operazioni di pagamento non autorizzate

4.6 Nessun automatismo

Il perito non deve concludere:

“Il rimborso è sicuramente dovuto.”

“La vittima ha autorizzato, quindi non ha diritto ad alcuna tutela.”

“La banca è certamente responsabile.”

Sono valutazioni che dipendono da:

  • qualificazione dell’operazione;
  • contratto;
  • autenticazione;
  • comportamento delle parti;
  • misure di sicurezza;
  • tempestività;
  • prove;
  • interpretazione normativa;
  • decisioni del giudice o dell’organismo competente.

5. Perché la tempestività è decisiva

I fondi possono essere:

  • trasferiti su un altro conto;
  • prelevati;
  • convertiti;
  • divisi;
  • utilizzati per acquisti;
  • spostati su carte;
  • inviati all’estero;
  • trasformati in criptoattività;
  • trasferiti attraverso più intermediari.

Un bonifico istantaneo può essere accreditato in pochi secondi e in qualsiasi momento della giornata. La rapidità del regolamento riduce il tempo disponibile per un intervento prima dell’accredito. Banca Centrale Europea — Instant payments

La tempestività non garantisce il recupero.

Può però consentire:

  • apertura immediata della pratica;
  • segnalazione alla banca beneficiaria;
  • attivazione di procedure interbancarie;
  • blocco di ulteriori pagamenti;
  • preservazione dei log;
  • identificazione del conto destinatario;
  • acquisizione delle prove prima della loro cancellazione.

6. Protocollo dei primi quindici minuti

1. interrompere la comunicazione con il presunto operatore;
2. non eseguire altri pagamenti;
3. usare un telefono o computer affidabile;
4. contattare la banca mediante un recapito ufficiale;
5. bloccare carta o home banking, se necessario;
6. chiedere l’apertura della pratica antifrode;
7. comunicare identificativo, importo e beneficiario;
8. chiedere il richiamo o blocco, ove disponibile;
9. acquisire screenshot dell’operazione;
10. salvare SMS, email e chat;
11. annotare numero chiamante e orario;
12. non cancellare applicazioni;
13. non formattare il dispositivo;
14. registrare tutte le azioni effettuate;
15. informare il responsabile aziendale, se pertinente.

7. Protocollo delle prime ventiquattro ore

[ ] formalizzare il disconoscimento o la contestazione;
[ ] conservare la ricevuta della banca;
[ ] acquisire il dettaglio completo della transazione;
[ ] acquisire CRO, TRN, EndToEndId o UETR;
[ ] conservare estratto conto e saldo;
[ ] acquisire email e chat in formato originario;
[ ] acquisire il sito o il profilo fraudolento;
[ ] preservare dominio, URL e numero telefonico;
[ ] cambiare le credenziali da dispositivo sicuro;
[ ] revocare sessioni e dispositivi;
[ ] verificare regole email e inoltri;
[ ] bloccare carte e wallet;
[ ] presentare denuncia;
[ ] avvisare il beneficiario reale, se esiste;
[ ] acquisire smartphone e computer;
[ ] costruire la prima timeline;
[ ] verificare eventuali ulteriori pagamenti;
[ ] informare DPO e legale, se coinvolti dati aziendali;
[ ] conservare ogni ticket e risposta;
[ ] evitare contatti non coordinati con il truffatore.

8. Cosa non fare

[ ] non inviare altro denaro per “sbloccare” il rimborso;
[ ] non pagare presunte tasse di recupero;
[ ] non fornire OTP;
[ ] non installare software indicato da un chiamante;
[ ] non accedere all’home banking dal computer sospetto;
[ ] non cancellare la chat;
[ ] non eliminare le email;
[ ] non modificare i file ricevuti;
[ ] non ritagliare gli screenshot originali;
[ ] non pubblicare l’IBAN del beneficiario;
[ ] non contattare autonomamente il titolare apparente del conto;
[ ] non minacciare il presunto autore;
[ ] non condividere la seed phrase di un wallet;
[ ] non caricare i reperti su siti di analisi sconosciuti;
[ ] non credere a chi garantisce il recupero delle somme;
[ ] non promettere al cliente un risultato.

9. Questionario iniziale per il cliente

9.1 Operazione economica

1. Quale importo è stato trasferito?
2. In quale data e ora?
3. Con quale strumento?
4. Bonifico ordinario o istantaneo?
5. Carta di credito, debito o prepagata?
6. Wallet o criptoattività?
7. Quale beneficiario compare?
8. Quale IBAN o indirizzo wallet?
9. Quale causale?
10. Quale identificativo?
11. Il pagamento risulta eseguito, pendente o annullato?
12. Esistono pagamenti successivi?

9.2 Modalità della truffa

1. Chi ha contattato la vittima?
2. Attraverso quale canale?
3. Quale identità ha dichiarato?
4. È stato mostrato il numero della banca?
5. È stato utilizzato un sito?
6. È stata inviata una fattura?
7. È stato installato software remoto?
8. È stato comunicato un OTP?
9. È stata approvata una notifica?
10. La vittima ha inserito personalmente il bonifico?

9.3 Dispositivi

[ ] smartphone;
[ ] computer;
[ ] tablet;
[ ] telefono aziendale;
[ ] browser;
[ ] app bancaria;
[ ] app di messaggistica;
[ ] app di autenticazione;
[ ] software remoto;
[ ] wallet.

9.4 Azioni già eseguite

Chiedere se la vittima ha:

  • bloccato la carta;
  • cambiato password;
  • cancellato messaggi;
  • disinstallato app;
  • formattato il dispositivo;
  • contattato il beneficiario;
  • inviato la denuncia;
  • chiesto il richiamo;
  • aperto un reclamo;
  • comunicato dati a terzi;
  • effettuato un secondo pagamento.

10. Definire correttamente il quesito tecnico

Un quesito improprio è:

“Dimostrare che la banca deve restituire il denaro.”

Quesiti tecnicamente corretti possono essere:

- ricostruire la sequenza che ha preceduto il pagamento;
- verificare se l’account email fosse compromesso;
- acquisire il messaggio che conteneva il nuovo IBAN;
- confrontare fattura originale e fattura modificata;
- verificare dispositivo e sessione utilizzati;
- acquisire le notifiche di autenticazione;
- ricostruire la timeline del bonifico;
- identificare i riferimenti della transazione;
- documentare sito, dominio e profilo fraudolento;
- analizzare eventuali software remoti;
- individuare elementi compatibili con phishing o malware;
- descrivere i limiti dell’attribuzione.

“L’accertamento è finalizzato alla ricostruzione tecnica della comunicazione, del dispositivo e dell’operazione di pagamento. Non comprende la decisione sul diritto al rimborso né l’accertamento della responsabilità penale.”

11. Mappa delle fonti di prova

11.1 Banca o prestatore di pagamento

  • ricevuta;
  • estratto conto;
  • dettaglio operazione;
  • identificativo;
  • log di accesso;
  • autenticazione;
  • dispositivo;
  • IP;
  • notifiche;
  • registrazione della chiamata;
  • ticket;
  • reclamo;
  • richiamo;
  • risposta della banca beneficiaria.

11.2 Email

  • EML;
  • header;
  • Message-ID;
  • allegati;
  • DKIM;
  • SPF;
  • DMARC;
  • URL;
  • cronologia;
  • regole;
  • inoltri;
  • accessi.

11.3 Messaggistica

  • WhatsApp;
  • Telegram;
  • Signal;
  • SMS;
  • chat marketplace;
  • messaggi social;
  • vocali;
  • chiamate;
  • allegati.

11.4 Dispositivo

  • browser;
  • cronologia;
  • download;
  • cache;
  • malware;
  • software remoto;
  • notifiche;
  • applicazioni;
  • registri;
  • file;
  • account.

11.5 Web

  • dominio;
  • URL;
  • DNS;
  • certificato;
  • pagina;
  • form;
  • profilo;
  • annuncio;
  • archivio;
  • pubblicità;
  • codice QR.

11.6 Pagamento

  • IBAN;
  • BIC;
  • beneficiario;
  • causale;
  • importo;
  • valuta;
  • data;
  • EndToEndId;
  • CRO;
  • TRN;
  • UETR;
  • hash della ricevuta;
  • identificativo carta;
  • transaction hash blockchain.

12. Cartella del caso

CASO_RM_2026_019/
├── 00_incarico/
├── 01_verbali/
├── 02_banca/
├── 03_ricevute_pagamenti/
├── 04_email/
├── 05_chat/
├── 06_chiamate/
├── 07_siti_web/
├── 08_domìni_dns_tls/
├── 09_smartphone/
├── 10_computer/
├── 11_account/
├── 12_file_fatture_pdf/
├── 13_carte/
├── 14_cripto_wallet/
├── 15_hash/
├── 16_timeline/
├── 17_flusso_fondi/
├── 18_reclami_denunce/
├── 19_output_strumenti/
├── 20_report/
└── 21_relazione/

Le cartelle contenenti:

  • numeri di carta;
  • documenti d’identità;
  • dati bancari;
  • seed phrase;
  • chiavi;
  • token;

devono essere cifrate e soggette ad accesso limitato.

13. Registro dei reperti

ID Descrizione Fonte Data acquisizione Hash Riservatezza
RM19-001 Email falsa fattura casella autorizzata data e ora SHA-256 riservata
RM19-002 PDF con IBAN allegato email data e ora SHA-256 riservata
RM19-003 Ricevuta bonifico portale banca data e ora SHA-256 altamente riservata
RM19-004 Chat WhatsApp smartphone data e ora SHA-256 riservata
RM19-005 Acquisizione sito URL data e ora SHA-256 ordinaria
RM19-006 Log di accesso banca/provider data e ora SHA-256 altamente riservata
RM19-007 Transazione blockchain fonte pubblica data e ora SHA-256 output ordinaria

14. Catena di custodia

Per ogni reperto annotare:

- identificativo;
- descrizione;
- fonte;
- soggetto conferente;
- data e ora;
- fuso;
- modalità di acquisizione;
- strumento;
- versione;
- formato;
- hash;
- posizione;
- copie;
- accessi;
- trasferimenti;
- eventuali anomalie.

La procedura generale è descritta nel Capitolo 2 — Catena di custodia, hash e verbale tecnico.

“I reperti sono stati acquisiti mediante fonti e account autorizzati, identificati con impronta SHA-256 e conservati separatamente dalle copie di lavoro.”

15. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\ricevuta-bonifico.pdf"

Linux

sha256sum -- ricevuta-bonifico.pdf

macOS

shasum -a 256 -- ricevuta-bonifico.pdf

Per una directory:

find reperti -type f -print0 \
  | sort -z \
  | xargs -0 sha256sum \
  > manifest_sha256.txt

L’hash:

  • documenta l’identità binaria;
  • consente confronti;
  • non dimostra la veridicità della ricevuta;
  • non dimostra che il pagamento sia stato eseguito;
  • non identifica l’autore.

16. Data, ora e fuso

Registrare:

- data del messaggio;
- data del server;
- data della ricevuta;
- data contabile;
- data valuta;
- data del bonifico;
- data di esecuzione;
- data di accredito;
- ora locale;
- UTC;
- fuso del dispositivo;
- fuso del provider;
- precisione.

PowerShell

Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"
(Get-Date).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ss.fffZ")

Linux

date --iso-8601=seconds
date -u --iso-8601=seconds

Non confondere:

data ordine
≠
data autorizzazione
≠
data esecuzione
≠
data regolamento
≠
data valuta
≠
data acquisizione forense

17. Phishing, smishing, vishing e quishing

Tecnica Canale Obiettivo tipico
Phishing email credenziali, pagamento, malware
Smishing SMS link, OTP, app falsa
Vishing chiamata manipolazione, codici, bonifico
Quishing QR code sito falso o pagamento
Spoofing mittente o numero apparire come soggetto affidabile

La Banca d’Italia descrive queste tecniche come forme ricorrenti di social engineering nei pagamenti digitali. Banca d’Italia — Truffe nei pagamenti

17.1 Acquisire

[ ] messaggio completo;
[ ] numero o mittente;
[ ] data;
[ ] link;
[ ] QR;
[ ] email originale;
[ ] dominio;
[ ] chiamata;
[ ] istruzioni ricevute;
[ ] credenziali richieste;
[ ] azione eseguita.

17.2 Cosa non dimostra il mittente

Il campo visualizzato può essere falsificato.

Esempio:

Mittente visualizzato: BANCA
Numero visualizzato: numero ufficiale
Dominio reale: diverso

La visualizzazione non prova l’origine.

18. Social engineering

Il social engineering agisce su:

  • urgenza;
  • autorità;
  • paura;
  • scarsità;
  • fiducia;
  • opportunità;
  • relazione affettiva;
  • senso del dovere;
  • segretezza.

Esempi:

“Il conto verrà bloccato.”
“È in corso un bonifico.”
“Deve spostare il denaro su un conto sicuro.”
“Non informi nessun collega.”
“L’amministratore delegato richiede il pagamento.”
“Il rendimento è disponibile solo oggi.”
“Occorre versare una tassa per recuperare i fondi.”

Il perito deve documentare il linguaggio della manipolazione senza formulare diagnosi psicologiche.

“La comunicazione contiene elementi di urgenza, autorità e riservatezza compatibili con tecniche di manipolazione della vittima.”

19. Business Email Compromise

Il BEC è una frode in cui una comunicazione aziendale viene utilizzata per indurre un pagamento non dovuto o verso coordinate alterate.

Può avvenire mediante:

  • casella compromessa;
  • dominio simile;
  • account falso;
  • inoltro email;
  • falsa identità del dirigente;
  • modifica della fattura;
  • controllo prolungato della conversazione.

Europol descrive il BEC o CEO fraud come uno schema in cui un dipendente autorizzato ai pagamenti viene indotto a pagare una falsa fattura o a eseguire un trasferimento fraudolento. Europol — CEO fraud e BEC

19.1 Sequenza tipica

accesso alla casella
        ↓
lettura delle conversazioni
        ↓
individuazione di una fattura imminente
        ↓
creazione di regola o inoltro
        ↓
invio di nuove coordinate
        ↓
pagamento
        ↓
eliminazione o occultamento delle risposte

19.2 Elementi da verificare

[ ] account mittente;
[ ] dominio;
[ ] Message-ID;
[ ] Received;
[ ] DKIM;
[ ] SPF;
[ ] DMARC;
[ ] Reply-To;
[ ] allegato;
[ ] IBAN;
[ ] regole;
[ ] inoltri;
[ ] login;
[ ] dispositivi;
[ ] timeline;
[ ] comunicazioni precedenti.

20. CEO fraud

Nella CEO fraud il truffatore impersona:

  • amministratore delegato;
  • titolare;
  • direttore finanziario;
  • avvocato;
  • consulente;
  • responsabile acquisti.

La richiesta è spesso:

  • urgente;
  • riservata;
  • fuori procedura;
  • diretta a un dipendente specifico;
  • collegata a una falsa acquisizione o operazione societaria.

“La richiesta di pagamento risulta inserita in una comunicazione che riproduceva l’identità apparente del dirigente, ma proveniva dall’account o dominio descritto. L’attribuzione dell’invio a una persona fisica richiede ulteriori elementi.”

21. Sostituzione dell’IBAN

La sostituzione può avvenire:

  1. nel corpo dell’email;
  2. in un PDF;
  3. in un documento Office;
  4. mediante immagine sovrapposta;
  5. in una risposta da dominio simile;
  6. attraverso una casella compromessa;
  7. tramite messaggio WhatsApp;
  8. mediante falso portale fornitore.

21.1 Confrontare le versioni

Elemento Documento reale Documento contestato
Hash valore A valore B
IBAN reale sostituito
Data valore valore
Autore PDF valore valore
Software valore valore
Firma presente/assente presente/assente
Dimensione valore valore
Email sorgente casella A casella B

21.2 Analisi del PDF

pdfinfo fattura.pdf
qpdf --check fattura.pdf
exiftool -G0:1:2 -a -s fattura.pdf

Approfondimento: PDF, firme digitali e marche temporali.

22. Casella compromessa o dominio imitativo?

22.1 Casella compromessa

Indicatori:

  • email realmente inviata dal dominio del fornitore;
  • accessi anomali;
  • regole;
  • messaggi eliminati;
  • inoltri;
  • modifiche account;
  • attività da IP esterno.

22.2 Dominio imitativo

Esempio:

fornitore-roma.it
fomitore-roma.it
fornitore-rorna.it
fornitore-roma.com

Possibili tecniche:

  • sostituzione di lettere;
  • caratteri Unicode;
  • sottodomini;
  • dominio diverso;
  • punycode;
  • nome visualizzato identico.

22.3 Acquisire il dominio

whois dominio.example
dig dominio.example A
dig dominio.example MX
dig dominio.example NS
dig dominio.example TXT

Certificato:

openssl s_client \
  -connect dominio.example:443 \
  -servername dominio.example \
  < /dev/null 2>/dev/null |
openssl x509 \
  -noout \
  -fingerprint \
  -sha256 \
  -dates \
  -issuer \
  -subject

La registrazione del dominio non identifica automaticamente l’autore.

23. Analisi forense dell’email

Acquisire preferibilmente:

  • EML;
  • MSG;
  • MBOX;
  • esportazione della casella;
  • messaggio nel server;
  • audit log.

Non limitarsi al PDF stampato.

23.1 Header essenziali

From
To
Date
Message-ID
Return-Path
Reply-To
Received
Authentication-Results
DKIM-Signature
SPF
DMARC
Content-Type

23.2 Allegati

Per ogni allegato:

Nome:
MIME:
Dimensione:
Hash:
Data:
Metadati:
Relazione col messaggio:

Approfondimento: Analisi forense di email e header.

24. Verifica del beneficiario

Il regolamento europeo sui bonifici istantanei ha introdotto il servizio di verifica del beneficiario, comunemente indicato come Verification of Payee.

Il servizio confronta il nome fornito dal pagatore con l’identificativo del conto e comunica un risultato prima dell’autorizzazione, ad esempio:

match
close match
no match
other

L’obbligo è entrato in applicazione nell’area euro dal 9 ottobre 2025, ferme le scadenze differenziate previste dal regolamento per specifiche categorie di prestatori. Banca Centrale Europea — Verification of Payee

24.1 Acquisire

[ ] nome inserito;
[ ] IBAN;
[ ] esito della verifica;
[ ] testo dell’avviso;
[ ] eventuale nome proposto;
[ ] scelta dell’utente;
[ ] data e ora;
[ ] canale;
[ ] screenshot originale.

24.2 Limiti

Un esito “match” non dimostra che:

  • il beneficiario sia affidabile;
  • il pagamento sia legittimo;
  • il venditore consegnerà il bene;
  • il conto non sia controllato da un prestanome;
  • l’operazione non faccia parte di una truffa.

Un esito “no match” non dimostra automaticamente una frode.

Può derivare da:

  • ragione sociale;
  • abbreviazione;
  • intestazione diversa;
  • conto professionale;
  • errore;
  • conto di pagamento.

“Il sistema ha restituito l’esito indicato rispetto alla coppia nome-IBAN. Tale controllo non costituisce una verifica complessiva della legittimità economica del pagamento.”

25. Ricevuta del bonifico

La ricevuta dovrebbe essere acquisita:

  • dal portale bancario;
  • come PDF originale;
  • come esportazione;
  • mediante screenshot completo;
  • con hash.

25.1 Campi da cercare

- ordinante;
- conto di addebito;
- beneficiario;
- IBAN;
- BIC;
- importo;
- valuta;
- causale;
- data ordine;
- data esecuzione;
- stato;
- CRO;
- TRN;
- EndToEndId;
- UETR;
- canale;
- commissioni.

25.2 Ricevuta falsa

Un PDF può essere creato senza che il pagamento sia stato realmente eseguito.

Verificare:

  • riscontro sul conto;
  • stato dell’operazione;
  • accredito;
  • portale;
  • identificativo;
  • metadati;
  • struttura PDF;
  • firma;
  • comunicazione della banca.

“Il documento rappresenta una ricevuta apparente. L’effettiva esecuzione deve essere verificata attraverso i dati del prestatore di pagamento.”

26. Identificativi della transazione

26.1 CRO e TRN

Possono essere visualizzati nelle ricevute italiane e aiutare a individuare l’operazione.

26.2 EndToEndId

È un riferimento inserito nella catena del pagamento e può essere utile per correlare:

  • ordine;
  • distinta;
  • flusso;
  • estratto conto;
  • risposta bancaria.

26.3 UETR

Nei pagamenti SWIFT, l’Unique End-to-end Transaction Reference funziona come identificativo di tracciamento lungo la catena del pagamento. SWIFT lo descrive come un riferimento univoco che permette alle parti della catena di localizzare il pagamento. SWIFT — Unique End-to-end Transaction Reference

26.4 Regola

Non utilizzare un identificativo isolato come prova dell’identità dell’autore.

Serve a identificare:

  • messaggio;
  • ordine;
  • transazione;
  • catena bancaria.

27. Bonifico ordinario e bonifico istantaneo

Elemento Ordinario Istantaneo
Esecuzione secondo tempi bancari normalmente in pochi secondi
Disponibilità giorni e orari previsti continuativa
Tempo di reazione potenzialmente maggiore molto ridotto
Richiamo dipende dallo stato particolarmente critico
Verifica beneficiario prevista prevista

27.1 Non promettere il richiamo

La richiesta di richiamo può fallire perché:

  • il pagamento è già regolato;
  • i fondi sono stati trasferiti;
  • il conto è vuoto;
  • l’intermediario necessita di ulteriori passaggi;
  • il beneficiario non collabora;
  • sono coinvolti paesi o schemi differenti.

“È stata richiesta l’attivazione delle procedure di recupero disponibili. L’esito dipende dallo stato del pagamento, dalla disponibilità delle somme e dagli intermediari coinvolti.”

28. Richiamo, blocco e recupero

Distinguere:

revoca:
annullamento prima dell’esecuzione, quando consentito;

richiamo:
richiesta successiva trasmessa nella catena del pagamento;

blocco:
limitazione dell’operatività del conto o dello strumento;

recupero:
restituzione effettiva, totale o parziale, delle somme.

Non utilizzare i termini come sinonimi.

Registro

Data richiesta:
Banca ordinante:
Banca beneficiaria:
Operazione:
Importo:
Procedura richiesta:
Codice pratica:
Risposta:
Somma bloccata:
Somma recuperata:
Stato:

29. Operazioni non autorizzate e disconoscimento

Quando la vittima non riconosce l’operazione:

[ ] identificare ogni transazione;
[ ] indicare importo e data;
[ ] dichiarare di non averla disposta;
[ ] bloccare lo strumento;
[ ] preservare notifiche;
[ ] acquisire login e dispositivi;
[ ] conservare comunicazioni;
[ ] formalizzare il disconoscimento;
[ ] conservare la risposta.

La Banca d’Italia ricorda che l’autenticazione, la registrazione e la contabilizzazione dell’operazione non esauriscono necessariamente ogni valutazione sulla responsabilità e che il cliente può chiedere il rimborso delle operazioni non autorizzate. Banca d’Italia — Operazioni di pagamento non autorizzate

30. Pagamento autorizzato sotto inganno

Esempio:

- il falso operatore chiama;
- la vittima apre l’app;
- inserisce il bonifico;
- approva l’operazione;
- il beneficiario è sconosciuto;
- l’azione è stata eseguita per “mettere al sicuro” il denaro.

Il dato tecnico può mostrare:

  • dispositivo noto;
  • autenticazione riuscita;
  • IP abituale;
  • OTP corretto;
  • operazione inserita dalla vittima.

Questo non esclude l’inganno.

La relazione dovrebbe distinguere:

dato tecnico:
l’ordine è stato inserito dal dispositivo;

dichiarazione:
la vittima riferisce di essere stata indotta dal chiamante;

valutazione:
la qualificazione del consenso e delle responsabilità esula
dall’accertamento tecnico.

31. Reclamo, ABF ed esposto

La sequenza orientativa è:

1. segnalazione o disconoscimento alla banca;
2. reclamo formale;
3. eventuale ricorso all’Arbitro Bancario Finanziario;
4. eventuale esposto alla Banca d’Italia;
5. iniziative giudiziarie valutate con il legale.

Prima del ricorso all’ABF è necessario presentare un reclamo all’intermediario. La Banca d’Italia indica inoltre che, in caso di mancata risposta o risposta insoddisfacente, il cliente può valutare ABF ed esposto secondo le rispettive procedure. Arbitro Bancario Finanziario

Il perito può predisporre:

  • cronologia;
  • tabella operazioni;
  • allegati;
  • hash;
  • relazione;
  • confronto tra dati;
  • descrizione dei dispositivi.

Non deve redigere valutazioni legali fuori dal proprio ambito.

32. Frodi su carte

Possibili eventi:

  • pagamento e-commerce;
  • contactless;
  • token wallet;
  • prelievo ATM;
  • carta virtuale;
  • abbonamento;
  • merchant non riconosciuto;
  • recurring payment.

32.1 Acquisire

- carta mascherata;
- circuito;
- emittente;
- merchant;
- merchant ID;
- data;
- importo;
- valuta;
- paese;
- metodo;
- autenticazione;
- 3-D Secure;
- wallet;
- notifica;
- stato;
- ricevuta.

32.2 Bloccare immediatamente

Le indicazioni istituzionali raccomandano di contattare subito l’emittente per bloccare la carta e presentare denuncia quando pertinente. Carabinieri — Bancomat e carte di credito

32.3 Non pubblicare

Nella relazione ordinaria oscurare:

  • numero completo;
  • CVV;
  • scadenza;
  • token;
  • PAN;
  • dati personali.

33. Chargeback e contestazioni del circuito

Il chargeback è una procedura collegata alle regole del circuito e al rapporto contrattuale.

Non coincide necessariamente con:

  • rimborso previsto dalla legge;
  • denuncia;
  • richiamo di un bonifico;
  • decisione dell’ABF.

Il perito può documentare:

  • ordine;
  • merce;
  • comunicazione;
  • mancata consegna;
  • tentativo di risoluzione;
  • ricevuta;
  • condizioni;
  • prove del merchant.

Non deve garantire l’accoglimento.

34. Software di accesso remoto

Il falso operatore può chiedere di installare:

  • AnyDesk;
  • TeamViewer;
  • RustDesk;
  • Quick Assist;
  • applicazioni simili.

34.1 Acquisire

- nome software;
- versione;
- data installazione;
- file;
- log;
- ID sessione;
- configurazione;
- processi;
- servizi;
- persistenza;
- cronologia;
- download;
- autorizzazioni.

34.2 Attenzione al dispositivo

Non utilizzare il dispositivo sospetto per:

  • cambiare password;
  • accedere alla banca;
  • creare nuove credenziali;
  • aprire il wallet.

Procedere con l’analisi forense del computer Windows o di macOS e Linux.

35. SIM swap e OTP

Indicatori:

  • perdita improvvisa del segnale;
  • SIM non attiva;
  • SMS non ricevuti;
  • modifica del contratto;
  • nuova eSIM;
  • telefonate dall’operatore;
  • recupero account;
  • bonifici successivi.

Acquisire:

- contratto telefonico;
- notifiche;
- orari;
- ticket operatore;
- ICCID disponibile;
- numero;
- cambio SIM;
- dati account;
- login;
- SMS.

La presenza di un OTP corretto non prova chi lo abbia materialmente ricevuto o inserito.

36. Truffe su marketplace

Possibili schemi:

  • bene inesistente;
  • falso acquirente;
  • link di pagamento;
  • falsa spedizione;
  • assicurazione richiesta;
  • pagamento esterno;
  • account rubato;
  • falso supporto.

Acquisire

[ ] annuncio;
[ ] URL;
[ ] profilo;
[ ] ID inserzione;
[ ] fotografie;
[ ] descrizione;
[ ] prezzo;
[ ] chat;
[ ] pagamento;
[ ] spedizione;
[ ] tracking;
[ ] feedback;
[ ] segnalazione.

La fotografia del bene può essere ricercata in altre inserzioni, ma la sua presenza altrove non identifica automaticamente l’autore.

37. Falso trading online

Lo schema può comprendere:

pubblicità
   ↓
contatto del consulente
   ↓
piccolo versamento
   ↓
dashboard con guadagni apparenti
   ↓
ulteriori investimenti
   ↓
richiesta di tasse o commissioni
   ↓
impossibilità di prelevare
   ↓
falso servizio di recupero

La Consob raccomanda di verificare che il soggetto sia autorizzato e pubblica avvisi e provvedimenti relativi a siti che offrono servizi finanziari abusivi. Consob — Oscuramenti e avvertenze

37.1 Acquisire

- sito;
- dominio;
- account;
- contratto;
- dashboard;
- saldo apparente;
- versamenti;
- IBAN;
- carte;
- wallet;
- chat;
- vocali;
- nominativi;
- documenti;
- richieste di prelievo;
- risposte.

37.2 Saldo apparente

Il valore mostrato nella dashboard può essere:

  • simulato;
  • modificato dal gestore;
  • privo di corrispondenza con reali operazioni;
  • espresso in unità inesistenti.

“Il saldo è quello rappresentato dall’interfaccia della piattaforma e non costituisce, da solo, prova dell’esistenza delle attività finanziarie indicate.”

38. Truffe in criptoattività

Possibili schemi:

  • investimento;
  • falsa piattaforma;
  • wallet compromesso;
  • token fraudolento;
  • phishing seed phrase;
  • giveaway;
  • mining inesistente;
  • romance scam;
  • recovery scam;
  • rug pull;
  • impersonificazione di exchange.

Le autorità europee ricordano che le criptoattività possono comportare rischi elevati e che le tutele possono essere limitate, in particolare quando il servizio è fornito da soggetti non autorizzati nell’Unione. ESMA — Rischi delle criptoattività

38.1 Non chiedere la seed phrase

Il perito deve acquisire:

  • indirizzi pubblici;
  • transaction hash;
  • rete;
  • token;
  • data;
  • importo;
  • exchange;
  • ricevute;
  • screenshot;
  • file wallet autorizzati, se strettamente necessario.

Non deve ricevere:

  • seed phrase;
  • chiave privata;
  • password del wallet;
  • codici MFA dell’exchange.

39. Analisi blockchain

39.1 Elementi da documentare

- blockchain;
- transaction hash;
- block height;
- timestamp;
- address mittente;
- address destinatario;
- asset;
- importo;
- fee;
- token contract;
- stato;
- transazioni successive;
- bridge;
- exchange apparente.

39.2 Limiti

Un indirizzo blockchain:

  • non identifica automaticamente una persona;
  • può essere custodial;
  • può appartenere a un exchange;
  • può essere condiviso;
  • può derivare da smart contract;
  • può essere etichettato erroneamente da servizi terzi.

39.3 Timestamp

Il timestamp del blocco documenta l’inclusione nella blockchain secondo il relativo protocollo.

Non prova:

  • momento esatto dell’ordine;
  • identità dell’utente;
  • posizione geografica;
  • legittimità.

39.4 Servizi di analisi

Le etichette “exchange”, “mixer”, “scam” o “gambling” devono essere indicate come:

“attribuzioni fornite dal database utilizzato”

e non come fatti autonomamente dimostrati.

40. Exchange centralizzato

Se il trasferimento raggiunge un exchange, possono esistere:

  • account;
  • KYC;
  • email;
  • IP;
  • dispositivi;
  • ordini;
  • prelievi;
  • wallet;
  • log.

Il perito privato non ottiene tali dati con accessi autonomi.

Può:

  • identificare il servizio apparente;
  • preservare la transazione;
  • predisporre un report;
  • supportare il legale;
  • analizzare i dati successivamente acquisiti in modo lecito.

41. Recovery scam

Dopo la prima frode, la vittima può essere contattata da:

  • falsa società investigativa;
  • falso studio legale;
  • falso exchange;
  • falso funzionario;
  • falso hacker;
  • presunta autorità.

Viene richiesto:

  • anticipo;
  • tassa;
  • assicurazione;
  • deposito;
  • sblocco;
  • costo notarile;
  • ulteriore investimento.

La Polizia Postale segnala che le vittime del falso trading possono essere ricontattate da soggetti che promettono il recupero delle somme. (Commissariato di P.S. online)

Regola:

Nessun professionista serio può garantire il recupero di fondi già trasferiti.

42. Romance scam

La relazione può svilupparsi per settimane o mesi.

Possibili richieste:

  • emergenza sanitaria;
  • viaggio;
  • dogana;
  • eredità;
  • investimento;
  • prestito;
  • criptoattività;
  • aiuto familiare.

Acquisire:

- profilo;
- fotografie;
- chat;
- vocali;
- video;
- email;
- numeri;
- pagamenti;
- documenti;
- account;
- timeline;
- richieste.

Non colpevolizzare la vittima.

“La sequenza mostra una progressiva costruzione del rapporto seguita dalle richieste economiche descritte.”

43. Falso operatore di banca o autorità

Il truffatore può dichiararsi:

  • banca;
  • Poste;
  • Polizia;
  • Banca d’Italia;
  • Agenzia delle Entrate;
  • avvocato;
  • tecnico antifrode;
  • exchange.

La Banca d’Italia pubblica periodicamente avvisi relativi all’uso indebito del proprio nome e raccomanda di non fornire dati, documenti o informazioni bancarie in risposta a tali comunicazioni. (Banca d’Italia)

Acquisire:

  • numero;
  • email;
  • logo;
  • documento;
  • dominio;
  • linguaggio;
  • pagamento richiesto;
  • coordinate;
  • file;
  • registrazione disponibile lecitamente.

44. Voice cloning e deepfake

La voce di un dirigente o familiare può essere simulata mediante sistemi di intelligenza artificiale.

Possibili indicatori:

  • richiesta atipica;
  • urgenza;
  • impossibilità di richiamare;
  • voce plausibile ma breve;
  • rumore;
  • mancato rispetto della procedura;
  • coordinate nuove;
  • richiesta di segretezza.

La verifica tecnica richiede:

  • file originale;
  • formato;
  • codec;
  • metadati;
  • provenienza;
  • confronto con campioni;
  • analisi spettrografica;
  • contesto;
  • account.

Approfondimenti:

Non affidarsi a un solo detector.

45. Acquisizione dello smartphone

Lo smartphone può contenere:

  • app bancaria;
  • notifiche;
  • SMS;
  • email;
  • WhatsApp;
  • registri chiamate;
  • browser;
  • QR;
  • software remoto;
  • autenticazione;
  • screenshot;
  • file;
  • wallet.

Approfondimenti:

Non disinstallare:

  • app bancaria;
  • app di autenticazione;
  • software remoto;
  • messaggistica;

prima del triage.

46. Acquisizione del computer

Verificare:

[ ] browser;
[ ] cronologia;
[ ] download;
[ ] email;
[ ] PDF;
[ ] malware;
[ ] software remoto;
[ ] estensioni;
[ ] password manager;
[ ] cookie;
[ ] sessioni;
[ ] file temporanei;
[ ] registri;
[ ] VPN.

Quando pertinente, procedere con una copia forense del supporto.

47. Malware e infostealer

Possibili indicatori:

  • processi anomali;
  • file scaricati;
  • persistenza;
  • estensioni sospette;
  • accessi ai browser;
  • archivi temporanei;
  • connessioni;
  • rilevazioni EDR;
  • furto di cookie.

Procedura:

1. isolare il dispositivo;
2. valutare l’acquisizione della memoria;
3. acquisire il disco;
4. raccogliere log EDR;
5. identificare il malware;
6. estrarre indicatori;
7. correlare la data con gli accessi;
8. cambiare le credenziali da dispositivo sicuro;
9. bonificare dopo la preservazione.

Approfondimento: Incident response forense e ransomware.

48. Messaggi e chat

Per WhatsApp acquisire:

  • dispositivo;
  • conversazione;
  • partecipanti;
  • numero;
  • timestamp;
  • allegati;
  • vocali;
  • messaggi citati;
  • modifiche;
  • cancellazioni;
  • database.

Vedere il Capitolo 8 — Perizia WhatsApp: messaggi, vocali e allegati.

Per Telegram e Signal: Telegram, Signal e app di messaggistica forensics.

Lo screenshot isolato non sostituisce l’acquisizione della conversazione.

49. Acquisizione del sito fraudolento

Procedura:

1. registrare URL;
2. annotare data e ora;
3. acquisire barra degli indirizzi;
4. registrare il percorso;
5. acquisire la pagina;
6. salvare HTML e header;
7. acquisire DNS e certificato;
8. scaricare le risorse pertinenti;
9. generare WARC, quando possibile;
10. calcolare gli hash;
11. non inserire credenziali;
12. non effettuare pagamenti di prova.

Approfondimento: Acquisizione di pagine web, social e contenuti online.

50. Codici QR

Un QR può contenere:

  • URL;
  • IBAN;
  • richiesta di pagamento;
  • wallet address;
  • testo;
  • contatto;
  • configurazione.

Acquisire:

- immagine originale;
- contesto;
- contenuto decodificato;
- hash;
- dominio;
- pagina risultante;
- data.

Non aprire il QR sul dispositivo utilizzato per l’home banking.

51. Caller ID spoofing

Documentare:

  • numero visualizzato;
  • data;
  • ora;
  • durata;
  • screenshot;
  • registro chiamate;
  • messaggi successivi;
  • contenuto riferito;
  • eventuale voicemail.

Il numero visualizzato identifica ciò che il dispositivo ha mostrato, non necessariamente la sorgente reale della chiamata.

“Il registro documenta una chiamata associata al numero visualizzato; tale informazione non consente autonomamente di verificare l’origine tecnica della comunicazione.”

52. Conti di transito e money mule

I fondi possono essere ricevuti da:

  • conto intestato a terzo;
  • carta;
  • conto aperto con documenti sottratti;
  • società;
  • exchange;
  • wallet;
  • prestatore inconsapevole.

La presenza del nome dell’intestatario non dimostra automaticamente che il soggetto abbia ideato la frode.

Le indagini possono distinguere:

  • autore;
  • beneficiario;
  • intestatario;
  • utilizzatore;
  • intermediario;
  • prestanome;
  • vittima di furto d’identità.

“Il conto beneficiario risulta intestato al soggetto indicato nei documenti disponibili. Tale dato non consente autonomamente di determinarne il ruolo nella vicenda.”

53. Ricostruire il flusso dei fondi

Esempio:

Conto azienda Roma
        │
        ├── € 38.500
        ↓
Conto beneficiario A
        │
        ├── € 12.000 → conto B
        ├── € 10.000 → carta C
        ├── € 9.500  → exchange D
        └── € 7.000  → prelievo / destinazione ignota

Per ogni passaggio indicare:

- fonte;
- data;
- identificativo;
- importo;
- stato;
- livello di certezza;
- limite.

Non rappresentare passaggi non documentati come certi.

54. Timeline forense

Data e ora Evento Fonte Attendibilità Note
10:02 email falsa EML elevata Reply-To differente
10:08 link aperto browser elevata dominio imitativo
10:14 login provider elevata IP esterno
10:18 regola email audit elevata messaggi nascosti
11:05 IBAN inviato email elevata nuovo beneficiario
11:40 bonifico banca elevata istantaneo
11:42 notifica smartphone elevata acquisita
11:50 banca contattata ticket elevata richiamo
14:30 denuncia verbale elevata allegato

Approfondimento: Timeline forense e ricostruzione cronologica degli eventi.

55. Matrice delle evidenze

Quesito Fonte Risultato Limite
Chi ha inviato l’email? header account apparente non prova persona
L’IBAN è cambiato? confronto PDF non identifica autore
Chi ha disposto il bonifico? log banca dispositivo cliente non esclude inganno
Quale IP? login log IP A può essere VPN
Pagamento eseguito? estratto conto non prova disponibilità attuale
VoP mostrato? screenshot no match non determina responsabilità
Sito falso? dominio imita marchio attribuzione da approfondire
Fondi recuperati? banca parzialmente stato temporaneo

56. Calcolo della perdita economica

Separare:

A. importo trasferito;
B. importo recuperato;
C. importo rimborsato;
D. commissioni;
E. variazioni di cambio;
F. ulteriori pagamenti;
G. costi documentati;
H. valore residuo contestato.

Formula:

perdita finanziaria tecnica provvisoria =
importi trasferiti
- importi effettivamente recuperati
- rimborsi già accreditati

Il perito informatico non sostituisce:

  • commercialista;
  • revisore;
  • consulente finanziario;
  • giudice;
  • esperto di valutazione del danno.

“L’importo è riportato a fini descrittivi sulla base dei movimenti acquisiti e non costituisce una quantificazione giuridica del danno.”

57. Caso pratico 1 — IBAN modificato in una fattura

Scenario

Un’azienda di Roma deve pagare 28.000 euro a un fornitore abituale.

Pochi giorni prima della scadenza riceve una fattura con un nuovo IBAN.

Risultati

- casella del fornitore compromessa;
- regola di inoltro;
- PDF modificato;
- IBAN estero;
- email proveniente dalla casella reale;
- bonifico ordinario;
- segnalazione effettuata dopo quattro ore.

Conclusione

“La sequenza è compatibile con una compromissione della casella del fornitore e con la successiva sostituzione delle coordinate bancarie. L’utilizzo della casella reale ha reso la comunicazione tecnicamente coerente con le precedenti, senza consentire al destinatario di individuare la frode attraverso il solo dominio.”

58. Caso pratico 2 — Falso operatore bancario

Scenario

Un cliente di Roma riceve una telefonata dal numero visualizzato della propria banca.

Gli viene chiesto di trasferire 7.500 euro su un “conto sicuro”.

Risultati

- numero visualizzato coincidente con quello della banca;
- bonifico inserito dalla vittima;
- MFA approvata;
- beneficiario sconosciuto;
- conto successivamente svuotato;
- nessun accesso esterno all’home banking rilevato.

Conclusione

“Il pagamento è stato materialmente disposto dal dispositivo del cliente e autenticato mediante il fattore previsto. La ricostruzione documenta tuttavia una comunicazione ingannevole precedente all’operazione. Il numero visualizzato non consente di stabilire l’origine reale della chiamata.”

59. Caso pratico 3 — Operazioni con carta non riconosciute

Scenario

Una cliente romana rileva cinque acquisti e-commerce mai effettuati.

Risultati

- carta ancora in possesso;
- merchant esteri;
- nessuna notifica 3-D Secure osservata;
- dati carta salvati in un browser compromesso;
- infostealer sul computer.

Conclusione

“Le operazioni non risultano riconosciute dalla titolare. Sul computer è stato rilevato un software compatibile con il furto di dati del browser. La correlazione temporale supporta l’ipotesi di compromissione, ma non consente di identificare il soggetto che ha utilizzato i dati.”

60. Caso pratico 4 — Falso marketplace

Scenario

Un privato di Roma paga 1.200 euro per uno scooter pubblicizzato online.

Risultati

  • profilo recente;
  • fotografie copiate;
  • bonifico verso carta-conto;
  • documento d’identità di terza persona;
  • annuncio rimosso;
  • bene mai spedito.

Conclusione

“Le fotografie e il documento risultano già associati ad altre pubblicazioni. Il conto beneficiario è intestato al nominativo indicato nei documenti bancari disponibili, ma tale dato non consente di stabilire il ruolo effettivo del soggetto nella frode.”

61. Caso pratico 5 — Falso trading

Scenario

Un professionista di Roma versa complessivamente 46.000 euro a una piattaforma di trading.

Risultati

- dashboard con saldo di 180.000 euro;
- operazioni non verificabili su mercati reali;
- società non presente negli elenchi consultati;
- versamenti verso più IBAN;
- richiesta finale di “tassa di sblocco”;
- contatto di un falso recuperatore.

Conclusione

“Il saldo indicato è rappresentato esclusivamente dall’interfaccia della piattaforma e non è stato possibile verificarne la corrispondenza con operazioni finanziarie reali. La richiesta di ulteriore denaro per consentire il prelievo è compatibile con la prosecuzione dello schema fraudolento.”

62. Caso pratico 6 — Truffa in criptoattività

Scenario

Una cliente di Roma trasferisce stablecoin verso un wallet indicato da un presunto consulente.

Risultati

- transazioni confermate;
- fondi divisi tra più address;
- parte trasferita a un exchange;
- etichette fornite da un servizio terzo;
- nessuna chiave privata acquisita;
- account social del consulente eliminato.

Conclusione

“Le transazioni risultano registrate sulla blockchain e mostrano i passaggi descritti. Le etichette attribuite agli indirizzi derivano dal servizio di analisi utilizzato e non consentono autonomamente di identificare i titolari.”

63. Caso pratico 7 — Deepfake del dirigente

Scenario

Il responsabile amministrativo di una società romana riceve una videochiamata apparentemente effettuata dall’amministratore delegato.

Risultati

- video non conservato nativamente;
- registrazione schermo;
- richiesta urgente;
- nuovo IBAN;
- account videoconferenza imitativo;
- voce e volto compatibili ma artefatti;
- procedura interna non rispettata.

Conclusione

“La registrazione presenta elementi compatibili con una sintesi o manipolazione audiovisiva. La qualità e la natura derivata del reperto non consentono una conclusione assoluta; l’ipotesi è supportata anche dall’account utilizzato e dalla deviazione dalle procedure aziendali.”

64. Caso pratico 8 — Falsa ricevuta di pagamento

Scenario

Un venditore di Roma riceve via email una ricevuta relativa a un bonifico di 15.000 euro.

Consegna il bene prima dell’accredito.

Risultati

  • PDF creato con software grafico;
  • identificativo inesistente;
  • nessun movimento;
  • banca indicata non riconosce il documento;
  • metadati successivi alla presunta operazione.

Conclusione

“Il PDF non trova riscontro nei movimenti del conto e presenta caratteristiche compatibili con una creazione grafica. Il documento non costituisce prova dell’esecuzione del pagamento.”

65. Caso pratico 9 — Casella aziendale condivisa

Scenario

Un’azienda romana sospetta un ex dipendente dopo un bonifico fraudolento.

Risultati

- password condivisa;
- nessuna MFA;
- accessi da VPN aziendale;
- account utilizzato da più addetti;
- log scaduti;
- fattura modificata.

Conclusione

“I dati disponibili documentano l’utilizzo della casella, ma la condivisione delle credenziali e l’assenza di tracciamento individuale impediscono di attribuire l’attività a uno specifico utilizzatore.”

66. Caso pratico 10 — Recovery scam

Scenario

Dopo aver perso 20.000 euro, un cliente di Roma viene contattato da una falsa società di recupero.

Risultati

  • conoscenza precisa della prima frode;
  • documenti con loghi di autorità;
  • richiesta di 3.000 euro;
  • dominio registrato di recente;
  • pagamento verso cripto wallet.

Conclusione

“La comunicazione utilizza informazioni relative alla precedente frode per costruire credibilità e richiede un ulteriore pagamento anticipato. Gli elementi sono compatibili con un tentativo di nuova vittimizzazione.”

67. Errori da evitare

Errore 1 — Attendere prima di contattare la banca

I fondi possono essere spostati.

Errore 2 — Usare il numero ricevuto dal chiamante

Può appartenere al truffatore.

Errore 3 — Cancellare la chat per vergogna

Si perde la prova.

Errore 4 — Formattare il computer

Si distruggono le tracce.

Errore 5 — Cambiare password dal dispositivo infetto

Le nuove credenziali possono essere sottratte.

Errore 6 — Confondere operazione autorizzata e non autorizzata

La ricostruzione tecnica cambia.

Errore 7 — Considerare il numero chiamante autentico

Può essere falsificato.

Errore 8 — Attribuire l’IBAN all’autore

L’intestatario può avere un ruolo differente.

Errore 9 — Considerare la ricevuta prova del pagamento

Può essere falsa.

Errore 10 — Non acquisire l’email originale

Si perdono gli header.

Errore 11 — Non controllare le regole della casella

Possono occultare le comunicazioni.

Errore 12 — Non confrontare le fatture

Si perde la modifica dell’IBAN.

Errore 13 — Limitarsi allo screenshot

Mancano metadati e contesto.

Errore 14 — Pubblicare i dati del conto beneficiario

Si espongono dati personali.

Errore 15 — Pagare un recuperatore improvvisato

Può trattarsi di una seconda truffa.

Errore 16 — Condividere seed phrase o chiavi

Si perde il controllo del wallet.

Errore 17 — Considerare una label blockchain come prova

È un’attribuzione di terzi.

Errore 18 — Confondere data ordine e data esecuzione

La timeline diventa errata.

Errore 19 — Ignorare il fuso orario

Gli eventi possono apparire invertiti.

Errore 20 — Non acquisire il dettaglio della transazione

Si perdono identificativi essenziali.

Errore 21 — Non registrare le chiamate alla banca

Si perde il ciclo di risposta.

Errore 22 — Non acquisire la schermata VoP

Si perde l’avviso mostrato al pagatore.

Errore 23 — Promettere il recupero

Nessun esito può essere garantito.

Errore 24 — Accedere all’account del sospetto

È un’attività non autorizzata.

Errore 25 — Usare un solo detector AI

L’esito non è conclusivo.

Errore 26 — Confondere IP e persona

L’IP identifica una connessione.

Errore 27 — Non coinvolgere il DPO

Una frode aziendale può comportare un data breach.

Errore 28 — Non preservare il sito

Può essere rimosso.

Errore 29 — Non verificare ulteriori addebiti

La compromissione può continuare.

Errore 30 — Scrivere conclusioni giuridiche

Il perito deve mantenere l’ambito tecnico.

68. Procedura operativa completa

Fase 1 — Emergenza

[ ] banca;
[ ] blocco;
[ ] richiamo;
[ ] carte;
[ ] account;
[ ] denuncia;
[ ] dispositivo sicuro.

Fase 2 — Incarico

[ ] committente;
[ ] autorizzazione;
[ ] quesito;
[ ] importi;
[ ] account;
[ ] strumenti;
[ ] periodo;
[ ] riservatezza.

Fase 3 — Triage

[ ] pagamento;
[ ] ricevuta;
[ ] email;
[ ] chat;
[ ] chiamate;
[ ] sito;
[ ] dispositivi;
[ ] account.

Fase 4 — Conservazione

[ ] originali;
[ ] copie;
[ ] hash;
[ ] catena custodia;
[ ] cifratura;
[ ] accessi.

Fase 5 — Pagamento

[ ] importo;
[ ] IBAN;
[ ] beneficiario;
[ ] data;
[ ] stato;
[ ] identificativi;
[ ] VoP;
[ ] richiamo.

Fase 6 — Comunicazioni

[ ] EML;
[ ] header;
[ ] chat;
[ ] vocali;
[ ] SMS;
[ ] chiamate;
[ ] allegati;
[ ] QR.

Fase 7 — Web

[ ] URL;
[ ] dominio;
[ ] DNS;
[ ] TLS;
[ ] WARC;
[ ] HTML;
[ ] profilo;
[ ] annuncio.

Fase 8 — Account

[ ] login;
[ ] sessioni;
[ ] dispositivi;
[ ] MFA;
[ ] OAuth;
[ ] regole;
[ ] inoltri;
[ ] recovery.

Fase 9 — Endpoint

[ ] smartphone;
[ ] computer;
[ ] browser;
[ ] malware;
[ ] software remoto;
[ ] notifiche;
[ ] file.

Fase 10 — Analisi

[ ] phishing;
[ ] spoofing;
[ ] BEC;
[ ] IBAN;
[ ] ricevuta;
[ ] autenticazione;
[ ] IP;
[ ] dispositivi;
[ ] cripto.

Fase 11 — Timeline

[ ] contatto;
[ ] accesso;
[ ] modifica;
[ ] ordine;
[ ] autenticazione;
[ ] esecuzione;
[ ] segnalazione;
[ ] recupero.

Fase 12 — Flusso economico

[ ] conto origine;
[ ] conto destinazione;
[ ] intermediari;
[ ] ulteriori trasferimenti;
[ ] importi;
[ ] stato;
[ ] recuperi.

Fase 13 — Relazione

[ ] materiale;
[ ] metodo;
[ ] risultati;
[ ] timeline;
[ ] flusso;
[ ] attribuzione;
[ ] limiti;
[ ] conclusioni;
[ ] allegati;
[ ] hash.

69. Checklist finale

Urgenza

[ ] banca contattata;
[ ] pratica aperta;
[ ] carte bloccate;
[ ] account protetti;
[ ] richiamo richiesto;
[ ] denuncia valutata;
[ ] azioni registrate.

Prova bancaria

[ ] ricevuta;
[ ] estratto conto;
[ ] identificativo;
[ ] IBAN;
[ ] beneficiario;
[ ] importo;
[ ] stato;
[ ] VoP;
[ ] ticket.

Comunicazioni

[ ] email originale;
[ ] header;
[ ] chat;
[ ] SMS;
[ ] chiamate;
[ ] allegati;
[ ] screenshot originali.

Dispositivi

[ ] smartphone;
[ ] computer;
[ ] browser;
[ ] software remoto;
[ ] malware;
[ ] notifiche;
[ ] account.

Analisi

[ ] timeline;
[ ] confronto fatture;
[ ] dominio;
[ ] IP;
[ ] login;
[ ] regole;
[ ] fondi;
[ ] limiti.

Relazione

[ ] fatti e deduzioni separati;
[ ] attribuzione prudente;
[ ] dati oscurati;
[ ] nessuna garanzia;
[ ] allegati verificabili;
[ ] hash.

70. Output minimo

1. incarico;
2. verbale;
3. registro reperti;
4. ricevuta del pagamento;
5. estratto conto;
6. identificativi della transazione;
7. schermata VoP;
8. ticket banca;
9. richiesta di richiamo;
10. reclamo;
11. email originali;
12. header;
13. chat;
14. registro chiamate;
15. sito acquisito;
16. DNS e TLS;
17. fatture e PDF;
18. confronto documenti;
19. acquisizione smartphone;
20. acquisizione computer;
21. log account;
22. indicatori malware;
23. transazioni blockchain;
24. timeline;
25. matrice evidenze;
26. grafo dei fondi;
27. tabella importi;
28. hash;
29. relazione;
30. allegati tecnici.

71. Struttura della relazione tecnica

71.1 Incarico

  • committente;
  • quesito;
  • autorizzazione;
  • periodo;
  • limiti.

71.2 Materiale

  • pagamenti;
  • account;
  • email;
  • chat;
  • dispositivi;
  • siti;
  • file;
  • hash.

71.3 Metodo

  • acquisizione;
  • strumenti;
  • versioni;
  • conservazione;
  • normalizzazione temporale.

71.4 Risultati

  • comunicazione;
  • autenticazione;
  • beneficiario;
  • pagamento;
  • account;
  • dispositivi;
  • dominio;
  • file.

71.5 Timeline

  • contatto;
  • manipolazione;
  • accesso;
  • ordine;
  • esecuzione;
  • segnalazione;
  • contenimento.

71.6 Flusso dei fondi

  • origine;
  • destinazione;
  • passaggi;
  • recuperi;
  • limiti.

71.7 Attribuzione

  • account;
  • IP;
  • dispositivi;
  • intestatari;
  • alternative;
  • limiti.

71.8 Conclusioni

Risposte tecniche proporzionate al quesito.

72. Modelli di frasi tecniche

72.1 Operazione non riconosciuta

“Il titolare ha dichiarato di non aver disposto né autorizzato l’operazione indicata. L’accertamento documenta i dati tecnici disponibili e non comprende la decisione sul diritto al rimborso.”

72.2 Operazione indotta

“Il pagamento risulta materialmente inserito dal dispositivo del cliente, in un contesto che il medesimo riferisce essere stato determinato dalle comunicazioni ingannevoli acquisite.”

72.3 Bonifico istantaneo

“L’operazione risulta eseguita mediante bonifico istantaneo. La rapidità del regolamento ha ridotto il tempo disponibile per l’intervento prima dell’accredito.”

72.4 Richiamo

“La banca ha attivato la procedura di richiamo indicata. L’attivazione non implica l’effettivo recupero delle somme.”

72.5 IBAN modificato

“Il documento contestato contiene coordinate bancarie differenti rispetto alla versione acquisita dal fornitore.”

72.6 Casella compromessa

“Sono stati rilevati eventi compatibili con un accesso non autorizzato alla casella e con la successiva manipolazione della corrispondenza.”

72.7 Dominio imitativo

“Il dominio presenta caratteristiche grafiche e lessicali simili a quello legittimo, ma costituisce un dominio distinto.”

72.8 Caller ID

“Il numero visualizzato non consente autonomamente di verificare l’origine reale della chiamata.”

72.9 Autenticazione

“Il sistema registra il completamento dell’autenticazione prevista. Tale dato non dimostra chi abbia materialmente controllato il dispositivo o determinato la volontà dell’utente.”

72.10 VoP

“Il servizio di verifica del beneficiario ha restituito l’esito indicato. Tale esito non costituisce una verifica complessiva della legittimità economica del pagamento.”

72.11 Ricevuta

“Il PDF rappresenta una ricevuta apparente, la cui corrispondenza con un’operazione effettivamente eseguita deve essere verificata presso il prestatore di pagamento.”

72.12 IP

“L’indirizzo IP identifica una connessione o infrastruttura e non consente, da solo, di identificare la persona fisica.”

72.13 Conto beneficiario

“L’intestazione del conto non consente autonomamente di determinare il ruolo del titolare nella frode.”

72.14 Criptoattività

“La transazione risulta registrata sulla blockchain. L’indirizzo destinatario non identifica automaticamente il relativo controllore.”

72.15 Label blockchain

“L’attribuzione dell’indirizzo al servizio indicato deriva dal database utilizzato e deve essere considerata un’informazione di fonte terza.”

72.16 Falso trading

“Il saldo rappresentato dalla piattaforma non è stato verificato attraverso evidenze indipendenti di effettive operazioni finanziarie.”

72.17 Deepfake

“Sono stati rilevati elementi compatibili con una manipolazione sintetica, senza che il solo reperto disponibile consenta una conclusione assoluta.”

72.18 Recupero

“L’attività tecnica non consente di garantire il recupero totale o parziale delle somme trasferite.”

72.19 Assenza di log

“L’assenza dell’evento nei log disponibili non dimostra necessariamente che l’attività non sia mai avvenuta.”

72.20 Limite generale

“Le conclusioni sono formulate nei limiti dei dati acquisiti, delle fonti accessibili e dei periodi di conservazione applicabili.”

73. Immagini e figure suggerite

Figura 1 — Anatomia di una truffa finanziaria

Descrizione: contatto, inganno, pagamento, trasferimento e occultamento.
Alt: Sequenza tecnica di una truffa online con pagamento fraudolento.

Figura 2 — Operazione non autorizzata e operazione indotta

Descrizione: confronto tra furto delle credenziali e pagamento eseguito dalla vittima.
Alt: Differenza tecnica tra pagamento non autorizzato e pagamento sotto inganno.

Figura 3 — Business Email Compromise

Descrizione: casella compromessa, fattura e nuovo IBAN.
Alt: Flusso di una frode BEC con sostituzione dell’IBAN.

Figura 4 — Header email

Descrizione: From, Reply-To, Received, DKIM e dominio.
Alt: Elementi da analizzare in una falsa email bancaria.

Figura 5 — Verifica del beneficiario

Descrizione: match, close match e no match.
Alt: Esiti del servizio Verification of Payee.

Figura 6 — Timeline del pagamento

Descrizione: email, login, fattura, bonifico e segnalazione.
Alt: Timeline forense di un bonifico fraudolento.

Figura 7 — Caller ID spoofing

Descrizione: numero reale, rete telefonica e numero visualizzato.
Alt: Perché il numero visualizzato non dimostra l’origine della chiamata.

Figura 8 — Flusso dei fondi

Descrizione: conto origine, conti di transito, exchange e prelievo.
Alt: Ricostruzione grafica del percorso di fondi sottratti.

Figura 9 — Ricevuta vera e falsa

Descrizione: identificativo, portale, metadati e riscontro contabile.
Alt: Confronto forense tra ricevuta bancaria autentica e contraffatta.

Figura 10 — Truffa di trading

Descrizione: pubblicità, deposito, saldo apparente e tassa di sblocco.
Alt: Sequenza di una truffa di falso trading online.

Figura 11 — Analisi blockchain

Descrizione: transaction hash, address, blocco e trasferimenti.
Alt: Elementi tecnici di una transazione in criptoattività.

Figura 12 — Matrice delle evidenze

Descrizione: quesito, fonte, risultato e limite.
Alt: Matrice tecnica delle prove in una truffa finanziaria online.

74. Riferimenti tecnici e normativi esterni

  1. Articolo 640 del codice penale — Truffa.
  2. Articolo 640-ter del codice penale — Frode informatica.
  3. Articolo 493-ter del codice penale — Strumenti di pagamento diversi dal contante.
  4. Decreto legislativo n. 11/2010 — Servizi di pagamento e operazioni non autorizzate.
  5. Banca d’Italia — Truffe nei pagamenti e cybersicurezza.
  6. Banca d’Italia — Operazioni di pagamento non autorizzate.
  7. Banca d’Italia — Cosa fare se si è vittima di truffe o frodi.
  8. Arbitro Bancario Finanziario — Procedura di ricorso.
  9. Regolamento UE 2024/886 — Bonifici istantanei e verifica del beneficiario.
  10. Banca Centrale Europea — Instant Payments Regulation e Verification of Payee.
  11. Europol — Business Email Compromise e frodi online.
  12. Consob — Avvertenze su trading e siti abusivi.
  13. ESMA — Rischi e tutele limitate per determinate criptoattività.
  14. Polizia Postale — Segnalazioni e denunce di reati informatici.
  15. SWIFT — Unique End-to-end Transaction Reference.
Nota metodologica: procedure bancarie, interfacce, strumenti di pagamento, schemi di messaggistica, tempi di conservazione e regole dei circuiti possono cambiare. Nella relazione devono essere indicate la data della verifica, la fonte consultata e gli output effettivamente acquisiti.

75. Collegamenti interni consigliati

Capitolo precedente

Capitolo successivo

Capitoli correlati

76. Pagine servizio consigliate

Anchor text consigliati

perizia per truffa online a Roma
analisi di un bonifico fraudolento
verifica di una falsa fattura
analisi tecnica della sostituzione IBAN
perizia Business Email Compromise
acquisizione di email bancarie fraudolente
analisi di phishing e vishing
verifica di una ricevuta di pagamento
analisi di un falso sito di trading
ricostruzione di transazioni in criptovalute
analisi di carte e pagamenti non riconosciuti
consulente informatico forense per frodi finanziarie

77. Box commerciale finale

Hai subito una truffa online o un bonifico fraudolento a Roma?

Lo Studio Quaranta Digital Forensics può supportare privati, aziende, professionisti e studi legali nell’acquisizione e nell’analisi tecnica di:

[ ] bonifici fraudolenti;
[ ] Business Email Compromise;
[ ] fatture con IBAN modificato;
[ ] false ricevute bancarie;
[ ] phishing;
[ ] smishing;
[ ] vishing;
[ ] caller ID spoofing;
[ ] carte utilizzate senza consenso;
[ ] falsi marketplace;
[ ] falso trading;
[ ] truffe in criptoattività;
[ ] romance scam;
[ ] recovery scam;
[ ] voice cloning e deepfake.

L’attività può comprendere:

  • acquisizione delle comunicazioni;
  • analisi email e header;
  • confronto tra fatture;
  • analisi di PDF e ricevute;
  • acquisizione di smartphone e computer;
  • verifica di account compromessi;
  • analisi di siti e domini;
  • ricostruzione temporale;
  • documentazione degli identificativi bancari;
  • analisi tecnica delle transazioni blockchain;
  • matrice delle evidenze;
  • relazione tecnica;
  • supporto al legale e al CTP.

Richiedi una valutazione preliminare

Descrivi il pagamento, l’importo, il canale utilizzato e quando è avvenuto. La prima valutazione serve a definire le priorità di contenimento e quali reperti preservare senza alterazioni.

Avvertenza: contatta immediatamente la banca mediante un recapito ufficiale e conserva ogni email, chat, ricevuta e notifica. Lo Studio non garantisce il recupero delle somme e non sostituisce l’avvocato, la banca o l’autorità competente.

78. Conclusione del capitolo

Una truffa finanziaria digitale non si ricostruisce partendo soltanto dall’importo sottratto.

Occorre analizzare l’intera catena:

contatto
→ manipolazione
→ account
→ dispositivo
→ autenticazione
→ pagamento
→ beneficiario
→ trasferimenti successivi
→ contenimento
→ recupero

La corretta attività deve distinguere:

  • operazione non riconosciuta;
  • pagamento disposto sotto inganno;
  • casella compromessa;
  • dominio imitativo;
  • fattura alterata;
  • ricevuta falsa;
  • conto beneficiario;
  • persona fisica;
  • indirizzo blockchain;
  • titolare effettivo.

Il dato bancario identifica una transazione; il dato informatico descrive account, dispositivi e comunicazioni; soltanto la loro correlazione può ricostruire il meccanismo della frode, senza garantire l’identificazione dell’autore o il recupero dei fondi.

La tempestività resta essenziale:

contenere
→ preservare
→ acquisire
→ correlare
→ documentare
→ riferire

79. Anticipazione del capitolo successivo

Capitolo 20 — Analisi di log aziendali, firewall, VPN e sistemi cloud

Saranno trattati:

  • log Windows e Linux;
  • firewall;
  • VPN;
  • proxy;
  • DNS;
  • DHCP;
  • Active Directory;
  • Microsoft Entra ID;
  • Google Workspace;
  • EDR;
  • SIEM;
  • applicazioni cloud;
  • sincronizzazione temporale;
  • normalizzazione dei formati;
  • identificazione degli IP;
  • correlazione degli eventi;
  • retention;
  • integrità dei log;
  • timeline aziendale;
  • limiti dell’attribuzione di un evento a una persona fisica.

Continua con il Capitolo 20 — Analisi di log aziendali, firewall, VPN e sistemi cloud →