Hai ricevuto l’e‑mail “Action Required – Microsoft Email Data Sharing Request”? Non è (di per sé) phishing: fa parte del processo con cui Microsoft sta consegnando ai clienti le conversazioni e‑mail lette dal gruppo APT “Midnight Blizzard”. In questa guida trovi verifiche tecniche, playbook e modelli operativi.
Cos’è l’e‑mail “Microsoft Email Data Sharing Request”
Da metà 2024 diverse organizzazioni hanno ricevuto un messaggio con oggetto “Action Required – Microsoft Email Data Sharing Request”. Nel testo si fa riferimento all’attacco a Microsoft da parte del gruppo Midnight Blizzard (anche noto come APT29/Nobelium) e si afferma che gli attaccanti hanno letto alcune conversazioni tra Microsoft e l’organizzazione. L’e‑mail chiede di indicare il Tenant ID e gli indirizzi delle persone autorizzate a esaminare il materiale, rimandando a un portale “sicuro” su https://purviewcustomer.powerappsportals.com/.
Il messaggio, a prima vista, ha tutto il look‑and‑feel del phishing: dominio “Power Apps” inusuale, branding quasi assente, richiesta di compilare un modulo. Eppure, come confermato da analisi indipendenti e da comunicati Microsoft, si tratta di una comunicazione legittima che fa parte del programma di notifica ai clienti impattati [3].
Perché sembra phishing ma non lo è
- Dominio atipico: l’URL usa un sottodominio di Power Apps. È comunque un’infrastruttura Microsoft; il certificato TLS appartiene a Microsoft e il portale è stato impiegato per gestire il flusso di consegna dati ai clienti [1].
- Branding minimale: il messaggio ha una veste grafica scarna e un testo burocratico; ciò ha portato molti team a segnalarlo come spam/phishing [2].
- Richiesta di dati sensibili: non vengono chieste credenziali, ma il Tenant ID e gli indirizzi dei referenti. Il motivo è abilitare un accesso mirato e tracciato alle e‑mail esfiltrate.
- Coerenza con i fatti: Microsoft ha reso pubblica la compromissione di un tenant interno a fine 2023 e l’esfiltrazione di una porzione limitata di e‑mail, alcune con conversazioni con i clienti; ha inoltre promesso notifiche e misure di rimedio [3].
Playbook operativo immediato
Se l’e‑mail è arrivata alla tua organizzazione, applica subito questi passaggi. Sono pensati per essere concreti, rapidi e documentabili.
| Cosa fare | Perché |
|---|---|
| Verificare l’autenticità tecnica (header completi, SPF/DKIM/DMARC, Message‑ID, catena TLS del portale indicato). | Il messaggio risulta autentico; il dominio Power Apps e l’assenza di branding lo rendono sospetto agli occhi di chi filtra manualmente [1]. |
| Coinvolgere il proprio Customer Success Account Manager o aprire un ticket nel portale Microsoft 365 citando “Microsoft Email Data Sharing”. | Fornisce conferma ulteriore, contestualizza il caso e accelera la nomina dei revisori interni/esterni. |
| Compilare il modulo solo dopo aver designato i referenti interni corretti (Global/Privileged Admin, Security, Legal). | Il link consente l’accesso a materiale sensibile: serve personale con privilegi e competenze adeguate e un processo documentato. |
| Analizzare le e‑mail ricevute da Microsoft per individuare credenziali, token, dati personali e terze parti coinvolte; predisporre contromisure (reset, revoche, avvisi). | Riduce il rischio di impieghi secondari del materiale esfiltrato (spear phishing, thread hijacking, estorsioni). |
| Verificare cartelle spam e caselle “break‑glass” e inoltrare l’avviso ai team competenti. | Gli avvisi sono stati spesso recapitati agli amministratori globali o caselle poco presidiate; vari casi sono finiti nello spam [2]. |
Verifica tecnica dell’autenticità
Prima di interagire con il portale o fornire qualsiasi dato, esegui due diligence tecnica. Ecco una procedura chiara e ripetibile.
Analisi degli header del messaggio
- Recupera gli header completi dal tuo client: in Outlook/M365 “Visualizza origine messaggio”.
- Controlla le catene di ricezione (
Received:) per assicurarti che il messaggio provenga da server Microsoft legittimi (*.protection.outlook.com/outbound.protection.outlook.com). - Valuta SPF/DKIM/DMARC in
Authentication-Results:Authentication-Results: yourdomain.tld; spf=pass smtp.mailfrom=microsoft.com; dkim=pass (signature was verified) header.d=microsoft.com; dmarc=pass (p=reject) header.from=microsoft.com - Esamina il
Message-ID(dominio coerente con Microsoft) e possibili custom headers usati per campagne di notifica. - Confronta contenuto e fraseologia con altre notifiche ufficiali ricevute in passato e con la cronologia dei ticket aperti con Microsoft.
Controllo del portale Power Apps indicato
- Apri l’URL solo da un ambiente aziendale sicuro, senza disabilitare controlli di sicurezza, e verifica il certificato TLS:
- Il certificato deve essere emesso a favore di Microsoft e la catena deve risultare valida.
- Il Common Name/Subject Alternative Name deve includere il dominio del portale.
- Autentica l’accesso con account di servizio o amministrativi protetti (MFA obbligatoria, sessione isolata), mai con account personali.
- Evita di fornire informazioni eccedenti rispetto a quanto richiesto (niente credenziali, niente segreti).
Convalida laterale con Microsoft
- Contatta il tuo Customer Success Account Manager o apri un ticket dal centro amministrazione, citando esplicitamente “Microsoft Email Data Sharing”.
- Richiedi il codice del caso e il riferimento interno per correlare l’e‑mail al ticket.
- Se la tua organizzazione ha un contratto di supporto Premier/Unified, coinvolgi il TAM/Support Account Manager.
Designazione dei revisori e principio del privilegio minimo
La pagina di raccolta dati serve a nominare i revisori che potranno accedere alle conversazioni esfiltrate. Definisci ruoli chiari:
- Owner operativo (Security/IR): coordina le attività di analisi, definisce il perimetro e approva azioni correttive.
- Amministratore M365 (Global/Privileged): gestisce l’accesso, i gruppi, i permessi e l’audit.
- Referente legale: valuta impatti su privacy, contratti, eventuali obblighi di notifica.
- Referente business (solo se necessario): fornisce contesto su progetti o clienti citati nelle e‑mail.
Applica least privilege: accesso temporaneo, registrato, con MFA e sessioni approvate. Chiudi l’accesso appena conclusa l’analisi.
Accesso ai dati esfiltrati in modo sicuro
- Ambiente: usa un device aziendale conforme, con EDR attivo, aggiornato e cifrato; se possibile, una VM dedicata all’analisi.
- Download: scarica i file soltanto sul repository designato (es. area IR evidence con versioning e auditing); evita cartelle locali improvvisate.
- Archiviazione: conserva gli artefatti in uno spazio con controllo accessi a ruoli, log di accesso e retention predefinita.
- Tracciamento: registra chi ha visto cosa e quando; allega hash dei file per integrità.
Analisi delle e‑mail esfiltrate
Concentrati su contenuti che, se noti a terzi, abilitano attacchi a catena o rischi regolamentari. Una griglia di lavoro efficace include:
| Elemento | Cosa cercare | Azioni consigliate |
|---|---|---|
| Credenziali e segreti | Password in chiaro, token API, chiavi SSH, stringhe di connessione, allegati con credenziali. | Rotazione immediata, segnalazione a proprietari di sistema, aggiornamento vault. |
| Token/OAuth e applicazioni | Riferimenti a app enterprise, grant offline_access, redirect URL. | Revisione delle app, revoca dei consensi sospetti, Conditional Access più restrittiva. |
| Dati personali | PII/PHI, dati clienti, elenchi di contatto, numeri di pratica. | Valutazione Legale/Privacy, eventuali notifiche, minimizzazione copie. |
| Thread con terze parti | Conversazioni che potrebbero essere riusate per thread hijacking / business email compromise. | Avvisi mirati ai contatti, raccomandazioni MFA e verifica pagamenti. |
| Dettagli infrastrutturali | IP, nomi host, topologie, screenshot di console, piani progetto. | Riconsiderare l’esposizione pubblica, segmentazione, hardening dove necessario. |
Azioni di risposta e mitigazione
- Identità: reset forzato password per gli utenti esposti; revoca dei refresh tokens; controllo di sessioni persistenti e registrazioni MFA.
- Applicazioni: revisione di tutti gli Enterprise Applications con permessi elevati; rimozione di app non usate; blocco del consenso utente dove possibile.
- Posta: ricerca di regole di inoltro sospette; disabilitazione degli inoltri automatici verso domini esterni non autorizzati; verifica di inbox rules malevole.
- Rete: se emergono endpoint citati nelle e‑mail, verifica esposizioni e rinnova certificati/chiavi eventualmente inclusi in thread.
- Terze parti: notifica proattiva ai partner menzionati e allerta contro possibili reply‑chain phishing.
Raccolta evidenze e audit M365
- Unified Audit Log: consulta attività di accesso/posta per gli utenti coinvolti nel periodo dicembre 2023 – giugno 2024 e successivo.
- Defender for Office 365: controlla detections su messaggi correlati e attack simulation per formazione mirata.
- Purview: se emergono dati regolamentati, aggiorna policy DLP e labels di protezione.
Domande frequenti
Il Tenant ID è un segreto? No. Non è progettato come segreto di sicurezza (è spesso ricavabile). Va comunque trattato con cura e condiviso solo con canali ufficiali.
Posso ignorare l’e‑mail? Sconsigliato. Potresti perdere la consegna delle conversazioni esfiltrate e non mitigare i rischi discendenti.
Perché non è stata usata la messaggistica del tenant? Microsoft ha scelto un portale dedicato per gestire in modo centralizzato e tracciato la condivisione con referenti nominati [1].
È un data breach notificabile? Dipende dal contenuto delle e‑mail che riguardano la tua organizzazione. Coinvolgi il legale per le valutazioni su privacy/contratti/regolamenti.
Contesto sulla minaccia Midnight Blizzard
Midnight Blizzard è un gruppo APT associato a interessi russi, già noto per SolarWinds. Nel novembre 2023 ha compromesso un tenant di test Microsoft; tra dicembre 2023 e gennaio 2024 ha esfiltrato una percentuale ridotta di e‑mail interne, alcune contenenti conversazioni con clienti. Il 19 gennaio 2024 Microsoft ha pubblicato un post MSRC che descrive l’incidente, le indagini e gli impegni di notifica ai clienti [3]. A partire da giugno 2024 sono state inviate comunicazioni con consegna delle conversazioni ai clienti interessati; l’aspetto delle e‑mail e l’uso del portale Power Apps hanno generato confusione e molte segnalazioni di phishing [2].
Confronto rapido: phishing vs notifica Microsoft
| Indicatore | Notifica Microsoft | Phishing tipico |
|---|---|---|
| Dominio | Sottodominio Power Apps Microsoft; certificato TLS valido. | Domini typosquatting o URL offuscati/accorciati. |
| Richiesta | Tenant ID e mail dei referenti autorizzati. | Credenziali, OTP, pagamenti, allegati eseguibili. |
| Allineamento storico | Coerente con dichiarazioni pubbliche sul breach [3]. | Nessun riferimento verificabile o eventi inventati. |
| Branding | Minimale, sobrio, talvolta “grezzo”. | Branding spesso imitato, ma errori ortografici e formattazioni strane. |
| Tracciabilità | Possibilità di correlare a ticket/case ufficiali. | Nessun canale ufficiale di verifica. |
Procedura dettagliata di verifica
Passi consigliati
- Centralizza l’e‑mail in un case IR con numero interno e proprietario.
- Acquisisci gli header completi e salva l’originale (.eml/.msg) su repository evidenze.
- Esegui message trace per confermare la catena di recapito.
- Verifica SPF/DKIM/DMARC come descritto sopra.
- Apri il ticket Microsoft e ottieni conferma formale dell’associazione al caso.
- Nomina i revisori e raccogli il loro consenso informato sulla gestione dei dati.
- Accedi al portale e scarica i materiali attenendoti alle pratiche di sicurezza.
- Esegui analisi dei contenuti e attua le mitigazioni prioritarie.
Come trovare il Tenant ID in modo sicuro
Evita copie manuali da pagine pubbliche; preferisci metodi tracciati:
# Microsoft Graph PowerShell
Connect-MgGraph -Scopes Organization.Read.All
Get-MgOrganization | Select-Object DisplayName, Id, VerifiedDomains
In alternativa, dagli strumenti di amministrazione Azure/M365 il Tenant ID è visibile nelle proprietà dell’organizzazione.
Comunicazioni interne ed esterne
Linee guida
- Trasparenza con il management: stato, rischi, tappe successive.
- Minimizzazione dei dettagli verso platee ampie: condividi solo ciò che serve, evitando di re‑esporre dati sensibili.
- Allineamento legale: tutte le comunicazioni esterne (clienti/fornitori) devono passare dal legale.
Modello sintetico per notificare i team interni
Oggetto: Notifica Microsoft – Condivisione e‑mail esfiltrate (Midnight Blizzard)
Microsoft ci ha notificato la disponibilità di conversazioni e‑mail tra loro e la nostra organizzazione,
lette da attori APT nel 2023/2024. La comunicazione usa un portale Power Apps ed è legittima.
Azioni:
1. Security/IR e Admin M365 nomineranno i revisori autorizzati.
2. I revisori accederanno al portale per scaricare e analizzare i materiali.
3. Seguirà piano di mitigazione per eventuali credenziali/dati coinvolti.
Per domande: – Referente: .Checklist pronta all’uso
- Header originali acquisiti e verificati.
- Ticket Microsoft aperto e correlato all’e‑mail.
- Revisori designati (Security, Admin, Legal) con accesso tracciato.
- Download dei materiali su repository sicuro con hashing.
- Analisi completata con elenco rischi e piano azioni.
- Rotazione/reset di credenziali e revoca token interessati.
- Comunicazioni interne/esterne approvate dal legale.
- Lezioni apprese e aggiornamento controlli (DLP, CA, EDR, training).
Segnali da monitorare dopo la notifica
- Aumenti di reply‑chain phishing su thread Microsoft‑cliente.
- Nuovi consensi OAuth o app registrate con permessi insoliti.
- Regole di inoltro e filtri mailbox sospetti.
- Accessi da impossible travel o ASN anomali.
- Contatti esterni che citano dettagli noti solo ai thread compromessi.
Lezioni apprese e rafforzamento dei controlli
- Hardening identità: MFA obbligatoria, FIDO2, policy di sessione e sign‑in risk bloccante.
- Gestione segreti: niente credenziali in e‑mail; vault centralizzato; scadenze e rotazioni automatiche.
- DLP e classificazione con Microsoft Purview su canali mail e archivi.
- Secure‑by‑design nella comunicazione: modelli standard per scambio dati sensibili, allegati cifrati e link protetti.
- Formazione mirata su thread hijacking e frodi di pagamento.
Riferimenti e contesto
- [1] Analisi e resoconti indipendenti hanno confermato la legittimità del portale Power Apps usato da Microsoft, pur criticandone l’aspetto simile a spam/phishing.
- [2] Resoconti di casi reali indicano recapiti finiti nello spam e in caselle amministrative poco presidiate.
- [3] Post pubblico MSRC del 19 gennaio 2024: conferma della compromissione e dell’impegno a notificare i clienti coinvolti.
In sintesi
L’e‑mail “Microsoft Email Data Sharing Request” è legittima e collegata alla campagna di notifica post‑incidente Midnight Blizzard. Verifica tecnicamente gli header, coinvolgi i referenti Microsoft ufficiali, nomina revisori interni, accedi al portale in modo sicuro e analizza le conversazioni consegnate per individuare credenziali e dati sensibili. Completa con reset, revoche, comunicazioni e aggiornamenti dei controlli. Così riduci il rischio di compromissioni a catena e allinei la risposta a requisiti legali e di sicurezza.
Nota sul contesto storico: Midnight Blizzard (APT29/Nobelium) è attivo da anni. L’evento descritto si colloca tra fine 2023 e 2024; alcune organizzazioni hanno ricevuto le notifiche e la consegna delle conversazioni a partire da giugno 2024, con ondate successive [3]. Se ricevi nuove comunicazioni, applica la stessa procedura di verifica e coordinamento.