Phishing no Microsoft 365 apesar de MFA: roubo de sessões

O phishing no Microsoft 365 vai muito além de mensagens mal escritas e páginas de início de sessão falsas. Os ataques começam numa conta empresarial comprometida, conduzem a páginas da Microsoft convincentes ou legítimas e terminam, apesar da MFA, na caixa de correio, no SharePoint ou no Teams.

O Relatório semestral 2026/1 do Serviço Federal de Cibersegurança é relevante para as empresas suíças. No primeiro semestre de 2026, aumentou o número de comunicações sobre contas Microsoft 365 comprometidas. Estas foram usadas para phishing e fraude. Os atacantes fizeram-se passar pelo suporte de TI ou por gestores e contornaram controlos através de session tokens, Device Code Phishing ou reverse proxies.

A MFA continua a ser indispensável. Nem todos os métodos são resistentes a phishing. Uma sessão confirmada pode tornar-se o alvo do ataque. O Microsoft 365 deve ser protegido como plataforma de identidade e não apenas como serviço de e-mail.

Como funciona o phishing no Microsoft 365 apesar de MFA

Depois de verificar a palavra-passe, o segundo fator, o estado do dispositivo e as condições, o Entra ID emite tokens ou cookies de sessão. Tal como acontece com um cartão de visitante, a partir daí é sobretudo a sua validade que conta. Se estes elementos chegarem a outra pessoa, essa pessoa poderá não ter de repetir a verificação.

Os tipos de token no Microsoft Entra ID diferem em finalidade e duração. O essencial é: um token roubado ou disponibilizado ao atacante pode representar uma sessão autenticada.

Adversary-in-the-Middle Phishing com reverse proxy

Num ataque Adversary-in-the-Middle (AiTM), a infraestrutura de phishing posiciona-se entre o browser e a Microsoft e encaminha o início de sessão real em tempo real:

1. Uma mensagem remete, por exemplo, para um documento do SharePoint, uma mensagem de voz, uma fatura ou uma assinatura.
2. A ligação conduz ao início de sessão da Microsoft através do reverse proxy do atacante.
3. O nome de utilizador, a palavra-passe e a resposta MFA são encaminhados para a Microsoft.
4. A Microsoft aceita o início de sessão confirmado e cria a sessão.
5. O proxy interceta o cookie de sessão ou os tokens. O acesso só termina quando estes expiram, são revogados ou bloqueados.

A MFA não foi quebrada. O utilizador confirmou uma sessão que estava a ser intercetada. Os códigos TOTP e as confirmações push não impedem, por si só, este relay. Em contrapartida, as chaves FIDO2, o Windows Hello for Business e os passkeys corretamente implementados vinculam criptograficamente o início de sessão ao serviço legítimo. Contudo, também não protegem contra malware num dispositivo com sessão iniciada nem contra todas as formas de roubo de sessão.

Device Code Phishing através de uma página Microsoft legítima

O Device Code Flow destina-se a dispositivos sem uma forma prática de introduzir dados. Um equipamento de sala de conferências ou uma ferramenta de linha de comandos apresenta um código, que é confirmado num segundo dispositivo através da Microsoft.

Os atacantes iniciam o processo e enviam o código sob um pretexto. Quando este é introduzido na página Microsoft legítima, os tokens são entregues à sessão do atacante. O domínio e o certificado estão corretos, mas é autorizado um início de sessão de terceiros. A Microsoft classifica este fluxo como de risco e recomenda o seu bloqueio quando não existe uma necessidade documentada.

Inundação de e-mail, falso suporte de TI e phishing em cadeia

Uma cadeia de ataque pode começar com centenas de mensagens de newsletters, registos e notificações. Estas geram pressão e ocultam alertas reais. Em seguida, um alegado suporte de TI solicita, através do Teams ou por telefone, a utilização do Quick Assist ou de uma ferramenta de acesso remoto. Isto permite executar comandos, instalar malware, ler dados do browser e roubar credenciais. O posto de trabalho é comprometido, não o início de sessão.

Após a tomada de controlo, o atacante utiliza correspondência real, fornecedores conhecidos e conversas existentes para manipular faturas, lançar novo phishing e comprometer outras contas. SPF, DKIM e DMARC não bastam quando a mensagem provém do tenant Microsoft 365 legítimo.

O que a MFA faz e onde estão os seus limites

A MFA impede muitas tomadas de controlo de contas porque uma palavra-passe deixa de ser suficiente. Contudo, os métodos diferem:

• Palavra-passe mais SMS, chamada ou simples confirmação push: melhor do que apenas uma palavra-passe, mas vulnerável a social engineering, SIM swapping, MFA fatigue e phishing em tempo real.
• TOTP ou Authenticator com Number Matching: mais resistente a confirmações acidentais, mas um código pode ser imediatamente encaminhado numa página AiTM.
• Autenticação resistente a phishing: FIDO2, Windows Hello for Business, autenticação baseada em certificados e passkeys verificam criptograficamente o serviço legítimo e reduzem significativamente os inícios de sessão AiTM.

Os riscos permanecem: um endpoint infetado pode ler sessões, uma aplicação OAuth pode obter permissões persistentes e um utilizador pode confirmar Device Codes ou acessos remotos de terceiros. A MFA resistente a phishing é fundamental, mas não constitui um conceito de segurança completo.

Reforçar corretamente o Microsoft Entra ID

O Conditional Access e o Token Protection requerem licenças Entra adequadas, enquanto as condições de dispositivo exigem uma base de dispositivos geridos. As políticas devem ser testadas primeiro no modo Report-only com um grupo-piloto.

Dar prioridade a inícios de sessão resistentes a phishing

A primeira fase deve abranger administradores, responsáveis financeiros, direção e helpdesk. As Conditional Access Authentication Strengths podem exigir Windows Hello for Business, chaves FIDO2, passkeys ou autenticação baseada em certificados para estes grupos.

É igualmente necessário um processo de recuperação com pelo menos dois métodos registados, dispositivos de substituição verificados e contas de emergência monitorizadas separadamente. A perda de uma chave não deve causar uma interrupção prolongada nem exceções de helpdesk facilmente manipuláveis. Os passkeys também são adequados para o início de sessão no Sophos Central, mas a recuperação e a mudança de dispositivo também têm de ser planeadas.

Verificar e, se possível, bloquear o Device Code Flow

A utilização pode ser inventariada nos Entra Sign-in Logs através de Authentication protocol > Device code. Equipamentos de salas de conferências, ferramentas antigas ou aplicações de linha de comandos podem depender deste fluxo. Sem uma necessidade justificada, é criada uma política em Entra ID > Conditional Access > Policies:

1. Selecionar utilizadores ou grupos regulares.
2. Excluir contas de emergência e exceções técnicas justificadas.
3. Em Target resources, selecionar, se possível, All resources; utilizar alvos mais restritos apenas com justificação.
4. Em Conditions > Authentication flows, ativar Device code flow.
5. Em Grant, bloquear o acesso.
6. Utilizar primeiro Report-only, analisar os logs e só depois ativar a política.

As exceções devem ser limitadas, documentadas e associadas a contas ou recursos concretos.

Vincular o acesso a dispositivos geridos

O Conditional Access pode exigir um dispositivo conforme ou associado ao Microsoft Entra para aplicações sensíveis. Isto dificulta a utilização abusiva de tokens em dispositivos desconhecidos, mas afeta BYOD, convidados, dispositivos móveis e clientes especiais. Por isso, o inventário de dispositivos, os sistemas operativos e as aplicações têm de ser conhecidos. Registos obsoletos, enrollment fraco ou exceções demasiado abrangentes comprometem o controlo.

Testar o Token Protection de forma dirigida

O Token Protection vincula criptograficamente ao dispositivo emissor os Sign-in Session Tokens suportados, dificultando o replay noutros sistemas. A função requer Entra ID P1 e abrange apenas determinadas plataformas, aplicações e recursos. No Windows, protege sobretudo aplicações Microsoft 365 nativas e suportadas. Os dispositivos Apple requerem gestão e o Microsoft Enterprise SSO Plug-in. As aplicações Mail e Calendar da Apple não suportam atualmente Token Protection.

A implementação começa com um âmbito restrito em Report-only. Em seguida, são verificados os Token Protection Status Details, os clientes e os recursos nos Sign-in Logs. A imposição só deve ocorrer depois de confirmada a compatibilidade. Browsers, software antigo e dispositivos especiais são avaliados separadamente.

Controlar o Teams e o acesso remoto

É necessário definir que domínios ou tenants externos podem contactar os utilizadores através do Teams e como são identificados os participantes externos. Para o suporte aplicam-se as seguintes regras:

• O acesso remoto só é iniciado com um ticket ou uma chamada de retorno verificada para um número conhecido.
• Sessões inesperadas de Quick Assist iniciadas por chat ou telefone não são aceites.
• As ferramentas de acesso remoto autorizadas são documentadas e monitorizadas.
• Ferramentas RMM desconhecidas são bloqueadas ou geram alertas através de Application Control, AppLocker, Windows Defender Application Control ou controlos equivalentes.
• Uma inundação de e-mail invulgar é comunicada à equipa de TI ou Security e não é tratada apenas como spam.

A sensibilização deve refletir estes processos. O Sophos Phish Threat torna-se mais eficaz com canais de comunicação claros, cenários no Teams e um runbook de helpdesk realista.

Que indícios devem os administradores verificar

Um evento MFA bem-sucedido não prova que o início de sessão é legítimo. Em AiTM ou Device Code, o próprio fator pode ter sido confirmado. A identidade, a caixa de correio, o endpoint e as comunicações têm de ser investigados em conjunto.

Microsoft Entra Sign-in Logs

Os registos encontram-se em Entra ID > Monitoring & health > Sign-in logs e podem ser lidos a partir da função Reports Reader. Consoante a suspeita, a análise deve incluir inícios de sessão interativos e não interativos, Service Principals e Managed Identities. São relevantes:

• dispositivos desconhecidos ou não conformes, bem como IPs, regiões, aplicações e clientes invulgares,
• Device code como Authentication Protocol,
• novas combinações de browser ou dispositivo após um início de sessão normal,
• acessos invulgares ao Exchange Online, SharePoint ou Microsoft Graph,
• resultado do Conditional Access, requisitos de autenticação cumpridos e
• acessos bem-sucedidos sem a interação esperada do utilizador através de tokens existentes.

Um único sinal não é suficiente. Um IP suíço pode pertencer a uma rede móvel ou VPN e um início de sessão no estrangeiro pode ser profissionalmente legítimo. É a combinação de utilizador, dispositivo, momento, aplicação e atividade subsequente que importa.

Exchange Online, auditoria e endpoint

Depois de comprometer uma conta, os atacantes procuram frequentemente faturas e conversas existentes. Devem ser verificadas as regras de reencaminhamento internas e externas, as Inbox Rules visíveis e ocultas, as delegações e permissões Send-as, atividades invulgares de pesquisa, leitura, download e envio, novos consentimentos OAuth e Enterprise Applications, métodos de autenticação alterados e todas as mensagens enviadas durante o período relevante.

No caso de falso suporte de TI, os indícios encontram-se no endpoint: aplicações de acesso remoto, downloads, PowerShell, MSHTA, tarefas agendadas, acessos ao browser e processos suspeitos. A segurança de e-mail, a Endpoint Protection e soluções XDR ou MDR podem bloquear e correlacionar estes eventos, desde que as fontes de dados estejam licenciadas, integradas e monitorizadas. A estratégia Sophos Fusion ajuda neste processo, mas não substitui o Conditional Access nem o processo de resposta a incidentes.

A retenção e o nível de detalhe dos dados de auditoria dependem da licença e da configuração. Ambos devem ser definidos antecipadamente, pois os registos ativados posteriormente não criam histórico.

Plano de emergência para uma conta Microsoft 365 comprometida

Alterar a palavra-passe não é suficiente. Sessões, métodos MFA de terceiros, consentimentos OAuth e regras de caixa de correio podem permanecer ativos.

1. Utilizar um dispositivo de administração limpo

Se existir a possibilidade de o endpoint estar comprometido, a alteração da palavra-passe e a administração devem ser efetuadas noutro dispositivo. O sistema afetado é isolado sem apagar precipitadamente vestígios. Durante um ataque ativo ou quando se trata de uma conta privilegiada, pode ser aconselhável desativá-la temporariamente.

2. Revogar sessões ativas

As sessões podem ser revogadas no Entra Admin Center ou através do Microsoft Graph PowerShell:

Connect-MgGraph -Scopes User.RevokeSessions.All
Revoke-MgUserSignInSession -UserId user@example.com

O User Principal Name deve ser adaptado. Consoante a aplicação, o tipo de token e o Continuous Access Evaluation, o acesso pode persistir durante algum tempo. Por isso, o resultado deve ser confirmado nos logs e nas aplicações.

3. Corrigir a palavra-passe e a autenticação

A palavra-passe é alterada na fonte de identidade principal e, no caso de contas sincronizadas ou federadas, no Active Directory local ou no Identity Provider. Em seguida, são verificados os métodos MFA, passkeys, números de telefone, dispositivos e Temporary Access Passes, removendo entradas desconhecidas. Se existir malware ou acesso remoto, o endpoint é investigado em paralelo e, se necessário, reconstruído.

4. Verificar consentimentos OAuth e funções

Os consentimentos de utilizador, Enterprise Applications e Service Principals suspeitos podem permitir acesso persistente. No caso de contas privilegiadas, também são verificadas as funções do Entra, Azure e Microsoft 365.

5. Verificar reencaminhamentos e Inbox Rules

O Exchange Online PowerShell apresenta as principais definições da caixa de correio:

Get-Mailbox -Identity user@example.com |
  Format-List Forwarding*Address,DeliverTo*

Get-InboxRule -Mailbox user@example.com -IncludeHidden |
  Format-List Name,Enabled,RedirectTo,Forward*,Identity

As regras suspeitas são documentadas e removidas. As delegações, permissões Send-as e regras administrativas de transporte são verificadas separadamente.

6. Identificar e informar outras vítimas

O Message Trace e os dados de auditoria mostram as mensagens enviadas. Os destinatários internos e externos são informados antes de serem afetados por ligações, pagamentos ou pelo comprometimento de outras contas. Em caso de alteração de pagamentos, o banco, a contabilidade e os parceiros comerciais são contactados através de canais conhecidos. O artigo sobre medidas imediatas em caso de phishing e hacking apresenta passos adicionais.

7. Determinar a causa e o alcance

Por fim, é necessário esclarecer se estiveram envolvidos AiTM, Device Code, uma MFA confirmada ou acesso remoto, que ficheiros do SharePoint ou OneDrive foram exfiltrados, se foram registadas outras contas, aplicações ou dispositivos e se foram afetados dados pessoais ou segredos comerciais. Sem uma análise da causa, a falha permanece aberta.

Lista de verificação prática para administradores do Microsoft 365

• Dar prioridade à autenticação resistente a phishing para administradores, equipas financeiras, direção e helpdesk.
• Manter contas de emergência separadas, monitorizadas e testadas regularmente.
• Inventariar a utilização de Device Code, bloqueá-la ou criar exceções justificadas.
• Testar o Conditional Access em Report-only com um grupo-piloto.
• Exigir dispositivos geridos para recursos sensíveis e implementar Token Protection apenas com clientes compatíveis.
• Definir regras vinculativas para comunicação externa no Teams, ferramentas de acesso remoto, chamadas de retorno do helpdesk e verificação de identidade.
• Criar alertas para inundações de e-mail, inícios de sessão invulgares, consentimentos OAuth e reencaminhamentos.
• Testar a revogação de sessões, a limpeza de MFA, Inbox Rules, rastreio de mensagens enviadas e isolamento de endpoints.
• Definir a retenção de auditoria e as responsabilidades antes de ocorrer um incidente.

A minha recomendação

A MFA continua a ser obrigatória, mas uma palavra-passe combinada com uma aplicação push já não tem suficientemente em conta os ataques modernos. Primeiro, as contas privilegiadas e financeiramente críticas devem passar a utilizar autenticação resistente a phishing. Seguem-se o controlo do Device Code, dispositivos geridos e Conditional Access. Devido às suas limitações, o Token Protection requer uma implementação controlada. Em paralelo, o helpdesk precisa de processos seguros para contactos inesperados no Teams.

O essencial é a combinação de uma identidade forte, um dispositivo fiável, uma sessão controlada, comunicações monitorizadas e um plano de emergência para tokens ativos e mecanismos de persistência ocultos.

FAQ