Segurança  |  ✎ Duarte Spínola  |  2026-07-15

Defender SaaS contra Abuso de OAuth: ShinyHunters e Consent Phishing no Microsoft 365

O grupo ShinyHunters, um actor de ameaça financeiramente motivado, tem explorado relações de confiança OAuth em aplicações SaaS para aceder a dados empresariais sem despoletar alertas de autenticação tradicionais. Entre meados de 2025 e meados de 2026, a Microsoft identificou campanhas que combinam vishing (phishing por voz) e compromissão de cadeia de fornecimento para abusar tokens OAuth em plataformas como Salesforce, com impacte directo em inquilinos Microsoft 365 que integram com serviços SaaS de terceiros. Este guia prático explica o que é consent phishing, como os atacantes abusam tokens OAuth, como detectar aplicações maliciosas no Entra ID, como remediar e quais as estratégias de prevenção para PME portuguesas.

Neste artigo

1. O Que é Consent Phishing e Abuso de OAuth
2. Como os ShinyHunters Abusam OAuth no M365 e SaaS
3. As Duas Vias de Ataque: Vishing e Cadeia de Fornecimento
4. Deteção de Aplicações OAuth Maliciosas no Entra ID
5. Remediação: Revogar Tokens e Aplicações Comprometidas
6. Conditional Access para Bloquear Consent Phishing
7. Defender for Cloud Apps: Governance de OAuth
8. Monitorização com Sentinel e KQL
9. Prevenção de PME: Estratégias Práticas
10. Erros Comuns na Gestão de OAuth
11. Checklist Rápido de Verificação

1. O Que é Consent Phishing e Abuso de OAuth

O OAuth 2.0 é o protocolo de autorização usado por praticamente todas as aplicações SaaS modernas — Microsoft 365, Salesforce, Google Workspace, Slack — para permitir que uma aplicação aceda a dados de outra em nome do utilizador. O fluxo funciona assim: o utilizador clica em “Aceitar”, a aplicação recebe um token de acesso e passa a poder chamar APIs com os privilégios concedidos. O problema é que este consentimento é persistente — o token mantém-se válido durante dias, semanas ou meses, sem voltar a pedir a palavra-passe ou MFA ao utilizador (Microsoft Learn — Consent Framework).

O consent phishing explora exactamente este mecanismo. Em vez de roubar a palavra-passe, o atacante engana o utilizador para autorizar uma aplicação maliciosa que se faz passar por uma legítima. Assim que o utilizador clica em “Aceitar”, o atacante obtém um token OAuth válido com as permissões concedidas — que podem incluir ler email, aceder a ficheiros no OneDrive, consultar registos CRM ou enviar mensagens em nome do utilizador. A autenticação multi-fator não ajuda aqui, porque o utilizador autenticou-se legitimamente; foi o consentimento que foi manipulado (CISA — Cybersecurity Advisories).

No contexto do Microsoft 365, o risco é particularmente elevado porque o Entra ID (antigo Azure AD) suporta milhares de aplicações multi-inquilino. Qualquer programador pode registar uma aplicação no Entra ID e pedir permissões como Mail.Read, Files.ReadWrite.All ou Directory.Read.All. Se um utilizador conceder consentimento, a aplicação pode operar silenciosamente sem gerar alertas de login anómalo — porque há um login válido, apenas não é do utilizador legítimo.

2. Como os ShinyHunters Abusam OAuth no M365 e SaaS

Os ShinyHunters são um grupo de actors de ameaça financeiramente motivado, conhecido por atacar plataformas cloud empresariais. Entre meados de 2025 e meados de 2026, a Microsoft observou campanhas que usam duas vias principais para abusar OAuth em aplicações SaaS, com foco em Salesforce mas com impacte transversal em inquilinos M365 que integram com serviços SaaS externos via OAuth (Microsoft Security Blog — 13 Jul 2026).

O modus operandi do ShinyHunters é particularmente perigoso porque não depende de malware nem de roubo de credenciais. Em vez disso, os atacantes operam dentro de fluxos OAuth legítimos, usando tokens válidos que lhes foram concedidos — voluntariamente — pela vítima. Isto significa que:

• Não há login anómalo — o token foi emitido por Microsoft após consentimento legítimo do utilizador;
• Não há MFA para contornar — o consentimento já foi dado, o token é válido;
• A actividade parece legítima — chamadas API através de aplicações OAuth aprovadas são indistinguíveis de uso normal;
• O acesso é persistente — os tokens de actualização (refresh tokens) permitem manter acesso durante semanas ou meses.

Para PME portuguesas que usam Microsoft 365 com integrações SaaS (Salesforce, HubSpot, Mailchimp, Salesloft, Gainsight), o risco é real: um ataque bem-sucedido a uma integração OAuth de terceiros pode expor dados do inquilino M365, incluindo contactos, email e documentos partilhados via integrações.

3. As Duas Vias de Ataque: Vishing e Cadeia de Fornecimento

A Microsoft identificou duas vias de intrusão distintas usadas pelos ShinyHunters, ambas explorando OAuth mas com vectores de entrada diferentes:

Via 1 — Vishing para Consent Phishing

A partir de meados de 2025, os atacantes conduziram campanhas de vishing (voice phishing) fazendo-se passar por pessoal de suporte IT. Por telefone, guiavam os utilizadores através do fluxo de consentimento OAuth para autorizar uma aplicação maliciosa disfarçada de ferramenta legítima — por exemplo, um “Salesforce Data Loader” falso. Após o consentimento, a aplicação obtinha permissões elevadas que permitiam aos atacantes:

• Enumerar instâncias Salesforce das organizações visadas;
• Mantenham acesso persistente aos dados CRM;
• Potencial movimento lateral para outras plataformas SaaS via credenciais descobertas.

Via 2 — Compromissão de Cadeia de Fornecimento

Após as campanhas iniciais, os atacantes escalaram para ataques de cadeia de fornecimento contra fornecedores SaaS de terceiros que integram com Salesforce via OAuth. Os incidentes documentados incluem:

Data	Fornecedor Comprometido	Vector	Impacto
Ago 2025	Salesloft / Drift	Credenciais comprometidas usadas para obter connection secrets	Tokens OAuth usados em múltiplas instâncias Salesforce de clientes
Nov 2025	Gainsight	Aplicações publicadas pelo Gainsight comprometidas	Acesso API persistente em instâncias Salesforce de múltiplos clientes
Jun 2026	Klue (Storm-3138)	Credenciais de acesso a instâncias Salesforce de clientes	Descoberta, consulta e exfiltração em massa de dados CRM

A lição crítica para PME é que o risco não vem apenas das suas próprias aplicações OAuth, mas de toda a cadeia de integrações SaaS. Se um fornecedor de terceiros for comprometido, os tokens OAuth que ligam a sua organização a esse fornecedor podem ser abusados para aceder aos seus dados — mesmo que a sua configuração esteja correcta.

4. Deteção de Aplicações OAuth Maliciosas no Entra ID

A deteção de aplicações OAuth maliciosas no Entra ID exige auditoria regular dos consentimentos concedidos. O portal Entra ID fornece visibilidade sobre aplicações com consentimento, mas a maioria dos administradores de PME nunca audita esta lista. Para detetar aplicações suspeitas, há três sinais a procurar:

Para listar todas as aplicações com consentimento no inquilino, usa o Microsoft Graph PowerShell:

# Listar todas as aplicações com consentimento de utilizador no inquilino
Connect-MgGraph -Scopes "Directory.Read.All", "AuditLog.Read.All"

# Obter service principals de aplicações
Get-MgServicePrincipal -Filter "tags/Any(x: x eq 'WindowsAzureActiveDirectoryIntegratedApp')" |
    Select-Object DisplayName, AppId, Homepage, @{Name="OAuth2PermissionGrants";Expression={$_.Oauth2PermissionGrants}} |
    Format-Table -AutoSize

# Listar consentimentos OAuth concedidos por utilizadores
Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $spId |
    Select-Object ClientId, ResourceId, Scope, ConsentType, PrincipalId

Os sinais de alerta a procurar durante a auditoria incluem:

Sinal	Nível de Risco	Acção
App com permissões Mail.Read ou Files.ReadWrite.All não reconhecida	🔴 Crítico	Revogar imediatamente e investigar
App concedida por utilizador não-admin com permissões de diretório	🔴 Crítico	Revogar; activar restrição de consentimento admin-only
App inactiva há > 90 dias com permissões elevadas	🟡 Alto	Revogar se não houver justificação de uso
App com homepage desconhecido ou domínio suspeito	🟡 Alto	Verificar publisher; revogar se não confirmada
App com nome semelhante a app legítima (typosquatting)	🔴 Crítico	Revogar imediatamente; alertar utilizadores

Para verificar o histórico de consentimento, consulta os logs de auditoria do Entra ID (Microsoft Learn — Audit Logs):

# Obter eventos de consentimento OAuth dos últimos 30 dias
Connect-MgGraph -Scopes "AuditLog.Read.All"

$startDate = (Get-Date).AddDays(-30)

Get-MgAuditLogDirectoryAudit -Filter "activityDateTime ge $startDate" |
    Where-Object { $_.ActivityDisplayName -match "consent" -or $_.ActivityDisplayName -match "OAuth" } |
    Select-Object ActivityDateTime, ActivityDisplayName,
           @{Name="User";Expression={$_.InitiatedBy.User.UserPrincipalName}},
           @{Name="App";Expression={$_.TargetResources[0].DisplayName}} |
    Format-Table -AutoSize

5. Remediação: Revogar Tokens e Aplicações Comprometidas

Quando uma aplicação OAuth maliciosa é detectada, a remediação tem de ser imediata e envolver três passos sequenciais: revogar o consentimento, invalidar os tokens e remover a aplicação do inquilino. Saltar qualquer passo deixa uma janela de acesso ao atacante.

Passo 1 — Revogar o consentimento OAuth no portal Entra ID:

# Revogar consentimento OAuth de uma aplicação específica
Connect-MgGraph -Scopes "Directory.ReadWrite.All"

# Encontrar o ServicePrincipal da aplicação maliciosa
$sp = Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'"

# Remover todos os consentimentos OAuth desta aplicação
Get-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id | 
    ForEach-Object { Remove-MgServicePrincipalOauth2PermissionGrant -ServicePrincipalId $sp.Id -OAuth2PermissionGrantId $_.Id }

Passo 2 — Invalidar tokens de actualização de todos os utilizadores afectados:

# Invalidar todos os tokens de actualização (refresh tokens) do utilizador
Connect-MgGraph -Scopes "Directory.ReadWrite.All"

# Revogar todos os refresh tokens de um utilizador específico
Revoke-MgUserSignInSession -UserId "<USER-UPN>"

# Para todos os utilizadores que consentiram a app maliciosa:
$affectedUsers = @("[email protected]", "[email protected]")
foreach ($user in $affectedUsers) {
    Revoke-MgUserSignInSession -UserId $user
    Write-Host "Tokens revogados para: $user"
}

Passo 3 — Desactivar ou remover a aplicação do inquilino:

# Desactivar o ServicePrincipal da aplicação maliciosa
Update-MgServicePrincipal -ServicePrincipalId $sp.Id -AccountEnabled:$false

# Remover permanentemente (após confirmação)
Remove-MgServicePrincipal -ServicePrincipalId $sp.Id

# Verificar se existem outras instâncias da mesma app
Get-MgServicePrincipal -Filter "appId eq '<APP-ID>'" | Format-Table DisplayName, Id, AccountEnabled

6. Conditional Access para Bloquear Consent Phishing

O Conditional Access é a defesa mais eficaz contra consent phishing. Por defeito, o Entra ID permite que qualquer utilizador conceda consentimento a qualquer aplicação multi-inquilino — uma configuração perigosa que os ShinyHunters exploram activamente. A Microsoft recomenda restringir o consentimento a apenas administradores, garantindo que nenhuma aplicação obtenha acesso sem validação prévia (Microsoft Learn — Conditional Access).

Para configurar a restrição de consentimento no portal Entra ID:

# Configurar consentimento de aplicações — apenas admins
# Portal Entra ID → Enterprise Applications → Consent and permissions → User settings

# Via Microsoft Graph PowerShell:
Connect-MgGraph -Scopes "Policy.ReadWrite.Authorization"

# Definir policy de consentimento:
# 1. Navegar para Entra ID → Enterprise Applications
# 2. Consent and permissions → User consent settings
# 3. Seleccionar "Do not allow user consent" ou
#    "Allow user consent for apps from verified publishers"
# 4. Guardar

# Para permitir consentimento apenas com admin approval:
# Configurar "Admin consent workflow" para que utilizadores
# possam solicitar acesso a apps, que admins aprovam/rejeitam

Além da restrição de consentimento, cria uma Conditional Access policy específica para bloquear aplicações não verificadas:

Definição da Policy	Valor Recomendado
Utilizadores	Todos os utilizadores (excluindo Contas de Emergência)
Aplicações na cloud	Todas as aplicações na cloud
Condições → Plataformas de dispositivo	Todas as plataformas
Controlo de acesso → Grant	Block access para apps não-verificadas; Require admin consent
Session	Sign-in frequency: 1 hora (reduz janela de token theft)

7. Defender for Cloud Apps: Governance de OAuth

O Microsoft Defender for Cloud Apps é a ferramenta central para governance de aplicações OAuth em ambientes SaaS. Em resposta às campanhas dos ShinyHunters, a Microsoft expandiu as capacidades do Defender for Cloud Apps com novas funcionalidades de governance e posture para aplicações OAuth conectadas, incluindo:

• Visibilidade de permissões — inventário completo de todas as apps OAuth conectadas, com scopes concedidos e nível de privilégio;
• Identificação de apps privilegiadas — destaca automaticamente apps com permissões administrativas ou sensíveis que exigem revisão prioritária;
• Identificação de apps inactivas — apps sem actividade há mais de 90 dias, que mantêm permissões desnecessárias;
• Risk scoring de apps conectadas — pontuação de 0-100 baseada em padrões de uso, sensibilidade de permissões e sinais comportamentais;
• Políticas personalizadas — criação de policies baseadas em thresholds de risco que geram alertas, acções e notificações automáticas.

Para PME com Microsoft 365 Business Premium, o Defender for Cloud Apps está incluído no plano. A configuração inicial envolve ligar as aplicações SaaS (Salesforce, se aplicável, e outras apps conectadas ao inquilino M365):

# Ligar Salesforce ao Defender for Cloud Apps
# 1. Portal Microsoft Defender → Cloud Apps → Connected apps
# 2. Selecionar Salesforce → Configurar
# 3. Autenticar com conta admin do Salesforce
# 4. Activar Salesforce Shield: Event Monitoring (RTEM)
#    para detecção em tempo quase real

# Criar policy de detecção de apps OAuth suspeitas
# Cloud Apps → Policies → Policy management → Create policy
# Tipo: OAuth app policy
# Filtros:
#   - Permission level = High
#   - Last used = more than 90 days ago
#   - Publisher = not verified
# Acção: Revoke app + Notify admin

A Microsoft também coordena detecções entre Defender for Endpoint, Defender for Identity e Defender for Cloud Apps, permitindo correlacionar actividade suspeita que abrange identidades, aplicações e ambientes SaaS. Isto é crucial porque os ataques ShinyHunters frequentemente envolvem múltiplas fases — vishing inicial, consentimento OAuth, exfiltração via API — que só são visíveis quando se correlacionam eventos de diferentes fontes (Microsoft Learn — Defender for Cloud Apps).

8. Monitorização com Sentinel e KQL

O Microsoft Sentinel permite criar regras de detecção customizadas para actividade OAuth anómala. A Microsoft publicou queries Advanced Hunting KQL específicas para as campanhas ShinyHunters, que podem ser adaptadas para PME com Sentinel. As queries abaixo foram extraídas do relatório oficial da Microsoft (Microsoft Security Blog):

// Query 1: Caçar atividade de connected-apps Salesforce
// a partir de infraestrutura suspeita
CloudAppEvents
| where Application == "Salesforce"
| where ActionType in ("ApiTotalUsage", "API Event")
| extend ConnectedAppId = tostring(
    coalesce(
        RawEventData.CONNECTED_APP_ID,     // from ApiTotalUsage
        RawEventData.ConnectedAppId         // from API Event
    )
  )
| where isnotempty(ConnectedAppId)
| where array_length(UncommonForUser) > 0  // pelo menos 1 atributo incomum

// Query 2: Caçar exportação anómala de relatórios
// (potencial exfiltração de dados)
CloudAppEvents
| where Application == "Salesforce"
| where ActionType == "ReportExport"
| extend SalesforceUserId = tostring(RawEventData.USER_ID)
| summarize Events = count() by AccountObjectId, AccountId,
           AccountName, SalesforceUserId, IPAddress, UserAgent

// Query 3: Caçar utilizadores com risk score alto
// a iniciar sessão via SSO no Salesforce
let VeryRiskyUsers = IdentityInfo
    | where RiskScore >= 90
    | distinct AccountObjectId;
CloudAppEvents
| where Application == "Salesforce"
| where ActionType has "sso" or ActionType has "saml"
| where AccountObjectId in (VeryRiskyUsers)
| project Timestamp, AccountObjectId, AccountDisplayName,
          ActionType, UserAgent
| order by Timestamp desc

// Query 4: Auditar que objectos os utilizadores estão a aceder
CloudAppEvents
| where Application == "Salesforce"
| where ActionType == "UniqueQuery"
| extend QueryText = tostring(RawEventData.QUERY_IDENTIFIER),
         QueryObject = extract(@"(?i)\bfrom\s+([^\s]+)", 1,
             tostring(RawEventData.QUERY_IDENTIFIER)),
         SalesforceUserId = tostring(RawEventData.USER_ID)
| where QueryText != "SOQL"
| project Timestamp, AccountDisplayName, SalesforceUserId,
          QueryObject, QueryText

Para PME sem Sentinel, as mesmas queries podem ser executadas no portal Microsoft Defender → Advanced Hunting, que está incluído no Microsoft 365 Business Premium. Embora não permita automatizar respostas como o Sentinel, fornece visibilidade de caça a ameaças equivalente (Microsoft Learn — Advanced Hunting).

9. Prevenção de PME: Estratégias Práticas

As PME portuguesas têm recursos limitados, mas existem cinco estratégias práticas que reduzem drasticamente o risco de abuso de OAuth sem exigir investimento significativo:

Estratégia 1 — Restringir Consentimento a Administradores

A medida mais eficaz e de custo zero. No portal Entra ID, configura o consentimento de aplicações para “Do not allow user consent” ou, no mínimo, “Allow user consent for apps from verified publishers, for selected permissions”. Isto impede que utilizadores não-admins autorizem aplicações maliciosas — o vector primário dos ShinyHunters.

Estratégia 2 — Auditoria Trimestral de Aplicações OAuth

Agenda uma revisão trimestral de todas as aplicações OAuth com consentimento no inquilino. Remove apps inactivas, revoga permissões desnecessárias e documenta as apps legítimas. Usa o script PowerShell da secção 4 para automatizar o inventário.

Estratégia 3 — Formação Anti-Vishing

Os ShinyHunters usam vishing — chamadas telefónicas a fazer-se passar por suporte IT — para enganar utilizadores e guiá-los através do consentimento OAuth. Forma os utilizadores para: (1) nunca autorizar aplicações a pedido telefónico, (2) verificar o URL do consentimento (deve ser login.microsoftonline.com), (3) contactar o IT interno para confirmar qualquer pedido de autorização de app.

Estratégia 4 — Validar Integrações de Terceiros

Antes de ligar qualquer integração SaaS (Salesforce, HubSpot, Salesloft, Gainsight) ao inquilino M365, verifica: (1) se o fornecedor tem publisher verification no Entra ID, (2) quais as permissões mínicas necessárias, (3) se o fornecedor tem histórico de incidentes de segurança. Documenta cada integração com nome do fornecedor, data de autorização e permissões concedidas.

Estratégia 5 — Activar Defender for Cloud Apps

Se a PME tem Microsoft 365 Business Premium, o Defender for Cloud Apps está incluído. Liga-o para todas as aplicações SaaS conectadas e configura policies de OAuth app governance. Mesmo sem Salesforce, as políticas de governance de OAuth aplicam-se a Microsoft 365, Google Workspace e outras apps conectadas.

10. Erros Comuns na Gestão de OAuth

Problema	Causa	Solução
Utilizadores podem consentir qualquer app sem aprovação	Configuração predefinida do Entra ID permite consentimento de utilizador	Alterar para “Do not allow user consent” ou “verified publishers only”
Apps OAuth antigas mantêm permissões elevadas	Ninguém audita consentimentos após projectos terminados	Auditoria trimestral; revogar apps inactivas > 90 dias
Integração SaaS comprometida expõe dados M365	Tokens OAuth de terceiros (Salesloft, Gainsight) são abusados após compromisso do fornecedor	Monitorizar alertas de segurança do fornecedor; revogar tokens após incidentes; usar permissões mínimas
Utilizador autoriza app maliciosa após chamada telefónica (vishing)	Falta de formação anti-vishing; não há processo de verificação de pedidos IT	Formação obrigatória; processo interno para confirmar pedidos IT por canal alternativo
Consentimento OAuth não é revogado após desactivar conta	Desactivar conta no Entra ID não revoga automaticamente tokens OAuth de apps	Executar Revoke-MgUserSignInSession no processo de offboarding de utilizadores
Defender for Cloud Apps não está activo	Licença Business Premium inclui a funcionalidade mas não é configurada por defeito	Ligar Defender for Cloud Apps no portal Microsoft Defender; configurar OAuth policies
Tokens de actualização permanecem válidos durante semanas	Sign-in frequency não configurada no Conditional Access	Configurar sign-in frequency para 1-7 dias; activar Continuous Access Evaluation (CAE)

11. Checklist Rápido de Verificação

• [ ] Restringir consentimento OAuth a admins no Entra ID (Enterprise Applications → Consent settings)
• [ ] Configurar admin consent workflow para pedidos de utilizadores
• [ ] Executar inventário de todas as apps OAuth com consentimento no inquilino
• [ ] Revogar consentimentos de apps não reconhecidas ou inactivas > 90 dias
• [ ] Verificar que todas as apps com permissões Mail.Read, Files.ReadWrite.All ou Directory.Read.All são legítimas
• [ ] Activar Defender for Cloud Apps para todas as apps SaaS conectadas
• [ ] Configurar OAuth app policy no Defender for Cloud Apps (risk score threshold)
• [ ] Criar Conditional Access policy com sign-in frequency de 1-7 dias
• [ ] Activar Continuous Access Evaluation (CAE) no Entra ID
• [ ] Importar queries KQL ShinyHunters para Sentinel ou Advanced Hunting
• [ ] Incluir Revoke-MgUserSignInSession no processo de offboarding de utilizadores
• [ ] Formar utilizadores sobre vishing e consent phishing (trimestral)
• [ ] Documentar todas as integrações SaaS de terceiros com permissões concedidas
• [ ] Verificar publisher verification de todas as apps OAuth no inquilino
• [ ] Subscrever alertas de segurança de fornecedores SaaS de terceiros

Artigos Relacionados

• Phishing-as-a-Service no Microsoft 365: Detectar e Bloquear Kits PhaaS
• Conditional Access no Entra ID: Configuração Prática
• Zero Trust para PME em 2026: 5 Pilares Práticos
• Microsoft Sentinel: SIEM para PME
• MFA FIDO2 Phishing-Resistente no M365 e Google Workspace
• Identity Governance e Risk Management no Entra ID para PME
• Phishing Moderno: Detectar e Prevenir
• PIM: Gestão de Acesso Privilegiado no Entra ID

← Voltar ao Índice