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

1. Recupera gli header completi dal tuo client: in Outlook/M365 “Visualizza origine messaggio”.
2. Controlla le catene di ricezione (Received:) per assicurarti che il messaggio provenga da server Microsoft legittimi (*.protection.outlook.com / outbound.protection.outlook.com).
3. 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
4. Esamina il Message-ID (dominio coerente con Microsoft) e possibili custom headers usati per campagne di notifica.
5. 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

1. 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.
2. Autentica l’accesso con account di servizio o amministrativi protetti (MFA obbligatoria, sessione isolata), mai con account personali.
3. 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

1. Ambiente: usa un device aziendale conforme, con EDR attivo, aggiornato e cifrato; se possibile, una VM dedicata all’analisi.
2. Download: scarica i file soltanto sul repository designato (es. area IR evidence con versioning e auditing); evita cartelle locali improvvisate.
3. Archiviazione: conserva gli artefatti in uno spazio con controllo accessi a ruoli, log di accesso e retention predefinita.
4. 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

1. Centralizza l’e‑mail in un case IR con numero interno e proprietario.
2. Acquisisci gli header completi e salva l’originale (.eml/.msg) su repository evidenze.
3. Esegui message trace per confermare la catena di recapito.
4. Verifica SPF/DKIM/DMARC come descritto sopra.
5. Apri il ticket Microsoft e ottieni conferma formale dell’associazione al caso.
6. Nomina i revisori e raccogli il loro consenso informato sulla gestione dei dati.
7. Accedi al portale e scarica i materiali attenendoti alle pratiche di sicurezza.
8. 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.