Accessi abusivi ad account email, social e cloud

Introduzione

Un accesso non riconosciuto a un account email, social o cloud può manifestarsi in modi molto diversi:

• notifica di accesso da una località insolita;
• cambio della password;
• modifica dell’indirizzo email di recupero;
• aggiunta di un numero telefonico sconosciuto;
• comparsa di un nuovo dispositivo;
• messaggi inviati senza il consenso dell’utente;
• regole automatiche che spostano o cancellano email;
• inoltro della posta verso indirizzi esterni;
• richieste di reimpostazione della password;
• file cloud scaricati o condivisi;
• inserzioni pubblicitarie non autorizzate;
• modifiche agli amministratori di una pagina;
• sessioni ancora valide dopo il cambio della password;
• autorizzazioni concesse a un’applicazione esterna;
• notifiche di autenticazione a più fattori non richieste;
• esportazioni di dati mai avviate dall’interessato.

La domanda del cliente è spesso:

Dal punto di vista informatico-forense, questa domanda deve essere scomposta.

Occorre verificare:

1. se sia effettivamente avvenuto un accesso;
2. se l’evento rappresenti un tentativo o un’autenticazione riuscita;
3. quale account e quale servizio siano coinvolti;
4. quali credenziali, sessioni o autorizzazioni siano state utilizzate;
5. da quale indirizzo IP o infrastruttura sia provenuto l’evento;
6. quale dispositivo o applicazione sia stato dichiarato dal servizio;
7. quali attività siano state eseguite dopo l’accesso;
8. se siano state create forme di persistenza;
9. se siano stati letti, esportati, modificati o eliminati dati;
10. quali elementi possano essere correlati a una persona fisica;
11. quali limiti impediscano un’attribuzione certa.

La presenza di un indirizzo IP estero non dimostra automaticamente che l’utente si trovasse all’estero.

La comparsa di un telefono sconosciuto non dimostra necessariamente che quel modello fisico sia stato utilizzato dall’autore.

Una sessione attiva non coincide sempre con un nuovo accesso.

Una località dichiarata dal provider può essere approssimativa.

Un’autenticazione riuscita non dimostra da sola chi abbia materialmente digitato, approvato o riutilizzato le credenziali.

La distinzione fondamentale è:

Nei casi aziendali, inoltre, l’account compromesso può rappresentare soltanto il primo passaggio di un incidente più ampio:

phishing
   ↓
furto delle credenziali
   ↓
accesso alla casella
   ↓
creazione di una regola nascosta
   ↓
lettura delle conversazioni commerciali
   ↓
sostituzione dell’IBAN
   ↓
bonifico fraudolento

L’attività deve quindi coordinarsi con l’analisi delle email e degli header, la cloud forensics, l’analisi dei log aziendali e, quando vi sono conseguenze economiche, con il capitolo dedicato alle truffe online e ai bonifici fraudolenti.

Sintesi operativa

1. valutare se l’accesso abusivo è ancora in corso;
2. usare un dispositivo affidabile e non sospetto;
3. documentare subito notifiche, sessioni, dispositivi e dati di recupero;
4. non ritardare il contenimento quando esiste un rischio attivo;
5. cambiare la password da un dispositivo sicuro;
6. revocare sessioni, token e dispositivi sconosciuti;
7. verificare metodi MFA, passkey, chiavi e numeri di recupero;
8. controllare app OAuth, deleghe e servizi collegati;
9. verificare regole email, inoltri, risposte automatiche e alias;
10. acquisire log, email di sicurezza, esportazioni e file disponibili;
11. conservare gli output e calcolarne l’hash;
12. costruire una timeline in ora locale e UTC;
13. correlare IP, user agent, dispositivo, sessione e azioni;
14. analizzare smartphone e computer utilizzati dall’utente;
15. verificare eventuali messaggi di phishing o malware;
16. determinare quali dati possono essere stati esposti;
17. valutare con legale, DPO e responsabili gli obblighi di notifica;
18. separare compromissione tecnica e attribuzione personale;
19. descrivere sempre fonti, limiti e ipotesi alternative;
20. predisporre una relazione tecnica riproducibile.

La regola centrale è:

1. Avvertenza preliminare

Le procedure descritte in questo capitolo devono essere utilizzate esclusivamente:

• sul proprio account;
• su account aziendali amministrati legittimamente;
• con autorizzazione del titolare;
• nell’ambito di un incarico professionale;
• su sistemi per i quali si possiedono credenziali e poteri amministrativi leciti;
• in attività difensive, peritali o di incident response autorizzate.

Non è lecito utilizzare le informazioni di questo capitolo per:

• tentare password di terzi;
• aggirare l’autenticazione;
• utilizzare codici di recupero altrui;
• intercettare OTP;
• clonare sessioni;
• accedere a dispositivi non autorizzati;
• utilizzare token o cookie sottratti;
• impersonare il titolare;
• installare software di controllo;
• ottenere dati mediante inganno;
• mantenersi nell’account dopo la revoca del consenso.

Il perito non deve chiedere al cliente di trasmettere via email o messaggistica ordinaria:

• password;
• codici OTP;
• codici di recupero;
• chiavi private;
• cookie;
• token;
• passkey;
• seed;
• codici dell’app di autenticazione;
• PIN della SIM.

La collaborazione deve essere organizzata mediante:

- accesso eseguito direttamente dal titolare;
- sessione controllata;
- presenza dell’amministratore autorizzato;
- canale sicuro;
- verbale;
- acquisizione limitata ai dati pertinenti;
- revoca degli accessi temporanei al termine.

2. Inquadramento normativo essenziale

2.1 Accesso abusivo a un sistema informatico o telematico

L’articolo 615-ter del codice penale riguarda l’introduzione abusiva in un sistema informatico o telematico protetto da misure di sicurezza e il mantenimento nel sistema contro la volontà, espressa o tacita, di chi ha il diritto di escludere l’accesso. Gazzetta Ufficiale — articolo 615-ter

Dal punto di vista tecnico possono assumere rilievo:

• autenticazioni;
• sessioni;
• token;
• modifiche di credenziali;
• accessi a dati;
• azioni eseguite;
• permanenza dopo la revoca;
• utilizzo di credenziali ancora formalmente valide;
• superamento dei limiti associati al ruolo;
• accessi effettuati da dipendenti o collaboratori oltre il perimetro autorizzato.

La disponibilità materiale della password non equivale automaticamente a un’autorizzazione attuale.

Un ex dipendente può conoscere ancora una credenziale ma non avere più titolo per utilizzarla.

Un familiare può aver ricevuto in passato la password, senza essere autorizzato ad accedere indefinitamente.

Un amministratore di sistema può possedere privilegi tecnici, ma essere soggetto a limiti funzionali, organizzativi e contrattuali.

La valutazione giuridica spetta al legale e all’autorità competente.

2.2 Codici e mezzi di accesso

L’articolo 615-quater disciplina, nei presupposti previsti dalla norma, la detenzione, diffusione o installazione abusiva di apparecchiature, codici e altri mezzi idonei all’accesso a sistemi informatici o telematici. Gazzetta Ufficiale — articolo 615-quater

Nell’attività tecnica ciò impone particolare cautela nella gestione di:

• password rinvenute;
• cookie di sessione;
• token OAuth;
• chiavi API;
• codici di backup;
• QR di configurazione MFA;
• certificati;
• file di configurazione;
• esportazioni di password;
• archivi del browser.

Questi elementi non devono essere inseriti integralmente nella relazione ordinaria.

Devono essere:

• protetti;
• oscurati;
• conservati separatamente;
• accessibili soltanto agli incaricati;
• eliminati secondo la procedura definita al termine dell’incarico.

2.3 Data breach

Un accesso abusivo a un account aziendale che comporti perdita di riservatezza, integrità o disponibilità di dati personali può costituire una violazione di dati personali.

L’articolo 33 del GDPR prevede, quando ricorrono i relativi presupposti, la notifica all’autorità di controllo senza ingiustificato ritardo e, ove possibile, entro 72 ore dal momento in cui il titolare viene a conoscenza della violazione. L’articolo 34 disciplina la comunicazione agli interessati quando il rischio per i loro diritti e libertà risulta elevato. Il titolare deve inoltre documentare le violazioni anche quando non procede alla notifica. Regolamento UE 2016/679

Il perito può contribuire a determinare:

- account coinvolti;
- periodo della compromissione;
- categorie di dati accessibili;
- azioni osservate;
- eventuali esportazioni;
- numero approssimativo di soggetti interessati;
- misure di contenimento;
- indicatori di compromissione;
- limiti dell’accertamento.

Non decide autonomamente se notificare.

La valutazione deve essere coordinata con:

• titolare del trattamento;
• DPO, se presente;
• responsabili della sicurezza;
• legale;
• management.

2.4 Soggetti NIS

Per i soggetti essenziali o importanti rientranti nell’ambito del decreto legislativo n. 138/2024, gli incidenti significativi possono comportare ulteriori obblighi verso il CSIRT Italia. L’articolo 25 prevede, nei casi applicabili, una pre-notifica entro 24 ore dalla conoscenza dell’incidente significativo, una notifica entro 72 ore e successive relazioni. Tali obblighi riguardano i soggetti e gli incidenti definiti dalla disciplina NIS, non ogni compromissione di un comune account personale. Gazzetta Ufficiale — decreto legislativo 138/2024

3. Che cos’è un account digitale

Un account non è soltanto una combinazione di username e password.

Può comprendere:

- identificativo primario;
- indirizzo email;
- password;
- passkey;
- chiavi di sicurezza;
- applicazione MFA;
- numeri telefonici;
- email di recupero;
- codici di backup;
- dispositivi fidati;
- sessioni;
- token;
- app collegate;
- autorizzazioni OAuth;
- ruoli;
- deleghe;
- metodi di pagamento;
- file;
- messaggi;
- log;
- profili collegati.

La compromissione può riguardare uno o più di questi componenti.

Un utente può cambiare la password ma lasciare attivo:

• un token OAuth;
• una regola di inoltro;
• una passkey sconosciuta;
• un amministratore aggiunto;
• una sessione su un dispositivo;
• un numero di recupero;
• una delega;
• un’applicazione con accesso ai dati.

Per questo:

4. Tipologie di account

4.1 Account email personale

Esempi:

• Gmail;
• Outlook.com;
• Yahoo;
• provider italiani;
• caselle associate a operatori telefonici.

Può consentire il recupero di molti altri servizi.

4.2 Account aziendale

Esempi:

• Microsoft 365;
• Google Workspace;
• server Exchange;
• sistemi IAM;
• portali gestionali;
• VPN;
• CRM;
• ERP.

Può essere associato a:

• ruolo;
• gruppi;
• privilegi;
• risorse condivise;
• dati di clienti;
• sistemi amministrativi.

4.3 Account social

Esempi:

• Facebook;
• Instagram;
• LinkedIn;
• TikTok;
• X;
• YouTube.

Può comprendere:

• profilo;
• pagine;
• inserzioni;
• metodi di pagamento;
• messaggi;
• amministratori;
• account collegati.

4.4 Account cloud

Esempi:

• Google Drive;
• OneDrive;
• SharePoint;
• Dropbox;
• iCloud;
• servizi di backup.

Può consentire:

• lettura;
• download;
• sincronizzazione;
• eliminazione;
• condivisione;
• versioning;
• recupero di file.

4.5 Account federato

L’utente accede a più servizi tramite:

• Microsoft Entra ID;
• Google;
• Apple;
• Facebook;
• SAML;
• OpenID Connect;
• Single Sign-On.

La compromissione dell’identità principale può estendersi ai servizi federati.

4.6 Account amministrativo

Può modificare:

• utenti;
• ruoli;
• politiche;
• log;
• metodi di autenticazione;
• domini;
• applicazioni;
• conservazione;
• condivisioni.

La compromissione di un account amministrativo richiede un’escalation immediata.

5. Tipologie di compromissione

Una stessa vicenda può comprendere più meccanismi.

6. Evento di accesso, sessione e azione

6.1 Tentativo di accesso

Il provider registra una richiesta che può essere:

• fallita;
• bloccata;
• sottoposta a verifica;
• rifiutata dall’utente;
• interrotta;
• riuscita.

Un tentativo fallito non dimostra che l’account sia stato compromesso.

6.2 Autenticazione riuscita

Indica che il sistema ha accettato:

• password;
• passkey;
• token;
• certificato;
• fattore MFA;
• federazione;
• flusso di recupero.

Non identifica automaticamente la persona.

6.3 Sessione

È il periodo durante il quale un browser, un’applicazione o un servizio continua a utilizzare l’account.

Una sessione può rimanere valida:

• per ore;
• per giorni;
• su più servizi;
• dopo la chiusura del browser;
• su un dispositivo sincronizzato.

Google, ad esempio, distingue nella pagina dei dispositivi tra dispositivi e sessioni e avverte che sullo stesso dispositivo possono apparire più sessioni create da browser, app o servizi differenti. Guida Google sui dispositivi e sulle sessioni

6.4 Azione

Dopo l’accesso possono essere eseguite azioni come:

• leggere email;
• cercare parole chiave;
• scaricare file;
• modificare regole;
• inviare messaggi;
• aggiungere un dispositivo;
• creare una chiave;
• autorizzare un’app;
• modificare ruoli;
• eliminare dati.

L’evento di accesso e l’azione devono essere correlati temporalmente.

7. Indicatori iniziali di compromissione

[ ] password modificata senza consenso;
[ ] email o telefono di recupero cambiati;
[ ] passkey sconosciuta;
[ ] chiave di sicurezza non riconosciuta;
[ ] nuovo dispositivo fidato;
[ ] login riuscito da IP insolito;
[ ] sessione non riconosciuta;
[ ] notifiche MFA ripetute;
[ ] messaggi inviati dall’account;
[ ] email cancellate;
[ ] posta spostata automaticamente;
[ ] inoltro esterno;
[ ] regola inbox sconosciuta;
[ ] risposta automatica modificata;
[ ] alias aggiunto;
[ ] amministratore aggiunto;
[ ] app OAuth sconosciuta;
[ ] esportazione dati richiesta;
[ ] file condivisi pubblicamente;
[ ] acquisti o inserzioni;
[ ] contatti avvisati di messaggi fraudolenti;
[ ] notifiche del provider nascoste;
[ ] perdita improvvisa dell’accesso.

Un singolo indicatore può avere spiegazioni legittime.

Più indicatori coerenti aumentano la probabilità di compromissione.

8. Conservare la prova o bloccare l’accesso?

L’attività presenta una tensione operativa.

Scenario A — Compromissione attiva e rischio elevato

Esempi:

• l’attaccante sta inviando email;
• sono in corso pagamenti;
• vengono scaricati file;
• vengono cancellati dati;
• vi sono minacce personali;
• l’account controlla altri servizi.

In questo caso:

Si documentano rapidamente gli elementi essenziali e si procede alla messa in sicurezza.

Scenario B — Evento passato, account sotto controllo

Esempi:

• accesso sospetto di due settimane prima;
• nessuna sessione attiva;
• log ancora disponibili;
• amministratore presente;
• nessuna azione in corso.

In questo caso è possibile acquisire più ampiamente prima di modificare:

• password;
• sessioni;
• regole;
• dispositivi;
• autorizzazioni.

Scenario C — Pericolo personale

Quando l’account compromesso è collegato a stalking, violenza, controllo coercitivo o diffusione intima, utilizzare un dispositivo sicuro e coordinare la risposta con autorità e soggetti competenti.

La disciplina generale dell’incident response considera rilevanti le fasi di rilevazione, risposta e recupero, inserite in un più ampio sistema di gestione del rischio. NIST SP 800-61 Rev. 3

9. Protocollo dei primi quindici minuti

1. interrompere l’uso del dispositivo sospetto, se possibile;
2. utilizzare un dispositivo affidabile;
3. annotare data, ora e fuso;
4. fotografare o acquisire le notifiche;
5. acquisire la pagina delle sessioni;
6. acquisire l’elenco dei dispositivi;
7. acquisire metodi di recupero e MFA;
8. acquisire app e servizi collegati;
9. acquisire regole e inoltri, se visibili;
10. verificare se sono in corso operazioni economiche;
11. cambiare la password quando necessario;
12. revocare le sessioni sconosciute;
13. mettere in sicurezza l’email primaria;
14. avvisare l’amministratore aziendale;
15. registrare ogni modifica eseguita.

Apple, nelle proprie indicazioni di sicurezza personale, suggerisce di documentare le notifiche e i dispositivi prima di rimuovere gli elementi sconosciuti, quando ciò è compatibile con la sicurezza dell’utente. Apple — mantenere sicuro l’Apple Account

10. Protocollo delle prime ventiquattro ore

[ ] formalizzare l’incarico;
[ ] acquisire account e notifiche;
[ ] esportare log disponibili;
[ ] acquisire email di sicurezza;
[ ] controllare sessioni;
[ ] controllare dispositivi;
[ ] controllare MFA e passkey;
[ ] controllare recovery email e telefono;
[ ] controllare OAuth e app collegate;
[ ] controllare regole email e inoltri;
[ ] controllare alias e deleghe;
[ ] controllare pagine e ruoli social;
[ ] controllare file e condivisioni cloud;
[ ] acquisire smartphone e computer;
[ ] verificare phishing e malware;
[ ] costruire una prima timeline;
[ ] individuare dati potenzialmente esposti;
[ ] informare legale, DPO e management;
[ ] valutare richieste urgenti al provider;
[ ] documentare il contenimento.

11. Cosa non fare

[ ] non utilizzare il dispositivo sospetto per cambiare tutte le password;
[ ] non rispondere alle email di sicurezza tramite link non verificati;
[ ] non approvare notifiche MFA non richieste;
[ ] non inoltrare password o OTP al perito;
[ ] non cancellare le email del provider;
[ ] non eliminare subito ogni regola senza documentarla;
[ ] non disinstallare il browser;
[ ] non eseguire una pulizia automatica;
[ ] non formattare il computer;
[ ] non ripristinare il telefono;
[ ] non rimuovere l’account dal dispositivo prima del triage;
[ ] non tentare di entrare nell’account sospetto dell’autore;
[ ] non pubblicare gli IP rilevati;
[ ] non accusare una persona sulla base della geolocalizzazione;
[ ] non condividere integralmente log contenenti token;
[ ] non considerare risolutivo il solo cambio password.

12. Questionario iniziale

12.1 Account

1. Quale account è coinvolto?
2. È personale o aziendale?
3. Chi è il titolare?
4. Chi conosceva la password?
5. L’account era condiviso?
6. Era attiva l’autenticazione a più fattori?
7. Quali dispositivi erano autorizzati?
8. Quale email di recupero era impostata?
9. Quale numero telefonico era associato?
10. Esistono amministratori?

12.2 Evento

1. Quando è stato notato?
2. Quale notifica è stata ricevuta?
3. L’accesso risulta riuscito?
4. Quale IP compare?
5. Quale località?
6. Quale dispositivo?
7. Quale browser o applicazione?
8. Sono state eseguite azioni?
9. Sono stati inviati messaggi?
10. Sono stati modificati file?

12.3 Contenimento già eseguito

Chiedere se il cliente ha:

• cambiato la password;
• revocato sessioni;
• eliminato dispositivi;
• modificato MFA;
• cancellato email;
• formattato un dispositivo;
• contattato il provider;
• avvisato clienti;
• segnalato alla Polizia;
• revocato app;
• rimosso regole;
• bloccato la SIM.

12.4 Conseguenze

[ ] perdita dell’account;
[ ] furto di dati;
[ ] email fraudolente;
[ ] bonifici;
[ ] pubblicazioni social;
[ ] impersonificazione;
[ ] diffusione di fotografie;
[ ] cancellazione di file;
[ ] ricatto;
[ ] accesso ad altri servizi;
[ ] esposizione di dati personali;
[ ] interruzione aziendale.

13. Definire il quesito tecnico

Un quesito improprio è:

Quesiti tecnici corretti possono essere:

- verificare se l’account presenti accessi non riconosciuti;
- acquisire i log disponibili;
- documentare sessioni e dispositivi;
- ricostruire le modifiche dei fattori di autenticazione;
- verificare regole, inoltri e deleghe;
- individuare app e token autorizzati;
- determinare le azioni osservabili;
- ricostruire il periodo della compromissione;
- valutare quali dati fossero accessibili;
- correlare gli eventi con dispositivi e reti;
- indicare gli elementi utili e i limiti dell’attribuzione.

Formula:

14. Mappa delle fonti di prova

14.1 Fonti del provider

• attività di sicurezza;
• login;
• sessioni;
• dispositivi;
• autorizzazioni;
• audit log;
• account recovery;
• modifiche password;
• ruoli;
• condivisioni;
• download;
• email di servizio;
• ticket.

14.2 Fonti email

• messaggi EML;
• header;
• notifiche;
• posta inviata;
• cestino;
• regole;
• inoltri;
• deleghe;
• risposte automatiche;
• alias;
• autenticazioni.

14.3 Fonti del dispositivo

• browser;
• cronologia;
• cookie;
• database;
• applicazioni;
• notifiche;
• file;
• malware;
• password manager;
• registri;
• sincronizzazioni.

14.4 Fonti di rete

• router;
• firewall;
• VPN;
• proxy;
• DNS;
• SIEM;
• EDR;
• log del provider Internet;
• log del carrier.

14.5 Fonti organizzative

• amministratori;
• help desk;
• ticket;
• policy;
• assegnazione dei ruoli;
• inventario dispositivi;
• cessazione del rapporto;
• accessi fisici;
• turni;
• deleghe.

15. Cartella del caso

CASO_RM_2026_018/
├── 00_incarico/
├── 01_verbali/
├── 02_notifiche/
├── 03_security_activity/
├── 04_sessioni/
├── 05_dispositivi/
├── 06_login_logs/
├── 07_email/
├── 08_regole_inoltri_deleghe/
├── 09_oauth_app_token/
├── 10_cloud_files/
├── 11_social/
├── 12_endpoint/
├── 13_network_logs/
├── 14_hash/
├── 15_timeline/
├── 16_indicatori_compromissione/
├── 17_data_breach/
├── 18_report/
└── 19_relazione/

Le cartelle contenenti token, cookie o codici devono essere cifrate e mantenute separate dagli allegati ordinari.

16. Catena di custodia

Per ogni reperto registrare:

- ID;
- descrizione;
- account;
- provider;
- fonte;
- data;
- ora;
- fuso;
- modalità di acquisizione;
- operatore;
- strumento;
- versione;
- formato;
- hash;
- posizione;
- modifiche;
- accessi.

Approfondimento: catena di custodia, hash e verbale tecnico.

Formula:

17. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 -LiteralPath ".\signin-log.csv"

Linux

sha256sum -- signin-log.csv

macOS

shasum -a 256 -- signin-log.csv

Per tutti i file:

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

L’hash documenta l’identità binaria dell’output acquisito.

Non dimostra:

• completezza del log;
• correttezza del provider;
• autore dell’evento;
• data originaria;
• assenza di record non esportati.

18. Documentare data, ora e fuso

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

macOS

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

Annotare:

- ora visualizzata dal provider;
- fuso dell’account;
- fuso del dispositivo;
- UTC;
- ora del sistema di acquisizione;
- precisione;
- eventuale differenza;
- conversione applicata.

Un evento indicato come “ieri alle 23:10” deve essere acquisito anche nel suo formato completo, quando disponibile.

19. Credenziale, autenticatore e fattore

19.1 Password

È un segreto conosciuto dall’utente.

Può essere:

• riutilizzata;
• sottratta;
• osservata;
• registrata;
• esposta in un data breach;
• salvata nel browser;
• inserita in un sito falso.

19.2 Fattore di possesso

Esempi:

• telefono;
• app;
• chiave fisica;
• smart card;
• token.

19.3 Fattore biometrico

Può attivare una credenziale presente nel dispositivo.

19.4 Passkey

Utilizza crittografia a chiave pubblica ed è legata al servizio per cui è stata creata.

Le linee guida NIST distinguono gli autenticatori resistenti al phishing dalle password, che non sono considerate resistenti al phishing. L’effettiva robustezza dipende comunque dall’implementazione, dalla protezione del dispositivo e dai processi di recupero. NIST SP 800-63B

19.5 Codice OTP

Può essere:

• generato dall’app;
• ricevuto via SMS;
• inviato via email;
• approvato mediante push.

Un OTP non deve essere trasmesso a terzi.

20. Autenticazione a più fattori

La presenza di MFA non esclude la compromissione.

Possibili scenari:

• approvazione involontaria;
• SIM swap;
• phishing in tempo reale;
• furto del token;
• dispositivo già autenticato;
• aggiunta di un nuovo fattore;
• utilizzo di un metodo di recupero;
• autorizzazione OAuth;
• sessione sottratta dopo il login.

20.1 MFA fatigue

L’utente riceve molte richieste e ne approva una per errore.

Acquisire:

- data e ora delle notifiche;
- numero di richieste;
- dispositivo;
- metodo;
- accesso successivo;
- eventuali chiamate o messaggi;
- dichiarazione dell’utente.

20.2 SMS

L’SMS può dipendere dal controllo del numero e dalla sicurezza dell’operatore.

Verificare:

• perdita improvvisa del segnale;
• sostituzione SIM;
• deviazione;
• cambio operatore;
• richieste di assistenza;
• numero associato.

20.3 Passkey o chiavi sconosciute

Acquisire prima della rimozione:

• nome;
• data;
• dispositivo;
• tipo;
• ultima attività, se mostrata;
• schermata completa.

21. Furto della sessione

Un attaccante può utilizzare una sessione già autenticata senza ripetere l’intero login.

Questo può avvenire quando:

• il dispositivo viene sottratto;
• il browser è controllato;
• cookie o token vengono sottratti;
• un malware accede al profilo;
• una sessione viene sincronizzata;
• un’app mantiene l’autorizzazione.

Possibili conseguenze:

• assenza di una nuova richiesta MFA;
• attività da un browser già riconosciuto;
• IP differente all’interno della stessa sessione;
• accesso anche dopo il cambio password, se i token non vengono revocati;
• azioni effettuate tramite API.

Formula:

22. OAuth e applicazioni collegate

OAuth consente a un’applicazione di accedere a determinate risorse senza ricevere direttamente la password dell’utente.

Un’app può ottenere permessi per:

• leggere email;
• inviare email;
• accedere ai contatti;
• leggere file;
• modificare file;
• gestire calendari;
• accedere al profilo;
• operare offline.

La revoca della password non sempre coincide automaticamente con la revoca di ogni autorizzazione applicativa.

Google consente di riesaminare e revocare le app collegate e i relativi livelli di accesso; Google Workspace dispone inoltre di eventi di audit OAuth per ricostruire autorizzazioni e utilizzo dei token. Google — connessioni con app e servizi di terze parti

Acquisire:

- nome app;
- sviluppatore;
- client ID;
- data autorizzazione;
- scope;
- ultimo utilizzo;
- account autorizzante;
- eventuale revoca;
- log delle API;
- email di consenso.

Formula:

23. Canali di recupero

Verificare:

[ ] email di recupero;
[ ] numero telefonico;
[ ] dispositivo fidato;
[ ] contatto di recupero;
[ ] codici backup;
[ ] chiavi;
[ ] passkey;
[ ] domande di sicurezza;
[ ] alias;
[ ] account collegati.

Un attaccante può modificare i canali per:

• bloccare il titolare;
• recuperare nuovamente l’account;
• ricevere notifiche;
• aggiungere un metodo persistente.

Conservare le email del provider che segnalano:

• modifica password;
• aggiunta numero;
• modifica email;
• nuova chiave;
• nuovo dispositivo;
• richiesta di recupero.

24. Analisi dell’indirizzo IP

24.1 Che cosa indica

Un indirizzo IP può collegare un evento a:

• rete domestica;
• rete mobile;
• azienda;
• VPN;
• proxy;
• cloud provider;
• rete pubblica;
• infrastruttura condivisa.

24.2 Che cosa non indica

Non identifica automaticamente:

• persona;
• dispositivo;
• posizione precisa;
• abitazione;
• autore materiale.

24.3 Variabili

• NAT;
• CGNAT;
• IP dinamici;
• IPv4 e IPv6;
• VPN;
• proxy;
• roaming;
• carrier mobile;
• relay privacy;
• CDN;
• server applicativi;
• app che accedono per conto dell’utente.

24.4 Geolocalizzazione

La geolocalizzazione IP è una stima.

Può indicare:

• sede dell’operatore;
• nodo di uscita;
• città vicina;
• regione;
• paese.

Una connessione mobile effettuata a Roma può apparire associata a un’altra città.

Gmail, ad esempio, avverte che l’attività da telefoni o tablet può mostrare la località del carrier e che ciò può produrre localizzazioni distanti dalla posizione fisica dell’utente. Gmail — ultima attività dell’account

Formula:

25. User agent e dispositivo dichiarato

Il provider può mostrare:

• sistema operativo;
• browser;
• app;
• modello generico;
• famiglia del dispositivo;
• metodo di autenticazione.

Questi dati possono derivare da:

• stringa user agent;
• identificatore dell’app;
• registrazione del dispositivo;
• token;
• profilo gestito.

Limiti:

• user agent modificabile;
• browser privacy;
• stringhe ridotte;
• modelli aggregati;
• app embedded;
• virtualizzazione;
• emulazione;
• sessione sincronizzata.

Formula:

26. Impossible travel e accessi anomali

Un sistema può segnalare due accessi temporalmente incompatibili con uno spostamento fisico ordinario.

Possibili spiegazioni:

• VPN;
• rete mobile;
• proxy;
• sessioni parallele;
• app cloud;
• geolocalizzazione errata;
• attività automatizzata;
• attaccante;
• sincronizzazione.

Microsoft Entra consente agli amministratori autorizzati di esaminare cronologia del rischio e log di accesso, correlando località insolite, IP anonimi e segnali di viaggio atipico. Questi indicatori devono essere analizzati, non assunti come prova autonoma. Microsoft Entra ID Protection — investigare il rischio

27. Account email: controlli indispensabili

[ ] attività recenti;
[ ] sessioni;
[ ] dispositivi;
[ ] posta inviata;
[ ] cestino;
[ ] archivio;
[ ] regole inbox;
[ ] filtri;
[ ] inoltro;
[ ] deleghe;
[ ] alias;
[ ] risposte automatiche;
[ ] account collegati;
[ ] POP;
[ ] IMAP;
[ ] SMTP;
[ ] app OAuth;
[ ] app password;
[ ] metodi MFA;
[ ] email di recupero;
[ ] esportazioni;
[ ] attività amministrativa.

28. Regole, inoltri e persistenza nella casella

Un attaccante può creare una regola che:

• sposta email in una cartella;
• elimina notifiche;
• segna messaggi come letti;
• inoltra comunicazioni;
• nasconde risposte;
• intercetta conversazioni economiche.

Microsoft segnala le regole sospette di manipolazione della posta come possibile indicatore di account compromesso e mette a disposizione procedure specifiche per la loro analisi. Microsoft Defender XDR — regole di manipolazione della posta

Acquisire per ogni regola:

- nome;
- stato;
- condizione;
- azione;
- destinatario;
- priorità;
- data disponibile;
- autore o account;
- schermata;
- export;
- hash.

Formula:

29. Gmail e account Google personali

29.1 Attività di sicurezza

Google consente di esaminare:

• eventi di sicurezza recenti;
• dispositivi;
• sessioni;
• modifiche rilevanti;
• app collegate.

La procedura ufficiale per un account compromesso prevede la revisione degli eventi recenti, dei dispositivi e delle impostazioni di sicurezza. Google — proteggere un account compromesso

29.2 Dispositivi e sessioni

Acquisire:

- nome dispositivo;
- sistema;
- località;
- ultima attività;
- stato della sessione;
- servizi utilizzati;
- indicazione “disconnesso”;
- eventuali duplicati.

Non considerare automaticamente sospette più sessioni con lo stesso nome.

29.3 Ultima attività Gmail

Gmail rende disponibile una vista delle attività recenti con date, orari e indirizzi IP; la documentazione ufficiale precisa che la vista può includere accessi da browser, app e protocolli e che gli IP possono riferirsi anche a servizi o carrier. Gmail — dettagli dell’ultima attività

Acquisire:

• screenshot;
• tipo di accesso;
• IP;
• data;
• sessioni simultanee;
• eventuale avviso.

29.4 Filtri e inoltro

Verificare:

• filtri;
• inoltro;
• POP;
• IMAP;
• delega;
• risposte automatiche;
• account importati.

29.5 App collegate

Acquisire l’elenco prima della revoca.

29.6 Esportazione

Google Takeout consente al titolare di richiedere un archivio dei propri dati. L’export deve essere considerato una fonte complementare: descrive i dati resi disponibili dal servizio nel momento e secondo le opzioni della richiesta, non costituisce automaticamente un log completo di ogni attività storica. Google Takeout

30. Google Workspace

30.1 Sospensione e contenimento

Per un utente aziendale compromesso, Google indica agli amministratori autorizzati di sospendere temporaneamente l’account, investigare le attività, riesaminare dispositivi e ripristinare l’accesso dopo la bonifica. La sospensione reimposta i cookie di accesso e i token OAuth dell’utente. Google Workspace — identificare e mettere in sicurezza account compromessi

30.2 User log events

I log utente possono documentare:

• modifiche password;
• modifiche recovery;
• iscrizione 2-Step Verification;
• azioni critiche;
• sessioni.

Google precisa che alcuni tentativi ravvicinati possono essere aggregati in una singola voce e che determinate attività di client non browser possono non essere rappresentate come un normale login. Google Workspace — User log events

30.3 Login audit

Acquisire:

• timestamp;
• utente;
• IP;
• evento;
• esito;
• tipo;
• verifica;
• challenge;
• applicazione.

30.4 OAuth log

Verificare:

• app autorizzate;
• token;
• scope;
• revoche;
• applicazioni Marketplace;
• account di servizio;
• delega domain-wide.

30.5 Admin log

Se l’account compromesso possedeva ruoli amministrativi, acquisire:

• modifiche utenti;
• assegnazioni ruoli;
• policy;
• configurazioni;
• condivisioni;
• servizi;
• deleghe;
• routing email.

Google Workspace permette di consultare eventi amministrativi e, nelle edizioni supportate, utilizzare strumenti di audit e investigazione. Google Workspace — Admin log events

30.6 Drive

Verificare:

• download;
• condivisioni;
• link;
• eliminazioni;
• ripristini;
• modifiche proprietario;
• app esterne.

31. Account Microsoft personale

31.1 Attività recenti

La pagina “Attività recenti” mostra, alla data di aggiornamento, utilizzi dell’account Microsoft degli ultimi 30 giorni, con informazioni su data, località approssimativa e metodo di accesso. Microsoft — pagina Attività recenti

Acquisire:

- data;
- ora;
- località;
- IP, se disponibile;
- browser;
- dispositivo;
- attività riuscita o non riuscita;
- modifica sicurezza;
- alias;
- evento insolito.

31.2 Recupero dell’account

Microsoft raccomanda di verificare il dispositivo, cambiare o reimpostare la password e controllare le impostazioni dell’account, incluse connessioni, inoltri e risposte automatiche. Microsoft — recuperare un account compromesso

31.3 Email Outlook.com

Controllare:

• regole;
• inoltri;
• account connessi;
• risposte automatiche;
• posta inviata;
• eliminati;
• alias;
• metodi di sicurezza.

32. Microsoft 365 ed Entra ID

32.1 Sign-in logs

Microsoft Entra registra gli accessi al tenant e mette a disposizione degli amministratori dettagli per interpretare esito, metodo, applicazione, IP, dispositivo e condizioni. Microsoft Entra — log di accesso

Acquisire:

- createdDateTime;
- userPrincipalName;
- appDisplayName;
- resourceDisplayName;
- ipAddress;
- location;
- clientAppUsed;
- deviceDetail;
- conditionalAccessStatus;
- authenticationRequirement;
- authenticationDetails;
- status;
- correlationId;
- riskLevel;
- riskState.

32.2 Audit logs

Verificare:

• modifiche password;
• reset MFA;
• aggiunta metodo;
• assegnazione ruolo;
• consenso applicazione;
• registrazione dispositivo;
• modifica gruppi;
• service principal;
• conditional access;
• app registration.

32.3 Mailbox

Microsoft raccomanda, per una casella compromessa, di esaminare sintomi, messaggi inviati, regole, inoltri e impostazioni, quindi revocare l’accesso e bonificare l’identità. Microsoft — rispondere a una casella compromessa

32.4 Audit delle email

Nelle licenze e configurazioni supportate, eventi come MailItemsAccessed possono contribuire a determinare l’accesso a messaggi mediante diversi protocolli e client. Disponibilità, dettaglio e conservazione dipendono dal piano e dalla configurazione del tenant. Microsoft Purview — investigare account compromessi

32.5 Business Email Compromise

Controllare:

[ ] regole;
[ ] forwarding;
[ ] delegated access;
[ ] send-as;
[ ] app consent;
[ ] login;
[ ] rischio utente;
[ ] messaggi inviati;
[ ] traccia messaggi;
[ ] conversazioni economiche;
[ ] allegati;
[ ] IBAN;
[ ] eliminazioni;
[ ] ruoli.

33. Apple Account e iCloud

Apple indica, in caso di sospetta compromissione:

• cambio password;
• verifica delle informazioni personali e di sicurezza;
• controllo dei dispositivi;
• rimozione dei dispositivi non riconosciuti;
• verifica di email e numeri associati;
• procedura di recupero quando l’utente non riesce ad accedere.

Apple — account compromesso

33.1 Acquisire prima della rimozione

- notifica di accesso;
- località mostrata;
- dispositivo;
- nome;
- modello;
- numero seriale disponibile;
- metodo di autenticazione;
- numeri fidati;
- email;
- servizi iCloud;
- browser attivi.

33.2 Controlli

• dispositivi;
• numeri fidati;
• email;
• passkey o chiavi;
• accesso web a iCloud;
• browser;
• Foto;
• Drive;
• Mail;
• backup;
• condivisioni familiari.

Apple consente anche di disconnettere i browser iCloud e, quando opportuno, disattivare l’accesso web ai dati iCloud. Apple — sicurezza dell’account

33.3 Esportazione dati

Gli utenti possono richiedere una copia di determinate categorie di dati associate al proprio Apple Account attraverso gli strumenti privacy del servizio. Apple — ottenere una copia dei dati

34. Facebook, Instagram e account Meta

34.1 Account compromesso

Meta mette a disposizione procedure dedicate per il recupero degli account compromessi e raccomanda, quando possibile, di avviare il recupero da un dispositivo già utilizzato in precedenza. Facebook — account compromesso

34.2 Attività di accesso

In Accounts Center è possibile verificare:

• dove l’account risulta connesso;
• sessioni;
• dispositivi;
• attività di login;
• autenticazione a due fattori;
• avvisi.

Meta descrive specifiche funzioni per rivedere le sessioni e disconnettere dispositivi non riconosciuti. Facebook — dove hai effettuato l’accesso

34.3 Acquisire

- username;
- ID;
- email;
- numero;
- sessioni;
- località;
- dispositivi;
- account collegati;
- pagine;
- Business Manager;
- amministratori;
- metodi di pagamento;
- inserzioni;
- app collegate;
- messaggi;
- modifiche profilo.

34.4 Pagine e inserzioni

Verificare:

• amministratori;
• partner;
• ruoli;
• account pubblicitario;
• campagne;
• pagamenti;
• pixel;
• app;
• fatture.

34.5 Esportazione

Meta consente di esportare informazioni e attività attraverso Accounts Center. L’archivio deve essere acquisito con verbale e hash, conservando le opzioni scelte e l’intervallo temporale richiesto. Facebook — download delle informazioni

35. Dropbox e altri servizi cloud

Dropbox consente di visualizzare dalla sezione sicurezza:

• computer collegati;
• sessioni web;
• dispositivi mobili;
• app collegate;
• attività.

Le sessioni e i dispositivi possono essere disconnessi da remoto; per gli account team sono disponibili ulteriori controlli amministrativi e report. Dropbox — dispositivi e sessioni

Acquisire:

- sessione;
- IP;
- località;
- data;
- browser;
- dispositivo;
- app;
- cartelle condivise;
- link;
- download;
- eliminazioni;
- ripristini;
- membri;
- amministratori.

Per altri servizi cloud applicare lo stesso modello:

identità
+ autenticazione
+ sessioni
+ app
+ file
+ condivisioni
+ log
+ amministrazione

36. Esportazioni dei dati

Le esportazioni possono includere:

• profilo;
• attività;
• messaggi;
• file;
• contatti;
• impostazioni;
• dispositivi;
• eventi.

36.1 Procedura

1. documentare l’account;
2. documentare le categorie selezionate;
3. documentare l’intervallo temporale;
4. documentare il formato;
5. acquisire l’email di conferma;
6. scaricare su workstation controllata;
7. conservare l’archivio originale;
8. calcolare l’hash;
9. estrarre una copia di lavoro;
10. conservare la struttura;
11. registrare eventuali errori;
12. non modificare i file originari.

36.2 Limiti

Un export:

• può essere generato dopo il contenimento;
• può non includere log interni;
• può riflettere dati già modificati;
• può avere date di generazione diverse dalle date degli eventi;
• può dipendere dalle opzioni;
• può escludere dati cancellati;
• può essere incompleto per limiti del provider.

Formula:

37. Acquisizione dello smartphone

Lo smartphone può contenere:

• notifiche;
• app di autenticazione;
• SMS;
• email;
• browser;
• cronologia;
• screenshot;
• sessioni;
• password salvate;
• app social;
• token;
• log;
• malware;
• profili di gestione;
• VPN.

Approfondimenti:

• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS

Non rimuovere subito l’account dal telefono prima di valutare:

• notifiche;
• dati locali;
• app;
• sessioni;
• configurazione MFA;
• database.

38. Acquisizione del computer

Il computer può contenere:

• cronologia;
• cache;
• cookie;
• session storage;
• local storage;
• password manager;
• estensioni;
• download;
• malware;
• file temporanei;
• email;
• VPN;
• log.

Approfondimenti:

• Analisi forense di computer Windows
• Analisi forense di macOS e Linux

Quando si sospetta un infostealer, evitare di usare il computer compromesso per impostare nuove password.

39. Browser forensics

Esaminare:

[ ] profili browser;
[ ] cronologia;
[ ] login data;
[ ] cookie;
[ ] sessioni;
[ ] estensioni;
[ ] download;
[ ] autofill;
[ ] password manager;
[ ] notifiche;
[ ] service worker;
[ ] storage;
[ ] sincronizzazione.

39.1 Estensioni

Un’estensione può:

• leggere pagine;
• accedere ai cookie;
• modificare contenuti;
• intercettare form;
• sincronizzare dati.

Acquisire:

• nome;
• ID;
• versione;
• sorgente;
• permessi;
• data installazione;
• file;
• stato.

39.2 Sincronizzazione

Un profilo sincronizzato può trasferire:

• password;
• estensioni;
• cronologia;
• segnalibri;
• impostazioni.

La presenza di dati su più dispositivi non dimostra necessariamente che ogni dispositivo li abbia creati.

40. Analisi di phishing

Se l’accesso può derivare da phishing, acquisire:

• email originale;
• EML;
• header;
• URL;
• dominio;
• pagina;
• certificato;
• screenshot;
• allegato;
• cronologia browser;
• download;
• data;
• credenziali modificate;
• evento di login.

Approfondimenti:

• Analisi forense di email e header
• Acquisizione di pagine web e contenuti online

Non visitare il link sospetto da una workstation ordinaria collegata agli account aziendali.

41. Malware e infostealer

Possibili indicatori:

• processi anomali;
• persistenza;
• attività EDR;
• file scaricati;
• estensioni sospette;
• accessi ai profili browser;
• archivi temporanei;
• esfiltrazione;
• connessioni;
• rilevazioni antivirus.

Procedura:

1. isolare il dispositivo;
2. non spegnerlo automaticamente senza valutazione;
3. acquisire memoria quando pertinente;
4. acquisire disco;
5. raccogliere log EDR;
6. verificare browser;
7. estrarre indicatori;
8. correlare con gli accessi;
9. bonificare dopo l’acquisizione;
10. cambiare credenziali da dispositivo sicuro.

Vedere il Capitolo 21 — Incident response forense e ransomware.

42. Comandi di acquisizione e normalizzazione

42.1 Hash dei log

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\entra-signins.csv" |
  Format-List |
  Out-File ".\entra-signins.sha256.txt"

42.2 Ordinamento CSV in PowerShell

Import-Csv ".\entra-signins.csv" |
  Sort-Object createdDateTime |
  Export-Csv ".\entra-signins-ordinato.csv" `
    -NoTypeInformation `
    -Encoding UTF8

42.3 Filtrare eventi per utente

Import-Csv ".\entra-signins.csv" |
  Where-Object {
    $_.userPrincipalName -eq "utente@example.invalid"
  } |
  Sort-Object createdDateTime |
  Export-Csv ".\utente-signins.csv" `
    -NoTypeInformation `
    -Encoding UTF8

42.4 Estrarre dati JSON con jq

jq -r '
  .value[] |
  [
    .createdDateTime,
    .userPrincipalName,
    .appDisplayName,
    .ipAddress,
    .clientAppUsed,
    .status.errorCode
  ] |
  @csv
' signins.json > signins.csv

42.5 Raccogliere indirizzi IP unici

jq -r '.value[].ipAddress' signins.json \
  | sort \
  | uniq -c \
  | sort -nr \
  > ip_frequency.txt

Gli output derivati devono essere conservati insieme al file sorgente e ai comandi utilizzati.

43. Esempi Microsoft 365 in sola lettura

Le seguenti operazioni sono destinate esclusivamente ad amministratori autorizzati.

43.1 Regole della casella

Connect-ExchangeOnline

Get-InboxRule `
  -Mailbox "utente@example.invalid" |
  Select-Object Name,Enabled,Priority,Description |
  Export-Csv ".\inbox-rules.csv" `
    -NoTypeInformation `
    -Encoding UTF8

43.2 Inoltro

Get-Mailbox `
  -Identity "utente@example.invalid" |
  Select-Object `
    DisplayName,
    ForwardingAddress,
    ForwardingSmtpAddress,
    DeliverToMailboxAndForward |
  Export-Csv ".\mailbox-forwarding.csv" `
    -NoTypeInformation `
    -Encoding UTF8

43.3 Permessi

Get-MailboxPermission `
  -Identity "utente@example.invalid" |
  Export-Csv ".\mailbox-permissions.csv" `
    -NoTypeInformation `
    -Encoding UTF8

43.4 Accessi Entra tramite Microsoft Graph

Connect-MgGraph -Scopes "AuditLog.Read.All"

Get-MgAuditLogSignIn -All |
  Select-Object `
    CreatedDateTime,
    UserPrincipalName,
    AppDisplayName,
    IpAddress,
    ClientAppUsed,
    CorrelationId |
  Export-Csv ".\entra-signins.csv" `
    -NoTypeInformation `
    -Encoding UTF8

Registrare:

• identità dell’amministratore;
• privilegi;
• ora;
• versione moduli;
• comandi;
• errori;
• hash degli output.

44. Analisi delle email di sicurezza

Conservare in formato originale:

• nuovo accesso;
• password modificata;
• recupero;
• numero aggiunto;
• app autorizzata;
• esportazione;
• pagamento;
• dispositivo;
• MFA.

Per ogni email:

- Message-ID;
- Date;
- Received;
- From;
- Return-Path;
- DKIM;
- SPF;
- DMARC;
- link;
- destinatario;
- contenuto;
- allegati.

Una falsa email di sicurezza può essere essa stessa il phishing.

Non utilizzare il pulsante presente nel messaggio prima di aver verificato:

• dominio;
• header;
• link;
• autenticazione;
• contesto.

45. Timeline degli accessi

Esempio:

La timeline forense deve distinguere:

• dato osservato;
• conversione temporale;
• deduzione;
• dichiarazione;
• evento esterno.

46. Matrice delle evidenze

47. Attribuzione a una persona fisica

47.1 Elementi deboli

• nome account;
• fotografia;
• IP isolato;
• località;
• dispositivo generico;
• email;
• numero intestato;
• stile di scrittura.

47.2 Elementi da correlare

- assegnazione IP nel momento esatto;
- dispositivo acquisito;
- browser;
- cronologia;
- token;
- dati dell’operatore;
- accessi fisici;
- account collegati;
- messaggi;
- pagamenti;
- log aziendali;
- comportamento successivo.

47.3 Formula

48. Dati detenuti dal provider

Il provider può detenere:

• registrazione;
• recovery history;
• IP;
• sessioni;
• dispositivi;
• log;
• ticket;
• fatturazione;
• modifiche;
• dati cancellati;
• informazioni amministrative.

La disponibilità dipende da:

• servizio;
• contratto;
• piano;
• conservazione;
• area geografica;
• tipo di account;
• procedura legale;
• tempo trascorso.

Il perito privato non può ottenere dati mediante accesso abusivo o falsa identità.

Può:

• preservare ID;
• individuare provider;
• descrivere i dati utili;
• supportare il legale;
• analizzare quanto acquisito lecitamente.

49. Data breach aziendale

49.1 Domande iniziali

1. Sono presenti dati personali?
2. Quali categorie?
3. Quante persone?
4. Il dato era cifrato?
5. È stato soltanto accessibile o anche esportato?
6. Per quanto tempo?
7. Quali privilegi aveva l’account?
8. Vi sono dati particolari?
9. Sono coinvolti minori?
10. Esiste rischio di frode o impersonificazione?

49.2 Registro

Documentare:

• momento della conoscenza;
• valutazione;
• fonti;
• conseguenze;
• contenimento;
• decisione;
• eventuale notifica;
• motivazione.

Il GDPR consente una notifica per fasi quando tutti i dettagli non sono immediatamente disponibili, purché gli aggiornamenti siano forniti senza ulteriore ingiustificato ritardo. Garante privacy — data breach

49.3 Separare i tempi

data dell’evento
≠
data della rilevazione
≠
data della conoscenza qualificata
≠
data della notifica

La definizione giuridica del momento di conoscenza deve essere valutata con DPO e legale.

50. Caso pratico 1 — Accesso Gmail segnalato a Roma

Scenario

Un cliente di Roma riceve una notifica relativa a un accesso da Bologna.

Risultati

- accesso da rete mobile;
- stesso modello di telefono;
- orario coincidente con viaggio in treno;
- indirizzo IP appartenente al proprio carrier;
- nessuna modifica password;
- nessuna nuova sessione;
- nessuna app sconosciuta.

Conclusione

51. Caso pratico 2 — Casella Microsoft 365 e frode su fattura

Scenario

Un’azienda romana scopre che un cliente ha ricevuto una fattura con IBAN differente.

Risultati

- phishing ricevuto dal dipendente;
- login riuscito;
- MFA approvata;
- regola inbox;
- inoltro esterno;
- accesso a conversazioni commerciali;
- messaggio con coordinate bancarie alterate;
- eliminazione della risposta del cliente.

Conclusione

52. Caso pratico 3 — Instagram compromesso

Scenario

Una professionista di Roma perde l’accesso al profilo.

Risultati

- email di phishing;
- password modificata;
- indirizzo di recupero sostituito;
- nuovo dispositivo;
- pubblicazioni promozionali;
- account pubblicitario collegato.

Attività

1. acquisizione delle email;
2. documentazione del profilo;
3. avvio recupero da dispositivo noto;
4. revoca sessioni;
5. rimozione del nuovo recapito;
6. verifica inserzioni;
7. esportazione dati;
8. timeline.

Conclusione

53. Caso pratico 4 — Dispositivo sconosciuto nell’Apple Account

Scenario

Un cliente di Roma vede un Mac sconosciuto nell’elenco dei dispositivi.

Risultati

• nome generico;
• dispositivo aziendale precedentemente utilizzato;
• seriale corrispondente all’inventario;
• sessione non più attiva;
• nessuna modifica recovery.

Conclusione

54. Caso pratico 5 — Credenziali condivise in azienda

Scenario

Un’impresa romana sospetta che un ex dipendente abbia utilizzato una casella condivisa.

Risultati

- password nota a cinque persone;
- nessuna MFA;
- account generico;
- accessi da VPN aziendale;
- IP condiviso;
- log endpoint incompleti;
- password non cambiata alla cessazione.

Conclusione

55. Caso pratico 6 — Sessione sottratta

Scenario

Un avvocato di Roma cambia la password, ma continuano ad apparire attività sospette.

Risultati

- computer infetto;
- browser con sessione persistente;
- nessun nuovo login evidente;
- attività mediante token;
- app OAuth sconosciuta.

Conclusione

56. Caso pratico 7 — Consenso OAuth

Scenario

Un dipendente autorizza un’app presentata come visualizzatore di documenti.

Risultati

• nessuna password sottratta accertata;
• app autorizzata;
• permessi su email e file;
• accessi API;
• download di documenti;
• revoca successiva.

Conclusione

57. Caso pratico 8 — File Dropbox condivisi

Scenario

Uno studio professionale di Roma rileva file disponibili tramite link pubblico.

Risultati

- link creato da account interno;
- file scaricabile senza autenticazione;
- impossibilità di identificare tutti i download;
- link successivamente disattivato;
- account non compromesso.

Conclusione

58. Errori da evitare

Errore 1 — Cambiare password senza acquisire nulla

Si perdono informazioni visibili su sessioni e dispositivi.

Errore 2 — Ritardare il contenimento

L’attaccante può continuare ad agire.

Errore 3 — Usare il dispositivo infetto

Le nuove credenziali possono essere sottratte.

Errore 4 — Revocare soltanto la password

Restano token, app, regole o passkey.

Errore 5 — Confondere tentativo e login riuscito

Sono eventi differenti.

Errore 6 — Confondere login e accesso ai dati

Un login non dimostra quali dati siano stati letti.

Errore 7 — Attribuire l’IP a una persona

L’IP identifica una connessione o infrastruttura.

Errore 8 — Fidarsi della località

È una stima.

Errore 9 — Ignorare le regole inbox

Possono nascondere messaggi.

Errore 10 — Ignorare OAuth

L’app può operare senza conoscere la password.

Errore 11 — Non verificare i recovery channel

L’attaccante può recuperare di nuovo l’account.

Errore 12 — Non controllare gli amministratori

Pagine e tenant possono avere nuovi ruoli.

Errore 13 — Cancellare email di sicurezza

Sono reperti importanti.

Errore 14 — Non acquisire gli header

Una notifica può essere falsa.

Errore 15 — Non considerare la sessione

Può spiegare attività dopo il cambio password.

Errore 16 — Non analizzare il computer

La causa può essere un infostealer.

Errore 17 — Formattare il dispositivo

Si distruggono le tracce.

Errore 18 — Usare screenshot ritagliati

Mancano URL, data e contesto.

Errore 19 — Non documentare il contenimento

Le modifiche diventano indistinguibili dagli eventi precedenti.

Errore 20 — Considerare l’export completo

Può essere parziale.

Errore 21 — Non verificare il fuso

La timeline può risultare errata.

Errore 22 — Confondere dispositivo dichiarato ed esemplare fisico

Il modello può essere generico o modificabile.

Errore 23 — Esporre token nella relazione

Si crea un rischio ulteriore.

Errore 24 — Trasmettere OTP al consulente

Il consulente non deve richiederli.

Errore 25 — Accedere all’account dell’autore sospetto

È un’attività non autorizzata.

Errore 26 — Promettere l’identificazione

I dati decisivi possono essere presso il provider.

Errore 27 — Ignorare gli obblighi privacy

Un account aziendale può coinvolgere dati personali.

Errore 28 — Non coinvolgere il DPO

La valutazione del data breach può richiederlo.

Errore 29 — Non verificare altri account

La stessa password può essere stata riutilizzata.

Errore 30 — Concludere “nessun accesso” per assenza di log

I log possono essere scaduti, incompleti o non previsti.

59. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] titolare;
[ ] account;
[ ] incarico;
[ ] amministratore;
[ ] perimetro;
[ ] trattamento dati;
[ ] riservatezza;
[ ] limiti.

Fase 2 — Valutazione del rischio

[ ] accesso attivo;
[ ] pagamenti;
[ ] cancellazioni;
[ ] dati personali;
[ ] privilegi amministrativi;
[ ] stalking;
[ ] account collegati;
[ ] compromissione aziendale.

Fase 3 — Dispositivo affidabile

[ ] workstation pulita;
[ ] rete affidabile;
[ ] browser dedicato;
[ ] registrazione ora;
[ ] profilo separato;
[ ] nessuna estensione non necessaria.

Fase 4 — Acquisizione minima

[ ] notifiche;
[ ] login;
[ ] sessioni;
[ ] dispositivi;
[ ] MFA;
[ ] recovery;
[ ] app;
[ ] regole;
[ ] condivisioni.

Fase 5 — Contenimento

[ ] password;
[ ] revoca sessioni;
[ ] rimozione dispositivi;
[ ] reset MFA;
[ ] revoca token;
[ ] revoca OAuth;
[ ] rimozione regole;
[ ] recupero account.

Fase 6 — Acquisizione provider

[ ] audit log;
[ ] login log;
[ ] admin log;
[ ] mailbox log;
[ ] cloud activity;
[ ] export;
[ ] ticket;
[ ] email.

Fase 7 — Endpoint

[ ] smartphone;
[ ] computer;
[ ] browser;
[ ] malware;
[ ] notifiche;
[ ] app MFA;
[ ] cronologia;
[ ] download.

Fase 8 — Analisi

[ ] IP;
[ ] dispositivo;
[ ] sessione;
[ ] autenticazione;
[ ] azioni;
[ ] persistenza;
[ ] dati accessibili;
[ ] dati esportati;
[ ] correlazioni.

Fase 9 — Timeline

[ ] ora originale;
[ ] UTC;
[ ] login;
[ ] MFA;
[ ] regola;
[ ] accesso dati;
[ ] messaggi;
[ ] contenimento;
[ ] ripristino.

Fase 10 — Obblighi

[ ] data breach;
[ ] GDPR;
[ ] NIS;
[ ] assicurazione;
[ ] contratto;
[ ] provider;
[ ] autorità;
[ ] interessati.

Fase 11 — Hardening

[ ] password uniche;
[ ] password manager;
[ ] MFA;
[ ] passkey;
[ ] chiavi;
[ ] recovery;
[ ] account admin separati;
[ ] logging;
[ ] alert;
[ ] formazione.

Fase 12 — Relazione

[ ] materiale;
[ ] metodo;
[ ] risultati;
[ ] timeline;
[ ] azioni;
[ ] impatto;
[ ] attribuzione;
[ ] limiti;
[ ] allegati;
[ ] hash.

60. Checklist finale

Sicurezza

[ ] account sotto controllo;
[ ] dispositivo sicuro;
[ ] password cambiata;
[ ] sessioni revocate;
[ ] MFA verificata;
[ ] recovery verificato;
[ ] app revocate;
[ ] endpoint analizzato.

Prova

[ ] notifiche;
[ ] email originali;
[ ] log;
[ ] dispositivi;
[ ] sessioni;
[ ] regole;
[ ] export;
[ ] hash;
[ ] verbale.

Email

[ ] inoltri;
[ ] filtri;
[ ] deleghe;
[ ] alias;
[ ] sent;
[ ] deleted;
[ ] app;
[ ] protocolli.

Cloud

[ ] file;
[ ] download;
[ ] link;
[ ] condivisioni;
[ ] eliminazioni;
[ ] versioni;
[ ] amministratori.

Analisi

[ ] timeline;
[ ] IP;
[ ] geolocalizzazione;
[ ] user agent;
[ ] sessione;
[ ] OAuth;
[ ] azioni;
[ ] limiti.

Compliance

[ ] dati personali;
[ ] registro breach;
[ ] DPO;
[ ] legale;
[ ] notifica;
[ ] NIS;
[ ] comunicazioni.

61. Output minimo

1. incarico;
2. verbale;
3. registro reperti;
4. screenshot notifiche;
5. elenco sessioni;
6. elenco dispositivi;
7. attività di sicurezza;
8. login log;
9. audit log;
10. regole email;
11. inoltri;
12. deleghe;
13. app OAuth;
14. metodi di autenticazione;
15. canali di recupero;
16. esportazione account;
17. acquisizione email;
18. acquisizione endpoint;
19. indicatori di compromissione;
20. timeline;
21. matrice evidenze;
22. hash;
23. registro del contenimento;
24. valutazione dati esposti;
25. relazione;
26. allegati tecnici;
27. hash degli output.

62. Struttura della relazione tecnica

62.1 Incarico

• committente;
• titolare;
• account;
• quesito;
• autorizzazione;
• limiti.

62.2 Materiale

• notifiche;
• log;
• dispositivi;
• email;
• export;
• file;
• hash.

62.3 Metodo

• ambiente;
• strumenti;
• versioni;
• procedure;
• contenimento;
• conservazione.

62.4 Risultati

• eventi;
• sessioni;
• IP;
• dispositivi;
• MFA;
• app;
• regole;
• azioni;
• dati.

62.5 Timeline

• accesso;
• persistenza;
• attività;
• rilevazione;
• contenimento;
• recupero.

62.6 Attribuzione

• elementi;
• correlazioni;
• alternative;
• limiti.

62.7 Impatto

• account;
• dati;
• messaggi;
• file;
• servizi;
• soggetti.

62.8 Conclusioni

Risposte proporzionate al quesito.

63. Modelli di frasi tecniche

63.1 Accesso riuscito

63.2 Tentativo fallito

63.3 IP

63.4 Località

63.5 Dispositivo

63.6 Sessione

63.7 MFA

63.8 OAuth

63.9 Regola email

63.10 File cloud

63.11 Condivisione

63.12 Account condiviso

63.13 Assenza di log

63.14 Data breach

63.15 Attribuzione

63.16 Conclusione limitata

64. Immagini e figure suggerite

65. Riferimenti tecnici e normativi esterni

1. Articolo 615-ter del codice penale — Accesso abusivo a un sistema informatico o telematico.
2. Articolo 615-quater del codice penale — Codici e mezzi atti all’accesso.
3. Regolamento UE 2016/679, articoli 33 e 34 — Data breach.
4. Garante per la protezione dei dati personali — Violazioni di dati personali.
5. Decreto legislativo n. 138/2024, articolo 25 — Notifica incidenti NIS.
6. NIST SP 800-61 Rev. 3 — Incident Response Recommendations and Considerations.
7. NIST SP 800-63-4 — Digital Identity Guidelines.
8. Google — Protezione di un account compromesso e revisione dei dispositivi.
9. Gmail — Ultima attività dell’account.
10. Google Workspace — User log events.
11. Google Workspace — OAuth log events.
12. Google Workspace — Identificazione e messa in sicurezza degli account compromessi.
13. Microsoft — Attività recenti dell’account.
14. Microsoft — Risposta a una casella compromessa.
15. Microsoft Entra — Sign-in logs e rischio identità.
16. Apple — Account compromesso e dispositivi associati.
17. Meta — Recupero account e sessioni attive.
18. Dropbox — Dispositivi, sessioni e app collegate.

66. Collegamenti interni consigliati

Capitolo precedente

• Diffamazione online, cyberbullismo, stalking digitale e revenge porn

Capitolo successivo

• Truffe online, bonifici fraudolenti e financial cybercrime

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
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Incident response forense e ransomware
• Dipendente infedele, sottrazione dati e uso di USB
• Cloud forensics: Google, Microsoft, Dropbox e backup
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

67. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/analisi-smartphone-computer/
/servizi/acquisizione-pagine-web-social/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

perizia per accesso abusivo a un account a Roma
analisi di una casella email compromessa
verifica dei log di accesso
analisi delle sessioni attive
acquisizione di notifiche di sicurezza
verifica di account Gmail compromesso
analisi Microsoft 365 e Entra ID
recupero tecnico di un profilo social
verifica dei dispositivi collegati
analisi delle autorizzazioni OAuth
perizia su file cloud scaricati
ricostruzione della compromissione account

68. Box commerciale finale

Hai ricevuto una notifica di accesso o perso il controllo di un account?

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

[ ] account Gmail;
[ ] Google Workspace;
[ ] Outlook.com;
[ ] Microsoft 365;
[ ] Microsoft Entra ID;
[ ] Apple Account e iCloud;
[ ] Facebook;
[ ] Instagram;
[ ] LinkedIn;
[ ] Dropbox;
[ ] OneDrive;
[ ] altri servizi cloud.

L’attività può comprendere:

• acquisizione di notifiche e log;
• verifica degli accessi;
• analisi di IP e dispositivi;
• ricostruzione delle sessioni;
• verifica dei fattori MFA;
• controllo delle applicazioni OAuth;
• analisi di regole e inoltri email;
• acquisizione di smartphone e computer;
• ricostruzione temporale;
• valutazione tecnica dei dati potenzialmente esposti;
• supporto alla gestione del data breach;
• relazione tecnica;
• supporto al legale e al CTP.

69. Conclusione del capitolo

L’analisi di un accesso abusivo non si esaurisce nella lettura di una notifica.

Una corretta attività informatico-forense deve distinguere:

- tentativo;
- autenticazione;
- sessione;
- token;
- dispositivo;
- indirizzo IP;
- località;
- azione;
- account;
- persona fisica.

Deve inoltre verificare se l’attaccante abbia lasciato forme di persistenza attraverso:

• regole;
• inoltri;
• deleghe;
• app OAuth;
• passkey;
• dispositivi;
• recovery channel;
• ruoli amministrativi;
• link cloud.

Nei casi aziendali, l’indagine deve determinare non soltanto come l’account sia stato compromesso, ma anche:

• quali dati fossero accessibili;
• quali azioni siano state eseguite;
• per quanto tempo;
• con quali conseguenze;
• quali obblighi organizzativi e normativi possano derivarne.

La formula da ricordare è:

Il contenimento non deve essere ritardato quando il rischio è attivo.

La conservazione della prova non deve però essere dimenticata:

documentare
→ contenere
→ acquisire
→ analizzare
→ correlare
→ riferire
→ rafforzare

70. Anticipazione del capitolo successivo

Nel prossimo capitolo il manuale affronterà una delle conseguenze più frequenti della compromissione di account email e aziendali:

Capitolo 19 — Truffe online, bonifici fraudolenti e financial cybercrime

Saranno trattati:

• Business Email Compromise;
• sostituzione dell’IBAN;
• phishing bancario;
• false fatture;
• pagamenti con carta;
• wallet e criptovalute;
• ricevute contraffatte;
• account marketplace;
• chat e social engineering;
• acquisizione delle comunicazioni;
• timeline dei pagamenti;
• rapporti con banca, provider e piattaforme;
• limiti dell’attribuzione tecnica;
• documentazione forense delle perdite economiche.

Continua con il Capitolo 19 — Truffe online, bonifici fraudolenti e financial cybercrime →