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:
- chi ha materialmente disposto l’operazione;
- attraverso quale account e dispositivo;
- se il pagamento fosse riconosciuto o non riconosciuto dal titolare;
- se la vittima sia stata indotta a eseguire personalmente il trasferimento;
- se sia stata compromessa una casella email;
- se siano stati alterati fatture, PDF o coordinate bancarie;
- se siano state utilizzate sessioni, token o applicazioni remote;
- quale identificativo abbia la transazione;
- quali intermediari siano coinvolti;
- quali dati possano essere ancora preservati;
- quali elementi siano utili per un’eventuale attribuzione;
- 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 | 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:
- nel corpo dell’email;
- in un PDF;
- in un documento Office;
- mediante immagine sovrapposta;
- in una risposta da dominio simile;
- attraverso una casella compromessa;
- tramite messaggio WhatsApp;
- 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 | 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 | sì | 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 | sì | 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
Descrizione: contatto, inganno, pagamento, trasferimento e occultamento.
Alt: Sequenza tecnica di una truffa online con pagamento fraudolento.
Descrizione: confronto tra furto delle credenziali e pagamento eseguito dalla vittima.
Alt: Differenza tecnica tra pagamento non autorizzato e pagamento sotto inganno.
Descrizione: casella compromessa, fattura e nuovo IBAN.
Alt: Flusso di una frode BEC con sostituzione dell’IBAN.
Descrizione: From, Reply-To, Received, DKIM e dominio.
Alt: Elementi da analizzare in una falsa email bancaria.
Descrizione: match, close match e no match.
Alt: Esiti del servizio Verification of Payee.
Descrizione: email, login, fattura, bonifico e segnalazione.
Alt: Timeline forense di un bonifico fraudolento.
Descrizione: numero reale, rete telefonica e numero visualizzato.
Alt: Perché il numero visualizzato non dimostra l’origine della chiamata.
Descrizione: conto origine, conti di transito, exchange e prelievo.
Alt: Ricostruzione grafica del percorso di fondi sottratti.
Descrizione: identificativo, portale, metadati e riscontro contabile.
Alt: Confronto forense tra ricevuta bancaria autentica e contraffatta.
Descrizione: pubblicità, deposito, saldo apparente e tassa di sblocco.
Alt: Sequenza di una truffa di falso trading online.
Descrizione: transaction hash, address, blocco e trasferimenti.
Alt: Elementi tecnici di una transazione in criptoattività.
Descrizione: quesito, fonte, risultato e limite.
Alt: Matrice tecnica delle prove in una truffa finanziaria online.
74. Riferimenti tecnici e normativi esterni
- Articolo 640 del codice penale — Truffa.
- Articolo 640-ter del codice penale — Frode informatica.
- Articolo 493-ter del codice penale — Strumenti di pagamento diversi dal contante.
- Decreto legislativo n. 11/2010 — Servizi di pagamento e operazioni non autorizzate.
- Banca d’Italia — Truffe nei pagamenti e cybersicurezza.
- Banca d’Italia — Operazioni di pagamento non autorizzate.
- Banca d’Italia — Cosa fare se si è vittima di truffe o frodi.
- Arbitro Bancario Finanziario — Procedura di ricorso.
- Regolamento UE 2024/886 — Bonifici istantanei e verifica del beneficiario.
- Banca Centrale Europea — Instant Payments Regulation e Verification of Payee.
- Europol — Business Email Compromise e frodi online.
- Consob — Avvertenze su trading e siti abusivi.
- ESMA — Rischi e tutele limitate per determinate criptoattività.
- Polizia Postale — Segnalazioni e denunce di reati informatici.
- SWIFT — Unique End-to-end Transaction Reference.
75. Collegamenti interni consigliati
Capitolo precedente
Capitolo successivo
Capitoli correlati
- Triage iniziale della prova digitale a Roma
- Catena di custodia, hash e verbale tecnico
- Copia forense di hard disk, SSD, pendrive e NAS
- Analisi forense di computer Windows
- Analisi forense di macOS e Linux
- Acquisizione forense di smartphone Android
- Acquisizione forense di iPhone e iPad iOS
- Perizia WhatsApp: messaggi, vocali e allegati
- Telegram, Signal e app di messaggistica forensics
- Recupero dati cancellati per fini probatori
- Analisi forense di email e header
- PEC, ricevute, allegati e prova digitale
- PDF, firme digitali e marche temporali
- Metadati, EXIF, XMP, C2PA e provenienza dei file
- Verifica forense di screenshot e schermate
- Acquisizione di pagine web, social e contenuti online
- Diffamazione online, cyberbullismo, stalking digitale e revenge porn
- Incident response forense e ransomware
- Dipendente infedele, sottrazione dati e uso di USB
- Cloud forensics: Google, Microsoft, Dropbox e backup
- Autenticità audio: tagli, montaggi e ricodifiche
- Voice cloning e audio generati con intelligenza artificiale
- Autenticità video: frame, codec, tagli e montaggi
- Analisi video deepfake e face swapping
- Immagini, fotografie manipolate e contenuti generati con AI
- Timeline forense e ricostruzione cronologica degli eventi
- Relazione tecnica, CTP informatico e contestazione delle prove digitali
76. Pagine servizio consigliate
- Perizia informatica forense a Roma
- Analisi di email, PEC e documenti digitali
- Analisi di smartphone e computer
- Acquisizione di pagine web e social
- Consulente tecnico di parte informatico a Roma
- Contatti
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.
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 →
