Dipendente infedele, sottrazione dati e uso di USB

Introduzione

Un’azienda può sospettare che un dipendente, un ex dipendente, un collaboratore, un amministratore di sistema o un consulente esterno abbia:

• copiato documenti riservati su una chiavetta USB;
• scaricato file da SharePoint, OneDrive o Google Drive;
• inviato allegati a un indirizzo email personale;
• creato archivi ZIP o 7z prima delle dimissioni;
• sincronizzato cartelle aziendali con un cloud personale;
• trasferito sorgenti software verso un repository esterno;
• esportato clienti, contatti o ordini da un gestionale;
• stampato documenti;
• utilizzato un telefono collegato via USB;
• cancellato file, cronologie o log per ridurre le tracce;
• continuato ad accedere ai sistemi dopo la cessazione del rapporto.

L’espressione “dipendente infedele” è frequentemente utilizzata nelle richieste aziendali e nelle ricerche online, ma non rappresenta una conclusione tecnica.

Il perito informatico non dovrebbe partire dall’assunto che il dipendente abbia commesso un illecito.

Deve invece verificare:

1. quali sistemi e account fossero assegnati al soggetto;
2. quali attività siano state effettivamente registrate;
3. se un dispositivo rimovibile sia stato collegato;
4. se un volume sia stato montato e con quale lettera;
5. quali file risultino presenti, aperti, selezionati, copiati o cancellati;
6. se esista una copia su un supporto, in un cloud o in una casella esterna;
7. quale account e quale sessione risultino associati all’attività;
8. se l’operazione fosse prevista dalle mansioni o da una procedura autorizzata;
9. quali dati siano effettivamente riservati;
10. se siano state adottate misure organizzative per mantenerli segreti;
11. quali limiti impediscano l’attribuzione personale o la ricostruzione completa.

Il collegamento di una pendrive a un computer aziendale non dimostra, da solo, che siano stati copiati documenti.

L’apertura di una cartella non dimostra che tutti i file contenuti siano stati letti.

Un evento di accesso a un file non dimostra necessariamente che la copia sia stata completata.

La presenza sul dispositivo esterno di un file identico a quello aziendale costituisce un elemento più significativo, ma non dimostra automaticamente:

• chi lo abbia copiato;
• quando sia avvenuta la prima copia;
• per quale finalità;
• se il soggetto fosse autorizzato;
• se il documento sia stato successivamente utilizzato o divulgato.

Analogamente, un download registrato da SharePoint documenta un’azione associata a un account e a una sessione, ma non identifica automaticamente la persona fisica che controllava le credenziali.

L’indagine deve evitare due errori opposti:

errore accusatorio:
considerare ogni anomalia come prova di sottrazione;

errore riduttivo:
considerare inutile una traccia soltanto perché non è conclusiva da sola.

La corretta perizia informatica aziendale costruisce una ricostruzione mediante la convergenza di:

• file system;
• registro di Windows;
• log dei dispositivi;
• eventi di sicurezza;
• artefatti utente;
• email;
• cloud;
• EDR e DLP;
• firewall e proxy;
• account;
• dispositivi fisici;
• autorizzazioni;
• procedure aziendali;
• contesto organizzativo.

Sintesi operativa

1. formalizzare incarico, quesito e autorizzazioni;
2. coinvolgere legale, HR, DPO e responsabile IT;
3. evitare conclusioni anticipate sul dipendente;
4. verificare se esiste un rischio attivo di ulteriore sottrazione;
5. preservare account, computer, mailbox, cloud e log;
6. documentare ogni misura di contenimento;
7. non cancellare o riconfigurare l’account prima della raccolta;
8. acquisire il computer aziendale con metodo proporzionato;
9. identificare supporti USB e dispositivi portatili;
10. acquisire il supporto esterno, quando disponibile e autorizzato;
11. conservare formato nativo, immagini forensi e hash;
12. analizzare USBSTOR, SetupAPI, MountedDevices e profili utente;
13. verificare eventi PnP, removable storage, EDR e DLP;
14. correlare dispositivo, volume, lettera, utente e intervallo;
15. analizzare MFT, USN Journal, LNK, Jump List e MRU;
16. cercare archivi, cartelle di staging e file temporanei;
17. confrontare file mediante hash e metadati;
18. acquisire email, webmail, browser e servizi cloud;
19. analizzare SharePoint, OneDrive, Google Drive e Dropbox;
20. verificare messaggistica, stampa, screenshot e accessi remoti;
21. costruire una timeline in UTC e ora locale;
22. distinguere attività osservata, deduzione e dichiarazione;
23. valutare mansioni, autorizzazioni e procedure;
24. minimizzare i dati personali non pertinenti;
25. formulare conclusioni proporzionate alle fonti disponibili;
26. indicare sempre lacune e ipotesi alternative;
27. produrre una relazione tecnica riproducibile;
28. conservare gli originali separatamente dalle copie di lavoro.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente:

• su dispositivi di proprietà o legittima disponibilità dell’azienda;
• su account aziendali amministrati legittimamente;
• con un incarico formalizzato;
• con un perimetro definito;
• nel rispetto delle norme applicabili;
• nel rispetto delle informative e delle policy;
• con raccolta proporzionata alla finalità;
• con il coordinamento dei soggetti responsabili.

Non è lecito utilizzare questo capitolo per:

• entrare nell’email personale del dipendente;
• tentare password;
• accedere a cloud privati senza autorizzazione;
• utilizzare cookie o token sottratti;
• installare keylogger;
• installare spyware;
• attivare webcam o microfono;
• creare profili falsi per indurre il dipendente a compiere azioni;
• intercettare comunicazioni private;
• acquisire un telefono personale senza consenso o provvedimento;
• proseguire l’accesso dopo la revoca dell’autorizzazione;
• effettuare una raccolta indiscriminata su tutti i lavoratori.

Il perito informatico non decide:

• se il dipendente debba essere licenziato;
• se una condotta sia disciplinarmente rilevante;
• se esista concorrenza sleale;
• se un’informazione costituisca giuridicamente un segreto commerciale;
• se sia configurabile un reato;
• quale sanzione applicare;
• quale danno economico riconoscere.

Queste valutazioni competono ai soggetti e alle autorità titolari dei rispettivi ruoli.

2. Perché “dipendente infedele” non è una conclusione tecnica

L’espressione viene utilizzata come sintesi operativa, ma può creare un pregiudizio.

Un dipendente può aver copiato file per ragioni legittime:

• lavoro da remoto autorizzato;
• backup;
• trasferimento verso un sistema aziendale;
• consegna a un cliente;
• migrazione;
• attività di supporto;
• utilizzo di una procedura precedente;
• incarico del responsabile;
• necessità di stampa;
• uso di dispositivi ammessi dalla policy.

La stessa attività tecnica può assumere significati diversi.

Esempio:

copia di 2.000 file su USB

può essere:

• una sottrazione;
• un backup autorizzato;
• una consegna;
• una migrazione;
• una raccolta richiesta dal management;
• un errore di sincronizzazione.

Il perito deve pertanto utilizzare formule come:

E non:

La seconda frase introduce una qualificazione personale e giuridica che può non essere supportata dal solo dato tecnico.

3. Inquadramento giuridico e organizzativo essenziale

3.1 Obbligo di fedeltà

L’articolo 2105 del codice civile disciplina l’obbligo di fedeltà del prestatore di lavoro, comprendendo il divieto di trattare affari in concorrenza con l’imprenditore e di divulgare o utilizzare informazioni aziendali in modo pregiudizievole. L’applicazione concreta deve essere valutata dal legale in relazione a mansioni, contratto, policy e fatti documentati. Normattiva — Codice civile, articolo 2105

3.2 Controlli e strumenti di lavoro

L’articolo 4 dello Statuto dei lavoratori distingue gli impianti dai quali possa derivare un controllo a distanza dagli strumenti utilizzati dal lavoratore per rendere la prestazione e dagli strumenti di registrazione degli accessi e delle presenze. L’utilizzabilità delle informazioni raccolte richiede comunque adeguata informazione al lavoratore e rispetto della disciplina sulla protezione dei dati personali. Normattiva — Statuto dei lavoratori

Il fatto che un log sia tecnicamente disponibile non significa quindi che possa essere raccolto e utilizzato senza:

• finalità;
• perimetro;
• trasparenza;
• proporzionalità;
• verifica delle policy;
• confronto con il legale.

3.3 Metadati della posta elettronica

Nel documento di indirizzo del 6 giugno 2024, il Garante ha chiarito che la conservazione ordinaria dei metadati necessari al funzionamento della posta elettronica dovrebbe essere limitata a pochi giorni, indicativamente non oltre ventuno, salvo particolari condizioni documentate. Una conservazione generalizzata più estesa può richiedere le garanzie previste dall’articolo 4, primo comma, dello Statuto dei lavoratori. Il termine orientativo non deve essere interpretato come una durata obbligatoria universale per ogni tipo di log. Garante privacy — metadati della posta elettronica

Anche nel 2026 il Garante ha ribadito che le finalità di sicurezza non eliminano la necessità di:

• determinare una durata proporzionata;
• informare correttamente gli interessati;
• rispettare lo Statuto dei lavoratori;
• documentare le scelte organizzative.

Garante privacy — logging, retention e controlli nel lavoro

3.4 Principi GDPR

L’indagine deve rispettare, tra gli altri:

• liceità;
• correttezza;
• trasparenza;
• limitazione della finalità;
• minimizzazione;
• esattezza;
• limitazione della conservazione;
• sicurezza;
• responsabilizzazione.

La raccolta non dovrebbe essere ampliata “nel caso possa servire”. Deve essere motivata dal quesito e dal rischio concreto. Regolamento UE 2016/679

4. Segreti commerciali e informazioni riservate

Non ogni file aziendale costituisce automaticamente un segreto commerciale.

La disciplina del Codice della proprietà industriale tutela le informazioni aziendali e le esperienze tecnico-industriali che:

1. siano segrete;
2. abbiano valore economico in quanto segrete;
3. siano sottoposte a misure ragionevolmente adeguate a mantenerle segrete.

L’analisi tecnica può documentare le misure adottate, ma la qualificazione giuridica resta affidata al legale e al giudice. Ministero della Giustizia — segreti commerciali

4.1 Misure da verificare

[ ] classificazione documentale;
[ ] cartelle riservate;
[ ] autorizzazioni individuali;
[ ] gruppi Active Directory;
[ ] autenticazione;
[ ] MFA;
[ ] cifratura;
[ ] DLP;
[ ] controllo USB;
[ ] restrizioni di condivisione;
[ ] accordi di riservatezza;
[ ] policy;
[ ] formazione;
[ ] logging;
[ ] watermark;
[ ] tracciamento download;
[ ] procedure di offboarding.

4.2 Perché queste misure sono importanti

Se un file era:

• pubblicamente disponibile;
• accessibile a tutti senza restrizioni;
• mai classificato;
• liberamente condivisibile;
• privo di una gestione riservata;

la valutazione del suo carattere segreto può essere differente da quella relativa a un documento protetto mediante controlli tecnici e organizzativi.

Il perito può scrivere:

Non dovrebbe scrivere:

5. Le domande tecniche corrette

Una richiesta generica come:

deve essere trasformata in quesiti verificabili.

Esempi:

- identificare i dispositivi USB collegati al computer;
- determinare quali volumi risultino montati;
- ricostruire l’intervallo temporale di utilizzo;
- verificare artefatti compatibili con l’accesso a determinati file;
- verificare la presenza di copie su un supporto acquisito;
- confrontare file aziendali e file esterni mediante hash;
- individuare archivi creati prima delle dimissioni;
- verificare download da SharePoint o Google Drive;
- verificare invii verso email esterne;
- verificare upload mediante browser;
- ricostruire l’utilizzo di applicazioni cloud;
- indicare i limiti dell’attribuzione personale.

6. Scala dei livelli probatori

Livello 1 — Dispositivo rilevato

Il sistema conserva tracce compatibili con la presenza di un dispositivo.

Non dimostra:

• che sia stato montato correttamente;
• che sia stato aperto;
• che siano stati copiati file;
• chi lo abbia collegato.

Livello 2 — Volume montato

Il dispositivo risulta associato a:

• volume;
• GUID;
• lettera;
• file system;
• sessione utente.

Non dimostra ancora una copia.

Livello 3 — Navigazione o accesso

Artefatti indicano che una cartella o un file risultano selezionati, aperti o richiamati.

Non dimostrano necessariamente una copia.

Livello 4 — Operazione di lettura o scrittura

Un audit o un prodotto EDR/DLP registra un’operazione sul file.

Il valore dipende da:

• configurazione;
• evento;
• esito;
• oggetto;
• applicazione;
• completamento.

Livello 5 — Evidenza di copia

Più artefatti risultano coerenti con una copia:

sorgente
+ destinazione
+ intervallo temporale
+ nome
+ dimensione
+ hash
+ attività utente

Livello 6 — Copia presente sul supporto

Il file viene acquisito sul dispositivo esterno ed è:

• identico;
• derivato;
• rinominato;
• compresso;
• modificato.

Livello 7 — Trasferimento fuori dal perimetro

La copia viene osservata in:

• email esterna;
• cloud personale;
• servizio di condivisione;
• repository;
• messaggistica;
• altro sistema.

Livello 8 — Attribuzione personale

Richiede correlazione con:

• account individuale;
• MFA;
• dispositivo assegnato;
• accesso fisico;
• orario;
• attività;
• dichiarazioni;
• assenza di condivisione delle credenziali.

Livello 9 — Utilizzo e rilevanza

La copia può essere stata:

• utilizzata da un concorrente;
• pubblicata;
• impiegata per contattare clienti;
• conservata senza ulteriore attività.

Questa fase può richiedere ulteriori accertamenti e valutazioni non informatiche.

7. Tabella di interpretazione

8. Scenari tipici

8.1 Dimissioni imminenti

Il dipendente:

• crea archivi;
• scarica cartelle;
• collega USB;
• usa cloud personale;
• invia email;
• cancella dati.

8.2 Cessazione già avvenuta

L’azienda scopre l’anomalia dopo:

• disattivazione dell’account;
• restituzione del computer;
• sostituzione del dispositivo;
• cancellazione della mailbox;
• scadenza dei log.

8.3 Collaboratore esterno

Il consulente utilizza:

• computer personale;
• VPN;
• cloud condiviso;
• repository;
• account del cliente.

8.4 Amministratore di sistema

Dispone di:

• privilegi;
• accesso ai log;
• capacità di cancellazione;
• backup;
• account condivisi.

8.5 Supporto USB rinvenuto

Il dispositivo può contenere:

• file identici;
• versioni precedenti;
• archivi;
• file cancellati;
• metadati;
• documenti di altre fonti.

8.6 Nessun supporto disponibile

La ricostruzione deve basarsi su:

• computer;
• log;
• artefatti utente;
• EDR;
• DLP;
• cloud;
• email;
• rete.

9. Volatilità delle prove

Possibili perdite:

• sovrascrittura dei log;
• eliminazione della mailbox;
• scadenza dei cloud audit;
• rotazione dell’USN Journal;
• pulizia del profilo;
• reinstallazione del computer;
• riutilizzo della pendrive;
• modifica dei timestamp;
• cancellazione del browser;
• chiusura dell’account personale;
• riassegnazione del dispositivo.

Ordine orientativo

1. account ancora attivi;
2. log cloud prossimi alla scadenza;
3. EDR/DLP;
4. computer acceso;
5. sessioni e dati volatili;
6. email e browser;
7. file system;
8. USB disponibile;
9. backup;
10. archivi storici.

L’ordine deve essere adattato al rischio e al perimetro.

10. Protocollo dei primi trenta minuti

1. nominare un responsabile;
2. aprire un registro del caso;
3. verificare l’autorizzazione;
4. identificare il computer e gli account;
5. impedire modifiche non coordinate;
6. verificare se il rischio è ancora attivo;
7. preservare account e mailbox;
8. esportare i log prossimi alla scadenza;
9. documentare eventuali dispositivi collegati;
10. verificare cloud e condivisioni;
11. acquisire l’ora locale e UTC;
12. proteggere il computer da nuovi utilizzi;
13. evitare la riconsegna immediata ad altro utente;
14. preservare ticket, autorizzazioni e mansioni;
15. coinvolgere legale, HR e DPO.

11. Protocollo delle prime ventiquattro ore

[ ] formalizzare il quesito;
[ ] identificare tutti gli asset assegnati;
[ ] preservare account Active Directory e cloud;
[ ] acquisire computer e smartphone aziendali;
[ ] acquisire mailbox;
[ ] esportare SharePoint, OneDrive e Google Drive audit;
[ ] esportare DLP, EDR e SIEM;
[ ] acquisire firewall, proxy e VPN;
[ ] identificare supporti USB;
[ ] preservare eventuali pendrive disponibili;
[ ] acquisire inventario e assegnazioni;
[ ] verificare account condivisi;
[ ] costruire la prima timeline;
[ ] acquisire policy e informative;
[ ] verificare procedura di offboarding;
[ ] individuare i dati riservati interessati;
[ ] impedire l’eliminazione automatica degli elementi pertinenti;
[ ] registrare ogni intervento.

12. Cosa non fare

[ ] non interrogare il dipendente prima di preservare i reperti;
[ ] non utilizzare il computer per normali attività;
[ ] non aprire ripetutamente i documenti contestati;
[ ] non collegare la pendrive senza protezione da scrittura;
[ ] non montare il supporto in lettura-scrittura;
[ ] non cancellare l’account prima dell’export;
[ ] non eliminare regole email o app senza documentarle;
[ ] non cambiare i timestamp dei file;
[ ] non chiedere password personali;
[ ] non accedere al cloud privato senza autorizzazione;
[ ] non installare spyware;
[ ] non attivare controlli retroattivi inesistenti;
[ ] non creare prove mediante copie di test sul reperto;
[ ] non considerare il solo USBSTOR prova di sottrazione;
[ ] non accusare una persona sulla base del solo username;
[ ] non pubblicare documenti o dati personali.

13. Questionario iniziale

13.1 Rapporto e mansioni

1. Qual era il ruolo del soggetto?
2. Quali dati poteva utilizzare?
3. Quali strumenti erano assegnati?
4. Esisteva lavoro da remoto?
5. Erano consentiti i supporti USB?
6. Era consentito il cloud personale?
7. Era consentito inviare file a clienti?
8. Esisteva una procedura di backup?
9. Chi autorizzava le esportazioni?
10. Le credenziali erano individuali?

13.2 Evento sospetto

1. Quando è nato il sospetto?
2. Quale attività è stata osservata?
3. Quali file risultano coinvolti?
4. È disponibile il supporto?
5. Esiste un alert DLP?
6. Esiste un audit cloud?
7. Sono stati creati archivi?
8. Sono state inviate email?
9. Vi sono accessi dopo la cessazione?
10. Vi sono clienti contattati?

13.3 Azioni già compiute

Chiedere se l’azienda ha:

• bloccato l’account;
• cambiato password;
• cancellato la mailbox;
• formattato il computer;
• aperto i file;
• collegato la pendrive;
• interrogato il dipendente;
• modificato policy;
• esportato log;
• reinstallato agent;
• consegnato il dispositivo a un altro utente.

14. Matrice delle autorizzazioni

15. Mappa delle fonti

15.1 Computer

• file system;
• registro;
• eventi;
• browser;
• email;
• cloud client;
• LNK;
• Jump List;
• MRU;
• Prefetch;
• Amcache;
• USN Journal;
• MFT;
• EDR.

15.2 Supporti

• pendrive;
• dischi USB;
• schede SD;
• telefoni;
• fotocamere;
• masterizzatori;
• NAS portatili.

15.3 Cloud

• OneDrive;
• SharePoint;
• Google Drive;
• Dropbox;
• Box;
• repository;
• file sharing.

15.4 Comunicazioni

• email;
• webmail;
• Teams;
• Slack;
• WhatsApp;
• Telegram;
• Signal;
• SMS.

15.5 Rete e sicurezza

• proxy;
• firewall;
• DNS;
• VPN;
• SIEM;
• EDR;
• DLP;
• CASB.

15.6 Organizzazione

• mansioni;
• autorizzazioni;
• policy;
• inventario;
• offboarding;
• ticket;
• turni;
• accessi fisici.

16. Cartella del caso

CASO_RM_2026_022/
├── 00_incarico/
├── 01_verbali/
├── 02_policy_informative/
├── 03_inventario_asset/
├── 04_computer_originale/
├── 05_immagini_forensi/
├── 06_usb_originali/
├── 07_usb_immagini/
├── 08_registry/
├── 09_event_logs/
├── 10_file_system/
├── 11_lnk_jumplist_mru/
├── 12_browser/
├── 13_email/
├── 14_cloud/
├── 15_edr_dlp/
├── 16_firewall_proxy/
├── 17_hash/
├── 18_confronti_file/
├── 19_timeline/
├── 20_matrici/
├── 21_output_strumenti/
├── 22_report/
└── 23_relazione/

17. Registro dei reperti

18. Catena di custodia

Per ogni reperto registrare:

- identificativo;
- descrizione;
- produttore;
- modello;
- seriale;
- fonte;
- soggetto consegnante;
- data e ora;
- fuso;
- stato;
- metodo;
- strumento;
- versione;
- hash;
- posizione;
- copie;
- accessi;
- trasferimenti;
- anomalie.

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

19. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\USB001.E01"

Linux

sha256sum -- USB001.E01

macOS

shasum -a 256 -- USB001.E01

Per confrontare due file:

Get-FileHash -Algorithm SHA256 `
  ".\sorgente\clienti.xlsx"

Get-FileHash -Algorithm SHA256 `
  ".\usb\clienti.xlsx"

Hash coincidenti indicano identità bit per bit tra le due copie esaminate.

Non dimostrano:

• chi abbia effettuato la copia;
• quale sia la copia più antica;
• quando sia avvenuto il primo trasferimento;
• la finalità;
• l’autorizzazione.

20. Data, ora e sincronizzazione

Registrare:

- ora del computer;
- ora UTC;
- timezone;
- fonte NTP;
- scarto;
- ora del cloud;
- ora EDR;
- ora del supporto;
- data dell’acquisizione.

PowerShell

Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"

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

w32tm /query /status

Non confondere:

data file sorgente
≠
data creazione copia
≠
data ultima modifica
≠
data accesso
≠
data del record forense
≠
data acquisizione

21. Preservazione e contenimento

L’azienda può aver bisogno di:

• bloccare l’account;
• revocare sessioni;
• impedire ulteriori download;
• disconnettere il dispositivo;
• modificare le autorizzazioni;
• disattivare un link.

Queste azioni possono alterare le evidenze.

Non sono scorrette se necessarie, ma devono essere documentate.

Esempio:

09:05 — alert DLP
09:08 — screenshot dell’evento
09:12 — export audit
09:18 — sessione revocata
09:21 — account disabilitato
09:32 — computer ritirato

22. Piano di acquisizione

Priorità A

• computer assegnato;
• USB rinvenuto;
• account cloud;
• mailbox;
• DLP/EDR;
• log prossimi alla scadenza.

Priorità B

• smartphone aziendale;
• firewall;
• proxy;
• VPN;
• repository;
• NAS;
• file server.

Priorità C

• backup;
• inventario;
• ticket;
• badge;
• sistemi secondari.

Per ogni fonte decidere:

- acquisizione completa;
- raccolta mirata;
- export;
- screenshot di supporto;
- conservazione amministrativa;
- esclusione motivata.

23. Acquisizione del computer aziendale

23.1 Computer spento

Privilegiare, quando tecnicamente e operativamente opportuno:

• acquisizione bitstream;
• write blocker;
• immagine E01 o RAW;
• hash;
• fotografia;
• seriale;
• verbale.

Vedere il Capitolo 3 — Copia forense di hard disk, SSD, pendrive e NAS.

23.2 Computer acceso

Valutare:

• cifratura;
• sessioni;
• processi;
• volumi montati;
• cloud sincronizzato;
• dispositivi collegati;
• memoria;
• rischio di spegnimento.

L’analisi forense di computer Windows deve essere adattata al quesito aziendale.

23.3 Computer già riutilizzato

Documentare:

• nuova assegnazione;
• accessi successivi;
• aggiornamenti;
• pulizia;
• attività del nuovo utente.

24. Immagine completa o raccolta mirata

Immagine completa

Preferibile quando:

• si sospetta cancellazione;
• esistono più canali;
• occorre ricostruire una timeline;
• sono presenti file cancellati;
• il computer è disponibile.

Raccolta mirata

Può essere necessaria quando:

• il sistema è critico;
• non può essere spento;
• il volume è molto elevato;
• il quesito è ristretto;
• i tempi sono limitati.

Raccolta minima orientativa

- registro;
- EVTX;
- MFT;
- USN Journal;
- $LogFile;
- LNK;
- Jump List;
- browser;
- email;
- cloud client;
- Prefetch;
- Amcache;
- SRUM;
- SetupAPI;
- EDR;
- file contestati.

La raccolta mirata deve dichiarare ciò che non è stato acquisito.

25. Acquisizione del supporto USB

25.1 Documentazione fisica

[ ] fotografie;
[ ] marca;
[ ] modello;
[ ] capacità;
[ ] colore;
[ ] seriale visibile;
[ ] connettore;
[ ] etichetta;
[ ] stato;
[ ] confezione.

25.2 Protezione da scrittura

Utilizzare, quando tecnicamente compatibile:

• write blocker hardware;
• ambiente forense;
• mount in sola lettura;
• supporto di destinazione controllato.

25.3 Immagine

Acquisire:

• intero supporto;
• partizioni;
• spazio non allocato;
• file system;
• file cancellati;
• slack space, quando pertinente.

25.4 File cifrato o protetto

Non tentare password non autorizzate.

Documentare:

• formato;
• volume;
• stato;
• richiesta credenziali;
• informazioni disponibili.

26. File system del supporto

Possibili file system:

• FAT32;
• exFAT;
• NTFS;
• APFS;
• HFS+;
• ext;
• file system proprietari.

La capacità di ricostruire:

• file cancellati;
• timeline;
• journal;
• permessi;
• metadati;

dipende dal file system.

Esempio:

NTFS:
MFT, USN Journal, attributi avanzati;

FAT/exFAT:
struttura più semplice e minori metadati;

APFS:
snapshot, container e metadati specifici.

27. Tracce USB in Windows: quadro generale

Le principali fonti comprendono:

- HKLM\SYSTEM\...\Enum\USB;
- HKLM\SYSTEM\...\Enum\USBSTOR;
- MountedDevices;
- MountPoints2;
- SetupAPI.dev.log;
- Event Log PnP;
- DriverFrameworks;
- Security Log;
- Defender Device Control;
- Endpoint DLP;
- EDR;
- LNK;
- Jump List;
- ShellBags;
- file system.

Nessuna fonte dovrebbe essere interpretata isolatamente.

28. Identificatori del dispositivo

28.1 VID e PID

Indicano generalmente:

• produttore;
• famiglia o modello.

Non identificano necessariamente il singolo esemplare.

28.2 Numero seriale

Può:

• identificare il singolo dispositivo;
• essere assente;
• essere generico;
• essere duplicato;
• essere esposto in forme differenti;
• essere simulato dal firmware.

28.3 Device Instance ID

Identifica l’istanza secondo Windows.

Può includere:

USBSTOR\DISK&VEN_...\SERIALE&0

28.4 Volume serial e GUID

Sono associati al volume o file system, non necessariamente all’hardware fisico.

28.5 Regola

Non confondere:

seriale hardware
≠
device instance
≠
volume serial
≠
volume GUID
≠
lettera di unità

29. Registro Enum\USB ed Enum\USBSTOR

Windows mantiene informazioni sui dispositivi nell’area:

HKLM\SYSTEM\CurrentControlSet\Enum

Enum\USBSTOR è particolarmente rilevante per i dispositivi di archiviazione USB. Il ramo Enum\USB può contenere informazioni sui dispositivi USB, incluse periferiche composite. Microsoft documenta Enum come area usata dal sistema Plug and Play per le informazioni sui dispositivi e avverte che la struttura interna può variare nel tempo. Microsoft — HKLM SYSTEM CurrentControlSet Enum

29.1 Dati utili

• vendor;
• product;
• revision;
• seriale;
• friendly name;
• parent;
• container ID;
• service;
• driver;
• proprietà.

29.2 Limiti

Una voce indica che il sistema ha conosciuto il dispositivo.

Non dimostra:

• ogni collegamento;
• la lettera assegnata in ogni sessione;
• la copia di file;
• l’identità dell’utente.

29.3 ControlSet

In un hive offline possono essere presenti:

ControlSet001
ControlSet002

La chiave Select contribuisce a individuare il control set attivo nel sistema acquisito.

30. SetupAPI.dev.log

Il file:

C:\Windows\INF\setupapi.dev.log

registra attività di installazione e configurazione dei dispositivi e può contenere:

• device instance;
• driver;
• data;
• sezione di installazione;
• esito;
• percorso INF.

Microsoft indica SetupAPI.dev.log come il registro relativo all’installazione di dispositivi nelle versioni moderne di Windows. Microsoft — SetupAPI Device Installation Log

30.1 Limite fondamentale

SetupAPI è spesso utile per documentare la prima configurazione o un’installazione.

Non deve essere automaticamente interpretato come un registro completo di ogni inserimento successivo.

31. MountedDevices

La chiave:

HKLM\SYSTEM\MountedDevices

conserva associazioni persistenti gestite dal Mount Manager tra:

• volumi;
• identificatori;
• lettere;
• mount point.

Microsoft descrive MountedDevices come il database persistente utilizzato dal Mount Manager per le associazioni tra volumi e nomi di montaggio. Microsoft — Mount Manager

31.1 Utilità

Può contribuire a collegare:

dispositivo
→ volume
→ GUID
→ lettera

31.2 Limiti

• la lettera può cambiare;
• un volume può essere montato su più sistemi;
• le associazioni possono persistere dopo la rimozione;
• il dato non identifica automaticamente l’utente.

32. MountPoints2

Nel profilo dell’utente:

HKCU\Software\Microsoft\Windows\
CurrentVersion\Explorer\MountPoints2

possono essere presenti riferimenti a:

• volumi rimovibili;
• condivisioni;
• mount point;
• identificatori.

32.1 Utilità

Può supportare la correlazione tra:

• profilo utente;
• volume;
• interazione con Explorer;
• intervallo.

32.2 Limite

Non dimostra automaticamente:

• copia;
• apertura di ogni file;
• presenza fisica dell’utente.

La chiave deve essere acquisita dal relativo NTUSER.DAT e interpretata nel contesto del profilo.

33. Eventi Plug and Play

Possibili fonti:

- System;
- Kernel-PnP;
- DeviceSetupManager;
- DriverFrameworks-UserMode;
- UserPnp;
- Partition;
- Storage-ClassPnP.

Canali ed Event ID possono variare in base a:

• versione Windows;
• driver;
• tipo di dispositivo;
• configurazione;
• retention.

La procedura corretta è:

1. acquisire il canale nativo;
2. mantenere il record raw;
3. identificare provider ed Event ID;
4. leggere i campi;
5. correlare col device instance;
6. confrontare con registro e SetupAPI.

Non utilizzare un singolo Event ID come regola universale per ogni versione di Windows.

34. Audit Removable Storage

Windows può essere configurato per registrare accessi a oggetti presenti su supporti rimovibili.

La documentazione Microsoft indica che, quando la policy Audit Removable Storage è attiva:

• l’evento 4663 può documentare accessi riusciti;
• l’evento 4656 può documentare richieste fallite;
• gli eventi dipendono dall’auditing configurato e non vengono creati retroattivamente.

Microsoft — Audit Removable Storage

34.1 Dati utili

- account;
- object name;
- access mask;
- processo;
- Logon ID;
- timestamp;
- esito.

34.2 Interpretazione

Un evento 4663 può indicare una lettura o scrittura autorizzata dal sistema.

Non dimostra automaticamente:

• che l’intero file sia stato copiato;
• dove sia stato copiato;
• che la persona fosse davanti al computer;
• che l’operazione non fosse legittima.

35. Defender Device Control ed Endpoint DLP

Microsoft Defender Device Control può:

• limitare lettura, scrittura ed esecuzione;
• applicare policy per gruppi di dispositivi;
• produrre eventi di audit;
• supportare ricerche tramite advanced hunting.

Microsoft Purview Endpoint DLP può inoltre monitorare attività su file sensibili, dispositivi rimovibili, browser e servizi supportati, in funzione di licenza, configurazione e policy. Microsoft — Device Control

35.1 Possibili eventi

• montaggio USB;
• smontaggio;
• operazione consentita;
• operazione bloccata;
• copia su supporto;
• evidenza del file;
• classificazione;
• policy applicata.

35.2 Limiti

• la funzione deve essere configurata;
• la telemetria può avere retention limitata;
• i nomi dei campi possono cambiare;
• non ogni dispositivo è gestito allo stesso modo;
• un evento DLP non stabilisce l’intenzione.

36. Modello di correlazione USB

La forza dell’ipotesi aumenta quando fonti indipendenti convergono.

37. Problema della data di collegamento

Diverse fonti hanno significati differenti.

Non scrivere:

Meglio:

38. Telefoni e dispositivi MTP

Uno smartphone collegato via USB può essere esposto come:

• dispositivo portatile;
• MTP;
• PTP;
• interfaccia composita;
• tethering;
• archivio, in specifici casi.

Può non apparire come un normale disco USB con lettera.

Le copie possono avvenire attraverso:

• Esplora file;
• applicazioni del produttore;
• sincronizzazione;
• software fotografico;
• client cloud.

L’assenza di una voce USBSTOR non esclude quindi il collegamento di un telefono.

Occorre analizzare:

• PnP;
• WPD;
• registry;
• SetupAPI;
• shell;
• LNK;
• file system;
• eventi dell’applicazione.

39. Tracce USB su macOS

macOS può fornire informazioni mediante:

• System Information;
• system_profiler;
• diskutil;
• Unified Log;
• /Volumes;
• Finder;
• FSEvents;
• file recenti;
• metadati del file system.

Apple indica che System Information mostra l’hardware installato o collegato e le principali caratteristiche del sistema. Apple — System Information

39.1 Comandi di triage

date "+%Y-%m-%dT%H:%M:%S%z"
date -u "+%Y-%m-%dT%H:%M:%SZ"

system_profiler SPUSBDataType \
  > usb-system-report.txt

diskutil list \
  > diskutil-list.txt

39.2 Unified Log

log show \
  --style json \
  --start "2026-07-01 00:00:00" \
  --end   "2026-07-11 00:00:00" \
  > unified-log.json

Il sistema di Unified Logging centralizza numerosi eventi, ma la disponibilità effettiva dipende da categoria, persistenza, livello e retention. Apple Developer — Logging

40. Tracce USB su Linux

Fonti possibili:

• kernel log;
• journald;
• udev;
• auditd;
• mount;
• shell;
• file manager;
• cronologia;
• file system.

40.1 Comandi di triage

date --iso-8601=ns
date -u --iso-8601=ns

lsusb -v > lsusb.txt

lsblk \
  -o NAME,SERIAL,MODEL,TRAN,FSTYPE,LABEL,UUID,MOUNTPOINTS \
  > lsblk.txt

journalctl \
  --utc \
  --since "2026-07-01 00:00:00" \
  --output short-iso-precise \
  --no-pager \
  > journal-usb.txt

Per un dispositivo già identificato:

udevadm info \
  --query=all \
  --name=/dev/sdX \
  > udev-device.txt

Sostituire /dev/sdX soltanto dopo aver identificato correttamente il dispositivo.

Non montare in scrittura il reperto.

41. Che cosa significa “copia di un file”

Una copia può avvenire mediante:

• Explorer;
• comando;
• applicazione;
• sincronizzazione;
• drag and drop;
• backup;
• script;
• browser;
• email;
• API.

Per dimostrarla tecnicamente è utile combinare:

sorgente presente
+ destinazione disponibile
+ contenuto coerente
+ timestamp compatibili
+ attività del file system
+ artefatti utente
+ sessione
+ contesto

L’evidenza più forte è spesso:

Resta comunque necessario valutare chi controllasse la sessione e se l’operazione fosse autorizzata.

42. Master File Table

La $MFT di NTFS conserva record relativi a file e directory.

Può contenere:

• nomi;
• parent directory;
• identificativi;
• dimensioni;
• attributi;
• timestamp;
• stato allocato o cancellato;
• resident data, in specifici casi.

42.1 Utilità

• individuare file;
• ricostruire directory;
• verificare archivi;
• datare creazioni;
• identificare cancellazioni;
• correlare file ID.

42.2 Limiti

La MFT non documenta direttamente:

• chi abbia copiato il file;
• la destinazione esterna;
• l’intenzione;
• ogni accesso.

43. USN Change Journal

Il journal NTFS registra variazioni apportate a file e directory sul volume.

Microsoft descrive il change journal come una registrazione persistente delle modifiche a file e directory di un volume NTFS, associata ai relativi identificativi. Microsoft — USN Change Journal

Possibili reason code:

• file create;
• data extend;
• data overwrite;
• rename;
• close;
• delete.

43.1 Utilità

Può contribuire a ricostruire:

creazione archivio
→ aumento dimensione
→ chiusura
→ rinomina
→ cancellazione

43.2 Limiti

Il journal:

• è per volume;
• può ruotare;
• non conserva il contenuto;
• non identifica automaticamente l’utente;
• non indica sempre l’applicazione;
• non documenta la destinazione di una copia esterna.

44. $LogFile

$LogFile supporta le transazioni dei metadati NTFS.

Può contenere dati recenti utili a:

• ricostruire operazioni;
• confermare creazioni;
• individuare modifiche;
• correlare rinomine e cancellazioni.

È una fonte:

• complessa;
• circolare;
• soggetta a sovrascrittura;
• dipendente dal parser.

Non dovrebbe essere interpretata senza confrontarla con:

• MFT;
• USN;
• directory;
• timeline;
• artefatti utente.

45. Timestamp e semantica della copia

Una copia può produrre timestamp differenti a seconda di:

• sistema operativo;
• file system;
• applicazione;
• protocollo;
• tool;
• cloud;
• preservazione dei metadati.

Spesso una copia tramite Explorer:

• assegna una nuova data di creazione alla destinazione;
• conserva la data di ultima modifica del contenuto.

Non è una regola assoluta.

Programmi di sincronizzazione e copia possono:

• preservare la creazione;
• modificare tutti i timestamp;
• usare UTC o ora locale;
• riscrivere i metadati.

46. File LNK

I collegamenti .lnk possono essere creati quando un file viene aperto o richiamato mediante determinate funzioni di Windows.

Possono contenere:

• percorso;
• nome file;
• volume;
• seriale volume;
• lettera;
• MAC address, in alcuni casi;
• timestamp;
• dimensione;
• informazioni della destinazione.

46.1 Utilità

Un LNK può collegare:

profilo utente
→ file
→ percorso su E:
→ volume serial
→ intervallo temporale

46.2 Limiti

Un LNK non dimostra automaticamente:

• che il file sia stato copiato;
• che sia stato letto integralmente;
• che l’utente abbia avuto intenzione di sottrarlo.

LECmd consente di analizzare file LNK e prevede anche un’opzione per limitare la ricerca ai collegamenti relativi a unità rimovibili. LECmd — GitHub

47. Jump List

Le Jump List conservano riferimenti ai documenti recenti o frequenti utilizzati dalle applicazioni.

Possono contribuire a ricostruire:

• applicazione;
• file;
• percorso;
• ordine;
• frequenza;
• volume.

JLECmd è uno strumento dedicato all’analisi delle Jump List AutomaticDestinations e CustomDestinations. JLECmd — GitHub

Limiti

Una voce indica una relazione tra applicazione e file.

Non dimostra:

• copia;
• destinazione;
• divulgazione;
• attività illegittima.

48. ShellBags

Gli ShellBags possono conservare informazioni relative alle cartelle visualizzate da Explorer.

Possono contribuire a documentare:

• navigazione;
• cartelle su volumi non più collegati;
• struttura;
• ordinamento e visualizzazione.

Non dimostrano automaticamente:

• accesso a ogni file;
• copia;
• lettura del contenuto;
• trasferimento esterno.

49. RecentDocs e MRU

Possibili artefatti:

RecentDocs
OpenSavePidlMRU
LastVisitedPidlMRU
TypedPaths
ComDlg32
Office MRU
Adobe recent files

Possono indicare:

• file selezionato;
• finestra di apertura o salvataggio;
• percorso recente;
• applicazione.

La presenza deve essere interpretata in relazione:

• all’app;
• al profilo;
• al timestamp;
• al percorso;
• ad altri artefatti.

50. Prefetch, Amcache e Shimcache

50.1 Prefetch

Può documentare l’esecuzione di applicazioni su sistemi configurati per produrlo.

Esempi:

• 7ZG.EXE;
• ROBOCOPY.EXE;
• client cloud;
• browser;
• tool di cancellazione.

50.2 Amcache

Può conservare informazioni su file eseguibili osservati dal sistema.

50.3 Shimcache

Può contribuire alla ricostruzione della presenza o esecuzione di programmi, ma la semantica varia tra versioni Windows.

50.4 Limite comune

Questi artefatti non dimostrano automaticamente:

• quale documento sia stato copiato;
• l’uso illecito;
• la persona fisica.

51. SRUM

SRUM può contenere dati relativi all’uso di risorse e rete da parte delle applicazioni.

Può contribuire a:

• individuare applicazioni attive;
• stimare utilizzo di rete;
• correlare periodi;
• verificare client cloud o browser.

Non identifica necessariamente:

• file specifici;
• destinazione remota esatta;
• contenuto trasferito.

52. Cestino e cancellazioni

Analizzare:

• $Recycle.Bin;
• file $I;
• file $R;
• cancellazioni dirette;
• Shift+Delete;
• file system journal;
• spazio non allocato.

Un file cancellato dal computer può indicare:

• pulizia;
• normale gestione;
• errore;
• tentativo di ridurre le tracce.

La finalità non si deduce dalla cancellazione isolata.

53. Archivi ZIP, 7z e RAR

La creazione di un archivio può essere una fase di staging.

Cercare:

• archivi recenti;
• file temporanei;
• directory di lavoro;
• Prefetch;
• Jump List;
• MRU;
• command line;
• USN;
• MFT;
• upload successivo.

53.1 Dati da acquisire

- nome;
- hash;
- contenuto;
- commento;
- password richiesta;
- timestamp;
- percorso;
- applicazione;
- file sorgenti compatibili.

Un archivio può essere legittimo.

La rilevanza aumenta se:

archivio creato
+ dati riservati
+ dimissioni imminenti
+ upload o USB
+ cancellazione successiva

54. Confronto mediante hash

54.1 Hash identico

Supporta l’identità binaria.

54.2 Hash differente

Non esclude la derivazione.

Il file può essere stato:

• rinominato;
• modificato;
• esportato;
• compresso;
• convertito;
• salvato nuovamente;
• privato dei metadati.

54.3 Confronti ulteriori

• dimensione;
• contenuto;
• struttura;
• fogli Excel;
• testo;
• record;
• metadati;
• identificatori;
• immagini;
• righe.

55. Nomi, versioni e metadati

Confrontare:

clienti.xlsx
clienti_finale.xlsx
clienti_aggiornato.xlsx
clienti_export_2026.xlsx

Verificare:

• autore dichiarato;
• ultimo autore;
• revisioni;
• applicazione;
• creazione;
• modifica;
• template;
• proprietà custom;
• ID documentali.

Il Capitolo 14 — Metadati, EXIF, XMP, C2PA e provenienza dei file approfondisce limiti e interpretazione.

56. Email aziendale

Acquisire preferibilmente:

• mailbox;
• EML;
• MSG;
• header;
• allegati;
• posta inviata;
• eliminati;
• regole;
• inoltri;
• deleghe;
• audit.

Cercare:

• destinatari esterni;
• indirizzi personali;
• allegati;
• link cloud;
• archivi;
• bozze;
• messaggi eliminati;
• inoltro automatico.

La procedura completa è descritta nel Capitolo 11 — Analisi forense di email e header.

57. Webmail personale

L’uso di una webmail può lasciare tracce nel computer aziendale:

• cronologia;
• cache;
• download;
• upload;
• cookie;
• storage;
• notifiche;
• DNS;
• proxy;
• DLP.

Il perito può acquisire tali artefatti dal dispositivo aziendale autorizzato.

Non può entrare nella casella personale utilizzando:

• password salvate;
• cookie;
• sessioni;
• token;

senza una specifica autorizzazione o titolo legittimo.

58. OneDrive e SharePoint

Possibili fonti:

• Purview Audit;
• client OneDrive;
• registry;
• log di sincronizzazione;
• browser;
• file system;
• link;
• condivisioni;
• version history;
• Defender for Cloud Apps;
• DLP.

Le attività di audit Microsoft possono includere eventi quali:

• FileDownloaded;
• FileSyncDownloadedFull;
• FileUploaded;
• FileSyncUploadedFull;
• FileCopied;
• FolderCopied;
• modifiche di condivisione.

Disponibilità, dettaglio e retention dipendono da licenza e configurazione. Microsoft — Audit log activities

58.1 Distinguere

download browser
≠
sincronizzazione client
≠
copia interna SharePoint
≠
condivisione esterna
≠
accesso anonimo

58.2 Limite

Un evento associato all’account non identifica automaticamente la persona fisica.

59. Google Drive e Workspace

Possibili fonti:

• Drive audit;
• login audit;
• token OAuth;
• browser;
• Drive for desktop;
• file system;
• condivisioni;
• download;
• upload;
• modifica permessi.

Google Workspace mette a disposizione eventi di audit Drive per attività quali accessi, download, modifiche e condivisioni, secondo disponibilità, edizione e periodo di conservazione. Google Workspace — Drive audit events

Verificare:

- actor;
- event name;
- document ID;
- owner;
- visibility;
- IP;
- application;
- timestamp;
- target;
- external user.

60. Dropbox

Per account team, Dropbox può rendere disponibili report amministrativi relativi a:

• accessi;
• dispositivi;
• app collegate;
• membri;
• condivisioni;
• modifiche amministrative;
• attività sui contenuti.

La documentazione precisa che l’audit registra numerose attività del team, ma non necessariamente ogni singola azione o ogni consultazione anonima. Dropbox — attività account e team

60.1 Distinguere

• file sincronizzato;
• download;
• link pubblico;
• condivisione;
• trasferimento;
• app autorizzata;
• dispositivo collegato.

61. Messaggistica

Possibili canali:

• Teams;
• Slack;
• WhatsApp;
• Telegram;
• Signal;
• chat CRM;
• chat di marketplace;
• SMS.

Acquisire:

• account;
• messaggio;
• file;
• destinatario;
• timestamp;
• canale;
• thread;
• allegato;
• eliminazione;
• audit, quando disponibile.

Approfondimenti:

• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics

62. Condivisioni di rete e NAS

Verificare:

• accessi SMB/NFS;
• audit;
• file server;
• share;
• permessi;
• account;
• client;
• byte;
• open files;
• shadow copy;
• NAS audit.

Un accesso a una share dimostra la connessione o l’operazione registrata.

Non dimostra automaticamente:

• copia su USB;
• trasferimento esterno;
• persona fisica.

Correlare con:

• host;
• utente;
• file;
• processo;
• endpoint;
• volume esterno.

63. Stampa, screenshot e fotografie

La sottrazione può avvenire senza copia digitale.

63.1 Stampa

Possibili fonti:

• spooler;
• print server;
• audit;
• document name;
• account;
• stampante;
• pagine;
• orario.

63.2 Screenshot

Possibili fonti:

• file PNG/JPEG;
• cartella screenshot;
• clipboard;
• applicazioni;
• cloud sync;
• cronologia;
• hotkey non sempre registrata.

63.3 Fotografia dello schermo

Può non lasciare alcuna traccia sul computer.

L’assenza di USB, email e cloud non esclude quindi la fuoriuscita mediante:

• stampa;
• fotografia;
• trascrizione;
• appunti.

La verifica tecnica degli screenshot e delle schermate richiede il file originario e il contesto di acquisizione, quando disponibili.

64. Accesso remoto e software RMM

Possibili strumenti:

• Remote Desktop;
• AnyDesk;
• TeamViewer;
• Quick Assist;
• strumenti MSP;
• VPN;
• VDI;
• Citrix.

Acquisire:

- installazione;
- log;
- sessioni;
- account;
- dispositivo remoto;
- file transfer;
- clipboard;
- orari;
- configurazione.

Una sessione remota può consentire:

• download;
• copia negli appunti;
• stampa remota;
• mapping di dischi;
• screenshot.

65. Repository di codice

Fonti:

• Git;
• GitHub;
• GitLab;
• Azure DevOps;
• Bitbucket;
• repository locale;
• CI/CD.

Verificare:

- clone;
- fetch;
- pull;
- push;
- fork;
- token;
- SSH key;
- personal access token;
- download archive;
- repository pubblico;
- account esterno.

Un clone può essere attività normale dello sviluppatore.

La rilevanza dipende da:

• repository;
• account;
• destinazione;
• autorizzazione;
• periodo;
• successivo push esterno.

66. Database, CRM e gestionali

Possibili azioni:

• export CSV;
• export Excel;
• report;
• stampa;
• query;
• API;
• backup;
• sincronizzazione.

Fonti:

• audit applicativo;
• database;
• API log;
• browser;
• download;
• file system;
• DLP.

Esempio:

09:50 — login CRM
09:54 — ricerca clienti
10:02 — export 18.400 record
10:05 — creazione clienti.csv
10:12 — upload webmail

Questa convergenza è più significativa di un singolo file CSV rinvenuto sul computer.

67. Antiforensics e pulizia

Possibili indicatori:

• cancellazione cronologia;
• svuotamento cestino;
• pulizia dei recenti;
• software di wiping;
• sovrascrittura;
• disattivazione log;
• rimozione agent;
• modifica timestamp;
• formattazione USB;
• utilizzo di sistemi live.

67.1 Prudenza

Una pulizia può derivare da:

• manutenzione;
• privacy;
• procedura aziendale;
• liberazione spazio;
• tool automatico.

68. Triage PowerShell del dispositivo collegato

I comandi seguenti modificano in misura limitata il sistema attraverso la normale esecuzione e la generazione di log. Devono essere autorizzati e documentati.

Get-Date -Format "yyyy-MM-ddTHH:mm:ss.fffK"

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

Get-PnpDevice -PresentOnly |
  Where-Object {
    $_.Class -in "DiskDrive","USB"
  } |
  Export-Csv ".\pnp-present.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Get-CimInstance Win32_DiskDrive |
  Select-Object `
    Model,
    SerialNumber,
    InterfaceType,
    DeviceID,
    Size |
  Export-Csv ".\diskdrives.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Get-Disk |
  Select-Object `
    Number,
    FriendlyName,
    SerialNumber,
    BusType,
    PartitionStyle,
    OperationalStatus |
  Export-Csv ".\disks.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Get-Partition |
  Select-Object `
    DiskNumber,
    PartitionNumber,
    DriveLetter,
    Offset,
    Size |
  Export-Csv ".\partitions.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    UniqueId,
    Size |
  Export-Csv ".\volumes.csv" `
    -NoTypeInformation `
    -Encoding UTF8

69. Esportazione degli Event Log

wevtutil epl Security `
  "D:\CASO\Security.evtx" `
  /ow:true

wevtutil epl System `
  "D:\CASO\System.evtx" `
  /ow:true

wevtutil epl `
  "Microsoft-Windows-DriverFrameworks-UserMode/Operational" `
  "D:\CASO\DriverFrameworks-UserMode.evtx" `
  /ow:true

wevtutil epl `
  "Microsoft-Windows-Kernel-PnP/Configuration" `
  "D:\CASO\Kernel-PnP-Configuration.evtx" `
  /ow:true

Non tutti i canali sono necessariamente presenti o abilitati.

Registrare:

• comando;
• account;
• host;
• privilegi;
• errori;
• dimensione;
• hash.

70. Acquisizione di SetupAPI e hive

SetupAPI

Copy-Item `
  "$env:WINDIR\INF\setupapi.dev.log" `
  "D:\CASO\setupapi.dev.log"

Hive SYSTEM e SOFTWARE

reg save HKLM\SYSTEM `
  D:\CASO\SYSTEM.hiv `
  /y

reg save HKLM\SOFTWARE `
  D:\CASO\SOFTWARE.hiv `
  /y

L’esportazione live deve essere documentata.

I profili utente, inclusi:

NTUSER.DAT
UsrClass.dat

dovrebbero essere acquisiti mediante immagine forense o procedura controllata, evitando di forzare file in uso con tecniche non documentate.

71. Analisi con RECmd

RECmd consente di analizzare hive del registro mediante query singole o batch.

Sintassi orientativa:

RECmd.exe `
  -f ".\SYSTEM.hiv" `
  --bn ".\<BATCH_VALIDATO>.reb" `
  --csv ".\out"

Registrare:

• versione;
• batch;
• hash del batch;
• hive;
• comando;
• output;
• errori.

Il batch deve essere validato rispetto agli artefatti e alla versione del sistema. RECmd — GitHub

72. Analisi MFT e USN con MFTECmd

MFT

MFTECmd.exe `
  -f ".\$MFT" `
  --csv ".\out" `
  --csvf "mft.csv"

USN Journal

MFTECmd.exe `
  -f ".\$J" `
  --csv ".\out" `
  --csvf "usn-journal.csv"

MFTECmd supporta l’analisi di strutture NTFS, tra cui MFT e change journal, producendo output utilizzabili per timeline e correlazioni. MFTECmd — GitHub

Conservare:

• file sorgente;
• output;
• versione;
• comando;
• hash.

73. LECmd e JLECmd

Collegamenti LNK

LECmd.exe `
  -d ".\LNK" `
  -r `
  --csv ".\out"

L’opzione -r limita l’output ai collegamenti riconducibili a unità rimovibili secondo la logica dello strumento. LECmd — GitHub

Jump List

JLECmd.exe `
  -d ".\JumpLists" `
  --csv ".\out"

Non considerare l’output del parser una conclusione.

Ogni riga deve essere collegata:

• al file originale;
• al profilo;
• al percorso;
• al volume;
• alla timeline.

74. KAPE

KAPE utilizza:

• Targets per raccogliere artefatti;
• Modules per elaborarli.

È utile per una raccolta rapida e documentata, ma target e moduli devono essere verificati rispetto alla versione. KAPE — Kroll

Sintassi concettuale:

kape.exe `
  --tsource C: `
  --tdest D:\CASO\KAPE `
  --target <TARGET_VALIDATO> `
  --tflush

Annotare:

- versione;
- target;
- moduli;
- sorgente;
- destinazione;
- log;
- errori;
- volume acquisito;
- hash.

75. Advanced Hunting per USB

Esempio orientativo in Microsoft Defender:

DeviceEvents
| where ActionType in (
    "UsbDriveMounted",
    "UsbDriveUnmounted"
)
| project
    Timestamp,
    DeviceName,
    ActionType,
    AccountName,
    AdditionalFields
| order by Timestamp asc

Gli action type disponibili e il contenuto di AdditionalFields dipendono dalla versione e dalla telemetria attiva. Microsoft documenta eventi di montaggio e smontaggio USB nella telemetria Device Control e Advanced Hunting. Microsoft — Advanced Hunting schema

Correlare con:

• DeviceFileEvents;
• identità;
• classificazione;
• policy DLP;
• eventi di rete.

76. Microsoft Purview Audit

Esempio orientativo per amministratori autorizzati:

Search-UnifiedAuditLog `
  -StartDate "2026-07-01" `
  -EndDate   "2026-07-11" `
  -UserIds   "utente@example.invalid" `
  -Operations `
    FileDownloaded,
    FileSyncDownloadedFull,
    FileUploaded,
    FileSyncUploadedFull

Prima dell’uso verificare:

• licenza;
• retention;
• limiti;
• timezone;
• ruolo;
• eventuale segmentazione dell’export.

Conservare:

• query;
• output raw;
• numero risultati;
• intervallo;
• account di acquisizione;
• hash.

77. Google Workspace e Dropbox: acquisizione amministrativa

Google Workspace

Acquisire:

- Drive audit;
- login audit;
- token audit;
- admin audit;
- condivisioni;
- download;
- document ID;
- actor;
- IP;
- timestamp.

Dropbox

Acquisire:

- team activity;
- accessi;
- dispositivi;
- app;
- condivisioni;
- link;
- trasferimenti;
- amministrazione.

Ogni report deve essere accompagnato da:

• filtro;
• intervallo;
• timezone;
• ruolo;
• formato;
• limitazioni;
• hash.

78. Costruire la timeline

Esempio:

Conservare:

- timestamp originale;
- UTC;
- fonte;
- record ID;
- evidenza;
- deduzione;
- limite.

La timeline forense deve mantenere separati valori originari, normalizzazioni e inferenze.

79. Matrice delle evidenze

80. Modello di attribuzione personale

Elementi tecnici

• account;
• sessione;
• computer;
• MFA;
• device ID;
• file;
• volume;
• applicazione;
• orario.

Elementi organizzativi

• assegnazione del PC;
• presenza;
• turno;
• mansione;
• ticket;
• autorizzazione;
• account condiviso;
• accesso di amministratori.

Elementi alternativi

• credenziali compromesse;
• uso da parte di collega;
• sessione lasciata aperta;
• amministrazione remota;
• malware;
• processo automatico;
• sincronizzazione.

81. Dipendente ancora in servizio

Possibili esigenze:

• contenere il rischio;
• non compromettere l’indagine;
• preservare la continuità;
• evitare accessi ulteriori;
• non anticipare accuse.

Misure possibili, se autorizzate:

• modifica controllata dei privilegi;
• revoca condivisioni;
• preservazione dei log;
• riassegnazione temporanea;
• imaging del computer;
• monitoraggio mediante strumenti già previsti e informati.

Non introdurre improvvisamente controlli occulti non previsti.

82. Cessazione e offboarding

Una procedura efficace dovrebbe comprendere:

[ ] disabilitazione account;
[ ] revoca sessioni;
[ ] revoca MFA;
[ ] revoca VPN;
[ ] rimozione token;
[ ] recupero dispositivi;
[ ] preservazione mailbox;
[ ] preservazione OneDrive;
[ ] trasferimento documenti;
[ ] revoca repository;
[ ] cambio segreti condivisi;
[ ] inventario restituzioni;
[ ] conservazione log.

82.1 Prima di cancellare

Verificare:

• esigenze probatorie;
• obblighi;
• conservazione;
• accessi;
• cloud;
• legal hold;
• autorizzazioni.

La cancellazione immediata dell’account può determinare la perdita di:

• audit;
• mailbox;
• condivisioni;
• metadati;
• proprietari dei file;
• dati di attribuzione.

83. BYOD

Quando il lavoratore utilizza un dispositivo personale:

• il perimetro aziendale e quello privato si sovrappongono;
• l’acquisizione integrale può essere sproporzionata;
• possono essere presenti dati familiari, sanitari e finanziari;
• occorre definire chiaramente cosa acquisire.

Possibili soluzioni:

• raccolta selettiva;
• container aziendale;
• MDM;
• export dell’app di lavoro;
• acquisizione alla presenza del titolare;
• filtro mediante keyword concordate;
• verbalizzazione delle esclusioni.

84. Account personali

L’azienda può disporre di evidenze sul proprio dispositivo relative all’uso di:

• Gmail;
• Dropbox personale;
• Drive personale;
• webmail;
• repository personale.

Può acquisire dal dispositivo aziendale:

• cronologia;
• log proxy;
• artefatti browser;
• file locali;
• eventi DLP.

Non può automaticamente:

• aprire la casella;
• scaricare i dati;
• usare password salvate;
• riattivare la sessione;
• accedere al cloud.

L’analisi deve fermarsi al perimetro autorizzato.

85. Legal hold e preservazione

Quando esiste un contenzioso attuale o prevedibile, l’organizzazione dovrebbe valutare con il legale la sospensione delle normali cancellazioni per i dati pertinenti.

Possibili fonti:

• mailbox;
• OneDrive;
• SharePoint;
• Teams;
• audit;
• endpoint;
• backup;
• ticket.

Il legal hold non significa conservare indiscriminatamente ogni dato.

Deve indicare:

- soggetti;
- periodo;
- fonti;
- categorie;
- custode;
- durata;
- accessi;
- revoca.

86. Minimizzazione e oscuramento

La raccolta può comprendere:

• email private;
• dati sanitari;
• conversazioni sindacali;
• dati familiari;
• password;
• documenti non pertinenti;
• informazioni di altri dipendenti.

Prevedere:

- repository completo protetto;
- dataset di lavoro;
- allegati selettivi;
- oscuramenti;
- pseudonimi;
- registro degli accessi;
- criteri di esclusione.

Non modificare l’originale.

Produrre copie derivate, indicando:

• trasformazione;
• strumento;
• data;
• operatore;
• hash della copia.

87. Caso pratico 1 — Pendrive collegata senza prova di copia

Scenario

Un’azienda romana rileva una voce USBSTOR sul computer di un commerciale dimissionario.

Risultati

- dispositivo configurato;
- nessun evento DLP;
- supporto non disponibile;
- nessun LNK verso il volume;
- nessuna Jump List;
- nessun archivio;
- nessuna anomalia cloud.

Conclusione

88. Caso pratico 2 — File identici rinvenuti sulla pendrive

Scenario

Una società di consulenza di Roma acquisisce il laptop aziendale e una pendrive riconsegnata dal dipendente.

Risultati

- USB collegata nel periodo;
- volume associato a E:;
- archivio clienti creato;
- DLP registra scrittura;
- 320 file presenti sulla pendrive;
- hash coincidenti con la cartella aziendale.

Conclusione

89. Caso pratico 3 — Archivio caricato su webmail

Scenario

Un dipendente di un’azienda romana crea un file progetti.zip e accede a una webmail personale.

Risultati

• creazione ZIP in MFT e USN;
• esecuzione 7-Zip;
• accesso webmail;
• proxy registra upload;
• DLP rileva classificazione riservata;
• nessun accesso alla casella personale.

Conclusione

90. Caso pratico 4 — Download massivo da SharePoint

Scenario

Uno studio professionale di Roma rileva 4.800 download nei due giorni precedenti le dimissioni.

Risultati

- account individuale;
- dispositivo gestito;
- IP aziendale;
- OneDrive sync;
- eventi FileSyncDownloadedFull;
- mansioni che consentivano accesso soltanto a parte dei documenti;
- nessuna destinazione esterna accertata.

Conclusione

91. Caso pratico 5 — Telefono personale collegato via MTP

Scenario

Un’azienda di Roma sospetta la copia di fotografie tecniche verso uno smartphone.

Risultati

• dispositivo portatile rilevato;
• nessuna lettera di unità;
• cartella immagini aperta;
• file recenti;
• telefono non acquisito;
• nessun DLP.

Conclusione

92. Caso pratico 6 — Dropbox personale

Scenario

Un progettista romano utilizza il client Dropbox personale sul computer aziendale.

Risultati

- client installato;
- cartella sincronizzata;
- file aziendali presenti localmente;
- traffico di rete;
- nessun audit del tenant personale;
- computer acquisito.

Conclusione

93. Caso pratico 7 — Stampa di un elenco clienti

Scenario

Un’azienda romana non rileva USB o upload, ma il print server mostra una stampa di 600 pagine.

Risultati

• account individuale;
• documento denominato elenco-clienti.pdf;
• stampante aziendale;
• orario serale;
• accesso fisico mediante badge;
• mansione non compatibile con la stampa massiva.

Conclusione

94. Caso pratico 8 — Account amministrativo condiviso

Scenario

Tre tecnici di una società romana utilizzano lo stesso account amministrativo.

Risultati

• export database;
• account condiviso;
• accesso da jump server;
• nessun PAM;
• turno sovrapposto;
• file successivamente rinvenuto su USB di uno dei tecnici.

Conclusione

95. Caso pratico 9 — Cancellazione dopo la copia

Scenario

Un dipendente elimina archivi e cronologia prima di restituire il laptop.

Risultati

- archivi cancellati;
- USN compatibile;
- Recycle Bin svuotato;
- tool di pulizia eseguito;
- copie presenti su pendrive;
- hash coincidenti.

Conclusione

96. Caso pratico 10 — Dispositivo personale e acquisizione selettiva

Scenario

Un consulente romano ha utilizzato il proprio MacBook per lavorare su documenti aziendali.

Procedura

• consenso formalizzato;
• intervallo definito;
• cartella di progetto;
• client cloud aziendale;
• hash dei file;
• esclusione di foto, email e documenti privati;
• verbalizzazione.

Conclusione

97. Errori da evitare

Errore 1 — Considerare USBSTOR prova di copia

Documenta il dispositivo, non il trasferimento.

Errore 2 — Considerare SetupAPI ultimo collegamento

Può riferirsi alla prima installazione.

Errore 3 — Interpretare ogni LastWrite come inserimento

Indica la modifica della chiave.

Errore 4 — Confondere seriale hardware e volume serial

Sono identificatori differenti.

Errore 5 — Considerare la lettera stabile

Può cambiare tra sessioni.

Errore 6 — Non acquisire il supporto

Si perde la verifica della destinazione.

Errore 7 — Collegare il supporto senza write blocker

Si modificano metadati.

Errore 8 — Analizzare direttamente gli originali

Si altera la catena di custodia.

Errore 9 — Aprire i file contestati sul computer

Si modificano recenti e timestamp.

Errore 10 — Non acquisire l’ora e il fuso

La timeline può risultare errata.

Errore 11 — Confondere accesso e copia

Sono operazioni differenti.

Errore 12 — Confondere copia e divulgazione

La presenza locale non dimostra l’invio.

Errore 13 — Confondere account e persona

Le credenziali possono essere condivise.

Errore 14 — Ignorare accessi amministrativi

Un tecnico può utilizzare il computer.

Errore 15 — Ignorare MTP

Il telefono può non apparire come USBSTOR.

Errore 16 — Non acquisire MountPoints2

Si perde la correlazione col profilo.

Errore 17 — Non acquisire MFT e USN

Si perde la sequenza del file system.

Errore 18 — Ignorare LNK e Jump List

Possono collegare file e volume.

Errore 19 — Considerare ShellBags prova di copia

Documentano soprattutto navigazione.

Errore 20 — Considerare Prefetch prova del file trasferito

Documenta l’esecuzione del programma.

Errore 21 — Non cercare archivi

La sottrazione può essere preceduta da staging.

Errore 22 — Limitarsi alla pendrive

Il canale può essere cloud o email.

Errore 23 — Ignorare la webmail

Può essere usata dal browser.

Errore 24 — Accedere alla webmail personale

Può essere non autorizzato.

Errore 25 — Ignorare i client cloud

La sincronizzazione può essere automatica.

Errore 26 — Considerare ogni download illecito

Può essere compatibile con la mansione.

Errore 27 — Non acquisire policy e ticket

Manca il contesto autorizzativo.

Errore 28 — Non verificare le misure di segretezza

È essenziale per la valutazione dei dati riservati.

Errore 29 — Raccogliere tutti i dati del dipendente

Viola la minimizzazione.

Errore 30 — Ignorare BYOD e dati personali

Si amplia impropriamente il perimetro.

Errore 31 — Cancellare l’account troppo presto

Si perdono audit e proprietà.

Errore 32 — Non preservare la mailbox

I dati possono scadere o essere eliminati.

Errore 33 — Non verificare la retention cloud

Gli eventi possono diventare indisponibili.

Errore 34 — Non registrare la query amministrativa

L’output non è riproducibile.

Errore 35 — Considerare un DLP infallibile

Dipende da policy e classificazione.

Errore 36 — Confondere un evento bloccato con una copia riuscita

L’azione potrebbe non essere stata completata.

Errore 37 — Considerare l’assenza di DLP come assenza di copia

La policy potrebbe non coprire il canale.

Errore 38 — Non considerare stampa e fotografia

La sottrazione può essere non digitale.

Errore 39 — Ignorare il software remoto

Può trasferire file o clipboard.

Errore 40 — Non analizzare repository e database

La fuoriuscita può avvenire mediante export.

Errore 41 — Usare un solo timestamp

Occorre correlare più fonti.

Errore 42 — Considerare hash diverso come file estraneo

Può essere una versione derivata.

Errore 43 — Considerare hash uguale prova dell’autore

Dimostra identità del contenuto.

Errore 44 — Formulare intenzioni dal solo dato

L’intenzione non è registrata dal file system.

Errore 45 — Accusare il soggetto nella relazione

Il tecnico deve descrivere fatti e limiti.

Errore 46 — Non documentare lacune e sovrascritture

Si presenta una ricostruzione ingannevolmente completa.

98. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] incarico;
[ ] legale;
[ ] HR;
[ ] DPO;
[ ] quesito;
[ ] soggetti;
[ ] periodo;
[ ] fonti;
[ ] limiti.

Fase 2 — Rischio attivo

[ ] account ancora attivo;
[ ] sessioni;
[ ] condivisioni;
[ ] cloud;
[ ] VPN;
[ ] repository;
[ ] supporti;
[ ] dati riservati.

Fase 3 — Preservazione

[ ] computer;
[ ] mailbox;
[ ] OneDrive;
[ ] SharePoint;
[ ] Drive;
[ ] Dropbox;
[ ] EDR;
[ ] DLP;
[ ] log;
[ ] USB.

Fase 4 — Inventario

[ ] asset;
[ ] seriali;
[ ] account;
[ ] smartphone;
[ ] token;
[ ] dispositivi personali;
[ ] badge;
[ ] mansioni.

Fase 5 — Acquisizione endpoint

[ ] immagine;
[ ] RAM;
[ ] registry;
[ ] EVTX;
[ ] MFT;
[ ] USN;
[ ] LNK;
[ ] Jump List;
[ ] browser;
[ ] cloud client.

Fase 6 — Acquisizione supporti

[ ] fotografia;
[ ] write blocker;
[ ] immagine;
[ ] partizioni;
[ ] file system;
[ ] file cancellati;
[ ] hash.

Fase 7 — USB correlation

[ ] Enum;
[ ] USBSTOR;
[ ] SetupAPI;
[ ] MountedDevices;
[ ] MountPoints2;
[ ] PnP;
[ ] Security;
[ ] DLP;
[ ] EDR.

Fase 8 — File activity

[ ] MFT;
[ ] USN;
[ ] LogFile;
[ ] LNK;
[ ] Jump List;
[ ] MRU;
[ ] archive;
[ ] delete.

Fase 9 — Canali esterni

[ ] email;
[ ] webmail;
[ ] cloud;
[ ] messaggistica;
[ ] repository;
[ ] remote access;
[ ] stampa;
[ ] telefono.

Fase 10 — Confronto

[ ] hash;
[ ] dimensione;
[ ] nome;
[ ] metadati;
[ ] contenuto;
[ ] versione;
[ ] struttura.

Fase 11 — Timeline

[ ] valori originali;
[ ] UTC;
[ ] fonte;
[ ] attendibilità;
[ ] deduzione;
[ ] lacune.

Fase 12 — Attribuzione

[ ] account;
[ ] sessione;
[ ] dispositivo;
[ ] MFA;
[ ] presenza;
[ ] mansioni;
[ ] accessi di terzi;
[ ] alternative.

Fase 13 — Relazione

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

99. Checklist finale

Perimetro

[ ] incarico formalizzato;
[ ] quesito definito;
[ ] legale coinvolto;
[ ] HR coinvolte;
[ ] DPO coinvolto;
[ ] periodo definito;
[ ] fonti autorizzate.

Computer

[ ] fotografia;
[ ] seriale;
[ ] stato;
[ ] immagine;
[ ] hash;
[ ] registro;
[ ] EVTX;
[ ] MFT;
[ ] USN.

USB

[ ] dispositivo identificato;
[ ] seriale;
[ ] volume;
[ ] lettera;
[ ] mount;
[ ] write blocker;
[ ] immagine;
[ ] file cancellati;
[ ] hash.

Artefatti utente

[ ] LNK;
[ ] Jump List;
[ ] ShellBags;
[ ] RecentDocs;
[ ] Prefetch;
[ ] Amcache;
[ ] SRUM;
[ ] browser.

Canali esterni

[ ] email;
[ ] webmail;
[ ] OneDrive;
[ ] SharePoint;
[ ] Google Drive;
[ ] Dropbox;
[ ] messaggistica;
[ ] repository;
[ ] stampa.

Interpretazione

[ ] presenza distinta da copia;
[ ] copia distinta da divulgazione;
[ ] account distinto da persona;
[ ] attività distinta da autorizzazione;
[ ] hash interpretato correttamente;
[ ] alternative considerate;
[ ] lacune indicate.

100. Output minimo dell’accertamento

1. incarico;
2. verbale di consegna;
3. registro reperti;
4. inventario asset;
5. policy e informative;
6. immagine forense del computer;
7. immagine del supporto USB;
8. hash degli originali;
9. hive di registro;
10. SetupAPI.dev.log;
11. Event Log;
12. output USBSTOR;
13. output MountedDevices;
14. output MountPoints2;
15. output PnP;
16. output Security 4663;
17. audit Defender;
18. audit DLP;
19. MFT;
20. USN Journal;
21. LogFile;
22. LNK;
23. Jump List;
24. ShellBags;
25. MRU;
26. Prefetch;
27. Amcache;
28. SRUM;
29. browser;
30. archivi;
31. mailbox;
32. audit cloud;
33. OneDrive/SharePoint;
34. Google Drive;
35. Dropbox;
36. proxy e firewall;
37. repository;
38. confronti hash;
39. tabella dei file;
40. timeline;
41. matrice delle evidenze;
42. matrice delle autorizzazioni;
43. tabella delle lacune;
44. relazione tecnica;
45. allegati;
46. hash degli output.

101. Struttura della relazione tecnica

101.1 Incarico

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

101.2 Contesto

• azienda;
• mansioni;
• strumenti;
• sistemi;
• policy;
• dati interessati.

101.3 Materiale

• computer;
• supporti;
• account;
• mailbox;
• log;
• cloud;
• hash.

101.4 Metodo

• acquisizione;
• strumenti;
• versioni;
• comandi;
• correlazione;
• minimizzazione.

101.5 Risultati USB

• dispositivo;
• volume;
• lettera;
• profilo;
• date;
• file;
• audit.

101.6 Risultati file system

• MFT;
• USN;
• LNK;
• Jump List;
• archivi;
• cancellazioni.

101.7 Risultati cloud ed email

• download;
• upload;
• condivisioni;
• allegati;
• destinatari;
• sessioni.

101.8 Timeline

• eventi;
• fonti;
• UTC;
• attendibilità;
• deduzioni;
• gap.

101.9 Attribuzione

• account;
• dispositivo;
• sessione;
• presenza;
• accessi di terzi;
• alternative.

101.10 Limiti

• log assenti;
• supporto non acquisito;
• account personale;
• retention;
• dispositivo riutilizzato;
• credenziali condivise.

101.11 Conclusioni

Risposte tecniche proporzionate al quesito.

102. Modelli di frasi tecniche

102.1 Presenza del dispositivo

102.2 Limite USBSTOR

102.3 SetupAPI

102.4 Mount point

102.5 Profilo utente

102.6 Accesso al file

102.7 Copia compatibile

102.8 Hash coincidente

102.9 Hash differente

102.10 Audit DLP

102.11 Download cloud

102.12 Sincronizzazione

102.13 Webmail

102.14 MTP

102.15 Stampa

102.16 Account condiviso

102.17 Attività autorizzata

102.18 Informazione riservata

102.19 Pulizia

102.20 Assenza del supporto

102.21 Assenza di log

102.22 Attribuzione

102.23 Conclusione prudente

103. Immagini e figure suggerite

104. Riferimenti tecnici e normativi esterni

1. Codice civile, articolo 2105 — Obbligo di fedeltà del prestatore di lavoro
2. Legge n. 300/1970, articolo 4 — Impianti audiovisivi e altri strumenti di controllo
3. Garante privacy — Metadati della posta elettronica nel contesto lavorativo, 6 giugno 2024
4. Garante privacy — Linee guida per posta elettronica e Internet nel rapporto di lavoro
5. Garante privacy — Provvedimento del 12 marzo 2026 su logging, retention e controlli nel lavoro
6. Regolamento UE 2016/679 — Principi, minimizzazione e sicurezza del trattamento
7. Codice della proprietà industriale — Informazioni aziendali riservate e segreti commerciali
8. Decreto legislativo n. 63/2018 — Protezione del know-how riservato e dei segreti commerciali
9. Microsoft — SetupAPI Device Installation Log
10. Microsoft — Audit Removable Storage
11. Microsoft — Defender Device Control ed eventi USB
12. Microsoft — Endpoint DLP e attività sui dispositivi
13. Microsoft — Registro Plug and Play e MountedDevices
14. Microsoft — NTFS USN Change Journal
15. Microsoft — Purview Audit e operazioni sui file
16. Google Workspace — Drive audit events
17. Dropbox — Team activity, accessi e condivisioni
18. Eric Zimmerman Tools — LECmd, JLECmd, MFTECmd e RECmd
19. KAPE — Targets e Modules per raccolta e processamento degli artefatti
20. Apple — System Information e Unified Logging

105. Collegamenti interni consigliati

Capitolo precedente

• Incident response forense e ransomware

Capitolo successivo

• Cloud forensics: Google, Microsoft, Dropbox e backup

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
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

106. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/analisi-smartphone-computer/
/servizi/incident-response-forense/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

perizia su dipendente infedele a Roma
analisi forense di una pendrive USB
verifica della copia di file aziendali
analisi USBSTOR e SetupAPI
ricostruzione dei dispositivi collegati
perizia su sottrazione di dati
analisi download SharePoint e OneDrive
verifica di upload verso cloud personale
analisi di email e allegati aziendali
indagine informatica su un ex dipendente
acquisizione forense del computer aziendale
consulente informatico forense per imprese a Roma

107. Box commerciale finale

Sospetti una sottrazione di dati aziendali a Roma?

Lo Studio Quaranta Digital Forensics può supportare aziende, professionisti, studi legali, responsabili IT, HR e DPO nelle attività di:

[ ] acquisizione forense di computer aziendali;
[ ] analisi di pendrive e dischi USB;
[ ] ricostruzione dei dispositivi collegati;
[ ] analisi di USBSTOR, SetupAPI e MountedDevices;
[ ] verifica di file copiati;
[ ] confronto mediante hash;
[ ] analisi di archivi ZIP, 7z e RAR;
[ ] ricostruzione di cancellazioni;
[ ] analisi di email e webmail;
[ ] analisi OneDrive, SharePoint e Microsoft 365;
[ ] analisi Google Workspace e Google Drive;
[ ] analisi Dropbox;
[ ] analisi EDR e DLP;
[ ] ricostruzione di download e upload;
[ ] timeline forense;
[ ] relazione tecnica;
[ ] supporto al legale e al CTP.

CTA principale: Richiedi una valutazione preliminare
CTA secondaria: Descrivi i dispositivi e i dati coinvolti

Lo Studio non garantisce:

• l’identificazione della persona;
• il recupero di ogni file;
• la prova automatica della sottrazione;
• la qualificazione disciplinare o penale;
• l’esito di un procedimento.

108. Conclusione del capitolo

Un’indagine aziendale sulla sottrazione di dati non può ridursi alla ricerca di una voce USBSTOR.

La ricostruzione corretta deve collegare:

dispositivo
→ volume
→ profilo
→ file
→ operazione
→ destinazione
→ account
→ persona
→ contesto autorizzativo

Ogni passaggio ha un significato differente.

La presenza di una pendrive non dimostra la copia.

La presenza di un file sulla pendrive costituisce un dato più forte, ma non identifica automaticamente l’autore.

L’account collega l’attività a un’identità digitale, non necessariamente a una persona fisica.

La policy e le mansioni contribuiscono a stabilire se l’operazione fosse prevista, ma la relativa valutazione compete all’azienda e al legale.

Una relazione tecnicamente corretta deve indicare:

- quali dispositivi sono stati acquisiti;
- quali fonti sono state analizzate;
- quali file risultano identici;
- quali attività sono osservabili;
- quali passaggi sono dedotti;
- quali autorizzazioni erano presenti;
- quali dati non erano disponibili;
- quali ipotesi alternative restano possibili.

La proporzionalità è essenziale anche quando il sospetto è grave.

L’indagine deve proteggere:

• integrità della prova;
• riservatezza aziendale;
• dati personali;
• diritti del lavoratore;
• affidabilità della conclusione.

109. Anticipazione del capitolo successivo

Capitolo 23 — Cloud forensics: Google, Microsoft, Dropbox e backup

Il prossimo capitolo tratterà:

• definizione del perimetro cloud;
• account personali e aziendali;
• tenant e organizzazioni;
• Microsoft Entra ID;
• Microsoft 365;
• Exchange Online;
• OneDrive;
• SharePoint;
• Teams;
• Google Workspace;
• Gmail;
• Google Drive;
• Dropbox;
• iCloud;
• log di accesso;
• audit amministrativi;
• download;
• upload;
• condivisioni;
• eliminazioni;
• version history;
• account compromessi;
• OAuth;
• token;
• esportazioni;
• legal hold;
• eDiscovery;
• retention;
• backup cloud;
• snapshot;
• acquisizione mediante API;
• hash e catena di custodia;
• correlazione con endpoint e rete;
• timeline;
• limiti dell’attribuzione personale;
• relazione tecnica forense.

Continua con il Capitolo 23 — Cloud forensics: Google, Microsoft, Dropbox e backup →