Recebeu um e‑mail com o assunto “Action Required – Microsoft Email Data Sharing Request” citando o ataque do grupo Midnight Blizzard e pedindo Tenant ID e contatos? Veja como confirmar a legitimidade, evitar phishing e cumprir o processo da Microsoft com segurança e rastreabilidade.
O que é a solicitação “Microsoft Email Data Sharing”
Trata‑se de uma comunicação operacional da Microsoft voltada a organizações cujas conversas com a empresa podem ter sido acessadas durante o incidente atribuído ao grupo Midnight Blizzard. O objetivo é compartilhar, de forma controlada, um conjunto de mensagens trocadas entre a sua organização e a Microsoft que possivelmente foram exfiltradas, permitindo que você:
- tenha visibilidade do material que a Microsoft identificou como potencialmente acessado;
- avalie impacto, privacidade e obrigações regulatórias;
- coordene resposta e comunicação com partes interessadas (Segurança, Jurídico, Privacidade e Compliance).
O e‑mail costuma solicitar:
- Tenant ID da organização (GUID do diretório);
- e‑mails de pessoas autorizadas a indicar revisores;
- envio desses dados por um portal Power Apps, tipicamente indicado como
purviewcustomer.powerappsportals[.]com.
É legítimo ou phishing?
Em geral, a comunicação é legítima e integra o fluxo da Microsoft para compartilhar, mediante validação, o material possivelmente exfiltrado (“Microsoft Email Data Sharing”). Contudo, por envolver dados sensíveis e um link de portal, a abordagem correta é tratar o e‑mail como suspeito até comprovar.
Abaixo, um guia prático de validação para confirmar legitimidade sem se expor a risco.
Checklist rápido para validar com segurança
| O que verificar | Como verificar sem clicar no link | Indicação de legitimidade |
|---|---|---|
| Autenticidade do remetente | Abra os cabeçalhos completos da mensagem (Outlook/Gmail), valide SPF, DKIM e DMARC e analise a cadeia “Received:”. | SPF/DKIM/DMARC pass e domínio alinhado à Microsoft; ausência de saltos estranhos na rota. |
| Conteúdo do pedido | Confirme se não há solicitação de senha, token MFA, código de verificação ou dados pessoais além de Tenant ID e e‑mails corporativos. | O pedido não inclui credenciais, anexos executáveis ou urgência coercitiva. |
| Portal informado | Sem clicar: copie o endereço informado no e‑mail (p. ex., purviewcustomer.powerappsportals[.]com) para o seu ticket de suporte e peça confirmação pelo portal do Microsoft 365 Admin ou ao seu gerente de conta/CSAM. | Equipe Microsoft confirma o endereço do portal e o case ID/código do e‑mail pelo chamado oficial. |
| Código de acesso/caso | Inclua no chamado: assunto, possível access code e quaisquer identificadores citados no e‑mail para validação cruzada. | Os identificadores batem com os registros do suporte Microsoft. |
Passo a passo recomendado (seguro)
- Não clique no link do e‑mail por enquanto.
- Valide a comunicação por um canal conhecido:
- Abra um chamado no Microsoft 365 Admin Center com a conta administrativa da sua organização, citando “Microsoft Email Data Sharing”; ou
- contate seu CSAM/gerente de conta pelos canais já usados pela sua organização.
- No chamado, cole os detalhes do e‑mail: remetente (domínio), assunto, texto relevante, código de acesso/ID de caso e o endereço do portal informado.
- Somente após a confirmação no chamado, acesse o portal seguro para enviar:
- Tenant ID (ID do diretório);
- e‑mails dos responsáveis por indicar revisores (tipicamente Segurança/Privacidade/Compliance).
- Registre tudo para auditoria e resposta a incidentes: número do chamado, capturas de tela, cabeçalhos da mensagem e hashes do e‑mail.
Como localizar o Tenant ID
Há três formas comuns; utilize a que for mais prática na sua realidade:
| Método | Passos | Resultado |
|---|---|---|
| Portal (Microsoft Entra ID) | Acesse o centro administrativo → Microsoft Entra ID → Visão geral → ID do diretório (Tenant). | GUID do diretório (ex.: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee). |
| PowerShell (Microsoft Graph) | Connect-MgGraph -Scopes Organization.Read.AllSelect-MgProfile beta (opcional)Get-MgOrganization | Select-Object Id,DisplayName | Campo Id corresponde ao Tenant ID. |
| CLI (Azure CLI) | az account show --query tenantId -o tsv | Retorna o Tenant ID no formato GUID. |
Quem deve indicar revisores e por quê
Indique apenas pessoas que precisam ver o conteúdo para cumprir suas funções (princípio do menor privilégio). Em geral, envolva:
- Segurança da Informação (Blue Team/CSIRT): avaliação técnica e contenção;
- Privacidade/Proteção de Dados (DPO): avaliação de dados pessoais e obrigações legais;
- Compliance/Jurídico: requisitos regulatórios, comunicação a autoridades, cláusulas contratuais;
- TI/M365 Admin: suporte técnico e governança de acesso.
Uma matriz RACI ajuda a definir papéis:
| Função | R | A | C | I |
|---|---|---|---|---|
| Segurança (CSIRT) | Responsável por validar impacto técnico | Consultado | Informado | |
| Privacidade (DPO) | Aprovador para dados pessoais | Consultado | Informado | |
| Compliance/Jurídico | Aprovador regulatório | Consultado | Informado | |
| TI/M365 Admin | Responsável por submissão | Consultado | Informado |
Modelo de chamado (para copiar e adaptar)
[Assunto]
Validação – Microsoft Email Data Sharing (Midnight Blizzard)
\[Resumo]
Recebemos e-mail com assunto “Action Required – Microsoft Email Data Sharing Request”.
Solicitamos confirmação de legitimidade e instruções.
\[Detalhes]
- Remetente: \
- Data/hora do recebimento: \
- Código/ID citado no e-mail: \
- Portal informado: purviewcustomer.powerappsportals\[.]com
- Não clicamos em nenhum link.
- Anexamos cabeçalhos completos e o e-mail em formato .eml/.msg.
\[Solicitações]
1. Confirmação de legitimidade do contato;
2. Confirmação do endereço do portal e do código/ID do caso;
3. Orientações sobre o envio de Tenant ID e e-mails de responsáveis.
\[Contato técnico]
Nome, e-mail, telefone (apenas corporativos) O que esperar após a validação
- Confirmação oficial do suporte ou do CSAM de que o e‑mail pertence ao fluxo “Microsoft Email Data Sharing”.
- Acesso ao portal indicado para informar Tenant ID e lista de indicados (nomes e e‑mails corporativos).
- Contato direto da Microsoft com os indicados, contendo instruções de como revisar o conjunto de e‑mails relacionados à sua organização.
- Janela de revisão para analisar as mensagens e extrair evidências necessárias a avaliação de impacto, privacidade e compliance.
Boas práticas de segurança (essenciais)
- Não forneça senhas, chaves, tokens, códigos MFA ou dados além do estritamente solicitado (Tenant ID e contatos).
- Valide SPF/DKIM/DMARC e examine os cabeçalhos antes de qualquer interação.
- O portal Power Apps pode parecer “simples”; isso não é indicador de fraude por si só. Valide via chamado oficial.
- Use contas corporativas e ambientes gerenciados para acessar o portal (navegador atualizado, EDR, políticas).
- Privilégios mínimos: indique revisores com as funções adequadas e registre aprovações.
- Se algo não bater (domínio, instruções, código), interrompa e siga apenas pelo chamado com a Microsoft.
Registro e auditoria: o que armazenar
Mantenha uma trilha de auditoria completa. Itens recomendados:
| Artefato | Descrição | Onde armazenar |
|---|---|---|
| E‑mail original | Arquivo .eml/.msg + cabeçalhos completos | Repositório de evidências com controle de acesso |
| Hashes | SHA‑256 do e‑mail e anexos | Ticket e cofre de evidências |
| Chamado oficial | Número, transcrições, anexos e confirmações | Sistema de ITSM (ex.: ServiceNow/Jira) |
| Decisões e aprovações | Quem aprovou, quando, por qual razão | Dossiê do incidente/privacidade |
| Relatório de revisão | Resultado da análise do conjunto de e‑mails | Repositório seguro e versionado |
Como gerar hash do e‑mail
Opções multiplataforma (use apenas em estações corporativas):
:: Windows (PowerShell/Prompt)
CertUtil -hashfile "c:\evidencias\email.eml" SHA256
macOS
shasum -a 256 "/Users/\/evidencias/email.eml"
Linux
sha256sum "/home/\/evidencias/email.eml" Sinais de alerta de phishing (e como reagir)
- Tom de urgência exagerado e ameaça de bloqueio imediato se você não clicar.
- Pedido de credenciais, códigos MFA ou dados bancários.
- Remetente estranho ou domínio recém‑criado.
- Erros grosseiros de idioma e formatação.
- Links encurtados ou redirecionamentos suspeitos.
Se identificar qualquer um desses sinais, pare, encaminhe a mensagem para o time de Segurança/CSIRT e prossiga apenas pelo chamado oficial com a Microsoft.
Fluxo interno recomendado (playbook)
- Triagem (Service Desk/Segurança): isole o e‑mail, gere ticket interno e aplique o checklist de validação.
- Confirmação (TI/Admin M365): abra o chamado com a Microsoft e aguarde confirmação formal.
- Autorização (DPO/Compliance/Jurídico): defina quem pode revisar o material e aprove os nomes.
- Submissão (TI/Admin M365): após confirmação, envie Tenant ID e contatos no portal validado.
- Revisão (Indicados): acesse o conjunto de e‑mails, classifique itens sensíveis, avalie impacto e reporte.
- Encerramento (Segurança/Privacidade): documente decisões, retenções aplicáveis e comunicações necessárias.
Perguntas frequentes
Por que a Microsoft pede Tenant ID e e‑mails de contatos, e não credenciais?
Porque o fluxo é de compartilhamento controlado de dados, não de autenticação. O Tenant ID vincula o caso à sua organização, e os e‑mails permitem contatar os revisores. Credenciais nunca são solicitadas nesse processo.
O portal Power Apps parece simples. Isso significa fraude?
Não. Muitas iniciativas corporativas utilizam portais Power Apps com visual minimalista. A legitimidade não se mede pelo “design”, e sim pela confirmação via suporte oficial e pela consistência dos identificadores/códigos do caso.
O que devo enviar ao portal depois de validar?
Apenas o Tenant ID e os e‑mails corporativos dos responsáveis por indicar revisores. Nenhum dado de autenticação, nenhuma senha, nenhum token.
E se o domínio do e‑mail ou o código informado não baterem com a confirmação da Microsoft?
Interrompa o fluxo, não acesse o portal, trate como suspeita e continue apenas pelo seu chamado com a Microsoft até sanar as divergências.
Quem deve ser indicado como revisor?
Pessoas com mandato formal e necessidade de acesso: Segurança, Privacidade (DPO), Compliance/Jurídico e, se preciso, representantes de áreas impactadas. Registre aprovações.
Como proteger dados pessoais durante a revisão?
Implemente controles de acesso, registre logs, aplique políticas de retenção e, se requerido, envolva o DPO para avaliar notificação a titulares/autoridades, conforme a legislação aplicável no seu país.
Erros comuns (e como evitá‑los)
- Clicar no link do e‑mail antes de validar: sempre confirme pelo Admin Center/gerente de conta.
- Compartilhar credenciais: nunca faça isso; não faz parte do processo.
- Indicar revisores demais: restrinja a quem precisa e registre justificativas.
- Não guardar evidências: sem trilha, sua auditoria e relatórios ficam comprometidos.
- Perder prazos internos: defina responsáveis e um playbook com SLAs.
Resumo executivo
O e‑mail “Action Required – Microsoft Email Data Sharing Request” relacionado ao incidente Midnight Blizzard tende a ser legítimo e integra o processo da Microsoft de compartilhamento controlado de mensagens possivelmente exfiltradas. A postura segura é: validar pelos canais oficiais, evitar cliques diretos, enviar apenas Tenant ID e e‑mails de responsáveis após confirmação, e manter trilha de auditoria. Com isso, sua organização cumpre a diligência devida sem ampliar a superfície de risco.
Lista de verificação final
- ☑ Não clique no link do e‑mail antes de validar;
- ☑ Abra ticket no Microsoft 365 Admin Center ou contate o CSAM pelo canal usual;
- ☑ Anexe cabeçalhos completos, assunto, código/ID e portal informado ao ticket;
- ☑ Após confirmação, forneça apenas Tenant ID e e‑mails dos responsáveis;
- ☑ Registre evidências (eml/msg, hashes, ticket, decisões e aprovações);
- ☑ Aplique princípio do menor privilégio e segregação de funções.
Resultado esperado: depois da validação e envio dos contatos autorizados, a Microsoft contata os indicados com instruções de acesso e revisão do conjunto de e‑mails relacionados à sua organização, no escopo de “Microsoft Email Data Sharing”.